This paper was converted on www.awesomepapers.org from LaTeX by an anonymous user.
Want to know more? Visit the Converter page.

11institutetext: School of Computing, The Australian National University, Australia 22institutetext: School of Computing, Newcastle University, NE4 5TG, UK

Using Rely/Guarantee to Pinpoint Assumptions underlying Security Protocols

Nisansala P. Yatapanage 11    Cliff B. Jones 22
Abstract

This paper explores the application of a state-based specification notation (VDM) and associated rely-guarantee ideas to security. The verification of security protocols is essential in order to ensure the absence of potential attacks. However, verification results are only valid with respect to the assumptions under which the verification was performed. These assumptions are often difficult to identify and hidden in documentation, making it unclear whether a given protocol is safe to deploy in a particular environment. Rely-guarantee ideas offer a way to reason abstractly about interference from an environment: using this approach, assumptions can be recorded and made precise. This paper investigates this approach on the Needham-Schroeder Public Key protocol and Lowe’s extension, showing that the technique can effectively uncover –and provide a way to record– the assumptions under which the protocol can withstand attacks from intruders.

Keywords:
rely/guarantee


1 Introduction

This paper is an experiment in specification and reasoning styles for security protocols; these are certainly not solved problems. Most protocol descriptions actually start with a sketch of the intended communications between “principals”; attacks are commonly handled as post facto test cases that show how specific properties might be violated — but these desirable properties are rarely made clear as a pre-specification. Moreover, protocols –even corrected ones– do not come with recorded assumptions about the behaviour of unintended (or undesired) participants. For example, in Lowe’s attack [22] on the Needham-Schroeder [24] protocol, the nonces appear to be a means-to-an-end (of authentication) but are then sometimes used as session keys. Even in [7] the roles of Authentication and Key Establishment (AKE) are not always distinct.

Protocol specification cannot be achieved simply: standard pre/post specifications record things that should be achieved by the conclusion of executions, but leakage of information is about situations that should not occur during execution. Rely-guarantee conditions (see below) were proposed to facilitate compositional development of shared-variable concurrent software but have subsequently been shown to be useful for recording assumptions about external interference from components that are not under the control of designers.

Assumptions are fundamental to establishing the viability of security protocols. This invites the question of whether rely-guarantee conditions can be useful in the formal specification and justification of security protocols; specifically, for recording the assumptions made about attackers and proving protocol safety with respect to the assumptions. This paper explores evidence for a positive answer to the question. Furthermore, it is argued that challenging the assumptions provides a method for incorporating run-time checks that facilitate a reduction of assumptions about the behaviour of miscreants in protocols.

It is well known that the original Needham-Schroeder (N-S) protocol [24] is “flawed”; but we want to identify (and record) a set of assumptions which might have resulted in the residual flaw; furthermore, we consider Gavin Lowe’s “corrected” protocol [22] and identify assumptions that appear to be made in justifying his suggested correction.

Perhaps more importantly, what protocol designers (including Needham, Schroeder and Lowe) try to do is to build checks into their designs to reduce the assumptions that are made about the behaviours of intended and unintended participants. Here again, clear recording of assumptions is imperative. Examples of assumptions include:

  1. 1.

    secret keys are never shared

  2. 2.

    brute force attacks are not economic

  3. 3.

    if α\mathit{}\alpha sends a secret under the public key of β\mathit{}\beta, β\mathit{}\beta will not leak the original secret.

  4. 4.

    if α\mathit{}\alpha sends a secret under the public key of β\mathit{}\beta, receipt of that same secret (under the public key of α\mathit{}\alpha) justifies the conclusion that any accompanying new secret must have been generated by β\mathit{}\beta.

  5. 5.

    a process is communicating with its intended recipient.

The first two of these relate narrowly to encryption; the other assumptions also relate to the content of the messages sent.

Being explicit about the assumptions is desirable because it invites discussion (and pre-deployment confirmation); it can also expose attack vectors; furthermore, it can help designers to increase the checking in a protocol and such checks can be shown to yield protocols that need less dangerous assumptions. Above all, if the claim is that a protocol manages to reduce the assumptions by adding checks, it must be worth making the assumptions explicit; furthermore, there should be a record of the argument as to correctness under the stated assumptions.

1.1 Rely-guarantee thinking

Space limitations make it impossible to describe all of the background material. The long-established VDM notation is not described here but can be studied in [18]; there is also an international standard on VDM [14].

A convenient publication outlining the rely-guarantee ideas is [12]; early papers on rely/guarantee ideas include [15, 16, 17]; an algebraic presentation and more recent references are covered in [13]. R-G was conceived as a way of decomposing a specified component into sub-components that executed concurrently. It was subsequently observed (e.g. [20]) that rely conditions could be used to describe assumptions about external components that were not being designed: they were part of the problem space. In a further development (e.g. [8]) it was shown how layered R-G conditions could be used to describe fault-tolerant systems: optimistic rely conditions are linked to optimal behaviour but useful behaviour can still be achieved under weaker assumptions.

2 Protocols

In order to verify any protocol, it is first necessary to determine what properties it is required to fulfil and, crucially, what assumptions have been made. As the specification is developed, the assumptions required for the protocol to satisfy these potential properties should be identified.

2.1 The Needham-Schroeder protocol proposal

Most protocol discussions start by listing the (expected) interactions; for example the public key version of Needham-Schroeder (N-S) is normally presented as [24]:

(a1)A:enc([A,NA],pkeym(B))(b1)B:enc([NA,NB],pkeym(A))(a2)A:enc([NB],pkeym(B))\mathit{}(a1)A:enc([A,NA],pkeym(B))\newline (b1)B:enc([NA,NB],pkeym(A))\newline (a2)A:enc([NB],pkeym(B))

User A\mathit{}A initiates the protocol by sending a message (a1\mathit{}a1) to some other participant, B\mathit{}B. This message, encrypted with the public key of B\mathit{}B, contains A\mathit{}A’s identity and a fresh nonce, NA\mathit{}NA. The intended recipient, B\mathit{}B, replies with a message b1\mathit{}b1 encrypted with the public key of the user whose identity was in message a1\mathit{}a1 (i.e. A\mathit{}A) containing both NA\mathit{}NA, as confirmation of having read the a1\mathit{}a1 message and a new nonce, NB\mathit{}NB. Finally, A\mathit{}A replies with a2\mathit{}a2 (encrypted with the public key of B\mathit{}B) containing NB\mathit{}NB to confirm receipt of b1\mathit{}b1. In addition, there are implied aborts in situations where the expected nonces in messages b1\mathit{}b1 or a2\mathit{}a2 are absent.

A train of thought about this exchange might be that only B\mathit{}B can decrypt a1\mathit{}a1 and therefore A\mathit{}A has evidence111We avoid terms such as “A\mathit{}A believes …” because such protocols are algorithms being followed as defined; one might choose to say that “a designer believes …”. in message b1\mathit{}b1 both that B\mathit{}B received a1\mathit{}a1 and that NB\mathit{}NB was created by B\mathit{}B; similarly a2\mathit{}a2 provides evidence to B\mathit{}B that A\mathit{}A received b1\mathit{}b1.

