Model Checking Detectability of Attacks in Multiagent Systems

Model checking detectability of attacks in

multiagent systems

Ioana Boureanu

Department of Computing Imperial College London, UK

[email protected]

Mika Cohen

Department of Computing Imperial College London, UK

[email protected]

Alessio Lomuscio

Department of Computing Imperial College London, UK

[email protected]

ABSTRACT

Information security is vital to many multiagent system ap-plications. In this paper we formalise the notion of de-tectability of attacks in a MAS setting and analyse its appli-cability. We introduce a taxonomy of detectability specifi-cations expressed in temporal-epistemic logic. We illustrate the practical relevance of attack detectability in a case study applied to a variant of Kerberos protocol. We model-check attack detectability in automatically generated MAS models for security protocols.

Categories and Subject Descriptors

D.2.4 [Software/Program Verification]: Model checking

General Terms

Verification, Security

Keywords

Verification of MAS; Logics of Agency; Logic-based ap-proaches and methods; Privacy, safety and security; Formal models of agency

1.

INTRODUCTION

Security is an essential component to several multiagent system (MAS) applications including online trading [23], web-services [9], negotiation systems [19], self-healing sys-tems, etc. Manually validating security requirements is a notoriously difficult and error-prone task. To surpass this difficulty tools have been developed to verify security proto-cols, to identify possible attacks [1, 2, 3, 4, 18, 10].

While being able to discover attacks automatically is obvi-ously important, protocols that are known to be susceptible to attacks (e.g., IPSec, WEP, GSM, DNS, SSH1, Kerberos, etc.) remain in widespread use at least in some applications. In some cases the cost of protocol redeployment over large multi-agent distributed applications is too high to justify the benefit. Other times hardware, software, or standards constraints make it impossible to deploy other protocols on some applications.

Cite as:Model checking detectability of attacks in multiagent systems, I. Boureanu, M. Cohen, A. Lomuscio,Proc. of 9th Int. Conf. on Au-tonomous Agents and Multiagent Systems (AAMAS 2010), van der Hoek, Kaminka, Lespérance, Luck and Sen (eds.), May, 10–14, 2010, Toronto, Canada, pp. XXX-XXX.

Copyright c 2010, International Foundation for Autonomous Agents and Multiagent Systems (www.ifaamas.org). All rights reserved.

If we are prepared to accept that in some cases the system will be compromised, it becomes of paramount importance to detect when this happens. Detecting that an attack has happened, or identifying some early signs of an attack being attempted, could be fundamental to limiting the damages to the system. Having the ability to detect attacks could itself be a deterrent for the attacks to be carried out. Even more so if the culprit of the attack could be identified. When are attacks detectable then? In security it is assumed that when an attack is successful the frauded party does not learn an attack has taken place. However, attacks may leave groups of agents with sufficient collective information to infer that an attack has taken place.

Just as verifying whether protocols are secure is a question competently answered by means of automatic tools, it turns out that checking the detectability of attacks is also difficult to check manually.

In this paper we show how attack detectability can be ver-ified automatically in a MAS setting. To fix the technical details, here we focus on a class of widespread security pro-tocols, e.g., authentication and key-establishment protocols and on attacks carried out on them. However our analysis can be extended to higher-level, dedicated protocols, e.g., protocols for web-services, e-voting, e-commerce etc. We only focus on the information-theoretic notion of detectabil-ity here (i.e., whether or not a group of agents has sufficient information to deduce an attack has taken place); we leave for further work the actual, protocol-dependent synthesis of communication steps to make this notion explicit.

The rest of the paper is structured as follows. Section 2 provides the required background on the formal MAS frame-work and logics used, on security protocols, and on a mod-elling of protocol executions as MAS as per [5]. Section 3 presents a taxonomy of specifications in temporal-epistemic logic formalising attack detectability in a group of agents. In Section 4 we illustrate the practical relevance of the in-troduced detectability specifications in a case study on KSL, a variant of the Kerberos protocol. Section 5 uses a recent toolkit put forward in [5] to verify automatically attack de-tectability for KSL and for other well-known security proto-cols. Finally Section 6 concludes and considers future work.

2.

INTERPRETED SYSTEMS, CTLK AND

SECURITY PROTOCOLS

Interpreted systems and temporal epistemic logic. The interpreted systems (IS) formalism [11] is a seman-tics for multiagent systems. We summarise its basic defi-nitions. We assume a set A = {1, . . . , n} of agents and a

special agent called the Environment, abbreviated E. We associate to each agent i ∈ A a set Li of possible local

states and a set Acti of local actions. A protocol function

Pi: Li→ 2Acti defines for each local state lithe set of

ac-tions enabled at li. For the environment we associate similar

sets LE, ActE, and a protocol function PE. The local

tran-sitions of agent i are defined by the evolution function ti :

Act1× . . . × Actn× ActE → 2Li×Li. The evolution function

tEof the environment is defined in a similar way. To describe

the system as a whole we define a set of possible global states G =Q

1≤i≤nLi× LE, a joint protocol P = (P1, . . . , Pn, PE),

joint actions Act = Act1× . . . × Actn× ActE, a global

evolu-tion funcevolu-tion t = (t1, . . . , tn, tE) operating on global states.

An interpreted system is a tuple I = ˙G, P , t, I0, V¸,

where I0 ⊂ G is a set of initial global states describing the

initialization of the system, and V : G → 2AP is a valuation function for a set of atomic propositions AP .

The joint protocol and the joint evolution function induce a transition relation between any two possible global states. A (computation) path is a sequence of global states in which each two adjacent states are in the transition relation.

We associate to each agent i an epistemic indistinguisha-bility relation over global states ∼i⊆ G×G such that g ∼ig0

iff gi= g0i, agent i is in the same local state in both g and g 0

. In more detail, the relation ∼i denotes that agent i cannot

differentiate between states g and g0 as it holds the same information gior g0iat each of the two states. For groups of

agents G ⊆ A, the indistinguishability relation is extended naturally to g ∼Gg0. Global state g is indistinguishable by

group G from global state g0 iff by using the information of all members of the group, the states (still) cannot be differ-entiated: g ∼Gg0iff g ∼ig0, for each agent i member of the

group G.

We use a logic that combines a fragment of branching– time logic CTL and the modal system S5nwith a knowledge

operator Kifor each agent i and a group–knowledge

opera-tor D_G for each group G of agents. Formally, our language L is defined as follows:

ϕ, ψ := p | ¬ϕ | ϕ ∧ ψ | Kiϕ | DGϕ | AG ϕ | AF ϕ | A(ϕW ψ),

where p ranges over atomic propositions in AP . The knowl-edge operators Kiand DGare read “agent i knows that” and

“the group G of agents collectively knows that” respectively. The CTL quantifier over paths A is read “along every com-putation path”. The path–specific quantifiers G, F and W are read “always”, “eventually” and “(weak) until ” or “unless” respectively.

We give some examples of interpreting formulae in the language L over the IS semantics. Consider an arbitrary IS model I. For instance, satisfaction under I of the CTL formula A(φ W ψ) in L is as follows: (I, g) |= A(φ W ψ) iff for all paths g0, g1, . . . in I with g = g0 it holds that

(I, gi) |= ψ and (I, gj) |= φ for some i ≥ 0 and for all j ≤ i

or, it holds that (I, gi) |= φ for all i ≥ 0. Another example

of satisfaction under I is that of epistemic formula DGφ in

L, as follows: (I, g) |= DGφ iff for all states g0 such that

g ∼Gg0it holds that (I, g0) |= φ.

Security protocols. A security protocol specifies a se-quence of data exchanges aimed at delivering some security related goal through the use of cryptographic primitives. Security protocols are often described using informal Al-ice&Bob notation [22]. To illustrate, consider the AlAl-ice&Bob notation for the well–known Needham Schroeder Public Key

(NSPK) protocol [20]:

1. A → B : {A, NA}pub(B)

2. B → A : {NA, NB}pub(A)

3. A → B : {NB}pub(B)

Two protocol roles are implied by the NSPK description: the role of A and the role of B. A participant playing the role of A encrypts its name and its nonce1 NA with the

public key pub(B) of a B–role participant, and sends the resulting encryption {A, NA}pub(B) to this B–role

partici-pant. The participant playing the role of A then waits for a message encrypted with its own public key pub(A), contain-ing its own nonce NA and a new nonce NB. Following this,

the participant proceeds in his A–role by encrypting the re-ceived nonce NB with the public key pub(B) and sending

this encryption back to NB’s originator, the B–role player.

Dually to an A–role, the first action of a participant playing a B–role is awaiting for a message encrypted with its own public key pub(B), etc.

A protocol is equipped at design time with a number of security requirements. These depict the purpose of the pro-tocol: authentication, secrecy, anonymity, etc. For example, a custom authentication requirement for NSPK is that when the participant playing the B–role has performed all its three steps it knows with whom it shares values NA and NB.

Interpreted system protocol–model. The Alice&Bob notation describes the sequence of messages exchanged dur-ing a sdur-ingle protocol session executed between honest partic-ipants. In contrast, participants in deployed protocols may engage simultaneously in multiple, parallel sessions with dif-ferent interlocutors. In more detail, the same identity may be simultaneously a participant in several sessions, playing a distinct role in each, manipulating different data, multiple keys etc. Moreover, it is assumed that all deployed proto-cols are executed in a hostile environment. In order to sub-vert the protocol, an intruder can always intercept messages, manipulate data (e.g., encrypt, decrypt, sign and generate nonces), challenge participants to engage in multiple sessions and to persue certain actions etc.

Given the above, we view multisession executions of pro-tocols as a multiagent system. Each agent is characterized by his identity, the principal whom he represents, and by his role, the protocol role that it plays. A model for a possible NSPK multisession execution includes two agents represent-ing principal alice and two agents representrepresent-ing principal bob; one of the agents identified as alice plays the A–role while the other agent of alice’s plays the B–role. Similarly for bob’s agents. Along the lines of [5], we formalise this MAS model for protocol executions by associating an interpreted system semantics to it:

• The local state of an agent contains the variables that appear in the role played by the agent, e.g., variables A, B, NA and NB for the A-role of NSPK protocol.

In addition, the local state includes a counter variable Step which indicates at what step in the protocol ex-ecution the agent is.

• The local protocol of an agent is defined according to the underlying role of the agent: at a certain step, the protocol selects an action either of sending or of receiving a message.

1

• The local evolution function specifies the update of the local state as messages are sent and received. For ex-ample in the case of NSPK, if agent ag is playing the role of A and ag receives the encryption {(v1, v2)}v3

at step 2, then her evolution function first dictates the check whether v3received is indeed her public key, then

the check whether v1 received is indeed the value

pre-viously sent by ag as NA. If these checks succeed, the

evolution function sets the value of ag’s local variable NB to the value v2 received and increments her local

Step variable.

• The Environment encodes a Dolev-Yao [7] intruder that controls the communication medium: the intruder can intercept and insert messages on the medium, but can only perform cryptographic operations (encrypt, decrypt, sign, etc.) if it has the relevant keys. Security requirements and attacks. Security require-ments are most often formalised as simple invariants (state predicates). In this paper, we assume that each security requirement of interest appears as an atomic proposition p in the interpreted system protocol model, but we leave the interpretation open. We emphasise however that the detectability specifications introduced in the next section apply equally to more complex, temporal–epistemic require-ments for privacy, receipt-freeness, etc.

Authentication requirement. A standard formulation for an authentication requirement is: whenever an agent i has performed (at least) N execution steps, there is a different agent j that agrees with agent i on the values of variables in a selected set Ξ

auth@N (i, Ξ) =df i.Step ≥ N →

_

j

agree(i, j, Ξ) where j ranges over agents different from i and agree(i, j, Ξ) abbreviates V

X∈Ξ

(i.X = j.X). We will implicitly assume that Ξ includes variables for the intended communication part-ners. For example, for NSPK auth@3(i, {NA}) abbreviates

auth@3(i, {A, B, NA}). This denotes that once all three

exe-cution steps of agent i have been completed, the agent shares the value i.NAwith its intended communication partner.

An attack against a security requirement p is an execution trace that refutes p. We say that an attack on p has occurred whenever p fails in the above sense.

Attack on authentication. An attack on the authentica-tion requirement auth@N (i, Ξ) has occurred if and only if there is an execution where agent i has completed N steps and there is no other agent j that agrees with i on the vari-ables Ξ:

i.Step ≥ N ∧ ¬_

j

agree(i, j, Ξ)

Intended goals and pre–goals. For each protocol a set of security requirements is explicitly specified at design time. These stipulate the intended goals of the protocol. In this sense, an attack on any of these is an attack on the protocol. Typically the intended goals of a protocol concern the final state of agents in some execution, e.g., the requirement auth@3(i, {NA, NB}) illustrated above for

NSPK.

However, intended goals are achieved gradually through-out a protocol execution. If an intended goal holds at a final step of an agent in an execution, it is expected that meaning-ful parts of that goal held at some intermediate steps of the agent, i.e., previously in that execution. We use pre-goals to denote (implicit) requirements that express parts of in-tended goals considered at intermediate execution steps. We illustrate below a possible derivation method for pre–goals given the protocol description and the intended goals. Derivation of pre-goals. Assume the set of intended goals includes the authentication requirement auth@N (i, Ξ). We derive a pre–goal auth@N0(i, Ξ0) for each N0 ≤ N and each subset Ξ0 ⊆ Ξ of variables which are set in the lo-cal states of agent i at step N0. For example, assume that auth@3(i, {NA, NB}) is given as an intended goal for NSPK.

Then auth@1(i, {NA}) is a pre–goal for the protocol derived

as above. It denotes that once the first step of agent i has been completed, the agent is expected to share the nonce NA with its intended communication partner.

We will assume that if a pre–goal fails it is impossible that the protocol will eventually complete successfully. In more detail, for a protocol with the intended goals Γ and one pre– goal p we assume that:

AG (¬ p → AG (end → ¬Γ)) (1)

where end says that agents have completed all their protocol steps, and ¬Γ says that at least one requirement in Γ fails. In light of property (1) it seems reasonable to consider also failures of pre–goals as protocol failures.

3.

DETECTABILITY

OF

PROTOCOL

FAILURES

It is not uncommon to find insecure protocols deployed in applications. For instance, IPSec, WEP, GSM, DNS, SSH1, Kerberos have all been shown to be susceptible to attacks, but are still widely used. Often, the cost of updating already deployed systems might outweigh the risk of attacks. Once a security protocol is found to be open to attacks a new question arises: are attacks detectable? In security it is as-sumed that an attack on a protocol leaves the agent subject to the assault without sufficient information to determine an attack has taken place. However, attacks may leave the group G of agents with sufficient collective information to infer an attack has taken place.

The relevant group G of information-sharing agents de-pends on the particular scenario. The most natural candi-date is a group of agents that represent the same principal. This group models the concurrent protocol sessions run by the same user on the same machine. But other groups may also be of interest. For instance, one might wish to consider only the subgroup of agents that represent the same princi-pal and play the same protocol role. The group may model a software client that collects information from different ses-sions (e.g., a user running the SSH protocol on the client side in two different terminals). In fact, one may even con-sider a group of agents that represent different principals. These groups are most relevant from the point of view of a protocol attacker. The attacker would be interested in a guarantee that he will remain undetectable no matter what information is subsequently exchanged between honest par-ticipants. Indeed, attacks that are in principle detectable

by a certain group can lead to retaliations undesired by the attacker. As argued in [12], this fact can act as deterrence.

