Foundations for Analyzing Security APIs in the symbolic...

Foundations for Analyzing Security APIs in the symbolic

and computational modelOberseminarvortrag MAIS, 04/02/2014

1

Steve Kremer, Robert Künnemann, Graham Steel

Outline

• Introduction

• Part 1: Analysis in the symbolic model

• Part II: Definition of security in the computational model

• Conclusion & Future work

2

Introduction

3

Basic Assumptions

„We assume that an intruder can inter-pose a computer in all communication paths, and thus can alter or copy parts of messages, replay messages, or emit false material. While this may seem an extreme view, it is the only safe one when designing authentication protocols.“ [Needham-Schroeder, 1978]

4

Basic Assumptions

„We also assume that each principal has a secure environment in which to compute, such as is provided by a personal computer or would be by a secure shared operating system.“ [Needham-Schroeder, 1978]

5

Security APIs

Protocol

6

API API

Security APIs

7

(trusted)(untrusted)

Security APIs

8

(trusted)(untrusted)

Security APIs

9

(untrusted)© 2013 Thales e-Security,

(trusted)

Cryptographic Security APIs

10


(trusted)

#3#2#1 #2#1

Relevance

• heavily used in security-critical contexts

• cash machine network, key-management

• not a niche topic either: 6.970 billion Smartcards shipped in 2012

11

Existing work

12

strengthen security

assume

properties

protocol

specification / policy

algorithmic impl.

physical impl.Secu

rity

