Digital envelopes and digital signatures are two specific applications of computer security technology that can enhance the functionality of electronic mail. A digital envelope (encryption) is the electronic equivalent of putting your message into a sealed envelope to provide privacy and resistance to tampering. A digital signature is the electronic equivalent of a signet ring and sealing wax: You seal the message so that the receiver has a high degree of confidence that the message really came from the purported sender and that no one has altered it. (For more information on the role of encryption in computer security, see Lawrence E. Hughes, "Secure Enterprise Email," Windows NT Magazine, May 1996.)
These two security functions are mutually independent, and you can apply neither, either, or both to a message. Only the sender's private key (a binary value 40-bits or more long) is required to create a signature. A secure mail client will apply digital signatures by default, without affecting a person's ability to read the message through a mail reader without a secure mail client. In contrast, digital envelopes make the entire message gibberish to a recipient without an appropriate reader and the correct decryption key. Therefore, a digital envelope is never a default. However, a well-designed mail client can remember (or determine from a directory service) what recipients to use digital envelopes with, what type of digital envelope to use (many standards are available), and the particular key to use for each recipient.
Digital Envelopes (Encryption)
Encryption, or secret writing,
has been around in one form or another since ancient times. Recently, encryption
has become more complex with the availability of computers to escalate the game
of lock builder vs. lock picker.
Encryption provides privacy. You scramble information so that only the intended recipient can unscramble it. Encryption does not prevent third parties from intercepting the message, but they intercept pure gibberish; the intercepted message is useless without the decryption software and appropriate key. Most contemporary encryption schemes use a fixed, standard algorithm (e.g., the Data Encryption Standard--DES), which produces a unique ciphertext (scrambled form) for each possible key (pattern of bits that modify the way the algorithm does the scrambling). The more bits in the key, the more keys are possible. For example, DES has 56 bits in each key, hence a total of 256 or roughly 72 quadrillion distinct keys.
Two primary kinds of encryption are symmetric key and asymmetric key. Symmetric key encryption uses the same key to encrypt and to decrypt. Asymmetric key encryption creates the key in two complementary pieces, like the two pieces of a raggedly torn dollar bill. One piece is the public key, because no security is lost by publishing it for anyone to know, and the other is the private key, because you must guard it from discovery. If you encrypt with a given public key, someone can decrypt only with the corresponding private key; no other key, including the public key used to encrypt the information, can successfully decrypt it. That simple difference in key use is the most significant breakthrough in security technology in 2000 years.
Unfortunately, asymmetric key algorithms are hundreds or thousands of times slower than symmetric key algorithms and are suitable only for processing small pieces of information (e.g., a 56-bit symmetric key). So, most digital envelope schemes use an asymmetric key algorithm (e.g., Rivest-Shamir-Adleman--RSA--or Diffie-Hellman) to securely exchange a session key (a randomly generated symmetric key just for this one message or session; then you discard it) and then use a symmetric key algorithm (e.g., DES or International Data Encryption Algorithm--IDEA) to encrypt the text by means of the session key.
The person sending a message in a digital envelope must randomly select a symmetric algorithm session key and then encrypt that session key by using the recipient's public key and an asymmetric algorithm. The sender encrypts the message body (the plaintext) with the original (unencrypted) symmetric session key, and then sends the encrypted session key and encrypted message body (the ciphertext) to the recipient.
The recipients of that message must decrypt the session key (using their own private key) and then decrypt the rest of the message using the recovered session key to obtain the original message body (the plaintext). Only the holder of the recipient's private key (hopefully, only the recipient) can recover the session key and the original message.
Digital Signatures
Digital signatures are a more recent concept
than encryption and address issues of authentication (proof of identity
of the sender) and message integrity (detection of changes to the
message). You can also use digital signatures for non-repudiation:
proving that a particular individual really sent a particular message.
Most digital signature schemes depend heavily on asymmetric key technology but need a trick to keep the amount of data processed with it to a minimum. In this case, you create a message digest with one of the many standards, such as the Secure Hash Algorithm (SHA) or Message Digest Algorithm 5 (MD5). You feed the entire contents of the message through an algorithm that is a function of the entire content, including the order of all the characters. This algorithm creates a residue (typically, 64 bits' worth, regardless of the size of the original message--even more condensed than a Reader's Digest condensation of a book!). If someone alters the message and you run the result through the algorithm again, the result is a different residue. The probability of getting the same residue from two different messages is one in 264 power, which is millions of times less likely than your chances of winning a lottery. This residue, or more accurately the cryptographic checksum, is what asymmetric key technology encrypts and then appends to the message to create the digital signature.
For a recipient to verify a digital signature, the receiving mail client program must use the sender's public key to extract and decrypt the transmitted message digest. The receiver must obtain the public key, recalculate the message digest by passing the rest of the message through the message digest algorithm, and compare the transmitted residue with the newly calculated one. If the residues match, no tampering with the message has occurred, and only the holder of the sender's private key can have created the digital signature (note that anyone can verify a signature, as only the sender's public key is required).
If the residues don't match, either someone altered the message in some way (possibly the mail transport system innocently altered it by wrapping long lines), or someone other than the purported sender created the digital signature with some key other than the sender's private key, or both. Many digital signature schemes let you encode the message content to prevent the mail transport system's innocent mauling from affecting the message digest, but these schemes have the unfortunate side effect of making the message text unreadable without an appropriately equipped mail client program (you use digital signatures with this feature only when sending mail to recipients that have the appropriate capability).
Sometimes privacy and message integrity are essential, but who sent the message is not important or is obvious from content. In this case, a digital envelope is necessary and sufficient. The interceptor first has to decrypt the message to change it and then re-encrypt it using the same key originally used to encrypt the message, so encryption prevents tampering. However, encryption alone does not provide any authentication.
At other times, who sees the information is not important, but the critical concern is that it really came from the person who claims to have sent it, and that no one has tampered with it in any way. In this case, you can send the message in plaintext (no digital envelope) with a digital signature. Also, you cannot legally use encryption in certain situations, such as crossing most international borders even if digital signatures are perfectly legal inside those borders. When sending mail internationally or even within the borders of many foreign countries, find out what security technology is allowed and what algorithms and key lengths are permitted. Penalties can be severe if authorities catch you--assume that the National Security Agency monitors most digital traffic that enters or leaves the US.
Digital envelopes and digital signatures do not interact, and people often first digitally sign and then encrypt a message before sending it, taking advantage of both privacy and authentication. Also, the digital envelope protects the digital signature. Finally, keeping the original digital signature as part of an archived message is useful. For example, you can detect alterations while it is in storage or verify the identity of the sender again at any time.
Infrastructure Issues
To add a digital envelope to a message,
the sender (or a mail program) must obtain the public key of the recipient.
Likewise, to verify a digital signature, the recipient (or a mail program) must
obtain the public key of the sender. A simple way is to include the
sender's public key in each message. You lose no security this way, but you get
a lot of extra overhead and clutter that are often longer than the original
message. Adding to this overhead is the need for digitally signed certificates
that guarantee that the public key belongs to the purported owner.
Today, a worldwide, distributed infrastructure (e.g., X.500 and Lightweight Directory Access Protocol--LDAP) is under construction to solve the problem of finding anyone's email address. This infrastructure will let you store and provide access to everyone's public keys and entire chains of certificates (all the way back to some unimpeachable source) on key servers, through the Web. This infrastructure provides Certificate Revocation Lists (CRLs). Schemes that embed the key in the message do not address CRLs. You can think of CRLs as the secure email equivalent of the books that stores use to check for terminated credit cards. If your private key is compromised (someone else discovers it), you advertise this fact by adding your name to a CRL. A good key server or mail client will use such lists to ensure that a given key's owner has not revoked it.
Real-World Products and Standards
The Lotus Notes mail system,
Notes Mail, provides all the features described above except for a key server,
but in a proprietary manner that works only with other Notes Mail clients. Mail
from a Lotus Notes mail client user arrives with a large amount of apparently
extraneous cybercrud. This is the sender's public key and
certificate(s), plus a digital signature for that message, all in ASCII encoded
form.
Microsoft Exchange offers the option of supporting advanced security,which requires you to install and manage yet another daemon process, a key server. Although Microsoft used some of the available standards, this approach works only if you do everything with Exchange Client and Exchange Server software. In particular, the overall proprietary design of Exchange Server makes translating security features into Internet-secure email standards via the Internet Connector impossible for users. This situation is a major reason why people are abandoning proprietary systems.
Riordan's Internet Privacy Enhanced Mail (RIPEM) is a commercial, secure email client that implements the Privacy Enhanced Mail (PEM) standard. RIPEM's success is not widespread due to lack of acceptance of PEM and the delayed implementation of the necessary PEM public key and certificate server infrastructure. In particular, email client vendors find creating interoperable products based on PEM difficult.
X.400-based mail systems can have all the security features mentioned above, and the X.500 directory service can have very good support for public key and certificate management and distribution, if you install the X.509 part. Unfortunately, X.400 does not specify the security features in enough detail to let independent developers create products that interoperate with products from other vendors (Exchange Server is an example of a product that supports X.400, although only via a gateway. Exchange currently has no support for X.500.). Also, X.400 in general and X.500 in particular require Open Systems Interconnect (OSI) network support (usually in addition to Internet-style TCP/IP support). Much of the world (especially the US) does not use OSI support.
Pretty Good Privacy (PGP) is not an email product but a standalone utility available for many platforms, including DOS, Windows 95, NT, and Unix. PGP lets you add or process security features such as digital envelopes and digital signatures on any file. ViaCrypt offers a commercial implementation of PGP. You can use PGP with most existing email systems to accomplish the same functions as with an email package that has integrated security (albeit with a clumsy, additional step before sending and after receiving). Pegasus email, in particular, has taken a step toward integrating PGP and is less clumsy than other packages.
A fascinating aspect of PGP is the concept of decentralized trust relationships (no central certificate authority is required), which makes PGP more acceptable to individuals and for inter-organizational secure mail. Much of the world anxiously awaits the availability of a good, strong Internet email client with PGP functionality and good PGP public key and certificate servers. This goal is the email software developer's equivalent of the Great American Novel.
The S/MIME standard is the most likely future of client-based secure Internet email, certainly in organizations that can implement centralized certificate management. S/MIME is a refinement and extension of the PEM concepts that RSA cleaned up with its Public Key Cryptography Standards (PKCS). Many vendors have signed on to implement this standard (despite the Internet community's reluctance to become so dependent on one company's technology). ConnectSoft E-Mail Connection 3.0 supports S/MIME.
Security Is Key
Digital envelopes and signatures are two
prevalent and safe methods for securing email privacy and integrity. Several
products support these methods and are making them easy to get and use. Anyone
developing email applications or even using email for business needs to know
what these technologies do, how to use them appropriately, and how they are
evolving. Listing 1 has resources both on the Web and in print for more
information on email security and evolving products and standards. Email
security is an area we cannot afford to ignore.
| Contact Info |
|
Lotus Notes 4 Lotus * 617-577-8500 Web: www.lotus.com Microsoft Exchange Microsoft * 206-882-8080 Web: www.microsoft.com RIPEM Mark Riordan mrr@scss3.cl.msu.edu Web: www.cs.indiana.edu/ripem/dir.html X.400 (an ISO standard) International Telecommunication Union (ITU) * Web: www.itu.ch Pretty Good Privacy Pretty Good Privacy * 415-631-1747 Web: www.pgp.com ViaCrypt ViaCrypt * 602-944-0773 Web: www.viacrypt.com S/MIME RSA Data Security * 415-595-8782 Web: www.rsa.com |