Server-Side Encryption at Rest (EAR)

Capabilities

Server-side EAR provides the following advantages:

It protects files against attackers who might gain access to server-side storage. This is important primarily when using NAS storage or cloud storage, where the storage can be accessed directly (and not just through the computer running HST Server or HST Endpoint).
It is especially suited for cases where the server is used as a temporary location–for example, when a client uploads a file and another one downloads it.
Server-side EAR can be used together with client-side EAR. When used together, content is doubly encrypted. For more information, see Client-Side Encryption-at-Rest (EAR).
Server-side EAR doesn't create an "envelope" as client-side EAR does. The transferred file stays the same size as the original file. The server stores the metadata necessary for server-side EAR separately in a file of the same name with the file extension .aspera-meta. By contrast, client-side EAR creates a envelope file containing both the encrypted contents of the file and the encryption metadata, and it also changes the name of the file by adding the file extension .aspera-env.
It works with both regular transfers (FASP) and HTTP fallback transfers.

Server-side EAR is not designed for cases where files need to move in an encrypted state between multiple computers. For that purpose, client-side EAR is more suitable: files are encrypted when they first leave the client, then stay encrypted as they move between other computers, and are decrypted when they reach the final destination and the passphrase is available.
Server-side EAR does not work with multi-session transfers (using ascp -C or Node API multi_session set to greater than 1).
Do not mix server-side EAR and non-EAR files in transfers, which can happen if server-side EAR is enabled after the server is in use or if multiple users have access to the same area of the file system but have different EAR configurations.

Set the docroot in URI format.
Server-side EAR requires the storage to have a docroot in URI format, such that it is prefixed with file:///. The third slash ( / ) does not serve as the root slash for an absolute path. For example, a docroot of /home/xfer would be set as file:////home/xfer and a docroot of C:\Users\xfer would be set as file:///C:\Users\xfer.
To configure the docroot options, click Configuration and set configurations for Global, Groups, or Users under their respective Docroot tabs. Select Override in the setting row to set a docroot and adjust read, write, and browse privileges. User docroot settings take precedence over group settings, which take precedence over global settings.
Set the password.
The server-side EAR password can be set for all users (global), per group, or per user. In the Server Configuration dialog, click the Authorization tab and locate the setting for Content Protection Secret. Select the override box and enter the password.