DHO is Mostly Confused
Rants from Devon H. O'Dell
Explaining DKIM to Your Grandmother
Email systems have grown increasingly complex since they first appeared in the early 1970s. The growth of the Internet (as measured by users of internet-enabled services) is largely responsible for this complexity. Spam, phishing, and forgery attacks have plagued email users across the world in recent years.
The fundamental problem with modern email systems is that, although we ascribe identity to individual email addresses, that identity is generally not enforced. To this day, it is common to find poorly configured email servers and web email forms that allow malicious users to forge emails.
To understand how this is possible and why it is a problem, we need to understand how email works in the first place.
How does email work?
The internet protocol describing email (called SMTP: Simple Mail Transfer Protocol) functions very similarly to what we now know as “snail mail”. (It turns out that this similarity is very unfortunate). In snail mail, we have two major components: the envelope, and the letter.
The Envelope
The envelope contains addressing information: Who is this letter to? Who did the letter come from? The postal service uses the “To” address, printed on the front-center of the envelope, to get the letter to the right place. Sometimes, something is wrong with this address, and the “From” address (usually printed on the top-left or rear of the envelope) allows the postal service to return the letter to the sender.
If neither of these addresses make any sense, the letter will eventually be destroyed as it can neither be delivered or returned.
.--------------------------------------------------------------------.
| 123 Cherry Lane |
| Silly Town, MD |
| 23456 |
| |
| Some Big Company |
| attn. Legal Department |
| Boston, MA, 12345 |
| USA |
| |
| |
'--------------------------------------------------------------------'
The Letter
A letter from a company to a legal office may not mention names of individuals on the envelope. However, the letter will usually have information embedded in it describing who the letter is individually to, and who individually is responsible for the contents of the letter.
.--------------------------------------------------------------------.
| 123 Cherry Lane |
| Silly Town, MD |
| 23456 |
| |
| 22 February 2013 |
| |
| Lead Council Foo |
| Some Big Company |
| Boston, MA, 12345 |
| |
| |
| Dear Mr. Foo, |
| |
| I am writing to inform you that I stole music published by your |
| company. I might have purchased it later, but you will never |
| know, pighead! Hahaha! |
| |
| Sue me, |
| |
| , __ , __ |
|/|/ \ /|/ \ |
| | __/ | __/ __, __ |
| | \ | \/ | / / _ |
| |(__/o |(__/\_/|_/ /_/ |
| /| |
| \| |
| |
| B. Baz |
| |
| |
'--------------------------------------------------------------------'
What Could Possibly Go Wrong?
The protocol for delivering letters via a postal service requires a large amount of trust. The example letter above is rather inflammatory, and we might have some doubts as to its validity. Consider the following questions:
- Who is B. Baz?
- Does B. Baz exist?
- Did B. Baz write this letter?
- Did Mr. Foo receive the mail, or did someone else?
- Was the letter altered?
We could probably come up with many other questions related to this as well. Fundamentally, these questions boil down to trust. The postal service does not provide us any way to verify that the sender is who they claim to be. It does not provide us with any way to verify that the sender actually wrote the contents of the letter.
For years, people have sought solutions to these problems. We have invented opaque envelopes to prevent people from reading contents. We use better adhesives to prevent tampering (or at least make it obvious if the letter was tampered with).
With hundreds of years of experiencing mail forgery, delivery tampering, and the like, email must have considered these cases, right? Wrong. Email does not solve any of these problems. Why are they problems? Malicious individuals can exploit these issues of trust to send computer viruses or unwanted marketing email (spam). People exploit these issues of trust to send diseases like anthrax, and unwanted marketing mail (coupon books, credit offers, etc.)
Email and snail mail are not so different. But in email, we can do better.
Trusting An Identity Crisis
We have established two problems with email:
- The identity of the sender and recipient of a mail are unknown.
- The contents of the message are not known to be correct.
So, if we are the recipient of a letter (or of an email, for that matter), how do we know who sent it? How do we know what we are reading is what the sender actually wrote?
With regular mail, we rely heavily on context and signatures. Humans are generally pretty good at recognizing visual patterns (and discrepancies in those patterns). If we receive a letter from someone we know, we can make an educated guess as to whether they sent it based on factors like writing style, handwriting, signature, and address information.
Imagine receiving a letter from a friend. This letter is asking you for money. You know your friend is on vacation in the Galapagos Islands, and the signature looks funny. You are probably going to request additional information before you send money to your friend.
Email does not enjoy these same protections. There are no signatures – just addresses. And most people are not technologically inclined. So when King Mubotu emails from Nigeria telling you to send him $50 so he can send you $50,000,000, you do it. I mean, it is King Mubotu, right?! Right!!?
So many people are still unaware of this attack, that it is still successful. Again, the fundamental problem is that identity has not been established, and our normal contextual clues for establishing it are gone. So we fall back to trust. If you follow one rule on the Internet, it should be not to trust anyone unless you have any technical knowledge that would make you think otherwise.
Enter DKIM
DKIM (pronounced “DEE-kim”) allows organizations to claim responsibility for messages they send and guarantee the contents of the messages they send. Senders may also guarantee the identity of the individual responsible for sending the message (although this is not yet widely used).
How does the guarantee work?
In a word: math. DKIM relies on what is called “asymmetric cryptography” (also known as “public-key cryptography”). After a message is received, and before that message is delivered to its destination, DKIM uses a “private key” to create a signature for both the contents of the message, as well as some key headers of the message. This signature is attached to the message.
When the message is delivered to the destination, the destination server asks the sender for a public key to verify that the signature is correct. If the public key allows the destination server to decrypt the supplied signature to the same value it computes as the signature, it can assume the sender is indeed who they claim to be.
(Note that we can only assume that the sender is not lying about who originated the email. If the malicious party is the sender in the first place, we have to trust that they are not lying to us!)
As an analogy, consider a message sent between two corporate offices. The message includes a reference number and a phone number. The receiving office can call the sending office, provide the reference number, and read the message. The sending office can verify that this is in fact correct.
What if someone else answers the phone?
In the hypothetical scenario of a letter sent between two offices with a reference number and a phone number to verify, it is logical to assume that a malicious person could attack the security of the system. The attacker would have to:
- modify the message,
- hijack the phone line,
- impersonate the sending office, and
- lie about the validity of the message.
This is a difficult attack to pull off. But can we pull off the same attack against a DKIM-signed message? Not really.
When DKIM asks for the public key, it either receives the public key or it receives something that is not the public key. If it receives the wrong key, decryption will fail, and the message will appear invalid. If the message appears invalid, we can assume some aspect of the system has been tampered with, and we can try more strict verification of the message (such as an in-person discussion). This case does not break the guarantee made by the DKIM signature, because it can still be validated with the proper key.
If the attacker responds with the valid public key, all they have done is prove that the message was sent unmodified.
But people have hacked DKIM!
To mount an attack against DKIM, you have to own or reconstruct the private key. This has happened before in, for example, the attack against Google in late 2012. In this case, Google used an insecure key size for their private key and the attacker was able to reconstruct the key. The solution? Use a bigger key! Although this seems like a weak argument, the justification for why this works is outside the scope of this article. I do not wish to attempt to explain the complexity of integer factorization in simple terms. (At least not in this article.)
For the time being, this is a fine solution.
Invalidating Keys
If a key is compromised (either because someone obtains the key by “hacking” the sender or because they were able to reconstruct it by brute force), one can simply change the key. The problem with doing this is that once a key is known to have been compromised, it is impossible to guarantee with certainty that a message has not been tampered with. There are two reasons for this:
Inherently, once the key is compromised, someone can forge messages that would have validated with the key. With some clever tricks, it might be possible for an attacker to even forge dates to make it look like the message was sent when the key was valid.
The public key is generally no longer available. Once the private key has changed, the public key must change as well. If both the public and private keys are subsequently lost or forgotten, it is nearly impossible to reconstruct them.
When doing forensics work with DKIM, if the original key was compromised, it is usually not difficult to prove that messages were not forged. Most people lack the skill to forge keys and emails, and the ability to forge dates requires access to both the sending and receiving machines.
Conclusion
Hopefully this is a useful, lucid, and digestable explanation about the security weaknesses inherent to email (and snail mail, for that matter). If you have additional questions, feel free to contact me either via comments or via email.
If you choose email, I hope you are using DKIM! (Edit: or DMARC.)
I am happy to provide consulting services on this topic (for a nominal fee).