Virtual USB Tools provides communication and device sharing security by means of the end-to-end encryption using best industry standard algorithms. Built-in trust management provides simple yet powerful control over the trusted servers and gives full protection against “main-in-the-middle” attacks.
End-to-end Encryption feature is not available in the free edition.
When Virtual USB Tools Server starts for a first time on a server computer, it generates a pair of keys: a private key and a corresponding public key. Private key is securely stored in the OS key container (possibly utilizing any hardware key containers such as TPM or external secure tokens). Server's public key is made available through the configuration utility, command-line utility or an API.
The user may renew the server encryption keys at any time using the same tools as described above. This will invalidate any trust stored on client computers and prevent them from establishing secure connections.
The public key must be communicated to the user on a client computer using any trusted secondary channel (such as e-mail, phone or messengers) to serve as a second verification factor. When the client connects to a server for the first time, it obtains its public key and displays it to the user. If the user successfully verifies that the displayed server's public key matches the one received over the secondary channel, the user may decide to add the trusted server to the trusted servers database it maintains.
The client will only establish secure connections using the public keys stored in its trusted servers database.
The client can establish non-secure connection to the server if there is no server's entry in its trusted servers database, but it will never establish any connection to the server if its stored entry does not match the server's actual public key. This provides a robust defense against man-in-the-middle attacks, in which a malicious person “in the middle” installs a fake server and tries to pretend to be a real server.
Defense against malicious clients is provided by means of authentication keys which must always match for shared devices. Authentication keys, if set (a recommended configuration), serve as “passwords” for devices shared on a server.
Internally, server keys are 256-bit prime elliptic curve Diffie-Hellman key exchange algorithm key pair (as defined in SP800-56A standard). A non-exportable private key is stored in the default OS key container.
When human-readable representation of a public key is requested, a SHA-256 hash over public key is calculated, then the first 255 bits are encoded using Base32 encoding and presented as eight groups of six characters with a prefix group of 3 characters.
The public key cannot be re-created from the human-readable form. When the user needs to transfer the full public key, a Base64-encoded version of a full public key may be obtained using the IPublicKey.fullKeyBase64 property.
The first client connection always occurs over non-secure TCP connection. Client requests server's version information as well as its public key. If the reported public key matches the one stored in client's trusted servers database, the client sends its public key and upgrades to secure TCP connection. Once connection is successfully upgraded, both server and client compute the unique session secret which they use to create session key for the AES algorithm (FIPS 197) used subsequently.