A First Step towards the Automatic Generation of SecurityProtocols

��

Adrian Perrigperrig@cs.berkeley.edu

Dawn Songdawnsong@cs.berkeley.edu

Computer Science DepartmentCarnegie Mellon University and University of California, Berkeley

Abstract

This paper describes automatic protocol genera-tion (APG for short), a novel mechanism to gen-erate security protocols automatically. With APG,the protocol designer inputs the specification of thedesired security properties and the system require-ments. The system requirements include a metricfunction which specifies the cost or overhead ofprotocol primitives, which defines an ordering overprotocols with respect to the metric function. Basedon this ordering, APG explores the protocol spaceand outputs the correct protocol which has minimalcost with respect to the metric function, as well assatisfies the security properties and system require-ments.

The APG approach has several advantages overthe current protocol design process. It is fully auto-matic, and hence, more efficient than a manual pro-cess. The protocols generated by APG offer higherconfidence, because they are verified by a powerfulprotocol analyzer. Another significant advantageis that, because APG search through the protocolspace in the order of increasing cost with respect tothe metric function, APG generates correct proto-

�This research was done while the authors were at Carnegie

Mellon University. This publication was supported in part byContract Number 102590-98-C-3513 from the United StatesPostal Service. The contents of this publication are solely theresponsibility of the author and do not necessarily reflect theofficial views of the United States Postal Service.�

This paper appeared in Proceedings of Network and Dis-tributed System Security Symposium, Feb 2000.

cols with minimal cost which ideally suit the systemrequirements. Furthermore, APG is flexible in thesense that it can handle different security propertiesand different system requirements.

To gain experience with APG, we conduct acase study on the automatic generation of two-party, mutual authentication protocols. In oneexperiment, APG generates authentication proto-cols that are simpler than the standard protocolsdocumented in the literature (i.e., ISO standards[Int93]). In another experiment, the automaticprotocol generation generates different protocolswith minimal cost for varying requirements, hencedemonstrating its capability to produce high qual-ity protocols.

1 Introduction

The exponential growth of the Internet and elec-tronic commerce brings not only prosperity, butalso vulnerability. Numerous attacks pose a realchallenge to different aspects of security mecha-nisms. Among these security mechanisms, secu-rity protocols play an essential role. They use cryp-tographic primitives as building blocks to achievesecurity goals such as authentication, confidential-ity, and integrity. New applications and systemseagerly demand security protocols suitable to theirsystem requirements. Unfortunately, designing se-curity protocols is a delicate task and experienceshows that security protocols are notoriously hard

1

to get right [BAN89, Low96]. This naturally raisesthe question whether the current security protocoldesign process is satisfactory. If the answer is no,how can we improve it?

The current process of finding a solution is usu-ally ad-hoc and involves little formalism, and al-most no mechanical assistance. Such a design pro-cess is not satisfactory for the following reasons:

� Error-prone. Security protocols are intricateand attackers are powerful.

– If the designer has limited experience,it is likely that the security protocol isflawed. Evidence shows that even whensecurity protocols are designed with careand examined intensely (even over timeof years), they can still be fundamentallyflawed.

– Due to the lack of formalism and me-chanical assistance, manually designedprotocols often suffer from the factthat they contain undocumented assump-tions. Since the implementation mightnot respect these assumptions the result-ing protocols might be insecure/flawed.

– Without proofs, these protocols cannotgive any guarantee on satisfying the de-sired security properties, and hence de-grade the level of confidence.

� Non-optimal. Such designed protocols maycontain unnecessary operations. Simply be-cause the designer cannot search a large num-ber of candidates, she may not find the optimalprotocol for the given system requirements.Moreover, conservative designers might putunnecessary operations just to play safe.

� Inefficient and Expensive. The current designprocess is often slow. It can be a serious bot-tleneck of the project and severely delay prod-uct development. If the protocol is flawed,high costs might incur, due to forced redesign,update plans, or liability claims.

