A recent vulnerability in the DomainKeys Identified Mail (DKIM) protocol allowed attackers to forge the authenticity of email messages. What are the practical implications? Can DKIM no longer be trusted for
Requires Free Membership to View
Ask the Expert
Have questions about enterprise information security threats for expert Nick Lewis? Send them via email today! (All questions are anonymous.)
DomainKeys Identified Mail is designed to cryptographically sign the From address in an email,
giving users the option to only receive signed email from legitimate providers. The recently
publicized vulnerability in DKIM affected large
email providers and basically allowed attackers to forge DKIM-signed emails from the vulnerable
providers. Email systems not using DKIM are vulnerable to the same issue of forged emails, but this
vulnerability is particularly dangerous because of the element of trust involved with DKIM. Forged
DKIM emails could be more effectively used as part of a phishing or social engineering attack than
unsigned emails because they look more legitimate.
A classic problem in cryptography involves vulnerabilities arising in the implementation rather
than in the cryptography itself. This vulnerability is found in the implementation of the protocol
by the email providers, not in the DKIM protocol. These email providers used test or weak signing
keys for the DKIM certificates in violation of the DKIM RFC. The weak signing keys used by these
email providers stand in contrast with other areas of PKI that have stopped using certificates of
less than 1,024-bit keys. Using test keys is like using a self-signed certificate on a website
where a user is prompted with a pop-up asking the user if they want to trust the website. Email
systems should never be configured to trust test certificates.
DKIM can still be used for email authentication, but enterprises should verify that the certificates
in use for DKIM are 1,024 bits or greater, signed by a generally trusted certificate authority, and
that their email systems are configured to not use or accept test certificates.
This was first published in April 2013
Security Management Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation