1 2 3 4 5 6 7 next »

Johannes Endres, Patrick Koetter

Signing emails with DomainKeys Identified Mail

Cryptography against phishing and spam

Originally, the DomainKeys Identified Mail technology was only designed to dam waves of spam. However, because it detects forged sender addresses, it is actually a phishing cure. Only when combined with the sender's spam reputation does it also reduce the number of Viagra ads in a user's inbox.

Spammers generally like to remain incognito – and not only to avoid the enormous fines they could be made to pay in the US nowadays. Therefore, they tend to dispatch junk emails using forged sender addresses. Phishers who want to lure unsuspecting users to malicious internet pages, where they wangle their passwords, PINs and account details off them, always send their emails out under false colours – after all, their messages must appear to come from a bank, or similar institution, if their tricks are to succeed. Their evil endeavours would be much more difficult if there was a way of making sure that emails really come from those who appear to be their senders. To do this, bona fide senders should confirm the origin of their messages in a way that can be evaluated automatically.

Users can do this themselves by putting a digital signature on all their emails. Every decent email client only requires one click to set up such a PGP (or, today, the equivalent free program GPG) or S/MIME signature. However, even 15 years after PGP was introduced, the number of emails signed by users is negligible.

Therefore, senders must be verified and confirmed by servers. One of the protocols used for this purpose is SPF (originally Sender Permitted From, now Sender Policy Framework). In the DNS, MX records contain the information about which server accepts a domain's emails, and postmasters can likewise simply state which servers send out for this domain in the DNS. If an email with this sender domain is received from a different IP address, the receiving server simply aborts the connection.

Practical use soon reveals one basic problem: if a sender or a mailing list outside of the original sender's domain forwards the email, its server IP and sender address no longer match up. In addition, postmasters need to keep updating the SPF entry in the DNS to match any changes they make to their mail server. Therefore, SPF is currently more likely to mistakenly reject emails than to separate out spam. In 2004, both Yahoo and Cisco developed procedures that combine the best of both ideas: To save users the hassle, a server adds a cryptographic signature which is independent of the server's IP address to every email. The two companies combined their efforts and created the DKIM internet standard in 2007. In the wild, many signatures that comply with the generally compatible, but obsolete, Yahoo system can still be found.

Digital signatures are the bread and butter of cryptography. The signatory creates a pair of keys: what was encrypted using one can only be decrypted with the other. If the sender keeps one key a secret and publishes the other, this method can serve as a signature. What can be decrypted with the public key must have been encrypted with its secret counterpart. If the public key "fits" – successfully decodes the signature – then the message is bound to come from somebody who has the secret key.

To keep emails legible for recipients who can't yet decipher DKIM, the message isn't encrypted in its entirety; a kind of sum total of all the letters, the "hash", is calculated instead. The hash gets added to the message only after it has been encrypted with the secret key. The result of the hash function changes greatly as soon as only small changes are made to the message. Therefore, the signature no longer fits if the message has been tampered with. Now, the crucial idea is to have the sending servers sign emails, not individual users. As long as the postmaster looks after their secret key, this system guarantees that the message came from that server and hasn't been modified. This, for example, prevents phishers from intercepting a genuine bank email and adding a link to their page, to it.

1 2 3 4 5 6 7 next »