In this paper, we present automatic protocol gen-eration, APG for short, a mechanism which ad-

dresses these shortcomings. With automatic proto-col generation, the protocol designer specifies thedesired security properties, such as authenticationand secrecy, and system requirements, i.e., sym-metric or asymmetric encryption/decryption, lowbandwidth. A protocol generator then generatescandidate security protocols which satisfy the sys-tem requirements. In the final step, a protocolscreener analyzes the candidate protocols, discardsthe flawed protocols, and outputs the correct proto-cols that satisfy the desired security properties.

Our approach provides several advantages:

� Automatic. The protocol designer specifiesthe security properties and the system require-ments. The remaining process is fully auto-matic.

� High Confidence. Since the input specifica-tions are written in a well-defined specifica-tion language and the automatic protocol gen-eration is fully mechanical, there are no hid-den assumptions, in contrast to the manual de-sign process. The protocol screener has a pow-erful engine which can automatically generatea proof if a protocol is correct, or a counterex-ample otherwise.

� High Quality. The user-defined system re-quirements includes a metric function whichspecifies the cost or overhead of a protocol.APG tries to generate correct protocols withminimal cost with respect to the metric func-tion hence suits the system requirements thebest.

� Flexible. The approach works for different se-curity properties, system requirements, and at-tacker models.

The remainder of this paper is organized as fol-lows. We begin with an overview of the generalframework and requirements of APG. Next, wepresent a case study of automatic generation of au-thentication protocols. In our case study, we showhow we deal with the arising difficulties to makeAPG feasible. Following the case study, we dis-cuss some of the limitations of APG, as well as the

insights and results of the case study and the inter-esting directions for further research. Finally, wesummarize the contributions of this paper.

2 General Framework and Re-quirements for APG

In this section, we first give an overview of thegeneral framework of APG. Then, we state the re-quirements of each component and give more de-tails about our design and implementation of thesecomponents.

2.1 Overview

At a high level, APG is, as Figure 1 shows, apipeline composed of an automatic protocol gener-ator and an automatic protocol screener. In general,the process of APG has four stages. First, the pro-tocol designer specifies the desired security prop-erties and system requirements as input. Second,the protocol generator searches through the pro-tocol space and generates candidate protocols thatsatisfy the system requirements. Third, the protocolscreener analyzes the candidate protocols. Finally,the flawed protocols are discarded and the correctones that satisfy the desired security properties areoutput.

ProtocolGenerator

ProtocolScreener

CandidateProtocols

Figure 1: APG overview

AutomaticProtocol

Generation(APG)

MetricFunction

InitialSetup

Security Properties

CorrectProtocols

System Requirements

Figure 2: APG data flow

2.2 Input Specification

Our specification language defines the securityproperties, including authentication, secrecy andother properties related to electronic commerce.The system requirements are specified as a metricfunction and a specification of the initial setup. Theinitial system configuration defines which crypto-graphic primitives are available to the principalsand what keys each principal possesses. For ex-ample, in a PKI environment, all protocol partiesknow their own private key and the public keys ofthe other principals, whereas in a symmetric-keyenvironment the principals have shared secret keys.Hybrid systems are also possible.

The metric function corresponds to the cost oroverhead of the protocol. An example for metricdesign is to make the metric correspond to the timeoverhead of the protocol. In a system such as asmart-card, encryption can be fast while the band-width between the card and the card reader may below, in which case the metric function specifies alow cost for encryption, whereas the cost of send-ing and receiving messages is high.

The metric function is required to be monoton-ically increasing as the protocol complexity is in-creasing. This requirement is necessary during theprotocol generation phase, where all the protocolsup to a maximum cost threshold are generated.

The metric function defines an ordering amongthe protocols generated. The screener analyzes theprotocols in the order of increasing cost,1 hencethe first correct protocol has a minimal cost-valuewith respect to the metric function. Given a spec-ification of security properties and system require-ments, we say that a protocol is optimal if it has thelowest cost-value with respect to the metric func-tion among protocols that satisfy the security prop-erties and the system requirements.

