Encrypted Internet transmissions

When ordering something at an e-commerce website, at some point the customer will have to transmit address information and his credit card data over the Internet to the Web server. The connection over which these data are transmitted is not secure, which is a big risk.

The reason that the connection is not secure is simply that the TCP/IP protocol was not built with security or confidentiality in mind. The data to be transmitted is divided into small portions or packets, which are then sent separately to the recipient. At the recipient's system, the portions are put back together to reconstruct the data. The packets are transmitted by passing them on from computer to computer. This means that any computer between sender and recipient can read the contents of the packets.

When using an Ethernet network it is even possible to monitor all traffic from and to all other computers on the same network. This kind of "sniffing" makes it very easy to recover passwords. But World-Wide Web traffic can also be intercepted and read.

Encrypted connection

To ensure that sensitive data is not intercepted and read, encryption can be used. A number of protocols have been developed, of which Secure Socket Layer (SSL) and Secure HTTP (S-HTTP) are the most famous ones. These two protocols are mainly used for Web traffic. Other protocols, such as Secure Shell (SSH), are mainly used for interactive Telnet-like sessions.

Protocols like SSL and S-HTTP use cryptography to establish a secured connection. The sender encrypts all packets before they are transmitted, and the recipient decrypts the packets after reception. Anyone eavesdropping on the connection only has access to the encrypted packets. Without the necessary decryption key the original information cannot be recovered.

Key length

A key for an encryption algorithm is a big number, usually expressed as a number of bits (0 or 1). A key size of 40 bits means there are 2 to the power of 40, or 1100 billion, possible keys.

The strength of an algorithm is usually related to the size of the keys. Public key encryption algorithms like RSA need at least 1024 bits, whereas private key encryption algorithms like IDEA are secure when only 128 bits-keys are used. A number of algorithms can operate with keys of different sizes. The private key encryption algorithm RC4 for instance can work with both 40 bits and 128 bits keys.

Public and private key encryption algorithms

An encryption algorithm can use public keys or private keys. A private or secret key system requires that both parties agree on a common key, which they must keep secret to the rest of the world. Encryption and decryption is done with the same key. A public key encryption system on the other hand uses two keys for every party. Every party has a public key, which as the name suggests is publicly available and which is used to encrypt data to be sent to that party. Every party also has a private key which he can use to decrypt data encrypted using his public key. This key must of course be kept secret. It is now possible to transmit the public key to other parties without worrying about interception. Even if an eavesdropper obtains a copy of the public key, he cannot use it to decrypt any data. Only the recipient, who has the necessary private key, can decrypt the data.

The biggest disadvantage of public key encryption systems is that they are much slower and need much bigger keys than private key encryption systems. For this reason public key encryption systems are generally only used to agree on a common key over an insecure channel. The sender makes up a random number of sufficient size for the private key encryption system that will be used. He encrypts this random number with the public key of the recipient and transmits the result. The recipient uses a secret key to recover the random number. The random number is now used to encrypt the packets in that particular communication session. For this reason the random number is generally referred to as the "session key".

Secure Socket Layer

The SSL protocol is very flexible. It can work with a variety of encryption algorithms, and it also allows authentication. This enables a visitor to verify the identity of the owner of a website. Although the protocol is mainly used for Web connections, in principle it can be used for any type of connection.

An SSL session is started when the client transmits a request to the server. This request contains amongst other things the algorithms supported by the client. The server sends back a confirmation indicating the algorithm that will be used. The server also sends its certificate to prove its identity. The certificate amongst other things contains the public key of the server. The client can then use this public key to communicate a session key to the server.

S-HTTP

Another protocol, which was specifically developed for use on the World Wide Web, is Secure HTTP (S-HTTP). S-HTTP also uses public key encryption systems like RSA or Diffie-Hellman to exchange session keys. This is not required; client and server can also use a previously agreed upon secret key.

S-HTTP works largely the same as SSL. The client transmits a request to the server, including either a session key encrypted using the server's public key, or an indication about the secret key to be used. After that the client can retrieve pages by transmitting encrypted requests. The pages are transmitted in encrypted fashion using the session key.

The biggest difference between SSL and S-HTTP is that SSL establishes a single secure connection over which commands and data can be exchanged. With S-HTTP every request and every response is encrypted separately and then transmitted over an insecure connection.

Why two different versions

The Web browsers Netscape and Internet Explorer are available in two different versions, called the "domestic" and the "international" version. The difference between these versions is that the domestic versions can use 128 bits session keys, whereas the international version is restricted to 40 bits.

The reason for the difference is a political one. Both browsers are manufactured by American companies. U.S. export law regulates export of computer software capable of encrypting data. To obtain an export license it is required to weaken the encryption such that any encrypted message can be cracked. The most common way to comply with this requirement is to restrict the length of session keys to 40 bits.

A key length of 40 bits should be practically unbreakable to anyone except very powerful government agencies like the U.S. NSA. International version this would be secure for normal use, but when necessary the NSA would be able to recover the contents of any message.

Things turned out differently in practice. A French student managed to recover a 40 bits key in August 1995 by using 120 UNIX computers for eight days. More recently there have been several contests to crack 40 bits RC4. The winners of these contests managed to recover the key in an even smaller period.

These efforts should prove that 40 bits are not sufficient to secure a message. Unfortunately for non-Americans it is not allowed to download the 128 bits versions from the official download site. There are several sites outside the USA which contain illegally exported versions of these browsers. There is also an add-on for Netscape called Fortify which can enable the international version of Netscape to use 128 bits encryption.

An encrypted Web session in practice

Suppose a user visits a website from which he would like to order an article, or where he is asked to fill in a form to receive a leaflet or promotional offer. To ensure his personal data is secure from eavesdroppers, the contents of the filled in form will have to be transmitted over a secure connection. This is done in six steps.

STEP 1

The user fills in the form and presses the "Transmit" button. The browser sees in the HTML source that the contents of the form has to be transmitted over a secure connection. It reports to the server that it is capable of using SSL to establish such a connection.

STEP 2

The server responds by transmitting its public key and a certificate containing the server's identity to the browser. Using the certificate the browser can verify that the public key is real and belongs to the server in question.

STEP 3

The browser now makes up a random number, the so-called session key. Its encrypts the session key with the public key it received in the previous step and transmits the result to the server.

STEP 4

The server receives the encrypted message and uses its own private key to recover the session key. If decryption is successful, the server transmits a confirmation to the browser.

STEP 5

The browser encrypts all information entered into the form using the session key and transmits the encrypted result to the server.

STEP 6

The server uses the session key to decrypt the transmitted data and recover the information the user entered. The information can then be processed on the server as usual.

Steps 5 and 6 can be repeated as often as necessary to safely exchange information. On a subsequent visit to the site steps 3 and 4 can be repeated to exchange a different session key.