Clearly, encryption provides some level of security against attack but it is important to identify how little can be concluded: for example, B\mathit{}B has no evidence from message a1\mathit{}a1 as to who actually sent it or the uniqueness of NA\mathit{}NA; whilst A\mathit{}A has evidence from receipt of b1\mathit{}b1 that B\mathit{}B (or someone with B\mathit{}B’s secret key) must have decrypted message a1\mathit{}a1, this does not establish that no one else now has NA\mathit{}NA. Apart from the lack of specification/assumptions, it is not made explicit under what circumstances the protocol should abort.

The objective of the current paper is to make the specifications of such protocols precise — in particular, recording assumptions that are required in order to verify that the protocols satisfy their specifications.

2.2 Protocol specification

A significant and recurrent problem is the lack of precise specifications for protocols in the literature. In both the original paper by Needham and Schroeder and Lowe’s version [22], the overall goal of the protocol is never actually stated, thus making it difficult to employ formal verification.

At first it might appear that the aim is to allow two participants to share secrets that are invisible to all other users. However, this cannot be the case, as there is no way to ensure the secrecy of the messages unless both participants are guaranteed to conform to the protocol. In the presence of dishonest users, a user who legitimately receives a message can forward it to anyone else.222This seems to contrast with Lowe’s claim that the shared message nonces can be used for authentication purposes for further transactions; perhaps Lowe’s intent was that the shared nonces be used in conjunction with the confirmed identities of the participants. This could be stated as:

Conjecture 1

If a protocol session between users X\mathit{}X and Y\mathit{}Y has terminated successfully, and the nonces used for the protocol were NX\mathit{}NX and NY\mathit{}NY, then only X\mathit{}X and Y\mathit{}Y know both NX\mathit{}NX and NY\mathit{}NY.

As an alternative, it might be assumed that the aim of the N-S protocol is instead to provide some form of authentication, i.e. allowing each participant to confirm the identity of the other participant with whom they are communicating. This would appear to be the view of [7, §4.3.3] and could be stated as:

Conjecture 2

If a protocol session between users X\mathit{}X and Y\mathit{}Y has terminated successfully, then Y\mathit{}Y has confirmed the identity of X\mathit{}X, and vice versa.

Note however that at this stage it is not yet clear what “has confirmed the identity” means. This needs to be determined as the specification is developed.

As will be seen in the following sections, these conjectures only hold under strong assumptions. In the case of Conjecture 1, the required assumptions are unrealistic and this property therefore does not hold in practice for the un-modified N-S protocol (nor, in fact, the Lowe correction).

Abstract models of protocols

Any abstraction leaves out certain aspects (e.g. hiding “side-channel” attacks), while exposing other aspects. The question is whether a given model exposes the required aspects. The current authors wonder whether using process algebra channels can inadvertently hide assumptions. The temptation to base specification and verification on process algebra (CSP is used by Lowe in [23]) might be dangerous because hiding information on channels is precisely the problem that has to be solved.

The goal of the rely/guarantee approach is precisely to identify and record assumptions. In our model, all messages are visible to every user,333This makes it easy to model “man in the middle” attacks; see, for example, the discussion in the next section. but, if properly encrypted, only the intended recipient can decrypt a message. This follows the principles of the Dolev-Yao intruder model [10], often used in security protocol verification.

3 Optimistic specification (postponing encryption)

Faced with the question, “what is the spec?”, we start with a rather optimistic one: after some set of actions, two users each record that the other is their partner and they share two nonces which no one else knows (Conjectures 1 and 2). Under strong (i.e. optimistic and uncheckable) assumptions, the original N-S protocol achieves this. Tackling this case exemplifies our approach and makes a systematic questioning of the assumptions possible.

The intention is to postpone discussing encryption and to treat it as an abstraction: a message, mkMsg(ur,us,vl)\mathit{}mk-Msg(u_{r},u_{s},vl), where ur\mathit{}u_{r} is the receiver and us\mathit{}u_{s} is the sender, is assumed to be only readable by ur\mathit{}u_{r}. Employing this abstraction exposes important assumptions about the flow of information between users in the N-S protocol.444There is no claim that this is an original idea — it is for example used in [26]. Encryption as a way to achieve this abstraction is covered in §5. Postponing encryption has an additional notational advantage that the reasoning in this section is not complicated by terms of the form dec(enc())\mathit{}dec(enc(\cdots)).

3.1 Abstract state

Messages are modelled as a record containing the Uid\mathit{}Uid of the intended recipient, the sender’s Uid\mathit{}Uid and the content of the message.

Msg\mathit{}Msg ::  rec\mathit{}rec : Uid\mathit{}Uid sender\mathit{}sender : Uid\mathit{}Uid content\mathit{}content : Item\mathit{}Item^{*}

All users can access all Msg\mathit{}Msgs, so they are all in the history\mathit{}history component of the state (Σ\mathit{}\mathchar 6\relax); the rec\mathit{}rec field governs who can access the content\mathit{}content. The sender\mathit{}sender field is a “ghost variable” that is used in correctness arguments; it is not to be confused with data included in the content\mathit{}content field that can be a Uid\mathit{}Uid (but might be fraudulently set).

Item=Nonce|Uid\mathit{}Item=Nonce|Uid

Considering only one protocol exchange can be confusing since it is possible for any user process to be involved in multiple overlapping “sessions”. One example is where a “man in the middle” uses an innocent receiver to generate nonces that are replayed to an initiating user of another session. For this reason, the models below separate information by session identifiers and record the origin of nonces.

Information about User\mathit{}Users is stored in:555The secret key fields (skey:SKey\mathit{}skey:SKey) and public keys (PKey\mathit{}PKey) are discussed in Section 5.

User\mathit{}User ::  intPartner\mathit{}intPartner : SidmUid\mathit{}Sid\buildrel m\over{\longrightarrow}Uid knows\mathit{}knows : SidmNonceset\mathit{}Sid\buildrel m\over{\longrightarrow}Nonce-\hbox{\bf set\/} skey\mathit{}skey : SKey\mathit{}SKey conforms\mathit{}conforms : 𝔹\mathit{}\Bool complete\mathit{}complete : Sidm𝔹\mathit{}Sid\buildrel m\over{\longrightarrow}\Bool

User records keep track of the intended partner and whether or not the session was successful (complete\mathit{}complete is false at the beginning of a session). If user x\mathit{}x is playing the role of A\mathit{}A in the N-S protocol, then σ.users(x).intPartner\mathit{}\sigma.users(x).intPartner contains the Uid\mathit{}Uid of the user with whom x\mathit{}x intended to communicate (i.e. the user for whom A\mathit{}A encrypted a1\mathit{}a1). If the user y\mathit{}y is playing the role of B\mathit{}B in the protocol, then σ.users(y).intPartner\mathit{}\sigma.users(y).intPartner contains the Uid\mathit{}Uid of the user with whom y\mathit{}y will communicate (i.e. the Uid\mathit{}Uid given as part of the a1\mathit{}a1 message received by B\mathit{}B). The knows\mathit{}knows field keeps track of the set of nonces that a user knows, either by inventing the nonce or receiving it in a message.

Assumptions about the behaviour of other users could be recorded as rely conditions but it is more convenient to make them invariants. Note that –as in [19]– preservation of the invariant by any context becomes an extra assumption as though it were part of every rely condition and an extra obligation as though it were conjoined to every guarantee condition.

The notion of Action\mathit{}Action includes both messages and invention of nonces:

Action=Msg|Invent\mathit{}Action=Msg|Invent

Invent\mathit{}Invent ::  user\mathit{}user : Uid\mathit{}Uid\hskip 100.00015pt what\mathit{}what : Nonce\mathit{}Nonce

The following function yields the history restricted to a single user’s activities.

uHist\mathit{}uHist:\mathit{}\;\mathpunct{:}\, Action×UidAction\mathit{}Action^{*}\times Uid\penalty-100\rightarrow Action^{*}

uHist(as,user) if =as[] then [] else if hdasMsg((hdas).rec=user(hdas).sender=user) then [hdas]uHist(tlas,user) else if hdasInvent(hdas).=useruser then [hdas]uHist(tlas,user) else uHist(tlas,user) \mathit{}\hbox{$\mathit{}uHist$}(as,user)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \vtop{\hbox to0.0pt{\hbox{\bf if \/}\vtop{\noindent$\mathit{}as=[\,]$}\hss}\hbox to0.0pt{\hbox{\bf then \/}\vtop{\noindent$\mathit{}[\,]$}\hss}\hbox to0.0pt{\hbox{\bf else \/}\vtop{\noindent$\mathit{}{\vtop{\hbox to0.0pt{\hbox{\bf if \/}\vtop{\noindent$\mathit{}\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}\in Msg\land((\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}).rec=user\mathchar 12895\relax(\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}).sender=user)$}\hss}\hbox to0.0pt{\hbox{\bf then \/}\vtop{\noindent$\mathit{}[\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}]\mathbin{\hbox{\raise 4.30554pt\hbox{$\mathit{}\@sc@nc$}}}uHist(\hbox{\bf tl\kern 1.66672pt\/}\nobreak{as},user)$}\hss}\hbox to0.0pt{\hbox{\bf else \/}\vtop{\noindent$\mathit{}{\vtop{\hbox to0.0pt{\hbox{\bf if \/}\vtop{\noindent$\mathit{}\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}\in Invent\land(\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}).user=user$}\hss}\hbox to0.0pt{\hbox{\bf then \/}\vtop{\noindent$\mathit{}[\hbox{\bf hd\kern 1.66672pt\/}\nobreak{as}]\mathbin{\hbox{\raise 4.30554pt\hbox{$\mathit{}\@sc@nc$}}}uHist(\hbox{\bf tl\kern 1.66672pt\/}\nobreak{as},user)$}\hss}\hbox to0.0pt{\hbox{\bf else \/}\vtop{\noindent$\mathit{}uHist(\hbox{\bf tl\kern 1.66672pt\/}\nobreak{as},user)$}\hss}}}$}\hss}}}$}\hss}}

To record the overall intent of the protocol, the most abstract specification is based on a state:

Σ\mathit{}\mathchar 6\relax ::  users\mathit{}users : UidmUser\mathit{}Uid\buildrel m\over{\longrightarrow}User history\mathit{}history : Action\mathit{}Action^{*} pkeys\mathit{}pkeys : UidmPKey\mathit{}Uid\buildrel m\over{\longrightarrow}PKey

where

invΣ(σ)uniquenonces(σ.history)noreadothers(σ)udomσ.users  σ.users(u).conformsno-leaks(uHist(σ.history,u))no-forge(uHist(σ.history,u)) \mathit{}\hbox{$\mathit{}inv-\mathchar 6\relax$}(\sigma)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline unique-nonces(\sigma.history)\land no-read-others(\sigma)\land\newline \Forall u\in\hbox{\bf dom\kern 1.66672pt\/}\nobreak{\sigma.users}\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\sigma.users(u).conforms\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\newline no-leaks(uHist(\sigma.history,u))\land no-forge(uHist(\sigma.history,u))$}\hss}

The predicates used in invΣ\mathit{}inv-\mathchar 6\relax are now defined. Nonce\mathit{}Nonces are assumed to be “fresh”:666This assumption is not treated formally below but actually depends on the low probability of a clash in a sufficiently large space.

uniquenonces\mathit{}unique-nonces:\mathit{}\;\mathpunct{:}\, Action𝔹\mathit{}Action^{*}\penalty-100\rightarrow\Bool

uniquenonces(as)i,jindsas  {as(i),as(j)}Inventas(i).=whatas(j).whati=j \mathit{}\hbox{$\mathit{}unique-nonces$}(as)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \Forall i,j\in\hbox{\bf inds\kern 1.66672pt\/}\nobreak{as}\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\{as(i),as(j)\}\subseteq Invent\land as(i).what=as(j).what\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mui=j$}\hss}

The predicate noreadothers\mathit{}no-read-others records the assumption that no user can read the contents of a message other than the intended recipient (given by the rec\mathit{}rec field of the message). This is an abstract version of the idea of encryption, which is explored in Section 5.

noreadothers\mathit{}no-read-others:\mathit{}\;\mathpunct{:}\, Σ𝔹\mathit{}\mathchar 6\relax\penalty-100\rightarrow\Bool

noreadothers(σ)udomσ.users  nσ.users(u).knows mrngσ.history mInventm.=userum.what=nmMsgm.rec=unelemsm.content \mathit{}\hbox{$\mathit{}no-read-others$}(\sigma)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \Forall u\in\hbox{\bf dom\kern 1.66672pt\/}\nobreak\sigma.users\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\Forall n\in\sigma.users(u).knows\suchthat\hfil\break\hbox to399.75494pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\Exists m\in\hbox{\bf rng\kern 1.66672pt\/}\nobreak\sigma.history\suchthat\hfil\break\hbox to389.75493pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}m\in Invent\,\land\,m.user=u\,\land\,m.what=n\mathchar 12895\relax\newline m\in Msg\,\land\,m.rec=u\,\land\,n\in\hbox{\bf elems\kern 1.66672pt\/}\nobreak{m.content}$}\hss}$}\hss}$}\hss}

A predicate that limits sending of non-locally generated nonces must, however, allow their return to the believed originator. There are two ways of tackling this: the simpler employs the ghost variable field sender\mathit{}sender, which has to be a ghost variable since no user process can actually determine which user sent a Msg\mathit{}Msg.

noleaks\mathit{}no-leaks:\mathit{}\;\mathpunct{:}\, Action𝔹\mathit{}Action^{*}\penalty-100\rightarrow\Bool

noleaks(as)i,jindsas  i<jlet =-mkMsg(β,α,vli)as(i)in let =-mkMsg(γ,β,vlj)as(j)in (cNoncecelemsvlielemsvlj)γ=α \mathit{}\hbox{$\mathit{}no-leaks$}(as)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \Forall i,j\in\hbox{\bf inds\kern 1.66672pt\/}\nobreak{as}\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}i<j\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\newline \vtop{\hbox to0.0pt{\hbox{\bf let \/}\vtop{\noindent$\mathit{}mk-Msg(\beta,\alpha,vl_{i})=as(i)\hskip 5.0pt\hbox{\bf in\/}$}\hss}}\hfil\break\vtop{\hbox to0.0pt{\hbox{\bf let \/}\vtop{\noindent$\mathit{}mk-Msg(\gamma,\beta,vl_{j})=as(j)\hskip 5.0pt\hbox{\bf in\/}$}\hss}}\hfil\break({\Exists c\in Nonce}\suchthat c\in\hbox{\bf elems\kern 1.66672pt\/}\nobreak{vl_{i}\cap\hbox{\bf elems\kern 1.66672pt\/}\nobreak{vl_{j}}})\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\gamma=\alpha$}\hss}

