Digital Envelopes and Signatures

Digital envelopes and digital signatures are two specific applications ofcomputer security technology that can enhance the functionality of electronicmail. A digital envelope (encryption) is the electronic equivalent ofputting your message into a sealed envelope to provide privacy and resistance totampering. A digital signature is the electronic equivalent of a signetring and sealing wax: You seal the message so that the receiver has a highdegree of confidence that the message really came from the purported sender andthat no one has altered it. (For more information on the role of encryption incomputer security, see Lawrence E. Hughes, "Secure Enterprise Email,"Windows NT Magazine, May 1996.)

These two security functions are mutually independent, and you can applyneither, either, or both to a message. Only the sender's private key (a binaryvalue 40-bits or more long) is required to create a signature. A secure mailclient will apply digital signatures by default, without affecting a person'sability to read the message through a mail reader without a secure mail client.In contrast, digital envelopes make the entire message gibberish to a recipientwithout an appropriate reader and the correct decryption key. Therefore, adigital envelope is never a default. However, a well-designed mail client canremember (or determine from a directory service) what recipients to use digitalenvelopes with, what type of digital envelope to use (many standards areavailable), 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, encryptionhas become more complex with the availability of computers to escalate the gameof lock builder vs. lock picker.

Encryption provides privacy. You scramble information so that only theintended recipient can unscramble it. Encryption does not prevent third partiesfrom intercepting the message, but they intercept pure gibberish; theintercepted message is useless without the decryption software and appropriatekey. 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 thealgorithm does the scrambling). The more bits in the key, the more keys arepossible. For example, DES has 56 bits in each key, hence a total of 2⁵⁶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. Asymmetrickey encryption creates the key in two complementary pieces, like the two piecesof a raggedly torn dollar bill. One piece is the public key, because nosecurity is lost by publishing it for anyone to know, and the other is the privatekey, because you must guard it from discovery. If you encrypt with a givenpublic key, someone can decrypt only with the corresponding private key; noother key, including the public key used to encrypt the information, cansuccessfully decrypt it. That simple difference in key use is the mostsignificant breakthrough in security technology in 2000 years.

Unfortunately, asymmetric key algorithms are hundreds or thousands of timesslower than symmetric key algorithms and are suitable only for processing smallpieces of information (e.g., a 56-bit symmetric key). So, most digital envelopeschemes use an asymmetric key algorithm (e.g., Rivest-Shamir-Adleman--RSA--orDiffie-Hellman) to securely exchange a session key (a randomly generatedsymmetric key just for this one message or session; then you discard it) andthen use a symmetric key algorithm (e.g., DES or International Data EncryptionAlgorithm--IDEA) to encrypt the text by means of the session key.

The person sending a message in a digital envelope must randomly select asymmetric algorithm session key and then encrypt that session key by using therecipient's public key and an asymmetric algorithm. The sender encrypts themessage body (the plaintext) with the original (unencrypted) symmetricsession 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 theirown private key) and then decrypt the rest of the message using the recoveredsession key to obtain the original message body (the plaintext). Only the holderof the recipient's private key (hopefully, only the recipient) can recover thesession key and the original message.

Digital Signatures
Digital signatures are a more recent conceptthan encryption and address issues of authentication (proof of identityof the sender) and message integrity (detection of changes to themessage). 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 technologybut need a trick to keep the amount of data processed with it to a minimum. Inthis 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). Youfeed the entire contents of the message through an algorithm that is a functionof the entire content, including the order of all the characters. This algorithmcreates a residue (typically, 64 bits' worth, regardless of the size ofthe original message--even more condensed than a Reader's Digestcondensation of a book!). If someone alters the message and you run the resultthrough the algorithm again, the result is a different residue. The probabilityof getting the same residue from two different messages is one in 2⁶⁴power, which is millions of times less likely than your chances of winning alottery. This residue, or more accurately the cryptographic checksum, iswhat asymmetric key technology encrypts and then appends to the message tocreate the digital signature.

