As long as I’m shouting into the void, I’ll mention a recent tutorial I summarized on implementing S/MIME email encryption, specifically within iOS.
I am very cognizant of the fact that people as a whole, when faced with the decision of mildly inconveniencing themselves for security vs. not using security at all, will inevitably choose the latter. It is a predictable constant which infuriates me immensely.
There, I voiced my opinion on the matter. With that preface, I will avoid the more lengthy soapbox speech. You’re welcome.
I categorize various technologies into one of three overly-simplified classifications: “Not Secure”, “Probably Secure”, and “Secure Beyond Reasonable Doubt”. The email protocol as a whole falls under “Not Secure”, however, circumstances may allow it a “Probably Secure” status. For example, when the sender’s email provider’s server sends the email to the recipient’s email provider’s server, it has the option to negotiate encryption. This encryption is not enforced, so if either server opts to not support it, then there is no encryption. Also, there is no way to verify this level of encryption as the user doesn’t see this process. Now, certain email providers can be assumed to use encryption as the default, based upon their established reputation. Google, for instance, does default to encryption with their Gmail service. Therefore, if both the sender and the recipient are using Gmail accounts, then it can be safely assumed that the email remained encrypted in transit, therefore it is “Probably Secure”. But this a very specific example, and cannot be assumed or confirmed by the end users.
Another example of “Probably Secure” is Apple’s iMessage. This messaging service not only defaults to, but requires encryption. The caveat is that Apple itself creates and maintains the encryption keys. This is where a lesson in how public key infrastructure operates would add context, but any explanation I could offer would be far less robust than that of a crypto-analyst’s, so if curious, you know, LOOK IT UP!
The conclusion here is that while iMessages are indeed encrypted, we’re relying solely on a third party to keep them that way, and again the user has no way of verifying the process. Therefore: “Probably Secure”.
The point being: in certain circumstances you are probably okay, but sometimes being probably okay isn’t good enough. My wife and I often have the need to exchange sensitive information, as no doubt many married couples do. Health information, other personal information about ourselves and our daughter, financial information, the need to exchange login credentials to sites that house this information–these are instances where “Probably Secure” doesn’t inspire much confidence, whereas coordinating dinner plans doesn’t need that level of security.
Which brings me to the solution and my ultimate point: a system exists that can provide “Secure Beyond Reasonable Doubt” communication, and as the title of this post would suggest, that is called “S/MIME Email”. The base concept is that both users obtain encryption certificates and, using the public key exchange system on which all modern asymmetric encryption is based, encrypt and decrypt each others’ emails before they are sent and after they are received at the device level. Nowhere in transit will the email be unencrypted (such as in webmail).
For a better understanding and background on the technology, some keywords to search for are: “S/MIME”, “Public Key Infrastructure”, and “Asymmetric Encryption”.
Moving on: the process is somewhat irritating to set up initially, plagued by the individual quirks of each device/computer and email client. After trial and error, I have compiled a brief walkthrough of the process for iOS–of which, I note, I was unable to find in its entirety elsewhere on the internet (specifically uninstalling previously installed recipients’ certificates). I have housed the walkthrough on my Wiki: https://moorheadfamily.net/MediaWiki/index.php?title=S/MIME .
Good luck, and keep your private information safe!
–Simon