Encrypted Folders (EFT Built-in, Secure-Data-at-Rest Solution)

EFT Server provides three forms of securing files on disk (data-at-rest encryption):

  • OpenPGP-based encryption is a well-known, dual-key based encryption technology. The primary benefit is the fact that only recipients whose public key was included at the time of encryption will be able to decrypt the file, assuming they own the corresponding private key to their public one. This provides more control over who can access the data, vs. other methods. PGP has two shortcomings: First, it requires that participants create and maintain their key pairs, adding complexity to the process. Second, it is not a streaming encryption technology, as the entire file must be present (written to disk) before encryption (or decryption) can occur. In the context of file transfers, the result is temporary files that cause havoc with automation that consumes files the moment they are received in the target directory. Refer to OpenPGP and EFT for how to use OpenPGP.

  • Encrypted folders (EFT built-in encryption) provides an alternative to using a best-of-breed 3rd party data-at-rest encryption solution. EFT’s encrypted folders provide streaming encryption (and decryption), enabling transparent, seamless file read/write. The symmetric encryption leverages AES 256 in CTR mode, with the encryption key known only to EFT. Any file touched by EFT’s protocols (either as a server or as a client) are automatically encrypted (or decrypted) on arrival or departure, as appropriate.

    • The primary drawback to the built-in encryption feature is that fact that any side-channeled files, such as those directly copied into a folder designated as an encrypted folder, will not be encrypted or decrypted by EFT. In fact, if you place a plaintext file in an encrypted folder and a customer log in and downloads the file, the file be corrupted, as EFT will attempt to decrypt what it thinks is an encrypted file. This risk can be mitigated by never side-channeling files into folders designated as secure, instead, use EFT’s event rule Copy/Move-> LAN copy action to move files from network shares or physical folders into the secure target, as that will result in the content being encrypted (or decrypted, if done in the other direction).

Each of these methods has benefits and drawbacks. Other alternatives include using third-party data-at-rest encryption, such as the built-in encryption provided by some NAS devices.

EFT Built-in Encrypted Folders

Physical folders can be transparently encrypted during read/write using EFT-managed AES-256 symmetric encryption (CTR mode), which uses a secret key known only to the server. The server will encrypt files as they arrive over supported protocols, and decrypt files when departing over those same protocols. The server, when acting as a client, will also encrypt files that it downloads into an encrypted folder, and decrypt files that it copies or moves to a remote server, including LAN copy.  

The following limitations for encrypted folder targets should be noted:

  • Encrypted folders are limited to physical folders

  • Encrypted folders affect subfolders within the designated folder

  • Encrypted folders can only point to folders that are under the Site root

  • Encrypted folders cannot be EFT system folders (such as program directory)

  • Encrypted folders cannot be EFT system folders (Install Folder, App Data Folder, Cluster Share) and Windows reserved directories (Windows, ProgramData, ProgramFiles, ProgramFilesx86), or their parents or children, and cannot be specified even by server admins. This is includes subfolders of those folders.

  • When configuring network shares for data encryption, the EFT service account must have access to the encrypted folder path; otherwise, you will be presented with a failure

  • When configuring an HA environment, the user home folder paths (by default, C:\Inetpub\) must not reside under the shared configuration, otherwise the encryption will fail because it will consider \Inetpub\ a reserved path. A workaround is to create a separate share for \Inetpub\ (user home folders) so that it doesn't trigger the reserved path error.

  • Using the CIC Action with encrypted files will not return an accurate result. Copy/move the files to a folder that is not encrypted to process with the ICAP server.

To enable EFT-managed encryption

  1. In the administration interface, connect to EFT and click the Server tab.

  2. On the Server tab, click the Site you want to configure.

  3. In the right pane, click the Security tab.  

  4. In the Data Security area, next to Encrypted folders, click Configure. The Encrypted Folders dialog box appears.

  5. To add folders that contain files you want to encrypt, click Add. The Folder to encrypt dialog box appears.

  6. Type path to the folder that you want to encrypt, then click OK. (The browse function is disabled in Arcus, so you will need to work with Support to provide the path that you want to encrypt.)

    Files uploaded to this folder will be encrypted upon arrival and decrypted upon departure over EFT's supported protocols. EFT will also encrypt files that are downloaded (as client) into an encrypted folder, and decrypt files that are copied or moved to a different location.

    EFT will attempt to decrypt any and all files already present in the folder. (This may take a long time if there are many files in the folder.)

To remove an encrypted folder from the list

  1. Click it in the Encrypted Folders dialog box, then click Remove.

  2. All encrypted files in the folder will be decrypted. (This may take a long time if there are many files in the folder.)

Considerations

  • If remotely connected (via Admin GUI), you will not be able to browse for folders. Instead, remote users must specify a valid, approved path, local to the server.

  • Whether local or remotely connected (via Admin GUI), admins beneath the role of Server admin (i.e., Site admin and below) will not able to browse for folders. Instead, these admins must specify a valid, approved path, local to the server.

  • If the server cannot perform initial encryption or final decryption due to lack of permissions, sharing violations, or network disconnect, a warning will appear indicating that "Some files in the folder were not [encrypted|decrypted]. The data in the folder might be corrupt."

  • The following protocols and protocol commands are encryption/decryption aware:

    • EFT FTP/HTTP/SFTP Server (Listening Engines): all operations: upload, download, resume, FTP COMB, FTP and HTTP XCRC32, HTTP Copy file, HTTP/FTP/SFTP move file/folder, HTTP ZIP Folder Download.

    • EFT FTP/HTTP/SFTP/Local Transfer Client (Client FTP transfers): offload, download, resume, Pre/Post commands, "Rename To" after download, FTP data integrity check (CRC).

  • All side-channel operations and all actions outside of copy/move/download are unaware of encryption/decryption. So if, for example, you have a Timer rule that downloads a file from a remote host, to an encrypted folder, and then a subsequent action attempts to manipulate that file (for example in AWE), that file could be encrypted, and thus AWE will not be able to parse it.

  • A new logger is available in Logging.cfg for output to EFT.log, labeled EncryptedFolders, set to TRACE by default.

  • You can only encrypt the folders in the Site's root folder. If you attempt to encrypt folders outside of the EFT Site's root folder (e.g., C:\InetPub\EFTRoot\MySite) an error prompt occurs: "This folder is not in the directory hierarchy of this Site's root folder."

  • EFT system folders (Globalscape/EFT, AppData, and cluster share) and Windows reserved directories (Windows, ProgramData, ProgramFiles, ProgramFilesx86), as well as their parents or children, cannot be encrypted. If a reserved path is selected in the Folder to Encrypt dialog box, an error prompt occurs: "This is a reserved path and cannot be encrypted."

To change the encryption key

EFT uses a default encryption key that is hard coded in the software. Using the default, hard-coded key introduces risk. If someone were able to obtain the encrypted files, they could decrypt those using their copy of EFT. Therefore it is recommended you change the key prior to using this feature.

  • Set the value to a string of exactly 64 hexadecimal digits (i.e., 0-9 and A-F)

  • This value is not used if the value is blank or malformed (e.g., if you have more or less than 64 digits)

  • If EncryptedFolderKey is defined and not malformed, EFT uses it for encryption/decryption, read at service startup.

  • Restart the EFT server service for the new key to take effect.

  • In an HA or Disaster Recovery scenario, each EFT must share the same key.