Stopping Forged Email 2: DKIM to the Rescue
We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, we learned that generally all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server — as this cannot realistically be forged in any way that would still enable you to receive the message.
In our last post in this series, we examined how SPF can be used to help weed out forged email messages based on validating if a message was sent by an approved server by looking at the IP address delivering the email message to you. We found that while SPF can work, it has many significant limitations that cause it to fall far short of being a panacea.
So — besides looking at the sending server IP address — what else can we do to determine of a message was forged?
It turns out that there is another way — through the use of encryption techniques and digital signatures — to have the sender’s servers transparently “sign” a message in a way that you can verify upon receipt. This is called DKIM.
DKIM – Domain Keys Identified Mail: A Simple Explanation
DKIM stands for “Domain Keys Identified Mail” … or, re-writing this more verbosely, “Domain-wide validation Mail Identity through use of cryptographic Keys”. To understand DKIM, we need to back up for a second and look at what we mean by “cryptographic keys” and how that can be used.
In security, there is a concept called symmetric encryption that everyone is familiar with: you pick a password and use some “cipher” to convert a regular (plaintext) message into an encrypted (ciphertext) message. Someone else who knows the password and cipher can reverse the process to get the regular message back.
Another extremely common (e.g. it is the basis for SSL, TLS, S/MIME, PGP and other security technologies), but more complex method is asymmetric encryption. In asymmetric encryption, one can create a “key pair” … a combination of a 2 keys. A message encrypted using Key 1 can only be decrypted with Key 2 and vice versa. We typically call Key 1 our “private key” because we keep that safe and secret. We are happy to publish “Key 2” to the world.
What does that buy you?
- Signatures: Anything that you encrypt using Key 1 can be decrypted by anyone. But if they can decrypt it, that proves that you sent it (as only you have your secret key and thus “only you” could have encrypted it).
- Encryption: Anyone can use your public key to encrypt a message that can only be opened by you (using your secret key).
DKIM uses the cool feature asymmetric encryption for signing messages. Here is how it works (a hand waving overview that leaves out many details for the sake of clarity):
- Make a Key Pair: The folks in charge of the sender’s servers create a cryptographic key pair
- Publish the Public Key: These same folks publish the public key in the DNS for their domain
- Sign Messages: Using the private key, the sender’s servers look at selected message headers (e.g. the sender name and address, the subject, the message ID) and the message body, they use a cryptographic “hash” function to make a unique “fingerprint” of this info (e.g. so that any change to that info would change the fingerprint). This fingerprint hash is encrypted using the private key and this “fingerprint” as added to the message as a new header called “DKIM-Signature”.
Now, when you receive a message that is signed using DKIM, you know the purported sender, the IP address the message came from and you have this additional “DKIM-Signature.” However, you cannot trust that this signature header is real or has not been tampered with. Fortunately, you do not have to trust it blindly; DKIM allows you to verify it. Here is what happens on the recipient’s side:
- Receipt: The recipient’s inbound email server receives the message
- Get the Signature: The encrypted DKIM fingerprint is detected and extracted from the message headers
- Get the Key: The sender’s purported domain is known; the recipients server looks in DNS to get the sender domain’s public DKIM encryption key
- Decryption: The fingerprint is decrypted using the public key.
- Fingerprint Check: The recipient then uses the message body and the same headers as the sender to make another fingerprint. If the fingerprints match … then the message has not been altered since it was sent.
So, this buys you sender identity verification by:
- We know that the message was not modified since it was sent — so the name and the address of the sender (among other things) is the same as it was when it was sent.
- We know that the message was sent by a server authorized for sending email for the sender’s domain — as that server used the DKIM private key for that domain.
So, through encryption, we have a way to verify that the message was sent by a server authorized to send email fro the sender’s domain … and thus we have a “solid” reason to believe the sender’s identity. Furthermore, this validation does not rely on server IP addresses at all, and thus does not share the weaknesses of SPF.
Setting up DKIM
With DKIM (as with all anti-fraud solutions for email), it is up to the owner of a domain (e.g. the owner of bankofamerica.com) to setup the DNS settings required for DKIM to be checked by the recipients. If they do not do this, then there is no way to verify DKIM and any DKIM signatures on messages will be ignored.
DKIM is set up by adding special entries to the published DNS settings for the domain. You can use a tool, such as this DKIM Generator, to create create your DKIM cryptographic keys and tell you what you should enter in to DNS. Your email provider may have their own tools that assist with this process — as the private key needs to be installed on their mail servers and use of DKIM has to be enabled; we recommend asking your email provider for assistance.
We are not going to spend time on the details of the configuration or setup here; instead we will look at the actual utility of DKIM and where it falls on its face and how attackers can get around it.
DKIM – The Good Parts
Once DKIM has been set up and is used by your sending mail servers, it does an amazing job with anti-fraud…. generally much better than SPF. It also helps ensure that messages have not been modified at all since they were sent … so we can be sure of who sent the message and of what they said; SPF does not provide any kind of assurance that messages were not modified.
Use of DKIM is highly recommended for every domain owner and for every email filtering system.
However, as we shall see next, its not time to throw a party celebrating the end of fraudulent email.
DKIM – Its Limitations
Domain Keys Identified Mail has sone significant limitations in the battle against fraud:
It can be hard to identify and set up all authorized servers
For proper use of DKIM, all servers that send email for your domain must be able to use DKIM and have keys for your domain. This can be difficult if you have vendors or partners that send email for you using your domain or if you otherwise can not be sure that all messages sent will be signed.. In such cases, if you cannot get them to use DKIM, you should have them send email for you using a different domain or a subdomain, so that your main domain can be fully DKIM-enabled and its DNS can tell everyone that DKIM signatures must be present on all messages. E.g. you want to be “strict” with DKIM usage in a way that is hard to do with SPF.
If you cannot be strict, then DKIM allows you to be soft … indicating that signatures may or may not be present. In such cases (like with SPF), the absence of a DKIM signature does not make a message invalid; the presence of a valid signature just makes the message certainly valid. If your DKIM setup is “soft”, forgery is simple.
DKIM checks only the domain name and the server.
If there are two different people in the same organization, Fred@domain.com and Jane@domain.com — either of them can send email legitimately from their @domain.com address using the servers they are authorized to use for domain.com email.
However, if Fred@domain.com uses his account to send a message forged to be from Jane@domain.com — DKIM will check out as “OK” … even if DKIM is set as strict.
DKIM does not protect against inter-domain forgery at all.
Note: using separate DKIM selectors and keys for each unique sender would resolve this problem (and the next one); but this is rarely done.
Same Email Provider: Shared Servers Forgery?
This is a generalization to inter-domain forgery. If Fred@badguy.com and Jane@goodguy.com were using the same email service provider and the same servers, Jane’s goodguy.com domain is setup with DKIM, and the email provider’s servers are also setup to sign messages from @goodguy.com with appropriate DKIM signatures, what happens when Feed@badguy.com logs in to his account and sends a message pretending to be from Jane?
The answer depends on the email provider!
- The provider could prevent Fred from sending email purporting to be from anyone except himself. This would solve the problem right away but is very restrictive and many providers do not do this.
- The provider could associate DKIM keys to specific users or accounts (this is what LuxSci does) … so Fred’s messages would never be signed by valid the “goodguy.com” DKIM keys, no matter what. This also solves the problem.
However, if the provider’s servers are not restrictive in one of these (or a similar way), then Fred’s forged email messages will be DKIM-signed with the goodguy.com signature and will look DKIM-valid.
Legitimate Message Modification
DKIM is very sensitive to message modification; DKIM signature checks will come back “invalid” if even 1 character has been changed. This is generally good, but it is possible that some filtering systems read and “re-write” messages in transit where the “real” message content is unchanged but certain (MIME) “metadata” is replaced with new data (e.g. the unique strings that separate message parts). This breaks DKIM and it can happen more frequently that you might expect.
Good spam filters check DKIM before modifying messages; but if you have multiple filtering systems scanning messages, then the DKIM checks of later filters may be broken by the actions of earlier filters.
DKIM does not really protect against Spam
This is not a limitation of DKIM, but worth noting anyway. All DKIM does is help you identify if a message is forged or not (and if it has been altered or not). Most Spammers are savvy. They use their own legitimate domain names and create valid DKIM (and DPF and DMARC) records so that their email messages look more legitimate.
In truth this does not make them look less spammy; it just says that the messages are not forged.
Of course, if the spammer is trying to get by your filters by forging the sender address so that the sender is “you” or someone you know, then DKIM can absolutely help.
For further DKIM issues and misconceptions, see: 7 common misconceptions about DKIM in the fight against Spam.
How Attackers Subvert DKIM
So, in the war of escalation where an attacker is trying to get a forged email message into your INBOX, what tricks do they use to get around sender identity validation by DKIM?
The protections afforded by DKIM are more significant than those provided by SPF. From an attacker’s perspective, it all comes down to what sender email address (and domain) they are forging. Can they pick an address to construct an email that you will trust that will make it past DKIM?
- If the sender address does not support DKIM at all — the attacker is “all set”.
- If your DKIM is set up as “weak“, then the attacker can send a forged message with a missing DKIM signature and it will look legitimate.
- If the attacker can send you a message from one of the servers authorized by the DKIM for the domain and if that server does not care who initiated the message … but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. E.g. If the attacker signs up with the same email provider as that used by the forged domain and that provider’s servers do not restrict DKIM key usage, then s/he can send an email from those same servers are the legitimate account and have his/her messages properly signed. This makes the attacker’s email look “Good” even if the forged domain’s DKIM records are “strict”.
An attackers options are much more limited with DKIM. S/he can only send fraudulent messages from domains with no or weak DKIM support, or send through non-restrictive shared email servers, or steal the private key used by the sender’s DKIM, or s/he must actually compromise the email account of someone using the same email domain as address that is to be faked.
The situation is better, but not perfect … especially as many organizations leave their DKIM configuration as “weak” as they would rather take a chance on forged email rather than have legitimate messages be missed or discarded due to inadvertent message modification or because they were sent from a server without DKIM.
We will see in our next post how one can use DMARC to combine the best features of DKIM and SPF to further enhance forged email detection…. and where the gaps that attackers use still remain.