For a recipient to verify a digital signature, the receiving mail clientprogram must use the sender's public key to extract and decrypt the transmittedmessage digest. The receiver must obtain the public key, recalculate the messagedigest by passing the rest of the message through the message digest algorithm,and compare the transmitted residue with the newly calculated one. If theresidues match, no tampering with the message has occurred, and only the holderof the sender's private key can have created the digital signature (note thatanyone can verify a signature, as only the sender's public key isrequired).

If the residues don't match, either someone altered the message in some way(possibly the mail transport system innocently altered it by wrapping longlines), or someone other than the purported sender created the digitalsignature with some key other than the sender's private key, or both.Many digital signature schemes let you encode the message content to prevent themail transport system's innocent mauling from affecting the message digest, butthese schemes have the unfortunate side effect of making the message textunreadable without an appropriately equipped mail client program (you usedigital signatures with this feature only when sending mail to recipients thathave the appropriate capability).

Sometimes privacy and message integrity are essential, but who sentthe message is not important or is obvious from content. In this case, a digitalenvelope is necessary and sufficient. The interceptor first has to decrypt themessage to change it and then re-encrypt it using the same key originally usedto 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 thecritical concern is that it really came from the person who claims to have sentit, and that no one has tampered with it in any way. In this case, you can sendthe message in plaintext (no digital envelope) with a digital signature. Also,you cannot legally use encryption in certain situations, such as crossing mostinternational borders even if digital signatures are perfectly legal insidethose borders. When sending mail internationally or even within the borders ofmany foreign countries, find out what security technology is allowed and whatalgorithms and key lengths are permitted. Penalties can be severe if authoritiescatch you--assume that the National Security Agency monitors most digitaltraffic that enters or leaves the US.

Digital envelopes and digital signatures do not interact, and people oftenfirst digitally sign and then encrypt a message before sending it, takingadvantage of both privacy and authentication. Also, the digital envelopeprotects the digital signature. Finally, keeping the original digital signatureas part of an archived message is useful. For example, you can detectalterations while it is in storage or verify the identity of the sender again atany 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) mustobtain the public key of the sender. A simple way is to include thesender's public key in each message. You lose no security this way, but you geta lot of extra overhead and clutter that are often longer than the originalmessage. Adding to this overhead is the need for digitally signed certificatesthat guarantee that the public key belongs to the purported owner.

Today, a worldwide, distributed infrastructure (e.g., X.500 and LightweightDirectory Access Protocol--LDAP) is under construction to solve the problem offinding anyone's email address. This infrastructure will let you store andprovide access to everyone's public keys and entire chains of certificates (allthe way back to some unimpeachable source) on key servers, through theWeb. This infrastructure provides Certificate Revocation Lists (CRLs).Schemes that embed the key in the message do not address CRLs. You can think ofCRLs as the secure email equivalent of the books that stores use to check forterminated credit cards. If your private key is compromised (someone elsediscovers it), you advertise this fact by adding your name to a CRL. A good keyserver or mail client will use such lists to ensure that a given key's owner hasnot 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. Mailfrom a Lotus Notes mail client user arrives with a large amount of apparentlyextraneous cybercrud. This is the sender's public key andcertificate(s), plus a digital signature for that message, all in ASCII encodedform.

Microsoft Exchange offers the option of supporting advanced security,whichrequires you to install and manage yet another daemon process, a key server.Although Microsoft used some of the available standards, this approach worksonly if you do everything with Exchange Client and Exchange Server software. Inparticular, the overall proprietary design of Exchange Server makes translatingsecurity features into Internet-secure email standards via the InternetConnector impossible for users. This situation is a major reason why people areabandoning proprietary systems.

Riordan's Internet Privacy Enhanced Mail (RIPEM) is a commercial, secureemail client that implements the Privacy Enhanced Mail (PEM) standard. RIPEM'ssuccess is not widespread due to lack of acceptance of PEM and the delayedimplementation of the necessary PEM public key and certificate serverinfrastructure. In particular, email client vendors find creating interoperableproducts based on PEM difficult.

X.400-based mail systems can have all the security features mentionedabove, and the X.500 directory service can have very good support for public keyand certificate management and distribution, if you install the X.509 part.Unfortunately, X.400 does not specify the security features in enough detail tolet independent developers create products that interoperate with products fromother 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 utilityavailable for many platforms, including DOS, Windows 95, NT, and Unix. PGP letsyou add or process security features such as digital envelopes and digitalsignatures on any file. ViaCrypt offers a commercial implementation ofPGP. You can use PGP with most existing email systems to accomplish the samefunctions as with an email package that has integrated security (albeit with aclumsy, additional step before sending and after receiving). Pegasus email, inparticular, has taken a step toward integrating PGP and is less clumsy thanother packages.

A fascinating aspect of PGP is the concept of decentralized trustrelationships (no central certificate authority is required), which makes PGPmore acceptable to individuals and for inter-organizational secure mail. Much ofthe world anxiously awaits the availability of a good, strong Internet emailclient with PGP functionality and good PGP public key and certificate servers.This goal is the email software developer's equivalent of the Great AmericanNovel.

The S/MIME standard is the most likely future of client-based secureInternet email, certainly in organizations that can implement centralizedcertificate management. S/MIME is a refinement and extension of the PEM conceptsthat RSA cleaned up with its Public Key Cryptography Standards (PKCS). Manyvendors have signed on to implement this standard (despite the Internetcommunity'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 twoprevalent and safe methods for securing email privacy and integrity. Severalproducts support these methods and are making them easy to get and use. Anyonedeveloping email applications or even using email for business needs to knowwhat these technologies do, how to use them appropriately, and how they areevolving. Listing 1 has resources both on the Web and in print for moreinformation on email security and evolving products and standards. Emailsecurity is an area we cannot afford to ignore.