Prototyping a Lightweight Trust Architecture to Fight … · Prototyping a Lightweight Trust Architecture to Fight Phishing David Chau 6.UAP Final Report 16 May 2005 Abstract

Prototyping a Lightweight Trust

Architecture to Fight Phishing

David Chau6.UAP Final Report

16 May 2005

AbstractLTA is a lightweight trust architecture that fights phishing attacks by authenticating

e-mail messages. LTA uses separable identity-based ring signatures, which are moreattractive than traditional digital signatures for e-mail signing. Because the signaturesare identity-based, users do not need to generate keys ahead of time. And because thering signatures are repudiable, users do not need to adapt to having every message theysend be binding.This paper describes a complete implementation of LTA. Our prototype includes a

keyserver that supplies secret keys to users, a DNS server that serves a master public key,and an e-mail client that can sign messages and verify signatures. These components usethe message-processing functions and cryptographic primitives that we implemented.Our prototype demonstrates that LTA is a feasible and practical system for authen-

ticating e-mail and for fighting phishing attacks.

Contents

1 Introduction 31.1 The phishing problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Existing solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Separable identity-based ring signatures . . . . . . . . . . . . . . . . . . . . 61.4 Lightweight trust architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Implementing LTA 82.1 The DNS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 The keyserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 E-mail client integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Message processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Cryptographic primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Analysis and possible improvements 163.1 Key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Messages to mailing lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Implementation improvements . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Conclusion 19

References 21

David Chau 6.UAP Final Report 16 May 2005

Acknowledgments

I want to thank Ben Adida, who supervised my work in building this prototype. Ben was a

wonderful source of insight and encouragement. For the prototype, Ben himself implemented

the cryptographic functions and integrated LTA into Rmail, and he gave me a lot of help

in implementing the other components.

I also want to thank Susan Hohenberger and Professor Rivest, who also worked

with us on LTA, and who also supported me with encouragement and feedback.

Finally, I owe a great deal of gratitude to my friends, who had to put up with my

complaints about my workload, and who helped me get through a very long and tiring

semester.

2


1 Introduction

Phishing is a technique attackers use to trick victims into revealing sensitive information.

The phisher masquerades as someone (such as the victim’s bank) who can legitimately ask

for the information, and convinces the victim to divulge it. As companies use the Internet

more and more for legitimate communications with customers, phishers are finding more

and more opportunities to exploit those customers as well.

At the heart of the phishing problem is the fact that most of the communications

sent over the Internet are unauthenticated. With e-mail, it is trivial for anyone to send

a message pretending to be someone else. Many schemes have been proposed to provide

the needed authentication, but most of them suffer from two problems. The first is that

they require significant infrastructure. Digital signatures on e-mail messages, for example,

require that the recipient have some way to verify that the key that generated the signature

actually belongs to the claimed sender of the message. The second problem with many of

the existing authentication schemes is that the authentication they offer is too strong. Most

users have not considered the consequences of having every message they send be provably

traceable back to them, but that is exactly the guarantee that common digital signature

schemes offer. Therefore, many of the existing authentication schemes are both too weak,

in the sense that they leave the key management problem to another layer, and too strong,

in the sense that they provide authentication stronger than most users are accustomed to.

To address both of these shortcomings, [1] proposes a solution that combines re-

pudiable identity-based signatures with a lightweight key infrastructure that piggybacks on

DNS. This combination, called a lightweight trust architecture (LTA), offers a practical way

to improve the accountability of e-mail messages.

This paper describes the design and implementation of a prototype of LTA. To

demonstrate the feasibility of LTA, we built a complete implementation, from the keyserver

that supplies the signing keys for the users to the e-mail client that signs and verifies

messages.

The paper begins with an examination of the existing solutions for e-mail au-

thentication, and then proceeds to introduce the new LTA signature scheme and the key-

3


From: Support PayPal <[email protected]>

Reply-To: [email protected]

To: [email protected]

Subject: Please Restore Your Account Access

Date: Sun, 3 Apr 2005 15:57:28 -0400

Dear PayPal Member,

Recently there have been a large number of identity theft attempts targeting

PayPal customers. In order to safeguard your account, we require that you

confirm your PayPal details (Credit Card information and login/password for

PayPal login , if you have).

This process is mandatory , and if not completed Within the nearest time your

account may be subject to temporary suspension.

To securely confirm you PayPal details please follow the link below :

https://www.paypal.com/cgi-bin/webscr?request=Reactivate

Thank you for prompt attention to this matter and thank you for using PayPal !

PayPal - Fraud Center

1-800-PayPal.

[email protected]

Do not reply to this e-mail as it is an unmonitored alias

Figure 1: An example of a phishing e-mail. It is interesting to note that many phishersuse the threat of identity theft to steal their victim’s personal information. The link in themessage looks like it would take the user to PayPal, but clicking it would actually bring theuser to http://218.57.129.20/manual/update/webscr/index.html.

distribution infrastructure. It then describes each of the components involved in our im-

plementation of the LTA prototype, presents an analysis of the implementation, and finally

discusses possible enhancements for future work.

1.1 The phishing problem

Phishing attacks have been growing in frequency and sophistication. The Anti-Phishing

Working Group reports that the number of phishing sites is growing at 28% per month. In

addition to luring users to divuldge financial information on counterfeit websites, attackers

are also using phising to install keyloggers and other malicious software on the victims’

computers [3].

4


Although many Internet users are smart enough to ignore obviously fraudulent

e-mails, and more are learning to be wary of anything that arrives in their inbox, phishers

have been able to design increasingly convincing messages to draw in victims. A professional-

looking e-mail and a well-designed website that closely mimics the legitimate site will fool

many users. If those techniques are not enough, phishers also have at their disposal a variety

of methods to hide or obfuscate URLs to trick the more knowledgeable users. The problem

is exacerbated by the fact that some companies do in fact send legitimate messages that

link to sites hosted on suspicious-looking URLs.

There have been many attempts to add authentication to e-mail to make it more

secure, but they have met with only limited success.

1.2 Existing solutions

The earliest attempts to fight spam and phishing were to close open relays, to prevent

attackers from routing their mail through unaccountable machines [21]. Some servers also

began to require user authentication [20] before allowing mail to be sent through them.

These measures have had only limited impact, however, because the attackers simply moved

to machines that remained open. Recently, attackers have also begun to send their e-mail

through the hijacked home computers of users with broadband connections.

A stronger form of authentication is to validate the domains that messages come

from. SPF [26] and SenderID [25] check that messages claiming to come from users on

a certain domain actually come from computers authorized to send messages from that

domain. (SPF checks the envelope headers, while SenderID also checks the message head-

ers.) Many domains have enabled SPF/SenderID, but these technologies have several major

shortcomings. One of the biggest problems is that they make it difficult for users to send

e-mail when they are connected from other networks. They also prevent automatic e-mail

forwarding unless special provisions have been made to handle it.

DomainKeys [8] is another attempt to authenticate the domain messages originate

from. DomainKeys offer stronger authentication than SPF/SenderID by digitally signing

messages with the secret keys of domains. DomainKeys is even more restrictive for users

5


because individual users obviously cannot be given the domain’s secret keys, and hence

cannot sign their own e-mails. All the e-mails they send must be routed through their

domain’s servers.

PGP [5] and X.509 [19] empower individual users to sign their e-mails. However,

for these two systems to work, users need to first generate keys and have them certified.

Unfortunately, this requirement asks for too much effort from end-users; to date, neither

technology has been widely adopted.

Looking at the shortcomings of the existing solutions, it is apparent that an im-

proved solution should allow individual users to sign their e-mails, but place the burden of

key management on the e-mail service providers. The new solution should be quick and

transparent to users, and require little setup before users can begin sending and receiving

e-mail. LTA fulfills these requirements.

1.3 Separable identity-based ring signatures

There are two main problems with existing digital signature schemes for e-mails. The first

is that they require a lot of infrastructure to associate the keys with the users: PGP needs

the web of trust to work, and X.509 needs the centralized certificate authorities. The second

problem is that digital signatures are stronger than most users are accustomed to: users

comfortable with the current unauthenticated e-mail system will want their messages to

continue to be deniable. LTA addresses both of these concerns with separable identity-

based ring signatures (SIBR).

Identity-based signatures means that the public key for a user is essentially their

e-mail address. The public key is an ID string that consists of the user’s e-mail address,

an expiration date, and some other metadata. Thus, to verify a signature, a recipient just

needs to know this ID string and the master public key for the sender’s domain. The

recipient does not need to go through the trouble of looking up the sender’s public key and

