If you would like to read the other parts in this article series please go to:
- Email Security with Digital Certificates (Part 1)
- Email Security with Digital Certificates (Part 2)
- Email Security with Digital Certificates (Part 4)
- Email Security with Digital Certificates (Part 5)
Introduction to S/MIME
The Secure Multipurpose Internet Mail Extensions (S/MIME) protocol has long emerged as a de facto standard for encrypted email. S/MIME uses the RSA encryption algorithm and has received the backing of major industry players, including RSA Security. With S/MIME, administrators have an e-mail option that is both more secure and widely accepted. S/MIME is as important a standard as SMTP because it brings SMTP to the next level: allowing widespread e-mail connectivity without compromising security.
The first version of S/MIME was developed in 1995 by a number of security vendors. It was one of several specifications for message security. Pretty Good Privacy (PGP) was an example of another, different specification for message security. At the time of S/MIME version 1, there was no recognized single standard for secure messages but rather several competing standards.
In 1998, this began to change with the introduction of S/MIME version 2, which was submitted to the Internet Engineering Task Force (IETF) for consideration as an Internet standard. This changed S/MIME from being one possible standard among many, to being the leading contender for a message security standard.
In 1999, S/MIME version 3 was proposed by the IETF to enhance S/MIME capability. It brought enhanced certificate handling and extended overall capabilities by adding additional services to S/MIME, such as secure receipts, triple-wrapping (discussed later in the series), and security labels. S/MIME version 3 achieved wide acceptance as the standard for message security and was supported by Outlook 2000 (with SR-1 applied) and later, Outlook Express 5.01 and later, and Exchange 5.5 and later. S/MIME version 3.2 was published in 2010.
S/MIME relies on the use of X.509 certificates for exchanging cryptographic keys. The public keys contained in these certificates are used for digital signatures and for the exchange of symmetric keys used for longer communications sessions (discussed in deeper detail next). RSA is the only public key cryptographic protocol supported by S/MIME. The protocol supports the AES and 3DES symmetric encryption algorithms.
Despite strong industry support for the S/MIME standard, technical limitations have prevented its widespread adoption. Although major desktop mail applications support S/MIME email, mainstream web-based email systems do not support it out of the box as the use of browser extensions is required.
S/MIME provides two security services, which are the core of S/MIME-based message security: Digital Signatures and Message Encryption. Before delving into how we use S/MIME, first we should understand how digital signatures and message encryption work and what they can do for us.
Digital Signatures
Digital signatures are the more commonly used service of S/MIME. As the name suggests, digital signatures are the digital counterpart to the traditional, legal signature on a paper document. As with a legal signature, digital signatures provide the following security capabilities:
- Authentication: a signature serves to validate an identity. It verifies the answer to “who are you” by providing a means of differentiating that entity from all others and proving its uniqueness. Because there is no authentication in SMTP, there is no way to know who actually sent a message. Authentication in a digital signature solves this problem by allowing a recipient to know that a message was sent by the person or organization who claims to have sent the message;
- Nonrepudiation: the uniqueness of a signature prevents the owner of the signature from disowning the signature. This capability is called nonrepudiation. Thus, the authentication that a signature provides gives the means to enforce nonrepudiation. Because SMTP does not provide a means of authentication, it cannot provide nonrepudiation. It is easy for a sender to deny ownership of an email;
- Data integrity: an additional security service that digital signatures provide is data integrity. When the recipient of a digitally signed email validates the digital signature, the recipient is assured that the email received is, in fact, the same email that was signed and sent, and has not been altered while in transit. Any alteration of the email while in transit after it has been signed invalidates the signature.
Signing Emails
Digital signature algorithms rely on a combination of the two major concepts already mentioned in this series: public key cryptography and hashing functions. If Linda wants to digitally sign a message she is sending to Nuno, she performs the following actions:
- Linda generates a message digest of the original plaintext message using a hashing algorithm;
- Linda then encrypts only the message digest using her private key. This encrypted message digest is the digital signature;
- Linda appends the signed message digest to the plaintext message;
- Linda transmits the entire message to Nuno.
Figure 1
Combining the message with the private key is accomplished by encrypting the hash value with the sender’s private key, which creates the actual digital signature. Depending on how the sender’s email system has been configured, the digital signature is appended either to the bottom of the message, creating a “clear signed” message, or the result is combined with the original message into a binary attachment, creating an “opaque signed” message.
Because the digital signature is added to the original message as an attachment, clear signed messages can be read by email clients that do not support S/MIME. The signature is discarded and the original message is displayed by the client. However, there is no way the message can be verified; it is essentially the same as an unsigned message. The disadvantage of clear signed messages is that there is an increased chance for mail gateways to alter the message and invalidate the signature.
On the other hand, because the message and the digital signature are treated as a single binary attachment in opaque signed messages, they are much less likely to be altered in transit. However, only an S/MIME client can read the attachment. If a non-S/MIME client receives an opaque signed message, the message is unreadable.
Opaque-signed messages were, in part, created to solve the problem of email systems that altered message bodies while email was in transit.
Current email solutions that comply with S/MIME standards typically do not alter the message body. However, there are many clients that cannot read opaque-signed email messages. Therefore, sending clear-signed messages is recommended.
Validating Digital Signatures
When Nuno receives the digitally signed message, he reverses the process performed by Linda:
- Nuno uses the same hashing function to create a message digest of the full plaintext message received from Linda;
- Nuno decrypts the digital signature using Linda’s public key;
- Nuno then compares the decrypted message digest he received from Linda with the message digest he computed himself. If the two digests match, he can be assured that the message he received was sent by Linda and was not altered in between. If they do not match, either the message was not sent by Linda or the message was modified while in transit.
Figure 2
When the message is received, the digital signature can be retrieved and the sender’s public key applied in a decryption operation, which reveals the original hash value of the message. A comparison of this hash value with the hash value of the received message can then be performed. Because only one private key can correspond to a public key, and only the owner of the public key could use it to encrypt the hash value successfully, decrypting the hash with the public key shows that the private key owner encrypted the hash value. Because the hash value is a representation of the message text, if the encrypted hash value matches the hash value of the message received, it indicates that the message text that was sent matches the text that was received. When coupled with the fact that only the private key owner could have sent the message, the result is that the recipient is assured that only the key owner sent the message, which provides authentication and, consequently, nonrepudiation. It also shows that the message has not been changed, which provides data integrity. If the hash values did not match, the recipient would know that the message had either been altered in transit or that the public key used does not match the private key used. In both cases, the recipient knows that the message is not valid and should not be trusted.
Note that the digital signature process does not provide any privacy. It only ensures that the cryptographic goals of integrity, authentication and nonrepudiation are met. Messages with only a digital signature are sent in clear text, similar to SMTP messages, and can be read by others. However, if Linda wanted to ensure the privacy of her message to Nuno, she could add a step to the message creation process. After appending the signed message digest to the plaintext message, Linda could encrypt the entire message with Nuno’s public key. When Nuno received the message, he would decrypt it with his own private key before following the steps just mentioned. This process, known as Message Encryption, is explained in detail in the next article.
Conclusion
In this article we introduced S/MIME and explored how digital signatures work and what they provide us with. In the next article we will look at message encryption.
If you would like to read the other parts in this article series please go to:
