Introducing FullContact CipherFTP 

CFTP: a new and easier way to secure file transfers.

Introduction

The File Transfer Protocol (FTP) is something that businesses rely on even to this day. While transferring your company’s sensitive data it is important to keep in mind how you are keeping that data secure. While using SFTP accomplishes many important security objectives, The FullContact-built CipherFTP (CFTP) accomplishes even more. CFTP is easy to use, provides in transit and at rest encryption by default, and provides out of the box internal logging and auditing. 

Let’s start by examining what FTP is and when it was introduced. The File Transfer Protocol (FTP) allows an organization to host file storage and enables users to log in with usernames and passwords to download and upload files to the server. FTP is widely used in the identity and data provider industry to transfer large files between identity providers, brands, and publishers. While FTP is a solution relied upon in day-to-day business, FTP is not a new solution–it’s been around quite a while!

The problem of transferring files between computers predates the modern internet and the World Wide Web. Shortly after the first early computers were connected through ARPANET, the first FTP protocol was created in 1971 (RFC 114) to enable the transfer of files from one computer to another. Over the past 50 years, this protocol has evolved, transformed, and changed into today’s two widely used protocols. They are most commonly known as the File Transfer Protocol (FTP RFC 989) and the SSH File Transfer Protocol (SFTP Internet Draft Standard). 

While SFTP addresses many more security concerns than the original FTP, we knew we could offer our customers even more protection by default. By building on top of existing standards and open source libraries (SFTP and the golang sftp library), FullContact introduced a new server called CipherFTP (CFTP). CFTP provides all of the protection of SFTP while introducing new secure-by-design features that usually need to be manually implemented or bolted onto SFTP. To examine the differences between FTP, SFTP, and CFTP, we will explore the security challenges that need to be addressed when transferring sensitive data over insecure networks:

• Authentication 
• Server identity and trust
• Confidentiality in transit 
• Confidentiality at rest
• Auditing 

Authentication

Authentication is how a user proves they are who they claim to be. Once a server has established a user’s verified identity, it can grant them appropriate access to systems and data. 

The most common way to establish identity is through a username and password. While passwords have several shortcomings, one of the most underlying issues is that they rely on shared knowledge. 

To illustrate the problem of shared knowledge and FTP passwords specifically consider the following examples:

• Bob and Sally work at AcmeInc, and both need to send data to a company called DataInc. DataInc proceeds to create a username called acme with password foo.
• As more and more people need to access the FTP server, the credentials are shared further within the company.
• Bob leaves AcmeInc. Since he still has shared knowledge of the password, he still has access to the data.

• Let’s further imagine that foo is Sally’s favorite password that she uses everywhere else. Using a brute force dictionary attack or data breach containing common passwords for Sally, it is not hard for Evil Bill (who has nothing to do with AcmeInc) to log into their FTP account hosted at DataInc. Evil Bill can then start reading all their data.

Another common way of verifying a user’s identity is through public/private key cryptography. Suppose a user is assigned a public/private keypair. In that case, any user or system can encrypt data using the public key, which can only be decrypted using the corresponding private key. While public keys can be distributed (hence the name “public”), private keys are considered secret and strictly guarded by the user. 

The original FTP server supported only simple usernames and passwords, whereas SFTP supports both usernames and passwords and public/private key authentication.  

CFTP also supports both username/password and public/private key authentication. While FTP and SFTP require user accounts to be created and managed by an administrator (using LDAP or other means), CFTP allows users to create and manage their own accounts. CFTP additionally provides a secure way for users from a shared organization to access shared data while using distinct identities.

Server Identity and Trust

Whenever you are connecting to a server on the public internet, whether that is a web server or a FTP server, there is the chance you might not be connecting to who you think you are connecting to. Imagine the scenario below where Sally thinks she is connecting to ftp.data.inc. In reality, Evil Bill has set up a new server that intercepts the original commands, logs them, and forwards them to the real ftp.data.inc. At this point, Evil Bill has all of the data and any user data and passwords sent.