establishing its trust before verifying signatures.

Separable signatures means that different users can use different parameters, or even

completely different algorithms, for their signature schemes. Some identity-based signature

6


schemes require every user to use the same system. This inflexibility makes adoption more

expensive because e-mail providers cannot reuse the public-key infrastructure they have

already deployed.

Ring signatures enable repudiability. A ring signature proves that some member of

the ring signed a message, but does not indicate which one. A ring with two members, the

sender and the recipient, makes the signature repudiable: the recipient knows the message

must have come from the sender, since the recipient did not sign it, but the recipient cannot

prove to anyone else that the sender wrote the message, since the recipient could have

generated the signature too.

1.4 Lightweight trust architecture

The lightweight trust architecture uses separable identity-based ring signatures to authen-

ticate e-mail and to fight phishing.

LTA distributes the master public key for each domain through DNS. To sign a

message, the e-mail client uses the sender’s secret key along with the recipient’s public key

to generate the signature. The recipient’s public key is derived from the recipient’s e-mail

address and the master public key for the recipient’s domain. Senders receive their secret

keys from a keyserver, which generates them using the master secret key corresponding to

the master public key. The users’ secret keys are delivered to their inbox.

LTA was designed to make spoofing as difficult as gaining access to the users’ e-mail.

Thus, it is acceptable to distribute master public keys through DNS, and to send the users’

private keys to their inboxes, because if an attacker can compromise DNS or read the users’

mail, then the e-mail system itself has already been compromised, in which case LTA would

be pointless anyway.

7


DNSserver

Keyserver

Messages

Message-processingfunctions

Cryptographicprimitives

E-mailclient

Figure 2: This diagram illustrates the interactions between the different components in theLTA implementation. The e-mail client receives secret keys from the keyserver, and e-mailmessages from the user and from the outside world. Secret keys are saved to local storage,and messages are passed to the message-processing functions. The message-processing func-tions use the cryptographic primitives and the master public keys from DNS to generateand verify signatures.

2 Implementing LTA

A complete implementation of LTA consists of three components:

• the master public key for a domain is hosted on its DNS server,

• the keyserver issues secret keys to users on request,

• and the user’s e-mail client is responsible for signing and verifying messages, and for

managing the secret keys the user receives.

Each of these components depends on lower-level functions in the LTA implementation.

Key generation, signing, and verifying use cryptographic primitives. The e-mail client uses

message-processing functions to prepare messages for signing and to put received messages

into the proper form for verification.

In our prototype, we decided to implement the low-level cryptographic and message-

processing functions in C/C++, and the keyserver in Python. Implementing the lower-level

functions in C/C++ would allow us to package them up as a library that could be directly

linked into the other components. However, we discovered that, for our prototype, it was

easier to build the lower-level functions as standalone executables, and communicate with

them through their standard inputs and outputs. Eventfully, we hope to fulfill our original

8


goal and offer a library that other implementors can use to add LTA capabilities to their

own programs.

2.1 The DNS server

The master public key for a domain is distributed through DNS. Since DNS already offers a

moderately secure infrastructure for distributing small amounts of data to a wide audience,

it makes a good vehicle for delivering LTA master public keys.

The LTA master public key is stored as a TXT record on the DNS server. Borrowing

the technique from DomainKeys [8], which stores the public key under the _domainkey

subdomain of a domain, we store the LTA master public key under the _lta subdomain.

Therefore, the master public key for example.net would be stored as a TXT record in

_lta.example.net.

In order to help LTA get along with other systems that might also need to store

TXT records in DNS, the master public key is identified by the “LTA1” prefix (for LTA,

version 1). Thus, the complete TXT record has the format:

LTA1 mpk=〈base-64 encoding of the MPK 〉 policy=〈key-issue policy for the domain〉

Because DNS responses are usually sent by UDP, this entire TXT record should

be kept under 512 bytes, the largest size that a UDP packet can be. Many routers on the

Internet can pass larger UDP packets (or they can break the oversized UDP packet up into

smaller fragments), and many hosts are configured to fall back to TCP for DNS when UDP

packets are not big enough, but the TXT record should still be kept under 512 bytes if

possible: most DNS servers only cache responses up to 512 bytes long, so a longer master

public key will defeat the caching mechanisms that come for free with DNS.

Key length was not a problem in our prototype. If it does become a problem, one