2.3 Notation

We use the following notation to describe protocolsin this paper.

1All protocols are sorted after the generation step, since thegeneration might not generate them in strictly increasing order

�����are the principals

���is a nonce generated by

�� �

denotes�

’s public key���� denotes

�’s private key

� ���denotes the secret (symmetric) key

which is shared between�

and�

���������is the encryption of message

�with�

’s public key

2.4 Protocol Representation

A protocol defines a sequence of actions of the par-ticipating parties. The actions include sending andreceiving messages. Messages are defined by thefollowing grammar. The grammar can be easily ex-tended if needed.

������������� �!�#" �%$'&)(+*-,/.10324,65)7�89$ �1:.);<&)24, � $ � 2 � $ �1:

�%$'&)(+*-, �!�#"Principalname

.Nonce

. � � 70324,=5>7�89$ �1:?�!�#"A@B�A�C�)�C����� �

Key D� � 7 �!�#"PublicKey

.PrivateKey.

SymmetricKey;<&)24, � $ � 2 � $ �1:?�!�#"E�A�C�)�C�����GF * � $�A�C�)���H���IF * � $ �!�#"E�A�C�)�C�����

. ������������� � �������������JF * � $

Each message can be represented as a tree withthe atomic messages as leaves and operations asintermediate nodes. Figure 3 shows an examplefor the message:

�����K� � �3��� �>���. We define the

depth of a message as the depth of the tree repre-senting that message. For example, in Figure 3 thedepth of the message tree is 4.

2.5 The Protocol Generator

The purpose of the protocol generator is to generatecandidate protocols that satisfy the specified sys-tem requirements. Intuitively, the protocol space isinfinite. Hence, we need a way to limit the number

Concat

A B Encr

Concat Kb

A B

Figure 3: Example of a message tree for the mes-sage:

�3���K� � ����� �)���

of candidate protocols generated while not omittingany potential optimal protocols.

Our primary method to solve this problem isto use iterative deepening, a standard search tech-nique [RN95]. In each iteration, we set a costthreshold of protocols. We then search through theprotocol space to generate all the protocols belowthe given cost threshold. After sorting the proto-cols, the protocol screener tests them in the order ofincreasing cost. If one protocol satisfies the desiredproperties, it is minimal with respect to the costmetric and the generation process can stop. Oth-erwise, we increase the cost threshold and generatemore protocols.

It is intuitive and our experiments confirmed thatthe number of protocols generated is exponential inthe value of the cost threshold. Hence, the proto-col generator can easily generate millions of pro-tocols. Since elaborate protocol verification takeson the order of 1 second per protocol, it wouldbe impractical for the protocol screener to analyzeall of these protocols. To make APG practical weuse efficient reduction techniques and heuristics toprune invalid candidate protocols early to reducethe number of candidate protocols passed to theprotocol screener. Most of the generated protocolscontain severe security flaws which can be detectedwith a simple and more efficient verification algo-rithm. Each security property that is supported bythe system is therefore accompanied by a pruning

algorithm (which efficiently discards most severelyflawed protocols) and a verification condition forthe screener. We give more detail about the prun-ing algorithms in the case study in Section 3.

2.6 The Protocol Screener

The automatic protocol screener needs to be soundand efficient. Given a candidate protocol, the proto-col screener has to be able to examine the protocoland tell whether it is correct or not. The protocolscreener is sound if when it claims that a protocolsatisfies certain security properties, it is true that theprotocol really does satisfy these properties. Sincethe protocol generator generates thousands of can-didate protocols, the protocol screener needs to behighly efficient to find the optimal protocol in a rea-sonable amount of time.

There are several existing tools for semi-automatic and automatic protocol analysis, suchas the NRL Analyzer [Mea94], the InterrogatorModel [Mil95], FDR [Low96], Mur � [MMS97],and Brutus [CJM98]. Athena is a recentlyintroduced checker for security protocol analy-sis [Son99]. Comparing to other existing automatictools, Athena has the following two main advan-tages:

� Athena has the ability to analyze protocol exe-cutions with any arbitrary configuration. Mostof other existing automatic tools can only rea-son about finite state space, which impliesthat they can only analyze protocol executionswith certain configurations, such as two ini-tiators and two responders. In contrast, whenAthena terminates, it provides a proof that aprotocol satisfies its specified property underany arbitrary protocol configuration, or it gen-erates a counterexample if the property doesnot hold.

� Athena exploits many state space reductiontechniques which result in a highly reducedstate space.

For these reasons, we choose to use Athena asthe protocol screener. During this project, Athena

has verified tens of thousands of protocols and hasestablished itself as a highly efficient and robusttool for automatic protocol analysis.

The following is a brief overview of how Athenaworks. Athena uses an extension of the recentlyproposed Strand Space Model [THG98] to repre-sent protocol execution. Athena incorporates a newlogic that can express security properties includ-ing authentication, secrecy and properties relatedto electronic commerce. An automatic procedureenables Athena to evaluate well-formed formulaein this logic. For a well-formed formula, if theevaluation procedure terminates, it will generate acounterexample if the formula is false, or providea proof if the formula is true. Even when the pro-cedure does not terminate when we allow any arbi-trary configurations of the protocol execution, (forexample, any number of initiators and responders),termination could be forced by bounding the num-ber of concurrent protocol runs and the length ofmessages, as is done in most existing automatictools.

Athena also exploits several state space reduc-tion techniques. Powered with techniques suchas backward search and symbolic representation,Athena naturally avoids the state space explosionproblem commonly caused by asynchronous com-position and symmetry redundancy. Athena alsohas the advantage that it can easily incorporate re-sults from theorem proving through unreachabilitytheorems. By using the unreachability theorems, itcan prune the state space at an early stage, hence,further reduce the state space explored and increasethe likely-hood of termination. These techniquesdramatically reduce the state space that needs to beexplored.

3 Case Study: Automatic Genera-tion of Authentication Protocols

In order to gain preliminary experience with APG,we perform a case study with automatic gener-ation of two-party mutual authentication proto-cols. Authentication protocols are among the mostwidely used and intensely studied security proto-

cols. Their complexity is suitable for an initial casestudy, and they are known to be notoriously diffi-cult to design correctly and hence a good challenge[BAN89, Low96].

We use the agreement properties proposedby Gavin Lowe for authentication protocols asthe formal definition of the authentication prop-erty [Low97]. A protocol guarantees a participant�

agreement for a certain binding �� if each timea principal

�completes a run of the protocol as a

responder using �� , supposedly with�

, then there isa unique run of the protocol with the principal

�as

initiator using �� , supposedly with�

.In this section, we first discuss the assumptions

we make in the case study. Then, we explain thedifficulties we encountered in the case study anddescribe our enhancement techniques to overcomethe difficulties. Finally, we summarize the experi-ment results and our findings.

3.1 Assumptions

We initially analyzed how many first messagesthe initiator

�can send, with a given depth

of the message tree. Subsequently, we referto the two protocol principals as the initiator�

and the responder�

. Initially the initiatorknows the following atomic message components:����� � � � � ���� � � � � ��� . With a message depthof 4 the initiator can generate about one thousandmessages; and with a depth of 6, it can generateabout 8 million messages. If a two-party mutual au-thentication protocol uses three rounds, considering1000 possible messages in each round would leaveus with

�����protocols. A protocol screener which

analyzes 20 protocols per second, would take over1 year.

After the initial estimate, we decide to make cer-tain assumptions to keep the protocol space small.We do not intend to prove that these assumptions donot eliminate the potential optimal protocol. Butwe believe these assumptions are intuitively rea-sonable. We list all the assumptions we make inthe case study as the following:

� Message components are typed. This allowsany participant to distinguish a nonce from a