While this was (and still is) a real problem with the original FTP, SFTP solves this issue the same way SSH does. When a client connects to a SSH or SFTP server, the server will respond with that key’s public key and fingerprint. The client will inspect that fingerprint to see if it matches up precisely with the fingerprint received the last time it connected to that host. If there is a mismatch, there is a chance of a man-in-the-middle attack. So how does the client know if they are connected to the legitimate host the first time? Unlike TLS (the protocol used with https:// when you see the little padlock), there is no trusted certificate chain that can be inspected to see if the host can be trusted.* (While there are SSH implementations that support X.509 certificates, they are not commonly used). If you want to verify that you are connecting to the real CFTP when following the directions below, make sure the key fingerprint returned when connecting to cftp.fullcontact.com matches one of the hashes below:

MD5 : 14:b8:56:4f:f4:2b:3c:fe:d7:4c:8c:b1:85:05:cc:1e
SHA256 : v1oW8uKDdtol9vXlGyTMdcjxRnKH9t9ofjxTNWCaHj

Confidentiality in Transit

Confidentiality in transit refers to how the information transmitted between Sally and ftp.acme.inc can remain secret even if Evil Bill has access to the network. 

The original FTP does not provide confidentiality in transit and allows Evil Bill to see the username/password and all of the data transmitted between Sally and ftp.acme.inc. 

After server identity is confirmed in SFTP, a secure channel is negotiated and established between the client/server using a symmetric key to encrypt all future communications. This allows all of the data sent between Sally and ftp.data.inc to remain secret even if there is a lurking Evil Bill. 

In addition to secrecy, the secure channel also provides integrity by using a standard hashing algorithm. This lets both parties know that the data they are receiving has not been modified somewhere in transit. 

Since CFTP is an implementation of SFTP and uses the same secure channels, CFTP has the same secrecy and integrity guarantees as SFTP.

Confidentiality at Rest

While keeping Evil Bill from reading your data during transmission is important, keeping your data secret after it is stored on disk is also important. By default, both FTP and SFTP store their files to disk exactly as they received them. While it is possible to encrypt the files using a tool like PGP before sending it to an SFTP server, clients often send their data as is (in unencrypted plain text). Even when files are encrypted using PGP, it is very possible that when an individual decrypts the files to process them, the raw decrypted versions may remain on disk much longer than intended. That is unless an organization has strict controls and policies around handling files. 

CFTP approaches this differently and provides confidentiality at rest by default without forcing the client to encrypt their data beforehand using a tool like PGP.  

As a preview, here is what encrypting files on the command line using both openssl and pgp look like. Commands in bold below are typed by the user where non bold lines represent output on the terminal.

OpenSSL Symmetric Encryption Example
echo "hi there" > file.txt
openssl aes-256-cbc -e -in file.txt -out file.txt.enc
enter aes-256-cbc encryption password:
openssl aes-256-cbc -d -in file.txt.enc
enter aes-256-cbc decryption password:
hi there

OpenSSL Asymmetric Encryption Example (using public/private keys)
# generate private and public key
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in private_key.pem -out public_key.pem
# encrypt file using public key
openssl rsautl -encrypt -inkey public_key.pem -pubin -in file.txt file.txt.asym.enc
# decrypt file using private key
openssl rsautl -decrypt -inkey private_key.pem -in file.txt.asym.enc -out file.txt.dec

PGP Asymmetric Encryption Example (using public/private keys)

gpg --full-generate-key
gpg (GnuPG) 2.2.23; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
  (14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 5y
Key expires at Sun Sep 27 11:51:02 2026 MDT
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: cftpblogexample
Email address: cftpblogexample@fullcontact.com
Comment: this is an example for a blog
You selected this USER-ID:
    "cftpblogexample (this is an example for a blog) <cftpblogexample@fullcontact.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 37F3D947A60BC20C marked as ultimately trusted
gpg: revocation certificate stored as '/Users/user/.gnupg/openpgp-revocs.d/ED3E9BCD84C8720C8653D42737F3D947A60BC20C.rev'
public and secret key created and signed.

pub   rsa4096 2021-09-28 [SC] [expires: 2026-09-27]
      ED3E9BCD84C8720C8653D42737F3D947A60BC20C
uid                      cftpblogexample (this is an example for a blog) <cftpblogexample@fullcontact.com>
sub   rsa4096 2021-09-28 [E] [expires: 2026-09-27]

user@FullContact-user-MBP 20210927 % gpg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2022-01-26
/Users/user/.gnupg/pubring.kbx
----------------------------------------

gpg --export --armor cftpblogexample > cftpblogexample_public.asc
gpg --import cftpblogexample_public.asc
gpg --encrypt --recipient cftpblogexample file.txt
gpg --decrypt file.txt.gpg
gpg: encrypted with 4096-bit RSA key, ID 464A25175D1FC7F2, created 2021-09-28
      "cftpblogexample (this is an example for a blog) <cftpblogexample@fullcontact.com>"
hi there

As the raw bytes are received by CFTP, they are buffered in memory and sent in chunks to an internal service called Ciphervisor. Ciphervisor is designed to look up the client specific symmetric key for the account, perform symmetric encryption (AES-128-CTR) using that key and store the encrypted data to an AWS S3 bucket (which also has bucket encryption applied). Keeping the raw data in memory as you encrypt it reduces the risk to that data if an attacker was able to gain access to the server. When paired with the fact that different encryption keys are used for each account the risk that the attacker gains access to your raw unencrypted data is greatly reduced.

In this way, even if an internal actor is able to gain access to an encrypted file or object in S3, they are unable to read it without sending the data through Ciphervisor and requesting that it be decrypted for them. 

Auditing

In systems like FTP and SFTP, auditing typically refers to the process of logging and recording which users have logged in and which actions have taken place. While FTP and SFTP do not provide comprehensive logging out of the box, they can be configured to log file-specific actions taken by each user. With FTP and SFTP, once files are accessed directly on the server by internal users, this log trail is usually lost. And even worse, if Evil Bill ever got into the machine, he could change the logs or even delete them!

With CFTP, any time the data needs to be read, the user must first request it be decrypted through Ciphervisor. This decrypt action is logged and audited. Unlike SFTP, access to files continues to be logged by default even after they are uploaded to the server.

Getting started with CFTP

Follow these steps to start using CFTP to send and receive data to/from FullContact.

1. Create or log in to your FullContact Dashboard account.
   1. Set up a username and password. You will need these when logging in using a client like CyberDuck. Do not use the “Sign in with Google” option.
   2. If you already have a login but don’t know your password the easiest thing to do is to request a password reset
2. Let your account manager or sales representative know the email you are using to upload data. This will allow your data to be processed by authorized users and systems on the back end.
3. Using command line SFTP or common SFTP clients like FileZilla or CyberDuck, upload your files.
   1. This service uses the SFTP protocol
   2. Server: cftp.fullcontact.com (notice it is a ‘c’, not an ‘s’); and if asked for, use port 22 
   3. For your username and password, use the same email you signed up with on the dashboard

Note: Use your full email address for username e.g. john.doe@fullcontact.com

1. Upload and download files as you would on an SFTP account.
2. For additional verification of the server’s identity, use the following fingerprints:
   MD5 : 14:b8:56:4f:f4:2b:3c:fe:d7:4c:8c:b1:85:05:cc:1e
   SHA256 : v1oW8uKDdtol9vXlGyTMdcjxRnKH9t9ofjxTNWCaHj

If you are unable to use the command line SFTP or user interface like Cyberduck you can send a request to your sales or account representative to enable the web CFTP interface built into Platform (this is a new beta feature). Once this feature is enabled on your account you will be able to browse and upload small files (<= 1GB) by dragging and dropping them to your browser.

Summary

When transferring your business’s most sensitive and valuable data, you want to know it’s being done securely and handled with care by those processing it. The primary security objectives you need to consider during any data transfer are: 

• Authentication
• Server identity and trust
• Confidentiality in transit and at rest
• Auditing

While it’s possible to achieve all of the above with SFTP and a few manual solutions, using CipherFTP (CFTP) is easy to accomplish all of them by default. More technical users can upload files to CFTP using a command line or GUI interfaces like CyberDuck or Filezilla. In contrast, users who just want a quick way to securely upload smaller files can take advantage of the new Files interface built into the FullContact Platform. However you choose to transfer your data to FullContact, you can rest assured that the security objectives described in this article are being addressed and that your data is in good hands.

If you have questions about FullContact or CFTP please contact support@fullcontact.com