It is however the case that no user process can ensure that noleaks\mathit{}no-leaks is satisfied precisely because it requires knowledge of the ghost field sender\mathit{}sender. An alternative noappleaks\mathit{}no-app-leaks could use the claimed sender field instead:

noappleaks\mathit{}no-app-leaks:\mathit{}\;\mathpunct{:}\, Action𝔹\mathit{}Action^{*}\penalty-100\rightarrow\Bool

noappleaks(as)i,jindsas  i<jlet mk-Msg(β,,vli)=as(i)in let mk-Msg(γ,,vlj)=as(j)in αUid,cNonce αelemsvlicelemsvlielemsvljγ=α \mathit{}\hbox{$\mathit{}no-app-leaks$}(as)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \Forall i,j\in\hbox{\bf inds\kern 1.66672pt\/}\nobreak{as}\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}i<j\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\newline \vtop{\hbox to0.0pt{\hbox{\bf let \/}\vtop{\noindent$\mathit{}mk-Msg(\beta,,vl_{i})=as(i)\hskip 5.0pt\hbox{\bf in\/}$}\hss}}\hfil\break\vtop{\hbox to0.0pt{\hbox{\bf let \/}\vtop{\noindent$\mathit{}mk-Msg(\gamma,,vl_{j})=as(j)\hskip 5.0pt\hbox{\bf in\/}$}\hss}}\hfil\break\Exists\alpha\in Uid,c\in Nonce\suchthat\hfil\break\hbox to399.75494pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\alpha\in\hbox{\bf elems\kern 1.66672pt\/}\nobreak{vl_{i}}\land c\in\hbox{\bf elems\kern 1.66672pt\/}\nobreak{vl_{i}\cap\hbox{\bf elems\kern 1.66672pt\/}\nobreak{vl_{j}}}\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\gamma=\alpha$}\hss}$}\hss}

but this requires all messages to be signed. Whilst this is true in Lowe’s extension (see Section 4.1), it is not the case in the original N-S protocol.

A predicate for ensuring that users only sign honestly is:

noforge\mathit{}no-forge:\mathit{}\;\mathpunct{:}\, Action𝔹\mathit{}Action^{*}\penalty-100\rightarrow\Bool

noforge(as)mkMsg(β,α,vl)elemsas  iindsvl vl(i)Uidvl(i)=α \mathit{}\hbox{$\mathit{}no-forge$}(as)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \Forall mk-Msg(\beta,\alpha,vl)\in\hbox{\bf elems\kern 1.66672pt\/}\nobreak{as}\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\Forall i\in\hbox{\bf inds\kern 1.66672pt\/}\nobreak{vl}\suchthat\hfil\break\hbox to399.75494pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}vl(i)\in Uid\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0muvl(i)=\alpha$}\hss}$}\hss}

The following dynamic invariant also holds on the states: this requires that nothing can change an Action\mathit{}Action that has occurred, a user’s conformity cannot change and that users retain all the information that was added to knows\mathit{}knows.

dyninv\mathit{}dyn-inv:\mathit{}\;\mathpunct{:}\, Σ×Σ𝔹\mathit{}\mathchar 6\relax\times\mathchar 6\relax\penalty-100\rightarrow\Bool

dyninv(σ,σ)σ.historyσ.historyuσ.users  sessdomσ.knows(sess) σ.users(u).knows(sess)σ.users(u).knows(sess)σ.users(u).=conformsσ.users(u).conforms \mathit{}\hbox{$\mathit{}dyn-inv$}(\sigma,\sigma^{\prime})\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \sigma.history\subseteq\sigma^{\prime}.history\land\newline \Forall u\in\sigma.users\suchthat\hfil\break\hbox to409.75496pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\Forall sess\in\hbox{\bf dom\kern 1.66672pt\/}\nobreak\sigma.knows(sess)\suchthat\hfil\break\hbox to399.75494pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\sigma.users(u).knows(sess)\subseteq\sigma^{\prime}.users(u).knows(sess)\land\newline \sigma^{\prime}.users(u).conforms=\sigma.users(u).conforms$}\hss}$}\hss}

3.2 Specification

An optimistic overall objective can be captured by the specification given in Fig. 1. The argument is that N-S and the NS(L) code satisfies this strong specification and that Lowe’s extension (see Section 4) also does something sensible (aborts) in the case of Lowe’s attack.

NS\mathit{}NS (\mathit{}(from:Uid,to:Uid,sf:Sid,st:Sid)\mathit{}from:Uid,to:Uid,sf:Sid,st:Sid)\ ext wr users\mathit{}\hbox{\bf wr \/}users : UidmUser\mathit{}Uid\buildrel m\over{\longrightarrow}User wr history\mathit{}\hbox{\bf wr \/}history : Action\mathit{}Action^{*} pre ¬users(from).complete(sf)¬users(to).complete(st)users(from).conformsusers(to).conforms\mathit{}\neg\,users(from).complete(sf)\land\neg\,users(to).complete(st)\land\newline users(from).conforms\land users(to).conforms rely noMods(users,users,from,sf)noMods(users,users,to,st)\mathit{}noMods(users,users^{\prime},from,sf)\land noMods(users,users^{\prime},to,st) guar noModsToOthers(users,users,{from,to},sf)noModsToOthers(users,users,{from,to},st)\mathit{}noModsToOthers(users,users^{\prime},\{from,to\},sf)\,\land\newline noModsToOthers(users,users^{\prime},\{from,to\},st) post users(from).intPartner(sf)=tousers(to).intPartner(st)=fromusers(from).complete(sf)users(to).complete(st)NA,NBNonce  NANB{NA,NB}users(from).knows(sf){NA,NB}users(to).knows(st)¬u(-Uid{from,to}),suSid {NA,NB}users(u).knows(su) \mathit{}users^{\prime}(from).intPartner(sf)=to\land\newline users^{\prime}(to).intPartner(st)=from\land\newline users^{\prime}(from).complete(sf)\land users^{\prime}(to).complete(st)\land\newline \Exists NA,NB\in Nonce\suchthat\hfil\break\hbox to371.61995pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}NA\neq NB\,\land\newline \{NA,NB\}\subseteq users^{\prime}(from).knows(sf)\land\newline \{NA,NB\}\subseteq users^{\prime}(to).knows(st)\land\newline \neg\,\Exists u\in(Uid\mathchar 8704\relax\{from,to\}),su\in Sid\suchthat\hfil\break\hbox to361.61993pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\{NA,NB\}\subseteq users^{\prime}(u).knows(su)$}\hss}$}\hss}

noMods\mathit{}noMods:\mathit{}\;\mathpunct{:}\, (UidmUser)×(UidmUser)×Uid×Sid𝔹\mathit{}(Uid\buildrel m\over{\longrightarrow}User)\times(Uid\buildrel m\over{\longrightarrow}User)\times Uid\times Sid\penalty-100\rightarrow\Bool