API {

Existing work

13

protocol


algorithmic impl.

physical impl.Secu

rity

API {

Assume: perfect crypto (symbolic world), and a

Security API with a strict policy.

!For all protocols using this Security API: nonces, long- and short-term keys stay

secret.[Cortier-Steel, 2009]

!some results for attestation

protocols based on a cryptoprocessor (TPM)[DKRS,

2010]

Existing work

14

protocol


algorithmic impl.

physical impl.Secu

rity

API {

Assume perfect crypto: !

show „complete“ policies secure (secrecy of keys)

[Froschle-Steel,2009] identify secure policies for

fixed number of keys[DKS,2010] !

Existing work

15

protocol


algorithmic impl.

physical impl.Secu

rity

API {

assume: side-channel-free implementation of

algorithms

definition of security in the computational model /

symbolic model [KSW,2011;CC,

2009]

Existing work

16

protocol


algorithmic impl.

physical impl.Secu

rity

API {

Aside from faulty crypto implementations, attacks

exploiting:

• padding errors [BFKSST,2012]

• power consumption [ORP,2013]

• physical access[Kingpin,2000]

Part 1 - security on protocol and policy level

17

strengthen security

assume

properties

protocol


algorithmic impl.

physical impl.Secu

rity

API {

• security depends on protocol

• approach: Security API as participant, use symbolic protocol verification

• challenges: protocol is stateful

Part 1I - security on implementation level

18

strengthen security

assume

propert.

protocol


algorithmic impl.

physical impl.Secu

rity

API {

• security ... needs to be defined

• approach: definition in the cryptographic model

• challenges: generality, applicability

Analysis of stateful protocols in the symbolic model

19

Automated protocol verification

• what are the properties we want?

20

(protocol security) (API security)

Challenge: state

21

set_d(h)

decrypt(h,c)

d

capture causality avoid state explosion

W W

W

W

d...

Existing approaches

22

approach limitations

ProVerif store state on priv. channelchannels don‘t forget, due to

abstractions

StatVerif explicit state manipulation, facts created

bound to protocol statefixed-size state

abstraction by set-membership

[Mödersheim,2010]abstract object x by

key corruption, fixed number of sets (cf. Yubikey)

tamarin multiset rewriting (msr)difficult to write, helping

lemmas required

Strand Space Model (State Ext)

input,output+state sync as acyclic graph, msr for state transitions

no tool support

OFMC, CLAtSe, SATMC

various bounded analysis

based on

Horn clause reso-lution{

tamarin• developed at ETH Zürich

• state of a protocol = multiset of „facts“

• uses msr for protocol description and message deduction

!

• backward reachability analysis, sound+complete, but might diverge

• helping lemmas, induction23

l �[a]! r Sa! S0

MSR and security APIs

• good results on:

• wrap/unwrap/enc/dec (1 aux. lemma)

• examples from [ARR,2011;Mödersheim,2010;DKRS,

2010]

• large case study on authentication protocol based on one-time passwords (OTPs), Yubikey protocol

24

Case study: Yubikey

25

Yubikey protocol

26

usb

Network

enc(otp,k)

enc(otp,k) okare replay attacks possible?

otp=(id, counter, ...) counter larger than last one saved

Yubikey protocol

• messages accepted at one point not necessarily accepted later, based on state (excluding ProVerif)

• unbounded number of Yubikeys connecting to one server (excl. StatVerif)

• many (65 536) states a counter can be in (excl. abstraction by set-membership)

27

Yubikey protocol

28

usb

Network

enc(otp,k)

enc(otp,k) okIs this an improvement?

enc(otp,k) and encrypted k

counter values

Yubikey protocol

• tamarin can show (with manual intervention) that replay-attacks are impossible

• tamarin can show that the YubiHSM provides secrecy of the otp-keys in case of server compromise (if configured carefully, 2 servers necessary)

• discovered attack on HSM for one-server case (security adv. 2012-01)

29

Sidenote: sidechannel attack on Yubikey; uses power

consumption (1h to retrieve key) [ORP13]

Disadvantages of MSR (for modelling)

• Experiences from Yubikey case study:

• large protocols are tedious to write, each step is one rule

• rules are atomic, locking issues often outside the model

• right degree of precision difficult to find

• very far away from an implementation

30

A calculus for stateful protocols

31

Design goals

• easy for novices (and ProVerif experts)

• operators for state manipulation

• explicit locking

• also: private channels, nested replication etc.

32

Syntax

33

5.2 a cryptographic pi calculus with explicit state 63

hM,Ni ::= x, y, z 2 V

| p 2 PN| n 2 FN| f(M

1

,. . . ,Mn

) (f 2 ⌃ of arity n)

hP,Qi ::= 0

| P | Q

| ! P| ⌫n; P| out(M,N); P| in(M,N); P| if M=N then P [else Q]| event F ; P (F 2 F)| insert M,N; P| delete M; P| lookup M as x in P [else Q]| lock M; P| unlock M; P| [L] -[A]! [R];P (L, R,A 2 F⇤)

Figure 9: Syntax.

analyze protocols without bounding the number of sessions, nor mak-ing any abstractions. Moreover it allows for modelling a wide rangeof cryptographic primitives by the means of equational theories. Asthe underlying verification problem is undecidable, tamarin may notterminate. However, it offers an interactive mode with a graphicaluser interface which helps the user to manually guide the tool in itsproof. The translation has been carefully engineered in order to favortermination by tamarin.

5.2.1 Syntax and informal semantics

Our calculus is a variant of the applied pi calculus [2]. In addition tothe usual operators for concurrency, replication, communication andname creation, it offers several constructs for reading and updatingan explicit global state. The grammar for processes is described inFigure 9.0 denotes the terminal process. For readability we sometimes omit

trailing 0 processes. P | Q is the parallel execution of processes P

and Q and !P the replication of P, allowing an unbounded number ofsessions in protocol executions. The construct ⌫n; P binds the namen in P and models the generation of a fresh, random value. Processesout(M,N); P and in(M,N); P represent the output, respectively in-put, of message N on channel M. Readers familiar with the applied

synchronous message passing

asynchronous database lookup,

recognises absence of data

locking operators

embedded msr

Translation to msr

!

• if/else, insert/delete/lookup and locks annotated with actions, security property filters „inconsistent“ traces

• translation is sound and complete

34

P

'

{l1 �[a1]! r1, . . . , ln �[an]! rn}translation

↵lock

^ ↵lookup

^ . . . ) '

Case studies

35

Example helping lemmas

manual intervention

Enc/Dec,Wrap/Unwrap 1 no

Yubikey Protocol 3 yes

GJM Contract-Signing 0 no

Mödersheim‘s example 0 no

Security Device 1 no

Needham-Schroeder-Lowe 1 no

Discussion• protocol representation is more descriptive

than pure msr (spi2java[Pironti-Sisto,2010])

• approach relies on helping lemmas in many cases (automated generation possible?)

• thus more interaction than approaches based on Horn clauses

• in context of Security API, those approaches have severe limitations

36

Defining secure key-management

37

Cryptographic Security APIs

38


(trusted)

#3#2#1

#2#1

Security in the computational model

• What constitutes a cryptographic security API?

• contains keys

• creates keys

• imports/exports keys

• .. other things

39

}key-management

} key-usage

[KSW,2011]

Security in the computational model

• secure key-management

• keys cannot leak (except corrupted explicitly or indirectly)

• policy is respected globally

• key-usage is implemented correctly

• need modularity

40

Composability

41

em

(We use GNUC [Hofheinz-Shoup,2011])

42

Enc Sig+PIN Mines

users external users

key-usage functionalities

provides: creation, wrap, unwrap checks policy before every stepparametric in

policy key-usage fun.

Secure key-management

Benefits of using universal composability

em

enforces policy

Enc Sig+PIN Mines

43

security in arbitrary contexts

enforcement of a global policy

modularity extensibility

Essentially, Security APIs are a means to make protocols more resistant against party corruption; therefore, composability is very important.

44

Benefits of using universal composability

em emem

It is useful:

Generic Security API

• assume all needed key-usage functionalities are „key-manageable“ (stateless except for key)

• assume key-wrapping scheme

• generic security API for arbitrary policy and arbitrary functions implementing key-usage

• secure with respect to our definition

• key-usage is easy to extend45

Limitations

• abstracts only homogenous networks, keys cannot be shared with the outside

• only one way of key-transport

• limits on key-usage (no counter or interact.)

• definition is complex

46

Conclusion

47

Contributions in Part I

• survey on formal analysis of security APIs in the symbolic model; result: approaches based on Horn clauses are insufficient

• proposal: use multiset rewriting and backward reachability analysis instead

• case study (Yubikey/YubiHSM)

• a protocol description language that translates to msr (sound+complete)

48

Future work - Part 1

• automatic generation of helping lemmas

• equivalence properties

• using the tool:

• full PKCS#11

• key-management API [CSW,2012;DLS,2013]

• TPM v1.2/v2.0

49

Contributions in Part II

• (yet another) definition of security for Security APIs[Cortier-Steel,2009;Cachin-Chandran,

2011;KSW,2011]

• novelty: uses and offers composability

• implementation of key-management for arbitrary policy and key-usage operations

• an interesting view on keys in universal composability frameworks

50

Future work - Part 1I

• Generalising key-transport

• Generalising key-usage

• make existing key-usage functionalities key-manageable

51

Thank you for your attention! Questions?

52

53

![ARR,2011] M. Arapinis, E. Ritter and M. Ryan StatVerif:Verification of Stateful Processes ![BFKSST,2012] Bardou et al. Efficient Padding Oracle Attacks on Cryptographic Hardware ![Blanchet,2001] Bruno Blanchet An Efficient Cryptographic Protocol Verifier Based on Prolog Rules ![Canneti,2000] R. Canetti Universally Composable Security: A New Paradigm for Cryptographic Protocols ![Cachin-Chandran,2011] C. Cachin and N. Chandran A Secure Cryptographic Token Interface ![Clulow,2003] J. Clulow On the Security of PKCS#11 ![Cortier-Steel, 2009] V. Cortier and G. Steel A generic security API for symmetric key management on cryptographic devices ![CSW,2012] V. Cortier, G. Steel, and C. Wiedling Revoke and let live: a secure key revocation api for cryptographic devices

![DLS,2013] M. Daubignard, D. Lubicz, and G. Steel A Secure Key Management Interface with Asymmetric Cryptography. !![DKS,2010] S. Delaune, S. Kremer and G. Steel Formal Analysis of PKCS#11 and Proprietary Extensions ![DKRS,2010] S. Delaune, S. Kremer, M. Ryan and G. Steel A Formal Analysis of Authentication in the TPM ![Froschle-Steel,2009] S. Fröschle and G. Steel Analysing PKCS#11 Key Management APIs with Unbounded Fresh Data ![Guttman,2012] J. Guttman State and Progress in Strand Spaces: Proving Fair Exchange ![Hofheinz-Shoup,2000] D. Hofheinz and V. Shoup GNUC: A New Universal Composability Framework ![Kingpin,2000] Kingpin Attacks on and Countermeasures for USB Hardware Token Devices

![KSW,2011] S. Kremer, G. Steel and B. Warinschi Security for Key Management Interfaces ![ORP,2013] D. Oswald et al. Side-Channel Attacks on the Yubikey 2 One-Time Password Generator ![Pironti-Sisto,2010] A. Pironti and R. Sisto Provably Correct Java Implementations of Spi Calculus Security Protocols Specifications ![Mödersheim,2010] S. Mödersheim Abstraction by set-membership: verifying security protocols and web services with databases ![Needham-Schroeder, 1978] R. M. Needham and M. D. Schroeder Using encryption for authentication in large networks of computers ![SMCB,2012] B. Schmidt, S. Meier, C. Cremers, and D. Basin Automated Analysis of Diffie-Hellman Protocols and Advanced Security Properties

References:

Backup slides

54

Rational behind Security APIs

55

Security APIs

56

protocol security

(cryptographic) operations

(often) relies on

rely on

shall be generated and stored on

not exposed to

implemented on

Clulow‘s attack

57

Example: Wrap/Dec

58

{|k2|}k1 h1 ! (k1,wrap), h2 ! (k2, a)

m h1 ! (k1, dec), {|m|}k1

init

wrap

dec

1. generate key

2. change attributes

3. wrap:

4. dec:

A simple attack[Clulow,2003]

59

W

d

wrap(h,h)

c=

set_w(h)

set_d(h)

decrypt(h,c)

k !!policy

Implementation

{|k|}k

init

wrap

init

wrap

dec

init

wrap

dec

init

wrap

dec

?

two points of view two research directions

60

security on implementation layer

security on protocol and policy layer

• security depends on protocol

• approach: Security API as participant, use symbolic protocol verification

• challenges: protocol is stateful

• security .. needs to be defined

• approach: definition in the cryptographic model

• challenges: generality, applicability

Survey (extended)

61

Horn Clause based Approaches (well, mostly ProVerif)

62

63

Protocol: Pi-calculus + crypto primitives

Equational Theory

Security Properties

Horn Clauses

Query: Is x derivable?

No! Yes! Yes? ... ^C

P1 ^ . . . ^ PN ! C

Approximation

64

in(c,M); out(c,enc(k,M))

-becomes-

mess(c,M) ! mess(c, enc(k,M))

65

direct approach: private channels

save M by sending it on c keep c secret

Why it fails: channels don‘t forget:

mess(c,M)

is there, forever

66

StatVerif: translates Applied Pi

+ State into Horn clauses

Why it fails:bounded number of cells

save set of keys as a list?

„3000 rules inserted. The rule base contains 3000 rules. 5964 rules in the queue.“

mess(�, c, setw) ^mess(i, c,M) ! mess(w, c,M)mess(�, c, setw) ^ att(i,M) ! att(w,M)

mess(�, c,M), att(�,M)introduce

67

Mödersheim: abstract values by

set membership

translate set rewriting rules into Horn clauses

Why it fails:

values that are in either of n sets are described by

val(a1, . . . , an)

Abstraction by set-membership

68

�[k]! att(h(k)), k 2 store

att(h(k)), k 2 store, k /2 dec ) k 2 store, k 2 wrap

att(h(val(1, 0, x))) ! timplies(val(1, 0, x), val(1, 0, 1))

att(h(val(1, 0, 0)))

timplies(v, v0) ^ att({|x|}v) ! att({|x|}v0)

69

Mödersheim: abstract values by

set membership

translate set rewriting rules into Horn clauses

Why it fails:

values that are in either of n sets are described by

val(a1, . . . , an)

• no key compromise possible • keys cannot be re-imported • if role separated from key, old problem occurs

Strand Space Model

70

Wrap/Dec

71

< h1, h2 >

{|k2|}k1

Ewrap(h1, h2, k1, k2)

setw, h

Esetw(h)

Init(h)�[Esetw(h)]! Wrap(h)

OK

Wrap/Dec

72

NewKey

h

ENew(h, k)

setw, h

Esetw(h)

OK

;

< h, h >

{|k|}k

Ewrap(h, h, k, k)

{Store(h, k), Init(h)}

{Store(h, k),Wrap(h)}

Esetw(h)

ENew(h, k)

{Store(h, k),Wrap(h)}

Ewrap(h, h, k, k)

73

Strand Spaces: extended by state

express Security API as a set of strands

What is missing:

captures causality

no tool support for state synchronisation (yet?)

model of the TPM

Multiset rewriting in tamarin

74

multiset rewriting

75

ground instantiation of a rule

S contains facts from l

is S minus old and plus new facts

Sa! S0

S0

traces(P ) all possible sequences of actions

l �[a]! r

tamarin

• developed at ETH Zürich

• uses msr for protocol decription..

!

• and message deduction

!

!

76

(1 ) dec(enc(m,k), k) �m (6 ) x ∗ 1 � x

(2 ) fst(�x, y�) � x (7 ) x ∗ x

−1 � 1

(3 ) snd(�x, y�) � y (8 ) (x−1)−1 � x

(4 ) x ∗ (y ∗ z) � (x ∗ y) ∗ z (9 ) (x ˆ y) ˆ z � x ˆ (y ∗ z)(5 ) x ∗ y � y ∗ x (10 ) x ˆ 1 � x

Figure 2. Equations that constitute EDH .

The equational theory EDH generated by the equations inFigure 2 formalizes the semantics of the function symbols in⌃DH. It consists of equations for decryption and projection(1–3), exponentiation (9–10), and the theory of abelian groupsfor the exponents (4–8). Equation (9) states that repeatedexponentiation in a DH group corresponds to multiplicationof the exponents.

As an example, consider the term ((g ˆ a) ˆ b) ˆ a−1, whichresults from exponentiating g with a, followed by b, followedby a inverse. This is equal to g ˆ ((a ∗ b) ∗ a−1) becauseof (9) and can be further simplified to g ˆ b using (4–7).

Note that our approach supports the combination ofEquations (2–10) modeling DH exponentiation and pairingwith an arbitrary subterm-convergent rewriting theory for theuser-defined cryptographic operators (see [18]). A rewritingtheory R is subterm-convergent if it is convergent and foreach rule l → r ∈ R, r is either a proper subterm of l oris ground and in normal form with respect to R. One cantherefore extend ⌃DH and EDH with asymmetric encryption,signatures, and similar operators.

Note that our equational theory does not support protocolsthat perform multiplication in the DH group G. To definesuch protocols, an additional function symbol × denotingmultiplication in G is required. The function symbol ∗denotes multiplication in the group of exponents, which is adifferent operation. For example, the equality (gˆa×gˆb)ˆc =(gˆa)ˆc×(gˆb)ˆc holds in all DH groups, but does usually nothold if we replace × by ∗. Moreover, addition of exponentsmust be modeled for such protocols to avoid missing attacks.Consider the example protocol that randomly choses twoexponents a and b, sends these exponents, receives someexponent x, and checks if g ˆ a × g ˆ b = g ˆ x. This checksucceeds if and only if x = a + b.

1) Transition System State: We model the states of ourtransition system as finite multisets of facts. We use a fixedset of fact symbols to encode the adversary’s knowledge,freshness information, and the messages on the network. Theremaining fact symbols are used to represent the protocolstate. Formally, we assume an unsorted signature ⌃Factpartitioned into linear and persistent fact symbols. We definethe set of facts as the set F consisting of all facts F (t1, .., tk)such that t

i

∈ T and F ∈ ⌃k

Fact. We denote the set of groundfacts by G. We say that a fact F (t1, .., tk) is linear if F islinear and persistent if F is persistent.

Linear facts model resources that can only be consumed

once, whereas persistent facts model inexhaustible resourcesthat can be consumed arbitrarily often. In the rest of thepaper, we assume that ⌃Fact consists of an arbitrary numberof protocol-specific fact symbols to describe the protocolstate and the following special fact symbols. A persistent factK(m) denotes that m is known to the adversary. A linear factOut(m) denotes that the protocol has sent the message m,which can be received by the adversary. A linear fact In(m)denotes that the adversary has sent the message m, whichcan be received by the protocol. A linear fact Fr(n) denotesthat the fresh name n was freshly generated.

2) Adversary, Protocol, and Freshness Rules: To specifythe possible transitions by the adversary and the honestparticipants, we use labeled multiset rewriting. A labeledmultiset rewriting rule is a triple (l, a, r) with l, a, r ∈ F∗,denoted l−−[ a ]→r. We often suppress the brackets around thesequences l, a, and r when writing rules. For ri = l−−[ a ]→r,we define the premises as prems(ri ) = l, the actions asacts(ri ) = a, and the conclusions as concs(ri ) = r. We useginsts(R) to denote the set of ground instances of a set oflabeled multiset rewriting rules R.

There are three types of rules. A rule for fresh name gen-eration, the message deduction rules, and the rules specifyingthe protocol and the adversary’s capabilities. All fresh namesare created with the rule FRESH = ([]−−[]→Fr(x∶fresh)). Thisis the only rule that produces Fr facts and we consider onlyruns with unique instances of this rule, i.e., the same freshname is never generated twice.

We use the following set of message deduction rules.

MD = { Out(x)−−[]→K(x), K(x)−−[ K(x) ]→In(x) }∪ { −−[]→K(x∶pub), Fr(x∶fresh)−−[]→K(x∶fresh) }∪ { K(x1),. . . ,K(xk

)−−[]→K(f(x1, . . . , xk

)) � f ∈ ⌃k

DH }The rules in the first line allow the adversary to receivemessages from the protocol and send messages to the protocol.The K(x) action in the second rule makes the messages sentby the adversary observable in a protocol’s trace. We exploitthis to specify secrecy properties. The rules in the secondline allow the adversary to learn public names and freshlygenerated names. The remaining rules allow the adversaryto apply functions from ⌃DH to known messages.

A protocol rule is a multiset rewriting rule l−−[ a ]→r suchthat (P1) it does not contain fresh names, (P2) K and Outfacts do not occur in l, (P3) K, In, and Fr facts do not occurin r, and (P4) vars(r) ⊆ vars(l) ∪ Vpub. A protocol is afinite set of protocol rules. Note that our formal notion of aprotocol encompasses both the rules executed by the honestparticipants and the adversary’s capabilities, like revealinglong-term keys. Condition P1 and the restriction on theusage of Fr facts from P3, which also hold for the messagededuction rules, ensure that all fresh names originate frominstances of the FRESH rule.

! !! !

! ! !

In(hset w, hi), !Store(h), Init(h)�[]! Wrap(h),Out(‘ok ‘)

trace formulas

• first-order formula over trace atoms:

• false

• term equality

• time-point ordering

• time-point equality

• action

77

?

t1 ⇡ t2

il j

i.= j

F@i

Example

78

4.1 yubikey and yubikey authentication protocol 49

The output can be used to authenticate with the server, in case thatthe counter inside the encryption is larger than the last counter storedon the server:

Server(pid, sid, otc), In(hpid,nonce, otpi), !SharedKey(pid, k), In(otc)

-[Login(pid, sid, tc, otp), LoginCounter(pid, otc, tc),Smaller(otc, tc) ]!

Server(pid, sid, tc)

for otp = senc(hsid, tc, pri, k). Tamarin is able to prove the followingproperties.

1. The absence of replay attacks:

¬(9i, j, pid, sid, x, otp1, otp2.Login(pid, sid, x, otp1)@i^ Login(pid, sid, x, otp2)@j

^¬(i = j)).

There are no two distinct logins that accept the same countervalue. Note that this property is stronger than showing that notwo distinct logins for the same OTP exists, as two OTPs that areequal necessarily contain the same counter value.

2. Injective correspondence between pressing the button on a Yu-bikey and a successful login:

8 pid, sid, x, otp, t2.Login(pid, sid, x, otp)@t

2

)9t1.YubiPress(pid, x)@t

1

^ t

1

l t

2

^ 8otp2, t3.Login(pid, sid, x, otp2)@t

3

) t

