Foundations for analyzing security APIs in the symbolic

HAL Id tel-00942459httpstelarchives-ouvertesfrtel-00942459v2

Submitted on 25 Jun 2014

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents whether they are pub-lished or not The documents may come fromteaching and research institutions in France orabroad or from public or private research centers

Lrsquoarchive ouverte pluridisciplinaire HAL estdestineacutee au deacutepocirct et agrave la diffusion de documentsscientifiques de niveau recherche publieacutes ou noneacutemanant des eacutetablissements drsquoenseignement et derecherche franccedilais ou eacutetrangers des laboratoirespublics ou priveacutes

Foundations for analyzing security APIs in the symbolicand computational model

Robert Kuumlnnemann

To cite this versionRobert Kuumlnnemann Foundations for analyzing security APIs in the symbolic and computationalmodel Cryptography and Security [csCR] Eacutecole normale supeacuterieure de Cachan - ENS Cachan 2014English NNT 2014DENS0001 tel-00942459v2

ENSC-201X-NYYY

T H Egrave S E D E D O C T O R AT D E Lrsquo Eacute C O L E N O R M A L ES U P Eacute R I E U R E D E C A C H A N

Preacutesenteacutee par

Monsieur Robert Kuumlnnemann

Pour obtenir le grade de

D O C T E U R D E Lrsquo Eacute C O L E N O R M A L E S U P Eacute R I E U R ED E C A C H A N

Domaine informatique

Sujet de la thegravese

F O U N D AT I O N S F O R A N A LY Z I N G S E C U R I T Y A P I SI N T H E S Y M B O L I C A N D C O M P U TAT I O N A L M O D E L

Thegravese preacutesenteacutee et soutenue agrave Cachan le 07012014 devant le jurycomposeacute de

Ralf Kuumlsters Professeur Rapporteur

Matteo Maffei Professeur Rapporteur

Hubert Comon-Lundh Professeur Examinateur

Joshua Guttman Professeur Examinateur

Thomas Jensen Directeur de recherche Examinateur

David Pointcheval Directeur de recherche Examinateur

Steve Kremer Directeur de recherche Directeur de thegravese

Graham Steel Chargeacute de recherche Directeur de thegravese

Laboratoire Speacutecification et VeacuterificationENS de Cachan UMR 8643 du CNRS61 avenue du Preacutesident Wilson94235 CACHAN Cedex France

F O U N D AT I O N S F O R A N A LY Z I N G S E C U R I T Y A P I S I N T H ES Y M B O L I C A N D C O M P U TAT I O N A L M O D E L

robert kuumlnnemann

October 2013

Robert Kuumlnnemann Foundations for analyzing security APIs in the sym-

bolic and computational model copy October 2013

A map is not the territory it represents but if correct it has a similar

structure to the territory which accounts for its usefulness

mdash Alfred Korzybski

Fuumlr meine Eltern

A B S T R A C T

Security critical applications often store keys on dedicated HardwareSecurity Modules (HSMs) or key-management servers to separate sen-sitive cryptographic operations from more vulnerable parts of thenetwork Access to such devices is given to protocol parties by themeans of Security APIs eg the RSA PKCS11 standard IBMrsquos CCAand the Trusted Platform Module (TPM) API all of which protect keysby providing an API that allows to address keys only indirectly

This thesis has two parts The first part deals with formal meth-ods that allow for the identification of secure configurations in whichSecurity APIs improve the security of existing protocols e g in sce-narios where parties can be corrupted A promising paradigm is toregard the Security API as a participant in a protocol and then usetraditional protocol analysis techniques But in contrast to networkprotocols Security APIs often rely on the state of an internal databaseWhen it comes to an analysis of an unbounded number of keys thisis the reason why current tools for protocol analysis do not workwell We make a case for the use of Multiset Rewriting (MSR) as theback-end for verification and propose a new process calculus whichis a variant of the applied pi calculus with constructs for manipula-tion of a global state We show that this language can be translatedto MSR rules while preserving all security properties expressible in adedicated first-order logic for security properties The translation hasbeen implemented in a prototype tool which uses the tamarin proveras a back-end We apply the tool to several case studies among whicha simplified fragment of PKCS11 the Yubikey security token and acontract signing protocol

The second part of this thesis aims at identifying security proper-ties that (a) can be established independent of the protocol (b) allowto catch flaws on the cryptographic level and (c) facilitate the analysisof protocols using the Security API We adapt the more general ap-proach to API security of Kremer et al to a framework that allows forcomposition in form of a universally composable key-managementfunctionality The novelty compared to other definitions is that thisfunctionality is parametric in the operations the Security API allowswhich is only possible due to universal composability A Security APIis secure if it implements correctly both key-management (accordingto our functionality) and all operations that depend on keys (with re-spect to the functionalities defining those operations) We present animplementation which is defined with respect to arbitrary functionali-ties (for the operations that are not concerned with key-management)and hence represents a general design pattern for Security APIs

R Eacute S U M Eacute

Dans une infrastructure logicielle les systegravemes critiques ont souventbesoin de garder des cleacutes cryptographiques sur des Hardware Secu-rity Modules (HSMs) ou des serveurs consacreacutes agrave la gestion de cleacutesIls ont pour but de seacuteparer les opeacuterations cryptographiques tregraves cri-tiques du reste du reacuteseau qui est plus vulneacuterable Lrsquoaccegraves aux cleacutes estfourni au travers des APIs de seacutecuriteacute comme par exemple le standardPKCS11 de RSA CCA drsquoIBM ou encore lrsquoAPI du Trusted PlatformModule qui ne permettent qursquoun accegraves indirect aux cleacutes

Cette thegravese est composeacutee de deux parties La premiegravere introduit desmeacutethodes formelles qui ont pour but lrsquoidentification des configura-tions dans lesquelles les APIs de seacutecuriteacute peuvent ameacuteliorer le niveaude sucircreteacute des protocoles existants par exemple en cas de compromis-sion drsquoun participant Un paradigme prometteur considegravere les APIsde seacutecuriteacute comme des participants drsquoun protocole afin drsquoeacutetendrelrsquoemploi des meacutethodes traditionnelles drsquoanalyse de protocole agrave cesinterfaces Agrave lrsquoopposeacute des protocoles reacuteseau les APIs de seacutecuriteacute uti-lisent souvent une base de donneacutees interne Ces outils traditionnelsdrsquoanalyse ne sont adapteacutes que pour le cas ougrave le nombre des cleacutes estborneacute a priori

Nous exposons eacutegalement des arguments pour lrsquoutilisation de lareacuteeacutecriture de multi-ensembles MSR (Multiset Rewriting) lors de la veacute-rification De plus nous proposons un langage deacuterivant du pi-calculappliqueacute posseacutedant des opeacuterateurs qui permettent la manipulationdrsquoun eacutetat explicite Ce langage se traduit en regravegles MSR en preacuteser-vant des proprieacuteteacutes de seacutecuriteacute qui srsquoexpriment dans une logique depremier ordre La traduction a eacuteteacute impleacutementeacutee sous forme drsquoun pro-totype produisant des regravegles speacutecifiquement adapteacute au prouveur ta-marin Plusieurs eacutetudes de cas dont un fragment de PKCS11 le jetondrsquoauthentification Yubikey et un protocole de signature de contratoptimiste ont eacuteteacute effectueacutees

Le deuxiegraveme partie de la preacutesente thegravese a pour but lrsquoidentificationdes proprieacuteteacutes de seacutecuriteacute qui a) peuvent ecirctre eacutetablies indeacutependam-ment du protocole b) permettent de trouver des failles au niveau de lacryptographie c) facilitent lrsquoanalyse des protocoles utilisant cette APIde seacutecuriteacute

Nous adoptons ici lrsquoapproche plus geacuteneacuterale de Kremer et al dansun cadre qui permet la composition universelle agrave travers une fonc-tionnaliteacute de gestion de cleacutes La nouveauteacute de ce genre de deacutefinitionest qursquoelle deacutepend des opeacuterations mises agrave disposition par lrsquoAPI Ceciest seulement possible gracircce agrave la composition universelle Une APIde seacutecuriteacute nrsquoest sucircre que si elle reacutealise correctement la gestion descleacutes (selon la fonctionnaliteacute preacutesenteacutee dans ce travail) et les opeacuterations

utilisant les cleacutes (selon les fonctionaliteacutes qui les deacutefinissent) Pour fi-nir nous preacutesentons aussi une impleacutementation de gestion de cleacutes deacute-finie par rapport agrave des opeacuterations arbitraires utilisant des cleacutes nonconcerneacutees par la gestion des cleacutes Cette reacutealisation repreacutesente ainsiun modegravele geacuteneacuterique pour le design des APIs de seacutecuriteacute

P U B L I C AT I O N S

Some ideas have appeared previously in the following publications

[1] Steve Kremer Robert Kuumlnnemann and Graham Steel lsquoUniver-sally Composable Key-Managementrsquo In European Symposium

on Research in Computer Security Springer 2013 pp 327ndash344

[2] Robert Kuumlnnemann and Graham Steel lsquoYubiSecure FormalSecurity Analysis Results for the Yubikey and YubiHSMrsquo InWorkshop on Security and Trust Management Springer 2012pp 257ndash272

A C K N O W L E D G M E N T S

First things first I would like to thank my supervisors Steve Kremerand Graham Steel for their patient guidance as well as the time andeffort they have invested in me I always found an open ear andvaluable advice in scientific questions as well as question outsidethis matter

While preparing my thesis I was lucky to work in a relaxing andstimulating environment which I found in the PROSECCO group Inparticular Iro Bartzia and Alfredo Pironti whom I shared office withhave been great partners in discussion and in crime Many laughswere had I would also like to thank Benjamin (notre benjamin) whojoined us for an internship in my last year and helped me with thereacutesumeacute in French

Furthermore I wish to thank my friends Esfandiar Mohammadiand Guillaume Scerri as well as the other members of the Labora-toire Speacutecification et Veacuterification for their help and for the conversa-tions we had I am likewise indebted to Dominique Unruh for hisdiscussion and advice about all things UC

A very special thank you goes to Milla for all the love and patienceencouragement and distraction she had for me Well and for readingthe manuscript of course

Most importantly none of this would have been possible withoutthe love and support of my parents and my brother who read themanuscript almost in full and gave excellent critique

C O N T E N T S

Introduction 1

1 introduction 3

11 Cryptographic security APIs 6

12 security APIs and network protocols 10

13 security APIs in context of arbitrary protocols 11

i analysis of stateful protocols in the symbolic

model 15

2 preliminaries 17

21 Terms and equational theories 17

22 Facts 18

23 Substitutions 18

24 Sets sequences and multisets 18

3 a survey on existing methods 21

31 Running Examples 22

32 StatVerif 24

321 Running Example 4 Left-or-right encryption inStatVerif 25

322 Running Example 5 WrapDec in StatVerif 25

33 Abstraction by set-membership 26

331 Running Example 5 WrapDec using abstrac-tion by set-membership 28

332 Running Example 4 Left-or-right encryption 30

34 Why Horn clause approaches are unsuitable 31

35 Other Approaches 35

36 The tamarin-prover 35

361 Labelled multiset rewriting 36

362 Adversarial deduction 39

363 Security Properties 39

4 analysis of the yubikey protocol and the yubihsm 43

41 Yubikey and Yubikey Authentication Protocol 44

411 About the Yubikey Authentication Protocol 44

412 Formal Analysis (Uncompromised Server) 47

42 The YubiHSM 50

421 About the YubiHSM 50

422 Two Attacks on the Implementation of Authen-ticated Encryption 51

423 Analysis in the Case of Server Compromise 53

43 Evaluation 55

431 Positive Results 55

432 Negative Results 56

xvi contents

433 Possible changes to the YubiHSM 57

434 Methodology 58

435 Future work 59

5 a process calculus with state 61

51 Related work 62

52 A cryptographic pi calculus with explicit state 62

521 Syntax and informal semantics 63

522 Semantics 66

523 Discussion 69

53 A translation from processes to multiset rewrite rules 71

531 Translation of processes 71

532 Translation of trace formulas 77

533 Discussion 78

54 Correctness of the translation 85

541 Lemmas about message deduction 89

542 Inclusion I 89

543 Inclusion II 93

55 Case studies 94

551 Security API agrave la PKCS11 95

552 Needham-Schoeder-Lowe 96

553 Yubikey 96

554 The GJM contract signing protocol 97

555 Further Case Studies 97

ii when is a security api ldquosecurerdquo 99

6 when is a security api secure 101

61 Criteria for persuasive definitions 101

62 Characteristics of a ldquosecurerdquo security API 102

63 Composability 102

64 Overview 103

65 Related work 103

7 introduction to gnuc 105

71 Preliminaries 105

72 Machines and interaction 106

73 Defining security via ideal functionalities 107

8 key-management functionality and refer im-plementation 111

81 Design Rationals 112

811 Policies 112

812 Sharing Secrets 113

813 Secure Setup 113

814 Operations required 114

82 Key-usage (ku) functionalities 114

821 Credentials 115

822 Key-manageable functionalities 115

83 Policies 116

contents xvii

84 FKM and the reference implementation 117

841 Structure and Network setup 118

842 Setup phase 120

843 Executing commands in Cpriv 120

844 Creating keys 121

845 Wrapping and Unwrapping 122

846 Changing attributes of keys 124

847 Corruption 124

848 Public key operations 125

849 Formal definition of FKM 126

8410 Formal definition of the security token network 127

9 analysis of the key-management functionality 129

91 Properties 129

92 Limitations 131

93 Discussion 133

10 proof of emulation 137

11 a simple case study 141

111 Realizing FKM for a static key-hierarchy 141

112 An example implementation of the authenticated chan-nel functionality 143

Conclusion 149

12 conclusion and perspectives 151

121 Analysis of protocols using security APIs 151

122 Analysis of security APIs 154

Appendix 159

a listings for part i 161

a1 Listings for Chapter 3 161

b proofs for part i 197

b1 Correctness of tamarinrsquos solution procedure for trans-lated rules 197

b2 Proofs for Section 54 199

c initialisation and setup in FKM 241

c1 Initialisation phase 241

c2 Handling of the setup phase in FKM and STi 241

c3 Setup assumptions for the implementation 242

d the complete proof of emulation 243

bibliography 265

L I S T O F F I G U R E S

Figure 1 Policy graph strict role separation 9

Figure 2 Policy graph no separation but still avoidingthe attack in Example 1 9

Figure 3 Syntax of the StatVerif calculus 24

Figure 4 Example 4 in StatVerif The deconstructors car

and cdr extract the first respectively the last el-ement of a pair 25

Figure 5 Modelling for Example 5 in AVISPA Interme-diate Format (AIF) The full code can be foundin Listing 16 in Section A1 p 164 29

Figure 6 Modelling for Example 4 in AIF The full codecan be found in Listing 14 in Section A1 p 16231

Figure 7 Structure of the One-time Password (OTP) (ses-sion 19 token 16) 46

Figure 8 Advanced Encryption Standard (AES) in countermode (simplified) 52

Figure 9 Syntax 63

Figure 10 Deduction rules 66

Figure 11 Operational semantics 68

Figure 12 Definition of JP p xK 75

Figure 13 Example trace for translation of Pnew 77

Figure 14 Definition of JP p xK=ptwhere middot

= middot ifa = b and empty otherwise 91

Figure 15 Distributed security tokens in the network (left-hand side) and idealized functionality FKM inthe same network (right-hand side) 118

Figure 16 Visualisation of Case 2 217

Figure 17 Visualisation of Case 2a 218

Figure 18 Visualisation of Case 2b 218

List of Tables xix

L I S T O F TA B L E S

Table 1 Case studies 95

L I S T I N G S

Listing 1 Fach with session parameters 〈Ppid Qpid label〉Note that in this example every step can onlybe executed once 107

Listing 2 Executing command C on a handle hwith datam (FKM above STi below) 121

Listing 3 Creating keys of type F and attribute a (FKM

above STi below) 121

Listing 4 Wrapping key h2 under key h1 with additionalinformation id (FKM above STi below) 122

Listing 5 Unwrapping w created with attribute a2 F2and id using the key h1 existxp(x) holds if thereexists exactly one x such that p(x) holds (FKM

Listing 6 Changing the attribute of h to a prime (FKM aboveSTi below) 124

Listing 7 Corruption procedure used in steps corrupt

and wrap 125

Listing 8 Corrupting h (FKM above STi below) 125

Listing 9 Computing the public commands C using theinputs public and m (FKM note that STi doesnot implement this step) 125

Listing 10 A signature functionality FSIG 142

Listing 12 The modelling of Example 4 in StatVerif byArapinis et al [5] 161

xx Listings

Listing 13 An attempt to express Example 5 in StatVerifNote that the key store is modelled as singlestate cell which refers to a list of keys This listgrows in size for every newly generated keyProVerif did not terminate on the horn clausesproduced by StatVerifrsquos translation procedurein the experiments we conducted 161

Listing 14 A modelling of Example 4 in AIF 162

Listing 15 Another modelling of Example 4 in AIF 163

Listing 17 Modelling of the Yubikey authentication proto-col in tamarinrsquos MSR calculus The counter ismodelled as a term constituting a multiset ofconstants where the cardinality of the multi-set equals the size of the counter 166

Listing 18 Modelling of the Yubikey authentication pro-tocol in conjunction with the YubiHSM for-malised in tamarinrsquos MSR calculus The counteris modelled as a term constituting a multiset ofconstants where the cardinality of the multisetequals the size of the counter 168

Listing 19 Modelling of the Yubikey authentication pro-tocol formalised in tamarinrsquos MSR calculus Thecounter is modelled using a ldquosuccessor ofrdquo con-structor The permanent fact IsSmaller can beproduced by the adversary to proof that onecounter value is smaller than another We needto enforce transitivity in order to be able toproof our claims ndash that means we require (us-ing an axiom) each trace to contain IsSmaller(a

c) should IsSmaller(a b) and IsSmaller(a c) bepresent for a b c isin M Succ models a func-tional relation If Succ(a b) then the adver-sary was able to show that b is the successorof a The relation modelled by Smaller is notfunctional If Smaller(a b) then the adversarywas able to show that a is smaller than b TheTheory() action is used to enforce that this rela-tion (to the extend it is needed in this trace) hasto be build up before running the first protocolactions 173

Listing 20 Modelling of the Yubikey authentication pro-tocol in conjunction with the YubiHSM mod-elling the ldquosmaller-thanrdquo relation as describedin Listing 19 177

Listing 21 The running example from Chapter 5 183

Listing 22 Security agrave la Public-Key Cryptography Stan-dards Number 11 (PKCS11) 184

Listing 23 Needham-Schoeder-Lowe protocol 186

Listing 24 Yubikey protocol 187

Listing 25 Garay Jakobsson and MacKenziersquos optimisticcontract signing protocol 190

Listing 26 Key-server example from [74] 192

Listing 27 Key-server example from [74] modelled underthe use of insert and lookup 194

Listing 28 Left-right example from [5] described in Ex-ample 4 on p22 195

Listing 29 Initilisation (FKM) 241

Listing 30 Initilisation (STi) 241

Listing 31 The setup phase sharing keys (FKM) 241

Listing 32 The setup phase sharing keys (STi) 241

Listing 33 The setup phase terminating the setup phase(FKM) 242

Listing 34 The setup phase terminating the setup phase(STi) 242

Listing 35 procedure for corrupting a credential c 245

Listing 36 Procedure for corrupting a credential c 252

A C R O N Y M S

AEAD Authenticated Encryption with Associated Data

AES Advanced Encryption Standard

AIF AVISPA Intermediate Format

API Application Programming Interface

ATM Automated teller machine

AVISPA Automated Validation of Internet Security Protocols andApplications

CBC Cipher-block chaining mode of operation

CCA IBM Common Cryptographic Architecture

CCM Counter mode of operation with CBC-MAC

CC Common Criteria for Information Technology SecurityEvaluation

CPSA Cryptographic Protocol Shapes Analyzer

xxii acronyms

CRC Cyclic Redundancy Check

EMV Europay MasterCard and Visa

GNUC GNUC is Not UC

HMAC keyed-hash Message Authentication Code

HOTP keyed-hash Message Authentication Code (HMAC)-basedOne-time Password Algorithm

HSM Hardware Security Module

IV Initialisation Vector

MAC Message Authentication Code

MSR Multiset Rewriting

OATH Initiative For Open Authentication

OTP One-time Password

PIN Personal Identification Number

PKCS11 Public-Key Cryptography Standards Number 11

PPT probabilistic polynomial-time

RFC Request For Comments

RFID Radio-frequency identification

RSA RSA Security Inc

SIM Subscriber Identity Module

SIV Synthetic Initialization Vector

TLS Transport Layer Security

TPM Trusted Platform Module

UC Universal Composability

USB Universal Serial Bus

I N T R O D U C T I O N

1I N T R O D U C T I O N

The more complex a system the more difficult it is to verify thatit is secure Computers used in a network protocol are often usedfor other tasks such as reading emails and surfing on the Internettoo The hardware and software components necessary to perform allthose tasks not only add to the complexity of analysing the systembut also provide an increased attack surface for compromising partsof the system that are important for the security of the protocol

The computer at your bank that verifies your Personal Identifica-tion Number (PIN) should not be used for reading emails for exam-ple It should in fact only do what is necessary to check your PIN Itshould be behind locked doors so it can only be accessed by autho-rized personnel ndash this way the interface between a potential outsideattacker and the computer is reduced If the computer that checksPINs is separate from the computer that provides you with a key-pad and transfers your PIN and both are separate from the computeremails are read on then there is actually hope that we can analysethose systems in isolation Furthermore if e g the computer thatchecks PINs can be shown to never accept an incorrect PIN a certainamount of security can be guaranteed for the system as a whole nomatter if the computer that emails are read on can be trusted or not

There are companies that sell devices dedicated to performing PIN

verification Those devices can only be accessed using a clearly de-fined Application Programming Interface (API) Furthermore thereare a number of hardware measures in place that are supposed toprevent any other way of accessing the device or more precisely theinformation contained on this device Such measures include for ex-ample strong enclosures that make it difficult to obtain physical ac-cess to the main board but also tamper detectionresponse circuitrythat overwrites sensitive cryptographic information in case an intru-sion of the enclosure is detected [43]

The literature often uses the term security token for such a deviceWhile most people are aware what kind of device a PC is and manyof them are aware that there are attacks for example viruses wormstrojan horses etc on PCs to most people the term ldquosecurity tokenrdquomeans nothing Moreover the idea of a tamper-resistant device withcryptographic functions appears to be a very specific solution for avery specific problem something that is for example part of the op-erations of a financial institution Many are not aware of the ubiquityof security tokens in our everyday lives Not only is it the case thatsecurity tokens are indispensable for money transfers of all kinds be

4 introduction

it online banking the use of ATMs (cash machines) or credit card ter-minals Also e-commerce whose security hinges on the security ofthe channel between client and merchant via the Transport Layer Se-curity (TLS) protocol relies on devices dedicated for cryptographicoperations Many large vendors employ such devices to establish TLS

connections Even smaller vendors who cannot afford such devicesrely on the integrity of the keys stored with the certification authori-ties for the use of the TLS protocol which themselves (should) storetheir signature keys on security tokens

Security tokens have their part in most aspects of our lives that haveto do with money but they are with us in a quite literal sense tooMany security tokens are integrated circuits we carry in our pocketsso-called smart cards In some cities they are used as tickets for pub-lic transport as part of a public bicycle renting system or for publiclibraries They are frequently employed as part of the public healthsystem too Of course smart cards also play a role in our financialactivities We use them for payments and money withdrawal Eu-rosmart reports that in 2012 alone 6970 billion smart cards whereshipped in telecommunication financial services government trans-port pay TV and other areas [42] Telecommunication makes up for51 billion of this figure the reason is the Subscriber Identity ModuleIt is used with practically every mobile phone subscription and se-curely stores the information necessary to identify and authenticatesubscribers on mobile telephony devices such as mobile phones andcomputers There are an estimated 68 billion active mobile phonesubscriptions in 2013 hence about the same number of SubscriberIdentity Module (SIM) cards in use [52] Considering that there arearound 71 billion people in world (as of 2013) this number is sur-prisingly high The number of PCs seems modest in comparison Atthe beginning of 2013 Deloitte Canada estimated that in 2013 therewill be 16 billion PCs in use [75] These numbers bear witness of theimpact that the development and use of security tokens have had onmodern life The analysis of the secure operating of those device isthus of utmost importance

In this thesis we will use the term security API for the interface thatdevices like security tokens provide to the outside The concept of asecurity API entails the following characteristics

a They provide (often limited) access to sensitive resources to theoutside which is untrusted

b The implementation of the security API is trusted

c Access is only possible via the security API

A security API is often implemented using an external piece ofhardware with a tamper-resistant enclosure for example in form ofa security token But the concept extends to other domains too A

introduction 5

virtual machine running in a secure environment or an API accessi-ble to some untrusted code that runs in a sandbox shares the samecharacteristics as well as JavaScript code embedded in a website (un-trusted) accesses via the web browserrsquos implementation of JavaScriptConsider the following examples

bull Smart cards pocket-sized cards with an integrated circuit forexample the SIM used in mobile phones and the EMV standardused for debit cards as well as credit cards provide a securityAPI to the mobile phone in use

bull PKCS11 [82] defines a platform-independent API to security to-kens for example smart cards but also HSMs HSMs are physicalcomputing devices that can be attached directly to a server andcommunicated via Ethernet Universal Serial Bus (USB) or otherservices providing logical and physical protection for sensitiveinformation and algorithms

bull The IBM Common Cryptographic Architecture (CCA [25]) is asecurity API supported by the IBM 4764 and IBM 4758 Crypto-graphic Coprocessors Since CCA provides many functions thatare of special interest in the finance industry it is widely usedin the ATM network for example to encrypt decrypt or verifyPINs Both PKCS11 and CCA are commonly used interfaces toHSMs

bull Small security tokens for example the Yubikey manufacturedby the Swedish company Yubico provide a security API Theycan provide one-time passwords used for secure authentication

bull The Trusted Platform Module (TPM [87]) is the specification ofa secure cryptographic processor and hence defines a securityAPI that can store keys A TPM chip is built into most PCs andnotebooks that are sold today It can be used to provide full diskencryption password protection and to assure the integrity ofa platform e g the operating system running with a set ofapplications

bull Key-management protocols for instance the OpenPGP HTTPKeyserver Protocol [91] can also be seen as security APIs Thekey-server in such protocols also provides a limited interface tothe outside In particular the computer running the key-serveris likely to be protected against physical access This exampleshows that a security API is not necessarily the interface to asecurity token

bull The Google maps API provides an interface between a set ofservers trusted by Google and the Internet which is untrustedThis shows that a security API is not necessarily a cryptographicAPI

6 introduction

Although security APIs mainly describe the interface between thetrusted implementation and the outside we will sometimes use thisterm to refer to the trusted implementation which maybe a piece ofhardware a library or a network of computers

11 cryptographic security apis

Many network protocols rely on cryptographic operations Crypto-graphic operations in turn rely on secrets which a) should not beextractable by the adversary and b) often need to be honestly gener-ated Let us assume for the rest of this thesis that the implementationof the security API has a higher level of confidence than the rest ofthe system This assumption is based on the fact that it is easier toverify than the overall system since it is less complex Furthermoreit can and often is designed with security as a main goal somethingthat is hardly true for an all-purpose computer Under this assump-tion it seems rational to put the cryptographic secrets on the securityAPI and forbid all direct access to them

This has two consequences which further outline how a crypto-graphic security API operates First all algorithms that depend oncryptographic secrets need to be implemented inside the security APISecond all other parts of the system shall stay outside the device (asit should be as small as possible) Assuming such a system mdash a net-work of all-purpose computers that run some protocol together andaccess one or many security APIs to compute cryptographic valuesused in the protocol mdash there are four layers where things could gowrong

layer 1 The overall system including the security API and otherprotocol parties from the perspective of a network adversary

Example The protocol for PIN verification is faulty ndash an ad-versary can simply replay a previous PIN authentication to theserver The authentication server communicates with the secu-rity API to verify that the PIN was signed by the terminal butit does not check for its freshness i e whether the same queryhas been emitted before and thus performs an unauthorizedtransaction

layer 2 The security API according to its specification from the per-spective of any machine that has full or partial access to it

Example The security API contains a command to export aPIN derivation key i e a cryptographic secret that allows togenerate a PIN given an account number The command is therefor backup uses but it allows the adversary to export the keyin a way that reveals its value Now the adversary can computethe PIN entry herself and perform an unauthorised transactionNote that the attacker only uses a sequence of perfectly legal

11 cryptographic security apis 7

commands that all work within their specification Sometimessuch attacks on security APIs are called logical attacks

layer 3 The actual algorithms that the security API computes inorder to meet its specification from the perspective of any ma-chine that has full or partial access to it

Example The algorithm used to derive PINs is flawed The ad-versary can forge a PIN without the knowledge of the derivationkey

layer 4 The physical implementation of the security API whateverform it has Attacks can make use of the concrete implementa-tion of the algorithm as well as of the hardware it runs on

Example The adversary can measure the power consumptionduring computation of the PIN He is able to do so because theenclosure does not protect the charger The peaks in his readingallow him to conclude the value of the generated PIN becausethe PIN derivation algorithm produces a different processor loaddepending on its output

This thesis concentrates on attacks on layer one to three Hardwareattacks are out of scope of this work

The following attack was discovered by Jolyon Clulow [27] andillustrates that requests which are harmless on their own can be com-posed to form an attack It also shows that it is not always clear howto classify attacks according to the above scheme

Example 1 (WrapDecrypt Conflict ) Consider a security API thatcontains a store for an arbitrary number of keys The security APIallows the following five kinds of request

1 When it receives a creation request it draws a random key kand another random value h the handle In its database itstores that h points to the key k and that the attribute of his the value ldquoinitrdquo

2 When it receives a request ldquoallow decryptionrdquo for a handle hno matter what the current attribute of h is it is changed toldquodecryptrdquo

3 Similarly when it receives a request ldquoallow wrappingrdquo for a han-dle h no matter what the current attribute of h is it is changedto ldquowraprdquo

4 When it receives a wrapping request for h1 and h2 it performsa database lookup for the keys k1 and k2 that h1 and h2 re-spectively point to and the attribute a1 associated to h1 If a1is ldquowraprdquo it outputs the encryption of k2 under k1 If a lookupfails no output is produced

8 introduction

5 When it receives a decryption request for a handle h and somedata c it performs a database lookup for the key k that h pointsto as well as the attribute a associated to h If a1 is ldquodecryptrdquoit outputs the decryption of c using k if decryption succeedsOtherwise if a lookup fails or the decryption fails no output isproduced

Furthermore the security API would be expected to specify thedual operations to wrapping and decryption namely unwrapping(which decrypts a wrapping using the key a handle points to andstores the result as a key giving a new handle to the imported key tothe user) and encryption (which encrypts a plaintext using the key agiven handle points to) For this example however theses operationsare not of importance

Although there is no single request that reveals the value of a key kcreated on the device it is possible for an attacker to learn this valueShe proceeds as follows

1 The attacker requests the creation of a key and obtains a handleh The store of the security API consists of a mapping from h

to a randomly drawn key k and a mapping from h to the valueldquoinitrdquo

2 She requests the security API to ldquoallow wrappingrdquo for the han-dle h Now h is mapped to ldquowraprdquo instead of ldquoinitrdquo Otherwisethe store remains unchanged

3 She requests a wrapping for h with itself Since the attribute ofh is ldquowraprdquo she obtains k encrypted under itself

4 She requests the security API to ldquoallow decryptionrdquo for the han-dle h Now h is mapped to ldquodecryptrdquo instead of ldquowraprdquo Oth-erwise the store remains unchanged

5 She requests a decryption of the previously obtained encryptionof k under k using the handle h Since h has the attributeldquodecryptrdquo and h points to k the decryption step succeeds andthe attacker obtains the key k in the clear Since the secrecy ofkeys generated on the device is typically guaranteed by securityAPIs we consider this an attack

This attack can be regarded as an attack on the second layer or asan attack on the third layer Let us discuss those views one after theother It is not important which encryption scheme is really used anysecurity API that follows this specification is prone to this attack Theattack succeeds because the security API fails to separate the rolesbetween a key used for wrapping and unwrapping and a key usedfor encryption and decryption Role separation can be implementedby using the attribute to mark the role of each key This attack is

only possible because a key is allowed to switch roles from ldquowraprdquoto ldquodecryptrdquo The ldquoallow wrappingrdquo and ldquoallow decryptrdquo requestsshould only succeed if the attribute associated to the handle is ldquoinitrdquoThis implements what we call a policy for keys Only keys with theattribute ldquowraprdquo are allowed to wrap and unwrap only keys withthe attribute ldquodecryptrdquo can encrypt and decrypt and the attributes ofeach key can only move as indicated by the graph in Figure 1

decrypt

Figure 1 Policy graph strict role separation

Another more permissive policy is secure despite not strictly sepa-rating the roles associated to the attributes ldquowraprdquo and ldquodecryptrdquo(wewill formally prove this claim in Chapter 5) In addition to the pre-vious policy this one allows to change the attribute of a key fromldquodecryptrdquo to ldquowraprdquo but not the other way around (see Figure 2)

decrypt

Figure 2 Policy graph no separation but still avoiding the attack in Exam-ple 1

On the one hand the nature of Clulowrsquos attack suggests that it isan attack on layer two On the other hand it can be argued thatthe encryption scheme used for wrapping and unwrapping shouldbe a completely different encryption scheme from the one used forencryption and decryption since the requirements for those schemesare different It should e g be impossible to forge a wrapping thatis to produce a wrapping outside the device that can be unwrapped(imported) with a key generated on the device Encryption and de-cryption have different requirements so one could consider the spec-ification as incomplete in this regard and the implementation of en-cryption and wrapping using the same algorithm as an unfortunatechoice

10 introduction

Had two completely different encryption scheme been used forwrapping and decryption then this attack could have been circum-vented ndash depending on whether wrapping and decryption share thesame keys and if they do how exactly those schemes interact witheach other

The first part of this thesis discusses the analysis of security APIsas participants in a protocol and on their own both in the symbolicmodel of cryptography which allows to capture attacks on layer oneand two We will provide techniques to discover logical attacks likeClulowrsquos attack following an approach that takes the point of viewstandpoint as the first view on the attack

On the other hand the security definition we propose in Part iiallows to capture attacks on layer three but requires security APIsto separate the roles of wrapping and decryption as they have alto-gether different requirements Hence the definition excludes (securebut debatable) policies like the policy from Figure 2 in the first placetaking the same standpoint as the second view on the attack

12 security apis and network protocols

The overall goal of a security API in the context of network protocolsis to improve the security of the protocol that makes use of it forinstance to make it more resistant in case protocol parties are underadversary control What security means in this context depends onthe protocol

A commonly used approach is to model the security API as a par-ticipant in a protocol and use traditional protocol analysis techniquesto establish protocol-specific security properties Automated analysistools that rely on a protocol representation in the symbolic model ofcryptography where messages are represented as formal terms in-stead of bit strings (also called the Dolev-Yao model [39]) effectivelydescribe the security API on the specification level Therefore theyare able to detect attacks on layer one and two The security proper-ties can be specific to the outside protocol e g fairness in a contractsigning protocol that uses a security API as a trusted third party (seeSection 554 for a definition of contract signing protocols) It is alsopossible to show properties that are protocol independent by mod-elling the security API as the only entity in the protocol and by givingthe adversary full access to the security API This allows for establish-ing properties like the secrecy of keys that are generated on the devicemdash no matter which protocol makes use of the security API

While security protocol analysers can be used for the analysis of se-curity APIs represented as protocols they often perform badly whenprotocols are stateful But as we have seen in Example 1 the securitydepends on how attributes in the database can change over time J

13 security apis in context of arbitrary protocols 11

Herzog [49] advocates improving protocol analysers to overcome thishindrance

For API analysis on the other hand the idea of mutablestate is crucial A cryptographic devicersquos internal statecan be changed by some function calls (migration or key-loading calls for example) and API-level attacks oftenuse state-changing functions in crucial ways To use themfor interface analysis therefore we must extend protocol-analysis techniques to track the devicersquos internal state []

Understanding and overcoming theses difficulties is the goal of thefirst part of this thesis In Chapter 2 we introduce some preliminariesbefore giving a survey on existing techniques for the analysis of pro-tocols with state in Chapter 3 A large case study discusses the afore-mentioned Yubikey and the analysis of the authentication protocolthat builds upon its use We present this case study in Chapter 4 Wedevelop our own calculus which allows to express protocols that relyon state manipulation We devise a method that allows to translateprotocols from this higher-level language into a protocol representa-tion on a much lower level This translation allows us to use existingmethods for the analysis of stateful protocols as a number of casestudies confirm The description of this protocol the translation thecase studies and the proof of correctness for this translation can befound in Chapter 5

13 security apis in context of arbitrary protocols

For the producer of a security API the situation is different They areunaware of what protocols the security API she is developing mightbe used for but would like to verify security properties that can beestablished

a independent of the protocol

b that guarantee that there are no flaws on layer 3 and layer 2 and

c that facilitate the analysis of higher-level protocols for her cus-tomers

A definition of what constitutes a ldquosecurerdquo security API in thecomputational setting where messages are represented as actual bitstrings and cryptographic functions are not necessarily perfect couldestablish such properties The greatest challenge in formulating thisdefinition is that security APIs are quite diverse as the previous ex-amples have shown In the second part of this thesis we describe anapproach to finding a definition of security that is reasonable for awide range of APIs but still not for all This definition uses a frame-work that allows for modular analysis in the computational model

12 introduction

supporting the analysis of higher-level protocols Especially in scenar-ios where several devices implement the same security API ndash whichis often the case for reasons of redundancy and high-throughput assecurity APIs are often mission-critical ndash our definition facilitates theanalysis of higher-level protocols By modelling the case of severaldevices implementing the same security API our definition is able toensure that a given policy is respected not only on each individualdevice but on the global level The following examples shows that apolicy that is respected locally can still be violated on the global level

Example 2 The security API from Example 1 additionally allows to re-import a key using an unwrap request When it receives an unwraprequest for a handle h and some data c it performs a database lookupfor the key k that h points to as well as the attribute a associatedto h If a1 is ldquowraprdquo it encrypts c using k Should the decryptionsucceed a new handle h prime is drawn If the result of the decryption sayk prime is already on the device let a prime be the attribute associated to somehandle pointing to k prime (it should be the same for any handle pointingto some key equal to k prime) If k prime is not already on the device let a prime beldquoinitrdquo In its database the security API stores that h prime points to thekey k prime and that the attribute of h prime is the value a prime To be on the safeside the second handle for a wrapping request has to be associatedto ldquowraprdquo or ldquodecryptrdquo but not ldquoinitrdquo

Even if the device implements the policy from Figure 1 on a localscale it is possible to use the same key for wrapping as well as forencryption An attacker can wrap some key that is either associated toldquowraprdquo or ldquodecryptrdquo and import the key on a second device using anunwrap request (given that both devices share a common wrappingkey) The key will be new on the second device so its handle isassociated the attribute ldquoinitrdquo Using either an ldquoallow decryptionrdquo orldquoallow wrappingrdquo request a copy on the key can be produced thathas ldquowraprdquo set on one device and ldquodecryptrdquo on the other While thepolicy was respected on each of the two devices it is not respectedglobally

In the second part of this thesis we establish a template for thedesign of security APIs that are secure with respect to our definitionIt offers insight in some ldquobest practicesrdquo for the design of a securityAPI and provides a template for a secure implementation for a widerange of security APIs as it can be easily extended without losingsecurity

To this end we introduce the concept of key-usage functionalitiesSome features are vital for the security of a set of security APIs butmost features only have to be secure with respect to the function theyperform The second kind of feature performs what we call key-usage(as opposed to key-management) The distinction between the two al-lows us to derive a design that allows to safely add the second kindof feature If the second kind of feature can be implemented securely

then this implementation can be integrated into the system preserv-ing the security of the resulting extended system This is importantRoss Anderson makes following observation about a number of at-tacks [4 17 18] on security APIs [3]

At a practical level [those attacks illustrate] one of themain reasons APIs fail They get made more and morecomplex to accommodate the needs of more and morediverse customers until suddenly therersquos an attack

Considering the apparent need to adapt security APIs to changingrequirements we propose this ldquogenericrdquo implementation and subse-quently show it secure as a means to the designer of a security APIto easily tell whether a certain function can be added without furtherado

The second part of this thesis is organized as follows We discussour approach for the definition of security for security API implemen-tations as well as previous definitions in Chapter 6 In Chapter 7 wediscuss the framework in which we will formulate this definition InChapter 8 we introduce our notion of security as well as our designtemplate In Chapter 9 we discuss this notion and its limitations InChapter 10 we show that our design template is secure with respectto this notion In Chapter 11 we instantiate this design template andshow how our notion of security helps the analysis of protocols usingsecurity APIs

Part I

A N A LY S I S O F S TAT E F U L P R O T O C O L S I N T H ES Y M B O L I C M O D E L

Security APIs such as the RSA PKCS11 standard [81] orIBMrsquos CCA [25] have been known to be vulnerable to log-ical attacks for quite a while [64 17] Formal analysis isnecessary to identify secure configurations Several mod-els have been proposed for example [44] however man-ual inspection is tedious and error-prone A promisingparadigm is to regard the Security API as a participant ina protocol and then use traditional protocol analysis tech-niques e g symbolic techniques [20 29 36] for analysis

This section presents a survey on existing techniques tosuch analysis We introduce two examples that help point-ing out the differences in existing methods and where theyare lacking We propose a modelling on the basis of multi-set rewriting and show the advantages by verifying secu-rity properties of the Yubikey-protocol and the YubiHSMWe introduce our own process calculus which include op-erators for manipulation of a global store This calculuscan be translated into MSR rules We show this transla-tion to be both sound and complete

2P R E L I M I N A R I E S

21 terms and equational theories

As usual in symbolic protocol analysis we model messages by ab-stract terms Therefore we define an order-sorted term algebra withthe sort msg and two incomparable subsorts pub and fresh For eachof these subsorts we assume a countably infinite set of names FN

for fresh names and PN for public names Fresh names will be usedto model cryptographic keys and nonces while public names modelpublicly known values We furthermore assume a countably infiniteset of variables for each sort s Vs and let V be the union of the setof variables for all sorts We write u s when the name or variable uis of sort s Let Σ be a signature ie a set of function symbols eachwith an arity We denote by TΣ the set of well-sorted terms built overΣ PN FN and V For a term t we denote by names(t) respectivelyvars(t) the set of names respectively variables appearing in t Theset of ground terms ie terms without variables is denoted by MΣWhen Σ is fixed or clear from the context we often omit it and simplywrite T for TΣ and M for MΣ

We equip the term algebra with an equational theory E e g a fi-nite set of equations of the form M = N where MN isin T Fromthe equational theory we define the binary relation =E on termswhich is the smallest equivalence relation containing equations inE that is closed under application of function symbols bijective re-naming of names and substitution of variable by terms of the samesort Furthermore we require E to distinguish fresh names i eforalla b isin FN a 6= brArr a 6=E b

Example 3 Symmetric encryption can be modelled using a signatureΣ = senc2 sdec2 encSucc2 true0 and an equational theory de-fined by dec(enc(mk) k) = m and encSucc(senc(x y) y) = true Us-ing the last equation one can check whether a term can be decryptedwith a certain key

For the rest of Part i we assume that E refers to some fixed equa-tional theory and that the signature and equational theory always con-tain symbols and equations for pairing and projection ie 〈〉 fstsnd sube Σ and equations fst(〈x y〉) = x and snd(〈x y〉) = y are in E

We also employ the usual notion of positions for terms A positionp is a sequence of positive integers and t|p denotes the subterm of tat position p

18 preliminaries

22 facts

We assume an unsorted signature Σfact disjoint from Σ The set offacts is defined as

F = F(t1 tk)|ti isin TΣ F isin Σkfact

Facts will be used both to annotate protocols by the means of eventsand for defining multiset rewrite rules We partition the signatureΣfact into linear and persistent fact symbols In multiset rewritingwhich will be introduced in Section 361 linear facts may disappearwhile persistent facts may not We suppose that Σfact always containsa unary persistent symbol K and a linear unary symbol Fr Givena sequence or set of facts S we denote by lfacts(S) the multiset of alllinear facts in S and pfacts(S) the set of all persistent facts in S Bynotational convention facts whose identifier starts with lsquorsquo will bepersistent G denotes the set of ground facts ie the set of facts thatdoes not contain variables For a fact f we denote by ginsts(f) the setof ground instances of f This notation is also lifted to sequences andsets of facts as expected

23 substitutions

A substitution σ is a partial function from variables to terms Wesuppose that substitutions are well-typed ie they only map vari-ables of sort s to terms of sort s or of a subsort of s We denoteby σ = t1x1

tn xn the substitution whose domain is D(σ) =

x1 xn and which maps xi to ti As usual we homomorphicallyextend σ to apply to terms and facts and use a postfix notation todenote its application eg we write tσ for the application of σ to theterm t A substitution σ is grounding for a term t if tσ is ground Weuse f = g[a 7rarr b] to denote f = g(x) for x 6= a and f = b otherwiseeven if f or g are not substitutions

24 sets sequences and multisets

We write Nn for the set 1 n Given a set S we denote by Slowast

the set of finite sequences of elements from S and by S the set offinite multisets of elements from S We use the superscript to an-notate usual multiset operation eg S1 cup S2 denotes the multisetunion of multisets S1 S2 We will furthermore use the hash sym-bol to distinguish multisets from sets Given a multi-set S we denote by set(S) the set of elements in S The sequenceconsisting of elements e1 en will be denoted by [e1 en] andthe empty sequence is denoted by [] We denote by |S| the lengthie the number of elements of the sequence We use middot for the op-eration of adding an element either to the start or to the end eg

24 sets sequences and multisets 19

e1 middot [e2 e3] = [e1 e2 e3] = [e1 e2] middot e3 Given a sequence S we denoteby idx(S) the set of positions in S ie Nn when S has n elements andfor i isin idx(S) Si denotes the ith element of the sequence Applicationof substitutions and =E are lifted to sets sequences and multisets asexpected Set membership modulo E is denoted by isinE ie e isinE Sif existe prime isin S e prime =E e By abuse of notation we sometimes interpret se-quences as sets or multisets the applied operators should make theimplicit cast clear

3A S U RV E Y O N E X I S T I N G M E T H O D S

Automated analysis of security protocols has known increasing suc-cess Using automated tools flaws have been discoverede g in theGoogle Single Sign On Protocol [7] in commercial security tokens im-plementing the PKCS11 standard [20] as well as Lowersquos attack [66] onthe Needham-Schroeder public key protocol 17 years after its publica-tion While efficient tools such as ProVerif [14] AVISPA [6] or Maude-NPA [41] exist these tools fail to analyze protocols that require anon-monotonic global state ie some database register or memory lo-cation that can be read and altered by different parallel threads Inparticular ProVerif one of the most efficient and widely used proto-col analysis tools relies on an abstraction of protocols as Horn clauseswhich are inherently non-monotonic Once a fact is true it cannot beset to false anymore This abstraction is well suited for the mono-tonic knowledge of an attacker (who never forgets) makes the toolextremely efficient for verifying an unbounded number of sessionsand allows for building on existing techniques for Horn clause res-olution While ProVerifrsquos input language a variant of the appliedpi calculus [2] supports a priori encodings of a global memory theabstractions performed by ProVerif introduce false attacks

Security APIs have been known to be vulnerable to logical attacksfor some time [64 17] Therefore formal analysis is necessary to iden-tify secure configurations Several models have been proposed someof which require manual inspection [44] which is tedious and error-prone A promising paradigm is to regard the security API as a par-ticipant in a protocol Is it possible to translate the success protocolanalysers like ProVerif have had in the domain of network protocolsto this application In contrast to most network protocols securityAPIs often rely on the state of an internal database which we canmodel as a set of facts i e predicates on ground terms When mov-ing from one state to another facts might be added or subtractedtherefore we say that the state of a security API is non-monotonicWhen it comes to the analysis of an unbounded number of keys thisnon-monotonicity is the reason why current tools for protocol analy-sis do not work well Herzog [49] already identified not accountingfor mutable global state as a major barrier to the application of secu-rity protocol analysis tools to verify security APIs There are otherprotocols besides security APIs that maintain databases too Keyservers need to store the status of keys in optimistic contract signingprotocols a trusted party maintains the status of a contract Radio-frequency identification (RFID) protocols maintain the status of tags

22 a survey on existing methods

and more generally websites may need to store the current status oftransactions

We present a survey on how different techniques to deal with statein protocol analysis perform on the application of security APIs Thisincludes two abstractions for the use with ProVerif (a protocol verifierbased on a representation of the protocol by Horn clauses) [5 74] anextension of the strand space model [47] and the tamarin prover [89]which represents protocols as multiset rewrite rules

While the first two approaches both based on Horn clause res-olution are not sufficient for modelling even simple fragments ofPKCS11 they show quite well why Horn clauses are not suited forthis kind of problems If the intruder knowledge at a point in timeis coupled with the current state of the security API ProVerif is verylikely not to terminate If it is not coupled with the current state of thesecurity API the intruder can derive knowledge and then ldquorewindrdquothe security API which introduces false attacks

The strand space model captures the causal relations between pro-tocol inputoutput adversarial deductions and transitions from onestate to another by modelling an execution of protocol and adversaryas an acyclic graph As in the tamarin prover the state itself is mod-elled as a multiset of facts As of now protocol analysis in the strandspace model with state has not been mechanized yet

The tamarin prover borrows ideas from the strand space modelbut uses classical multiset rewriting for protocol description and ad-versarial deduction It implements a backward induction techniquethat explicitly models the causality between a message deduced bythe adversary and the protocol output allowing the deduction Al-though the tool is in an early development stage we will show whyit has the potential to make fully automated verification of securityAPIs possible

31 running examples

The first example was introduced by Arapinis et al as a runningexample for the StatVerif tool [5]

Example 4 (Left-or-right encryption) A device is initialized to act ineither ldquoleftrdquo or ldquorightrdquo mode A key k is chosen on initialisation andthe attacker receives the encryption of a pair of secret values underthat key Once it is initialized the only possible operation is to sendan encryption of a pair (x y) under k to the device If the device is inldquoleftrdquo mode it outputs x otherwise it outputs y The attackerrsquos goalis to learn both secret values

The security of this example relies on the fact that the output thatthe adversary receives depends on the state of the system and thatthe states ldquoleftrdquo ldquorightrdquo and the initial state are exclusive

31 running examples 23

The second example is inspired by problems that occur with key-management APIs in the style of PKCS11 Those APIs support creatinga large number of keys which are supposed to stay secret Neverthe-less it is necessary to export such keys For this reason there is amechanism called wrapping A key can be encrypted using a secondkey making it safe to store the key outside the device The secrecyof the key inside the wrapping depends on the secrecy of the secondkey

As mentioned in Example 1 on page 7 the existence of a wrap com-mand might allow for an attack if a decryption command is availabletoo The second example is a minimal example with respect to thisconflict

Example 5 (WrapDec) A security device accepts the following fourkinds of request

2 When it receives a wrapping request for h1 and h2 it performsa database lookup for the keys k1 and k2 that h1 and h2 respec-tively point to and the attribute a1 associated to h1 If a1 isldquowraprdquo it outputs the encryption of k2 under k1 If the lookupfails no output is produced

3 When it receives a decryption request for a handle h and somedata c it performs a database lookup for the key k that h pointsto as well as the attribute a associated to h If a1 is ldquodecrdquoit outputs the decryption of c using k if decryption succeedsOtherwise if the lookup fails no output is produced

4 When it receives a request to change the attribute of h to a prime itperforms a database lookup for the current attribute of h De-pending on its current value the attribute in the database ischanged to a prime or nothing is done We consider the followingthree policies

a) No matter what the current attribute is it may be changedto ldquodecrdquo or ldquowraprdquo This allows for the attack sketched inExample 1

b) Attributes may only change from ldquoinitrdquo to ldquowraprdquo andfrom ldquoinitrdquo to ldquodecryptrdquo This enforces a role separationof wrapping and decryption keys

c) Like the previous policy but attributes may also changefrom ldquodecrdquo to ldquowraprdquo

〈MN〉 = (terms)

| x y z (variables)

| a b c s (names)

| f(M1 Mn) (constructor appl)

〈PQ〉 = (processes)

| 0 (nil)

| P | Q (parallel composition)

| P (replication)

| νnP (restriction)

| out(MN)P (output)

| in(MN)P (input)

| let x = g(M1 Mn) in P else Q (destructor appl)

| if M = N then P else Q (conditional)

| [s 7rarrM] P (state initialisation)

| read s as xP (read)

| s =M P (assign)

| lock P (locked section)

| unlock P (locked section)

Figure 3 Syntax of the StatVerif calculus

32 statverif

StatVerif is a compiler from the StatVerif calculus to Horn clauseswhich can either be handled by ProVerif or by the automated theo-rem prover SPASS [5 97] The StatVerif calculus extends ProVerifrsquosprocess calculus by the following additional constructs that handleglobal state

bull initialisation of a state cell [s 7rarrM]

bull reading a value off a state cell read s as x

bull writing a value to a state cell s =M and

bull two operators for locking and unlocking the whole state1

where s is a name addressing a cell M can be any term and x is avariable that will be bound to the value of the cell We see that thestore at some point in time is a function from names (cell names) toterms It is global in the sense that it might be addressed anywhere

1 Newer versions support locking individual cells

32 statverif 25

let device =

out(cpk(k)) |

(in(cx) lock(s) read s as y

if y = init then

(if x = left then s = x unlock(s)

else if x = right then s = x unlock(s)) ) |

if y = left then out(ccar(adec(kx))) unlock(s)

else if y = right then out(ccdr(adec(kx))) unlock(s))

let user = ν r out(caenc(pk(k)rpair(slsr)))

process

ν k ν s [s 7rarrinit] | device | user

Figure 4 Example 4 in StatVerif The deconstructors car and cdr extract thefirst respectively the last element of a pair

in a process but not by the adversary See Figure 3 for the completesyntax See [5] for the semantics We just note that StatVerif aswell as ProVerif divide the function symbols in the signature Σ intoconstructors and destructors

The following syntactical restrictions apply

a [s 7rarrM] may only occur once for a given cell name s and onlyin scope of a new a parallel and a replication but no otherconstruct

b In every branch of the syntax tree every lock must be followedby precisely one corresponding unlock and in between no par-allel replication and unlock are allowed

321 Running Example 4 Left-or-right encryption in StatVerif

The listing in Figure 4 shows the modelling of Example 4 Using theHorn clauses produced by the StatVerif translation as input ProVerifcan show that for secret values sl and sr the adversary is unable toproduce the pair pair(slsr)

322 Running Example 5 WrapDec in StatVerif

The modelling is more difficult in the case of Example 5 In manypractical systems the handle pointing to a key is some encoding ofits address in memory This would correspond to modelling the han-dle as a cell name in StatVerif Developing this idea further the han-dle is in the scope of a restriction which in turn is in the scope ofa replication to allow for an unbounded number of keys The pro-

cess handling creation requests would look similar to the followingprocess

(in(ccreate) ν handle ν key handle=key out(chandle))

To treat other requests for instance a decryption request the pro-cess needs to read the key that belongs to some given handle It canonly address the key using a cell name in this case the correspondinghandle Since the cell name is in the scope of a restriction the processthat handles decryption requests needs to be in the same scope

A wrapping request has the same requirement for the wrappingkey but also for the key to be wrapped Since both keys might bedifferent they could have different handles which may point to dif-ferent keys But there is only one cell name in scope of the aboverestriction

We argue that StatVerif is not suitable for modelling Example 5

for an unbounded number of keys since a) the subprocess treatingwrapping queries cannot access all keys unless there is a cell in thestore whose value is not bound a priori and b) our experiments incase we have such a value e g a single cell storing the list of keyssuggest neither ProVerif not SPASS handle this case well

The argument for a) is as follows Let P prime be a subprocess that treatsa wrapping query It has to access two possibly different keys toproduce a wrapping Since processes are finite P prime can only be a sub-process of a finite number of processes that handle creation requestThis means if P prime is in the scope of one of the keyrsquos restriction itcannot be in the scope of the other keyrsquos restriction The number ofthose keys is not bound a priori so to be able to address all keysP prime would need to be able to access an unbounded number of keysvia the store But assuming that each term referred in the store is ofconstant length the sum of the length of terms in the store P prime canaccess is fixed as well since the number of cells is fixed a priori

To support part b) of the previous claim we conducted an experi-ment where we modelled the store using a single state cell and storedthe keys as a list of pairs of handles and keys see Listing 13 in Sec-tion A1 page 161 Whenever a key is looked up there is a fetchprocess that traverses the list Not very surprisingly this kind ofmodelling turns out to be difficult to handle using either ProVerif orSPASS Both theorem provers did not terminate during our experi-ments In Section 34 we investigate further on why translations intoHorn clauses are not suitable for this kind of problems in general

33 abstraction by set-membership

Similar to StatVerif this approach aims at translating a protocol spec-ification into Horn clauses which can then be verified using SPASSor ProVerif The main idea is the following Given a finite number

33 abstraction by set-membership 27

of sets there are so-called abstractable symbols which might be ele-ments of those sets Those symbols can occur in terms as variables ornames They are abstracted by the available information about whichsets they are members of For instance there might be the sets WrapDec and Init of keys that have the attribute ldquowraprdquo ldquodecrdquo andor theinitial attribute respectively Every key that is in Wrap not in Dec andnot in Init is represented by the term val(1 0 0) where the first posi-tion represents the membership in Wrap the second the membershipin Dec and the third the membership in Init

The infinite set of keys is represented by a finite amount of repre-sentatives if there are finitely many sets Consider now that the ad-versary knows a message containing as a subterm a key k in ldquoinitrdquobut not in ldquodecrdquo or ldquowraprdquo If k might move from ldquoinitrdquo to ldquodecrdquoit would be represented by val(001) The abstraction handles theintruder knowledge as follows All previous facts including thosemodelling the intruder knowledge are maintained but additionallyall facts where k appears in its old form val(100) are added butwith val(100) substituted by val(001)

The protocol specification language called AVISPA IntermediateFormat (AIF) [83] is not a high-level language as in the case of Stat-Verif but a much simpler calculus based on set-rewriting The state ofthe protocol is modelled as a set of facts for instance the fact iknows

has arity 1 and represents the intruder knowledge i e if iknows(m)

is in the state the intruder knows the message m In addition theprotocol state might contain set conditions which are of the form t isin

M or t 6isin M where t is an abstractable symbol and M is a groundterm free of abstractable symbols Abstractable symbols can appearin other terms for example in facts like iknows

A transition rule has the following form

LF middot S+ middot Sminus minus[F]rarr RF middotRS

Loosely speaking the left-hand side of a rule describes to whichstates the rule can be applied while the right-hand side describesthe changes to the state after the transition LF represents a set offacts that is required to be present in the state before the transitionRF is the set of facts that is added after the transition S+ and Sminus aresets of positive and negative set conditions that are required to bepresent in the state before the transition RS is the set of positive setconditions that is added after the transition and F is a set of newlyintroduced abstractable symbols Formally a transition from a set Sto a set S prime is possible written S rArrr S prime if there is a grounding substi-tution σ of a rule of the above form and the following conditions arefulfilled

bull (LF middot S+)σ sub S

bull (Sminus cap S = empty) and (S prime = S S+σ)cupRFσcupRSσ

bull Fσ are fresh (i e they do not occur in S or in any rule)

Facts and negative set conditions are persistent but positive set con-ditions can be removed namely if they appear in S+ but not in RSA state S is reachable using the set of transition rules R if and onlyif empty rArrlowast

R S where rArrR= cuprisinR rArrr and rArrlowastR is the reflexive transitive

closure ofrArrRLet us have a look at the following example

minus[SK ]rarr SKisin init(t) middotiknows(senc(SKpair(slsr)))

This rule has an empty left-hand side and introduces a new ab-stractable symbol SK Since SK is fresh the state is extended by afact iknows(senc(SKpair(slsr))) and a positive set condition SKisin

init(t) This models a protocol step where a secret key is freshlydrawn which is then added to the ldquoinitrdquo database of a token t (t isa constant in this case) Finally the encryption of a pair 〈sl sr〉 underthis freshly drawn key is output to the adversary Assuming there arethree sets init(t) dec(t) and wrap(t) this rule is translated to thefollowing Horn clause

minusrarr iknows(senc(iknows(100)pair(slsr)))

This expresses that the adversary without any preconditions canlearn the encryption of the secret pair under a key that is in init(t)but not in dec(t) or wrap(t) The translation will produce additionalclauses but this should give the gist of it

331 Running Example 5 WrapDec using abstraction by set-membership

Abstraction by set-membership works remarkably well on Example 5See Figure 5 for the code of this model We use a unary function hto model the handle that belongs to a given key Since the handleshould reveal no information about the value of the key there is norule to extract a term t from a term h(t)

The first four lines model the intruderrsquos deductive capabilities Themodelling of the security device uses four sets in total store whichmodels the set of keys that are available on the device as well as initdec and wrap which model the set of keys that have the respectiveattributes set

Wrapping is modelled as a rule that for two handles that are knownto the adversary checks if they belong to keys in the store if thewrapping key has ldquowraprdquo set and then adds the fact iknows(senc(

KEY1KEY2)) but does not alter the state any further The same holdsfor decryption The security goal is secrecy of keys If the attackerknows a key that is at the same time in the store we consider thisan attack We modelled different policies The following two pairsof rules both model a policy where after initialisation keys might

The intruderrsquos deduction capabilities

minusrarr iknows(Token)

iknows(K) middotiknows(M) minusrarr iknows(senc(KM))

iknows(senc(KM)) middotiknows(K) minusrarr iknows(M)

Generate a key

minus[KEY ]rarr iknows(h(KEY)) middotKEYisin store(Token) middotKEYisin init(Token)

iknows(h(KEY1)) middotiknows(h(KEY2))middotKEY1isin wrap(Token) middotKEY1isin store(Token) middotKEY2isin store(Token)minusrarr iknows(senc(KEY1KEY2)) middotKEY1isin wrap(Token) middotKEY1isin store(Token) middotKEY2isin store(Token)

SDecrypt

iknows(h(KEY)) middotiknows(senc(KEYM)) middotKEYisin store(Token) middotKEYisin dec(Token)

minusrarr iknows(M) middotKEYisin store(Token) middotKEYisin dec(Token)

Security goal

iknows(KEY) middotKEYisin store(Token) minusrarrattack

Figure 5 Modelling for Example 5 in AIF The full code can be found inListing 16 in Section A1 p 164

become either wrapping keys or decryption keys Otherwise thoseroles are permanent and thus exclusive

Policy B

KEYisin store(Token) middot KEYisin init(Token)minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

KEYisin store(Token) middot KEYisin init(Token)minusrarr KEYisin store(Token) middot KEYisin dec(Token)

The second pair of rule does not check whether a key is in init ornot but instead uses a negative set condition to determine if the keyis in an initial state i e has not been assigned the role of either adecryption or a wrapping key yet

Policy Brsquo - simplified version of Policy B

KEYisin store(Token) middot KEYisindec(Token)minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

KEYisin store(Token) middot KEYisinwrap(Token)minusrarr KEYisin store(Token) middot KEYisin dec(Token)

For either choice of policy ProVerif confirms within milliseconds thata state where the fact attack is present cannot be reached The sameholds for the following policy where a key might move from ldquodecrdquoto ldquowraprdquo but not the other way around

Policy C

KEYisin store(Token) middot KEYisin init(Token)

minusrarr KEYisin store(Token) middot KEYisin wrap(Token)KEYisin store(Token) middot KEYisin init(Token)

minusrarr KEYisin store(Token) middot KEYisin dec(Token)KEYisin store(Token) middot KEYisin dec(Token)

minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

Finally the following example policy allows for an attack

Policy A -- an attack is reachable middotKEYisin store(Token) middot KEYisin init(Token)

minusrarr KEYisin store(Token) middot KEYisin dec(Token)KEYisin store(Token) middot KEYisin wrap(Token)

minusrarr KEYisin store(Token) middot KEYisin dec(Token)

This policy allows the attacker to change a keyrsquos attribute from ldquoinitrdquoto ldquowraprdquo produce a wrapping of a second key (possibly the wrap-ping key itself) move the key from ldquowraprdquo to ldquodecrdquo and finally obtaina decryption of the key that was just wrapped The translation cor-rectly allows ProVerif to conclude that such an attack exists showingthat this model captures the attack described in Example 1

332 Running Example 4 Left-or-right encryption

The left-or-right encryption example (Example 4) shows the limita-tions of abstraction by set-membership A straight-forward mod-elling of this example (see Figure 6) shows where the abstractionby set-membership is too coarse The modelling first generates anabstractable name sk which is in the set init(token) but may be inother sets too It is not possible to specify negative set conditionson the right-hand side which is why a second rule allows the adver-sary to obtain the encryption of the secret pair only if sk the onlyabstractable name ever generated is in init(token) not in any of theother two sets It is then possible to move the set membership fromldquoinitrdquo to ldquoleftrdquo or from ldquoinitrdquo to ldquorightrdquo Decryption gives the left orthe right element of the pair depending on the set membership If theadversary can derive both the left and the right part of the secret shehas successfully mounted an attack

ProVerif finds a (false) attack on the Horn clauses produced by thisabstraction The reason is the following The adversary can learn thesecret pair encrypted under the abstraction of this key i e iknows(senc(var(100)pair(slsr)) is a derivable fact If this is the case sois iknows(senc(var(010)pair(slsr)) since a key that is abstractedby val(100) can move to ldquoleftrdquo and therefore be substituted by (val

(010) If iknows(senc(var(010)pair(slsr)) is present sl can bederived With the same argument iknows(senc(var(001)pair(slsr)) and therefore sr can be derived which shows that the abstractionintroduces a false attack in this case

34 why horn clause approaches are unsuitable 31

sk minusrarr skisin init(token)SKisin init(token) middot SKisinleft(token) middot SKisinright(token) middot

minusrarr SKisin init(token) middotiknows(senc(pair(slsr)SK))

Set left - or - set right

SKisin init(token) minusrarr SKisin left(token)SKisin init(token) minusrarr SKisin right(token)

decryption

SKisin left(token) middotiknows(senc(pair(XY)SK)) minusrarr SKisin left(token) middotiknows(X)

SKisin right(token) middotiknows(senc(pair(XY)SK)) minusrarr SKisin right(token) middotiknows(Y)

Security goal

iknows(sl) middotiknows(sr) minusrarrattack

The main problem here is that in this abstraction every key whichhas the same set-membership is equivalent This means that there arereally only three encryptions of the secret pair one under val(100)one under val(010) and one under val(001) At the same timethe abstraction produces two clauses which allow the attacker to ob-tain an encryption under val(010) from an encryption under val

(100) as well as an encryption under val(001) Both clauses canbe used as often as necessary to obtain this (false) attack

34 why horn clause approaches are unsuitable

Why approaches based on Horn clause resolution are often not suit-able

While protocols can be accurately represented as multiset rewritesystems [89 37] or in linear logic [40] the reason for ProVerifrsquos effi-ciency both in terms of computational resources and degree of au-tomation lies in the use of a Horn clause representation for the pro-tocol The attacker knowledge is modelled as a fact att(m) which ispresent if the attacker knows a message m The attackerrsquos deductivecapabilities are modelled as Horn clauses that derive a fact att(m)

from one or more facts att(m1) att(mn) This part of the mod-elling seems accurate because indeed If an attacker knows m atsome point much like the fact att(m) stays available for future de-ductions the attacker never forgets this message Furthermore if theattacker can derive m from m prime she needs to know m prime in advance

Protocols are modelled as oracles If the attacker knows a messagem at some point then he can potentially learn a new message by

sending m to the protocol and thereby learning a message m prime whichmight depend on m These protocol steps are modelled as Hornclauses they can be repeated arbitrarily often even if the real systemprevents that with challenge-response mechanisms or timestamps Inthe context of security APIs this often results in false attacks as oftena database lookup is guarding critical protocol steps ndash e g in Exam-ple 5 the decryption operation validates that a key has the ldquodecrdquo at-tribute set The statement ldquokey x has attribute ardquo might be true at onepoint in time and false in another ndash in Example 5 for instance a keycan have ldquoinitrdquo set but this attribute could be removed later How-ever facts produced by the Horn clause presentation of the protocolpersist

The approach StatVerif takes is quite obvious The translation em-beds the state into the att-fact There is an explicit state given by thenumber of state cells that appear in the protocol The attacker knowl-edge is now given in relation to the explicit state of the system soatt(σ t) means that the attacker can derive t when the system is instate σ If the state can change from σ to σ prime then the attacker knowl-edge is preserved so att(σ t) implies att(σ prime t) in this case Notethat this is not the complete state of a protocol as the implicit state ofthe protocol i e which part is at what point of the execution is notrecorded

The resulting Horn clauses are meant to be verified using ProVerifwhich attempts a proof by refutation The number of terms in thestore is hence fixed a priori by the number of cell names appearing inthe protocol description Even if we ldquocheatrdquo our way around this re-striction by encoding a list of terms in a single cell using e g nestedpairs as we did in Section 322 the resolution algorithm used byProVerif does not terminate The reason is the following In order toaccess an element of the list e g to test of membership or to retrievea certain item a recursion on the list is necessary This translates toa Horn clause with the term encoding the list in the hypothesis anda subterm of this term (typically the tail of the list) in the conclu-sion Backwards induction on this Horn clause which representsthe recursive step and the Horn clause that represents the initial callof the recursion produces an infinite set of clauses2 A recent ex-tension to ProVerif by Blanchet and Paiola represents lists using ageneralized notion of Horn clauses and achieves successful verifica-tion of a number of stateless protocols involving lists of unboundedlength [16] Combining this extension with StatVerifrsquos translation pro-cedure could remedy this problem

StatVerif avoids this issue at least for the case where only terms offixed length are stored in cells by imposing an artificial limit on the

2 The recursive step can be unified with the call resulting in a clause that representsthe state as a list of one element and a tail This clause can again be unified withclause representing the recursive step resulting in a similar clause which representsthe state as a list of two elements and a tail This continues ad infinitum

number of state cells effectively imposing a bound on the total stateAs a consequence previous works using the same abstraction [35]and more recent work using StatVerif [5 9] suffer from limitations onthe environment (the model of the TPM for instance requires a boundon the number of times the computer can be rebooted [35]) limita-tions on the number of fresh values that can be stored as well as onthe number or security devices that can be modelled (the modellingof Example 4 in StatVerif cannot capture the interaction between anunbounded number of security devices in the network) and often re-quire additional soundness theorems that justify simplifications on aper-case basis [35 9]

The ldquoabstraction by set-membershiprdquo approach circumvents thisproblem in a clever way There are only certain parts of the state of aprotocol (abstractable objects in their terminology) that have proper-ties that change over time and that are important for analysis Ratherthan incorporating the complete state of a system into each fact thisabstraction incorporates only the set membership of objects that ap-pear in terms relevant to each fact As a side effect the state spaceis made ldquofiniterdquo Every abstractable object is substituted by a repre-sentative of its equivalence class where two objects are equivalent ifthey are members of exactly the same sets Given that the numberof sets is finite there are only finitely many such classes 2n for nthe number of sets This greatly reduces the amount of terms thatmight appear inside the att-facts and therefore works very well withProVerifrsquos refutation algorithm

Unfortunately this abstraction is too coarse for some cases thatare relevant for our target application security APIs Example 4 (seeSection 321) is such a case albeit contrived The abstraction excludesthe analysis of scenarios in which keys might leak Such scenarios arevery relevant in practice where a single incident of key leakage in alarge system can result from

bull an attack on a specific key via exhaustive key-space exploration

bull not sufficiently tamper-resistant hardware that is used ldquoin thefieldrdquo but only holds keys of lower security levels or

bull incorrect handling of key-data (for example backups) by person-nel

The proposal for a generic security API by Cortier and Steel [30]for instance proposes a policy that limits the damage in case that akey is leaked This security API assigns a security level l isin N toeach handle Handles of security level l can only be used to wraphandles of lower security levels which enforces a so-called strict key

hierarchy Under these circumstances it is possible to show that anattacker assuming he can learn a single key of any security level lis not able to learn any other key that has a higher or equal security

level than l A strict key-hierarchy allows large companies to keep thecosts of securing lower-level keys reasonable while at the same timecontaining the risk of exposing a higher-level key Other policies thatare less restrictive but enjoy similar properties could be investigatedusing automated verification tools if those tools support modellingkey leakage

In the case of abstraction by set-membership the keys are the ob-jects to be abstracted since we want to have arbitrary many of themThey would be abstracted by the security level which means thateach key of the same security level falls into the same equivalenceclass Therefore if a key of level l is leaked every key of level l isleaked (for the abstraction) The problem persists even if in orderto distinguish corrupted keys from uncorrupted keys the modellingintroduces a set for corrupted keys If any key that is uncorruptedcan become a key of this set the abstraction introduces a set of rulespermitting the substitution of every corruptible but uncorrupted key(i e keys of level l) by a corrupted key Hence within the abstractionthe attacker would be able to decrypt any encryption with a key oflevel l nor matter if this key itself was corrupted or not which alsorestricts the use of this abstraction for higher-level protocols

Sometimes the state of protocols cannot be modelled by a fixednumber of sets The Yubikey protocol introduced in Chapter 4 bindskeys to a counter value to produce one-time passwords Those proto-col could not benefit from this abstraction although we should notethat in practice due to hardware restrictions there is a maximumnumber of states the counter can be in 65 prime536 Still this is infeasiblefor an analysis in this model

Besides those two approaches there has also been work tailored toparticular applications In 2010 Delaune et al showed using a dedi-cated hand proof that for analyzing PKCS11 it is possible to boundthe message size [36] Their analysis still requires to artificially boundthe number of keys Similarly in spirit in 2011 Delaune et al gavea dedicated result for analyzing protocols based on the TPM and itsregisters [35] However the number of reboots (which reinitializeregisters) needs to be limited for this approach Those two works usethe same abstraction that StatVerif employs but for a specific case inother words StatVerif is a generalisation of those approaches

We have seen that techniques based on Horn clause resolution [1498] have to represent the sequence of states of a protocol throughpersistent facts in order to be useful for our application the analysisof security APIs The abstraction employed in StatVerif restricts thesize of the explicit part of the state and is therefore unsuitable forthe analysis of security APIs since our goal is to be able to dealwith an unbounded number of keys Abstraction by set-membershipmanages to partly overcome theses restrictions but there are plenty ofcases where this abstraction is unsuitable (see above) Our conclusion

35 other approaches 35

is that Horn clause resolution is not of advantage in our case and thatwe need an approach that takes into account the causality between theprotocol outputs that give information to the adversary and the statetransitions that allow them

35 other approaches

In the following we give a concise summary of other approaches wehave looked at and decided not to pursue further

The two back-ends OFMC and CL-AtSe of the Automated Vali-dation of Internet Security Protocols and Applications (AVISPA) tool-suite [6] have support for state manipulation Unfortunately both re-quire concrete bounds on the number of sessions and nonces whichcontradicts our goal of an analysis for an unbounded number of keysAlthough SATMC can avoid this restriction in princple [45] accordingto [34] SATMC performs poorly in experiments where the messagelength is high

The strand space model [92] captures the causal relations betweenprotocol inputoutput and adversarial deductions by modelling anexecution of the protocol and the adversary as an acyclic graph Tobe able to analyze optimistic fair exchange protocols Guttman intro-duced an extension to the strand space model [47] In addition tothe existing kinds of nodes modelling transmission and receptionof messages the extension adds a new kind of node which allowscomputations on a global state Similar to the tamarin prover whichwe will introduce in the following the global state is modelled as amultiset of facts

As of now protocol analysis in the strand space model with statehas not been mechanized yet The paradigm behind verification inthe original strand space model is the search for a finite number ofso-called shapes which are characterisations of an infinite number ofprotocol runs The Cryptographic Protocol Shapes Analyzer [38] isable to reduce the set of protocol runs to a finite number of shapesCPSA is usually able to compute a relatively small number of shapesand verify correspondence and secrecy properties on each of themUnfortunately CPSA does not support the additions accounting forstate It is not clear how to extend the notion of shapes to state com-putations i e sequences of multisets

36 the tamarin-prover

In the following we will introduce the tamarin protocol prover [89]a tool for the symbolic analysis of security protocols The tamarinprover borrows ideas from the strand space model but uses classicalmultiset rewriting for protocol description and adversarial deductionIt implements a backward induction technique that explicitly mod-

els the causality between a message deduced by the adversary andthe protocol output allowing the deduction Although the tool isrelatively new we will show why it has the potential to make fullyautomated verification of security APIs possible

Protocols are specified using multiset rewrite rules a formalismexpressive enough to encode state However multiset rewrite rulesconstitute a ldquolow-levelrdquo specification language with no direct supportfor concurrent message passing making the encoding of protocolsdifficult and error-prone We propose a translation from a higher-level language in Chapter 5 with the aim of mitigating this problem

Since the underlying formalism Multiset Rewriting (MSR) is ex-pressive enough to encode explicit state we are able to encode se-curity APIs without any abstractions that enforce a monotonic stateAdditionally tamarin supports both falsification and verification ofsecurity goals that can be expressed as first-order formulas Since thetool is sound and complete but allows to express the secrecy problemwith unbounded nonces which is undecidable [40] there is no guar-antee that the tool terminates In order to achieve termination someintervention is necessary Lemmas need to be used to cut branches inthe proof attempt

Both Example 4 and Example 5 can be analyzed for an unboundednumber of keys and security devices using tamarin Furthermore itis able to reproduce and improve on existing results on PKCS11 [36]and the TPM [35] that required a bound on the number of keys re-spectively the number of security devices and reboots of those de-vices without such restriction In Chapter 4 we show how tamarincan be used for the analysis of an authentication protocol based onhardware-generated one-time passwords an example that we con-sider to be out of the scope of the previously discussed tools Boththe case studies presented with abstraction by set-membership [74]as well as those presented with StatVerif [5] were successfully verifiedwith the tamarin prover [71 68 70]

Contrary to ProVerif tamarin sometimes requires additional typing

lemmas which are used to guide the proof These lemmas need to bewritten by hand but are proven automatically In four out of sevencase studies we needed to provide at least one such lemma manually

361 Labelled multiset rewriting

We now define the syntax and semantics of labelled multiset rewriterules which are the input language of the tamarin tool We largelyfollow the presentation by Meier Schmidt et al [89] We remind thereader that we have introduced facts in Section 22 on page 18

Definition 1 (Multiset rewrite rule) A labelled multiset rewrite rule riis a triple (l a r) l a r isin Flowast written l minus[a]rarr r We call l = prems(ri)

36 the tamarin-prover 37

the premises a = actions(ri) the actions and r = conclusions(ri) theconclusions of the rule

Example 6 The following rule has the fact Init(k) as premise and thepermanent fact (see Section 22) Left(k) as conclusion It is part of themodelling of the LeftRight device from Example 4 This rule modelsthat an initialized but unconfigured security device can be put inldquoleftrdquo mode identifying the device by its secret key k The actionSetLeft(k) serves the purpose of logging that this step happened

[Init(k)] minus[SetLeft(k)]rarr [Left(k)]

Definition 2 (Labelled multiset rewriting system) A labelled multisetrewriting system is a set of labelled multiset rewrite rules R such thateach rule (l minus[a]rarr r) isin R satisfies the following conditions

bull l a r do not contain fresh names

bull r does not contain Fr-facts

bull for each (l prime minus[ a prime]rarr r prime) isinE ginsts(l minus[ a]rarr r) we have thatcapr primeprime=Er primenames(r primeprime)cap FN sube capl primeprime=El primenames(l primeprime)cap FN

The third condition ensures that protocol rules cannot create freshnames Instead we define one distinguished rule Fresh which is theonly rule allowed to have Fr-facts on the right-hand side and to createfresh names i e all fresh names originate from this rule

Fresh [] minus[]rarr [Fr(x fresh)]

Example 7 The complete modelling of Example 4 consists of the fol-lowing five rules

[Fr(k)Fr(sl)Fr(sr)] minus[New(k sl sr)]rarr

[Init(k)Out(senc(〈sl sr〉 k))]

[Init(k)] minus[SetRight(k)]rarr [Right(k)]

[Left(k) In(senc(〈mlmr〉 k))] minus[Read(ml)]rarr [Out(ml)]

[Right(k) In(senc(〈mlmr〉 k))] minus[Read(mr)]rarr [Out(mr)]

The first rule initialises a device with a fresh key and fresh secretsThe encrypted pair of secrets is output and a temporary fact marksthe device as freshly initialised The two next rules allow for settingthe device to either ldquoleftrdquo or ldquorightrdquo mode by replacing the temporaryfact by the corresponding permanent fact The two last rules allowfor retrieving one of the two secrets if a permanent fact is present towitness that the device has been set to ldquoleftrdquo or ldquorightrdquo mode

The semantics of the rules is defined by a labelled transition rela-tion

Definition 3 (Labelled transition relation for multiset rewriting) Givena multiset rewriting system R we define the labeled transition relation

rarrRsube G timesP(G)times G as

SaminusrarrR ((S lfacts(l))cup r)

if and only if l minus[ a]rarr r isinE ginsts(R cup Fresh) lfacts(l) sube S andpfacts(l) sube S

Example 8 Given the previous multiset rewriting system P the fol-lowing transition corresponds to setting one out of two initialisedsecurity devices to ldquoleftrdquo mode

Init(k1) Init(k2) SetLeft(k2)minusminusminusminusminusminusminusrarrP Init(k1) Left(k2)

Definition 4 (Executions) Given a multiset rewriting system R we de-fine its set of executions as

execmsr(R) =

emptyA1minusrarrR

AnminusrarrR Sn |

foralla i j 0 6 i 6= j lt n(Si+1 Si) = Fr(a)

rArr (Sj+1 Sj) 6= Fr(a)

The set of executions consists of transition sequences that respectfreshness i e for a given name a the fact Fr(a) is only added onceor in other words the rule Fresh fires at most once for each name

Example 9 The following execution is in execmsr(P cup Fresh ) (forreadability we write minusrarr instead of minusrarrPcupFresh )

empty minusrarr Fr(k) (Fresh)

minusrarr Fr(k)Fr(l) (Fresh)

minusrarr Fr(k)Fr(l)Fr(r) (Fresh)New(klr)minusminusminusminusminusminusminusrarr Init(k)Out(senc(〈l r〉 k)) (1st rule in P)SetLeft(k)minusminusminusminusminusminusrarr Left(k)Out(senc(〈l r〉 k)) (3rd rule in P)

Definition 5 (Traces) The set of traces is defined as

tracesmsr(R) =

[A1 An] | forall 0 6 i 6 n Ai 6= empty

and emptyA1=rArrR

An=rArrR Sn isin execmsr(R)

where A=rArrR is defined as empty

minusrarrlowastR

AminusrarrR

emptyminusrarrlowast

Note that the set of traces is a sequence of sets of facts

Example 10 From the previous example we conclude that

[New(k l r) SetLeft(k)] isin tracesmsr(P cup Fresh )

362 Adversarial deduction

To model the adversaryrsquos message deduction capabilities we intro-duce the following set of rules MD

Out(x) minus[ ]rarr K(x) (MDOut)

K(x) minus[K(x)]rarr In(x) (MDIn)

minus[ ]rarr K(x pub) (MDPub)

Fr(x fresh) minus[ ]rarr K(x fresh) (MDFresh)

K(x1) K(xk) minus[ ]rarr K(f(x1 xk))

for f isin Σk (MDAppl)

Example 11 The following execution is in execmsr(P cup Fresh cupMD)

(for readability we write minusrarr instead of minusrarrPcupFresh cupMD)

minusrarr Left(k) K(senc(〈l r〉 k)) (MDOut)K(senc(〈lr〉k))minusminusminusminusminusminusminusminusminusminusrarr Left(k) K(senc(〈l r〉 k))

In(senc(〈l r〉 k)) (MDIn)Read(l)minusminusminusminusminusrarr Left(k) K(senc(〈l r〉 k))Out(l) (5th rule in P)

minusrarr Left(k) K(senc(〈l r〉 k)) K(l) (MDOut)K(l)minusminusminusrarr Left(k) K(senc(〈l r〉 k)) In(l) (MDIn)

Therefore we have the following trace

(New(k l r) SetLeft(k)K(senc(〈l r〉 k))Read(l)K(l))

isin tracesmsr(P cup Fresh cupMD)

This trace contains the action K(l) which is often used to witness thefact that the adversary is able to deduce a term in this case l

363 Security Properties

In the tamarin tool security properties are described in an expressivetwo-sorted first-order logic The sort temp is used for time pointsVtemp are the temporal variables [89]

Definition 6 (Trace formulas) A trace atom is either false perp a termequality t1 asymp t2 a time point ordering i⋖ j a time point equalityi

= j or an action Fi for a fact F isin F and a time point i A trace

formula is a first-order formula over trace atoms

To define the semantics we let each sort s have a domain D(s)Let D(temp) = Q D(msg) = M D(fresh) = FN and D(pub) = PNA function θ V rarr M cup Q is a valuation if it respects sorts that isθ(v) isin D(s) for all sorts s and all v isin Vs If t is a term tθ is theapplication of the homomorphic extension of θ to t

Definition 7 (Satisfaction relation) The satisfaction relation (tr θ)

ϕ between trace tr valuation θ and trace formula ϕ is defined asfollows

(tr θ) perp never

(tr θ) Fi iff θ(i) isin idx(tr) and Fθ isinE trθ(i)

(tr θ) i⋖ j iff θ(i) lt θ(j)

(tr θ) i= j iff θ(i) = θ(j)

(tr θ) t1 asymp t2 iff t1θ =E t2θ

(tr θ) notϕ iff not (tr θ) ϕ

(tr θ) ϕ1 andϕ2 iff (tr θ) ϕ1 and (tr θ) ϕ2

(tr θ) existx sϕ iff there is u isin D(s) such that

(tr θ[x 7rarr u]) ϕ

When ϕ is a ground formula we sometimes simply write tr ϕ asthe satisfaction of ϕ is independent of the valuation

Definition 8 (Validity satisfiability) Let Tr sube (P(G))lowast be a set of tracesA trace formula ϕ is said to be valid for Tr written Tr forall ϕ if for anytrace tr isin Tr and any valuation θ we have that (tr θ) ϕ

A trace formula ϕ is said to be satisfiable for Tr written Tr exist ϕ ifthere exist a trace tr isin Tr and a valuation θ such that (tr θ) ϕ

Example 12 The following formula is valid for the trace from Exam-ple 11

existk sl sr msg i j temp New(k sl sr)iand K(sl)j

since for any valuation θ such that

θ(k msg) = k θ(sl msg) = l θ(sr msg) = r

θ(i temp) = 0 θ(j temp) = 4

we have that

((New(k l r) SetLeft(k)K(senc(〈l r〉 k))Read(l)K(l)) θ)

Note that Tr forall ϕ iff Tr 6exist notϕ Given a multiset rewriting systemR we say that ϕ is valid written R forall ϕ if tracesmsr(R) forall ϕ We saythat ϕ is satisfied in R written R exist ϕ if tracesmsr(R) exist ϕ Similarlygiven a ground process P we say that ϕ is valid written P forall ϕif tracespi(P) forall ϕ and that ϕ is satisfied in P written P exist ϕ iftracespi(P) exist ϕ

Example 13 The following trace formula expresses the secrecy of thepair generated by the security device in Example 4

φ = not(existk sl sr msg i j temp New(k sl sr)iand K(〈sl sr〉)j)

The security of Example 4 is therefore expressed via the propertyP cup Fresh cupMD forall φ

Now that the notions of multiset rewrite rules and security prop-erties of the form tamarin uses are layed out we can proceed to theanalysis of the Yubikey protocol in the next chapter

4A N A LY S I S O F T H E Y U B I K E Y P R O T O C O L A N D T H EY U B I H S M

The problem of user authentication is central to computer securityand of increasing importance as the cloud computing paradigm be-comes more prevalent Many efforts have been undertaken to replaceor supplement user passwords with stronger authentication mecha-nisms [19] The Yubikey is one such effort Manufactured by Yubicoa Swedish company the Yubikey itself is a low cost ($25) thumb-sized USB device In its typical configuration it generates a OTPs

based on encryptions of a secret value a running counter and somerandom values using a unique AES-128 key contained in the deviceThe Yubikey authentication server accepts an OTP only if it decryptsunder the correct AES key to a valid secret value containing a counterlarger than the last counter accepted The counter is thus used asa means to prevent replay attacks To date over a million Yubikeyshave been shipped to more than 30000 customers including govern-ments universities and enterprises eg Google Microsoft Agfa andSymantec [102] Despite missing certification for governmental stan-dards several contractors of the US Department of Defense switchedto the Yubikey after RSArsquos SecureID database was hacked in March2012 [101]

Despite its widespread deployment the Yubikey protocol has re-ceived little independent security analysis Yubico themselves presentsome security arguments on their website [104] A first independentanalysis was given by blogger Fredrik Bjoumlrck in 2009 [13] raising is-sues that Yubico responded to in a subsequent post [12] OswaldRichter et al analyse the Yubikey version 20 for side-channel at-tacks [76] They show that non-invasive measurements of the powerconsumption of the device allow retrieving the AES-key within ap-proximately one hour of access The authors mention a more recentversion of the Yubikey Yubikey Neo [103] which employs a CC cer-tified smart-card controller that was designed with regard to imple-mentation attacks and is supposed to be more resilient to power con-sumption analysis Our analysis however is focussed on version 20of the original Yubikey

The only formal analysis of the protocol itself that we are awareof was carried out by Vamanu [96] who succeeded in showing theabsence of replay attacks for an abstract version of the Yubikey OTP

protocol for a bounded number of fresh OTPs In the first sectionof this chapter we give a formal model for the operation of the Yu-bikey OTP protocol version 20 in the form of multiset rewrite rules

44 analysis of the yubikey protocol and the yubihsm

for tamarin which was not available at the time of Vamanursquos analy-sis We prove security properties of the protocol for an unboundednumber of fresh OTPs using the tamarin prover

In the second section of this chapter we analyze the security of theprotocol with respect to an adversary that has temporary access to theauthentication server To address this scenario Yubico offers a smallHardware Security Module (HSM) called the YubiHSM intended toprotect keys even in the event of server compromise We show that ifthe same YubiHSM configuration is used both to set up Yubikeys andrun the authentication protocol there is inevitably an attack that leaksall of the keys to the attacker Our discovery of this attack lead to aYubico security advisory in February 2012 [105] In the case whereseparate servers are used for the two tasks we give a configurationfor which we can show (using tamarin) that if an adversary can com-promise the server running the Yubikey-protocol but not the serverused to set up new Yubikeys she cannot obtain the keys used to pro-duce one-time passwords The third section of this chapter evaluatesour results and methodology

All our analysis and proofs are in an abstract model of cryptogra-phy in the Dolev-Yao style and make various assumptions (that wewill make explicit) about the behaviour of the Yubikey and YubiHSMWhen we refer to the Yubikey or the Yubikey protocol we mean ver-sion 20 of the hardware token and the authentication protocol Weanalysed version 098 beta of the YubiHSM and validated our attackon this device According to the documentation the model presentedin Section 42 remains unchanged for the publicly available version10 of the hardware device

The analysis described in this chapter is joint work with GrahamSteel and was published at STM 2012 [60]

41 yubikey and yubikey authentication protocol

This section first discusses the Yubikey and the Yubikey authentica-tion protocol before describing the modelling used for security anal-ysis

411 About the Yubikey Authentication Protocol

In the remainder we will cover the authentication protocol as it per-tains to version 20 of the Yubikey device [93]

The Yubikey is connected to the computer via the USB port It iden-tifies itself as a standard USB keyboard in order to be usable out-of-the-

box in most environments using the operating systemrsquos native driversSince USB keyboards send ldquoscan codesrdquo rather than actual charactersthe character the Yubikey transmits to the systems depends on themapping from scan codes to characters i e keyboard layout on the

41 yubikey and yubikey authentication protocol 45

system In order to transmit the correct characters in the majority ofenvironments the Yubikey employs a modified hexadecimal encod-ing called modhex which uses characters that have the same positionon many different keyboard layouts including the French AZERTYthe German QUERTZ and the US QWERTY layout Each keystrokecarries 4 bits of information [93 Section 62]

The Yubikey can be configured to work in any of the followingmodes [93 Section 21]

bull Yubikey OTP which is the method that is typically employed

bull OATH-HOTP where the OTP is generated according to the stan-dard RFC 4226 HOTP algorithm

bull Challenge-response mode where a client-side API is used to re-trieve the OTP instead of the keyboard emulation and

bull Static mode where a (static) password is output instead of anOTP

We will focus only on the Yubikey OTP mode which we will explainin detail Depending on the authentication module used on the serverthere are four basic authentication modes [107 Section 341]

bull User Name + Password + YubiKey OTP

bull User Name or YubiKey OTP + Password

bull YubiKey OTP only

bull User Name + Password

As the security provided by a user-chosen password is an orthogo-nal topic and the OTP is the main feature of the Yubikey we will onlyfocus on the third authentication mode

The Yubikey has exactly one button If this button is pressed itemits a string via USB The string emitted by the Yubikey is a 44-character string (i e 22 bytes of information in modhex encodingsee above) and consists of the unique public ID (6 bytes) and the OTP

(16 bytes) encrypted under its AES key [55] The length of the OTP isexactly the block-length of AES It contains the following information(in order) [93 Section 61]

bull the unique secret ID (6 bytes)

bull a session counter (2 byte)

bull a timecode (3 byte)

bull a token counter (1 byte)

bull a pseudo-random value (2 bytes)

8792ebfe26cc 0013 c0a8 00 10 4495 e9ecUnique Device Id

Session Counter

Timestamp

Token Counter

Pseudo-random

CRC-16 value

Figure 7 Structure of the OTP (session 19 token 16)

bull a CRC-16 checksum (2 byte)

See Figure 7 for an exampleYubico assigns an AES key and a public and secret ID to the Yu-

bikey before shipment but they can be overwritten The Yubikey iswrite-only in this regard thus it is not possible to retrieve the secretID nor the AES key The session counter is incremented wheneverthe Yubikey is plugged in Once it reaches its limit of 216 = 65536it cannot be used anymore The timecode is incremented by an 8Hzinternal clock When it reaches its limit the session is terminatedi e no more OTPs can be generated This happens after approxi-mately 24 days The token counter is incremented whenever an OTP

is generated When it reaches its limit of 256 it restarts at 1 insteadof terminating the session The pseudo-random value of length twobytes is supposed to add entropy to the plaintext while the CyclicRedundancy Check (CRC) is supposed to detect transmission errorsIt does not provide cryptographic integrity

A Yubikey stores public and secret ID pid and sid and the AES

key k and is used in the following authentication protocol The userprovides a client C with the Yubikeyrsquos output pid otpe g by filling itin a web form The infix operator denotes concatenation

Crarr S pid otp nonce

Srarr C otp nonce hmac status

Here nonce is a randomly chosen value between 8 and 20 bytes andhmac is a Message Authentication Code (MAC) over the parametersusing a key present on the server and the client By status we denoteadditional status information given in the response containing an er-ror code that indicates either success or where the verification of theOTP failed plus (in case of success) the value of the internal times-tamp session counter and token counter when the key was pressedand more [94]

The server S accepts the token if and only if either the sessioncounter is bigger than the last one received or the session counterhas the same value but the token counter is incremented It is pos-sible to verify if the timestamp is in a certain window with respectto the previous timestamp received however our model does notinclude the timing of messages therefore we ignore this (optional)check

412 Formal Analysis (Uncompromised Server)

We are using tamarin for the analysis because it supports the mod-elling of explicit state which is an important part of this protocolConsider for example that the last counter received from some Yu-bikey is saved on the server The protocol relies on the fact that oncean OTP with a counter value has been accepted the last counter valueis updated Certain OTP values that would have been accepted be-fore will be rejected from this moment on We argued in Chapter 3specifically Section 34 why this kind of ldquonon-monotonicityrdquo doesnot work well with many abstractions that are used in the context ofautomated protocol verification As we will show in the course of thenext chapters tamarin allows for the analysis of this protocol

An important part of the modelling of the protocol is to determinewhether one counter value is smaller than another To this end ourmodelling employs a feature added to the development version oftamarin as of October 2012 a union operator cup for multisets of mes-sage terms The operator is denoted with a plus sign (ldquo+rdquo) in tamarinto avoid confusion we will use the same notation in the multisetrewriting calculus We model the counter as a multiset only consist-ing of the symbol ldquoonerdquo The cardinality of the multiset is the valueof the counter A counter value is considered smaller than anotherone if the first multiset is included in the second We enforce thosesemantics by adding an axiom that requires for all instantiations ofrules annotated with Smaller(a b) that a is a subset of b

foralli temp a b msg Smaller(a b)irArr existz msga+ z = b

Recall that i is a time-points and Eventi means that the trace con-tains a rule instantiation that produces the action Event at time pointi

We had to simplify the modelling of the session and token counterInstead of having two counters we just model a single counter Sincethe Yubikey either increases the session counter and resets the tokencounter or increases the token counter and leaves the session counteruntouched it implements a complete lexicographical order on thepair (session counter token counter) Since the authentication serveraccepts an OTP if either the session counter is bigger than the lastone received or the session counter has the same value but the tokencounter is incremented we let it accept the single counter if it is largerthan previously received counter

The following rule models the initialisation of a Yubikey A freshpublic ID (pid) secret ID (sid) and Yubikey-key (k) are drawn andsaved on the server and the Yubikey

Fr(k)Fr(pid)Fr(sid)

minus[ Protocol() Init(pid k)ExtendedInit(pid sid k)]rarr

Y(pid sid)Y_counter(pid prime1 prime) Server(pid sid prime1 prime)

SharedKey(pid k)

The Fr-facts guarantee that each instantiation of this rule replaces kpid and sid by different fresh names The Yubikey is identified by itspublic ID thus the permanent fact Y stores the corresponding secretID and SharedKey the corresponding key k which is shared with theserver i e rules both on the side of the authentication server andthe Yubikey make use of this fact Y_counter is the current countervalue stored on the Yubikey Server models the table on the server-side storing which Yubikey is associated with which secret ID andthe value of the last counter received

The next rule models how the counter is increased when a Yubikeyis plugged in As mentioned before we model both the session andthe token counter as a single counter We over-approximate in thecase that the Yubikey increases the session token by allowing the ad-versary to instantiate the rule for any counter value that is higherthan the previous one using the Smaller action

Y_counter(pid otc) In(tc) minus[ Yubi(pid tc)Smaller(otc tc)]rarr

Y_counter(pid tc)

Note that the adversary has to input tc We can only express proper-ties about the set of traces in tamarin e g the terms the adversaryconstructs in a given trace but not the terms she could construct inthis trace By requiring the adversary to produce all counter valueswe can ensure that they are in K i e the adversaryrsquos knowledge

When the button is pressed an encryption is output in addition toincreasing the counter

Y(pid sid)Y_counter(pid tc) SharedKey(pid k) In(tc)Fr(npr)

Fr(nonce)

minus[ YubiPress(pid tc)]rarr

Y_counter(pid tc + prime 1 prime)Out(〈pidnonce senc(〈sid tcnpr〉 k)〉)

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(〈pidnonce otp〉) SharedKey(pid k) In(otc)

minus[Login(pid sid tc otp) LoginCounter(pid otc tc)

Smaller(otc tc) ]rarr

Server(pid sid tc)

for otp = senc(〈sid tc pr〉 k) Tamarin is able to prove the followingproperties

1 The absence of replay attacks

not(existi j pid sid x otp1 otp2

Login(pid sid x otp1)iand Login(pid sid x otp2)j

andnot(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

forall pid sid x otp t2

Login(pid sid x otp)t2 rArr

existt1YubiPress(pid x)t1 and t1 ⋖ t2and forallotp2 t3Login(pid sid x otp2)t3 rArr t3 = t2

A successful login must have been preceded by a button pressfor the same counter value Furthermore there is not seconddistinct 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

forall pid otc1 tc1 otc2 tc2 t1 t2 t3 Smaller(tc1 tc2)t3and LoginCounter(pid otc1 tc1)t1and LoginCounter(pid otc2 tc2)t2rArr t1 ⋖ t2

The absence of replay attacks is proven by showing the followingstronger property which we use as an invariant

forall pid otc1 tc1 otc2 tc2 t1 t2 LoginCounter(pid otc1 tc1)t1and LoginCounter(pid otc2 tc2)t2 and t1 ⋖ t2

rArr existztc2 = z+ tc1

Intuitively this means that counter values are strictly increasing intime If counter values are increasing strictly in time any two lo-gins with the same counter value are in fact the same i e there areno replay attack Tamarin is able to prove the invariant as well asthe security properties completely automatically Note that in thismodel the adversary has no direct access to the server she can onlycontrol the network (as well as the Yubikey according to its specifica-tion) A stronger attack model is discussed in the next section Forthe complete input to tamarin including the multiset rewrite rulesconstituting the model as well as the security properties and helpinglemmas see Listing 17 in Section A2 All source files and proofs areavailable online too [59]

42 the yubihsm

The results from the previous chapter assume that the authenticationserver remains secure Unfortunately such servers are valuable tar-gets and consequently successful attacks occur from time to time ndashas in the case of the RSA Security Inc (RSA) SecurID system whereattackers were able to compromise the secret seed values stored onthe server and thereby fake logins for sensitive organisations such asLockheed Martin [56] RSA now use an HSM to protect seeds in theevent of server compromise Yubico also offer (and use themselves)an application specific HSM the YubiHSM to protect the Yubikey AES

keys in the event of an authentication server compromise by encrypt-ing them under a master key stored inside the YubiHSM In the sec-ond part of our chapter we analyse the security of the YubiHSM APIFirst we show that due to an apparent oversight in the cryptographicdesign an attacker with access to the server where Yubikey AES keysare generated is able to decrypt the encrypted keys and obtain themin clear We then prove secrecy of keys in various configurations ofYubiHSMs and servers and suggest design changes that would allowa single server to be used securely

421 About the YubiHSM

The YubiHSM is also a USB device about 5 times thicker than a Yu-bikey According to Yubico it ldquoprovides a low-cost [$500] way tomove out sensitive information and cryptographic operations awayfrom a vulnerable computer environment without having to investin expensive dedicated Hardware Security Modules (HSMs)rdquo [106]The YubiHSM stores a very limited number of AES keys in a way thatthe server can use them to perform cryptographic operations with-out the key values ever appearing in the serverrsquos memory Theselsquomaster keysrsquo are generated during configuration time and can nei-ther be modified nor read at runtime The master keys are used to

42 the yubihsm 51

encrypt working keys which can then be stored safely on the serverrsquoshard disk The working keys are encrypted inside so-called AEADs

(blocks produced by authenticated encryption with associated data)In order to produce or decrypt an AEAD an AES key and a piece ofassociated data is required The YubiHSM uses CCM mode to obtainan AEAD algorithm from the AES block cipher [99]

In the case of the Yubikey protocol AEADs are used to store thekeys the server shares with the Yubikey tokens and the associateddata is the public ID and the key-handle used to reference the AES keyThe idea here is that since the master keys of the YubiHSM cannot beextracted the attacker never learns the value of any Yubikey AES keyseven if she successfully attacks the server While she is in control ofthe server she is (of course) able to grant or deny authentication toany client at will However if the attack is detected and the attackerloses access to the server it should not be necessary to replace orrewrite the Yubikeys that are in circulation in order to re-establishsecurity

422 Two Attacks on the Implementation of Authenticated Encryption

The YubiHSM provides access to about 22 commands that can be ac-tivated or de-activated globally or per key during configuration Wefirst examined the YubiHSM API in its default configuration discover-ing the following two attacks which led to a security advisory issuedby Yubikey in February 2012 [105]

The attacks use the following two commands

bull AES_ECB_BLOCK_ENCRYPT takes a handle to an AES key anda plaintext of length of one AES block (16 Bytes) and applies theraw block cipher

bull YSM_AEAD_GENERATE takes a nonce a handle to an AES keyand some data and outputs an AEAD More precisely but stillsimplified for our purposes it computes

AEAD(noncekh data) =

|data|blocksize

AES(k counteri)

where k is the key referenced by the key-handle kh counteri isa counter that is completely determined by khnonce i and thelength of data and blocksize is 16 bytes For the precise definitionof mac and counter we refer to Request For Comments (RFC)3610 [99]

Figure 8 depicts the counter mode of operation used to calculatethe ciphertext body of the AEAD to which the MAC will be appended

counter1 counter2 countern

AES AES AES

data1oplus

data2oplus

middot middot middot datanoplus

cypher1 cypher2 middot middot middot cyphern

Figure 8 AES in counter mode (simplified)

The AEADs used to store keys for decrypting OTPs in the Yubikeyprotocol are special cases The plaintext is a concatenation of therespective Yubikeyrsquos AES key and secret device ID (22 bytes in total)and nonce consists of the Yubikeyrsquos public ID

An attacker with access to the command AES_ECB_BLOCK_EN-CRYPT is able to decrypt an AEAD by recreating the blocks of thekey-stream i e AES(k counteri) She xors the result with the AEAD

truncated by 8 bytes (the length of mac) and yields data When the at-tacker is able to compromise the server she learns the AEAD and thekey-handle used to produce it Since the nonce is the public ID of theYubikey she can compute counteri and using AES_ECB_BLOCK_EN-CRYPT the key-stream It is in the nature of the counter-mode thatencryption and decryption are the same operation According to thereference manual[106 Section 43] ldquothe YubiHSM intentionally doesnot provide any functions [sic] that decrypts an AEAD and returnsit in clear text either fully or partial [sic]rdquo We therefore considerthe protection of the AEADrsquos contents a security goal of the YubiHSMwhich is violated by this attack The attack can be prevented by dis-abling the AES_ECB_BLOCK_ENCRYPT command on the relevantkey handles at configuration time

The second attack uses only YSM_AEAD_GENERATE An attackercan produce AEAD(nonce kh 0l) for the same handle kh and a valuenonce that was previously used to generated another AEAD of lengthl This way an attacker can recover the key-stream directly (discard-ing mac) Once again it is possible to decrypt AEADs This attackis worse than the first one because YSM_AEAD_GENERATE is nec-essary for the set-up of Yubikeys Note that the attack applies alsoto the commands YSM_RANDOM_AEAD_GENERATE and YSM_-BUFFER_AEAD_GENERATE [106 p 28-29]

This second attack is harder to prevent since in order to set up Yu-bikeys with their AES keys the YSM_AEAD_GENERATE commandmust be enabled at some point The security advisory suggests thatthe threat can be ldquomitigated by observing that a YubiHSM used togenerate AEADs is guarded closely to not permit maliciously craftedinputrdquo In the next section we try to interpret this advice into a con-crete configuration for which we can prove security of the sensitive

42 the yubihsm 53

keys Then in section 43 we describe practical ways in which thisconfiguration could be used

Remark 1 Bellare et al gave a proof of security for counter mode[10]Under the assumption that AES constitutes are pseudo-random per-mutation this mode of operation should transform the block cipherAES into a secure encryption scheme The flaw lies in the implementa-tion The YubiHSM allows an arbitrary nonce to be supplied as Initial-isation Vector (IV) for the counter The security relies on the fact thatthose nonce values are unique Bellare et al propose counter modeas a statefull encryption scheme that increments the nonce value forevery produced cipher-text The uniqueness of the nonces cannot beassured neither in the case that AES_ECB_BLOCK_ENCRYPT is avail-able nor in the case where YSM_AEAD_GENERATE is available

423 Analysis in the Case of Server Compromise

From now on we will assume the following corruption scenario Inaddition to the capacities described in Section 412 the attacker canread the AEADs stored on the server and she can access the HSM EveryAEAD is created using the same key on the HSM the handle to thiskey is made public The public ID is given to the adversary when aYubikey is set up Counter values are deducible so there is no needto give the adversary explicit access to this data The adversary is stillnot able to directly read the data stored on the Yubikey or YubiHSMNote that in this situation the attacker can trivially approve or denyauthorisation requests to the server hence we cannot expect to showabsence of replay attacks We are rather interested in whether theattacker can recover the secret keys used to create OTPs which wouldallow her to continue to obtain authorisation even once she is deniedaccess to the server

We model the xor operator in a simplified manner The equationaltheory we employ allows for rediscovering the two attacks describedin Section 422 but it does not capture all attacks that xor mightpermit in this context For this reason the positive security resultsin this section have to be taken with caution We model xor with thefunction symbols xor and the following five equations

xor(xor(a b) a) = b xor(0 a) = a

xor(xor(a b) b) = a xor(a 0) = a and

xor(a a) = 0

These equations ignore commutativity and associativity of xor Usingthis equational theory we are able to rediscover the attacks describedin the previous section The current version of tamarin (0821) doesnot have built-in support yet but it is planned for future releases

Remark 2 There is a technique by Kuumlsters and Truderung which re-duces protocol analysis including xor to the xor-free case using an

approach based on Horn clauses [85] This technique cannot be em-ployed here since the protocol contains steps where xor is appliedto two terms which both contain variables see for example the rulesfor YSM_AEAD_YUBIKEY_OTP_DECODE below i e the protocolis not oplus-linear in the sense of their work

The counter values are modelled as before We initialise the Yu-biHSM with exactly one key-handle

Fr(k)Fr(kh) minus[ MasterKey(k)OneTime()]rarrHSM(kh k)Out(kh)

YSM_AEAD_YUBIKEY_OTP_DECODE(kh)

We make sure that this rule is only instantiated once by adding acorresponding axiom foralli j OneTime()iandOneTime()jrArr i = j

The following rules model the fact that the adversary can commu-nicate with the YubiHSM

OutHSM(x) minus[HSMRead(x) ]rarr [Out(x)]

In(x) minus[HSMWrite(x)]rarr [InHSM(x)]

and can read the list of AEADs stored on the authentication server

S_AEAD(pid aead) minus[AEADRead(aead)HSMRead(aead)]rarr

[Out(aead)]

The next rules aim at modelling the HSM We defined a set of 4 rulesin total but only YSM_AEAD_YUBIKEY_OTP_DECODE is actuallyused The initialisation rule produces the permanent fact YSM_-

AEAD_YUBIKEY_OTP_DECODE but not the fact required by theother rules This way we model a configuration that allows onlythe execution of YSM_AEAD_YUBIKEY_OTP_DECODE while theauthentication server might be compromised The rule YSM_AEAD_-GENERATE is deactivated in this sense but it is directly incorporatedinto the rule BuyANewYubikey see below This models a configura-tion where YSM_AEAD_GENERATE is active during setup but onlyduring setup

InHSM(〈did kh aead otp〉) HSM(kh k)

minus[ OtpDecode(k2 k 〈did sc r〉 sc xor(senc(ks k) 〈k2 did〉)mac)

OtpDecodeMaster(k2 k)]rarr OutHSM(sc)

ks = keystream(khN)

mac = mac(〈k2 did〉 k)

aead = 〈xor(senc(ksk) 〈k2 did〉)mac〉 and

otp = senc(〈did sc r〉 k2)

43 evaluation 55

The rules for emitting the OTP and the login are modelled in away that is very similar to the rules described in Section 412 but ofcourse we model the encryption used inside the AEAD in more detailHere the server-side rule for the login

In(〈pidnonce senc(〈sid tc pr〉 k2)〉) HSM(kh k)

S_sid(pid sid) S_AEAD(pid aead) S_Counter(pid otc)

minus[ Login(pid tc senc(〈sid tc pr〉 k2)) Smaller(otc tc)]rarr

S_Counter(pid tc)

where ksmac and aead are defined as beforeTamarin is able to prove that within our limited model of xor the

adversary never learns a Yubikey AES key or a YubiHSM master key -in other words AEAD as well as the key used to produce them stayconfidential The proof does not need human intervention howeversome additional typing invariants are needed in order to reach termi-nation For instance the following invariant is used to proof that akey k2 shared between the authentication server and the Yubikey canonly be learned when the key k used to encrypt the AEADs is leaked

forall t1 t2 pid k2 Init(pid k2)t1 andK(k2)t2rArr exist t3 t4 k K(k)t3 andMasterKey(k)t4 and t3 ⋖ t2

For the complete input to tamarin including the multiset rewriterules constituting the model as well as the security properties andhelping lemmas see Listing 18 in Section A2

43 evaluation

The positive and negative results in this chapter provide formal cri-teria to evaluate the security of the Yubikey protocol in different sce-narios

431 Positive Results

Under the assumption that the adversary can control the networkbut is not able to compromise the client or the authentication serverwe have shown that she cannot mount a replay attack Furthermoreif a YubiHSM is configured such that YSM_AEAD_YUBIKEY_OTP_-DECODE is the only available command then even in case the adver-sary is able to compromise the server the Yubikey AES keys remainsecure All these results are subject to our abstract modelling of cryp-tography and the algebraic properties of xor

Since the Yubikeys need to be provisioned with their AES keys andsecret identities must be stored in the AEADs we propose two set-upsthat can be used to obtain the configuration used in the analysis

1 One Server One YubiHSM There is a set-up phase which servesthe purpose of producing AEADs (using one of the AEAD gener-ation commands e g YSM_AEAD_GENERATE) and writingthe key and secretpublic identity on the Yubikey This phaseshould take place in a secure environment Afterwards the Yu-biHSM is returned to configuration mode and all commandsare disabled except YSM_AEAD_YUBIKEY_OTP_DECODE Inthis set-up only one YubiHSM is needed but it is not possibleto add new Yubikeys once the second phase has begun withouttaking the server off-line and returning the YubiHSM to config-uration mode Note that switching the YubiHSM into configu-ration mode requires physical access to the device hence wouldnot be possible for an attacker who has remotely compromisedthe server

2 Two Servers Two YubiHSMs There is one server that handlesthe authentication protocol and one that handles the set-up ofthe Yubikeys The latter is isolated from the network and onlyused for this very purpose so we consider it a secure environ-ment We configure two YubiHSMs such that they store thesame master-key (the key used to produce AEADs) The first isused for the authentication server and has only YSM_AEAD_-YUBIKEY_OTP_DECODE set to true the second is used in theset-up server and has only YSM_AEAD_GENERATE set to trueThe set-up server produces the list of public ids and correspond-ing AEADs which is transferred to the authentication server ina secure way for example in fixed intervals (every night) us-ing fresh USB keys The transfer does not necessarily have toprovide integrity or secrecy (as the adversary can block the au-thentication via the network anyway) but it should only beallowed in one direction

Reading between the lines (since no YubiHSM configuration detailsare given) it seems that Yubico themselves use the second set-up toprovision Yubikeys [100]

432 Negative Results

In case either of the permissions AES_ECB_BLOCK_ENCRYPT orYSM_AEAD_GENERATE are activated on a master key handle (bydefault both are) the YubiHSM does protect the keys used to produceone-time passwords encrypted under that master key Since YSM_-AEAD_GENERATE (or YSM_BUFFER_AEAD_GENERATE) are nec-essary in order to set up a Yubikey this means that separate setupand authorisation configurations have to be used in order to benefitfrom the use of the YubiHSM i e have a higher level of securitythan in the case where the keys are stored unencrypted on the hard

43 evaluation 57

disk Unfortunately open source code available on the web in eg theyhsmpam project [48] designed to use the YubiHSM to protect pass-words from server compromise uses the insecure configuration ieone YubiHSM with both YSM_AEAD_GENERATE and (in this case)YSM_AEAD_DECRYPT_CMP enabled and hence would not providethe security intended

433 Possible changes to the YubiHSM

We will now discuss two possible counter-measures against this kindof attack that could be incorporated into future versions of the Yu-biHSM to allow a single device to be used securely the first whichmay be seen as a kind of stop-gap measure the second which is amore satisfactory solution using more suitable crypto

1 AEAD_GENERATE with a randomly drawn nonce All three Yu-biHSM commands to generate AEADs i e

bull YSM_AEAD_GENERATE

bull YSM_BUFFER_AEAD_GENERATE and

bull YSM_RANDOM_AEAD_GENERATE

let the user supply the nonce that is used as Initialisation Vector(IV) This would not be possible if they were replaced by acommand similar to YSM_AEAD_GENERATE that chooses thenonce randomly and outputs it at the end so it is possible to usethe nonce as the public ID of the Yubikey However even in thiscase there is an online guessing attack on the HSM An AEAD canbe decrypted if the right nonce is guessed We can assume thatthe adversary has gathered a set of honestly generated OTPs soshe is able to recognize the correct nonce Since the nonce spaceis rather small (248) in comparison to the key-space of AES-128the adversary could perform a brute-force search We measuredthe amount of time it takes to perform 10 000 YSM_AEAD_-GENERATE operations on the YubiHSM The average value is02178 ms so it would take approximately 1900 years to traversethe nonce space Even so this is not completely reassuring

2 SIV-mode The Synthetic Initialization Vector (SIV) mode of op-eration [86] is designed to be resistant to repeated IVs It is anauthenticated encryption mode that works by deriving the IV

from the MAC that will be used for authentication As such it isdeterministic - two identical plaintexts will have an identical ci-phertext - but the encryption function cannot be inverted in thesame way as Counter mode of operation with CBC-MAC (CCM)mode by giving the same IV (the encryption function does nottake an IV as input the only way to force the same IV to beused is to give the same plaintext) This would seem to suit the

requirements of the YubiHSM very well since it is only keysthat will be encrypted hence the chances of repeating a plain-text are negligible Even if the same key is put on two differentYubikeys they will have different private IDs yielding differentAEADs In our view this is the most satisfactory solution

434 Methodology

Since the tamarin prover could not derive the results in this chapterwithout auxiliary lemmas we think it is valuable to give some infor-mation about the way we derived those results

We first modelled the protocol using multiset rewrite rules whichwas a relatively straight-forward task However note that our modelconsists of only four rules and is therefore quite coarse In particu-lar since e g the emission of a Yubikey and the authentication bythe server e g are modelled using a single rule each we assumethose steps to be atomic This idealisation seems common for multi-set rewrite models but is somewhat unrealistic as it removes a lot ofpotential scheduling problems from the model

After we modelled the protocol we stated a sanity lemma sayingldquoThere does not exist a trace that corresponds to a successful protocolrunrdquo to verify that our model is sane Tamarin should be able toderive a counter-example which is a proof that a correct protocol runis possible

We stated the security property we wanted to prove e g the ab-sence of replay attacks Since tamarin did not produce a proof on itsown we investigated the proof derivation in interactive mode Wededuced lemmas that seemed necessary to cut branches in the proofthat are looping so-called typing invariants An example is YSM_-AEAD_YUBIKEY_OTP_DECODE It outputs a subterm of its inputnamely the counter value Whenever tamarin tries to derive a termt it uses backward induction to find a combination of AEAD and OTP

that allows to conclude that the result of this operation is t MeierCremers and Basin propose a technique they call decryption-chain rea-

soning in [73 Section 3b] that we used to formulate our typing invari-ant Once the invariant is stated it needs to be proven Sometimes theinvariant depends on another invariant that needs to be found man-ually Finding the right invariants took a bit of time and to a certaindegree was a trial and error task as we did not have much experiencewith tamarin We eventually found a set of invariants that lead to asuccessful verification of the security property and then minimisedthis set of lemmas by deleting those that were not necessary

All in all it took about 1 month to do the analysis presented in thiswork The modelling of the protocol took no more than half a dayFinding a first modelling of the natural numbers and the ldquoIs smallerthanrdquo relation suitable for analysis in tamarin took a week since at

43 evaluation 59

this time the multiset union operator was not available in tamarinWe employed a modelling that builds the ldquoIs smaller thanrdquo as a set ofpermanent facts from an ldquoIs Successorrdquo of relation

In(0) In(S(0)) minus[IsSucc(0S(0))IsZero(0)]rarrSucc(0S(0))

In(y) In(S(y))

Succ(x y)minus[IsSucc(yS(y)) ]rarrSucc(yS(y))

Succ(x y) minus[IsSmaller(x y) ]rarrSmaller(x y)

Smaller(x y)

Succ(y z)minus[IsSmaller(x z) ]rarrSmaller(x z)

An additional axiom was needed to enforce transitivity Using thismodelling it was also possible to derive all results covered in thischapter We consider the modelling using the multiset data type morenatural whereas this modelling does not rely on the support of asso-ciativity commutativity and a neutral element in equational theoriesas is needed to model multisets with the empty multiset and multisetunion It might be interesting for similar use cases with other toolsthat may not support such equational theories The complete input totamarin including the multiset rewrite rules constituting the modeldescribed as well as the security properties helping lemmas and ad-ditional axioms can be found in Listing 19 (for the case without servercompromise) and Listing 20 (for the case where the server might becompromised but a YubiHSM is protecting the key) in Section A2

The lionrsquos share of the time was spent in searching the right in-variants for termination The running time of tamarin is acceptableProving the absence of replay attacks in case of an uncompromisedserver takes around 35 seconds proving confidentiality of keys in thecase of a compromised server takes around 50 seconds both on a24GHz Intel Core 2 Duo with 4GB RAM

435 Future work

We learned that it is possible to obtain formal results on the YubiKeyand YubiHSM for an unbounded model using tamarin Howeverthere are plenty of improvements to be made In the model presentedin this chapter we treat the session and token counter on the Yubikeyas a single value which is justifiable by the fact that the Yubikey ei-ther increases the session counter and resets the token counter orincreases the token counter thereby implementing a complete lexico-graphical order on the pair (session counter token counter) Never-theless a more detailed model would not rely on this argument Wefurthermore omit the CRC and the time-stamp since in the symbolicsetting they do not add to the security of the protocol

Secondly we simplified the algebraic theory of xor considerablyThe treatment of xor is in discussion for future versions of the tamarintool

As stated in Section 434 finding the right lemmas to prove the se-curity properties was a huge part of the analysis A methodology forderiving the lemmas that tamarin needs to obtain a proof automati-cally could permit more automation and hence allow for the analysisof larger models

5A P R O C E S S C A L C U L U S W I T H S TAT E

The applied pi calculus [2] has been very successful in the domain ofprotocol verification as it allows an intuitive modelling of protocolswith an emphasis on the most important part the communication be-tween processes It is sufficiently abstract to allow for automated anal-ysis while at the same time it is sufficiently concrete to allow refine-ment into a working implementation that actually benefits from theprotocol analysis ndash ideally this refinement can be proven to carry thesecurity results from the analysis to the implementation as demon-strated by Pironti et al [79 80] Even if the refinement may not beprovably correct a semantically rich model helps minimizing the ldquode-grees of freedomrdquo of such a refinement and thus helps establishingconfidence in the implementation

In our opinion the formalism of StatVerif [5] has those two qual-ities Unfortunately as shown in Chapter 3 the translation fromStatVerifrsquos calculus into Horn clauses suffers some limitations withrespect to the application of security APIs Additionally there aresome limitations in the calculus itself such as the limited amount ofcells and the limited use of locks In the last chapter we have seenhow multiset rewriting can be used for the analysis of security APIsalthough it requires a certain amount of effort to derive a good mod-elling Another disadvantage is that it is quite hard to see whetherthe set of multiset rewrite rules describing the protocol and an im-plementation of the protocol do the same thing The representationof protocols as multiset rewrite rules is very low level and far awayfrom actual protocol implementations making it difficult to modelprotocols correctly Encoding private channels nested replicationsand locking mechanisms directly as multiset rewrite rules is a trickyand error prone task Protocol steps are often represented as a singlerule making them effectively atomic This obscures eventual issuesin concurrent protocol steps that would otherwise require e g ex-plicit locking thus increasing the risk of implicitly excluding attacksin the model that are well possible in a real implementation e g raceconditions This chapter aims at combining the advantages of an ap-plied pi-like calculus similar to StatVerif with the constraint solvingalgorithm employed by the tamarin-prover

In this chapter we propose a tool for analyzing protocols that mayinvolve non-monotonic global state The toolrsquos input language de-scribed in Section 52 is a variant of the applied pi calculus withadditional constructs for manipulating state The heart of our toolis a translation from this calculus to a set of multiset rewrite rules

62 a process calculus with state

that can then be analyzed by the tamarin-prover (see Section 36) as aback-end We introduce this translation in Section 53 We prove thecorrectness of this translation in Section 54 and show that it preservesall properties expressible in a dedicated first order logic for express-ing security properties In Section 55 we illustrate the tool on severalcase studies a simple security API in the style of PKCS11 a complexcase study of the Yubikey security device as well as several examplesanalyzed by other tools that aim at analyzing stateful protocols Inall of these case studies we were able to avoid restrictions that werenecessary in previous works

51 related work

The most closely related work is the StatVerif tool by Arapinis etal [5] They propose a stateful extension of the applied pi calcu-lus similar to ours which is translated to Horn clauses and ana-lyzed by the ProVerif tool Their translation is sound but may re-port false attacks which limits the scope of protocols that can beanalyzed Moreover StatVerif can only handle a finite number ofmemory cells When analyzing an optimistic contract signing pro-tocols this appeared to be a limitation and only the status of a sin-gle contract is modeled Arapinis et al have to provide a man-ual proof to justify the correctness of this protocol-specific abstrac-tion We highlight the differences between our calculus and the cal-culus StatVerif offers in Section 523 A more extensive discussionof StatVerif the abstraction-by-set-membership approach by Moumlder-sheim [74] the state synchronisation extension to Guttmanrsquos strandspace model [47] and work tailored to particular applications [36 35]can be found in Chapter 3

In the goal of relating different approaches for protocol analysisBistarelli et al [11] also proposed a translation from a process alge-bra to multiset rewriting which is very similar to our goal Theydo however not consider private channels or global state and assumethat processes have a particular structure Because of those limita-tions their translation and its correctness proof differ significantlyfrom ours Moreover their work does not include any tool supportfor automated verification where we designed our translation withregard to tamarinrsquos constraint solving algorithm

52 a cryptographic pi calculus

with explicit state

Our specification language includes support for private channels foran explicit global state and for locking mechanisms (which are crucialto write meaningful programs in which concurrent threads manipu-late a common memory) The underlying tamarin prover is able to

52 a cryptographic pi calculus with explicit state 63

〈MN〉 = x y z isin V

| p isin PN

| n isin FN

| f(M1 Mn) (f isin Σ of arity n)

〈PQ〉 = 0

| P | Q

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

521 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 90 denotes the terminal process For readability we sometimes omit

trailing 0 processes P | Q is the parallel execution of processes Pand 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(MN) P and in(MN) P represent the output respectively in-put of message N on channel M Readers familiar with the applied

pi calculus [2] may note that we opted for the possibility of patternmatching in the input construct rather than merely binding the inputto a variable x The process if M = N then P else Q will execute Pif M =E N and Q otherwise As usual we sometimes omit to writeelse Q when Q is 0 The event construct is merely used for annotatingprocesses and will be useful for stating security properties

The remaining constructs are used for manipulating state and arenew compared to the applied pi calculus We offer two differentmechanisms for state The first construct is functional and associatesa value to a key The construct insert MN binds the value N to a keyM Successive inserts change this binding The delete M operationsimply ldquoundefinesrdquo the mapping for the key M The lookup M as x

in P else Q construct retrieves the value associated to M and bindsit to the variable x in P If the mapping is undefined for M theprocess behaves as Q The lock and unlock constructs can be usedto gain exclusive access to a resource M This is essential for writingprotocols where parallel processes may read and update a commonmemory We additionally offer another kind of global state in formof a second store modelled as a multiset of ground facts

This second store allows access to the underlying notion of state intamarin but it is distinct from the previously introduced functionalstate It is similar in style to the state extension in the strand spacemodel [47] and the underlying specification language of the tamarintool [89 90] It is accessed via the construct [L] minus[A]rarr [R]P whichmatches each fact in the sequence L to facts in the current store andif successful adds the corresponding instance of facts R to the storeThe facts A are used as annotations in a similar way to events

The following example illustrates a problem that occurs in the anal-ysis of security APIs such as PKCS11 [36 20 44] and will serve as arunning example throughout this chapter

Example 14 The following API allows the creation of keys in somesecure memory The user can access the device via an API If she cre-ates a key she obtains a handle which she can use to let the deviceperform operations on her behalf The goal is that the user can nevergain knowledge of the key as the userrsquos machine might be compro-mised Consider the following process modelling the device (we useout(m) as a shortcut for out(lsquocrsquom) for a public channel lsquocrsquo)

Pex =Pnew |Pset |Pdec |Pwrap

Pnew =νhνk event NewKey(hk) (1)

insert ltlsquokeyrsquohgtk

insert ltlsquoattrsquohgtlsquodecrsquo out(h)

In the first line the device creates a new handle h and a key k andlogs the creation of this key It then stores the key that belongs to

the handle by associating the pair 〈lsquokeyrsquo h〉 to the value of the keyk In the next line 〈lsquoattrsquo h〉 is associated to a public constant lsquodecrsquoIntuitively we use the public constants lsquokeyrsquo and lsquoattrsquo to distinguishtwo databases The process

Pset = in(h) insert 〈lsquoattrsquoh〉 lsquowraprsquo

provides an interface for changing the attribute of a key from theinitial value lsquodecrsquo to another value lsquowraprsquo to the user If a handle hasthe lsquodecrsquo attribute set it can be used for decryption

Pdec = in(〈 hc〉) lookup 〈lsquoattrsquoh〉 as a in (2)

if a=lsquodecrsquo then lookup 〈lsquokeyrsquoh〉 as k in

if encSucc(ck)=true then

event DecUsing(ksdec(ck)) out(sdec(ck))

The first lookup stores the value associated to 〈lsquoattrsquo h〉 in a The valueis compared against lsquodecrsquo If the comparison and another lookup forthe associated key value k succeeds we check whether decryptionsucceeds and if so output the plaintext

If a key has the lsquowraprsquo attribute set it might be used to encrypt thevalue of a second key

Pwrap = in(〈h1 h2〉) lookup 〈lsquoattrsquoh1〉 as a1 in

if a1=lsquowraprsquo then lookup 〈lsquokeyrsquoh1〉 as k1 in

lookup 〈lsquokeyrsquo h2〉 as k2 in

event Wrap(k1k2) out(senc(k2k1))

The bound names of a process are those that are bound by νnWe suppose that all names of sort fresh appearing in the process areunder the scope of such a binder Free names must be of sort pub Avariable x can be bound in three ways

1 by the construct lookup M as x or

2 x isin vars(N) in the construct in(MN) and x is not under thescope of a previous binder

3 x isin vars(L) in the construct [L] minus[A]rarr [R] and x is not under thescope of a previous binder

While the construct lookup M as x always acts as a binder the inputconstruct and the [L] minus[A]rarr [R] constructs do not rebind an alreadybound variable but perform pattern matching For instance in theprocess

P = in(cf(x)) in(cg(x))

x is bound by the first input and pattern matched in the second Wediscuss this choice in Section 5233

a isin FN cup PN a isin nνnσ ⊢ a Dname

νnσ ⊢ t t =E tprime

νnσ ⊢ t primeDEq

x isin D(σ)

νnσ ⊢ xσ DFrameνnσ ⊢ t1 middot middot middotνnσ ⊢ tn f isin Σk

νnσ ⊢ f(t1 tn)DAppl

Figure 10 Deduction rules

A process is ground if it does not contain any free variable Wedenote by Pσ the application of the homomorphic extension of thesubstitution σ to P As usual we suppose that the substitution onlyapplies to free variables We sometimes interpret the syntax tree ofa process as a term and write P|p to refer to the subprocess of P atposition p (where | if and lookup are interpreted as binary symbolsall other constructs as unary)

522 Semantics

5221 Frames and deduction

Before giving the formal semantics of our calculus we introduce thenotions of frame and deduction A frame consists of a set of freshnames n and a substitution σ and is written νnσ Intuitively a framerepresents the sequence of messages that have been observed by anadversary during a protocol execution σ and the secrets generatedby the protocol n a priori unknown to the adversary Deductionmodels the capacity of the adversary to compute new messages fromthe observed ones

Definition 9 (Deduction) We define the deduction relation νnσ ⊢ tas the smallest relation between frames and terms defined by thededuction rules in Figure 10

Example 15 If one key is used to wrap a second key then given theintruder learns the first key he can deduce the second For n = k1 k2and σ = senc(k2k1)x1

k1 x2 νnσ ⊢ k2 since

x1 isin D(σ)

νnσ ⊢ senc(k2 k1)

x2 isin D(σ)

νnσ ⊢ k1νnσ ⊢ sdec(senc(k2 k1) k1) sdec(senc(k2 k1) k1) =E k2

νnσ ⊢ k2

5222 Operational semantics

We can now define the operational semantics of our calculus Thesemantics is defined by a labelled transition relation between processconfigurations A process configuration is a 6-tuple (E S SMSP σL)

bull E sube FN is the set of fresh names generated by the processes

bull S MΣ rarrMΣ is a partial function modeling the functional store

bull SMS sube G is a multiset of ground facts and models the multisetof stored facts

bull P is a multiset of ground processes representing the processesexecuted in parallel

bull σ is a ground substitution modeling the messages output to theenvironment

bull L subeMΣ is the set of currently acquired locks

The transition relation is defined by the rules described in Figure 11Transitions are labelled by sets of ground facts For readability weomit empty sets and brackets around singletons ie we write rarr foremptyminusrarr and f

minusrarr for f minusrarr We writerarrlowast for the reflexive transitive closure

of rarr (the transitions that are labelled by the empty sets) and writefrArr for rarrlowast f

rarrrarrlowast We can now define the set of traces ie possibleexecutions that a process admits

Definition 10 (Traces of P) Given a ground process P we define the set

of traces of P as

tracespi(P) =

[F1 Fn] | (empty empty empty P empty empty)F1=rArr (E1 S1

SMS1 P1 σ1 L1)

F2=rArr

Fn=rArr (En Sn S

MSn Pn σnLn)

Example 16 The following examples shows how the first key is cre-ated on the security device in our running example

(empty empty empty Pnew |Pset |Pdec |Pwrap empty empty)

rarr(empty empty empty Pnew Pset |Pdec |Pwrap︸︷︷︸

=P prime

empty empty)

rarr(empty empty empty Pnew cup P prime empty empty)

rarr(empty empty empty new h new k event NewKey(hk) cup P prime empty empty)

rarrlowast(h prime k prime empty empty event NewKey(hrsquokrsquo) cup P prime empty empty)

NewKey(h primek prime)minusminusminusminusminusminusminusminusminusminusrarr

(h prime k prime empty empty insert 〈lsquokeyrsquoh〉 k cup P prime empty empty)

rarrlowast(h prime k prime S empty out(h) 0 cup P prime empty empty)

rarrlowast(h prime k prime S emptyP prime hprimex1

empty) where

S(〈lsquokeyrsquo h prime〉) = k prime and S(〈lsquoattrsquo h prime〉) = lsquodecrsquo Therefore

[NewKey(h prime k prime)] isin tracespi(P)

Standard operations

(E S SMSPcup 0 σL) minusrarr (E S SMSP σL)

(E S SMSPcup P|Q σL) minusrarr (E S SMSPcup PQ σL)

(E S SMSPcup P σL) minusrarr (E S SMSPcup P P σL)

(E S SMSPcup νaP σL) minusrarr (Ecup a prime S SMSPcup Pa primea σL)

if a prime is fresh

(E S SMSP σL)K(M)minusrarr (E S SMSP σL) if νEσ ⊢M

(E S SMSPcup out(MN)P σL)K(M)minusrarr (E S SMSPcup P σcup NxL)

if x is fresh and νEσ ⊢M

(E S SMSPcup in(MN)P σL)K(〈MN〉)minusrarr (E S SMSPcup Pτ σL)

if existτ τ is grounding for N

νEσ ⊢MνEσ ⊢ Nτ

(E S SMS P cupout (MN)P

in (MrsquoNrsquo)Qσ L)minusrarr (E S SMSPcup PQτ σL)

if M =E Mprime and existτN =E N

primeτ

and τ grounding for N prime

(E S SMSPcup if M = N

then P else Q σL)minusrarr (E S SMSPcup P σL) if M =E N

then P else Q σL)minusrarr (E S SMSPcup Q σL) if M 6=E N

(E S SMSPcup event(F)P σL) Fminusrarr (E S SMSPcup P σL)

Operations on global state

(E S SMSPcup insert MN P σL) minusrarr (E S[M 7rarr N] SMSPcup P σL)

(E S SMSPcup delete MP σL) minusrarr (E S prime SMSPcup P σL)

where S prime(x) =

S(x) if x 6=E M

perp otherwise

(E S SMSPcup lookup M

as x in P else Q σL)minusrarr (E S SMSPcup PVx σL)

if S(N) =E V is defined and N =E M

as x in P else Q σL)minusrarr (E S SMSPcup Q σL)

if S(N) is undefined for all N =E M

(E S SMSPcup lock M P σL) minusrarr (E S SMSPcup P σLcup M )

if M 6isinEL

(E S SMSPcup unlock M P σL) minusrarr (E S SMSPcup P σL M prime |M prime =E M )

(E S SMSPcup [l minus[a]rarr r] P σL) a prime

minusrarr (E S SMS lfacts(l prime)cup r primePcup Pτ σL)

if existτ l prime a prime r prime

with τ grounding for l minus[a]rarr r

and l prime minus[a prime]rarr r prime isinE (l minus[a]rarr r)τ

and lfacts(l prime) sube SMS pfacts(l prime) sub SMS

Figure 11 Operational semantics

523 Discussion

In the following we will discuss various design decision we havemade and compare our calculus with the StatVerif calculus

5231 Private Channels and Store

The careful reader might have noticed that the applied pi calculus ac-tually offers a way to store a value such that it can be accessed fromwithin a different process If a private channel s is only known to thepart of the process allowed to access the store a fact could be storedby sending it on the channel s and similarly be read by readingfrom s So one might ask why we chose to introduce new constructsfor reading and writing state instead of just providing a sound andcomplete translation for the communication on private channels andreusing existing well-accepted syntax Besides the fact that a valueread from the channel ldquodisappearsrdquo hence every lookup to the storewould need to put the value back on the channel which would becumbersome to write there is another more important reason Com-munication on a private channel is synchronous in our calculus Thismeans that a process sending a message cannot proceed until themessage has been received by a second process A quick look onthe definition of Pnew (see (1) on page 64) should convince the readerthat this is impractical in many cases In general databases consti-tute asynchronous ways of communication and should be modelledas such

On the other hand we decided for synchronous message passing infavour of asynchronous message passing first because synchronousmessage passing is more powerful (Palamidessi showed that the syn-chronous applied pi calculus is strictly more expressive than the asyn-chronous applied pi calculus [77]) and second because by using thesame mechanism as in the popular protocol verifier ProVerif we keepour calculus more accessible for users familiar with this tool

5232 Distributed Databases

There is only one store for the whole protocol It is of course unreal-istic to assume all protocol parties have access to the same databaseTo model an unbounded number of machines each with a distinctstore each database access might be prefixed with an identifier to themachine like in the following template

(ν id insert 〈idx〉 y )

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 prime is the actual protocol

(in(y) insert rsquoAdversaryCellrsquo y)

| (lookup rsquoAdversaryCellrsquo as y in out(y)) | P prime

5233 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(cx) lookup lsquostorersquo as x in P prime

might unexpectedly perform a check if lsquostorersquo contains the messagegiven by the adversary instead of binding the content of lsquostorersquo to xdue to an undetected clash in the naming of variables

5234 Inline multiset rewriting

In addition to the access to the functional store via lookup insert anddelete we support a ldquolow-levelrdquo form of state manipulation in formof the construct [L] minus[A]rarr [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 533) 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

rsquostore1rsquo as x in [] minus[ ]rarr [store2(x)]

5235 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

53 a translation from processes to multiset rewrite rules 71

2 Initial state In contrast to StatVerif we have no special operatorfor state initialisation Values are undefined from the start andcan be initialised during the protocol run The modeller canuse axioms (c f Section 532 in particular the definition ofαinit) to enforce the initialisation of the store before the protocolis executed

3 State cells StatVerifrsquos state cells roughly correspond to keys inthe sense of our functional store While state cells are namesand there is only an arbitrary but a-priori fixed amount of themkeys to the store can be arbitrary terms and there is no a-prioribound on them

4 Locking Both StatVerif and our calculus use locks(binary sema-phores) for process synchronisation The locking mechanism de-scribed in the paper introducing StatVerif [5] can only lock oneglobal resource but the current version of their translation toolhandles the locking of individual cells as well The mechanismin our tool can lock arbitrary terms so similar to the previouspoint we have no a-priori bound on the number of lockable re-sources There is a syntactic restriction in StatVerif that ldquothe partof the process P that occurs before the next unlock if any maynot include parallel replication or lockrdquo which corresponds tothe condition on well-formed processes for our calculus(c f Defi-nition 13) Well-formedness is a requirement for the translationto multiset rewrite rules which means that the same restrictionapplies to our calculus

The L minus[ A]rarr R construct gives the user a way to implementlocking in a different less restricted manner see Section 5334for further discussion

53 a translation from processes

into multiset rewrite rules

In this section we define a translation from a process P into a set ofmultiset rewrite rules JPK and a translation on trace formulas suchthat P |=forall ϕ if and only if JPK |=forall JϕK Note that the result alsoholds for satisfiability as an immediate consequence For a ratherexpressive subset of trace formulas (see [89] for the exact definition ofthe fragment) checking whether JPK |=forall JϕK can then be dischargedto the tamarin prover that we use as a backend

531 Translation of processes

We recall the adversaryrsquos message deduction capabilities from Sec-tion 362 encoded in the following set of rules MD

In order for our translation to be correct we need to make someassumptions on the set of processes we allow These assumptions arehowever as we will see rather mild and most of them without loss ofgenerality First we define a set of variables that will be used in ourtranslation and is therefore reserved

Definition 11 (Reserved variables and facts) The set of reserved vari-ables is defined as the set containing the elements na for any a isin FNlockl for any l

The set of reserved facts Fres is defined as the set containing factsf(t1 tn) where t1 tn isin T and f isin Init Insert Delete IsIn Is-NotSet state Lock Unlock Out Fr In Msg ProtoNonce Eq NotEqEvent InEvent

Similar to [5] we require for our translation that any unlock t in aprocess can be assigned to a lock t preceding it in the processrsquo syntaxtree and that this assignment is injective Moreover given a processlock t P the corresponding unlock in P may not be under a parallel orreplication These conditions allow us to annotate each correspond-ing lock t unlock t pair with a unique label l The annotated version ofa process P is denoted P In case the annotation fails ie P violatesone of the above conditions the process P contains perp The formaldefinition of P is as follows

Definition 12 (Process annotation) Given a ground process P we de-fine the annotated ground process P as follows

P|Q = P|Q

if t1 = t2 then P

else Q= if t1 = t2 then P else Q

lookup M as x

in P else Q= lookup M as x in P else Q

αP = αP

where α isin lock tunlock t t isin T

lock tP = lockl t au(P t l)

where l is a fresh label

unlockl tP = unlockl tP

unlock tP = perp

where au(P t l) annotates the first unlock that has parameter t withthe label l i e

au(P|Q t l) = perp

au(P t l) = perp

au(if t1 = t2 then

P else Q t l)=

if t1 = t2 then au(p t l)

else au(Q t l)

au(lookup M as x

in P else Q t l)=

lookup M as x

in au(p t l) else au(Q t l)

au(αPt l) = α au(P t l) where α 6= unlock t

au(unlock tPt l) = unlockl tP

au(0 t l) = 0

Definition 13 (well-formed) A ground process P is well-formed if

bull no reserved variable nor a reserved fact appear in P

bull any name and variable in P is bound at most once and

bull P does not contain perp

bull For each action (l minus[ a]rarr r) that appears in the process thefollowing holds For each (l prime minus[ a prime]rarr r prime) isinE ginsts(l minus[ a]rarr r)

we have that capr primeprime=Er primenames(r primeprime)cap FN sube capl primeprime=El primenames(l primeprime)cap FN

A trace formula ϕ is well-formed if no reserved variable nor a re-served fact appear in ϕ

The two first restrictions of well-formed processes are not a lossof generality as processes and formulas can be consistently renamedto avoid reserved variables and α-converted to avoid binding namesor variables several times Also note that the second condition isnot necessarily preserved during an execution eg when unfoldinga replication P and P may bind the same names We only requirethis condition to hold on the initial process for our translation to becorrect

The annotation of locks restricts the set of protocols we can trans-late but allows us to obtain better verification results since we canpredict which unlock is ldquosupposedrdquo to close a given lock This addi-tional information is helpful for tamarinrsquos backward reasoning Dur-ing our case studies this restriction never formed an obstacle Wenevertheless discuss how the modeller can overcome this restrictionin Section 5334

The fourth condition is due to condition three in Definition 2 andensures that the embedded multiset rewrite rules cannot create freshnames

Definition 14 Given a well-formed ground process P we define themultiset rewrite system JPK as

MDcup Initcup JP [] []K

bull where the rule Init is defined as

Init [] minus[Init()]rarr [state[]()]

bull JP p xK is defined inductively for process P position p isin Nlowast

and sequence of variables x in Figure 12

bull For a position p of P we define statep to be persistent if P|p =Qfor some process Q otherwise statep is linear

In the definition of JP p xK we intuitively use the family of factsstatep to indicate that the process is currently at position p in itssyntax tree A fact statep will indeed be true in an execution of theserules whenever some instance of Pp (ie the process defined by thesubtree at position p of the syntax tree of P) is in the multiset P ofthe process configuration Note in particular that the translation of Presults in a persistent fact as P always remains in P The translationof the zero-process parallelisation and replication do nothing buthandle statep-facts

The translation of the construct νa translates the name a into a vari-able na as multiset rewrite rules cannot contain fresh names Anyinstantiation of this rule will substitute na by a fresh name which theFr-fact in the premise guarantees to be new This step is annotatedwith a (reserved) action ProtoNonce which is used in the proof ofcorrectness to distinguish adversary and protocol nonces Note that

J0 p xK = [statep(x)]rarr []

JP | Qp xK = [statep(x)]rarr [statepmiddot1(x) statepmiddot2(x)]

cupJP p middot 1 xKcup JQp middot 2 xK

JP p xK = [statep(x)]rarr [statepmiddot1(x)]cup JP p middot 1 xK

JνaP p xK = [statep(x)Fr(na fresh)] minus[ProtoNonce(na fresh)]rarr

[statepmiddot1(x na fresh)]cup JP p middot 1 (x na fresh)K

Jout(MN)P p xK = [statep(x) In(M)] minus[InEvent(M)]rarr [Out(N) statepmiddot1(x)]

[statep(x)]rarr [Msg(MN) statesemip (x)]

[statesemip (x)Ack(MN)]rarr [statepmiddot1(x)]

cup JP p middot 1 xK

Jin(MN)P p xK = [statep(x) In(〈MN〉)] minus[InEvent(〈MN〉)]rarr [statepmiddot1(xcup vars(N))]

[statep(x)Msg(MN)]rarr [statepmiddot1(xcup vars(N))Ack(MN)]

cup JP p middot 1 xcup vars(N)K

Jif M = N then P

else Qp xK

= [statep(x)] minus[Eq(MN)]rarr [statepmiddot1(x)]

[statep(x)] minus[NotEq(MN)]rarr [statepmiddot2(x)]

cup JP p middot 1 xKcup JQp middot 2 xK

Jevent FP p xK = [statep(x)] minus[Event() F]rarr [statepmiddot1(x)]cup JP p middot 1 xK

Jinsert s tP p xK = [statep(x)] minus[Insert(s t)]rarr [statepmiddot1(x)]cup JP p middot 1 xK

Jdelete sP p xK = [statep(x)] minus[Delete(s)]rarr [statepmiddot1(x)]cup JP p middot 1 xK

Jlookup M as v

in P else Qp xK

= [statep(x)] minus[IsIn(Mv)]rarr [statepmiddot1(M v)]

[statep(x)] minus[IsNotSet(M)]rarr [statepmiddot2(x)]

cup JP p middot 1 (x v)Kcup JQp middot 2 xK

Jlockl sP p xK = [Fr(lockl) statep(x)] minus[Lock(lockl s)]rarr [statepmiddot1(x lockl)]

Junlockl sP p xK = [statep(x)] minus[Unlock(lockl s)]rarr [statepmiddot1(x)]cup JP p middot 1 xK

J[l minus[a]rarr r] P p xK = [statep(x) l] minus[Event() a]rarr [r statepmiddot1(xcup vars(l))]

cup JP p middot 1 xcup vars(l)K

Figure 12 Definition of JP p xK

the fact statepmiddot1 in the conclusion carries na so that the followingprotocol steps are bound to the fresh name used to instantiate na

The first rules of the translation of in and out model the communi-cation between the protocol and the adversary and vice versa In thefirst case the adversary has to prove knowledge of the channel andthe message she would like to send in the second case knowledgeof the channel suffices The action InEvent serves a purpose that wewill explain in the next section The other rules model an internalcommunication on a synchronous channel and are a little more com-plicated If the adversary who controls the scheduling decides notto eavesdrop the communication and allow internal communicationto happen he should not be able to interrupt the communication stepand change his mind ndash since the channel is synchronous the sendingprocess can only execute the following step if the message was suc-cessfully transmitted For this reason when the second rule of thetranslation of out is fired the state-fact is substituted by a semi-statefact statesemi Additionally the fact Msg(MN) signals that a messageis present on the synchronous channel This fact is picked up by thesecond rule of the translation of in Only with the resulting acknowl-edgement fact Ack(MN) it is possible to advance the execution of thesending process using the third role in the translation of out whichtransforms the semi-state and the acknowledgement of receipt intostatepmiddot1( ) Only now the next step in the execution of the sendingprocess can be executed

Some of the labels are used to restrict the set of executions that wewill consider For instance the label Eq(MN) will be used to indicatethat we only consider executions in which M =E N This is also thecase for event insert delete lookup lock and unlock As we will seethese restrictions will be encoded in the trace formula Finally theconstruct for embedded multiset rewrite rules is translated by addingthe previous state-fact to the left-hand side and the next one to theright-hand side

Example 17 JPnewK gives the following set of rules

[] minus[Init()]rarr [state[]()]

[state[]()] minus[ ]rarr [state1()]

[state1()Fr(h)] minus[ ]rarr [state11(h)]

[state11(h)Fr(k)] minus[ ]rarr [state111(k h)]

[state111(k h)] minus[Event()NewKey(h k)]rarr [state1111(k h)]

[state1111(k h)] minus[Insert(〈rsquokeyrsquo h〉 k)]rarr [state11111(k h)]

[state11111(k h)] minus[Insert(〈rsquoattrsquo h〉 rsquodecrsquo)]rarr

[state111111(k h)]

[state111111(k h)] minus[ ]rarr [Out(h) state1111111(k h)]

An example trace is presented in Figure 13 Every box in this pic-ture stands for the application of a multiset rewrite rule where the

premises are at the top the conclusions at the bottom and the actionin middle if there are any Every premise needs to have a matchingconclusion which is visualized by the arrows otherwise the graphwould not depict a valid MSR execution (This is a simplification of thedependency graph representation tamarin uses to perform backward-induction [89 90])

state_0111111( k h )

Out( h ) state_01111111( k h )

state_011111( k h )

Insert( ltatt hgt dec )

state_0111111( k h )

state_01111( k h )

Insert( ltkey hgt 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 )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

state_0111( k h )

Figure 13 Example trace for translation of Pnew

532 Translation of trace formulas

We can now define the translation for formulas

Definition 15 Given a well-formed trace formula ϕ we define

JϕKforall = αrArr ϕ and JϕKexist = αandϕ

where α = αinit andαeq andαnoteq andαin andαnotin andαlock andαinEv and

αinit =forallx y i jInit()iand Init()j =rArr i = j

αeq =forallx y iEq(x y)i =rArr x asymp y

αnoteq =forallx y iNotEq(x y)i =rArr not(x asymp y)

αin =forallx y t3IsIn(x y)t3 =rArr

existt2Insert(x y)t2 and t2 ⋖ t3and (forallt1Delete(x)t1 rArr t1 ⋖ t2 or t3 ⋖ t1)

and (forallt1 yInsert(x y)t1 =rArr t1 ⋖ t2 or t3 ⋖ t1))

αnotin =forallx y t3IsNotSet(x)t3 =rArr

(forallt1 yInsert(x y)t1 =rArr t3 ⋖ t1)

or existt1Delete(x)t1 and t1 ⋖ t3and forallt2 yInsert(x y)t2 and t2 ⋖ t3 =rArr t2 ⋖ t1

αlock =forallx l lprime i jLock(l x)iand Lock(l prime x)jand i⋖ j

rArr existkUnlock(l x)kand i⋖ kand k⋖ jand

(foralll primemLock(l prime x)mrArr not(i⋖mandm⋖ k))

and (foralll primemUnlock(l prime x)mrArr not(i⋖mandm⋖ k))

αinEv =forallt iInEvent(t)irArr existjK(t)jand

(forallkEvent()krArr (k⋖ jor i⋖ k))and

(forallk t primeK(t prime)krArr (k⋖ jor i⋖ kor k asymp j))

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

bull αinit ensures that the init rule is only fired once

bull αeq and αnoteq ensure that we only consider traces where all(dis)equalities hold

bull α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

bull α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

bull α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 MDInand 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 forall JϕKforall iff Tr 6exist JnotϕKexist

533 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 rulesThen we will give some insight into why the state manipulation and

locking constructs are modelled the way they are Finally we discussthe axioms we have chosen and the well-formedness conditions weimpose on the locks

5331 The need for such a translation

Obviously any protocol that we are able to analyze can be directlyanalyzed by the tamarin prover [89 90] as we use it as a backendIndeed tamarin has already been used for analyzing a model ofthe Yubikey device in Chapter 4 the case studies presented withMoumldersheimrsquos abstraction as well as those presented with StatVerifIt is furthermore able to reproduce the aforementioned results onPKCS11 [36] and the TPM [35] ndash moreover it does so without bound-ing the number of keys security devices reboots etc

An important disadvantage is that the representation of protocolsas multiset rewrite rules is very low level and far away from actualprotocol implementations making it very difficult to model a proto-col correctly Our calculus is semantically richer in particular it givesinformation on which part of the protocol runs on which party andwhich kind of requests are treated in which thread respectively Thiskind of information is fundamental in the development of protocolsas well as in the implementation of protocols starting from a proto-col description There has been work on the automated translationfrom protocol descriptions in the spi calculus (another variant of theapplied pi calculus) into Java programs [79 80] an approach that ap-pears to be adaptable to our calculus but not to multiset rewritingThis supports the claim that our calculus contains enough informa-tion to serve as a template for an implementation For protocols thatare first designed then analysed for security and later implementedon the basis of the analysed model this translation from a model to animplementation needs to be performed whether it is done automati-cally or by hand One way or another it should be as straight-forwardas possible

For the other direction where a protocol description exists in oneform or another possibly in form of an implementation and is tobe modelled with the aim of analysing its security we face similarproblems Encoding private channels nested replications and lockingmechanisms directly as multiset rewrite rules is a tricky and error-prone task During our experiments with tamarin we noticed thatin particular the last point is often swept under the rug Protocolsteps typically consist of a single input followed by several databaselookups and finally an output In MSR they are usually modelled asa single rule and therefore effectively atomic Real implementationsare different from that Several entities might be involved databaselookups could be slow etc In this case such models could obscureeventual issues in concurrent protocol steps that would otherwiserequire e g explicit locking Ignoring the fact that protocol steps

are not atomic in the model increases the risk of implicitly excludingattacks in the model that are well possible in a real implementatione g race conditions In the following we will try to illustrate thatthe question of where to put locks is a) difficult to answer and b) amatter of security Recall the running example Example 14 on page 7Using our translation and the tamarin-prover we are able to showkey-secrecy for this example i e tracespi(Pex)

forall φ for

φ = not(existh k msg i j temp NewKey(h k)iand K(k)j)

(See Listing 21 for the full model including the necessary typinglemma) Let us change the example so it implements a slightly dif-ferent policy The initial attribute to a key is ldquoinitrdquo instead of ldquodecrdquoand there are two processes similar to Pset one which allow the at-tribute to be changed from ldquoinitrdquo to ldquodecrdquo and one which allows theattribute to be changed from ldquoinitrdquo to ldquoencrdquo

P primeex =P prime

new |Psetminusw |Psetminusd |Pdec |Pwrap

P primenew = ν h ν k event NewKey(hk)

insert ltlsquokeyrsquohgtk insert ltlsquoattrsquohgtlsquonewrsquo out(h)

Psetminusd = in(h) lookup ltrsquoattrsquohgt as a in

if a=rsquoinitrsquo then insert ltrsquoattrsquohgt rsquodecrsquo

Psetminusw = in(h) lookup ltrsquoattrsquohgt as a in

if a=rsquoinitrsquo then insert ltrsquoattrsquohgt rsquowraprsquo

Pdec and Pwrap are defined as before It may come as a surprise that P primeex

allows for an attack i e tracespi(P primeex) 6

forall φ even though Example 14as well as this altered variant seem to implement similar policies Wewill only sketch this attack which is a variation of the attack de-scribed in Example 1 and can be found using our translation Firstthe attacker executes P prime

new to create a key with a handle h Then sheexecutes Psetminusd with handle h until just before the insert commandShe will continue this execution in a moment but first she executesPsetminusw with h so that 〈 primeatt prime h〉 points to primewrap prime in the store Thisallows her to obtain senc(k k) by calling Pwrap with 〈h h〉 Now bycontinuing the previous execution of Psetminusd she can alter the store sothat 〈 primeatt prime h〉 points to primedec prime Hence she is allowed to run Pdec on〈h senc(k k) which reveals k

This attack can be mitigated by enclosing everything behind in(h)

in the processes Psetminusw and Psetminusd between lock h and unlock h Thisshows that for the analysis of security APIs state synchronisationis an essential part of the modelling and it is far from trivial to seewhen locking is needed (e g in P prime

ex) and when it is not (e g Pex) Amodelling that is too coarse to capture such attacks (for example due

the ldquoimplicitrdquo global lock during a multiset rewriting step) should beviewed critically as it could give a false sense of security

The modelling of the Yubikey in the form of multiset rewrite rulesin Chapter 4 as well as in our calculus (in the following Section 55)confirms that our translation is needed to derive the better model i ethe model including the necessary locking etc The translation of theprotocol from our calculus produces a total of 49 rules (as opposed tothe four rules in the manual encoding) While in this case the securityresults could be confirmed (given that the locks were put in the rightplaces) this may not always be the case Instead of expecting theprotocol modeller to describe the protocol in such tedious detail wesuggest a tool that performs this task while preserving the soundnessand completeness present in the tamarin-prover

5332 Modelling the store using actions instead of facts

The store is presently modelled in the form of Insert and Delete eventsthat appear in the trace Since in multiset rewriting the state of aprotocol is the multiset of facts at a given point in time the readermight ask why the store is not translated to facts for instance insert

xy could result in a fact Store(x y) We faced the following problemStore needs to be a linear fact since we want to be able to remove itat some point A rule in the translation of some part of the protocolthat performs a lookup to this value will need to contain Store(x y)

on the left-hand side (so the database lookup is performed) as wellas on the right-hand side (so it is not removed afterwards) Such atranslation does not interact well with tamarinrsquos constraint solvingalgorithm Without going too much into the details of how tamarinrsquosconstraint solving algorithm works we will sketch the parts relevantfor this argument Tamarin translates the negation of the securityproperty into a constraint system which it then tries to solve i e ittries to find a counter-example

It refines this constraint system until it is either solved (and thesecurity property invalidated) or until all possible cases of the refine-ment are contradictory Trace formulas resulting from the negatedsecurity property as well as from previously established lemmas arepart of the constraint system as well as graph constraints They de-scribe protocol traces in a way similar to Figure 13 A node describesan instantiation of a multiset rewrite rule including its premises ac-tions and conclusions An edge may connect the conclusion of an in-stantiated multiset rewriting rule with a matching premise in anotherinstantiation of a possibly different multiset rewriting rule (There areother kinds of edges which are relevant for message deduction butunimportant for this argument) The algorithm performs backwardsearch The negation of the security property typically postulates theexistence of one or two actions in the trace (see for example φ inthe previous paragraph) This will be refined into a graph constraint

consisting of a node that corresponds to an instance of a multisetrewriting rule that carries this action Often this node will have openpremises which will result in a case distinction over multiset rewriterules that can be instantiated to have a matching conclusion Thosenodes may haven open premises themselves which may result in an-other case distinction etc

Now back to the example Whenever there is an open premise fora fact Store(x y) there is a case distinction over all multiset rewrit-ing rules that have Store as a conclusion including the rule resultingfrom a translation of a lookup But this rule has Store in the conclu-sion as well as in the premise which is provokes a loop in tamarinrsquosbackward search Our modelling using the actions allows us to estab-lish a connection between a lookup and the (uniquely defined) insertthat this value in the store originated from i e an insert with cor-responding key and value which has neither been overwritten nordeleted until the lookup This is precisely what we encode in the ax-iom αinndash we have not found a way to express this using only multisetrewrite rules

We think that it is possible to avoid the loop mentioned above de-spite using linear facts as a store but it would require extendingtamarinrsquos constraint solving algorithm There could be a syntactic el-ement to mark linear facts that shall only be verified but not removedby a multiset rewriting rule This could be reflected in a graph nodethat has Store as a read-only premise but not as part of the conclusionRead-only premises would need to be connected to a matching con-clusion but a conclusion of this linear fact can be connected to morethan one read-only premise in the graph As a side condition anypremise that may consume the fact i e any not-read-only premisemust appear either before the node with the Store in a conclusion orafter the last node with Store in a read-only premise Adding this ex-tension to the constraint solving algorithm and comparing this mod-elling of state with our current modelling appears to be an interestingline of future research

5333 Axioms

The axioms in the translation of the formula are designed to workhand in hand with the translation of the process into rules They ex-press the correctness of traces with respect to our calculusrsquo semanticsbut are also meant to guide tamarinrsquos constraint solving algorithmIn the following we will discuss how the axioms achieve those goalsThe axiom αinit assures that the initial rule which is the only ruleannotated with the action Init() appears once in a trace Unless thetop-level construct of the process is a replication state[]() is a linearfact and can hence only be consumed once The axioms αeq and αnoteq

are straight-forward On the other hand αin and αnotin illustrate whatkind of axioms work well In the case of αin when a node with the ac-

tion IsIn is created (by definition of the translation this corresponds toa lookup command) the existential translates into a graph constraintthat postulates an insert node for the value fetched by the lookupand two formulas that assure that a) this insert node appears beforethe lookup b) this insert node is uniquely defined that is it is thelast insert to the corresponding key Further c) there is not delete inbetween Due to this side conditions αnotin only adds one Insert nodeper IsIn node ndash the case where an axiom postulates a node whichitself allows for postulating yet another node needs to be avoided astamarin runs into loops otherwise

Similarly αnotin produces two cases if it can be applied due to theexistence of an IsNotSet node The first one is coupled with a verystrong condition namely that no previous insert to this key existsThis case can usually be refuted quickly In the second case it mustbe assumed that a Delete node exists but that there is no subsequentInsert In the majority of our case studies the second case was refutedimmediately since no delete command appeared during the processThus we were left with a very strong assumption (no insert prior tothe lookup) which often led to quick termination

A naiumlve way of implementing locks using an axiom would be thefollowing (to simplify the presentation we will assume there to bejust one global lock)

Every lock happens either after an unlock and there isneither a lock nor an unlock in between or it is the firstlock so there is no previous lock and no unlock at all

This axiom would guide tamarin in the following way If a lock ispostulated a case distinction is made In the first case an unlockis postulated and a constraint stored which says that there are nolocks and unlocks between the two Then tamarin tries to resolve themissing premises in particular the state-facts which will eventuallylead to another lock since the well-formedness condition imposesevery unlock be preceded (in the sense of the depth in the processtree) by a lock The axiom applies again etc ad infinitum

The axiom αlock avoids this caveat first and foremost because it onlyapplies to pairs of locks We will outline how αlock is applied duringthe constraint solving procedure

1 If there are two locks for the same term and with possibly dif-ferent annotations an unlock for the first of those locks is pos-tulated more precisely an unlock with the same term the sameannotation and no lock or unlock for the same term in-betweenThe axiom itself contains only one case so the only case distinc-tion that takes place is over which rule produces the matchingUnlock-action However due to the annotation all but one arerefuted immediately in the next step Note further that αlock

postulates only a single node namely the node with the actionUnlock

2 Due to the annotation the fact statep( ) contains the freshname that instantiates the annotation variable Let a fresh bethis fresh name Every fact statep prime( ) for some position p prime thatis a prefix of p and a suffix of the position of the correspondinglock contains this fresh name Furthermore every rule instan-tiation that is an ancestor of a node in the dependency graphcorresponds to the execution of a command that is an ancestorin the process tree Therefore the backward search eventuallyreaches the matching lock including the annotation which isdetermined to be a and hence appears in the Fr-premise

3 Because of the Fr-premise any existing subgraph that alreadycontains the first of the two original locks would be mergedwith the subgraph resulting from the backwards search that wedescribed in the previous step as otherwise Fr(a) would beadded at two different points in the execution

4 The result is a sequence of nodes from the first lock to the corre-sponding unlock and graph constraints restricting the secondlock to not take place between the first lock and the unlock Wenote that the axiom αlock is only instantiated once per pair oflocks since it requires that i⋖ j thereby fixing their order

In summary the annotation helps distinguishing which unlock isexpected between to locks vastly improving the speed of the back-ward search This optimisation however required us to put restric-tions on the locks which are the subject of the next section

5334 Restrictions on lockunlock

The annotation of locks restricts the set of protocols we can trans-late but allows us to obtain better verification results since we canpredict which unlock is ldquosupposedrdquo to close a given lock This addi-tional information is helpful for tamarinrsquos backward reasoning Wethink that our locking mechanism captures all practical use cases forlocking However since our calculus supports inline multiset rewriterules the user is free to implement locks herself eg as follows

[NotLocked()]rarr [] code []rarr [NotLocked()]

Note that in this case the user does not benefit from the optimisationwe put into the translation of locks

Obviously locks can be modelled in both tamarinrsquos multiset rewrit-ing calculus in tamarin (this is actually what the translation does) andMoumldersheimrsquos set rewriting calculus [74] Hence there are no restric-tions on where locks appear however they must be implement byhand for example using a predicat as above Therefore there are norestrictions but no optimisations either To the best of our knowledgeStatVerif is the only comparable tool that models locks explicitly As

54 correctness of the translation 85

pointed out in Section 523 the restriction in StatVerif are strictlystronger than in our calculus

5335 Well-formedness of translation

The third condition of Definition 2 does not hold for the translation ofthe lookup operator In order to be able to use tamarin as a back-endwe need to show that under this specific conditions the solution pro-cedure is still correct This is formally proven in Appendix B1 Theidea is the following A modified translation JmiddotKD which is definedlike the current translation but adds a dummy-fact the conclusionwhen translating an insert as well as to the premises of a lookup pro-duces exactly the same set of traces that are correct with respect to theaxioms We use this fact to prove that if tamarinrsquos constraint solvingalgorithm would miss a trace for the original not well-formed trans-lation it would miss a trace for the dummy-translation too whichwould contradict tamarinrsquos correctness as proven by Schmidt Meieret al [89 88 69]

54 correctness of the translation

In this chapter we will show the correctness of our translation statedby the following theorem

Theorem 1 Given a well-formed ground process P and a well-formedtrace formula ϕ we have that

tracespi(P) ⋆ ϕ iff tracesmsr(JPK) ⋆ JϕK⋆

where ⋆ is either forall or exist

We will first give an overview of the main propositions and lemmasneeded to prove Theorem 1 We first introduce two functions ontraces The first one filter removes all traces that do not satisfy thetrace formula α i e our axioms from page 77 The second one hideremoves all reserved actions from each trace in the set We will showthat the set of traces in tracespi(P) is equal to the set of traces thatresult from the translation tracesmsr(JPK) after filter and hide have beenapplied It is not the case that tracespi(P) equals tracesmsr(JPK) as wewill see in the following

Example 18 Consider the process

P = if rsquoapplersquo=rsquoorangersquo then event A() else 0

There is no trace containing A() in tracespi(P) as the semantics of ourcalculus cannot reduce this process to its then branch However there

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

JPK = [] minus[]rarr state[]()

state[]() minus[Eq(rsquoapplersquo rsquoorangersquo)]rarr state1()

state1() minus[Event() A()]rarr state11()

state11() minus[]rarr []

[] minus[NotEq(rsquoapplersquo rsquoorangersquo]rarr state2()

There is indeed a trace that contains A() for example the trace[

Eq(rsquoapplersquo rsquoorangersquo) Event() A() ]

However this trace does not satisfy the axiom αeq which means thatit is not important for the verification of translated security propertiesas 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 isin Tr | forallθ(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 ⋆ = forall We start byshowing that Tr forall JϕK implies filter(Tr) ϕ

Tr forall JϕKforall rArr filter(Tr) forall JϕKforall (since filter(Tr) sube Tr)

hArr filter(Tr) forall αrArr ϕ (by definition of JϕKforall)

hArr filter(Tr) forall ϕ (since filter(Tr) forall α)

We next show that filter(Tr) forall ϕ implies Tr forall JϕKforall

filter(Tr) forall ϕrArr filter(Tr) forall αandϕ (since filter(Tr) forall α)

hArr Tr forall notαor (αandϕ)

(since filter(Tr) sube Tr and (Tr filter(Tr)) 6forall α)

hArr Tr forall αrArr ϕ

hArr Tr forall JϕKforall (by definition of JϕKforall)

The case of ⋆ = exist now easily follows

Tr exist JϕKexist iff Tr 6forall JnotϕKforall iff filter(Tr) 6forall notϕ iff filter(Tr) exist ϕ

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(rsquoapplersquo rsquoorangersquo)] is such a case(NotEq isin Fres) although it satisfies the axioms α including αnoteq andhence belongs to filter(tracesmsr(JPK)) We need to ldquohiderdquo all thoseactions that are reserved in order to have equivalent sets of tracesSince reserved actions do not appear in well-formed trace formulasit 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 middot tr) =

hide(tr) if F sube Fres

(F Fres) middot hide(tr) otherwise

Given a set of traces Tr we define hide(Tr) = hide(t) | t isin Tr

As expected well-formed formulas that do not contain reservedfacts 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) ⋆ ϕ

Proof We start with the case ⋆ = exist and show the stronger statementthat for a trace tr

forallθexistθ prime if (tr θ) ϕ then (hide(tr) θ prime) ϕ

andforallθexistθ prime if (hide(tr) θ) ϕ then (tr θ prime) ϕ

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 θ prime = θ

If |tr| = n we define tr and F such that tr = tr middot F By inductionhypothesis we have that

forallθexistθprime if (tr θ) ϕ then (hide(tr) θ

prime) ϕ

andforallθexistθ

prime if (hide(tr) θ) ϕ then (tr θ

prime) ϕ

We proceed by structural induction on ϕ

bull ϕ = perp ϕ = i⋖ j ϕ = i= j or t1 asymp t2 In these cases we trivially

conclude as the truth value of these formulas does not dependon the trace and for both statements we simply let θ prime = θ

bull ϕ = fi We start with the first statement Suppose that (tr θ) fi If θ(i) lt n then we have also that tr θ fi By inductionhypothesis there exists θ

primesuch that (tr θ

prime) fi Hence we

also have that (tr θprime) fi and letting θ prime = θ

primeallows us to

conclude If θ(i) = n we know that f isin trn As ϕ is well-formed f 6isin Fres and hence f isin hide(tr)n prime where n prime = |hide(tr)|The proof of the other statement is similar

bull ϕ = notϕ prime ϕ = ϕ1 andϕ2 or ϕ = existx sϕ prime We directly concludeby induction hypotheses (on the structure of ϕ)

From the above statements we easily have that Tr exist ϕ iff hide(Tr) exist

ϕThe case of ⋆ = forall now easily follows

Tr forall ϕ iff Tr 6exist notϕ iff hide(Tr) 6exist notϕ iff hide(Tr) forall ϕ

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 birdrsquos-eye view

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

Proof of Theorem 1

tracespi(P) ⋆ ϕ

hArrhide(filter(tracesmsr(JPK))) ⋆ ϕ (by Lemma 1)

hArrfilter(tracesmsr(JPK)) ⋆ ϕ (by Proposition 2)

hArrtracesmsr(JPK) ⋆ JϕK⋆

(by Proposition 1)

In the following subsections we will show that Lemma 1 holds byshowing inclusion of tracespi(R) in hide(filter(tracesmsr(JPK))) (Lemma 3

in Section 542) and by showing the reverse inclusion (Lemma 4 andLemma 5 in Section 543) But before we are able to show this weneed to establish a lemma about message deduction and fresh valuesThis is the purpose of the next subsection

541 Lemmas about message deduction

The following lemma relates the message deduction in our calculus tothe message deduction in multiset rewriting using the rules MDOut

MDPubMDFreshMDApplFresh It will be useful for both direc-tions of the proof of Lemma 1 i e for Lemma 3 and Lemma 5

First every message m such that K(m) is part of the current statecan be derived from the terms that appear in Out facts Second if amessage can be derived in our calculus there is a chain of applicationusing the above mentioned rules such that K(m) is part of the state

Lemma 2 Let P be a ground process and emptyF1minusrarr S1

F2minusrarr Fnminusrarr Sn isin

filter(execmsr(JPK)) Let

t1 tm = t | Out(t) isin16j6n Sj

σ = t1x1 tm xm and

n = a fresh | ProtoNonce(a) isinE⋃

We have that

1 if K(t) isin Sn then νnσ ⊢ t

2 if νnσ ⊢ t then there exists S such that

bull emptyF1minusrarr S1

F2minusrarr Fnminusrarr Snminusrarr

lowastS isin filter(execmsrE (JPK))

bull K(t) isinE S and

bull Sn rarrlowastR S for R = MDOutMDPubMDFreshMDAppl

To prove this lemma we show the first statement by induction onthe number of steps in the execution For every rule producing aK-fact one can show that a corresponding deduction rule (see Defi-nition 9) can be used to derive this term For the second statementwe perform induction over the deduction tree witnessing νnσ ⊢ twhich we use to construct a sequence of multiset rewriting steps pro-ducing K(t) See Appendix B for the full proof including the helpinglemmas 13 and 14

542 Inclusion I

To state the next lemma describing the inclusion of tracespi(P) inhide(filter(tracesmsr(JPK))) we need two additional definitions The first

one formally defines which set of rules results from the translation ofa particular position in the process tree Note that the rules in Fig-ure 14 are the same as in Figure 12

Definition 18 Let P be a well-formed ground process and pt a posi-tion in P We define the set of multiset rewrite rules generated forposition pt of P denoted JPK=pt

as follows

JPK=pt= JP [] []K=pt

where Jmiddot middot middotK=ptis defined in Figure 14

The next definition will be useful to state that for a process P everyfact of the form statep(t) in a multiset rewrite execution of JPK corre-sponds to an active process in the execution of P which is an instanceof the subprocess P|p

Definition 19 Let P be a ground process P be a multiset of pro-cesses and S a multiset of multiset rewrite rules We write P harrP S

if there exists a bijection between P and the multiset statep(t) |

existp t statep(t) isin S such that whenever Q isin P is mapped to

statep(t) isin S we have that

1 P|pτ = Qρ for some substitution τ and some bijective renamingρ of fresh but not bound names in Q and

2 existri isinE ginsts(JPK=p) statep(t) isin prems(ri)

When P harrP S Q isin P and statep(t) isin S we also write Q harrP

statep(t) if this bijection maps Q to statep(t)We are now ready to formulate an invariant that implies the in-

clusion of traces generated using the semantics of our calculus in thefragment of multiset rewriting traces of the translation of process thatfulfills the axioms We show that this invariant holds for every cor-responding pair of a state in our calculus and a state of the multisetrewriting execution The correspondence is defined by the function f

Lemma 3 Let P be a well-formed ground process and

(E0 S0 SMS0 P0 σ0L0)

E1minusrarr (E1 S1 SMS1 P1 σ1L1)

E2minusrarr

Enminusrarr (En Sn S

MSn Pn σnLn)

where (E0 S0 SMS0 P0 σ0L0) = (empty empty empty P empty empty) Then there are

(F1 S1) (Fn prime Sn prime) such that

emptyF1minusrarrJPK S1

F2minusrarrJPK Fn primeminusrarrJPK Sn prime isin execmsr(JPK)

and there exists a monotonic strictly increasing function f Nn rarr

Nn prime such that f(n) = n prime and for all i isinNn

1 Ei = a | ProtoNonce(a) isin⋃

16j6f(i) Fj

J0 p xK=pt= [statep(x)]rarr []

JP | Qp xK=pt= [statep(x)]rarr [statepmiddot1(x) statepmiddot2(x)]

cupJP p middot 1 xK=ptcup JQp middot 2 xK=pt

JP p xK=pt= [statep(x)]rarr [statepmiddot1(x)]

p=ptcup JP p middot 1 xK=pt

JνaP p xK=pt= [statep(x)Fr(na fresh)] minus[ProtoNonce(na fresh)]rarr

[statepmiddot1(x na fresh)] p

=ptcup JP p middot 1 (x na fresh)K=pt

Jout(MN)P p xK=pt= [statep(x) In(M)] minus[InEvent(M)]rarr [Out(N) statepmiddot1(x)]

cup JP p middot 1 xK=pt

Jin(MN)P p xK=pt= [statep(x) In(〈MN〉)] minus[InEvent(〈MN〉)]rarr [statepmiddot1(xcup vars(N))]

[statep(x)Msg(MN)]rarr [statepmiddot1(xcup vars(N))Ack(MN)] p

cup JP p middot 1 xcup vars(N)K=pt

Jif M = N then P

else Qp xK=pt

[statep(x)] minus[NotEq(MN)]rarr [statepmiddot2(x)] p

cup JP p middot 1 xK=ptcup JQp middot 2 xK=pt

Jevent FP p xK=pt= [statep(x)] minus[Event() F]rarr [statepmiddot1(x)]

Jinsert s tP p xK=pt= [statep(x)] minus[Insert(s t)]rarr [statepmiddot1(x)]

Jdelete sP p xK=pt= [statep(x)] minus[Delete(s)]rarr [statepmiddot1(x)]

Jlookup M as v

in P else Qp xK=pt

[statep(x)] minus[IsNotSet(M)]rarr [statepmiddot2(x)] p

cup JP p middot 1 (x v)K=ptcup JQp middot 2 xK=pt

Jlockl sP p xK=pt= [Fr(lockl) statep(x)] minus[Lock(lockl s)]rarr [statepmiddot1(x lockl)]

Junlockl sP p xK=pt= [statep(x)] minus[Unlock(lockl s)]rarr [statepmiddot1(x)]

J[l minus[a]rarr r] P p xK=pt= [statep(x) l] minus[Event() a]rarr [r statepmiddot1(xcup vars(l))]

= middot if a = b and empty other-wise

2 forallt isinM Si(t) =

u if existj 6 f(i)Insert(t u) isin Fj

andforallj prime u prime

j lt j prime 6 f(i)rArr Insert(t u prime) 6isinE Fj prime

andDelete(t) 6isinE Fj prime

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

5 xσi | x isin D(σi) = Out(t) isin cupk6f(i)Sk

6 Li =E t | existj 6 f(i) u Lock(u t) isinE Fj and forallj lt k 6 f(i)Unlock(u t) 6isinE Fk

7 [F1 Fn prime ] α where α is defined as in Definition 15

8 existk f(iminus 1) lt k 6 f(i) and Ei = Fk and cupf(iminus1)ltj 6=k6f(i) Fj sube

The first condition expresses that the set of restricted values of theprocess is the set of nonces that the translation of ν has produced Thesecond condition expresses that the store corresponds to the Insert

and Delete-actions in the translation The third condition expressesthat every non-reserved fact in the state of the translation is a factin the secondary store of the calculus The fourth condition makessure that the set of current processes and the state-facts in the transla-tion correspond correspond according to Definition 19 i e for everystate fact that is in the premise of some ground instance of a multisetrewrite rule there is a substitution and a bijective renaming of freshbut unbound names that relates this rule instance to a running pro-cess The fifth condition states that the frame corresponds to the setof terms that have appeared in Out-facts during the protocol execu-tion The sixth condition expresses that the set of locks corresponds tothe Lock and Unlock-actions in the translation The seventh conditionmakes sure that the resulting trace respects the axioms α Finally theeighth condition expresses that the actions between two correspond-ing traces are the same except for reserved actions

The proof of this lemma is an induction over the number of tran-sitions following a case distinction over all transitions possible inthe semantics of our calculus In the majority of cases only a fewconditions have to be proven while the others follow directly fromthe induction hypothesis In particular the cases for insert deletelookup lock and unlock are difficult since the induction hypothesisexpresses a semantical interpretation of the actions in the trace whilethe axioms αin αnotin and αlock are formulated with the goal of fa-cilitating analysis using tamarin This semantical correctness of the

axioms and the annotation procedure are therefore part of those casesin the proof The complete proof can be found in Section B21 in theAppendix

543 Inclusion II

To simplify the proof for the opposite inclusion we first define anormal form of a multiset rewriting execution with respect to ourtranslation see Definition 33 on page 220 in Section B22 A nor-mal execution e g removes semi-states as soon as possible keepsthe rules corresponding to an internal communication together andproduces In-facts as late as possible

We can show that we can bring every execution into this formwhich allows us to only reason about ldquonormalizedrdquo executions in theproof of Lemma 5

Lemma 4 (Normalisation) Let P be a well-formed ground process If

S0 = emptyE1minusrarrJPK S1

E2minusrarrJPK EnminusrarrJPK Sn isin execmsr(JPK)

and [E1 En] α then there exists a normal MSR execution

T0 = emptyF1minusrarrJPK T1

F2minusrarrJPK Fn primeminusrarrJPK Tn prime isin execmsr(JPK)

such that hide([E1 En]) = hide(F1 Fn prime) and [F1 Fn prime ] α

This lemma is proven in Section B22 Like in the previous sectionwe first define what it means when a set of processes and a multisetcorrespond to each other

Definition 20 Let P be a ground process P be a multiset of pro-cesses and S a multiset of multiset rewrite rules We write P P S

statep(t) isin S then

1 statep(t) isinE prems(R) for R isin ginsts(JPK=p)

2 Let θ be a grounding substitution for state(x) isin prems(JPK=p)

such that t = xθ Then

(P|pτ)ρ =E Q

for a substitution τ and a bijective renaming ρ of fresh but notbound names in Q defined as follows

τ(x) =θ(x) if x not a reserved variable

ρ(a) =a prime if θ(na) = aprime

When P P S Q isin P and statep(t) isin S we also write Q P

statep(t) if this bijection maps Q to statep(t) Lemma 5 is similar toLemma 3 and is proven by induction over the number of transitionssee Section B22 in the Appendix

Lemma 5 Le P be a well-formed ground process If

is normal and [E1 En] α (see Definition 33 and 15) then thereare (E0 S0 S

MS0 P0 σ0L0) (En prime Sn prime SMS

n prime Pn prime σn prime Ln prime) and F1

Fn prime such that

F1minusrarr (E1 S1 SMS1 P1 σ1L1)

F2minusrarr Fn primeminusrarr (En prime Sn prime SMS

n prime Pn prime σn prime Ln prime)

where (E0 S0 SMS0 P0 σ0L0) = (empty empty empty P empty empty) and there exists a

monotonically increasing surjective function f Nn 0 rarrNn prime suchthat f(n) = n prime and for all i isinNn

1 Ef(i) = a isin FN | ProtoNonce(a) isinE⋃

16j6i Ej

2 forall t isinM Sf(i)(t) =

u if existj 6 iInsert(t u) isinE Ej

j lt j prime 6 irArr Insert(t u prime) 6isinE Ej prime

andDelete(t) 6isinE Ej prime

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

5 xσf(i) | x isin D(σf(i)) =E Out(t) isin cupk6iSk

6 Lf(i) =E t | exist j 6 i u Lock(u t) isinE Ej and forall j lt k 6 iUnlock(u t) 6isinE Ek

Furthermore

7 hide([E1 En]) =E [F1 Fprimen]

Lemma 1 follows now from Lemma 3 Lemma 4 and Lemma 5

55 case studies

This section gives an overview of the case studies we performed in-cluding a simple security API similar to PKCS11 [81] the Yubikeysecurity token (see Chapter 4) the optimistic contract signing proto-col by Garay Jakobsson and MacKenzie (GJM) [46] the left-right en-cryption example discussed by Arapinis et al [5] and the key-serverexample discussed by Moumldersheim [74] The results are summarizedin Table 1 For each of the case studies we also provide the number oftyping lemmas that were needed by the tamarin prover and whethermanual guidance of the tool was required

55 case studies 95

example lemmas manual

Security API agrave la PKCS11 1 no

Yubikey Protocol [60 93] 3 yes

GJM Contract-Signing protocol [5 46] 0 no

Moumldersheimrsquos Example (lockinsert) [74] 0 yeslowast

Moumldersheimrsquos Example (emb MSRs) [74] 0 no

Security Device Example [5] 1 no

Needham-Schroeder-Lowe [66] 1 no

lowast only a small amount of guidance was necessary (7 mouse clicks)

Table 1 Case studies

551 Security API agrave la PKCS11

This example illustrates how our modelling might be useful for theanalysis of security APIs in the style of the PKCS11 standard [81] Weexpect studying a complete model of PKCS11 such as in [36] to bea straightforward extension of our running example in Section 52The actual case study models two additional operations First givena handle and a plaintext the user can request an encryption underthe key the handle points to Second given an encryption of somevalue k2 under a key k1 and a handle h1 pointing to k1 the user canrequest the encryption to be unwrapped which means it is decryptedunder k1 The result is stored on the device and she receives a handleh2 pointing to k2 Furthermore new keys are assigned an initialattribute from which they can move to either lsquowraprsquo or lsquounwraprsquosee the following snippet

in(lt lsquo set_dec rsquohgt) lock lt rsquo att rsquohgtlookup lt rsquo att rsquohgt as a in

if a= rsquo in i t rsquo then

insert lt rsquo att rsquohgt rsquodec rsquo unlock lt rsquo att rsquohgt

Note that in contrast to the running example of the previous sectionsin this modelling it is necessary to encapsulate the state changes be-tween lock and unlock as otherwise an adversary could stop theexecution after line 3 set the attribute to lsquowraprsquo in another subpro-cess and therefore be able to produce a wrapping which he can afterresuming operation at line 4 decrypt and therefore learn a key Suchsubtleties can produce attacks which can be detected and mitigatedusing our modeling If the locking is handled correctly we can showsecrecy of keys produced on the device See Listing 22 in Section A3for the complete model

552 Needham-Schoeder-Lowe

We can show secrecy for a session-key established between two hon-est parties running the Needham-Schroeder-Lowe protocol [65] Themodelling does not require tags on the messages See Listing 23 inSection A3 for the complete model

553 Yubikey

The Yubikey [93] is a small hardware device designed to authenti-cate a user against network-based services When the user pressesa button on the device it outputs a one-time-password consisting ofa counter a timestamp and other data encrypted using a key that ison the device This one-time-password can be used to authenticateagainst a server that shares the same secret key

We introduced the Yubikey in Chapter 4 and showed by the meansof an injective correspondence property and a formalisation of theprotocol in tamarinrsquos multiset rewriting calculus that an attacker thatcontrols the network cannot perform replay attacks The modelling inthis chapter is more fine-grained due to the use of our calculus whichmakes security-relevant operations like locking and tests on state ex-plicit The resulting model is closer to the real-life operation of sucha device and the server component The modeling of the Yubikeytakes approximately 38 lines in our calculus which translates to 49

multiset rewrite rules The modelling from Chapter 4 contains onlyfour rules which are quite complicated in themselves resulting in 23

lines of code From the new modelling we learn that the server cantreat multiple authentication requests in parallel as long as they donot claim to stem from the same Yubikey An implementation on thebasis of the model from Chapter 4 would need to implement a globallock accessible to the authentication server and all Yubikeys to be onthe safe side since in the MSR model each of the four rules is atomicThis is of course impossible First the Yubikeys are likely to be usedat different places around the world so it is unlikely that there existmeans of direct communication between them (the Yubikey ldquotypesrdquoin an OTP in a web-form for the user i e it does not send anythingon the network itself) second there are typically many Yubikeys de-ployed at once so locking the authentication between the moment thebutton on the Yubikey is pressed and the moment the OTP is send onthe network is not only unrealistic but highly inefficient too Thirdlyand most importantly the Yubikey does not have support for such amechanism so while a server-side global lock might be conceivable(albeit impractical for the reason previously mentioned) a real globallock could not be implemented for the Yubikey as deployed In Sec-tion 533 we argue that such locking issues are far from trivial todetect We refer to Listing 24 in Section A3 for the complete model

55 case studies 97

554 The GJM contract signing protocol

A contract signing protocol allows two parties to sign a contract in afair way None of the participants should be bound to the contractwithout the other participant being bound as well A straightforwardsolution is to use a trusted party that collects both signatures on thecontract and then sends the signed contracts to each of the partici-pants Optimistic protocols have been designed to avoid the use of atrusted party whenever possible (optimizing efficiency and avoidingthe potential cost of a trusted party) In these protocols the partiesfirst try to simply exchange the signed contracts in case of failureor cheating behavior of one of the parties the trusted party can becontacted Depending on the situation the trusted party may eitherabort the contract or resolve it In case of an abort decision the proto-col ensures that none of the parties obtains a signed contract whilein case of a resolve the protocol ensures that both participants obtainthe signed contract For this the trusted party needs to maintain adatabase with the current status of all contracts (aborted resolved orno decision has been taken) In our calculus the status information isnaturally modelled using our insert and lookup constructs The useof locks is also crucial here to avoid the status to be changed betweena lookup and an insert

The contract signing protocol by Garay Jakobsson and MacKenziewas also studied by Arapinis et al [46 5] They showed the cru-cial property that the same contract may never be both aborted andresolved However due to the fact that StatVerif only allows for afinite number of memory cells they have shown this property for asingle contract and provide a manual proof to lift the result to an un-bounded number of contracts We directly prove this property for anunbounded number of contracts in the model described in Listing 25

in Section A3

555 Further Case Studies

We investigated the case study presented by Moumldersheim [74] andArapinis et al [5] in order to be able to compare our approach toeach of them For Moumldersheimrsquos key-server example we encodedtwo models of this example one using the insert construct the othermanipulating state using the embedded multiset rewrite rules Forthis example the second model turned out to be more natural andmore convenient allowing for a direct automated proof without anyadditional typing lemma (Listing 26 in Section A3 Listing 27 for themodelling using insert and lookup)

The modelling of the left-right encryption example by Arapinis etal also described in Example 4 was straight-forward (Listing 28 in

Section A3) In both cases we were able to re-use the typing lemmasfrom the tamarin models of those protocols by Simon Meier [71 68]

Part II

W H E N I S A S E C U R I T Y A P I ldquo S E C U R E rdquo

We introduce and discuss a definition of security for secu-rity API implementations This definition is presented inform of the first universally composable key-managementfunctionality formalized in Hofheinzrsquo and Shouprsquos GNUC

framework GNUC and similar frameworks define the secu-rity of protocols by comparison to special network entitiesaccessed by secure channels which express the ldquoidealrdquo ofwhatever computation the protocol should define Thisapproach allows for composability which means that aldquosecurerdquo protocol can be substituted by the functionalitythat defines its security in any context The key-manage-ment functionality enforces a range of security policiesand can be extended by key usage operations with noneed to repeat the security proof We illustrate its useby proving an implementation of a security token securewith respect to arbitrary key-usage operations and explorea proof technique that allows the storage of cryptographickeys externally

6W H E N I S A S E C U R I T Y A P I S E C U R E

In this chapter we discuss the characteristics of security APIs andcriteria we require in order to call a security API ldquosecurerdquo Decidingwhether a given definition is good is difficult therefore we discusswhat makes a good definition before we try to characterize the natureof security APIs in a cryptographic context This helps establishing abasis for the design decisions we make and provides for criteria forthe evaluation of our definition

61 criteria for persuasive definitions

The following five rules are traditionally used criteria for a certainkind of definition [28 54 53] With the aim of deriving a definitionthat is commonly acceptable we will regard those rules as desirableproperties of a good definition of security

a It should set out the essential attributes of what it defines

b It should not be too wide e g it should not include securityAPIs that are insecure

c It should not be too narrow

d It should not be obscure

e It should not be negative where it could be positive

Of course security definitions have slightly different constraints al-though we think that those properties provide a good starting pointWe would like to add an additional constraint which is very impor-tant for a security definition It should be possible to work withthe definition by which we means that it should both be possibleto show whether an object is secure with respect to the definitionand it should be possible to use the fact that an object is secure withrespect to the definition for the analysis of other objects

f Security definitions should be applicable

Furthermore security definitions usually put a lot of emphasis on thesecond property Since security definitions that are too wide mightgive a false sense of security and thus lead to attacks which are costlythe general consensus is to try to be ldquoon the safe siderdquo In practicethis means that often clarity and sometimes generality are sacrificedto that end ndash the definition we propose is not different in this regardThe fifth property a definition should not be negative where it could

102 when is a security api secure

be positive is usually easy to fulfill A secure cryptographic primitiveis typically an algorithm or a set of algorithms that has a number ofproperties

62 characteristics of a ldquosecurerdquo security api

The first property brings us back to one of the questions we haveposed in the introduction What characterises cryptographic securityAPIs First they provide an interface to cryptographic keys that arestored in some secure memory Second this interface allows to in-directly use these keys to compute cryptographic functions possiblydepending on one or more secrets randomness and the userrsquos inputThird the access to those secrets can be restricted for example by theconfiguration of the device

What characterises the security of such devices First it shouldnot reveal secrets to the user Second the cryptographic functionsshould be secure ndash what this means depends on the cryptographicfunction Third the intended access restrictions to the secrets shouldbe respected Fourth the previous properties should hold in a net-work where the user might be malicious and where several securityAPIs might be present and might contain the same secrets

63 composability

The fourth point suggests the use of a framework that supports uni-versal composability i e a framework that preserves the security ofa component in a network even under (parallel) composition with asecond components The GNUC (ldquoGNUC is Not UCrdquo) framework [51]which we will introduce in Chapter 7 is such a framework Compos-ability is helpful for the analysis of higher-level protocols which is anappealing feature for security definitions in particular Consider thefollowing perspective on security APIs Hosts in a network can easilybe compromised since it is very difficult to secure general-purposemachines against attacks on the implementation level Taking scenar-ios where parties are possibly under adversary control into accountit is often impossible to show protocols secure Let us modify theprotocol as follows Instead of performing the cryptographic opera-tions in the protocol themselves the parties have security APIs whichperform those computations for them In the case of GNUC the se-curity API would be an incorruptible entity in the network that theparties ndash corrupted or not ndash have access to Maybe assuming truston the security APIs but not the parties we can show interesting se-curity properties for this protocol Through the use of a frameworkthat allows for composability we can substitute the security APIs bya far more abstract object a functionality (cf Chapter 7) which helpsperforming this kind of proof

64 overview 103

64 overview

In Chapter 7 we will introduce the GNUC framework In Chapter 8we introduce our security definition which tries to incorporate thecharacterisation of a security API and its security we sketched abovewith the aim of deriving a definition that ldquosets out the essential at-tributes of what it definesrdquo In Chapter 9 we analyse this securitydefinition We will prove a lemma which states that many guaran-tees one should expect from our definitions are indeed provided tosupport the claim that this definition is not too wide In the samechapter we discuss the limitations of our approach and evaluate itwith respect to the properties mentioned before discussing in partic-ular whether the definition too narrow or too obscure

In Chapter 8 we furthermore introduce generic architecture for se-curity APIs It can serve as a guideline to the design of security APIsand is independent of how cryptographic functions are implementedas long as they are known upfront and the implementation is securein itself In order to achieve this we make use of the composabil-ity of the underlying framework We show in Chapter 10 that thisgeneric implementation is secure with respect to our definition InChapter 11 we will provide an example of how to use the secure im-plementation in a higher-level protocol supporting the claim that ourdefinition is applicable in the sense of being useful for the analysis ofother protocols

The contributions that we will present in the following chapters arejoint work with Steve Kremer and Graham Steel and were publishedat ESORICS 2013 [57]

65 related work

There is recent work that aims at trying to define appropriate securitynotions for security APIs [21 30 58] Both the proposal by Cachinand Chandran and the proposal by Kremer et al define security interms of a cryptographic game i e in both cases there is a gamewith a challenger that depending on a coin toss either acts like thesecurity API or acts like an idealized version of the security APIe g encrypting random values instead of the actual plaintexts etcThis approach has two major disadvantages First it is not clear howthe security notion will compose with other protocols implementedby the API How does the security of a single security API translateto the security of 100 security APIs that may eventually share thesame keys We have previously argued that this is inappropriatesince security APIs are first and foremost used as building blocks forlarger protocols ndash therefore composability is crucial

Second it is difficult to see whether a definition covers the attackmodel completely since the game may be tailored to a specific API

For example the security definition by Cachin and Chandran [21]specifies a list of commands that a security API must support ndash formany applications this definition is too narrow Furthermore it re-quires that one single central key server is used for a group of userssince the security depends on a complete and current log of all op-erations The definition of Cortier and Steel [30] also defines the setof commands that the API must support albeit it is intended fordistributed tokens as opposed to the definition by Cachin and Chan-dran This definition allows only for security proofs in the symbolicmodel and has a more limited functionality in comparison to Cachinand Chandranrsquos definition Recent work by Daubignard Lubicz andSteel extends the interface to public-key cryptography [32] Whilepublic key cryptography is supported by Chachin and Chandranrsquosdefinition as well as our definiton neither supports the use of public-key encryption of key export and import Daubignard Lubicz andSteel use signature keys to sign encryptions to guarantee the integrityof keys that are imported onto a device

The functionality defined in these works is fixed which means theirapproach is limited to APIs that provide no more operations thanldquoallowedrdquo This can be done better to this end it is worthwhile to findout which operations are essential to key-management In presentthesis we adapt the more general approach to API security of Kremeret al [58] to a framework that allows for composition The idea is toseparate the task of key-management from the task of key-usage inorder to distinguish the functions that are relevant for security (andtherefore have to be defined) from the functions that are not relevantfor the security (and can therefore be left open) Kremer et al givea game-based definition in the computational model as well as adefinition in the symbolic model We extend the idea of separatingkey-management and key-usage and transfer it into the frameworkof GNUC In fact the composability of this framework allows us to goone step further and define the security of the key-usage operationswithout fixing the set of key-usage operations in our definition

Some aspects of the functionality Fcrypto by Kuumlsters et al [61] aresimilar to our key-management functionality in that they both pro-vide cryptographic primitives to a number of users and enjoy com-posability However the Fcrypto approach aims at abstracting a spec-ified set of cryptographic operations on client machines to make theanalysis of protocols in the simulation-based security models easierand addresses neither key-management nor policies

7I N T R O D U C T I O N T O G N U C

The GNUC framework recently proposed by Hofheinz and Shoup [51]is a variant of the UC framework [23] and as such a framework forsimulation-based security The requirements on a protocol are for-malized by abstraction An ideal functionality computes the protocolrsquosinputs and outputs securely while a lsquosecurersquo protocol is one that emu-lates the ideal functionality Simulation-based security naturally mod-els the composition of the API with other protocols so that proofs ofsecurity can be performed in a modular fashion We decided to usethe GNUC model because it avoids shortcomings of the original Uni-versal Composability (UC) framework which have been pointed outover the years Moreover the GNUC framework is well structured andwell documented resulting in more rigorous and readable securityproofs

Hofheinz and Shoup proposed GNUC to address several knownshortcomings in UC In particular in UC the notion of a poly-timeprotocol implies that the interface of a protocol has to contain enoughinput padding to give sub-protocols of the implementation enoughrunning time hence the definition of an interface that is supposed tobe abstract depends on the complexity of its implementation More-over the proof of the composition theorem is flawed due to an inade-quate formulation of the composition operation [51] though here theauthors remark that ldquonone of the objections we raise point to gapsin security proofs of existing protocols Rather they seem artifactsof the concrete technical formulation of the underlying frameworkrdquoThese shortcomings are also addressed to a greater or lesser extentby other altenative frameworks [84 67] We chose GNUC because it issimilar in spirit to the original UC yet rigorous and well documentedWe now give a short introduction to GNUC and refer the reader to [51]for additional details

71 preliminaries

Let Σ be some fixed finite alphabet of symbols We note η the securityparameter

Definition 21 (probabilistic polynomial-time (PPT)) We say that a prob-abilistic programA runs in polynomial-time if the probability thatArsquosruntime on an input of length n is bounded by a polynomial in n is1 If so we say such a program is PPT

Definition 22 (Computationally indistinguishable) Let X = Xη η

and Y = Yη η be two families of random variables where each

106 introduction to gnuc

random variable takes values in a set Σlowast cup perp We say that X andY are computationally indistinguishable written X asymp Y if for every PPT

program D that takes as input a string over Σ we have that

|Pr[D(x) = 1| xlarr Xη] minus Pr[D(y) = 1| ylarr Yη]|

is negligible in η

72 machines and interaction

In GNUC a protocol π is modeled as a library of programs e g afunction from protocol names to code This code will be executed byinteractive Turing machines There are two distinguished machinesthe environment and the adversary that π does not define code forAll other machines are called protocol machines Protocol machines canbe divided into two subclasses regular and ideal protocol machinesThey come to life when they are called by the environment and areaddressed using machine ids A machine ID ltpidsidgt contains twoparts the party ID pid which is of the form ltregbasePIDgt for regu-lar protocol machines and ltidealgt for ideal protocol machines andthe session ID sid Session ids are structured as pathnames of theform 〈α1 αk〉 The last component αk must be of the particularform protName sp When the environment sends the first message toa protocol machine a machine running the code defined by the pro-tocol name protName is created The code will often make decisionsbased on the session parameter sp and the party ID A machine Midentified by its machine ID 〈pid 〈α1 αk〉〉 can call a subroutineie a machine with the machine ID 〈pid 〈α1 αk αk+1〉〉 We thensay that M is the caller with respect to this machine Two protocolmachines regular or ideal are peers if they have the same session IDPrograms have to declare which other programs they will call as sub-routines defining a static call graph which must be acyclic and thushave a program r with in-degree 0 ndash then we say that the protocol isrooted at r

GNUC imposes the following communication constraints on a reg-ular protocol machine M It can only send messages to the adversaryto its ideal peer (i e a machine with party ID ltidealgt and the samesession ID) its subroutines and its caller If the caller is the envi-ronment a sandbox mechanism translates its machine ID which issimply ltenvgt to the machine ID of the caller of M (which is uniquelydefined) As a consequence regular protocol machines cannot talkdirectly to regular peers They can communicate via the adversarywhich models an insecure network or via the ideal peer This idealpeer is a party that can communicate directly with all regular protocolparties and the adversary

The code of the machines is described by a sequence of steps simi-larly to [51 sect 12] Each step is defined by a block of the form

73 defining security via ideal functionalities 107

name [condition] P

The label name identifies the step The logical expression [condition]

is a guard that must be satisfied to trigger a step We omit the guardin case it is true A step name in the guard expression evaluates totrue if the corresponding step was triggered at some previous pointP is the code (whose semantics we expect to be clear) to be executedwhenever the guard evaluates to true In particular P may containaccept-clauses that describe the form of the message that can be inputThe accept clause too might have logical conditions that must besatisfied in order to continue the execution of the step Any messagenot triggering any step is processed by sending an error message toA Listing 1 in the next section gives an example of a functionalitywritten in this notation

73 defining security via ideal functionalities

As in other universal composability frameworks the security of aprotocol is specified by a so-called ideal functionality which acts asa third party and is trusted by all participants Formally an idealfunctionality is a protocol that defines just one protocol name sayr The behavior defined for this protocol name depends on the typeof machine All regular protocol machines act as ldquodummy partiesrdquoand forward messages received by their caller (which might be theenvironment) to their ideal peer The ideal peer (the machine withthe same session ID and party ID ltidealgt see Section 72) interactswith the regular parties and the adversary Using the inputs of theparties the ideal functionality defines a secure way of computinganything the protocol shall compute explicitly computing the datathat is allowed to leak to the attacker

Example 19 For instance an authenticated channel is specified as afunctionality that takes a message from Alice and sends it to the at-tacker exposing its content to the network but only accepting a mes-sage from the attacker (the network) if it is the same message Alicesent in the first place

We present the following formulation of this functionality which isvery similar to the one presented in [51 sect1211] and which we willlater come back to

Listing 1 Fach with session parameters 〈Ppid Qpid label〉 Note that in thisexample every step can only be executed once

ready-sender accept ltreadygt from P

send ltsender-readygt to A

ready-receiver[notready-sender] accept ltreadygt from Q

send ltready-receiver-earlygt to A

ready-receiver[ready-sender] accept ltreadygt from Q

send ltreceiver-readygt to A

send [ready-receiver] accept ltsendxgt from P

xlarr x send ltsendxgt to A

done [send] accept ltdonegt from A

send ltdonegt to P

deliver[send] accept ltdeliverxgt from A where x = x

send ltdeliverxgt to Q

We see that a functionality is completely defined by the code runon the ideal protocol machine

Now we can define a second protocol which is rooted at r anddoes not necessarily define any behaviour for the ideal party but onlyfor the regular protocol machines The role of the environment Z isto distinguish whether it is interacting with the ideal system (dummyusers interacting with an ideal functionality) or the real system (usersexecuting a protocol) We say that a protocol π emulates a functional-ity F if for all attackers interacting with π there exists an attacker thesimulator Sim interacting with F such that no environment can dis-tinguish between interacting with the attacker and the real protocolπ or the simulation of this attack (generated by Sim) and F It is actu-ally not necessary to quantify over all possible adversaries The mostpowerful adversary is the so-called dummy attacker AD that merelyacts as a relay forwarding all messages between the environment andthe protocol [51 Theorem 5]

Let Z be a program defining an environment i e a program thatsatisfies the communication constraints that apply to the environment(e g it sends messages only to regular protocol machines or to the ad-versary) Let A be a program that satisfies the constraints that applyto the adversary (e g it sends messages only to protocol machines(ideal or regular) it previously received a message from) The proto-col π together with A and Z defines a structured system of interactiveTuring machines (formally defined in [51 sect 4]) denoted [πA Z] Theexecution of the system on external input 1η is a randomized processthat terminates if Z decides to stop running the protocol and outputa string in Σlowast The random variable Exec[πA Z](η) describes theoutput of Z at the end of this process (or Exec[πA Z](η) = perp if itdoes not terminate) Let Exec[πA Z] denote the family of randomvariables Exec[πA Z](η) infinη=1 An environment Z is well-behavedif the data-flow from Z to the regular protocol participants and theadversary is limited by a polynomial in the security parameter η Wesay that Z is rooted at r if it only invokes machines with the samesession identifier referring to the protocol name r We do not definethe notion of a poly-time protocol and a bounded adversary here dueto space constraints and refer the reader to the definition in [51 sect 6]

Definition 23 (emulation wrt the dummy adversary) Let π and π prime

be poly-time protocols rooted at r We say that π prime emulates π if there

exists an adversary Sim that is bounded for π such that for everywell-behaved environment Z rooted at r we have

Exec[πSim Z] asymp Exec[π prime AD Z]

where asymp denotes computational indistinguishability (Definition 22)

8K E Y- M A N A G E M E N T F U N C T I O N A L I T Y A N DR E F E R E N C E I M P L E M E N TAT I O N

In the following we will develop and discuss a composable notionof secure key-management in the form of a functionality with thename FKM To the best of our knowledge it is the first composabledefinition of secure key-management

An ideal functionality should provide the required operations ina way that makes security obvious This means its design must beas simple as possible in order for this security to be clear Howeverthere are subtle issues in such designs Obtaining a satisfactory for-mulation of digital signature took years because of repeated revisionscaused by subtle flaws making the functionality unrealizable Thefunctionality we define will at some point need to preserve authen-ticity in a similar way to this signature functionality but in a multi-session setting So we must expect a key-management functionality tobe at least as complex Nonetheless we aim to keep it as simple as pos-sible and so justify the inclusion of each feature by discussing whatminimum functionality we expect from a key-management system Itwill be necessary to compromise at certain points for example we de-cided to only support symmetric encryption as a key-transportationmechanism The following Chapter 9 provides an analysis of FKMIn Section 91 we will give some properties that any security APIthat implements FKM enjoys We list limitations in Section 92 Adiscussion of FKM takes place in Section 93

The functionality FKM formalises the requirements for a securityAPI It assures that keys are transferred correctly from one securitytoken to another that the global security policy is respected (eventhough the keys are distributed on several tokens) and that opera-tions which use keys are computed correctly The latter is achievedby describing operations unrelated to key-management by so-calledkey-usage functionalities FKM is parametric in the policy and the setof key-usage functionalities which can be arbitrary This facilitates re-vision of API designs because changes to operations that are not partof the key-management or the addition of new functions do not affectthe emulation proof This allows the aim of deriving a definition thatis wide enough to cover many different forms of security APIs Toachieve this extensibility we investigate what exactly a ldquokeyrdquo meansin the context of simulation-based security in Section 82

Common functionalities in such settings do not allow two partiesto share the same key In fact they do not have a concept of keysbut a concept of ldquothe owner of a functionalityrdquo instead The actual

112 key-management functionality and refer implementation

key is kept in the internal state of a functionality used for computa-tion but never output Dealing with key-management we need thecapability to export and import keys and we propose an abstractionof the concept of keys that we call credentials The owner of a cre-dential can not only compute a cryptographic operation but he canalso delegate this capacity by transmitting the credential We thinkthis concept is of independent interest We subsequently introducea general proof method that allows the substitution of credentials byactual keys when instantiating a functionality

We will now proceed to explain the architecture of FKM then inSection 82 introduce our concept of key-usage functionalities whichcovers the usual cryptographic operations we might want to performwith our managed keys In Section 83 we describe our notion ofsecurity policies for key-management In Section 84 we formallydefine FKM as well as a generic implementation of FKM

81 design rationals

The network we want to show secure has the following structureA set of users takes input from the environment each of them isconnected to a security token Each security token is a network entityjust like the users and has a secure channel to the user it belongsto Cryptographic keys are stored on the token but are not givendirectly to the user ndash instead at creation of a key the user (and thusthe environment) receives a handle to the key

We consider such a network secure if it emulates a network inwhich the users are communicating with a single entity the key-management functionality FKM instead of their respective securitytoken It gives the users access to its operations via handles too andis designed to model the ldquoidealrdquo way of performing key-managementTo show the security of the operations that have nothing to do withkey-management FKM accesses several other functionalities whichmodel the security of the respective operations This allows us tohave a definition that is applicable to many different cases

811 Policies

As mentioned in Chapter 6 a security API we want to consider secureshould respect the intended access restrictions that apply to keys Inorder to formalise this intention we assume there to be a policy whichis to be enforced on a global level Our definition allows the expres-sion of two kinds of requirements usage policies of the form ldquokeyA can only be used for tasks X and Yrdquo and dependency policies ofthe form ldquothe security of key A may depend on the security of keysB and Crdquo The need for the first is obvious The need for the sec-ond arises because almost all non-trivial key-management systems

81 design rationals 113

allow keys to encrypt other keys or derive keys by e g encryptingan identifier with a master key Typically the policy defines roles forkeys i e groups of tasks that can be performed by a key and se-

curity levels which define a hierarchy between keys The difficultylies in enforcing this policy globally when key-management involvesa number of distributed security tokens that can communicate onlyvia an untrusted network Recall Example 2 from the introductionwhich showed that a global policy can be violated even if each se-curity token enforces the policy locally Our ideal key-managementfunctionality considers a distributed set of security tokens as a singletrusted third party It makes sure that every use of a key is compliantwith the (global) policy Therefore if a set of well-designed securitytokens with a sound local policy emulates the ideal key-managementfunctionality they can never reach a state where a key is used foran operation that is contrary to the global policy This implies thatin general the key should be kept secret from the user as the usercannot be forced to comply with any policy Thus keys are only ac-cessed via an interface that executes only the operations on the keypermitted by the policy The functionality associates some meta-dataan attribute to each key This attribute defines the keyrsquos role andthus its uses Existing industrial standards [81] and recent academicproposals [21 58] are similar in this respect

812 Sharing Secrets

A key created on one security token is a priori only available to usersthat have access to this token (since it is hidden from the user) Manycryptographic protocols require that the participants share some keyso in order to be able to run a protocol between two users of differentsecurity tokens we need to be able to ldquotransferrdquo keys between deviceswithout revealing them There are several ways to do this e g usingsemantically secure symmetric or asymmetric encryption but we willopt for the simplest key-wrapping (the encryption of one key byanother) While it is possible to define key-management with a moreconceptual view of ldquotransferring keysrdquo and allow the implementationto decide for an option we think that since key-wrapping is relevantin practice (it is defined in RFC 3394) the choice for this option allowsus to define the key-management in a more comprehensible way Weleave the definition of a notion more general in this regard for futurework

813 Secure Setup

The use of key-wrapping requires some initial shared secret valuesto be available before keys can be transferred We model the setupin the following way A subset of users Room is assumed to be in

a secure environment during a limited setup-phase Afterwards theonly secure channel is between a user Ui and his security token STiThe intruder can access all other channels and corrupt any party atany time as well as corrupt keys i e learn the value of the key storedinside the security token This models the real world situation wheretokens can be initialised securely but then may be lost or subject toe g side channel attacks once deployed in the field

814 Operations required

These requirements give a set of operations that key-management de-mands new (create keys) wrap and unwrap (our chosen method oftransferring keys) corrupt (corruption of keys) and sharefinish_-setup (modelling a setup phase in a secure environment) For poli-cies that allow a keyrsquos attribute to be changed the command attr_-

change is provided We argue that a reasonable definition of securekey-management has to provide at least those operations Further-more the users need a way to access the keys stored in the securitytokens so there is a set of operations for each type of key A sig-nature key for example allows the operations sign and verify Thisallows the following classification The first group of operations de-fines key-management the second key-usage While key-managementoperations for example wrap might operate on two keys of possiblydifferent types key-usage operations are restricted to calling an oper-ation on a single key and user-supplied data This is coherent withglobal policies as mentioned above The form ldquokey A can be used fortask Xrdquo expresses key-usage the form ldquothe security of key A dependson keys B and Crdquo expresses a constraint on the key-management

82 key-usage (ku) functionalities

We now define an abstract notion of a functionality making use of akey which we call a ku functionality This will allow us to define ourideal key-management functionality FKM in a way that is general withrespect to a large class of cryptographic functionalities For every kuoperation FKM calls the corresponding ku functionality receives theresponse and outputs it to the user We define FKM for arbitrary kuoperations and consider a security token secure with respect to theimplemented ku functionalities if it emulates the ideal functionalityFKM parametrized by those ku functionalities This allows us to pro-vide an implementation for secure key-management independent ofwhich ku functionalities are used

82 key-usage (ku) functionalities 115

821 Credentials

Many existing functionalities e g [23] bind the roles of the partiese g signer and verifier to a machine ID encoded in the session pa-rameters In implementations however the privilege to perform anoperation is linked to the knowledge of a key rather than a machineID While for most applications this is not really a restriction it is forkey-management The privilege to perform an operation of a ku func-tionality must be transferable as some piece of information whichhowever cannot be the actual key A signature functionality for ex-ample that exposes its keys to the environment is not realizable sincethe environment could then generate dishonest signatures itself Oursolution is to generate a key but only send out a credential which is ahard-to-guess pointer that refers to this key We actually use the keygeneration algorithm to generate credentials As opposed to the realworld where security tokens map handles to keys and compute theresults based on the keys in the ideal world FKM maps handles tocredentials and uses those credentials to address ku functionalitieswhich compute the results The implementation of a ku functionalitymaps credentials to cryptographic keys (see Definition 24) While cre-dentials are part of the key-management functionality FKM and the kufunctionality they are merely devices used for abstracting keys Theyare used in the proofs but disappear in the reference implementationpresented in Section 84

In summary credentials serve as an abstraction of keys in the idealworld Whoever knows the credential is allowed to sign Keys notonly allow a distinguished party the owner of the key to performoperation but also allow delegation of this capacity An abstraction oflsquokeysrsquo by lsquocredentialsrsquo is thus more powerful than abstraction of thelsquoowner of a keyrsquo by a lsquofixed identity of party that is allowed to signrsquoIn our scenario where keys are exported it is necessary to abstractkeys

822 Key-manageable functionalities

Our approach imposes assumptions on the ku functionalities as theyneed to be implementable in a key-manageable way

Definition 24 (key-manageable implementation) A key-manageableimplementation I is defined by (i) a set of commands Cmds thatcan be partitioned into private and public commands as well as key-(and credential-)generation i e C = Cpriv ⊎ Cpub ⊎ new and (ii) a setof PPT algorithms implementing those commands implC CisinC suchthat for the key-generation algorithm impl

newit holds that

bull for all k Pr[

k prime = k | (k prime public)larr implnew

(1η)]

is negligible inη and

bull Pr[

|k1| 6= |k2| | (k1 p1)larr implnew

(1η) (k2 p2)larr implnew

(1η)]

isnegligible in η

I is a protocol in the sense of [51 sect5] i e a run-time library thatdefines only one protocol name The session parameter encodes amachine ID P When called on this machine the code below is exe-cuted If called on any other machine no message is accepted Fromnow on in our code we follow the convention that the response to aquery (Command sid ) is always of the form (Commandbull sid )or perp The variable L holds a set of pairs and is initially empty

new accept ltnewgt from parentId

(key public) larr implnew(1η)

(credential_) larr implnew(1η)

Llarr Lcup (credential key)send ltnewbull credential publicgt to parentId

command accept ltC credentialmgt from parentId

if (credential key) isin L for some keysend ltCbull implC(keym)gt to parentId

public_command accept ltC publicmgt from parentId

send ltCbull implC(publicm)gt to parentId

corrupt accept ltcorruptcredentialgt from parentId

if (credential key) isin L for some keysend ltcorruptbull keygt to parentId

inject accept ltinjectkgt from parentId

(c _) larr implnew(1η)

Llarr Lcup (c k) send ltinjectbullcgt to parentId

The definition requires that each command C can be implementedby an algorithm implC If C is private implC takes the key as anargument Otherwise it only takes public data (typically the publicpart of some key and some user data) as arguments In other wordsan implementation I emulating F is once a key is created statelesswith respect to queries concerning this key The calls 〈corrupt〉 and〈inject〉 are necessary for cases where the adversary learns a key oris able to insert dishonestly generated key-material

Definition 25 (key-manageable functionality) A poly-time functional-ity F (to be precise an ideal protocol [51 sect 82]) is key-manageable iff itis poly-time and there is a set of commands C and implementationsi e PPT algorithms ImplF = implC CisinC defining a key-manageableimplementation I (also poly-time) which emulates F

83 policies

Since all credentials on different security tokens in the network areabstracted to a central storage FKM can implement a global policyEvery credential in FKM is associated with an attribute from a set ofattributes A and to the ku functionality it belongs to (which we will

call its type) Keys that are used for key-wrapping are marked withthe type KW

Definition 26 (Policy) Given the ku functionalities Fi i isin 1 l

and corresponding sets of commands Ci a policy is a quaternary rela-tion Π sub F1 Fl KWtimescupiisin1l C

privi cup new wrap unwrap attr_

changetimesAtimesA

FKM is parametrized by a policy Π If (F C a a prime) isin Π and if

bull C = new then FKM allows the creation of a new key for thefunctionality F with attribute a

bull F = Fi and C isin Cprivi then FKM allows sending the command C

to F if the key is of type F and has the attribute a

bull F = KW and C = wrap then FKM allows wrapping a key withattribute a prime using a wrapping key with attribute a

bull F = KW and C = unwrap then FKM allows unwrapping a wrap-ping with attribute a prime using a wrapping key with attribute a

bull if C = attr_change then FKM allows changing a keyrsquos attributefrom a to a prime

Note that a prime is only relevant for the commands wrap unwrap andattr_change Because of the command attr_change a key can havedifferent attributes set for different users of FKM corresponding todifferent security tokens in the real word

Example 20 To illustrate Definition 26 consider the case of a singleku functionality for encryption Fenc The set of attributes A is 0 1Intuitively a key with attribute 1 can be used for wrapping and a keywith attribute 0 for encryption The following table describes a policythat allows wrapping keys to wrap encryption keys but not otherwrapping keys and allows encryption keys to perform encryptionon user-data but nothing else ndash even decryption is disallowed Thepolicy Π consists of the following 4-tuples (FCmdattr1attr2)

F Cmd attr1 attr2KW new 1

Fenc new 0

KW wrap 1 0

KW unwrap 1 0

Fenc enc 0

84 the key-management functionality and a generic

and secure reference implementation

We are now in a position to give a full definition of FKM togetherwith a generic secure architecture for security APIs We give the de-

U1 Un Uext1 Uext

Fsetup

ST1 STn

(a) Distributed security tokens in the network

U1 Un Uext1 Uext

(b) An idealized functionality FKM in the samenetwork

Figure 15 Distributed security tokens in the network (left-hand side) andidealized functionality FKM in the same network (right-handside)

scription of FKM in the Listings 3 to 8 At the same time to illustrateour definition and demonstrate its use we present the implemen-tation of a security API showing that it is possible to implement asecurity API for key-management that is independent of the ku func-tions it provides By presenting the functionality FKM and the modelimplementation side-by-side we hope to be able to show how on theone hand how FKM provides the security guarantees and deals withcorner cases while on the other hand the implementation illustratesa straight-forward way of implementing FKM using a deterministicsymmetric key-wrapping scheme

The implementation ST is inspired by Kremer et alrsquos proposal fora secure implementation of key-management [58] and is parametricwith respect to the ku parameters FC Π and the implementationfunctions Impl = ImplFFisinF It is therefore composable in the fol-lowing sense If a device performs the key-management according toour implementation it does not matter how many and which func-tionalities it enables access to as long as those functionalities providethe amount of security the designer aims to achieve (cf Corollary 1)In Chapter 10 we show that this implementation is indeed a realiza-tion of FKM We emphasize that extending FKM and the implementa-tion by a new ku functionality does not require a new proof

841 Structure and Network setup

For book-keeping purposes FKM maintains a set Kcor of corruptedkeys and a wrapping graph W whose vertices are the credentials Anedge (c1 c2) is created whenever (the key corresponding to) c1 isused to wrap (the key corresponding to) c2FKM acts as a proxy service to the ku functionalities It is possible

to create keys which means that FKM asks the ku functionality for thecredentials and stores them but outputs only a handle referring to thecredential which represents the key A handle can be the position of

the key in memory or a running number ndash we just assume that thereis a way to draw them such that they are unique When a commandC isin C

privi is called with a handle and a message FKM substitutes the

handle with the associated credential and forwards the output to FiThe response from Fi is forwarded unaltered All queries are checkedagainst the policy The environment may corrupt parties connectedto security tokens as well as individual keys

Definition 27 (Parameters to a security token network) We summarizethe parameters of a security token network as two tuples (UUext ST

Room) and (FC Π) The first tuple defines network parameters

bull U = U1 Un are the party IDs of the users connected to asecurity token

bull Uext = Uext1 U

extm are the party IDs of external users i e

users that do not have access to a security token

bull ST = ST1 STn are the party IDs of the security tokensaccessed by U1 Un

bull Room sub U

The second tuple defines key-usage parameters

bull F = F1 Fl and

bull C = C1 Cl are key-manageable functionalities with corre-sponding sets of commands Note that KW 6isin F1 Fl andthat each Ci isin C is partitioned into the private C

privi and public

commands Cpubi as well as the singleton set consisting of new

bull Π is a policy for F and C (cf Definition 26) and a membershiptest on Π can be performed efficiently

Figure 15 shows the network of distributed users and security to-kens on the left and their abstraction FKM on the right There are twokinds of users U1 Un = U each of whom has access to exactlyone security token STi and external users Uext

1 Uextm = Uext who

cannot access any security token but may access the public parts ofkeys that are stored on a security token The security token STi canonly be controlled via the user Ui The functionality Fsetup in the realworld captures our setup assumptions which need to be achievedusing physical means Among other things Fsetup assures a securechannel between each pair (UiSTi) The necessity of this channelfollows from the fact that a) GNUC forbids direct communicationbetween two regular protocol machines (indirect communication viaA is used to model an insecure channel) and b) U1 Un can becorrupted by the environment while ST1 STn are incorruptiblesince security tokens are designed to be better protected against phys-ical attacks as well as worms viruses etc Although we assume that

the attacker cannot gain full control of the device (party corruption)he might obtain or inject keys in our model (key corruption)

The session ID sid is of the form 〈α1 αkminus1 〈protminus fkm sp〉〉where the session parameter sp is some encoding of the network pa-rameters UUext STRoom The code itself is parametric in the kuparameters FC Π When we refer to FKM as a network identity wemean the machine ID 〈ideal sid〉

Similarly each security token STi isin ST1 STn is addressedvia the machine ID 〈STi sid〉 We will abuse notation by identifyingthe machine ID with STi whenever the session ID is clear from thecontext The session parameter within sid encodes the network pa-rameters UUext STRoom STi makes subroutine calls to the function-ality Fsetup which subsumes our setup assumptions Fsetup providestwo things 1 a secure channel between each pair Ui and STi 2 a se-cure channel between all pairs STi and STj for which Ui Uj isin Room

during the setup phase (see below) STi receives commands from a ma-chine Ui isin U which is defined in Definition 29 Ui relays arbitrarycommands sent by the environment to STi (via Fsetup) The environ-ment cannot talk directly to STi but the attacker can send queries onbehalf of any corrupted user given that the user has been corruptedpreviously (by the environment)

842 Setup phase

The setup assumptions are implemented by the functionality Fsetupwhich Listing C3 in Section C3 in the appendix describes in full de-tail All users in Room are allowed to share keys during the setupphase i e the implementation is allowed to use secure channels totransport keys during this phase but not later This secure chan-nel between each two security tokens STiSTj isin Room is only used dur-ing the setup phase Once the setup phase is finished the expres-sion setup_finished evaluates to true and the functionality entersthe run phase During the run phase Fsetup provides only a se-cure channel between a user Ui which takes commands from theenvironment and his security token STi When we say that STi

calls Fsetup we mean that it sends a message to the machine ID〈ideal 〈sid 〈protminus fsetup 〈UUext STRoom〉〉〉〉

843 Executing commands in Cpriv

We will now describe FKM and the reference implementation ST com-mand by command Note that from now on when we say that FKM

calls F we mean that it sends a message to a regular peer that callsF as a sub-protocol and relays the answers Formally FKM sendsa message to the machine ID F = 〈〈regF〉 sid〉 who in turn ad-dresses 〈〈regF〉〈sid 〈F F〉〉〉 as a dummy party This is necessary

since Condition C6 in [51 sect45] disallows ideal parties from makingsub-routine calls Note first that for unambiguity we use the code F

as the party ID for this user Note secondly that F uses the sessionparameter F to identify F as the only machine ID it accepts messagesfrom

If the policy Π permits execution of a command C isin Cpriv FKM

calls the corresponding functionality as a sub-protocol (via F) substi-tuting the handle by the corresponding credential Similarly STi usesthe corresponding key to compute the output of the implementationfunction implC of the command C (see Listings 2) Note that the se-curity token communicates with its respective user via Fsetup whichforwards messages between STi and Ui serving as a secret channel

Listing 2 Executing command C on a handle h with data m (FKM aboveSTi below)

command[finish_setup] accept ltC isin Cprivi hmgt from U isin U

if Store[Uh]=ltFiacgt and ltFiCagtisin Π and Fi 6= KW

call Fi with ltCcmgt accept ltCbullrgt from Fi

send ltCbullrgt to U

command[finish_setup] accept ltC isin Cprivi prime

hmgt from Fsetup

if Store[Ui h] =ltFi primeakgt and ltFi primeCagtisin Π and Fi prime 6= KW

send ltCbullimplC(km)gt to Fsetup

844 Creating keys

A user can create keys of type F and attribute a using the command〈newF a〉 In FKM the functionality F is asked for a new creden-tial and some public information The credential is stored with themeta-data at a freshly chosen position h in the store ST proceedssimilarly but stores an actual key instead of a credential Both FKM

and ST output the handle h and the public information given by For produced by the key-generation algorithm FKM treats wrappingkeys differently It calls the key-generation function for KW It is pos-sible to change the attributes of a key in future if the policy permits(Listing 6)

Listing 3 Creating keys of type F and attribute a (FKM above STi below)

new[ready] accept ltnewFagt from U isin U

if 〈F new a lowast〉 isin Πif F =KW then

(c public)larr implKWnew (1η)

call F with ltnewgt

accept ltnewbullcpublicgt from F

if c isin KcupKcor then

send lterrorgt to A

create h

Store[U h] larr ltFacgt

K = K cup c send ltnewbullhpublicgt to U

new[ready] accept ltnewFagt from Fsetup

if 〈F new a lowast〉 isin Π

(k public) larr implFnew(1η )

create h

Store[Ui h] larr ltFakgt

send ltnewbullhpublicgt to Fsetup

845 Wrapping and Unwrapping

The commands that are important for key-management are handledby FKM itself To transfer a key from one security token to anotherin the real world the environment instructs for instance U1 to askfor a key to be wrapped (see Listing 4) A wrapping of a key is the en-cryption of a key with another key the wrapping key The wrappingkey must of course be on both security tokens prior to that U1 willreceive the wrap from ST1 and forward it to the environment whichin turn instructs U2 to unwrap the data it just received from U1 Theimplementation STi just verifies if the wrapping confirms the policyand then produces a wrapping of c2 under c1 with additionally au-thenticated information the type and the attribute of the key plus auser-chosen identifier that is bound to a wrapping in order to identifywhich key was wrapped This could e g be a key-digest providedby the ku functionality the key belongs to The definition of FKM isparametric in the algorithms wrap unwrap and implnew used to pro-duce the wrapping When a handle to a credential c is corrupted thevariable key[c] stores the corresponding key cf Listing 7 We use $l

to denote a bitstring drawn from a uniform distribution of bitstringsof length l

Listing 4 Wrapping key h2 under key h1 with additional information id(FKM above STi below)

wrap[finish_setup] accept ltwraph1h2idgt from U isin U

if Store[Uh1]=ltKWa1c1gt and Store[Uh2]=ltF2a2c2gt

and ltKWwrapa1a2gtisin Π then

if existwltc2ltF2a2idgtwgtisinencs[c1]send ltwrapbullwgt to U

WlarrWcup (c1 c2) if c1 isin Kcor

forall c3 reachable from c2 in W

corrupt c3

wlarr wrapltF2a2idgt(c1 key[c2])else

wlarr wrapltF2a2idgt(c1 $|c2|)encs[c1] larr encs[c1] cup ltc2ltF2a2idgtwgtsend ltwrapbullwgt to U

wrap[finish_setup] accept ltwraph1h2idgt from Fsetup

if Store[Ui h1]=ltKWa1k1gt and Store[Ui h2]=ltF2a2k2gt

and ltKWwrapa1a2gtisin Π

wlarr wrapltF2a2idgt(k1 k2)

send ltwrapbullwgt to Fsetup

When a wrapped key is unwrapped using an uncorrupted key FKM

checks if the wrapping was produced before using the same identifierFurthermore FKM checks if the given attribute and types are correctIf this is the case it creates another entry in Store i e a new handleh prime for the user U pointing to the correct credentials type and attributetype of the key This way FKM can guarantee the consistency of itsdatabase for uncorrupted keys see Theorem 2 in Chapter 9 If thekey used to unwrap is corrupted this guarantee cannot be given butthe resulting entry in the store is marked corrupted It is possibleto inject keys by unwrapping a wrapping created outside the deviceSuch keys could be generated dishonestly by the adversary that isnot using their respective key-generation function In this case the 〈inject 〉 call imports the cryptographic value of the key onto the kufunctionality which generates a new credential for this value

Listing 5 Unwrapping w created with attribute a2 F2 and id using the keyh1 existxp(x) holds if there exists exactly one x such that p(x) holds(FKM above STi below)

unwrap[finish_setup] accept ltunwraph1wa2F2idgt from U isin U

if Store[Uh1]=ltKWa1c1gt and ltKWunwrapa1a2gtisin ΠF2 isin F

if c1 isin Kcor

c2 larr unwrapltF2a2idgt(c1 w)

if c2 6= perp and c2 6isin K

if F2 =KW

create h2

Store[Uh2] larr ltF2a2c2gt

key[c2]larr c2

Kcor larr Kcor cup c2 else

call F2 with ltinjectc2gt

accept ltinjectbullc primegt

if c prime 6isin KcupKcorcreate h2

Store[Uh2] larr ltF2a2cprimegt

key[c prime]larr c2

Kcor larr Kcor cup cprime

send ltunwrapbullhgt to U

else if c2 6= perpand c2 isin Kand c2 isin Kcorcreate h2

else (c2 = perpor c2 isin KKcor)

send lterrorgt to A

else if ( c1 isin Kcor and exist c2 ltc2ltF2a2idgtwgtisinencs[c1])

create h2

Store[U h2 ] larr ltF2a2c2gt

send ltunwrapbullh2gt to U

unwrap[finish_setup] accept ltunwraph1wa2F2idgt from Fsetupif Store[Ui h1 ]=ltKWa1k1gt and F2 isin F and ltKWunwrapa1a2gtisin Π

and k2 = unwrapltF2 a2 idgt (k1 w) 6= perpcreate h2

Store[U h2 ] larr ltF2a2k2gt

send ltunwrapbullh2gt to Fsetup

There is an improvement that became apparent during the emu-lation proof (see Chapter 10) When unwrapping with a corruptedkey FKM checks the attribute to be assigned to the (imported) keyagainst the policy instead of accepting that a corrupted wrapping-key might import any wrapping the attacker generated This pre-vents eg a corrupted wrapping-key of low security from creating ahigh-security wrapping-key by unwrapping a dishonestly producedwrapping This detail in the definition of FKM enforces a strongerimplementation than the one in [58] ST validates the attribute givenwith a wrapping enforcing that it is sound according to the policy in-stead of blindly trusting the authenticity of the wrapping mechanismHence our implementation is more robust against key-corruption

846 Changing attributes of keys

The attributes associated with a key with handle h can be updatedusing the command 〈attr_change h a prime〉

Listing 6 Changing the attribute of h to a prime (FKM above STi below)

attr_change[finish_setup] accept ltattr_changeha primegt from U isin U

if Store[Uh]=ltFacgt andltFattr_changeaa primegtisin ΠStore[Uh]=ltFa primecgt

send ltattr_changebullgt to U

attr_change[finish_setup] accept ltattr_changeha primegt from Fsetup

if Store[Ui h]=ltFakgt and ltFattr_changeaa primegtisin ΠStore[Ui h]=ltFa

primekgt

send ltattr_changebullgt to Fsetup

847 Corruption

Since keys might be used to wrap other keys we would like to knowhow the loss of a key to the adversary affects the security of other

keys When an environment ldquocorrupts a keyrdquo in FKM the adversarylearns the credentials to access the functionalities Since corruptioncan occur indirectly via the wrapping command too we factoredthis out into a procedure used both in the corrupt command and thewrap command The procedure used in FKM is depicted in Listing 7Listing 8 shows the actual corruption command in FKM and in STIn FKM the corruption procedure is invoked for all keys that havebeen wrapped with the newly corrupted key ST implements thiscorruption by outputting the actual key to the adversary

Listing 7 Corruption procedure used in steps corrupt and wrap

procedure for corrupting a credential c

Kcor larr Kcor cup c for any Store[Uh] =lt F a c gt

if F = KW

key[c]larr c send ltcorruptbullhcgt to A

call F with ltcorruptcgt accept ltcorruptbullkgt from

key[c]larr k send ltcorruptbullhkgt to A

Listing 8 Corrupting h (FKM above STi below)

corrupt[finish_setup] accept ltcorrupthgt from U isin U

if Store[Uh] =lt F a c gtfor all c prime reachable from c in W corrupt c prime

corrupt[finish_setup] accept ltcorrupthgt from Fsetup

if Store[Ui h] =lt F a k gt send ltcorruptbullhkgt to A

848 Public key operations

Some cryptographic operations (e g digital signatures) allow userswithout access to a security token to perform certain operations (e gsignature verification) Those commands do not require knowledgeof the credential (in FKM) or the secret part of the key (in ST) Theycan be computed using publicly available information In the casewhere participants in a high-level protocol make use of e g signa-ture verification but nothing else the protocol can be implementedwithout requiring those parties to have their own security tokensNote that FKM relays this call to the underlying ku functionality un-altered and independent of its store and policy (see Figure 9) Theimplementation STi does not implement this step since Ui Uext

i com-pute implC(publicm) themselves

Listing 9 Computing the public commands C using the inputs public and m(FKM note that STi does not implement this step)

public_command accept ltCpublicmgt from U isin UcupUext

if C isin Cipub

call Fi with ltCpublicmgt

accept ltCbullrgt from Fi

849 Formal definition of FKM

Before we give the formal definition of FKM note that FKM is notan ideal protocol in the sense of [51 sect 82] since not every reg-ular protocol machine runs the dummy party protocol ndash the party〈〈regFi〉 sid〉 relays the communication with the ku functionalities

Definition 28 (FKM) Given the ku parameters FC Π and polytimealgorithms wrap unwrap and implnew let the ideal protocols Fp+1

Fl be rooted at prot-Fp+1 prot-Fl In addition to those proto-cols names FKM defines the protocol name prot-fkm For prot-fkmthe protocol defines the following behaviour a regular protocol ma-chine with machine ID 〈〈regFi〉 sid〉 for Fi isin F1 Fl runs thefollowing code

ready accept ltreadygt from parentId

send ltreadygt to ltidealsidgt (= FKM)

relay_to accept ltmgt from ltidealsidgt (= FKM)

send ltmgt to ltltregFigtltsidltprot-Filtgtgtgt (= Fi)

relay_from accept ltmgt from ltltregFigtltsidltprot-Filtgtgtgt

send ltmgt to ltidealsidgt (= FKM)

The ideal party runs the logic for FKM described in Listings 3 to 8

remark 1 Credentials for different ku functionalities are distinctIt is nonetheless possible to encrypt and decrypt arbitrary credentialsusing ltwrapgt and ltunwrapgt Suppose a designer wants to prove asecurity API secure which uses shared keys for different operationsOne way or another she would need to prove that those roles do notinterfere For this case we suggest providing a functionality that com-bines the two desired operations and proving that the implementa-tion of the two operations combined emulates the combined function-ality It is possible to assign different attributes to keys of the sameku functionality and thus restrict their use to certain commands ef-fectively providing different roles for credentials to the same ku func-tionality This can be done by specifying two attributes for the tworoles and defining a policy that restricts which operation is permittedfor a key of each attribute

remark 2 Many commonly used functionalities are not caller-in-

dependent often the access to critical functions is restricted to a net-work party that is encoded in the session identifier In the imple-

mentation this party is the party holding the key which is other-wise not represented in the functionality We think that it is possibleto construct caller-independent functionalities for many functionali-ties if the implementation relies on keys but is otherwise statelessA general technique for transforming such functionalities into key-manageable functionalities that preserves existing proofs will be dis-cussed in Section 122 in the conclusion of this thesis

remark 3 Constraint C6 in [51 sect82] requires each regular ma-chine to send a message to Fsetup before it can address it The initial-ization procedure and the parts of the definition of FKM ST and Fsetup

that perform this procedure are explained in detail in Appendix C1

8410 Formal definition of the security token network

We can now define the network of security tokens ST users and ex-ternal users that implements FKM

Definition 29 (security token network) For ku parameters FC Π andimplementation functions Impl = ImplF FisinF define the protocolπFCΠImpl as follows πFCΠImpl defines πFCΠImpl(protminus fkm) andπFCΠImpl(protminus fsetup) The session parameter is expected to bean encoding of the network parameters UUext STRoom The codeexecuted depends on the party running πFCΠImpl(protminus fkm) If theparty has identity Ui (which we assume to have the form 〈〈reg u-i〉sid〉) the following code is executed

relay_to accept ltmgt from parentId

call Fsetup with ltmSTigt

relay_from accept ltm STigt or ltm = perpgt from Fsetupsend ltmgt to parentId

public_command

accept ltCpublicmgt from parentId

if C isin Cipub

send ltCbullimplC(publicm)gt to parentId

If the party has identity Uexti (which we assume to have the form

〈〈reg ext-u-i〉 sid〉) the following code is executed

public_command accept ltCpublicmgt from parentId

if C isin Cipub

A regular protocol machine with machine ID ltregFigtsid for Fi isin

F1 Fl runs the following code

call Fsetup with ltreadygt

All other regular protocol machines run the code of the dummy ad-versary If the party has identity STi (which we assume to have the

form 〈〈reg st-i〉 sid〉) then the code for ST described in this chap-ter is executed for i The code for STi is given in Section 84 andin for the setup procedure in Appendix C1 For other machinesincluding ideal machines it responds to any message with an errormessage to the adversary i e πFCΠImpl(prot-fkm) is totally regularπFCΠImpl(protminusfkm) declares the use of prot-fsetup as a subrou-tine πFCΠImpl(protminusfsetup) runs Fsetup i e πFCΠImpl is a Fsetup-hybrid protocol

9A N A LY S I S O F T H E K E Y- M A N A G E M E N TF U N C T I O N A L I T Y

In this chapter we will give an analysis of FKM in three steps Firstwe will show that this functionality gives the properties that youwould expect it to guarantee Second we will discuss the limita-tions of our approach Third we will discuss to what extent we havereached the requirements for a commonly acceptable definition wehave outlined in Chapter 6

91 properties

In order to identify some properties we get from the design of FKMwe introduce the notion of an attribute policy graph

Definition 30 We define a family of attribute policy graphs (AΠF) onefor each ku functionality F and one for key-wrapping (in which caseF = KW) as follows

bull a is a node in AΠF if (F C a a prime) isin Π for some C a prime

bull a is additionally marked new if (F new a a prime) isin Π

bull An edge (a a prime) is in AΠF whenever (F attr_change a a prime) isin

Example 21 For the policy Π described in Example 20 the attributepolicy graph AΠKW contains one node labelled 1 connected to itselfand marked new Similarly the attribute policy graph AΠFenc containsone node 0 connected to itself and marked new

The following theorem shows that (1) the set of attributes an un-corrupted key can have in FKM is determined by the attribute policygraph (2) there are exactly three ways to corrupt a key and (3) kufunctionalities receive the corrupt message only if a key is corrupted

Theorem 2 ( Properties of FKM) Every instance of FKM with parame-ters FC Π and session parameters UUext STRoom has the followingproperties

(1) At any step of an execution of [FKM AD Z] the following holdsfor FKM For all Store[Uh] = 〈F a c〉 such that c 6isin Kcor thereis a node a prime marked new in the attribute policy graph AΠF

such that a is reachable from a prime in AΠF and there was a stepnew where Store[U prime h prime] = 〈F a prime c〉 was added

(2) At any step of an execution of [FKM AD Z] the following holdsfor FKM All c isin Kcor were either

130 analysis of the key-management functionality

a) directly corrupted there was a corrupt step triggered by aquery 〈corrupt h〉 from U while Store[Uh]= 〈F a c〉 orindirectly that is

b) corrupted via wrapping there is c prime isin Kcor such that at somepoint the wrap step was triggered by a message 〈wrap h prime h

id〉 from U while Store[Uh prime]= 〈KW a prime c prime〉 Store[Uh]=〈F a c〉 or

c) corrupted via unwrapping (injected) there is c prime isin Kcor suchthat at some point the unwrap step was triggered by amessage 〈unwrap h prime w a F id〉 from U while Store[Uh prime] =

〈KW a prime c prime〉 and c = unwrap〈Faid〉c prime (w) for some a F and id If

this step did not return lterrorgt then at the point in timethis step was triggered c isin Kcor (it was corrupted before)or c 6isin K (k was created outside FKM)

(3) At any step of an execution of [FKM AD Z] the following holdsWhenever an ideal machine Fi = 〈ideal 〈sid 〈Fi F〉〉〉 withF = 〈〈regF〉〈sid〉〉 accepts the message 〈corrupt c〉 for some csuch that FKM in session sid has an entry Store[Uh] = 〈Fi a c〉then c isin Kcor in FKM

Proof We proof each property separately

(1) Proof by induction over the number of epochs since FKMrsquos firstactivation t If t = 0 Store is empty t〉0 Since the propertywas true in the previous step there are only three steps we needto look at If a key 〈F a c〉 is added to Store at step new thenit is created only if the policy contains an entry (F newa) i ea itself is a new node If a key 〈F a c〉 is added to Store at stepunwrap let 〈unwrap h1 wF id〉 be the arguments sent by a userU and Store[Uh1]= 〈KW aw cw〉 If c 6isin Kcor then cw 6isin Kcortoo and thus there is an entry 〈c 〈F a id〉 w〉 isin encs[cw] Thearray encs is only written in wrap therefore there was a position[U prime h prime] in the store such that Store[U prime h prime]=〈F a c〉 Using theinduction hypothesis we see that a is reachable in the attributepolicy graph The third and last step where the store is writtento is AttributeChange If this step alters the attribute from a prime

to a there must have been an entry (F attr_change a prime a) isin ΠBy induction hypothesis a prime is reachable from a new node andhence a is too

(2) A credential c is only added to the set Kcor in three steps If itis added in corrupt then a message 〈corrupt h〉 was receivedfrom U isin U and Store[Uh]=〈F a c〉 If it was added in wrapthen a message 〈wrap h1 h2〉must have been received fromU isin

U while Store[Uh1]= 〈KW a1 c1〉 and c was reachable fromc1 Let c prime be the last node on the path to c c prime isin Kcor because

92 limitations 131

it is reachable from c1 too Since (c prime c) isinW there was anotherwrapping query 〈wrap h prime h id〉 with Store[Uh prime]= 〈KW a prime c prime〉

and Store[Uh]= 〈F a c〉 Since entries in the store are neverdeleted (only the attribute can be altered) and credentials arenever removed from Kcor the property holds in this case If itwas added in unwrap then c 6isin K at that point in time and c =unwrap

〈Faid〉c prime (w) 6= perp Furthermore we observe that the condi-

tionals prior to adding c to Kcor require that Store[Uh prime]=〈KWa prime c prime〉 c prime isin Kcor and that the step was triggered by a message〈unwrap h prime w a F id〉 If c isin K Kcor then 〈error〉 is outputsince c is only added to Kcor if c isin K (thus the first subbranchis not taken) and c isin K cupKcor (thus the first and second sub-branch are not taken)

(3) Ii accepts only messages coming from the party F and F inturn only accepts messages coming from FKM Therefore wecan conclude from the definition of step corrupt in FKM thatc isin Kcor

92 limitations

Before we discuss FKM and to what extend it achieves our goals fromChapter 6 we discuss the limitations of the key-management func-tionality we have presented in this chapter

architecture of the network One of the key features of thekey-management functionality FKM is that it is able to abstract a net-work of security APIs as one monolithic block that verifies accordanceto a policy before every step it takes This ensures that the policy is re-spected on a global level as the first statement of Theorem 2 and thedefinition of FKM show Different instantiations of FKM with differ-ent parameters e g in terms of the policy and the ku functionalitiessupported may coexist in the same network but they may not sharethe same keys

In practice this means that the enforcement of a global policy canonly extend to a set of security APIs in the network that are similarlyconfigured in particular that offer the same interface to the outsideThis is for example the case if each department in an organisationhas an identical HSM that manages the departmentrsquos keys but alsoshares some common key used for backup and key-transfer If one ofthe HSMs offers a command that the other HSMs do not support thenit is (in general) not possible to abstract those HSMs using the sameinstance of FKM Since the key-transfer in the setup phase is limitedto the same instance of FKM those HSMs cannot share keys with eachother One such example is the Yubikey protocol from Chapter 4

The Yubikeys in the network and the YubiHSM provide a completelydifferent interface but need to share the AES keys in order to run theprotocol

In summary our approach is limited to cases where the securityAPIs in a network offer the same interface i e where the environ-ment is homogeneous

key-transport Currently FKM is tightly coupled with the em-ployment of a deterministic symmetric and authenticated encryp-tion scheme that is secure against key-dependant messages for keyexport and import While practitioners indeed favour deterministickey-encryption in protocol design and standardization efforts (seee g RFC 3394) it restricts the analysis to security devices provid-ing this kind of encryption We have not yet covered asymmetricencryption of keys in FKM (but we cover asymmetric encryption ofuser-supplied data) although FKM could be extended to support thisoption An even better alternative than extending FKM to support dif-ferent ways of key-transfer would be to introduce a more conceptualview of transferring keys A key-management functionality wouldsupport an interface that allows the environment to give the instruc-tion to transfer a key from one security API to another but send thewrapping of the key or whatever piece of information is transferredon a public channel i e to the adversary as opposed to the envi-ronment The adversary is free to relay the message to the securityAPI which is supposed to receive the message In case he does theenvironment only receives a simple acknowledgement from the userconnected to the receiving token The machines in U would imple-ment this more abstract interface depending on what mechanism theactual security APIs employs This way we could formulate FKM

without specifying how exactly keys are transferred

key-usage The access that key-usage functions have on keys isvery limited They can compute an algorithm that uses the value ofthe key some untrusted input provided by the user or the adversaryand randomness This is a realistic assumption for general purposesecurity APIs such as PKCS11 but not for security APIs that are de-signed for a specific protocol like the Yubikey The Yubikey can beset up with an AES key Upon a query it computes the encryption ofa OTP that contains a running counter Due to the design of FKM it isnot possible store the last counter value so FKM is not useful for theanalysis of the security of a set of Yubikeys in the network It wouldonly be possible to compute the encrypted OTP given the key and thecounter value as an input but the counter cannot be trusted unless itis stored on the device itself

On the other hand it is this restriction the strict separation be-tween key-management and key-usage that allows us to achieve the

93 discussion 133

result in Chapter 10 which shows a generic implementation of thekey-management secure with respect to arbitrary ku functionalitiesIt might be possible to achieve the same result with a redesign ofFKM that supports an additional store for payload values similar tothe store for credentials which might be used in each ku functionalityIn the case of the Yubikey this would allow storing the last countervalue on the device

commitment problem Adaptive corruption of parties as wellas adaptive corruption of keys that produce an encryption provokesthe well-known commitment problem [50] This requires us to placelimitations on the types of corruptions that the environment may pro-duce

93 discussion

In the Chapter 6 we gave five qualities which we think a persuasivedefinition of security should possess For each of those desideratawe will now discuss whether is satisfied by the definition of provablysecure key-management in the GNUC model presented in Chapter 8

It should set out the essential attributes of what it defines

Our definition quite clearly defines the aspects of the use of a securityAPI that are relevant for key-management The characteristics of asecurity API are set out through the interface FKM provides Firstthat it provides an interface to cryptographic keys that are stored insome secure memory Second that this interface allows to indirectlyuse this keys to compute cryptographic functions possibly dependingon one (but for the ku functions not more than one) randomness andthe userrsquos input Third the access to those secrets can be restrictedusing the policy

The characteristics of the security of security APIs are set out aswell First it does not reveal secrets to the user (unless a key is cor-rupted in which case the adversary learns those secrets) Secondthe cryptographic functions are secure which is defined by the corre-sponding ku functionality Third the intended access restrictions tothe secrets defined in the policy Π are respected Fourth the previ-ous properties hold in a network where the user might be maliciousand where several security APIs might be present and might containthe same secrets through the use of the GNUC framework and thesupport for party corruption

Finally the concept of credentials sets out quite well which at-tributes are essential for a key and how keys can be handled insimulation-based security frameworks

It should not be too wide e g it should not include secu-rity APIs that are insecure

Theorem 2 gives some indication that this is achieved but carefulinspection of FKM is necessary to validate this claim

It should not be too narrow

As pointed out in the previous section there are a number of limita-tions to our approach some of which exclude certain kinds of APIsin particular security APIs that focus less on key-management andmore on providing some protocol-specific functionality One can ar-gue that security results for the latter kind of security APIs are likelyto be protocol dependant as well

The key-management functionality presented is not as general asour approach would allow it could be extended to allow for differ-ent kinds of key-transportation for different kinds of ku functional-ities etc as we pointed out in the previous section However theapproach of separating key-management and key-usage combinedwith composability features of the underlying framework allow usto reason about the security of the key-management and key-usagewhile keeping the definition flexible in this regard which we regardas a promising starting point for future work

It should not be obscure

Definitions in simulation-based security frameworks such as the onewe employ in this work GNUC are notorious for being long and fullof technical details The definition of FKM is no exception in this re-gard it might even be worse than most functionalities The fact thata theorem like Theorem 2 is necessary to convince the reader of thesoundness of the definition illustrates the obscurity of FKM In the fol-lowing we will try justify the obscurity of FKM but we acknowledgethe fact that it is indeed difficult to read and understand

First many functionalities in simulation-based security suffer fromthis problem often due to the definition of efficiency in the frame-work Most existing frameworks perhaps with the exception of theabstract cryptography framework by Maurer and Renner [67] pro-vide their composability results on very low level of abstraction sothat technical details like the scheduling the runtime of the proto-col etc are necessary to obtain a security result The initialisationphase Section C1 to give an example is the result of such a tech-nical requirement Fortunately since the first proposal by Canettiin 2001 [22] simulation-based security frameworks have been andnow in 2013 still are an active subject of research [63] leading tocontinuous improvements [23 51 84 67 63] We hope that futureframeworks allow for presenting functionalities like FKM in a moreconcise manner In particular the initialisation procedure of the net-work (see Section C1) as well as the communication between FKM

and its ku functionalities (see Definition 28) are obscured due to tech-nical requirements of the framework

93 discussion 135

Second defining the security of key-management in this setting is

a challenging task It took year to obtain a satisfactory formulationof digital signature took years and repeated revision due to by subtleflaws making the functionality unrealizable [24 23 8] FKM preservesauthenticity in a similar way to this signature functionality but ina multi-session setting So we must expect a key-management func-tionality to be at least as complex Previous definitions of security forsecurity APIs in terms of games are a matter of several pages too [5821](but still more concise)

Third as FKM is the first formulation of a functionality of its kindit is only natural that there is room for improvement We hope thatthis work sparks interest for future work which might enhance theclarity of this work

Security definitions should be applicable

A definition in the UC framework can be applicable in two sensesFirst it can be used to evaluate the security of a protocol In Chap-ter 10 we show that FKM can be used to show a generic implementa-tion of key-management secure Second it can be used to help show-ing the security of higher-level protocols that make usee g of onesecurity tokens per participant Using the composition theorem theset of security tokens used by the participants can be substituted byan instance of FKM which provides for example the properties shownin Theorem 2

10P R O O F O F E M U L AT I O N

We show that for arbitrary ku parameters FC Π the security tokennetwork described in Chapter 8 πFCΠImpl consisting of the set ofusers U connected to security tokens ST the set of external users Uext

and the functionality Fsetup emulates the key-management function-ality FKM We achieve this result in two steps which we describe intwo lemmas The first step shows that the key-management func-tionality FKM can be implemented by a similar functionality whichinstead of calling a ku functionality Fi calls the functions ImplFi

that define a key-manageable implementation of Fi The resulting

functionality Fimpl

KM = FF1ImplF1

FlImplFl

KM acts as a ldquobigrdquo machinethat all users in U access just like FKM but instead of substitutingkeys by credentials and forwarding requests to the ku functionalitiesFimpl

KM computes the output itself using the implementation functionsin ImplF1

ImplFl Now the translation from credentials to keys

(which takes place in the key-manageable implementations) is notnecessary anymore and consequently F

KM stores keys instead ofcredentials

In the second step we show that the computations that Fimpl

KM per-forms can be distributed The security token network πFCΠImpl

performs the same computations on the key-usage part that Fimpl

KMperforms but implements the key-management part including key-wrapping and unwrapping using the algorithms implKW

new wrap and

unwrap Under the assumption that those three algorithms consti-tute a secure and correct key-wrapping scheme we can show thatπFCΠImpl implements F

KM and hence by transitivity of the emula-tion relation πFCΠImpl emulates FKM

The first step is subsumed by the following lemma

Lemma 6 Let FC Π be ku parameters such that all F isin F are key-manageable Let further ImplFi

be the set of functions defining the

key-manageable implementation Ii of Fi Then FF1ImplF1

FlImplFl

KMemulates FKM Furthermore it is poly-time

Proof Sketch (Full proof in Appendix D) Making use of the compositiontheorem the last functionality Fl in FKM can be substituted by its key-manageable implementation IL Then FKM can simulate Il instead of

calling it Let FFlIl KM be the resulting functionality In the next step

calls to this simulation are substituted by calls to the functions usedin Il i e implC for each C isin Cl ndash so instead of addressing the sim-ulation of Il with the credentials the function implC is called withthe key that the credential would otherwise be mapped to The re-

138 proof of emulation

sulting partially implemented functionality FFlImplFl

KM saves keysrather than credentials (for Fl) We repeat the previous steps un-til FKM does not call any ku functionalities anymore i e we have

FF1ImplF1

FnImplFn

KM i e Fimpl

Before we come to Lemma 7 which describes the last step weneed to define what we understand under a key-wrapping schemeWe took the definition by Kremer et al [58] as a basis which is basedon the notion of deterministic authenticated encryption by Rogawayand Shrimpton [86] but additionally supports key-dependant mes-sages In contrast to the definition by Kremer et al we allow wrap-ping the same key with the same wrapping key but under differentattributes which is also permitted in Rogaway and Shrimptonrsquos defi-nition

Definition 31 (Multi-user setting for key wrapping) We define exper-iments Expwrap

AKW(η) and ExpwrapfakeAKW (η) for a key-wrapping scheme

KW = (KGwrap unwrap) In both experiments the adversary can ac-cess a number of keys k1 k2 kn (which he can ask to be cre-ated via a query NEW) In his other queries the adversary refers tothese keys via symbols K1 K2 Kn (where the implicit mappingshould be obvious) By abusing notation we often use Ki as a place-holder for ki so for example wrapaKi

(Kj) means wrapaki(kj) We now

explain the queries that the adversary is allowed to make and howthey are answered in the two experiments

bull NEW(Ki) a new key ki is generated via ki larr KG(η)

bull ENC(Ki am) where m isin K cup Ki | i isin N and h isin H Theexperiment returns wrapaki

bull TENC(Ki am) where m isin K cup Ki | i isin N and a isin HThe real experiment returns wrapaki

(m) whereas the fake exper-

iment returns $|wrapaki(m)|

bull DEC(Ki a c) the real experiment returns unwrapaki(c) the fake

experiment returns perp

bull CORR(Ki) the experiment returns ki

Correctness of the wrapping scheme requires that for any k1 k2 isinK and any a isin H if clarr wrapak1

(k2) then unwrapak1(c) = k1

Consider the directed graph whose nodes are the symbolic keys Ki

and in which there is an edge from Ki to Kj if the adversary issues aquery ENC(Ki a Kj) We say that a key Ki is corrupt if either the ad-versary corrupted the key from the start or if the key is reachable inthe above graph from a corrupt key If a handle respectively pointerpoints to a corrupted key we call the pointer corrupted as well

We make the following assumptions on the behaviour of the adver-sary

proof of emulation 139

bull For all i the query NEW(Ki) is issued at most once

bull All the queries issued by the adversary contain keys that havealready been generated by the experiment

bull The adversary never makes a test query TENC(Ki a Kj) if Ki iscorrupted at the end of the experiment

bull If A issues a test query TENC(Ki am) then A does not issueTENC(Kj a

primem prime) or ENC(Kj aprimem prime) for (Ki am) = (Kj a

primem prime)

bull The adversary never queries DEC(Ki a c) if c was the resultof a query TENC(Ki am) or of a query ENC(Ki am) or Ki iscorrupted

At the end of the execution the adversary has to output a bit b whichis also the result of the experiment The advantage of adversary A inbreaking the key-wrapping scheme KW is defined by

AwrapKWA(η) =

∣Pr[

blarr ExpwrapKWA(η) b = 1

blarr ExpwrapfakeKWA (η) b = 1

and KW is secure if the advantage of any probabilistic polynomialtime algorithm is negligible

The second and last step assumes a key-wrapping scheme that issecure with respect to this definition It is subsumed by the follow-ing lemma which shows that the completely implemented but stillmonolithic functionality F

KM can be emulated by a set of securitytokens each only managing the set of keys that belongs to its asso-ciated user A necessary condition is that a secure and correct key-wrapping scheme is used In this step we need to restrict the set ofenvironments to those which guarantee that keys are not corruptedafter they have been used to wrap Otherwise we would provokethe commitment problem [50] To formally define this class of envi-ronments we introduce the notion of a guaranteeing environment anda predicate on the inputs and outputs an environment receives andsends in a given execution which is called corrupt-before-wrap Bothcan be found in Appendix D

Lemma 7 For any ku parameter FC Π and set of sets of PPT al-

gorithms Impl let FF1ImplF1

FlImplFl

KM be the partial implementa-tion of FKM with respect to all ku functionalities in F If KW =

(implKWnewwrap unwrap) is a secure and correct key-wrapping scheme

(Definition 31) then πFCΠImpl emulates Fimpl

KM for environments thatguarantee corrupt-before-wrap

Proof sketch (Full proof in Appendix D) This lemma is proven using areduction to the security of the key-wrapping scheme We show thatany environment that is able to distinguish πFCΠImpl from F

KM can

be transformed into an adversary against the fake-or-real game de-scribed in Definition 31 Fix such an environment Z We first haveto show that an attacker we construct from Z which we call BZ isvalid with respect to the fake-or-real game i e that it does not re-peat queries etc Then we show that the distinguishing environmentZ interacting with F

KM and a (carefully crafted) simulator has thesame output distribution as BZ in the fake experiment and that Zinteracting with πFCΠImpl and a dummy adversary has the sameoutput distribution as BZ in the real experiment This allows us toconclude that a distinguishing environment Z would imply a distin-guishing attacker for the key-wrapping game and thus contradict theassumption that KW is secure and correct

The main result follows from the transitivity of emulation and Lem-mas 6 and 7

Corollary 1 Let FC Π be ku parameters such that all F isin F arekey-manageable Let ImplFi

be the set of functions defining the key-manageable implementation Ii of Fi If KW = (implKW

newwrap unwrap)

is a secure and correct key-wrapping scheme (see Definition 31) thenπFCΠImpl emulates FKM for environments that guarantee corrupt-

before-wrap

11A S I M P L E C A S E S T U D Y

To demonstrate the use of our main result we will instantiate thegeneric reference implementation of a security API presented in Chap-ter 8 with a policy and two functionalities If the functionalities arekey-manageable then by Corollary 1 from the previous chapter wehave a concrete implementation that is secure with respect to our def-inition We furthermore demonstrate how two security token usingthis implementation can be employed in a higher-level protocol toimplement an authenticated channel

111 realizing FKM for a static key-hierarchy

We equip the security token with the functionalities F1 = FRand andF2 = FSIG described below The resulting token STFRand FSIG is ableto encrypt keys and random values and sign user-supplied data It isnot able to sign keys as this task is part of the key-management Thefirst functionality FRand is unusual but demonstrates what can bedone within the design of FKM as well as its limitations It modelshow random values can be stored as keys with equality tests andcorruption which means here that the adversary learns the value ofthe random value Since our framework requires a strict division be-tween key-management and usage they can be transmitted (usingwrap) and compared but not appear elsewhere since other ku func-tionalities shall not use them We define FRand as follows

new accept ltnewgt from parentId (=p)

clarr 0 1η Llarr Lcup (c 0) send ltnewbullcgt to p

command accept ltequalcngt from p

if (c k) isin L for some k

if k 6isin Kcorsend ltequalbullfalsegt to p

else if n = k

send ltequalbulltruegt to p

corrupt accept ltcorruptcgt from p

if (c 0) isin Lklarr 0 1η

Llarr (L (c 0) )cup (c k) Kcor = Kcor cup k send ltcorruptbull kgt to A

inject accept ltinjectngt from P

(c_) larr 0 1η

Kcor larr Kcor cup n

Llarr Lcup (c n) send ltinjectbullcgt to parentId

142 a simple case study

The two functions implnew

and implequal

give the key-manageableimplementation implnew on input 1η gives output (n _) for n larr0 1η impl

equalon input nn prime gives output n = n prime

The digital signature functionality is designed after the one de-scribed in [62] and detailed in Listing 10 It is parametrized bythree algorithms KG sign and verify It expects the session parame-ter to encode a machine ID P and implements Cpriv = sign andCpub = verify

Listing 10 A signature functionality FSIG

new accept ltnewgt from P

(sk vk)larr KG(1η) (credential_) larr KG(1η)

Llarr Lcup (credentialskvk)

send ltnewbullcredentialvkgt to P

sign accept ltsigncredentialmgt from P

if (credentialskvk)isinL for some key

σlarr sign(skm)

if verify(vkm σ) 6= perpand sk 6isin Kcorsigns[vk]= signs[vk] cup (mσ)

else σlarr perpsend ltsignbullσgt to P

verify accept ltverifyvkltmσgtgt from P

blarr verify(vkm σ)if existc sk (cskvk)isinL and sk isin Kcor and b = 1 and

6 existσ prime (mσ prime) isinsigns[vk] or b 6isin 0 1

blarr perpsend ltverifybullbgt to P

corrupt accept ltcorruptcredentialgt from P

if (credentialskvk)isinL for some sk vkKcor larr Kcor cup sk send ltcorruptbullskgt to A

inject accept ltinjectltsk vkgtgt from P

(c_) larr KG(1η) Kcor larr Kcor cup skLlarr Lcup (c sk vk) send ltinjectbullcgt to parentId

In the following we will consider FKM for the parameters F = FRand

FSIG C = equal sign verify and a static key-hierarchy Πwhich is defined as the relation that consists of all 4-tuples (FCmdattr1 attr2) such that the conditions in one of the lines in the fol-lowing table holds Note that we omit the ldquo=rdquo sign when we meanequality and ldquordquo denotes that no condition has to hold for the vari-able

F Cmd attr1 attr2KW new gt 0

6= KW new 0

attr_change a a

KW wrap gt 0 attr1 gt attr2KW unwrap gt 0 attr1 gt attr2Fi C isin Cpriv 0

112 an example implementation of the authenticated channel functionality 143

(where a isinN)

Theorem 2 allows immediately to conclude some useful propertieson this instantiation of FKM From (1) we conclude that all keys withc isin Kcor have the attribute they were created with This also meansthat the same credential always has the same attribute no matterwhich user accesses it From (2) we can see that for each corruptedcredential c isin Kcor there was either a query 〈corrupt h〉 whereStore[Uh]= 〈F a c〉 or there exist Store[Uh prime]= 〈KW a prime c prime〉 andStore[Uh]= 〈F a c〉 and a query 〈wrap h prime h id〉 was emitted forc prime isin Kcor or an unwrap query 〈unwrap h prime w a F id〉 for a c isin Kcor

was emitted By the definition of the strict key-hierarchy policy in thelatter two cases we have that a prime gt a It follows that for any creden-tial c for F such that Store[Uh] = 〈F a c〉 for some Uh and a wehave that c 6isin Kcor as long as every corruption query 〈corrupt hlowast〉at U was addressed to a different key of lower or equal rank key i eStore[Uhlowast] = 〈KW alowast clowast〉 clowast 6= c and alowast 6 a By (3) those creden-tials c isin Kcor have not been corrupted in their respective functionalityi e it has never received a message 〈corrupt c〉

112 an example implementation of the authenticated

channel functionality

The following implementation of the authenticated channel function-ality Fach from the introduction may serve as an example on how touse FKM in a protocol We repeat the definition of Fach from Chapter 7

send ltdonegt to P

The idea is the following Two parties the sender and the recip-ient use the set-up phase to generate a shared signature key Therecipient creates this signature key stores the public part shares theprivate part which is hidden inside FKM with the sender and thenannounces the end of the set-up phase At some later point when

the sender is instructed to send a message it attaches the signature tothe message The recipient accepts only messages that carry a validsignature which she can verify using the public part of the sharedsignature key Obviously a similar implementation without the key-management functionality FKM is possible (although other means ofpre-sharing signature keys or MAC keys for that matter would berequired) However our aim is to provide a very concise use caseFormally the protocol πach defines three protocol names proto-achproto-fkm and proto-sig πach(proto-sig) is defined by the signa-ture functionality FSIG πach(proto-fkm) is defined by FKM for the pa-rameters F = FSIG C = signverify and a static key-hierarchyΠ as defined in the previous section πach(proto-ach) parses the ses-sion parameter as a tuple 〈Ppid Qpid label〉 where label is used to dis-tinguish different channels and Ppid Qpid to identify the sender andthe recipient Let sid be the session ID Then we will use P to denote〈Ppid sid〉 and Q to denote 〈Qpid sid〉 As we want to keep the exam-ple simple we do not model party corruption The following codedefines the behaviour of the sender P

ready-sender accept ltreadygt from parentId

call FKM with ltreadygt

import[ready-sender] accept ltsharebullh primegt from FKM hprimelarr h prime

call FKM with ltfinish_setupgt

send[import] accept ltsendxgt from parentId

call FKM with ltsignhprimexgt accept ltsignbullσgt from FKM

send ltx σgt to A

send ltdonegt to parentId

When we say that P calls FKM we mean that P sends a message to〈Ppid 〈sid 〈protminus fkm 〈UUext STRoom〉〉〉 where U = PQ Uext =

Q Room = PQ and ST any two regular peers of P and Q butnot P and Q themselves Similar for the receiver Q

ready-receiver

accept ltreadygt from parentId call FKM with ltreadygt

accept ltproceedgt from A call FKM with ltnewFSIG0gt

accept ltnewhvkgt from FKM

hlarr h

vklarr vkcall FKM with ltsharehgt

deliver[ready-receiver]

accept ltdeliverxσgt from A

call FKM with ltverifyvkltx σgtgtaccept ltverify1gt from FKM

send ltdeliverxgt to parentId

The following lemma makes use of the fact that FKM provides anauthentic way to share keys during the set-up phase and that FSIG

outputs 〈verify 1〉 only if the corresponding message was ldquoregis-teredrdquo before

Lemma 8 πach emulates Fach

Proof We have to show that there exists a simulator Sim boundedfor Fach and that for every well-behaved environment Z rooted atprot-fach

Exec[πach AD Z] asymp Exec[FachSim Z]

We define the following simulator Sim

ready-sender

accept ltsender-readygt from ltidealgt

send ltFKMltreadybullPgtgt to ltenvgt

faux-ready-receiver[notready-sender]

accept ltready-receiver-earlygt from ltidealgt

send ltFKMltreadybullQgt to ltenvgt

accept ltQproceedgt from ltenvgt

send ltFKMerrorgt to ltenvgt

ready-receiver[ready-sender]

accept ltreceiver-readygt from ltidealgt

send ltFKM ltreadybullQgtgt to ltenvgt

sk vklarr KG(1η)

send ltFKMltfinish_setupbullgtgt to ltenvgt

send [ready-receiver]

accept ltsendxgt from ltidealgt

σlarr sign(sk x)send ltPltxσgtgt to ltenvgt

done [send]

accept ltPdonegt from ltenvgt

send ltdonegt to P

faux-deliver[ready-receiverandnotsend]

accept ltQltdeliverxσgtgt from ltenvgt

send ltQerrorgt to ltenvgt

deliver[send]

if σ = σ

send ltdeliverxgt to ltidealgt

accept ltPerrorgt from ltidealgt

send ltPerrorgt to ltenvgt

Let us fix the session ID sid and assume it is of the form 〈sid prime

〈prot-ach 〈Ppid Qpid label〉〉〉 Let P = 〈Ppid sid〉 and Q = 〈Qpid

sid〉 First we show that Sim is bounded for Fach It is trivial to verifythat Sim is time-bounded since KG and sign are assumed to be Everyflow from Sim to Fach is provoked by an input from the environmentand the length of the message from Sim to Fach is polynomially re-lated to the length of the message from the environment to Sim

Next we show that for every well-behaved environment Z rootedat prot-fach Exec[πach AD Z] = Exec[FachSim Z] by showing astronger invariant

At the end of each epoch the following conditions hold true

1 The view of Z is the same in [πach AD Z] and [FachSim Z]

2 If Fach has finished a step S in [FachSim Z] Sim has finished thesame step and in [πach AD Z] either P or Q has finished S

Induction over the number of activations of Z In the base case Zhas not called any party so the invariant holds trivially Now assumethe invariant held true at the end of the previous activation of Z afterwhich Z sends a message m to some party We have to show theinvariant to hold true when this new epoch is over i e Z is activatedagain Case distinction over the steps that were completed by Fach in[FachSim Z] before Z emittedm Note that the guards define a partialorder of the steps therefore it is sufficient to perform the distinctionover the last completed step

1 Fach has not finished any step yet If Z sends m = 〈ready〉 toP then in [FachSim Z] Sim will translate Fachrsquos response into〈FKM 〈ready

bull P〉〉 which is what Z would receive in [πach AD

Z] due to the definition of FKM If Z sends the message to Qinstead in [FachSim Z] an error message is sent to Sim as theguard for the step ready-receiver would not be fulfilled Byinduction hypothesis Sim is in the same state as Fach and there-fore simulates the error that FKM would send out in [πach AD

Z] because it receives a share query from Q without havingreceived ready from P before ndash otherwise Z would have sentready to P and then Fach would have finished this step If anyother message is sent FKM sends an error message to Sim whoforwards it to Z just like AD does in [πach AD Z]

2 Fach has finished ready-sender If Z sends m = 〈ready〉 to Qin [πach AD Z] it will receive 〈FKM 〈ready

bull Q〉 from AD Sim-ilarly in [FachSim Z] Sim would wait for the same response toproceed If Sim and Q in πach were in this step before Z sendsm and m = 〈Q proceed〉 then in [πach AD Z] Q would cre-ate a key on FKM and save the handle as well as the publicpart Before Zrsquos next activation FKM would activate P on stepimport which would store the same handle (by definition ofFKM) and finish the setup phase producing as only observableoutput to Z the message 〈FKM finish_setupbull〉 In [FachSim Z]Sim draws the secret and public part of the key itself (with thesame algorithm KG that FSIG uses which is called by FKM) Itwould then produce the same output to Z Any other messagem would result in an error-message and treated as describedbefore

3 Fach has finished ready-receiver If Z sends m = 〈send x〉 toQ then Z would receive 〈P 〈x σ〉〉 for an equally distributedσ in both networks [πach AD Z] and [FachSim Z] since as

mentioned before the value at the key-position is equally dis-tributed If Z sends m = 〈Q 〈deliver x σ〉〉 to Sim it receives〈Q error〉 as response In [πach AD Z] AD forwards this to Qwho queries FKM Because deliver was not executed yet thearray signs in FSIG is empty Since vk was created in FSIGFKM

(since by induction hypothesis ready-receiver also holds inπach) and no corruption message is emitted by any party in πachthe response from FSIGFKM cannot be 〈verifybull 1〉 Thereforethe second accept step in deliver in Q fails and 〈Q error〉 isoutput just as in [FachSim Z] Any other message m wouldresult in an error-message and treated as described before

4 Fach has finished send If m = 〈P done〉 is send to AD in [πach

AD Z] Z receives 〈done〉 from P In [FachSim Z] Sim translatesthis to 〈done〉 which Fach relays to the same response via thedummy party P If Z sends m = 〈Q 〈deliver x σ〉〉 to AD in[πach AD Z] it receives 〈deliver x〉 from Q but only in casethat Z has sent a message 〈send x〉 to P earlier when P wasin state import and gave the output 〈x σ〉 to AD since FSIG

keeps a list of previously signed message and their signaturesIn [FachSim Z] by definition of Sim and Fach Z receives thesame response from Q if x is the same x in a 〈send x〉 queryaccepted earlier and σ is the output produced by Sim beforeforwarding Since FKM may have only accepted such querieswhen ready-receiver was finished and done or deliver werenot yet called this corresponds to the same input z in [πach AD

Z] Any other message m would result in an error-message andtreated as described before

5 Fach has finished deliver No messages are accepted anymore(i e they lead to error-messages)

C O N C L U S I O N

12C O N C L U S I O N A N D P E R S P E C T I V E S

The interface between trusted code in an enclosed environment suchas for example a security token and untrusted code on the outside iscalled a security API Security APIs are often used as a means to makeother protocols more resistant against the corruption of protocol par-ties The idea is to protect sensitive data from a potentially untrustedldquooutsiderdquo since a security token is simpler than a general-purposesystem and designed with the intent of providing security Thoroughsecurity analysis is indispensable for achieving this goal

There are two orthogonal objectives for security analysis which wehave investigated in this thesis First there is the security of whateverprotocol makes use of the security API What security goals need tobe achieved in this context depends of course on the protocol Sec-ond there is the security of the security API itself As the designerof a security API can hardly predict all possible contexts in which hissecurity API will be employed a definition of security is necessary tohelp guiding the design of the security API as well as its implemen-tation and provide evaluation criteria for both

121 analysis of protocols using security apis

Previous work has identified a promising approach to establish secu-rity guarantees of protocols that employ security APIs Modelling thesecurity APIs as ordinary protocol parties it is possible to use tradi-tional protocol verification tools for analysis However as we pointedout in Chapter 3 security APIs are typically stateful they contain adatabase that stores cryptographic keys and additional attributes tothose keys As opposed to typical network protocols this means thata protocol execution is stateful and more importantly the state ismutable and non-monotonic The approach of using Horn clause res-olution to perform protocol verification which is very successful forordinary protocols leads to false attacks in this case since it is basedon the (sound but not complete) abstraction that protocol actions canbe repeated arbitrarily often Despite some efforts being put into in-corporating parts of the state into the horn-clause representation ofthe protocol these limitations are still present as we have shown ina thorough evaluation of those approaches in Chapter 3

In Section 36 we argued that multiset rewrite rules are bettersuited as a back-end for the analysis since they model causal relation-ships more accurately In Chapter 4 we gave support to this claimby presenting a case study in which we show the absence of replay

152 conclusion and perspectives

attacks in a protocol based on a security token the Yubikey protocolin the formal model The verification of this protocol was particularlychallenging because it involves storing values which need to be com-pared to each other An analysis of this protocol had been attemptedbefore using protocol verification tools based on Horn clauses aswell as a model-checking approach but in contrast to the presentwork it was previously only possible for a fixed number of noncesWe furthermore modelled an extension to this protocol that makesuse of a second different security token and showed that an attackon this protocol is possible but also how this attack can be thwartedOur results has been obtained using multiset rewriting and providesformal results on both the Yubikey protocol and its extension in anunbounded model

Building on the experience with this modelling we recognized theneed for a protocol representation which is closer to an actual imple-mentation yet still abstract A manual encoding of protocols usingmultiset rewrite rules is a difficult process Deriving a model thatis accurate with respect to concurrent runs of processes and is ableto recognises locking issues is possible however it is a tedious anderror-prone task that requires a great deal of expertise to be donecorrectly To remedy this shortfall we introduced a calculus that canserve as a front-end in Chapter 5 This calculus is especially conve-nient for users familiar with the well-known ProVerif tool It extendsthe applied pi calculus with synchronous communication by opera-tors for database access and explicit locking and uses verification onmultiset rewrite rules on the back-end We presented a number ofcase studies to show our toolrsquos use for the analysis of security APIsthe above mentioned Yubikey protocol the examples that we usedfor evaluating Horn-clause resolution approaches in Chapter 3 and afragment similar to the PKCS11 standard

Our translation makes it possible to include the subtle issues thatcan arise in the context of synchronisation and locking in the modelbut keep the amount of time needed to model a protocol small En-coding such models directly in multiset-rewrite rules is tiresome anddifficult to do right

We conclude that the analysis of security APIs benefits from a pre-cise verification procedure which can be provided by using multisetrewriting as a back-end and our calculus and translation to allow fora convenient and versatile modelling of the protocol or security APIin question

Future work

automatic generation of helping lemmas For 4 out of 7

case studies our method required helping lemmas to find a proofThese lemmas are proven automatically but they have to be given

121 analysis of protocols using security apis 153

by the user We would like to further advance the degree of automa-tion in our tool for example as follows We observed that many ofthe helping lemmas we formulated in the course of our case studiesare instances of what Meier Cremers and Basin call the decryption

chain case [73] Their work introduces two invariants which for proto-cols that fall into a certain class help generating machine-checkableproofs of security It might be possible to instantiate these invariantsto a protocol-specific helping lemma given that the protocol is in theright class Due to our approach by translation we have access tothe protocol in a high-level language which gives us more structureto work with as well as in form of low-level rewrite rules that wegenerate ourselves This gives us better control and puts us in a morefavorable situation to automatically generate helping lemmas

loops Certain protocols for example the TESLA protocol [78] con-tain loops There are various ways to model loops in the calculuswe propose First using secret (and thus synchronous) channels andreplication The initial local variable are sent on a secret channeland each process in the replication can pick these values up performsome inputoutput and compute new values If the loop shall con-tinue the new values are emitted on the same channel otherwisea message on a second secret channel permits leaving the loop andproceeding elsewhere Second using insert lookup and lock Theprocedure here is similar but a lock is needed since the store is anasynchronous channel Third using embedded multiset-rewrite rulesand replication Instead of transferring the local variables from pro-cess to process via a secret channel or the store a fact can be used tothe same end The resulting multiset rewrite rules from a translationusing the third method would be quite similar to the modelling ofthe TESLA protocol in tamarin [72] Evaluating these different mod-ellings of loops and if necessary extending the calculus by a loopoperator and finding an efficient translation are possible venues offuture research

equivalence properties Privacy-type properties for examplethe secrecy of a vote in e-voting protocols are naturally formulatedas equivalences between different instances of a protocol Two veryprominent notions of equivalence are labelled bisimilarity and ob-servational equivalence which have been formulated and shown tocoincide in the applied pi calculus [2] As the calculus we propose issimilar to the applied pi calculus adapting these two notions wouldbe quite straight forward To prove the equivalence of two processeshowever a different translation is necessary as tamarin currentlydoes not support equivalence between MSR systems

ProVerif provides support for showing diff-equivalence a strongernotion of equivalence than observation equivalence for processes that

differ only in the choice of some terms [15] While the method issound it sometimes produces false attacks Subsequent work elim-inates some of the false attacks in the case where conditionals areinvolved [26] Both methods essentially translate two processes ofsimilar structure into a set of Horn clauses and a reachability queryFuture work could lift this translation to output multiset rewritingrules instead of Horn clauses possibly using ideas from our currenttranslation to incorporate constructs that are present in our calculusbut not in the applied pi calculus

case studies We see the strengths of the calculus we proposein the analysis of protocols that rely heavily on state such as key-management APIs and will give some possible targets in the follow-ing A modelling of the full PKCS11 standard would be both use-ful in practice and challengeing since security policies for PKCS11

can define recursive datatypes Although this feature is rarely usedin practice an automated analysis could possibly help identifyingnew key-policies with useful properties Academic proposals for key-management APIs that have only been proven by hand so far areof special interest too since they provide security properties thatgo beyond key secrecy As such we would like to mention the key-management API by Cortier Steel and Wiedling [31] which allows forkey-revocation and the key-management API proposed by Daubig-nard Lubicz and Steel [32] which supports public-key cryptography

The TPM standard is another goal for analysis especially since amodelling in our calculus has the potential to lift some restrictionspresent in previous work [35 33 9] for reasons detailled in Chapter 3The new version 20 of the standard is currently in public review [95]and is therefore perhabs the most interesting target for a case study

122 analysis of security apis

In the second part of this thesis we presented a definition that coversa wide range of security APIs and helps assessing the security of a net-work of security APIs This definition uses a framework that allowsfor universal composability which offers the following advantagesFirst security holds in arbitrary contexts Second we can define se-curity for sets of security APIs which enables us to show that a policyis respected globally Third we can use composition to define the se-curity API as a combination of secure key-management and correctimplementations of key-usage tasks Fourth our definition can beused in proofs of higher-level protocols without need for a reductionproof

Our definition differs from previous definitions in this respect asthese were based on real-or-fake games and hence do not benefit fromthese advantage With the exception of the definition proposed by

122 analysis of security apis 155

Kremer et al they are tailored to specific APIs and thereby lack gen-erality In order to formulate the transport of keys in the ldquoideal worldrdquosetting of the universal composability framework we introduced theconcept of credentials randomly drawn strings that allow the delega-tion of access rights to functionalities We introduced our definitionalong with the concept of credentials in Chapter 8

In Chapter 9 we established some properties that this functionalityenjoys and that high-level protocol can benefit from In the samechapter we discussed the limitations to our approach in detail

In Section 84 we demonstrated that our definition can guide thedesign of a generic implementation of key-management This imple-mentation is secure with respect to our definition and can serve as atemplate for the implementation of many security APIs as it is inde-pendent of which functions it is supposed to offer as long as those op-erations are implemented correctly As a consequence adding func-tionality to security APIs that follow this design does not require anew proof A case study in Chapter 11 gave an example on howthe functionality can be instantiated and be used in the analysis of ahigher-level protocol

Future work

generalising key-transport The proposed definition of se-curity can be generalized Currently it is too strict It specifies theway keys are transferred from one device to another very explicitlythereby restricting the possible implementation of this task to deter-ministic symmetric and authentic encryption schemes that allow forkey-dependant messages Future research can explore to what ex-tend key-transport can be captured in a more abstract way makingthe definition applicable to a wider range of security APIs

generalising key-usage The current interface FKM provides tokey-usage functionalities does not allow two keys to interact withanother although it might be safe to do this if the two keys belongto the same key-usage functionalities For some applications like theYubikey protocol it would also be useful to extend key-manageableimplementations to be able to keep some kind of state for example arunning counter which is then exported along with the key Makingthe key-management more powerful in this regard would suggestformulating the policy in a more general way too

making existing functionalities key-manageable Relat-ing key-manageable functionalities to existing functionalities in theliterature could allow reusing existing proofs of emulation Most ex-isting functionalities even those for signature and encryption bindthe permission to perform operations to the identity of some party

This can be seen as unnecessarily restrictive as many implementa-tions could allow exporting keys or even give them to trusted thirdparties like security token

We think it is possible to develop a technique for transformingfunctionalities that have implementations of a certain form but arenot key-manageable into key-manageable functionalities This formdescribes an implementation that stores a single key Our conjec-ture is that if an implementation of this form emulates an ldquoordinaryrdquofunctionality then we can construct a key-manageable implementa-tion that emulates a key-manageable functionality consisting of sev-eral copies of the ldquoordinaryrdquo functionality This way existing proofscould be used to develop a secure implementation of cryptographicprimitives in a plug-and-play manner Investigating the restrictionsof this approach could furthermore provide deeper insight about themodelling of keys in simulation-based security frameworks

case studies Case studies of bigger systems than the examplewe provide in this thesis would be useful in gaining insight into theuse of the definition in practice as well as an assessment of its limita-tions It would be interesting to discover to what extend the PKCS11

standard can be modelled The fact that many PKCS11 configurationsare indeed insecure would suggest using our translation to identify asecure and practical configuration before performing analysis in thecomputational model Features that do not conform our distinctionbetween key-management and key-usage can be excluded in the firstplace e g signatures on keys asymmetric key-wrapping (which inPKCS11 is broken anyway [27]) etc The difficulty of this analysisdepends on the configuration chosen If the configuration entails apolicy that enforces a strict key-separation then the proof can be per-formed in a more modular way The resulting security token networkcan harden other protocols against party corruption which suggestsusing the security network or more precisely the instantiation ofFKM it emulates to to analyse higher-level protocols in typical do-mains where PKCS11 is used e g smart card sign-on mechanismsdisk encryption and protocols like TLS

key transfer in uc using credentials Finally credentialsmight be useful in other contexts where keys can be transferred be-tween protocol parties One example that comes to mind is the mod-elling of protocols that have a key-agreement phase followed by acommunication phase that makes use of this key for example theTLS protocol Hardware accelerators allow for offloading the (com-putationally expensive) processing of the key-agreement phase andleave the server to process (less expensive) symmetric operations ofthe communication phase After the key-agreement phase sessionkey is transferred between two different entities the hardware accel-

erator and the server We think that this interaction is but one ex-ample where the use of credentials for the modelling of key-transferbetween different functionalities appears to produce a very naturalway of abstracting keys

A P P E N D I X

AL I S T I N G S F O R PA RT i

a1 listings for chapter 3

Listing 12 The modelling of Example 4 in StatVerif by Arapinis et al [5]

fun pair2

fun aenc3

fun pk1

4 free left

free right

free init

free c

private free sl

9 private free sr

car(pair(xleft xright)) = xleft

cdr(pair(xleft xright)) = xright

14 adec(u aenc(pk(u) v w)) = w

query attvspair(slsr)

let device =

19 out(c pk(k)) |

( in(c x) lock(s) read s as y

if y = init then

24 ( in(c x) lock(s) read s as y

if y = left then out(c car(adec(k x))) unlock(s)

else if y = right then out(c cdr(adec(k x))) unlock(s)

let user =

29 ν r

out(c aenc(pk(k) r pair(slsr)))

process

ν k ν s [s 7rarr init] | device | user

Listing 13 An attempt to express Example 5 in StatVerif Note that the keystore is modelled as single state cell which refers to a list of keysThis list grows in size for every newly generated key ProVerifdid not terminate on the horn clauses produced by StatVerifrsquostranslation procedure in the experiments we conducted

162 listings for part i

fun pair2

2 fun senc2

free c

free nil

free store

7 reduc

sdec(u senc(u v)) = v

12 query attvskey

let create_proc =

in(cx) ν key ν handle lock

read store as list

17 store = pair(pair(keyhandle)list)

unlock

out(chandle)

let wrap_proc =

22 in(cx) let h1 = car(x) in let h2 = cdr(x) in

read store as list

unlock

out(inputpair(h1list))

27 in(outputk1)

in(outputk2)

if k1 = nil then 0

else if k2 = nil then 0

32 else out(csenc(k1k2))

let fetch_key =

in (inputx) let arg=car(x) in

let list=cdr(x) in

37 let h = car(list) in

let r = cdr(list) in

if arg=car(h) then

out(outputcdr(h))

else if r=nil then

42 out(outputnil)

out(inputpair(argr))

process

47 ν input ν output

ν store

[store 7rarr nil] | create_proc | wrap_proc | fetch_key

Listing 14 A modelling of Example 4 in AIF

A1 listings for chapter 3 163

Problem Leftrightincorrect

not correct the model actually allows the attack

since the same secrets are used for every newly generated

machine middot

5 Types

Secrets slsr

SKsk value

KMXYtoken untyped

10 Sets

init(token)left(token)right(token)

Functions

public senc2 pair2

15 private inv1

iknows1 attack0

20 Rules

the intruderrsquos deduction capabilities

minusrarr iknows(token)

25 iknows(senc(MK)) middotiknows(K) minusrarr iknows(M)

iknows(X) middotiknows(Y) minusrarr iknows(pair(XY))

iknows(pair(XY)) minusrarr iknows(X)

iknows(pair(XY)) minusrarr iknows(Y)

30 Init

35 Set left - or - set right

decryption

40 SKisin left(token) middotiknows(senc(pair(XY)SK)) minusrarr SKisin left(token) middotiknows(X)

Security goal

Listing 15 Another modelling of Example 4 in AIF

1 Problem wrapdec

Secrets slsr

SK value

6 KMXYt untyped

init(t)left(t)right(t)

11 Functions

public senc2 pair2

private sl1 sr1

16 iknows1 attack0

21 iknows(K) middotiknows(M) minusrarr iknows(senc(KM))

minus[SK ]rarr SKisin init(t) middotiknows(senc(SKpair(sl(SK)sr(SK))))

31 SKisin init(t) minusrarr SKisin left(t)SKisin init(t) minusrarr SKisin right(t)

decryption

SKisin left(t) middotiknows(senc(SKpair(XY))) minusrarr SKisin left(t) middotiknows(X)36 SKisin right(t) middotiknows(senc(SKpair(XY))) minusrarr SKisin right(t) middotiknows(Y

Security goal

iknows(sl(SK)) middotiknows(sr(SK)) minusrarrattack

1 Problem Wrapdec

Agents t Agents Token Intruder

Token t one token

KEY HANDLE KEY1KEY2 value

KM untyped

11 store(Token)init(Token)wrap(Token)dec(Token)

Functions

public senc2

private h1

iknows1 attack0

forall Agents middot minusrarr iknows(Agents)

Generate a key

forall Token middot minus[KEY ]rarr iknows(h(KEY)) middotKEYisin store(Token) middotKEYisin init(Token)

31 forall Token middot KEY1isin wrap(Token) middot iknows(h(KEY1)) middot iknows(h(KEY2)) middotKEY1isin store(Token) middot KEY2isin store(Token)minusrarr iknows(senc(KEY1KEY2)) middotKEY1isin wrap(Token) middot KEY1isin store(Token) middot KEY2isin store(Token)

36 SDecrypt

forall Token middotiknows(h(KEY)) middotiknows(senc(KEYM)) middotKEYisin store(Token) middotKEYisin dec(Token)

Security goal

41 forall Token middot KEYisin store(Token) middotiknows(KEY) minusrarrattack

Policy 1

forall Token middot KEYisin store(Token) middot KEYisindec(Token) middot KEYisin init(Token) minusrarrKEYisin store(Token) middot KEYisin wrap(Token)

forall Token middot KEYisin store(Token) middot KEYisinwrap(Token) middot KEYisin init(Token)minusrarr KEYisin store(Token) middot KEYisin dec(Token)

Policy 2

forall Token middot KEYisin store(Token) middot KEYisindec(Token) minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

forall Token middot KEYisin store(Token) middot KEYisinwrap(Token) minusrarr KEYisin store(Token) middot KEYisin dec(Token)

51 Policy 3

forall Token middot KEYisin store(Token) middot KEYisin init(Token) minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

forall Token middot KEYisin store(Token) middot KEYisin init(Token) minusrarr KEYisin store(Token) middot KEYisin dec(Token)

forall Token middot KEYisin store(Token) middot KEYisin dec(Token) minusrarr KEYisin store(Token) middot KEYisin wrap(Token)

56 Bad policy -- attack is reachable middotforall Token middot KEYisin store(Token) middot KEYisin init(Token) minusrarr KEYisin store(

Token) middot KEYisin wrap(Token)forall Token middot KEYisin store(Token) middot KEYisin init(Token) minusrarr KEYisin store(

Token) middot KEYisin dec(Token)forall Token middot KEYisin store(Token) middot KEYisin wrap(Token) minusrarr KEYisin store(

Token) middot KEYisin dec(Token)

Listing 17 Modelling of the Yubikey authentication protocol in tamarinrsquosMSR calculus The counter is modelled as a term constituting amultiset of constants where the cardinality of the multiset equalsthe size of the counter

theory Yubikey

section The Yubikey Authentication Protocol

builtins symmetric-encryption multiset

Initialisation and Setup of a Yubikey

10 rule BuyANewYubikey

[Fr(~k)Fr(~pid)Fr(~sid)]

minus[Protocol() Init(~pid~k)ExtendedInit(~pid~sid~k) ]rarr[Y(~pid~sid) Y_counter(~pid rsquo1 rsquo)

Server(~pid~sid rsquo1 rsquo)SharedKey(~pid~k)15 Out(~pid)]

rule Yubikey_Plugin

[Y_counter(pidotc) In(tc) ]

minus[ Yubi(pidtc) Smaller(otctc) ]rarr20 [Y_counter(pid tc)]

If the Button is pressed the token counter is increased

rule Yubikey_PressButton

[Y(pidsid) Y_counter(pidtc)SharedKey(pidk)

25 In(tc)Fr(~npr)Fr(~nonce) ]

minus[ YubiPress(pidtc) ]rarr[Y_counter(pid tc + rsquo1 rsquo)Out(ltpid~noncesenc(ltsidtc~nprgtk)gt)

Upon receiving an encrypted OTP the Server compares the

(unencrypted) public id to his data base to identify the

key to decrypt the OTP After making sure that the secret

id is correct the Server verifies that the received

35 counter value is larger than the last one stored If the

Login is successful ie the previous conditions were

fulfilled the counter value on the Server that is

associated to the Yubikey is updated

rule Server_ReceiveOTP_NewSession

[ Server(pidsidotc)

In(ltpidnoncesenc(ltsidtc~prgtk)gt)

SharedKey(pidk) In(otc) ]

45 minus[ Login(pidsidtcsenc(ltsidtc~prgtk))

LoginCounter(pidotctc)

Smaller(otctc) ]rarr[ Server(pidsidtc) ]

50 model the larger relation using the smaller action and

exclude all traces where the predicate does not hold true

axiom smaller

forall i a b Smaller(ab)i minusrarr exist z a+z=b

55 For sanity Ensure that a successful login is reachable

lemma Login_reachable

exists-trace

exist i pid sid x otp1 Login(pidsidxotp1)i

60 If a succesful Login happens before a second sucesfull

Login the counter value of the first is smaller than the

counter value of the second

lemma invariant[reuse use_induction]

( forall pid otc1 tc1 otc2 tc2 t1 t2

65 LoginCounter(pidotc1tc1)t1 amp

LoginCounter(pidotc2tc2)t2

minusrarr ( t1ltt2 and ( exist z tc1+z=tc2))

or t2ltt1 or t1=t2)

It is not possible to have to distinct logins with the

same counter value

lemma no_replay

not ( exist i j pid sid x otp1 otp2

75 Login(pidsidxotp1)i and Login(pidsidxotp2)j

and not(i=j))

lemma injective_correspondance

forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr80 ( exist t1 YubiPress(pidx)t1 and t1ltt2

and forall otp2 t3 Login(pidsidxotp2)t3 minusrarr t3=t2

lemma Login_invalidates_smaller_counters

85 forall pid otc1 tc1 otc2 tc2 t1 t2 t3

LoginCounter(pidotc1tc1)t1 amp

and Smaller(tc1tc2)t3

minusrarr t1ltt2

90 end

Listing 18 Modelling of the Yubikey authentication protocol in conjunctionwith the YubiHSM formalised in tamarinrsquos MSR calculus Thecounter is modelled as a term constituting a multiset of con-stants where the cardinality of the multiset equals the size ofthe counter

theory YubikeyHSM

section The Yubikey-Protocol with a YubiHSM

functions

keystream2 keystream_kh1 keystream_n1

10 xor2 zero0

mac2 demac2

equations

keystream_kh(keystream(khn))=kh

15 keystream_n(keystream(nn))=n

models the way the key-stream used for encryption is

computed

xor(xor(ab)a)=b

xor(xor(ab)b)=a

20 xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

incomplete modelling of xor

demac(mac(mk)k)=m

25 describes the MAC used inside the AEADs

using mac adv might find out something about the

message we over-approximate

Rules for intruderrsquos control over Server

send messages to the HSM

rule isendHSM

[ In( x ) ] minus[ HSMWrite(x) ]rarr [ InHSM( x ) ]

rule irecvHSM

35 [ OutHSM( x ) ] minus[ HSMRead(x) ]rarr [Out(x)]

write and read the Authentication Serverrsquos database

rule read_AEAD

[ S_AEAD(pidaead) ]

40 minus[ AEADRead(aead)HSMRead(aead) ]rarr[Out(aead)]

rule write_AEAD

[ In(aead) In(pid) ]

minus[ AEADWrite(aead)HSMWrite(aead) ]rarr45 [S_AEAD(pidaead) ]

Initialisation of HSM and Authentication Server

rule HSMInit

50 [Fr(~k) Fr(~kh)] minus[MasterKey(~k) OneTime() ]rarr[ HSM(~kh~k) Out(~kh)

YSM_AEAD_GENERATE(~kh) uncomment to produce attack

YSM_AEAD_YUBIKEY_OTP_DECODE(~kh)

HSM commands

rule YSM_AEAD_RANDOM_GENERATE

let ks=keystream(khN)

aead=ltxor(senc(ksk)~data)mac(~datak)gt

[Fr(~data) InHSM(ltNkhgt)HSM(khk)

YSM_AEAD_RANDOM_GENERATE(kh)]

minus[GenerateRandomAEAD(~data) ]rarr[OutHSM( aead)

rule YSM_AEAD_GENERATE

aead=ltxor(senc(ksk)data)mac(datak)gt

[InHSM(ltNkhdatagt)HSM(khk)YSM_AEAD_GENERATE(kh)]

minus[GenerateAEAD(dataaead ) ]rarr[OutHSM( aead) ]

75 rule YSM_AES_ESC_BLOCK_ENCRYPT

[InHSM(ltkhdatagt) HSM(khk)

YSM_AES_ESC_BLOCK_ENCRYPT(kh)]

minus[ ]rarr[OutHSM(senc(datak))]

rule YSM_AEAD_YUBIKEY_OTP_DECODE

aead=ltxor(senc(ksk)ltk2didgt)mac(ltk2didgtk)gt

otp=senc(ltdidscrandgtk2)

[InHSM(ltdidkhaeadotpgt) HSM(khk)

minus[

90 OtpDecode(k2kltdidscrandgtsc

xor(senc(ksk)ltk2didgt)mac(ltk2didgtk))

OtpDecodeMaster(k2k)

]rarr[OutHSM(sc)]

Yubikey operations

rule BuyANewYubikey

let ks=keystream(kh~pid)

100 aead=ltxor(senc(ks~k)lt~k2~sidgt)mac(lt~k2~sidgt~k)gt

This rule implicitly uses YSM_AEAD_GENERATE

[ Fr(~k2)Fr(~pid)Fr(~sid)

YSM_AEAD_GENERATE(kh)

105 Uncomment to require the HSM to have

YSM_AEAD_GENERATE

HSM(kh~k) In( rsquo1 rsquo) ]

minus[Init(~pid~k2) ]rarr[Y_counter(~pid rsquo1 rsquo) Y_Key(~pid~k2) Y_sid(~pid~sid)

S_Counter(~pid rsquo1 rsquo) S_AEAD(~pidaead) S_sid(~pid~sid)

110 Out(~pid) ]

On plugin the session counter is increased and the token

counter reset

rule Yubikey_Plugin

115 [Y_counter(pidsc)In(Ssc) ]

The old counter value sc is removed

minus[ Yubi(pidSsc)Smaller(sc Ssc) ]rarr[Y_counter(pid Ssc)]

and substituted by a new counter value larger Ssc

[Y_counter(pidtc)Y_Key(pidk2)Y_sid(pidsid)

Fr(~pr)Fr(~nonce) In(tc+ rsquo1 rsquo)]minus[ YubiPress(pidtc)

125 YubiPressOtp(pidltsidtc~prgttck2) ]rarr[Y_counter(pidtc+ rsquo1 rsquo)

Out(ltpid~noncesenc(ltsidtc~prgtk2)gt)]

130 let ks=keystream(khpid)

aead=ltxor(senc(ksk)ltk2sidgt)mac(ltk2sidgtk)gt

[In(ltpidnoncesenc(ltsidtc~prgtk2)gt)

HSM(khk) S_AEAD(pidaead) S_Counter(pidotc)

135 S_sid(pidsid) ]

minus[ Login(pidsidtcsenc(ltsidtc~prgtk2))

LoginCounter(pidotctc) Smaller(otctc) ]rarr[ S_Counter(pidtc) ]

axiom smaller

145 axiom onetime

forall t3 t4 OneTime()t3 and OneTime()t4 minusrarr t3=t4

For sanity Ensure that a successful login is reachable

150 exists-trace

exist i pid sid x otp1 Login(pidsid x otp1)i

Every counter produced by a Yubikey could be computed by

the adversary anyway (This saves a lot of steps in the

155 backwards induction of the following lemmas)

lemma adv_can_guess_counter[reuseuse_induction]

forall pid sc t2 YubiPress(pidsc)t2

minusrarr ( exist t1 K(sc)t1 and t1ltt2)

160 Everything that can be learned by using OtpDecode is the

counter of a Yubikey which can be computed according to

the previous lemma

otp_decode_does_not_help_adv_use_induction[reuseuse_induction]

165 forall t3 k2 k m sc enc mac OtpDecode(k2kmscencmac)t3

minusrarr exist t1 pid YubiPress(pidsc)t1 and t1ltt3

forall keys shared between the YubiHSM and the

Authentication Server are either not known to the

170 adversary or the adversary learned the key used to

encrypt said keys in form of AEADs

lemma k2_is_secret_use_induction[use_inductionreuse]

forall t1 t2 pid k2 Init(pidk2)t1 and K(k2)t2

minusrarr175 ( exist t3 t4 k K(k)t3 and MasterKey(k)t4 and t3ltt2)

Neither of those kinds of keys are ever learned by the

adversary

lemma neither_k_nor_k2_are_ever_leaked_inv[use_inductionreuse]

180 not( exist t1 t2 k MasterKey(k)t1 and KU(k)t2 )

and not ( exist t5 t6 k6 pid Init(pidk6)t5 and KU(k6)t6 )

Each successful login with counter value x was preceded by a

button press

185 event with the same counter value

lemma one_count_foreach_login[reuseuse_induction]

forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr( exist t1 YubiPress(pidx)t1 and t1ltt2 )

190 If a successful Login happens before a second successful

lemma slightly_weaker_invariant[reuse use_induction]

195 LoginCounter(pidotc1tc1)t1 and LoginCounter(pid

otc2tc2)t2

minusrarr ( t1ltt2 and ( exist z tc2=tc1 + z))

or t2ltt1 or t1=t2)

induction

200 case empty_trace

by contradiction from formulas

case non_empty_trace

simplify

205 solve( (not(t1 lt t2)) or (forall z2 ((otc2+z1) = (otc1+z+z2)) rArrperp) )

case case_1

solve( (t2 = t1) or (t1 lt t2) )

case case_1

210 next

case case_2

215 case case_2

case case_1

220 case case_2

solve( S_Counter( pid otc2 ) 3t2 )

case BuyANewYubikey

by sorry

225 case Server_ReceiveOTP_NewSession_case_1

by sorry

case Server_ReceiveOTP_NewSession_case_2

by sorry

230 qed

same counter value

lemma no_replay

and not(i=j))

Every Login was preceded by exactly one corresponding button

245 forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr( exist t1 YubiPress(pidx)t1 and t1ltt2

250 If one login has a smaller counter than the other it must

have occurred earlier

forall pid otc1 tc1 otc2 tc2 t1 t2 z

and LoginCounter(pidotc2tc2)t2

255 and tc2=tc1+z

minusrarr t1ltt2

Listing 19 Modelling of the Yubikey authentication protocol formalised intamarinrsquos MSR calculus The counter is modelled using a ldquosuc-cessor ofrdquo constructor The permanent fact IsSmaller can be pro-duced by the adversary to proof that one counter value is smallerthan another We need to enforce transitivity in order to be ableto proof our claims ndash that means we require (using an axiom)each trace to contain IsSmaller(a c) should IsSmaller(a b) andIsSmaller(a c) be present for a b c isin M Succ models a func-tional relation If Succ(a b) then the adversary was able to showthat b is the successor of a The relation modelled by Smaller isnot functional If Smaller(a b) then the adversary was able toshow that a is smaller than b The Theory() action is used toenforce that this relation (to the extend it is needed in this trace)has to be build up before running the first protocol actions

1 theory Yubikey-noms

section The Yubikey-Protocol (alternative modelling)

6 builtins symmetric-encryption

functions S1zero0

Rules modelling the successor of relation

11 rule InitSucc

[In(zero)In(S(zero))]

minus[Theory() IsSucc(zeroS(zero))IsZero(zero) ]rarr[Succ(zeroS(zero))]

16 rule StepSucc

[In(y)In(S(y)) Succ(xy)]

minus[Theory() IsSucc(yS(y)) ]rarr[Succ(yS(y))]

21 Rules modelling the smaller than relation

rule SimpleSmaller

[Succ(xy)]

minus[Theory() IsSmaller(xy) ]rarr[Smaller(xy)]

rule ZExtendedSmaller

[Smaller(xy)Succ(yz)]

minus[Theory() IsSmaller(xz) ]rarr[Smaller(xz)]

Rules modelling the Yubikey

rule BuyANewYubikey

minus[Protocol() Init(~pid~k)

36 ExtendedInit(~pid~sid~k)IsZero(zero) ]rarr[Y(~pid~sid) Y_counter(~pidzero)

Server(~pid~sidzero)SharedKey(~pid~k) Out

(~pid)]

counter reset

41 rule Yubikey_Plugin

[Y_counter(pidsc)Smaller(sc Ssc) ]

minus[ Yubi(pidSsc) ]rarr[Y_counter(pid Ssc)]

46 If the Button is pressed the token counter is increased

Succ(tcStc)Fr(~npr)Fr(~nonce) ]

minus[ YubiPress(pidtc) ]rarr51 [Y_counter(pid Stc)

Out(ltpid~noncesenc(ltsidtc~nprgtk)gt)

Upon receiving an encrypted OTP the Server compares

56 the (unencrypted) public id to his data base to

identify the key to decrypt the OTP After making

sure that the secret id is correct the Server

verifies that the received counter value is larger

than the last one stored If the Login is

61 successful ie the previous conditions were

66 rule Server_ReceiveOTP_NewSession

[Server(pidsidotc) In(ltpidnoncesenc(ltsidtc~prgtk)

SharedKey(pidk) Smaller(otctc) ]

minus[ Login(pidsidtcsenc(ltsidtc~prgtk))

71 ]rarr[Server(pidsidtc)]

The following three axioms function like filters on

the traces They ensure that

a) the Smaller relation is transitive

axiom transitivity

forall t1 t2 a b c IsSmaller(ab)t1 and IsSmaller(bc)t2

minusrarr exist t3 IsSmaller(ac)t3

b) Smaller implies inequality

axiom smaller_implies_unequal

not ( exist a t IsSmaller(aa)t)

86 c) The protocol runs only after the IsSmaller and

IsSuccessor relation is build up

axiom theory_before_protocol

forall i j Theory() i and Protocol() j minusrarr i lt j

exists-trace

96 Each successful login with counter value x was

preceded by a button press with the same counter

forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr101 ( exist t1 YubiPress(pidx)t1 and t1ltt2 )

If a successful Login happens before a second

successful Login the counter value of the first is

smaller than the counter value of the second

106 lemma slightly_weaker_invariant[reuse use_induction]

minusrarr ( t1ltt2 and ( exist t3 IsSmaller(tc1tc2)t3 ))

111 or t2ltt1 or t1=t2)

induction

case empty_trace

116 next

simplify

solve( (forall pid otc1 tc1 otc2 tc2 t1 t2

(LoginCounter( pid otc1 tc1 ) t1) and

121 (LoginCounter( pid otc2 tc2 ) t2)

rArr(last(t2)) or

(last(t1)) or

((t1 lt t2) and

126 (forall t3 (IsSmaller( tc1 tc2 ) t3) and not(last(t3)))

(t2 lt t1) or

(t1 = t2)) or

(forall t1 t2 a b c

(IsSmaller( a b ) t1) and (IsSmaller( b c ) t2)

131 and

(not(last(t2))) and

(not(last(t1))) and

(forall t3 (IsSmaller( a c ) t3) rArr last(t3))) )

case case_1

136 solve( (last(t2)) or (last(t1)) or

((t1 lt t2) and

(forall t3 (IsSmaller( tc1 tc2 ) t3) and not(last(t3)))

(t2 lt t1) or (t1 = t2) )

case case_1

141 solve( Server( pid sid otc1 ) 0t1 )

case BuyANewYubikey

solve( Server( ~pid sid1 otc2 ) 0t2 )

by sorry

151 solve( Server( ~pid sid1 otc2 ) 0t2 )

by sorry

156 by sorry

by sorry

161 qed

case case_2

by contradiction cyclic

166 case case_3

case case_4

171 next

case case_5

176 case case_2

by sorry

181 lemma no_replay

Login(pidsidxotp1)i and Login(pidsidxotp2)j

and not(i=j))

186 lemma injective_correspondance

forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr( exist t1 YubiPress(pidx)t1 and t1ltt2

forall pid otc1 tc1 otc2 tc2 t1 t2 t3

196 and IsSmaller(tc1tc2)t3

minusrarr t1ltt2

Listing 20 Modelling of the Yubikey authentication protocol in conjunctionwith the YubiHSM modelling the ldquosmaller-thanrdquo relation as de-scribed in Listing 19

1 theory YubikeyHSMnoms

section The Yubikey-Protocol with a YubiHSM (alternative

modelling)

functions S1zero0

functions keystream2 keystream_kh1 keystream_n1

11 xor2

mac2 demac2

equations keystream_kh(keystream(khn))=kh

keystream_n(keystream(nn))=n

16 xor(xor(ab)a)=b

xor(xor(ab)b)=a

xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

21 demac(mac(mk)k)=m

rule InitSucc

26 minus[Theory() IsSucc(zeroS(zero))IsZero(zero) ]rarr[Succ(zeroS(zero))]

rule StepSucc

31 minus[Theory() IsSucc(yS(y)) ]rarr[Succ(yS(y))]

Rules modelling the smaller than relation

rule SimpleSmaller

36 [Succ(xy)]

41 [Smaller(xy)Succ(yz)]

Intruderrsquos control over Server

The attacker can send messages to the HSM ie on

behalf of the authentication server Likewise he

can receive messages

rule isendHSM

51 [ In( x ) ] minus[ HSMWrite(x) ]rarr [ InHSM( x ) ]

rule irecvHSM

[ OutHSM( x ) ] minus[ HSMRead(x) ]rarr [Out(x)]

The attacker can write and read the Authentication

56 Serverrsquos database

rule read_AEAD

[ S_AEAD(pidaead) ] minus[ AEADRead(aead)HSMRead(aead) ]rarr [

Out(aead)]

rule write_AEAD

[ In(aead) In(pid) ] minus[ AEADWrite(aead)HSMWrite(aead) ]rarr[S_AEAD(pidaead) ]

OneTime() Assures that this can only happen a single

time in a trace

rule HSMInit

66 [Fr(~k) Fr(~kh)]

minus[ Protocol() GenerateRole1(~k)

MasterKey(~k) OneTime() ]rarr[ HSM(~kh~k) Out(~kh)

71 YSM_AEAD_YUBIKEY_OTP_DECODE(~kh)

Some commands on the HSM

76 let ks=keystream(khN)

[ Fr(~data) InHSM(ltNkhgt)

HSM(khk)YSM_AEAD_RANDOM_GENERATE(kh)]

81 minus[GenerateRandomAEAD(~data) ]rarr[OutHSM( aead)

minus[GenerateAEAD(dataaead ) ]rarr91 [OutHSM( aead) ]

rule YSM_AES_ESC_BLOCK_ENCRYPT

[InHSM(ltkhdatagt) HSM(khk) YSM_AES_ESC_BLOCK_ENCRYPT(kh)

minus[ ]rarr96 [OutHSM(senc(datak))]

101 otp=senc(ltdidscrandgtk2)

[ InHSM(ltdidkhaeadotpgt) HSM(khk)

106 minus[

OtpDecode(k2kltdidscrandgtsc

]rarr111 [ OutHSM(sc) ]

Yubikey operations

rule BuyANewYubikey

This rule implicitly uses YSM_AEAD_GENERATE to

produce the AEAD that stores the secret identity and

shared key of a Yubikey By disabling the

121 YSM_AEAD_GENERATE flag but nevertheless permitting

this operation we model a scenario where

YSM_AEAD_GENERATE can be safely used to guarantee

the operation but not by the attacker This

corresponds to a setup where Yubikey initialisation

126 takes place on a different server or a setup where

the initialisation takes place before the server is

plugged into the network Uncomment the following

line to require the HSM to have the

YSM_AEAD_GENERATE flag set

Fr(~k2) Fr(~pid) Fr(~sid) HSM(kh~k) Succ(zeroone) ]

minus[ Init(~pid~k2) ]rarr136 [ Y_counter(~pidone) Y_Key(~pid~k2) Y_sid(~pid~sid)

S_Counter(~pidzero) S_AEAD(~pidaead)

S_sid(~pid~sid) Out(~pid) ]

counter reset

146 rule Yubikey_PressButton

Succ(tcStc)Fr(~pr)Fr(~nonce) ]

minus[ YubiPress(pidtc)

YubiPressOtp(pidltsidtc~prgttck2) ]rarr151 [Y_counter(pidStc) Out(ltpid~noncesenc(ltsidtc~prgtk2)gt)]

let ks=keystream(khpid)

156 in

[ In(ltpidnoncesenc(ltsidtc~prgtk2)gt)

S_sid(pidsid) Smaller(otctc) ]

161 LoginCounter(pidotctc) ]rarr[ S_Counter(pidtc) ]

axiom transitivity axiomatic

b) Smaller implies unequality

axiom smaller_implies_unequal axiomatic

176 c) The protocol runs only after the IsSmaller and IsSuccessor

relation is

build up

181 axiom onetime

LEMMAS

exists-trace forall i pid sid x otp1 Login( pid sid x otp1

simplify

solve( KU( senc (ltsid (otc+z) ~prgt k2) ) vk4 )

191 case Yubikey_PressButton

solve( S_sid( pid ~sid ) 4i )

case BuyANewYubikey

solve( S_Counter( ~pid otc ) 3i )

case BuyANewYubikey

196 solve( S_AEAD( ~pid

ltxor(senc(keystream(kh ~pid) k) lt~k2

~sidgt)

mac(lt~k2 ~sidgt k)gt

) 2i )

case BuyANewYubikey

201 solve( HSM( ~kh ~k ) 1i )

case HSMInit

solve( Y_counter( ~pid (rsquo1rsquo+z) ) 0vr )

case Yubikey_Plugin_case_1

solve( Y_counter( ~pid rsquo1rsquo ) 0vr5 )

206 case BuyANewYubikey

solve( KU( ~pid ) vk3 )

case BuyANewYubikey

SOLVED trace found

211 qed

case write_AEAD

216 by sorry

by sorry

221 next

by sorry

226 next

case csenc

by sorry

case irecvHSM

231 by sorry

Every counter produced by a Yubikey could be

computed by the adversary anyway (This saves a lot

236 of steps in the backwards induction of the following

lemmas)

Everything that can be learned by using OtpDecode is

the counter of a Yubikey which can be computed

according to the previous lemma

lemma otp_decode_does_not_help_adv_use_induction

246 [reuseuse_induction]

forall t3 k2 k m sc enc mac OtpDecode(k2kmscencmac)t3

251 Authentication Server are either not known to the

adversary or the adversary learned the key used to

256 minusrarr( exist t3 t4 k K(k)t3 and MasterKey(k)t4 and t3ltt2)

Neither of those kinds of keys are ever learned by

the adversary

261 lemma neither_k_nor_k2_are_ever_leaked_inv[use_inductionreuse]

not( exist t1 t2 k MasterKey(k)t1 and KU(k)t2 )

Each successful login with counter value x was

271 forall pid sid x otp t2 Login(pidsidxotp)t2 minusrarr( exist t1 YubiPress(pidx)t1 and t1ltt2 )

induction

case empty_trace

276 next

simplify

solve( S_AEAD( pid

ltxor(senc(keystream(kh pid) k) ltk2 sidgt)

mac(ltk2 sidgt k)gt

281 ) 2t2 )

case BuyANewYubikey_case_1

by sorry

286 by sorry

case write_AEAD

solve( KU( xor(senc(keystream(kh pid) k) ltk2 sidgt)

) vk6 )

291 case irecv

case cxor

by sorry

296 next

case read_AEAD_case_1

by sorry

301 by sorry

306 end

Listing 21 The running example from Chapter 5

theory RunningExample

builtins symmetric-encryption

functions encSucc2 true0

equations encSucc(senc(xy)y) = true

( ν h ν k event NewKey(hk)

insert lt rsquokey rsquohgtkinsert lt rsquo att rsquohgt rsquodec rsquo out(h) )

14 | allow wrap

( in(h) insert lt rsquo att rsquohgt rsquowraprsquo )

( in(lthcgt)

lookup lt rsquo att rsquohgt as a in

19 if a= rsquodec rsquo then lookup lt rsquokey rsquohgt as k in

if encSucc(ck)=true() then

event DecUsing(ksdec(ck)) out(

sdec(ck))

| Wrap

24 ( in(lth1h2gt) lookup lt rsquo att rsquoh1gt as a1 in

if a1= rsquowraprsquo then lookup lt rsquokey rsquoh1gt as k1

lookup lt rsquokey rsquoh2gt as k2 in

event Wrap(k1k2)

out(senc(k2k1))

lemma can_create_key for sanity

exists-trace

34 exist t h k NewKey(hk)t

lemma can_obtain_wrapping for sanity

exists-trace

exist t k1 k2 Wrap(k1 k2)t39

lemma dec_limits[ reuse typing]a message that can be decrypted was

either encrypted on the device or some key leaked or

not a valid enc

44 forall k m t1 DecUsing(km)t1 =rArr( exist h k2 t2 t3 NewKey(h k2)t2 and KU(k2)t3 and t2ltt1

and t3ltt1 )

lemma cannot_obtain_key_ind[ reuse use_induction]49 not ( exist i j h k NewKey(hk)i and KU(k) j)

lemma cannot_obtain_key

not ( exist i j h k NewKey(hk)i and K(k) j)

54 end

Listing 22 Security agrave la PKCS11

1 theory EncWrapDecUnwrap

( in( rsquo create rsquo) ν h ν k event NewKey(hk)

insert lt rsquokey rsquohgtkinsert lt rsquo att rsquohgt rsquo in i t rsquo out(h) )

( in(lt rsquoset_wrap rsquohgt) lock lt rsquo att rsquohgt lookup lt rsquo att rsquohgt as a

if a= rsquo in i t rsquo then delete lt rsquo att rsquohgtinsert lt rsquo att rsquohgt rsquowraprsquoevent WrapHandle(h) unlock lt rsquo att rsquohgt

( in(lt rsquo set_dec rsquohgt) lock lt rsquo att rsquohgt lookup lt rsquo att rsquohgt as a in

if a= rsquo in i t rsquo then delete lt rsquo att rsquohgt insert lt rsquo att rsquohgt rsquodecrsquo

unlock lt rsquo att rsquohgt21 )

( in(lthsenc(mk)gt) lookup lt rsquo att rsquohgt as a in

if a= rsquodec rsquo then

lookup lt rsquokey rsquohgt as kp in

26 if kp=k then

event DecUsing(km) out(m)

( in(lthmgt) lookup lt rsquo att rsquohgt as a in

event EncUsing(km) out(senc(mk))

| Wrap

( in(lth1h2gt) lookup lt rsquo att rsquoh1gt as a1 in

36 if a1= rsquowraprsquo then lookup lt rsquokey rsquoh1gt as k1 in

event Wrap(k1k2)

out(senc(k2k1))

41 | Unwrap

( in(lth1senc(mk)gt) lookup lt rsquo att rsquoh1gt as a1 in

if a1= rsquowraprsquo then lookup lt rsquokey rsquoh1gt as k1 in

if k1=k then

46 insert lt rsquokey rsquoh2gt m

insert lt rsquo attr rsquoh2gt rsquowraprsquo)

51 exists-trace

exist t h k NewKey(hk)t

lemma can_set_wrap for sanity

exists-trace

56 exist t h WrapHandle(h)t

exists-trace

lemma dec_limits[ reuse typing] a message that can be decrypted was either encrypted on the

device or some

key leaked

forall k m t1 DecUsing(km)t1 =rArr66 ( exist h k2 t2 t3 NewKey(h k2)t2 and KU(k2)t3 and t2ltt1 and

t3ltt1 )or exist t2 EncUsing(km)t2 and t2ltt1

lemma cannot_obtain_key_ind[ reuse use_induction] not ( exist i j h k NewKey(hk)i and KU(k) j)

Listing 23 Needham-Schoeder-Lowe protocol

theory NeedhamSchroeder

builtins asymmetric-encryption

( ν skA

event HonestA(pk(skA))

9 out(pk(skA))

( in(pk(xB))

event OUT_I_1(aenc(ltNapk(skA)gtpk(xB)))

out(aenc( ltNapk(skA) gt pk(xB)))

14 in(aenc(ltNaxNbpk(xB)gtpk(skA)))

event IN_I_2_nr(xNbaenc(ltNaxNbpk(xB)gtpk(skA)))

ν k out(aenc(ltxNbkgtpk(xB)))

event SessionA(pk(skA)pk(xB)k)

( ν skB

event HonestB(pk(skB))

out(pk(skB))

( in(aenc(ltxNapk(xA)gtpk(skB)))

24 event IN_R_1_ni(xNaaenc(ltxNapk(xA)gtpk(skB)))

event OUT_R_1(aenc(ltxNaNbpk(skB)gtpk(xA)))

out(aenc(ltxNaNbpk(skB)gtpk(xA)))

in(aenc(ltNbxkgtpk(skB)))

29 event SessionB(pk(xA)pk(skB)xk)

lemma sanity1 make sure that a valid protocol run exists

exists-trace

34 exist pka pkb k t1 SessionA(pkapkbk)t1

lemma sanity2

exists-trace

exist pka pkb k t1 SessionB(pkapkbk)t139

lemma types [ typing reuse] ( forall ni m1 i

IN_R_1_ni( ni m1) i=rArr

44 ( ( exist j KU(ni ) j and j lt i )or ( exist j OUT_I_1( m1 ) j )

and ( forall nr m2 i 49 IN_I_2_nr( nr m2) i

=rArr( ( exist j KU(nr) j and j lt i )or ( exist j OUT_R_1( m2 ) j )

lemma secrecy

59 exist pka pkb k t1 t2 SessionA(pkapkbk)t1and K(k)t2and ( exist i HonestA(pka)i)and ( exist i HonestB(pkb)i)

Listing 24 Yubikey protocol

theory Yubikey

section The Yubikey-Protocol

8 let Yubikey=

ν k ν pid ν secretid

insert lt rsquoServer rsquopidgt ltsecretidk rsquoone rsquogtinsert lt rsquoYubikey rsquopidgt rsquoone rsquoevent ExtendedInit(pidsecretidk)

13 out(pid)

( ( Plug

lock pid

lookup lt rsquoYubikey rsquopidgt as sc in

in(sc) just a trick to enforce adv learning sc

18 insert lt rsquoYubikey rsquopidgt sc+ rsquoone rsquoevent Yubi(pidsc + rsquoone rsquo)

unlock pid

) | ( ButtonPress

lock pid

23 lookup lt rsquoYubikey rsquopidgt as tc in

in(tc) just a trick to enforce adv learning tc

insert lt rsquoYubikey rsquopidgt tc + rsquoone rsquoν nonce

ν npr

28 event YubiPress(pidsecretidktc)

out(ltpidnoncesenc(ltsecretidtcnprgtk)gt)

unlock pid

let Server=

in(ltpidnoncesenc(ltsecretidtcnprgtk)gt)

lock pid

38 lookup lt rsquoServer rsquopidgt as tuple in

if fst(tuple)=secretid then

if fst(snd(tuple))=k then

in(otc)

if snd(snd(tuple))=otc then

43 event Smaller(otctc)

event InitStuff(pid

secretidktupleotc

event Login(pidktc)

insert lt rsquoServer rsquopidgt ltsecretidktcgt

unlock pid

(Server | Yubikey)

we model the larger relation using the smaller action

53 and excluding all traces where it is not correct

axiom smaller

forall i a b Smaller(a b)i =rArr exist z a+z=b

58 lemma Login_reachable

exists-trace

exist i pid k x Login(pid k x)i

typing lemmas

63 There exists a Initialisation for every Login on the Server

lemma init_server[ typing] forall pid sid k tuple otc tc i InitStuff (pid sid

k tuple otc tc )i=rArr

tuple=ltsid k otcgt68 amp

exist j ExtendedInit(pid sid k)j and j lt i

lemma init_yubikey[ typing]73 forall pid sid k tc i YubiPress(pid sid k tc )i

=rArr exist j ExtendedInit(pid sid k)j and j lt i

If a succesful Login happens before a second sucesfull Login

the counter value of the first is smaller than the counter

78 value of the second

lemma slightly_weaker_invariant[ reuse use_induction] ( forall pid k tc1 tc2 t1 t2

Login(pid k tc1 ) t1 and Login(pid k tc2 ) t2

=rArr ( t1lt t2 and ( exist z tc1+z=tc2 ) )83 or t2lt t1 or t1= t2 )

It is impossible to have to distinct logins with the same

counter value

88 lemma no_replay[ reuse] not ( exist i j pid k x Login(pid k x)i and Login(pid k x)jand not( i= j ) )

93 Each succesful login with counter value x was preceeded by a

PressButton

event with the same counter value

proof needs to be guided

lemma one_count_foreach_login[ reuse use_induction] forall pid k x t2 Login(pid k x)t2 =rArr

98 ( exist t1 sid YubiPress(pid sid k x) t1 and t1lt t2

lemma injective_correspondance[ reuse use_induction]103 forall pid k x t2 Login(pid k x)t2 =rArr

( exist t1 k YubiPress(pid kk x) t1 and t1lt t2 )and forall t3 Login(pid k x)t3 =rArr t3= t2

108 lemma Login_invalidates_smaller_counters

forall pid k tc1 tc2 t1 t2 t3 Login(pid k tc1 ) t1 and Login(pid k tc2 ) t2

and Smaller( tc1 tc2 )t3=rArr t1lt t2

113 end

Listing 25 Garay Jakobsson and MacKenziersquos optimistic contract signingprotocol

theory Contract

2 begin

section GM Protocol for Contract signing

builtins signing

functions pcs3 checkpcs5 convertpcs2 check_getmsg2

fakepcs4

equations

check_getmsg(sign(xm xsk) pk(xsk)) = xm

12 checkpcs(xc pk(xsk) ypk zpk pcs(sign(xc xsk) ypk zpk)) =

true()

convertpcs(zsk pcs(sign(xc xsk) ypk pk(zsk))) = sign(xc xsk)

fakepcs ()

checkpcs(xc xpk pk(ysk) zpk fakepcs(xpk ysk zpk xc)) =

true()

17 let Abort1 =

in(lt rsquoabort rsquoltctpk1pk2ysiggtgt)if check_getmsg(ysig pk1) = ltctpk1pk2gt then

(lock ct

lookup ct as state in unlock ct TODO maybe output state

22 else

insert ct rsquoaborted rsquoevent Abort1(ct)

unlock ct

27 out(sign(ltltctpk1pk2gtysiggtskT))

let Resolve2 =

32 in(lt rsquo resolve2 rsquoltctpk1pk2ypcs1ysig2gtgt)if check_getmsg(ysig2 pk2)=ct then

check validity of the pcs something not done in StatVerif

Tamarin modelling

if check_getmsg(convertpcs(skTypcs1)pk1) = ct then

if checkpcs(ct pk1 pk2 pk(skT) ypcs1)=true then

lock ct

lookup ct as status in unlock ct

42 else

insert ct rsquo resolved2 rsquoevent Resolve2(ct)

unlock ct

47 out(sign(ltconvertpcs(skTypcs1) ysig2gtskT))

let Resolve1 =

in(lt rsquo resolve1 rsquoltctpk1pk2ysig1ypcs2gtgt)if check_getmsg(ysig1pk1)=ct then

57 if check_getmsg(convertpcs(skTypcs2)pk2) = ct then

lock ct

62 lookup ct as status in unlock ct

67 unlock ct

out(sign(ltysig1convertpcs(skT ypcs2)gtskT))

let WitnessAbort =

in (sign(pcs(sign(ctsk1) pk(ysk) pk(skT))skT) )

event AbortCert(ct)

77 let WitnessResolved =

in (sign(ltsign(ctsk1) sign(ctsk2)gtskT))

event ResolveCert(ct)

let HonestClient =

82 ν skA

out(pk(skA))

in (ltctxpkBgt)

( First decision Sign the contract

out(sign(ctskA))

in(sigB)

if verify(sigBctxpkB)=true() then

if we get a signature backgood

event AhasSignature(ct)

92 else if not

0 Accept silently

| Or we decide not to sign it

102 ν skT

event TrustedParty(skT)

out(pk(skT))

Abort1 | Resolve2 | Resolve1 |

107 WitnessAbort | WitnessResolved |

HonestClient

112 Lemmas taken from tamarin files

lemma aborted_and_resolved_exclusive

not ( exist ct i j AbortCert( ct ) i and ResolveCert( ct ) j )

117 Sanity checks

lemma resolved1_contract_reachable

exists-trace

( exist ct i ResolveCert( ct ) i ) Ensure that this is possible with at most one Resolve1

step 122 and ( forall ct i Abort1( ct ) i =rArr F)

and ( forall ct1 ct2 i1 i2 Resolve1(ct1 ) i1 and Resolve1(ct2 ) i2 =rArr i1 = i2 )

and ( forall ct i Resolve2( ct ) i =rArr F)

exists-trace

and ( forall ct i Resolve1( ct ) i =rArr F)and ( forall ct1 ct2 i1 i2

Resolve2(ct1 ) i1 and Resolve2(ct2 ) i2 =rArr i1 = i2 )

137 end

Listing 26 Key-server example from [74]

theory SetAbst

section The PKI-example

builtins asymmetric-encryption signing

8 let Client=

Revoke key

ν ~nsk

[ ClientKey(user ~sk) ] minus[ HonestKey(~nsk) ]rarr [ ClientKey(user~nsk) ]

13 out(lt rsquorevoke rsquouserpk(~nsk)gt)out(sign(lt rsquorevoke rsquouserpk(~nsk)gt~sk))in(sign(lt rsquoconfirm rsquosign(lt rsquorevoke rsquouserpk(~nsk)gt~sk)gtpki))event Revoked(~sk)

out(~sk)

let Server=

( ( in(lt rsquo create rsquousergt) Create Honest Keys

ν ~sk

23 [ ] minus[ HonestKey(~sk) ]rarr [ ServerDB(pki user pk(~sk) ) ClientKey(user~sk) ]

out(pk(~sk))

| Allow creating Dishonest Keys

28 ( in(ltuserskgt)

[ ] minusrarr [ServerDB(pki user pk(sk) ) ])

| Revoke Key

33 in(lt rsquorevoke rsquouserpk(nsk)gt)in(sign(lt rsquorevoke rsquouserpk(nsk)gtsk))[ServerDB(pki user pk(sk) ) ]minusrarr[ServerDB(pki user pk(nsk) ) ]out(sign(lt rsquoconfirm rsquosign(lt rsquorevoke rsquouserpk(nsk)gtsk)gtpki))

(ν pki Server | (ν user Client) )

rule SetupDishonestKey

[ In(sk) ] minusrarr [ ServerDB($A pk(sk) ) ]43

lemma Knows_Honest_Key_imp_Revoked

forall sk i d HonestKey(sk) i and K(sk) d =rArr( exist r Revoked(sk) r )

Listing 27 Key-server example from [74] modelled under the use of insertand lookup

1 theory SetAbst

6 builtins asymmetric-encryption signing

let Client=

Revoke key

ν ~nsk

11 lock user

lookup lt rsquoUSERrsquousergt as ~sk in

event HonestKey(~nsk)

delete lt rsquoUSERrsquousergtinsert lt rsquoUSERrsquousergt~nsk

16 unlock user

out(lt rsquorevoke rsquouserpk(~nsk)gt)out(sign(lt rsquorevoke rsquouserpk(~nsk)gt~sk))in(sign(lt rsquoconfirm rsquosign(lt rsquorevoke rsquouserpk(~nsk)gt~sk)gt

event Revoked(~sk)

21 out(~sk)

let Server=

( Create Honest Keys

26 in(lt rsquo create rsquousergt)ν ~sk

lock user

event HonestKey(~sk)

insert lt rsquoSERVERrsquopkiusergt pk(~sk)

31 insert lt rsquoUSERrsquousergt ~sk

unlock user

out(pk(~sk))

( Revoke key

in(lt rsquorevoke rsquouserpk(nsk)gt)in(sign(lt rsquorevoke rsquouserpk(nsk)gtsk))lock user

41 lookup lt rsquoSERVERrsquopkiusergt as pksk in

if pksk = pk(sk) then

delete lt rsquoSERVERrsquopkiusergtinsert lt rsquoSERVERrsquopkiusergt pk(nsk)

unlock user

46 out(sign(lt rsquoconfirm rsquosign(lt rsquorevoke rsquouserpk(nsk)gtsk)gtpki))

[ In(sk) ] minusrarr [ ServerDB($A pk(sk) ) ]

56 lemma Knows_Honest_Key_imp_Revoked

Sanity check Commented out for runtime comparison to [1]

lemma Honest_Revoked_Known_Reachable

exists-trace

( exist sk i j r HonestKey(sk) i66 and K(sk) j

and Revoked(sk) r)

Listing 28 Left-right example from [5] described in Example 4 on p22

theory StatVerif_Security_Device begin

5 let Device=(

out(pk(sk))

( lock s

in(req)

10 lookup s as status in

if status= rsquo in i t rsquo then

insert sreq

unlock s

lock s

in(aencltxygtpk(sk))

lookup s as status in

20 if status= rsquo l e f t rsquo then

event Access(x) out(x) unlock s

else if status= rsquo right rsquo then

event Access(y) out(y) unlock s

let User=

ν lm ν rm event Exclusive(lmrm)

out(aencltlmrmgtpk(sk))

( ν sk ν s insert s rsquo in i t rsquo ( Device | User ))

Typing lemma taken from Tamarinrsquos example directory

lemma types [ typing]35 forallm i Access(m) i =rArr

( exist j KU(m) j and j lt i )or ( exist x j Exclusive(x m) j )or ( exist y j Exclusive(my) j )

Check that there is some trace where the intruder knows the

left message of an exclusive message-tuple In contrast to the

typing lemma we use the standard rsquoKrsquo-fact which is logged by

the built-in rsquoISendrsquo rule

45 lemma reachability_left

exists-trace

exist x y i j Exclusive(x y) i and K(x) j

lemma reachability_right

50 exists-trace

exist x y i k Exclusive(x y) i and K(y) k

Check that exclusivity is maintained

lemma secrecy

55 not( exist x y i k1 k2 Exclusive(x y) i and K(x) k1 and K(y) k2

60 end

BP R O O F S F O R PA RT i

b1 correctness of tamarinrsquos solution procedure for

translated rules

The multiset rewrite system produced by our translation for a well-formed process P could actually contain rewrite rules that are notvalid with respect to Definition 2 because they violate the third con-dition which is For each l prime minus[a prime]rarr r prime isin R isinE ginsts(l minus[a]rarr r) wehave that capr primeprime=Er primenames(r primeprime)cap FN sube capl primeprime=El primenames(l primeprime)cap FN

This does not hold for rules in JPK=p where p is the position of thelookup-operator The right hand-side of this rule can be instantiatedsuch that assuming the variable bound by the lookup is named v thisvariable v is substituted by a names that does not appear on the left-hand side In the following we will show that the results from [89]still hold In practice this means that the tamarin-prover can be usedfor verification despite the fact that it outputs well-formedness errorsfor each rule that is a translation of a lock

We will introduce some notation first We re-define JPK to containthe Init rule and JP [] []K but not MD (which is different to Defi-nition 14) We furthermore define a translation with dummy-facts

denoted JPKD that contains Init and JP [] []KD

which is defined asfollows

Definition 32 We define JPKD = Init cup JP [] []KD

where JP [] []KD

isdefined just as JP [] []K with the exception of two cases P = lookupM as v in P else Q and P = insert s tP In those cases it is definedas follows

Jlookup M as v in P else Qp xKD =

[statep(x) Dum(v)] minus[IsIn(Mv)]rarr [statepmiddot1(M v)]

cup JP p middot 1 (x v)KD cup JQp middot 2 xKD

Jinsert s tP p xKD = [statep(x)] minus[Insert(s t)]rarr

[statepmiddot1(x) Dum(t)]cup JP p middot 1 xKD

The only difference between JPK and JPKD is therefore that JPKD

produces a permanent fact Dum for every value v that appears in anaction insert(k v) which is a premise to every rule instance with anaction IsIn(k prime v) We see that JPKD contains now only valid multisetrewrite rules

In the following we would like to show that the tamarin-proverrsquossolution algorithm is correct for JPK To this end we make use of the

198 proofs for part i

proof of correctness of tamarin as presented in Benedikt SchmidtrsquosPhD thesis [88] We will refer to Lemmas Theorems and Corollariesin this work by their numbers We will use the notation of this workto make it easier to the reader to compare our statements against thestatements there In particular trace(execs(R)) is tracesmsr(R) in ournotation We have to show that

Lemma 9 For all well-formed process P and guarded trace propertiesφ

trace(execs(JPKcupMD) DHenotαin orφ

if and only if

trace(ndgraphs(JPK)) ACC notαin orφ

Proof The proof proceeds similar to the proof to Theorem 327 Werefer to results in [88] whenever their proofs apply despite the factthat the rules in JPK do not satisfy the third condition of multisetrewrite rules

trace(execs(JPKcupMD) DHenotαin orψ

hArr trace(execs(JPKcupMD) DHenotαin orφ

(Lemma 37 (unaltered))

hArr trace(execs(JPKcupMD)) darrRDHeDHe

notαin orφ

(Definition of DHe)

hArr trace(dgraphsDHe(JPKcupMD)) darrRDHe

DHenotαin orφ

hArr trace(dg | dg isin dgraphsACC(lceilJPKcupMDrceilRDHe

insts )

anddg darrRDHe-normal) DHe

notαin orφ

hArr trace(ndgraphs(JPK)) DHenotαin orφ (Lemma A12 ())

hArr trace(ndgraphs(JPK)) ACC notαin orφ

(Lemma 37 and A20(both unaltered))

It is only in Lemma A12 where the third condition is used Theproof to this lemma applies Lemma A14 which says that all fac-tors (or their inverses) are known to the adversary We will quoteLemma A14 here

Lemma 10 (Lemma A14 in [88]) For all ndg isin ndgraphs(P) conclu-sions (i u) in ndg with conclusion fact f and terms t isin afactors(f)there is a conclusion (j v) in ndg with j lt i and conclusion fact Kd(m)

such that m isinACC t (tminus1) darrRBPe

B2 proofs for Section 5 4 199

If there is ndg isin ndgraphs(JPK) such that trace(ndg) ACC αin then

hArrforallndg isin ndgraphs(JPK) s t trace(ndg) ACC αin

trace(ndg) ACC φ

Since for the empty trace [] ACC αin we only have to show thatLemma A14 holds for ndg isin ndgraphs(JPK) such that trace(ndg) ACC

αinFor every ndg isin ndgraphs(JPK) such that trace(ndg) ACC αin there

is a trace equivalent ndg prime isin ndgraphs(JPKD) since the only differencebetween JPK and JPKD lies in the dummy conclusion and premisesand αin requires that any v in an action IsIn(uv) appeared previouslyin an action Insert(uv) (equivalence modulo ACC) Therefore ndg prime

has the same Kd-conclusions ndg has and every conclusion in ndg isa conclusion in ndg prime

We have that Lemma A14 holds for JPKD since all rules gen-erated in this translation are valid multiset rewrite rules There-fore Lemma A14 holds for all ndg isin ndgraphs(JPK) such thattrace(ndg) ACC αin too concluding the proof by showing the marked() step

b2 proofs for Section 5 4

The following two lemmas are used in the proof to Lemma 2 In orderto prove the first one Lemma 1 we need a few additional lemmas

We say that a set of traces Tr is prefix closed if for all tr isin Tr andfor all tr prime which is a prefix of tr we have that tr prime isin Tr

Lemma 11 (filter is prefix-closed) Let Tr be a set of traces If Tr is prefixclosed then filter(Tr) is prefix closed as well

Proof It is sufficient to show that for any trace tr = tr prime middotawe have thatif forallθ (tr θ) α then forallθ (tr prime θ) α This can be shown by inspectingeach of the conjuncts of α

We next show that the translation with dummy facts defined inDefinition 32 produces the same traces as JPK excluding traces notconsistent with the axioms For this we define the function d whichremoves any dummy fact from an execution ie

d(emptyF1minusrarr S1

F2minusrarr Fnminusrarr Sn) = empty

F1minusrarr S prime1F2minusrarr

Fnminusrarr S primen

where S primei = Si cuptisinT Dum(t)

Lemma 12 Given a ground process P we have that

filter(execmsr(JPK)) = filter(d(execmsr(JPKD cupMD)))

Proof The only rules in JPKD that differ from JPK are translations ofinsert and lookup The first one only adds a permanent fact whichby the definition of d is removed when applying d The second onerequires a fact Dum(t) whenever the rule is instantiated such theactions equals IsIn(s t) for some s Since the translation is otherwisethe same we have that

filter(d(execmsr(JPKD cupMD))) sube filter(execmsr(JPK))

For any trace in filter(d(execmsr(JpKcupMD))) and any action IsIn(s t) inthis trace there is an earlier action Insert(s prime t prime) such that s = s prime andt = t prime as otherwise αin would not hold Therefore the same traceis part of filter(d(execmsr(JpKD cupMD))) as this means that wheneverDum(t) is in the premise Dum(t prime) for t = t prime has previously appearedin the conclusion Since it is a permanent fact it has not disappearedand therefore

We slightly abuse notation by defining filter on executions to filterout all traces contradicting the axioms see Definition 16

filter(execmsr(JPK)) For all 1 6 i 6 n if Fr(a) isin Si and F(t1 tk) isinSi for any F isin Σfact Fr then a 6isin capt=Et primenames(t prime) for any t isin

Proof The translation with the dummy fact introduced in Section B1(see Definition 32) will make this proof easier as for JPKD cupMD wehave that the third condition of Definition 2 holds namely

foralll prime minus[a prime]rarr r prime isinE ginsts(l minus[a]rarr r)

capr primeprime=Er prime names(r primeprime)cap FN sube capl primeprime=El primenames(l primeprime)cap FN (3)

We will show that the statement holds for all emptyF1minusrarr S1

F2minusrarr Fnminusrarr

Sn isin filter(execmsr(JPKD cupMD)) which implies the claim since

by Lemma 12 We proceed by induction on n the length of the exe-cution

bull Base case n = 0 We have that S0 = empty and therefore the state-ment holds trivially

bull Inductive case n gt 1 We distinguish two cases

1 A rule that is not Fresh was applied and there is a factF(t1 tk) isin Sn such that F(t1 tk) isin Snminus1 andFr(a) isin Sn such that a isin capti=Et primenames(t prime) for some ti(If there are no such F(t1 tk) and Fr(a) we immedi-ately conclude by induction hypothesis) By Equation 3a isin t primej for some F prime(t prime1 t

primel) isin Snminus1 Since Fresh is the

only rule that adds a Fr-fact and Fr(a) isin Sn it must bethat Fr(a) isin Snminus1 contradicting the induction hypothesisTherefore this case is not possible

2 The rule Fresh was applied i e Fr(a) isin Sn and Fr(a) isin

Snminus1 If there is no a isin capti=Et primenames(t prime) for some tiand F(t1 tk) isin Sn then we conclude by induction hy-pothesis Otherwise if there is such a F(t1 tk) isin Snthen by Equation 3 a isin t primej for some F prime(t prime1 t

primel) isin Si

for i lt n We construct a contradiction to the induc-tion hypothesis by taking the prefix of the execution upto i and appending the instantiation of the Fresh ruleto its end Since d(execmsr(JPKD cupMD)) is prefix closed

by Lemma 11 we have that emptyF1minusrarr S prime1

F2minusrarr Fiminusrarr Si isin

filter(d(execmsr(JPKD cupMD))) Moreover as rule Fresh wasapplied adding Fr(a) isin Sn it is also possible to apply thesame instance of Fresh to the prefix (by Definition 4) andtherefore

emptyF1minusrarr S prime1

F2minusrarr Fiminusrarr Si minusrarr Si cup Fr(a)

isin filter(d(execmsr(JPKD cupMD)))

contradicting the induction hypothesis

Lemma 14 For any frame νnσ t isin M and a isin FN if a 6isin st(t)a 6isin st(σ) and νnσ ⊢ t then νn aσ ⊢ t

Proof In [1 Proposition 1] it is shown that νnσ ⊢ t if and only ifexistMfn(M) cap n = empty and Mσ =E t Define M prime as M renaming a tosome fresh name ie not appearing in n σ t As a 6isin st(σ t) andthe fact that equational theories are closed under bijective renamingof names we have that M primeσ =E t and fn(M prime) cap (n a) = empty Henceνn aσ ⊢ t

σ = t1x1 tm xm and

We have that

Proof We prove both items separately

1 The proof proceeds by induction on n the number of steps ofthe execution

base case n=0 This case trivially holds as Sn = empty

inductive case ngt0 By induction we suppose that ifK(t) isin Snminus1 then νn primeσ prime ⊢ t where n prime σ prime are defined in a sim-ilar way as n σ but for the execution of size nminus 1 We proceedby case analysis on the rule used to extend the execution

bull MDOut Suppose that

Out(u) minus[]rarr K(u) isin ginsts(MDOut)

is the rule used to extend the execution Hence Out(u) isin

Snminus1 and by definition of σ there exists x such that xσ = uWe can apply deduction rule DFrame and conclude thatνnσ ⊢ u If K(t) isin Sn and t 6= u we conclude by inductionhypothesis as n = n prime σ = σ prime

bull MDPub Suppose that

minus[]rarr K(a pub) isin ginsts(MDPub)

is the rule used to extend the execution As names of sortpub are never added to n we can apply deduction ruleDName and conclude that νnσ ⊢ a If K(t) isin Sn and t 6= awe conclude by induction hypothesis as n = n prime σ = σ prime

bull MDFresh Suppose that

Fr(a fresh) minus[]rarr K(a fresh) isin ginsts(MDFresh)

is the rule used to extend the execution By definition ofan execution we have that Fr(a fresh) 6= (Sj+1 Sj) forany j 6= nminus 1 Hence n 6isin n We can apply deduction ruleDName and conclude that νnσ ⊢ a If K(t) isin Sn and t 6= awe conclude by induction hypothesis as n = n prime σ = σ prime

bull MDAppl Suppose that

K(t1) K(tk) minus[]rarr K(f(t1 tk)) isin ginsts(MDAppl)

is the rule used to extend the execution We have thatK(t1) K(tk) isin Snminus1 and thus by induction hypothesisνn primeσ prime ⊢ ti for 1 6 i 6 k As n = n prime σ = σ prime we havethat νnσ ⊢ ti for 1 6 i 6 k and can apply deduction ruleDAppl and conclude that νnσ ⊢ f(t1 tk) If K(t) isin Snand t 6= f(t1 tk) we conclude by induction hypothesisas n = n prime σ = σ prime

bull If Snminus1ProtoNonce(a)minusminusminusminusminusminusminusminusrarrSn then Fr(a) isin Snminus1 By Lemma 13

we obtain that if K(t) isin Snminus1 then a 6isin st(t) and a 6isin

st(σ prime) For each K(u) isin Sn there is K(u) isin Snminus1 and byinduction hypothesis νn primeσ prime ⊢ u By Lemma 14 and thefact that σ = σ prime we conclude that νnσ ⊢ u

bull All other rules do neither add K( )-facts nor do theychange n and may only extend σ Therefore we concludeby the induction hypothesis

2 Suppose that νnσ ⊢ t We proceed by induction on the prooftree witnessing νnσ ⊢ t

base case The proof tree consists of a single node In thiscase one of the deduction rules DName or DFrame has beenapplied

bull DName We have that t 6isin n If t isin PN we use rule MDPub

and we have that Sn rarr S = Sn cup K(t) In case t isin FN weneed to consider 3 different cases (i) K(t) isin Sn and weimmediately conclude (by letting S = Sn) (ii) Fr(t) isin Snand applying rule MDFresh we have that Sn rarr S = Sn cup

K(t) (iii) Fr(t) 6isin Sn By inspection of the rules we seethat Fr(t) 6isin Si for any 1 6 i 6 n The only rules that couldremove Fr(t) are MDFresh which would have created thepersistent fact K(t) or the ProtoNonce rules which wouldhowever have added t to n Hence applying successivelyrules Fresh and MDFresh yields a valid extension of theexecution Sn rarr Sn cup Fr(t)rarr S = Sn cup K(t)

bull DFrame We have that xσ = t for some x isin D(σ) that ist isin t1 tm By definition of t1 tm Out(t) isin Sifor some i 6 n If Out(t) isin Sn we have that Sn rarr S =

(Sn Out(t))cup K(t) applying rule MDOut If Out(u) 6isin

Sn the fact that the only rule in JPK that allows to removean Out-fact is MDOut suggests that it was applied beforeand thus K(u) isin S

inductive case We proceed by case distinction on the lastdeduction rule which was applied

bull DAppl In this case t = f(t1 tk) such that f isin Σk

and νnrσ ⊢ ti for every i isin 1 k Applying the in-duction hypothesis we obtain that there are k transitionsequences Sn rarrlowast

R Si for 1 6 i 6 k which extend the execu-

tion such that ti isin Si All of them only add K facts whichare persistent facts If any two of these extensions removethe same Out(t)-fact or the same Fr(a)-fact it also adds thepersistent fact K(t) respectively K(a) and we simply re-move the second occurrence of the transition Thereforeapplying the same rules as for the transitions Sn rarrlowast Si

(and removing duplicate rules) we have that Sn rarrlowast S prime andK(t1) K(tk) isin S prime Applying rule MDAppl we con-clude

bull DEq By induction hypothesis there exists S as requiredwith K(t prime) isinE S and t =E t

prime which allows us to immedi-ately conclude that K(t) isinE S

b21 Proofs for Section 542

Remark 3 Note that harrP (see Definition 19) has the following proper-ties (by the fact that it defines a bijection between multisets)

bull If P1 harrP S1 and P2 harrP S2 then P1 cup P2 harrP S1 cup

bull If P1 harrP S1 and Q harrP statep(t) for Q isin P1 and statep(t) isin

S1 (ie Q and statep(t) are related by the bijection defined byP1 harrP S1) then P1

QharrP S1 statep(t)

The following lemma will be used throughout Lemma 3

Lemma 15 If νnσ ⊢ t n =E nprime σ =E σ

prime and t =E tprime then νn primeσ prime ⊢ t prime

Proof Assume νnσ ⊢ t Since an application of DEq can be ap-pended to the leafs of its proof tree we have νnσ prime ⊢ t Since DEq

can be applied to its root we have νnσ prime ⊢ t prime Since n n prime consist onlyof names n = n prime and thus νn primeσ prime ⊢ t prime

The following proposition is used in Lemma 3

Proposition 3 Let A be a finite set lt a strict total order on A and p apredicate on elements of A We have that

foralli isin Ap(i) hArr foralli isin A p(i)or existj isin A i lt jandnotp(j)

(hArr foralli isin A notp(i)rarr existj isin A i lt jandnotp(j))

existi isin Ap(i) hArr existi isin Ap(i)and forallj isin A i lt jrarr notp(j)

The following Lemma implies the first direction of the inclusion

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

Proof We proceed by induction over the number of transitions n

Base Case For n = 0 we let f(n) = 1 and S1 be the multiset obtainedby using the Rule Init

emptyInitminusrarr state[]()

Condition 1 Condition 2 Condition 3 Condition 5 Condition 6Condition 7 and Condition 8 hold trivially To show that Condi-tion 4 holds we have to show that P0 harrP state[]()

Note thatP0 = P We choose the bijection such that P harrP state[]() Forτ = empty and ρ = empty we have that P|[]τ = Pτ = Pρ By Definition 18JPK=[] = JP [] []K=[] We see from Figure 14 that for every P we havethat state[]() isin prems(JP [] []K=[]) Hence we conclude that there is aground instance ri isinE ginsts(JPK=[]) with state[]() isin prems(ri)

Inductive step Assume the invariant holds for nminus 1 gt 0 We have toshow that the lemma holds for n transitions

E2minusrarr Enminusrarr (En Sn S

MSn Pn σnLn)

By induction hypothesis we have that there exists a monotonicallyincreasing function from Nnminus1 rarrNn prime and an execution

such that Conditions 1 to 8 hold Let fp be this function and note thatn prime = fp(nminus 1) Fix a bijection such that Pnminus1 harrP Sfp(nminus1) We willabuse notation by writing P harrP statep(t) if this bijection goes fromP to statep(t)

We now proceed by case distinction over the type of transition from(Enminus1 Snminus1 S

MSnminus1Pnminus1 σnminus1Lnminus1) to the last state (En Sn S

Pn σnLn) We will (unless stated otherwise) extend the previousexecution by a number of steps say s from Sn prime to some Sn prime+s andprove that Conditions 1 to 8 hold for n (since by induction hypothesisthey hold for all i lt n) and a function f Nn rarrNn prime+s that is definedas follows

f(i) =

fp(i) if i isinNnminus1

n prime + s if i = n

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup 0 σnminus1Lnminus1) rarr (Enminus1

Snminus1 SMSnminus1P

prime σnminus1Lnminus1) By induction hypothesis Pnminus1 harrP Sn prime Let p and t be such that 0 harrP statep(t) By Definition 19 thereis a ri isin ginsts(JPK=p) such that statep(t) is part of its premise Bydefinition of JPK=p we can choose

ri = [statep(t)] minus[]rarr []

We can extend the previous execution by one step using ri therefore

F2minusrarrJPK Fn primeminusrarrJPK Sn primeminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sf(nminus1) statep(t) It is left to show that Conditions 1

to 8 hold for nCondition 1 Condition 2 Condition 3 Condition 5 Condition 6

Condition 7 and Condition 8 hold triviallyCondition 4 holds because P prime = Pnminus1 0 Sf(n) = Sf(nminus1)

statep(t) and 0harrP statep(t) (see Remark 3)

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup Q|R σnminus1Lnminus1) rarr (Enminus1

prime cup QR σnminus1Lnminus1) By induction hypothesis Pnminus1

harrP Sn prime Let p and t be such that Q|RharrP statep(t) By Definition 19

there is a ri isin ginsts(JPK=p) such that statep(t) is part of its premiseBy definition of JPK=p we can choose

ri = [statep(t)] minus[]rarr [statepmiddot1(t) statepmiddot2(t)]

with Sn prime+1 = Sf(nminus1) statep(t) cup statepmiddot1(t) statepmiddot2(t)

It isleft to show that Conditions 1 to 8 hold for n

Condition 1 Condition 2 Condition 3 Condition 5 Condition 6Condition 7 and Condition 8 hold trivially We now show that Con-dition 4 holds

Condition 4 holds because Pn = Pnminus1 Q|R cup QR Q harrP

statepmiddot1(x) and RharrP statepmiddot2(x) (by definition of the translation)(see Remark 3)

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup Q σnminus1Lnminus1) rarr (Enminus1

prime cup QQ σnminus1Lnminus1) Let p and t such that iQharrP

statep(t) By Definition 19 there is a ri isin ginsts(JPK=p) such thatstatep(t) is part of its premise By definition of JPK=p we can chooseri = [statep(t)] minus[ ]rarr [statep(t) statepmiddot1(t)] We can extend the previ-ous execution by 1 step using ri therefore

F2minusrarrJPK Fn primeminusrarrJPK Sn prime

(ri)rarrJPK Sn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sf(n) cup statepmiddot1(t)

Condition 4 holds because Pn =

Pnminus1 cup Q and Q harrP statepmiddot1(t) (by definition of JPK=p) Con-

dition 1 Condition 2 Condition 3 Condition 5 Condition 6 Condi-tion 7 and Condition 8 hold trivially

Case (Enminus1 Sinminus1 SMSinminus1 Pnminus1 = P prime cup νaQ σnminus1 Lnminus1) rarr

(Enminus1 cup a prime Sinminus1 SMSinminus1P

prime cup Qaprimea σnminus1Lnminus1) for a fresh a prime

Let p and t be such that νaQ harrP statep(t) There is a ri isin

ginsts(JPK=p) such that statep(t) is part of its premise By definitionof JPK=p there is a ri isin ginsts(JPK=p) ri = [statep(t)Fr(a prime fresh)] minus[

ProtoNonce(a prime fresh)]rarr [statepmiddot1(t aprime fresh)] Assume there is an

i lt n prime such that Fr(a prime) isin Si If Fr(a prime) isin Sn then we can removethe application of the instance of Fresh that added Fr(a prime) while stillpreserving Conditions 1 to 8 If Fr(a prime) is consumned at some pointby the definition of JPK the transition where it is consumned is anno-tated either ProtoNonce(a prime) or Lock(a prime t) for some t In the last casewe can apply a substitution to the execution that substitutes a by adifferent fresh name that never appears in cupi 6 n primeSi The conditionswe have by induction hypothesis hold on this execution too sinceLock isin Fres and therefore Condition 8 is not affected The first caseimplies that a prime isin Enminus1 contradicting the assumption that a prime is fresh

with respect to the process execution Therefore without loss of gen-erality the previous execution does not contain an i lt n prime such thatFr(a prime) isin Si and we can extend the previous execution by two stepsusing the Fresh rule and ri therefore

F2minusrarrJPK

Fn primeminusrarrJPK Sn prime

(Fresh)rarrJPK Sn prime+1

with Sn prime+1 = Sn prime cup Fr(a prime fresh) and Sn prime+2 = Sf(n) = Sn prime cup

statepmiddot1(t aprime fresh) We define f(i) = fp(i) for i lt n and f(n) =

f(nminus 1) + 2 We now show that Condition 4 holds As by inductionhypothesis νaQ harrP statepmiddot1(t) we also have that P|pσ = νaQρ forsome σ and ρ Extending ρ with a prime 7rarr a it is easy to see from def-inition of JPK=p that Qa

primea harrP statepmiddot1(t a

prime) As Pn = Pnminus1

νaQ cup Qaprimea

we also immediately obtain that Pn harrP Sf(n)Since Fn = ProtoNonce(a prime) and a prime is fresh and therefore a prime =

En Enminus1 Condition 1 holds Condition 2 Condition 3 Condition 5Condition 6 Condition 7 and Condition 8 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 σnminus1Lnminus1)

K(t)minusrarr (Enminus1 Snminus1 S

MSnminus1

Pnminus1 σnminus1Lnminus1) This step requires that νEnminus1σnminus1 ⊢ t From

Lemma 2 follows that there is an execution emptyF1minusrarrS1

F2minusrarr Fn primeminusminusrarrSn prime rarrlowast

S isin execmsrE (JPK) such that K(t) isinE S and Sn prime rarrlowast

R S for R = MDOut

MDPubMDFreshMDAppl From S we can go one further step using MDIn since K(t) isin S

emptyF1minusrarrJPKS1

F2minusrarrJPK

Fn primeminusminusrarrJPKSn primeminusrarrlowast

RsubJPKS = Sn prime+sminus1K(t)minusminusminusrarrJPKSn prime+s isin execmsr(JPK)

where Sn prime+s = Scup In(t)From the fact that Sf(nminus1) rarr

lowastR Sf(n) = S and the induction hypoth-

esis we can conclude that Condition 8 holds Condition 4 holds sincePn = Pnminus1 and no state-facts where neither removed nor addedCondition 1 Condition 2 Condition 3 Condition 5 Condition 6 andCondition 7 hold trivially

Case (Enminus1 Snminus1 SMSnminus1 Pnminus1 = P prime cup out(t t prime)Q σnminus1 Lnminus1)

K(t)minusminusminusrarr(Enminus1 Snminus1 S

MSnminus1P

prime cup Q σnminus1 cup t primexLnminus1) This step re-

quires that x is fresh and νEnminus1σ ⊢ t Using Lemma 2 we have that

there is an execution emptyF1minusrarrS1

F2minusrarr Ff(n)minusminusminusrarrSf(nminus1) rarr

lowast S isin execmsrE (JPK)

such that K(t) isinE S and Sf(nminus1) rarrlowastR S for R = MDOutMDPub

MDFreshMDAppl Let p and t st out(t t prime)Q harrP statep(t) ByDefinition 19 there is a ri isin ginsts(JPK=p) such that statep(t) is part ofits premise From the definition of JPK=p we see that we can chooseri = [statep(t) In(t)] minus[ InEvent(t)]rarr [Out(t prime) statepmiddot1(t)] To apply

this rule we need the fact In(t) Since νEnminus1σ ⊢ t as mentionedbefore we can apply Lemma 2 It follows that there is an execution

emptyF1minusrarrS1

F2minusrarr Fn primeminusminusrarrSn prime rarrlowast S isin execmsr

E (JPK) such that K(t) isinE S andSn prime rarrlowast

R S for R = MDOutMDPubMDFreshMDAppl From Swe can now go two steps further using MDIn and ri

Fn primeminusrarrJPK Sn prime rarrlowast

RsubJPK S = Sn prime+sminus2

K(t)minusminusminusrarrJPKSn prime+sminus1

InEvent(t)minusminusminusminusminusminusrarrJPKSn prime+s isin execmsr(JPK)

where Sn prime+sminus1 = Scup In(t) and

Sf(n) = S statep(t) cup

Out(t prime) statepmiddot1(t)

Taking k = n prime + s minus 1 we immediately obtain that Condition 8

holds Note first that since Sn prime rarrR S set(Sn prime) Fr(t)Out(t)|t isin

M sub set(S) and set(S) K(t)|t isin M sub set(Sn prime) Since Pn =

Pnminus1 out(t t prime)Q cup Q and Q harrP statepmiddot1(t) (by definition ofJPK=p) we have that Pn harrP Sf(n) i e Condition 4 holds Condi-tion 5 holds since t prime was added to σnminus1 and Out(t) added to Sf(nminus1)Condition 7 holds since K(t) appears right before InEvent(t) Condi-tion 1 Condition 2 Condition 3 and Condition 6 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup in(tN)Q σnminus1Lnminus1) rarr

(Enminus1 Snminus1 SMSnminus1P

prime cup Qθ σnminus1Lnminus1) This step requires thatθ is grounding for N and that νEnminus1σnminus1 ⊢ 〈tNθ〉 Using Lemma 2

we have that there is an execution emptyF1minusrarrS1

F2minusrarr Ff(nminus1)minusminusminusminusrarrSf(nminus1) rarr

lowast

S isin execmsrE (JPK) such that K(t) isinE S and Sf(nminus1) rarr

lowastR S for R =

MDOutMDPubMDFreshMDAppl The same holds for Nθ Wecan combine those executions by removing duplicate instantiationsof Fresh MDFresh and MDOut (This is possible since K is per-

sistent) Let emptyF1minusrarrS1

lowastR S isin execmsr

E (JPK) thiscombined execution and K(t) K(Nθ) isinE S

Let p and t be such that in(tN)Q harrP statep(t) By Definition 19

there is a ri isin ginsts(JPK=p) such that statep(t) is part of its premiseFrom the definition of JPK=p and the fact that θ is grounding for Nθwe have statep(t) in their premise namely

ri = [statep(t) In(〈tNθ〉)]

minus[InEvent(〈tNθ〉)]rarr [statepmiddot1(tcup (vars(N)θ)]

From Sn prime we can first apply the above transition Sn prime rarrlowastR S and

then (since K(t) K(Nθ) statep(x) isin S) MDAppl for the pair con-structer MDIn and ri

(MdAppl)minusminusminusminusminusminusrarrJPKSn prime+sminus2

K(〈tNθ〉)minusminusminusminusminusminusminusrarrJPKSn prime+sminus1

InEvent(〈tNθ〉)minusminusminusminusminusminusminusminusminusminusrarrJPKSn prime+s isin execmsr(JPK) where

bull since Sn prime rarrR S S is such that set(Sn prime) Fr(t)Out(t)|t isin M sube

set(S) set(S) K(t)|t isinM sube set(Sn prime) and K(t) K(Nθ) isin S

bull Sn prime+sminus2 = Scup K(〈tNθ〉)

bull Sn prime+sminus1 = Scup In(〈tNθ〉)

bull Sn prime+s = S statep(t) cup statepmiddot1(tcup (vars(N)θ))

Letting k = n prime + sminus 1 we immediately have that Condition 8 holdsWe now show that Condition 4 holds Since by induction hypoth-

esis in(tN)Q harrP statep(t) we have that P|pτ = in(tN)Qρ forsome τ and ρ Therefore we also have that P|pmiddot1τ cup (θρ) = Qρ(θρ)

and it is easy to see from definition of JPK=p that QθharrP statepmiddot1(t

(vars(N)θ)) Since Pn = Pnminus1 in(tN)Q cup Q we have thatPn harrP Sf(n) i e Condition 4 holds Condition 7 holds since K(〈tNθ〉) appears right before InEvent〈tNθ〉) Condition 1 Condition 2Condition 3 Condition 5 and Condition 7 hold trivially

Case (E S SMSP cup out(cm)Q cup in(c prime N)R σL) rarr (E S SMS

P cup QRθ σL) This step requires that θ grounding for N t =E

Nθ and c =E c prime Let p p prime and t N such that out(cm)P harrP

statep(t) in(c prime N)QharrP statep prime(t prime) and there are ri isin ginsts(JPK=p)

and ri prime isin ginsts(JPK=p prime) such that statep(t) and statep prime(t prime) are part oftheir respective premise From the definition of JPK=p and the factthat θ is grounding for N we have

ri1 = [statep(t)]rarr [Msg(tNθ) statesemipmiddot1 (t)]

ri2 = [statep prime(t prime)Msg(tNθ)]rarr [statep primemiddot1(tprime cup (vars(N)θ))

Ack(tNθ)]

ri3 = [statesemip (t)Ack(tNθ)]rarr [statepmiddot1(t)]

Hence we can extend the previous execution by 3 steps

(ri1)rarrJPK Sn prime+sminus2

(ri2)rarrJPK Sn prime+s isin execmsr(JPK)

bull Sn prime+sminus2 = Sn prime statep(t) cup Msg(tNθ) statesemi

pmiddot1 (t)

bull Sn prime+sminus1 = Sn prime statep(t) statep prime(t prime) cup statesemipmiddot1 (t)Ack(t

Nθ) statep primemiddot1(tprime cup (vars(N)θ))

bull Sn prime+s = Sn prime statep(t) statep prime(t prime) cup statepmiddot1(t) statep primemiddot1(tprime

cup (vars(N)θ))

We have that Pn = Pnminus1 out(cm)Q in(c prime t prime)R cup QRθ Exactly as in the two previous cases we have that Q harr statepmiddot1(t)as well as Rθ harr statep primemiddot1(t

prime) Hence we have that Condition 4 holdsCondition 1 Condition 2 Condition 3 Condition 5 Condition 6 Con-dition 8 and Condition 7 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup if t = t prime then Q else Q prime

σnminus1Lnminus1) rarr (Enminus1 Snminus1 SMSnminus1P

prime cup Q σnminus1Lnminus1) This steprequires that t =E t

prime By induction hypothesis Pnminus1 harrP Sn prime Letp and t be such that if t = t prime then Q else Q prime harrP statep(t) By Defini-tion 19 there is a ri isin ginsts(JPK=p) such that statep(t) is part of itspremise By definition of JPK=p we can choose

ri = [statep(t)] minus[Eq(t t prime)]rarr [statepmiddot1(t)]

Eq(tt prime)minusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sn prime statep(t) cup statepmiddot1(t)

It is left to showthat Conditions 1 to 8 hold for n The last step is labelled Ff(n) =

Eq(t t prime) As t =E tprime Condition 7 holds in particular αeq is not

violated Since Eq is reserved Condition 8 holds as wellAs before since Pn = Pnminus1

if t = t prime then Q else Q prime cup Q andQ harr statepmiddot1(t a) (by definition of the translation) we have thatPn harrP Sf(n) and therefore Condition 4 holds Condition 1 Condi-tion 2 Condition 3 Condition 5 and Condition 6 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup if t = t prime then Q prime else Q

σnminus1Lnminus1) minusrarr (Enminus1 Snminus1 SMSnminus1 P

prime cup Q prime σnminus1 Lnminus1) Thisstep requires that t 6=E t

prime This case is similar to the previous caseexcept ri is chosen to be

[statep(t)] minus[NotEq(t t prime)]rarr [statepmiddot2(t)]

The condition in αnoteq holds since t 6=E tprime

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup event(F)Q σnminus1Lnminus1)

Fminusrarr

(Enminus1 Snminus1 SMSnminus1

P prime cup Q σnminus1Lnminus1) By induction hypothesis Pnminus1 harrP Sn prime Letp and t be such that event(F)Q harrP statep(t) By Definition 19 thereis a ri isin ginsts(JPK=p) such that statep(t) is part of its premise Bydefinition of JPK=p we can choose

ri = [statep(t)] minus[FEvent()]rarr [statepmiddot1(t)]

FEvent()minusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sn prime) statep(t) cup

statepmiddot1(t) It is left to show thatConditions 1 to 8 hold for n Condition 4 holds because Pn =

Pnminus1 event(F)Q cup Q and Q harr statepmiddot1(t) (by definition of

JPK=p) Taking k = f(n) Condition 8 holds Condition 1 Condition 2Condition 3 Condition 5 Condition 6 and Condition 7 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup insert t t prime Q σnminus1Lnminus1)

rarr (Enminus1 Sn = Snminus1[t 7rarr t prime]

SMSnminus1P

prime cup Q σnminus1Lnminus1) By induction hypothesis Pnminus1 harrP Sn prime Let p and t be such that insert t t prime QharrP statep(t) By Definition 19there is a ri isin ginsts(JPK=p) such that statep(t) is part of its premiseBy definition of JPK=p we can choose

ri = [statep(t)] minus[Insert(t t prime)]rarr [statepmiddot1(t)]

Insert(tt prime)minusminusminusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sf(nminus1) statep(t)

cup statepmiddot1(t) It is left to show

that Conditions 1 to 8 hold for nThis step is labelled Ff(n) = Insert(t t prime) hence Condition 8 holds

To see that Condition 2 holds we let j = f(n) for which both conjunctstrivially hold Since by induction hypothesis Condition 7 holds ie[F1 Fn prime ] α it holds for this step too In particular if [F1 Fn prime ]

αin and [F1 Fn prime ] αnotin we also have that [F1 Fn prime Ff(n)] αin

and [F1 Fn prime Ff(n)] αnotin As the Insert-action was added at thelast position of the trace it appears after any InIn or IsNotSet-actionand by the semantics of the logic the formula holds

Since Pn = Pnminus1 insert t t prime Q cup Q and Q harr statepmiddot1(t)

(by definition of JPK=p) we have that Condition 4 holds Condition 1Condition 3 Condition 5 and Condition 6 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup delete t Q σnminus1Lnminus1) rarr

(Enminus1 Sn = Snminus1[t 7rarr perp]

SMSnminus1P

prime cup Q σnminus1Lnminus1) By induction hypothesis Pnminus1 harrP Sn prime Let p and t be such that delete t Q harrP statep(t) By Definition 19there is a ri isin ginsts(JPK=p) such that statep(t) is part of its premiseBy definition of JPK=p we can choose

ri = [statep(t)] minus[Delete(t)]rarr [statepmiddot1(t)]

Delete(t)minusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sf(nminus1) statep(t) cup

statepmiddot1(t) It is left to showthat Conditions 1 to 8 hold for n

This step is labelled Ff(n) = Delete(t) hence Condition 8 holdsSince by induction hypothesis Condition 7 holds ie [F1 Fn prime ]

α it holds for this step too In particular if [F1 Fn prime ] αin and[F1 Fn prime ] αnotin we also have that [F1 Fn prime Ff(n)] αin and[F1 Fn prime Ff(n)] αnotin As the Insert-action was added at the lastposition of the trace it appears after any InIn or IsNotSet-actions andby the semantics of the logic the formula holds

We now show that Condition 2 holds We have that Sn = Snminus1[t 7rarr

perp] and therefore for all t prime 6=E Tt Sn(x) = Snminus1(x) Hence for allsuch t prime we have by induction hypothesis that for some u

existj 6 n primeInsert(t prime u) isin Fj and forallj prime u primej lt j prime 6 n prime

rarr Insert(t prime u prime) 6isinE Fj prime and Delete(t prime) 6isinE Fj prime

As Fn prime+1 6=E Delete(x u) and Fn prime+1 6=E Insert(x u prime) for all u prime isinMwe also have that

existj 6 n prime + 1Insert(t prime u) isin Fj and forallj prime u primej lt j prime 6 n prime + 1

For t prime =E t the above condition can never be true because Fn prime+1 =

Delete(t) which allows us to conclude that Condition 2 holdsSince Pn = Pnminus1

delete t Q cup Q and Pharr statepmiddot1(t) (bydefinition of JPK=p) we have that Condition 4 holds Condition 1Condition 3 Condition 5 and Condition 6 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup lookup t as x in Q else Q prime

prime cup Qvx σnminus1Lnminus1) Thisstep requires that Snminus1(t

prime) =E v for some t prime =E t By inductionhypothesis Pnminus1 harrP Sn prime Let p and t be such that lookup t as v in Q

else Q prime harrP statep(t) By Definition 19 there is a ri isin ginsts(JPK=p)

such that statep(t) is part of its premise By definition of JPK=p wecan choose

ri = [statep(t)] minus[IsIn(t v)]rarr [statepmiddot1(t v)]

IsIn(tv)minusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

This step is labelled Ff(n) = IsIn(t v) hence Condition 8 holdsFrom the induction hypothesis Condition 2 we have that there is

a j such that Insert(t t prime) isinE Fj j 6 n prime and

forallj prime u prime j lt j prime 6 n prime rarr Insert(t u prime) 6isinE Fj prime and Delete(t) 6isinE Fj prime

This can be strengthened since Ff(n) = IsIn(t v)

forallj prime u prime j lt j prime 6 f(n)rarr Insert(t u prime) 6isinE Fj prime and Delete(t) 6isinE Fj prime

We can now conclude that Condition 2 holds From Condition 2 italso follows that Condition 7 in particular αin holds

We now show that Condition 4 holds By induction hypothesis wehave that lookup t as x in Q else Q prime harrP statep(t) and hence P|pτ =

(lookup t as x in Q else Q prime)ρ for some τ and ρ Therefore we also havethat P|pmiddot1τ cup (vρx) = Qρvρx) and it is easy to see from defini-tion of JPK=p that Qvx harrP statepmiddot1(t v) Since Pn = Pnminus1

lookup t as x in Q else Q prime cup Qvx we have that Pn harrP Sf(n)i e Condition 4 holds

Condition 1 Condition 3 Condition 5 and Condition 6 hold triv-ially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup lookup t as x in Qelse Q prime

prime cup Q prime σnminus1 Lnminus1) Thisstep requires that S(t prime) is undefined for all t prime =E t By inductionhypothesis Pnminus1 harrP Sn prime Let p and t be such that lookup t as x in Q

ri = [statep(t)] minus[IsNotSet(t)]rarr [statepmiddot1(t)]

IsNotSet(t)minusminusminusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

statepmiddot1(t) It is left to show thatConditions 1 to 8 hold for n

This step is labelled Ff(n) = IsNotSet(t) hence Condition 8 holdsCondition 2 also holds trivially and will be used to show Condition 7Since this step requires that S(t prime) is undefined for all t prime =E t we haveby Condition 2 that

forallj 6 f(n) u Insert(t u) isinE Fjrarr existj prime u primej lt j prime 6 f(n)

and (Insert(t u prime) isinE Fj prime or Delete(t) isinE Fj prime)

Now suppose that

existi 6 f(n) yInsert(t y) isinE Fi)

As there exists an insert there is a last insert and hence we also have

existi 6 f(n) y Insert(t y) isinE Fiand foralli prime y primei lt i prime 6 f(n)rarr Insert(t y prime) isinE Fi prime

Applying Condition 2 (cf above) we obtain that

existi 6 f(n) y Insert(t y) isinE Fiand foralli prime y prime i lt i prime 6 f(n)rarr Insert(t y prime) isinE Fi prime

and existj prime u prime i lt j prime 6 f(n)

which simplifies to

existi 6 f(n) y Insert(t y) isinE Fiand foralli prime y prime i lt i prime 6 f(n)rarr Insert(t prime y prime) isin Fi prime

and existj prime i lt j prime 6 f(n)and Delete(t) isinE Fj prime

Now we weaken the statement by dropping the first conjunct andrestricting the quantification foralli primei lt i prime 6 f(n) to foralli primej prime lt i prime 6 f(n)since i lt j prime

existi 6 f(n) existj prime i lt j prime 6 f(n)and foralli prime j prime lt i prime 6 f(n)

rarr Insert(t prime y prime) isin Fi prime and Delete(t) isinE Fj prime

We further weaken the statement by weakening the scope of the exis-tential quantification existj prime i lt j prime 6 f(n) to existj prime j prime 6 f(n) Afterwards iis not needed anymore

existj prime j prime 6 f(n)and foralli prime j prime lt i prime 6 f(n)

This statement was obtained under the hypothesis that existi 6 f(n) yInsert(t y) isinE Fi) Hence we have that

foralli 6 f(n) y Insert(t y) 6isinE Fiorexistj prime 6 f(n) Delete(t) isinE Fj prime and foralli prime j prime lt i prime 6 f(n)

rarr Insert(t prime y prime) isin Fi prime

This shows that Condition 7 in particular αnotin holdsSince Pn = Pnminus1

lookup t as x in Q else Q prime cup Q prime and Q primeharr

statepmiddot1(t) (by definition of JPK=p) we have that Condition 4 holdsCondition 1 Condition 3 Condition 5 and Condition 6 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup lock t Q σnminus1Lnminus1) minusrarr

prime cup Q prime σnminus1Lnminus1 cup t ) This step requiresthat for all t prime =E t t prime isin Lnminus1 Let p and t such that lock t Q harrP

statep(t) By Definition 19 there is a ri isin ginsts(JPK=p) such thatstatep(t) is part of its premise By definition of JPK=p we can chooseri = [Fr(l) statep(t)] minus[Lock(l t)]rarr [statepmiddot1(t l)] for a fresh name lthat never appeared in a Fr-fact in cupj6f(nminus1)Sj We can extend the

previous execution by s = 2 steps using an instance of Fresh for land ri

F2minusrarrJPK Fn primeminusrarrJPK Sn primeminusrarr fresh Sn prime+sminus1

Lock(lt)minusminusminusminusminusminusrarrJPKSn prime+s isin execmsr(JPK)

with Sn prime+sminus1 = Sf(nminus1) statep(t)

cup Fr(l) and Sn prime+s = Sf(nminus1)

statep(t) cup statepmiddot1(t)

It is left to show that Conditions 1 to8 hold for n

The step from Sf(n)minus1 to Sf(n) is labelled Ff(n) = Lock(l t) henceCondition 8 and Condition 2 holdFf(n) also preserves Condition 6 for the new set of active locks

Lf(n) = Lf(nminus1) cup t In the following we show by contradiction that αlock and therefore

Condition 7 holds αlock held in the previous step and Ff(nminus1)+1

is empty so we assume (by contradiction) that Ff(n) = Lock(l t)violates αlock If this was the case then

existi lt f(n) l1 Lock(l1 t) isinE Fiand

and forallj i lt j lt f(n)rarr Unlock(l1 t) 6isinE Fjor existl2 k i lt k lt j

and (Lock(l2 t) isinE Fk or Unlock(l2 t) isinE Fk) (4)

Since the semantics of the calculus requires that for all t prime =E t t prime isinLnminus1 by induction hypothesis Condition 6 we have that

foralli lt f(nminus 1) l1 Lock(l1 t) isinE Fi rarr

existj i lt j lt f(nminus 1)and Unlock(l1 t) isinE Fj

Since Ff(nminus1)+1 = empty and f(n) = f(nminus 1) + 2 we have

foralli lt f(n) l1Lock(l1 t) isinE Fi rarr

existj i lt j lt f(n)and Unlock(l1 t) isinE Fj

We apply Proposition 3 for the total order gt on the integer intervali+ 1f(n) minus 1

foralli lt f(n) l1 Lock(l1 t) isinE Fi rarr

existj i lt j lt f(n)and Unlock(l1 t) isinE Fjand forallk i lt k lt jrarr Unlock(l1 t) 6isinE Fk

Combining this with (4) we obtain that

existj i lt j lt f(n)and Unlock(l1 t) isinE Fjand existl2 k i lt k lt jand (Lock(l2 t) isinE Fkor (Unlock(l2 t) isinE Fk and l2 6=E l1))

Fix i lt f(n) j such that i lt j lt f(n) and l1 such that Lock(l1 t) isinEFi and Unlock(l1 t) isinE Fj Then there are l2 and k such that i lt k lt jand either Lock(l2 t) isinE Fk or Unlock(l2 t) isinE Fk but l2 6=E l1 Weproceed by case distinctionCase 1 there is no unlock in between i and j i e for all m i lt m lt jUnlock(l prime t) 6isin Fm Then there is a k and l2 such that Lock(l2 t) isinEFk In this case αlock is already invalid at the trace produced by thek-prefix of the execution contradicting the induction hypothesisCase 2 there are l prime and m i lt m lt j such that Unlock(l prime t) isin Fm(see Figure 16)

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Figure 16 Visualisation of Case 2

We first observe that for any l u i1 i2 if Unlock(lu) isinE Fi1 andUnlock(lu) isinE Fi2 then i1 = i2 We proceed by contradiction Bydefinition of JPK and well-formedness of P the steps from i1 minus 1 toi1 and from i2 minus 1 to i2 must be ground instances of rules JPK=q andJPK=q prime such that P|q and P|q prime start with unlock commands that arelabelled the same and have the same parameter since every variablelockl in JPK appears in a Fr-fact in the translation for the correspond-ing lock command By definition of P this means q and q prime have acommon prefix ql that starts with a lock with this label

Let ql 6 q denote that ql is a prefix of q Since P gives perp if thereis a replication or a parallel between ql and q or q prime and since P iswell-formed (does not contain perp) we have that every state fact staterfor ql 6 r 6 q or ql 6 r 6 q prime appearing in JPK is a linear fact sinceno replication is allowed between ql and q or q prime This implies thatq prime 6= q Furthermore every rule in cupql6r6qorql6r6q primeJPK=r adds atmost one fact stater and if it adds one fact it either removes a factstater prime where r = r prime middot 1 or r prime middot 2 or removes a fact statesemi

r prime wherer = r prime middot 1 which in turn requires removing stater prime (see translation ofout) Therefore either q 6 q prime or q prime 6 q But this implies that bothhave different labels and since JPK=ql

requires Fr(l) and E distin-guishes fresh names we have a contradiction (A similiar observa-tion is possible for locks For any l u i1 i2 if Lock(lu) isinE Fi1 andLock(lu) isinE Fi2 then i1 = i2 since by definition of the translationthe transition from i1 minus 1 to i1 or iminus 2minus 1 to i2 removes fact Fr(l))

From the first observation we learn that l prime 6=E l1 for any l prime andm i lt m lt j such that Unlock(l prime t) isin Fm We now choose thesmallest such m By definition of JPK the step from Smminus1 to Sm mustbe ground instance of a rule from JPK=q for P|q starting with unlockSince P is well-formed there is a ql such that P|ql

starts with lockwith the same label and parameter as the unlock As before since Pis well-formed and therefore there are no replications and parallels

between ql and q there must be n such that Lock(l prime t) isin Fn andn lt m We proceed again by case distinctionCase 2a n lt i (see Figure 17) By the fact that m gt i we have thatthere is no o such that n lt o lt i and Unlock(l prime t) isinE Fo (see firstobservation) Therefore the trace produced by the i-prefix of thisexecution does already not satisfy αlock i e [F1 Fi] 6 αlock

Lock(l prime t)

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Figure 17 Visualisation of Case 2a

Case 2b i lt n (see Figure 18) Again [F1 Fn] 6 αlock since thereis no o such that i lt o lt n and Unlock(l1 t) isinE Fo

Lock(l1 t)

Lock(l prime t)

Unlock(l prime t)

Unlock(l1 t)

Figure 18 Visualisation of Case 2b

Since we could under the assumption that Condition 1 to Condi-tion 8 hold for i 6 n prime reduce every case in which [F1 Fn prime+1] 6

αlock to a contradiction we can conclude that Condition 7 holds forn prime + 1

Since Pn = Pnminus1 lock t Q cup Q and Q harr statepmiddot1(t) (by

definition of the translation) we have that Condition 4 holds Condi-tion 1 Condition 3 and Condition 5 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P prime cup unlock t Q σnminus1Lnminus1)rarr

prime cup Q prime σnminus1Lnminus1 tprime t prime =E t ) By induc-

tion hypothesis Pnminus1 harrP Sn prime Let p and t be such that unlock t Q

harrP statep(t) By Definition 19 there is a ri isin ginsts(JPK=p) such thatstatep(t) is part of its premise By definition of JPK=p we can choose

ri = [statep(t)] minus[Unlock(l t)]rarr [statepmiddot1(t)]

Unlock(lt)minusminusminusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

The step from Sf(nminus1) to Sf(n) is labelled Ff(n) = Unlock(l t)hence Condition 8 and Condition 2 hold

In order to show that Condition 6 holds we perform a case dis-tinction Assume t 6isinEisin Lnminus1 Then Lf(nminus1) = Lf(n) In this caseCondition 6 holds by induction hypothesis In the following we as-sume t isinE Lnminus1 Thus there is j isin n prime l prime such that Lock(l prime t) isinE Fjand for all k such that j lt k 6 n prime Unlock(l prime t) 6isinE Fk

Since P|p is an unlock node and P is well-formed there is a prefix qof p such that P|q is a lock with the same parameter and annotationBy definition of P there is no parallel and no replication betweenq and p Note that any rule in JPK that produces a state namedstatep for a non-empty p is such that it requires a fact with namestatep prime for p = p prime middot 1 or p = p prime middot 2 (in case of the translation of out itmight require statesemi

p prime which in turn requires statep prime) This meansthat since statep(t) isin Sn prime there is an i such that stateq(t

prime) isin Si andstateq(t

prime) 6isin Siminus1 for t prime a prefix to t This rule is an instance of JPK=q

and thus labelled Fi = Lock(l t) We proceed by case distinction

Lock(l prime t)

Lock(l t)

n prime + 1

Unlock(l t)

Case 1 j lt i (see Figure 19) By induction hypothesis Condition 7

holds for the trace up to n prime But [F1 Fi] 6 αlock since we assumedthat for all k such that j lt k 6 n prime Unlock(l prime t) 6isinE Fk

Lock(l t)

Lock(l prime t)

n prime + 1

Unlock(l t)

Case 2 i lt j (see Figure 20) As shown in the lock case any k suchthat Unlock(l t) isinE Fk is k = n prime + 1 This contradicts Condition 7 forthe trace up to j since [F1 Fj] 6 αlock because there is not k suchthat i lt k lt j such that Unlock(l t) isinE Fk This concludes the proofthat Condition 6 holds for n+ 1

Condition 7 holds since none of the axioms in particular not αlockbecome unsatisfied if they were satisfied for the trace up to f(nminus 1)

and an Unlock is addedSince Pn = Pnminus1 unlock t Q cup Q and Q harr statepmiddot1(t)

(by definition of the translation) we have that Condition 4 holds Con-dition 1 Condition 3 and Condition 5 hold trivially

Case (Enminus1 Snminus1 SMSnminus1Pnminus1 = P primecup l minus[a]rarr r Q σnminus1Lnminus1)

aminusrarr

(Enminus1 Snminus1 SMSnminus1 lfacts(l prime)cup mset(r)P prime cup Q σnminus1Lnminus1) This

step requires that l prime minus[a prime]rarr r prime isinE ginsts(l minus[a]rarr r) and lfacts(l prime) sub

SMSnminus1 pfacts(l prime) sub mset(SMS

nminus1) Let θ be a substitution such that (l minus[a]rarr r)θ = (l prime minus[ a prime]rarr r prime) Since by induction hypothesis SMS

nminus1 =

Sn prime Fres we therefore have lfacts(l prime) sub Sn prime pfacts(l prime) sub mset(Sn prime)By induction hypothesis Pnminus1 harrP Sn prime Let p and t be such that l minus[a]rarr r Q harrP statep(t) By Definition 19 there is a ri isin ginsts(JPK=p)

ri = [statep(t) lprime] minus[a primeEvent()]rarr [r prime statepmiddot1(tcup (vars(l)θ))]

a primeEvent()minusminusminusminusminusminusrarrJPKSn prime+1 isin execmsr(JPK)

with Sn prime+1 = Sf(nminus1) statep(t) lfacts(l prime) cup mset(r prime) cup

statepmiddot1(t cup (vars(l)θ)) It is left to show that Conditions 1 to 8

hold for nCondition 3 holds since

SMSn = SMS

nminus1 lfacts(l prime)cup mset(r)

= (Sn prime Fres) lfacts(l prime)cup mset(r) (induction hypothesis)

= (Sn prime lfacts(l prime)cup mset(r) statep(t)

cup statepmiddot1(tcup (vars(l)θ)) ) Fres

(since statep(t) statepmiddot1(tcup (vars(l)θ)) isin Fres)

= Sf(n) Fres

The step from Sf(nminus1) to Sf(n) is labelled Ff(n) = a and does notcontain actions in Fres since P is well-formed Hence Condition 2Condition 6 Condition 7 and Condition 8 hold

Since Pn = Pnminus1 l minus[a]rarr r Q cup Q and Q harr statepmiddot1(t cup

(vars(l)θ)) (by definition of JPK=p) we have that Condition 4 holdsCondition 1 and Condition 5 hold trivially

Definition 33 (normal MSR execution) A MSR execution

emptyE1minusrarrJPK middot middot middot

EnminusminusrarrJPKSn isin execmsr(JPK)

for the multiset rewrite system JPK defined by a ground process P isnormal if

1 The first transition is an instance of the Init rule i e S1 =

state[]() and there is at least this transition

2 Sn neither contains any fact with the symbol statesemip for any p

nor any fact with symbol Ack

3 if for some i isinN and t1 t2 isinM Ack(t1 t2) isin (Siminus1 Si) then

there are p and q such that

Siminus3minusrarrR1Siminus2minusrarrR2

Siminus1minusrarrR3Si where

bull R1 = [statep(x)]rarr [Msg(t1 t2) statesemip (x)]

bull R2 = [stateq(y)Msg(t1 t2)]rarr [stateqmiddot1(ycup yprime)Ack(t1 t2)]

bull R3 = [statesemip (x)Ack(t1 t2)]rarr [statepmiddot1(x)]

4 Snminus1EnminusminusrarrJP[][]KMDInInitSn

5 if In(t) isin (Siminus1 Si) then Siminus2

K(t)minusminusminusrarrMDInSiminus1 (for some i isin N

and t isinM)

6 if n gt 2 and no Ack-fact in (Siminus1 Si) then there exists m lt n

such that Sm rarrlowastR Snminus1 for R = MDOutMDPubMDFresh

MDApplFresh and emptyE1minusrarrJPK middot middot middot

EmminusminusrarrJPKSm isin execmsr(JPK) is nor-mal

7 if for some t1 t2 isin M Ack(t1 t2) isin (Snminus1 Sn) then there

exists m 6 nminus 3 such that emptyE1minusrarrJPK middot middot middot

EmminusminusrarrJPKSm isin execmsr(JPK) isnormal and Sm rarrlowast

R Snminus3 for R = MDOutMDPubMDFresh

MDApplFresh

Proof We will modify S0E1minusrarrJPK

EnminusrarrJPK Sn by applying one trans-formation after the other each resulting in an MSR execution that stillfulfills the conditions on its trace

1 If an application of the Init rule appears in S0E1minusrarrJPK

EnminusrarrJPK

Sn we move it to the front Therefore S1 = state[]() This ispossible since the left-hand side of the Init rule is empty Ifthe rule is never instantiated we prepend it to the trace SinceInit() isin Fres the resulting MSR execution

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

is such that hide([E1 En]) = hide([E(1)1 E

n(1) ]) Since

Init() is only added if it was not present before [E(1)1 E(1)

n(1) ]

α especially αinit

2 For each fact Ack(t1 t2) contained in S(1)n(1 it also contains a fact

statesemip (t) for some p and t such that there exists a rule of type

R3 that consumes both of them since Ack(t1 t2) can only be pro-duced by a rule of type R2 which consumes Msg(t1 t2) whichin turn can only be produced along with a fact statesemi

p (t) andby definition of JPK there exists a rule in JPK=p of form R3 thatconsumes Ack(t1 t2) and statesemi

p (t) We append as many ap-

plications of rules of type R3 as there are facts Ack(t1 t2) isin S(1)

and repeat this for all t1 t2 such that Ack(t1 t2) isin S(1)

n(1) Then

n(1)minusrarrJPKS(1)n prime and S(1)n prime does not contain Ack-facts anymore

If S(1)n prime contains a fact statesemip (t) we remove the last transi-

tion that produced this fact i e for i such that Si = Siminus1

statep(t) cup Msg(t1 t2) state

semip (t) we define S(1)

j = S(1)j

if j 6 i minus 1 and S(1) prime

j = S(1)j+1 Msg(t1 t2) state

semip (t) cup

statep(t) if iminus 1 lt j lt n prime The resulting execution is valid

since statesemip (t) isin S

(1)n prime and since Msg(t1 t2) isin S

(1)n prime The latter

is the case because if Msg(t1 t2) would be consumned at a laterpoint say j j+1would contain Ack(t1 t2) but since S(1)

n primeminus1 doesnot contain Ack-facts they can only be consumned by a rule oftype R3 which would have consumned statesemi

p (t) We repeat

this procedure for every remaining statesemip (t) isin S

(1)n prime and call

the resulting trace

E(2)1minusrarrJPK

E(2)nminusrarrJPK S

Since no rule added or removed or removed has an actionhide([E1 En]) = hide([E

(2)1 E

n(2) ]) and [E(2)1 E

n(2) ]

3 We transform S(1)0

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

n(1) as follows (all equal-ities are modulo E) Let us call instances of R1 R2 or R3 thatappear outside a chain

Siminus1minusrarrR3Si

for some i t1 t2 isin M ldquounmarkedrdquo Do the following for thesmallest i that is an unmarked instance of R3 ( we will call theinstance of R3 ri3 and suppose it is applied from Siminus1 to Si)Apply ri3 after j lt i such that Sjminus1 to Sj is the first unmarkedinstance of R2 for some q and yi e this instance producesa fact stateqmiddot1(y y

prime) and a fact Ack(t1 t2) Since there is norule between j and i that might consume Ack(t1 t2) (only rulesof form R3 do and ri3 is the first unmarked instance of sucha rule) and since ri3 does not consume stateqmiddot1(y y

prime) we canmove ri3 between j and j + 1 adding the conclusions of ri3and removing the premises of ri3 from every Sj+1 Si Notethat unmarked instances of R2 and R3 are guaranteed to be pre-ceeded by a marked R1 and therefore only remove facts of form

Ack( ) or Msg( ) that have been added in that preceedingstep Since the transition at step j requires a fact Msg(t1 t2)there is an instance of R1 prior to j say at k lt j since only rulesof form R1 produces facts labelled Msg(t1 t2) Since ri3 is nowapplied from Sj to Sj+1 we have that an instance ri1 of a ruleof form R1 that produces statesemi

p (t) must appear before j i eri1 isin ginsts(JPK=p) Therefore it produces a fact Msg(t1 t2) in-deed We choose the largest k that has an unmarked R1 whichproduces Msg(t1 t2) and statesemi

p (t) and move it right before jresulting in the following MSR execution

S(1) prime

S(1)t if t lt k

S(1)t+1 cup

Msg(t1 t2) statesemip (t)

statep(t)

if k 6 t lt jminus 1

(t)if jminus 1 6 t lt j+ 1

(tminus1)cup statepmiddot1(t)

statesemip (t)Ack(t1 t2)

if j+ 1 6 t lt i+ 1

S(1)t if i+ 1 6 t

We apply this procedure until it reaches a fixpoint and call theresulting trace

E(3)1minusrarrJPK

E(3)nminusrarrJPK S

No rule that has an action moved during the procedure hencewe can conclude hide([E1 En]) = hide([E

(3)1 E

n(3) ]) as

well as [E(3)1 E

n(3) ] α

4 If the last transition is in the set MDOutMDPubMDFresh

MDApplFresh we remove it Repeat until fixpoint is reachedand call the resulting trace

E(4)1minusrarrJPK

E(4)nminusrarrJPK S

Since this procedure removes no rule that is annotated with anaction hide([E1 En]) = hide([E

(4)1 E

n(4) ]) and [E(4)1

n(4) ] α

5 If there is In(t) isin S(4)

n(4)minus1 then there is a transition where In(t)

is produced and never consumned until n(4) minus 1 The only ruleproducing In(t) is MDIn We can move this transition to justbefore n(4) minus 1 and call the resulting trace

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

Since [E(4)1 E

n(4) ] α especially αinEv there are only ac-tion in Fres between the abovementioned instance of MDIn andn(4) Therefore hide([E1 En]) = hide([E

(5)1 E

n(5) ]) holdsSince αinEv is the only part of α that mentions K and sincethe tranformation preserved αinEv we have that [E(5)1 E

n(5) ]

6 We will show that 6 and 7 hold for

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

in one step

If n(5) gt 2 and there is no Ack-fact in S(5)n(5)minus1 S

n(5) then we

chose the largest m lt n such that S(5)mminus1

E(5)mminusminusrarrJP[][]KInitMDInS

or if there is an Ack-fact in S(5)

n(5)minus1 S(5)

n(5) we will chose the

largest m prime lt nminus 2 such that S(5)m primeminus1

m primeminusminusrarrJP[][]KInitMDInS

(5)m prime

This trivially fulfills 4 S(5)m rarrlowastR S

n(5) and S(5)m prime rarrlowastR S

n(5)minus3 sinceotherwise there would be a larger m or m prime This also implies2 as none of the rules in R = MDOutMDPubMDFresh

MDApplFresh remove Ack- or statesemi-facts and the chainof rules R1 R2 R3 consumes as many as it produces Thus ifthey where in S(5)m they would be in S(5)

n(5) too Since n gt 2m gt 1 and therefore 1 3 holds for all parts of the trace andtherefore also for the m prefix Similar for 5

Since we can literally apply the same argument for the largest

m lt m such that S(5)mminus1

(5)m or in case that

there is an Ack-fact in S(5)mminus1 S(5)m for the largest m lt mminus2 can

show that 6 and 7 hold for the trace up to m or m prime concludingit is normal

Remark 4 Note that P has the following properties (by the fact thatit defines a bijection between multisets)

bull If P1 P S1 and P2 P S2 then P1 cup P2 P S1 cup

bull If P1 P S1 and Q P statep(t) for Q isin P1 and statep(t) isin

S1 (ie Q and statep(t) are related by the bijection defined byP1 P S1) then P1

Q P S1 statep(t)

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

Base Case A normal MSR execution contains at least an application ofthe init rule thereby the shortest normal MSR execution is

emptyminusrarrJPKS1 = state[]()

We chose n prime = 0 and thus

(E0 S0 SMS0 P0 σ0L0) = (empty empty empty P empty empty)

We define f 1 rarr 0 such that f(1) = 0To show that Condition 4 holds we have to show that P0 P

state[](s fresh) Note that P0 = P We choose the bijection suchthat PP state[](s fresh)

By Definition 18 JPK=[] = JP [] []K=[] We see from Figure 14

that for every P we have that state[](s fresh) isin prems(Rθ) for R isin

JP [] []K=[] and θ = empty This induces τ = empty and ρ = empty Since P|[]τρ = Pwe have PP state[]() and therefore P0 P S1

Condition 1 Condition 2 Condition 3 Condition 5 Condition 6and Condition 7 hold trivially

Inductive step Assume the invariant holds for nminus 1 gt 1 We have toshow that the lemma holds for n transitions i e we assume that

emptyE1minusrarrJPK S1

is normal and [E1 En] α Then it is to show that there is

F2minusrarr

F primenminusrarr (En prime Sn prime SMS

fulfilling Conditions 1 to 8Assume now for the following argument that there is not fact with

the symbol Ack in Snminus1 Sn This is the case for all cases except for

the case where rule instance applied from Snminus1 to Sn has the formri = [statesemi

p (s)Ack(t1 t2)] minus[]rarr [statepmiddot1(s)] This case will requirea similiar but different argument which we will present when wecome to this case

Since emptyE1minusrarrJPK middot middot middot

EnminusminusrarrJPKSn isin execmsr(JPK) is normal and n gt 2 thereexists an m lt n such that Sm rarrlowast

R Sn for R = MDOutMDPub

MDFreshMDApplFresh and emptyE1minusrarrJPK middot middot middot

EmminusminusrarrJPKSm isin execmsr(JPK)

is normal too This allows us to apply the induction hypothesis on

EmminusminusrarrJPKSm isin execmsr(JPK) Hence there is a monotonicallyincreasing function from Nm rarr Nn prime and an execution such thatConditions 1 to 8 hold Let fp be this function and note that n prime =

fp(m)In the following case distinction we will (unless stated otherwise)

extend the previous execution by one step from (En prime Sn prime SMSn prime Pn prime

σn prime Ln prime) to (En prime+1 Sn prime+1 SMSn prime+1Pn prime+1 σn prime+1Ln prime+1) showing Con-

ditions 1 to 7 for n prime + 1 By induction hypothesis they hold for alli 6 n prime We define a function f Nn rarrNn prime+1 as follows

f(i) =

fp(i) if i isinNm

n prime if m lt i lt n

n prime + 1 if i = n

Since Sm rarrlowastR Sn for R = MDOutMDPubMDFreshMDAppl

Fresh only Sn Sm contains only Fr-facts and K-facts and Sm

Sn contains only Fr-facts and Out-facts Therefore Condition 34 and5 hold for all i 6 nminus 1 Since Em+1 Enminus1 = empty Condition 1 26and 7 hold for all i 6 nminus 1

Fix a bijection such that Pn prime P Sm We will abuse notation bywriting PP statep(t) if this bijection maps P to statep(t)

We now proceed by case distinction over the last type of transitionfrom Snminus1 to Sn Let llinear =E Snminus1 Sn and r =E Sn Snminus1 llinear

can only contain linear facts while r can contain linear as well aspersistent facts The rule instance ri used to go from Snminus1 to Sn hasthe following form

[llinear lpersistent] minus[En]rarr r

for some lpersistent subE Snminus1

Note that llinear En and r uniquely identify which rule in JP [] []K ri

is an instance of ndash with exactly one exception J[] minus[a]rarr [] P p xK =

Jevent a P p xK Luckily we can treat the last as a special case of thefirst

If R is uniquely determined we fix some ri isin ginsts(R)

Case R = Init or R isin MD MDIn In this case emptyE1minusrarr

EnminusminusrarrSn isnot a well-formed MSR execution

Case R = MDIn Let t isinM such that ri = Rτ = K(t) minus[K(t)]rarr In(t)From the induction hypothesis and since Em+1 En = empty we

have that

En prime = a isin FN | ProtoNonce(a) isinE⋃

From the induction hypothesis and since no rule producing Out-facts is applied between step m and step n we have that

xσn prime | x isin D(σn prime) =E Out(t) isin cupk6nSk

Let r = a isin FN | RepNonce(a) isinE⋃

16j6n Fj Then by Lemma 2

and Lemma 15 we have that νEn prime rσn prime ⊢ t Therefore νEn prime σn prime ⊢ tThis allows us to chose the following transition

middot middot middotFn primeminusminusrarr(En prime Sn prime SMS

K(t)minusminusminusrarr(En prime+1 Sn prime+1 S

MSn prime+1Pn prime+1 σn prime+1Ln prime+1)

with (En prime+1 Sn prime+1 SMSn prime+1Pn prime+1 σn prime+1Ln prime+1) equal to (En prime Sn prime

SMSn prime Pn prime σn prime Ln prime)Conditions 1 to 8 hold trivially

Case ri = [statep(t)] minus[]rarr [] (for some p and t) By induction hy-pothesis we have Pn prime P Sm and thus as previously establishedPn prime P Snminus1 Let Q isin Pn prime such that Q P statep(t) Let θ be agrounding substitution for statep(x) isin prems(JPK=p) such that t = xθThen θ induces a substitution τ and a bijective renaming ρ for freshbut not bound names (in Q) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = 0

We therefore chose the following transition

middot middot middotF primenminusrarr(En prime Sn prime SMS

with En prime+1 = En prime Sn prime+1 = Sn prime SMSn prime+1 = SMS

n prime Pn prime+1 = Pn prime 0 σn prime+1 = σn prime and Ln prime+1 = Ln prime

We define f as in equation 5 on page 226 Therefore Conditions 1

to 8 hold for i lt nminus 1 It is left to show that Conditions 1 to 8 holdfor n

Condition 4 holds since Q harr statep(t) Pn prime+1 = Pn prime 0 andSn = Snminus1

statep(t) Conditions 1 2 3 5 and 7 hold trivially

Case ri = [statep(t)] minus[]rarr [statepmiddot1(t) statepmiddot2(t)] (for some p and

t) By induction hypothesis we have Pn prime P Sm and thus aspreviously established Pn prime P Snminus1 Let Q isin Pn prime such thatQ P statep(t) Let θ be a grounding substitution for statep(x) isin

prems(JPK=p) such that t = xθ Then θ induces a substitution τ and abijective renaming ρ for fresh but not bound names (in Q) such thatP|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = Q1|Q2 for some processes Q1 = P|pmiddot1τρ and Q2 = P|pmiddot2τρ

minusrarr(En prime+1 Sn prime+1 SMSn prime+1Pn prime+1 σn prime+1Ln prime+1)

n prime Pn prime+1 = Pn prime Q1 |

Q2 cup Q1 Q2

σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q1 harr statepmiddot1(t) andQ2 harr statepmiddot2(t) Therefore and since Qharr statep(t) Pn prime+1 = Pn prime

Q1 | Q2 cup Q1 Q2

and Sn = Snminus1 statept

cup statepmiddot1(t)

statepmiddot2(t) Condition 4 holds

Conditions 1 2 3 5 and 7 hold trivially

Case ri = [statep(t)] minus[]rarr [statepmiddot1(t)] (for some p t) By inductionhypothesis we have Pn prime P Sm and thus as previously establishedPn prime P Snminus1 Let Q isin Pn prime such that Q P statep(t) Let θ be agrounding substitution for statep(x) isin prems(JPK=p) such that t = xθThen θ induces a substitution τ and a bijective renaming ρ for freshbut not bound names (in Q) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = Q primefor a process Q prime = P|pmiddot1τρ

n prime Pn prime+1 = Pn prime cup Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime

By definition of JPK and JPK=p we have that Q prime P statepmiddot1(t)Therefore and since Pn prime+1 = Pn prime cup Q prime while Sn = Snminus1 cup

Case ri = [statep(t)Fr(a prime fresh)] minus[ProtoNonce(a prime fresh)]rarr [statepmiddot1(

t a prime fresh)] (for some p t and a prime isin FN) By induction hypothesiswe have Pn prime P Sm and thus as previously established Pn prime P

Snminus1 Let Q isin Pn prime such that QP statep(t) Let θ be a groundingsubstitution for statep(x) isin prems(JPK=p) such that t = xθ Then θinduces a substitution τ and a bijective renaming ρ for fresh but notbound names (in Q) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = νa Q prime for a name a isin FN and a process Q prime = P|pmiddot1τρ

By definition of execmsr the fact Fr(a prime) can only be produced onceSince this fact is linear it can only be consumed once Every rule inJPK that produces a label ProtoNonce(x) for some x consumes a factFr(x) Therefore

a prime isin a isin FN | ProtoNonce(a) isinE⋃

16j6nminus1

The induction hypothesis allows us to conclude that a prime isin En prime i e a prime

is fresh We therefore chose the following transition

with En prime+1 = En prime cup a prime Sn prime+1 = Sn prime SMSn prime+1 = SMS

n prime Pn prime+1 = Pn prime

ν aQ prime cup Q prime aa prime σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK statepmiddot1(x a) isin prems(R prime) for an R prime isin JPK=pmiddot1We can choose θ prime = θ[na 7rarr a prime] Let statepmiddot1(t a

prime) = statepmiddot1(x a)θprime

Since Q = P|pτρ for τ and ρ induced by θ Q prime aprimea = P|pτ

primeρ prime forτ prime and ρ prime induced by θ prime i e τ prime = τ and ρ prime = ρ[a 7rarr a prime] ThereforeQ prime a

primea P statepmiddot1(t a

prime)

Condition 4 holds since furthermore

ν a prime Qrsquoharr statep(t)

Pn prime+1 = Pn prime ν a prime Qrsquo cup Q prime aprimea

Sn = Snminus1 Fr(a) statep(t)

cup statepmiddot1(t a fresh)

Condition 1 holds since En prime+1 = En prime cupa prime and En = ProtoNonce(a prime)Condition 7 holds since ProtoNonce(a) isin Fres

Conditions 2 3 and 5 hold trivially

Case ri = [statep(t) In(t1)] minus[ InEvent(t1)]rarr [statepmiddot1(t)Out(t2)] (for

some p t and t1 t2 isinM) Since the MSR execution is normal we have

that Snminus2K(t1)minusminusminusrarrMDInSnminus1 Since S0

E1minusrarrJPK EnminusminusrarrJPKSn is normal so

is S0E1minusrarrJPK

Enminus1minusminusminusrarrJPKSnminus1 and therefore S0

E1minusrarrJPK Enminus2minusminusminusrarrJPKSnminus2

Hence there is an m lt n minus 2 such S0E1minusrarrJPK

EmminusminusrarrJPKSm is a nor-mal trace and Sm rarr

lowastR Snminus1 for R = MDOutMDPubMDFresh

MDApplFresh By induction hypothesis we have Pn prime P Sm and thus since the

rules in MDOutMDPubMDFreshMDApplFresh neither addnor remove state-facts Pn prime P Snminus2 Let Q isin Pn prime such thatQ P statep(t) and θ be a grounding substitution for state(x) isin

From the form of the rule R and since Q = P|pτρ we can deducethat Q = out (t1 t2)Q prime for a process Q prime = P|pmiddot1τρ

From the induction hypothesis and since Em+1 Enminus2 = empty wehave that

16j6nminus2

From the induction hypothesis and since no rule producing Out-facts is applied between step m and step nminus 2 we have that

xσn prime | x isin D(σn prime) =E Out(t) isin cupk6nminus2Sk (6)

Let r = a fresh | RepNonce(a) isin⋃

16j6nminus2 Fj Since K(t1) isinprems(MDInσ) for σ(x) = t1 we have K(t) isinE Snminus2 By Lemma 2

and Lemma 15 we have νEn prime rσn prime ⊢ t Therefore νEn prime σn prime ⊢ t Wechose the following transition

K(t1)minusminusminusrarr(En prime+1 Sn prime+1 S

out (t1 t2)Q prime cup Q prime σn prime+1 = σn prime cup t2x and Ln prime+1 = Ln prime

for a fresh xWe define f as follows

f(i) =

fp(i) if i isinNm

n prime if m lt i lt nminus 1

Therefore Conditions 1 to 8 hold for i lt nminus 1 It is left to showthat Conditions 1 to 8 hold for n

Condition 7 holds since Enminus1 = K(t1) which implies hide([E1

Em]) =E [F1 nprime] and [Em+1 Enminus1] =E [Fn prime+1]

Condition 5 holds since σn prime+1 = σn prime cup t2x and therefore

xσn prime+1 | x isin D(σn prime+1) = xσn prime | x isin D(σn prime) cup t2

=EOut(t) isin cupk6nminus2Sk cup t2

(by (6))

=Out(t) isin cupk6nSk

By definition of JPK and JPK=p we have that Q prime P statepmiddot1(t)Therefore and since out (t1 t2)Q prime P statep(t) Pn prime+1 = Pn prime

out (t1 t2)Q prime cup Q prime and Sn =E Snminus1 In(a) statep(t) cup

statepmiddot1(t)Out(t2) Condition 4 holdsConditions Condition 1 2 and 3 hold trivially

Case ri = [statep(t) In(lt t1 t2 gt)] minus[ InEvent(〈t1 t2〉)]rarr [statepmiddot1(t

t prime)] (for some p t t prime and t1 t2 isin M) Since the MSR execution is nor-

mal we have that Snminus2K(t1)minusminusminusrarrMDInSnminus1 Since S0

E1minusrarrJPK EnminusminusrarrJPKSn

is normal so is S0E1minusrarrJPK

E1minusrarrJPK Enminus2minusminusminusrarrJPKSnminus2 Hence there is an m lt n minus 2 such that S0

E1minusrarrJPK EmminusminusrarrJPKSm is a normal trace and Sm rarrlowast

R Snminus1 for R = MDOut

MDPubMDFreshMDApplFresh By induction hypothesis we have Pn prime P Sm Since MDOut

MDPubMDFreshMDAppl Fresh and MDIn do not add or re-move state-facts Pn prime P Snminus2

Let Q isin Pn prime such that Q P statep(t) Let θ be a groundingsubstitution for statep(x) isin prems(JPK=p) such that t =E xθ Then θinduces a substitution τ and a bijective renaming ρ for fresh but notbound names (in Q) such that P|pτρ = Q (see Definition 20) Fromthe form of the rule R and since Q = P|pτρ we can deduce thatQ = in (t1 N)Q prime for N a term that is not necessarily ground anda process Q prime = P|pmiddot1τρ Since ri isinE ginsts(R) we have that there is asubstitution τ prime such that Nτ prime =E t2

En prime = a | ProtoNonce(a) isin⋃

16j6nminus2

xσn prime | x isin D(σn prime) = Out(t) isin cupk6nminus2Sk (7)

16j6nminus2 Fj Since K(〈t1 t2〉) isinprems(MDInσ) for σ(x) = 〈t1 t2〉 we have K(〈t1 t2〉)E isin Snminus2 ByLemma 2 and Lemma 15 we have νEn prime rσn prime ⊢ 〈t1 t2〉 ThereforeνEn prime σn prime ⊢ 〈t1 t2〉 Using DEq and DAppl with the function symbolsfst and snd we have νEn prime σn prime ⊢ t1 and νEn prime σn prime ⊢ t2 Therefore wechose the following transition

in (t1 N)Q prime cup Q primeτ prime σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as follows

f(i) =

fp(i) if i isinNm

Condition 7 holds since hide([E1 Em]) = [F1 nprime] and [Em+1

Enminus1] = [Fn prime+1] since Enminus1 = K(t1)Let θ prime such that ri = θ primeR As established before we have τ prime such

that Nτ prime =E t2 By definition of JPK=p we have that statepmiddot1(t tprime) isinE

ginsts(P=pmiddot1) and that θ prime = θ middot τ prime Since τ and ρ are induced by θθ prime induces τ middot τ prime and the same ρ We have that Q primeτ prime = (P|pmiddot1τρ)τ

prime =

P|pττprimeρ and therefore Q primeτ P statepmiddot1(t t

prime) Thus and since in(t1

N) Qrsquo P statep(t) Pn prime+1 = Pn prime in (t1 N)Q prime cup Q primeτ prime andSn = Snminus1 In(lt t1 t2 gt) statep(t)

cup statepmiddot1(t tprime) Condi-

tion 4 holdsConditions Condition 1 2 3 and 5 hold trivially

Case ri = [statesemip (s)Ack(t1 t2)] minus[]rarr [statepmiddot1(s)] (for some p t

and t1 t2 isin M) Since the MSR execution is normal we have thatthere pqx y y prime such that

Snminus3minusrarrR1Snminus2minusrarrR2

Snminus1minusrarrR3Sn where

Since in this case there is a fact with symbol Ack removed from

Snminus1 to Sn we have to apply a different argument to apply the in-duction hypothesis

EnminusminusrarrJPKSn isin execmsr(JPK) is normal n gt 2 andt1 t2 isin M Ack(t1 t2) isin (Snminus1 Sn) there exists m 6 nminus 3 suchthat Sm rarrlowast

R Snminus3 for R = MDOutMDPubMDFreshMDAppl cup

Fresh and emptyE1minusrarrJPK middot middot middot

EmminusminusrarrJPKSm isin execmsr(JPK) is normal This al-

lows us to apply the induction hypothesis on emptyE1minusrarrJPK middot middot middot

EmminusminusrarrJPKSm isin

execmsr(JPK) Hence there is a monotonically increasing function fromNm rarr Nn prime and an execution such that Conditions 1 to 8 hold Letfp be this function and note that n prime = fp(m)

In the following case distinction we extend the previous executionby one step from (En prime Sn prime SMS

n prime Pn prime σn prime Ln prime) to (En prime+1 Sn prime+1 SMSn prime+1

Pn prime+1 σn prime+1Ln prime+1) and prove that Conditions 1 to 7 hold for n prime +

1 By induction hypothesis they hold for all i 6 n prime We define afunction f Nn rarrNn prime+1 as follows

f(i) =

fp(i) if i isinNm

n prime if m lt i 6 nminus 3

Sn contains only Fr-facts and Out-facts Therefore Condition 3 4 and5 hold for all i 6 nminus 3 Since Em+1 Enminus1 = empty Condition 1 2 6

and 7 hold for all i 6 nminus 3Fix a bijection such that Pn prime P Sm We will abuse notation by

writing P P statep(t) if this bijection maps P to statep(t) SinceMDOutMDPubMDFreshMDAppl and Fresh do not add or re-move state-facts Pn prime P Snminus3 Let P isin Pn prime such that P P

statep(s) Let Q isin Pn prime such that QP stateq(t)Let θ prime be a grounding substitution for stateq(y) isin prems(JPK=q)

such that t =E yθprime Then θ prime induces a substitution τ prime and a bijective

renaming ρ prime for fresh but not bound names (inQ) such that P|qτ primeρ prime =Q (see Definition 20)

From the form of the rules R1 and R3 and since P =E P|pτρ forτ and ρ induced by the grounding substitution for statep(x) we candeduce that P =E out t1 t2 P

prime for a process P prime = P|pmiddot1τρ Similarlyfrom the form of R2 we can deduce Q =E in (t1 N)Q prime for N a

term that is not necessarily ground and a process Q prime = P|qmiddot1τprimeρ prime

Since Snminus2minusrarrR2Snminus1 we have that there is a substitution τlowast such that

Nτ primeρ primeτlowast =E t2 and ((y cup vars(N)) y)τlowast =E t prime where t prime such thatstateqmiddot1(t t

prime) isin Snminus1 Snminus2

Given that Q =E in (t1 N)Q prime and P =E out t1 t2 Pprime have that

Pn prime = P prime cup out t1 t2P prime in (t prime1 N)Q prime with t1 =E tprime1 and t2 =E

Nτlowast Therefore we chose the following transition

n prime Pn prime+1 = P prime cup P prime Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime

Conditions 1 to 8 hold for i 6 nminus 3 It is left to show that Condi-tions 1 to 8 hold for n

As established before we have τlowast such that Nτ primeρ primeτlowast =E t2 Letstateq(t t

prime) be the state variable added to Snminus1 Then ((ycupvars(N))

y)τlowast = t prime By definition of JPK=q we have that stateqmiddot1(t tprime) isin

prems(ginsts(P=pmiddot1)) for a grounding substitution θqmiddot1 = θ prime middot τlowast Sinceτ prime and ρ prime are induced by θ prime θqmiddot1 induces τ middot τ prime and the same ρ Wehave that Q primeτ prime = (P|qmiddot1τ

primeρ prime)τlowast = P|qmiddot1ττprimeρ and therefore Q primeτlowast P

stateqmiddot1(t tprime) Similarly we have P prime P stateqmiddot1(s) We conclude

that Condition 4 holdsConditions Condition 1 2 3 5 6 and 7 hold trivially

Case ri = [statep(t)] minus[ Eq(t1 t2)]rarr [statepmiddot1(t)] (for some p t and

t1 t2 isinM) By induction hypothesis we have Pn prime P Sm and thusas previously established Pn prime P Snminus1 Let Q isin Pn prime such thatQ P statep(t) Let θ be a grounding substitution for statep(x) isin

From the form of the rule R and since Q = P|pτρ we can deducethat Q = if t1 = t2 then Q1 else Q2 for a process Q prime = P|pmiddot1τρ

Since [E1 En α and thus [E1 Em αeq we have thatt1 =E t2 We therefore chose the following transition

n prime Pn prime+1 = Pn prime if t1 =

t2then Q1 else Q2 cup Q1

By definition of JPK and JPK=p we have that Q1 harr statepmiddot1(t)Therefore and since if t1 = t2 thenQ1 elseQ2 harr statep(t) Pn prime+1 =

Pn prime if t1 = t2 then Q1 else Q2 cup Q1

and Sn = Snminus1

Condition 4 holds Conditions 1 2 3 56 and 7 hold trivially

Case ri = [statep(t)] minus[ NotEq(t1 t2)]rarr [statepmiddot1(t)] (for some p t

and t1 t2 isin M) In this case the proof is almost the same as in theprevious case except that αnoteq is the relevant axiom Q2 is choseninstead of Q1 and Sn = Snminus1

Case ri = [statep(t)] minus[ FEvent()]rarr [statepmiddot1(t)] (for some p t)

This is a special case of the case where ri = [statep(t) l] minus[ a]rarr

[statepmiddot1(t) r] for l = r = empty and a = F

Case ri = [statep(t)] minus[Insert(t1 t2)]rarr [statepmiddot1(t)] (for some p t and

From the form of the rule R and since Q = P|pτρ we can deducethat Q = insert t1 t2Q prime for a process Q prime = P|pmiddot1τρ

with En prime+1 = En prime Sn prime+1 = Sn prime [t1 7rarr t2] SMSn prime+1 = SMS

n prime Pn prime+1 =

Pn prime insert t1 t2Q prime cup Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q prime harr statepmiddot1(t)Therefore and since insert t1 t2Q prime harr statep(t) Pn prime+1 = Pn prime

insert t1 t2Q prime cup Q prime as well as Sn = Snminus1 statep(t)

statepmiddot1(t) we have that Condition 4 holds

Condition 2 holds since En = Insert(t1 t2) is the last element ofthe trace

Case ri = [statep(t)] minus[Delete(t1 t2)]rarr [statepmiddot1(t)] (for some p t and

From the form of the rule R and since Q = P|pτρ we can deducethat Q = delete t1Q prime for a process Q prime = P|pmiddot1τρ

Pn prime delete t1Q prime cup Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q prime harr statepmiddot1(t)Therefore and since delete t1Q prime harr statep(t) Pn prime+1 = Pn prime delete

t1Q prime cup Q prime as well as Sn=Snminus1 statep(t)

we have that Condition 4 holdsCondition 2 holds since En = Delete(t1 t2) is the last element of

the traceConditions 1 3 5 6 and 7 hold trivially

Case ri = [statep(t)] minus[ IsIn(t1 t2)]rarr [statepmiddot1(t t2)] (for some p t

and t1 t2 isin M) By induction hypothesis we have Pn prime P Smand thus as previously established Pn prime P Snminus1 Let Q isin Pn prime

such that Q P statep(t) Let θ be a grounding substitution forstatep(x) isin prems(JPK=p) such that t = xθ Then θ induces a substitu-tion τ and a bijective renaming ρ for fresh but not bound names (inQ) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = lookup t1 as v in Q1 else Q2 for some variable V and twoprocesses Q1 = P|pmiddot1τρ and Q2 = P|pmiddot2τρ

Since [E1 En] αin there is an i lt n such that Insert(t1 t2) isinEEi and there is no j such that i lt j lt n and Delete(t1) isinE Ej or andInsert(t1 t2) isinE TEj Since Em En = empty we know that i lt mHence by induction hypothesis Sn prime(t1) = t2 We therefore chose thefollowing transition

lookup t1 as v in Q1 else Q2 cup Q1

t2v σn prime+1 = σn prime and

Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have thatQ1vt2 harr statepmiddot1(t

t2) (for τ prime = τ[v 7rarr t2] and ρ prime = ρ) Therefore and since lookup

t1 as v in Q1 else Q2 harr statep(t) Pn prime+1 = Pn prime lookup t1 as v

in Q1 else Q2 cup Q prime as well as Sn = sectnminus1 statep(t)

statepmiddot1(t t2) Condition 4 holds

Conditions 1 2 3 5 6 and 7 hold trivially

Case ri = [statep(t)] minus[ IsNotSet(t1)]rarr [statepmiddot2(t)] (for some p t and

t1 isin M) By induction hypothesis we have Pn prime P Sm and thusas previously established Pn prime P Snminus1 Let Q isin Pn prime such thatQ P statep(t) Let θ be a grounding substitution for statep(x) isin

From the form of the rule R and since Q = P|pτρ we can deducethat Q = lookup t1 as v in Q1 else Q2 for a variable v and twoprocesses Q1 = P|pmiddot1τρ and Q2 = P|pmiddot2τρ

Since [E1 En] αnotin there is no i lt n with Insert(t1 t2) isinE Eiand there is no j such that i lt j lt n and Delete(t1) isinE Ej or andInsert(t1 t2) isinE TEj Since Em En = empty we know that holdsj lt m Hence by induction hypothesis Sn prime(t1) is undefined Wetherefore chose the following transition

σn prime+1 = σn prime and Ln prime+1 =

Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q2 harr statepmiddot2(t)Therefore and since lookup t1 as v in Q1 else Q2 harr statep(t)Pn prime+1 = Pn prime lookup t1 as v in Q1 else Q2

cup Q2 and

Sn = sectnminus1 statep(t)

cup statepmiddot2(t) Condition 4 holds

Case ri = [statep(t)Fr(lockl)] minus[Lock(lockl t)]rarr [statepmiddot1(t lockl)] (for

some p t lockl isin FN and t isin M) By induction hypothesis we havePn prime P Sm and thus as previously established Pn prime P Snminus1 LetQ isin Pn prime such that Q P statep(t) Let θ be a grounding substitu-tion for statep(x) isin prems(JPK=p) such that t = xθ Then θ inducesa substitution τ and a bijective renaming ρ for fresh but not boundnames (in Q) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = lockl t Q prime for Q prime = P|pmiddot1τρ

Since [E1 En] αlock for every i lt n such that Lock(lp t) isinE Eithere a j such that i lt j lt n and Unlock(lp t) isinE Ej and in betweeni and j there is no lock or unlock i e for all k such that i lt k lt jand all li Lock(li t) isinE Ek and Unlock(li t) isinE Ek

Since Em En = empty we know that this holds for i lt m andj lt m as well By induction hypothesis Condition 6 this implies thatt 6isinE Ln prime We therefore chose the following transition

lockl t Q prime cup Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime cup t We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q prime harr statepmiddot1(t)Therefore and since lockl t Q prime harr statep(t) Pn prime+1 = Pn prime lockl tQ prime cup Q prime and Sn = sectnminus1

statep(t)Fr(lockl) cup statepmiddot1(t

lockl) Condition 4 holds

Condition 6 holds since En = Lock(lockl t) is added to the end

of the traceConditions 1 2 3 5 and 7 hold trivially

Case ri = [statep(t)] minus[ Unlock(nl t)]rarr [statepmiddot1(t)] (for some p t

nl isin FN and t isin M) By induction hypothesis we have Pn prime P

Sm and thus as previously established Pn prime P Snminus1 Let Q isin

Pn prime such that Q P statep(t) Let θ be a grounding substitutionfor statep(x) isin prems(JPK=p) such that t = xθ Then θ induces asubstitution τ and a bijective renaming ρ for fresh but not boundnames (in Q) such that P|pτρ = Q (see Definition 20)

From the form of the rule R and since Q = P|pτρ we can deducethat Q = unlockl t Q prime for Q prime = P|pmiddot1τρ

unlockl t Q prime cup Q prime σn prime+1 = σn prime and Ln prime+1 = Ln prime t We define f as in equation 5 on page 226 Therefore Conditions 1

By definition of JPK and JPK=p we have that Q prime harr statepmiddot1(t)Therefore and since unlockl t Q prime harr statep(t) Pn prime+1 = Pn prime

unlockl t Q prime cup Q prime as well as Sn = Snminus1 statep(t) cup

We show that Condition 6 holds for Ln prime+1 = Ln prime t For all t prime 6=E

t t prime isinE Ln prime hArr t prime isinE Ln prime+1 by induction hypothesis If t 6isinE Ln prime then forallj 6 muLock(u t) isinE Ej rarr existj lt k 6 nUnlock(u t) isinE Ek

Since we have Em Enminus1 = empty and En = Unlock(nl t) we

can strengthen this to forallj 6 nuLock(u t) isinE Ej rarr existj lt k 6

nUnlock(u t) isinE Ek which means that the condition holds in thiscase If t isinE Ln prime then existj 6 nuLock(u t) isinE Ej and forallj lt k 6

nUnlock(u t) 6isinE Ek and since En = Unlock(nl t) and Em

Enminus1 = empty a contradiction to Condition 6 would constitute of j andu 6=E nl such that Lock(u t) isinE Ej and forallj lt k 6 n Unlock(u t) 6isinEEk

We will show that this leads to a contradiction with [E1 En] αFix j and u By definition of JPK and well-formedness of P there isa pl that is a prefix of p such that P|ql

= lockltQ primeprime for the sameannotation l and parameter t The form of the translation guaran-tees that if statep(t) isin Sn then for some t prime there is i 6 n such thatstatep prime(t prime) isin Si if p prime is a prefix of p We therefore have that there isi lt n such that Ei =E Lock(nl t)

We proceed by case distinctionCase 1 j lt i (see Figure 21) Since forallj lt k 6 nUnlock(u t) 6isinE Ek[E1 En] 6 αlock

Lock(u t)

Lock(nl t)

Unlock(nl t)

Case 2 i lt j (see Figure 22) By definition of P there is no paral-lel and no replication between pl and p Note that any rule in JPK

that produces a state named stateq for a non-empty q is such thatit requires a fact with name stateq prime for q = q prime middot 1 or q = q prime middot 2 (incase of the translation of out it might require statesemi

q prime which in turnrequires stateq prime) Therefore there cannot be a second k 6= n suchthat Unlock(nl t) isinE Ek (since nl was added in a Fr-fact in to Si)This means in particular that there is not k such that i lt k lt n andUnlock(nl t) isinE Ek Therefore [E1 En] 6 αlock

Lock(nl t)

Lock(u t)

Unlock(nl t)

Case ri = [statep(t) lprime] minus[ a primeEvent()]rarr [statepmiddot1(t t

prime) r prime] (for some

p t t prime and l prime r prime a prime isin Glowast) By induction hypothesis we have Pn prime P

From the form of the rule R and since Q = P|pτρ we can deducethat Q = l minus[a]rarr rQ prime for a process Q prime = P|pmiddot1τρ

Since ri isinE ginsts(R) we have that there is a substitution τlowast suchthat (l minus[ a]rarr r)τlowast = l prime minus[ a]rarr prime r prime lfacts(l prime) sub Snminus1 pfacts(l prime) subE

Snminus1 and from the definition of JPK=p vars(l)τlowast = t prime Since P is well-formed no fact in Fres appears in neither l nor r so from Condition 3

in the induction hypothesis we have that lfacts(l prime) sub SMSm = SMS

n prime andpfacts(l prime) sub SMS

m = SMSn prime We therefore chose the following transition

a prime

n prime lfacts(l prime)cup r prime Pn prime+1 =

Pn prime l minus[a]rarr rQ prime cup Q primeτlowast σn prime+1 = σn prime and Ln prime+1 = Ln prime We define f as in equation 5 on page 226 Therefore Conditions 1

Condition 7 holds since Em+1 Enminus1 = empty and since hide([E1

Em]) = [F1 nprime] while En = F primen Event() = a prime (note that Event() isin

Fres)As established before we have τlowast such that (l minus[a]rarr r)τlowast =E l minus[

a]rarr r By the definition of JPK=p we have that statepmiddot1(t tprime) isinE

ginsts(P=pmiddot1) and a θ prime = θ middot τlowast that is grounding for statepmiddot1(t tprime)

Since τ and ρ are induced by θ θ prime induces τ middot τlowast and the same ρWe have that Q primeτlowast = (P|pmiddot1τρ)τ

lowast = P|pττlowastρ and therefore Q primeτ P

statepmiddot1(t tprime) Thus and since l minus[a]rarr rQ prime P statep(t) Pn prime+1 =

Pn prime l minus[a]rarr rQ prime cup Q primeτlowast and Sn = Snminus1 lfacts(l prime) cup r prime

statep(t) cup statepmiddot1(t t

prime) Condition 4 holdsCondition 3 holds since

Sn Fres = (Snminus1 lfacts(l prime)cup r prime

prime) ) Fres

= (Snminus1 lfacts(l prime)cup r prime) Fres

= Snminus1 Fres

lfacts(l prime)cup r prime

= SMSn prime

= SMSn prime+1

CI N I T I A L I S AT I O N A N D S E T U P I N FK M

c1 initialisation phase

All regular protocol machines that shall accept messages from FK M

need to send a message to FK M first [51 sect 45] A similar behaviourneeds to be emulated by F s e t u p in the network with the actual tokensThe involved protocol machines are M = U cup S T cup F 1 F l where F i denotes the regular protocol machine that makes subrou-tine calls to F i identified with the machine ID laquoregF igts i d gt

We add the following part to the definition of FK M

Listing 29 Initilisation (FKM)

ready-P accept ltreadygt from P isinM

send ltreadybullPgt to A

ready [ready-P forallP isinM ]

We add the following part to the definition of ST

Listing 30 Initilisation (STi)

ready [not ready]

2 accept ltreadygt from parentId

c2 handling of the setup phase in FKM and STi

The following listings describe the setup phase introduced on p 120

Listing 31 The setup phase sharing keys (FKM)

share[notfinish_setupandready] accept ltshareh1U2gt from U1 isin U

2 if Ui U2 isin Roomcreate h2 Store[U2h2]=Store[U1h1] send lt

sharebullh2gt to U2

Listing 32 The setup phase sharing keys (STi)

share[notfinish_setupandready] accept ltshareh1U2gt from Fsetup

2 if Store[Uh1]=s call Fsetup with ltsendsU2gt

import[notfinish_setupandready]accept ltdeliversU1gt from Fsetupif U1 isin Room create h2 Store[Uih2]=s send ltsharebullh2gt

to Fsetup

242 initialisation and setup in km

Listing 33 The setup phase terminating the setup phase (FKM)

1 finish_setup[notfinish_setupandready] accept ltfinish_setupgt from

U isin U

send ltfinish_setupbullgt to A

Listing 34 The setup phase terminating the setup phase (STi)

finish_setup[notfinish_setupandready] accept ltclosegt from Fsetup

send ltclosebullgt to Fsetup

c3 setup assumptions for the implementation

The setup assumption used for ST is subsumed in the setup function-ality Fsetup which is defined as follows

ready-Ui accept ltreadySTigt from Ui isin U

send ltreadybullUigt to A

3 ready-P accept ltreadygt from P isinMU

ready [ready-P forallP isinM]

share[readyand notfinish_setup] accept ltsendxSTjgt from STi

if Ui Uj isin Room8 send ltdeliverxSTigt to STj

send ltperpSTigt to Ui

finish_setup[readyandnotfinish_setup]

accept ltfinish_setupgt from U isin U

13 from i=1 to n

send ltclosegt to STi accept ltclosebullgt from STi

relay_receive[ready] accept ltxSTigt from Ui send ltxgt to STi

relay_send[ready] accept ltxgt from STisend ltxSTigt to Ui

(The sixth line signifies that ready is considered true when ready-P

is true for all P isinM)

DT H E C O M P L E T E P R O O F O F E M U L AT I O N

The static call graph has only an edge from prot-fkm to prot-fsetupπFCΠImpl is thus rooted at prot-fkm

Lemma 16 For all KU parameters FC Π πFCΠImpl is a poly-timeprotocol

Proof By Definition 2 in [51 sect 6] we need to show that there exists apolynomial p such that for every well-behaved environment Z that isrooted at prot-fkm we have

Pr[TimeπFCΠImpl[πFCΠImpl AD Z](η)

gt p(FlowZrarrπFCΠImplAD[πFCΠImpl AD Z](η))]

= negl(η)

Let pmax be a polynomial such that for all Fi and C isin C the al-gorithm implC terminates in a running time smaller than pmax(n)where n is the length of the input implF

newis always called on input

of length η thus all keys have a length smaller pmax(η) In step newF and a are provided by the environment (as input to Ui which thenasks Fsetup to relay the request to STi) Store grows at most by somepolynomial pgrowthminusnew in the length of the environmentrsquos input Sim-ilarly an ltunwrapgt query cannot grow the Store by more thanpgrowthminusunwrap Therefore at any point in time t (we simply count thenumber of epochs i e activations of the environment) the store issmaller than p prime(FlowZrarrπFCΠImplAD

[πFCΠImpl AD Z](η)) for a poly-nomial p prime

We observe that there is not a single activation of a machine inπFCΠImpl neither a Ui an STi nor Fsetup where the running timeis not polynomial in the environmentrsquos input and the length of theStore AD might corrupt user U isin UcupUext but they do not have anystate Thus we have for the running time of πFCΠImpl at point ti e TimeπFCΠImplt

[πFCΠImpl AD Z](η)

TimeπFCΠImplt[πFCΠImpl AD Z](η)

= TimeπFCΠImpltminus1[πFCΠImpl AD Z](η)+

p prime(FlowZrarrπFCΠImplAD[πFCΠImpl AD Z](η))

6 t middot p prime(FlowZrarrπFCΠImplAD[πFCΠImpl AD Z](η))

6 p primeprime(FlowZrarrπFCΠImplAD[πFCΠImpl AD Z](η))

244 the complete proof of emulation

for another polynomial p primeprime because

t lt FlowZrarrπFCΠImplAD[πFCΠImpl AD Z](η))

The proof that π implements FKM proceeds in several steps Mak-ing use of the composition theorem the last functionality Fl in FKM

can be substituted by its key-manageable implementation IL Then

FKM can simulate I instead of calling it Let FFlIl KM be the result-

ing functionality In the next step calls to this simulation are sub-stituted by calls to the functions used in I implC for each C isin Cl

The resulting partially implemented functionality FFlImplFl

KM saveskeys rather than credentials (for Fl) We repeat the previous stepsuntil FKM does not call any KU functionalities anymore i e we

have FF1ImplF1

FnImplFn

KM which we abbreviate to Fimpl

KM Thenwe show that the network of distributed token π emulates the mono-lithic block F

KM which does not call KU functionalities anymoreusing a reduction to the security of the key-wrapping scheme

The first four steps will be the subject of Lemma 6 the last stepis Lemma 7 But before we come to this the following definition ex-presses partial implementations of FKM In fact the formal definitionof FKM is the special case in which the set of substituted functionali-ties is empty

Definition 34 (FKM with partial implementation) Given the KU pa-rameters FC Π and functions (implKW

newwrap unwrap) let ImplFi

bethe algorithms defining the keymanageable implementation Ii of Fi isin

F1 Fp sub F We define the partial implementation of FKM withrespect to the KU functionalities F1 Fp denoted

FF1ImplF1

FpImplFp

KM as follows

Let the ideal protocols Fp+1 Fl be rooted at prot-Fp+1

prot-Fl In addition FF1ImplF1

FpImplFp

KM defines the protocolname prot-fkm For prot-fkm the protocol defines the following be-haviour A regular protocol machine with machine ID 〈〈regFi〉 sid〉

for Fi isin F1 Fl runs the following code

3 relay_to accept ltmgt from ltidealsidgt (= FKM)

The ideal party runs the logic for FKM described in Section-84 withthe following alteration of the corrupt macro used in the corrupt andwrap step

the complete proof of emulation 245

Listing 35 procedure for corrupting a credential c

Kcor larr Kcor cup c for any Store[Uh]=〈F a c〉

if F isin KWF1 Fp

4 key[c]larr c

send ltcorruptbullhcgt to A

call F with ltcorruptcgt

accept ltcorruptbullkgt from F

9 key[c]larr k

send ltcorruptbullhkgt to A

and in the new command public_command and unwrap steps

if ltFnewagt isin Π then

if F isin F1 Fp

(k public) larr implFnew(1η)

5 create h Store[Uh] larr ltFakgt

Klarr Kcup k send ltnewbullhpublicgt to U

else if F = KW

(k public)larr implKWnew (1η)

10 if k isin KcupKcorsend lterrorgt to A

create h Store[Uh] larr ltFakgt

Klarr Kcup k 15 send ltnewbullhpublicgt to U

call F with ltnewgt

if c isin KcupKcor20 send lterrorgt to A

create h Store[Uh] larr ltF a cgt

Klarr Kcup c send ltnewbullhpublicgt to U

1 command[finish_setup]

accept ltChmgt from U isin U

if Store[Uh]=ltFacgt and ltFCagtisin Πif F isin F1 Fp

send ltCbullimplC(cm)gt to U

6 else if F 6= KW

call F with ltCcmgt

accept ltCbullrgt from F

1 public_command

accept ltCpublicmgt from U isin U

if C isin Cipub

if F isin F1 Fp

send ltCbullimplC(publicm)gt to U

6 else

accept ltCbullrgt from Fisend ltCbullrgt to U

1 unwrap[finish_setup]

accept ltunwraph1wa2F2idgt from U isin U

if Store[Uh1]=ltKWa1c1gt and

ltKWunwrapa1a2gtisin ΠF2 isin F

if c1 isin Kcor

6 c2 = unwrapltF2a2idgt(c1 w)

Kcor larr Kcor cup c2 if F2 isin KWF1 Fp

create h211 Store[Uh2] larr ltF2a2c2gt

key[c2]=c2else

16 if c prime 6isin KcupKcorcreate h2Store[Uh2] larr ltF2a2c

primegt

key[c prime]=c2send ltunwrapbullhgt to U

21 else if c2 6= perp c2 isin K and c2 isin Kcorcreate h2Store[Uh2] larr ltF2a2c2gt

26 send lterrorgt to A

else if ( c1 isin Kcor and

existc2ltc2ltF2a2idgtwgtisinencs[c1])create h2Store[Uh2] larr ltF2a2c2gt

31 send ltunwrapbullhgt to U

Note that the partial implementation of FKM is not an ideal proto-col in the sense of [51 sect 82] since not every regular protocol machineruns the dummy party protocol ndash the party ltregFigt relays the com-munication with the KU functionalities

FlImplFl

Proof Induction on the number of substituted KU functionalities

base case FemptyKM actually equals FKM Since emulation is reflexive

FemptyKM emulates FKM It is left to show that FKM is poly-time The argu-

ment is actually the same as for πFCΠImpl (see proof to Lemma 16)after we have established five things 1 instead of calling implemen-tation functions implFC for F 6= KW FKM is calling the function F withthe same value Since F is key-manageable it is also poly-time 2 Theimplementation function for wrapping is applied on a different valuebut this value has the same length therefore the same upper boundholds for its running time 3 Graph reachability is linear in the num-ber of credentials which in turn is polynomial because the flow fromthe environment is polynomial and thus the number of new queries ispolynomial too Therefore only a number of credentials that is poly-nomial in the flow from the environment is added 4 The relayingof messages from Ui via Fsetup does not add more than linearly in ηto the running time 5 similarly for the distribution of the ltfinish_-

setupgt message

induction step Assume i gt 1 and FF1ImplF1

Fiminus1ImplFiminus1

KM(in the following Fiminus1

KM ) emulates FKM Since emulation is transi-

tive it suffices to show that FF1ImplF1

FiImplFi

KM emulates Fiminus1KM We

will proceed in three steps First we will substitute Fi by its key-manageable implementation Ii Then we will alter FKM to simulateIi inside The main part of the proof is showing that Ii can be emu-lated by calling ImplFi

inside FKM storing keys instead of credentialsThe first step is a consequence of composition theorem [51 The-

orem 7] The induction hypothesis gives us that Fiminus1KM is a poly-

time protocol which is rooted in fkm By assumption Ii is the key-manageable implementation of Fi i e Ii is a polytime protocol thatemulates Ii Furthermore Ii defines only F-i therefore IF is substi-tutable for Fi in Fiminus1

KM Therefore Fiminus1[FiIi] is poly-time and emu-lates Fiminus1

KM In the second step we alter Fiminus1[FiIi] (in the following Fiminus1 prime

KM )such that the ideal functionality defined in Fiminus1 prime

KM (protminus fkm) sim-ulates Ii locally and calls this simulation whenever 〈〈regFi〉 sid〉

would be addressed in FKM Ii might send a message to A in whichcase this message is indeed relayed to A Since the simulation willonly be called by FKM it will only respond to FKM We will callthis protocol Fiminus1 primeprime

KM To show that Fiminus1 primeprime

KM emulates Fiminus1 prime

KM we have tomake sure that in Fiminus1 prime

KM Ii can only be addressed by FKM via therelay mechanism implemented in 〈〈regFi〉 sid〉 (which consequentlyis not present in Fiminus1 primeprime

KM since any call to 〈〈regFi〉 sid〉 is substitutedby calls to the simulation of Ii) If this is the case then the observableoutput to the environment is exactly the same First Ii never adressesltadvgt so by C5 it cannot be adressed by the adversary Second sincethe environment is rooted at proto-fkm it cannot address Ii Thirdthere is no other regular party than 〈〈regFi〉 sid〉 in sid that calls Ii

By C8 there cannot be other regular machines addressing Ii There-fore Fiminus1 primeprime

KM Since Ii is poly-time Fiminus1 primeprime

KM can simulateit and is still poly-time

In the third step we show that Fi emulates Fiminus1 primeprime

KM We claim thatin fact with overwhelming probability Fi provides a perfect simula-tion of Fiminus1 primeprime

KM namely when the list L maintained in Fiminus1KM describes a

function from credentials to keys Whenever a pair (c k) is added to L(this happens only in steps new and inject) implFi

newis used to draw c

Since for all k Pr[k prime = k|k prime larr implFinew

(1η)] is negligible by assumption(see Definition 24) for every c there is (with overwhelming probabil-ity) exactly one k such that (c k) isin L hence L describes a functionfrom credentials to keys So we can assume that with overwhelmingprobability this list describes a function We will inspect the stepsnew command wrap unwrap and corrupt since they are the onlysteps that produce an output depending on the value of the creden-tial Note first that since Pr[k prime = k|k prime larr implFi

new(1η)] is negligible

for all k and since both K and Kcor are only polynomial in size thechecks for c isin KcupKcor in step new pass only with negligible probabil-ity Therefore we can assume those checks to be non-operations Thesteps new corrupt and command are trivial to verify Each credentialis substituted by the corresponding key The corruption macro usedin both steps corrupt and wrap makes sure that for each credentialc isin KcapKcor key[c] contains the same key that the bijection definedby L in Fiminus1

KM assigns to it Furthermore for each c 6isin K c isin Kcor thestep unwrap gives the same guarantee (by definition of step inject

in Definition 24) Therefore the step wrap correctly substitutes cor-rupted credentials by keys Since Ii is key-manageable and both cre-dential and keys are drawn using implFi

new with overwhelming proba-

bility the substitution is correct for uncorrupted credentials too Thelast step to check is unwrap Unless c1 isin Kcor and c2 6isin K this steprestores only a previously created credential in the Store so no sub-stitution necessary In case that c1 isin Kcor and c2 6isin K a credentialthat is freshly created and linked to the content of the wrapping (seethe inject step) is stored whereas in Fiminus1 primeprime

KM it is the content of thewrapping itself that is stored

By transitivity of emulation we have that Fi emulates FKM By thefact that Fi actually computes less than Fiminus1 primeprime

KM we know it is poly-time

Definition 35 (guaranteeing environment) Suppose Z is an environ-ment that is rooted at r and p is a predicate on sequences of (id0 id1m) Let Sp(Z) be a sandbox that runs Z but checks at the end ofeach activation if the predicate holds true on the list of messages sentand received by the environment (including the message about to besend) If the predicate does not hold true Sp aborts Zp and outputssome error symbol fail isin Σ We say that Z guarantees a predicate p if

there exists such a sandbox Sp(Z) and for every protocol Π rooted atr for every adversary A we have that

Pr[Exec[ΠAZ] = fail]

is negligible in η

Let us denote a list of messages mi from ai to bi as Mt = ((a0 b0

m0) (at btmt)) We will denote the i-prefix of this list by MiWe can filter messages by their session ID Mi

|SP denotes a messages(ai bimi) where either ai = lt env gt and bi is of the form

〈〈reg basePID〉〈α1 αkminus1 〈protminus fkm 〈SP〉〉〉〉

or vice versa We say (aj bjmj) is a response to (ai bimi) if (aj bjmj) is the earliest message such that i lt j ai = bj bj = ai and thatno other message at an epoch k lt i exists such that (ai bimi) isa response to (ak bkmk) This assumes that there is a response toevery query (In case of an error FKM responds with perp rather thanignoring the query) In order to tell which handles are corrupted weneed to define which handles point to the same key a given momentt

Given M|NP = M|UUextSTRoom = ((a0 b0m0) (an bnmn))we define equiv0 to be the empty relation and for all 1 6 t 6 n wedefine equivt as the least symmetric transitive relation such that

1 equivtsubequivtminus1 cup (Uh) (Uh) if mt = lt newbull h public) gt at = Uand exists lt t F a ms = lt new F a gt and (at btmt) is aresponse to (as bsms)

2 equivtsubequivtminus1 cup (U1 h1) (U2 h2) if mt = lt sharebull gt at = U1

and exists lt t ms = lt share (U1 h1) (U2 h2) gt and (at btmt)

is a response to (as bsms)

3 equivtsubequivtminus1 cup (U1 h1) (U2 h2) if mt = lt unwrapbull h2 gtat = U2 and existq r s such that (at btmt) is a response to(as bsms) and (ar brmr) is a response to (aq bqmq) andr lt s Furthermoremq = lt wrap h1 h2 id gt bq = U1mr = lt wrapbull w gtar = U1

and ms = unwrap h prime1 w a F id gt bs = U1 and

(U2 hprime1) equiv

tminus1 (U1 h1)

4 equivt=equivtminus1 otherwise

Using this relation we can define the predicate corruptedM|NP(Uh)

which holds iff either some (Ulowast hlowast) ((Ulowast hlowast) equivt (Uh)) were cor-rupted directly via wrapping with a corrupted key or injected viaunwrapping i e if there are mimj isin M|NP mj is a response to mi

bull mj = (adv env 〈corruptbull hlowast c〉)mi = (env Ulowast 〈corrupt h〉)

(for some c) or

bull mj = (Ulowast env 〈wrapbull w〉) mi = (env Ulowast 〈wrap h1 hlowast id〉)

with corruptedM|NP(Ulowast h1) or

bull mj = (Ulowast env 〈unwrapbull hlowast〉)mi = (env Ulowast 〈unwrap h1 w a2

F2 id〉) with corruptedM|NP(Ulowast h1)

Finally let corrupt-before-wrap be the following predicate on a listof messages Mt = ((a0 b0m0) (at btmt)) For all i 6 t andnetwork parameters NP = UUext STRoom we have

corruptedM|NP(Uh)and (env Ult wrap h h prime gt) isinMi

rArr corruptedMi|NP

FlImplFl

Proof Proof by contradiction Assuming that there is no adversarySim such that for all well-behaved environments Z that are rooted atprot-fkm and guarantee corrupt-before-wrap both networks are indis-tinguishable i e

Exec[πFCΠImpl AD Z] asymp Exec[Fimpl

KM Sim Z]

we chose a Sim that basically simulates Fsetup for corrupted usersin F

KM and a Z that is indeed able to distinguish Exec[πFCΠImpl

AD Z] and Exec[Fimpl

KM Sim Z] Then we use it to construct an at-tacker BZ against the key-wrapping challenger BZ will be carefullycrafted such that a) it is a valid adversary b) it has the same outputdistribution in the fake key-wrapping experiment as Z has when in-teracting with F

KM and Sim c) it has the same output distribution inthe real key-wrapping experiment as Z in interaction with πFCΠImpl

and ADSim defines the same code as the dummy adversary (see [51 sect47])

but when instructed by the environment to instruct a corrupted partyto call Fsetup it simulates Fsetup (because F

KM does not define prot-

-fsetup) This means Sim waits for 〈readybull P〉 from Fimpl

KM for allparties P isin Ucup ST cup F before operating - for corrupted parties Ui isin U

(security tokens are incorruptible Uext isin Uext are ignored) it waits un-til instructed to send ready and simulates the reception of 〈readybull P〉itself Afterwards it accepts instructions to send 〈m〉 as Ui to Fsetupndash

in this case Sim instructs Ui to send m to Fimpl

KM Similarly the re-sponse from F

KM is simulated to be transmitted via Fsetup When Ui

is instructed to send finish_setup to Fsetup Sim sends finish_setup

to Fimpl

KM instead (and relays the answer) but only if it received readyfrom all parties P isin Ucup ST cup F before (as we already mentioned) andonly the first time

Given Z we will now construct the attacker BZ against the key-wrapping game in Definition 31 Recall that Z is rooted at prot-fkmThis means that Z only calls machines with the same SID and the pro-tocol name prot-fkm In particular the session parameters (FC Π)are the same (see [51 sect53]) so from now on we will assume themto be arbitrary but fixed The construction of BZ aims at simulat-ing Z in communication with the simulator Sim given above and thekey-management functionality F

KM but instead of performing wrap-ping and unwrapping in F

KM itself BZ queries the challenger in thewrapping experiment In case of the fake experiment the simula-tion is very close to the network [F

KM Sim Z] for the case of thereal experiment we have to show that the output is indistinguishablefrom a network of distributed security tokens and a dummy adver-sary [πFCΠImpl AD Z] This will be the largest part of the proof

BZ is defined as follows BZ simulates the network [FimplKWKM Sim Z]

where FimplKWKM is defined just as F

KM but newwrapunwrap andcorrupt are altered such that they send queries to the experimentinstead Note that for this reason FimplKW

KM is not a valid machine inthe GNUC model - we just use it as a convenient way to describe thesimulation that BZ runs We assume that the place-holder symbolsK1 from Definition 31 are distinguishable from other credentialsand that there is some way to select those symbols such that each ofthem is distinct Furthermore they should be difficult to guess Oneway to achieve this is to implement a pairing of i and j for U = Ui

and jlarr 0 1η using Cantorrsquos pairing function

if F isin F1 Fl

4 (k public) larr implFnew(1η)

else if F = KW

9 create Ki h

query NEW(Ki)

Klarr Kcup Ki

Store[Uh] larr ltKWaKigt

send ltnewbullhgt to U

wrap[finish_setup]

2 accept ltwraph1h2idgt from U isin U

and ltKWwrapa1a2gtisin Πif existwltc2ltF2a2idgtwgtisinencs[c1]

send ltwrapbullwgt to U

7 else

WlarrWcup (c1 c2) if c1 isin Kcorfor all c3 reachable from c2 in W

corrupt c312 wlarr wrapltF2a2idgt(key[c1]key[c2])

w = TENC(c1 lt F2 a2 id gt c2)encs[c1] larr encs[c1] cup ltc2ltF2a2idgtwgtsend ltwrapbullwgt to U

unwrap[finish_setup]

4 if c1 isin Kcor

c2 = unwrapltF2a2idgt(key[c1] w)

if c2 6= perp and c2 isin KKcorKcor larr Kcor cup c2 create h2

9 Store[Uh2] larr ltF2a2c2gt

key[c2]=c2send ltunwrapbullhgt to U

else first bad event

send lterrorgt to A

14 else

if existc2ltc2ltF2a2idgtwgtisinencs[c1]create h2Store[Uh2] larr ltF2a2c2gt

19 else c1 6isin Kcor andnotexistc2〈c2 〈F2 a2 id〉 w〉 isinencs[c1])query c2 = DEC(c1 lt F2 a2 id gtw)if c2 6= perp second bad event

halt and output 0

Listing 36 Procedure for corrupting a credential c

if c isin Kcorsend ltcorruptbullhkey[c]gt to A

3 else

Kcor larr Kcor cup c for any Store[Uh]=ltFacgt

if F isin KW

query k = CORR(c)

8 key[c]larr k

key[c]larr c

send ltcorruptbullhkey[c]gt to A

BZ is a valid adversary We will argue about each conditionon the behaviour of the adversary from Definition 31

1 For all i the query NEW(Ki) is issued at most once because wespecified F

implKWKM to select a new Ki for each such query

2 All queries issued by BZ contain keys that have already beengenerated by the experiment Observe that all queries are pre-ceeded by a conditional that checks if the argument to the queryis in the third position of the store i e there are Uh a suchthat Store[Uh] = 〈KW a k〉 at some point of the execution ofBZ We claim that each such k has either been generated us-ing NEW or is in Kcor (in which case no query is made) Proofby contradiction Assume we are at the first point of the ex-ecution where such a key is added to the store The store isonly written in the new and unwrap step In new a new Ki iscreated In unwrap there are three cases in which the store iswritten to a) If c1 isin Kcor then c2 isin Kcor Once somethingis marked as corrupted it stays corrupted b) If c1 6isin Kcor butexistc2 〈c2 〈F2 a2 id〉 w〉 isin encs[c1] Only wrap can write to encsso c2 must have been in the store before

3 The adversary never makes a test query TENC(Ki a Kj) if Ki iscorrupted at the end of the experiment because a TENC queryis only output in the step wrap if c1 6isin Kcor The conditioncorrupt-before-wrap enforces that if c1 is not corrupted at thatpoint it will never be corrupted (A detailed analysis abouthow corrupt-before-wrap is correct with respect to the definitionif FimplKW

KM is left to the reader)

4 If BZ issues a test query TENC(Ki am) then BZ neither issuesTENC(Kj a

primem prime) nor ENC(Kj aprimem prime) with (Ki am) = (K prime

m prime) since BZ never issues ENC queries at all and only issuesTENC queries if the same combination of (Ki am) was notstored in encs before Every time TENC is called encs is up-dated with those parameters

5 BZ never queries DEC(Ki a c) if c was the result of a queryTENC(Ki am) or of a query ENC(Ki am) or Ki is corruptedbecause a) TENC queries are stored in encs and the step unwrap

checks this variable before querying DEC b) enc queries are notissued at all c) if a credential c1 inside the unwrap step is cor-rupted the query DEC is not issued

We conclude that BZ fulfills the assumptions on the behaviour of theadversary expressed in Definition 31

BZ simulates FimplKWKM in the fake experiment BZ is de-

fined to be a simulation of the network[

FimplKWKM Sim Z

FimplKWKM is F

KM except for the altered steps newwrapunwrap andcorrupt We claim that in the fake experiment those alterations donot change the inputoutput behaviour First we will simplify theunwrap step in F

2 accept ltunwraph1wa2F2idgt from U isin U

3 if Store[Uh1]=ltKWa1c1gt and

4 ltKWunwrapa1a2gtisin ΠF2 isin F

5 if c1 isin Kcor

7 if c2 6= perp and c2 6isin K

8 Kcor larr Kcor cup c2 9 create h2

11 key[c2]=c212 send ltunwrapbullhgt to U

13 else if c2 6= perp c2 isin K and c2 isin Kcor14 create h215 Store[Uh2] larr ltF2a2c2gt

17 else (c2 = perpor c2 isin KKcor)

19 else if ( c1 isin Kcor and

20 existc2ltc2ltF2a2idgtwgtisinencs[c1])21 create h222 Store[Uh2] larr ltF2a2c2gt

We first observe that it would not make a difference if the code inthe branch at Line 13 would execute the same code as in the branchat Line 7 i e additionally perform the computations in Line 8 and11 since from the definition of the steps unwrap and the corruptionprocedure if c2 isin Kcor then already key[c2] = c2 This means thatLines 7 to 12 are executed if c2 6= perp and c2 6isin K Kcor otherwise abad event is produced i e an error is send to the adversary Forreference this is the equivalent simpler code

if c1 isin Kcor

c2 = unwrapltF2a2idgt(c1 w)

7 if c2 6= perp and c2 isin KKcorKcor larr Kcor cup c2 create h2Store[Uh2] larr ltF2a2c2gt

key[c2]=c212 send ltunwrapbullhgt to U

send lterrorgt to A

existc2ltc2ltF2a2idgtwgtisinencs[c1])17 create h2

We claim that the following invariant holds For all Z and at theend of every epoch [51 sect53] i e after each activation of Z

bull the distribution of the input received by Z (the view of Z) is thesame for Z in [F

KM Sim Z] as well as in the network [FimplKWKM

Sim Z] simulated by BZ

bull in the same two execution the entry Store[Uh] = 〈KW a c〉 ex-ists in F

implKWKM if and only if the entry Store[Uh] = 〈KW a c〉

exists in Fimpl

KM and the following holds for c and c

ndash c isin Kharr c isin K and c isin Kcor harr c isin Kcor

ndash if c isin K then c is the key drawn for c in the NEW stepFurthermore if c isin Kcor in F

implKWKM key[c] = c and in

KM key[c] = c

ndash if c isin Kcor K (i e c was injected) c = c and key[c] = c inboth F

implKWKM and F

The only relevant steps are the altered steps newwrapunwrap andthe corruption macro

bull corrupt For honestly generated wrapping keys c isin K by in-duction hypothesis the corruption procedure outputs the keygenerated with NEW in F

implKWKM and the equally drawn key in

case of Fimpl

KM Assume c isin K If c isin Kcor by induction hypoth-esis both F

KM and FimplKWKM produce an error and leave their

respective store unchanged For dishonestly generated keys ndashthat is for the missing case where c isin Kcor K ndash both outputthe same keys by induction hypothesis The second conditionholds by definition of this step and induction hypothesis

bull new From the definition of the fake experiment follows thatthe first condition holds The second condition holds since thefreshly created c is added to K and since c is the argument tothe NEW step

bull wrap By definition of the fake experiment ENC and TENC sub-stitute credentials c in F

implKWKM If c1 6isin Kcor then c1 isin K (as

otherwise it would not be in the database) Thus in FimplKWKM

TENC will perform this substitution for both c1 and c2 result-ing in the same output that Fimpl

KM produces If c1 isin Kcor thenby definition of this step in F

KM c2 isin Kcor at the point in thetime where the unwrap function is computed Therefore andby induction hypothesis key[c1] in F

implKWKM contains c1 The

same holds for c2) Hence the same value is computed andoutput in F

implKWKM and F

KM and the first condition holds Thesecond condition holds by induction hypothesis and the factthat both functions call the corrupt macro on c2 if c1 isin Kcor

bull unwrap Since for c1 6isin Kcor (by definition of the fake experi-ment) DEC produces perp i e the conditional marked ldquosecondbad eventrdquo never evaluates Note furthermore that this step isthe same in F

implKWKM and F

KM only that the call to the unwrap

function in case c1 isin Kcor substitutes c1 by key(c1) in FimplKWKM

This is correct by the second condition of the induction hypoth-esis Therefore both conditions of the induction hypothesis arepreserved for the next step

We can conclude that

ExpwrapfakeKWBZ

(η) = Exec[Fimpl

KM Sim Z](η)

BZ simulates πFCΠImpl in the real experiment In thefake experiment it is not possible that BZ halts at the end of theunwrap step (marked ldquosecond bad eventrdquo) since DEC always outputsperp Thus the probability that BZ halts at the ldquosecond bad eventrdquo markwhilst in the real experiment must be negligible as this would contra-dict the assumption that KW is a secure wrapping scheme right hereThe representation of the this part of the proof benefits from alteringBZ such that instead of halting BZ continues to run F

implKWKM by

running the following code

1 create h2 Store[Uh2]larr ltF2a2c2gt

We further modify the code of BZ by removing the conditional infront of the comment ldquofirst bad eventrdquo Here as well the probabilitythat this conditional evaluates to true is negligible following fromthe assumption that KW is a secure wrapping scheme Proof by con-tradiction If BZ could produce this conditional then she knows awrappingw such that unwrapa(k1 w) = c2 for c2 isin K and c2 6isin KcorSince c1 isin Kcor and k1 = key[c1] BZ either knows k1 (since it injectedit i e c1 6isin K) or can learn by corrupting it (if c1 isin K) If there wasa path in W from c1 to c2 it would already be corrupted so the at-tacker can learn k1 while c2 6isin Kcor She can use k1 as to decrypt whimself and learn c2 But she should not be able to learn c2 in thefake experiment since it is randomly drawn and did never appear inany output1 Since this happens only with neglible probability it canonly happen with negligible probability in the real experiment too

1 The adversary can check if it guessed c2 correctly for example by requesting awrapping of a third corrupted wrapping key under c2 via F

implKW

KM and then callingDEC to check if the received wrapping (using the same argument) decrypts to thecorrupted and thus known key

as otherwise the assumption that KW is a secure wrapping schemewould be contradicted

Therefore we perform those modifications and call the sightly dif-ferent attacker B prime

Z Since those parts of the code are only executedwith negligible probability we have that

Pr[blarr ExpwrapKWBZ

(η) b = 1] minus Pr[blarr ExpwrapKWB prime

Z(η) b = 1]

is negligible in ηFix an arbitrary security parameter η Then let ViewB prime

Z(t) be the

view of Z i e the distribution of messages it is simulated to sendto the protocol machine or the adversary in the tth step of the sim-ulation of B prime

Z in the real experiment Furthermore let StoreB primeZ(t)

be the distribution of the variable Store within the simulated ma-chine 〈ideal sid〉 i e FimplKW

KM but with the following substitutionthat affects the wrapping keys Every entry 〈KW a Ki〉 in the variableStore[Uh] for some U and h is substituted by an entry 〈KW a ki〉where ki is the key that the key-wrapping experiment associates toKi denoted in the following by k(Ki) If Ki was not created by thekey-wrapping experiment it is left untouched

We will denote the view of Z in the execution of the network[πFCΠImpl AD Z] by Viewπ and the distribution of the union of allStore variables of all security tokens ST1 STn in the network asStoreπ The union of those variables is still a map because the firstelement of each key-value of this table is different for all ST A step tis an epoch [51 sect53] i e it begins with an activation of Z and endswith the next activation

We define the following invariant which will allow us to concludethat B prime

Z has the same output distribution as [πFCΠImpl AD Z] Foreach number of steps t the following three conditions hold

bull state consistency (sc) StoreB primeZ

(t) and Storeπ are equally dis-tributed

bull output consistency (oc) ViewB primeZ

(t) and Viewπ are equally dis-tributed

bull phase consistency (pc) The probability that the flag ready is setin F

implKWKM in Expwrap

KWB primeZ

equals the probability that ready isset in Fsetup in [πFCΠImpl AD Z] Furthermore the probabil-

ity that the flag setup_finished is set in FimplKWKM in Expwrap

KWB primeZ

equals the probability that setup_finished is set in all ST isin ST

If t = 0 the protocol has not been activated thus there was nooutput and not state changes The invariant holds trivially If t gt 0we can assume that sc oc and pc were true at the end of the pre-ceding epoch Note that Z is restricted to addressing top-level parties

with the same sid In particular it cannot address Fsetup directly (butit can corrupt a user to do this) Since the sid has to have a specificformat that is expected by all machines in both networks we assumesid to encode UUext STRoom Case distinction over the recipientand content of the message that Z sends at the beginning of the nextepoch

1 Z sends a message to STi isin ST and

a) the message is 〈ready〉 In ExpwrapKWB prime

implKWKM records

ready-STi and sends 〈readybullSTi〉 to Sim if the messageis recorded for the first time Sim behaves just like AD inthis case If all other STj isin ST and all U isin U have sent thismessage before the flag ready is set to true

In [πFCΠImpl AD Z] STi accepts the message and for-wards it (as 〈ready〉) to Fsetup Then Fsetup records ready-STi and sends lt readybullSTi gt to AD if the message isrecorded for the first time If all other STj isin ST and allU isin U have sent this message before the flag ready is setto true We see that pc and oc hold Sc holds triviallybecause the Store did change in neither execution

b) the message is of some other form In [πFCΠImpl AD

Z] ST accepts no other message from the environmentIn Expwrap

KWB primeZ

FimplKWKM ignores any other message coming

from STi too So pc oc and sc hold

2 Z sends a message to Ui isin U

In ExpwrapKWB prime

implKWKM will receive this message and treat it

depending on its form (if its flag ready is set) In [πFCΠImpl

AD Z] Ui will relay this message m in the form ltmSTigt toFsetup who in turn will send m to STi (assuming the stepsnecessary for the flag ready were completed)

a) Let m be ltreadygt If the ready flag has not been set be-fore and Ui is the last party in U cup ST that has not sentthis message yet FimplKW

KM in ExpwrapKWB prime

Zwill set the ready

flag otherwise it will not The same holds for Fsetup in[πFCΠImpl AD Z] Therefore we have pc In both casesSim respectively AD forwards the acknowledgement tothe environment (after recording the state change) Thussc and oc hold trivially

For the following cases assume ready to be set in bothExpwrap

KWB primeZ

and [πFCΠImpl AD Z] If it is unset in one ofthem by induction hypothesis it is unset in both If itis not set any other message will not be accepted by nei-ther F

implKWKM nor Fsetup (thus never reach STi) Therefore

in the following cases we will assume ready to be set in

FimplKWKM and Fsetup i e Fsetup delivering commands thatUi receives from the environment to STi

b) Let m=ltnewFagt If F 6= KW the same code is executed(except for the step adding the freshly created credentialto K) pcsc and oc hold trivially Assume F = KW

and ltKWnewagtisin Π (otherwise perp is output in both exe-cutions) F

implKWKM draws a new Ki and call NEW to cre-

ate the key Ki is created just like handles in a waythat makes sure it is unique Therefore since through-out Expwrap

KWB primeZ

Ki is always substituted for the same keythere is a function mapping Ki to the key ki created bythe experiment and this function is injective Note thatby the definition of StoreB prime

Z StoreB prime

Z(t) is StoreB prime

Z(t minus 1)

with an additional entry 〈KW a ki〉 at [Uh] where ki is dis-tributed according to KG In [πFCΠImpl AD Z] STi callsthe key-generation directly (implKW

newcalls KG adding noth-

ing but an empty public part) The output in both cases isltnewbullhgt for an equally distributed h Thus oc holdsStoreπ is Storeπ(tminus 1) with an additional entry KWaki at[Uh] where ki is distributed according to the same KG asabove Therefore sc holds ( Pc holds trivially)

c) Let m = 〈share hi Uj〉 In ExpwrapKWB prime

Z assuming Ui Uj isin

Room FimplKWKM outputs 〈sharebull hj〉 and StoreB prime

Z(t) equals

StoreB primeZ(t minus 1) extended by a copy of its entry [Ui hi] at

[Uj hj] In [πFCΠImpl AD Z] STi checks the same condi-tions (which by pc have an equal probability of success)implicitly It sends the content of its store at [Ui hi] toFsetup which verifies Ui Uj isin Room If this is not the caseFsetup sends perp to STi which sends this to the environment(via Fsetup) behaving just like Expwrap

KWB primeZ

If the condition ismet STi sends the content of the store at [Ui hi] to Fsetupwhich delivers this information to STj which in the nextstep extends Storeπ(tminus 1) by a copy of its entry [Ui hi] at[Uj hj] Thus sc holds Both output ltsharebullhjgt uponsuccess so oc holds too pc holds trivially

d) Let m = 〈finish_setup〉 By pc we have that ExpwrapKWB prime

and [πFCΠImpl AD Z] either both have finish_setup setor none has If both have it set both output perp and donothing

Assume none has finish_setup set and both ready InExp F

implKWKM sets the flag finish_setup and responds

In [πFCΠImpl AD Z] Ui sends ltfinish_setupgt to Fsetupwhich in turn instead of forwarding it to STi like for themajority of commands sends ltclosegt to every STj isin ST accepting the response (and thus taking control) after each

of those have set the finish_setup flag By the time Fsetup

finishes this step and hands communication over to Uiwhich forwards finish_setup to the environment everySTi has left the setup phase We see that pc and oc arepreserved

e) Let m = 〈Chm〉 FimplKWKM and STi execute the same

code on their inputs so by sc the invariant is preserved

f) Let m = 〈corrupt h〉 STi outputs the credential FimplKWKM

does the same except for wrapping keys where it substi-tutes the credential by the output of CORR i e k = k(c)By definition of Storeπ as sc lt KW a k gt isin Storeπ[Ui h]

with the same probability as lt KW a c gt isin StoreB primeZ[Ui h]

thus the output is equally distributed Sc and pc holdtrivially

g) Let m = 〈wrap h1 h2 id〉 For this case and the followingcase observe that F

implKWKM initialises key[c] only at steps

wrap unwrap and corrupt

The variable key[c] contains either the output of a queryCORR thus k(c) or the same value as c or it is definedIt is defined whenever c isin Kcor capK because if c is addedto Kcor at step corrupt the response is written to key[c]and if a c3 6isin Kcor is found during step wrap the conditioncorrupt-before-wrap must have been violated by Z If sucha c3 is reachable from c1 without loss of generality as-sume it to have minimal distance from c1 in W Then thesecond-before last node on this path is in Kcor as the dis-tance would not be minimal otherwise By definition of thestep wrap this node could not have been wrapped withoutadding it to Kcor therefore this node was corrupted afterit was used to create this wrapping If c isin Kcor but c isin Kthen key[c] = c (see step unwrap)

Assume now STi and FimplKWKM both have finish_setup set

as otherwise either pc was violated in the previous stepor both would output perp and trivially satisfy the invariant(This argument is valid for each of the following sub-casesbut the last one)

Both machines check the same conditions on the Store andthe policy STi computes w = wrap〈F2a2id〉(c1 c2) on thevalues 〈KW a1 c1〉 and 〈F2 a2 c2〉 at [Ui h1] and [Ui h2]

in Storeπ

FimplKWKM performs a case distinction but we will show that

in each cases it outputs the same value If 〈c2 〈F2 a2 id〉w〉 isin encs[c1] then by observing that encs is only writtenat the end of this function we see that pc would have

been violated in an earlier step if the output now was dif-ferently distributed then the output in [πFCΠImpl AD Z]

If c1 isin Kcor then c2 isin Kcor too Assume c1 c2 isin K Thensince key(c1) = k(c1) (and key(c2) = k(c2) in case F2 =

KW) the output is w = wrapltF2a2idgt(k(c1) c2)) (or w =

wrapltF2a2idgt(k(c1) k(c2))) which preserves oc since scfrom the last step guarantees that 〈KW a c〉 isin Storeπ[Ui h]

which equals 〈KW a k(c)〉 isin StoreB primeZ[Ui h] for c = c1 and

c = c2 in case c2 is a wrapping key By definition of thereal experiment it performs the same substitutions in casec1 6isin Kcor so the same argument can be applied In casethat c1 isin K or c2 isin K the substitution performed is theidentity as key[c] = c for c isin Kcor K Therefore in thiscase the same output is produced in both F

implKWKM and

[πFCΠImpl AD Z]

Therefore the output is equally distributed in all threecases assuming that sc was true for the previous stepsc and pc hold trivially

h) Let m=ltunwraph1wa2F2idgt In [πFCΠImpl AD Z]if policy and Store allow i e 〈F1 a1 c1〉 isin Storeπ(Ui h1)then STi writes 〈F2 a2 unwrap〈F2a2id〉(c1 w)〉 at a freshplace [Ui h] in Storeπ unless unwrap returns perp on this in-put

FimplKWKM chooses Ui and a new h exactly the same way

By sc we have with equal probability that 〈F1 a1 c1〉 isinStoreB prime

Z(Ui h1) Since F1 = KW we will use c1 for the actual

value in BZrsquos store before substitution i e given c1 c1 issuch that k(c1) = c1

bull If c1 isin Kcor and c1 6isin K we have that c1 = c1 and thatkey[c1] = c1 (only in step unwrap a key that is not inK can be added to the store) Hence FimplKW

KM writes〈F2 a2 unwrap〈F2a2id〉(k(c1) w)〉

bull If c1 isin Kcor and c1 isin K k(c1) = c1 Since a key in Kcor

but not K must have been added using the corruptionprocedure we have that key[c1] = c1 = k(c1) ThusFimplKWKM writes 〈F2 a2 unwrap〈F2a2id〉(k(c1) w)〉

bull If c1 6isin Kcor and w was recorded earlier inspection ofFimplKWKM shows that encs is written to only at the wrap

step which implies that w = wrap〈F2a2id〉(k(c1) c2)

for some c2 From the correctness of the scheme weconclude that 〈F2 a2 c2 = unwrap〈F2a2id〉(k(c1) w)〉

is written to this position

bull If c1 6isin Kcor and w is not recorded earlier by defini-tion of DEC 〈F2 a2 unwrap〈F2a2id〉(k(c1) w)〉 is writ-

ten (Same argument as in the first case follows fromsc)

i) Let m = 〈attr_change h a prime〉 The same code is executedin both Expwrap

KWB primeZ

and [πFCΠImpl AD Z] thus pc scand oc hold trivially

j) Let m = 〈C publicm〉 The same code is executed in bothExpwrap

KWB primeZ

and [πFCΠImpl AD Z] thus pc sc and ochold trivially

3 Z sends a message to Uext isin Uext

Both FimplKWKM and Uext in [πFCΠImpl AD Z] only accept mes-

sages of the form 〈C publicm〉 for C isin Cipub Both perform thesame computations thus pc sc and oc hold trivially

4 Z sends a message to ltadvgt

Both AD and Sim ignore messages that are no instruction Sowe can assume that Z instructs the adversary to send a messageto some party

a) Assume Z instructs ltadvgt to send a message to a corruptedparty namely

i Ui isin U Ui can only be addressed by the adversary ifit was corrupted before as otherwise it has never senta message to the adversary Note that the code runby Ui in [πFCΠImpl AD Z] as well as in Expwrap

KWB primeZ

does not depend on any internal state Ui can onlytalk to the environment the adversary (Sim acts likeAD in this case) and it can call Fsetup which Sim hasto simulate in Expwrap

KWB primeZ

Sim is described above andreceives all the information necessary to simulate itthat is 〈readybull P〉 when a protocol party in Ucup ST re-ceives 〈ready〉 from the environment 〈finish_setupbull〉when a protocol party in U receives 〈ready〉 from theenvironment and all messages that FimplKW

KM sends tothe corrupted UU (and Fsetup would need to relay)Thus if pc holds in the previous step the invariantis preserved in case that the message is 〈ready Ui〉 or〈finish_setup〉 A message of form 〈send 〉 is ig-nored by Fsetup and Sim so the invariant is triviallypreserved here The communication relayed in thesteps relay_receive and relay_send in Fsetup is simu-lated as described above and thus falls back to case 2

ii Uexti isin Uext Like in the previous case only that Fsetup

ignores messages from Uexti which Sim simulates cor-

rectly

iii other parties cannot become corrupted

b) Assume Z instructs ltadvgt to send a message to a party thatcannot be corrupted but that addressed ltadvgt before i eST isin ST or Fsetup Since both ST and Fsetup are specifiedto ignore messages in this case Sim can simply mask theirpresence by reacting like ST or Fsetup react upon receptionof an unexpected message and answer with perp

We conclude that the invariant is preserved for an arbitrary numberof steps Since output consistency implies that Z has an identical viewthe distribution of Zrsquos output is the same in both games Thus

Pr[blarr Exec[πFCΠImpl AD Z](η) b = 1] =

Pr[b larr ExpwrapKWB prime

Z(η) b = 1]

and therefore

|Pr[blarr Exec[πFCΠImpl AD Z](η) b = 1]

minus Pr[blarr Exec[Fimpl

KM Sim Z](η) b = 1]|

= |Pr[blarr ExpwrapfakeKWBZ

(η) b = 1]

minus Pr[blarr ExpwrapKWB prime

Z(η) b = 1]|

gt |Pr[blarr ExpwrapfakeKWBZ

(η) b = 1]

minus Pr[blarr ExpwrapKWBZ

(η) b = 1]|minus ǫ(η)

where ǫ is negligible in η This contradicts the indistinguishabilityof Exec[Fimpl

KM Sim Z] and Exec[πFCΠImpl AD Z] and thus concludesthe proof

B I B L I O G R A P H Y

[1] Martiacuten Abadi and Veacuteronique Cortier lsquoDeciding Knowledge inSecurity Protocols Under Equational Theoriesrsquo In Automata

Languages and Programming (2004) pp 46ndash58

[2] Martiacuten Abadi and Ceacutedric Fournet lsquoMobile values new namesand secure communicationrsquo In Principles of Programming Lan-

guages ACM 2001 pp 104ndash115

[3] Ross J Anderson Security engineering - a guide to building de-

pendable distributed systems Wiley 2001

[4] Ross J Anderson and Markus G Kuhn lsquoLow Cost Attacks onTamper Resistant Devicesrsquo In International Workshop on Secu-

rity Protocols Springer 1998 pp 125ndash136

[5] Myrto Arapinis Eike Ritter and Mark Dermot RyanlsquoStatVerif Verification of Stateful Processesrsquo In Computer

Security Foundations Symposium IEEE Computer Society 2011pp 33ndash47

[6] A Armando D Basin Y Boichut Y Chevalier L CompagnaJ Cuellar P Hankes Drielsma P C Heaacutem O KouchnarenkoJ Mantovani S Moumldersheim D von Oheimb M Rusinow-itch J Santiago M Turuani L Viganograve and L Vigneron lsquoTheAVISPA tool for the automated validation of internet secu-rity protocols and applicationsrsquo In Computer Aided VerificationSpringer 2005 pp 281ndash285

[7] Alessandro Armando Roberto Carbone Luca CompagnaJorge Cuellar and Llanos Tobarra Abad lsquoFormal Analysisof SAML 20 Web Browser Single Sign-On Breaking theSAML-based Single Sign-On for Google Appsrsquo In Workshop

on Formal Methods in Security Engineering ACM 2008pp 1ndash10

[8] Michael Backes and Dennis Hofheinz lsquoHow to Break and Re-pair a Universally Composable Signature Functionalityrsquo In In-

formation Security (2004) pp 61ndash72

[9] Ian Batten Shiwei Xu and Mark Ryan lsquoDynamic measure-ment and protected execution model and analysisrsquo In Trust-

worthy Global Computing To appear Spinger 2013

[10] Mihir Bellare Anand Desai E Jokipii and Phillip RogawaylsquoA Concrete Security Treatment of Symmetric Encryptionrsquo InSymposium on Foundations of Computer Science IEEE ComputerSociety 1997 pp 394ndash403

266 Bibliography

[11] Stefano Bistarelli Iliano Cervesato Gabriele Lenzini andFabio Martinelli lsquoRelating multiset rewriting and processalgebras for security protocol analysisrsquo In Journal of Computer

Security 1 (2005) pp 3ndash47

[12] Fredrik Bjoumlrck Security DJ Blog Increased security for Yubikey2009 url httpwebarchiveorgweb20100725005817httpsecuritydjp=154

[13] Fredrik Bjoumlrck Security DJ Blog Yubikey Security Weaknesses2009 url httpwebarchiveorgweb20100203110742httpsecuritydjp=4

[14] Bruno Blanchet lsquoAn Efficient Cryptographic Protocol VerifierBased on Prolog Rulesrsquo In Computer Security Foundations Work-

shop IEEE Computer Society 2001 pp 82ndash96

[15] Bruno Blanchet Martiacuten Abadi and Ceacutedric FournetlsquoAutomated Verification of Selected Equivalences for SecurityProtocolsrsquo In Journal of Logic and Algebraic Programming 1

(2008) pp 3ndash51

[16] Bruno Blanchet and Miriam Paiola lsquoAutomatic Verification ofProtocols with Lists of Unbounded Length (long version)rsquo toappear at CCSrsquo13 2013 url httpssitesgooglecomsiteccs2013submission

[17] M Bond and R Anderson lsquoAPI level attacks on embeddedsystemsrsquo In IEEE Computer Magazine (2001) pp 67ndash75

[18] Mike Bond and Piotr Zielinski Decimalisation table attacks for

PIN cracking Tech rep University of Cambridge ComputerLaboratory 2003

[19] Joseph Bonneau Cormac Herley Paul C van Oorschot andFrank Stajano The quest to replace passwords a framework for

comparative evaluation of Web authentication schemes Tech repUCAM-CL-TR-817 University of Cambridge Computer Lab-oratory 2012 url httpwwwclcamacuktechreportsUCAM-CL-TR-817pdf

[20] Matteo Bortolozzo Matteo Centenaro Riccardo Focardi andGraham Steel lsquoAttacking and Fixing PKCS11 Security To-kensrsquo In Computer and Communications Security ACM 2010pp 260ndash269

[21] C Cachin and N Chandran lsquoA Secure Cryptographic TokenInterfacersquo In Computer Security Foundations Symposium IEEEComputer Society 2009 pp 141ndash153

[22] Ran Canetti lsquoUniversally Composable Security A NewParadigm for Cryptographic Protocolsrsquo In Foundations of

Computer Science IEEE Computer Society 2001 pp 136ndash145

Bibliography 267

[23] Ran Canetti lsquoUniversally Composable Signature Certificationand Authenticationrsquo In Computer Security Foundations Work-

[24] Ran Canetti and Tal Rabin lsquoUniversal Composition with JointStatersquo In Advances in Cryptology Springer 2003 pp 265ndash281

[25] CCA Basic Services Reference and Guide IBM 2006 url httpwww-03ibmcomsecuritycryptocardspdfsbs327pdf

[26] Vincent Cheval and Bruno Blanchet lsquoProving More Observa-tional Equivalences with ProVerifrsquo In Principles of Security and

Trust Springer 2013 pp 226ndash246

[27] Jolyon Clulow lsquoOn the Security of PKCS11rsquo In International

Worshop on Cryptographic Hardware and Embedded SystemsSpringer 2003 pp 411ndash425

[28] Irving M Copi Introduction to logic Macmillan 1982

[29] V Cortier G Keighren and G Steel lsquoAutomatic Analysisof the Security of XOR-based Key Management Schemesrsquo InTools and Algorithms for the Construction and Analysis of Systems2007 pp 538ndash552

[30] Veacuteronique Cortier and Graham Steel lsquoA generic security APIfor symmetric key management on cryptographic devicesrsquo InEuropean Symposium on Research in Computer Security Springer2009 pp 605ndash620

[31] Veacuteronique Cortier Graham Steel and Cyrille Wiedling lsquoRe-voke and let live a secure key revocation api for cryptographicdevicesrsquo In Computer and communications security ACM 2012pp 918ndash928

[32] Marion Daubignard David Lubicz and Graham Steel A Se-

cure Key Management Interface with Asymmetric CryptographyTech rep 2013 url httphalinriafrhal-00805987

[33] Steacutephanie Delaune Steve Kremer Mark D Ryan and GrahamSteel lsquoA Formal Analysis of Authentication in the TPMrsquo InFormal Aspects in Security and Trust Vol 6561 Springer 2010pp 111ndash125 url httpwwwlsvens-cachanfrPublisPAPERSPDFDKRS-fast10pdf

[34] Steacutephanie Delaune Steve Kremer Mark D Ryan and GrahamSteel lsquoA formal analysis of authentication in the TPMrsquo In For-

mal Aspects in Security and Trust Springer 2010 pp 111ndash125

[35] Steacutephanie Delaune Steve Kremer Mark D Ryan and GrahamSteel lsquoFormal analysis of protocols based on TPM state regis-tersrsquo In Computer Security Foundations Symposium IEEE Com-puter Society 2011 pp 66ndash82

268 Bibliography

[36] Steacutephanie Delaune Steve Kremer and Graham Steel lsquoFormalAnalysis of PKCS11 and Proprietary Extensionsrsquo In Journal

of Computer Security 6 (2010) pp 1211ndash1245

[37] G Denker J Meseguer and C Talcott lsquoProtocol Specificationand Analysis in Maudersquo In Workshop on Formal Methods and

Security Protocols Springer 1998

[38] Shaddin F Doghmi Joshua D Guttman and F Javier ThayerlsquoSearching for Shapes in Cryptographic Protocolsrsquo In Tools

and Algorithms for the Construction and Analysis of SystemsThe Cryptographic Protocol Shapes Analyzer is available athttphackagehaskellorgpackagecpsa Springer 2007pp 523ndash537

[39] Danny Dolev and Andrew Chi-Chih Yao lsquoOn the security ofpublic key protocolsrsquo In Transactions on Information Theory 2

(1983) pp 198ndash207

[40] N Durgin P Lincoln J Mitchell and A Scedrov lsquoUndecid-ability of Bounded Security Protocolsrsquo In Workshop on Formal

Methods and Security Protocols IEEE Computer Society 1999

[41] Santiago Escobar Catherine Meadows and Joseacute MeseguerlsquoMaude-NPA Cryptographic Protocol Analysis ModuloEquational Propertiesrsquo In Foundations of Security Analysis and

Design Vol 5705 Springer 2009 pp 1ndash50

[42] Eurosmart Eurosmart General Assembly Confirms Strong GrowthAccessed Fr 13 Sep 2013 145139 IST 2013 url httpwwweurosmartcomindexphppublicationsmarket-overview

[43] FIPS-140-2 Security Requirements for Cryptographic Modules2004 url httpwwwnistgovitluploadfips1402pdf

[44] Sibylle B Froumlschle and Nils Sommer lsquoReasoning with Past toProve PKCS11 Keys Securersquo In Formal Aspects in Security and

Trust Vol 6561 Springer 2010 pp 96ndash110

[45] Sibylle Froumlschle and Graham Steel lsquoAnalysing PKCS11 KeyManagement APIs with Unbounded Fresh Datarsquo In Joint

Workshop on Automated Reasoning for Security Protocol Analysis

and Issues in the Theory of Security Springer 2009 pp 92ndash106

[46] Juan A Garay Markus Jakobsson and Philip D MacKenzielsquoAbuse-Free Optimistic Contract Signingrsquo In Advances in Cryp-

tology Springer 1999 pp 449ndash466

[47] Joshua D Guttman lsquoState and Progress in Strand Spaces Prov-ing Fair Exchangersquo In Journal of Automated Reasoning 2 (2012)pp 159ndash195

Bibliography 269

[48] Thomas Habets YubiHSM login helper program Accessed Wed18 Sep 2013 150742 CEST 2011 url httpcodegooglecompyhsmpam

[49] Jonathan Herzog lsquoApplying Protocol Analysis to Security De-vice Interfacesrsquo In Security and Privacy 4 (2006) pp 84ndash87

[50] Dennis Hofheinz Possibility and impossibility results for selective

decommitments Cryptology ePrint Archive 2008 url http

eprintiacrorg

[51] Dennis Hofheinz and Victor Shoup GNUC A New Universal

Composability Framework Cryptology ePrint Archive 2011 urlhttpeprintiacrorg

[52] ITU Telecommunication Development Bureau 68 billion

mobile-cellular subscriptions Accessed Fr 13 Sep 2013

150838 IST 2013 url http www itu int en ITU -

DStatisticsDocumentsfactsICTFactsFigures2013pdf

[53] Horace William Brindley Joseph An Introduction to LogicClarendon Press 1916

[54] George Hayward Joyce Principles of logic Green 1949

[55] Kamikaze28 et al Specification of the Yubikey operation in the

Yubico wiki 2012 url httpwikiyubicocomwikiindexphpYubikey

[56] D Kaminsky On The RSA SecurID Compromise 2011 urlhttpdankaminskycom20110609securid

[58] Steve Kremer Graham Steel and Bogdan Warinschi lsquoSecurityfor Key Management Interfacesrsquo In Computer Security Founda-

tions Symposium IEEE Computer Society 2011 pp 66ndash82

[59] Robert Kuumlnnemann and Graham Steel Source files and proofs for

the analysis of the Yubikey protocol 2013 url httpwwwlsvens-cachanfr~kunnemanyubikeyanalysisyktargz

[61] Ralf Kuumlsters and Max Tuengerthal lsquoIdeal Key Derivation andEncryption in Simulation-Based Securityrsquo In Topics in Cryptol-

ogy Springer 2011 pp 161ndash179

[62] Ralf Kuumlsters and Max Tuengerthal lsquoJoint State Theorems forPublic-Key Encryption and Digitial Signature Functionalitieswith Local Computationrsquo In Computer Security Foundations

Symposium IEEE Computer Society 2008 pp 270ndash284

270 Bibliography

[63] Ralf Kuumlsters and Max Tuengerthal The IITM Model a

Simple and Expressive Model for Universal ComposabilityTech rep 2013025 Cryptology ePrint Archive 2013 urlhttpeprintiacrorg

[64] D Longley and S Rigby lsquoAn Automatic Search for SecurityFlaws in Key Management Schemesrsquo In Computers amp Security

1 (1992) pp 75ndash89

[65] Gavin Lowe lsquoAn attack on the Needham-Schroeder public-key authentication protocolrsquo In Information Processing Letters

3 (1995) pp 131ndash133

[66] Gavin Lowe lsquoBreaking and fixing the Needham-Schroederpublic-key protocol using FDRrsquo In Tools and Algorithms

for the Construction and Analysis of Systems Springer 1996pp 147ndash166

[67] Ueli Maurer and Renato Renner lsquoAbstract Cryptographyrsquo InInnovations in Computer Science Tsinghua University Press2011 pp 1ndash21

[68] Simon Meier Contract Signing Protocol (Example 2 from [5])Accessed Tue 17 Sep 2013 142806 CEST 2012 url https github com tamarin - prover tamarin - prover blob

develop data examples related _ work StatVerif _ ARR _

CSF11StatVerif_GM_Contract_Signingspthy

[69] Simon Meier lsquoFormal Analysis of Key-Exchange Protocolsand Physical Protocolsrsquo PhD thesis ETH Zuumlrich 2013

[70] Simon Meier Simple security device (Example 1 from [5])available in the example directory of the tamarindistribution Accessed Tue 17 Sep 2013 143132 CEST2012 url httpsgithubcomtamarin-provertamarin-prover blob develop data examples related _ work

StatVerif_ARR_CSF11StatVerif_Security_Devicespthy

[71] Simon Meier The keyserver example from [74] Ac-cessed Tue 17 Sep 2013 142353 CEST 2012 urlhttps github com tamarin - prover tamarin -

proverblobdevelopdataexamplesrelated_workAIF_

Moedersheim_CCS10Keyserverspthy

[72] Simon Meier The TESLA protocol scheme 1 and 2 available inthe example directory of the tamarin distribution AccessedThu 19 Sep 2013 143652 CEST 2012 url httpsgithubcomtamarin-provertamarin-proverblobdevelopdata

examplesloopsTESLA_Scheme[12]spthy

[73] Simon Meier Cas J F Cremers and David A Basin lsquoStrongInvariants for the Efficient Construction of Machine-CheckedProtocol Security Proofsrsquo In Computer and Communications Se-

curity ACM 2010 pp 231ndash245

Bibliography 271

[74] Sebastian Moumldersheim lsquoAbstraction by set-membership veri-fying security protocols and web services with databasesrsquo InComputer and Communications Security ACM 2010 pp 351ndash360

[75] The Canadian Press ndash OBJ PCs still more popular than tablets

smarpthones Deloitte Accessed Fr 13 Sep 2013 154446 IST2013 url httpwwwobjcaCanada20-20World2013-01- 15article- 3156753PCs- still- more- popular- than-

tablets-smarpthones-Deloitte1

[76] David Oswald Bastian Richter and Christof PaarlsquoSide-Channel Attacks on the Yubikey 2 One-Time PasswordGeneratorrsquo In Research in Attacks Intrusions and DefensesSpringer 2013

[77] Catuscia Palamidessi lsquoComparing the Expressive Power of theSynchronous and the Asynchronous pi-calculirsquo Anglais InMathematical Structures in Computer Science 5 (2003) pp 685ndash719 url httphalinriafrinria-00201104

[78] Adrian Perrig J D Tygar Dawn Song and Ran Canetti lsquoEf-ficient Authentication and Signing of Multicast Streams overLossy Channelsrsquo In Security and Privacy IEEE Computer Soci-ety 2000 pp 56ndash73

[79] Alfredo Pironti Davide Pozza and Riccardo Sisto lsquoFormally-Based Semi-Automatic Implementation of an Open SecurityProtocolrsquo In Journal of Systems and Software (2012) pp 835ndash849

[80] Alfredo Pironti and Riccardo Sisto lsquoProvably CorrectJava Implementations of Spi Calculus Security ProtocolsSpecificationsrsquo In Computers amp Security (2010) pp 302ndash314

[81] PKCS 11 Cryptographic Token Interface Standard RSA SecurityInc 2004

[82] PKCS11 v220 Cryptographic Token Interface Standard Available

from httpwwwrsacomrsalabs 2004

[83] AVISPA project Deliverable 23 The Intermediate Format 2003url httpwwwavispa-projectorg

[84] R Kuumlsters lsquoSimulation-Based Security with Inexhaustible In-teractive Turing Machinesrsquo In Computer Security Foundations

Workshop IEEE Computer Society 2006 pp 309ndash320

[85] R Kuumlsters and T Truderung lsquoReducing Protocol Analysiswith XOR to the XOR-free Case in the Horn Theory BasedApproachrsquo In Journal of Automated Reasoning 3 (2011)pp 325ndash352

272 Bibliography

[86] P Rogaway and T Shrimpton Deterministic Authenticated En-

cryption A Provable-Security Treatment of the Keywrap Problem2006

[87] Mark Ryan Introduction to the TPM 12 Tech rep Universityof Birmingham 2009

[88] Benedikt Schmidt lsquoFormal Analysis of Key-Exchange Proto-cols and Physical Protocolsrsquo PhD thesis ETH Zuumlrich 2012

[89] Benedikt Schmidt Simon Meier Cas Cremers andDavid Basin lsquoAutomated Analysis of Diffie-HellmanProtocols and Advanced Security Propertiesrsquo In Computer

[90] Benedikt Schmidt Simon Meier Cas Cremers and DavidBasin lsquoThe TAMARIN Prover for the Symbolic Analysis ofSecurity Protocolsrsquo In Computer Aided Verification Springer2013 pp 696ndash701

[91] D Shaw The OpenPGP HTTP Keyserver Protocol (HKP)Internet-Draft Internet Engineering Task Force 2003 urlhttptoolsietforghtmldraft-shaw-openpgp-hkp-00

[92] F Javier Thayer Jonathan C Herzog and Joshua D GuttmanlsquoStrand Spaces Why is a Security Protocol Correctrsquo In Secu-

rity and Privacy IEEE Computer Society 1998 pp 160ndash171

[93] The YubiKey Manual - Usage configuration and introduction of ba-

sic concepts (Version 22) Yubico AB 2010 url httpwwwyubicocomdocumentation

[94] The yubikey-val-server-php project Validation Protocol Version

20 2011 url httpcodegooglecompyubikey- val-server-phpwikiValidationProtocolV20

[95] Trusted Platform Module Library Family 20 Commit-tee Draft Trusted Computing Group 2013 urlhttpwwwtrustedcomputinggrouporgresourcestpm_

library_specification

[96] Loredana Vamanu lsquoFormal Analysis of Yubikeyrsquo MasterrsquosThesis Eacutecole normale supeacuterieure de Cachan 2011 url httpnethzch~lvamanudownloadYubiKeyAnalysispdf

[97] Christoph Weidenbach lsquoCombining Superposition Sorts andSplittingrsquo In Handbook of Automated Reasoning (2001) pp 1965ndash2013

[98] Christoph Weidenbach lsquoTowards an Automatic Analysis of Se-curity Protocols in First-Order Logicrsquo In Automated DeductionVol 1632 Springer 1999 pp 314ndash328

Bibliography 273

[99] D Whiting R Housley and N Ferguson Counter with CBC-

MAC (CCM) RFC 3610 (Informational) Internet EngineeringTask Force 2003 url httpwwwietforgrfcrfc3610txt

[100] Yubicloud Validation Service - (Version 11) Yubico AB 2012 urlhttpwwwyubicocomdocumentation

[101] Yubico AB Department of Defence Moving from legacy authen-

tication to Yubico technology and best practice security processesAccessed Wed 17 Jul 2013 112048 CEST 2013 url httpswwwyubicocomaboutreference-customersdepartment-

defence

[102] Yubico AB Yubico customer list Accessed Wed 17 Jul 2013

114050 CEST 2013 url httpswwwyubicocomaboutreference-customers

[103] Yubico AB YubiKey NEO Accessed Wed 17 Jul 2013 132532

CEST 2013 url www yubico com products yubikey -

hardwareyubikey-neo

[104] Yubico AB YubiKey Security Evaluation Discussion of security

properties and best practices v20 2009 url httpstaticyubicocomvaruploadspdfsSecurity_Evaluation_2009-

09-09pdf

[105] Yubico Inc YubiHSM 10 security advisory 2012-01 2012url http static yubico com var uploads pdfs

SecurityAdvisory202012-02-13pdf

[106] Yubico YubiHSM - Cryptographic Hardware Security Module (Ver-

sion 10) Yubico AB 2011 url httpwwwyubicocomdocumentation

[107] YubiKey Authentication Module Design Guide and Best Practices

(Version 10) Yubico AB 2011 url httpwwwyubicocomdocumentation

Dedication

Abstract

Reacutesumeacute

Publications

Acknowledgments

Contents

List of Figures

List of Tables

Listings

Acronyms

Introduction

1 Introduction

11 Cryptographic security APIs

12 security APIs and network protocols

13 security APIs in context of arbitrary protocols

Analysis of stateful protocols in the symbolic model

2 Preliminaries

21 Terms and equational theories

22 Facts

23 Substitutions

24 Sets sequences and multisets

3 A survey on existing methods

31 Running Examples

32 StatVerif



33 Abstraction by set-membership



34 Why Horn clause approaches are unsuitable

35 Other Approaches

36 The tamarin-prover




4 Analysis of the Yubikey protocol and the YubiHSM

41 Yubikey and Yubikey Authentication Protocol



42 The YubiHSM




43 Evaluation




434 Methodology

435 Future work

5 A process calculus with state

51 Related work

52 A cryptographic pi calculus with explicit state


522 Semantics

523 Discussion

53 A translation from processes to multiset rewrite rules



533 Discussion

54 Correctness of the translation


542 Inclusion I

543 Inclusion II

55 Case studies



553 Yubikey



When is a Security API ``secure

6 When is a security API secure

61 Criteria for persuasive definitions

62 Characteristics of a ``secure security API

63 Composability

64 Overview

65 Related work

7 Introduction to GNUC

71 Preliminaries

72 Machines and interaction

73 Defining security via ideal functionalities

8 Key-management functionality and refer implementation

81 Design Rationals

811 Policies

812 Sharing Secrets

813 Secure Setup


82 Key-usage (ku) functionalities

821 Credentials


83 Policies

84 FKM and the reference implementation


842 Setup phase

843 Executing private commands

844 Creating keys



847 Corruption




9 Analysis of the key-management functionality

91 Properties

92 Limitations

93 Discussion

10 Proof of emulation

11 A simple case study

111 Realizing FKM for a static key-hierarchy

112 An example implementation of the authenticated channel functionality

Conclusion

12 Conclusion and Perspectives

121 Analysis of protocols using security APIs

122 Analysis of security APIs

Appendix

A Listings for Part i

A1 Listings for Chapter 3



B Proofs for Part i

B1 Correctness of tamarins solution procedure for translated rules

B2 Proofs for Section 54



C Initialisation and Setup in FKM

C1 Initialisation phase

C2 Handling of the setup phase in FKM and the generic implementation

C3 Setup assumptions for the implementation

D The complete proof of emulation

Bibliography

ENSC-201X-NYYY

T H Egrave S E D E D O C T O R AT D E Lrsquo Eacute C O L E N O R M A L ES U P Eacute R I E U R E D E C A C H A N

Preacutesenteacutee par

Monsieur Robert Kuumlnnemann

Pour obtenir le grade de

D O C T E U R D E Lrsquo Eacute C O L E N O R M A L E S U P Eacute R I E U R ED E C A C H A N

Domaine informatique

Sujet de la thegravese

F O U N D AT I O N S F O R A N A LY Z I N G S E C U R I T Y A P I SI N T H E S Y M B O L I C A N D C O M P U TAT I O N A L M O D E L

Thegravese preacutesenteacutee et soutenue agrave Cachan le 07012014 devant le jurycomposeacute de

Ralf Kuumlsters Professeur Rapporteur

Matteo Maffei Professeur Rapporteur

Hubert Comon-Lundh Professeur Examinateur

Joshua Guttman Professeur Examinateur

Thomas Jensen Directeur de recherche Examinateur

David Pointcheval Directeur de recherche Examinateur

Steve Kremer Directeur de recherche Directeur de thegravese

Graham Steel Chargeacute de recherche Directeur de thegravese

Laboratoire Speacutecification et VeacuterificationENS de Cachan UMR 8643 du CNRS61 avenue du Preacutesident Wilson94235 CACHAN Cedex France

robert kuumlnnemann

October 2013

Fuumlr meine Eltern

A B S T R A C T

C O N T E N T S

Introduction 1

1 introduction 3

model 15

2 preliminaries 17

22 Facts 18

23 Substitutions 18

32 StatVerif 24

42 The YubiHSM 50

43 Evaluation 55

xvi contents

434 Methodology 58

435 Future work 59

51 Related work 62

522 Semantics 66

523 Discussion 69

533 Discussion 78

542 Inclusion I 89

543 Inclusion II 93

55 Case studies 94

553 Yubikey 96

64 Overview 103

65 Related work 103

811 Policies 112

821 Credentials 115

83 Policies 116

contents xvii

842 Setup phase 120

847 Corruption 124

91 Properties 129

92 Limitations 131

93 Discussion 133

Conclusion 149

Appendix 159

bibliography 265

Figure 9 Syntax 63

List of Tables xix

L I S T I N G S

and wrap 125

xx Listings

A C R O N Y M S

xxii acronyms

GNUC GNUC is Not UC

4 introduction

introduction 5

6 introduction

8 introduction

decrypt

10 introduction

12 introduction

Part I

18 preliminaries

22 facts

23 substitutions

31 running examples

〈MN〉 = (terms)

| x y z (variables)

| a b c s (names)

| 0 (nil)

| P (replication)

| out(MN)P (output)

| in(MN)P (input)

| s =M P (assign)

32 statverif

32 statverif 25

let device =

out(cpk(k)) |

if y = init then

process

Generate a key

SDecrypt

Security goal

Policy B

Policy C

decryption

Security goal

35 other approaches

execmsr(R) =

emptyA1minusrarrR

AnminusrarrR Sn |

tracesmsr(R) =

and emptyA1=rArrR

minusrarrlowastR

AminusrarrR

(tr θ) perp never

we have that

Session Counter

Timestamp

Token Counter

Pseudo-random

CRC-16 value

Fr(k)Fr(pid)Fr(sid)

SharedKey(pid k)

Y_counter(pid tc)

Fr(nonce)

Server(pid sid tc)

andnot(i = j))

42 the yubihsm

42 the yubihsm 51

|data|blocksize

AES(k counteri)

AES AES AES

data1oplus

data2oplus

42 the yubihsm 53

xor(a a) = 0

[Out(aead)]

ks = keystream(khN)

43 evaluation 55

S_Counter(pid tc)

43 evaluation

43 evaluation 57

434 Methodology

43 evaluation 59

In(y) In(S(y))

Smaller(x y)

435 Future work

51 related work

with explicit state

| p isin PN

| n isin FN

〈PQ〉 = 0

| P | Q

Figure 9 Syntax

x isin D(σ)

522 Semantics

x1 isin D(σ)

x2 isin D(σ)

νnσ ⊢ k2

of traces of P as

tracespi(P) =

SMS1 P1 σ1 L1)

F2=rArr

Fn=rArr (En Sn S

MSn Pn σnLn)

=P prime

empty empty)

empty) where

Standard operations

if a prime is fresh

primeτ

where S prime(x) =

S(x) if x 6=E M

perp otherwise

if M 6isinEL

523 Discussion

P|Q = P|Q

if t1 = t2 then P

lookup M as x

αP = αP

unlock tP = perp

au(P|Q t l) = perp

au(P t l) = perp

au(if t1 = t2 then

P else Q t l)=

else au(Q t l)

au(lookup M as x

in P else Q t l)=

lookup M as x

au(0 t l) = 0

Jif M = N then P

else Qp xK

Jlookup M as v

in P else Qp xK

[state111111(k h)]

state_0111111( k h )

Out( h ) state_01111111( k h )

state_011111( k h )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

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 )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

state_0111( k h )

533 Discussion

forall φ for

P primeex =P prime

5333 Axioms

Tr ⋆ JϕK⋆

hide(F middot tr) =

prime) ϕ

andforallθexistθ

prime) ϕ

prime) fi Hence we

primeallows us to

Proof of Theorem 1

tracespi(P) ⋆ ϕ

(by Proposition 1)

σ = t1x1 tm xm and

We have that

542 Inclusion I

as follows

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

Jif M = N then P

else Qp xK=pt

Jlookup M as v

in P else Qp xK=pt

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

543 Inclusion II

(P|pτ)ρ =E Q

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

55 case studies

55 case studies 95

553 Yubikey

55 case studies 97

in Section A3

Part II

63 composability

64 overview 103

64 overview

65 related work

71 preliminaries

is negligible in η

name [condition] P

send ltdonegt to P

81 design rationals

811 Policies

812 Sharing Secrets

813 Secure Setup

821 Credentials

newit holds that

bull for all k Pr[

(1η)]

bull Pr[

(1η)]

isnegligible in η

83 policies

changetimesAtimesA

Fenc new 0

KW wrap 1 0

KW unwrap 1 0

Fenc enc 0

U1 Un Uext1 Uext

Fsetup

ST1 STn

U1 Un Uext1 Uext

bull Uext = Uext1 U

bull Room sub U

bull F = F1 Fl and

privi and public

1 Uextm = Uext who

842 Setup phase

hmgt from Fsetup

844 Creating keys

call F with ltnewgt

send lterrorgt to A

create h

corrupt c3

if c1 isin Kcor

if F2 =KW

create h2

key[c2]larr c2

key[c prime]larr c2

send lterrorgt to A

create h2

primekgt

847 Corruption

if F = KW

if C isin Cipub

public_command

if C isin Cipub

91 properties

92 limitations 131

92 limitations

93 discussion 133

93 discussion

93 discussion 135

functionality Fimpl

KM = FF1ImplF1

FlImplFl

new wrap and

FlImplFl

FF1ImplF1

FnImplFn

KM i e Fimpl

primem prime)

AwrapKWA(η) =

∣Pr[

FlImplFl

KM can

newwrap unwrap)

before-wrap

else if n = k

(c_) larr 0 1η

and implequal

σlarr sign(skm)

6= KW new 0

attr_change a a

(where a isinN)

send ltdonegt to P

send ltx σgt to A

ready-receiver

hlarr h

ready-sender

sk vklarr KG(1η)

done [send]

send ltdonegt to P

deliver[send]

if σ = σ

C O N C L U S I O N

Future work

A P P E N D I X

fun pair2

fun aenc3

fun pk1

4 free left

free right

free init

free c

private free sl

9 private free sr

let device =

19 out(c pk(k)) |

if y = init then

let user =

29 ν r

process

fun pair2

2 fun senc2

free c

free nil

free store

7 reduc

12 query attvskey

let create_proc =

read store as list

unlock

out(chandle)

let wrap_proc =

read store as list

unlock

27 in(outputk1)

in(outputk2)

if k1 = nil then 0

let fetch_key =

let list=cdr(x) in

if arg=car(h) then

out(outputcdr(h))

else if r=nil then

42 out(outputnil)

process

ν store

machine middot

5 Types

Secrets slsr

SKsk value

KMXYtoken untyped

10 Sets

Functions

public senc2 pair2

15 private inv1

iknows1 attack0

20 Rules

30 Init

decryption

Security goal

1 Problem wrapdec

Secrets slsr

SK value

6 KMXYt untyped

11 Functions

public senc2 pair2

private sl1 sr1

16 iknows1 attack0

decryption

Security goal

1 Problem Wrapdec

Token t one token

KM untyped

Functions

public senc2

private h1

iknows1 attack0

Generate a key

36 SDecrypt

Security goal

Policy 1

Policy 2

51 Policy 3

theory Yubikey

rule Yubikey_Plugin

[ Server(pidsidotc)

axiom smaller

exists-trace

or t2ltt1 or t1=t2)

same counter value

lemma no_replay

and not(i=j))

minusrarr t1ltt2

90 end

theory YubikeyHSM

functions

10 xor2 zero0

mac2 demac2

equations

computed

xor(xor(ab)a)=b

xor(xor(ab)b)=a

20 xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

demac(mac(mk)k)=m

rule isendHSM

rule irecvHSM

rule read_AEAD

[ S_AEAD(pidaead) ]

rule write_AEAD

rule HSMInit

HSM commands

minus[

]rarr[OutHSM(sc)]

Yubikey operations

rule BuyANewYubikey

YSM_AEAD_GENERATE

110 Out(~pid) ]

counter reset

rule Yubikey_Plugin

135 S_sid(pidsid) ]

axiom smaller

145 axiom onetime

150 exists-trace

the previous lemma

adversary

button press

otc2tc2)t2

or t2ltt1 or t1=t2)

induction

simplify

case case_1

210 next

case case_2

215 case case_2

case case_1

220 case case_2

case BuyANewYubikey

by sorry

230 qed

same counter value

lemma no_replay

and not(i=j))

255 and tc2=tc1+z

minusrarr t1ltt2

functions S1zero0

11 rule InitSucc

16 rule StepSucc

rule SimpleSmaller

[Succ(xy)]

rule BuyANewYubikey

(~pid)]

counter reset

axiom transitivity

exists-trace

induction

case empty_trace

116 next

simplify

rArr(last(t2)) or

(last(t1)) or

((t1 lt t2) and

(t2 lt t1) or

(t1 = t2)) or

(forall t1 t2 a b c

131 and

(not(last(t2))) and

(not(last(t1))) and

case case_1

((t1 lt t2) and

(t2 lt t1) or (t1 = t2) )

case case_1

case BuyANewYubikey

by sorry

156 by sorry

by sorry

161 qed

case case_2

166 case case_3

case case_4

171 next

case case_5

176 case case_2

by sorry

181 lemma no_replay

and not(i=j))

minusrarr t1ltt2

modelling)

functions S1zero0

11 xor2

mac2 demac2

16 xor(xor(ab)a)=b

xor(xor(ab)b)=a

xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

rule InitSucc

rule StepSucc

rule SimpleSmaller

36 [Succ(xy)]

rule isendHSM

rule irecvHSM

rule read_AEAD

Out(aead)]

rule write_AEAD

time in a trace

rule HSMInit

66 [Fr(~k) Fr(~kh)]

106 minus[

Yubikey operations

rule BuyANewYubikey

counter reset

156 in

relation is

build up

181 axiom onetime

LEMMAS

simplify

case BuyANewYubikey

~sidgt)

) 2i )

case BuyANewYubikey

case HSMInit

case BuyANewYubikey

SOLVED trace found

211 qed

case write_AEAD

216 by sorry

by sorry

221 next

by sorry

226 next

case csenc

by sorry

case irecvHSM

231 by sorry

lemmas)

the adversary

induction

case empty_trace

276 next

simplify

solve( S_AEAD( pid

mac(ltk2 sidgt k)gt

281 ) 2t2 )

by sorry

286 by sorry

case write_AEAD

) vk6 )

291 case irecv

case cxor

by sorry

296 next

by sorry

301 by sorry

306 end

14 | allow wrap

( in(lthcgt)

sdec(ck))

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

exists-trace

not a valid enc

and t3ltt1 )

54 end

26 if kp=k then

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

41 | Unwrap

if k1=k then

51 exists-trace

exists-trace

device or some

key leaked

( ν skA

9 out(pk(skA))

( in(pk(xB))

( ν skB

out(pk(skB))

exists-trace

lemma sanity2

exists-trace

lemma secrecy

theory Yubikey

8 let Yubikey=

13 out(pid)

( ( Plug

lock pid

unlock pid

) | ( ButtonPress

lock pid

ν npr

unlock pid

let Server=

lock pid

in(otc)

event InitStuff(pid

secretidktupleotc

event Login(pidktc)

unlock pid

(Server | Yubikey)

axiom smaller

exists-trace

typing lemmas

counter value

PressButton

113 end

theory Contract

2 begin

builtins signing

fakepcs4

equations

true()

fakepcs ()

true()

17 let Abort1 =

(lock ct

22 else

unlock ct

let Resolve2 =

Tamarin modelling

lock ct

42 else

unlock ct

let Resolve1 =

lock ct

67 unlock ct

let WitnessAbort =

event AbortCert(ct)

let HonestClient =

82 ν skA

out(pk(skA))

in (ltctxpkBgt)

out(sign(ctskA))

in(sigB)

92 else if not

0 Accept silently

102 ν skT

out(pk(skT))

HonestClient

117 Sanity checks

exists-trace

137 end

theory SetAbst

8 let Client=

Revoke key

ν ~nsk

out(~sk)

let Server=

ν ~sk

out(pk(~sk))

28 ( in(ltuserskgt)

| Revoke Key

1 theory SetAbst

let Client=

Revoke key

ν ~nsk

11 lock user

16 unlock user

event Revoked(~sk)

21 out(~sk)

let Server=

lock user

unlock user

out(pk(~sk))

( Revoke key

unlock user

exists-trace

and Revoked(sk) r)

5 let Device=(

out(pk(sk))

( lock s

in(req)

insert sreq

unlock s

lock s

let User=

exists-trace

50 exists-trace

lemma secrecy

60 end

translated rules

where JP [] []KD

if and only if

notαin orφ

(Definition of DHe)

DHenotαin orφ

insts )

notαin orφ

trace(ndg) ACC φ

primel) isin Si

σ = t1x1 tm xm and

We have that

QharrP S1 statep(t)

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

MSn Pn σnLn)

f(i) =

F2minusrarrJPK

νaQ cup Qaprimea

MSnminus1

R S for R = MDOut

F2minusrarrJPK

MSnminus1P

emptyF1minusrarrS1

lowast

lowastR S for R =

Ack(tNθ)]

pmiddot1 (t)

cup (vars(N)θ))

Fminusrarr

SMSnminus1P

Now suppose that

which simplifies to

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l1 t)

Lock(l prime t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l t)

n prime + 1

Unlock(l t)

Lock(l t)

Lock(l prime t)

n prime + 1

Unlock(l t)

aminusrarr

nminus1 =

SMSn = SMS

= Sf(n) Fres

and t isinM)

MDApplFresh

EnminusrarrJPK

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

n(1) ]) Since

n(1) ]

n(1) Then

j = S(1)j

semip (t) cup

p (t) We repeat

(1)n prime and call

the resulting trace

E(2)1minusrarrJPK

E(2)nminusrarrJPK S

(2)1 E

n(2) ]) and [E(2)1 E

n(2) ]

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

S(1) prime

S(1)t if t lt k

S(1)t+1 cup

statep(t)

if j+ 1 6 t lt i+ 1

S(1)t if i+ 1 6 t

E(3)1minusrarrJPK

E(3)nminusrarrJPK S

(3)1 E

n(3) ]) as

well as [E(3)1 E

n(3) ] α

E(4)1minusrarrJPK

E(4)nminusrarrJPK S

(4)1 E

n(4) ]) and [E(4)1

n(4) ] α

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

Since [E(4)1 E

(5)1 E

n(5) ]

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

in one step

n(5) then we

n(5)minus1 S(5)

(5)m prime

Q P S1 statep(t)

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

F2minusrarr

f(i) =

fp(i) if i isinNm

have that

Q2 cup Q1 Q2

Q1 | Q2 cup Q1 Q2

16j6nminus1

prime)

is S0E1minusrarrJPK

16j6nminus2

f(i) =

fp(i) if i isinNm

(by (6))

16j6nminus2

f(i) =

fp(i) if i isinNm

prime =

f(i) =

fp(i) if i isinNm

and Sn = Snminus1

cup Q2 and

Lock(u t)

Lock(nl t)

Unlock(nl t)

Lock(nl t)

Lock(u t)

Unlock(nl t)

a prime

prime) ) Fres

= Snminus1 Fres

= SMSn prime

= SMSn prime+1

ready [not ready]

sharebullh2gt to U2

to Fsetup

U isin U

13 from i=1 to n

= negl(η)

have FF1ImplF1

FnImplFn

FF1ImplF1

FpImplFp

KM as follows

FpImplFp

if F isin KWF1 Fp

4 key[c]larr c

9 key[c]larr k

if F isin F1 Fp

else if F = KW

call F with ltnewgt

6 else if F 6= KW

call F with ltCcmgt

1 public_command

if C isin Cipub

if F isin F1 Fp

6 else

if c1 isin Kcor

key[c2]=c2else

primegt

FlImplFl

setupgt message

FiImplFi

is negligible in η

(U2 hprime1) equiv

tminus1 (U1 h1)

(for some c) or

rArr corruptedMi|NP

FlImplFl

KM Sim Z]

to Fimpl

if F isin F1 Fl

else if F = KW

9 create Ki h

query NEW(Ki)

Klarr Kcup Ki

wrap[finish_setup]

7 else

4 if c1 isin Kcor

send lterrorgt to A

14 else

halt and output 0

3 else

if F isin KW

query k = CORR(c)

8 key[c]larr k

key[c]larr c

FimplKWKM Sim Z

FimplKWKM is F

5 if c1 isin Kcor

if c1 isin Kcor

send lterrorgt to A

exists in Fimpl

KM key[c] = c

implKWKM and F

case of Fimpl

implKWKM and F

ExpwrapfakeKWBZ

(η) = Exec[Fimpl

KM Sim Z](η)

implKWKM by

implKW

Z(η) b = 1]

Z(t) be the

implKWKM in Expwrap

KWB primeZ

implKWKM records

KWB primeZ

In ExpwrapKWB prime

Zwill set the ready

KWB primeZ

Z StoreB prime

Z(t minus 1)

Z(t) equals

KWB primeZ

in Storeπ

implKWKM and

[πFCΠImpl AD Z]

KWB primeZ

rectly

Z(η) b = 1]

and therefore

(η) b = 1]

Z(η) b = 1]|

(η) b = 1]

266 Bibliography

(2008) pp 3ndash51

Bibliography 267

268 Bibliography

(1983) pp 198ndash207

Bibliography 269

eprintiacrorg

270 Bibliography

1 (1992) pp 75ndash89

3 (1995) pp 131ndash133

Bibliography 271

272 Bibliography

Bibliography 273

defence

hardwareyubikey-neo

09-09pdf

Dedication

Abstract

Reacutesumeacute

Publications

Acknowledgments

Contents

List of Figures

List of Tables

Listings

Acronyms

Introduction

1 Introduction





2 Preliminaries


22 Facts

23 Substitutions



31 Running Examples

32 StatVerif







35 Other Approaches









42 The YubiHSM




43 Evaluation




434 Methodology

435 Future work


51 Related work



522 Semantics

523 Discussion




533 Discussion



542 Inclusion I

543 Inclusion II

55 Case studies



553 Yubikey







63 Composability

64 Overview

65 Related work


71 Preliminaries




81 Design Rationals

811 Policies

812 Sharing Secrets

813 Secure Setup



821 Credentials


83 Policies



842 Setup phase


844 Creating keys



847 Corruption





91 Properties

92 Limitations

93 Discussion





Conclusion




Appendix





B Proofs for Part i










Bibliography

robert kuumlnnemann

October 2013

Fuumlr meine Eltern

A B S T R A C T

C O N T E N T S

Introduction 1

1 introduction 3

model 15

2 preliminaries 17

22 Facts 18

23 Substitutions 18

32 StatVerif 24

42 The YubiHSM 50

43 Evaluation 55

xvi contents

434 Methodology 58

435 Future work 59

51 Related work 62

522 Semantics 66

523 Discussion 69

533 Discussion 78

542 Inclusion I 89

543 Inclusion II 93

55 Case studies 94

553 Yubikey 96

64 Overview 103

65 Related work 103

811 Policies 112

821 Credentials 115

83 Policies 116

contents xvii

842 Setup phase 120

847 Corruption 124

91 Properties 129

92 Limitations 131

93 Discussion 133

Conclusion 149

Appendix 159

bibliography 265

Figure 9 Syntax 63

List of Tables xix

L I S T I N G S

and wrap 125

xx Listings

A C R O N Y M S

xxii acronyms

GNUC GNUC is Not UC

4 introduction

introduction 5

6 introduction

8 introduction

decrypt

10 introduction

12 introduction

Part I

18 preliminaries

22 facts

23 substitutions

31 running examples

〈MN〉 = (terms)

| x y z (variables)

| a b c s (names)

| 0 (nil)

| P (replication)

| out(MN)P (output)

| in(MN)P (input)

| s =M P (assign)

32 statverif

32 statverif 25

let device =

out(cpk(k)) |

if y = init then

process

Generate a key

SDecrypt

Security goal

Policy B

Policy C

decryption

Security goal

35 other approaches

execmsr(R) =

emptyA1minusrarrR

AnminusrarrR Sn |

tracesmsr(R) =

and emptyA1=rArrR

minusrarrlowastR

AminusrarrR

(tr θ) perp never

we have that

Session Counter

Timestamp

Token Counter

Pseudo-random

CRC-16 value

Fr(k)Fr(pid)Fr(sid)

SharedKey(pid k)

Y_counter(pid tc)

Fr(nonce)

Server(pid sid tc)

andnot(i = j))

42 the yubihsm

42 the yubihsm 51

|data|blocksize

AES(k counteri)

AES AES AES

data1oplus

data2oplus

42 the yubihsm 53

xor(a a) = 0

[Out(aead)]

ks = keystream(khN)

43 evaluation 55

S_Counter(pid tc)

43 evaluation

43 evaluation 57

434 Methodology

43 evaluation 59

In(y) In(S(y))

Smaller(x y)

435 Future work

51 related work

with explicit state

| p isin PN

| n isin FN

〈PQ〉 = 0

| P | Q

Figure 9 Syntax

x isin D(σ)

522 Semantics

x1 isin D(σ)

x2 isin D(σ)

νnσ ⊢ k2

of traces of P as

tracespi(P) =

SMS1 P1 σ1 L1)

F2=rArr

Fn=rArr (En Sn S

MSn Pn σnLn)

=P prime

empty empty)

empty) where

Standard operations

if a prime is fresh

primeτ

where S prime(x) =

S(x) if x 6=E M

perp otherwise

if M 6isinEL

523 Discussion

P|Q = P|Q

if t1 = t2 then P

lookup M as x

αP = αP

unlock tP = perp

au(P|Q t l) = perp

au(P t l) = perp

au(if t1 = t2 then

P else Q t l)=

else au(Q t l)

au(lookup M as x

in P else Q t l)=

lookup M as x

au(0 t l) = 0

Jif M = N then P

else Qp xK

Jlookup M as v

in P else Qp xK

[state111111(k h)]

state_0111111( k h )

Out( h ) state_01111111( k h )

state_011111( k h )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

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 )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

state_0111( k h )

533 Discussion

forall φ for

P primeex =P prime

5333 Axioms

Tr ⋆ JϕK⋆

hide(F middot tr) =

prime) ϕ

andforallθexistθ

prime) ϕ

prime) fi Hence we

primeallows us to

Proof of Theorem 1

tracespi(P) ⋆ ϕ

(by Proposition 1)

σ = t1x1 tm xm and

We have that

542 Inclusion I

as follows

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

Jif M = N then P

else Qp xK=pt

Jlookup M as v

in P else Qp xK=pt

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

543 Inclusion II

(P|pτ)ρ =E Q

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

55 case studies

55 case studies 95

553 Yubikey

55 case studies 97

in Section A3

Part II

63 composability

64 overview 103

64 overview

65 related work

71 preliminaries

is negligible in η

name [condition] P

send ltdonegt to P

81 design rationals

811 Policies

812 Sharing Secrets

813 Secure Setup

821 Credentials

newit holds that

bull for all k Pr[

(1η)]

bull Pr[

(1η)]

isnegligible in η

83 policies

changetimesAtimesA

Fenc new 0

KW wrap 1 0

KW unwrap 1 0

Fenc enc 0

U1 Un Uext1 Uext

Fsetup

ST1 STn

U1 Un Uext1 Uext

bull Uext = Uext1 U

bull Room sub U

bull F = F1 Fl and

privi and public

1 Uextm = Uext who

842 Setup phase

hmgt from Fsetup

844 Creating keys

call F with ltnewgt

send lterrorgt to A

create h

corrupt c3

if c1 isin Kcor

if F2 =KW

create h2

key[c2]larr c2

key[c prime]larr c2

send lterrorgt to A

create h2

primekgt

847 Corruption

if F = KW

if C isin Cipub

public_command

if C isin Cipub

91 properties

92 limitations 131

92 limitations

93 discussion 133

93 discussion

93 discussion 135

functionality Fimpl

KM = FF1ImplF1

FlImplFl

new wrap and

FlImplFl

FF1ImplF1

FnImplFn

KM i e Fimpl

primem prime)

AwrapKWA(η) =

∣Pr[

FlImplFl

KM can

newwrap unwrap)

before-wrap

else if n = k

(c_) larr 0 1η

and implequal

σlarr sign(skm)

6= KW new 0

attr_change a a

(where a isinN)

send ltdonegt to P

send ltx σgt to A

ready-receiver

hlarr h

ready-sender

sk vklarr KG(1η)

done [send]

send ltdonegt to P

deliver[send]

if σ = σ

C O N C L U S I O N

Future work

A P P E N D I X

fun pair2

fun aenc3

fun pk1

4 free left

free right

free init

free c

private free sl

9 private free sr

let device =

19 out(c pk(k)) |

if y = init then

let user =

29 ν r

process

fun pair2

2 fun senc2

free c

free nil

free store

7 reduc

12 query attvskey

let create_proc =

read store as list

unlock

out(chandle)

let wrap_proc =

read store as list

unlock

27 in(outputk1)

in(outputk2)

if k1 = nil then 0

let fetch_key =

let list=cdr(x) in

if arg=car(h) then

out(outputcdr(h))

else if r=nil then

42 out(outputnil)

process

ν store

machine middot

5 Types

Secrets slsr

SKsk value

KMXYtoken untyped

10 Sets

Functions

public senc2 pair2

15 private inv1

iknows1 attack0

20 Rules

30 Init

decryption

Security goal

1 Problem wrapdec

Secrets slsr

SK value

6 KMXYt untyped

11 Functions

public senc2 pair2

private sl1 sr1

16 iknows1 attack0

decryption

Security goal

1 Problem Wrapdec

Token t one token

KM untyped

Functions

public senc2

private h1

iknows1 attack0

Generate a key

36 SDecrypt

Security goal

Policy 1

Policy 2

51 Policy 3

theory Yubikey

rule Yubikey_Plugin

[ Server(pidsidotc)

axiom smaller

exists-trace

or t2ltt1 or t1=t2)

same counter value

lemma no_replay

and not(i=j))

minusrarr t1ltt2

90 end

theory YubikeyHSM

functions

10 xor2 zero0

mac2 demac2

equations

computed

xor(xor(ab)a)=b

xor(xor(ab)b)=a

20 xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

demac(mac(mk)k)=m

rule isendHSM

rule irecvHSM

rule read_AEAD

[ S_AEAD(pidaead) ]

rule write_AEAD

rule HSMInit

HSM commands

minus[

]rarr[OutHSM(sc)]

Yubikey operations

rule BuyANewYubikey

YSM_AEAD_GENERATE

110 Out(~pid) ]

counter reset

rule Yubikey_Plugin

135 S_sid(pidsid) ]

axiom smaller

145 axiom onetime

150 exists-trace

the previous lemma

adversary

button press

otc2tc2)t2

or t2ltt1 or t1=t2)

induction

simplify

case case_1

210 next

case case_2

215 case case_2

case case_1

220 case case_2

case BuyANewYubikey

by sorry

230 qed

same counter value

lemma no_replay

and not(i=j))

255 and tc2=tc1+z

minusrarr t1ltt2

functions S1zero0

11 rule InitSucc

16 rule StepSucc

rule SimpleSmaller

[Succ(xy)]

rule BuyANewYubikey

(~pid)]

counter reset

axiom transitivity

exists-trace

induction

case empty_trace

116 next

simplify

rArr(last(t2)) or

(last(t1)) or

((t1 lt t2) and

(t2 lt t1) or

(t1 = t2)) or

(forall t1 t2 a b c

131 and

(not(last(t2))) and

(not(last(t1))) and

case case_1

((t1 lt t2) and

(t2 lt t1) or (t1 = t2) )

case case_1

case BuyANewYubikey

by sorry

156 by sorry

by sorry

161 qed

case case_2

166 case case_3

case case_4

171 next

case case_5

176 case case_2

by sorry

181 lemma no_replay

and not(i=j))

minusrarr t1ltt2

modelling)

functions S1zero0

11 xor2

mac2 demac2

16 xor(xor(ab)a)=b

xor(xor(ab)b)=a

xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

rule InitSucc

rule StepSucc

rule SimpleSmaller

36 [Succ(xy)]

rule isendHSM

rule irecvHSM

rule read_AEAD

Out(aead)]

rule write_AEAD

time in a trace

rule HSMInit

66 [Fr(~k) Fr(~kh)]

106 minus[

Yubikey operations

rule BuyANewYubikey

counter reset

156 in

relation is

build up

181 axiom onetime

LEMMAS

simplify

case BuyANewYubikey

~sidgt)

) 2i )

case BuyANewYubikey

case HSMInit

case BuyANewYubikey

SOLVED trace found

211 qed

case write_AEAD

216 by sorry

by sorry

221 next

by sorry

226 next

case csenc

by sorry

case irecvHSM

231 by sorry

lemmas)

the adversary

induction

case empty_trace

276 next

simplify

solve( S_AEAD( pid

mac(ltk2 sidgt k)gt

281 ) 2t2 )

by sorry

286 by sorry

case write_AEAD

) vk6 )

291 case irecv

case cxor

by sorry

296 next

by sorry

301 by sorry

306 end

14 | allow wrap

( in(lthcgt)

sdec(ck))

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

exists-trace

not a valid enc

and t3ltt1 )

54 end

26 if kp=k then

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

41 | Unwrap

if k1=k then

51 exists-trace

exists-trace

device or some

key leaked

( ν skA

9 out(pk(skA))

( in(pk(xB))

( ν skB

out(pk(skB))

exists-trace

lemma sanity2

exists-trace

lemma secrecy

theory Yubikey

8 let Yubikey=

13 out(pid)

( ( Plug

lock pid

unlock pid

) | ( ButtonPress

lock pid

ν npr

unlock pid

let Server=

lock pid

in(otc)

event InitStuff(pid

secretidktupleotc

event Login(pidktc)

unlock pid

(Server | Yubikey)

axiom smaller

exists-trace

typing lemmas

counter value

PressButton

113 end

theory Contract

2 begin

builtins signing

fakepcs4

equations

true()

fakepcs ()

true()

17 let Abort1 =

(lock ct

22 else

unlock ct

let Resolve2 =

Tamarin modelling

lock ct

42 else

unlock ct

let Resolve1 =

lock ct

67 unlock ct

let WitnessAbort =

event AbortCert(ct)

let HonestClient =

82 ν skA

out(pk(skA))

in (ltctxpkBgt)

out(sign(ctskA))

in(sigB)

92 else if not

0 Accept silently

102 ν skT

out(pk(skT))

HonestClient

117 Sanity checks

exists-trace

137 end

theory SetAbst

8 let Client=

Revoke key

ν ~nsk

out(~sk)

let Server=

ν ~sk

out(pk(~sk))

28 ( in(ltuserskgt)

| Revoke Key

1 theory SetAbst

let Client=

Revoke key

ν ~nsk

11 lock user

16 unlock user

event Revoked(~sk)

21 out(~sk)

let Server=

lock user

unlock user

out(pk(~sk))

( Revoke key

unlock user

exists-trace

and Revoked(sk) r)

5 let Device=(

out(pk(sk))

( lock s

in(req)

insert sreq

unlock s

lock s

let User=

exists-trace

50 exists-trace

lemma secrecy

60 end

translated rules

where JP [] []KD

if and only if

notαin orφ

(Definition of DHe)

DHenotαin orφ

insts )

notαin orφ

trace(ndg) ACC φ

primel) isin Si

σ = t1x1 tm xm and

We have that

QharrP S1 statep(t)

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

MSn Pn σnLn)

f(i) =

F2minusrarrJPK

νaQ cup Qaprimea

MSnminus1

R S for R = MDOut

F2minusrarrJPK

MSnminus1P

emptyF1minusrarrS1

lowast

lowastR S for R =

Ack(tNθ)]

pmiddot1 (t)

cup (vars(N)θ))

Fminusrarr

SMSnminus1P

Now suppose that

which simplifies to

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l1 t)

Lock(l prime t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l t)

n prime + 1

Unlock(l t)

Lock(l t)

Lock(l prime t)

n prime + 1

Unlock(l t)

aminusrarr

nminus1 =

SMSn = SMS

= Sf(n) Fres

and t isinM)

MDApplFresh

EnminusrarrJPK

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

n(1) ]) Since

n(1) ]

n(1) Then

j = S(1)j

semip (t) cup

p (t) We repeat

(1)n prime and call

the resulting trace

E(2)1minusrarrJPK

E(2)nminusrarrJPK S

(2)1 E

n(2) ]) and [E(2)1 E

n(2) ]

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

S(1) prime

S(1)t if t lt k

S(1)t+1 cup

statep(t)

if j+ 1 6 t lt i+ 1

S(1)t if i+ 1 6 t

E(3)1minusrarrJPK

E(3)nminusrarrJPK S

(3)1 E

n(3) ]) as

well as [E(3)1 E

n(3) ] α

E(4)1minusrarrJPK

E(4)nminusrarrJPK S

(4)1 E

n(4) ]) and [E(4)1

n(4) ] α

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

Since [E(4)1 E

(5)1 E

n(5) ]

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

in one step

n(5) then we

n(5)minus1 S(5)

(5)m prime

Q P S1 statep(t)

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

F2minusrarr

f(i) =

fp(i) if i isinNm

have that

Q2 cup Q1 Q2

Q1 | Q2 cup Q1 Q2

16j6nminus1

prime)

is S0E1minusrarrJPK

16j6nminus2

f(i) =

fp(i) if i isinNm

(by (6))

16j6nminus2

f(i) =

fp(i) if i isinNm

prime =

f(i) =

fp(i) if i isinNm

and Sn = Snminus1

cup Q2 and

Lock(u t)

Lock(nl t)

Unlock(nl t)

Lock(nl t)

Lock(u t)

Unlock(nl t)

a prime

prime) ) Fres

= Snminus1 Fres

= SMSn prime

= SMSn prime+1

ready [not ready]

sharebullh2gt to U2

to Fsetup

U isin U

13 from i=1 to n

= negl(η)

have FF1ImplF1

FnImplFn

FF1ImplF1

FpImplFp

KM as follows

FpImplFp

if F isin KWF1 Fp

4 key[c]larr c

9 key[c]larr k

if F isin F1 Fp

else if F = KW

call F with ltnewgt

6 else if F 6= KW

call F with ltCcmgt

1 public_command

if C isin Cipub

if F isin F1 Fp

6 else

if c1 isin Kcor

key[c2]=c2else

primegt

FlImplFl

setupgt message

FiImplFi

is negligible in η

(U2 hprime1) equiv

tminus1 (U1 h1)

(for some c) or

rArr corruptedMi|NP

FlImplFl

KM Sim Z]

to Fimpl

if F isin F1 Fl

else if F = KW

9 create Ki h

query NEW(Ki)

Klarr Kcup Ki

wrap[finish_setup]

7 else

4 if c1 isin Kcor

send lterrorgt to A

14 else

halt and output 0

3 else

if F isin KW

query k = CORR(c)

8 key[c]larr k

key[c]larr c

FimplKWKM Sim Z

FimplKWKM is F

5 if c1 isin Kcor

if c1 isin Kcor

send lterrorgt to A

exists in Fimpl

KM key[c] = c

implKWKM and F

case of Fimpl

implKWKM and F

ExpwrapfakeKWBZ

(η) = Exec[Fimpl

KM Sim Z](η)

implKWKM by

implKW

Z(η) b = 1]

Z(t) be the

implKWKM in Expwrap

KWB primeZ

implKWKM records

KWB primeZ

In ExpwrapKWB prime

Zwill set the ready

KWB primeZ

Z StoreB prime

Z(t minus 1)

Z(t) equals

KWB primeZ

in Storeπ

implKWKM and

[πFCΠImpl AD Z]

KWB primeZ

rectly

Z(η) b = 1]

and therefore

(η) b = 1]

Z(η) b = 1]|

(η) b = 1]

266 Bibliography

(2008) pp 3ndash51

Bibliography 267

268 Bibliography

(1983) pp 198ndash207

Bibliography 269

eprintiacrorg

270 Bibliography

1 (1992) pp 75ndash89

3 (1995) pp 131ndash133

Bibliography 271

272 Bibliography

Bibliography 273

defence

hardwareyubikey-neo

09-09pdf

Dedication

Abstract

Reacutesumeacute

Publications

Acknowledgments

Contents

List of Figures

List of Tables

Listings

Acronyms

Introduction

1 Introduction





2 Preliminaries


22 Facts

23 Substitutions



31 Running Examples

32 StatVerif







35 Other Approaches









42 The YubiHSM




43 Evaluation




434 Methodology

435 Future work


51 Related work



522 Semantics

523 Discussion




533 Discussion



542 Inclusion I

543 Inclusion II

55 Case studies



553 Yubikey







63 Composability

64 Overview

65 Related work


71 Preliminaries




81 Design Rationals

811 Policies

812 Sharing Secrets

813 Secure Setup



821 Credentials


83 Policies



842 Setup phase


844 Creating keys



847 Corruption





91 Properties

92 Limitations

93 Discussion





Conclusion




Appendix





B Proofs for Part i










Bibliography

Fuumlr meine Eltern

A B S T R A C T

C O N T E N T S

Introduction 1

1 introduction 3

model 15

2 preliminaries 17

22 Facts 18

23 Substitutions 18

32 StatVerif 24

42 The YubiHSM 50

43 Evaluation 55

xvi contents

434 Methodology 58

435 Future work 59

51 Related work 62

522 Semantics 66

523 Discussion 69

533 Discussion 78

542 Inclusion I 89

543 Inclusion II 93

55 Case studies 94

553 Yubikey 96

64 Overview 103

65 Related work 103

811 Policies 112

821 Credentials 115

83 Policies 116

contents xvii

842 Setup phase 120

847 Corruption 124

91 Properties 129

92 Limitations 131

93 Discussion 133

Conclusion 149

Appendix 159

bibliography 265

Figure 9 Syntax 63

List of Tables xix

L I S T I N G S

and wrap 125

xx Listings

A C R O N Y M S

xxii acronyms

GNUC GNUC is Not UC

4 introduction

introduction 5

6 introduction

8 introduction

decrypt

10 introduction

12 introduction

Part I

18 preliminaries

22 facts

23 substitutions

31 running examples

〈MN〉 = (terms)

| x y z (variables)

| a b c s (names)

| 0 (nil)

| P (replication)

| out(MN)P (output)

| in(MN)P (input)

| s =M P (assign)

32 statverif

32 statverif 25

let device =

out(cpk(k)) |

if y = init then

process

Generate a key

SDecrypt

Security goal

Policy B

Policy C

decryption

Security goal

35 other approaches

execmsr(R) =

emptyA1minusrarrR

AnminusrarrR Sn |

tracesmsr(R) =

and emptyA1=rArrR

minusrarrlowastR

AminusrarrR

(tr θ) perp never

we have that

Session Counter

Timestamp

Token Counter

Pseudo-random

CRC-16 value

Fr(k)Fr(pid)Fr(sid)

SharedKey(pid k)

Y_counter(pid tc)

Fr(nonce)

Server(pid sid tc)

andnot(i = j))

42 the yubihsm

42 the yubihsm 51

|data|blocksize

AES(k counteri)

AES AES AES

data1oplus

data2oplus

42 the yubihsm 53

xor(a a) = 0

[Out(aead)]

ks = keystream(khN)

43 evaluation 55

S_Counter(pid tc)

43 evaluation

43 evaluation 57

434 Methodology

43 evaluation 59

In(y) In(S(y))

Smaller(x y)

435 Future work

51 related work

with explicit state

| p isin PN

| n isin FN

〈PQ〉 = 0

| P | Q

Figure 9 Syntax

x isin D(σ)

522 Semantics

x1 isin D(σ)

x2 isin D(σ)

νnσ ⊢ k2

of traces of P as

tracespi(P) =

SMS1 P1 σ1 L1)

F2=rArr

Fn=rArr (En Sn S

MSn Pn σnLn)

=P prime

empty empty)

empty) where

Standard operations

if a prime is fresh

primeτ

where S prime(x) =

S(x) if x 6=E M

perp otherwise

if M 6isinEL

523 Discussion

P|Q = P|Q

if t1 = t2 then P

lookup M as x

αP = αP

unlock tP = perp

au(P|Q t l) = perp

au(P t l) = perp

au(if t1 = t2 then

P else Q t l)=

else au(Q t l)

au(lookup M as x

in P else Q t l)=

lookup M as x

au(0 t l) = 0

Jif M = N then P

else Qp xK

Jlookup M as v

in P else Qp xK

[state111111(k h)]

state_0111111( k h )

Out( h ) state_01111111( k h )

state_011111( k h )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

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 )

state_0111111( k h )

state_01111( k h )

state_011111( k h )

state_0111( k h )

state_01111( k h )

state_0111( k h )

533 Discussion

forall φ for

P primeex =P prime

5333 Axioms

Tr ⋆ JϕK⋆

hide(F middot tr) =

prime) ϕ

andforallθexistθ

prime) ϕ

prime) fi Hence we

primeallows us to

Proof of Theorem 1

tracespi(P) ⋆ ϕ

(by Proposition 1)

σ = t1x1 tm xm and

We have that

542 Inclusion I

as follows

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

Jif M = N then P

else Qp xK=pt

Jlookup M as v

in P else Qp xK=pt

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

543 Inclusion II

(P|pτ)ρ =E Q

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

55 case studies

55 case studies 95

553 Yubikey

55 case studies 97

in Section A3

Part II

63 composability

64 overview 103

64 overview

65 related work

71 preliminaries

is negligible in η

name [condition] P

send ltdonegt to P

81 design rationals

811 Policies

812 Sharing Secrets

813 Secure Setup

821 Credentials

newit holds that

bull for all k Pr[

(1η)]

bull Pr[

(1η)]

isnegligible in η

83 policies

changetimesAtimesA

Fenc new 0

KW wrap 1 0

KW unwrap 1 0

Fenc enc 0

U1 Un Uext1 Uext

Fsetup

ST1 STn

U1 Un Uext1 Uext

bull Uext = Uext1 U

bull Room sub U

bull F = F1 Fl and

privi and public

1 Uextm = Uext who

842 Setup phase

hmgt from Fsetup

844 Creating keys

call F with ltnewgt

send lterrorgt to A

create h

corrupt c3

if c1 isin Kcor

if F2 =KW

create h2

key[c2]larr c2

key[c prime]larr c2

send lterrorgt to A

create h2

primekgt

847 Corruption

if F = KW

if C isin Cipub

public_command

if C isin Cipub

91 properties

92 limitations 131

92 limitations

93 discussion 133

93 discussion

93 discussion 135

functionality Fimpl

KM = FF1ImplF1

FlImplFl

new wrap and

FlImplFl

FF1ImplF1

FnImplFn

KM i e Fimpl

primem prime)

AwrapKWA(η) =

∣Pr[

FlImplFl

KM can

newwrap unwrap)

before-wrap

else if n = k

(c_) larr 0 1η

and implequal

σlarr sign(skm)

6= KW new 0

attr_change a a

(where a isinN)

send ltdonegt to P

send ltx σgt to A

ready-receiver

hlarr h

ready-sender

sk vklarr KG(1η)

done [send]

send ltdonegt to P

deliver[send]

if σ = σ

C O N C L U S I O N

Future work

A P P E N D I X

fun pair2

fun aenc3

fun pk1

4 free left

free right

free init

free c

private free sl

9 private free sr

let device =

19 out(c pk(k)) |

if y = init then

let user =

29 ν r

process

fun pair2

2 fun senc2

free c

free nil

free store

7 reduc

12 query attvskey

let create_proc =

read store as list

unlock

out(chandle)

let wrap_proc =

read store as list

unlock

27 in(outputk1)

in(outputk2)

if k1 = nil then 0

let fetch_key =

let list=cdr(x) in

if arg=car(h) then

out(outputcdr(h))

else if r=nil then

42 out(outputnil)

process

ν store

machine middot

5 Types

Secrets slsr

SKsk value

KMXYtoken untyped

10 Sets

Functions

public senc2 pair2

15 private inv1

iknows1 attack0

20 Rules

30 Init

decryption

Security goal

1 Problem wrapdec

Secrets slsr

SK value

6 KMXYt untyped

11 Functions

public senc2 pair2

private sl1 sr1

16 iknows1 attack0

decryption

Security goal

1 Problem Wrapdec

Token t one token

KM untyped

Functions

public senc2

private h1

iknows1 attack0

Generate a key

36 SDecrypt

Security goal

Policy 1

Policy 2

51 Policy 3

theory Yubikey

rule Yubikey_Plugin

[ Server(pidsidotc)

axiom smaller

exists-trace

or t2ltt1 or t1=t2)

same counter value

lemma no_replay

and not(i=j))

minusrarr t1ltt2

90 end

theory YubikeyHSM

functions

10 xor2 zero0

mac2 demac2

equations

computed

xor(xor(ab)a)=b

xor(xor(ab)b)=a

20 xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

demac(mac(mk)k)=m

rule isendHSM

rule irecvHSM

rule read_AEAD

[ S_AEAD(pidaead) ]

rule write_AEAD

rule HSMInit

HSM commands

minus[

]rarr[OutHSM(sc)]

Yubikey operations

rule BuyANewYubikey

YSM_AEAD_GENERATE

110 Out(~pid) ]

counter reset

rule Yubikey_Plugin

135 S_sid(pidsid) ]

axiom smaller

145 axiom onetime

150 exists-trace

the previous lemma

adversary

button press

otc2tc2)t2

or t2ltt1 or t1=t2)

induction

simplify

case case_1

210 next

case case_2

215 case case_2

case case_1

220 case case_2

case BuyANewYubikey

by sorry

230 qed

same counter value

lemma no_replay

and not(i=j))

255 and tc2=tc1+z

minusrarr t1ltt2

functions S1zero0

11 rule InitSucc

16 rule StepSucc

rule SimpleSmaller

[Succ(xy)]

rule BuyANewYubikey

(~pid)]

counter reset

axiom transitivity

exists-trace

induction

case empty_trace

116 next

simplify

rArr(last(t2)) or

(last(t1)) or

((t1 lt t2) and

(t2 lt t1) or

(t1 = t2)) or

(forall t1 t2 a b c

131 and

(not(last(t2))) and

(not(last(t1))) and

case case_1

((t1 lt t2) and

(t2 lt t1) or (t1 = t2) )

case case_1

case BuyANewYubikey

by sorry

156 by sorry

by sorry

161 qed

case case_2

166 case case_3

case case_4

171 next

case case_5

176 case case_2

by sorry

181 lemma no_replay

and not(i=j))

minusrarr t1ltt2

modelling)

functions S1zero0

11 xor2

mac2 demac2

16 xor(xor(ab)a)=b

xor(xor(ab)b)=a

xor(aa)=zero

xor(zeroa)=a

xor(azero)=a

rule InitSucc

rule StepSucc

rule SimpleSmaller

36 [Succ(xy)]

rule isendHSM

rule irecvHSM

rule read_AEAD

Out(aead)]

rule write_AEAD

time in a trace

rule HSMInit

66 [Fr(~k) Fr(~kh)]

106 minus[

Yubikey operations

rule BuyANewYubikey

counter reset

156 in

relation is

build up

181 axiom onetime

LEMMAS

simplify

case BuyANewYubikey

~sidgt)

) 2i )

case BuyANewYubikey

case HSMInit

case BuyANewYubikey

SOLVED trace found

211 qed

case write_AEAD

216 by sorry

by sorry

221 next

by sorry

226 next

case csenc

by sorry

case irecvHSM

231 by sorry

lemmas)

the adversary

induction

case empty_trace

276 next

simplify

solve( S_AEAD( pid

mac(ltk2 sidgt k)gt

281 ) 2t2 )

by sorry

286 by sorry

case write_AEAD

) vk6 )

291 case irecv

case cxor

by sorry

296 next

by sorry

301 by sorry

306 end

14 | allow wrap

( in(lthcgt)

sdec(ck))

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

exists-trace

not a valid enc

and t3ltt1 )

54 end

26 if kp=k then

| Wrap

event Wrap(k1k2)

out(senc(k2k1))

41 | Unwrap

if k1=k then

51 exists-trace

exists-trace

device or some

key leaked

( ν skA

9 out(pk(skA))

( in(pk(xB))

( ν skB

out(pk(skB))

exists-trace

lemma sanity2

exists-trace

lemma secrecy

theory Yubikey

8 let Yubikey=

13 out(pid)

( ( Plug

lock pid

unlock pid

) | ( ButtonPress

lock pid

ν npr

unlock pid

let Server=

lock pid

in(otc)

event InitStuff(pid

secretidktupleotc

event Login(pidktc)

unlock pid

(Server | Yubikey)

axiom smaller

exists-trace

typing lemmas

counter value

PressButton

113 end

theory Contract

2 begin

builtins signing

fakepcs4

equations

true()

fakepcs ()

true()

17 let Abort1 =

(lock ct

22 else

unlock ct

let Resolve2 =

Tamarin modelling

lock ct

42 else

unlock ct

let Resolve1 =

lock ct

67 unlock ct

let WitnessAbort =

event AbortCert(ct)

let HonestClient =

82 ν skA

out(pk(skA))

in (ltctxpkBgt)

out(sign(ctskA))

in(sigB)

92 else if not

0 Accept silently

102 ν skT

out(pk(skT))

HonestClient

117 Sanity checks

exists-trace

137 end

theory SetAbst

8 let Client=

Revoke key

ν ~nsk

out(~sk)

let Server=

ν ~sk

out(pk(~sk))

28 ( in(ltuserskgt)

| Revoke Key

1 theory SetAbst

let Client=

Revoke key

ν ~nsk

11 lock user

16 unlock user

event Revoked(~sk)

21 out(~sk)

let Server=

lock user

unlock user

out(pk(~sk))

( Revoke key

unlock user

exists-trace

and Revoked(sk) r)

5 let Device=(

out(pk(sk))

( lock s

in(req)

insert sreq

unlock s

lock s

let User=

exists-trace

50 exists-trace

lemma secrecy

60 end

translated rules

where JP [] []KD

if and only if

notαin orφ

(Definition of DHe)

DHenotαin orφ

insts )

notαin orφ

trace(ndg) ACC φ

primel) isin Si

σ = t1x1 tm xm and

We have that

QharrP S1 statep(t)

E2minusrarr

MSn Pn σnLn)

16j6f(i) Fj

perp otherwise

3 SMSi = Sf(i)

4 Pi harrP Sf(i)

MSn Pn σnLn)

f(i) =

F2minusrarrJPK

νaQ cup Qaprimea

MSnminus1

R S for R = MDOut

F2minusrarrJPK

MSnminus1P

emptyF1minusrarrS1

lowast

lowastR S for R =

Ack(tNθ)]

pmiddot1 (t)

cup (vars(N)θ))

Fminusrarr

SMSnminus1P

Now suppose that

which simplifies to

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l1 t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l1 t)

Lock(l prime t)

Unlock(l prime t)

Unlock(l1 t)

Lock(l prime t)

Lock(l t)

n prime + 1

Unlock(l t)

Lock(l t)

Lock(l prime t)

n prime + 1

Unlock(l t)

aminusrarr

nminus1 =

SMSn = SMS

= Sf(n) Fres

and t isinM)

MDApplFresh

EnminusrarrJPK

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

n(1) ]) Since

n(1) ]

n(1) Then

j = S(1)j

semip (t) cup

p (t) We repeat

(1)n prime and call

the resulting trace

E(2)1minusrarrJPK

E(2)nminusrarrJPK S

(2)1 E

n(2) ]) and [E(2)1 E

n(2) ]

E(1)1minusrarrJPK

E(1)nminusrarrJPK S

S(1) prime

S(1)t if t lt k

S(1)t+1 cup

statep(t)

if j+ 1 6 t lt i+ 1

S(1)t if i+ 1 6 t

E(3)1minusrarrJPK

E(3)nminusrarrJPK S

(3)1 E

n(3) ]) as

well as [E(3)1 E

n(3) ] α

E(4)1minusrarrJPK

E(4)nminusrarrJPK S

(4)1 E

n(4) ]) and [E(4)1

n(4) ] α

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

Since [E(4)1 E

(5)1 E

n(5) ]

E(5)1minusrarrJPK

E(5)nminusrarrJPK S

in one step

n(5) then we

n(5)minus1 S(5)

(5)m prime

Q P S1 statep(t)

Fn prime such that

16j6i Ej

perp otherwise

3 SMSf(i)

=E Si Fres

4 Pf(i) P Si

Furthermore

F2minusrarr

f(i) =

fp(i) if i isinNm

have that

Q2 cup Q1 Q2

Q1 | Q2 cup Q1 Q2

16j6nminus1

prime)

is S0E1minusrarrJPK

16j6nminus2

f(i) =

fp(i) if i isinNm

(by (6))

16j6nminus2

f(i) =

fp(i) if i isinNm

prime =

f(i) =

fp(i) if i isinNm

and Sn = Snminus1

cup Q2 and

Lock(u t)

Lock(nl t)

Unlock(nl t)

Lock(nl t)

Lock(u t)

Unlock(nl t)

a prime

prime) ) Fres

= Snminus1 Fres

= SMSn prime

= SMSn prime+1

ready [not ready]

sharebullh2gt to U2

to Fsetup

U isin U

13 from i=1 to n

= negl(η)

have FF1ImplF1

FnImplFn

FF1ImplF1

FpImplFp

KM as follows

FpImplFp

if F isin KWF1 Fp

4 key[c]larr c

9 key[c]larr k

if F isin F1 Fp

else if F = KW

call F with ltnewgt

6 else if F 6= KW

call F with ltCcmgt

1 public_command

if C isin Cipub

if F isin F1 Fp

6 else

if c1 isin Kcor

key[c2]=c2else

primegt

FlImplFl

setupgt message

FiImplFi

is negligible in η

(U2 hprime1) equiv

tminus1 (U1 h1)

(for some c) or

rArr corruptedMi|NP

FlImplFl

KM Sim Z]

to Fimpl

if F isin F1 Fl

else if F = KW

9 create Ki h

query NEW(Ki)

Klarr Kcup Ki

wrap[finish_setup]

7 else

4 if c1 isin Kcor

send lterrorgt to A

14 else

halt and output 0

3 else

if F isin KW

query k = CORR(c)

8 key[c]larr k

key[c]larr c

FimplKWKM Sim Z

FimplKWKM is F

5 if c1 isin Kcor

if c1 isin Kcor

send lterrorgt to A

exists in Fimpl

KM key[c] = c

implKWKM and F

case of Fimpl

implKWKM and F

ExpwrapfakeKWBZ

(η) = Exec[Fimpl

KM Sim Z](η)

implKWKM by

implKW

Z(η) b = 1]

Z(t) be the

implKWKM in Expwrap

KWB primeZ

implKWKM records

KWB primeZ

In ExpwrapKWB prime

Zwill set the ready

KWB primeZ

Z StoreB prime

Z(t minus 1)

Z(t) equals

KWB primeZ

in Storeπ

implKWKM and

[πFCΠImpl AD Z]

KWB primeZ

rectly

Z(η) b = 1]

and therefore

(η) b = 1]

Z(η) b = 1]|

(η) b = 1]

266 Bibliography

(2008) pp 3ndash51

Bibliography 267

268 Bibliography

(1983) pp 198ndash207

Bibliography 269

eprintiacrorg

270 Bibliography

1 (1992) pp 75ndash89

3 (1995) pp 131ndash133

Bibliography 271

272 Bibliography

Bibliography 273

defence

hardwareyubikey-neo

09-09pdf

Dedication

Abstract

Reacutesumeacute

Publications

Acknowledgments

Contents

List of Figures

List of Tables

Listings

Acronyms

Introduction

1 Introduction





2 Preliminaries


22 Facts

23 Substitutions



31 Running Examples

32 StatVerif







35 Other Approaches









42 The YubiHSM




43 Evaluation




434 Methodology

435 Future work


51 Related work



522 Semantics

523 Discussion




533 Discussion



542 Inclusion I

543 Inclusion II

55 Case studies



553 Yubikey







63 Composability

64 Overview

65 Related work


71 Preliminaries




81 Design Rationals

811 Policies

812 Sharing Secrets

813 Secure Setup



821 Credentials


83 Policies



842 Setup phase


844 Creating keys



847 Corruption





91 Properties

92 Limitations

93 Discussion





Conclusion




Appendix





B Proofs for Part i










Bibliography