noMods(userm,userm,u,sess)userm(u).complete(sess)=userm(u).complete(sess)userm(u).intPartner(sess)=userm(u).intPartner(sess)\mathit{}\hbox{$\mathit{}noMods$}(userm,userm^{\prime},u,sess)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline userm^{\prime}(u).complete(sess)=userm(u).complete(sess)\land\newline userm^{\prime}(u).intPartner(sess)=userm(u).intPartner(sess)

noModsToOthers\mathit{}noModsToOthers:\mathit{}\;\mathpunct{:}\, (UidmUser)×(UidmUser)×Uidset×Sid𝔹\mathit{}(Uid\buildrel m\over{\longrightarrow}User)\times(Uid\buildrel m\over{\longrightarrow}User)\times Uid-\hbox{\bf set\/}\times Sid\penalty-100\rightarrow\Bool

noModsToOthers(userm,userm,good,sess)(u(domuserm-good)userm(u)=userm(u))ugood  -{sess}userm(u).=complete-{sess}userm(u).complete-{sess}userm(u).=intPartner-{sess}userm(u).intPartner \mathit{}\hbox{$\mathit{}noModsToOthers$}(userm,userm^{\prime},good,sess)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline ({\Forall u\in(\hbox{\bf dom\kern 1.66672pt\/}\nobreak{userm}\mathchar 8704\relax good)}\suchthat userm^{\prime}(u)=userm(u))\land\newline \Forall u\in good\suchthat\hfil\break\hbox to373.61996pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\{sess\}\mathbin{\hbox{$\mathit{}\hbox to0.0pt{$\mathit{}\mathord{\mathchar 8704\relax}$\hss}\mkern-1.5mu\lower 0.43057pt\hbox{$\mathit{}\lhd$}$}}userm^{\prime}(u).complete=\{sess\}\mathbin{\hbox{$\mathit{}\hbox to0.0pt{$\mathit{}\mathord{\mathchar 8704\relax}$\hss}\mkern-1.5mu\lower 0.43057pt\hbox{$\mathit{}\lhd$}$}}userm(u).complete\land\newline \{sess\}\mathbin{\hbox{$\mathit{}\hbox to0.0pt{$\mathit{}\mathord{\mathchar 8704\relax}$\hss}\mkern-1.5mu\lower 0.43057pt\hbox{$\mathit{}\lhd$}$}}userm^{\prime}(u).intPartner=\{sess\}\mathbin{\hbox{$\mathit{}\hbox to0.0pt{$\mathit{}\mathord{\mathchar 8704\relax}$\hss}\mkern-1.5mu\lower 0.43057pt\hbox{$\mathit{}\lhd$}$}}userm(u).intPartner$}\hss}

Figure 1: Specification for NS with users from/to\mathit{}from/to conforming to the protocol

3.3 Pseudo-code

The pseudo-code for NS is given in Fig. 2, which uses statements with the following semantics:
invent:history:mkInvent(me,n)\mathit{}\hbox{\bf invent\/}:history:\mathbin{\hbox{\raise 4.30554pt\hbox{$\mathit{}\@sc@nc$}}}mk-Invent(me,n) (n\mathit{}n is completely new)
send(to,b):mkMsg(to,this,b)\mathit{}\hbox{\bf send\/}(to,b):\mathbin{\hbox{\raise 4.30554pt\hbox{$\mathit{}\@sc@nc$}}}mk-Msg(to,this,b)
rcv\mathit{}\hbox{\bf rcv\/}\cdots: picks up the most recent unread Msg\mathit{}Msg whose rec\mathit{}rec field matches this\mathit{}this.
Analogous with x:+1\mathit{}x:+1, s:t\mathit{}s:\cup t sets the final value of s\mathit{}s to st\mathit{}s\cup t, etc.

sender(to):receiver()wr loc:User,s1:Sidwr loc:User,s2:Sids1s2loc.intPartner(s1)to;NAinvent;loc.knows(s1):{NA};send(to,[this,NA]);rcv(mkMsg(this,,[from,Nf]));loc.intPartner(s2)from;loc.knows(s2):{Nf};NBinvent;loc.knows(s2):{NB};send(from,[Nf,NB]);rcv(mkMsg(this,,[ret,Nt]));if retNA then abort ;loc.knows(s1):{Nt};send(to,[Nt]);loc.complete(s1)truercv(mkMsg(this,,[ret]));if retNB then abort ;loc.complete(s2)true\mathit{}\begin{array}[]{l l}sender(to):&receiver()\\ \hbox{\bf wr \/}loc:User,s1:Sid&\hbox{\bf wr \/}loc:User,s2:Sid\\ s1\leftarrow\cdots&s2\leftarrow\cdots\\ loc.intPartner(s1)\leftarrow to;\\ NA\leftarrow\hbox{\bf invent\/};\\ loc.knows(s1):\cup\{NA\};\\ \hbox{\bf send\/}(to,[this,NA]);\\ &\hbox{\bf rcv\/}(mk-Msg(this,,[from,Nf]));\\ &loc.intPartner(s2)\leftarrow from;\\ &loc.knows(s2):\cup\{Nf\};\\ &NB\leftarrow\hbox{\bf invent\/};\\ &loc.knows(s2):\cup\{NB\};\\ &\hbox{\bf send\/}(from,[Nf,NB]);\\ \hbox{\bf rcv\/}(mk-Msg(this,,[ret,Nt]));\\ \hbox{\bf if \/}ret\neq NA\hbox{\bf then abort \/};\\ loc.knows(s1):\cup\{Nt\};\\ \hbox{\bf send\/}(to,[Nt]);\\ loc.complete(s1)\leftarrow\hbox{\bf true\/}\\ &\hbox{\bf rcv\/}(mk-Msg(this,,[ret]));\\ &\hbox{\bf if \/}ret\neq NB\hbox{\bf then abort \/};\\ &loc.complete(s2)\leftarrow\hbox{\bf true\/}\end{array}


Figure 2: Distributed code for N-S

3.4 Correctness argument

The correctness of the decomposition of NS1\mathit{}NS1:

NS1=sender(to)receiver()other\mathit{}NS1=sender(to)\parallel receiver()\parallel other

is interesting because there are actually two arguments: synchronisation and that sender\mathit{}sender/receiver\mathit{}receiver are effectively running as disjoint parallel processes, but the fact that the visibility of their nonces can be shown to be kept limited needs the assumptions noleaks/noforge\mathit{}no-leaks/no-forge. Although the assumptions match for sender/receiver\mathit{}sender/receiver, these assumptions for other\mathit{}other are dangerous and are precisely the vulnerability of the N-S protocol. Crucially, there can be many other messages than the intended three, so we have to accept that these are a sub-sequence of the history\mathit{}history extension.

subseq\mathit{}subseq:\mathit{}\;\mathpunct{:}\, X×X𝔹\mathit{}X^{*}\times X^{*}\penalty-100\rightarrow\Bool

subseq(s1,s2)sel𝔹lensel=lens2select(sel,s2)=s1\mathit{}\hbox{$\mathit{}subseq$}(s1,s2)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad{\Exists sel\in\Bool^{*}}\suchthat\hbox{\bf len\kern 1.66672pt\/}\nobreak{sel}=\hbox{\bf len\kern 1.66672pt\/}\nobreak{s2}\land select(sel,s2)=s1

select\mathit{}select:\mathit{}\;\mathpunct{:}\, 𝔹×XX\mathit{}\Bool^{*}\times X^{*}\penalty-100\rightarrow X^{*}