3

= t

2

A successful login must have been preceded by a button pressfor the same counter value. Furthermore, there is not second,distinct login for this counter value.

3. The fact that the counter values associated to logins are mono-tonically increasing in time, which implies that a successful lo-gin invalidates previously collected OTPs.

8 pid, otc1, tc1, otc2, tc2, t1, t2, t3. Smaller(tc1, tc2)@t

3

^ LoginCounter(pid, otc1, tc1)@t

1


2

) t

1

l t

2

The absence of replay attacks is proven by showing the following,stronger property, which we use as an invariant:

8 pid, otc1, tc1, otc2, tc2, t1, t2. LoginCounter(pid, otc1, tc1)@t

1


2

^ t

1

l t

2

) 9z.tc2

= z+ tc1

79

Finally, we define normal message deductions and thecorresponding normal dependency graphs. We also showthat normal dependency graphs are weakly trace equivalentto the multiset rewriting semantics.

A. Dependency Graphs

We use dependency graphs to represent protocol executionstogether with their causal dependencies. A dependencygraph consists of nodes labeled with rule instances anddependencies between the nodes. We first present an exampleof a dependency graph and then give its formal definition.

Example 1 (Dependency Graph). Consider the protocol

P = { [Fr(x),Fr(k)]−−[]→[St(x,k),Out(enc(x,k)),Key(k)], [St(x, k), In(�x,x�)]−−[ Fin(x, k) ]→[], [Key(k)]−−[ Rev(k) ]→[Out(k)] } .

Figure 5 shows a dependency graph for an execution ofP . We use inference rule notation with the actions on theright for rule instances. Nodes 1 and 2 are rule instances thatcreate fresh names. Node 3 is an instance of the first protocolrule. Node 4 is an instance of the key reveal rule. Nodes 5–9are instances of message deduction rules and denote thatthe adversary receives a ciphertext and its key, decryptsthe ciphertext, pairs the resulting cleartext with itself, andsends the result to an instance of the second protocol rule,Node 10. The edges denote causal dependencies: an edgefrom a conclusion of node i to a premise of node j denotesthat the corresponding fact is generated by i and consumedby j. Since this is a dependency graph modulo EDH , it issufficient that each pair of generated and consumed facts isequal modulo EDH .

Formally, let E be an equational theory and R be a set ofmultiset rewriting rules. We say that dg = (I,D) is a depen-dency graph modulo E for R if I ∈ (ginsts(R∪{FRESH}))∗,D ⊆ N2 ×N2, and dg satisfies the conditions DG1–4 listedbelow. To state these conditions, we introduce the followingdefinitions. We call idx(I) the nodes and D the edges ofdg. We write (i, u) � (j, v) for the edge ((i, u), (j, v)).Let I = [l1−−[ a1 ]→r1, . . . , ln−−[ an

]→r

n

]. The trace of dg istrace(dg) = [set(a1), . . . , set(a

n

)]. A conclusion of dg is apair (i, u) such that i is a node of dg and u ∈ idx(r

i

). Thecorresponding conclusion fact is (r

i

)u

. A premise of dg isa pair (i, u) such that i is a node of dg and u ∈ idx(l

i

). Thecorresponding premise fact is (l

i

)u

. A conclusion or premiseis linear if its fact is linear.DG1 For every edge (i, u)� (j, v) ∈D, it holds that i < j

and the conclusion fact of (i, u) is equal modulo E tothe premise fact of (j, v).

DG2 Every premise of dg has exactly one incoming edge.DG3 Every linear conclusion of dg has at most one outgoing

edge.DG4 The FRESH rule instances in I are unique.

3 :Fr(a) Fr(k)

St(a, k) Out(enc(a, k))) Key(k)

7 :K(enc(a, k)) K(k)

K(dec(enc(a, k), k))

5 :Out(enc(a, k))

K(enc(a, k))6 :

Out(k)

K(k)

1 :Fr(a)

2 :Fr(k)

9 :K(�a, a�)In(�a, a�)

[K(�a, a�)]

10 :St(a, k) In(�a, a�)

[Fin(a, k)]

8 :K(a) K(a)

K(�a, a�)

4 :Key(k)

Out(k)[Rev(k)]]

Figure 5. Dependency graph modulo EDH .

We denote the set of all dependency graphs modulo E forR by dgraphs

E

(R).Note that, for all protocols P , the multiset rewriting

semantics given in Section IV and the dependency graphsmodulo EDH for P ∪MD have the same set of traces, i.e.,traces(P ) =

EDH{trace(dg) �dg ∈ dgraphs

EDH(P ∪MD)}.

B. Dependency Graphs modulo AC

