A look at email security - Part 2 - S/MIME certificates: what they are, how they work and how to obtain one free of charge

Summary

This is part 2 of a series looking at email security.

The schedule and content of the other parts might change as they are released over the next few months, but each article will contain an up-to-date table of contents.

• Part 1 - Overview and general advice
  • Introduction
  • Dos and don'ts
• Part 2 - S/MIME certificates: what they are, how they work and how to obtain one free of charge
  • What is S/MIME?
  • Public-Key Cryptography
  • How does digital signing work?
  • What about encrypting the message?
  • Obtaining a free S/MIME certificate
• Part 3 - Signing and encrypting emails with S/MIME on desktop and mobile devices
  • Using S/MIME on Windows with Outlook and Thunderbird
  • Using S/MIME on the Apple Mac
  • Using S/MIME in Outlook Web App (in Office 365)
  • Using S/MIME on Android, iOS and Windows Phone
• Part 4 - PGP keys: what are they and how can I get one?
  • What is PGP?
  • Obtaining a PGP key
• Part 5 - Signing and encrypting email with PGP on desktop and mobile devices
  • Using PGP on Windows with Outlook, Thunderbird, etc
  • Using PGP in Outlook Web App (in Office 365)
  • Using PGP on Android, iOS, Windows Phone
• Part 6 - DKIM and SPF
  • What are they and how do they work? Something to do with DNS records?
• Part 7 - Sending signed emails programmatically
  • Sample code to sign and send emails. Probably written in C# to be delivered via ASP.NET Web API 2.
• Part 8 - Conclusions

Introduction

In part 1 we decided that email is not a secure communication medium and that it would be nice if we could find a way to offer some assurances about the identity of the sender and the privacy and integrity of the message (i.e. that it had neither been read nor altered whilst in transit).

This time, we're going to look at how using an S/MIME certificate can help to achieve those aims. In order to facilitate this, we'll be covering the basics of Public-Key Cryptography in simple terms.

Finally, we'll see where we can obtain an S/MIME certificate free of charge.

What is S/MIME?

According to Wikipedia, S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public-key encryption and signing of MIME data that provides authentication, message integrity, non-repudiation of origin (using digital signatures), privacy and data security (using encryption).

That's quite a comprehensive list, but what does it all actually mean?

• Authentication - the message was sent by the apparent sender.
• Message Integrity - the message was not altered in transit.
• Non-repudiation of origin - the person who sent it can't pretend that they didn't.
• Privacy - nobody else has read the message in transit.
• Data Security - this is a combination of message integrity and privacy which also means that data has not been destroyed.

Multipurpose Internet Mail Extensions (MIME) is an internet standard that extends the format of email to support (amongst other things) the inclusion of non-text attachments such as audio, video, images, documents, etc. Nearly all email is transmitted over SMTP in MIME format.

S/MIME uses Cryptographic Message Syntax (CMS). CMS relies on X.509 certificates for public key distribution. As well as containing a public key, an X.509 certificate always contains the name of the entity it identifies, an expiry date, the name of the Certificate Authority (CA) that issued the certificate, a serial number and various other information besides.

In other words, S/MIME is a more secure way of sending email.

If you've ever had a corporate email account that allowed you to sign your emails then the chances are, you were using an S/MIME certificate.

Public Key Cryptography

A detailed discussion of Public-Key Cryptography is significantly beyond the scope of this article, but we do need to know something about it in order to understand how an S/MIME certificate works.

Public-key cryptography, which is also known as asymmetric cryptography, is a way of encrypting data using a matched pair of two different (but intrinsically linked) keys. When data is encrypted with one key, it can only be decrypted by the other key. One key is private and the other one is public. Either key can be used to encrypt data.

This means that if I encrypt data with my private key, then anybody can decrypt it using my public key. This might seem pointless at first glance, but its utility in digitally signing messages will soon become apparent.