possible solution is to strip the meta information from the master public key. Logically, the

master public key might include information like the domain it is for. This meta information

is not strictly necessary, and can be removed from the copy of the master public key that

is stored in DNS.

9


For our prototype, we implemented functions to retrieve the master public key

from DNS and to decode the key. We then set up a MaraDNS [18] server, generated a

master public key, and manually added the key to the server. (We do not yet have a tool to

automatically put keys into DNS.) We confirmed that our implementation correctly obtains

the master public key from DNS.

2.2 The keyserver

The keyserver uses a domain’s master secret key to generate secret keys for the individual

users. In practice, the provider of the e-mail service for a domain would also operate the

keyserver.

When a user needs a secret key to sign messages with, the user contacts the keyserver

and requests a key. The keyserver makes sure that the user has an account with the e-mail

provider, then sends the key to the user. Since the goal of this LTA is to secure e-mail

communications, it makes sense for the secret key to be delivered to the user’s e-mail

address: if an attacker has access to the user’s mailbox, then chances are that the attacker

has fully compromised the user’s account, in which case forged e-mails will be just one of the

user’s worries. To prevent the secret key from being intercepted in transit while it travels

from the keyserver to the user’s inbox, the keyserver can run on the same machine as the

mail server, and write the secret key directly into the user’s inbox, or the keyserver could

use some secure encrypted channel to deliver the key to the user’s inbox.

To make it easy for users to request keys, our prototype implemented the keyserver

as a website. Users simply go to the website, supply their e-mail address, and the keyserver

will generate their secret key and mail it to them.

In addition to the user’s e-mail address, the other parameter that the secret key is

based on is an expiration date. Users normally receive secret keys that are valid for, say, a

week or a month. They use this key to sign all their outgoing messages. However, because

the signature is a ring signature, the recipient’s public key is also needed to compute the

ring. Since the sender has no idea about what keys the recipient has requested, and hence

no idea about what expiration dates they have, the sender just picks the current date.

10


Figure 3: The LTA keyserver, accessible as a website, allows users to request secret keys.The keyserver generates the secret key, and sends it to the address supplied.

Therefore, in order to preserve repudiation, it must be possible for the recipient to request

keys with arbitrary expiration dates as well, so that the recipient can forge messages. Most

likely, the recipient will never actually request such a key for forgery, but the mere fact that

the recipient could have received such a key is enough for repudiation.

The keyserver does not keep any records of who has requested secret keys. This

policy helps preserve the repudiability of LTA signatures.

We implemented our prototype keyserver in Python, using the CherryPy web devel-

opment framework [6]. The keyserver website presents a simple form for the user to supply

an e-mail address and an expiration date. The keyserver generates a secret key with these

parameters, and sends the key to the supplied address by e-mail. The message containing

the key has a special header, X-LTASecretKeyIDString, to help e-mail clients recognize the

key.

2.3 E-mail client integration

The user’s e-mail client is responsible for generating signatures on the messages that the

user sends, and for verifying the signatures on the messages that the user receives. In

addition, the user’s e-mail client recognizes when it receives a secret key from the keyserver,

and saves the secret key into a keyring for use in future signatures.

11


Originally, we had planned to write Thunderbird [27] plugins to demonstrate e-mail

client integration for our prototype. The plugins would have linked to a library of LTA

message-processing functions that we would have built. However, we found that it was

more expeditious to create standalone executables for the message-level functions, and to

communicate between the e-mail client and the executables using pipes. (This is the same

technique that most e-mail clients use to interface with GnuPG [14]. There is no library

that lets e-mail clients call the message-level GnuPG functions directly; instead, clients just

use wrappers that run the GnuPG executable [15].)

For our prototype, we added LTA capabilities into Rmail [24], an e-mail client that

runs on the Emacs platform. We chose Rmail over Thunderbird for our first implementation

because Rmail offers an easy way to pass messages through command-line programs, whereas

Thunderbird does not. Now that we have the command-line LTA executables ready, it

should be relatively easy to add LTA to any other e-mail client that supports passing

messages through command-line programs.

We configured Rmail to run the LTA signature verification program whenever it

displays a message. We also configured Rmail to run the program that saves secret keys from

the keyserver to disk. Rmail calls these two programs for every message that it displays, but

the programs just ignore any messages that are not intended for LTA processing. Finally,

we configured Rmail to run the LTA signature program on every outgoing message. The