We now switch to a semantics based on dependency graphsmodulo AC . We use standard notions from order-sortedrewriting [24] and proceed in two steps.

First, we define AC as the equational theory generatedby Equations (4–5) from Figure 2 and DH as the rewritingsystem obtained by orienting Equations (1–3,9–10) fromFigure 2 and all equations from Figure 6 from left to right.DH �AC is an equational presentation of EDH and DH isAC -convergent and AC -coherent. We can therefore definet↓DH as the normal form of t with respect to DH,AC -rewriting and have t =

EDHs iff t↓DH =AC s↓DH . We say

that t is ↓DH -normal if t =AC t↓DH . We say a dependencygraph dg = (I,D) is ↓DH -normal if all rule instances in I

are ↓DH -normal.Second, EDH has the finite variant property [25] for this

presentation, which allows us to perform symbolic reasoningabout normalization. More precisely, for all terms t, thereis a finite set of substitutions {⌧1, . . . , ⌧k

} such that for allsubstitutions �, there is an i ∈ {1, . . . , k} and a substitution �

′with (t�)↓DH =AC ((t⌧i

)↓DH )�′ and (x�)↓DH =AC x⌧

i

�

′for all x ∈ vars(t). We call {( t⌧

i

↓DH , ⌧

i

) � 1 ≤ i ≤ k} acomplete set of DH,AC -variants of t. For a given term t,we use folding variant narrowing [24] to compute such a set,

premise matches conclusion

one edge to premise

one edge from linear conclusion

Instances of Fresh are unique

constraint solving

80

' ¬' l2

r1

a : il1

: ja0

r2

l3 l4

+ il j

solved constraint system → attack

no further refinement possible →successful verification

sound+complete, but might diverge → helping lemmasstate_0111111( k, h )

Out( h ) state_01111111( k, h )

state_011111( k, h )

Insert( <'att', h>, 'dec' )

state_0111111( k, h )

state_01111( k, h )

Insert( <'key', h>, k )

state_011111( k, h )

state_0111( k, h )

Event( ),NewKey( h, k )

state_01111( k, h )

state_011( h ) Fr( k )

state_0111( k, h )

!state_01( ) Fr( h )

state_011( h )

state_0( )

!state_01( )

!state_01( ) Fr( h' )

state_011( h' )

0[Init( )]

state_0( )

state_0111111( k', h' )

Out( h' ) state_01111111( k', h' )

state_011111( k', h' )

Insert( <'att', h'>, 'dec' )

state_0111111( k', h' )

state_01111( k', h' )

Insert( <'key', h'>, k' )

state_011111( k', h' )

state_0111( k', h' )

Event( ),NewKey( h', k' )

state_01111( k', h' )

state_011( h' ) Fr( k' )

state_0111( k', h' )

Figure 5: Example trace for the translation of !Pnew

.

↵

lock

:=8x, l, l0, i, j.Lock(l, x)@i ^ Lock(l0, x)@j ^ il j

) 9k.Unlock(l, x)@k ^ il k ^ k l j^(8l0,m.Lock(l0, x)@m ) ¬(ilm ^ml k))

^ (8l0,m.Unlock(l0, x)@m ) ¬(ilm ^ml k))

↵

inev

:=8t, i.InEvent(t)@i ) 9j.K(t)@j^(8k.Event()@k ) (k l j _ il k))^(8k, t0.K(t0)@k ) (k l j _ il k _ k ⇡ j))

The hypotheses of J'K use the labels of the generated rulesto filter out executions that we wish to discard:

• ↵

init

ensures that the init rule is only fired once.

• ↵

eq

and ↵

noteq

ensure that we only consider traceswhere all (dis)equalities hold.

• ↵

in

and ↵

notin

ensure that all successful lookups werepreceded by an insert that was neither revoked noroverwritten while all unsuccessful lookups where eithernever inserted, or at one point deleted and never re-inserted

• ↵

lock

checks that between each two matching locksthere must be an unlock. Furthermore, between thefirst of these locks and the corresponding unlock, thereis neither a lock nor an unlock.

• ↵

inev

ensures that, whenever an instance of MDIn isrequired to generate an In-fact, it is generated as lateas possible, i. e., there is no visible Event between theaction !K(t) produced by MDIn, and a rule that re-quires In(t).

We also note that Tr ✏8 J'K8 i↵ Tr 6✏9 J¬'K9.

6.3 Correctness of the translationWe will now show that the correctness of our translation

stated by the following theorem.

Theorem 1. Given a well-formed ground process P and awell-formed trace formula ' we have that

tracespi(P ) ✏?

' i↵ tracesmsr (JP K) ✏? J'K?

where ? is either 8 or 9.We here give an overview of the main propositions and

lemmas needed to prove Theorem 1. To show the result weneed two additional definitions. We first define an operationwhich allows to restrict a set of traces to those that satisfythe trace formula ↵ as defined in Definition 14.

Definition 15. Let ↵ be the trace formula as defined inDefinition 14 and Tr a set of traces. We define

filter(Tr) := {tr 2 Tr |8✓.(tr , ✓) ✏ ↵}The following proposition states that if a set of traces sat-

isfies the translated formula then the filtered traces satisfythe original formula.

Proposition 1. Let Tr be a set of traces and ' a traceformula. We have that

Tr ✏? J'K?

i↵ filter(Tr) ✏?

'

where ? is either 8 or 9.The proof (detailed in full version) follows directly from

the definitions. Next we define the hiding operation whichfilters out all reserved facts from a trace.

Definition 16 (hide). Given a trace tr and a set of factsF we inductively define hide([]) = [] and

