requirements for security protocols

Requirements for Security ProtocolsWuu Yang

Department of Computer ScienceNational Chiao-Tung University

Hsin-Chu, Taiwan, R.O.C.w

Rong-Hong JanDepartment of Computer ScienceNational Chiao-Tung University

Hsin-Chu, Taiwan, R.O.C.r

Abstract: A correctsecurity protocol should satisfy four requirements: no-intrusion, authenticity, freshness, and secrecy. Wedivide the four requirements into two groups (one for no-intrusion, authenticity, and freshness and the other for secrecy). Forthe former we use themessage-exchange formsand for the latter, we use thep-knowsandn-knowsinformation that is inferredfrom a latest topological orders of thetrigger-graph. Based on these methods, flaws and weaknesses hidden in an imperfectsecurity protocol could be uncovered.

Key-Words: authentication, authentication protocol, computer communication, computer security, security protocol, ver-ification.

1 Introduction

1 A security protocol is a set of messages that the com-municating parties use to establish secure communica-tion channels, mostly by setting up agreed-upon secretkeys. Examples of computer security protocols include[10, 11, 12, 16, 8]. However, many security protocols arefound to be flawed after they are deployed [1]. Given therapid growth of computer networks, there is a pressing needfor a framework and tools for the development and analysisof security protocols [4]. This implies that protocol verifi-cation is a difficult task.

A lot of work [14, 9, 5, 6, 12, 7, 15] was focused onprotocol verification. Some researchers propose methodsfor testing security protocols like testing software [17]. Af-ter reviewing the previous work on protocol verification,we feel that the security of a protocol is not a single prop-erty. Rather, it is the composition of several more funda-mental properties. We list four requirements for an abso-lutely secure protocols and shows how to enforce the fourrequirements.

no-intrusion No-intrusion means that an attacker cannotintrude into a session of a protocol. If the attackerplans to impersonate a legitimate participant, he hasto do it from the very beginning of the session. No-intrusion implies that the attacker cannot inject fakemessages in the middle of a session of a security pro-tocol without being detected.

authenticity Authentication means that a participant mustauthenticate other participants in a session before hecan trust them. Authentication is usually accom-

1The work reported in this paper is partially supported from Na-tional Science Council, Taiwan, Republic of China, under grant NSC-94-2213-E-009-029. The authors can be reached by e-mail: [email protected] and [email protected].

plished by demonstrating that a participant knows cer-tain secrets, such as a secret key.

freshnessFreshness means that messages sent and re-ceived in a session are generated specifically for thecurrent session. An attacker cannot use messagesfrom previous sessions in the current session.

secrecy Secrecy means that the contents of a message iskept secret between the participants of a protocol ses-sion.

The four requirements together can guarantee thecorrect-nessof a security protocol. No-intrusion assures that thepersons sending messages in a session are fixed partici-pants. Their roles in a session will not be stolen by at-tackers. Authentication means the fixed participants can allshow sufficient information to identify themselves. Fresh-ness prevents a participant from mistaking a message froma previous session as a legitimate message for the currentsession. Secrecy keeps a by-stander from obtaining vitalinformation by eavesdropping on the communication me-dia.

The crux of this paper is that we use two verifica-tion processes: First, we make sure that the no-intrusion,authenticity, and freshness requirements are satisfied. Wedo this by checking that the underlying structure of a se-curity protocol consists ofmessage-exchange forms(to bediscussed in Section 3). Second, we check that an attackercannot know the important secrets. We use aearliest topo-logical order (to be discussed in Section 4) to infer the in-formation an attack could know immediately before eachmessage of the security protocol is sent.

Clark and Jacob [4] identified seven kinds of com-mon attacks to security protocols. Brackin [3] classifiedfive kinds of security threats: freshness, type, binding, par-allel session, and oracle attacks. There are many methodsintended for protocol verification. Burrows et al. [2] pro-

Proceedings of the 5th WSEAS International Conference on Telecommunications and Informatics, Istanbul, Turkey, May 27-29, 2006 (pp315-320)

poses a logic for security protocols. Their logic has muchinfluence in the study verification; however, there are stillflaws that escapes their logic. Previously, we proposed anexhaustive testing method for security protocols [17].

