Encrypted Folders (EFT Encrypted)

Encrypted Folders (EFT Encryption)

EFT Server provides the following 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.
Integrated Windows encryption via Encrypted File Share (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.
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. In SSL FIPS mode , encryption at rest uses the FIPS-certified SSL library.

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 logs in and downloads the file, the file will 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).

NOTE: Encrypted folders with long paths are not supported.

Encrypted Folders Command-Line Utility - EFT’s built-in folder encryption feature will encrypt files as they arrive or decrypt them as they leave EFT via standard protocols; however, there may be instances where you need to encrypt or decrypt files independent of EFT, while adhering to the same encryption mechanisms (AES-256 symmetric-key). For example, you may want to encrypt a file received by a folder monitor rule, or conditionally encrypt files prior to emailing them, or decrypt previously encrypted files side-channeled into EFT from a different EFT server. To that effect, EFT’s encryption/decryption subroutines have been exported to a command utility, eftencrypt.exe, which is installed alongside EFT in the \Redistributables subfolder. You can run the utility directly or from within EFT’s Event Rules, by leveraging the built-in PowerShell action. You can also copy the utility to another computer to encrypt and decrypt files there. (The utility follows standard command line rules.)

To use the eftencrypt.exe utility

Locate the eftencrypt.exe utility. (The default is C:\Program Files\Globalscape\EFT Server\)
Locate your Site or specific Encrypted Folder’s encryption key. Alternatively, create a new 256-bit key (64 hexadecimal characters, i.e. 32 bytes in length).
Locate the name of the target file you want to encrypt or decrypt.
Launch a command line prompt or PowerShell, running as Administrator. Alternatively, create a PowerShell action in EFT’s event rules.
To encrypt or decrypt in place, type: eftencrypt.exe <key> <path to target file>
To encrypt or decrypt using source and destination: eftencrypt.exe <key> <path to source file> <path to target file>

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 provides an advanced property, IgnoreEncryptedFoldersInOutboundTransfers, which can be used to prevent EFT from decrypting encrypted folders during transfers. For example, EFT receives a file into an encrypted folder and EFT encrypts it. Then the file is transferred to another system using EFT’s “Copy/Move” event rule action, which normally results in the file being decrypted. If the advanced property IgnoreEncryptedFoldersInOutboundTransfers is set to True, the file will remain encrypted when transferred. It can then can be decrypted later with the eftencrypt.exe utility.

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. (See below for instructions for creating the key.)

EFT randomly generates the Encrypted Folders key upon new Site creation. You should change the secret and maintain a copy of the secret in your key manager.
If the Advanced Property EncryptedFolderKey is defined and not malformed, EFT uses it for encryption/decryption, read at service startup. (This is mainly for EFT upgrades to 8.0.4 from earlier builds. The key can be created/edited in the Encrypted folders dialog box, as described below.)
Upon EFT upgrade, EFT generates a new key if the key is the old "default" value, and no other key is defined
Per-folder encryption keys can be used to encrypt the contents of all data in the site root automatically, using a separate key for each sub-folder off of the site root, and also for folders referenced by virtual folders (VFS) that are shared by users.

The following considerations for encrypted folder targets should be noted:

Encrypted folders are limited to physical folders (Per-folder encryption keys can be used on physical folders referenced by virtual folders.)
Encrypted folders affect subfolders within the designated folder
Encrypted folders can only point to folders that are under the Site root (for example, C:\InetPub\EFTRoot\MySite)
When using Encrypted folders, you can only encrypt files in the directory hierarchy of the Site's root folder. Make sure that the Site root folder on the Site > General tab is pointing to the correct path. That is, if the HA config drive is D:\HAConfig\, you should edit the Site root folder to point to D:\HAConfig\InetPub\EFTRoot\MySite.
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 administrators. 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
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.