The best bit is that anybody can encrypt data using my public key and, since I am the only one in possession of the private key, therefore I am the only person who can decrypt it.

I can safely give out copies of my public key to all and sundry, as long as I keep my private key secret. Indeed, when I digitally sign an email my public key is sent along too.

At this point, it would also be useful to know a little about Public Key Infrastructure (PKI). In essence, the PKI is everything to do with the creation, management, distribution, usage, storage, and revocation of digital certificates. In the context of X.509 certificates (such as S/MIME and TLS/SSL certificates) this involves a Certificate Authority (CA) who are a trusted third party responsible both for issuing the certificate and vouching for its authenticity.

How does digital signing work?

• The original message is hashed (passed through a non-reversible mathematical function) to produce a digest which is then encrypted with the private key of the sender.
• The unencrypted message and the digest are sent to the recipient together, along with the public key (remember, the public key really is in the public domain) as well as information about the hashing algorithm that was used.
• Upon receipt, the recipient uses the public key of the sender to decrypt the digest that accompanied the message.
• Next they hash the accompanying message to produce their own digest.
• Finally, they compare the two digests. If they are the same then they can safely say that:

1. the message was not altered after it was signed (otherwise the hashes, and therefore the digests, would not have matched).

• the message was signed using the private key of the purported sender (otherwise their public key would not have decrypted the digest).

It follows that, as long as nobody else has stolen the sender's private key, then it must be they who sent the message.

What about encrypting the message?

In the previous example, you will have noticed that the original message was not encrypted, but rather was sent as plain text. In order to send an encrypted message, it is necessary to have a copy of the recipient's public key.

You will remember that we mentioned that as well as encrypting with the private key and decrypting with the public key, the reverse is also possible, meaning that if you encrypt a message with the public key, only the owner of the private key can decrypt it. Thus, we can work out how to send an encrypted message, as long as we have the recipient's public key.

The intended recipient sends us a signed email which gives us their public key. We check the validity of this signing certificate as follows.

• I have a number of trusted root certificates from certification authorities (CAs), each containing a public key which I trust. These trusted root certificates are usually installed as part of the operating system.
• The signed email contains a chain of certificates. This certificate chain includes the certificate used to sign the email (the certificate belonging to the sender and containing their public key) and usually includes one or more intermediate certificates. [It may also include the root certificate although this will never be used because the last certificate in the chain has to be a trusted root certificate and they are usually installed as part of the operating system.]
• I check the certificate used to sign the email by decrypting it using the public key from the next certificate in the chain (the first intermediate certificate).
• If the Issuer of the first certificate matches the Subject of the next certificate then everything is okay and I repeat this process for each intermediate certificate until I get to the trusted root certificate.
• Finally, I decrypt the penultimate certificate in the chain using the public key from my trusted root certificate corresponding to that Subject.
• If the chain is intact then I know that the email was signed with a valid certificate issued by the trusted root certificate authority, since each certificate in the chain must have been signed with the corresponding private key.

You can read more about certificate chains here.

Once you have got the public key of the intended recipient and have written a message which you wish to encrypt, it's fairly straightforward to:

• Hash the original message to produce a digest.
• Encrypt the digest with your own private key.
• Encrypt the message with the recipient's public key.

Then when they receive the message they can:

• Decrypt the message with their private key.
• Hash the decrypted message to create a digest.
• Decrypt the digest you sent using your public key.
• Compare the digests.

This reliance on public and private keys (asymmetric cryptography) forms the basis of all of the online certificate stuff with which you're probably familiar. I might write a bit more about this in a future article, but for now, suffice it to say that the certificate contains the public key and the private key is stored somewhere on my computer.

If we are confident that the message has been encrypted in such a way that only the intended recipient can decrypt it, then our requirement for privacy in transit has been satisfied. Of course, as we alluded to in part 1, we can't prevent the recipient from printing out the email and nailing it to a lamp post.

Certificate revocation

