Secure communication and keys

Transmission of data securely over open channels is a field of study unto itself, and well beyond the scope of the discussion presented here. The basic things to know are that encryption algorithms and secure protocols are developed openly and are subject to critical review to verify that they are indeed robust. The DbNet system uses well known encryption techniques and protocols to protect data.

Encryption

To protect data subject to intercept by hostile parties, encryption algorithms have been developed. Data is scrambled prior to transmission, then reconstructed by the receiving party. This scrambling requires that both parties have a key which can be used to unlock the data. Because data scrambling requires computational effort, performance is adversely affected by encryption and must be taken into account when developing encryption algorithms.

Perhaps the best known and best performing encryption algorithm for data communications is called RC4 or ArcFour. This is known as a symmetric algorithm because the key for locking and unlocking data is the same. This key is known as the session key. It has a special property that allows it to encrypt data without increasing the size of the data transmission. It is also extremely computationally efficient, making it a very desirable method for protecting data without compromising performance. The biggest hurdle to using this form of encryption is getting the key into the hands of both the server and the client without allowing a hostile third party to figure it out.

Key Exchange

In order to echange keys, the server and client engage in a transaction according to a set protocol in which the two parties verify each other's identity and then exchange encrypted versions of the session key. The exchange uses what is called Public Key Cryptography in order to allow the parties to exchange information securely.

The idea behind Public Key Cryptography is that a set of data may be encrypted with one key, called the public key, and decrypted with another key, called the private key. The public key may be given to anybody anywhere, and used to encrypt data. The public key cannot, however, be used to decrypt data. Only the private key can decrypt data.

Public Key Cryptography is obviously quite useful. It has some important drawbacks, however, in that it can severely impair the performance of a system using it to encrypt data. It will increase the size of the data being transmitted, and is orders of magnitude less computationally efficient than the RC4 encryption discussed above. For these reasons, the public key is used only to encrypt a small amount of data, namely the session key, which is used for the bulk of the data transmission.

In order to exchange keys, the client must know the server's public key. The client uses the server public key to encrypt it's own public key and transmit that to the server. The server then uses it's private key to decrypt the client public key. The server then encyrpts the session key using the client's public key and transmits that back to the client. The client also transmits a hashed version of a secret code to the server which the server is required to digitally sign using the server private key. The client then decrypts the session key and the digitally signed secret to verify the server, and now the two parties may communicate securely using the session key.

This key exchange and session encyrption protocol is formally defined as the Transport Layer Security protocol and is specified in an internet Request For Comments (RFC) numbered 2246. A well known implementation of this protocol is used in most web browsers and is called Secure Socket Layer (SSL).

Protecting the system

There are important things to consider when using remote access features of the DbNet system. Most importantly, the system installs itself with a common server key. If you allow access to your system over the internet using this key, anybody who has the system may be able to decrypt and intercept your data. If you do not set up passwords to require login, there is nothing stopping anybody from getting into your system at all.

ALWAYS CHANGE YOUR SERVER KEYS BEFORE ALLOWING REMOTE ACCESS

Changing your server keys is easy. Keys are files stored on your server computer in the Program Files\DbNet directory. They are named server_public_key and server_private_key. When you delete these files, and re-start the server, the server will generate fresh keys. You will need to send a copy of the server public key to each of the remote clients so they can access the system.

ALWAYS REQUIRE PASSWORDS WHEN ALLOWING REMOTE ACCESS

Requiring passwords for access over the internet is just good common sense. It may be possible for someone to obtain access to your server public key, in which case they would be able to communicate with your server. If no password is required for them to connect to your database, they will have free reign over your data. The system has a locking feature that will disable user accounts that have been attempted to be opened with incorrect passwords. This will prevent someone who does in fact have your server public key, but no valid password, from repeatedly trying different passwords in an attempt to guess their way into your system.