result is an e-mail client that seamlessly integrates LTA. We confirmed that Rmail thus

configured generates and verifies LTA signatures on messages correctly.

2.4 Message processing

The message-processing functions sit between the high-level e-mail client and the low-level

cryptographic primitives. Since the cryptographic primitives just generate and verify sig-

natures on byte strings, it is up to the message-processing functions to properly format the

e-mail messages and to choose the right keys.

Message formatting is an important consideration because e-mail messages can (and

often do) get modified in transit. It is possible to simply treat the message a an opaque bi-

12


nary sequence of bytes, compute the signature on that, and then encode the byte sequence

with some transport-safe transformation like base-64. However, this makes the message

unreadable to anyone without a decoder. Canonicalizing the message will allow it to be

sent as readable text through e-mail, but at the risk of reducing the fidelity of the message.

Therefore, a good canonicalization scheme aims to keep the signature valid for inconsequen-

tial modifications to the message, but needs to detect any changes that alter the meaning

of the message.

Another consideration is whether and how to incorporate the message headers into

the signature. Headers are even more likely than the message body to be modified as the

message travels through the network. (Mail servers may rewrite the From: and the To:

headers, and some mail filters add tags to the Subject: header to indicate message priority,

discussion topic, etc.) Because the identity of the sender and the recipient are important in

LTA, the LTA signature includes those headers.

Overview of existing message canonicalization schemes We examined existing

canonicalization schemes to draw inspiration for how to canonicalize messages for LTA

signatures. Two of the earliest schemes include the ones used in PGP/MIME [9] and

S/MIME [22]. These two schemes convert all the line endings in the message to <CR><LF>,

and sign over just the body of the message. OpenPGP/MIME [10] further requires that

whitespace at the ends of lines be removed. (The difference between the way PGP/MIME

handles trailing whitespace and the way OpenPGP/MIME does it is a source of subtle com-

patibility problems.) Yahoo’s DomainKeys [8] has two canonicalization modes: in “simple”

mode, line endings are converted to <CR><LF>. In “nofws” mode, all the whitespace within

a line are additionally removed. DomainKeys canonicalization also offers the capability of

specifying which headers are included in the signature.

LTA message canonicalization The LTA signature protects the body of the message

and the important headers. It is robust against the common modifications that a message

might experience in transit.

13


The canonicalization scheme first takes the entire MIME-encoded message body—

including attachments if any—and removes the leading and trailing whitespace from it

(newlines count as whitespace). It then replaces any internal sequence of whitespace (again,

including newlines) with a single space character. The message body is now effectively one

long line. Finally, the canonicalization scheme adds the special LTA headers for the sender’s

key ID, the recipient’s key ID, the current timestamp, and the message subject. It is this

canonicalized form that gets passed to the signature function. (Note that this is not the

form that the message is actually sent in; it is just the form that the signature is computed

over.)

This canonicalization scheme keeps the signature valid for most modifications that

e-mail messages face in transit. However, because it reduces linebreaks to spaces, this

scheme is not a good choice if the meaning of the message depends on which lines words

fall on. If the sender needs to make sure that the signature is valid only for the exact text

of the message, then one option is to send the message as an attachment.

We implemented the message-processing functions as command-line programs that would

be called by the e-mail client. The signing program takes newly-composed messages just

before they enter the mail transport system, and adds signatures to them. The input to the

signing program is a complete and properly-formatted e-mail message, with the appropriate

headers in place. The signing program examines the To: address on the message, and

retrieves the master public key for the recipient’s domain through DNS. The program

then computes the recipient’s public key, and using it together with the sender’s secret key,

generates a signature on the canonicalized version of the message. The signing program

adds this signature as a header to the message, along with the other LTA headers, and then

finally outputs the signed message. The e-mail client takes the signed message and injects

it into the mail transport system for delivery.

The signature verification program performs the reverse process. It uses the LTA

headers on the message, which contain contain copies of the sender’s and recipient’s e-mail

addresses that have not been modified in transit, to look up the master public keys for the

sender’s and recipient’s domains. The verification program uses the master public keys to

14


generate the sender’s and recipient’s public keys. The program then re-canonicalizes the

message, and uses the public keys to verify the signature.

The signing and verification programs use the Gmime MIME library [12] to manip-

ulate the messages. They also use an RFC822 address parser library [23] to parse the From:

and To: addresses (because the syntax for these headers allow them to be quite complex),

and a base-64 implementation to encode and decode the signature.

Finally, we also developed a program that recognizes messages containing secret

keys from the keyserver, and saves the decoded keys to local storage.

2.5 Cryptographic primitives

We implemented two different separable identity-based signature schemes. The first imple-

mentation, which uses bilinear maps for Boneh-Franklin keys [4], is a scheme proposed by

Adida, Hohenberger, and Rivest [2] based on a signature scheme by Hess [17]. However, we

found that a patent application on Boneh-Franklin keys may prevent us from distributing

our work. Therefore, we switched our prototype to use a different identity-based signa-

ture scheme, this one proposed by Guillou and Quisquater [16]. The Guillou-Quisquater

signature scheme works as follows:

The keyserver hasMPK = (n, e) andMSK = d, where n, e, and d are respectively

the modulus, encryption exponent, and decryption exponent as would be generated for RSA.

When a user with an ID ∈ Z∗n asks for a secret key, the keyserver supplies IDd. Then the

user’s PK = ID, and SK = IDd.

The user can prove knowledge of SK to a verifier with the following protocol: the

user picks a random r ∈ Z∗n, and sends the commitment t = re to the verifier. The verifier

then gives the user a random challenge c ∈ Z∗n, and the user responds with s = r ·SKc. The

verifier accepts if se = t ·PKc. The Fiat-Shamir heuristic [11] turns this proof-of-knowledge

protocol into a signature scheme: to sign a message m, the user assumes the verifier’s role as

well, supplying a challenge based on the commitment and the message. Thus, the signature

is σ = (t, H(t, m), s), where H is a hash function.

15


Using this signature scheme, a sender can sign messages non-repudiably. To make

the signature repudiable, the sender needs to turn it into a ring signature, with the ring com-

posed of the sender and the recipient. In our prototype, all parties use Guillou-Quisquater

signatures, but the sender and the recipient may be in different domains with different mas-

ter keys. Hence, we need to construct a “medium separable” ring signature, as described

in [2]. To construct the ring signature, the sender first forms a“fake” signature for the recip-

ient R, by choosing a random challenge cR and a random response sR, and by calculating

the commitment tR = (sR)eR/(IDR)

cR . The sender S then forms a “real” signature for the

sender using the sender’s secret key, with a commitment tS = (rS)eS (where rS is randomly

chosen), a challenge cS = H(tR, tS , m) − cR, and a response sS = rS · (SKS)cS . The new

ring signature is thus σ = (tR, cR, sR, tS , cS , sS , H(tR, tS , m)).

To verify the signature, the recipient checks that (sR)eR = tR · (IDR)

cR , that

(sS)eS = tS · (IDS)

cS , and that cR + cS = H(tR, tS , m). If the signature checks out,

then the recipient can be sure that the sender had to have known at least one of SKR or

SKS .

We implemented these signing and verification functions in C++, using the GMP

library [13] for large-integer support. We chose SHA-256 for the hash function H (we sim-

ply concatenated multiple arguments to H), and used the Crypto++ [7] implementation of

SHA-256. After combining these cryptographic functions with the message-processing func-

tions and integrating the result into Rmail, we verified that our prototype implementation

generated signatures correctly, and that it accepted valid signatures and rejected invalid

ones.

3 Analysis and possible improvements

We developed a complete implementation of LTA. Our prototype successfully demonstrates

every step of LTA, from requesting secret keys from the keyserver to signing and verifying

messages. The prototype shows that LTA is a feasible and practical system for authenti-

cating e-mail.

16


In our prototype, there were a few issues that we did not focus on. These issues

will need to be addressed to turn LTA into a production-ready system that can be deployed

in the real world.

3.1 Key management

The first issue is to further develop the mechanisms and policies for key handling. In the real

world, users and e-mail service providers will want to have additional semantics on LTA-

signed messages beyond just whether the signature is mathematically good or bad. For

example, how strictly does the e-mail service provider check the identity of a user before

issuing the user a secret key? What does it mean if a domain participates in LTA, but

a message from a sender in that domain is not signed? To whom does the provider issue

secret keys, and what does having a secret key mean? For example, does having a secret

key for mit.edu mean that the key holder is an authorized representative of MIT (e.g.,

the Registrar), or just that the key holder happens to have an MIT e-mail address (e.g., a

random student trying to steal personal information)? [1] presents mechanisms for dealing