select(sel,s) if =sel[] then [] else if hdselthen [hds]select(tlsel,tls)else select(tlsel,tls) \mathit{}\hbox{$\mathit{}select$}(sel,s)\quad\raise 2.15277pt\hbox{\footnotesize\text@underline{$\mathit{}\mathchar 12852\relax$}}\penalty-100\quad\newline \vtop{\hbox to0.0pt{\hbox{\bf if \/}\vtop{\noindent$\mathit{}sel=[\,]$}\hss}\hbox to0.0pt{\hbox{\bf then \/}\vtop{\noindent$\mathit{}[\,]$}\hss}\hbox to0.0pt{\hbox{\bf else \/}\vtop{\noindent$\mathit{}{\hbox to0.0pt{\vtop{\noindent$\mathit{}\hbox{\bf if \/}\nobreak\hbox{\bf hd\kern 1.66672pt\/}\nobreak{sel}\penalty 0\hskip 5.0pt\hbox{\bf then \/}\nobreak[\hbox{\bf hd\kern 1.66672pt\/}\nobreak{s}]\mathbin{\hbox{\raise 4.30554pt\hbox{$\mathit{}\@sc@nc$}}}select(\hbox{\bf tl\kern 1.66672pt\/}\nobreak{sel},\hbox{\bf tl\kern 1.66672pt\/}\nobreak{s})\penalty-100\hskip 5.0pt\hbox{\bf else \/}\nobreak select(\hbox{\bf tl\kern 1.66672pt\/}\nobreak{sel},\hbox{\bf tl\kern 1.66672pt\/}\nobreak{s})$}\hss}}$}\hss}} pre lensel=lens\mathit{}\hbox{\bf len\kern 1.66672pt\/}\nobreak{sel}=\hbox{\bf len\kern 1.66672pt\/}\nobreak{s}

Lemma 1

Synchronisation of the two threads in Fig. 2 follows from the semantics of the message send/rcv statements.

Proof. Providing there are no other messages, the combined code would have the same effect as the obvious combined code. If there is another message before the first rcv in receiver\mathit{}receiver, it would initiate a separate session. Because of the assumptions in noreadothers\mathit{}no-read-others, no other\mathit{}other user can generate a Msg\mathit{}Msg that is accepted by the rcv in sender\mathit{}sender. The argument is similar for the second rcv in receiver\mathit{}receiver.

Lemma 2

The invariant uniquenonces\mathit{}unique-nonces is preserved by both the sender\mathit{}sender and receiver\mathit{}receiver.

Proof. This holds because the chosen nonces are created by invent.

The dynamic invariant dyninv\mathit{}dyn-inv requires that history\mathit{}history is only extended, which is true of both processes.

Lemma 3

The obligations in invΣ\mathit{}inv-\mathchar 6\relax regarding the (non) leakage of nonces is preserved by both the sender\mathit{}sender and receiver\mathit{}receiver.

Proof. The sender\mathit{}sender operation transmits a nonce (Nt\mathit{}Nt) that it received in a Msg\mathit{}Msg, but it returns it to the Uid\mathit{}Uid from where it appeared to have been sent, and similarly for Nf\mathit{}Nf in receiver\mathit{}receiver.

Lemma 4

The obligations in invΣ\mathit{}inv-\mathchar 6\relax also include the (absence of) forgery of Uid\mathit{}Uids in Msg\mathit{}Msgs.

Proof. Only sender\mathit{}sender (in pure NS\mathit{}NS) includes a Uid\mathit{}Uid in the body of a Msg\mathit{}Msg, which is not a forgery because it sends its own Uid\mathit{}Uid (this\mathit{}this).

Lemma 5

postNS\mathit{}post-NS requires that only from/to\mathit{}from/to can have NA/NB\mathit{}NA/NB in their knows\mathit{}knows fields.

Proof: Since from/to\mathit{}from/to both have conforms\mathit{}conforms, neither can leak the nonces; it follows from noreadothers\mathit{}no-read-others that there is no other way for a mischievous user u\mathit{}u to access the nonces and uniquenonces\mathit{}unique-nonces ensures that identical nonces cannot be generated.

Fault tolerance

Lemma 6

The flag complete\mathit{}complete is not set to true if any errant messages interfere (i.e. sender\mathit{}sender or receiver\mathit{}receiver abort).

4 Lowe’s analysis

Lowe’s counterexample, described in §4.1, shows the need for precise specifications; Lowe’s fix is easy to represent in the “distributed code” with only a few minor changes to the original N-S version in Fig. 2. Lowe’s fix is also correct with respect to postNS\mathit{}post-NS. However, the assumptions embodied in invΣ\mathit{}inv-\mathchar 6\relax are unrealistic and cannot be satisfied in the presence of miscreants; §4.2 addresses this by offering a different post condition, postNS(L)FT\mathit{}post-NS(L)-FT, that holds under more relaxed and realistic assumptions. More importantly, the assumptions are spelled out.

4.1 Lowe’s attack and “correction”

The N-S protocol was accepted as being correct for 18 years before Lowe discovered an attack [22]. At first sight, Lowe’s attack:

(a1)A:enc([A,NA],pkeym(I))(d1)I:enc([A,NA],pkeym(B))(b1)B:enc([NA,NB],pkeym(A))(a2)A:enc([NB],pkeym(I))(d3)I:enc([NB],pkeym(B))\mathit{}(a1)A:enc([A,NA],pkeym(I))\newline (d1)I:enc([A,NA],pkeym(B))\newline (b1)B:enc([NA,NB],pkeym(A))\newline (a2)A:enc([NB],pkeym(I))\newline (d3)I:enc([NB],pkeym(B))

is odd in that A\mathit{}A starts by communicating with a partner who does not conform to the protocol, referred to as I\mathit{}I (for intruder) in the following. It is important to accept that A\mathit{}A intends to communicate with I\mathit{}I, unlike man-in-the-middle attacks, though A\mathit{}A does not know that I\mathit{}I is dishonest.777It is paradoxical that it is a2\mathit{}a2 that completes the intruder’s knowledge since this message was clearly intended as a confirmation. It is clear that I\mathit{}I immediately violates both of the earlier rely conditions (noleaks,noforge\mathit{}no-leaks,no-forge). Unfortunately, it is not possible to check that a recipient does not “leak” secrets (and it would also be possible for sender\mathit{}sender to leak the nonces).

Notice that Lowe’s attack is not a standard “man in the middle” anomaly in which the duped user has a separate session with the intruder. In Lowe’s attack, B\mathit{}B has evidence that their partner is A\mathit{}A; the danger here is that B\mathit{}B accepts this fact to release some information and/or take some action on the basis that A\mathit{}A is a trusted user.

The defence that Lowe suggests results in a more elaborate protocol (to which both partners have to conform) where all messages include the (encrypted) identity of the sender; this makes it possible to detect Lowe’s intruder:

(a1)A:enc([A,NA],pkeym(I))(d1)I:enc([A,NA],pkeym(B))(b1)B:enc([B,NA,NB],pkeym(A))(aabort)A detects the problem because [I,NA,NB] was expected.\mathit{}(a1)A:enc([A,NA],pkeym(I))\newline (d1)I:enc([A,NA],pkeym(B))\newline (b1^{\prime})B:enc([B,NA,NB],pkeym(A))\newline (a-abort)\newline A\hbox{ detects the problem because }[I,NA,NB]\hbox{ was expected.}

