Validating Attacks on Authentication Protocols Anders Moen Hagalisletto Abstract

advertisement
Validating Attacks on Authentication Protocols
Anders Moen Hagalisletto
Department of Informatics, University of Oslo
Abstract
It is possible to show that well-known attacks on authentication protocols are flawed. This is a problem,
since good protocols may thus be dismissed rather than
improved and poor protocols that might continue to
be used although they may contain irreparable errors.
This paper describes a novel method for validating attacks on authentication protocols, based on a strategy
for checking that all elements of the attack have been
legally obtained. A Maude-program which implements
the method, identified errors in attacks on the Wide
Mouthed Frog and Yahalom authentication protocols.
More generally, the paper shows that the method will
find all errors in attacks that originates from incompleteness of cryptographic assumptions. The main implications is that new attacks can be effectively validated
even when an exhaustive state-space analysis becomes
infeasible. We expect that in the future, validation will
be an obligatory part in effectively checking the soundness of any attacks on security protocols.
1. Introduction
In this paper we present a new efficient method for
analyzing attack descriptions. A tool based on this
method has been implemented in the functional language Maude. Protocol analysis is a very active research area involving fully automated state space analysis used to search for possible attacks on protocols
([7], [11], [8], [5], [2]). The tool checks whether each element in the attack has been obtained in a legal way by
communication and cryptographic principles. This validation can provide important answers regarding protocols, where state space analysis becomes infeasible.
Validation can be used to make informal design principles of security protocol specification explicit and formal, and thereafter check whether attacks are correct.
Note that validation can not find new attacks, only
check whether existing attacks are correct. Our experience so far indicates that attack descriptions should be
Attack
Description
P
Validator
Automated
Refinement
P’
Ok
P’’
freshness
Validation
Algorithm
Non valid
Debugging/redesign
Failure
Report
Figure 1. Process flow of validation.
described as accurately as protocols and their correctness should be analyzed as formally as protocols: The
tool has recently revealed that seven of 23 attacks in
the report “A Survey of Authentication Protocol Literature: Version 1.0” by Clark and Jacob [4] (denoted
Clark/Jacob) contain flaws [10].
To the best of the author’s knowledge, explicit validation of attacks has not been performed before. Many
tool providers claim to have performed implicit validation, as an integrated part of their model checkers ([3],
[7]) Several authors, in particular Martin Abadi [1], has
emphasized the importance of being explicit about the
underlying assumptions in authentications protocols.
In specifications languages like CAPSL [6] and Casper
[12], and HLPSL [3], the protocol specifier is first invited to include initial assumptions about which keys,
nonces and timestamps that are used in the specification and then finally the security goals regarding secrecy of data and authentication of agents that should
be met in the protocols. Our investigation shows that
this is not enough, assumptions about the local behaviour of agents should be specified explicitly, and inserted in-between the clauses for message transmission.
The validator is part of the precompiler for the protocol simulator PROSA. The simulator is implemented
in Maude, which is a functional language based on
rewriting logic [13]. The high level flow of the validation process is specified in Figure 1. Initially an attack description is specified in the high level protocol specification language LP , which is based on temporal epistemic logic. The attack description P is the
input of the automated refinement algorithm. Auto-
mated refinement makes explicit every implicit assumption in P, about required beliefs about keys, awareness
of agents, etc. There are two kind of assumptions, assertions about the local beliefs of an agent, and assignments or actions that the agent performs in order to create fresh keys, nonces, timestamps, or to decrypt, encrypt, or hash data in the messages. Assumptions can also be categorized by their roles in the transmission: the assumptions are divided into either the
sender’s preconditions or receiver’s postconditions. The
output of refinement is then a specification P1 . Duplicated assumptions are then removed from P1 and assumptions that must have been created freshly during
the execution is substituted to form P2 . The resulting
refined description P2 is the input to the validation algorithm: The validation algorithm takes advantage of
the fact that the automated refinement algorithm does
not assure that every assumption in the refined specification is obtained in a legal cryptographic way. It is
exactly these cryptographically ungrounded sentences
that the validator algorithm discovers. It is possible to
repair some of the attacks, by using the generated Failure Report. The original flawed description is revised
and the adjusted protocol is validated once more.
The paper is organized as follows: The high level
language for writing attack specifications, is presented
in Section 2. Attack descriptions specified in the language are the input of the automated refinement module, described in Section 3. Validation is described in
Section 4. A detailed analysis of the validation of the
attack on the Yahalom protocol is presented in Section 5.
bols for nonces nptN , aq, time-stamps stampptT , aq, keys
keyps, a, b, xK q, keypa, i, a, xK q, keypa, u, a, xK q. Protocol names µ1 , µ2 might be concatenated: µ1 µ2 . Ground
terms for nonces tN , time-stamps tT , and key-terms
tK , may either denote natural numbers N or variables of the appropriate sort.
Definition 1 Let LP is the least language such that:
piq Each of the following atomic formulas are in LP
ε
the empty sentence
a is an agent
Agentpaq
isKeypk q
k is a key
isNoncepnpN, aqq npN, aq is a nonce
TimepstamppN, aqq stamppN, aq is a timestamp
rolepbq
b is a protocol role
piiq If ϕ, ψ, ξT , ξA, ξS P LP , then so are;
ϕ, ϕ Ñ ψ
propositional logic
Transmitpa, b, ϕq a sends ϕ to b
a believes ϕ
Bela pϕq
ϕU ψ
ϕ holds until ψ holds
E rk : ϕs
encrypt ϕ using key k
decrypt ϕ using key k
Drk : ϕs
Hashrϕs
hash the sentence ϕ
enforce agent a to do ϕ
Enforcea pϕq
protocolrµ, N, ξ T , ξ A, ξ S, Φs protocol operator
2. A language for attack specifications
The connectives ^, _ and Ø are definable in terms
and Ñ and J ϕ Ñ ϕ. The operator Bela pϕq
of
reads “the agent a believes ϕ holds”. In protocol specifications beliefs are used to explicitly state required
cryptographic assumptions. The until operator ϕ U ψ
means that ϕ holds until ψ holds. The operator before B , is definable from U by ϕ B ψ p ϕ U ψ q.
In this section we present technical preliminaries for the rest of the paper.The content the messages consists of basic entities: nonces, timestamps,
text strings, and agent names. In addition there are
three composition operators: concatenation, hashing and encryption. A language for specifying security protocols LP can be defined as follows: LP consists of terms of four sorts, agents, nonces, time-stamps,
keys, and natural numbers. The agent-names are typically written “Alice”, “Bob”, “Server”, agent-variables
are written x, y, x1 , x2 , . . ., and agent-terms a, b, c,
. . . Variables for the other sorts are labeled with the
sort xN (nonce-variable), xT (time-variable), and xK
(key-variable) respectively, when their sorts are emphasized. Constants include protocol names µ, µ1 ,
µ2 , encryption methods for cryptography s (symmetric) and a (asymmetric), in addition to the indicators
i (private) and u (public). There are function sym-
A subset of this language is the set of P-positive
sentences; that includes the atomic sentences, and composite sentences where a modal operator is the uttermost connective (thus every connective in Definition 1
part piiq, except and Ñ).
The sentence Enforcea pϕq, means: “enforce agent
a to perform ϕ”. Enforcement is the only imperative construct in the language, and is used usually with the generation of fresh entities within
the protocol: We augment LP with additional constructs for local construction of fresh entities:
A
A
newKeypkeyps, tA
1 , t2 , M qq, CurrentpstamppN, t qq, and
newNoncepnptN , tA qq. Note that the usage of the nested
operator Enforcex pBelx pψ qq shall be restrictive. The operator protocolrµ, N, ξ T , ξ A , ξ S , Φ s denotes: “protocol named µ with session number N , the total roles ξ T ,
the agent specific roles ξ A , the start-roles ξ S and with
the protocol body Φ”. Trust can be expressed within
LP by: Trustpa, b, ϕq Transmitpb, a, ϕq Ñ Bela pϕq.
2.1. Specification of protocols
Protocols are sequences of instructions in a distributed program, the notion of ordering can be expressed by temporal logic: A protocol is a chain of
events between agents. A chain of events is of the form
ϕ1 B ϕ2 ^ ϕ2 B ϕ3 ^ . . . ^ ϕn1 B ϕn , where each ϕi
is P-positive. The last event ϕn ε, is always the
empty event, marking the end of the protocol specification. Let Φ ϕ B rΦ1 s denote a chain of events written by recursion, hence ϕ is a single event and Φ1 a
chain of events.
Definition 2 If Φ and Ψ are chains of events, then
their concatenation, denoted Φ " Ψ, is given by:
piq Φ " ε Φ ε " Φ
piiq pϕ B rΦ1 sq " Ψ ϕ B rΦ1 " Ψs
We say that a text-book protocol, is a protocol where
each single event is of the form Transmitpxj , xk , ϕq, or
of the form Enforcex pBelx pnewKeypk qqq.
2.2. Attack protocols
The language presented sofar needs few extensions
in order to capture attacks: An attack protocol is a
protocol P, such that some of the transmissions contains occurrences of impersonation terms impI, Aq either as the sender or the receiver of a transmission.
The term impI, Aq reads “I impersonates as A”. In case
TransmitpimpI, Aq, B, M q, the real sender of the message is I, while the message itself claims that A is the
originator. In case TransmitpB, impI, Aq, M q, the message is intercepted by I, and A never receives the message. Protocols that do not contain any occurrence of
impersonation terms are called intended protocols. A
complete survey of the underlying protocol algebra was
given in [9].
The chain of events described in pPreM
A q, characterize
the sender’s preconditions for transmitting the message
pMsgq. The protocol region pPreMA q is a function of the
agent A, the message content M , and the result of refining the previous protocol messages. The chain pPreM
Aq
typically contains local assumptions about required beliefs (or assertions) that the agent A must have in order to be able to form M , or assignments about which
fresh nonces, timestamps, hashes or encryptions that
must be created as ingredients to M .
The chain of events described in pPostM
B q, contains protocol clauses that maximize the receiver’s extraction of information from M . The protocol region
pPostMB q is similarly a function of the receiver B, M ,
and the refinement of the previous messages. The chain
contains first a sentence saying that the receiver is enforced to trust the message content. Then afterwards
comes a sequence of projections and decryptions based
on the keys that the receiver possess. If an encrypted
part M 1 can not be decrypted by an agent a, because of
lack of keys, it is left in the chain as an assertion about
the cipher-text M 1 , that is, it is of the form Bela pM q.
If a transmission involves an impersonation, then the
attacker’s local behavior must be reflected in the preconditions if the attacker fakes an honest agent, or in
the postconditions if the attacker is an eavesdropper.
Consequently we need two functions for interpreting
the impersonation terms, realization of the impersonator or the intended agent. We define the functions t
and t as follows: If t is an agent variable or agent name,
then t t t. If t impt1 , t2 q, then t t1 and t t2 .
Definition 3 If P is a text-book protocol, then P can
be refined into an assumption protocol by ℜA :
pR0 q
pR1 q
pR2 q
3. Automated refinement of attacks
An automated refinement of a text-book specification includes every local assumption about each participant in the attack. Roughly the refinement algorithm works as follows: Given a transmission clause
A ÝÑ B : M , the refinement algorithm constructs a
protocol as follows:
The sender’s assumptions about M .
A ÝÑ B
: M
The receiver’s extraction of information
from M .
pPreMA q
pMsgq
pPostMB q
pR3 q
pR4 q
pR5 q
ℜA pprotocolrµ, N, ξ T , ξ A , ξ S , Φ sq protocolrµ, N, ξ T , ξ A , ξ S , ℜA pΦ, εq s
ℜA pε, P q P
ℜA pTransmitpt1 , t2 , F q B rΦs, P q ℜA pΦ, P " preApt1 , F, P q " pBelt1 pAgentpt2 qq B
Transmitpt1 , t2 , F q B Belt2 pAgentpt1 qq
B Enforcet2 pBelt2 pTrustpt2 , t1 , F qqq B εq
" postApt2 , F, P qq
ℜA pBela pF q B rΦs, P q ℜA pΦ, P " pBela pF q B εqq
ℜA pEnforcea pBela pHashrF sqq B rΦs, P q ℜA pΦ, P " preApa, F, P q "
pEnforcea pBela pHashrF sqq B εqq
ℜA pEnforcea pF q B rΦs, P q ℜA pΦ, P " pEnforcea pF q B εqq
if F Bela pHashrM sq, for every M
The definition of ℜA can be motivated as follows: In the
beginning pR0 q, the function is called with the empty
chain. If the first argument is the empty chain ε, then
ℜA returns the accumulated chain P , and the recursion ends pR1 q. In case the event is a transmission, then
the assumptions required to send the message are generated as preconditions for the sender, and afterwards
the local assumptions about the receivers extraction of
information is constructed, the postconditions for the
receiver pR2 q. The functions performing realizations of
the agent terms, and , ensures that attackers impersonating agents are refined correctly. If the protocol
contains explicit specifications of assumptions in advance, then these assumptions are included in the refined protocol (R3 and R5 ). One exception to this is
hashing (R4 ), if some data is hashed this data should
have been obtained earlier in the protocol session.
3.1. Assumptions regarding transmission
We first present the assumptions, pre- and postconditions for plain-text content hashing, and symmetric keys, and then the extension to public key cryptography is given:
3.1.1. Preconditions - constructing the subprotocol pPreM
t q The assumption function pre constructs
every required assumption necessary for transmitting a
message. First let A denote the following set of atomic
sentences:
tAgentpaq, isKeypkq, isNoncepnq, Timeprq| a is a agent
(term), k is a key, n is a nonce, r is a timestamp, u.
occurred earlier, the principal agent must perform the
hashing. Consider the cases where the uttermost operator is an encryption. The dominating strategy of the
precondition-algorithm will be to try to perform an explicit encryption, whenever this is possible. Case pAE1 q
covers the case where either the secret key is one of the
agent’s keys, or the agent has obtained the key previously in the execution. In both cases the agent should
be able to encrypt the sentence using data from its beliefs, and analyze the plain-text further. If neither of
these is the case, then the sentence can only be possessed by the agent, and the analysis ends pAE2 q.
3.1.2. Postconditions - constructing the subprotocol pPostM
t q The postcondition function post
works by extracting information from a received message, by decomposing the message using projection and
decryption.
Definition 5 The extraction function post is defined
by recursion on the complexity of the message content:
pPAq post pt, F, P q BeltpF q B ε, if F P A
pPCq post pt, F ^ G, P q post pt, F, P q"post pt, G, P q
pPHq post pt, HashrF s, P q ε
pPE1q post py, E rkeyps, x, z q : F s, P q post py, isKeypkeyps, x, z qq, P q
" pEnforcey pBely pDrkeyps, x, z q :
E rkeyps, x, z q : F ssqq B εq " post py, F, P q
if y z _ x z _ Bely pisKeypkeyps, x, z qqq P P
pPE2q postpy, E rkeyps, x, z q : F sq Bely pE rkeyps, x, z q : F sq B ε
if y x ^ y z ^ Belm pisKeypkeyps, y, z qqq R P
A
A
A
A
A
A
A
A
Definition 4 The assumption function pre is defined
by recursion on the complexity of the message content:
pAAq pre pt, F, P q BelxpF q B ε, if F P A
pACq pre pt, F ^ G, P q pre pt, F, P q " pre pt, G, P q
pAH1 q pre pt, HashrF s, P q pre pt, F, P q B ε
if Hash rF s P P
pAH2 q pre pt, HashrF s, P q pre pt, F, P q "
pEnforcetpBeltpHashrF sqq B εq if Hash rF s R P
pAE1 q pre px, E rkeyps, y, z q : F s, P q pre px, F ^ isKeypkeyps, y, z qq, P q "
Enforcex pBelx pE rkeyps, y, z q : F sqq B ε
if x y _ x z _ Belx pisKeypkeyps, y, z qqq P P
pAE2 q pre px, E rkeyps, y, z q : F s, P q Belx pE rkeyps, y, z q : F sq B ε
if x y ^ x z ^ Belx pisKeypkeyps, y, z qqq R P
Clause pAAq and pACq are obvious. Consider therefore
the cryptographic clauses pAH1 AE2 q: In case the opA
A
A
A
E
A
A
E
A
E
A
E
A
A
E
A
E
erator is a hash, there are two cases, the hash has been
introduced previously in the protocol session or it has
not been introduced earlier. In the former case pAH1 q,
the content to be hashed must be possessed by the
agent. In the latter case pAH2 q, since HashrF s has never
Full explicitness is obtained by the clause pPAq and
pPE2q: Every atomic belief is extracted in the post con-
dition in order to be explicit about everything the agent
knows after decryption. This is particularly important
in case of attack protocols, since it is crucial to the
analysis to know exactly what an attacker knows after receiving a message by interception. Projection of
conjunction PC, guarantees that every element is analyzed. Nothing can be extracted from hashed data
pPHq. In clause pPE1 q, the receiving agent y possess
the key either since it is one of its own secret keys, or
y has obtained it previously in the execution. Hence
the agent y is able to decrypt the sentence, and recursively decompose the message into basic assumptions.
Clause pPE2 q takes care of the opposite situation: The
receiving agent is not capable of decrypting the message, hence the information extraction stops, the agent
can only be aware of the cipher-text.
3.2. Public key cryptography extension
The previous algorithm extends easily to public key
cryptography. Note that the extension requires that
there is already an infrastructure for distributing the
public keys.
3.2.1. Preconditions Either the uttermost encryption uses a private key pAE3 AE5 q or a public key
pAE6 , AE7 q. In case of encryption with a private key,
either
1. pAE3 q : x already possesses the key and has not
previously failed analyzing the sentence, hence an
encryption can be made by recursively analyzing
the content F ,
2. pAE4 q : x does not possess the key and has not
previously failed analyzing the sentence, hence an
encryption is not be possible,
3. pAE5 q : x has previously failed analyzing the sentence, no encryption is being made, and since
failure has been reported earlier (E rkeypa, i, y q :
F s PE P ), it is not necessary at this point (hence
ε is returned).
In case the public key is used to encrypt the message we might safely assume that the sender has access to the public key, and is able to encrypt the message, and continue to construct the required assumptions pAE5 , AE7 q.
pAE3 q pre px, E rkeypa, i, yq : F s, P q pre px, F ^ isKeypkeypa, i, y qq, P q "
Enforcex pBelx pE rkeypa, i, y q : F sqq B ε
if px y _ Belx pisKeypkeypa, i, y qqq P P q
^ Belx pE rkeypa, i, yq : F sq R P
pAE4 q pre px, E rkeypa, i, yq : F s, P q Belx pE rkeypa, i, y q : F sq B ε
if px y ^ Belx pisKeypkeypa, i, y qqq R P q
^ Belx pE rkeypa, i, yq : F sq R P
pAE5 q pre px, E rkeypa, i, yq : F s, P q ε
if Belx pE rkeypa, i, y q : F sq P P
pAE6 q pre px, E rkeypa, u, yq : F s, P q pre px, F ^ isKeypkeypa, u, y qq, P q "
Enforcex pBelx pE rkeypa, u, y q : F sqq B ε
if Belx pE rkeypa, u, y q : F sq R P
pAE7 q pre px, E rkeypa, u, yq : F s, P q ε
if Belx pE rkeypa, u, y q : F sq P P
A
A
E
E
A
E
E
A
E
A
A
E
A
E
3.2.2. Postconditions In case the private key is
used to encrypt the message pPE5 q, we might safely
assume that the receiver has access to the public key,
and is able to decrypt the message, and continue to
extract the information from the message. If the public key is used, then the receiver might (case PE3 ) or
might not have the private key (case PE4 ). In the latter case information extraction is aborted, and the receiver can only be aware of the encrypted message.
pPE3 q
pPE4 q
pPE5 q
postApy, E rkeypa, u, z q : F s, P q pBely pisKeypkeypa, u, z qq ^ isKeypkeypa, i, z qqq
B Enforcey pBely pDrkeypa, i, z q :
E rkeypa, u, z q : F ssqq B εq " postApy, F, P q
if y z _ Bely pisKeypkeypa, i, z qqq PE P
postApy, E rkeypa, u, z q : F s, P q Bely pE rkeypa, u, z q : F sq B ε
if y z ^ Bely pisKeypkeypa, i, z qqq RE P
postApy, E rkeypa, i, z q : F s, P q pBely pisKeypkeypa, u, z qqq B
Enforcey pBely pDrkeypa, u, z q :
E rkeypa, i, z q : F ssqq B εq " postApy, F, P q
4. Automated validation of attacks
It is possible to use the resulting refined protocol for
further analysis. It turns out that automated refinement is the “working horse” of validation. There is a
close interplay between the automated validation algorithm and the beliefs obtained through automated refinement. From the presentation of the automated refinement algorithm in Section 3, it is clear that that
the algorithm does apply to text-book specifications
that are not cryptographically correct. The only sanity check that ℜ performs, is whether appropriate keys
have been obtained prior to encryptions and decryptions. In other words, it is possible to refine erroneous
protocols and attacks. We say that a belief statement is
grounded if it is obtained through legal cryptographic
operations or communication. From the definition of
the automated refinement algorithm in Section 3, we
observe that some beliefs in certain protocols might
not be grounded. Ungrounded beliefs might be atomic
facts as well as encrypted sentences. Candidates of ungrounded beliefs involving encrypted messages using
symmetric keys can be produced from Definition 4, part
AE2 , and Definition 5, part PE2 . Similarly, encryptions
using asymmetric keys that might potentially give rise
to ungrounded beliefs may come from the equations
AE4 , AE5 , AE6 , PE4 , and PE5 .
It is this distinction between the grounded protocol
and the ungrounded protocols that the validation algorithm is targeting. The validation algorithm decides
whether every belief in a refined protocol is grounded.
In other words, the validation algorithm makes the
informal reasoning of the protocol designer’s cryptographical understanding entirely explicit. Surprisingly
this algorithm has been used to discover several mistakes in famous attacks [?]. We call the algorithm validation, and write vpPq for the result of validating the
text-book protocol P. In practice validation is carried
out by first performing the automated refinement, then
removing duplicated assumptions (denoted eq), and finally supplementing the protocol with freshness actions
(denoted Æ). In other words, given a text-book protocol
P, validation amounts to apply vpÆpeqpℜpPqqqq. There
are three cases: a given protocol sentence is grounded,
hence we proceed traversing the rest, or the validation
reached the end, or finally a belief statement is found
that is not grounded. The first case corresponds to a
pattern:
vpϕ B ΦqΨ vpΦ, Ψ " pϕ B εqq if condition C holds.
If ϕ Bela pF q then the condition C formalize the sentence “F has been obtained correctly by the agent a
by past communication and the principles of cryptography”. Usually this involves backtracking in the protocol analyzed so far, either by checking whether a nonce,
timestamp, or message-text is created freshly and correctly earlier, or is the result of the legal actions of communication or decryption using known keys. Hence two
additional concepts are needed: A conjunction ϕ is included in another conjunction ψ, denoted ϕ „ ψ is defined by aggregation. The notion of ϕ is an element in
a chain Ψ, written ϕ PE Ψ, is defined by obvious recursion on the length of chains Ψ.
Definition 6 We say that ϕ can be embedded (cryptographically) valid inside Ψ for an agent a, denoted
epa, F, Ψq, iff
epa, ϕ1 , Belb pϕ2 q B Ψq epa, ϕ1 , Ψq
epa, ϕ1 , Enforcea pBela pDrk1 : E rk2 : ψ ssqq B Ψq J
if ϕ1 „ ψ
epa, ϕ1 , Enforcea pϕ2 q B Ψq epa, ϕ1 , Ψq
if ϕ2
Bela pDrk1 : E rk2 : ψssq implies ϕ1 † ψ
epa, ϕ1 , Transmitpb, a, ϕ2 q B Ψq J
if ϕ1 „ ϕ2
epa, ϕ1 ,Transmitpb, impa, cq, ϕ2 q B Ψq J if ϕ1 „ ϕ2
epa, ϕ1 ,Transmitpb, c, ϕ2 q BΨq epa, ϕ1 ,Ψq if ϕ1 † ϕ2
epa, ϕ1 , εq K
Let ÆpisNoncepnqq newNoncepnq and ÆpTimeptqq Currentptq. Also let ptq denote the function decalculating a numeric term t, e.g. px 1q x and px 1q x.
Definition 7 The validation algorithm v is given by:
piq vpprotocolrµ, N, ξT , ξA , ξS , Φ sq vpΦ, εq
piiq vpε, F q Textp"No error found"q
piiiq vpF B Φ, Ψq vpΦ, Ψ " pF B εqq
if F Bela pAgentpbqq or F Enforcea pBela pϕqq
or F Transmitpa, b, ϕq
pivq vpBela pF q B Φ, Ψq vpΦ, Ψ " pBela pF q B εqq
if pF isNoncepnpxN , bqq or
or F TimepstamppxT , bqq or F TextpS, bqq
and pEnforcea pBela pÆpF qqq P Ψ or epa, F, Ψqq
pvq vpBela pisNoncepnptN , bqqq B Φ, Ψq vpΦ, Ψ " pBela pisNoncepnptN , bqqq B εqq
E
if tN is a numeric term, and
pEnforcea pBela pnewNoncepnpptN q, bqqqq PE Ψ
or epa, isNoncepnptN , bqq, Ψq
or epa, isNoncepnpptN q, bqq, Ψqq
pviq vpBela pE rk : F sq B Φ, Ψq
vpΦ, Ψ"pE rk : F s B εqq if epa, E rk : F s, Ψq
pviiq vpBela pisKeypkeyps, x, y, N qqq B Φ, Ψq vpΦ, Ψ " Bela pisKeypkeyps, x, y, N qqq B εq
if a x _ a y
pviiiq vpBela pisKeypkeyps, x, y, wK qqq B Φ, Ψq vpΦ, Ψ " Bela pisKeypkeyps, x, y, wK qqq B εq
if pa x _ a y q^
pEnforcea pBela pnewKeypkeyps, x, y, wK qqqq PE Ψ
or epa, isKeypkeyps, x, y, wK qq, Ψqq
pixq vpBela pisKeypkeyps, x, y, tK qqq B Φ, Ψq vpΦ, Ψ " Bela pisKeypkeyps, x, y, tK qqq B εq
if a x and a y and
pEnforcea pBela pnewKeypkeyps, x, y, wK qqqq PE Ψ
or epa, isKeypkeyps, x, y, wK qq, Ψqq
pxq vpBela pisKeypkeypa, i, yqqq B Φ, Ψq vpΦ, Ψ " pBela pisKeypkeypa, i, y qqq B εq
if a x or epa, isKeypkeypa, i, y qq, Ψq
pxiq vpBela pisKeypkeypa, u, yqqq B Φ, Ψq vpΦ, Ψ " pBela pisKeypkeypa, u, y qqq B εq
pxiiq else vpBela pϕq B Φ, Ψq Bela pϕq ^ Ψ
The algorithm is motivated as follows: In piiq the original protocol to be validated is empty, which means
that there are no more sentences to check, hence the
protocol is correct. The main recursion involves checking the cryptographic integrity of beliefs. Hence beliefs
concerning agent names, enforcements and transmissions are not validated piiiq.
Nonces, timestamps, and message text piv q might either be created by the principal agent, or have been obtained as plain-text or encrypted by transmissions from
other agents. Nonces might involve numeric terms, the
most common nonce term is tN x 1. In that case
the nonce might have been received as a numeric term,
or as a subterm of a numeric term. In this case, the
term is decalculated, ptN q, in order to justify if the
origin of the nonce is valid. An encrypted message pviq
should have been obtained legally, received by transmission from other agents.
Symmetric keys might either be one of the agent’s
keys (vii, viii) or foreign keys pixq. In the former case
the key is either possessed by the agent pviiq, or created
in the current protocol session by the principal agent or
another agent, typically a server providing keys pviiiq.
Asymmetric keys is handled as follows: In case the key
is a public key, every agent is supposed to be able to
know it pxiq. In case the agent possesses a private key,
it might be its own private key, or the agent has obtained the key intentionally or as part of an attack pxq.
If none of the above conditions apply then the algorithm terminates in pxiiq with an exception, reporting
the negation of the ungrounded assumption: Bela pϕq,
and where this anomaly occurred Φ (representing the
initial segment of the protocol).
5. Case study - the Clark/Jacob library
Of the 23 attacks, 12 attacks rely on the possibility of mixing data types, and each could be validated
by the tool. Fortunately, the validator is able to check
attacks involving type flaws and standard (type correct) attacks. The validator revealed that 7 of 23 attacks were erroneous, that is 30 %. The results analyzed in detail in [10] is summarized by the following
table:
Protocol name
Page Attack-type
Error
Repair?
Wide Mouthed Frog
49
standard
severe
yes
Yahalom
49
type conv.
severe
no
Woo Lam Π
53
type conv.
severe
yes
Neuman Stubblebine
57
type conv. misprint
yes
Shamir Rivest Adelman
64
type conv.
severe
no
Denning Sacco
63
standard
severe
yes
Encrypted Key Exchange 65
standard
misprint
yes
In the next section we give a detailed analysis of the
attack on Yahalom.
5.1. The attack on Yahalom
The Yahalom protocol [4, p. 49] only uses symmetric keys, to establish a new session key: The specification given by Clark/Jacob is as follows:
pY1 q A ÝÑ B : A, NA
pY2 q B ÝÑ S : E pKBS : A, NA , NB q
pY3 q S ÝÑ A : E pKAS : B, KAB , NA, NBq,
E pKBS : A, KABq
pY4 q A ÝÑ B : B, E pKBS : A, KAB q, E pKAB : NB q
In the attack presented in Clark/Jacob, the attacker
tries to make the respondent B believe that the concatenation of nonces NA , NB plays the role of the new
r
p q^ p q^ p q^ p q
p q^ p q p q
p p q
p q^
pp
qqq
p
p q
p q^ r p
q
p q^
pp
qq ^
pp
qqsq
p p
p p
pp
qq ^
pp
qqqqqq
p p q
r p
q
p q
^
p p
pp
qq ^
pp
qqqqsq
^ r p
pp
qq ^
pp
qqq
pp
qqs s
protocol Yahalom Attack, 0, role A role B
role S
role I ,
role A
role B , role A ,
Transmit im I, A , B, Agent A
isNonce n NA, I
1
B Transmit B, im I, S , Agent B
E key s, B, S :
Agent A
isNonce n NA, I
isNonce n NB, B
2
B EnforceI BelI
isKey key isNonce n NA, A
isNonce n NB , B
3
B Transmit im I, A , B, E key s, B, S : Agent A
isKey key isNonce n NA, A
isNonce n NB , B
E key isNonce n NA, A
isNonce n NB , B
:
isNonce n NB , B
Bε
4
pq
pq
pq
pq
Figure 2. The Yahalom attack specified in LP .
r
p
p
p
p
p
p
p q^ p q^ p q^ p q
p q^ p q p q
p qq
p1q
p p
pp
qqqq
p2q
p qq
p3q
p p q
p q^
pp
qqq
p4q
p qq
p5q
p p
p
p q^
pp
qqqqq
p6q
pp
qqq
p7q
p qq
p8q
p p
pp
qqqq
p9q
p p
qqq
p10q
p p r p
q
p q^
pp
qq ^
pp
qqsqq
p11q
p p qq
p12q
p
p q
p q^ r p
q
p q^
pp
qq ^
pp
qqsq
p13q
p p
p
p q^ r p
q
p q^
pp
qq ^
pp
qqsqqq
p14q
p r p
q
p q^
pp
qq ^
pp
qqsq
p15q
p
pp
qqq
p16q
p p p p
pp
qq^
pp
qqqqqq p17q
p r p
q
p p
pp
qq ^
pp
qqqqsq
p18q
p p r p
pp
qq ^
pp
qqq
pp
qqsqq
p19q
p p q
r p
q
p p
pp
qq ^
pp
qqqqs
^ r p
pp
qq ^
pp
qqq
pp
qqsq
p20q
p p
p
r p
q
p p
pp
qq ^
pp
qqqqs
^ r p
pp
qq ^
pp
qqq
pp
qqsqqq
p21q
p p r p
q r p
q
p p
pp
qq ^
pp
qqqqssqq
p22q
p p p
pp
qq ^
pp
qqqqq
p23q
p p r p
pp
qq ^
pp
qqq
r p
pp
qq ^
pp
qqq
pp
qqssqq
p24q
protocol Yahalomattack, 0, role A
role B
role S
role I ,
role A
role B , role A ,
BelI Agent A
B EnforceI BelI newNonce n NA, I
B BelI Agent B
B Transmit im I, A , B, Agent A
isNonce n NA, I
B BelB Agent A
B EnforceB BelB Trust B, A, Agent A
isNonce n NA, I
B BelB isNonce n NA, I
B BelB Agent B
B EnforceB BelB newNonce n NB , B
B BelB isKey key s, B, S
B EnforceB BelB E key s, B, S :
Agent A
isNonce n NA, I
isNonce n NB , B
B BelB Agent S
B Transmit B, im I, S , Agent B
E key s, B, S :
Agent A
isNonce n NA, I
isNonce n NB , B
B EnforceI BelI Trust I, B, Agent B
E key s, B, S :
Agent A
isNonce n NA, I
isNonce n NB , B
B BelI E key s, B, S :
Agent A
isNonce n NA, I
isNonce n NB , B
B BelI isNonce n NB , B
B EnforceI BelI isKey key isNonce n NA, I
isNonce n NB , B
B BelI E key s, B, S :
isKey key isNonce n NA, I
isNonce n NB , B
B EnforceI BelI E key isNonce n NA, I
isNonce n NB , B
:
isNonce n NB , B
B Transmit im I, A , B, E key s, B, S :
isKey key isNonce n NA, I
isNonce n NB , B
E key isNonce n NA, I
isNonce n NB , B
:
isNonce n NB , B
B EnforceB BelB Trust B, A, E key s, B, S :
isKey key isNonce n NA, I
isNonce n NB , B
E key isNonce n NA, I
isNonce n NB , B
:
isNonce n NB , B
B EnforceB BelB D key s, B, S : E key s, B, S :
isKey key isNonce n NA, I
isNonce n NB , B
B BelB isKey key isNonce n NA, I
isNonce n NB , B
B EnforceB BelB D key isNonce n NA, I
isNonce n NB , B
:
E key isNonce n NA, I
isNonce n NB , B
:
isNonce n NB , B
Bε
s
Figure 3. Automated refinement of the Yahalom attack.
secret session key, in other words the attack is a typical type flaw attack:
pY.1q I pAq Ñ B : A, NA
pY.2q B Ñ I pS q : E pKBS : A, NA , NB q
pY.3q
Omitted
pY.4q I pAq Ñ B : B, E pKBS : A, NA , NB q, E pNA ,NB : NB q
The attacks specifications involving type flaws,
should explicitly include the type conversion. In the
attack the concatenation of the two nonces, NA , NB is
interpreted as the fresh symmetric key. Hence the intruder should be able to construct a fresh key. Since
the language is strongly typed, the type conversion is taken care of, by relaxing the input arguments of the key term to include sentences, i.e. keypF q.
In case of the previous attack the required conversion is obtained by the “casting” term:
keypisNoncepnpNA, I qq ^ isNoncepnpNB , B qqq
The type conversion of the two nonces into the symmetric key in the latter attack is performed by the command:
EnforceI pBelI p
isKeypkeypisNoncepnpNA, I qq ^ isNoncepnpNB , B qqqqqq
The attack is then specified in LP as shown in Figure 2 and Figure 3. By running the attack specification, the validator reported that the specification was
not valid, with an exception
BelI pisKeypkeypisNoncepnpNA, I qqqqq
in line 16, Figure 3, which means that the intruder I
should have obtained the nonce NB . Comparing with
Clark/Jacob’s specification, this means that I does not
have the component E pNA , NB : NB q before entering
pY.4q. There are two reasons why the intruder I cannot
form E pNA , NB : NB q: I does not possess NB , and
can neither build the fake key NA , NB nor the content
NB to be encrypted. Note that there is no obvious way
to repair this attack.
6. Conclusion
The tools for security protocol analysis reports to
have found attacks on protocols that are not correct.
We should warn the reader in jumping into conclusions: In many cases the errors reported do not save
the underlying protocols from being corrupt, since the
attacks could be repaired, or there exists another correct attack. However, the results in this paper do imply
that the analysis tools are not particularly successful
in filtering out the correct attacks: Any completeness
and correctness result proven about such a tool, that
claims to cover the entire collection of attacks in the
Clark/Jacob library, should be considered with scepticism.
Acknowledgments
Thanks to Bjarte Østvold, Chik How Tan, Peter
Csaba Ölveczky, Olaf Owe, and Steinar Kristoffersen
for comments on earlier drafts of this paper.
References
[1] Martín Abadi. Security protocols and their properties. In Foundations of Secure Computation, NATO
Science Series, pages 39–60, Marktoberdorf, Germany,
1999. IOS Press (2000).
[2] Michael Backes, Sebastian Mödersheim, Birgit Pfitzmann, and Luca Viganò. Symbolic and Cryptographic
Analysis of the Secure WS-ReliableMessaging Scenario. In Proceedings of FOSSACS 2006, volume 3921
of LNCS, pages 428–445. Springer-Verlag, 2006.
[3] David Basin, Sebastian Mödersheim, and Luca Viganò.
OFMC: A symbolic model checker for security protocols. International Journal of Information Security,
4(3):181–208, June 2005.
[4] J. Clark and J. Jacob. A Survey of Authentication
Protocol Literature, 1997. Version 1.0, Unpublished
Report, University of York, http://cs.york.ac.uk/
~jac/papers/drareview.ps.gz.
[5] Ricardo Corin, Sandro Etalle, and Ari Saptawijaya. A
logic for constraint-based security protocol analysis. In
Security and Privacy, pages 155–168. IEEE Computer
Society Press, 2006.
[6] Millen J. Denker G. and Ruess H. The CAPSL integrated protocol environment. Technical Report SRICLS-2000-02, SRI, 2000.
[7] Ben Donovan, Paul Norris, and Gavin Lowe. Analyzing a Library of Security Protocols using Casper
and FDR. In Proceedings of the Workshop on Formal
Methods and Security Protocols. IEEE Computer Society Press, 1999.
[8] A. Gordon and A. Jeffrey. Types and effects for asymmetric cryptographic protocols. In 15th IEEE Computer Security Foundations Workshop (CSFW 15),
Cape Breton, pages 77–91. IEEE Press, 2002.
[9] Anders Moen Hagalisletto. Protocol Algebra. In The
11th IEEE Symposium on Computers and Communications, pages 394–401, 2006.
[10] Anders Moen Hagalisletto. Errors in Attacks on Authentication Protocols, 2007. Accepted for publication in IEEE The Second International Conference on
Availability, Reliability and Security (ARES 2007) .
[11] Romain Janvier, Yassine Lakhnech, and Laurent
Mazaré. Relating the symbolic and computational
models of security protocols using hashes. In Joint
Workshop on Foundations of Computer Security and
Automated Reasoning for Security Protocol Analysis,
pages 67–89, 2006.
[12] Gavin Lowe. Casper: A compiler for the analysis of security protocols. Journal of Computer Security, 6:53–
84, 1998.
[13] J. Meseguer. Conditional rewriting logic as a unified
model of concurrency. Theoretical Computer Science,
96:73 – 155, 1992.
Download