The rest of the paper is organized as follows: The nextsection summarizes the terms and notations used in this pa-per. The third section discusses message-exchange forms.The fourth section infers knowledge of the attackers as wellas the legitimate participants. The last section concludesthis paper.

2 Preliminaries

In this paper, we will use the following Needham-Schroeder protocol [11, 13] as an example.

1. A → S : A,B, Na2. S → A : Na, B, Kab, Kab, AKbsKas

3. A → B : Kab, AKbs

4. B → A : NbKab

5. A → B : Nb− 1Kab

The keyKas is a shared key betweenA andS, which is es-tablished before a session of the Needham-Shroeder proto-col starts. Similarly,Kbs is a pr-established shared key be-tweenB andS. After a session of the Needham-Schroderprotocol, the new keyKab would be known exactly toA,B, andS.

A security protocolconsists of an partially orderedsequence ofmessagesand a specification. Each messageconsists of an ordered sequence ofitems. An item couldbe either un-encrypted (which is calledatomic) or en-crypted. An encrypted item consists of an ordered sequenceof subitems and an encryption key.

The specification of a security protocol include (1) thekeys and other relevant secrets each participant knows be-fore a session of a security protocol, (2) public informationthat everybody (including the attacker) knows before a ses-sion of a security protocol, and (3) the information eachparticipant and the attacker know and do not know after asession of the security protocol completes.

The legitimate communicating participants havesome previously established secrets, such as shared secretkeys and public keys. We assume that these previously es-tablished keys are well kept away from attackers. A se-curity protocol cannot protect secrets once these keys arelost.

A session of a security protocol is made up of two oremore participants, who send and receive messages. Thesender of the first message is theinitiator of the session.Intuitively, the initiator is the participant who intends tocommunicate with other participants.

The purpose of (a session of) a security protocol isto establish a new key between communicating parties (theinitiator of a session and a responder). This new key iscalled thejewel of the session. For example,Kab is thejewel in the above Needham-Schroeder Protocol. Some se-curity protocols may be capable of establish multiple new

keys among three or or communicating parties. Our tech-nique can be easily extended to these more capable proto-cols. The intended holders of the jewel are calledpropositi.For instance, in the above Needham-Schroeder Protocol,AandB are the propositi whereasS, who knows the jewel,is not.

3 How can a receiverR believe in a messagethat he receives?

For a receiver to believe in the authenticity and freshnessof a piece of information, the information must be properlyenclosed in messages. The messages of a security protocolmust consist ofmessage-exchange forms. (We can guaran-tee the secrecy of a piece of information only by examiningthe whole security protocol and inferring what an attackercan know. We will study secrecy guarantee in the next sec-tion.)

The message-exchange form is either a basic form orits variations. The basic form (from the perspective of thereceiverR), shown below, consists of a pair of messages:a challenge and a response. The challenge need not be en-crypted; however, the response is usually encrypted.

R → . . . : tokenr — a challege. . . → R : jewel, tokenrKp — a reply

Heretokenr is generated by the receiverR andKp isthe key that is agreed upon betweenR and (1) the intendedproducer of the jewel or (2) a participant who has alreadybelieved injewel. Kp could be a shared that is establishedbefore the current session of the security protocol starts orit could be a key that is established in previous steps of thecurrent session.

These two messages guarantee, toR, the freshnessand authenticity of the jewelunder the provision that theattacker does not knowjewel andKp and the receiverRmust be able to knowKp. (There is a provision in everyform discussed in this section. In the next section, we willshow a method to check the provisions.)

ToR, the freshness ofjewel is guaranteed bytokenr,which is generated byR. The authenticity ofjewel is guar-anteed byKp, which is assumed to be a well-kept secret be-tweenR and the legitimate participant who creates the en-crypted itemjewel, tokenrKp. Note that the two mes-sages guarantees the authenticity and freshness ofjewelonly toR, but not to other participants of the security pro-tocol. Usually,R must present a proof of his identity addi-tionally.

tokenr can be viewed as apassportannounced byR. ThenR will treat whatever is bound withtoken (by asuitable key) as packaged later thanR announcedtokenr.Freshness is therefore guaranteed.

A slight variation of the second message isjewel, f(tokenr)K , . . .Kp, wheref is a fixed func-tion, such as one-way hash, increment, or decrement, that


the receiver can verify andK is a key known toR. In thisvariation, eitherjewel or tokenr can be encrypted in orderto achieve secrecy. The use of the functionf is to avoid en-crypting the same item (in the case,tokenr) several times.Certain encryption algorithms become easier to break if thesame item is encrypted several times.

The whole second message can also be encrypted sev-eral times, such asjewel, tokenrKpK1K2K3, aslong as the receiver can decode it.

Example. AssumeR andP share a previously estab-lished secret keyKrp. Consider the following three proto-cols:

Protocol 1 :R → P : tokenrP → R : jewel, tokenrKrp

In Protocol 1,R generates a new tokentokenr andsends it toP . P sends back a new keyjewel, which isgenerated byP . Protocol 1 establishes a fresh and authen-ticated keyjewel betweenR andP

Protocol 2 :R → P : tokenr,KnewKrp

P → R : jewel, tokenr − 1Knew

Protocol 2 achieves a similar effect as Protocol 1.Protocol 3 :R → P : tokenr, jewelKrp

P → R : tokenr + 1jewel

Protocol 3 is flawed in that an attacker canpretend to beR and re-sends a previous messagetokenr, jewelKrp. P will believe in the authenticity(but not the freshness) ofjewel if this protocol can guaran-tee that onlyP andR knows the keyKrp. However, as farasR is concerned,jewel is fresh and authenticated (sinceit is R who generatesjewel).

An alternative, more flexible message-exchange formis shown below:

R → . . . : tokenr. . . → R : tokenp, tokenrKp

. . . → R : jewel, tokenpKp

This alternative form can be viewed as two runs ofthe basic form.tokenr guarantees the freshness oftokenp,which in turn guarantees the freshness ofjewel under theprovision that the attacker does not knowjewel andKp.tokenp must be generated by the partyP .

The tokentokenp may be considered as an interme-diate jewel. It can be used to guarantee the authenticity andfreshness of other jewels. For instance, we may also usetokenp to encrypt the jewel. The third message could bereplaced by the following message:

. . . → R : jeweltokenp

The provision for this variation is thatthe attackerdoes not knowjewel, Kp, and tokenp since tokenp isused to encrypt other items.

We can generalize the above form further.R → . . . : tokenr. . . → R : tokena, tokenrKa

. . . → R : tokenb, tokenaKb

. . . → R : tokenp, tokenbKp

. . . → R : jewel, tokenpKp

Theprovisionhere is thatthe attacker does not knowKa, Kb, Kp, and jewel.

Example. Consider the following protocol:Protocol 4 :1. A → B : A,nonceA

2. B → S : A,nonceA,B, nonceB

3. S → B : Kab, nonceBKbs

4. S → A : Kab, nonceAKas

We claim that a security protocol iscorrect if it con-sists of message-exchange forms for the propositi (and theprovisions in the forms are observed) for each legitimateparticipant.

For Protocol 4, there are two message-exchangeforms, one for each propositi (A andB):

message-exchange form forA1. A → . . . : . . . nonceA4. . . . → A : Kab, nonceAKas

message-exchange form forB2. B → . . . : . . . nonceB3. . . . → B : Kab, nonceBKbs

There is afreshness attackon the Needham-Schroederprotocol [11, 4]. Suppose the secret keyKab in the firstsession is compromised and is known to the attacker. Theattacker can re-send the third message of the first session asthe third message of the second session. ThenB is fooledto take the old keyKab as the new secret key for the secondsession. The real trouble lies in that, thoughB can decryptthe third message,B does not have the guarantee that themessage is fresh.

Our technique clearly shows that the message-exchange form for the propositusB is missing. There isonly one message-exchange form, which is intended forA.

message-exchange form forA1. A → . . . : . . . Na2. . . . → A : Na, . . . Kab, . . .Kas

message-exchange form forBmissing

In this section, we make an implicit assumption: Thelegitimate parties of the protocol—A, B, andP—who pos-sess the keysKa, Kb, andKp, respectively, are all well-behaved. When an attacker tries to fool others, he neveruses his real identity (so as to avoid being caught in the fu-ture). The attacker always impersonates as someone else.This is not a severe limitation. Most security protocols alsomake such an assumption.

4 What does an attacker know?

The information contained in the messages of a securityprotocol may belong to one of the two categories:

a. transient information those that is used only in thecurrent session


b. sustained information those that may be used in sub-sequent sessions.

Example. Consider the following protocol:A → B : Ksession, KnewKold

In this protocol,Ksession is the key for the currentsession andKnew will replaceKold in the next session.Thus,Ksession is a piece of transient information whileKnew is sustained. (In this case,Ksession is the jewelwhile Knew is just a piece of information transmitted inthe current session.)

Since sustained information gathered from one ses-sion might be useful in subsequent sessions, an attackermay quietly observe several sessions of the security pro-tocol to obtain sufficient sustained information beforelaunching his attack. Thus, we first infer what an attackercan know after he observes enough sessions and then weinfer what the attacker can know immediately before eachmessage of the attacked session is sent out.

4.1 What an attacker can know before helaunches an attack

We assume that the attacker does not know any secrets ini-tially. The legitimate parties knows suitable keys beforea session of the security protocol starts. We also assumethat the transmission media is subject to eaveasdropping.This implies that an attacker is able to collect all messages,though he probably could not decrypt the encrypted items.It is easy to infer what the attacker could know at the endof the whole session. There are two rules concerning theinference:

1. If an item is transmitted in plain text, the attacker isassumed to know the item right away.

2. If the attacker knows a keyK and items encryptedwith K, then the attacker can decrypt the encrypteditems. This rule is based on the generally accepted as-sumption that the encryption algorithm itself is knownto the public.

Example. Consider the following protocol:A → B : KB → C : QK

C → D : R, SQ, TKcd

At the end of a session of the protocol, the attackerwould knowK, QK , Q, R,SQ, R, S, andTKcd,but he knows neitherKcd andT .

4.2 What the attacker can know immediatelybefore a message is sent

A common, but implicit property of a security protocolis that there is aninitiator (who is usually the sender ofthe first message). When a participant receives a message,he will send another message to another participant. Wesay the first messagetriggers the second. We may draw

C

B A

F

D E

Figure 1. A directed acyclic graph

a trigger-graph in which each vertex represents a message.If messageA triggers another messageB, there will be anedgeA → B. Usually the trigger-graph is a linear graph.However, sometimes a message may trigger two or moremessages. In Protocol 4 in Section 3, the second messagetriggers the third and the fourth messages. In that case thetrigger-graph is an acyclic directed graph.

On a trigger-graph, we may derive topological ordersof the vertices. Among the topological orders, we wish tofind thelatest topological order.

Definition. Let G be a directed acyclic graphG. Atopological orderis a linear order of the vertices ofG suchthat if there is an edgeX → Y in G, thenX appears beforeY in the linear order.

Note that a directed acyclic graph may have more thanone topological order. In a topological order, the first vertexis assigned thesequence number1; the second is assigned2. Similarly for other vertices.

Definition. Let A be a vertex in a directed acyclicgraphG, a latest topological order with respect toA is atopological order in which the sequence number ofA is nosmaller than that in any other topological order.

Example. Consider the graph in Figure 1. The orders[C, D,B, E,A, F ] and [C, D,E, B,A, F ] are latest topo-logical orders with respect to vertexA because in both or-ders, the sequence number ofA is 5. However, the topo-logical order[C, B, D, A, E, F ] is not a latest topologicalorder with respect toA because the sequence number ofAis 4.

In terms of the trigger-graph, the latest topological or-der with respect to a vertex (i.e., a message)A indicates themessageA is delayed as much as possible. From the lat-est topological order with respect to vertexA, we may in-fer what an attacker can possibly know immediately beforemessageA is sent out.

It is quite easy to compute a latest topological orderwith respect to a vertexA in a directed acyclic graph. Wepartition the set of vertices into two categories: those thatare not reachable fromA and those that are. The vertexAwill be put in the former category. Then the concatenationof topological orders of the two categories is the requiredlatest topological order.


4.3 Two kinds of knowledge

After determining a proper order of message transmission,we will infer the knowledge of the legitimate participantsand possibly the attacker.