principal name, for example.

� In any concatenated message, there are no re-dundant message components, i.e.,

�?� � ���.

� No initial keys are sent in a message, since itdoes not make sense to send a private key, andwe assume every principal knows all the pub-lic keys. Session keys generated during theprotocol run do not fall into this category ofauthentication protocols.

� We assume that the initiator’s name needs tobe in the first message in a understandableformat to the responder, so that the respon-der knows who to reply to. (This assumptionmight not be necessary when the initiator andthe responder have a link between them thatis only used to communicate between the twoparties, although this case is not very generalso we do not consider it here.)

� We do not consider permutations of the mes-sage components of a concatenated message.

The last point reduces the protocol space tremen-dously. Unfortunately, this optimization might re-sult in missing a correct protocol. This case canoccur if the generated protocol is vulnerable to aspecific replay attack, where a message of round*

can be replayed for another message of round �(*�" � ). In our current implementation of APG,

the protocol is rejected and no permutation of themessage components is considered. In the future,however, we could detect this case and try to repairthe protocol through a message reordering.

3.2 Adding the Pruning Algorithm to theProtocol Generator

As we mentioned before, a naı̈ve approach gener-ates a large number of uninteresting candidate pro-tocols. In Table 1 we show that the naı̈ve approachgenerates tens of thousands of candidate protocolsin the real experiments. Generating a large numberof flawed candidate protocols risks to render APGimpractical, since the running time of the protocolscreener would be prohibitive. To deal with this

problem, we define a pruning algorithm for eachsecurity property, which efficiently prunes the ma-jority of the flawed protocols. This pruning algo-rithm can either operate on the message level oron the protocol level. A secrecy property, for in-stance, can be verified on the message level, sincethe secret value cannot be disclosed publically inany message. In the case of the authenticationproperty, however, the pruning algorithm works onthe protocol level, since it is difficult to define amessage-level pruning algorithm which does notviolate completeness (i.e. preserves correct proto-cols). To quickly discard flawed authentication pro-tocols, we use an intruder module which checks forimpersonation and simple replay attacks. As Ta-ble 1 shows, these two mechanisms reduce 98 per-cent of the candidate protocols in real experiments.

Impersonation attempt

We use two intruders to attack each protocol. Theintruder ��� tries to impersonate the initiator

�, and

the other intruder ��� attempts to impersonate theresponder

�. Both intruders have the public keys of

all the principals in their initial information. If sym-metric encryption is used, the intruders certainly donot obtain any of the secret keys. Then, ��� tries tostart a session with

�impersonating as

�. If � � can

get�

to finish his session believing it is talking to�, then the protocol is simply broken. Similarly we

can check whether ��� can impersonate as�

to fin-ish a session with

�. The purpose for this attack is

simply to check whether correct and necessary en-cryptions are used. It does not involve any replayattack and multiple protocol run and hence is veryefficient.

Preventing simple replay attacks

Now we look at a simple replay attack. After a pro-tocol session of an initiator

�and a responder

�,

an intruder � stores all the messages sent in the ses-sion. Then, � tries to re-send the packets to

�to

impersonate as�

. If � can trick�

to finish its ses-sion believing it is talking to

�, then the protocol

is flawed and is discarded. Similarly, � can launch

the simple replay attack to�

as well. The purposefor this attack is just to check whether nonces areused in a correct way. The intruder does not try toencrypt or decrypt messages or alter the receivedmessages and hence is very efficient.

3.3 Testing and Improving the ProtocolScreener

There are two main challenges for the protocolscreener. First, the protocol screener needs to besound. If the protocol screener outputs a flawedprotocol, the automatic protocol generation is nottrustworthy. Second, the protocol screener has to beefficient because potentially the protocol generatorcould generate thousands of candidate protocols.

Hence, one point worth mentioning is that thisresearch also serves a second purpose: a real testfor Athena. As far as shown in previous litera-ture, most of the automatic tools for protocol anal-ysis have only been tested with a handful testingprotocols and the testing protocols are mainly ex-isting human-designed protocols. The candidateprotocols generated by the protocol generator arepurely machine-generated from a large protocolspace, and hence, could potentially contain moremisbehavior and difficult errors. Therefore, this is agood test for the soundness of both design and im-plementation of Athena. During the experiments,the protocol generator generates thousands of can-didate protocols. Therefore, this is also a goodtest for the performance of Athena. As a sanitycheck, we also manually analyzed the protocolswhich Athena proved correct. We were not able tofind errors in these protocols. On average, Athenaverifies around 5 protocols per second, based on a400 MHz Pentium II Linux workstation.

3.4 Summary of the Experiment Results

Effectiveness of the Reduction Techniques

In this experiment, we use a simple, linear met-ric function. Each operation has a unit-cost.The cost value of a protocol is the sum of thecosts of all the protocol operations and compo-nents. We choose UNIT ELEMENT COST

" �

(cost to send a nonce or a principal name),and NEW NONCE COST

" �(cost to

generate a new nonce). For symmetric-keyprotocols SYM ENCRYPTION COST

