Aspera Security Model

Security Model

Overview

In summary, 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 ("SSH") are used unmodified in order to take full advantage of the standard. Aspera's products have been approved by the 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, and on-the-fly data encryption and integrity verification per data block. The transfer preserves the native file system access control attributes between any of the supported operating systems (Microsoft Windows 2003/2008/XP/Vista/Windows 7, Mac OS X version 10.5 and higher, Linux, and Isilon and Solaris). The specific cryptographic algorithms used by SSH for session encryption, authentication, and key exchange, and by the Aspera scp binary for data encryption, are described below.

Session Encryption

Each transfer job begins with establishment of a secure, encrypted session between the transfer endpoints, using the standard secure shell ("SSH"). SSH is invoked with its default symmetric cipher option for session encryption, 3DES (128 bits). SSH supports other ciphers for session encryption (e.g. 128 bit AES, Blowfish, CAST128, Arcfour, 192 bit AES, or 256 bit AES) and command line invocations of Aspera scp may request these alternative ciphers if supported by the peer ssh server. The particular algorithm used to negotiate the session encryption key depends upon whether SSHv-2 or SSHv-1 is used. SSH-v2 is the default for the sshd service built into Linux, Solaris and Mac OS X, and included with the Aspera distribution for MS Windows. However Aspera scp can be run with SSH-v1 as a command line option (and also works with other commercial implementations of ssh). SSH-v2 uses a Diffie-Hellman key agreement to negotiate the session encryption key. In SSH-v1, 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.

Authentication

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 only (SSH-v1) or RSA/DSA (SSH-v2) public key exchange. The ssh-keygen program is distributed with the Windows version of Aspera Scp for generating DSA and RSA keys. The default key length is 1024 bits although the user may request longer key lengths.

faspData Encryption and Integrity Verification

Once SSH authentication has completed, the fasp™ transfer session performs a three-way handshake during which the remote endpoint generates a random AES 128-bit per-session key for data encryption, and a random 128-bit key for computing an MD5 checksum, and sends these keys to the initiator over the secure ssh channel. A new encryption and MAC key is generated on each fasp™ transfer session, and the keys are never stored on disk.

fasp™ 2.0 uses 128-bit AES encryption in which the key is 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. fasp™ 1.3 uses 128-bit AES encryption in ECB (Electronic Code Book) mode.

The fasp™ source code includes support for ciphers in addition to 128-bit AES, and can be extended with other openssl ciphers such as AES 192. fasp™ does not at this time expose a command-line or graphical interface option for the end-user to select a cipher other than AES 128 but could if needed, as the cipher code is modular.

An MD5 cryptographic hash function (128 bits) is also 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 attacks, for example).

Firewall Considerations

Architecturally, an Aspera server runs one SSH server, running on a configurable TCP port (22 by default, but often customers use port 33001). 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, the client opens an SSH session to the SSH server on the designated TCP port and negotiates the UDP port over which the data will travel. By default, Aspera clients and servers are configured to use UDP port 33001. After the session initiation step, both the client and the server will send and receive UDP traffic on the negotiated port. 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 On Unix Aspera servers with multiple concurrent clients, concurrent transfers will share the same UDP port. On Windows Aspera servers with multiple concurrent clients, the operating system does not allow Aspera's fasp™ protocol to reuse the same UDP port for multiple connections. Therefore, the firewall on the server side must allow a range of UDP ports, for example 33001 through 33100, to reach the Aspera server. Incoming client connections will automatically 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 must configure their firewalls to allow TCP port 22 and UDP port 33001 to access the Aspera machine (both TCP and UDP ports being configurable). Firewall Configuration Summary

Aspera transfers use one TCP port for session initialization and control, and one UDP port for data transfer. The TCP port is usually either 22 (default port for SSH) or 33001, and the UDP port is by default 33001.

Client / Server installations
Server side firewall:

  • Allow inbound connections to the server on the TCP port
  • Allow inbound connections to the server on the UDP port
    For Windows servers only, allow a range of ports large enough to cover the number of potential concurrent clients, for example 33001 through 33020, for 20 concurrent. This is needed because Windows doesn't allow UDP port sharing.
  • Allow outbound connections from the server on the TCP port
  • Allow outbound connections from the server on the UDP port (or range of ports for Windows servers).

Client side firewall: 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. Special: In the case of corporate firewalls disallowing direct outbound connections, typically using proxy servers for web browsing:

  • Allow outbound connections from the Aspera client on the TCP port.
  • Allow outbound connections from the Aspera client 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). A's firewall: 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. Special: In the case of corporate firewalls disallowing direct outbound connections, typically using proxy servers for web browsing:

  • Allow outbound connections to B on the TCP port.
  • Allow outbound connections to B 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)

B's firewall:

  • Allow inbound connections from A on the TCP port.
  • Allow inbound and outbound UDP connections to B on the UDP port.

For A and B to act as both client and servers, you would need: A and B's firewalls:

  • Allow outbound connections to the peer on the TCP port
  • Allow inbound connections from the peer on the TCP port
  • Allow inbound and outbound UDP connections to the peer on the UDP port.
Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk