learn more...

Symmetric Cryptography

Until recently, symmetric encryption techniques were used to secure information transmitted on public networks. Traditional, symmetric cryptographic systems are based on the idea of a shared secret. In such a system, two parties that want to communicate securely first agree in advance on a single “secret key” that allows each party to both encrypt and decrypt messages.

Symmetric cryptography has several drawbacks. Exchanging secret keys is unwieldy in large networks. Furthermore, the sharing of secret keys requires both senders and recipients to trust, and, therefore, to be familiar with, every person they communicate with securely. Also, symmetric systems require a secure channel to distribute the “secret” keys in the first place. If there is indeed such a secure channel, why not use it to send the entire secret message?

In today’s Web-based systems involving many participants and transitory interactions with strong cryptography requirements, such symmetric key-based systems are highly impractical as a means for agreeing upon the necessary secrets to begin communicating securely. This problem, the key agreement, or key distribution problem, is part of a larger problem that is central to the modern understanding of cryptographic systems—the key management problem. Together, they represent the fundamental challenge in designing effective cryptography systems for modern computing systems. Symmetric key encryption plays an important role in the SSL protocol, along with asymmetric public key encryption.

Public Key Cryptography

Today’s public key, or asymmetric cryptography systems are a considerable improvement over traditional symmetric cryptography systems in that they allow two parties to exchange data privately in the presence of possible eavesdroppers, without previously agreeing on a “shared secret.” Such a system is a called “asymmetric” because it is based on the idea of a matched cryptographic key pair in which a cryptographic key is no longer a simple “shared secret,” but rather is split into two subkeys, the private key and public key.

Abstractly, a participant wanting to receive encrypted communications using an asymmetric cryptography system first generates such a key pair, keeping the private-key portion as a secret and “publishing” the public-key portion to all parties that want to encrypt data for that participant. Because encrypting data requires only access to the public key, and decrypting data requires the private key, such a system in principle can sidestep the first layer of complexity in the key management problem because no shared secret need be exchanged.

Modern Cryptography Systems: A Hybrid Approach

In fact, a combination of both public key and traditional symmetric cryptography is used in modern cryptographic systems. The reason for this is that public key encryption schemes are computationally intensive versus their symmetric key counterparts. Because symmetric key cryptography is much faster for encrypting bulk data, modern cryptography systems typically use public key cryptography to solve the key distribution problem first, then symmetric key cryptography is used to encrypt the bulk data.

Such a scheme is used by today’s SSL protocol for securing Web transactions and by secure e-mail schemes such as Secure/Multipurpose Internet Mail Extensions (S/MIME) that are built into such products as Netscape Communicator and Microsoft Internet Explorer.

The Key Management Problem

Underlying every cryptographic system is a set of practical problems and questions involving privacy, security, and overall confidence in the underlying confidentiality features of the system. In principle, the techniques of asymmetric and symmetric cryptography are sufficient to resolve the security questions and properties previously described. For example, today’s Web browsers use the public key of a Web site in order to send credit card numbers over the Web. Similarly, one can protect access to files and data using a private symmetric key to scramble the information before saving it.

However, in practice, each of these problems requires a “certified” public key in order to operate correctly without third parties being able to interfere. This leads to a second set of questions. For example, how can you be sure that the public key that your browser uses to send credit card information is in fact the right one for that Web site, and not a bogus one? And, how can you reliably communicate your public keys to your correspondents so that they can rely on it to send you encrypted communications?

What is needed in order to address such concerns is the notion of a “secure binding” between a given entity that participates in a transaction and the public key that is used to bootstrap secure communication with that entity using asymmetric public key cryptography. The next part of the article describes how a combination of digital signatures and X.509 digital certificates (which employ digital signatures), including SSL certificates, fulfills this role in e-commerce trust systems.

Digital Signatures

Digital signatures are based on a combination of the traditional idea of data hashing with public key-based encryption. Most hash functions are similar to encryption functions. In fact, some hash functions are just slightly modified encryption functions. Most operate by grabbing a block of data at a time and repeatedly using a simple scrambling algorithm to modify the bits. If this scrambling is done repeatedly, then there is no known practical way to predict the outcome. It is not, in general, practical for someone to modify the original data in any way while ensuring that the same output will emerge from the hash function. These hash-based signature algorithms use a cryptographically secure hash function, such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA), to produce a hash value from a given piece of data.

Because the digital signature process is central to the idea of a digital certificate (and in turn, the digital certificate is the primary tool to ensure e-commerce security), it’s useful to look at a diagram of the process.

The first step is to take the original message and compute a “digest” of the outgoing message using a hashing algorithm. The result is a “message digest,” which is typically depicted as a long string of hexadecimal digits (and manipulated by software as binary data). In the next step, the sender uses his private key to encrypt the message digest.

The original message content, together with the encrypted digest, forms a digitally signed message. This digitally signed message is suitable for delivery to the recipient. On receipt, the receiver verifies the digital signature using an inverse set of steps: first, the encrypted digest is decrypted using the sender’s public key. Next, this result is compared to an independent computation of the message digest value using the hashing algorithm. If the two values are the same, the message has been successfully verified.

Why is a digital signature compelling evidence that only the intended signer could have created the message? For example, what if interlopers were to change the original message? It was not encrypted, after all, and could have been changed by a third party in transit. The answer is that if such a change had been made, then the decrypted, original message digest wouldn’t have matched the recomputed one for the changed data in the message. Verification of the digital signature would fail. Similarly, the creation of a bogus signature is impractical because an interloper doesn’t have the appropriate private key.

Digital Certificates

A digital certificate is an electronic file that uniquely identifies individuals and Web sites on the Internet and enables secure, confidential communications. It associates the name of an entity that participates in a secured transaction (for example, an e-mail address or a Web site address) with the public key that is used to sign communication with that entity in a cryptographic system.

Typically, the “signer” of a digital certificate is a “trusted third party” or “certificate authority” (CA; such as VeriSign). In addition, all participants who use such certificates agree it is a point of secure storage and management of the associated private signing key. The CA issues, creates, and signs certificates, as well as possibly playing a role in their distribution.

Using digital certificates simplifies the problem of trusting that a particular public key is in fact associated with a participating party, effectively reducing it to the problem of “trusting” the associated CA service. Digital certificates, therefore, can serve as a kind of digital passport or credential. This approach represents an advance in the key management problem, because it reduces the problem of bootstrapping trust to the problem of setting up (or in today’s marketplace, selecting as a vendor) the appropriate CA functionality. All parties that trust the CA can be confident that the public keys that appear in certificates are valid.

Disclaimer

link to this article