" �

(cost to encrypt a message with a symmet-ric key), and for asymmetric-key protocolsASYM ENCRYPTION COST

" �(cost to

encrypt a message with an asymmetric key).

Table 1 shows the statistics for the protocol gen-eration. The cost threshold is 10 for symmetric-keyauthentication protocols and 14 for asymmetric-keyprotocols. The column labeled “Generated” showshow many protocols were initially generated withthe corresponding cost threshold without applyingthe intruder reduction. The table depicts the ef-fectiveness of the impersonator and replay attacks.The column marked “I.A.” shows the number ofprotocols that are eliminated by the impersonationattack. Similarly, the “R.A.” column depicts thenumber of protocols that are vulnerable to the re-play attack. The combination of the two attacksis quite efficient (shown in the “Combined” col-umn) and leaves about 2% of candidate protocolsfor the symmetric case and 0.2% for the asymmet-ric case (shown in the “Candidate” column). Therunning time for the protocol generation is on theorder of 1 second for every 2000 protocols gen-erated which includes the pruning algorithm (thisnumber is based on our Java implementation, exe-cuted by the JVM of the Sun JDK 1.1.7, running ona 400 MHz Pentium II Linux workstation).

Our Findings of the Protocols

Continuing the experiment from the previous sub-section, Athena analyzed the remaining candidateprotocols and output 2 correct symmetric-key pro-tocols, which have the minimum cost 10. Amongthe 110 asymmetric-key protocols, only 1 is correctand has the minimal cost 14. The three protocolsare listed below:

� Symmetric-key mutual authentication proto-

cols.

����������� � � ��� � � ��� ������ � � � ��� � � � ��� ����� ���� � � � �

������������ � � ��� � � ��� ������ � � � ��� � � � ��� ���������� � � � �

The standard symmetric key mutual authen-tication protocol using random numbers isdocumented in ISO/IEC 9798 [Int93] as ISOSymmetric-Key Three-Pass Mutual Authenti-cation Protocol:

������������ � � ��� � � ��� ������ � � � � � � � � ��� � � ������ � � � ��� � � � ����� �

Our automatically-generated protocols areclearly simpler than the one listed as ISO stan-dard with respect of serving the same purposeas mutual authentication protocol.

� Asymmetric-key mutual authentication proto-cols.

������������ � � ��� � � � ��� ��� �������� � � � � � � � � ��� � � ���� � � � �

This protocol happens to be the same as thefixed version of Needham-Schroeder proto-col [Low96], except for that the last messageis not encrypted. This is because we do nothave the secrecy requirement in the securityproperty specification.

Although intuitive, another interesting result fromthe statistics is that the number of correct proto-cols comparing to the protocols that have the samecost is very low. For example, in this case study,the ratio of generated protocols to correct protocolsis around