In this section we use temporal–epistemic logic to for-malise subtle differences in the ability of a group G to detect attacks and other protocol failures. Are attacks eventually detectable on all possible future paths, or just on some? Are attacks detectable without the intruder knowing this? Can attack–related failures be immediately detected and can at-tacks therefore be detected prior to their actual completion? In future sections, the meaning of these specifications will be explicitly denoted in MAS environments and their cor-responding formulae will be checked against formal MAS models for protocol executions.

Attack detectability.

We consider attack detectability specifications of the form:

AG (β →2 β) (2)

where the modality 2 is generated by the grammar: 2 ::= DG| AF DG| EF DG| ¬2

and the condition β expresses that a “bad” state has been reached. In the most basic case is β ::= ¬p and it states that there has been an attack on an intended security goal p. Below we consider more complex conditions β.

We say that condition β is instantly detectable by group G if whenever β holds the group G knows this:

AG (β → D_Gβ) (3)

We say that β is eventually detectable if whenever β holds the group G will eventually know this:2

AG (β → AF D_Gβ) (4)

We say that β is possibly detectable if whenever β holds it is possible that the group G will eventually know this:

AG (β → EF DGβ) (5)

We say that β is instantly undetectable if whenever β holds the group G does not know this:

AG (β → (¬DG) β) (6)

We say that β is possibly undetectable if whenever β holds it is possible that the group G will never know this:

AG (β → ( ¬(AF D_G) ) β) (7)

We say that β is forever undetectable if whenever β holds the group G will never know this:

AG (β → ( ¬(EF D_G) ) β) (8)

Specifications (3) - (8) exhaust the modalities2 up to logical equivalence. Clearly, the logical–strength decreases in speci-fications (3) to (5) while it increases in (6) to (8). Moreover, for detectability specifications (3) - (5) the logical–strength decreases with larger groups G. On the other hand, for (un)detectability specifications (6) - (8) the logical–strength decreases with more inclusive groups G.

2

It is a customary assumption in the Dolev–Yao model that the intruder is able to block messages. However, this is not reasonable in all protocols, e.g., wireless protocols. Thus, we sometimes restrict the path quantifiers to paths that are fair in the sense that agents complete all their protocol steps.

Simple attack–detectability. The most basic condi-tions β are of type β ::= ¬ Γ. This denotes that some se-curity requirement p from a selected set Γ of requirements fails. Note that in specifications we identify the set Γ with the conjunction of the requirements included in the set. The detectability schema (2) then becomes:

AG (¬ Γ →2 ¬ Γ)

stating that attacks on the security requirements Γ are instantly/eventually/possibly detectable or in-stantly/possibly/forever undetectable by the group G.

The selected set Γ of requirements might include only the intended security goals of the protocol being analysed. How-ever, it may be of interest to include also pre–goals in Γ; failure of an such goal signals that the intruder is mounting an attack and the protocol will not complete successfully.

Culprit–detectability. Some attacks on security proto-cols require that the intruder is an “insider”: the intruder knows from the outset the private keys and/or signatures of some corrupt principal. If honest agents can detect the identity of this corrupt principal then retaliation actions can be more precisely targeted, strengthening the deterrence.

We consider therefore instances of (3) - (8) in which the condition β states that a certain principal identity v is corrupt: β ::= ¬ Γ ∧ corrupt(v). The atomic proposi-tion corrupt(v) holds if the intruder started the current run knowing the private key of the principal with identity v. 3

In particular, the condition (¬ Γ ∧ corrupt(v)) is possibly detectable if:

AG (¬ Γ ∧ corrupt(v) → EF DG(¬ Γ ∧ corrupt(v))) (9)

i.e., whenever requirements Γ are attacked and v is corrupt it is possible for group G to know this eventually.

Nested attack–detectability. It seems reasonable to assume that possible culprit detectability (9), or even the weaker possible attack–detectability (5) for β ::= ¬ Γ achieve an adequate deterrence in many possible scenarios. Moreover, the perspective of being able to know whether his attack have been detected can influnce future actions of the intruder. Namely, the attacker could prepare for possible retaliations. In other words, if the attacker is assured that he will always know when he is detectable, he may be more willing to conduct attacks.

Thus, we consider instances of schema (2) where the “bad” states defined by β are those states in which an attack is detectable:

β ::= 2 ¬ Γ | 2(¬ Γ ∧ corrupt(v))

where the attack–modality 2 includes no negations. Intu-itively, β defines states that are “bad” from the point of view of an attacker (i.e., his actions are detectable). To illustrate, consider the states given by β ::= DG¬ Γ, “bad” states in

which an attack on requirements Γ is detectable by a group G of “honest” agents. Then, condition β itself is instantly detectable by another group G0 of “hostile” agents if:

AG (D_G¬ Γ → D_G0D G¬ Γ)

3

For ease of presentation, we assume that there is at most one corrupt principal in any run of the system I. More-over, we assume that the name of the corrupt principal is randomised in each run. In this way the corrupt identity is initially unknown to honest agents.

i.e., whenever the “honest” group G knows that there is an attack on requirements Γ, the “hostile” group G0 knows that the “honest” group G knows this. Another more complex instance of schema (2) views the states given by β ::= AF DG¬ Γ. These are “bad” states in which an attack

on requirements Γ is eventually detectable by the group G of “honest” agents. Then, condition β is instantly detectable by another group G0 of “hostile” agents if:

AG (AF D_G¬ Γ → D_G0AF D_G¬ Γ)

i.e., whenever it is the case that the “honest” group G will eventually know that there is an attack on requirements Γ, the “hostile” group G0 knows that the “honest” group G knows this.

Above we illustrated on the “hostile” group G0 being able to detect states that are “bad” from their point of view. However, it is of interest to consider whether the “hos-tile” group G0 can also detect states that are “good” from their perspective. For instance, consider the states in which attacks are undetectable by the “honest” group G. To this end we assume conditions β with a negative attack– modality2 (i.e., a modality with an odd number of nega-tions). For example, consider the states given by the condi-tion β ::= ( ¬(EF DG) )¬ Γ, “good” states in which an attack

on requirements Γ is forever undetectable by the group G of “honest” agents. Then, this condition β is eventually de-tectable by the group G0of “hostile” agents if:

AG ( ¬(EF DG) ¬ Γ → AF DG0 ¬(EF DG) ¬ Γ)

i.e., whenever it is the case that the “honest” group G will never know that there is an attack on requirements Γ, the “hostile” group G0eventually knows that the “honest” group

G will never know this.

Attack–launch detectability.

It might be the case that neither attacks on intended goals Γ nor attacks on pre–goals Γ0are detectable, not even possi-bly detectable. Nevertheless, attacks on the intended goals Γ might be observable in a weaker sense: an attack on the in-tended goals Γ cannot be mounted without the group learn-ing in the meanwhile that some pre–goal in Γ0 fails.

We say that attacks on pre–goals Γ0 signal attacks on in-tended goals Γ to group G if requirements Γ hold at least until the group G knows that requirements Γ0 fail:

A (Γ W D_G¬ Γ0) (10)

Note that attack–launch detectability (10) does not reduce to an attack detectability specification (2). In particular (10) may hold even if attacks on the pre–goals Γ0 are not possibly detectable (5) by the group G.

If attacks on the pre–goals Γ0 signal attacks on the in-tended goals in Γ we can conclude that the flawed protocol can be “patched” with the epistemic test D_G¬ Γ0

. For in-stance, a possible fix is for agents in G to abort as soon as D_G¬ Γ0. Several flawed protocols have been “patched” in a similar way [17], but with non-epistemic tests that compare values across agents representing the same principal. Find-ing the appropriate non-epistemic tests can be non–trivial. By contrast, the relevant set Γ0 of pre–goals can be derived automatically with little cost from the protocol description, as illustrated in Section 2.

4.

CASE STUDY: KSL

In this section we illustrate a case study on detectability of assaults against KSL [14], a variant of the Kerberos proto-col. The next section reports on a framework for automatic analysis of detectability specifications. Some of the results in this section were provided by the automatic methodology aforementioned.

The KSL protocol was designed with two distinct levels. In the first level, a key establishment level, two parties A and B use a trusted server S to establish a session key Kab and a ticket. We refer to [14] for details. The key and ticket are employed in the second level in order to mutually authenticate A and B in three simple message exchanges. The second level is a repeated authentication level since it can be run several times, until the ticket expires.

1. A -> B : Ma, {Tb,A,Kab}Kbb 2. B -> A : {Ma}Kab, Mb 3. A -> B : {Mb}Kab

In step 1 principal A sends to B a nonce challenge M a and the ticket {T b, A, Kab}Kbb established during the first level. This ticket contains a timestamp T b, the identity A and the session key Kab also established in level one. All these are locked with Kbb, a key known only by B. If the timestamp T b inside the ticket received by B has not expired yet, then B responds in step 2 by encrypting the nonce M a using the preestablished session key Kab. B also sends along a nonce challenge M b of her own, which A then returns encrypted with the session key Kab in step 3.

The purpose of KSL’s second–level is to ensure that when an agent playing the role of B completes all its steps it then shares the nonces M a and M b with its intended commu-nication partner. Therefore, we consider the intended au-thentication goal auth@3(ag, {M a, M b}) for each agent ag playing the B–role in the second-level.

The Hwang attack.

The following attack on the repeated authentication level is due to Hwang [13]:

i.1. I(A) -> B : Ma, {Tb,A,Kab}Kbb i.2. B -> I(A): {Ma}Kab, Mb ii.1. I(A) -> B : Mb, {Tb,A,Kab}Kbb ii.2. B -> I(A) : {Mb}Kab, Mb’ i.3. I(A) -> B : {Mb}Kab

This attack assumes a first–level session completed between principals alice and bob, playing an A–role and a B–role respectively. On these grounds, the intruder impersonates alice and initiates a second–level session i with bob. The intruder has previously intercepted a B–role ticket in the precedent first–level communication and in step i.1 sends this ticket together with a nonce M a to bob. In step i.2, bob responds according to his honest B–role by sending the nonce M a encrypted with the session key Kab and the challenge–nonce M b to his assumed A–role interlocutor. In-stead of completing this session, the intruder impersonates alice again and initiates yet another second–level session ii with bob. In this second session ii, the intruder uses bob as an oracle to encrypt his own challenge–nonce M b from the initial i session. The intruder finally inserts the oracled en-cryption {M b}Kab back into session i as if it were coming from alice, thus completing bob’s initial session in step i.3.

Informally, bob is fooled into believing that in session i he is sharing values M a and M b respectively with alice, while in fact he has been interacting with the intruder impersonating alice. Formally, KSL’s authentication goal auth@3(ag, {M a, M b}) fails for bob’s agent ag engaged in session i.