Notice that these changes are straightforward to reflect in the code shown in Fig. 2.

At first glance, Lowe’s defence appears to rely on a relatively dangerous assumption, that if a user sends their identity, it really is their Uid\mathit{}Uid (i.e. noforge\mathit{}no-forge); this is actually broken at d1\mathit{}d1 by I\mathit{}I, but its after-effects are detected at b1\mathit{}b1^{\prime}. However, the clever aspect of Lowe’s correction is in fact that it works despite the fact that dishonest users could be lying about their identity.

4.2 Specifying the extra check

The idea hinted at in §1.1 of specifying software by layers of R-G conditions can be applied to security protocols. In the case of Lowe’s extension to N-S (henceforth referred to as NSL):

  • The extended protocol above satisfies postNS\mathit{}post-NS, as in Fig. 1, under the optimistic assumptions recorded in invΣ\mathit{}inv-\mathchar 6\relax;

  • Lowe’s extension does not attempt to deliver agreement between from\mathit{}from and to\mathit{}to with weaker –more realistic– assumptions

  • What the extra self-identity in message b1\mathit{}b1 facilitates is an extra test by sender\mathit{}sender, which can detect that the message a1\mathit{}a1 is actually coming from a different user, rather than the user to whom the message was sent — this indicates that there is a miscreant involved.

Therefore, the second layer of the R-G specification must indicate that the protocol should terminate abnormally in this case. This leads to the following specification:

NS(L)FT\mathit{}NS(L)-FT (\mathit{}(from:Uid,to:Uid,sf:Sid,st:Sid)\mathit{}from:Uid,to:Uid,sf:Sid,st:Sid)\ ext wr users\mathit{}\hbox{\bf wr \/}users : UidmUser\mathit{}Uid\buildrel m\over{\longrightarrow}User wr history\mathit{}\hbox{\bf wr \/}history : Action\mathit{}Action^{*} pre users(from).conforms¬users(from).complete(sf)¬users(to).complete(st)\mathit{}users(from).conforms\land\newline \neg\,users(from).complete(sf)\land\neg\,users(to).complete(st) rely noMods(users,users,from,sf)noMods(users,users,to,st)\mathit{}noMods(users,users^{\prime},from,sf)\land noMods(users,users^{\prime},to,st) guar noModsToOthers(users,users,{from,to})\mathit{}noModsToOthers(users,users^{\prime},\{from,to\}) post NAusers(from).knows(sf)  u(-Uid{from,to}),suSid users(u).conformsNAusers(u).knows(su)users(u).intPartner(su)=from¬users(from).complete(sf) \mathit{}\Exists NA\in users^{\prime}(from).knows(sf)\suchthat\hfil\break\hbox to407.75494pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}\Exists u\in(Uid\mathchar 8704\relax\{from,to\}),su\in Sid\suchthat\hfil\break\hbox to397.75493pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}users^{\prime}(u).conforms\land\newline NA\in users^{\prime}(u).knows(su)\land\newline users^{\prime}(u).intPartner(su)=from\penalty-35\mskip 6.0mu plus 2.0mu minus 1.0mu\Rightarrow\mskip 6.0mu plus 2.0mu minus 1.0mu\newline \hbox to50.00008pt{}\neg\,users^{\prime}(from).complete(sf)$}\hss}$}\hss} Assuming that from\mathit{}from is conforming, this post condition ensures that there cannot be a third user who is conforming, has knowledge of NA\mathit{}NA and has an intPartner\mathit{}intPartner of from\mathit{}from. It is important to recognise that a simple “man in the middle” attack can still work (it would satisfy a specification which omitted users(u).intPartner(su)=from\mathit{}users^{\prime}(u).intPartner(su)=from).

Notice that an implementation of a layered R-G specification must (be shown to) satisfy all layers, so when both users are conforming, the requirements of postNS(L)\mathit{}post-NS(L) in Fig. 1 must be satisfied as well.

5 Encryption introduced as a reification

The notion that only the intended user (rec\mathit{}rec field) can access the content of a Msg\mathit{}Msg can be achieved using encryption. (This idea is also used in [26].) In our work we have been careful to identify the extra assumptions that are needed.

Sections 3 and 4 identify crucial assumptions about the content of messages; this section outlines how rely-guarantee conditions can be used to argue that encryption can discharge the secrecy assumptions on the rec\mathit{}rec field of Msg\mathit{}Msg; this brings in additional assumptions about SKey/PKey\mathit{}SKey/PKey.

Messages are encrypted lists of items that are either Nonce\mathit{}Nonce text or user identifiers. The essence of public key encryption is the use of matching keys:

match:PKey×SKey𝔹\mathit{}match:PKey\times SKey\penalty-100\rightarrow\Bool

Assumptions on match\mathit{}match need to be added to invΣ\mathit{}inv-\mathchar 6\relax. Furthermore, frame descriptions must mark that no user can read the secret key of another user.

Encryption/decryption functions are used:

enc:Item×PKeyEncMsgdec:EncMsg×SKeyItem\mathit{}enc:Item^{*}\times PKey\penalty-100\rightarrow EncMsg\newline dec:EncMsg\times SKey\penalty-100\rightarrow Item^{*}

These are related by the crucial decencprop\mathit{}dec-enc-prop property:

cmItemdec(enc(cm,pk),sk)=cmmatch(pk,sk)\mathit{}{\Forall cm\in Item^{*}}\suchthat dec(enc(cm,pk),sk)=cm\penalty-50\mskip 7.0mu plus 2.0mu minus 2.0mu\Leftrightarrow\mskip 7.0mu plus 2.0mu minus 2.0mumatch(pk,sk)

Decrypting an encrypted message using the correct secret key (and only that key) should return valid information:

mEncMsgdec(m,sk)ItempkPKeymatch(pk,sk)\mathit{}{\Forall m\in EncMsg}\suchthat dec(m,sk)\in Item^{*}\penalty-50\mskip 7.0mu plus 2.0mu minus 2.0mu\Leftrightarrow\mskip 7.0mu plus 2.0mu minus 2.0mu{\Exists pk\in PKey}\suchthat match(pk,sk)

skSKey,pkPKey  match(pk,sk)uUidu.skey=skpkeys(u)=pk \mathit{}\Forall sk\in SKey,pk\in PKey\suchthat\hfil\break\hbox to429.75499pt{\hbox{\bf\quad\/}\vtop{\noindent$\mathit{}match(pk,sk)\penalty-50\mskip 7.0mu plus 2.0mu minus 2.0mu\Leftrightarrow\mskip 7.0mu plus 2.0mu minus 2.0mu{\Exists u\in Uid}\suchthat u.skey=sk\land pkeys(u)=pk$}\hss}

6 Conclusion and Related Work

We have sought to illustrate how a state-based notation can expose interactions between processes. We feel that, in contrast to process algebraic notations, focussing on the interference can highlight issues that in turn can be recorded and reasoned about using rely-guarantee conditions.

