Causality in Security Protocols and Security APIs: Foundations and

322 Pages·2012·3.59 MB·English

Causality in Security Protocols and Security
APIs: Foundations and Practical Verification
Habilitationsschrift
Sibylle Fr¨oschle
Correct System Design
University of Oldenburg
June 20, 2012
2
Contents
I Context and Summary 7
1 Introduction 9
1.1 Motivation and Summary . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Security Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2 The Needham-Schroeder Public Key Protocol . . . . . . . 12
1.2.3 The Dolev-Yao Intruder . . . . . . . . . . . . . . . . . . . 13
1.2.4 Lowe’s Middleperson Attack. . . . . . . . . . . . . . . . . 14
1.3 Security APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.2 PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.3 IBM’s CCA . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.4 From Security Protocols to Security APIs . . . . . . . . . 25
1.4 Causality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 Overview of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 28
2 Models for Security Protocols 31
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 The Symbolic Approach . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Message Algebra . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.2 Intruder Deduction Capabilities . . . . . . . . . . . . . . . 35
2.2.3 Protocol Specifications . . . . . . . . . . . . . . . . . . . . 37
2.3 The Multiset Rewriting Model . . . . . . . . . . . . . . . . . . . 38
2.4 The Strand Space Model . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Contribution P1:
Branching for the Strand Space Model . . . . . . . . . . . . . . . 45
3 Decidability and Complexity of Security Protocols 49
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2 The Intruder Deduction Problem . . . . . . . . . . . . . . . . . . 52
3.3 The Insecurity Problem . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 The Bounded Insecurity Problem . . . . . . . . . . . . . . . . . . 59
3.4.1 Resource Measures . . . . . . . . . . . . . . . . . . . . . . 59
3.4.2 Data Exchange and Reduction . . . . . . . . . . . . . . . 60
3.4.3 Bounding the Number of Sessions . . . . . . . . . . . . . 61
3.4.4 Bounding Message Size and Fresh Data . . . . . . . . . . 66
3.5 The Insecurity Hierarchy. . . . . . . . . . . . . . . . . . . . . . . 71
3.6 Disequality Constraints and Contribution P2 . . . . . . . . . . . 71
3
4 CONTENTS
4 Verification of Security APIs 75
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 PKCS#11 and Contributions A1 to A4 . . . . . . . . . . . . . . 76
4.3 From Security Protocols to Security APIs . . . . . . . . . . . . . 79
4.4 The Security API Search Space . . . . . . . . . . . . . . . . . . . 82
4.4.1 Message Format and Size . . . . . . . . . . . . . . . . . . 82
4.4.2 Fresh Data and Key Abstraction . . . . . . . . . . . . . . 84
4.4.3 Key Metadata and Key Type Explosion . . . . . . . . . . 86
4.4.4 Number of Commands and Rule Explosion . . . . . . . . 87
4.4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5 General Aspects of Contributions A2 to A4 . . . . . . . . . . . . 89
4.5.1 Specifying and Modelling Security APIs . . . . . . . . . . 89
4.5.2 FOLTL+p for Security APIs . . . . . . . . . . . . . . . . 91
4.5.3 What to Verify? . . . . . . . . . . . . . . . . . . . . . . . 94
5 Causality: Foundations and Perspectives 97
5.1 Theory of Causality and Events:
Contributions C1 – C3 . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.1 Models and Equivalences for Concurrency . . . . . . . . . 97
5.1.2 Decidability and Complexity of Equivalences for Concur-
rency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.1 Relating Models for Security Protocols and APIs . . . . . 100
5.2.2 DecidabilityandComplexityofSecurityProtocolsandAPIs101
5.3 Practical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 101
II Theory of Causality and Events 113
6 Contribution C1:
Causality Versus True-Concurrency 115
7 Contribution C2:
TheDecidabilityBorderofHereditaryHistoryPreservingBisim-
ilarity 147
8 Contribution C3:
Non-Interleaving Bisimulation Equivalences on BPP 157
III Security Protocols: Foundations 197
9 Contribution P1:
Adding Branching to the Strand Space Model 199
10 Contribution P2:
The Insecurity Problem: Tackling Unbounded Data 221
CONTENTS 5
IV Security APIs: Practical Verification 239
11 Contribution A1:
Analysing PKCS#11 Key Management APIs with Unbounded
Fresh Data 241
12 Contribution A2:
Reasoning with Past to Prove PKCS#11 Keys Secure 261
13 Contribution A3:
Concepts and Proofs for Configuring PKCS#11 279
14 Contribution A4:
When is a PKCS#11 Configuration Secure? 299
6 CONTENTS
Part I
Context and Summary
7