Following the formalism in [5] and summarised in Sec-tion 2, we consider a MAS model I to formalise KSL multi-session executions.

Attack–launch detectability. On the MAS model I, we can show that principal bob can detect preparations for the attack prior to its actual completion. More precisely, attacks on the pre–goal of authentication upon M a at step 1 signals to bob attacks on the intended goal of authentica-tion upon M a and M b at step 3. Formally, the intended au-thentication goal holds at least until bob’s agents collectively have sufficient information to infer that in one session, one of these agents received a replayed nonce for an expectedly fresh M a. In other words, the corresponding attack–launch detectability formula that holds on the IS model I is:

A (auth@3({M a, M b}) W Dbob¬ auth@1(M a)) (11)

where Dbob is the distributed knowledge modality DG for

the group G of agents representing bob and playing the B– role in the second level, auth@3({M a, M b}) abbreviates the the set {auth@3(ag, {M a, M b}) | ag ∈ G} of intended goals, and auth@1(M a) operates analogously for the pre–goals. To explain, the group G of bob’s agents can compare the value of M b in each group member with the value of M a in each other group member; there has been an attack on auth@1(M a) if two values collide. Particularly, the epis-temic test Dbob¬ auth@1(M a) can be reduced to the non–

epistemic test:

∃ag, ag0∈ G | ag.M b = ag0.M b

which in turn translates (11) into a purely temporal prop-erty. However, the reduction of Dbob¬ auth@1(M a) to a

non-epistemic test is specific to a particular protocol and may be non-trivial to determine. By contrast, attack–launch specifications like (11) can be generated automatically as ex-plained in Section 3 and later shown in Section 5.

Eventual attack–detectability. Despite attack–launch detectability specification (11), attacks on the intended goals auth@3({M a, M b}) are not instantly detectable by bob in the sense of specification (3). In the MAS system I, the attack–trace i.1 – i.3 for the Hwang attack above is indis-tinguishable to bob from an execution trace in which the intruder does not impersonate alice. This counterexample trace of system I is shown below:

Counterexample E1

Trace of I, counterexample for DG¬auth@3({M a, M b}))

i’.1 A -> B: {Tb,A,Kab}Kbb, Ma i’.2 B -> A: Mb, {Ma}Kab

ii’.1 I(A) -> B: {Tb,A,Kab}Kbb, Mb ii’.2 B -> I(A): Mb’, {Mb}Kab i’.3 A -> B: {Mb}Kab

We briefly explain the above execution exhibited in the model I. As in the Hwang attack, the nonce M b of bob’s agent from the first session i0 is replayed to the agent rep-resenting bob in another session ii0. The trace is therefore indistinguishable to bob from the Hwang attack. Moreover,

note that in session i0of the counterexample–execution prin-cipal bob authenticates himself correctly upon values M a and M b with alice.

Nonetheless, we can show that attacks on the intended goals auth@3({M a, M b}) are eventually detectable by bob. In other words, the following attack–launch detectability for-mula holds on the IS model I:

AG (¬ auth@3({M a, M b}) → AF Dbob¬ auth@3({M a, M b}))

where the AF –modality quantifies only over execution paths that are fair in the sense that each agent eventually com-pletes all its steps.

We briefly explain the eventual detectability by bob in the above. Assume that bob’s agent used as an oracle in ses-sion ii of the Hwang attack has completed his execution. By comparing the nonce received in this session with the nonce generated in his first session i by another agent of his, principal bob can infer than the nonce received did not originate from alice as it purports to do. In other words, bob’s agents collectively know that bob has completed ses-sion ii without agreeing with alice, i.e., bob knows that the intended authentication goal has been attacked.

The Lowe attack.

The discussion above assumes that a KSL principal does not engage in the second level prior to completing all the steps of the first level. However, KSL has also been in-terpreted [17] as a protocol that allows a principal playing the B–role to engage in a second–level session as soon as a ticket has been established, but before actually completing the final challenge–response step of the protocol’s first–level. Again we refer to [14] for details.

As shown by Lowe, this permits more attacks against KSL. For instance, alice can be fooled into generating a B–role ticket {T a, bob, Kab}Kaa and bob also be fooled into generating another B–role ticket {T b, alice, Kab}Kbb with both tickets based on the same session key Kab. These can then be used by the intruder for an impersonation attack on the second level:

i.1. I(A) -> B : {Tb,A,Kab}Kbb, Ma i.2. B -> I(A) : Mb, {Ma}Kab ii.1. I(B) -> A : {Ta,B,Kab}Kaa, Mb ii.2. A -> I(B) : Ma’, {Mb}Kab i.3. I(A) -> B : {Mb}Kab

The attack begins like the Hwang attack above: the intruder impersonates alice to enter second–level session i with bob. However, in order to encrypt the nonce challenge M b with the session–key Kab the intruder does not use another agent representing bob as oracle like in Hwang attack. Instead, in step ii.1 the intruder engages an agent representing alice and playing the B–role. The intruder finally completes session i with bob in step i.3 by forwarding nonce M b as previously encrypted by alice in ii.2. We refer to the [13, 6] for details. Like in the Hwang attack the agent representing bob in ses-sion i is fooled into believing that he is sharing the values M a and M b with alice.

