Reference: Overview of Beyond FTP
Beyond FTP supports a variety of data encryption capabilities. Standard FTP server and client connections may be encrypted using the SSL/TLS scheme. Beyond FTP server and client connections may be encrypted using our private key system based on the Advanced Encryption Standard. Finally, files may be stored on an FTP server in an encrypted form using this same private key system.
Standard FTP Client
Both Beyond FTP client and server versions are capable of connecting to third-party FTP servers using SSL/TLS encryption or SSH encryption. These connections are configured in the address book. Beyond FTP supports both explicit and implicit SSL connections. Additional connection information is found on the Advanced dialog.
The Beyond FTP private key system may also be engaged for files that are transferred by the ftp client service. These files are encrypted and decrypted on the fly, and are stored on the FTP server in a secure form. This allows public areas to be used to exchange files. When the file is retrieved by a Beyond FTP server or client, it is decrypted and returned to its original state.
Standard FTP Server
The standard FTP server (available on the Beyond FTP server editions ) is capable of encrypting communication from any FTP client that supports SSL/TLS encryption. It can manage both implicit and explicit connections, on the ports of your choice. It also provides for specifying the data ports involved in PASV transfers to facilitate firewall traversal of encrypted information. There is no configuration required for this capability. APT currently provides a self-signed certificate to be used by this process. You may install your own certificates.
Beyond FTP Servers and Clients
Beyond FTP supports three algorithms. DES is available both domestically and internationally. Twofish, developed by Bruce Schneier of Counterpane Systems, and Rijndael, the new Advanced Encryption Standard selected by the National Institute of Standards and Technology, are both available only in North America and select countries outside of North America. All three use private keys that must be stored for each server or client that is sending or receiving encrypted data. The actual key information is not retained, but is passed through a standard transformation process and is further encrypted and stored in the registry. Key information is not exchanged during call setup. Both sides of a connection must already have matching keys. Certain display key information is exchanged when a Key Client updates its local keys from a Key Server (see below). However, this can take place only on an already secure connection.
Key Servers and Clients
A Key Server is a Beyond FTP server or client that provides encryption keys to Key Client installations. All encryption keys are maintained at the Key Server. Key Clients contact the Key Server daily and retrieve any new keys. In this way, central changes are propagated across the network. Each site maintains both primary and secondary keys so that connections are still possible between sites that have been updated and others that are still pending. This allows all encryption keys to be centrally maintained.
A Key Client retrieves keys based on its address book. Only those keys associated with an address book entry are actually updated. When address book entries are added, the associated encryption keys can be automatically retrieved.
The key information that is actually exchanged during an update is limited in several ways. First, only display keys are actually transferred. These are not actual keys, and are useful only to the Beyond FTP implementation of the encryption algorithms. In other words, you could tell someone the algorithm, its strength, and the display key, and they would not be able to decrypt a message. Second, the information is exchanged on an already encrypted connection. The Key Client must have an actual starting key that agrees with the Key Server to begin the process, and must have stored this key manually. This starting key is communicated through an entirely separate channel (telephone, mail, etc.). Finally, the Key Client must use a user account and password that the Key Server knows and that allows key retrieval.
This means that a hacker would have to know the name of the Key Server, a currently active key associated with that Key Server, the name of a valid Key Client, and a valid user name and password that allows key retrieval from the Key Server. Finally, said hacker must be running Beyond FTP, and will still only get key information that can be used by Beyond FTP to decrypt that single channel. It could not be used by another software package to decode messages without a complete reverse engineering of the Beyond FTP encryption engine and key generator. So, even if a hacker is able to somehow steal the information that allows him access to a site, it does him no good at all in terms of monitoring traffic unless he invests heavily in reverse engineering.
Encryption Components
Encrypted connections require keys to be stored using the private key dialog, and encryption to be enabled in the Address Book. Key propagation via servers and clients also involves the service configuration dialog and the security administrator. You must configure each Beyond FTP installation that will act as either a Key Server or Key Client, and you must enable key retrieval for each user account being used by a Key Client.
The tutorial includes topics on setting up the encryption service, Configuring a Key Server, and Configuring a Key Client.