You’ve Got Mail … And Why That Should Be Such A Scary Phrase
Everybody gets email, all the time. Copyright Vkraskouski | Dreamstime.com
By Kevin King
According to reports, people across the world will send and receive 269 billion emails in 2017. Internet Live Stats, which is the accepted global standard for such matters, and part of the Real Time Statistics Project, an effort by an international team of developers, researchers, and analysts aiming to make statistics relevant in real time, tells me that at the second of glancing at the website before writing this sentence, at 06:00:11 hours, Eastern United States time, on April 11, 2,579,875 were being sent, and a large percentage of those emails were spam. And yes, this two million-plus per second number is only expected to grow. So given how much email we use, why is our email hygiene so bad, and can we make it better?
Most people probably already know that email isn’t exactly a very secure mode of communication, but most people also probably push that thought to somewhere in the furthest recesses of their memories. After all, email is very convenient. So they send all kinds of incredibly sensitive information, like passwords, social security numbers, and other Personally Identifiable Information (PII) over email every single day.
The truth is that the human in the loop is often the weakest link when it comes to keeping information secure. We make poor choices about passwords, accessing the Internet, and trusting companies to protect our data every single day.
Email is particularly vulnerable to exploitation, and unfortunately, it’s incredibly difficult for the end user to know if any specific message exchange is secure. There are things that both your email provider and you can do to make your email more secure, but they all come with a cost.
While most people now know (or should know) enough not to use an email account that doesn’t provide secure communications at the front end — that little green padlock next to the website name — it is doubtful whether most ever consider how mail providers interact with other mail providers. Some of this is the stuff nightmares are made of.
As recently as 2014, only about 60 percent of notification emails sent by Facebook, for instance, were sent with encryption during transport. Google’s transparency report shows that you have a 1 in 10 chance of sending or receiving an email to a non-Google provided account that is not secure when exchanged with the other mail provider. Things are apparently better now, but still indicate that there’s a long road ahead for everyone before the state of email security is improved.
An Unfair Playing Field
One big failing of email is that it’s hard to prove who sent an email. This may seem unintuitive since there’s a field in email that is supposed to tell you whom the message is from, but, due to how email works, there’s no guarantee that this field is correct. In fact, bad actors will often put incorrect information in this field in order to fool the recipient into opening a dangerous email.
There are additional tools at the disposal of mail providers like the Sender Policy Framework, Domain Keys Identified Mail, and Domain-based Message Authentication, Reporting & Conformance, but the sender must implement them and the recipient must check them in order for these protections to help. And no, you can’t do them! These are checks that your email provider performs, so you have little control over how these extra security steps get implemented. But what are they?
Sender Policy Framework (SPF)
SPF is designed to address the problem of address spoofing. This is a technique where a sender puts the wrong information in the “from” header in an email, in an attempt to trick the recipient into opening the message. For instance, if I’m a known sender to you, and the sender puts in my email address in the from header, and at first glance, it appears to be from me. However, if you were to investigate the origin of the email and compare it to other ones that I have sent, you would find that the spoofed email was sent from a completely different place on the internet. SPF is a list of authorized senders for your domain as well as a suggestion for how recipients should treat mail that originates from locations not listed in the SPF.
Domain Keys Identified Mail (DKIM)
DKIM is another tool to reduce mail abuse and address spoofing. DKIM utilizes public key cryptography to add electronic signatures to an email, which allows a recipient to know if certain elements of a message have been forged or changed in transit (e.g. that “from” header).
Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC builds on the ideas of SPF and DKIM to prevent direct domain spoofing. DMARC adds layers of reporting to SPF and DKIM so that domain owners can learn about legitimate and forged emails associated with their domain, as well as publish a policy surrounding how to handle messages that fail authentication.
End-to-End Email Encryption
All of the above security techniques are ones that your email provider and your recipient’s email provider have to implement in order for them to be useful. If either side doesn’t implement these protections, your security is significantly reduced. Fortunately, you have an alternative — end-to-end encryption or E2EE. Unfortunately, implementing it is hard.
End-to-end email encryption has existed for decades, yet you’ve probably never used it. Why? Here’s the short version.
- You can create a certificate to receive encrypted emails, but you’ve got to tell all the people that send you email to use encryption too.
- That encryption being used by senders and receivers has to be compatible.
- And all recipients have to know how to send all other recipients encrypted emails, or there is no point to using the encryption.
As it’s unlikely that you’re sending or receiving emails only from people you know personally, this makes it almost impossible to use and rather pointless.
But you could still do it though, for critical emails, and the two most commonly accepted ways to encrypt email are Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME).
Pretty Good Privacy
PGP was developed in 1991 by Phil Zimmerman, and utilizes public key cryptography to sign and secure text-based communications. Here’s what he used. A PGP user (Alice) creates a public and private key pair. Alice distributes the public key to everyone so that they can send her encrypted messages. Another PGP user (Bob) does the same thing. When Alice and Bob send each other encrypted messages, they use the public key of the recipient to encrypt the message, and use their own private key to sign the message.
This allows Alice and Bob to know who sent the message and be sure that only the person they sent it to can read it. The message is usually sent as all text using ASCII armor, which, as techopedia so simply puts it, basically involves encasing encrypted messaging in ASCII, so they can be sent in a standard messaging format such as email. Otherwise, that message would be gibberish to you.
S/MIME
S/MIME is most often implemented using what’s called an X.509 hierarchical public and private key structure, in which the key pairs are issued by an organization instead of being individually generated by a user. These keys are then used when creating a message, using something called Cryptographic Message Syntax, which is used to digitally sign, digest, authenticate or encrypt forms of digital data. The resulting encrypted data is then placed in the email using the MIME format. Key and message exchange using S/MIME occurs in the same way as with PGP.
If all of this sounds complicated, it is. If it sounds difficult or even impossible to achieve, it probably is, at least at the moment. This is why, even today, end-to-end encryption is rarely used for a commonly used mode of communication like email.
Where do we go from here?
You could go back to faxing or physically mailing sensitive information to your peers —both of those are point-to-point communications and provide more security than email. You’d still run into problems. Fax communications are not encrypted, and the USPS et al can always open things you send.
Another option is to use a communication platform like Silent Circle (which comes at a cost), or an encrypted chat program such as Signal or WhatsApp. These privacy-focused communications applications usually attempt to implement a concept known as Forward Secrecy. The idea is that, even if someone that has bad intent cracks a specific message, it does not risk the contents of any other message. The disadvantage of a system like this is that communications often gets bound to a single device, making access to the information more difficult. These applications also often lack the proper auditing that a corporate environment might desire, which makes them problematic in legal disputes.
But there is hope. Recently, providers like ProtonMail have made an appearance, hoping to offer easier ways to send and receive encrypted emails, but these often force people to abandon their existing mail provider, making them not ideal solutions for adding encryption to email.
The reason to care about this is not just at the individual level, and any embarrassment or damage you might suffer if your email was leaked, but also because there are regulations in the US regarding the sharing or transmission of Personally Identifiable Information or PII, especially by organizations.
We have a comprehensive whitepaper on it here. Have a look, it tells you exactly what you can send or not send over an unsecured system like email, and what laws you are violating if you do send someone else’s PII over email, and whether you’re putting your company and yourself at risk every time you send this kind of information.
So what should you do? Well, until things like SPF, DKIM, and Secure Transport are 100 percent adopted, or you have access to an end-to-end encrypted information system like Biometrica’s SSIN, the Security & Surveillance Information Network, if you’re transmitting critically sensitive data over email, walk it over, take a chance with snail mail or a fax, remember to wipe that PII data off the fax (otherwise, you might probably end up breaking the law in multiple states), or just avoid it.
(The author is Biometrica’s Director of Project Architecture, he has an engineering Masters in communication networks)