hide(F · tr) :=(

hide(tr) if F ✓ Fres

(F \ Fres

) · hide(tr) otherwise

Given a set of traces Tr we define hide(Tr) = {hide(t) | t 2Tr}.As expected well-formed formulas that do not contain re-

served facts evaluate the same whether reserved facts arehidden or not.

Proposition 2. Let Tr be a set of traces and ' a well-formed trace formula. We have that

Tr ✏?

' i↵ hide(Tr) ✏?

'

where ? is either 8 or 9.We can now state our main lemma which is relating the set

of traces of a process P and the set of traces of its translationinto multiset rewrite rules.

Lemma 1. Let P be a well-formed ground process. We havethat

tracespi(P ) = hide(filter(tracesmsr (JP K))).Our main theorem is proven by applying Lemma 1, Propo-

sition 2 and Proposition 1.

Case study: Yubikey/YubiHSM

81

Yubikey protocol

82

usb

Network

enc(otp,k)

enc(otp,k) okIs this an improvement?

enc(otp,k), enc(k,master)

counter values

Results

• no replay attacks are possible, i.e.,

!

• (uses three lemmas to derive the result)

• nontrivial modelling of smaller-than

• injective correspondence between Login and button press; invalidation property

83

¬9 Login(id, otp)@t1 ^ Login(id, otp)@t2 ^ t1 6= t2

Security Property

84

very relevant: RSA SecurID disaster in 2011

40‘000‘000 x

positive Results

• analysis using a more detailed model

• result: if AEAD_GENERATE is always turned off (except in secure environments)

• the master key stays secret

• the Yubikey‘s AES key stay secret

• ⇒ distinct setup phase, or two servers

85

Yubikey protocol• Impact: very prompt reaction from Yubico

(security adv. 2012-01)

• model dev: 1 month, several refinements

• verification time: 35s (Yubikey), 50s (+HSM)

• interaction with ETH leading to nice new features (injective facts, proof strategy, axioms, multiset datatypes)

• experience: proper modelling is hard

86

Attack on YubiHSM

87

Attack

• there is no function: AEAD_DECRYPT

• but: encryption part uses counter-mode

88

“the YubiHSM intentionally does not provide any functions that decrypts an AEAD and

returns it in clear text, either fully or partial.”

Attack

89

The attacks use the following two commands: AES_ECB_BLOCK_EN-CRYPT takes a handle to an AES key and a plaintext of length of one AESblock (16 Bytes) and applies the raw block cipher. YSM_AEAD_GENERATEtakes a nonce, a handle to an AES key and some data and outputs an AEAD.More precisely, but still simplified for our purposes, it computes:

AEAD(nonce, kh, data) =

0

@

0

@d |data|

blocksize

ek

i=0AES (k, counter i)

1

AM

data

1

A ||mac

where k is the key referenced by the key-handle kh, counter i is a counter that iscompletely determined by kh,nonce, i and the length of data and blocksize is 16bytes. For the precise definition of mac and counter , we refer to RFC 3610 [20].Figure 2 depicts the counter mode of operation, the method used to derive theAEAD up to the MAC.

counter1 counter2 countern

AES AES AES

data1

Ldata2

L· · · datan

L

cypher1 k cypher2 k · · · k cyphern

Fig. 2. AES in counter mode (simplified)

The AEADs used to store keys for decrypting OTPs in the Yubikey protocolare special cases: the plaintext is a concatenation of the respective Yubikey’sAES key and secret device ID (22 bytes in total), and nonce consists of theYubikey’s public id.

An attacker with access to the command AES_ECB_BLOCK_ENCRYPTis able to decrypt an AEAD by recreating the blocks of the key-stream, i. e.,AES (k, counter i). He xors the result with the AEAD truncated by 8 bytes (thelength of mac) and yields data. When the attacker is able to compromise theserver, he learns the AEAD and the key-handle used to produce it. Since thenonce is the public ID of the Yubikey, he can compute counter i and, using AES_-ECB_BLOCK_ENCRYPT the key-stream. It is in the nature of the counter-mode that encryption and decryption are the same operation. According to thereference manual[19, Section 4.3], “the YubiHSM intentionally does not provideany functions that decrypts an AEAD and returns it in clear text, either fullyor partial.”. We therefore consider the protection of the AEAD’s contents asecurity goal of the YubiHSM, which is violated by this attack. The attack can

AES_ECB_BLOCK_ENCRYPT

YSM_AEAD_GENERATE

Embedded msr

• lookup ,store1‘ as x in

90

70 a process calculus with state

If the adversary shall have (partial) access to the store, this needs tobe made explicit, by having a process providing an interface to thestore. See the following example, where P

0 is the actual protocol:

!(in(y). insert ’AdversaryCell’, y)| !(lookup ’AdversaryCell’ as y in out(y)) | P 0

5.2.3.3 Lookup is binding

It might seem odd that lookup acts as a binder, while input doesnot. We justify this decision as follows: As Pdec and Pwrap in the previ-ous example show, lookups appear often after input was received. Iflookups were to use pattern matching, the following process

P = in(c,x); lookup ‘store’ as x in P

0

might unexpectedly perform a check if ‘store’ contains the messagegiven by the adversary, instead of binding the content of ‘store’ to x,due to an undetected clash in the naming of variables.

5.2.3.4 Inline multiset rewriting

In addition to the access to the functional store via lookup, insert anddelete, we support a “low-level” form of state manipulation in formof the construct [L] -[A]! [R];P. This style of state manipulation issimilar to the state extension in the strand space model [47] and theunderlying specification language of the tamarin tool [89, 90].

This low-level store is distinct from the functional store, which isa restriction imposed by our translation. We decided to neverthelessinclude this construct as a way of accessing the functionality of theunderlying tool, tamarin. This offers a great flexibility and has shownuseful in our case studies. However, we recommend its use only tousers familiar with how our translation works. The discussion onthe translation (see Section 5.3.3) gives further insight on why thefunctional store is distinct from this low-level store.

Note further that data can be moved from the functional store tothe low-level store, and vice versa, for example as follows: lookup’store1’ as x in [] -[ ]! [store2(x)].

5.2.3.5 Comparison with StatVerif

Our calculus is very close to the StatVerif calculus by Arapinis etal. [5]. Notable differences are the following:

1. Destructor application: Since tamarin handles the equational the-ory without making a distinction between constructors and de-structors, our calculus does not have a construct for this. Thedefinition of Pdec (see (2) on page 65) gives an example on howto handle destructors that might fail, in this case decryption.

Translation

91

Syntax

92

5.2 a cryptographic pi calculus with explicit state 63

hM,Ni ::= x, y, z 2 V

| p 2 PN| n 2 FN| f(M

1

,. . . ,Mn

) (f 2 ⌃ of arity n)

hP,Qi ::= 0

| P | Q

| ! P| ⌫n; P| out(M,N); P| in(M,N); P| if M=N then P [else Q]| event F ; P (F 2 F)| insert M,N; P| delete M; P| lookup M as x in P [else Q]| lock M; P| unlock M; P| [L] -[A]! [R];P (L, R,A 2 F⇤)

Figure 9: Syntax.

analyze protocols without bounding the number of sessions, nor mak-ing any abstractions. Moreover it allows for modelling a wide rangeof cryptographic primitives by the means of equational theories. Asthe underlying verification problem is undecidable, tamarin may notterminate. However, it offers an interactive mode with a graphicaluser interface which helps the user to manually guide the tool in itsproof. The translation has been carefully engineered in order to favortermination by tamarin.

5.2.1 Syntax and informal semantics

Our calculus is a variant of the applied pi calculus [2]. In addition tothe usual operators for concurrency, replication, communication andname creation, it offers several constructs for reading and updatingan explicit global state. The grammar for processes is described inFigure 9.0 denotes the terminal process. For readability we sometimes omit

trailing 0 processes. P | Q is the parallel execution of processes P

and Q and !P the replication of P, allowing an unbounded number ofsessions in protocol executions. The construct ⌫n; P binds the namen in P and models the generation of a fresh, random value. Processesout(M,N); P and in(M,N); P represent the output, respectively in-put, of message N on channel M. Readers familiar with the applied

synchronous message passing

asynchronous database lookup,

recognises absence of data

locking operators

embedded msr

Translation to msr

93

statep(x) .. process at position p with substitution described by x

.. if there is a parallel at position p

statep(x),Fr(n) ! statep·1(x, n)

.. if there is a new at position p (simpl.)

statep(x) ! statep·1(x), statep·2(x)

!statep(x) ! statep·1(x)

.. if there is a replication at position p

Translation to msr• input/output more involved (synchronous

message passing)

• if/else, state manipulation and locks use translation of security property:

• annotate rules:

!

• add „axioms“ to security property

94

statep(x)�[Eq(t1, t2)]! statep·1(x)

(8x, y, i. Eq(x, y)@i ) x = y) ) '

Translation to msr

• carefully designed axioms for lookup and locks

• pre-annotation of locks for efficiency, but with slight loss of generality (+ embedded msr can implement locks, too)

• translation is sound and complete

95

lookup

96