If you are remotely connected via the administration interface, you will not be able to browse for folders. Instead, you must specify a valid, approved path, local to the server.
Whether local or remotely connected via the administration interface, administrator accounts beneath the role of Server administrator (that is, Site administrator and below) will not able to browse for folders. Instead, these administrators 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 Advanced Workflows), that file could be encrypted, and thus Advanced Workflows 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
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 (for example, 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."
Before you enable this feature, it is recommended that you set up appropriate backup measures to protect your data. If you need to recover a private key to decrypt data, and that key is lost, you will not be able to recover the data that the key protects. If you need more information on setting up appropriate backup procedures, refer to Configuration and Security Best Practices.
If you had used the Encrypted Folder Key advanced property in versions prior to v8.0.4, the property for the key will appear in the AdvancedProperties.json file. EFT only uses that advanced property for backwards compatibility. After upgrading, if you want to change the key you should do so in the EFT administrator interface, NOT via the advanced property.
The following scenarios represent the only way in which files get ENCRYPTED when interacting with an encrypted folder:
- When files are uploaded to EFT via HTTP/FTP/SFTP into an encrypted folder.
- When files are downloaded by EFT (via a download action) via all protocols including LAN, from a remote server into an encrypted folder.
  - Likewise when using EFT’s synchronize action (make local just like the remote), when downloading to an encrypted folder.
- When PGP action writes file to an encrypted folder. The file is first PGP encrypted then AES-256 encrypted in a streaming fashion.
The following scenarios represent the only way in which files get DECRYPTED when interacting with an encrypted folder:
- When files are downloaded from EFT via HTTP/FTP/SFTP. The file is decrypted before it is sent down the wire.
- When files are uploaded (offloaded) by EFT (via copy/move action) via all protocols including LAN, to a remote server.
  - Likewise when using synchronize action (make remote appear as local), when uploading from an encrypted folder.
- When PGP action reads a file from an encrypted folder. The file is first AES-256 decrypted, then PGP decrypted in a streaming fashion.
The advanced property IgnoreEncryptedFoldersInOutboundTransfers is used to prevent EFT from decrypting encrypted folders during transfers. For example, EFT receives a file into an encrypted folder and EFT encrypts it. Then the file is transferred to another system. If the advanced property IgnoreEncryptedFoldersInOutboundTransfers is true, the file remains encrypted when transferred. It can then can be decrypted with eftencrypt.exe. Use eftencrypt.exe <key> <path to target file> to run the decryption process, and then file is decrypted.

Site Encryption

You can encrypt all folders under the Site root using a single, reusable key for encrypting and decrypting data. EFT will encrypt all data in that folder and its subs using the Site encryption key. Subsequent files written to those folders by users uploading files will result in those files being encrypted with the site encryption key automatically and transparently. Event Rules that process files written into those folders will decrypt using the site encryption key. (Refer to Enabling EFT-Managed Encryption, below.)

Per-Folder Encryption

If you want to encrypt the contents of all data in the Site root, you can use a separate key for each sub-folder under the Site root, and also for physical folders pointed to by virtual folders (VFS) that are shared by users.

In the Folder to encrypt dialog box, add each sub-folder under the Site root folder, and then assign it a per-folder encryption key, as described in Enabling EFT-Managed Encryption, below. For example:
EFT encrypts all data in the specified folders and sub-folders using the corresponding folder encryption key.
Subsequent files uploaded to those folders by users will be encrypted with the corresponding folder encryption key.
Event Rules that process files written into those folders will decrypt the files using the folder encryption key.

User-Specific Encryption

If you want to encrypt the contents of all data in the Site root, and also want to use a user-specific encryption key.

In the Folder to encrypt dialog box, click the folder icon to select a user's home folder.
Click Use unique encryption key and provide a key from the user's password manager.
Click OK.
EFT will encrypt all data currently in that folder and its sub-folders, including any physical folders pointed to by virtual folders, using the corresponding folder encryption key.
Subsequent files written to those folders by users uploading files will result in those files being encrypted with the corresponding folder encryption key.
Subsequent physical folders added by the user or admin or physical folders added by nature of a new virtual folder being associated with that user will results in their newly added contents also being encrypted.
Event Rules that process files written into those folders will decrypt using the corresponding user encryption key.

Enabling EFT-Managed Encryption

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.

Set the value to a string of exactly 64 hexadecimal digits (that is, 0-9 and A-F)
This value is not used if the value is blank or malformed (for example, if you have more or less than 64 digits)
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.

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

Type or browse for the folder that you want to encrypt. You can only encrypt the folders in the Site's root folder (for example, C:\InetPub\EFTRoot\MySite). (See note above regarding clusters.)
Click one of the following:

For the Site encryption key, click Use this Site (master) encryption key (the default).
For per-folder encryption, click Use unique encryption key, then paste or type the key (64 hexadecimal characters, 256-bit key). Optionally, provide an alias for this key. Note that using the same alias more than once does not cause a prompt, warning, or error. You can provide anything you want as an alias. The alias is purely for you to identify keys. If you want to use the same alias or no alias, you can. (However, providing the same alias for more than one key defeats the purpose of providing the alias.)

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 or replace an encrypted folder from the list

On the Site > Security tab, click Configure next to Encrypted folders. The Encrypted Folders dialog box appears.

If the Folder Path list is empty, then the password field is NOT read only (that is, you can change the key).
If the Folder Path list is NOT empty, select a folder in the list of folders, then click Remove. All encrypted files in the "removed" folder will be decrypted. (This may take a long time if there are many files in the folder. Note that files are not deleted, just unencrypted.)

In the Secret key box, provide a new key, then add the folder(s) back to the dialog box to be encrypted.
Click OK to close the dialog box, then click Apply.