Benlog

crypto and public policy

A Platform of Trust for Email

Filed under: Security & Crypto June 29, 2005 @ 10:03 pm

So, it’s time I begin describing the work my research team (Susan Hohenberger, Ronald L. Rivest, and myself) has been doing to fight phishing attacks (and maybe even spam). Over the next few posts, I’ll describe the building blocks, and eventually piece them together into a solution. Feel free to ask questions in comments or by email.

First, let’s talk about the overall problem and high-level approach.

Email isn’t trustworthy. When you receive email, you have no way to verify the authenticity of the sender’s address. That leads to a number of forms of anonymous spam (the kind you can’t complain about or unsubscribe from), and, most importantly, to phishing attacks, where the sender address is spoofed so as to mislead you into revealing confidential information (like your password). One obvious solution is to find some mechanism to authenticate this sender address. The not-so-obvious part is: how? Though we’ve known how to do digital signatures for more than 20 years, we still don’t have an easy mechanism that is truly deployable on a large scale. Most approaches require establishing a public-key infrastructure, where each user is responsible for generating a personal key and getting it certified. That generally requires significant user education and effort – and in the realm of security, where the payoff is only clear once the damage has been done, that education never happens in time.

A number of people will tell you that, even if you can authenticate an email sender, that’s not enough, because someone could send you email from “b1gbank.com” instead of “bigbank.com” (notice the “1” instead of an “i?”), and though the email will be authentic, you’ll still be fooled. That’s true. Email authentication is not enough to stop phishing and spam. But it is necessary. Not sufficient, but necessary. Email authentication can provide the basic platform of trust for email, much like SSL provides a platform of trust for the web. Once this platform is established, a number of reputation-management systems can be deployed to help users make that final trust decision. But without the platform, there can be no such reputation management. We need a platform of trust to provide basic accountability for email.

So our goal is to provide this platform of trust. We’re not trying to be 100% secure. We’re trying to be “just secure enough” to prevent email-based phishing attacks. Our solution isn’t appropriate for authorizing nuclear missile launches, but of course, most users’ email hardly ever needs to be.

In the end, our solution is very simple: we make it such that, if you want to successfully authenticate your emails as coming from “alice@wonderland.com,” you must be able to receive emails sent to “alice@wonderland.com.” Sound familiar? It should. It’s the same mechanism that numerous web sites use to authenticate you the first time you register for an account or when you lose your password: they just send you an email. Conceptually, our solution is quite similar. At a lower level, it’s much more powerful. We use cryptography to (1) capture Alice’s ability to receive email at a given address and (2) prove to another user, Bob, that she has this ability. And we do it without any extension to SMTP, the mail protocol. Deployment can happen at the client level (upgrade Outlook), OR at the server level (upgrade qmail, sendmail, exchange), which means it’s compatible both with web-based email providers and with mobile users accessing their mail from a heavily-firewalled place like China.

So, to summarize:

  • we need to authenticate emails to provide a basic platform of trust.
  • we’re going to provide this by tying email authentication for an address with the ability to receive emails at that address.
  • our solution requires no significant change, and is deployable today at the client or server level.

In my next post, I’ll describe Identity-Based Signatures, a super-cool crypto concept that is the key (no pun intended) to our solution.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.