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.
Digital signatures
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:
www.nss.co.uk/gigabitids
www.nss.co.uk/pki