In order to keep certain items secret, we encrypt themwith keys. These encryption keys in turn need to be keptsecret. We may use other keys to encrypt these keys. Thesame argument applies to these other keys. Eventually, weuse pre-established encryption keys, that is, keys that areestablished before a session of a security protocol.

In general, for a deeply encrypted item such asX, Y, Z K3K2K1, at least one ofK1, K2, andK3must be kept secret from each person who is not supposedto know the itemZ.

Definition. A participant who is entitled to know thejewel is called aknowledgeable.

The propositi are always knowledgeables whereas anattacker is never a knowledgeable. Other participants mayalso be knowledgeables. For instance, in the Needham-Schroeder protocol,A, B, andS are all knowledgeables.However, an attacker is not

It is the designer of a protocol who shall specify ex-plicitly the knowledgeables in his protocol. The responsi-bility of a protocol analyzer is to verify the designer’s spec-ification.

In order to check the specification of who knows whatin a security protocol, there are two cases to consider:

Positive Side We need to guarantee all the knowledge-ables are informed the jewel in some form that hecould understand, such as in an encrypted form that hecould decrypt. That is,every knowledgeable p-knowsthe jewel. (We will definep-knowslater.)

Negative SideWe need to guarantee nobody except theknowledgeables is able to know the jewel. That is,no one except the knowledgeables n-knows the jewel.(We will definen-knowslater.)

The main difference betweenp-knowsand n-knowslies in, for p-knows, a participant can examine only mes-sages sent to him whereas, forn-knows, an attacker canexamine all messages sent over the transmission medium.

4.3.1 The positive side

Let Z be an item. LetE be a participant. For ev-ery occurrence ofZ in the message sent toE, sayX, Y, Z K3K2K1, a sequence of keys that are usedto encryptZ, in this case,[K1,K2,K3], is created. IfZappears as a plain (that is, un-encrypted) item in a messagesent toE, an empty sequence is created. The set of all suchsequences of keys is denoted asΣZ,E .

Definition. We say thatE p-knowsZ if and onlyif (1) there is at least one sequence of keys inΣZ,E , say[K1,K2, . . . , Km], such thatE p-knows everyKi in this

sequence; (2)E knowsZ before the session starts (for in-stance, Alice p-knows the pre-established keyKab sharedbetween her and Beth); or (3)E generatesZ.

It is straightforward to construct the setΣZ,E , for ev-ery Z andE—simply by examining every message in theprotocol. We can use an iterative algorithm to determine ifE p-knowsZ, for every participantE and itemZ.

Theorem. If a knowledgeable p-knows the jewel,then the knowledgeable eventually knows the jewel.

This theorem implies that the protocol successfullyinforms every knowledgeable the jewel.

4.3.2 The negative side

Let Z be an item. For every occurrence ofZ in any mes-sage, sayX, Y, Z K3K2K1, a sequence of keys thatare used to encryptZ, in this case,[K1, K2,K3], is cre-ated. IfZ appears as a plain (that is, un-encrypted) itemin a message, an empty sequence is created. The set of allsuch sequences of keys is denotedΩZ .

Definition. Let E be a participant or an attacker. Wesay thatE n-knowsZ if and only if there is at least onesequence of keys inΩZ , say[K1,K2, . . . , Km], such thatE p-knows or n-knows everyKi in this sequence.

It is also straightforward to construct the setΩZ , foreveryZ—simply by examining every message in the pro-tocol. We can use an iterative algorithm to determine ifEp-knowsZ, for every participantE and itemZ.

Theorem. If no one except the knowledgeables n-knows the jewel, then no one except the knowledgeablesknows the jewel.

This theorem implies that the protocol successfullyhides the jewel from everyone except the knowledgeables.

Example. We use two tables to summarize thep-knowsandn-knowsrelations for the Needham-Schroederprotocol. Here is thep-knowsrelation:

pre-established inferredp-knows atomic items atomic items

S Kas,Kbs Na, KabA Kas Na, Kab, NbB Kbs Kab,Nb

The p-knowstable is good for checking if a securityprotocol successfully distribute the relevant keys to the in-tended participants. Usually, this is not a problem. Themajor problem in analyzing a security protocol is to decidewhat an attacker could know. This problem can be analyzedwith the help of then-knowstable, shown below.

