WANFast Security

Strong Identification and Authentication

WANFast uses a system of RSA key pairs for identifying and authenticating users and servers.  This system is modelled after the open source application Secure Shell, ssh, so it should be familiar to many users.  In fact, you can use most existing ssh keys with WANFast.

How it Works

The RSA public-key cryptosystem is often referred to as an asymmetric algorithm.  It works with a matched pair of keys -- a private key known only to you, and a public key that can be freely distributed to the public.  Data that has been encrypted with the private key can only be decrypted with the public key, and vice versa.   Because it is not possible to derive the private key from the public, we can use the keys for identification and authentication.  As only you have access to your private key, anyone with access to your public key can verify your identity by successfully decrypting data that you have encrypted with the private key.  This is the basis of the the WANFast Key Exchange and Authentication Protocol (WKEAP) used to mutually identify WANFast users and servers.  See the Wikipedia article on the RSA cryptosystem for more detailed information and a list of references.

Accessing a WANFast Server

WANFast key pairs are created using the WANFast client application.  The private key is stored in the file wfst.key in the WANFast directory associated with your login account.  The public key is stored in the wfst.pub file.  A hash (shortened, unique identifier) of the public key is stored in the wfst.hash file. The location of your WANFast directory is dependent upon your operating system.  See Getting Started for more details on files and locations.

The client identifies itself to the server by sending its unique ID as part of the WANFast WKEAP, and then using its private key to encrypt its portion of the key exchange.  The server uses the ID to locate the client's public key in the authorized_keys file in the WANFast directory of the account that client is trying to access.  If the client's public key is in the file, and if it successfully decrypts the client portion of the key exchange, the server can be confident that the client's identity is ID.  The server completes the authentication exchange by passing its public key to the client, along with its portion of the key exchange, encrypted with the server's private key.   The client verifies the server's public key by computing a hash of the key and comparing the hash to any saved value in the client's known_hosts file.  If the hash matches, and if the public key successfully decrypts the server's portion of the key exchange, then the client can be confident that it has connected to the correct server belonging to the server address.

Managing Multiple Key Pairs

By default the WANFast client will use your private key stored in the wfst.key file.  You can specify an alternate key file using the --identity-file option using either your configuration file or  command line option to the WANFast client application.  When using multiple key files, each should have a unique ID, as the server will use the ID to locate your public key on its end.  On the server end, each key that you use to access the server must be included within the authorized_keys file in the appropriate accounts.  You can have more than one public key in a single authorized_keys file if they use different IDs.

Authorization and Key Distribution

By default, when a WANFast client connects to a WANFast server, the server will run the requested operation using the same account under which the client program is being run on the client machine -- for example, if you have logged into the client machine as marys, then the server will attempt to run the operation as marys, if that account exists on the target machine.  The client can specify an alternate account to use on the target with either of the command line options below:  

wftp joez@targetMachine
wftp -l joez targetMachine

both of which will attempt to copy files to or from targetMachine using the account joez on the target. 

The server runs the operation on the target machine as if it were being run by a user that has logged into the specified account.  The operation will be able to access any resources that are available to the target account.  The operation will receive an access error if it attempts to access a resource that is not available to the target account.  

To determine whether the user on the client machine is authorized to access the target account, the server looks for the client's public key in the authorized_keys file in the target account's WANFast directory.  In the example above, if marys is attempting to copy files using her own account, then her public key must be present in the file (on Windows) C:/Users/marys/AppData/Local/WANFast/authorized_keys, and the file permissions on the authorized_keys file must be set so that only marys and the system Administrators can write to the file.  If marys is attempting to copy files using the joez account, then her public key must be present in  joez's authorized_keys file.   The command wfstPerms is provided to help set secure file permissions on you WANFast files.

As the security of your server is enforced by the public keys residing in the authorized_keys files, never add a key to an account's authorized_keys file unless you are certain that the key belongs to someone authorized to access the account.   And when adding a key to an authorized_keys file, be careful with cut/paste.  Each entry in the authorized_keys file must be a single line.  Because the public key is very long, cut/paste will often add newlines, making the key invalid.  It is better to distribute the public key as a file and then append a key using the command:

type KeyFile.pub >> C:\Users\USERNAME\AppData\Local\WANFast\authorized_keys   (Windows)
cat KeyFile.pub >> /home/USERNAME/.wfst/authorized_keys                       (Linux)

Verifying Server Identity

To ensure that a WANFast client has connected to the correct WANFast server, the server's public key is presented to the client.  This is hashed, and compared to the saved value in the client's known_hosts file.  The end user is warned if the server's key is not present in the file, or if the server's key has changed.  The user must then explicitly approve the server's public key.  To facilitate this process, the server's wfst.hash file can be made available to prospective clients.  The contents of this file look similar to:

ssh-rsa K/eObHG2/RjfXEJAz3V2rA2UT+COvqTGoPLK8nerOzw==

When encountering a new public key, the WANFast client software will ask whether to approve the new key similar to below:

Host (52.43.139.230) key (v958fgH5/f+E5NvSnu6MdfroBehsf+rdHZlOsSGxkfA==) not found.  Add to known_hosts? (y/N)