with some of these issues, such as adding a policy field to DNS to indicate how a domain

uses LTA.

Another interesting problem is how to use LTA when only a few domains have

deployed it. To promote adoption, [1] proposes that domains that have deployed LTA could

issue secret keys to users whose domains have not yet deployed LTA. This strategy raises

certain questions as well. There are the semantic questions again of what it means to have

a secret key from a certain domain, if the user is not even in the domain. In addition,

enabling “foreign” secret keys creates a new problem for users, who now cannot just look at

the e-mail address to determine which domain to get the master public key from.

Finally, we need to look at the key handling mechanisms and make them more

convenient and secure. Our prototype simply sends the secret keys to users by e-mail,

creating the possibility that the key could be intercepted in transit. A better system would

write the key directly into the user’s inbox. Also, we would want to create other channels

for requesting keys besides just having the user visit a website. It would be nice if the user

17


could click on a button in an e-mail client to obtain a key, for example. This capability

would require an interface to the keyserver that is designed for programs to use instead of

humans.

3.2 Messages to mailing lists

Signing messages destined for mailing lists presents interesting challenges. If the sender

simply treats the mailing list as a normal recipient, and computes a ring that includes

the sender and the mailing list, the sender would lose repudiability, since mailing lists are

unlikely to compose messages. (And often, a sender has no way to tell whether an address

belongs to a single user or to a mailing list.) The other solution of computing a separate

ring signature for every recipient on the mailing list is cumbersome, and the sender may

not have access to the list of mailing list members.

One possible solution that [1] proposes is evaporating keys: the sender (or the

sender’s keyserver) would publish the secret keys used for message signing at periodic inter-

vals. Once the secret key is published, then any messages signed with it become deniable.

Evaporating keys add their own challenges, however. For example, before the key expires,

someone could submit the signed message to a timestamping service, thus proving that only

the sender could have signed it. Nonetheless, this limited repudiability may be good enough

for users who send messages to mailing lists.

3.3 Implementation improvements

The goal of the prototype was to demonstrate what could be done with LTA, rather than

building a polished end product. Nevertheless, our experience developing the prototype

gave us some ideas of what we can do to enhance the implementation.

One item that can be improved is the message formats. Currently, we simply sign

the message body and some key headers, and add the signature as another header to the

message. As more features are added to the system in the future, we might want to include

more metadata with the signature. It may make sense to develop a MIME type for the

signature, and to include the signature object as a MIME entity in the message rather that

18


just as a header. A similar argument holds for the secret keys, which are currently sent

simply as base-64 encoded strings in bodies of messages from the keyserver. XML may also

offer a useful way of encapsulating signatures and secret keys.

Another avenue for improving the implementation is better integration with e-mail

clients. Although piping messages to standalone programs works, integrating LTA more

tightly into the e-mail client will improve the user experience.

Finally, as an alternative solution, we could move the work of signing and verifying

messages to the mail servers, thus alleviating the need to modify the users’ clients at all.

When a user sends a message, require the user to authenticate to the mail server, and then

let the mail server generate the signature. On the receiving end, the mail server performs

the signature verification, and tags the received messages with an indicator of whether the

signature is valid or not. Deploying LTA at the server level instead of at the client level

will probably speed up adoption, since it requires no effort at all from the users. In fact,

because the mail servers would automatically drop messages with invalid signatures, users

would not even need to be trained about e-mail authentication. It also has the advantage

of rejecting invalid messages immediately, so that they do not waste storage and bandwidth

traveling to the recipient.

4 Conclusion

We developed a prototype of a lightweight trust architecture that can be used to help

fight phishing attacks. LTA has a number of desirable features that make it particularly

suitable for this purpose. It uses the existing DNS infrastructure as a decentralized way to

distribute keys, neatly sidestepping the problem of building a web of trust or a certificate

authority hierarchy that is necessary for traditional signature systems. It puts the burden

of key generation on the e-mail service providers instead of on the end-users, which from

experience makes it more likely to be adopted. It can use completely different identity-based

signature schemes for different domains, thus allowing domains to reuse signature schemes

they may already have in place. It requires only small modifications to e-mail clients, or

even none at all if the signing and verification are performed by the mail servers. And

19


finally, it offers repudiable signatures, so that users can send messages with the level of

accountability that they are comfortable with now.

