Securing email

Written by Dominik Joe Pantůček on August 30, 2018.

After creating a robust solution for mail sending, filtering, delivering and storing, one starts wondering how to add more confidentiality and integrity to such communication setup security mix. DKIM signatures and SPF records are mostly helpful for fighting spam, but for an targeted attack they pose little to no threat. And as targeted attacks are always really big threat, this does not make the situation look very optimistic for the email user. Nowadays, there are at least two major standards used for securing email communication. Both have their advantages and both have their disadvantages – so let’s have a closer look at both of them. And as you can probably guess, we are getting closer to our goal of securing email communication using at least one of these standards.

The two standards I would like to talk about here are the S/MIME[1] extensions – adding the S letter standing for Security to the Multipurpose Internet Mail Extensions standard – and OpenPGP[2] which stands for Open Pretty Good Privacy. Encrypted messages and digital signatures using both standards can actually be delivered as MIME attachments – or more precisely MIME multipart type messages. Email messages using the OpenPGP standard can also be sent in text-only “ascii-armored” manner – but this should be considered discouraged nowadays.

S/MIME

Secure MIME (S/MIME) adds message authentication and integrity assurance (using digital signatures) and also message confidentiality (using encryption) to already prevalent electronic mail messages standards. Mostly developed since 1999 until 2004, this standard makes heavy use of already available technologies – like x.509(v3)[3] certificates and certificate authorities hierarchy and PKCS#7 cryptographic message format[4]. This, in addition to underlying cryptographic primitives (key generation, signature, key exchange and encryption algorithms) and their storage like PCKS#12[5], creates a relatively open – yet quite complex and also quite rigid – ecosystem for digital signatures and encryption when using email.

When using any kind of digital certificates, you can only confirm that someone is possessing a private key which is linked to a public key you know. Or you can encrypt a message for someone whose public key you already have. The method of obtaining the other party certificate is not at easy as it sound – that is, if you want to be really sure to whom you are actually talking.

A viable approach to this problem is to verify to some higher level the identity behind some certificates and let the identified entity verify other certificates and by signing their public keys certify that they really belong to someone specified in the certificate structure. Of course, then you have to trust the certifying entity that it will do its job well.

Such entity, using x.509 certificates, is called certificate authority (CA) and the process of signing other entities’ certificates is called issuing certificates. The role of CA does not end there and it has to be able not only to perform the whole identity verification but also provide infrastructure for complete certificate life-cycle management. This is nicely covered in my PKI song and the general idea about a typical CA hierarchy can be seen in picture 1.

Picture 1: Certificate authorities hierarchy.

With a robust CA hierarchy in place, this can serve as really good identity verification for otherwise previously unseen parties. However, the whole system relies on trusting the root CAs. And that has been shown lately to be slightly problematic, especially when it comes to government or corporate surveillance. Putting these problems aside, the CA hierarchy allows you to securely verify identity of anyone who presents such identity using x.509 digital certificates even though you have not seen them before. Without certificate authorities, the system would require you to manually link each and every x.509 certificate to actual person you want to communicate with.

This rather nicely sums up both the pro’s and the con’s of S/MIME – as the implementation details of actually signing and encrypting email are done in software transparently and (usually) you do not have to worry about it.

OpenPGP

Pretty Good Privacy is entirely different beast that covers both format of signatures and encrypted messages, but also custom format of user certificates, which are – informally – called “keys”. Originally developed by Phil Zimmerman in 1991 and was fully standardized in 2007[6] with latest additions of new algorithms on their way as you are reading this article[7].

The messages can be sent in binary form or in an ASCII format which allows for safe transfer over various kinds of some really weird connections. When sending the messages as an email, the ASCII-armored form can be sent as regular message or as an encrypted attachment – which most email clients recognize and act upon its reception accordingly. It is worth noting that the MIME extension allowing to send signed and encrypted messages in nicely structured format has been codified back in 2001[8].

As mentioned above, for PKI, there is a song. But what for Pretty Good Privacy? Of course, there is at least a Pretty Good Privacy song preview. What did you expect?

Verifying users’ identity with OpenPGP relies on a concept called the Web of Trust. The concept is fairly simple: for some number of contacts you verify their identity in-person. In order to verify identity of other users, the standard allows for signing other people certificates and exporting these signatures. This way you can easily publish your key including signatures you collected from other people. Then, if you want to verify an identity of certificate someone sent you, you look at the signatures this certificate contains and check if you know some of the signers and trust them to some extent when it comes to verifying other people identity. The more signatures you at least somehow trust, the more you can behave as if the identity belonging to the certificate you have just seen belongs to the person it claims.

You can see the general idea of identity verification is – as in x.509 case – shifted to a trusted entity. But in this case you do not need to fully trust a single entity and you can cross-check using multiple sources and decide for yourself if that is enough. You can have a look at Picture 2 which clearly demonstrates a small web of trust. Imagine you receive a message from Cecilia and you do not possess her certificate. But she sends the certificate alongside her message and you see signatures from Alice and Bob which you know and trust. That is probably enough for you to believe that Cecilia really is someone who is she pretending to be. But what if you get a similar message from Frank? Signed by Eve that you do not know… Looks suspicious, doesn’t it? In this case, if you could get your hands on the whole certificate chain from Alice and Bob over Cecilia, Dave and Eve to Frank, you could easily say that although the verification is far from perfect, at least some anchor is present and therefore for certain topics even this identity verification might suffice.

Picture 2: Web of Trust example

As with S/MIME the bulk of pro’s and con’s comes with the certificate distribution and key management. You can build a very robust web of trust within certain group but in order to communicate with someone distant, it is always a good measure to verify identities belonging to given certificate by other means as well. It is much harder to attach this scheme than the hierarchical structure of x.509 CAs, but sometimes people recklessly sign other certificates without actually verifying the identities of those behind them. Once again, it is about at least some level of trust.

Today, we have looked at two possible ways of securing email communication and briefly discussed their pro’s and con’s. Next time we will tackle the problem of private key storage for both standards and investigate the possibilities of enhancing the overall communication security even further. See you next week!

References

1. RFC 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, Network Working Group, July 2004, available online at https://tools.ietf.org/html/rfc3851

2. RFC 4880: OpenPGP Message Format, Network Working Group, November 2007, available online at https://tools.ietf.org/html/rfc4880

3. RFC 5208: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Network Working Group, May 2008, available online at https://tools.ietf.org/html/rfc5280

4. RFC 2315: PKCS #7: Cryptographic Message Syntax, Version 1.5, Network Working Group, March 1998, available online at https://tools.ietf.org/html/rfc2315

5. PKCS #12. (2018, February 4). In Wikipedia, The Free Encyclopedia. Retrieved 22:18, February 12, 2018, from https://en.wikipedia.org/w/index.php?title=PKCS_12&oldid=824020550

6. OpenPGP: Email encryption. For all operating systems. Standing the test of time.; homepage available online at https://www.openpgp.org/

7. EdDSA for OpenPGP, draft-koch-eddsa-for-openpgp-04, W. Koch, February 2016, available online at https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-04

8. RFC 3156: MIME Security with OpenPGP, Network Working Group, August 2001, available online at https://tools.ietf.org/html/rfc3156