Bob Walder, director of network security specialist the NSS Group, explains how public and private key encryption works to secure online transactions.
In the best tradition of a James Bond novel, encryption is all about secret codes. These codes can transform plain text into a form unreadable by anyone without a secret decryption key, thus allowing secure communication over an insecure channel, such as the internet.
Although the mathematics behind codes can be complex, encryption itself is fairly straight-forward. Cast your mind back to when you were a child and you wanted to send a secret message to a friend.
The simplest form of encryption was the one where every letter of the alphabet was subs-tituted for the one "n" positions after it. Here we are introduced fairly painlessly to the two most important buzzwords in cryptography: the "key" is the number of positions we are shifting the letters, and the "algorithm" is simply the idea that the encrypted letter is the one "n" places after the plain text letter.
There are two ways you can beef up security on this code: increase the length of the key, or devise ever more complex algorithms. Fortunately, we do not have to create our own algorithms as there are some perfectly acceptable standards already available.
The main algorithms are Data Encryption Standard (DES), Triple DES, International Data Encryption Algorithm (Idea) and RC4, an algorithm developed by Ron Rivest of RSA Security as a stream cipher with a variable key length.
Whereas the original DES algorithm used 56-bit keys, later and more powerful systems used much longer keys, forcing potential hackers to run through trillions of combinations in an attempt to find the right one. Triple DES is an enhanced version of the original DES algorithm and encrypts data three times using two different keys, thus providing an effective key length of 112 bits.
There is also an implementation of Triple DES, known as 3DES3Key, which encrypts data three times with three keys. This provides an effective key length of 168 bits, although this is much less widely deployed.
Another method of encryption, Idea, is a 128-bit mechanism developed by the University of Zurich in 1992. This is widely used by European financial institutions.
Secret key cryptography
The longer the key length, the more secure the encryption. Going back to our simple cipher, if a single digit key is represented by a letter of the alphabet, a potential hacker has to try only 26 possible combinations to crack the cipher.
If we increased the length of the key and wrote it beneath our original message, repeating the key over and over until it was equal to the length of the message, each character in the key would represent a different shift for the letter above.
If short keys are used, repeating patterns may begin to emerge. The most secure method is to use a key that is the same length as the message itself, but this is often impractical in real-life situations. However, if you combine long keys with sophisticated algorithms - something a little more complex than "shift each letter of the message by the value of the key character beneath" - you are in business.
Unfortunately, secret key, or symmetric key cryptography as it is known, relies on both parties having access to the same secret key. The sender uses the key to encrypt the message and the receiver uses the same key together with the same algorithm in reverse to decrypt the message. This introduces a problem. How do we ensure the key is distributed in a secure manner?
If we have regular contact with the receiver, we can securely pass on the key face to face. In business terms, secret keys, such as bank Pin codes, are often distributed by mail in tamper-proof envelopes, or they can be encapsulated in hardware devices such as smartcards, where the issuing authority never gives the customer access to the key information.
In the case of one-off internet transactions, we do not have that luxury. As a result of the unique key-pair arrangement between two parties, it is impossible to exchange data with someone to whom you have not already been "introduced".
Neither of the parties has a shared secret key and there is no secure channel over which to exchange one. For this reason, secret key cryptography works best when a single issuing authority is maintaining a service for a user base where some kind of registration process takes place prior to the exchange of information.
Public key cryptography
With public key or asymmetric key cryptography, each person gets a pair of keys, known as the public key and the private key. The public key is generated from the private key using a complex algorithm. This means the public key can be published and the private key remains secret.
The mathematics behind public key cryptography are exceedingly complex. Any message encrypted with a given public key can only be decrypted using the corresponding private key, and there is no known way to derive the private key from the public key.
For example, if Bob wants to send a message to Alice, he will encrypt it using Alice's public key. This can then be published in a directory or distributed via unsecured e-mail. The only person who can decrypt the message is the holder of the appropriate private key, which is Alice.
The need for the sender and receiver to share secret information is eliminated, as all communication involves only public keys and no private key is ever transmitted or shared. The best known and most widely used asymmetric key technologies are Diffie-Hellman for key exchange and RSA for encryption and signing.
Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. Therefore, for performance reasons, RSA is used to exchange keys and a conventional secret-key cryptosystem, such as DES, is used for the bulk of the message.
Suppose Alice wishes to send an encrypted message to Bob. She first encrypts the message with DES using a randomly chosen DES secret key, which can be different for every message she sends. She then uses Bob's public key to encrypt the DES key. The DES-encrypted message and the RSA-encrypted DES key together form a "digital envelope", which is sent to Bob. On receiving the digital envelope, Bob decrypts the DES key with his private key, finally using the DES key to decrypt the message itself.
Once we have our data encrypted to prevent snoopers discovering its content, we still have to prove who we are to the other party involved in the transaction.
In business, the most important piece of evidence available to the merchant is the customer's signature. Although it is possible to forge someone else's signature, we have to accept it is beyond the means of most casual thieves, provided the merchant takes sufficient care when checking it.
We therefore require an electronic equivalent, something the merchant can hold up in court as proof that a customer placed an order. Digital signatures also provide another useful feature: complete non-repudiation. Not only can we prove that the transaction originated from a particular source, we can also prove it was not tampered with during transit.
To ensure electronic signatures cannot be forged, digital signatures make use of public key techniques and algorithms such as DSA and RSA, the latter being the most common.
Suppose Alice now wishes to send a signed message to Bob using RSA. She uses a hash function to create a uniquely concise version of the original text - known as a message digest - which serves as a much smaller digital fingerprint of the message.
As with general encryption, there are several hash functions available, such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA-1). After a couple of potential weaknesses were discovered with MD-5, SHA-1 has become the preferred method. It is infeasible that different documents will have the same message digest, and even small changes in a document will cause significant changes in the digest.
Next, Alice encrypts the message digest with her RSA private key, or a secret key, if she prefers. This becomes the digital signature, which she sends to Bob along with the message itself, which may or may not be encrypted.
Bob, on receiving the message and signature, decrypts the signature with Alice's public key to recover the message digest. He then hashes the message with the same hash function Alice used and compares the result to the message digest decrypted from the signature.
If they are exactly equal, the signature has been successfully verified and he can be confident the message did indeed come from Alice. However, if they are not equal, the message either originated elsewhere, or was altered after it was signed, and he rejects the message.
For authentication, the roles of the public and private keys are converse to their roles in encryption, where the public key is used to encrypt and the private key to decrypt.
Signing guarantees integrity and authenticity, but it does not guarantee privacy. Encryption of the actual message content must be performed separately if required. DSS, which was developed for use by companies doing business with the US government, is a signature-only system, whereas RSA can be used for signing and encrypting.
Digital signatures provide the highest levels of data integrity, as any tampering after signing invalidates the signature. They also provide unforgeable origin authentication as they are based on the sender's private signing key and are authenticated by the public verifying key.
In most public key infrastructures, two key pairs are generated for each user. One pair is for encryption and decryption and the other is for signing and verification. This allows the administrator to keep back-up copies of users' encryption keys should those keys become lost or the employee leaves the company and the data within the keys needs to be recovered.
The signing keys, however, never leave the possession of the user and are not backed up as they are intended to be as personal and inaccessible to others as the user's physical signature.
This is the only way we can ensure non-repudiation, as unless the keys are compromised, for example, the token on which they are stored is lost or stolen, the user can never claim someone else signed on their behalf.
Bob Walder and the NSS Group
Network security expert Bob Walder is one of the founders of the NSS Group. He is also author of the PKI report, Public Key Infrastructure Group Test (Edition 6), which is available from the NSS website.
The NSS Group is an independent security testing facility. Based in the UK with separate security and network infrastructure testing facilities in the South of France, the NSS Group offers a range of specialist IT, networking and security-related services to suppliers and end-user organisations throughout Europe and the US.
Output from the labs, including detailed research reports, articles and white papers on the latest network and security technologies, are made available on the NSS website.
To view detailed Gigabit IDS product reviews and a full set of performance results, see:
This was first published in November 2003