↵in :=8x, y, t3

.IsIn(x, y)@t

3

=)9t

2

.Insert(x, y)@t

2

^ t

2

l t

3

^ (8t1

.Delete(x)@t

1

) t

1

l t

2

_ t

3

l t

1

)

^ (8t1

, y.Insert(x, y)@t

1

=) t

1

l t

2

_ t

3

l t

1

))

↵notin :=8x, y, t3

.IsNotSet(x)@t

3

=)(8t

1

, y.Insert(x, y)@t

1

=) t

3

l t

1

)

_ 9t1

.Delete(x)@t

1

^ t

1

l t

3

^ 8t2

, y.Insert(x, y)@t

2

^ t

2

l t

3

=) t

2

l t

1

↵lock :=8x, l, l 0, i, j.Lock(l, x)@i^ Lock(l 0, x)@j^ il j

) 9k.Unlock(l, x)@k^ il k^ kl j^

(8l 0,m.Lock(l 0, x)@m ) ¬(ilm^ml k))

^ (8l 0,m.Unlock(l 0, x)@m ) ¬(ilm^ml k))

↵inEv :=8t, i.InEvent(t)@i ) 9j.K(t)@j^

(8k.Event()@k ) (kl j_ il k))^

(8k, t 0.K(t 0)@k ) (kl j_ il k_ k ⇡ j))

The hypotheses of J'K use the labels of the generated rules to filterout executions that we wish to discard:

• ↵init ensures that the init rule is only fired once.

• ↵eq and ↵noteq ensure that we only consider traces where all(dis)equalities hold.

• ↵in and ↵notin ensure that all successful lookups were precededby an insert that was neither revoked nor overwritten whileall unsuccessful lookups where either never inserted, or at onepoint deleted and never re-inserted.

• ↵lock checks that between each two matching locks there mustbe an unlock. Furthermore, between the first of these locks andthe corresponding unlock, there is neither a lock nor an unlock.

• ↵inEv ensures that, whenever an instance of MDIn is required togenerate an In-fact, it is generated as late as possible, i. e., thereis no visible Event between the action !K(t) produced by MDIn,and a rule that requires In(t). This is needed to be correct withrespect to the operational semantics of in and out, see Figure 11.

We also note that Tr ✏8 J'K8 iff Tr 6✏9 J¬'K9.

5.3.3 Discussion

In the following we will discuss the advantages of using our transla-tion as opposed to a direct modelling in form of multiset rewrite rules.Then we will give some insight into why the state manipulation and

locking - annotation

• any unlock t is preceded by a lock t (syntactical equivalence between t) in the process tree

• this assignment is injective

• matching pairs of unlock and lock are annotated with the same labels (fresh names) l

97

locking

98


↵in :=8x, y, t3

.IsIn(x, y)@t

3

=)9t

2

.Insert(x, y)@t

2

^ t

2

l t

3

^ (8t1

.Delete(x)@t

1

) t

1

l t

2

_ t

3

l t

1

)

^ (8t1

, y.Insert(x, y)@t

1

=) t

1

l t

2

_ t

3

l t

1

))

↵notin :=8x, y, t3

.IsNotSet(x)@t

3

=)(8t

1

, y.Insert(x, y)@t

1

=) t

3

l t

1

)

_ 9t1

.Delete(x)@t

1

^ t

1

l t

3

^ 8t2

, y.Insert(x, y)@t

2

^ t

2

l t

3

=) t

2

l t

1

↵lock :=8x, l, l 0, i, j.Lock(l, x)@i^ Lock(l 0, x)@j^ il j

) 9k.Unlock(l, x)@k^ il k^ kl j^

(8l 0,m.Lock(l 0, x)@m ) ¬(ilm^ml k))

^ (8l 0,m.Unlock(l 0, x)@m ) ¬(ilm^ml k))

↵inEv :=8t, i.InEvent(t)@i ) 9j.K(t)@j^

(8k.Event()@k ) (kl j_ il k))^

(8k, t 0.K(t 0)@k ) (kl j_ il k_ k ⇡ j))

The hypotheses of J'K use the labels of the generated rules to filterout executions that we wish to discard:

• ↵init ensures that the init rule is only fired once.

• ↵eq and ↵noteq ensure that we only consider traces where all(dis)equalities hold.

• ↵in and ↵notin ensure that all successful lookups were precededby an insert that was neither revoked nor overwritten whileall unsuccessful lookups where either never inserted, or at onepoint deleted and never re-inserted.

• ↵lock checks that between each two matching locks there mustbe an unlock. Furthermore, between the first of these locks andthe corresponding unlock, there is neither a lock nor an unlock.

• ↵inEv ensures that, whenever an instance of MDIn is required togenerate an In-fact, it is generated as late as possible, i. e., thereis no visible Event between the action !K(t) produced by MDIn,and a rule that requires In(t). This is needed to be correct withrespect to the operational semantics of in and out, see Figure 11.

We also note that Tr ✏8 J'K8 iff Tr 6✏9 J¬'K9.

5.3.3 Discussion

In the following we will discuss the advantages of using our transla-tion as opposed to a direct modelling in form of multiset rewrite rules.Then we will give some insight into why the state manipulation and

Translation: Proof of Correctness

99

Proof of Correctness

100


and8✓.9✓ 0. if (hide(tr), ✓) ✏ ' then (tr, ✓ 0

) ✏ '

We proceed by structural induction on '.

• ' = ?, ' = il j, ' = i

.= j or t

1

⇡ t

2

. In these cases we triviallyconclude as the truth value of these formulas does not dependon the trace and for both statements we simply let ✓ 0 := ✓.

• ' = f@i. We start with the first statement. Suppose that (tr, ✓) ✏f@i. If ✓(i) < n then we have also that tr, ✓ ✏ f@i. By inductionhypothesis, there exists ✓

0 such that (tr, ✓ 0) ✏ f@i. Hence we

also have that (tr, ✓ 0) ✏ f@i and letting ✓

0 := ✓

0 allows us toconclude. If ✓(i) = n we know that f 2 tr

n

. As ' is well-formed f 62 Fres and hence f 2 hide(tr)

n

0 where n

0 = |hide(tr)|.The proof of the other statement is similar.

• ' = ¬' 0, ' = '

1

^'

2