We consider now a MAS model I formalising KSL mul-tisession executions upon the relaxed interpretation in [17] described above, i.e., possible initiation of second–level KSL runs without full completion of prior KSL first level sessions. Instant attack–detectability. On the MAS model I we can show that the Lowe attack is instantly detectable by

a subgroup of agents representing principals bob and alice together. More precisely, the group G of all second–level agents can instantly detect attacks on the intended authen-tication goals. In other words, the following detectability formula holds on the IS model I:

AG (¬auth@3({M a, M b}) → DG¬auth@3({M a, M b}))

In other words, by comparing values between group mem-bers the group can (trivially) deduce whether any one group member is fooled into completing the second-level without agreeing with any other agent.

Possible attack–undetectability. On the MAS model I we can show that the Lowe attack is possibly undetectable by principal bob alone. More precisely, attacks on the in-tended goals auth@3({M a, M b}) for bob’s agents are possi-bly undetectable by the common effort of all bob’s agents. In other words, the following (un)detectability formula holds on the IS model I:

AG (¬auth@3({M a, M b}) → ¬AF Dbob¬auth@3({M a, M b}))

Under the MAS model I if the intruder conducts the Lowe attack, then the resulting trace is indistinguishable to the group of bob’s agents from a trace in which there is no at-tack on the intended authentication goal. Unlike during the Hwang attack, in the Lowe attack the challenge nonce M b of one of bob’s agents is replayed to an agent representing alice rather than back to one of bob’s agents. Thus, there is no way for bob to observe this replay even at later stages.

However it is not the case that attacks on the intended goals auth@3({M a, M b}) are forever undetectable by bob in the sense of (8). Since the Hwang attack is possible also under this relaxed interpretation of KSL, there exists a path where bob’s undetection is eventually refuted.

Nested detectability. On the MAS model I we can show that even though attacks on the intended goals are not always undetectable by bob, whenever they are undetectable the intruder knows this is so. In other words, the following (nested) detectability formula holds on the IS model I:

AG (¬Dbob¬auth@3({M a, M b}) →

DI¬Dbob¬auth@3({M a, M b})

stating that the “good–from–the–intruder–point–of–view” states given by ¬Dbob¬auth@3({M a, M b}) are instantly

de-tectable by the intruder.

5.

EXPERIMENTS

In this section we report on an automatic approach to checking attack detectability in a variety of protocols. The results here presented generalise the ones discussed for KSL in the preceeding section.

Tools employed. PD2IS (Protocol Descriptions to Inter-preted Systems) [5] is an open source compiler from CAPSL [8] protocol descriptions into ISPL (Interpreted System Pro-gramming Language), the input language to the model checker MCMAS [15]. MCMAS is a BDD-based symbolic model checker for multiagent systems supporting temporal epistemic specifications.

In addition to CTLK security requirements which PD2IS already supported, we extended the tool to generate CTLK formulae encoding attack, attack-launch and culprit (un)detectability specifications described in section 3.

By doing so, we have produced an extended toolkit [21] that automatically analyses attack detection properties for protocols given in the CAPSL language.

Experiment design and results. We selected a set of well known authentication and key establishment protocols from the SPORE repository [6]. Given a CAPSL protocol description we used PD2IS to generate a corresponding ISPL file for each instantiation scenario with four or fewer ses-sions; each generated ISPL file was then passed to MCMAS for verification. For each protocol we selected the models that exhibited attacks and analysed the output of MCMAS for what concerns satisfiability of the detectability specifi-cations. Some of these results are summarised in Table 5.

Det Undet Launch Culprit

Scenario Groups

NSPK a F possible F possible

a1→ I b1 F forever F F

a1← b1

a1, b eventual possible T eventual a2→ b1

a, b eventual possible T eventual

WMF a F forever N/A N/A

a1→ S1

b F forever N/A N/A

S1 → b1

a, b eventual instant N/A N/A

I → b1 S, b eventual possible T eventual

A. S-RPC a instant F F N/A

a1_{→ b}1 _a2 _{F possible N/A N/A}

a2→ b2 b F forever F N/A a2, b2 instant F T N/A KSL a F forever F N/A a1→ b1 1 a1 F forever F N/A a1 1 → S b F possible T N/A a1 2

← b1 _a1_{, b eventual instant T N/A}

a1← b2 2

a2, b F possible T N/A

a2→ b2 3

a, b eventual F T N/A

Table 1: Attack detectability results.

In the table the first column denotes the scenario con-sidered (see below); the second column denotes the de-tectability group G considered; the third column reports on whether attacks were found to be detectable instantly, eventually, possibly, or never detectable (“F”) by the group G considered; the forth column reports on whether attacks were found to be undetectable instantly, possibly, or for-ever detectable; the fifth column states the satisfaction of detectability of attacks on pre-goals where it applies; the last column reports the results for satisfaction of culprit de-tectability formulae. “N/A” signifies that the corresponding detectability specification does not apply for the correspond-ing protocol or the correspondcorrespond-ing group.

In more detail, in the first column the notation a1→ I in-dicates that the NSPK scenario considered includes an agent a1 representing principal alice in session 1 communicating with a corrupt insider I. Analogously, a2→ b2

indicates that the scenario also includes an agent a2_{representing principal}

alice in session 2 communicating with an agent representing bob. The notation → in the KSL scenario denotes a com-i munication direction within level i of the protocol. 4 The

4_{We assume the classical interpretation of level interleaving}

letter S in the WMF scenario represents the server identity. The letters a and b in the second column denote the groups of all agents representing alice and bob respectively.

The table does not report the verification time of the toolkit. These were found not to be problematic for the protocols considered whenever the number of instances was kept to a practically useful number. As an example, check-ing NSPK [16] with 4 agents in a communication settcheck-ing enabling the Lowe attack against 218 specifications took approximately 21 seconds on an Intel Core 2 Duo clocked at 2.26GHz with 2.9 GB of memory, running Linux ker-nel 2.6.27.7. The corresponding number of reachable global states was in the region of 103.

6.

CONCLUSIONS

In this paper we have formalised the notion of detectabil-ity of attacks against securdetectabil-ity protocols in a MAS set-ting. We showed the applicability of different flavours of detectability on a MAS model for KSL, a variant of the Kerberos protocol. We reported on the results of model-checking automatically generated MAS models for security protocols against a taxonomy of detectability formulae (gen-erated inline with the models). The positive results demon-strate that detectability of attacks in MAS inspired security applications is a viable concept that can be used in more complex protocols. At a technical level, while our discus-sion was grounded on authentication and key–establishment protocols, much can be extended to attacks on higher-level protocols, such as e-voting.

Acknowledgments. The research described in this paper is partly supported by EPSRC funded project EP/E035655. The authors would like to thank Mads Dam for valuable comments on earlier drafts of this paper.

7.

REFERENCES

[1] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cu´ellar, P. Drielsma, P. H´eam, O. Kouchnarenko, J. Mantovani, S. M¨odersheim, D. von Oheimb, M. Rusinowitch, J. Santiago,

M. Turuani, L. Vigan`o, and L. Vigneron. The AVISPA tool for the automated validation of internet security protocols and applications. In Proc. of the 17th International Conference on Computer Aided Verification, pages 281–285, 2005.

[2] G. Bella, C. Longo, and L. Paulson. Verifying

second-level security protocols. In Theorem Proving in Higher Order Logics, pages 352–366. Springer, 2003. [3] B. Blanchet. An efficient cryptographic protocol

verifier based on prolog rules. In Proc. of the 14th IEEE Computer Security Foundations Workshop, pages 82–96. IEEE Computer Society Press, 2001. [4] M. Boreale and M. Buscemi. A framework for the analysis of security protocols. In Proc. of the 13th International Conference on Concurrency Theory, pages 483–498, 2002.

[5] I. Boureanu, M. Cohen, and A. Lomuscio. A compilation method for the verification of temporal-epistemic properties of cryptographic protocols. In Joint Workshop on Automated Reasoning for Security Protocol Analysis and Issues in the Theory of Security, 2009.

[6] LSV ENS Cachan. Security Protocols Open

Repository. http://www.lsv.ens-cachan.fr/spore. [7] D.Dolev and A.Yao. On the security of public-key

protocols. IEEE Transactionson Information Theory 29, pages 198–208, 1983.

[8] G. Denker and J. Millen. CAPSL integrated protocol environment. In In Proc. of DARPA Information Survivability Conference, pages 207–221. IEEE Computer Society, 2000.

[9] J. Estevez-Tapiador. Moving web services to the secure side. IEEE Distributed Systems Online, 5(1), 2004. [10] T. F´abrega, J. Herzog, and J. Guttman. Strand

spaces: Proving security protocols correct. Journal of Computer Security, 7(1):191–230, 1999.

[11] R. Fagin, J. Halpern, Y. Moses, and M. Vardi. Reasoning about Knowledge. MIT Press, 1995. [12] G.Bella, S.Bistarelli, and F.Massacci. Retaliation

against protocol attacks. Journal of Information Assurance and Security, 3:89–102, 2008.

[13] T. Hwang, N. Lee, C. Li, M. Ko, and Y. Chen. Two attacks on neuman-stubblebine authentication protocols. Information Processing Letters, 53(2):103–107, 1995.

[14] A. Kehne, J. Sch˝onw˝alder, and H. Langend˝orfer. Multiple authentications with a nonce-based protocol using generalized timestamps. In International Conference on Computer Communications, 1992. [15] A. Lomuscio, H. Qu, and F. Raimondi. MCMAS: A

model checker for the verification of multi-agent systems. Proc. of the 21th International Conference on Computer Aided Verification, 5643, 2009.

[16] G. Lowe. An attack on the Needham-Schroeder Public-Key authentication protocol. Information Processing Letters, 56(3):131–133, 1995.

[17] G. Lowe. Some new attacks upon security protocols. In , pages 162–169. Society Press, 1996.

[18] G. Lowe. Casper: A compiler for the analysis of security protocols. In Proc. of the 10th IEEE Computer Security Foundations Workshop, pages 18–30, 1997.

[19] A. Nacho and E. A¨ımeur. Building a multi-agent system for automatic negotiation in web service applications. Autonomous Agents and Multiagent Systems, International Joint Conference on, 3:1466–1467, 2004.

[20] R. Needham and M. Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21:393–399, 1978. [21] PD2IS. Protocol compilation into interpreted systems,

0.90. http://pc2is.sourceforge.net, 2009.

[22] R. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key

cryptosystems. Communications of the ACM, 21:120–126, 1978.

[23] E. Shakshuki and S. Abu-Draz. Multi-agent system architecture to trading systems. Journal of