Under certain circumstances, it may be necessary to cancel (or revoke) a certificate prior to its natural expiration date, usually if the private key has been lost or compromised. Consider the analogy of a credit card being stolen; if this happens you need a way to cancel it. This is handled by the use of a certificate revocation list (CRL) which contains the serial numbers of those certificates which are no longer valid, despite not yet having expired. CRLs are part of the PKI and are a topic for discussion elsewhere.

Obtaining an S/MIME certificate

All of the main certificate authorities provide email certificates but, as far as I'm aware, there are only two providers of free email certificates: StartSSL and Comodo, with the latter offering them through various of their branded sites, such as InstantSSL, PositiveSSL, etc.

Free S/MIME Certificate from Comodo

First go to https://www.instantssl.com/ssl-certificate-products/free-email-certificate.html and fill in the form.

Notice that it doesn't work properly in Edge in Windows 10; the key size drop down is missing.

I used Chrome instead and it worked fine.

Make sure you choose a decent revocation password and that you record it somewhere. As you will have guessed, you need this if you want to invalidate your certificate early.

I'm going to talk about passwords a lot more in a future article, but for now please just make sure you have kept a copy of your revocation password somewhere. Imagine if somebody got hold of your private key and was able to send signed emails, ostensibly from you, and there was no way for you to stop this from happening until the certificate expired. Not cool. Save your revocation password.

Downloading your certificate

After you've filled in the form you will receive an email containing a link to download your certificate. Click on the link.

If you're using Windows 10, you will notice that Edge won't invite you to install the certificate. When this happened to me, I pasted the link into Chrome instead and it worked fine.

Now if you've been paying attention up to this point, you might be worried that you can click the link over and over again to collect the certificate multiple times and that this information was sent in an unencrypted email which might have been intercepted.

However, it turns out your fears would be unfounded since you can only install the certificate on the same machine from which the original request was made. Why? When the original request was made, a private key was generated and that key never left your machine. The form you filled in even told you that.

Since the certificate is only validated by email, then that means that if somebody were to gain control of your email account they could get a certificate proving... what exactly? That they were in control of your email account. Nothing too alarming there.

So this is free and is actually secure. That's pretty good. Have a look at the certificate for yourself.

Notice that the certificate is just validated on my email address. All this proves is that the person who applied for the certificate was in charge of the email address [email protected] at the time. Fortunately, that was me. You can see this for yourself by sending me an email if you like.

Free S/MIME Certificate from StartSSL

StartSSL undertake a bit more validation before issuing a free certificate. You have to provide your name, address and telephone number. Since I already have an account with them, when I tried to sign up for another account for the purposes of this blog post, my account was held up for review. For this reason, I'm not going to give a detailed description of the signing up process here, but it's similarly straightforward. I hope this doesn't come across as being dismissive of StartSSL. I think they're great, I have paid for an account with them and this site uses a StartSSL Class 2 wildcard certificate.

StartSSL has a different business model where you pay for the validation and can then issue multiple certificates for free, although there is a fee for revocation should it be required. I think it's good.

Check out their validation and certification features.

Conclusion

It's possible to sign an unencrypted email so that the recipient can be sure that it was sent by the purported sender and that it has not been altered in transit. However, this does not offer any assurance that it has not been read by an unauthorised third party. If you have a copy of the recipient's public key, you can also encrypt the message which does provide this assurance.

Sending signed and encrypted emails is generally done by using Public-Key Cryptography, which means that you need to obtain matched private and public keys. One of the most common ways to do this is by using an S/MIME certificate and we have seen two ways that you can obtain one for free.

In part 3 we'll see how you can install your S/MIME certificate into your favourite email client (as long as your favourite is in the list of clients I am going to cover, which will probably be Outlook, Thunderbird, Windows Phone, iOS and Android).

Finally, it's worth remembering that if you receive a signed email from me, all that really tells you is that the sender was in control of my private key^[1]. If I'm careless^[2], then that might not be me.

Image credit: bluebay/Shutterstock.com