, or ' = 9x : s.' 0. We directly concludeby induction hypotheses (on the structure of ').

From the above statements we easily have that Tr ✏9' iff hide(Tr) ✏9

'.The case of ? = 8 now easily follows:

Tr ✏8' iff Tr 6✏9 ¬' iff hide(Tr) 6✏9 ¬' iff hide(Tr) ✏8

'

We can now state our main lemma which is relating the set of tracesof a process P and the set of traces of its translation into multisetrewrite rules, using the functions hide and filter to ignore reservedactions and discard traces that contradict the our axioms.Lemma 1: Let P be a well-formed ground process. We have that

tracespi(P) = hide(filter(tracesmsr(JPK))).

We will prove this lemma in the following sections, however, fornow we proceed to conclude the proof of Theorem 1 from the bird’s-eye view.

Given the above propositions and Lemma 1, we can now easilyproof our main theorem.

Proof of Theorem 1.

tracespi(P) ✏?'

,hide(filter(tracesmsr(JPK))) ✏?' (by Lemma 1)

,filter(tracesmsr(JPK)) ✏?' (by Proposition 2)

,tracesmsr(JPK) ✏? J'K? (by Proposition 1)

1st step

• Set inclusion in two directions

• both direction via induction on length of execution (not trace), many cases

• direction from msr to protocol calculus:

• „normalisation“ lemma

• requires lemma relating deduction relation from calculus to msr using only rules in MD

101

2nd step

• only need to show Exists-case

• induction on length of trace

• then: structural induction on \phi

102

5.4 correctness of the translation 87

The case of ? = 9 now easily follows:

Tr ✏9 J'K9 iff Tr 6✏8 J¬'K8 iff filter(Tr) 6✏8 ¬' iff filter(Tr) ✏9'.

If we take a second look at Example 18, we see that the traces intracesmsr(JPK) contain some actions that never appear in any trace intracespi(P), namely Eq, NotEq, and Event(). Observe that all theseactions are in Fres. The trace [NotEq(’apple’, ’orange’)] is such a case(NotEq 2 Fres), although it satisfies the axioms ↵, including ↵noteq, andhence belongs to filter(tracesmsr(JPK)). We need to “hide” all thoseactions that are reserved in order to have equivalent sets of traces.Since reserved actions do not appear in well-formed trace formulas,it is safe to hide them. We define the hiding operation which filtersout all reserved facts from a trace.Definition 17 (hide): Given a trace tr and a set of facts F we inductivelydefine hide([]) = [] and

hide(F · tr) :=

8<

:hide(tr) if F ✓ Fres

(F \ Fres) · hide(tr) otherwise

Given a set of traces Tr we define hide(Tr) = {hide(t) | t 2 Tr}.As expected, well-formed formulas that do not contain reserved

facts evaluate the same whether reserved facts are hidden or not.Proposition 2: Let Tr be a set of traces and ' a well-formed trace for-mula. We have that

Tr ✏?' iff hide(Tr) ✏?

'

where ? is either 8 or 9.

Proof. We start with the case ? = 9 and show the stronger statementthat for a trace tr

8✓.9✓ 0. if (tr, ✓) ✏ ' then (hide(tr), ✓ 0) ✏ '

and8✓.9✓ 0. if (hide(tr), ✓) ✏ ' then (tr, ✓ 0) ✏ '.

We will show both statements by nested induction on |tr| and thestructure of the formula. (The underlying well-founded order is thelexicographic ordering of the pairs consisting of the length of the traceand the size of the formula.)If |tr| = 0 then tr = [] and tr = hide(tr) which allows us to directlyconclude letting ✓

0 := ✓.If |tr| = n, we define tr and F such that tr = tr · F. By inductionhypothesis we have that

8✓.9✓ 0. if (tr, ✓) ✏ ' then (hide(tr), ✓ 0) ✏ '

3rd step

103


is a trace containing A() in tracesmsr(JPK). Observe that JPK containsof the following rules:

JPK = {[] -[ ]! state[](),state[]() -[Eq(’apple’, ’orange’)]! state

1

(),

state1

() -[Event(), A()]! state1,1

(),

state1,1

() -[ ]! [],

[] -[NotEq(’apple’, ’orange’]! state2

(),

state2

() -[ ]! []}

There is indeed a trace that contains A(), for example the trace⇥{Eq(’apple’, ’orange’) }#, {Event(), A() }#

⇤.

However, this trace does not satisfy the axiom ↵eq, which means thatit is not important for the verification of translated security properties,as we will show in the following.

The function filter removes traces that are incorrect with respect toour axioms ↵.Definition 16: Let ↵ be the trace formula as defined in Definition 15

and Tr a set of traces. We define

filter(Tr) := {tr 2 Tr | 8✓.(tr, ✓) ✏ ↵}

The following proposition states that if a set of traces satisfies thetranslated formula, then the filtered traces satisfy the original for-mula, too.Proposition 1: Let Tr be a set of traces and ' a trace formula. We havethat

Tr ✏? J'K? iff filter(Tr) ✏?'


Proof. We first show the two directions for the case ? = 8. We start byshowing that Tr ✏8 J'K implies filter(Tr) ✏ '.

Tr ✏8 J'K8 ) filter(Tr) ✏8 J'K8 (since filter(Tr) ✓ Tr)

, filter(Tr) ✏8↵ ) ' (by definition of J'K8)

, filter(Tr) ✏8' (since filter(Tr) ✏8

↵)

We next show that filter(Tr) ✏8' implies Tr ✏8 J'K8.

filter(Tr) ✏8' ) filter(Tr) ✏8

↵^' (since filter(Tr) ✏8↵)

, Tr ✏8 ¬↵_ (↵^')(since filter(Tr) ✓ Tr and (Tr \ filter(Tr)) 6✏8

↵)

, Tr ✏8↵ ) '

, Tr ✏8 J'K8 (by definition of J'K8)

3rd step (ctd.)

104




1

(),

state1

() -[Event(), A()]! state1,1

(),

state1,1

() -[ ]! [],


(),

state2

() -[ ]! []}


⇤.




filter(Tr) := {tr 2 Tr | 8✓.(tr, ✓) ✏ ↵}








↵)





↵)

, Tr ✏8↵ ) '





1

(),

state1

() -[Event(), A()]! state1,1

(),

state1,1

() -[ ]! [],


(),

state2

() -[ ]! []}


⇤.




filter(Tr) := {tr 2 Tr | 8✓.(tr, ✓) ✏ ↵}








↵)





↵)

, Tr ✏8↵ ) '


Universal Composability

105

106

⇡

8A9Sim s.t.8E

107

An example: Encryption

(Enc,m) cypher

cypher

(Dec,cypher) m (Dec,garbage) gdec

gdec

|m|


108

key-manageable functionality

• Assume F can be implemented in a certain way:

• new: create , store

• command, m: return

• in other words: stateless except for key

109

k

implcommand

(k,m)

k$ KG(1n)


110

Enc Sig+PIN

emimpl encimpldecimpl sigimpl verimplder

impl encimpldecimpl sigimpl verimplder

impl encimpl ver

impl encimpl ver

Mines

implboom

implboom

for all policies, for all ku-functionalities

Assumptions

• ku-functionalities are key-manageable, keys have to be unguessable

• (secure set-up phase)

• a key-wrapping scheme according to the definition from [KSW,2011]

• (inputs do not provoke the commitment problem)

111

Modelling & Reality(Universally composable key-management)

112

113

ku-functionalities

Fi

decrypt encrypt

114

ku-functionalities

Fi

decrypt encrypt

FKM

decrypt

115

ku-functionalities

Fi

decrypt encryptdecrypt

116

key-manageable functionalities

Fi

117

ku-functionalities

Fi

New k (enc,k,m) cyphernot realisable!

= enck(0|m|)

118

ku-functionalities

Fi

New credential (enc,credential,m) enck(0|m|)

(k KG(1n), credential {0, 1}|k|) 2 List

potentially realisable

keys & credentials

• design enforced introduction of credentials

• but it makes sense:

119

„owner of the key“≙ e.g. „the signer“

„key“≙ „credential“

• our goal was key-management..

Further work

120

I UC F ) I UC F ?

traditional functionality

implementation using keys

functionality with credentials

implementation with key-credential

mapping

Foundations for Analyzing Security APIs in the symbolic...

Documents

Transcript of Foundations for Analyzing Security APIs in the symbolic...