EFT Server provides three forms of securing files on disk (data-at-rest encryption):
OpenPGP based encryption
Integrated Windows encryption via Encrypted File Share (EFS)
Encrypted folders (EFT built-in encryption)
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.
OpenPGP 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
EFS addresses all of the drawbacks of PGP, eliminating participant key management and providing streaming encryption at the file I/O level; however, it also suffers from two shortcomings: First, some network drive technologies do not support Windows EFS (turning it on in EFT has no effect). Second, standards such as PCI DSS disallow the use of encryption technologies where the keys required for encryption/decryption reside on the systems within PCI scope. It just so happens that Window’s EFS keys do reside on the target system. Refer to Enable EFS Encryption for how to use Windows EFS integration.
EFT built-in encrypted folders 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).
Physical folders stored on the disk in EFT's Virtual File System (VFS) 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. (See below for instructions for creating the key.)
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
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
In the administration interface, connect to EFT and click the Server tab.
On the Server tab, click the Site you want to configure.
In the right pane, click the Security tab.
In the Data Security area, next to Encrypted folders, click Configure. The Encrypted Folders dialog box appears.
To add folders that contain files you want to encrypt, click Add. The Folder to encrypt dialog box appears.
Type or browse for the file that you want to encrypt, then click OK.
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
Click it in the Encrypted Folders dialog box, then click Remove.
All encrypted files in the folder will be decrypted. (This may take a long time if there are many files in the folder.)
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.
COM support is available
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. Override the default key passcode using the following registry setting.
In the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4, create a String Value named EncryptedFolderKey.
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.