DKIM, or DomainKeys Identified Mail, is a protocol created to allow mail services to verify the authenticity of the mail messages they deliver. Last week, it was reported that some popular mail services, including Google’s and Yahoo!’s implementation of the DKIM protocol, was not secure enough. When exploited, the DKIM security vulnerability allows attackers to forge critical mail components, including a mail sender’s address, while the mail is still considered to be authentic by the mailing system.
In this column, I will analyze the technical details of the vulnerability, evaluate the possible implications of the exploit and, finally, point to some general lessons.
Motivation for DKIM
Originally, mailing system and protocols–much like many other important components of the Internet–were not built with security in mind. Therefore, the original implementation had many security flaws. A major one was that the mail sender’s address was not verified. By abusing this loophole, mail criminals, such as phishers and spammers, were able to create fraudulent mail allegedly originating from a trustworthy sender.
DKIM was created to solve mail’s authenticity and integrity issues, such as sender’s address forging. With DKIM in place, the sending mail server cryptographically signs the outgoing mail, including the “FROM:” field. The receiving server can verify the authenticity of the message by comparing the mail contents with the signature.
DKIM was standardized by the Internet Engineering Task Force (IETF) and adopted by many mail related parties. For example, on 2008, Google announced its use of extended anti-phishing methods based on DKIM: “Since 2004, we’ve been supporting email authentication standards including DomainKeys and DomainKeys Identified Mail (DKIM) to verify senders and help identify forged messages… any email that claims to come from “paypal.com” or “ebay.com” (and their international versions) is authenticated by Gmail and — here comes the important part — rejected if it fails to verify as actually coming from PayPal or eBay. That’s right: you won’t even see the phishing message in your spam folder.”
Peeking under DKIM’s hood
You don’t really have to understand DKIM to receive the benefits of its protection, as your mail server is already doing it for you. Therefore, this section is intended only for the pleasure of the ones who enjoy taking a look under the hood to find out how stuff really works.
Here’s a quick DIY recipe for DKIM verification:
First, you would probably have to enable the display of the usually hidden mail headers:
Figure 1 DKIM signature
The mail headers contain the information needed to support the DKIM protocol. The following parameters are denoted in the picture. The “a=” parameter specifying the signing and hashing algorithm used, “d=” and “s=” are the sender’s domain and selector values and “b=” value is the signature itself.
Then, you can fetch the sender’s (in this example, “gmail.com”) public key via a DNS query. You can do so directly or by using a publicly available web tool:
Figure 2: Gmail public key, retrieved via a web tool
Finally, you would have to verify the signature of the received mail (b=ugC…) with the obtained public key, by using the specified algorithm (a=rsa-sha256).
DKIM vulnerability and possible implications
The strength of DKIM protection is directly derived from the strength of the keys used to sign the mail message. If the keys are too weak, i.e., does contain enough bits, attackers can guess the private key and forge the original domain signature. It was discovered that Google used a 512 bit long keys which can be cracked in about 72 hours by using Amazon Web Services. The total cost of the cloud computing used for the task was only $75.
By using the cracked key, the attackers can sign the mail as if it originated from Google and bypass any DKIM based protection systems. The discoverer of the vulnerability demonstrated it by sending a forged, yet properly signed, mail to Google’s co-founder Larry Page allegedly authored by Google’s other Co-founder Sergey Brin. Future abusers of the DKIM system, would probably go after less comical yet more profitable causes, such as phishing and spamming.
As a result, Google had upgraded their key size to 2048 bit and the US-CERT had published a warning about the security of the DKIM system with keys shorter than 1024 bit.
Eternal vigilance is the price of security
The key lesson to be taken from the DKIM incident is that, unlike wine, security does not get better with age. In fact, if left unattended, security quality actually deteriorates over time. New attacks are being discovered every day.
Cryptographic algorithms strong enough for the present, become inadequate over time. In an interview with Wired, mathematician Zachary Harris, who discovered the DKIM short keys problem, told Kim Zetter: “In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever.”
Therefore, system administrators should either keep mending all production systems, including the legacy ones, or strive to delegate the security aspects of production systems to external devices and make sure that these devices are being regularly updated with solutions to new threats.
Related: Best Practices for DKIM Verification