faspex™ Security Model
The Aspera faspex™ Server application has a comprehensive security model that provides for secure access to the faspex™ web application, secure authorization of user transfer requests, secure transport of the file data over the network, and optional encryption of the file content stored on the faspex™ server.
faspex™ transport and content security is based on a complete, open standards security model implemented with FIPS 140-2 compliant cryptography libraries (as required by DoD security standards), and has undergone rigorous security testing by independent third-parties. The components of the faspex™ security model are detailed below.
Secure Access to the faspex™ Web Application and Transfer Authorization
Steps 1-4: When the faspex™ application needs to upload or download files, it will build a file reference URL with the “fasp://” scheme. The fasp™ URL is built dynamically when the user selects upload or download functions and includes a unique authorization token generated on the server side through a cryptographic hash function performed on the path name, direction of transfer, time stamp, and user name, along with a unique secret known to the server (stored in a root-only accessible configuration file on the server). The token allows the user to upload or download the authorized files and directories for a period of time (which can be set by the faspex™ administrator).
Steps 5-6: The Connect client decodes the URL, extracts the token, server, path name and other transfer policy settings, and initiates a fasp™ transfer to the Enterprise Server. The transfer initiation is performed as a standard SSH connection from the fasp™ client core (in Connect) to the fasp™ server core. This process securely authenticates the client host to the server host, as well as establishes a secure encrypted connection for the transfer session initiation phase.
Step 7: During session initiation, Aspera’s Enterprise Server software verifies the validity of the token, decrypting the token using the server-side secret and extracting the file path, timestamp, direction and user constituents. If the verification passes and the token is still valid, the transfer is authorized - otherwise the client gets an “unauthorized to transfer” error.
Once an end user signs into the faspex™ web application over a standard HTTPS connection, faspex™ securely authorizes each file upload and/or download. The user is authenticated to the faspex™ web application over a standard secure SSL connection, ensuring secure transmission of the password exchange over the wire. Please note that password strength is configurable on the faspex™ server (Administration interface > faspex™ Server > Security Options > "Use Strong Passwords"). If this option is selected, the user password strength follows a standard strong password security model, requiring new user passwords to contain at least one letter, one number, and one symbol.
If the user requests a transfer upload or download from faspex™ after being securely authenticated, the transfer is then securely authorized using a secure token exchange performed over a standard, secure SSH connection between the fasp™ core, the end user’s Connect client, and the fasp™ core in the Enterprise Server software that underpins faspex™.
The SSH authentication from the FASP™ client to the FASP™ server is performed using a public-private key exchange (as the “Faspex” system user account). The private key is installed by default with the Connect client on the user's machine, so that the underlying SSH authentication works out-of-the-box (with no user configuration required). Consequently, all transfers authenticate as the same SSH user account. The token-based authorization that occurs on top of the default SSH authentication ensures that each individual transfer running as the specific faspex™ user is authorized. Because the account is configured with no password login capability, as well as with a default shell set to the asperashell (which enforces a chroot-like jail on the server), the server is protected from malicious programs or users attempting to log into the server as the default “Faspex” SSH user account.
The asperashell ensures that the only operation that can be performed within the “Faspex” user login shell on the server is an “ascp” transfer (where no other executables whatsoever, including “ls,” “mkdir,” etc., are allowed or supported within the restricted asperashell). Additionally, any “ascp” execution attempted within the asperashell must have a valid token in order to run. Consequently, no rogue program or user can execute an unauthorized “ascp” transfer by connecting to the server via SSH as the default “Faspex” account.
Aspera provides a Security Best Practices document to maximally harden the faspex™ server application and host operating system. For example, the recommended procedures take advantage of Enterprise Server’s advanced security features to restrict that only the faspex™ user account may be authorized for transfers. Another best practices example is to restrict faspex™ administrator access from certain IP address ranges within the faspex™ web application.
Secure Data Transport
If the transfer is authorized and data transfer takes place, the FASP™ protocol uses a complete security model for the data transfer, assuming encryption has been configured ON in the faspex™ Server (Administration interface > Faspex Server > Security > "Encrypt Transfers" ON).
The initial secure SSH authentication (using the SSH public-private key exchange as the “Faspex” user account) seeds an AES-128 encryption algorithm. Once the session is established, the fasp™ sender itself performs AES-128 encryption on-the-fly with a per-packet cryptographic checksum. Each packet is verified for integrity and decrypted on-the-fly at the fasp™ receiver before the file is written to disk. The security implementation uses the cryptographic functions of the standard openSSL toolkit, using a FIPS 140-2 compliant version of the cryptography libraries, and is described in detail under the FASP security model.
The security model, based solely on open standards cryptography, consists of secure authentication of the transfer endpoints using the standard secure shell (SSH), on-the-fly data encryption using strong cryptography (AES-128) for privacy of the transferred data, and an integrity verification per data block, to safeguard against man-in-the-middle and anonymous UDP attacks. The transfer preserves the native file system access control attributes between all supported operating systems, and is highly efficient.
Secure Endpoint Authentication: Each transfer session begins with the transfer endpoints performing a mutual authentication over a secure, encrypted channel, using SSH ("standard secure shell"). SSH authentication provides both interactive password login and public-key modes. Once SSH authentication has completed, the FASP™ transfer endpoints generate random cryptographic keys to use for bulk data encryption, and exchange them over the secure SSH channel. These keys are not written to disk, and are discarded at the end of the transfer session.
On-the-fly Data Encryption: Using the exchanged keys, each data block is encrypted on-the-fly before it goes on the wire. fasp™ uses a 128-bit AES cipher, re-initialized throughout the duration of the transfer using a standard CFB (cipher feedback) mode with a unique, secret nonce (or "initialization vector") for each block. CFB protects against all standard attacks based on sampling of encrypted data during long-running transfers.
IMPORTANT NOTE on CIPHERS: While the FASP™ library is designed for modular substitution of new ciphers as the state-of-the-art evolves, 128-bit AES is the default implementation today as the widely accepted industry standard for strong cryptography. Unlike 256-bit AES, 128-bit AES has no successful attacks with practical levels of complexity, AND provides for faster encryption. Some vendors make the false and erroneous claim that 256-bit AES is “more secure” than 128-bit AES. Quite the opposite, the state-of-the-art in cryptographic attack research has shown that 256-bit AES is vulnerable to attacks of practical complexity, and according to well-known security experts, should not be used in new products. For more information, please see for example: www.schneier.com/blog/archives/2009/07/another_new_aes.html
Integrity Verification: FASP™ accumulates a cryptographic hashed checksum, also using 128-bit AES, for each datagram. The resulting message digest is appended to the secure datagram before it goes on the wire, and checked at the receiver to verify message integrity. This protects against both man-in-the-middle and re-play attacks, and also against anonymous UDP denial-of-service attacks.
Secure Storage of the Files on the faspex™ Server ("Content Protection" or “Encryption At Rest”): All Aspera products, including faspex™, support the ability to leave transferred files encrypted in storage ("encryption at rest") using AES-128 and a uniquely encrypted envelope per recipient. This ensures that stored content is protected as it is stored on untrusted systems. The faspex™ server application can be configured to require encryption-at-rest, to require the Connect client on upload to provide an encryption passphrase before the files are uploaded (Administrator interface > Configuration > Security > “Content Protection” ON and Enterprise Server GUI > Server Configuration > “Require Content Protection” ON). The encrypted files are stored with an "aspera-env" extension on the faspex™ server; when downloaded through faspex™ , Connect prompts the user to enter the passphrase and if provided, decrypts the enveloped file on-the-fly before writing to disk. The user may bypass entering the passphrase, and Connect will leave the file(s) during download in encrypted form. The files may be decrypted later through command-line and right-click shortcut options.
Additional Security Options for faspex™
faspex™ includes several additional features that are useful for controlling / restricting what users can do on the system. Several features are described below:
User Restrictions: Each user account can be restricted by which IP address(es) they are allowed to upload or download from, an expiration date for the account logging in to faspex™, whether the account is a workgroup admin, and whether the account has permission to upload only, download only, send to external email addresses (non-registered users), and forward packages.
One-time Download / External Users: faspex™ can be configured to allow (or strictly prohibit) non-registered users to receive a one-time link to download files. The link has a secure token that has either an expiration date (e.g. 24 hours, as configured on the server) or an allowed number of downloads. If sending to external users is allowed, these policies ensure that if the email is stolen or given to an attacker, the content cannot be downloaded after the expiration date or after the content has already been downloaded by the intended recipient. Transfers by these users follow the same Transport Encryption and Encryption-at-Rest policies configured for the server.
Finally, please be sure to see the Security Best Practices document for several specific guidelines on configuring the Linux host operating system on which faspex™ is deployed for maximum security.