fasp Security Model
All Aspera products have complete, built-in security for data transfers using the standard open-source OpenSSL toolkit. The OpenSSL cryptographic libraries and the standard secure shell (SSH2) are used unmodified in order to take full advantage of the standard. Aspera’s products have been approved by the US Department of Commerce for export as a mass-market encryption product with >64 bit encryption. The security model consists of session encryption (to establish a secure channel for exchanging a random per-session key for data encryption), secure authentication of the transfer endpoints, on-the-fly data encryption, and integrity verification for each transmitted data block. The transfer preserves the native file system access control attributes between any of the supported operating systems.
- Built-in security that uses standard open-source OpenSSL toolkit
- FIPS 140-2 compliant.
- Approved by US Department of Commerce for export as mass-market encryption product.
- Secure, encrypted sessions using standard secure shell (SSH2)
- User/endpoint authentication with Native File System Access Control support across all operating systems
- Data encryption in transit and at rest with support for AES-128, AES-192 and AES-256 cryptography
- Encryption at rest supports for both client-side and server-side secrets and automatic resume of interrupted transfers and HTTP fallback transfers
- Configurable policies for token authorization to specify token lifetime
- Data integrity verification for each transmitted block
- Full cross platform (Linux, Windows, OS X, Solaris on Intel, BSD) support for encryption acceleration using AES-NI CPU support (2X transfer speed for same CPU)
- Qualys A+ security review on all Aspera transfer server products when configured using best practices
- Standard open-source encryption supports alternative ciphers, if needed
- LDAP, Active Directory user authentication
- Encryption in transit and at rest assures maximum security of business-critical digital assets
- Data integrity verification guards against man in the middle attacks
Firewall Configuration Summary
- Aspera transfers use one TCP port for session initialization and control, and one UDP port for data transfer
- Concurrent transfers on Windows require a range of UDP ports because Windows does not allow the use one port for multiple connections
Each transfer job begins by establishing a secure, encrypted session between the endpoints, using the standard secure shell (SSH2). SSH2 uses a DH (Diffie-Hellman) key agreement to negotiate the session encryption key. Each host has a host-specific RSA key (normally 1024 bits) and dynamically generates a new server RSA key (normally 768 bits) each time the ssh daemon starts up. This key is normally regenerated every hour if it has been used, and is never stored on disk. When an ssh client connects, the daemon responds with its public host and server keys, and the client and server negotiate the session encryption key.
Once the secure session channel is established, the transfer endpoints authenticate using one of the secure authentication mechanisms in ssh: interactive password or public-key. For public key authentication, the private keys are stored encrypted on disk using a secure, private passphrase and authentication is done using RSA/ECDSA (SSH2) public key exchange. The ssh-keygen program is distributed with the Windows version of Aspera scp for generating RSA/ECDSA keys. The default key length is 1024 bits although the user may request longer key lengths.
Once SSH authentication has completed, the FASP transfer session performs a three-way handshake during which the remote endpoint generates a random AES-128/192/256 -bit per-session key for data encryption, and a random 128-bit key for computing a SHA2 checksum, and sends these keys to the initiator over the secure ssh channel. A new encryption and HMAC-SHA2 key is generated on each FASP transfer session, and the keys are never stored on disk.
FASP by default uses 128-bit AES encryption in which the key is re-initialized throughout the duration of the transfer using Cipher Feedback (CFB) mode (FASP core v.3.7 and earlier) with a unique, secret nonce (or "initialization vector") for each block, protecting against all standard attacks based on sampling of encrypted data during long-running transfers. AES Galois Counter mode is expected to be introduced in v. 3.8. FASP source code also includes configurable options to use AES-192 or AES-256 for encryption in transit.
FASP also supports both client-side and server-side controlled encryption at rest, configurable per session using the same cipher as the in-transit encryption.
Encryption is performed on-the-fly with no pre-or post transfer steps required and without slowing the end-to-end transfer time. At rest encryption supports both client side encryption at rest whereby content is encrypted with a secret provided by the sender, and server side encryption for seamless on-the-fly encryption and decryption of content written to Aspera server hosts using a secret supplied by the server. Both client and server side options support automatic resume of interrupted transfers and HTTP fallback transfers.
DATA INTEGRITY VERIFICATION
A SHA2 cryptographic hash function is applied to each encrypted datagram before transmission on the network. The resulting message digest is appended to the secure datagram and verified at the receiver for data integrity (to prevent man-in-the-middle, re-play, and UDP denial-of-service attacks).
Aspera server runs one SSH server on a configurable TCP port (22 by default; 33001 is often used). The firewall on the server side must allow this one TCP port to reach the Aspera server. No servers are listening on UDP ports. When a transfer is initiated by an Aspera client, it opens an SSH session to the SSH server on the designated TCP port and negotiates the UDP port (33001 by default) over which the data will travel. To allow the UDP session to start, the firewall on the Aspera server side must allow port UDP 33001 to reach the Aspera server.
Concurrent Transfers Considerations
Concurrent transfers on Aspera servers with multiple concurrent clients will:
- Share the same UDP port on Unix.
- Require a range of UDP ports (e.g. 33001-33100) to be allowed on Windows because the operating system does not allow Aspera’s FASP™ protocol to reuse the same UDP port for multiple connections. Incoming client connections will auto-increment to use the next available port in the range.
In the case of point to point deployments of Aspera products, the end-points accepting incoming connections act as servers, and therefore their firewalls must allow TCP port 22 and UDP port 33001 (both configurable) to access the Aspera machine.
Server side firewall must allow inbound connections to the server on the TCP port and on the UDP port. For Windows servers only, allow a range of ports large enough to cover the number of potential concurrent clients (e.g. 33001 through 33020, for 20 concurrent transfers). This is needed because Windows does not allow UDP port sharing. Server side firewall must also allow outbound connections from the server on the TCP port and on the UDP port (or range of ports for Windows servers).
On the client side, typical consumer and business firewalls allow direct outbound connections from client computers on TCP and UDP. There is no configuration required for Aspera transfers in this case. In cases where corporate firewalls disallow direct outbound connections (typically using proxy servers for web browsing), allow outbound connections from the Aspera client on the TCP port and on the UDP port.
Point to Point Installations
Consider two Aspera computers: A and B. A initiates the transfer (we call A client) and B accepts an incoming connection (we call B server). The client and server designations are given by the computer initiating the Aspera transfers, regardless of the direction of the transfer (upload or download).
On the client side (computer A), typical consumer and business firewalls allow direct outbound connections from client computers on TCP and UDP. There is no configuration required for Aspera transfers in this case. In cases where corporate firewalls disallow direct outbound connections (typically using proxy servers for web browsing):
- Allow outbound connections from the Aspera client on the TCP port and on the UDP port.
- Allow either:
- inbound UDP traffic responding to the outbound UDP (this is default on most firewalls) or
- inbound UDP traffic on port 33001 (on non-standard firewall configurations)
On the server side (computer B), allow inbound connections from A on the TCP port and allow inbound and outbound UDP connections to B on the UDP port.
For A and B to act as both client and servers, both computers’ firewalls must allow outbound and inbound connections to/from the peer on the TCP port, and allow outbound and inbound UDP connections to/from the peer on the UDP port.
“Aspera’s technology not only provides significantly faster transmission speeds, which reduce the margin for error but also includes comprehensive security and data verification schemes to ensure that the possibility of corruption is reduced significantly. Plus, adaptive bandwidth control allows concurrent transfers to run with high efficiency, enabling us to meet strict deadlines.”Jonathan Humphrey, IT Director at Codemasters