pre-established inferredn-knows atomic items atomic items

S Kas,Kbs Na, Kab, NbA Kas Na, Kab, Nb

B Kbs Kab,Nb, NaD (a by-stander) Na


Then-knowstable is more useful in estimating whatattacker could know if he is one of the participants of theprotocol or if he is just a by-stander (by passively eaves-dropping on the communication lines).

5 Conclusion

We have proposed four requirements of acorrect secu-rity protocol—no-intrusion, authenticity, freshness, and se-crecy. The first three can be guaranteed with message-exchange forms while the fourth can be guaranteed withp-knowsand n-knows, which are inferred from the latesttopological orders of the trigger-graph.

References

[1] M. Abadi and R. Needham, “Prudent engineeringpractice for cryptographic protocols,”IEEE Transac-tions on Software Engineering, Vol. 22, No. 1, pp. 6-15, January 1996.

[2] M. Burrows, M. Abadi, and R. Needham, “A logic ofauthentication,”ACM Trans. Computer Systems, Vol.8, No. 1, pp. 18-36, 1990.

[3] S.H. Brackin, “Automatically detecting most vulner-abilities in cryptographic protocols,”Proc DARPA In-formation Survivability Conference and Exposition2000 (DISCEX 00), Vol. 1, pp. 222-236, January 25-27, 2000.

[4] J. Clark and J. Jacob, “A survey of authenticationprotocol literature, Version 1.0,”, technical report,York Univ., November 1997, available at http://www-users.cs.york.ac.uk/ jac/.

[5] J. Heather, G. Lowe, and S. Schneider, “How to pre-vent type flaw attacks on security protocols,” InPro-ceedings of 13th IEEE Computer Security Founda-tions Workshop, 255-268, 2000.

[6] P. Janson, G. Tsudik and M. Yung, “Scalability andflexibility in authentication services: The KryptoK-inght Approach,”Proceedings of INFOCOM’97, Vol.2, pp. 725 -736, 1997.

[7] A. Kehne, J. Schonwalder, and H. Langendorfer, “Anounce-based protocol for multiple authentication,”AMC Operating Systems Review, Vol. 26, No. 4, pp.84-89, October 1992.

[8] C. Laferriere and R. Charland, “Authentication andauthorization techniques in distributed systems,” InProceedings of IEEE 1993 International CarnahanConference on Security Technology, pp. 164-170,1993.

[9] Y. Li, W. Yang, and C.W. Huang, “Preventing typeflaw attacks on security protocols with a simplified

tagging scheme,”Journal of Information Science andEngineering(accepted), July 2004.

[10] G. Lowe, “A hierarchy of authentication specifica-tions,” In Proceedings of 10th Computer SecurityFoundations Workshop, pp. 31-43, June 1997.

[11] R.M. Needham and M.D. Schroeder, “Using encryp-tion for authentication in large networks of comput-ers,” Communications of ACM, Vol. 21, No. 12, pp.993-999, December 1978.

[12] B.C. Neumann and S.G. Stubblebine, “A note on theuse of the timestamps as nounces,”ACM OperatingSystems Review, Vol. 27, No. 2, pp. 10-14, April 1993.

[13] B.C. Neumann and Theodore Ts’o, “Kerberos: Anauthentication service for computer network,”IEEECommunications Magazine, Vol. 32, No. 9, pp. 33-38, September 1994.

[14] L.C. Paulson, “Proving security protocols correct.” InProceedings of 14th Symposium on Logic in Com-puter Science, 370-381, 1999.

[15] J.G. Steiner, C. Neumann, and J.I. Schiller, “An au-thentication service for open network systems,” InProceedings of the Winter 1988 USENIX Conference,pp. 191-202, 1988.

[16] T.Y.C. Woo and S.S. Lam, “A lesson on authentica-tion protocol design,”ACM Operating Systems Re-views, 28(3), 24-37, 1994.

[17] W. Yang, “Uncovering Attacks On Security Proto-cols,” In Proc.International Conf. Information Tech-nology and Applications(Sydney, Australia), Vol. 2,572-575, July 4-7, 2005.


requirements for security protocols

Documents