��� ��. This ratio decreases when we in-

crease the cost threshold.

Type Max Cost Generated I.A. R.A. Combined Candidates Correct

Symmetric 10 19856 12098 18770 19449 407 2Asymmetric 14 46518 46378 40687 46408 110 1

Table 1: Experiment Statistics for protocol generation. I.A. stands for impersonation attack and R.A. forreplay attack

Optimal Protocols

In this experiment, we experiment with two ex-treme cases of the metric function to see how wecan benefit from the automatic protocol generationto generate optimal protocols.

In the first case, we consider a smart-card,which has a built-in cryptographic accelerator andhence, can perform fast encryption/decryption op-erations. But the smart-card has a slow link tothe card reader. In this case, we set the cost ofencryption much lower than the bandwidth cost(UNIT ELEMENT COST in the specification).With this metric function, we find one symmetric-key authentication protocol with minimum cost:

������������ � � � � � � � � � ��� � � ������ � � � ��� � � � �������� � � � � �

In the second case, we consider a slow machinewith a fast link, where the cryptographic operationsare the bottleneck. In this case, we set the band-width cost much lower than the encryption cost inthe metric function. Hence, we get the followingtwo optimal symmetric-key protocols.

������������ � � � � � � ��� ���� � � � � ��� � ��� ��� �������� � � � � �

����������� � � ��� � � � � ������ � � � ��� � � � ��� ���������� � � � �

It is interesting to notice that the two protocols inthe first case use one more encryption than the twoprotocols in the second case, while the messages

are shorter. We can see a clear benefit from auto-matic protocol generation, since the protocols gen-erated suit the system requirements ideally.

For the asymmetric-key protocol, in both cases,the automatic protocol generation finds the sameprotocol as the optimal protocol. The resulting pro-tocol is the same as the asymmetric-key protocollisted in the previous subsection.

4 Discussion and Future Work

The approach of automatic protocol generationsounds attractive, but it is initially unclear whetherit is feasible to generate meaningful and correctprotocols automatically. One goal of this researchis to try to answer this question. During thecase study, we were able to generate correct au-thentication protocols automatically and some ofthem were documented before and are currently inuse. The automatic protocol generation process forauthentication protocols is efficient, usually onlytakes matter of seconds of running time. This illus-trates that the approach of automatic protocol gen-eration is feasible.

The case study is a proof of concept and showsthat automatic protocol generation can accomplishsimple tasks, but it says little about whether thisapproach will scale up to more complicated pro-tocols. Since the protocol space grows exponen-tially with the number of parties and the numberof messages, we expect that the number of candi-date protocols, generated by the protocol generatorin more complicated cases, can be orders of magni-tudes larger than the numbers that appeared in theexperiments. It is an interesting research directionto explore more powerful reduction techniques tomake this approach scale.

The case study mainly covers the authentication

security property. There are many other interestingsecurity properties including properties related toelectronic commerce, such as atomicity. We needto extend our system to handle these properties. Forexample, new reduction techniques are needed forthe protocol generator. Athena terminated and suc-cessfully analyzed all the candidate protocols gen-erated in the case study for authentication proto-cols. But for protocols requiring other properties,we might need to add new unreachability theoremsto enhance Athena.

Currently, in the protocol analysis, we assumeperfect encryption. The perfect-encryption as-sumption states that a ciphertext can only be de-crypted if the decryption key is present, and simi-larly, a ciphertext can only be produced if the en-cryption key is present. Researchers have beenexploring protocols which are resistant againststronger attacks, such as dictionary attacks. It isalso interesting to try to strengthen the attackermodel in the current approach to produce strongerprotocols.

5 Conclusion

The main points of the paper are the following:

� We present the novel approach of automaticgeneration of security protocols. With auser-defined specification of security proper-ties and the system requirements, including asystem metric function, APG generates min-imal protocols that satisfy the specified secu-rity properties and system requirements, min-imal with respect to the metric function. Thisapproach is a significant improvement over thecurrent protocol design process, because it ismore reliable, efficient, and produces proto-cols that suit the given system requirementsideally.