The importance of clearly identifying assumptions in models of security protocols has been identified by several researchers. Halpern and Pucella note that the Dolev-Yao model is insufficient in many cases [11]; to identify certain kinds of attacks, different adversary models are required, which place different assumptions on the environment. Halpern and Pucella also state: The problem is even worse when it is not clear exactly what assumptions are implicitly being made about the adversary. Armando et al. [1] support the view that realistic assumptions need to be made in order to ensure that a protocol is ready for deployment, commenting: Most model checking techniques for security protocols make a number of simplifying assumptions on the protocol and/or on its execution environment that greatly complicate or even prevent their applicability in some important cases. This view is shared by Bond and Clulow [5], who express concern that protocols verified by formal tools are restricted by unrealistic assumptions, and protocol designs based on these assumptions are over-engineered and impractical to deploy. Pass [25] lists several well-known protocols which have been proven correct under certain assumptions, and questions whether these protocols would still be secure under a different set of assumptions.

Formal approaches for protocol verification follow two main streams: symbolic and computational approaches. Symbolic approaches typically utilise model checking, using tools such as ProVerif [3], Scyther [9] and OFMC [2]. CryptoVerif [4] is an example of a tool based on a computational approach but with symbolic aspects. For a comprehensive survey of formal approaches for protocol verification see [21]. However, there has been very little effort in finding methods for clearly identifying and articulating assumptions, which is the main advantage of the rely/guarantee approach presented in this paper.

Future work includes the use of tool support to mechanise the descriptions, but Overture (see https://www.overturetool.org/) could require extensions to handle rely-guarantee conditions.

References

  • [1] Alessandro Armando, Roberto Carbone, and Luca Compagna. LTL model checking for security protocols. J. Appl. Non Class. Logics, 19(4):403–429, 2009.
  • [2] David A. Basin, Sebastian Mödersheim, and Luca Viganò. OFMC: A symbolic model checker for security protocols. Int. J. Inf. Sec., 4(3):181–208, 2005.
  • [3] Bruno Blanchet. Automatic verification of security protocols in the symbolic model: The verifier ProVerif. In Alessandro Aldini, Javier López, and Fabio Martinelli, editors, Foundations of Security Analysis and Design VII - FOSAD 2012/2013 Tutorial Lectures, volume 8604 of Lecture Notes in Computer Science, pages 54–87. Springer, 2013.
  • [4] Bruno Blanchet. CryptoVerif: a computationally-sound security protocol verifier (initial version with communications on channels). CoRR, abs/2310.14658, 2023.
  • [5] Mike Bond and Jolyon Clulow. Extending security protocol analysis: New challenges. In Alessandro Armando and Luca Viganò, editors, Proceedings of the Workshop on Automated Reasoning for Security Protocol Analysis, ARSPA@IJCAR 2004, Cork, Ireland, July 4, 2004, volume 125 of Electronic Notes in Theoretical Computer Science, pages 13–24. Elsevier, 2004.
  • [6] Jonathan P. Bowen, Qin Li, and Qiwen Xu, editors. Theories of Programming and Formal Methods, number 14080 in lncs. springer, 2023.
  • [7] Colin Boyd, Anish Mathuria, and Douglas Stebila. Protocols for authentication and key establishment. Springer, 2nd edition, 2019.
  • [8] Alan Burns and Cliff B. Jones. An Approach to Formally Specifying the Behaviour of Mixed-Criticality Systems. In Martina Maggio, editor, 34th Euromicro Conference on Real-Time Systems (ECRTS 2022), volume 231 of Leibniz International Proceedings in Informatics (LIPIcs), pages 14:1–14:23, Dagstuhl, Germany, 2022. Schloss Dagstuhl – Leibniz-Zentrum für Informatik.
  • [9] Cas J. F. Cremers. The Scyther tool: Verification, falsification, and analysis of security protocols. In Aarti Gupta and Sharad Malik, editors, Computer Aided Verification, 20th International Conference, CAV 2008, Princeton, NJ, USA, July 7-14, 2008, Proceedings, volume 5123 of Lecture Notes in Computer Science, pages 414–418. Springer, 2008.
  • [10] Danny Dolev and Andrew Chi-Chih Yao. On the security of public key protocols. IEEE Trans. Inf. Theory, 29(2):198–207, 1983.
  • [11] Joseph Y. Halpern and Riccardo Pucella. Modeling adversaries in a logic for security protocol analysis. volume 8 of Logical Methods in Computer Science, pages 1–26, 2012.
  • [12] I. J. Hayes and C. B. Jones. A guide to rely/guarantee thinking. In J. P. Bowen, Z. Liu, and Z. Zhang, editors, Engineering Trustworthy Software Systems, volume 11174 of LNCS, pages 1–38. Springer International Publishing, Cham, 2018.
  • [13] I. J. Hayes, C. B. Jones, and L. A. Meinicke. Specifying and reasoning about shared-variable concurrency. In Jonathan P. Bowen, Qin Li, and Qiwen Xu, editors, Theories of Programming and Formal Methods Theories of Programming and Formal Methods, number 14080 in lncs, pages 110–135. springer, 2023.
  • [14] ISO/IEC. Vienna Development Method — specification language: Part 1. base language. International Standard ISO/IEC 13817-1, ISO/IEC, 1996.
  • [15] C. B. Jones. Development Methods for Computer Programs including a Notion of Interference. PhD thesis, Oxford University, June 1981. Available as: Oxford University Computing Laboratory (now Computer Science) Technical Monograph PRG-25.
  • [16] C. B. Jones. Specification and design of (parallel) programs. In Proceedings of IFIP’83, pages 321–332. North-Holland, 1983.
  • [17] C. B. Jones. Tentative steps toward a development method for interfering programs. ACM ToPLaS, 5(4):596–619, 1983.
  • [18] C. B. Jones. Systematic Software Development using VDM. Prentice Hall International, second edition, 1990.
  • [19] Cliff B. Jones and Alan Burns. Extending rely-guarantee thinking to handle real-time scheduling. Formal Methods in System Design, 2023.
  • [20] Cliff B. Jones, Ian J. Hayes, and Michael A. Jackson. Deriving specifications for systems that are connected to the physical world. In Cliff B. Jones, Zhiming Liu, and Jim Woodcock, editors, Formal Methods and Hybrid Real-Time Systems:, volume 4700, pages 364–390. Springer Verlag, 2007.
  • [21] Tomas Kulik, Brijesh Dongol, Peter Gorm Larsen, Hugo Daniel Macedo, Steve Schneider, Peter WV Tran-Jørgensen, and James Woodcock. A survey of practical formal methods for security. Formal aspects of computing, 34(1):1–39, 2022.
  • [22] Gavin Lowe. An attack on the Needham-Schroeder public-key authentication protocol. Information processing letters, 56(3), 1995.
  • [23] Gavin Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. In International Workshop on Tools and Algorithms for the Construction and Analysis of Systems, pages 147–166. Springer, 1996.
  • [24] Roger M Needham and Michael D Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12):993–999, 1978.
  • [25] Rafael Pass. Limits of provable security from standard assumptions. In Lance Fortnow and Salil P. Vadhan, editors, Proceedings of the 43rd ACM Symposium on Theory of Computing, STOC 2011, San Jose, CA, USA, 6-8 June 2011, pages 109–118. ACM, 2011.
  • [26] Christoph Sprenger and David Basin. Developing security protocols by refinement. In Proceedings of the 17th ACM conference on Computer and communications security, pages 361–374, 2010.