A widely-deployed lightweight trust architecture would have more uses than just

fighting phishing. A good sender authentication system would help in reducing spam as

well. Other applications might include authenticated instant messaging, and authentication

for software updates.

We should note, of course, that LTA is just one component in the effort to eliminate

phishing. LTA lets recipients be sure of the identities of the senders they receive messages

from. However, other mechanisms—both technological and social—will be needed to help

the users decide whether to trust the sender in the first place. Additionally, LTA can only be

as secure as the underlying technologies it depends on, such as DNS and the e-mail system.

As LTA becomes more widely used, it will be important to make sure the underlying systems

are secure as well.

Phishing attacks have made users wary of e-mail and have reduced the value of

electronic communications. Deploying LTA will help restore the users’ trust in the Internet.

20


References

[1] B. Adida, S. Hohenberger, R. Rivest, “Fighting Phishing Attacks: A Lightweight TrustArchitecture for Detecting Spoofed Emails,” to be published, 2005.

[2] B. Adida, S. Hohenberger, R. Rivest, “Separable Identity-Based Ring Signatures: The-oretical Foundations for Fighting Phishing Attacks,” to be published, 2005.

[3] Anti-Phishing Working Group, “Phishing Activity Trends Report,”March 2005, avail-able from http://www.antiphishing.org/.

[4] D. Boneh, M. Franklin, “Identity-Based Encryption from the Weil Pairing,” SIAMJournal of Computing, vol. 32, no. 3, 2003, 586–615.

[5] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, “OpenPGP Message Format,” RFC2440, November 1998.

[6] CherryPy, http://www.cherrypy.org/.

[7] Crypto++ Library, http://www.eskimo.com/~weidai/cryptlib.html.

[8] DomainKeys, http://antispam.yahoo.com/domainkeys.

[9] M. Elkins, “MIME Security with Pretty Good Privacy (PGP),” RFC 2015, October1996.

[10] M. Elkins, D. Del Torto, R. Levien, T. Roessler, “MIME Security with OpenPGP,”RFC 3156, August 2001.

[11] A. Fiat, A. Shamir, “How To Prove Yourself: Practical Solutions to Identification andSignature Problems,” Advances in Cryptology—CRYPTO ’86: Proceedings, LectureNotes in Computer Science, vol. 263, 1987, 186–194.

[12] Gmime, http://spruce.sourceforge.net/gmime/.

[13] The GNU MP Bignum Library, http://www.swox.com/gmp/.

[14] The GNU Privacy Guard, http://www.gnupg.org/.

[15] GnuPG Made Easy (GPGME), http://www.gnupg.org/(en)/related_software/gpgme/index.html.

[16] L. Guillou, J. J. Quisquater, “A ‘Paradoxical’ Identity-Based Signature Scheme Re-sulting from Zero-Knowledge,” Advances in Cryptography—Crypto ’88: Proceedings,Lecture Notes in Computer Science, vol. 403, Springer-Verlag, 1990, 216–231.

[17] F. Hess, “Efficient Identity Based Signature Schemes Based on Pairings,”Selected Areasin Cryptography: 9th Annual International Workshop, 2002, Lecture Notes in Com-puter Science, vol. 2595, Springer-Verlag, 2003, 310–324.

[18] MaraDNS, http://www.maradns.org/.

[19] R. Housley, W. Polk, W. Ford, D. Solo, “Internet X.509 Public Key Infrastructure:Certificate and Certificate Revocation List (CRL) Profile,” RFC 3280, April 2002.

21


[20] J. Meyers, “SMTP Service Extension for Authentication,” RFC 2554, March 1999.

[21] Open Relay Database, http://www.ordb.org/.

[22] B. Ramsdell, ed., “S/MIME Version 3 Message Specification,” RFC 2633, June 1999.

[23] RFC822 Address Parser Library, http://cryp.to/librfc822/.

[24] Rmail, http://www.gnu.org/software/emacs/manual/html_node/Rmail.html.

[25] Sender ID, http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx.

[26] Sender Policy Framework, http://spf.pobox.com/.

[27] Thunderbird, http://www.mozilla.org/products/thunderbird/.

22

Documents

Prototyping a Lightweight Trust Architecture to Fight … · Prototyping a Lightweight Trust Architecture to Fight Phishing David Chau 6.UAP Final Report 16 May 2005 Abstract