Chapter 1
Introduction
1.1 Motivation and Summary
UntrustworthynetworkedenvironmentssuchastheInternethavebecomeubiq-
uitious in the modern world, and so has the need to secure communications
and systems against attacks. Two mechanisms are central to achieve this aim:
security protocols and security APIs.
A security protocol specifies an exchange of cryptographic messages, in-
tended to achieve security objectives such as mutual authentication, key estab-
lishment, or secrecy of data. Widespread examples are Kerberos for distributed
authentication and SSL/TLS for transport layer security. A security API (Ap-
plicationProgrammingInterface)isthesoftwareinterfacetoasecuritymodule:
atrusteddevicethatstoresandusessensitivecryptographickeysonbehalfofa
largeruntrustedsystem. Examplesofsecuritymodulesarethetamper-resistant
chip on a smartcard and the hardware security module (HSM) used by banks
to protect customers’ PINs.
Security protocols and security APIs have much in common: both specify
communications of cryptographic messages; the messages’ source (the network
forprotocolsandthehostsystemforAPIs)isassumedtobeuntrusted,possibly
under the control of an attacker; and both are prone to subtle attacks, where
an attacker tricks the honest party (an honest principal for protocols and the
securitymoduleforAPIs)intorevealingasensitivekeybyissuinganunexpected
sequence of communications.
While the field of security API analysis is young, security protocol analysis
goes back to the mid 1980s. There are now many special-purpose methods and
tools,whichhavebeensuccessfullyappliedtoanalyseandverifymostreal-world
protocols. On the other hand, many foundational problems have remained:
there is still no systematic understanding of the differences between the vari-
ous models for security protocols, and intruiging decidability and complexity
issues have remained unsettled. On the practical side, new research challenges
have emerged such as those posed by security APIs. In particular, preliminary
efforts to carry over protocol-analysis tools to security APIs have encountered
difficulties despite the above similarities.
The premise of this habilitation thesis is that we need to tackle the new
challenges of security APIs and other complex security issues from two fronts:
9
10 1. INTRODUCTION
top-down,drivenbyclassicaltheory,toresolvetheremainingfoundationalprob-
lemsofsecurityprotocolsandobtainasystematizedknowledgeinthearea;and
bottom-up, case-driven by the current security APIs, to develop practically rel-
evant verification methods. An orthogonal theme is to exploit causality in both
theory and practical verification.
This thesis consists of 9 research papers and a general introduction, which
summarizes these contributions and puts them into the wider context of the
topic. The research contributions fall into three areas. The first area is: theory
of causality and events; the second is: foundations of security protocols; and,
the third is: practical verification of security APIs. The contributions in the
third area are driven bottom-up from an investigation of PKCS#11, one of the
most widely adopted standards for both smartcards and HSMs.
The remainder of the present chapter is organized as follows. In Section 1.2
we introduce security protocols, and in Section 1.3 security APIs respectively.
In Section 1.4 we discuss the aspects of causality, which we shall make use of in
foundations and verification. Finally, in Section 1.5 we provide an overview of
the research contributions and the remainder of Part I.
1.2 Security Protocols
1.2.1 Introduction
A security protocol specifies an exchange of cryptographic messages, intended
to achieve security objectives such as authentication and key establishment.
The cryptographic functions used to construct the messages can involve any of
thestandardmechanisms: symmetricencryption,messageauthenticationcodes
(MACs), public key encryption, and digital signatures. Common to all security
protocolsisthattheymustbedesignedtooperateinahostileenvironment: they
must be secure against an intruder who cannot only eavesdrop on the messages
exchanged but who can actively intercept messages, replay and modify them,
as well as inject his own messages.
First Security Protocols. Security protocols in this sense were first designed
and investigated in the public domain in the 1970s when, with the advent of
computer networks1 new security requirements emerged, and with them new
challenges. Inparticular: howcantheusersofalargenetworkbeauthenticated,
and how can two users establish a session key, which they can then use to
exchange data encrypted over the network? In 1978 Needham and Schroeder
publishedaseminalpaperwiththetitle“Usingencryptionforauthenticationin
largenetworksofcomputers”[NS78]. Inthispapertheydescribetwoofthefirst
security protocols for authentication and key establishement. The first of these
protocolsisbasedonsymmetricencryption,andevolvedintoKerberos,whichis
now one of the most widely-used protocols for distributed authentication. The
secondoftheprotocolsisbasedonpublickeyencryption,andisnowusedasthe
standardexampleinacademicliteratureonsecurityprotocols. Asusual,wecall
it NSPK (short for Needham Schroeder Public Key) protocol in the following.
Programming Satan’s Computer. One reason why the NSPK protocol be-
came the standard example is because it is a point in case of how difficult it is
1The first public demonstration of the ARPANET network technology was organized in
1972,andLANsbegantoappearinthelate1970s[LCC+].