The user should compare the two hash values and only approve if they are the same.  Alternatively, the server hash can be added directly to the known_hosts file by preceding it on a single line with the server's address:

10.1.1.230 ssh-rsa FIivVA+NrhMrtmEG1VfoFHXr1c6iGpte3adxikeKFyA==

Note that in many environments -- such as within a corporate LAN environment -- verifying the server identity is unnecessary.  The client commands can skip the verification of unknown keys by adding the -y command line option.  When this option is given, the software will automatically add any unrecognized keys to the known_keys file. 

Ensuring the Security of Your WANFast Files

To ensure that your WANFast files are properly secured, run the command:

wfstPerms                            Secure my WANFast directory
wfstPerms PathToWANFastDirectory     Secure the specified directory
wfstPerms -s                         Secure the system directory (must be run as Admin)

This will secure all the files in your WANFast directory.  

(back to top)

Very Secure Key Exchange

The WANFast Key Exchange and Authentication Protocol uses RSA key pairs and 256-bit AES encryption (the NIST standard algorithm that replaced DES) to enhance the security of a Diffie-Hellman key exchange and provide the following features:

  • forward secrecy.  Each WANFast session uses a new Diffie-Hellman key exchange so that breaking the protection on one connection does not open subsequent connections.
  • mutual authentication.  Both the end-user and the server are authenticated using RSA key pairs.
  • enhanced security.  It has been hypothesized that a sufficiently well-funded organization can assemble enough computer power to break a 1024-bit Diffie-Hellman exchange (see Diffie-Hellman).  The WANFast KEAP prevents this by a) using a 2048-bit exchange that can optionally be set higher; b) and by AES encrypting the exchange using ephemeral keys exchanged via RSA encryption.  Thus breaking a WANFast session would require first breaking two 2048-bit RSA keys before breaking a 2048-bit Diffie-Hellman exchange.

 

See the detailed protocol description.

 

(back to top)

Data Encryption and Integrity

Using the shared session created during log in by the WANFast Key Exchange and Authentication Protocol, WANFast generates a new 256-bit key for each virtual connection.

Your data is then encrypted and integrity sealed using your choice of strong encryption and keyed hash algorithms.

Supported Data Encryption Algorithms

All encryption algorithms used by WANFast provide a minimum of 128-bit key size and are either NIST standards or endorsed by the European Union's eSTREAM network.

Supported Data Integrity Algorithms

WANFast data transfer supports an optional keyed integrity hash on each data segment that it sends.  The supported algorithms are listed below: 

  • None.  Provides the fastest transfer on a trusted network.  It relies on the underlying 32-bit TCP/UDP checksum to provide data integrity.  This protects against accidental data corruption, but cannot prevent a sufficiently sophisticated attacker from introducing random data errors.  However, this is greatly mitigated when the data stream is both compressed and encrypted, as a random modification to the encrypted data stream will typically cause the compression framing to fail.
  • MD5 128-bit keyed hash.  Slow.  Reduces the odds of an attacker causing an undetected random one byte error to approximately one in 3.4 x 10^38.
  • SpookyV2 Recommended.  A very fast 128-bit hash.  Much faster than MD5 and more secure (in this application) than MD5.
  • SHA256 256-bit keyed hash.  Very slow, but the most secure.  Odds drop to approximately one in 1.1 x 10^77.

Specifying an Encryption and/or Integrity Algorithms

Use the --query e option with any WANFast command to see the full list of supported encryption algorithms and configurations.   The configuration name is in the format ealg-keysize-halg, where ealg is the encryption algorithm, keysize is the key length, and halg is the optional integrity hash algorithm.  For example:

  • null-adler32 is no encryption with a keyed adler32 integrity hash
  • hc-128-md5 is the hc-128 encryption algorithm with a 128-bit key and an md5 integrity hash.
  • aes-ctr-192-sha256 is the AES encryption algorithm in CTR mode using a 192-bit key and the SHA256 integrity hash.

You can specify the encryption algorithm using the --encrypt-alg=ALG command line option.  By default this is set to hc-128, which is the fastest of the supported 128-bit algorithms when used on long data streams.

(back to top)

 Auditing

All use of WANFast applications for file copy, tunnels, remote login and remote commands is audited on both the client and server ends.  On Windows audit records are written to the Event Log and the WANFast log file.  On Linux audit records are written to syslog and the WANFast log file.  The audited events include:

  • Login
  • Failed login
  • Logout
  • Tunnel creation
  • Creation of a new virtual connection using a tunnel
  • Command execution (including wcp, wping)
  • License expiration
  • License update
  • License restriction -- i.e., user attempts something for which they are not licensed

Audit records are not written for each file that is copied using wcp.  If you wish to record this information on the server, add the following line to your server configuration file and a record of each copied or modified file will be written to the server log file.

command-opt = wcp: -V

(back to top)

Controlling Services on the Server

You can selectively disable WANFast services on your server by adding the following lines to your server's configuration file:

  • copy = false                    Prevent file copies/syncs in/out of the server
  • ping = false                     Prevent pings of the server
  • tunnels = false                Prevent tunnels in/out of the server
  • logins = false                  Prevent remote logins into the server
  • commands = false          Prevent a remote client from running commands on the server
  • replication = false           Prevent a machine from replicating its data to another machine.

 (back to top)