� We perform a case study on the automaticgeneration of two-party mutual authentica-tion protocols for proof of concept and togain experience with APG. During the casestudy, APG automatically generates protocols

that are simpler than the documented standardones. In two examples from the real world,APG is also able to generate different optimalprotocols with respect to varying metric func-tions, and hence, demonstrate its benefit.

6 Acknowledgments

We would like to thank Doug Tygar for his valu-able help and support during this project. We alsothank George Necula and Sean Smith for their use-ful suggestions and discussions. We are also great-ful to the anonymous reviewers for their feedbackand suggestions.

References

[BAN89] M. Burrows, M. Abadi, and R. Need-ham. A logic of authentication. Techni-cal Report 39, DEC Systems ResearchCenter, February 1989.

[CGP99] Edmund Clarke, Orna Grumberg, andDoron Peled. Model Checking. MITPress, 1999.

[CJM98] E.M. Clarke, S. Jha, and W. Marrero.Using state space exploration and a nat-ural deduction style message derivationengine to verify security protocols. In InProceedings of the IFIP Working Con-ference on Programming Concepts andMethods (PROCOMET), 1998.

[DY89] D. Dolev and A. Yao. On the se-curity of public key protocols. IEEETransactions on Information Theory,29(2):198–208, March 1989.

[HT96] N. Heintze and J. Tygar. A model for se-cure protocols and their compositions.IEEE Transactions on Software Engi-neering, 22(1):16–30, January 1996.

[Int93] International Standards Organization.Information Technology - Security tech-niques — Entity Authentication Mech-

anisms Part 3: Entity authentica-tion using symmetric techniques, 1993.ISO/IEC 9798.

[Low96] G. Lowe. Breaking and fixing theNeedham-Schroeder public-key proto-col using FDR. In Tools and Algo-rithms for the Construction and Analy-sis of Systems, volume 1055 of LectureNotes in Computer Science, pages 147–166. Springer-Verlag, 1996.

[Low97] G. Lowe. A hierarchy of authentica-tion specifications. In Proceedings ofthe 1997 IEEE Computer Society Sym-posium on Research in Security and Pri-vacy, pages 31–43, 1997.

[Mea94] C. Meadows. A model of computationfor the NRL protocol analyzer. In Pro-ceedings of the 1994 Computer Secu-rity Foundations Workshop. IEEE Com-puter Society Press, June 1994.

[Mea95] C. Meadows. Formal verification ofcryptographic protocols: A survey. InAdvances in Cryptology - Asiacrypt’94, volume 917 of Lecture Notesin Computer Science, pages 133–150.Springer-Verlag, 1995.

[Mil95] J. Millen. The Interrogator model.In Proceedings of the 1995 IEEESymposium on Security and Privacy,pages 251–260. IEEE Computer Soci-ety Press, 1995.

[MMS97] J. C. Mitchell, M. Mitchell, andU. Stern. Automated analysis of crypto-graphic protocols using mur � . In Pro-ceedings of the 1997 IEEE Symposiumon Security and Privacy. IEEE Com-puter Society Press, 1997.

[RN95] Stuart Russell and Peter Norvig. Artifi-cial Intelligence: A Modern Approach.Prentice Hall Series in Artificial Intelli-gence, 1995.

[Son99] Dawn Song. Athena: An automaticchecker for security protocol analysis.In Proceedings of the 12th ComputerScience Foundation Workshop, 1999.

[THG98] F.Javier Thayer, Jonathan C. Herzog,and Joshua D. Guttman. Strand spaces:Why is a security protocol correct? InProceedings of 1998 IEEE Symposiumon Security and Privacy, 1998.

[WL93] T. Y. C. Woo and S. S. Lam. A semanticmodel for authentication protocols. InProceedings of the IEEE Symposium onResearch in Security and Privacy, 1993.