Enhancing Security in Distributed Systems with Trusted Computing ...

Enhancing Security in Distributed Systems with Trusted Computing Hardware by

Jason Reid Bachelor of Commerce, UQ Australia 1994 Master of Information Technology, QUT Australia 1999

Thesis submitted in accordance with the regulations for Degree of Doctor of Philosophy

Information Security Institute Queensland University of Technology

2007

ii

Keywords Trusted computing, trusted computing hardware, trusted systems, operating system security, distributed systems security, smart card, security evaluation, tamper resistance, distance bounding protocol, side channel leakage, electronic cash, electronic health records, role-based access control.

iii

iv

Abstract The need to increase the hostile attack resilience of distributed and internetworked computer systems is critical and pressing. This thesis contributes to concrete improvements in distributed systems trustworthiness through an enhanced understanding of a technical approach known as trusted computing hardware. Because of its physical and logical protection features, trusted computing hardware can reliably enforce a security policy in a threat model where the authorised user is untrusted or when the device is placed in a hostile environment. We present a critical analysis of vulnerabilities in current systems, and argue that current industry-driven trusted computing initiatives will fail in efforts to retrofit security into inherently flawed operating system designs, since there is no substitute for a sound protection architecture grounded in hardware-enforced domain isolation. In doing so we identify the limitations of hardware-based approaches. We argue that the current emphasis of these programs does not give sufficient weight to the role that operating system security plays in overall system security. New processor features that provide hardware support for virtualisation will contribute more to practical security improvement because they will allow multiple operating systems to concurrently share the same processor. New operating systems that implement a sound protection architecture will thus be able to be introduced to support applications with stringent security requirements. These can coexist alongside inherently less secure mainstream operating systems, allowing a gradual migration to less vulnerable alternatives. We examine the effectiveness of the ITSEC and Common Criteria evaluation and certification schemes as a basis for establishing assurance in trusted computing hardware. Based on a survey of smart card certifications, we contend that the practice of artificially limiting the scope of an evaluation in order to gain a higher assurance rating is quite common. Due to a general lack of understanding in the marketplace as to how the schemes work, high evaluation assurance levels v

are confused with a general notion of ‘high security strength’. Vendors invest little effort in correcting the misconception since they benefit from it and this has arguably undermined the value of the whole certification process. We contribute practical techniques for securing personal trusted hardware devices against a type of attack known as a relay attack. Our method is based on a novel application of a phenomenon known as side channel leakage, heretofore considered exclusively as a security vulnerability. We exploit the low latency of side channel information transfer to deliver a communication channel with timing resolution that is fine enough to detect sophisticated relay attacks. We avoid the cost and complexity associated with alternative communication techniques suggested in previous proposals. We also propose the first terrorist attack resistant distance bounding protocol that is efficient enough to be implemented on resource constrained devices. We propose a design for a privacy sensitive electronic cash scheme that leverages the confidentiality and integrity protection features of trusted computing hardware. We specify the command set and message structures and implement these in a prototype that uses Dallas Semiconductor iButtons. We consider the access control requirements for a national scale electronic health records system of the type that Australia is currently developing. We argue that an access control model capable of supporting explicit denial of privileges is required to ensure that consumers maintain their right to grant or withhold consent to disclosure of their sensitive health information in an electronic system. Finding this feature absent in standard role-based access control models, we propose a modification to role-based access control that supports policy constructs of this type. Explicit denial is difficult to enforce in a large scale system without an active central authority but centralisation impacts negatively on system scalability. We show how the unique properties of trusted computing hardware can address this problem. We outline a conceptual architecture for an electronic health records access control system that leverages hardware level CPU virtualisation, trusted platform modules, personal cryptographic tokens and secure coprocessors to implement role based cryptographic access control. We argue that the design delivers important scalability benefits because it enables access control decisions to be made and enforced locally on a user’s computing platform in a reliable way.

vi

Contents Keywords

iii

Abstract

v

List of Abbreviations

xvii

Declaration

xxi

Previously Published Material

xxiii

Acknowledgements

xxv

1 Introduction & overview 1.1 Aims and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Outline of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Contributions and achievements . . . . . . . . . . . . . . . . . . . 2 Background 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Assets: threats and vulnerabilities . . . . . . . . . . . . . . 2.3 What is trusted computing hardware? . . . . . . . . . . . 2.3.1 Tamper resistance . . . . . . . . . . . . . . . . . . . 2.3.2 Tamper detection and response . . . . . . . . . . . 2.3.3 Hardware types . . . . . . . . . . . . . . . . . . . . 2.4 Attack methods . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Security services provided by trusted computing hardware 2.5.1 Data confidentiality . . . . . . . . . . . . . . . . . . 2.5.2 Code confidentiality . . . . . . . . . . . . . . . . . 2.5.3 Data integrity . . . . . . . . . . . . . . . . . . . . .

vii

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

1 3 4 7 9 9 10 11 11 13 14 18 19 19 20 20

2.6 2.7

2.5.4 Code integrity . . . . . . . . 2.5.5 Confidentiality and integrity 2.5.6 Availability . . . . . . . . . Applications . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . .

. . . . . . . . . - authentication . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Trusted computing and trusted systems 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Vulnerabilities in distributed computing infrastructure . . . . 3.3 Trusted systems . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Historical background and context . . . . . . . . . . . 3.3.2 Properties of trusted systems . . . . . . . . . . . . . . 3.4 Protection architecture flaws in mainstream operating systems 3.4.1 No least privilege or MAC . . . . . . . . . . . . . . . . 3.4.2 Lack of assurance . . . . . . . . . . . . . . . . . . . . . 3.4.3 Memory architecture - no reference monitor . . . . . . 3.4.4 Trustworthiness of mainstream operating systems . . . 3.4.5 Trusted Operating Systems . . . . . . . . . . . . . . . 3.4.6 Trusted systems - barriers to adoption . . . . . . . . . 3.5 TCG Scheme - description . . . . . . . . . . . . . . . . . . . . 3.5.1 Key features . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 The trusted computing controversy . . . . . . . . . . . 3.5.3 Background and relationship to prior work . . . . . . . 3.5.4 TCG trusted platform module . . . . . . . . . . . . . . 3.5.5 Integrity measurement and reporting . . . . . . . . . . 3.5.6 Protected storage . . . . . . . . . . . . . . . . . . . . . 3.5.7 Sealed storage . . . . . . . . . . . . . . . . . . . . . . . 3.6 Analysis of TCG remote attestation and privacy model . . . . 3.6.1 Identity credentials . . . . . . . . . . . . . . . . . . . . 3.6.2 Credential revocation requirements . . . . . . . . . . . 3.6.3 Minimising the trust on the privacy CA . . . . . . . . 3.7 Integrating TCG with mainstream operating systems . . . . . 3.7.1 DRM case study introduction . . . . . . . . . . . . . . 3.7.2 Relevance of trusted systems to DRM . . . . . . . . . . 3.7.3 Policy enforcement on a DRM client platform . . . . . 3.7.4 Maintaining integrity assurance . . . . . . . . . . . . . viii

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

22 23 24 28 28

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 31 34 37 37 39 43 43 44 45 47 48 48 49 49 50 51 53 54 55 56 56 58 59 62 64 65 66 67 70

3.8

3.9

3.7.5 Privacy impacts . . . . . . . . . . . . . . . . . Next Generation Secure Computing Base (NGSCB) . 3.8.1 NGSCB and virtual machine monitors . . . . 3.8.2 Trusted systems properties of NGSCB . . . . 3.8.3 Microsoft delays NGSCB . . . . . . . . . . . . 3.8.4 The significance of virtual machine technology Conclusion . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

4 Certification - Trusted and Trustworthy? 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4.2 How certification works . . . . . . . . . . . . . . . . . . 4.2.1 ITSEC . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 The Common Criteria . . . . . . . . . . . . . . 4.2.3 FIPS 140 . . . . . . . . . . . . . . . . . . . . . 4.3 A survey of smart card certifications . . . . . . . . . . 4.3.1 Mondex - E6 High or EAL 1 Low . . . . . . . . 4.3.2 Justification for a MULTOS High SoM . . . . . 4.3.3 Motivations to exclude hardware from the TOE 4.4 Evaluation by composition . . . . . . . . . . . . . . . . 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

5 Side channel leakage 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Attacking trusted hardware with side channel analysis . . . . . 5.2.1 CMOS power consumption and side channel leakage . . 5.2.2 A correlation power analysis attack on DES . . . . . . 5.2.3 Current practical significance of power analysis attacks 5.3 Applying side channel leakage to distance bounding protocols 5.3.1 Introduction to relay attacks and distance bounding . . 5.3.2 Distance-bounding protocols . . . . . . . . . . . . . . . 5.3.3 Hancke and Kuhn’s distance-bounding protocol . . . . 5.3.4 New distance-bounding protocol . . . . . . . . . . . . . 5.4 Security of new protocol . . . . . . . . . . . . . . . . . . . . . 5.4.1 Comparison with existing schemes . . . . . . . . . . . . 5.4.2 Communications requirements for distance bounding . 5.4.3 Timing Resolution for relay attack detection . . . . . .

ix

. . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . .

73 74 75 76 76 77 79

. . . . . . . . . . .

81 81 83 83 88 90 91 93 95 97 101 103

. . . . . . . . . . . . . .

105 105 107 107 109 114 116 117 118 122 124 126 127 128 130

5.5

5.4.4 Timing resolution for contactless card communication 5.4.5 A new approach to low latency communication . . . . 5.4.6 Experimental results . . . . . . . . . . . . . . . . . . 5.4.7 Investigations into modulation latency . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

131 135 136 138 143

6 An electronic cash scheme based on trusted computing hardware145 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.2 Background and design issues . . . . . . . . . . . . . . . . . . . . 147 6.2.1 Desirable scheme properties . . . . . . . . . . . . . . . . . 149 6.2.2 Common approaches to representing electronic value . . . 149 6.3 Outline of the proposed scheme . . . . . . . . . . . . . . . . . . . 157 6.3.1 Left cash . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.3.2 Right cash . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.4 Scheme design and implementation . . . . . . . . . . . . . . . . . 159 6.4.1 Overview and design principles . . . . . . . . . . . . . . . 159 6.4.2 Payment protocol . . . . . . . . . . . . . . . . . . . . . . . 163 6.4.3 Fraud and counterfeit detection . . . . . . . . . . . . . . . 167 6.4.4 Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . . 168 6.4.5 Public key authentication framework . . . . . . . . . . . . 170 6.4.6 Timing of left for right exchange . . . . . . . . . . . . . . . 171 6.4.7 Divisible instruments allow linking . . . . . . . . . . . . . 172 6.4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.5 Prototype description . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.5.1 Prototype System - functionality . . . . . . . . . . . . . . 174 6.5.2 Prototype system - components . . . . . . . . . . . . . . . 175 6.5.3 Dallas Semiconductor iButton . . . . . . . . . . . . . . . . 176 6.5.4 Simulation of security tokens . . . . . . . . . . . . . . . . . 179 6.5.5 Implementation using iButtons . . . . . . . . . . . . . . . 180 6.6 Scheme analysis and review of properties . . . . . . . . . . . . . . 181 6.6.1 Comparison of proposed scheme and Paypal . . . . . . . . 181 6.6.2 Review of properties . . . . . . . . . . . . . . . . . . . . . 183 6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 7 Application case study: Electronic health records 189 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

x

7.2

7.3

7.4

7.5

7.6

Background to electronic health records . . . . . . . . . . . . . 7.2.1 Electronic health records and privacy . . . . . . . . . . 7.2.2 Translating patient consent into access policy . . . . . Background to RBAC . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Motivation and benefits of RBAC . . . . . . . . . . . . 7.3.2 RBAC constraints and inheritance . . . . . . . . . . . 7.3.3 Related work . . . . . . . . . . . . . . . . . . . . . . . 7.3.4 Implementing explicit denial in RBAC . . . . . . . . . A novel RBAC model with explicit denial . . . . . . . . . . . 7.4.1 Role hierarchies . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Explanation of the model . . . . . . . . . . . . . . . . 7.4.3 Authorisation algorithm . . . . . . . . . . . . . . . . . 7.4.4 An Example of a nested allow and deny policy . . . . . 7.4.5 Initial prototype . . . . . . . . . . . . . . . . . . . . . Large-scale implementation considerations . . . . . . . . . . . 7.5.1 Protecting RBAC entity bindings . . . . . . . . . . . . 7.5.2 Scalable distributed system with negative privileges . . 7.5.3 Offline authorisation . . . . . . . . . . . . . . . . . . . 7.5.4 Benefits of cryptographic access control . . . . . . . . . Proposal for a role-based cryptographic access control scheme 7.6.1 Trusted computing hardware infrastructure . . . . . . . 7.6.2 Consent object confidentiality and distribution . . . . . 7.6.3 Relevance of proxy re-encryption . . . . . . . . . . . . 7.6.4 Confidential consent policy via proxy re-encryption . . 7.6.5 Building blocks: improved proxy re-encryption . . . . . 7.6.6 Improved proxy re-encryption without proxies . . . . . 7.6.7 Key management for access policy enforcement . . . . 7.6.8 Enforcing negative privileges . . . . . . . . . . . . . . . 7.6.9 Reducing the number of role keys . . . . . . . . . . . . 7.6.10 Directory services . . . . . . . . . . . . . . . . . . . . . 7.6.11 Structured object identifiers . . . . . . . . . . . . . . . 7.6.12 Consent update and revocation . . . . . . . . . . . . . 7.6.13 Record access procedure . . . . . . . . . . . . . . . . . 7.6.14 Revoking role membership . . . . . . . . . . . . . . . . 7.6.15 Binding data to policy . . . . . . . . . . . . . . . . . .

xi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191 191 192 194 195 196 196 198 198 199 200 201 202 202 204 204 205 208 209 211 212 213 214 214 215 216 217 219 219 220 220 221 221 223 223

7.7 7.8

7.6.16 Heterogeneous record sensitivity 7.6.17 Authorised record update . . . 7.6.18 Record authenticity . . . . . . . Discussion . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8 Conclusions and future work 8.1 Summary of contributions and achievements . . . . . . . . . . 8.2 Summary of main themes and conclusions . . . . . . . . . . . 8.2.1 Trusted computing hardware - properties and services . 8.2.2 Lest we forget - trusted systems and trusted computing 8.2.3 Assurance through evaluation and certification? . . . . 8.2.4 Side channel leakage for attack and defense . . . . . . . 8.2.5 Electronic cash with trusted computing hardware . . . 8.2.6 A scaleable and secure EHR system . . . . . . . . . . . 8.3 Opportunities for further work . . . . . . . . . . . . . . . . . . A Electronic cash scheme - right cash protocols A.1 Withdrawal . . . . . . . . . . . . . . . . . . . A.2 Payment . . . . . . . . . . . . . . . . . . . . . A.2.1 Authenticate S to C . . . . . . . . . . A.2.2 Authenticate C to S . . . . . . . . . . A.2.3 Establish secure channel . . . . . . . . A.2.4 Payment/Receipt of goods . . . . . . . A.3 A DSA based right cash scheme . . . . . . . . A.3.1 System Setup . . . . . . . . . . . . . . A.3.2 DSA Setup . . . . . . . . . . . . . . . A.3.3 Diffie-Hellman Setup . . . . . . . . . . A.3.4 Withdrawal . . . . . . . . . . . . . . . A.3.5 Payment . . . . . . . . . . . . . . . . A.3.6 Batch Deposit . . . . . . . . . . . . . . A.3.7 Specification of certificates, records and Bibliography

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . messages

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

224 224 225 225 227

. . . . . . . . .

229 229 231 231 232 234 234 235 236 238

. . . . . . . . . . . . . .

241 242 243 244 244 244 245 245 246 246 246 247 249 250 251 265

xii

List of Figures 3.1 3.2 3.3 3.4 3.5 3.6 3.7

The reference monitor concept. . . . . . . . . . Application 1 accesses application 2 memory via Intended use of the Intel x86 ring architecture. . TCG Integrity Protected Boot Sequence. . . . . TCG Platform Attestation to a Remote Entity. Identity Credential Issuing Protocol . . . . . . . Modified Identity Credential Issuing Protocol .

5.1

Power consumption traces of MOV instruction with operand Hamming weights from 1 to 8. . . . . . . . . . . . . . . . . . . . . . . Typical measured waveform across current sensing resistor. . . . . Instantaneous power consumption at time t across multiple traces represents an event vector. . . . . . . . . . . . . . . . . . . . . . . Correlation for correct and incorrect guess vectors. The 0.8 peak signifies the correct subkey. . . . . . . . . . . . . . . . . . . . . . . Event vector, correct and incorrect guess vectors. . . . . . . . . . Adversarial setting . . . . . . . . . . . . . . . . . . . . . . . . . . REQA command/response sequence as measured in reader RX circuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subcarrier load modulation of a single bit from card to reader at 106 kbits/s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing resolution using proposed method. . . . . . . . . . . . . . Card communicates with reader via load modulation. Higher antenna voltages produce delays in effecting a detectable amplitude increase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace alignment on resumption of carrier in last reader to card bit pause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

5.11

xiii

. a . . . . .

. . . . . . . . buggy driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

42 45 47 55 58 59 63

109 111 112 113 114 119 132 133 137

139 140

5.12 Percentage change in modulation peak amplitude vs. antenna voltage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8

7.1 7.2

Electronic cash scheme overview . . . Prototype overview . . . . . . . . . . Payment protocol flow . . . . . . . . A method to avoid timing attacks . . Life cycle of divisible coin . . . . . . Purse payment protocol . . . . . . . Mint issued coins . . . . . . . . . . . Internal construction a cryptographic Semiconductor Inc.) . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iButton (courtesy of Dallas . . . . . . . . . . . . . . . .

157 160 162 172 174 177 178 179

Consent for Doctors qualified by explicit denial of Dr X. . . . . . 201 Nested consent and denial. . . . . . . . . . . . . . . . . . . . . . . 203

A.1 Withdrawal overview . . . . . . . . . . . . . . . . . . . . . . . . . 243 A.2 Payment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 A.3 Withdrawal protocol flow . . . . . . . . . . . . . . . . . . . . . . . 253

xiv

List of Tables 3.1 Commercial trusted operating systems. . . . . . . . . . . . . . . . 3.2 Protocol Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 59

4.1

Survey of smart card certifications . . . . . . . . . . . . . . . . . .

92

5.1

Comparison of existing distance-bounding protocols . . . . . . . . 128

7.1

An example of consent policy data. . . . . . . . . . . . . . . . . . 219

A.1 Definition of cash scheme entities and terms. . . . . A.2 Coin Credential Encoded Format . . . . . . . . . . A.3 Merchant Credential Encoded Format . . . . . . . . A.4 Signed Credential Encoded Format - a Certificate . A.5 Purchase Record Encoded Format . . . . . . . . . . A.6 Signed Purchase Record Encoded Format . . . . . . A.7 Receipt Record Encoded Format . . . . . . . . . . . A.8 Signed Receipt Record Encoded Format . . . . . . A.9 Issued Right Coin Record Encoded Format . . . . . A.10 Purchase Init Message Encoded Format . . . . . . . A.11 Payment Details Message Encoded Format . . . . . A.12 Payment Transaction ID Message Encoded Format A.13 Receipt Message Encoded Format . . . . . . . . . . A.14 Current Coin Details Message Encoded Format . .

xv

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

242 254 255 255 256 257 258 259 259 260 260 261 262 263

xvi

List of Abbreviations ACL AES API ASCII ASIC ASK ATM BBRAM BCD BIOS CA CC CCA CE CESG CMOS COTS CPA CPU CRTM DAA DAC DES DH DMA DNS

Access Control List Advanced Encryption Standard Application Progamming Interface American Standard Code for Information Interchange Application Specific Integrated Circuit Amplitude Shift Keying Automatic Teller Machine Battery Backed Random Access Memory Binary Coded Decimal Basic Input Ouput System Certification Authority Common Criteria Common Cryptographic Architecture Conformance Entity Communications Electronics Security Group Complementary Metal Oxide Semiconductor Commercial Off-The-Shelf System Correlation Power Analysis Central Processing Unit Core Root of Trust for Measurement Direct Anonymous Attestation Discretionary Access Control Data Encryption Standard Diffie Hellman Direct Memory Access Domain Name System Continued on next page xvii

DoS DPA DRM DSA DSCA DSD DTE EEPROM EHR FDT FIPS GCHQ HMAC I/O IC ICC ICT ITSEC KDF LDAP MAC MAC MLS NGSCB NHS NIST NSA OID OS PC PCMCIA PCR PDA PE PKI

Denial of Service Differential Power Analysis Digital Rights Management Digital Signature Algorithm Differential Side Channel Analysis Defense Signals Directorate Domain and Type Enforcement Electrically Eraseable Programmable Read Only Memory Electronic Health Records Frame Delay Time Federal Information Processing Standard Government Communications Headquarters Hashed Message Authentication Code Input/Ouput Integrated Circuit Integrated Circuit Card Information and Communications Technology Information Technology Security Evaluation Criteria Key Derivation Function Lightweight Directory Access Protocol Message Authentication Code Mandatory Access Control Multi-Level Security Next Generation Secure Computing Base National Health Service National Institute of Standards and Technology National Security Agency Object Identifier Operating System Personal Computer Personal Computer Memory Card International Association Platform Configuration Register Personal Digital Assistant Platform Entity Public Key Infrastructure Continued on next page xviii

PP RAM RBAC RF RFID ROM RSA SCSUG SHA SoM SSCA SVC TCB TCG TCP/IP TCPA TCSEC TLV TOE TPM TPME UWB VMM VOIP

Protection Profile Random Access Memory Role Based Access Control Radio Frequency Radio Frequency Identification Read Only Memory Rivest Shamir Adelman Smart Card Security Users Group Secure Hash Algorithm Strength of Mechanisms Simple Side Channel Analysis Stored Value Cards Trusted Computing Base Trusted Computing Group Transmission Control Protocol/Internet Protocol Trusted Computing Platform Alliance Trusted Computer Security Evaluation Criteria Tag Length Value Target of Evaluation Trusted Platform Module Trusted Platform Module Entity Ultra Wide Band Virtual Machine Monitor Voice Over Internet Protocol

xix

xx

Declaration The work contained in this thesis has not been previously submitted for a degree or diploma at any higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made.

Signed:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date:. . . . . . . . . . . . . . . . . . . . . .

xxi

xxii

Previously Published Material The following papers have been published or presented, and contain material based on the content of this thesis. [1] Jason Reid and Mark Looi. Making sense of smart card security certifications. In Proceedings of the Fourth Working Conference on Smart Card Research and Advanced Applications (CARDIS), pages 225–240, Bristol, United Kingdom, 2000. Kluwer Academic Publishers. [2] Jason Reid, Juan M. Gonzalez Nieto, Ed Dawson, and Eiji Okamoto. Privacy and trusted computing. In DEXA ’03: Proceedings of the 14th International Workshop on Database and Expert Systems Applications, pages 383–388, Washington, DC, USA, 2003. IEEE Computer Society. [3] Greg Maitland, Jason Reid, Ernest Foo, Colin Boyd, and Ed Dawson. Linkability in practical electronic cash design. In E. Okamoto and J. Pieprzyk, editors, The Third International Workshop on Information Security (ISW2000), volume 1975 of Lecture Notes in Computer Science, pages 149–163. SpringerVerlag, 2000. [4] Jason Reid and William J. Caelli. DRM, trusted computing and operating system architecture. In Proceedings of the Australasian Information Security Workshop (AISW 2005), volume 44 of Conferences in Research and Practice in Information Technology (CRPIT), pages 127–136, Newcastle, Australia, 2005. Australian Computer Society, Inc. [5] Jason Reid. Towards practical trusted computing. In Proceedings of the 5th Asia-Pacific Industrial Engineering and Management Systems Conference (APIEMS), Gold Coast, Queensland, Australia, 2004.

xxiii

[6] Brian Fitzgerald and Jason Reid. Digital rights management (DRM): managing digital rights for open access. In David Rooney, Greg Hearn, and Abraham Ninan, editors, Handbook On The Knowledge Economy, chapter 21, pages 268–277. Edward Elgar Publishing, Cheltenham, UK, 2005. [7] Jason Reid. Prospects for improved operating system security. In AusCERT Computer Crime and Security Survey, page 28. AusCERT, Brisbane, Australia, 2005. [8] Jason Reid, Bouchra Senadji, and Tee Tang. Security considerations for conducted and radiated emissions. In Proceedings of the Asia Pacific Symposium on EMC, pages 345–348, Taipei, Taiwan, 2005. [9] Jason Reid, Ian Cheong, Matthew Henricksen, and Jason Smith. A novel use of RBAC to protect privacy in distributed health care information systems. In Rei Safavi-Naini and Jennifer Seberry, editors, Proceedings 8th Australasian Conference on Information Security and Privacy (ACISP 2003), volume 2727 of Lecture Notes in Computer Science, pages 403–415, Wollongong, Australia, 2003. Springer Verlag. [10] Jason Reid, Juan M. Gonzalez Nieto, Tee Tang, and Bouchra Senadji. Detecting relay attacks with timing-based protocols. In Proceedings of the 2007 ACM Symposium on Information, Computer and Communications Security (ASIACCS‘07), Singapore, 20-22 March 2007. ACM Press.

xxiv

Acknowledgements There are many people to whom I would like to express my thanks and appreciation - I have been truly fortunate to work with quite a number of inspiring and talented people in the course of my doctoral research. Firstly, I would like to acknowledge my sincere gratitude to my principal supervisor and friend, Professor Ed Dawson. Without his encouragement, guidance and support I would not have started or finished. My associate supervisors, Professor Bill Caelli and Professor Mark Looi also deserve special mention for their valuable advice and input. This thesis is the culmination of almost six years of research that I have pursued mostly as a part-time doctoral student. For the bulk of this time I was employed as a researcher with the Information Security Research Centre (now the Information Security Institute) at QUT. I was fortunate that the research projects I worked on for the ISI sometimes overlapped my thesis topic and this goes some way to explaining the breadth of material that the thesis deals with. I am most appreciative of the opportunities and support that the ISI has given me. I am very grateful to my close friend and colleague Juanma Gonzàlez Nieto for the generous way that he has shared his insight, intelligence and optimism. Working with Juanma has been a rewarding and enjoyable experience that I will not forget. We collaborated on the distance bounding work, particularly the protocols that are introduced in Section 5.3.2 and some of the Trusted Computing Group work in Section 3.6. My special thanks go to Dr Tee Tang and Dr Bouchra Senadji who worked with me on the side channel analysis investigations reported in Section 5.2. I also enjoyed the assistance of three undergraduate electrical engineering students, Benjamin David, Vania Sidharta and Jason Kong who showed great curiosity and enthusiasm in performing much of the early experimental work. I gratefully acknowledge the contributions and support of Greg Maitland, xxv

who was a PhD student at the time we worked on the electronic cash project together. Greg was instrumental in formulating the concept and the protocol design that is presented as Appendix A and also in the work that is presented in Sections 6.4.6 and 6.4.7. He was responsible for the Merchant store front components of the prototype, described in Section 6.5.2. Kapali Viswanathan also deserves special mention for his contribution in developing the user interface and networking aspects of the prototype. Ernest Foo, Andrew Clark, Colin Boyd and Roland Seidel also contributed to the success of the project in various and useful ways. The access control model presented in Section 7.4 was joint work with Jason Smith, Ian Cheong and particularly, Matt Henricksen and I wish to gratefully acknowledge their tremendous effort and hard work on what was both a challenging and rewarding project. I am forever indebted to my remarkable parents who encouraged me think and question. They gave me many opportunities and provided a living example of how to lead a thoughtful and considerate life - great gifts indeed. Finally, I would like to express my heartfelt gratitude to my best friend and life partner Karen, who supported me tirelessly and selflessly. Her belief and confidence kept me going and I cannot thank her enough.

xxvi

Chapter 1

Introduction & overview Industrialized societies are now heavily reliant on computers in almost every aspect of commerce, industry, government and, increasingly, in private life. Internetworked computers mediate and control safety critical systems, vast databanks of private and sensitive information and the daily flow of trillions of dollars, so it has become quite important that these computers ‘get it right’, even in the face of an increasing threat of targeted subversion. Distributed, internetworked computing infrastructure now faces a threat environment that has changed considerably over the past 20 years. In the early days, physical interference was relatively easy to prevent because computers were large, expensive and required a climatically controlled environment. This naturally lead to protection by guards, doors and locks and they ensured that only authorised personnel had physical access. Furthermore, logical interference was not a serious issue because computers were not networked, nor indeed, internetworked and thus accessible from any corner of the globe. Today, the number of computing devices has skyrocketed and they are deployed all around us, in potentially hostile environments where adversaries have easy physical access and logical access via pervasive network connections. This shift from a benign operational environment to one that literally bristles with threats provides the motivation for trusted computing hardware. The Internet is a public medium so cryptography is necessary to identify communicating entities to each other and to protect their messages from eavesdropping and modification. Cryptography implicitly assumes that secret keys 1

2

Chapter 1. Introduction & overview

can be stored and used whilst remaining secret. Some type of physical security is necessary to achieve this, particularly to protect keys when they are being used. While the military has refined, over very many decades, its understanding of the subtle and demanding task of protecting cryptographic keys in threatening environments, the commercial sector is considerably less advanced in this regard. It first had to come to grips with the problem in order to deploy automatic teller machine networks. This application motivated the development of some of the earliest commercial trusted computing devices. These were known as hardware security modules or secure coprocessors, since they worked alongside a general purpose computing platform, providing a sanctuary in which secret keys could be safely stored and used. The financial institutions had realized that general purpose commercial operating systems were unable to protect secret keys from attack by authorised insiders such as systems development and maintenance staff. In contrast to military trusted systems, commercial systems were not designed to provide strong protection against authorised users who intentionally or unintentionally overstepped their authority. Similar challenges to those that had confronted the banking sector began to surface when the Internet became a popular communication medium for government, commerce and industry. Again, cryptography was put forward as the solution to authenticate and protect sensitive communications over a public channel and it quickly became evident that the associated secret keys required more robust protection than software-only solutions could provide. Smart cards were promoted as a way of providing physical protection but with modest success due to their ability to address only a small subset of relevant threats. Internet connectivity had served to highlight a much deeper and more significant problem - that general purpose, mainstream operating systems1 were highly vulnerable to attacks that originated over the network. This is a fundamental consequence of the way such systems fail to protect themselves internally. Basically, there are no effective locks and doors once minimally inside the system. The reasons for this are explained by the observation that commercial operating systems were developed for a benign operating environment. Their approach to protecting and segregating users, data and processes rests on a very flexible 1

In this thesis we use the term mainstream operating system to refer to popular commercial operating systems such as Windows NT, 2000 and XP from Microsoft Inc, Linux and various versions of Unix that implement a discretionary access control policy. Discretionary access control is discussed in Section 3.4.

1.1. Aims and objectives

3

and user friendly model known as discretionary access control. Unfortunately, this model is highly vulnerable to software attacks that exploit seemingly everpresent bugs in code. Moreover, Trojan Horse software which seeks to co-opt the privileges of an authorised process or user is very effective because of the large number of processes that run with largely unrestricted rights. The once-benign operating environment has transformed into something altogether more threatening and in response, the computing industry has promoted ad-hoc, symptomatic, add-on treatments such as virus detection software, firewalls and intrusion detection systems. Since the low level architectural vulnerabilities remain, attackers have simply improved their ability to evade these monitoring and perimeter protection strategies and the general state of security has continued to deteriorate. Clearly, the widespread deployment of highly vulnerable systems now exposes a significant problem of societal scale. This thesis seeks to examine how trusted computing hardware might offer a solution.

1.1

Aims and objectives

The aim of this thesis is to understand at a fundamental level, the reasons why distributed systems are insecure and to analyse, investigate, and propose ways in which trusted computing hardware can be used to improve their robustness against attack. Since threats and vulnerabilities stem from many sources, and measures to address them are necessarily multifaceted, the thesis aims to approach the problem from a number of different, though complimentary directions, which we now describe. Trusted Platform Modules (TPMs) play an important role in a recent industryled proposal for improving distributed systems security. TPMs measure software integrity by calculating fingerprints of software components. They can communicate this information to remote systems. The thesis aims to evaluate the potential effectiveness of this approach and to identify flaws and weaknesses. Assurance is a vital aspect of the philosophy that has driven the development of trusted computing hardware and trusted systems. Assurance flows from being able to objectively assess a vendor’s claims as to why their product should be trusted, under what conditions and against which threats. A number of evaluation and certification schemes are available to independently test such claims. A further aim of the thesis is to evaluate how useful these schemes have been in

4


providing relevant and reliable information to potential purchasers and system designers. Personal cryptographic tokens such as smart cards have an important role to play in securing distributed systems, particularly in authenticating users. Due to practical constraints on size and cost they have a peculiar set of vulnerabilities. The thesis aims to develop an efficient and cost effective technique to detect a type of attack on smart cards known as a relay attack. In a relay attack a verifier is fooled into believing that they have authenticated a card that is close by, when in fact, the device could be quite a distance away. Amongst other problems, relay attacks undermine physical access control wherein an interaction with a token is used to infer its physical proximity. Finally, the thesis seeks an improved understanding of how the basis of trustworthy system behaviour can best be allocated between: • well designed code executing in an environment that is protected by trusted computing hardware and, • direct policy enforcement via application level cryptography. With the former approach, authenticated programmed functionality is trusted on the basis of isolation and cryptographic integrity protection from underneath. With the latter, cryptographic protocols are devised to directly enforce application level security policies from within. Programmed functionality running in an isolated domain provides the fundamental basis of trust because it is the method by which application level cryptography is actually implemented. But application-level cryptography can quarantine the consequences of a compromise of isolation of the lower layer, thus ensuring that a successful attack on one device does not mean that the whole system is broken. Such cryptographic ‘fire breaks’ are necessary because any device can be compromised, but they are computationally expensive and must therefore be used sparingly. What is not clear is how these two interrelated and mutually supportive approaches are best combined.

1.2

Outline of the thesis

This thesis consists of eight chapters plus appendices. Chapter 2 provides background on trusted computing hardware. It examines its defining feature - physical protection via tamper evidence, tamper resistance or active tamper response. It

1.2. Outline of the thesis

5

then reviews the security services that trusted computing hardware can provide, including confidentiality and integrity protection for both data and code, and describes how these can be used in a larger systems context. Trusted computing hardware’s relationship to availability is a complex mix of advantage and pitfall so we spend some time exploring the different angles. Chapter 3 begins by posing and answering the question, why are distributed systems so vulnerable? To do this, it recounts some of the history and theory of computer systems development by the US military. So-called trusted systems were developed through rigorous research to accommodate a threat model that assumed the infiltration of Trojan Horse software but could enforce its security policy nonetheless. Section 3.3 recounts the defining features of trusted systems and Section 3.4 examines the extent to which they are present in today’s commercial, mainstream operating systems. It identifies fundamental flaws in the protection architecture of current systems that makes them inappropriate for today’s threat environment. Part-way through the thesis research, the Trusted Computing Group (TCG) announced a program that aimed to address the central theme of this thesis, namely applying trusted computing hardware to improve trust in networked computing infrastructure. The concept of a Trusted Platform Module (TPM) is central to the TCG’s approach. Section 3.5 describes what the TCG style of trusted computing aims to deliver and how it goes about it. Section 3.7 examines what the addition of TCG components to mainstream operating systems actually achieves, concluding that the flaws in the protection architecture are not effectively addressed. It uses the example of a Digital Rights Management (DRM) client application to identify the necessary properties of a system that can enforce a security policy despite the assumed hostility of the platform administrator and user. These properties can only be delivered by client platforms with operating systems that base their security on domain isolation and trusted systems principles. Therefore, trusted hardware ‘add-ons’ cannot solve the problem - the nodes of a secure distributed system must base their protection on operating systems with a sound protection architecture. This is a fundamental requirement. This analysis and conclusion informs the design of an electronic health records system that we present in Chapter 7. The chapter closes with a look at the important role that hardware level virtualisation will play in accelerating the adoption of trusted operating systems. Chapter 3 is based on work that has been published [177, 174, 172, 173, 100].

6


Chapter 4 focuses on the concept of assurance. The designer of a system that integrates trusted computing devices needs a realistic assessment of the protection that can be expected against a range of threats and attackers. Conversely, it is in a vendor’s interest to maximise the perception of the ‘security strength’ of their product. There is a clearly a potential conflict of interest that independent evaluation and certification aims to diffuse. Chapter 4 surveys smart card certifications to determine whether they provide useful and realistic information to system designers. The chapter argues that certification results are often not what they appear to be and that the schemes can be manipulated to inflate the market perception of security. Chapter 4 is based on material that has been published [176]. Chapter 5 is concerned with various aspects of side channel leakage - measurable phenomena that are a result of the physical process of computation in a semiconductor device. Section 5.2 describes our implementation of a previously published correlation side channel attack on a smart card. It includes work that has been published in [178]. While investigating offensive applications of side channel leakage, we also considered whether it could have defensive uses. Section 5.3 introduces a novel communication method for distance bounding protocols that leverages the remarkably low latency of side channel information transfer. It also presents the experimental analysis on which we base our claims for the practicality of the proposal. Chapter 6 presents a design and prototype implementation for an electronic cash scheme for smart cards. A principal concern for the design is to ensure that a compromise of tamper resistance of individual devices is not catastrophic for the overall scheme. This provides the opportunity to explore the balance between trust that is derived from the execution of code in a protected environment and trust that flows from application level cryptography. The chapter includes previously published work [149]. Chapter 7 continues in the theme of practical application by examining a national scale Electronic Health Records (EHR) system. Australia is one of an increasing number of countries that has committed to build such a system. The privacy and security issues that a national EHR scheme raises are of such gravity and societal importance that they arguably set a new high water mark in this regard. It is certainly not clear whether it is actually possible to build a system that delivers all that has been promised - improved efficiency and safety without

1.3. Contributions and achievements

7

compromising individuals’ rights to privacy and control over their health information. It is however clear that for the project to have any chance of success, trusted computing hardware will need to play a central role. This chapter considers the access control requirements for an EHR system and, finding standard models lacking in expressiveness and flexibility, it proposes a novel adaptation of role based access control. The proposed model has previously been published [175]. The defining feature of the model is its support for explicit denial of access privileges, a restriction that is difficult to enforce in a way that is both scalable and secure in a large system without active central authority. We show how the unique features of trusted computing hardware can be used to address this apparent difficulty. This provides an opportunity to examine a range of issues that must be balanced when allocating the basis of trust between different layers of code and cryptography. We show how our proposed model can be implemented using an approach known as cryptographic access control, with significant scalability benefits. Our access control architecture takes advantage of a broad range of trusted computing hardware types and techniques.

1.3

Contributions and achievements

The main contributions and achievements of the thesis include the following: • We identify practical problems with the Trusted Computing Group’s TPM style of integrity protection when applied to mainstream operating systems. We provide a detailed analysis of the credential revocation requirements of the TCG proposal. • We present a survey of smart card security certifications and identify techniques that evaluation sponsors employ to artificially increase the evaluation assurance level and claimed strength of mechanisms for their products. • We propose the first distance bounding protocol that is secure against socalled terrorist fraud and is efficient enough for implementation on resource constrained devices. • We propose a novel communication method based on the principles of side channel leakage that has sufficiently fine timing resolution to detect sophisticated relay attacks on contactless smart cards. We present experimental evidence to support our claims.

8


• We propose a detailed design for an electronic cash scheme, in particular, a translation of cryptographic protocols into a command and message structure set that we have partially implemented with a type of personal cryptographic token known as the Dallas Semiconductor iButton. • We identify previously overlooked linkability issues between different divisible electronic cash payment instruments. • We propose an architecture and approach for implementing a national scale Electronic Health Records (EHR) system. We rely on trusted computing hardware to be able to implement the model in a scalable manner using cryptographic access control. The model shows how trust can be based on a combination of code executing in trusted hardware protected environment, and application-level cryptography. • We propose a novel adaptation to Role Based Access Control (RBAC) that supports policies expressed as general consent qualified by explicit denial. Our modified model is motivated by the challenges of enforcing patient consent in a large-scale distributed electronic heath records system. We describe an implementation of the model that leverages the properties of trusted computing hardware to enforce negative privileges and to deliver significant scalability benefits through enabling offline authorisation.

Chapter 2

Background 2.1

Introduction

What does it mean for a computer or distributed infomation system to ‘get it right’ ? To answer this question we need to introduce two concepts that are central to this thesis, namely trust and security. We use the term trust to denote a state of well-founded belief that a device or system will behave as expected, for a given purpose despite a level of physical or logical interference. In terms of behaviour and purpose, what might be expected? We might require a device or system to perform its function whilst maintaining some general notion of ‘security’. We use the term security to describe a process whose goal is to prevent certain undesirable events. With respect to some assets, there are three main classes of undesirable event, namely a loss of: 1. confidentiality, which results in unauthorised disclosure or access to assets; 2. integrity, which results in unauthorised modification of assets (including deletion or creation), and 3. availability, which results in a denial of service to authorised users including delay or impairment of system response time. An organisation’s security policy identifies protection goals that must be enforced to prevent such loss events and these are implemented through a combination of security mechanisms and administrative controls. But protection goals 9

10

Chapter 2. Background

must be pursued in a balanced way, because it is all too common for over-zealous controls in respect of confidentiality and integrity to result in denial of service to authorised users. If the security is so tight that it is practically impossible for people to do their jobs, this can be thought of as a loss of availablity, with unauthorised work-arounds as an effort to restore reasonable service levels. Maintaining a workable relationship between the three dimensions of security is a deep operational and research challenge that requires optimisation and tradeoff between competing interests, and in systems that deliver real as opposed to perceived security, the usability aspect of availability will not be overlooked. This is particularly so with trusted computing hardware which tends to be somewhat unforgiving and idiosyncratic. The rest of this chapter is structured as follows: in Section 2.2 we introduce further important terminology related to threats and vulnerabilities. Section 2.3 explains what we mean by the term trusted computing hardware, exploring its defining characteristics and different types. In Section 2.4 we briefly introduce attack methods on trusted computing hardware. Section 2.5 examines the security services that trusted computing hardware provides. Section 2.6 reviews application scenarios in which trusted computing hardware is useful and Section 2.7 concludes the chapter.

2.2

Assets: threats and vulnerabilities

Assets are those resources that an organisation needs to pursue its mission and discharge its legal obligations. Focusing on the information and communications technologies (ICT) side of a business, these include obvious candidates such as data, software and computer and networking hardware, but also procedural and institutional knowledge which will often be undocumented. An asset is subject to a threat when an internal or external agent has the capability and motivation to exploit a vulnerability, and thereby produce a result that is inconsistent with the security policy. A vulnerability is a property of an asset or a specific combination of assets that must cooperate to enforce the policy. For example, an attacker may be able to gain control of an operating system by exploiting a bug in some network service code which permits a procedure’s return address to be overwritten by overflowing an unchecked input buffer. The bug is a vulnerability in the software asset and the fact that the computer is accessible from a public network

2.3. What is trusted computing hardware?

11

introduces a threat, since there are known agents with the requisite knowledge, skill and motivation to exploit it. In the case of an operating system, the threat cascades to the other data assets that it protects.

2.3

What is trusted computing hardware?

Building on the terminology that has been introduced so far, we will use the term trusted computing hardware to refer to devices that justify a well-founded belief that they will enforce some defined security policy, with respect to the security dimensions of confidentiality, integrity and availability, despite a level of physical or logical interference. Their defining feature is the ability to facilitate policy enforcement despite an absence of trust in their environment. Moreover, they can provide protection in a threat model where the end user is potentially an adversary. To do this, trusted computing devices include some type of enclosure that provides a physical, protective barrier that must be breached to access the internal computing resources and data contained in the device. At their simplest, they can be thought of as a computer in a safe. They also include some type of input-output interface which is intended to provide the exclusive means by which an entity can legitimately alter or monitor the device’s internal state. Trusted computing devices have the capability to authenticate themselves to external entities who need to be able to distinguish a genuine device from an imposter.

2.3.1

Tamper resistance

Effecting a breach of the enclosure is known as tampering. A tamper-resistant enclosure aims to increase the time and effort required to gain useful access. A tamper-evident enclosure merely aims to ensure that successful tampering will leave observable signs, though it need not be difficult. Tamper-resistant devices tend to be considerably more expensive than tamper-evident ones. Tamper-proof devices do not currently exist so a system designer must assume that given enough time and resources, a sufficiently motivated and knowledgeable attacker will be able to compromise the tamper-resistance [141, 12, 10]. Therefore, the question of whether a trusted computing device will be able to perform its security policy enforcement function effectively must be answered in the context of how it is implemented, how it is used, the value it is intended to protect and the threats it is likely to encounter. In many applications, the economic

12


consequences of breaking the protection will be critical in deciding how much protection is needed. As the payoff for compromising a system increases, the effort adversaries will invest in effecting that compromise also increases. The designer seeks to ensure that the cost of breaking the system is greater than the benefit that accrues to the successful attacker. This design approach is complicated significantly by the fact that direct monetary reward is only one of many possible sources of attack motivation. For example, the realisation that a successful attack on a system may result in cost or disadvantage to the owner may motivate an attacker in the absence of direct financial gain. An organisation may wish to discredit a competitor’s system. A disgruntled former employee or contractor may wish to cause inconvenience. A freelance hacker may wish to gain recognition and prestige within a community of like-minded peers. These threats are difficult to assess within a typical financially based risk-management framework. Ongoing risk management for deployed systems demands a current awareness of attack methodologies and the vulnerabilities they expose. This is not a simple exercise and the natural market driven tendency of device manufacturers to encourage a perception that their products are unbreakable does not help. European pay TV conditional access systems were an early adopter of mass-issued, low cost trusted computing hardware in the form of smart cards, which were used in conjunction with set-top decoder boxes. These systems provide an instructive case-study in how and how not to deploy trusted hardware devices. An early design exemplifies the danger of relying too heavily on tamper resistance, wherein the same system-wide cryptographic key (necessary to decipher the encrypted, broadcast signal) was placed inside each subscriber-issued smart card. The designers must have believed that the cards were tamper-proof since the compromise of a single device would break the entire system [142] by allowing the production of counterfeit cards that are operationally indistinguishable from the real thing. Designing systems that can gracefully accommodate the compromise of tamper-resistance is a significant challenge which we will return to and examine in more detail in Chapter 6 in the context of an electronic cash scheme designed for smart cards. Manufacturers and users of commercial trusted hardware have struggled unsuccessfully to formulate a workable system for quantifying the level of protection that a given device can provide. Blaze [32] has argued that there is much to be


13

learnt in this regard from the physical security community, particularly from the rating systems for safes. For example, the US Underwriters laboratory issues ratings that quantify the number of minutes that a safe can be expected to resist a direct attack on the enclosure. Protection times are estimated on the basis of the tools used (the ratings distinguish ordinary hand tools, portable motorised power tools, cutting torches and, finally, explosives) and the evidence that the attack leaves. The locking mechanisms are also time-rated against compromise by exhaustive search and manipulation by experts and non-experts. On the basis of such time-based ratings, a security designer can specify complimentary security measures such as alarm response times or physical inspection frequency as countermeasures against the known and inevitable vulnerability of any given safe. Perhaps due to the comparative complexity and myriad possibilities for attacking trusted computing devices, current evaluation schemes do not provide this level of guidance to designers, making their task all the more difficult. We will return to this topic in Chapter 4 when we examine computer security evaluation and certification schemes and their effectiveness in quantifying the protection properties of smart cards.

2.3.2

Tamper detection and response

Since it is probably impossible and certainly uneconomical to produce a tamperproof device, tamper detection and response is a more effective strategy. This is an active and destructive approach, wherein the device is equipped with environmental sensors (light, temperature, radiation, acceleration, vibration, potted wire mesh barrier continuity etc.) which respond to signs of tampering by immediately zeroising confidential data such as cryptographic keys. The goal is to deny the attacker access to useful information or functionality. The most common way to implement zeroisation is to store sensitive information in volatile random access memory (RAM) that is powered by a battery. The battery power is removed when the sensors signal possible tampering and in theory, the data should be immediately lost. However, the phenomenon known as data remanence causes values that are stored in the same semiconductor logic elements for a long period of time to ‘burn in’ due to electromigration and, unfortunately, the values can be read even after power has been removed [114]. Moreover, freezing the semiconductor memory elements before the power is removed allows the data to be read out for a period even when the RAM is not

14


powered. The effects of data remanence can be countered to a degree by limiting the period of time that a memory cell holds the same value [114]. Overwriting memory cells with successive zeros and ones can also make data recovery more difficult. Lower cost trusted computing devices such as smart cards and USB tokens do not have their own power source so they must store their secrets in non-volatile memory. Consequently, they cannot employ active response measures when they are not powered, and this seriously limits the level of protection that they can provide. This vulnerability must be countered in the overall system design.

2.3.3

Hardware types

Trusted computing hardware comes in many different shapes and sizes, reflecting the broad range of application scenarios in which tamper evidence, response and resistance is useful. We now review the main classes by form factor. Coprocessors Trusted coprocessors were developed to provide a secure usage and storage environment for sensitive cryptographic keys. Tygar and Yee [207] provide an early theoretical treatment. In commercial application, their development was driven by the needs of the banking industry, particularly for Automatic Teller Machines (ATMs), motivated by the fact that standard computer operating system access controls were not considered to be robust enough to protect cryptographic keys against insider attacks by development, administrative and maintenance personnel [8]. In Chapter 3 we will examine the difficult problem of securing information against users who have administrative access to a general purpose computing platform, in the context of an analysis of the security requirements for a Digital Rights Management (DRM) client. Trusted coprocessors include tamper-resistance features but they derive their protection strength primarily through tamper-detection and zeroisation response. The IBM 4758 [87] and its recently released successor, the 4764 are leading and popular examples. They are based on an Intel 80486 processor that is encased in a potted protective wire mesh and metal case, with a PCI-based input-output (I/O) interface. They include environmental sensors to detect probe penetration, temperature, radiation and power manipulation attacks. They cost several thousand dollars each.


15

In addition to physical security sensing and response circuitry, trusted coprocessors typically include dedicated hardware implementations of asymmetric and symmetric cryptographic algorithms, volatile and non-volatile memory and a hardware-based source of randomness. Cryptographic accelerators that are used in e-commerce applications, particularly to handle processing intensive protocols such as TLS/SSL [85] are another type of secure coprocessor. The IBM 4758 provides a useful case study for secure coprocessors as its objectives, design, implementation and evaluation are well documented [199, 200, 198]. Smith and Weingart [201] report that the key challenges in developing a practical secure coprocessor include: • allowing different entities who do not necessarily trust each other to develop the coprocessor’s OS, applications etc., • permitting secure updating of software on the device even when deployed in a hostile environment, • delivering a high level of assurance that the boot security and trusted device identification cannot be subverted by the OS or applications. To meet these challenges the IBM 4758 employs an innovative system of hardware locks that control access to segregated memory pages where secrets are stored. The hardware lock checks the value of a privilege ratchet register (which holds a positive integer value) before granting access. Incrementing or ratcheting the register value closes access to successive pages of a hierarchy of memory pages. This register is incremented at each stage of booting. The register is increment only so for example, the OS cannot access device secrets used during boot as the privilege register would hold an integer that exceeds the value that would permit the lock to grant access. This is an extension of a concept described by Lampson [144]. Secure booting is discussed in more detail in Section 3.5.3. One of the difficulties in designing a system that uses a secure coprocessor involves partitioning the functionality between the trusted environment of the coprocessor and the untrusted external environment. There are security benefits associated with executing as much functionality as possible inside the coprocessor. However, a coprocessor’s memory and processing resources are considerably more restricted than those of the typical server in which they are installed. To address this limitation, the application needs to be split and an application programming interface (API) defined, by which less trusted external code calls on

16


and utilizes services offered by the coprocessor. Designing such an API is a notoriously difficult and subtle exercise. Bond [37] has noted that insecure states can often be reached by combinations of instruction calls that were not anticipated by the designer. This is an emerging area of application for formal methods of design and verification. Personal cryptographic tokens Unlike coprocessors which are semi-permanently installed in servers, ATMs and general purpose computers, personal cryptographic tokens are intended to be carried by an individual. Their principal use is for user authentication, and authorisation. This class of hardware includes smart cards, USB tokens, iButtons, and cryptographic one-time password generators. The characteristics of smart cards are specified by the ISO/IEC 7816 family of standards. They are low cost devices that are issued to users en masse. Having the same physical form-factor, they were developed as a more secure replacement for magnetic stripe cards. One of the earliest smart card projects was implemented in 1977 by the French Banking Association, Cartes Bancaires [90]. The primary goal was fraud minimisation. At that time the French telecommunications infrastructure could not reliably and economically support on-line credit authorisation. This contributed to the unacceptable levels of fraud that the banking community experienced. Since smart cards are able to execute cryptographic algorithms in their protected internal environment, the new technology facilitated off-line authentication and authorisation. The smart card acted like a ‘watch dog’, independently protecting the interests of its master (the bank), and fraud losses were significantly reduced. Cryptographically enabled smart cards include a single chip with an 8, 16 or 32 bit microprocessor, read only memory (ROM) for storage of an operating system and application code, non-volatile rewritable memory known as EEPROM for storage of personalisation and application data, and a small amount of volatile random access memory (RAM). More advanced cards include dedicated hardware implementations of cryptographic algorithms and a hardware-based source of randomness. Smart cards are reliant on an external source of power so they cannot employ tamper responding techniques when they are not active. Contactless smart cards are gaining in popularity, particularly in public transport ticketing and physical access control, due to their convenience and fast trans-


17

action times. They communicate with a reader wirelessly, via inductive coupling. In Chapter 5 we will consider defensive measures against a powerful type of attack on contactless cards known as a relay attack. USB tokens and iButtons1 are also typically based on single-chip microprocessor architectures similar to smart cards but they differ in their packaging and input/output interface. The Dallas Semiconductor iButton is an interesting hybrid of a secure coprocessor and a smart card since it has active tamper-responding zeroisation features that are made possible by the inclusion of battery backed RAM. Yet the device is small enough to be portable, even worn as jewellry. The electronic cash scheme prototype that we describe in Chapter 6 uses the Java iButton. PCMCIA cards such as the Fortezza card [160] fall somewhere between coprocessors and personal tokens in that they are removeable and easily portable (though somewhat larger and less robust) but can also include tamper-responding zeroisation features. Trusted platform modules Trusted Platform Modules (TPMs) are a more recent trusted computing development promoted by the Trusted Computing Group (TCG), a consortium of major computing organisations including Intel, AMD, Microsoft, IBM, Hewlett Packard, Sun Microsystems and Sony. A TPM equipped device can assert and authenticate its software configuration to a remote, independent entity through a security service known as remote attestation. TPMs are based on smart card style single-chip microprocessors that are permanently attached to the device that they are intended to secure. According to the TCG, platforms that can benefit from the addition of a TPM include general purpose PCs, laptops and servers, handheld computing devices, gaming consoles, set-top boxes and mobile phones. Since TPM’s are intended to be included in mass produced computing devices that are highly cost-sensitive, their features are simple and their resources somewhat modest. Current TPMs offer similar levels of functionality and performance to the smart card microprocessors on which they are based. Notwithstanding their simplicity, the TCG argues that TPMs can provide a basis for enhanced trust for existing computer architectures in a manner that supports considerable backward compatibility. The general design 1

See the iButton home page at www.ibutton.com/.

18


approach belies a considerable measure of commercial pragmatism, reflecting the interests of the large hardware and software companies that are members of the group. The quest for backward-compatible solutions to security problems that result from fundamental flaws in existing architectures is bound to be a difficult one and we expose some of the challenges and fallacies in Chapter 3.

2.4

Attack methods

Kömmerling and Kuhn [141] distinguish four types of attack on smart cards. These categories are applicable to trusted computing hardware in general: 1. Microprobing techniques: a physically invasive attack class that seeks to directly monitor electrical signals to compromise keys, confidential data and code. This category may also involve the destruction or modification of logic elements and environmental sensors to bypass protection mechanisms. It uses tools and techniques derived from semi-conductor engineering. 2. Software attacks: exploit vulnerabilities in the design or implementation of algorithms, protocols or executable code using the standard communications interface. 3. Eavesdropping attacks: also known as side channel analysis. This class of attack exploits the physical phenomena that are a side effect of semiconductorbased computation. It uses advanced statistical techniques to analyse power consumption, electromagnetic emanations and timing data to infer information about the internal state of the device. Side channel leakage attacks are examined in more detail in Chapter 5. 4. Fault generation: an attacker may generate useful faults by careful manipulation of the power supply or clock signal in devices such as smart cards that source these externally. Exposing the device to radiation or temperature extremes or intense light can also induce faults that can be exploited to compromise cryptographic keys. Fault attacks are particularly powerful and difficult to defend in an efficient and cost effective manner [25].

2.5. Security services provided by trusted computing hardware

2.5

19

Security services provided by trusted computing hardware

Trusted computing hardware is used to provide confidentiality and/or integrity protection for code and/or data in untrusted and potentially hostile environments. Moreover, confidentiality and integrity services can be combined to provide an authentication service for the device itself, and in the case of portable tokens, as a proxy for user authentication. Authentication is vital since it allows an external entity to determine whether it is communicating with a genuine, untampered device or a clever impostor. Trusted computing has a complex relationship with availability which we will consider in some detail in Section 2.5.6.

2.5.1

Data confidentiality

Cryptography implicitly assumes that crypto-variables or keys can be kept secret both in long-term storage and when being used. The protection of cryptographic key material is the primary reason that trusted computing hardware exists. This is particularly so since the bulk of the security services that trusted hardware provides are cryptographically derived. Many trusted computing devices also include a hardware-based source of randomness from which crypto-variables (session keys, challenges etc.) of sufficient entropy can be sourced. A trusted hardware device provides a data confidentiality service in at least three senses: 1. by keeping cryptographic key data secret; 2. by executing cryptographic algorithms that encrypt plaintext data and decrypt ciphertext. Once plaintext data is encrypted, it can safely leave the protected environment of the trusted hardware whilst remaining confidential. Trusted computing hardware can participate in key agreement protocols to establish confidentiality protected channels. 3. by storing confidential or sensitive data, (e.g. medical records or biometric templates) and employing access controls to ensure that it is only released to authorised entities.

20


2.5.2

Code confidentiality

Trusted computing hardware may also provide confidentiality for executable code. Code confidentiality has been applied to the problem of software copy protection. Best [29] proposes perhaps the first scheme of this type wherein critical parts of an application are stored encrypted. White and Comerford [215] refined the idea in their ABYSS architecture. Only the trusted hardware device holds the decryption key and it acts as a service provider, executing the protected functions on behalf of to the unprotected application code. To be effective, the unprotected application code should be of no use on its own. Moreover, it should not be practical to reverse-engineer the protected code by monitoring function calls and responses. In practice, this is quite difficult and the technique has not been widely adopted. Code confidentiality may be useful for protecting proprietary or secret cryptographic algorithms. A system that relies on the secrecy of an algorithm for its security violates Kerckhoff’s principle which states that no inconvenience should occur if the system falls into the hands of the enemy, because all security should reside in the secrecy of the keys [134]. The pursuit of security by obscurity is poorly regarded in some circles, perhaps with good reason. Secret algorithms such as A3 and A8 used in GSM mobile telephony were developed in a closed environment without the benefit of analysis by the wider, unclassified cryptographic community. When they were subsequently reverse engineered, significant weaknesses were identified and they are now considered broken [44]. Notwithstanding some significant security failures associated with secret and proprietary algorithms, they are still employed in military circles2 and in smart cards which use them for bus encryption and other related internal protection features that are intended to increase the difficulty of probing attacks and reverse engineering.

2.5.3

Data integrity

Trusted computing hardware can be used to provide integrity protection for data. An integrity protection service identifies and/or prevents unauthorised alterations to data or the fabrication of new data. The data may be stored within the 2

Military cryptography does generally have the benefit of thorough review by internal experts. For example, the United States National Security Agency (NSA) reportedly employs thousands of mathematicians [24]. Moreover, algorithm secrecy is intended to forestall cryptanalysis though military ciphers could reasonably be expected to provide a significant degree of protection even if the algorithms were known.


21

device or in external memory. We deal firstly, by way of example, with integrity protection via tamper resistance and response. Some smart card-based electronic cash schemes represent currency as a number stored in a protected memory register (a counter). To maintain the security of such a scheme it is vital that any alterations to this register occur only via wellformed increment or decrement transactions. An increase in one device’s register must only occur if there is a corresponding decrease in the register of another device. An attacker who could manipulate the register at will could fraudulently introduce funds to the system by arbitrarily increasing a counter. The tamper resistance property of a trusted computing device can provide a degree of physical protection against direct alteration of a value stored in memory. Active tamper response mechanisms can detect such attempts and render the device inoperable. We will examine data integrity issues associated with electronic cash in detail in Chapter 6. Hash functions, message authentication codes (MACs) and digital signatures provide a logical, as opposed to physical integrity protection service. The reader is referred to Menezes et al. [152] for a description of these terms. Logical protection builds on physical protection. For example, a trusted hardware device can calculate and store internally, the hash value of some data. The hash value represents a compressed fingerprint of the data that will be dramatically different even if there is as insignificant as a one-bit change in the underlying data. It distills the essence of an arbitrarily large bit sequence into a relatively small and fixed-length bit sequence. Subsequent modifications to the large bit sequence (the data) can be detected by recalculating the hash value and comparing it with the physically protected and therefore trusted, reference value. Assuming the soundness of the collision-resistance properties of the hash function, the data can be stored in an unprotected environment, without risk of undetected modification. If the trusted hardware device holds an asymmetric cryptographic key-pair it can create a digital signature by transforming the hash value with its private key. It no longer needs to physically protect the reference hash value or indeed the signature because of the property of asymmetric or public key cryptography that valid signatures can only be created with knowledge of the private key. Assuming the confidentiality of this key, any entity with the matching public key can verify the signature and conclude that it was generated by the device. Thus we see that a small amount of confidential data protected by physical means can be leveraged

22


to provide logical integrity protection for an arbitrarily large amount of data. Unauthorised substitution of current versions of integrity protected data by superseded though authentic prior versions can be prevented by digitally signing a concatenation of the hash value and a time stamp or monotonic counter. It is also worth noting that MACs can provide largely equivalent functionality to digital signatures but the underlying cryptographic primitive is a symmetric algorithm which is considerably more efficient. Personal identity tokens such as smart card based driver licenses and passports rely on these integrity protection techniques. An issuing authority digitally signs a hash of a record containing personal identity attributes and perhaps a biometric template which are stored, together with the signature in the smart card. Assuming the availability of the necessary public key infrastructure, a third party can validate the signature on the data to determine whether it is genuine. An attacker would require access to the authority’s private signing key in order to create a valid signature on invalid data. Note that the physical, tamper resistant properties of the smart card are not required to protect the data since this is achieved by the logical protection of the signature. The smart card is required to protect a secret key which is used to prove that the physical card object is a genuine, authorised one. Without this, authentic data and its associated signature could be installed in a fabricated token which would be logically indistinguishable from the genuine article.

2.5.4

Code integrity

Trusted computing hardware can provide physical and/or logical integrity protection for the code that the device itself executes. It can also provide logical integrity protection for code that runs on external processors as is described in detail in Chapter 3. Protecting the integrity of correct code is vital to ensuring that it continues to execute correctly and thereby plays its part in enforcing the security policy. Protecting the integrity of vulnerable code is quite a bit less productive but, as we will see in Chapter 3, it is an increasingly popular pursuit. The absence of integrity protection creates an opportunity for targeted subversion. Code is just binary data so the protection techniques are much the same as those described in the previous section, however there are some notable practical subtleties. For example, Kömmerling and Kuhn [141] consider the problem of protecting the integrity of a smart card operating system which will typically


23

be stored in ROM. Since the card has no active tamper responding mechanisms when it is not powered, an attacker may have succeeded in physically modifying the ROM code in between boot cycles via an invasive attack. The device security policy will commonly require that such modifications be detected. One way to achieve this would be to hash the OS code and compare the hash to a trusted reference value early in the initialisation process. The unfortunate side effect of doing so is that all the bits that represent the operating system will be passed over the bus lines. An attacker could monitor the bus via a carefully placed probe and gain convenient access to the entire operating system code which may greatly assist further reverse engineering. Encrypted bus lines may ameliorate the problem but this transforms the problem into one of protecting the encryption key which must also reside on the card. The reference hash value also needs to be protected. This is typical of the conundrums that a smart card designer must resolve. Often a protection measure that defeats one type of attack makes another easier.

2.5.5

Confidentiality and integrity - authentication

Confidentiality and integrity services in combination can provide a means to authenticate a device to a third party. Firstly, we will consider the relevance of confidentiality to authentication. Authentication is the process of verifying a claimed identity. We use the term remote authentication to refer to authentication over a public data communication channel. All methods that facilitate remote authentication make use of confidential data of some kind. We will now refer to such confidential data as a key. If the key is unique to the associated identity3 then only a genuine claimant will have the capability to perform a keyrelated mathematical transformation by which they can be distinguished from non-genuine claimants. The mathematical transformation allows a claimant device to prove that it has the key in its possession and control. The verifier infers the identity of the claimant on the basis that no other entity should know this key. Physical protection of the key to prevent its disclosure to third parties is therefore a precondition to the validity of this inferential conclusion. When the underlying cryptographic primitive used in the authentication protocol is a symmetric algorithm, the claimant and the verifier must both have 3

It should also be randomly drawn from a key space that is sufficiently large to reduce the probability of it being guessed by a brute force search to an acceptably low level.

24


prior knowledge of the same key. An authentication protocol based on an asymmetric cryptographic primitive can deliver an additional property known as nonrepudiation. The property of non-repudiation prevents an actor from making a plausible, yet false, denial of participation in an event that required use of a private key that is under their exclusive control. Asymmetric or public key cryptography differs from symmetric cryptography in that the verifier does not need to know the private key. A separate but related public key is used to verify a transformation that can only be performed with knowledge of the private key. Again, key confidentiality is vital to establishing the precondition of exclusive control. This is an area where trusted computing hardware has a unique strength. If the device includes a secure source of genuine randomness, it can generate a new public/private key pair within the confines of the protective enclosure. Since the private key need never leave the enclosure, it adds compelling weight to the argument that it is under the device’s exclusive control. This leads us to the relevance of code integrity to authentication. The mathematical transformation will be mediated by code which has access to the secret key. It is therefore vital that this code not be altered to abuse its access by leaking the key outside the enclosure. Indeed, we would like to deny code that has been altered in any way, access to the key that it uses to authenticate itself remotely. In Section 2.3.3 we described how the IBM 4758 coprocessor uses a system of hardware based ratchet locks to ensure that only unaltered software layers are able to access the keys that they use to authenticate themselves to external parties. With this approach, the ability to successfully authenticate directly implies the current integrity of the code for that layer and all those beneath it. This can be integrity with respect to general application security policy enforcement, not just key confidentiality. In Chapter 3 we will examine a different and possibly more flexible approach to the same problem that has been adopted by the Trusted Computing Group.

2.5.6

Availability

Availability is a property of an information system that ensures that its services are accessible to authorised users and usable when required [146]. In distributed systems the notion of service presupposes the availability of necessary data, computational resources and communication bandwidth. It connotes both a bounded waiting time for access and delay time to transaction completion, which requires


25

adequate capacity to meet current demand [145]. In the absence of malicious interference or denial of service (DoS) attacks, availability is largely a challenge of engineering capacity to match load, performing maintenance to forestall hardware or software failures and providing redundancy and/or recovery mechanisms to deal with them should they occur. DoS attacks are conscious actions that are intended to destroy, modify or degrade a service provided by an information system. As Leiwo [145] notes, engineering for denial of service resistance is a far more complicated challenge because attackers are creative, resourceful and less predictable than the general incidence of faults and failures. The relationship of trusted computing hardware to availability and denial of service is complex and certainly not always positive. Availability concerns are of great practical importance in systems that employ trusted computing hardware for a number of reasons: • Trusted computing hardware is normally positioned at critical points in a business process, so the service it provides is vital for operations. • Trusted computing hardware is defensive in orientation and designed to ‘fail safe’ which may result in a loss of operationally important data in the event of hardware failure or tampering. • Tamper responding mechanisms may falsely interpret data from environmental sensors and zeroise important key material when there is no actual threat. Alternately, an attacker may have the simple goal of triggering a sensor to force zeroisation and denial of service. This may disable a more secure protection system resulting in a fail-over to a less secure back-up mode of operation which is easier to attack. • The computational resources and I/O channel communication bandwidth of trusted computing hardware is often limited compared to the general purpose computing platforms that it services. It will often be the bottleneck that upper-bounds the transactional throughput of a system. To what extent can trusted computing hardware and more specifically, cryptography assist with availability and denial of service protection? With respect to communication, cryptography cannot be used to guarantee the availability of the

26


communication channel itself, since this must firstly be assumed along with processing resources. Cryptography can secure this channel with its confidentiality and integrity services but these are independent of availability. If cryptography cannot guarantee that which it must firstly assume, to what extent can we use confidentiality and integrity services to prevent a degradation of availability that results from intentional interference, i.e., DoS attacks? In this scenario the channel is still available to carry traffic in general, however, availability may be impaired by the presence and effects of undesirable traffic. This is an important question and to answer it we need to distinguish two types of DoS attack: 1. Logical attacks: a logical attack results in a denial of service through exploiting a vulnerability in protocol logic or its implementation. A process is forced or induced to perform an action that is inconsistent with correct operation. The Morris Worm [203], released in 1988, was one of the earliest examples of a self-propagating logical attack. It exploited implementation flaws in a number of network services, seriously impairing system availability, indeed the availability of the Internet as a whole. Failure to validate the format, syntax or length of input data from a protocol peer is the most significant source of logical attack vulnerability [17]. Failure to authenticate the source of an instruction or request is also a common design flaw. 2. Flooding attacks: flooding attacks seek to overwhelm and exhaust the network bandwidth, processing or storage resources of the target. The SYN flood attack was an iconic example [154], wherein an attacker sends a flood of TCP connection requests with spoofed source addresses. The target allocates storage resources for each half-open connection. In early TCP/IP implementations, only a relatively small number of half-open connections were allowed. The attacker’s connection requests quickly exhausted these so that legitimate users were denied the ability to connect. Cryptography provides useful techniques to avoid logical attacks. As we noted in Section 2.5.5, integrity and confidentiality protection can be used to authenticate the source and content of a message before acting on it. An attacker cannot forge or alter a message without knowledge of an authorised entities’ secret key. Similarly, trusted computing techniques allow us to authenticate a protocol peer’s integrity protected software stack to gain confidence that it will behave correctly and follow a pre-agreed transactional specification [198].


27

It is theoretically possible to eliminate denial of service vulnerabilities based on logical attacks through appropriate protocol design, careful implementation and integrity protection. However a design that is immune to logical attacks is likely to be more susceptible to flooding attacks. The inter-relationship exists because the protections that ensure that a host will not act on a forged or altered message require the host to perform calculations to assess message integrity and authenticity. The calculations require additional time and effort. By sending the host bogus messages, the attacker consumes finite processing resources of the target with a minimal commitment of its own. The messages will fail the integrity test if the attacker does not know the secret, but nonetheless, the host must perform the calculations before it can recognise the forgery. There is an asymmetry between the minimal effort required of the attacker to commit the receiving process to a much greater amount of work. If the attacker can access sufficient bandwidth to send a large number of unauthentic messages, the host’s capacity to authenticate them can be overwhelmed to the point where legitimate requests cannot be handled in a timely fashion. Denial of service results. To avoid this problem the host must be able to authenticate messages at the highest possible rate that they could arrive, i.e. the message processing capacity must be matched to the message carrying capacity (bandwidth) of the connection. With the growth in network bandwidth currently outstripping the growth in processing power, this is an increasingly difficult balancing act. It also results in the over-engineering of processing capacity, a potentially inefficient allocation of resources, since the message handling capability may far exceed the requirements of legitimate traffic. The overhead of cryptographic message integrity protection only exacerbates the imbalance. There is no simple solution to this issue. Logical attacks that exploit unauthenticated messages are powerful and highly effective. Flooding attacks that consume all processing, storage or bandwidth resources are powerful and highly effective. In a system that includes network accessible trusted computing hardware, the designer must strike a balance between the benefit of robust logical attack prevention and its associated cost: flooding attack vulnerability.

28


2.6

Applications

In their foundational work on the secure coprocessors, Tygar and Yee [208, 207, 217] identified a range of potential applications for trusted computing hardware that exploit the security services we have just described. These include: • software copy protection; • electronic cash; • electronic postage meters; • electronic contracts; • integrity protected audit trails; • host integrity checking. We discussed software copy protection in Section 2.5.2 and electronic cash in Section 2.5.3. Electronic postage meters are based on similar principles to electronic cash and these principles can be generalized to the concept of electronic contracts wherein, one trusted computing device authenticates the ability of another to enforce a policy with respect to some information objects via the service of code integrity. Tygar and Yee refer to this as host integrity checking. Once authenticated, the devices exchange integrity protected data to execute transactions which respect and enforce the contract (a security policy and more detailed transaction specification). As Tygar and Yee noted, contracts of this type are the basis of any secure, distributed system and therefore, all such systems can be seen to rely on some type of physical security, since physical security is ultimately required to protect the confidentiality of cryptographic keys. As we noted in the Section 2.5.5, assurance of the secrecy of keys and the integrity of code are necessary preconditions for secure remote authentication. Remote authentication in turn supports confidence in the ability of another platform to enforce a security policy and that confidence is the basis for cooperation and trust in any distributed information system.

2.7

Conclusion

The threat environment that today’s computing infrastructure is exposed to has been transformed by the widespread adoption of distributed computing archi-

2.7. Conclusion

29

tectures connected by public internetworks. Communication exchanges between information system nodes require protection and the nodes themselves must be defended against attacks that originate from the network, from authorised users or via attackers with direct physical access. We rely on the security services of confidentiality and integrity protection to do this job. These services in turn assume that cryptographic keys can be kept secret and trusted computing hardware has emerged as a technology capable of providing the necessary physical protection to do this. By virtue of its physical properties, trusted computing hardware is capable of supporting a well founded belief that a security policy will be enforced, despite the fact that the device’s immediate environment or authorised user’s may be considered hostile. This property is an indispensible foundation on which secure distributed systems can be built.

30


Chapter 3

Trusted computing and trusted systems 3.1

Introduction

One does not need to be a computer security specialist to recognise the growing crisis of computer insecurity - a situation that is deteriorating rather than improving. There are regular reports in the popular press of virus and worm attacks and successful hacking incidents where critical government, finance or healthcare networks have been compromised. Yet this realisation has not stopped the headlong rush to place more and more critical services under the control of computers. Consequently there are more systems to protect, and these systems present an increasingly attractive target to a broad range of perpetrators including hackers, criminals, terrorists, activists, and competing organisations. Inadequate computer security has serious consequences, as has been amply documented by Neumann [157] including threats to human safety, violations of privacy and significant economic loss. These issues have been explored and analysed at length (for example see [193, 161, 106]). Perhaps in response to this situation, there has been a resurgence of popular interest in a concept described variously as trusted computing and trustworthy computing. This has largely been driven by two recent IT industry initiatives, namely the Trusted Computing Group (TCG) specification [205] and Microsoft’s Next Generation Secure Computing Base (NGSCB) [170], formerly known as 31

32

Chapter 3. Trusted computing and trusted systems

Palladium. These initiatives share the aims that we described in the previous chapter, namely, to deliver systems that operate reliably and predictably for the purpose they were intended, being highly resistant to subversion by malicious adversaries. Given the way these initiatives have been promoted, a casual observer could be forgiven for thinking that trusted computing is an entirely new concept. As we discuss in Section 3.3, trusted computing (or trusted systems as it was more commonly known) actually has a long history but the lessons this history can teach have been largely ignored over the last 20 years. As a consequence, our deployed computing infrastructure has been designed for a benign operating environment. It is fundamentally ill equipped to deal with motivated internal and external attacks that are such a prevalent feature of today’s networked computing landscape. This has lead to a situation of widespread vulnerability where computing systems present a serious and systemic risk for which there are no quick fixes. Not surprisingly, the ongoing development of trusted computing technology to secure the computing resources used in critical commercial, government and industrial infrastructure is seen as vitally important [161]. But the same technology can be used to secure systems that mediate the distribution and consumption of digital entertainment ‘content’. The application of trusted computing technologies in this setting has been highly controversial because it paradoxically threatens to reduce the level of transparency and control that a platform user or owner can expect [11]. Indeed, the owner of the computer can be viewed as an adversary since they may be motivated to violate the content protection policy that their platform is expected to enforce, for example, to gain unrestricted access to a movie for which they have only paid for a single-view license. When a third party has the capability to define and enforce an access policy on a machine that they do not own or directly control, potentially against the interests of the owner/administrator, serious issues of public policy are implicated. Yet this ability provides the basis for cooperation and trust in increasingly interconnected distributed systems that span independent security and administrative domains. In this sense, trusted computing is yet another example in a long list of technologies that offer great benefits along with significant risks. This chapter expands the focus from trusted computing hardware that was introduced in Chapter 2 to the broader systems that it is intended to secure. It

3.1. Introduction

33

attempts to place recent developments within a historical context, by reiterating key principles of secure computing that were developed in the 1960s, ’70s and ’80s. The commercial computing industry has displayed widespread, willful forgetfulness in failing to apply this knowledge and the negative consequences will continue to flow, despite the new trust technologies, until these basic principles are operationally observed. An overview and a summary of the main contributions follows: • In Section 3.3 we review the essential properties and features of trusted systems - high assurance computer systems originally designed for military use. Section 3.4 presents an analysis of the extent to which current mainstream operating systems1 implement these features. The conclusion that they are generally absent motivates an examination of the protection architecture flaws of such systems, thus providing a rigorous explanation for their insecurity. • In Section 3.5 we provide a detailed description of the important features of the TCG specification (formerly TCPA)2 . The specification was developed by commercial organisations without the benefit of input or prior public examination by the wider academic security community. As such, an analysis of its key strengths and weaknesses was much needed. • In Section 3.6 we present the first detailed analysis of the revocation requirements inherent in the TCG design, highlighting subtle problems and the practical challenge that revocation presents in this context. We explore ways of reducing the trust that must be placed on the Privacy Certification Authority, and provide concrete suggestions to achieve this goal. • Drawing on Digital Rights Management (DRM) as an example application, in Section 3.7 we ask the question: to what extent do mainstream operating systems need to be modified to make use of key TCG features. In answering this question, we highlight reasons why the architecture of mainstream 1

As was noted in Chapter 1, the term mainstream operating system is used to refer to popular commercial operating systems such as Windows NT, 2000 and XP from Microsoft Inc, Linux and various versions of Unix that implement a discretionary access control policy. 2 This work is based on a previous publication [177] which provided a TCPA description, derived from analysis of the specification at a time when very little had appeared in the academic literature and there was a great deal of hyperbolic misinformation in the popular press. It aimed to contribute some accuracy and balance to what was at the time, a rather biased discourse.

34


operating systems undermines their ability to make meaningful use of TCG integrity reporting features. We explain in detail why mainstream operating systems are an inappropriate platform on which to base a DRM client. We clarify why DRM platforms require an operating system that can enforce mandatory access control. We aim to address common misunderstandings as to the extent to which the TCG specification implements DRM. A key conclusion of our analysis is that the addition of TCG components to a discretionary access control enforcing operating system does not result in a ‘trusted system’ that can reliably enforce DRM licenses. • We identify problems with the TCG sealed storage feature that flow from the non-deterministic order of execution of a multi-tasking operating system. We assess the expected prevalence of unrecognised object fingerprints and identify the problem they create. We argue that they seriously undermine the effectiveness of the TCG remote attestation feature when it is deployed on mainstream operating systems, to the point of calling the viability of the whole approach into question.

3.2

Vulnerabilities in distributed computing infrastructure

Why are our systems so vulnerable? There is general consensus (see for example, [84, 148]) that a major contributing factor has been the widespread adoption of general commodity level software and operating systems or so called COTS (commercial off-the-shelf systems). COTS place a higher priority on added features and flexible ease of use, which come at the price of reduced security and trust. Additional functionality increases system complexity and there is an inverse relationship between complexity and security. Flexible, feature rich systems are more likely to contain bugs and flaws that an attacker can exploit to subvert the expected behaviour of the system. The prevalence of vulnerable COTS products cannot be wholly explained by a lack of understanding of how to build secure systems. Up until recently, the commercial software marketplace has simply failed to demand products with well designed and rigorously implemented security features. Good security engineering does not come for free and since customers have not been willing to pay, vendors

3.2. Vulnerabilities in distributed computing infrastructure

35

have made a commercial decision not to provide it. While this may have been a rational individual choice for a large number of companies, the effect in aggregate has been a ‘tragedy of the commons’ - the guiding hand of self interest is not producing a favourable outcome at a societal level. If security is considered at all in COTS design, it is more commonly as an afterthought, yet it is a well accepted tenet of security engineering, that to be effective, security requirements must be an integral part of the system design, (see for example, Anderson [10]). Moreover, since the same COTS software is deployed in many organisations, an attacker can exploit a single vulnerability to compromise multiple systems. The rapid worldwide spread of worms such as NIMBDA, Code Red and Slammer underline the extent of collective vulnerability that flows from the widespread use of COTS [137]. The dominant response to address computer system vulnerability has been improved perimeter protection - firewalls, intrusion detection systems, email virus scanning, etc. The premise of this strategy is that perimeter guards will be able to identify and block attacks before they infect vulnerable systems. There are a number of problems that challenge the viability of this approach in the longer term: • Attacks are increasing in stealth and sophistication so as to avoid detection by perimeter filters. • Viruses, worms and other exploit tools are being developed and released within shorter timeframes, often before security patches are available and virus signatures distributed to detect the exploit code. • Signature based detection methods cannot detect an exploit that has not previously been seen so they cannot eliminate vulnerability. • End-to-end cryptographic protection hides packet data from perimeter filters rendering potentially malicious traffic invisible. • Distributed computing paradigms such as grid computing and web services rely on potentially malicious mobile code that can be downloaded over the network and executed locally. The perimeter filter may not understand the semantics of such code so it will be unable to decide whether it is dangerous or benign. • Attackers have easy access once the perimeter has been breached.

36


• The perimeter defences themselves are based on the same vulnerable COTS products. • Perimeter defences cannot adequately address the serious threat from authorised insiders. Moreover, the perimeter is becoming increasingly difficult to define as corporate networks open up access via wireless access points, Internet connections to suppliers, customers, outsourcing partners, contractors, remote employees, etc. The focus on perimeter protection ignores the real problem, which is the inherent vulnerability of the nodes in the network - workstations, servers, laptops, embedded systems, etc. Loscocco et al., [148] argue that the vulnerability is inherent because “the computer industry has not accepted the critical role of the operating system to security, as evidenced by the inadequacies of the basic protection mechanisms provided by current mainstream operating systems. ... Current security efforts suffer from the flawed assumption that adequate security can be provided in applications with the existing security mechanisms of mainstream operating systems. ... any security effort which ignores this fact can only result in a ‘fortress built upon sand’. There are two perspectives of trustworthiness that are desirable for networked computing platforms. Firstly, the platform owner and user should be able to trust the platform in its current configuration to enforce reasonable security policy requirements with regard to confidentiality, integrity and availability. This demands a combination of operating system and hardware protection features that are examined in Section 3.3. Secondly, and reflecting the importance of networking and distributed systems, a platform should be able to directly communicate its trustworthiness to another platform in a manner that the second platform can rely on - this necessarily goes beyond emphatic assertion. The first aspect has proven to be surprisingly difficult in practice. While the notion of ‘enforcing the security policy’ is expressed as a positive requirement, the difficulty arises because it is actually a negative one - the policy is enforced by ensuring that certain things do not happen. To do this, the design, implementation and current configuration of a system must combine to anticipate and counter every possible threat. While the platform administrator must maintain

3.3. Trusted systems

37

a system that is completely free of exploitable vulnerabilities, an attacker only needs to find a single weakness. The administrator’s task is considerably more difficult because experience has shown that attackers are creative and resourceful in ways that are impossible to fully anticipate. The second aspect, which is concerned with providing a basis by which remote computers can establish trustworthiness, is a more recent development3 . It has become particularly important due to increased reliance on cooperating networked computers that are under the administrative control of different entities, but are required to trust each other. Web services and grid computing are good examples. Finally, it is worth noting that a security strategy based solely on preventing attacks is doomed to failure. Networked computers are highly complex systems that cannot be made perfectly secure, therefore a cost effective security management strategy will also include elements of detection and response. However, detection strategies are currently being overly emphasized and without increased efforts aimed at prevention through sound design, the ‘security crisis’ will only worsen.

3.3

Trusted systems

This section provides a historical background to trusted systems and reviews their defining features and properties.

3.3.1

Historical background and context

Trusted systems is a term used to describe the high assurance computers that were developed to address the needs of the military from the mid 1960s. While they were required to address broadly similar aims to the contemporary notion of trusted computing, there are key differences in emphasis and approach. These are due in part to the current pragmatic need to make incremental improvements to a large base of widely deployed yet flawed infrastructure, since wholesale replacement of all vulnerable systems is unrealistic. In this respect, the efforts of the trusted computing fraternity reflect their strong commercial interests. On the other hand, the theory of trusted systems was developed through rigorous 3

The basic idea of communicating cryptographically protected statements that reflect the current configuration of a platform was introduced by Lampson et al. [144].

38


scientific research largely funded by defense and national security interests. At this time, the military did not emphasize the need for feature-rich, user friendly products. The main priority was to maintain confidentiality against motivated and well funded opponents. This demanded systems that were based on a sound theoretical foundation, and to the extent that it was necessary, flexibility and features would be sacrificed. The Anderson Report [7] issued in 1972, represented an important turning point in the development of trusted systems. In examining the state of military computer security it found that most systems were not designed to be secure from the outset and the prevalent cycle of ‘penetrate and patch’ was unlikely to ever produce secure systems. Vendors were adding security in an ad hoc manner to correct vulnerabilities that had been found by military ‘tiger teams’. The security patches often introduced new vulnerabilities for which vendors would issue another patch. Anderson recognised that what was needed was a system that was designed from the ground up to enforce a clearly articulated security policy. The system would need be built around a non-bypassable policy enforcer known as a reference monitor. The military has a hierarchical classification policy, (confidential, secret, top secret etc.) that lends itself to a rigorous mathematical representation [28], so the problem of articulating the policy and representing it in a manner that could be enforced by a computer proved to be a tractable one. Unfortunately, this was a very specific policy model that poorly suited the huge diversity of needs found in commerce, general government and industry and it would take at least another decade before practical policy models began to emerge to address non-military requirements [65]. The military policy model and its mechanism of enforcement were tightly bound in early trusted systems products so, lacking adaptability, they did not sell well to non-military customers. But the commercial sector was a considerably larger market for vendors and unsurprisingly, they developed their products to address commercial sector requirements. Since computers in commercial and government data centres were not networked and were in a physically protected environment, procedural controls could satisfactorily address most of the vulnerabilities highlighted in the Anderson report. The assumption of a benign internal environment which the military had not been prepared to make, was more reasonable in non-military settings. Consequently, military focused trusted systems did not flourish as vendors focused on more profitable market segments.


39

Moreover, the military was not prepared to exclusively finance their ongoing development, so product development faltered over time and the knowledge and skill base that had accrued in the trusted systems community dissipated. We now find ourselves in a situation where the commercial, industrial threat model has progressively moved closer to that assumed by the military in the 1970s. The observations made in the Anderson Report regarding the futility of ‘penetrate and patch’ seem oddly prescient. So, given the current state of computer insecurity it is somewhat surprising to note that the principles underlying secure computer systems are actually well understood. Gasser [108] provides a good overview. As Loscocco et al. [148] have argued, we face our current predicament because COTS developers have largely ignored these principles. The fact that they have some inconvenient implications does not alter their basic truth.

3.3.2

Properties of trusted systems

A trusted system is one which can be verified to enforce a given security policy. A component of a system that is in a position where it can violate the security policy is one that must be trusted, though it may or may not actually be trustworthy. Assurance of the trustworthiness of a system can be gained through evaluation and a system that has been successfully evaluated is said to be verified. An evaluation that has been carried out under the auspices and supervision of a national scheme will be certified if it meets the evaluation requirements. Verification was considered to be a vital aspect of trusted systems, and it heavily influenced their design, in particular by driving concerted efforts to minimise complexity and to carefully structure the interfaces between modules. Evaluation criteria The US Department of Defence Trusted Computer Security Evaluation Criteria (TCSEC) [209] or ‘orange book’ was a significant milestone in the development of trusted systems. Despite being superseded by ISO/IEC 15408 [126] (also known as the Common Criteria), TCSEC’s principles remain instructive and relevant today. The TCSEC aimed to provide a sound basis for asserting and evaluating the effectiveness of operating system security controls. It established for the first time, a broad hierarchical metric for classifying computer systems according to the security protection they provide. It defined seven classes (A1, B3, B2, B1, C2, C1, D) within four main divisions from A to D. TCSEC A1 and B3

40


systems were verified to enforce the most technically demanding security policy which also equates to a general notion of ‘higher levels of system security’ compared to levels C and D since the functional security requirements of higher level classes are a superset of lower level classes. The evaluation process also involved a progressively greater degree of depth and rigor at each level, with A1 systems delivering the greatest assurance through the requirement for formal mathematical security policy modeling and proofs of correspondence between design and implementation. Mandatory access control The security policy for A and B level systems, (particularly A1 and B3) assumed the presence of malicious insiders who could subvert application software. The complex and challenging threat that this presents was primarily countered through an enforcement paradigm known as Mandatory Access Control (MAC). In contrast, C and D level systems were specified to be appropriate for a benign internal environment, where authorised users were not presumed to present a serious threat. Today’s mainstream operating systems rate at TCSEC level C because they enforce a Discretionary Access Control (DAC) policy. In DAC systems, users have the responsibility for maintaining security, an approach that has distinct advantages in terms of flexibility and ease of management. However, it has a serious weakness in that users also have the discretion to mismanage security. In simple terms, they can configure access controls as they please, carelessly (or intentionally) putting systems at risk. In contrast, MAC systems allocate the responsibility for assigning and managing access rights to a security policy administrator. The control is mandatory because users are unable to override the policy. Since the access control policy is tightly controlled and centrally managed, there can be considerably more confidence that the system is configured properly, reliably enforcing the organisation’s security policy. To retain some flexibility, DAC policies can be enforced within MAC limits. MAC systems are particularly appropriate in situations where users and applications do not own the information they are able to access and therefore should not have the ability to give access to others. Healthcare, finance and government administration are good examples, where legislated privacy and confidentiality obligations arguably make MAC systems a requirement [52].


41

MAC is often associated with the Multi-Level Security (MLS) policy that is based on the work of Bell and La Padula [28]. MLS systems were developed to address the confidentiality needs of the military; indeed the TCSEC defines MAC in an MLS context. Clarke and Wilson [65] argued that MLS systems with their fixed hierarchy of object classifications and subject clearances, (unclassified, restricted, confidential, secret, and top secret) were inappropriate and insufficiently flexible in non-military settings where data integrity is a higher priority than confidentiality. This association of MAC with MLS is unfortunate because it has led to a widespread belief that MAC systems are unworkable in a business context. From the perspective of security and trust, the key element of MAC is its ability to enforce an access policy that users cannot override. MLS is just one of many possible access policies that can be enforced in a mandatory fashion since the concept of MAC is policy-neutral. This distinction is often overlooked. More recently proposed alternatives such as Role Based Access Control (RBAC) and policies based on Domain and Type Enforcement (DTE) offer sufficient flexibility to be useful in non-military settings (see Ferraiolo et al. [95] and Badger et al. [20] respectively). Least privilege RBAC, DTE and TCSEC MLS (through its notion of compartments) all provide the capability to observe the essential security principle that is known as least privilege, described for example, by Saltzer and Schroeder [185]. As the name suggests, least privilege requires a program or user to be given only the minimum set of access rights necessary to complete a task. To achieve this, a system needs to be able to express and enforce fine-grained access rights. Least privilege minimises the consequences of Trojan horses and security relevant flaws in software. Indeed, the threat of Trojan horses in application software was a strong motivation for the work of Bell and La Padula [28] that led to the development of TCSEC MLS. Since a Trojan horse executes with the privileges of the authorised user who has been tricked into running it, security vulnerability can be reduced by minimising the privilege set that it can exploit. Reference monitor MAC systems rely on the concept of a reference monitor, shown in Figure 3.1, which is responsible for enforcing the policy. The reference monitor adjudicates

42


every access request by an authenticated subject, to system resources and data, (collectively known as objects) deciding on the basis of their security labels, whether the requested access is consistent with the policy [7]. To ensure that every access is mediated, it must not be possible to bypass the reference monitor. The reference monitor mechanism also needs to be protected against tampering to ensure that an attacker cannot subvert or influence its access decisions. Finally, the reference monitor needs to be small enough to allow it to be validated via analysis and testing, to reduce the likelihood of undiscovered bugs. As has been amply shown by the TCSEC A1 rated GEMSOS operating system, these properties can be achieved by software in concert with hardware protection mechanisms [188]. The totality of software and hardware that is responsible for enforcing the security policy is known as the Trusted Computing Base (TCB).

Access Policy

Subject

Reference Monitor

Objects

Audit Log

Figure 3.1: The reference monitor concept. Operating systems that employ a reference monitor to enforce MAC policies allow an application or user to be strictly confined to a unique security domain from which they are unable to access other system resources [148]. If an application is compromised or misbehaves, the damage it can cause is restricted to its own domain. This has a profoundly positive impact on the difficult task of maintaining system integrity, particularly when COTS applications and middleware must be used.

3.4. Protection architecture flaws in mainstream operating systems

43

Trusted path To be trusted at level B2 and above, the TCSEC requires an operating system to implement the mechanism of trusted path. Trusted path protects sensitive user input such as passwords from disclosure to, or modification by, malicious processes including keystroke loggers or spoofed login screens. Trusted path also requires a protected channel to the display to prevent untrusted software from imitating a trusted process. Independent evaluation and assurance A final crucial requirement for a system to be trusted is assurance. Assurance measures seek to ensure that a system that is trusted is also trustworthy. Assurance is gained through sound design, rigorous development practices, through minimising the complexity of policy enforcing mechanisms and through independent system evaluation. Evaluation and assurance are dealt with in more detail in Chapter 4.

3.4

Protection architecture flaws in mainstream operating systems

In this section we review the protection architecture of mainstream operating systems in relation to the trusted systems security principles identified in the previous section. The protection architecture is concerned with the enforcement of the system security policy.

3.4.1

No least privilege or MAC

A key limitation of mainstream operating systems, at least from the perspective of trusted computing, is their enforcement of an identity based discretionary security policy, which is incompatible with the security principle of least privilege. In today’s mainstream operating systems, access decisions are based on user identity. As a consequence, a program will execute with all the access privileges of its associated user. To make matters worse there are only two major categories of users: the root or super-user, which cannot be constrained, and normal users. This operating system architecture creates a serious real-world problem due

44


to the large number of applications and network services that run with elevated or super-user privileges. If an attacker can compromise a super-user process they can take complete control of the system, bypassing all access controls. As we have already noted, observance of the principle of least privilege and enforcement of MAC reduces the damage that security bugs and Trojan horse programs can cause as a process is strictly confined or ‘walled in’. This makes it easier to maintain system integrity because there are far fewer highly privileged processes that must be trusted not to abuse their rights.

3.4.2

Lack of assurance

Due to the complexity of application and network services code and their tight coupling with the operating system kernel, (particularly in the case of Microsoft’s ‘Windows’ family of operating systems4 ) it is impossible to ensure that they are completely free of exploitable security bugs and therefore, it is extremely difficult to prevent attackers from taking control of a computing platform. Rapidly increasing system complexity, (which defeats assurance) combined with the failure of mainstream operating systems to observe the principle of least privilege are arguably the two most important reasons for the current state of insecurity in networked computer systems. In addition to the amplified risk of malicious system compromise that flows from the absence of mandatory access controls and ineffective domain confinement, such an architecture results in an all-powerful super-user account which makes it effectively impossible to ensure that authorised administrators are constrained in their actions or effectively accountable for them. Systems cannot be adequately secured against attacks by trusted insiders unless super-user privileges are decomposed into smaller functional bundles that relate to specific administrative tasks. These bundles can then be allocated to different individuals in accordance with the principle of separation of duty. Currently, within present mainstream operating system architectures, this is not possible. This type of administrative separation is implemented in trusted systems products such as Sun Microsystems, Trusted Solaris5 . 4

Microsoft Windows designates several generations of operating systems products from Microsoft Inc. whose home page can be accessed at http://www.microsoft.com/Windows/ . 5 Trusted Solaris is an operating system product of Sun Microsystems Inc. The Trusted Solaris home page can be accessed at http://www.sun.com/software/solaris/ trustedsolaris/.


3.4.3

45

Memory architecture - no reference monitor

Device driver code presents a particularly acute problem as it must be totally trusted but it is not necessarily trustworthy. A device driver needs to be tailored to a specific piece of hardware (e.g. a particular sound card, disk drive, scanner, etc.) so it is typically supplied by the hardware vendor. It is not uncommon for hardware vendors to outsource driver development to third parties. This creates a problem of trust. Solomon and Russinovich [202] note: “device driver code has complete access to system memory space and can bypass Windows 2000 security to access objects.” So device driver code is like application code in that it comes from potentially untrustworthy sources and is not subjected to detailed evaluation, but it is effectively operating system code since it has unrestricted access to system resources. As illustrated in Figure 3.2, a malicious or buggy driver can be used as an entry point to the memory space of another application, perhaps to compromise passwords, cryptographic keys and other sensitive information.

RING 3

Application 1

Application 2

RING 0

OS

Driver

Figure 3.2: Application 1 accesses application 2 memory via a buggy driver. This is a consequence of the two level, system and user memory architecture that Windows shares with other mainstream operating systems. Drivers need to be more privileged than users so in a two level architecture, the only practical option is to run them as a system process at the highest level of privilege. But this means there can be no hardware enforced isolation of the reference monitor mechanism from drivers and other system level code. As a result, in a two level architecture it is not possible to robustly implement a reference monitor mechanism and the principle of least privilege - the high degree of resistance to

46


tampering and bypass that the reference monitor concept demands cannot be met due to other ring zero processes that have unrestricted access to system memory. Similarly, Direct Memory Access (DMA) devices violate the reference monitor concept since their access is not mediated. Windows NT, 2000 and XP also include a function called ReadProcessMemory which, when executed with administrative privilege can be used to access the virtual memory of other processes [202]. The ptrace system call under many unix variants is dangerous in a similar way. Early trusted systems such as Multics (see Corbato et al. [73]) addressed the device driver trust issue via a hierarchy of hardware enforced execution domains known as rings. Building on the Multics approach, Intel x86 processors have supported a ring based protection architecture, as shown in Figure 3.3 since the 286 chip [122]. This four level design, with ring 0 being the most privileged and ring 3 the least, is intended to allow the operating system kernel, (which implements the reference monitor) to operate at a higher level of hardware enforced privilege than device drivers and other operating system components which in turn can have higher privilege than users and application processes. The higher level of privilege ensures that the reference monitor mechanism is more resistant to bypass or tampering by less trusted processes running in rings of lesser privilege. Moreover, by using hardware enforced protection structures, verification is simplified due to reduced software complexity, and higher levels of assurance can be achieved. The x86 hardware architecture is capable of supporting highly secure and trustworthy operation. When correctly utilised, its ring based architecture combined with its fine-grained memory segmentation allow it to enforce effective domain separation and confinement at the hardware level. Unfortunately, with rare exceptions, (e.g. the GEMSOS OS evaluated to TCSEC A1 [188]) the protection rings and memory segmentation features of the Intel x86 have not been used by operating system designers as they were intended. Mainstream operating systems use only the most and least privileged rings for system and user space respectively. While PC operating systems may not have been designed with security as a high priority, the same cannot be said of the processor on which they are based. The failure of mainstream operating systems to correctly utilise the ring structure of the x86 processor explains Intel’s announced intention to release a new


CPU Enforced Software Interfaces

47

Applications OS Extensions

Device Drivers Kernel OS Applications Extensions 0

1

2

3

Figure 3.3: Intended use of the Intel x86 ring architecture. chip with what is effectively a ‘ring -1’. According to Peinado et al., [170] the reason for this is Microsoft’s new NGSCB trusted computing architecture requires a higher level of privilege to enable effective domain separation within ring 0 which, for reasons of backward compatibility must continue to host device drivers of questionable provenance and other potentially insecure operating system components. This is discussed in more detail in Section 3.8.

3.4.4

Trustworthiness of mainstream operating systems

In summary, mainstream operating systems lack the essential features that lead to trustworthy operation. They do not employ a reference monitor that is tamperproof, always invoked and non-bypassable. They cannot enforce a mandatory access policy, and they fail to observe the principles of least privilege and economy of mechanism, which greatly magnifies the threat presented by software bugs and Trojan horse programs. In addition, the sheer volume and complexity of privileged code, (including device drivers) means that there is no possibility of gaining reasonable assurance of trustworthy operation. They also lack the mechanism of trusted path for secure input and display. These limitations are a direct consequence of design decisions that have favoured flexibility, openness, extensibility and ease of use over reliability and trustworthy operation. Openness and flexibility have clearly been valuable properties, contributing in large part to the

48


incredible success of the PC. But it is becoming increasingly clear that they have been bought at a high price, one that we will continue to pay as the consequences of fundamental computer insecurity escalate.

3.4.5

Trusted Operating Systems

There are a small number of commercial alternatives to mainstream operating systems that are designed as TCSEC style trusted systems (as elaborated in Section 3.3.2). These are listed in Table 3.1. The goal of these systems is primarily to meet the computing requirements of certain United States federal government agencies that are mandated to use TCSEC style MLS systems for restricted and classified information handling. OS Name Sun Microsystems Trusted Solaris SGI Trusted IRIX 6.5 BAE Systems XTS-400 and STOP OS

TCSEC Class B1 B1 B3

Product Reference and Information http://www.sun.com/software/solaris/ trustedsolaris/ http://www.sgi.com/products/software/irix/ http://www.baesystems.com/ProductsServices/ cs csit xts400.html

Table 3.1: Commercial trusted operating systems. Security Enhanced Linux (SELinux6 ) introduces TCSEC style MLS to the open-source Linux operating system. Like the commercial systems listed in Table 3.1, SELinux supports the labeling of objects and the association of subjects (via processes) with clearances to enforce mandatory access control according to the model of Bell and La Padula [28]. SELinux does not alter the way the operating system uses the protection rings of the processor - it is a two-state operating system inheriting the attendant difficulties that have already been noted, particularly that the reference monitor mechanism is not protected by processor hardware from other privileged processes.

3.4.6

Trusted systems - barriers to adoption

The main barriers preventing more widespread adoption of trusted operating systems in commercial and industrial settings include concerns over ease of use, inflexibility and application incompatibility. Research and product development is accelerating in this area and these barriers are progressively decreasing in importance. While further research is needed, progress has been made in improving 6

The SELinux homepage can be accessed at http://www.nsa.gov/selinux/ .

3.5. TCG Scheme - description

49

the flexibility of access policy models to support complex business processes and environments. Nonetheless, there is no doubt that systems enforcing MAC are more difficult to deploy and manage than discretionary access systems. A key reason is that MAC forces management to carefully consider and define access policy whereas DAC allows policy decisions to be avoided entirely, or devolved to operational positions within the organisation that have a greater interest in pragmatic efficiency and simplicity of usage. However, there is a strong trend toward making top-level management legally responsible for breaches of security and privacy. In this environment the extra effort and cost required to consider, define, implement and enforce access policy must be balanced against the benefit of more confident assurance that the policy will actually be enforced, thereby addressing management’s legal obligations [43].

3.5

TCG Scheme - description

This section reviews the architecture and key functional aspects of the recent Trusted Computing Group (TCG) initiative. It presents a comprehensive analysis of the credential revocation requirements of the scheme and identifies requirements and barriers to integrating the TCG style of trusted computing with mainstream operating systems. It contributes a detailed argument as to why the addition of TCG components to mainstream operating systems does not deliver the properties (discussed in Section 3.3.2) that allow a system to be considered a trusted system i.e., one that can be verified to enforce a defined security policy. The TCG, successor to the Trusted Computing Platform Alliance (TCPA), is an initiative led by AMD, Hewlett-Packard, IBM, Intel, Microsoft, Sony, and Sun Microsystems. The TCG aims to “develop and promote open, vendor-neutral, industry standard specifications for trusted computing building blocks and software interfaces across multiple platforms” 7 . We begin with a brief introduction to the main features of the TCG specification [205].

3.5.1

Key features

The claimed novelty of the TCG architecture lies in the range of entities that are able to use TCG features as a basis for trust. These include not only the platform user and owner, but remote entities wishing to interact with the platform. The 7

The TCG website can be accessed at https://www.trustedcomputinggroup.org/home

50


mechanism of remote attestation allows remote third parties to challenge the platform to report details of its current software state. On the basis of the attestation, third parties can decide whether they consider the platform to be trustworthy. This feature may be useful for implementing Digital Rights Management (DRM) on general purpose, open computing platforms. In Section 3.7, we use DRM as an application case study to analyse how the effectiveness of TCG’s security services relies on careful integration with certain required operating system structures. TCG also aims to provide reliable, hardware-based protection for secrets such as cryptographic keys. Since open computing platforms can run arbitrary software, this objective aims to ensure that protected secrets will not be revealed unless the platform’s software state meets clearly defined and accurately measurable criteria. TCG’s sealed storage feature can be used to bind a protected secret to a particular software configuration. If the current configuration is not as specified, the sealed key will not be released. This objective aims to provide protection against malicious code, a critical aspect of engendering trust in open platforms. The security service it aims to provide is functionally similar to the IBM 4758’s hardware-based ratchet locks that were described in Chapter 2.

3.5.2

The trusted computing controversy

The TCG initiative has attracted a degree of controversy, particularly in regard to DRM and software licence enforcement applications. This has been largely driven by reports in the popular press that have themselves drawn on the somewhat inflammatory and often inaccurate analysis of commentators such as Ross Anderson [9]. Contrary to Anderson’s observations, the TCG specification itself does not allow a third party to control which operating system and application software a platform owner can run. Furthermore, the architecture does not provide a mechanism for software licence enforcement where a platform boot can be terminated by a third party, (perhaps the software licensor) if usage conditions are not met, (e.g. the licence has expired). However, it is possible to implement an operating system or application that uses TCG features to terminate OS booting or application loading on the instruction of a third party. Similarly, TCG features can be used by applications to implement highly restrictive DRM regimes, capable of censorship, the erosion of fair use rights and invasive monitoring of content usage patterns. The requirements of DRM applications have clearly been considered in the TCG architecture design [22] but it is up to the


51

implementers of operating systems and application software to choose (or not) to build systems with these features. The TCG specification does not provide them - it enables them. This is an important distinction because the basic functionality that these controversial applications build on can equally be used in a context where consumers benefit, for example, in controlling downstream dissemination of sensitive information such as healthcare data, where privacy considerations are paramount. Like many new technologies that have come before it, trusted computing offers great benefits but also poses significant risks. This is likely to demand a regulatory response to ensure that societal costs do not outweigh the gains.

3.5.3

Background and relationship to prior work

Before analysing the TCG specification itself, we will review the technical motivation and prior work in the area of integrity protected booting and remote attestation - two key aspects of TCG. The procedure that boots an operating system on a computing platform is critical to providing a foundation of trust in the platform’s integrity and correct operation. Each successive layer of a computing system relies on the correct operation of the layer below. If layer integrity is not checked, there is no basis on which to trust succeeding layers. When a general purpose computer such as a PC is reset, it boots an operating system according to the following basic procedure. BIOS code that is stored in non-volatile, read only memory is executed by the CPU. The BIOS code loads device drivers and executes a boot loader program which in turn loads the operating system code. Operating system functions are used to load application code. In their pioneering work, Lampson et al. [144] note that authentication of a booted operating system and application programs is necessary to be able to trust a computing platform. They provide a general description of a method for securely booting an operating system and loading programs that works as follows: on installation in a security domain, a computing machine M, is given an asymmetric key pair (the machine key pair) and a certificate on the public key (the machine certificate) that is certified by an authority that speaks for M, presumably the domain administrator. The private key is securely stored by the machine in non-volatile memory and a hardware mechanism, (a simple precursor

52


to the IBM 4758 idea of racket locks) ensures that this key is only available during the boot process. Once the machine has booted any access to the machine private key is denied until the next boot. The boot code takes a hash of the operating system program P, during the boot procedure. If this hash matches a stored value that identifies a trusted operating system, the boot code generates a new asymmetric key pair and issues an authenticated boot cycle certificate by signing the public key with the machine private key. This certificate and the corresponding private key are made available to P to allow it to prove that it has booted according to the authenticated procedure. This design is reliant on the integrity of the boot code8 . Lampson et al. assume that this code can be kept secure by physical means. This is a fundamental limitation since a chain of trust must start somewhere. As Yee [217] later noted, it is a task for which a trusted hardware coprocessor is ideally suited. The Lampson proposal is not intended to provide proof to a third party regarding the nature of the booted operating system. Again, the boot code is trusted to only certify a boot cycle public key if it trusts the operating system. Other parties are required to trust the boot loader. The BITS system of Clarke and Hoffman [66] provides improved booting security through the use of a smart card. When a machine is reset, the user is required to insert a smart card and provide a PIN to authenticate to the card. The platform retrieves a shared secret from the card to authenticate the card to the platform. The platform then copies the boot loader code from the smart card. The boot loader is hashed and the value compared to an authorized value stored on the card. If the two match, the platform executes the boot loader. This proposal also requires trust in the BIOS to ensure that it involves the card in the boot loading process. A modified BIOS could avoid this step. The proposal does not provide trust in the operating system itself, only the boot loader. Yee [217] and Tygar and Yee [207] propose a scheme which uses a tamperresistant cryptographic coprocessor to provide security in operating system booting. As with the TCG approach, the coprocessor is part of the platform, typically installed as an expansion card attached to the mother board. When the platform is reset, the BIOS immediately passes control to the coprocessor. The coprocessor hashes the boot loader, operating system kernel and utilities and compares the 8

This is also true of the TCG which grounds its integrity assertions on the assumption that the ‘core root of trust for measurement’ has not been tampered with.


53

values to expected or trusted hashes that it stores. The coprocessor can terminate the boot procedure if it determines that boot components have been modified. The coprocessor can also report the details of the booted system to a third party after the boot completes. This report can be authenticated by having the coprocessor sign using a long term private key for which it has an associated public key certificate. With Tygar and Yee’s proposal, we see the essential features of the TCG style of trusted computing. The AEGIS integrity protected booting model is introduced by Arbaugh et al. [13]. Like the previously described proposals, it requires a modified BIOS. There is a fundamental concept that is common to AEGIS, TCG and the earlier proposals of Lampson [144], Clarke and Hoffman [66] and Tygar and Yee [207], namely that executable code should be hashed and the hash value either stored for subsequent reporting, or compared to a known trusted value before the code is executed. If the hash does not match the required value the platform cannot boot into a trusted state. The AEGIS architecture uses asymmetric cryptography to provide an authenticated recovery mechanism when code has been modified. A trusted copy of the modified code can be retrieved and a signature on it verified before installation, which returns the platform to a trusted state. The AEGIS architecture described in [13] is not designed to provide trustworthy proof of a platform’s configuration to third parties. One of the key limitations of these proposals is that they rely on taking fingerprints of executable code before the code is executed. These fingerprints are compared with reference values that are taken from supposedly trustworthy versions of the software. The practical difficulty lies in a rather questionable underlying assumption that a version of the software capable of justifying a wellgrounded notion of trust actually exists.

3.5.4

TCG trusted platform module

The architectural modifications required by the TCG specification include the addition of a cryptographic processor chip called a Trusted Platform Module (TPM) which is specified in [113]. The TPM must be a fixed part of the device that cannot easily be transferred to another platform. The TPM provides a range of cryptographic primitives including random number generation, SHA-1 hashing, asymmetric encryption and decryption, signing and verification using 2048 bit RSA, and asymmetric key pair generation (see Menezes et al., [152] for

54


a description of these terms). There is also a small amount of protected storage for keys. Currently available TPMs are based on smart card processors. The TCG has indicated their recognition of the importance of assurance by issuing a Common Criteria Protection Profile [206]. However, it only requires the TPM to be tamper evident as opposed to tamper resistant and it is only required to provide adequate protection against a “casual breach of security by attackers possessing a low attack potential”. The Protection Profile does not require resistance against side channel analysis [139], a powerful class of non-invasive attacks that can recover protected cryptographic keys by analysing the processor’s side channel leakage including power consumption, timing and electromagnetic emanations. Side channel analysis attacks, (discussed in more detail in Chapter 5) do not necessarily leave any signs of tampering. In section 3.6.2 we discuss the implications of this for TCG’s key revocation requirements.

3.5.5

Integrity measurement and reporting

The TCG security services, remote attestation and sealed storage build on an integrity protected boot sequence whose conceptual development was traced in Section 3.5.3. Integrity protected booting is fundamental to the design of the TCG architecture. Figure 3.4 illustrates the process with numbers in parentheses denoting the sequence of events. The boot process starts in a defined state with execution of the BIOS boot block code. The BIOS boot block is called the Core Root of Trust for Measurement (CRTM). Since it initiates the booting and measurement process, it is implicitly trusted. The core idea behind integrity protected booting is that a precise hash-based measurement or fingerprint of all executable code in the boot chain should be taken and securely stored immediately before that code is given control of the processor. Accordingly, the CRTM takes a hash of the BIOS code (1) and stores the value in a protected hardware register in the TPM (2), called a Platform Configuration Register (PCR). PCRs cannot be deleted or overwritten within a boot cycle. They are update only using a simple chained hash technique, based on the SHA1 secure hash algorithm that works as follows (where k denotes concatenation): UpdatedPCRValue = Hash(PreviousPCRValue k MetricToStore),


55

CPU Microcode Updates

Option ROMS Hash Code (6) Hash Code (4)

Hash Code (8)

Hash Code (11)

OS

BIOS Pass Control (10)

OS Pass Control (13)

Loader

Store Hash (12) Store Hash (5, 7, 9) Pass Control (3)

Hash Code (1)

CRTM BIOS Boot Block

Store Hash (2)

TPM

Figure 3.4: TCG Integrity Protected Boot Sequence. The CRTM then passes control to the BIOS code (3) which stores measurements of option ROMS, CPU microcode updates and the OS loader before passing control to the latter. The boot process continues following the same pattern until the kernel is loaded. If any executable stage in this chain has been modified, the change will be reflected in the hash value. Since the PCRs can only be extended, not overwritten with arbitrary values, the modification cannot be designed to hide itself when it is given control of the CPU. It is worth emphasizing that the TPM does not control the boot process. It is a merely a passive component that can be used to securely store measurement data.

3.5.6

Protected storage

The TPM can be used to protect cryptographic keys from compromise by malicious software. TCG provides greatly enhanced protection for signing keys with-

56


out requiring any modifications to current operating systems. This is because the TPM can generate signing only key pairs and perform all signing operations itself, not releasing the key. The TPM does not do bulk symmetric encryption. Rather, it stores symmetric encryption keys, releasing them to the operating system environment when the required authentication information is provided. Once released, the keys are reliant on the protection of the operating system. The TPM directly stores only a single asymmetric storage key. This key is used to encrypt immediate child nodes in a storage hierarchy. These immediate child nodes can encrypt keys of further descendant nodes allowing the storage hierarchy to be extended without limit. The TPM must perform an asymmetric decryption to traverse each node of the hierarchy so the access time for protected objects will grow linearly with the depth of the tree.

3.5.7

Sealed storage

Sealed storage allows the release of a protected key to be conditional on the current status of PCR registers. Access to protected objects can therefore be conditional on the software state. The required PCR values can be defined in two ways. Firstly, an object can be tied to the PCR values current at the time the object was sealed. Secondly, a third party can define the required PCR values, which allows them to stipulate the necessary software environment for the key to be released. In the context of a DRM application, this is intended to allow a content provider to send encrypted content with the knowledge that it will not be accessible unless the platform is configured according to their wishes.

3.6

Analysis of TCG remote attestation and privacy model

In this section we review the TCG’s credential system and privacy protection model in which the Privacy CA plays a critical role. We present a detailed analysis of the revocation requirements inherent in the TCG design, highlighting the practical challenge that revocation presents in this context. We explore ways of reducing the trust that must be placed on the Privacy CA, and provide concrete suggestions to achieve this goal. The TPM has an RSA key pair called the endorsement key pair that is gener-

3.6. Analysis of TCG remote attestation and privacy model

57

ated within the TPM or securely installed at the time of manufacture. There is no function to intentionally release the private portion of the key to the outside. A so-called TPM Entity (TPME), normally the manufacturer, provides a certificate of the endorsement public key called the endorsement credential. The endorsement key pair is unique to the TPM and, hence, its use in transactions with other parties would provide a means of unambiguously identifying the TPM. In order to protect the privacy of the trusted platform, the TCG specification defines a pseudonymous identity credential scheme in which the endorsement credential is used by the TPM to obtain multiple identity credentials from Privacy Certification Authorities (CAs). In version 1.1b of the TPM specification, the endorsement key pair could not be changed or erased. Notwithstanding the existence of the pseudonymous identity credential scheme, the lifelong, unique identification that the endorsement key pair would allow raised considerable privacy concerns, so version 1.2 of the TPM specification [113] gave TPM manufacturers the option of supplying TPMs where the endorsement key pair could be erased and reset. Since a reset endorsement key pair requires re-certification with the certifier physically examining the platform to ensure that it has not been tampered with, the associated high cost would tend to indicate that the use of this function will not be widespread. The endorsement key pair is only used in the identity credential request protocol. It cannot be used for general transactions. An identity credential is a certificate by a Privacy CA on an identity public key generated by the TPM. The privacy afforded by the scheme relies on the trusted mediation of the Privacy CA who knows the binding between the platform identifiers (the endorsement credential) and the issued (pseudonymous) identities. Remote attestation allows a TCG platform to prove the state of its current software environment and its status as a genuine TCG platform to a third party. An identity key pair is used to sign current PCR values. Figure 3.5 illustrates the attestation procedure. A TCG platform seeking service from a provider is challenged by the provider to attest to its current configuration. The provider avails the service once satisfied that the TCG platform is genuine, and that the current software environment is a trusted one. Different identity keys can be used by the TPM in different remote attestations to protect its anonymity.

58


Figure 3.5: TCG Platform Attestation to a Remote Entity.

3.6.1

Identity credentials

In order to obtain an identity credential from a Privacy CA, a TCG platform must show the following three different credentials: 1. A TPM endorsement credential signed by a TPME that attests that the identified TPM is genuine; 2. A platform credential signed by a Platform Entity (PE) (e.g. the platform manufacturer) that vouches that the TPM identified in the endorsement credential has been integrated into a platform that conforms to design; 3. A conformance credential signed by a Conformance Entity (CE) attesting that the TPM and platform designs conform with the TCG specification. Figure 3.6 shows a simplified version of the identity credential issuing protocol run between the trusted platform (TP) and the Privacy CA (PCA). Table 3.2 explains the notation used in the protocol description. Firstly, the TPM generates a new identity key pair (IdPub, IdPri). The public identity key IdPub is then


59

sent to the Privacy CA together with the endorsement, platform and conformace credentials, denoted by EndCred, PlaCred and ConCred, respectively. In order to bind the request to the identity key pair, the TPM uses IdPri to generate a signature on BindData, which includes a hash of the Privacy CA’s public key and IdPub. The signature is attached to the request. On receipt of the request, the Privacy CA verifies the submitted credentials and the signature. If the verification is succesful, the Privacy CA proceeds to create the identity credential, essentially a certificate on IdPub signed by the Privacy CA. The identity credential is then sent to the TP encrypted under the endorsement public key EndPub of the TPM. Encryption of the credential ensures that only the TPM identified in the identity request can succesfully obtain the credential. Further protection is achieved by a mechanism in the TPM that only allows the decryption of identity credentials whose request originated in the TPM itself. EndPub, EndPri IdPub, IdPri EndCred PlaCred ConCred IdCred PrivPub Enc(e, m) Sign(s, m) BindData

endorsement key pair attestation identity key pair endorsement credential platform credential conformance credential identity credential Privacy CA public key asymmetric encryption of message m using key e signature on message m using key s Sign(IdPri, IdPub||PrivPub) Table 3.2: Protocol Notation

1. TP → PCA : IdPub, EndCred, PlaCred, ConCred, Sign(IdPri, BindData) 2. TP ← PCA : Enc(EndPub, IdCred) Figure 3.6: Identity Credential Issuing Protocol

3.6.2

Credential revocation requirements

As noted in Section 3.5.4, the current TPM Protection Profile does not require a TPM to be tamper resistant, only tamper evident. Therefore, attacks that result

60


in the compromise of the endorsement secret key (or any other key) should be expected to occur frequently, when trusted platforms are used, for example, in high value transactions or DRM applications. Recovery of this key allows an attacker to create a virtual trusted platform that is entirely under their control. Publication of a valid endorsement key pair would allow widespread impersonation of the trusted platform, without the trust. The TCG specification acknowledges that “the trustworthiness of the architecture is vulnerable to the compromise of a single TPM endorsement private key”; however, no provision for credential revocation is included. It is clearly important that endorsement credentials can be revoked for TCG to realise its full potential. Privacy CAs need to confirm that an endorsement credential has not been revoked before they issue an identity credential based on it. Similarly, service providers may need to confirm that a pseudonymous identity has not been revoked before they rely on it. The specification also claims that “certain forms of revocation scheme can be retrofitted, should it become necessary at some time in the future.” However, the current specification severely hinders the deployment of any mechanism capable of addressing the revocation of credentials in an efficient and effective manner. To see this, we firstly must appreciate the complexity inherent in certificate revocation, a task that is proving itself to be a major impediment in the successful deployment of a global public key infrastructure (PKI) [181]. We should notice that the intended scope of TCG is also global. Scenarios in which credentials may need to be revoked include the following. 1. A TPM endorsement private key is compromised. Then, the endorsement credential and any associated identities credentials have to be revoked. 2. An identity private key is compromised. Then, depending on the revocation policies being implemented by the different CAs, different scenarios are possible, including the following: (a) The corresponding TPM endorsement credential is also deemed compromised and revocation is effected as in scenario 1; (b) All associated identity credentials within the same issuing Privacy CA need to be revoked. (c) Only the compromised identity credential requires revocation.


61

These scenarios represent a subset of the potential situations that require revocation of credentials. Other circumstances that would result in revocation include the compromise of the signing keys of entities such as manufacturers or CAs. The propagation of revocation amongst associated credentials adds complexity to the revocation mechanism when compared with traditional PKIs. It not only increases the amount of certificates that need to be revoked within the infrastructure, but also demands extra functionality to allow credentials that are associated to be traceable. The above revocation scenarios show that there are situations in which it may be required to find the endorsement credential behind a given identity credential, as well as to find all the identity credentials within the domain of a Privacy CA that are associated to a given identity credential. Informally, we can define the security requirements needed to support traceability of credentials as follows. • Revocable Anonymity: It should not be possible for anyone (except for a designated Privacy CA ) to link an identity credential to the associated endorsement credential. • Revocable Unlinkability: It should not be possible for anyone (except for a designated Privacy CA) to link any two associated identity credentials. We say that the credential scheme provides credential traceability if it satisfies the above two properties. Clearly, the capability to revoke anonymity implies the capability to revoke unlinkability. The Privacy CA acts as a revocation authority that can be called upon in special circunstances, e.g. as part of the credential revocation process, to reveal the binding between credentials. We can further qualify the (anonymity and unlinkability) revocation process as strong or weak depending on whether the Privacy CA can provide cryptographic proof of the link between credentials. The current TCG architecture provides weak traceability, i.e. it allows Privacy CAs to revoke the anonymity (and hence the unlinkability) of identity credentials, but no proof can be produced by the Privacy CA to demonstrate the link between them. The Privacy CA is trusted to claim only genuine mappings between issued identity credentials and TPMs. This trust, if violated, allows the Privacy CA to frame a TPM by asserting an incorrect mapping. If an identity key was used for misbehaviour, a service provider could request revocation of the associated TPM endorsement credential. If the evidence of misbehaviour were sufficient, the Privacy CA could claim an incorrect mapping

62


resulting in revocation of an ‘innocent’ TPM. In Section 3.6.3 we show that strong traceability can be obtained at very little extra cost. Bearing in mind the intricacies of credential revocation, it is not difficult to conclude that the decision by the TCG to only require tamper evidence for TPM chips complicates the retrofitting of any revocation mechanism; for it considerably increases the number of credential revocations due to key compromise that the mechanism must deal with. Similarly, the lack of strong credential traceability predetermines a revocation scheme which places unnecessary trust on Privacy CAs, thus limiting the scheme’s robustness.

3.6.3

Minimising the trust on the privacy CA

Credential authenticity is the most basic security requirement for any credential system. It should not be possible for any user to generate a credential without the approval of the corresponding trust provider. In the TCG architecture, the trust providers for the endorsement, platform and conformance credentials are the TPME, the PE and the CE, respectively. The possession of these certificates by a TCG platform is what enables service providers to trust the attestation process. As explained in Section 3.6.1, possession of the credentials is not proved directly to the service provider, but indirectly through the Privacy CA. Hence, service providers must trust that the Privacy CA will not issue identities to nongenuine TPMs. Service providers who are in a position of relative bargaining power with respect to their customers may choose to act as their own privacy CA to address this trust issue, thereby obviating any privacy protection that the scheme provides. As pointed out in Section 3.6.2, Privacy CAs cannot prove that an identity credential that they have issued was actually requested by the TPM with the matching endorsement credential. As a consequence, Privacy CAs cannot be made accountable for the fabrication of illegitimate identity credentials. This can be easily fixed by modifying the identity credential issuing protocol so that the requesting TPM generates a signature using the endorsement private key to bind the requested identity credential to the endorsement credential. For example, the signature from the original protocol (Figure 3.6) could be replaced by Sign(EndPri, EndPub k Sign(IdPri, BindData)),


63

The Privacy CA would now have to verify both signatures and store them in case it needs to show proof of the binding between the identity and endorsement credentials. The modified protocol is shown in Figure 3.7.

1. TP → PCA : IdPub, EndCred, PlaCred, ConCred, Sign(EndPri, EndPub k Sign(IdPri, BindData)) 2. TP ← PCA : IdCred Figure 3.7: Modified Identity Credential Issuing Protocol

Since the reason for including Privacy CAs in the TCG architecture is the provision of privacy to platforms, it appears that the additional reliance on the Privacy CA to check the authenticity of the credentials is an undesirable side effect of the design. Perhaps in response to criticism of a number of flaws, (including those identified in the previous section) an additional credential scheme called Direct Anonymous Attestation (DAA) that does not require a Privacy CA was introduced in the more recent version 1.2 of the TPM specification [113]. It is a group signature system based on zero-knowledge proof techniques developed by Camenisch and Lysyanskaya [53]. DAA allows a verifier to determine whether a prover holds a genuine DAA credential without gaining knowledge that would allow them to distinguish that TPM from another genuine TPM. One of the complications of DAA is that it does not support anonymity revocation. Moreover, the lack of TPM tamper resistance means that an attacker who manages to extract DAA secrets from a genuine TPM can use the associated anonymous credentials in an unconstrained TPM emulation. Such a compromised credential could be freely distributed and widely used, undermining the trust in the TCG scheme. The TCG has proposed that this problem be addressed by making attestations that are performed with the same anonymous credential potentially linkable. The degree of linkability can be controlled by the verifier, who must agree to a supposedly random value that TCG calls the named base, that is used in each run of an attestation protocol. If the named base is chosen at random each time, protocol runs with the same TPM will not be linkable. If the verifier requires that the same named-base be used it will be able to link DAA protocol runs that use the same credential. If the pattern of repeat usage of a credential indicates unauthorised behaviour, further protocol runs that use the credential

64


can be recognised and aborted. Both attestation protocols strike an uneasy balance between anonymity and security that is not under effective user control. The version 1.1b protocol places a great degree of trust on the Privacy CA. The TCG asserts that users exercise control by selecting a Privacy CA with a good reputation and an acceptable privacy policy. This will be of little comfort in situations where providers of essential services or those that find themselves able to exert considerable leverage over their customers, specify a Privacy CA, (probably themselves) on a ‘take it or leave it’ basis. The DAA protocol is an improvement but it still permits verifier controlled linkability. To address the attendant privacy risks it is vital that DAA client software provide a simple mechanism to report the extent of reuse of the named base so that users are not misled as to the degree that their activities can be linked and cross matched.

3.7

Integrating TCG with mainstream operating systems

In this section we present an analysis of the degree to which the TCG specification can improve the trustworthiness of mainstream operating systems. To this end, we examine the types of operating system support that are necessary to meaningfully make use of two key TCG security services: remote attestation and sealed storage. We identify a number of serious challenges in applying TCG concepts of trusted computing to mainstream operating systems. The TCG specification is claimed to be operating system neutral. It defines lowest common denominator functionality for a range of platform types including PDAs, mobile phones and PCs. Consequently, it does not deal with operating system architecture issues and it does not mandate or suggest operating system security features necessary for TCG services to work reliably. The specification defines requirements as far as the operating system (or bootstrap) loader. Despite the TCG specification’s understandable silence in this regard, we contend that a multi-tasking operating system cannot meaningfully implement TCG functions, particularly remote attestation and sealed storage unless it has the ‘classical’ trusted systems features that were described in Section 3.3.2. The TCG’s integrity verification approach is not a substitute for sound operating system architecture. To understand why this is so, we will explore a representative TCG application

3.7. Integrating TCG with mainstream operating systems

65

scenario: a typical DRM content delivery and access system.

3.7.1

DRM case study introduction

Advances in digital compression technology coupled with the reduced cost and increased capacity of storage media and network bandwidth have combined to make the distribution of digital content over the Internet a practical reality. The owners of copyrighted works, particularly in the entertainment area, have become increasingly anxious to ensure that evolving digital technology does not limit or reduce their capacity to enforce their copyrights for financial reward. This concern has motivated a steadily growing interest in the field of Digital Rights Management (DRM). DRM has been defined as “the management of rights to digital goods and content, including its confinement to authorized use and users and the management of any consequences of that use throughout the entire life cycle of the content” [57]. The essential premise of DRM is that a rights owner wishes to license digital content (which is represented as binary digits or bits) to a licensee or customer who agrees to be bound by the terms of the license. Note that the customer is not buying the bits themselves. Rather, they are buying the right to use the bits in a defined and restricted manner, as authorised in the terms of the license. Hence the license defines a type of usage policy. A hypothetical license might authorise a single playing of the content on a nominated platform. Copying, multiple ‘plays’, redistribution and modification may be prohibited. Technological enforcement is necessary because the rights owner does not necessarily trust the customer, yet they would like to have a reasonable level of assurance that the license terms will be complied with despite the content being stored and used on devices that they do not own or control. Digital information can be protected from unauthorised access in transit and storage by well-understood cryptographic techniques. As Schneck [192] argues, the more complicated challenge presented by DRM flows from the observation that the content bits must be in the clear (i.e., not protected by encryption) on the client platform in order to be rendered in a manner perceptible to a user. If the decrypted content bits can be accessed, (for example by using a kernel debugger or modified device driver) the technological enforcement of the license conditions can be circumvented. Once dissociated from its protection, the content can be freely copied, played, modified and redistributed, albeit in violation of the

66


license terms. Consequently, to reliably enforce typical DRM policies, it must not be possible for the platform user to access the plaintext bits that represent the content, despite the practical reality that the platform is under the user’s direct control. This is an access control problem that cannot be solved purely by cryptography. On open computing platforms that can run arbitrary software, it is a difficult problem to which there is currently no practical, deployed solution, particularly in terms of ‘software-only’ techniques. The Trusted Computing Group (TCG) specification [205] and Microsoft’s Next Generation Secure Computing Base (NGSCB) (discussed in Section 3.8) aim to address this issue through both hardware and software based methods [11].

3.7.2

Relevance of trusted systems to DRM

Stefik [204] argues that trusted systems are a basic requirement for robust DRM since DRM relies on verifiable enforcement of a security policy. The security policy contains the rules or license terms that govern the usage of a digital work, expressed in a computer-interpretable format known as a rights expression language. The content rendering client ensures that the content is protected and manipulated in a manner consistent with the rules. Stefik does not describe the properties a trusted system should have to reliably enforce the rules. However it is implicit from the functional description that the trusted system must protect the underlying bit representation of the content from direct access by a user. If this were not the case, bypassing rule enforcement would be trivial. It should be noted that this ‘gatekeeper’ style of intellectual property rights enforcement is only applicable when the user is seen as a paying, passive consumer of pre-packaged creative works. This view can be contrasted with that of so called ‘open’ intellectual property right regimes like the Creative Commons9 . Open schemes embrace the possibility of creative forms of interaction, modification and adaptation of a work and this requires access to the raw data. This does not mean that technological protection has nothing to contribute to open schemes. It does mean however that applicable technological measures tend more toward a passive supporting role than an active and restrictive style of enforcement. According to Lacy et al. [143], the license interpretation and enforcement com9

“The Creative Commons is devoted to expanding the range of creative work available for others to build upon and share.” See http://creativecommons.org/ accessed May 2004.


67

ponents of the client’s content rendering platform, (which we will refer to as the DRM client) must be implemented within the boundaries of a Trusted Computing Base (TCB). Lacy does not consider the complications that are introduced if the DRM client is an open computing device capable of running arbitrary software. Biddle et al. [30] identify the following necessary enforcement properties for a DRM client: 1. The client cannot remove the encryption from the file and send it to a peer. 2. The client cannot ‘clone’ its DRM system to make it run on another host. 3. The client obeys the rules set out in the DRM license. 4. The client cannot separate the rules from the payload. When the DRM client is implemented in application software on a mainstream operating system, Hauser and Wenz [119] contend that policy enforcement can be bypassed with relative ease. They document a number of successful attacks on deployed schemes. Properties 1, 3 and 4 are particularly difficult to implement in application level clients that run on mainstream operating systems. We discuss reasons for the inadequacy of application level policy enforcement, (in the absence of certain required operating system features) in the next section.

3.7.3

Policy enforcement on a DRM client platform

We now consider a typical DRM content delivery scenario wherein a TCG enabled DRM client platform wishes to connect to a content provider to download and subsequently view a movie. In exchange for payment, the provider will transfer an encrypted copy of the movie and a license for a single viewing. The license prohibits copying, modification and transfer to other platforms. Note that these license terms implicate all of Biddle’s enforcement properties (listed in the previous section). Building on TCG features, the content provider takes a number of steps to ensure the integrity of the policy enforcement mechanisms on the client’s platform. We use the term integrity to refer to the ongoing ability of the platform to reliably enforce the license terms. This requires application code to be correct and executing in an isolated domain. There are three main types of verification requirement to determine and preserve integrity:

68


• The content provider requires client platforms to establish via remote attestation that they have booted according to TCG principles. The content provider assesses the booted software environment against a list of ‘trusted’ components to ensure that the client booted into a trusted state. • The content provider must ensure that the client has not executed untrusted software after the boot process completed but before the remote attestation was initiated. • The content provider must ensure that a trusted version of the DRM client is executing at the time of the remote attestation, and that client cannot execute untrusted software while the protected content is being accessed or viewed since this would violate the requirement for isolation. We will now analyse the practical implications of addressing these requirements in the context of a mainstream operating system. The motivation for the first requirement is self-evident. However, it is worth emphasizing that the TCG design is based on the premise that a system can be trusted if the PCR registers match values expected by a relying party. The expected values must be those of a known secure configuration. This assumes that a secure and trusted configuration actually exists and that the configuration is trusted because it is trustworthy. As we argued in Section 3.4, this assumption is not well founded in the case of mainstream operating systems because complexity and architecture defeat assurance of integrity. TCG does not solve code quality or operating system architecture problems. This is a critical and often overlooked drawback of the TCG model of trusted computing. The second and third requirements reflect the fact that the integrity of a platform (running a mainstream operating system) is dependent on its runtime behaviour. A theoretically trustworthy state immediately post-boot provides no guarantee that integrity will be maintained, since software executing post-boot can affect the integrity of the platform. For example, a dynamically loaded kernel module, device driver or privileged application can potentially execute at any time and violate protection requirements. As we noted in Section 3.4, this is possible because there is no mandatory control over information flow among and within processes running at the highest level of privilege.


69

Operating system requirements to support TCG features To support requirements two and three, the operating system itself needs to be modified to include a measuring function that fingerprints the executable code and configuration data of any system or user level process before it is launched. Sailer et al. [184] propose a ‘TCG based integrity measurement architecture’ based on Linux in which they describe a number of operating system modifications to this end. They describe the instrumentation of functions that initiate the loading of code and data that may impact platform integrity. In a DAC-based operating system not enforcing the principle of least privilege, there are many such places where the measuring function must be called. Relatively simple candidates include functions that load kernel modules, dynamically loadable libraries, and user-level executables. Other more problematic candidates include script interpreters, virtual machines, (e.g., the java class loader) privileged applications and network services. The instrumentation itself is relatively simple. It requires a call to a ‘hash and store’ function immediately prior to code execution. The problem lies in the practical difficulty of ensuring that all code is instrumented, particularly privileged application code. The source code of legacy and proprietary applications is not always available and software vendors may not be motivated or able to issue instrumented versions of all software that is still in use. Arguably, the impracticality of instrumenting all script interpreters, virtual machines, just in time compilers, and privileged applications calls into question the viability of the whole approach. The failure to instrument results in potential avenues for integrity violation. The third requirement is the most challenging since it requires that the PCR values always reflect the current configuration. Therefore, to be able to verify the integrity of any one process all other processes must be measured on an ongoing basis [184]. Since the integrity of a process may be violated at any moment, an attestation is only meaningful at the instant of the last measurement. By the time a challenger has evaluated an attestation response, the integrity status may have changed in a material way. The challenger has no way to know if this has happened except to continually rechallenge the platform, a highly inefficient and unsatisfactory option that in any case can only provide retrospective assurance. This problem also impacts sealed storage. A platform may have been in the configuration mandated in a sealed storage policy (as reflected in the required PCR values) at the time a protected cryptographic key was released to the op-

70


erating system but this configuration can subsequently change (i.e., within the same boot cycle) putting the key and decrypted ciphertext at risk of compromise. In the absence of MAC based domain confinement, what is needed is a reliable way for the platform to revoke its trusted status and immediately purge any protected content or keys from memory if an integrity-relevant change occurs. The insurmountable difficulty lies in distinguishing a change that should result in trusted status revocation from an integrity preserving one. The reason we consider the problem to be insurmountable relates to how unrecognised fingerprints that have been extended into PCRs should be handled. This is discussed in the next section.

3.7.4

Maintaining integrity assurance

In the TCG remote attestation protocol, the challenged platform sends the current PCR values together with a log of the individual fingerprints that have been chained together to produce these values. The challenger can use the log to determine whether it trusts the components that are identified by each individual measurement that makes up a hash chain. To identify any tampering with the log, it can recalculate the chain to ensure it produces the reported PCR value. The problem with unrecognised fingerprints From a challenger’s perspective, the presence of any unrecognised fingerprint in the log should result in the platform being considered untrustworthy - the unknown fingerprint could be that of a malicious component such as a modified device driver or a program that provides the same functionality as an instrumented program but without the instrumentation, e.g. a kernel module loader that can violate the integrity of the platform by loading malicious code that will not be reflected in the current PCR values. This will only present a problem if unrecognised fingerprints can be legitimately expected from an otherwise ‘trustworthy’ platform. Unfortunately they are highly likely because loosely structured data (including scripting files, configuration files) must be fingerprinted. This is necessary because the runtime behaviour of a program is commonly determined by the configuration files it parses at start up, and also, the data consumed as inputs once running. Therefore, to assess the integrity impact of executable code, its inputs must be measured. The measurement of semi-structured and unstructured input data and configuration


71

files is particularly problematic in the context of the TCG architecture since they are not as amenable to integrity verification via fingerprinting, as is static code. Non-executable files of this type can tolerate subtle differences such as extra white space characters, comments or the same elements in a different order, with no impact on integrity. Nonetheless, any such difference will produce a completely different fingerprint. Differences of this type can be reasonably expected in the real world as users tailor system behaviour to meet their individual needs via configuration files. Without access to the measured file itself, the challenger will be unable to determine whether an unrecognised fingerprint results from an irrelevant formatting difference in a semi-structured file as opposed to a malicious component or an un-instrumented component loader. Hash-based integrity measurement may be practical for executable code but it is very unforgiving when applied to semi-structured data - arguably so unforgiving as to call the whole approach into question. Why sealed storage is impractical This line of reasoning applies equally to TCG’s sealed storage feature. We noted that sealed storage allows the release of a protected key to be conditional on the current status of PCR registers matching some predefined and trusted values. The presence of an unknown measurement in the PCR hash chains will render a sealed object inaccessible. New measurements can be introduced by changes in the software or hardware configuration (e.g., an upgrade of a video card). We believe the use of sealed storage for DRM content protection in mainstream operating systems is impractical for two reasons. The first relates to the order PCRs are extended in. With hash chains, the order of element chaining determines the resulting output value. Therefore, to access a sealed object, all the fingerprints that have been extended into a PCR must be trusted and they must be chained together in precisely the same order that produced the reference PCR values to which the object is sealed. In mainstream operating systems, the order of PCR extension is deterministic up to the operating system loader. After this point, order depends on individual runtime behaviour as the operating system kernel proceeds to launch multiple concurrent processes which themselves may be multithreaded. In such a multi-tasking environment, execution order is not deterministic. The second reason why sealed storage is impractical flows from the observa-

72


tion in Section 3.7.3 that to maintain integrity all executable code needs to be measured before it is loaded. This means that PCRs continue to be extended as new applications are run. Therefore, in typical usage they do not stabilise to a predetermined value. Version 1.2 of the TPM specification [113] introduced PCRs that can be reset during a boot cycle but this does not solve the problem because a reset breaks the chain of trust that links back to the core root of trust for measurement - the BIOS10 . The problem of continually evolving PCRs could be ameliorated by sealing an object to a subset of PCR values that only reflects the early stages of the boot process, perhaps up to the loading of the operating system kernel. This would be more likely to produce the deterministic result that sealed storage requires. It will not however capture post boot platform configuration changes such as the loading of kernel modules that can materially impact integrity. DRM clients require MAC-based confinement The impracticality of remote attestation and sealed storage on mainstream operating systems is a serious drawback. It underlines the fact that the TCG building blocks cannot remedy problems that flow from operating system architectural deficiencies. Secure DRM clients cannot be deployed on multi-tasking operating systems that are unable to provide MAC-based isolation and confinement of mutually distrustful and potentially hostile processes. The application of TCG components does not change this fact. Sailer et al. [184] assert that “many of the Microsoft NGSCB guarantees can be obtained on today’s hardware and today’s software and that these guarantees do not require a new CPU mode or operating system but merely depend on the availability of an independent trusted entity, a TPM for example.” We contend that while a number of guarantees may be possible, the important ones cannot be achieved since critical elements of a trusted system must be enforced by a combination of the operating system mapped to CPU hardware-based protection structures. They cannot be provided by add-on hardware. The addition of TCG components to mainstream operating systems does not result in a ‘trusted system’ in the sense described in Section 3.3. It does not introduce trusted paths, or a tamper resistant, non-bypassable reference monitor, 10

Resets work in trusted computing architectures where the BIOS does not need to be trusted as is the case with virtualisation approaches discussed in Section 3.8.


73

and it does not alter the problems created by the failure to observe the principle of least privilege. The TPM allows integrity measurements to be stored in a trusted fashion but it does not provide any mechanism to prevent integrity violations. It does allow known versions of compromised software to be identified by their fingerprints and this is definitely useful. It also provides a more secure environment for the storage of cryptographic keys, particularly asymmetric signing keys. However, effective domain confinement and mandatory access control are fundamental requirements for trusted computing and reliable license enforcement in DRM clients. For these reasons we believe that the security benefits gained by applying TCG components to mainstream operating systems that enforce purely discretionary access control are worthwhile but modest. The combination of TCG components with MAC-based operating systems (e.g., SELinux) may have significant advantages over DAC based counterparts advantages that may make sealed storage and remote attestation more practical. In a MAC based system a challenger needs to verify the integrity of the security policy interpretation and enforcement mechanism, the policy configuration itself and the DRM client application. If these components are trusted to enforce isolation of the DRM client, no further measurements are required to establish the ongoing integrity of the DRM client. Thus the impractical requirement for ongoing measurement in DAC architectures is avoided. Since integrity assurance is based on isolation, detailed measurements of other loaded executables and configuration data is not required. While SELinux offers improved assurance of policy enforcement, it does not address the lower-level problems caused by over use of ring 0 that we discussed in Section 3.4.

3.7.5

Privacy impacts

Remote attestation reveals particularly fine-grained details of a platform’s configuration that are likely to be sufficient to distinguish different platforms from each other and to recognise the same platform across different sessions. In DAC enforcing architectures in particular, the privacy protection mechanisms detailed in the TCG specification, including the Direct Anonymous Attestation protocols introduced in version 1.2 (see Section 3.6.3) are at great risk of being rendered practically ineffective.

74

3.8


Next Generation Secure Computing Base (NGSCB)

Next Generation Secure Computing Base (NGSCB) is the name for Microsoft Inc.’s trusted computing program, formerly known as Palladium. Technical details of the proposal have appeared in the academic literature [1, 170]. According to the designers of the system, Peinado et al., [170] NGSCB is a “high assurance runtime environment for trustworthy applications on a regular personal computer”. This new environment runs along side and separate from the existing Windows operating system, so NGSCB does not make Windows itself secure. Securing Windows would require major changes to the way the operating system uses the ring-based memory protection features of the Intel CPU and this could not be done without breaking existing applications, a commercially unacceptable option. NGSCB builds on the TCG specification (TPM version 1.2) and a number of significant planned modifications to the CPU and chipset that have been announced by Intel Inc. under their LaGrande program [111] now referred to by Intel as Virtualisation Technology. The chipset modifications are apparently designed to introduce a trusted path for keyboard, mouse and other input, and secure display output. The CPU modifications introduce a new mode akin to a ‘ring -1’, (since it has a higher level of privilege than ring 0) and a number of new instructions to support it. This design is heavily influenced by the need for backward compatibility with existing two-state operating systems including Microsoft Windows. Backward compatibility was stated as a key requirement for NGSCB. As we noted in Section 3.4.3, the Windows kernel, device drivers and operating system operate at the highest level of hardware privilege, in ring 0. Due to the untrustworthy, bug-prone nature of some operating system components and drivers running in this ring, there is no way to introduce a “high assurance runtime environment” because there is no tamper resistant space in which to implement a domain separation mechanism. The new mode introduces the necessary hardware-based support for such a mechanism.

3.8. Next Generation Secure Computing Base (NGSCB)

3.8.1

75

NGSCB and virtual machine monitors

The NGSCB approach effectively allows two or more operating systems to concurrently share a CPU. This technique was developed in the 1960s and employs a protection construct known as a Virtual Machine Monitor (VMM) to isolate mutually distrustful systems on the same processor [171]. In the simplest version of the VMM approach, multiple operating systems can be simultaneously hosted in ring 1 by a VMM that runs in ring 0. The VMM presents the same interface to the hosted operating systems as the native hardware and provides domain isolation between them. The VMM approach cannot be used to implement a secure and efficient domain separation mechanism on the current Intel processor because, according to Robin and Irvine [182], the Intel x86 cannot be securely virtualised. This is because the IA-32 instruction set includes 17 so called ‘sensitive’ instructions that are not privileged. A sensitive instruction is one that can monitor or effect the scheduling and allocation of real system resources. Popek and Goldberg [171], argue that for a processor to be fully virtualisable, all sensitive instructions should be privileged so that when one is called by a virtual machine, a hardware interrupt will automatically trap to the VMM which emulates the effect of the instruction for the virtual view of the hardware seen by that virtual machine instance. Non-sensitive instructions are executed directly on the hardware without the interposition of the VMM. This maximises speed and efficiency without putting the VMM or other virtual machine instances at risk. Full, secure virtualisation of the x86 chip may not be possible but nonetheless, the type of isolation that NGSCB demands requires something roughly equivalent to a VMM and a VMM requires a higher level of privilege than the hosted operating systems in order to work. This is the reason behind the new ‘ring -1’ mode. Peinado et al., [170] describe the NGSCB equivalent of a VMM as an isolation kernel. The isolation kernel protects the memory and device resources of a domain from access by other domains. The isolation kernel is not itself a fully featured operating system, it merely manages the coexistence of multiple operating systems on the same machine. Again, for reasons of backward compatibility, the isolation kernel does not boot before the standard Windows operating system and it does not run beneath it. This somewhat unconventional approach is a key difference to the TCG style of trusted computing, which bases its assurance on an assessment of the integrity of the entire boot chain. NGSCB also takes a different tack in not assuming that the BIOS is trustworthy. In a sense, the

76


NGSCB approach has abandoned any premise of making the traditional Windows operating system ‘trusted’ and opted instead to construct a secure environment that can run along side it - “a tight sanctuary on an otherwise bug-prone system” in the words of Peinado et al., [170]. This tight sanctuary can be launched and terminated multiple times in the same boot cycle11 and multiple sanctuaries can simultaneously coexist. In effect, the LaGrande extensions allow a single platform to concurrently and independently run multiple operating systems that exist in hardware enforced isolation from one another.

3.8.2

Trusted systems properties of NGSCB

Like TCG, the NGSCB design supports remote attestation, and sealed storage. Unlike the basic version of TCG described in the previous section, it supports hardware enforced domain isolation and trusted paths. As between domains, this is a form of MAC since, once activated neither users nor administrators can turn the hardware protection off within a boot cycle. Microsoft has asserted that the code for the isolation kernel will be sufficiently small and simple to provide assurance of its correctness through independent evaluation. Thus NGSCB’s ‘sanctuary’ appears to embody the important features that are required of a trustworthy computing platform. However, Microsoft has not described in any detail the trusted operating system that the isolation kernel actually launches - the trusted sanctuary itself. This sanctuary is intended to support multiple applications or applets which do not necessarily trust each other. Thus an operating system capable of the functions described in Section 3 will also be required.

3.8.3

Microsoft delays NGSCB

In May 2004, Rooney reported [183] Microsoft’s announcement of a substantially reduced commitment to the inclusion of NGSCB features in the next major Windows OS release, originally code named Longhorn, now to be released as Windows Vista. At the time of writing, the NGSCB web page12 confirms this by noting that “customers were concerned that having to rewrite all of their applications would hinder adoption of NGSCB” and that Microsoft was evolving the design 11

This is the main reason for the addition of resettable PCRs in version 1.2 of the TPM specification. 12 http://www.microsoft.com/resources/ngscb/default.mspx, last accessed 4 April 2006.

3.8. Next Generation Secure Computing Base (NGSCB)

77

to deliver benefits without requiring code re-writes, thus implying a significant watering-down of the original strategy. How can this major shift be explained? Microsoft is tightly constrained by a pragmatic commercial imperative that effectively rules out any new security development which might break existing applications. The original NGSCB strategy was backward compatible, however, by requiring applications to be rewritten to take advantage of the new secure environment, it implicitly created a security perception risk because it drew the insecurity of the old system in starker relief. Developers who did not rewrite their applications would potentially be seen as not taking security sufficiently seriously. The initial strategy would also have introduced considerable challenges for developers both in partitioning applications into security-relevant and security-insensitive parts, and in managing the interface between these without introducing further vulnerabilities. Microsoft has chosen to avoid these issues for the time being by not delivering any of the core elements that defined the NGSCB proposal. The most important aspect of the original conception of NGSCB was the utilisation of hardwarebased memory protection via ‘ring -1’ to support robust, non-bypassable domain separation. Without this feature, it is not possible to move beyond the primary source of vulnerability in Windows systems, the insecure use of ring 0. In the place of the ambitious initial goals of NGSCB, Microsoft has settled for a hard disk encryption feature that uses a TPM to store the cryptographic keys. This is a significant capitulation to more immediate commercial pressures that arguably place a higher degree of importance on market perception than on addressing the real source of Microsoft’s security vulnerabilities.

3.8.4

The significance of virtual machine technology

The fact that Microsoft has indefinitely delayed the rollout of NGSCB may not prove to be a significant setback for the ultimate delivery of NGSCB type functionality. The reason for this follows from the observation that NGSCB provided a way to step outside the insecure Windows operating system environment into a ‘secure sanctuary’. However, the door and walls of this more secure environment are actually underpinned by the new instructions supported by the Intel processor and chipset, not by Windows itself. Since Intel’s LaGrande technology and virtualisation technology programs are still progressing [111], and AMD plans to deliver equivalent functionality under their Pacifica program [115], other vendors

78


will be able to fill the gap by developing competing, high security operating system environments that may also take advantage of the remote attestation and sealed storage features of the TPM. In the past, the idea of developing an operating system to compete with Microsoft would have been fairly regarded as a high risk strategy. However, the virtualisation support in upcoming Intel processors and associated VMM technology (e.g., Xen [26], VMware [212]) means that competitors do not have to offer a backward compatible replacement for Windows. Instead, they can develop niche operating system products that address the specific needs of individual applications or application groups. These can coexist with Windows on the same machine, booted at the same time. Platform owners will not be forced to choose one system over another. They can choose the best operating system for the task. This is a truly significant development that promises to accelerate the adoption of trusted systems. Virtualisation removes the burden on an operating system to concurrently provide high levels of trust and high levels of speed and high levels of flexibility. The trade-off between these competing interests has traditionally sacrificed the former for the later two. VMMs allow an operating system to be tailored to the specific needs of an application, e.g., an Internet banking application can be run on a highly secure, mandatory access controlled operating system while a networked game or video editing application concurrently runs on an operating system optimised for speed and flexibility. Applications that are tightly integrated with a dedicated and custom-tailored operating system will also be considerably more stable and thus more amenable to authentication by third parties using TCG remote attestation (see for example, Garfinkel’s Terra architecture [107] for virtual machine remote attestation). An application (such as the electronic health records system that we describe in Chapter 7) can also have it’s access to a application stack authentication key or data decryption key regulated via sealed storage. Entities interacting with the application can be confident of the integrity of the application’s code since it would not be able to access its keys if the code had been altered in any way. We have argued that this is not the case with applications running on mainstream operating systems - the likelihood of unrecognised measurements is overwhelming due to the multipurpose, reconfigurable nature of such systems. VMMs facilitate domain isolation for mission and safety critical applications from applications that have less demanding security requirements. They can accommodate the pragmatic need to support legacy

3.9. Conclusion

79

systems and applications whilst simultaneously allowing migration to more trustworthy alternatives. They do require hardware input/output (I/O) devices such as storage and network interfaces to be virtualised securely and this will require further modifications at the hardware level, for example to support channel based I/O as implemented in early IBM mainframe systems such as the VM/370 [21]. Secure I/O virtualisation is a challenging exercise, particularly given the diversity of hardware that needs to be supported. The potential difficulties here should not be underestimated.

3.9

Conclusion

We began the chapter by reviewing the escalating state of insecurity in networked computing infrastructure. We argued that current perimeter defense strategies including firewalls, virus checking and intrusion detection were unlikely to arrest the problem. The remainder of the chapter tracked the development of high assurance computing from its formative period in the 1960s and 70s when it was known as trusted systems to more recent incarnations described by their promoters as trusted or trustworthy computing. The period in between saw the development an growing market dominance of commercial, mainstream operating systems that ignored the knowledge and insights garnered through earlier rigorous scientific research, practical implementation and operation in hostile environments. We highlighted the significant points of departure from trusted systems principles in an effort to explain why mainstream operating systems became progressively more vulnerable as the commercial threat environment increased in hostility due to pervasive system interconnection. We reviewed the main features of the TCG specification and contributed a detailed analysis of the revocation requirements implicated by the design and also suggested ways to reduce the trust on the Privacy CA. We then examined the degree to which the addition of TCG components and features to mainstream operating systems could improve their trustworthiness, using a DRM client application as a vehicle to advance our arguments. We concluded that overall, the gains were modest. TCG cannot turn a mainstream operating system into a trusted system because the most important element that underpins trust is absent - rigorous domain separation, which permits mutually distrustful processes to

80


safely execute on the same computing platform. The way mainstream operating systems use the memory protection features of the Intel processor is inadequate for this purpose. We contributed detailed arguments as to why the TCG security services of sealed storage and remote attestation were impractical when applied to mainstream operating systems, thus arguing that they do not deliver the necessary properties of a DRM client. We concluded the chapter with an examination of Microsoft’s NGSCB initiative, comparing it with the TCG specification. We argued that it was on firmer theoretical ground due its emphasis on tackling the fundamental problem of memory management and domain separation. Unfortunately, Microsoft has signaled a flagging commitment to addressing this problem by failing to deliver any of NGSCBs key features in the next Windows release as initially promised. On a more positive note we observed that virtualisation technology promised to speed the adoption of trusted systems by allowing multiple systems to coexist on the same processor, thus allowing the choice of best of breed operating systems to support the needs of individual applications. This promises to be a truly significant development which may alter the competitive dynamics of the operating system market to the extent that domination by one commercial vendor is no longer possible.

Chapter 4

Certification - Trusted and Trustworthy? 4.1

Introduction

Users of trusted hardware need a way to establish and justify that their trust in a device is technically well founded - if it must be trusted it should also be trustworthy. Since trusted devices, particularly those with cryptographic functionality, are designed not to reveal information about how they operate or any unintended aspect of their internal state, it is difficult if not impossible for a prospective user or buyer to make a sound judgment as to whether a particular device meets their security needs, without relying on an expert and unbiased opinion of a third party. Otherwise-uncorroborated emphatic assertions from the manufacturer need to be taken with a grain of salt due to an inherent conflict of interest; developing and building a product which has no exploitable vulnerabilities is very expensive. Since the manufacturer/vendor will not bear the direct costs of a security failure, there is an incentive to maximise the perception of security whist minimizing development and production costs. Security evaluation and certification through the Information Technology Security Evaluation Criteria, known as ITSEC [164] or Common Criteria [126] schemes is an increasingly popular option for manufacturers who wish to provide a sound basis for trust in their products. It has also proved to be a way of generating a market perception of some abstract notion of ‘high security’, 81

82

Chapter 4. Certification - Trusted and Trustworthy?

though in some cases, with questionable objective justification. Successful evaluation, particularly to high assurance levels can be of great benefit in marketing a trusted hardware device since security concerns are paramount and the certification process is all about establishing confidence in security. In this chapter we examine the certification process and the extent to which it provides a sound basis of trust for the issuers and users of evaluated security devices, particularly smart cards. This is achieved through a survey of certification reports, security targets and related documentation, issued under the Common Criteria and ITSEC schemes for a range of smart cards used in the finance and banking industry1 . The main contribution of the chapter is the identification of specific instances where smart card manufacturers have manipulated the certification process to attain a high assurance rating. Furthermore, it highlights the methods by which this is achieved, the dominant one being evaluation against security targets with an artificially restrictive scope. We examine why this is possible and identify ways to make it more difficult in practice, so that the certification schemes have a greater chance of achieving their goals. The Chapter is structured as follows: Section two presents an overview of the certification process under ITSEC and the Common Criteria. It highlights some of the challenges in applying the criteria to smart cards, challenges that flow from the nature of the device and the fact that they are issued in large numbers to untrusted users for their long term retention. This is contrasted against the certification scheme’s more natural orientation towards software and components for networked computer systems. Section three presents the survey data and analysis, examining the relationship between the scope of the evaluation and the level of security accreditation achieved. The rationale for the presented analysis is that certifications will be of the greatest benefit to issuers and device users when they are sufficiently comprehensive to allow an assessment of whether a candidate card is secure enough for an intended application, the risks associated with its use being known and acceptable. This approach would be more within the spirit of the certification schemes, as well as being considerably more useful to end users compared to evaluation efforts that target high assurance levels for small subsets of functionality or limited stages of the card lifecycle. 1

This chapter is based on research undertaken primarily in 2000 and 2001. While some effort has been expended in bringing this work up to date at the time of writing, the more recent certifications that have been included are by no means exhaustive.

4.2. How certification works

4.2

83

How certification works

This section describes the key features and operational details of three evaluation and certification schemes: the ITSEC, the Common Criteria and FIPS 140.

4.2.1

ITSEC

The Information Technology Security Evaluation Criteria (ITSEC) scheme [164] began in the early 1990s. Though the Common Criteria was intended to be a harmonised replacement for ITSEC and other North American schemes, ITSEC certifications are still offered in participating countries including the UK and Australia and have been issued as recently as October 20052 so this analysis is of more than mere historical interest. The ITSEC evaluates a product3 or so called Target of Evaluation (TOE) against a security target. The security target is a document prepared by the evaluation sponsor. In general terms, the security target describes what the product does, the environment it is intended to operate in, the threats it is likely to encounter and how it protects against those threats. The security target makes claims about the security functionality of the TOE and the evaluation process determines whether these claims are substantiated. In this sense, the security target forms the basis of the evaluation and a certification must be interpreted within the scope of the security target’s claims. ITSEC uses an E scale rating system with seven levels from E0 to E6. These evaluation levels represent increasing levels of confidence that the TOE meets its security target, where E0 denotes failure to establish any confidence and E6 denotes the highest level of confidence. The E scale is a measure of assurance that a target has been met. Unfortunately, there is a widespread misconception in the marketplace that the evaluation assurance scale is a hierarchical measure of security strength. Organisations that sell evaluated products have not invested much effort in correcting this misconception. For example, in the year 2000 Annual Report issued by Keycorp [135], a MULTOS smart card developer, it was stated (our emphasis added): Keycorp’s implementation of the MULTOS standard for operating 2

see the Certified Products list at http://www.cesg.gov.uk/site/iacs/ Under the ITSEC and Common Criteria schemes, the approach and requirements for the evaluation of individual information technology products is different to that of complete systems. Because this chapter deals with smart cards which are evaluated as products, the following discussion deals with the schemes as they apply to products. 3

84


systems was given ITSEC’s highest level of accreditation, security level E6 making it the most secure smart card platform available in the world today. There is no such thing as an E6 security level. The earlier, highly influential US evaluation scheme, the Trusted Computer Security Evaluation Criteria (TSCEC) [209] did use a rating system where successively higher rating levels indicated higher levels of system security, so an A1 system could be considered more secure than a system evaluated to C2. This may go some way to explaining why the confusion has developed. It is certainly true that the E6 evaluations have been leveraged by MULTOS vendors to gain the security ‘high ground’ at least from a marketing perspective, as can be seen from their aggressive promotion of the fact that theirs is the only smart card product to achieve E6. But as we will soon see, these evaluations are not as compelling as they may at first seem. Because the security target effectively defines the scope of the evaluation, it is potentially dangerous to automatically equate a high assurance rating with some abstract notion of high security in a particular operational environment. As the later analysis of actual smart card certifications will illustrate, security targets can tightly define and confine the scope of what is evaluated. For example, the certifications reported in [189] and [190] exclude the integrated circuit (IC), [77] and [76] limit the scope of the evaluation to the phases of design, manufacture and testing. As a consequence, it can be difficult to draw definite conclusions about the ability of a card to counter threats when they have been issued and are in the hands of untrusted card holders, particularly where the evaluation did not thoroughly examine threats in this phase of the card lifecycle. This can limit the utility that a potential issuer of a smart card can draw from a certification because issuers are primarily interested in how the card will fare in actual use. To establish assurance that a TOE meets its security target, the ITSEC scheme looks for substantiating evidence to justify confidence along two separate dimensions: • confidence in the correctness of implemented security functionality, and • confidence in the effectiveness of that functionality. This approach recognises that a set of correctly implemented security mechanisms will not be effective unless they are actually suitable for the task. They must bind together so that there is a synergy in their individual contributions


85

to security that leaves no exploitable vulnerabilities. To enable evaluation on the basis of effectiveness and correctness, a security target makes claims about a TOE’s security properties at three different levels of abstraction - essentially why, what and how. Security objectives are the highest level, the ‘why’. They explain why particular functionality is necessary. Security objectives reflect the threats that have been identified in the security target. Security enforcing functions are the ‘what’. They detail what security functionality is actually provided. Security mechanisms are how that security functionality is implemented. In addition to specifying a target assurance level, (E1 to E6) the security target must also claim a minimum strength of mechanisms (SoM) rating. ITSEC [164] defines strength of mechanisms as; an aspect of the assessment of the effectiveness of a Target of Evaluation, namely the ability of its security mechanisms to withstand direct attack against deficiencies in their underlying algorithms, principles and properties. There are three possible strength of mechanism ratings, namely basic, medium and high. As the ITSEC definition suggests, the evaluator must determine whether individual, critical security mechanisms can resist a direct attack at the claimed minimum SoM level. This aspect of SoM, (examining the strength of individual mechanisms) is very similar to the concept of ‘strength of function’ under the Common Criteria [128]. But there is another critical aspect to the strength of mechanisms rating that is concerned with overall effectiveness of the security functions. This second facet of SoM is largely equivalent to the concept of attack potential4 in the vulnerability assessment class under the Common Criteria. The evaluator must investigate whether critical mechanisms can be bypassed or avoided via an indirect attack. The existence of indirect attack methods results in an exploitable vulnerability. In this sense, the claimed minimum SoM is a measure of the attack potential that the TOE can resist. A TOE with a high SoM should resist attackers possessing a high level of expertise, opportunity and resources, within the scope of the claims made by the security target. The issue of scope is important because the security target can be very specific but the 4

The three levels of attack potential map to the various components of the vulnerability analysis, (AVA VLA) assurance family. AVA VLA.4 requires resistance to attackers possessing a high attack potential. AVA VLA.3 requires resistance to attackers possessing a moderate attack potential. AVA VLA.2 requires resistance to attackers possessing a low attack potential. AVA VLA.1 merely requires resistance to obvious attacks.

86


concept of exploitable vulnerabilities can be quite general. Vulnerabilities that would be of interest to a card issuer because they are exploitable in practice can be excluded from consideration through restrictions on the scope of the security target. This is a significant loophole in the ITSEC scheme. Because it exists, a careful examination of the precise wording of security target claims is extremely important. Unlike Common Criteria certifications that claim conformance to a certified Protection Profile, there is no rigorous requirement that the security target identify a sensible and realistic set of threats and corresponding security enforcing functions to counter them. ITSEC is intended to provide evaluation criteria capable of producing results that are objective, transparent and reproducible. But assessing whether a claimed SoM is justified in the context of tamper resistant hardware is difficult to do in an objective manner. These difficulties are foreshadowed by ITSEC [164] which clearly states; These criteria are not intended to cover physical aspects of hardware security such as the provision of tamper resistant enclosures or the control of electromagnetic emanations. An assessment of hardware tamper resistance and the strength and appropriate implementation of cryptographic mechanisms is sometimes provided by the government body responsible for such matters, the Communications-Electronics Security Group (CESG) in the UK and Defense Signals Directorate (DSD) in Australia5 . But the nature of the analysis performed and the level of protection provided are only described in the certification reports in the most general of terms, the general thrust being that they are considered appropriate, with no real explanation of why this is so. This limits the transparency and independence of the evaluation which has arguably proven to be a barrier to the recognition and acceptance of such certifications. This is problematic for smart cards because their degree of tamper resistance is a critical aspect of their utility. An evaluation that fails to comprehensively consider physical and side channel leakage attacks is inadequate because in practice their use is widespread. Indeed, an evaluation should consider a full range of state-of-the-art attacks. Again, the Common Criteria has an advantage in this respect because its vulnerability analysis requirements at the assurance level 5

Such an assessment was carried out in the case of the MULTOS evaluations reported in Section 4.3.


87

now commonly targeted by smart cards, (AVA VLA.4 highly resistant) mandate testing for state of the art attacks. There are also difficulties in interpreting the factors of expertise, opportunity and resources in the context of smart cards. These need to be considered when examining a claimed SoM. The concept of resources includes equipment and time, where time is the time taken by an attacker to perform the attack, not including study time [165]. Smart cards for financial and banking applications are issued in significant quantities to untrusted users for their long term retention. It should therefore be expected that an attacker could obtain multiple copies of a card without great difficulty. This allows them to experiment without time constraints, not caring if a number of cards are destroyed in the process. Kuhn [141] states that a common attack methodology involves relatively expensive and time consuming reverse engineering aimed at analysing the security structure and design of the card, (including access control mechanisms, hardware security mechanisms, data protection systems and memory partitioning). Once this is understood, a simpler non-invasive attack, (perhaps involving manipulation of the power or clock signal) can often be designed. Such an attack can often be executed on cards of the same type in seconds [141]. At issue is whether the first stage of the process should be regarded as study time. If it is, a card compromised in this way would be rated basic. If it is not, the reverse engineering effort may justify a claim of a high minimum SoM. This problem of interpretation can be traced to the realisation that ITSEC was primarily envisaged as a scheme to evaluate networked computer systems or components of those systems. The TOEs would typically be expensive parts of a connected, managed, interactive system so an attacker would not have inexpensive access to multiple copies with which to experiment. The aspect of time is more important in these systems because longer attack times increase the likelihood of detection. The likelihood of detection is also a factor in assessing opportunity since attacks taking a longer period of time require greater levels of opportunity to avoid discovery. Collusion with insiders may be necessary to execute lengthy attacks. But with smart cards, detection risk does not necessarily increase with time because an attacker can work in private. So high levels of opportunity are not needed for attacks that require a lengthy execution. Moreover, a generation of cards will commonly be in circulation for in excess of five years. Attack time merely adds to the cost and even substantial costs may be justified by the poten-

88


tial rewards of compromising an electronic purse, credit card or digital signature scheme. Under ITSEC, the required standards of effectiveness to justify a high SoM are exacting, “successful attack being judged to be beyond normal practicality” [164]. Many of the cards in the survey (including [189], [190], [82], [77] and [76], see Table 4.3) have been certified with a high SoM but concluding that an attack on these cards in their operational environment is ‘beyond normal practicality’ may be dangerous. It is now widely accepted that, given sufficient time and expertise, any smart card can be compromised6 . So with financial smart card applications, the threat model is largely driven by matters of economics, measuring attack cost against potential reward. This requires a thorough risk analysis of the complete system. ITSEC can be used to evaluate complete systems but the scope of inquiry can be contained to a greater degree when the TOE is evaluated as a product thereby enabling certification to a higher level of assurance and SoM. These higher level certifications are useful to quote in marketing material and press releases where the constraints or limited scope of the security target are not given emphasis. Readers of this material should take great care that they are not inadvertently misled.

4.2.2

The Common Criteria

The Common Criteria resulted from a cooperative effort to harmonise the disparate frameworks for information technology security evaluation that existed, particularly in Europe and North America. The general concepts and approach have much in common with ITSEC including evaluation against a security target to a defined level of assurance, considering aspects of correctness and effectiveness. The Common Criteria envisages the definition of Protection Profiles (PP), standardised and well understood sets of security requirements developed by a user group to specify their security functionality needs for a particular product. The SCSUG-PP [112] is an example. This allows a manufacturer or product developer to build a product according to the requirements of a PP. They can then have it evaluated and claim conformance to the PP. The product is still evaluated against a security target but the contents of the security target mirror the requirements laid down in the protection profile. 6

This is stated as an explicit assumption in the Smart Card Security User Group Protection Profile (SCSUG-PP), Section 2.6 [112].


89

The degree of assurance that a security target has been met is measured by the EAL scale, with possible ratings from EAL1 to EAL7. As with ITSEC, the scope, depth and rigour of the evaluation increases with EAL level. Each EAL has a predefined package of assurance components drawn from the various assurance classes. Some examples of assurance classes include vulnerability assessment (AVA), development (ADV), tests (ATE), and delivery and operation (ADO). To illustrate the relationship between EALs and assurance components, EAL1 does not include any components from the vulnerability assessment class whereas EAL3 includes AVA VLA.1 (vulnerability assessment), AVA SOF.1 (strength of function analysis) and AVA MSU.1 (misuse analysis). A protection profile can choose to augment the assurance components of the selected EAL by selecting additional components that would normally only be required in a higher EAL. Arguably, the Common Criteria assurance classes represent a refinement to the ITSEC methodology in terms of explicitness and modularity. The Common Criteria includes a catalogue of well defined and understood security functionality requirements [127]. These are known as functionality classes and security targets or protection profiles specify their required security functionality by drawing from this detailed catalogue. The advantage of this approach is that the security functionality will be expressed in an explicit, unambiguous way. The wording is well understood and [127] includes detailed guidance for interpretation and application. The intention of this explicitness is that the precise scope of a security target, (and therefore, a certification) can be established. The framework of functionality classes, families and components also enforces an internal consistency on the functionality claims and a relationship to the identified threats. Because security targets and protection profiles are constructed from a set of standardised components, comparison of certifications by users and mutual recognition by certification bodies is more practical. The Common Criteria provides guidance on calculating attack potential that specifically factors in attack identification time, which is similar to study time under the ITSEC. So under the Common Criteria attack identification time must be included. The detailed guidance on calculating attack potential aims at removing some of the subjectivity from this difficult assessment task and it may offer more clarity that the ITSEC.

90


4.2.3

FIPS 140

FIPS 140 [159] is a security standard that describes metrics, criteria and procedures for cryptographic module design, implementation and evaluation. The program is overseen by the National Institute for Standards and Technology (NIST) in the United States. It was adopted as a standard in 1994 and updated in 2001 to the current version which is FIPS 140-2. Since microprocessor-based smart cards are cryptographic modules, one might expect FIPS 140 evaluation to play an important role in establishing smart card assurance. Up until fairly recently, this has not been the case. FIPS 140 is a US-centric scheme whereas the smart card industry has been focused primarily in Europe. Accordingly, the vast majority of smart card evaluation activity has occurred under the auspices of the more European-centric ITSEC and the Common Criteria schemes. This is changing, particularly as a result of large scale US government and military programs to implement smart cards for user authentication. The US Federal government Information Security Management Act (FISMA) of 2002 requires Federal agencies that use cryptography to protect sensitive information to use FIPS 140-2 evaluated products so smart card evaluation is becoming more prevalent. The scope of a FIPS 140-2 evaluation is defined by the standard itself according to the chosen level of evaluation. There are four levels that demand increasing evaluation rigour and protection. Like the TCSEC, the absence of a sponsor-defined security target leaves considerably less room for ambiguity and manipulation. The standard addresses eleven areas concerned with design, implementation and evaluation: 1. Cryptographic module specification 2. Cryptographic module ports and interfaces 3. Roles, services, and authentication 4. Finite state model 5. Physical security 6. Operational environment 7. Cryptographic key management

4.3. A survey of smart card certifications

91

8. Electromagnetic interference/electromagnetic compatibility (EMI/EMC) 9. Self tests 10. Design assurance 11. Mitigation of other attacks In terms of physical security requirements, Level 1 requires very basic protection. Level two requires some type of lock or tamper evident seal. At level three, the device must be able to actively detect and respond to certain types of tampering. Anderson [10] notes that there is a considerable gap between level 3 devices which may be defeated by clever attackers that have no particular inside knowledge or specialist tools (known as Class 1 attackers under the IBM attacker taxonomy [213]) and level 4 which effectively must resist attacks by state-funded organisations. Level 4 requirements are so demanding that as at August 2005, no more than six distinct devices had been successfully evaluated at this level [214]. Not surprisingly, the highest evaluation level for a smart card is 3. This is consistent with our observation in Section 4.3.2 that SoM-high claims for smart cards are questionable because SoM-high implies that a successful attack is beyond normal practicality [164]. FIPS 140 is prescriptive in its requirements for what must be evaluated and the scope can exclude areas that are highly relevant in practice. For example, the IBM 4758’s hardware and firmware have been evaluated to FIPS 140-1 level 4, and the operating system to level 3. Yet Clayton and Bond [69] have reported an attack which can successfully recover 3-DES keys from the device by exploiting weaknesses in the transaction set API - the Common Cryptographic Architecture (CCA). It is an insider attack which requires authorised access, but the IBM 4758 is intended to defeat insider attacks. Note that the attack does not invalidate the results of the FIPS 140 evaluation because the vulnerability lies a component that was outside of the evaluation scope. This is a further example of the need to review a limited-scope product evaluation with a skeptical eye.

4.3

A survey of smart card certifications

This section presents the survey of smart card certifications. The survey results are summarized in Table 4.3. The table column, Resists Attack Potential

Mondex Purse release 2.0 on MULTOS Version 3 on Hitachi H8/3112 [189] Mondex Purse Version 2.03 on MULTOS V4.1N & SLE66CX160S [79] SLE66CX160S Chipcard Security Controller [82]

5

6

7

8

9

10 11 12

P130 1999

Sept

E6

High

Yes

Mondex International

ITSEC

UK

P129 1999

Sept

E6

High

Yes

Credit Mutuel

Mondex International, Keycorp, Infineon Infineon Technologies

CC

France

99/09 1999

Nov

Low

No

ITSEC

Germany

TUVITDSZ-ITSEC9102-1999 Mar 1999 99/07 Dec 1999

EAL1 Augmented AVA VLA.2 E4

High

Yes

EAL1 Augmented AVA VLA.2

Low

No

BSI-DSZCC-01531999 Nov 1999 99/04 Sept 1999

EAL3

-

Yes

EAL1

-

No

Infineon Technologies

Assurance Level

UK

Country

ITSEC

Scheme

Mondex International

Developers

Limited Scope?

2

4

Resists Attack Potential

MULTOS Version 3 on Hitachi H8/3112 [190]

3

National Westminster Bank Plc National Westminster Bank Plc

Sponsor

1

Reference / Certification Date


Product Name

92

Javacard/VOP GemXpresso 211 on Philips P8WE5032/MPH02 with applets Oberthur B0 v0.32 & Visa VSDC v1.08 [78] Philips Smart card Controller P8WE5032V0B [104]

Groupement Carte Blue

Philips Semiconductors, Gemplus, Oberthur, Visa International

CC

France

Philips Semiconductors

Philips Semiconductors

CC

Germany

Banking Application B4/B0’ Combined Smart Card MONEO/CB on ST19SF16B RCL [80] ST16SF44 A Masked for application SCOT400 version 1 (reference ST16SF44ARHQ) [77] Component ST16601 H/SKG masked for banking application B4/B0’ V2 [76] MULTOS Version 4 on Hitachi AE45C [191] MULTOS 1Q [18]

Soci´ et´ e Europ´ eenne de Monnaie ´ Electronique

IBM Germany, ST Microelectronics

CC

France

ST Microelectronics, Bull CP8

ST Microelectronics, Bull CP8

ITSEC

France

98/01 1998

Apr

E3

High

Yes

Groupement des Cartes Bancaires “CB” Mondex International Keycorp International Keycorp

ST Microelectronics, Bull CP8, GIE CB

ITSEC

France

97/04 1997

Dec

E3

High

Yes

Mondex International Keycorp International Keycorp Infineon AG

ITSEC

UK

High

Yes

AUST

E6

High

Yes

CC

FRA

P167 June 2002 2003/30 October 2003 2003/14 Dec 2003

E6

ITSEC

EAL4 Augmented AVA VLA.4

High

No

MULTOS I4C (1-1-1) on SLE66CX322P/m1484 a24 [75]

Table 4.1: Survey of smart card certifications requires some explanation. For ITSEC certifications it refers to the claimed minimum strength of mechanisms. As was discussed in Section 4.2.1 the SoM claim implies that the TOE can resist attackers possessing the stated level of expertise, opportunity and resources. So a TOE claiming a basic SoM could be compromised by an attacker with a medium level of expertise, opportunity and resources but a TOE with a high SoM could resist an attacker with a high level of expertise, opportunity and resources, successful attack being beyond practicality. For


93

the Common Criteria certifications, the value in this column is determined by the vulnerability component selected from the AVA VLA assurance family . Without augmentation AVA VLA.1 applies to EALs 1-3. AVA VLA.1 does not require the evaluator to conduct an independent search for vulnerabilities. It merely requires that there are no obvious exploitable weaknesses. Therefore a TOE certified with vulnerability component AVA VLA.1 might be compromised by an attacker with a low attack potential. Table entries 6 and 7 have no entry in this column because they are EAL3 and EAL1 certifications. They have not been certified to resist attackers with a low attack potential. Entries 3 and 5 are EAL1 certifications but they have been augmented by the inclusion of vulnerability component, AVA VLA.2. This vulnerability component requires an independent search for vulnerabilities that could be exploited by an attacker with low attack potential. The TOE must resist such attackers. The column labelled ‘Limited Scope?’ is concerned with whether there are significant limitations on the scope of the evaluation . Some interesting patterns emerge. All of the surveyed ITSEC certifications claim a high minimum SoM, implying that successful attacks are not practical, even for attackers with a high attack potential. All of these evaluations also have their scope limited in critical ways. Table entries 1, 2, 11 and 12 exclude the integrated circuit from the evaluation while entries 8 and 9 limit the evaluation to phases of the card lifecycle up to and including integrated circuit testing. Bonding, personalisation and actual use are excluded. Entry 4 evaluates very specific security functionality namely, bus and memory encryption with true random number generation, monitoring of operational modes, phase management and espionage protection. This scope limitation raises some interesting issues which are discussed in greater detail in the sections that follow.

4.3.1

Mondex - E6 High or EAL 1 Low

Table entry 2 lists the UK ITSEC certification of the Mondex Purse on MULTOS Version 3 on the Hitachi H8/3112 chip. This product was successfully evaluated at E6, SoM High in September 1999. Together with the MULTOS operating system, these were the first commercial products to achieve the E6 rating. Table entry 3 lists the French Common Criteria evaluation of the Mondex Purse on MULTOS Version 4.1 on the Infineon SLE66CX160S chip. This product was certified at EAL1 augmented with AVA VLA.2. The difference in the certification

94


level achieved by the two Mondex products is significant to say the least. The UK ITSEC E6 certification represents the highest level of assurance and the Highest SoM rating. The French Common Criteria EAL1 evaluation represents the lowest level of assurance, but more importantly, the vulnerability assessment at AVA VLA.2 means that the product is only certified to resist attackers possessing a low attack potential. The certifications imply that attacks on the Hitachi H8/3112 based purse are beyond practicality but attacks on the SLE66CX160S based purse might be achieved by attackers possessing a moderate attack potential. How can this considerable disparity be explained? One possibility is that the SLE66CX160S chip is less secure than the Hitachi H8/3112. But this seems to be a less than satisfactory explanation given that the SLE66CX160S chip was certified at E4 SoM High in March 1999 and the Hitachi H8/3112 has not been certified at all. The certification report for Mondex on the Hitachi chip7 includes the following assumption about the TOE’s environment: The ICC (integrated circuit card) used for the purse is tamper-resistant and withstands tampering attacks with a strength that is consistent with a High SoM. An identical assumption appears in the UK ITSEC MULTOS certification [190]. It is quite clear from other sections of the certification reports that the chip is excluded from the TOE and has not been evaluated under ITSEC. If disparity in the security of the underlying chips cannot explain the differences in certification level8 , it raises the following question. Would the Mondex purse on the Hitachi chip have reached E6 SoM High if the chip had been included in the TOE? We are unable to answer this question but the exclusion of the chip seems somewhat artificial and conspicuous. It is the only instance that we can locate where a certification of a smart card loaded with an application excluded the chip. Table entries 3, 5, 7, 8 and 9 are certifications of smart cards loaded with banking applications and the TOE includes the integrated circuit, operating system and application. The separate evaluations of the MULTOS operating system [190] (where the chip is excluded) and the Mondex purse [189] (where the chip and operating 7

Annex A: Summary of the Security Target- Environmental Assumptions in [189] Another possible explanation is that the TOE could have achieved a higher level of assurance but the sponsor only required or was only willing to pay for evaluation at a lower level 8


95

system are excluded) creates similar uncertainty. The summary of the Mondex purse security target [189] states that “the TOE is also protected against specific hardware attacks by the MULTOS software interacting with the hardware alarm sensors”. But the MULTOS ITSEC evaluators did not examine this aspect of the card’s operation because hardware tamper resistance was simply assumed to justify a high minimum SoM. The evaluator did not perform independent penetration testing to verify it. Also, the security functionality claimed in the MULTOS security target is very specific and focuses on the secure loading of applications and insuring that one application cannot access another application’s memory space. The Mondex application relies on security relevant aspects of the MULTOS operating system that have not been evaluated. For example, Mondex uses the OS primitives CallCodelet and ReturnFromCodelet but the codelet mechanism is excluded from the scope of the MULTOS security target. More generally, the Mondex application relies on the synergistic cooperation of hardware alarm sensors and MULTOS software to defeat certain hardware attacks9 but confidence in this functionality has not been established within the same independent evaluation framework.

4.3.2

Justification for a MULTOS High SoM

In Section 3 the MULTOS Certification report [190] makes its strongest statement regarding the appropriateness of the SoM high assumption: CESG confirmed the evidence provided by MXI and the 3 independent test laboratories supported the Security Target assumption that the Hitachi H8/3112 ICC is tamper resistant and withstands tampering attacks with a strength that is consistent with the High SoM claimed for the cryptographic mechanisms. It is able to make this statement only after carefully defining what SoM high means for the purposes of this certification report. A high SoM for hardware may be summarised as resistance to all types of direct attack except for the following: 9

For example, the security target [189] includes the threat ‘Creating value within a purse using electronic or physical means’.

96


a. an attack by an expert using dedicated equipment with collusion with the Developer and Administrator taking months or years: and b. an attack by an expert using sophisticated equipment with collusion with the Developer, or Developer and Administrator, taking years. This does not conflict with a common sense and generally accepted understanding of what SoM high should mean. But the definition of SoM high goes on to state a critical assumption - one which significantly alters the meaning described above. The assessment of the hardware tamper resistance mechanisms therefore assumed that Developer knowledge is equivalent to the ability to understand the ICC layout and/or operating system services and that Administrator knowledge is equivalent to knowledge of secrets held on the ICC. To be worthy of a high rating the successful attacker must require collusion with the developer and/or administrator (or years to effect the attack). If it were possible for an expert using sophisticated equipment to effect an attack without collusion in months, the high SoM would not be justified. CESG establishes the need for collusion by stating that ICC layout knowledge is equivalent to developer knowledge. CESG is effectively saying, if you have knowledge of the ICC layout and/or operating system services, you must have colluded with the developer. Conversely, if ICC layout knowledge can be gained without developer collusion, the assumption is invalid and the SoM high justification disappears. The assertion that knowledge of the ICC layout is equivalent to developer knowledge is tenuous as best. For instance, Blythe [35] reports effective automated methods for layout reconstruction. While Anderson [10] notes that increasingly small feature sizes require more advanced techniques that demand sophisticated and expensive equipment, he states that smart card pirates have been known to employ the services of commercial reverse-engineering labs that have the requisite expertise and equipment and are used to working in conditions of secrecy. The sophistication of equipment is being indirectly used as a measure of the likelihood that attackers will be able to access it and use it. Yet equipment availability through universities and commercial labs, and information dissemination through the Internet


97

has made this linkage progressively less useful. Kömmerling [141] notes that: With semiautomatic image processing methods, significant portions of a processor can be reverse engineered within a few days. The resulting polygon data can then be used to automatically generate transistor and gate-level netlists for circuit simulations. If an expert with access to sophisticated equipment can reverse engineer an ICC in weeks without the need for any collusion with developers or administrators, CESG’s assumption that ICC layout knowledge is equivalent to developer knowledge is arguably rather questionable. This artificial distortion of the meaning of SoM high seriously undermines the value of the certification reports.

4.3.3

Motivations to exclude hardware from the TOE

Given the clear disadvantages of evaluations that exclude relevant parts of a product from the scope of the TOE, (at least from the perspective of an issuer) what might be the motivation for such an approach? One reason for exclusion of the hardware from the MULTOS evaluations may have been due to a strong desire to achieve the highest assurance level (with its associated beneficial impressions of the ‘highest level of security’) and this was not possible with a combined hardware and software TOE. E6 requires the extensive use of formal methods and a mathematical analysis of combined hardware and software is very difficult. At E6, a high level abstract security policy model (expressing the necessary security properties), and a lower level concrete architectural design must both be expressed formally. The developer must also present a formal proof of correspondence between the two. This proved to be a challenging but tractable exercise for a TOE that was exclusively software, but when the TOE is a complex combination of both hardware and software, it would appear to be beyond the current state of the art. This explanation is supported by the fact that a combined integrated circuit plus MULTOS software TOE developed by Keycorp has more recently been evaluated under the Common Criteria to EAL4+ in 2003 [75]. Keycorp also had the same MULTOS software version evaluated and certified under the ITSEC scheme in Australia in the same year but in this case it achieved E6 assurance [18]. How can the disparity between evaluation levels be explained? Why did the developer not pursue an EAL7 Common Criteria evaluation given

98


that the formal analysis work had already been done (at least for the software) for the ITSEC E6 evaluation? An EAL7 evaluation would be more in line with MULTOS stated commitment to the highest levels of security. Again, the answer would appear to lie in the fact that, for the ITSEC E6 evaluation the Australian evaluators did not examine the hardware, instead choosing to rely on an E4 evaluation of the integrated circuit performed under the German scheme [105]. This raises an interesting question of how a higher assurance certification can rely on a lower assurance certification of a fundamentally important part of the device. An E6 evaluated TOE can only be based on an underlying E4 evaluated product when the security target claims are carefully and somewhat artificially limited. Another reason for exclusion of the hardware may be motivated by a desire on the part of the IC, operating system and application developers to reduce the cost of evaluation and certification. If each layer can be separately evaluated and the results composed when they are brought together in an actual product, repeated evaluations of the underlying layers would not be necessary. If evaluation by composition is not possible then every new combination would require a complete (re)evaluation. For IC manufacturers in particular, this is unacceptable since their products are integrated in a large number of permutations of operating system and application. The issue of composed evaluation is examined further in Section 4.4. The Common Criteria certifications in table entries 3, 5, and 7 evaluate cards loaded with a financial application . These TOEs include the three layers namely, integrated circuit, operating system and application as an integrated whole. Table entries 3 and 5 resist attackers with a low attack potential while entry 7 does not. The assurance level for these certifications of integrated products is EAL1, the lowest under the Common Criteria. This tends to encourage a speculation that attaining high assurance certifications for integrated products under the Common Criteria is much harder. The Smart Card Security User Group Smart Card Protection Profile (SCSUGPP) emphasises that a vulnerability to certain types of threats can only be ascertained by examining the integrated circuit, operating system and application as an integrated whole because effective security relies on a synergistic contribution of these three layers. Resistance to differential power analysis, electromagnetic analysis, fault and glitch attacks (manipulations of the clock signal and power)


99

are examples of threats that must be examined in the context of the integrated platform. SCSUG-PP [112] requires an assurance level of EAL4 augmented by the selection of AVA VLA.3 which demands resistance to attackers possessing a medium attack potential10 . AVA VLA.3 mandates that the evaluator perform and document a systematic search for vulnerabilities. It also includes a refinement to this vulnerability component requiring that the analysis take into account certain guidelines that direct the search for exploitable vulnerabilities: a. The TOE should be designed so that deconstruction to reveal internal circuits and structures requires a high level of equipment, knowledge, and skill. b. The TOE should be designed so that manipulations outside defined operational boundaries do not lead to security vulnerabilities. c. The TOE should be designed so that any logical commands received by it produce responses which do not lead to security vulnerabilities. d. The TOE should be designed so that it is highly resistant to attempts to tamper with the structure and content of internal memories, data transport mechanisms, security functions, and test methods. e. The TOE should be designed so that it is highly resistant to analysis of information which may be available external to the device through monitoring emanations or any of the connections to the device including power, ground, clock, i/o, and reset. This guidance is reflected in the specific identification of these issues as threats and the inclusion of security objectives that address them. They are also directly reflected in detailed functional and assurance requirements. 10

AVA VLA.3 was chosen because it was not thought that the more demanding AVA VLA.4 was attainable for smart cards. Subsequently, new guidance on the application of attack potential to smart cards was issued [49] which indicated that AVA VLA.4 could be met. The guidance somewhat arbitrarily assigns a score to certain types of equipment and expertise and assigns a maximum score to each AVA VLA level. The arbitrary score levels basically add up to the fact that the highest level can be claimed, nothwithstanding the fact that given sufficient time and expertise, any smart card can be compromised. This was quite a controversial restatement of the guidance at the time.

100


Contrast this approach with that of table entry 6, (a Philips Smart Card Controller used as the IC in the entry 5) whose security target specifically excludes threats relating to physical tampering. The security targets for table entries 8 and 9 naturally focus on threats that are relevant to the card lifecycle stages of design, manufacture and testing since the evaluation limits its scope to these phases. These threats include theft, alteration or substitution of the mask, theft or disclosure of application software, personalisation of card(s) by an unauthorised entity, and unauthorised modification of configuration data . It seems reasonable to question whether the High SoM would have been achieved had threats in the environment of actual use been fully considered in the security target. As a consequence, the certification does not provide the card issuer with an authoritative independent assessment of how the card will counter these threats when in the unsupervised custody of untrusted users. This is not to say that card certifications examining the phases of design, manufacture and testing are not important. Since smart cards still rely on security by obscurity to increase an attacker’s work factor, this is a critical part of the card lifecycle where vulnerabilities can be introduced. But it is also only part of the picture. Similarly with the UK ITSEC certifications of MULTOS and Mondex, whose focus is on protocol design and the quality of the software that comprises the operating system and application. This is also very important since software bugs can be exploited simply with a card reader and a PC. But the approach of the SCSUG-PP [112] suggests that still more is needed. Unless a sensible, realistic and complete set of threats are examined and addressed in the context of an integrated product in an operational environment, a certification runs the risk of misleading those who do not carefully study the security target. It is interesting to note that despite the significant effort invested in the development of the SCSUG-PP and the market power of the card issuing organisations that promoted its development, not a single product has been evaluated against it in the five years since its release. Instead, the smart card industry has adopted a more pragmatic and cost effective approach that bypasses the evaluation of integrated products in favour of separate evaluation of layers that they claim can be composed.

4.4. Evaluation by composition

4.4

101

Evaluation by composition

There has been an effort amongst European certification bodies and smart card manufacturers to develop methods under the Common Criteria that permit separate evaluations of the three principal layers of a smart card product (IC, operating system and applications) in such a way that the certification results can be subsequently composed. These methods are presented in Joint Interpretation Library guidance documentation [47, 50]. This would allow, for example, a single hardware evaluation to form the basis of multiple operating system evaluations with that IC. This approach is controversial and not without its problems, particularly at higher levels of assurance. However, it has compelling advantages in terms of reducing the costs and time delay associated with certification, particularly for IC developers who do not wish to participate in an evaluation process every time their chip is included in a smart card product. When an IC is evaluated separately but to support composable certification11 the TOE does not include the operating system or application code. Yet, this code is necessary to make use of the chip’s security features including hardware cryptographic engines, random number generators, memory protection structures and environmental monitoring controls. The bare IC merely presents an interface that can be used by the higher layer - it can do nothing on its own. Since there are known instantiations of operating system and application code that could use the hardware features insecurely, the TOE also includes guidance documentation that describes how the software should use the hardware to avoid vulnerabilities. As part of the TOE, this documentation is also evaluated. The problem is that it is impossible for the IC developer to foresee all the possible ways that an operating system developer might implement the various functions of an operating system. Therefore, the implementation guidance cannot hope to be complete. Moreover, without a specific operating system in mind, the hardware cannot be exhaustively tested because all the possible methods of its use cannot be anticipated. Due to the tight integration and synergy between hardware and software in a smart card, unanticipated interactions can produce unexpected vulnerabilities that are only evident when the product is reviewed in totality. As is the case in many complex systems, the resulting behaviour is 11

For example, against the Smartcard IC Platform Protection Profile [48] that has been developed by Atmel Smart Card ICs, Hitachi Europe Ltd., Infineon Technologies AG, and Philips Semiconductors specifically to support evaluation by composition.

102


an emergent property of the whole which cannot always be anticipated from an examination of the parts. It is not enough for the operating system evaluator to search for logical flaws and confirm that the implementation guidance has been followed, concluding on this basis that there are no exploitable vulnerabilites. The SCSUG-PP makes this point very clear. Evaluation of the combined package of hardware and software is needed. To this end, the SCSUG-PP proposes12 the use of the Common Criteria notion of packages - intermediate combinations of functional or assurance requirements that meet an identifiable subset of security objectives. Packages are meant to support the reuse of evaluation effort but a package evaluation is not intended to produce a certifiable result on it own. Instead, an over-arching protection profile will comprise a number of packages e.g., the SCSUG-PP suggests an IC package, an OS package and an integrated platform package. Non-interdependent aspects of the OS and IC can be evaluated, resulting in separate, reusable evaluation reports that confirm conformance to their respective package requirements. The only original evaluation effort that is required when package components are brought together to form a usable product relates to the parts that are identified in the integrated package, parts that rely on synergistic cooperation across IC, OS and application package boundaries in the composite TOE (for example, evaluating side channel leakage or fault injection vulnerability). Clearly, this goes well beyond assessing that the OS developer followed the IC developer’s implementation guidance. This approach necessarily requires a greater degree of repeated hardware evaluation effort compared to the composite approach that is currently being pursued by smart card manufacturers. It is unlikely to be adopted for that reason. In the currently favoured composition approach, the hardware analysis and vulnerability testing is a one-off activity that occurs primarily to facilitate the IC certification. The alternative approach of evaluation of an integrated product against a protection profile structured as packages offers a much greater potential to support high assurance certification of usable products. By emphasizing that a usable smart card product must be evaluated as an integrated whole due to the high level of synergistic interdependence and interaction between layers, it more closely reflects sound theoretical principles of evaluation of composable subsets, principles that were developed by Schockley and Schell [196] almost twenty years ago13 . According to these principles, evaluation by subsets is only possible where 12 13

See SCSUG-PP Annex D [112] This work contributed to the development of the TCSEC Trusted Database Interpretation,

4.5. Conclusion

103

the security policy enforced by a lower layer is independent of the policy enforced by a higher dependent layer. This means that there must not be any objects that are mediated by more than one subset or layer and more informally, that a higher layer cannot make a lower layer ‘misbehave’. With current smart card architectures, layer interdependencies are rife.

4.5

Conclusion

In this chapter we have presented an analysis of ITSEC and Common Criteria certifications as they apply to smart cards. This included a survey of actual smart card certifications relevant to the finance and banking industry. We highlighted the difficulty in interpreting and determining minimum strength of mechanism and performing vulnerability analysis in the context of smart cards, a problem that flows from the orientation of the two certification schemes toward software and components for networked computer systems. These are typically expensive, monitored and afforded external protection whereas smart cards are inexpensive and issued in large numbers to untrusted users for their long term and unsupervised retention. This together with the nature of a smart card as a small portable device without its own power or clock signal, creates a unique set of threats and considerable difficulty in applying SoM and vulnerability assessment guidance. We discussed the ITSEC certifications in the survey, noting that they all claimed a high SoM but the scope of each evaluation was also limited in some way, either to particular phases of the card lifecycle, by exclusion of the chip from the TOE or by specifically excluding relevant threats. We questioned whether a high SoM would be attained if all threats were considered in the context of the integrated product, as it is issued to the user in its actual mode of use. We contrasted the Common Criteria certifications and questioned whether the security target scope restrictions contributed to this difference. The analysis served to highlight the importance of interpreting a certification in the context of the security target. We examined the continuing trend to evaluate IC, operating system and applications separately and highlighted the difficulties that this approach is likely to create, particularly for certification at higher levels of assurance. We noted TG-021 issued in 1991. This was arguably the first scientifically based treatment of composable evaluation. It has been largely ignored, in part due to its inconvenient implications.

104


that the current methodology represents a departure from the preconditions for evaluation of subsets identified by Schockley and Schell. As a final note we wish to emphasise that evaluations that are limited in scope in some way are still useful, but they do require care in their interpretation. Card issuers will derive the greatest utility from certifications that are based on a realistic and complete set of threats. The SCSUG-PP [112] recognises this and presents a thorough and detailed evaluation baseline. While the design, development and manufacturing phases are important, and software quality is equally important, addressing threats in the context of an integrated product in its environment of use is the only way to arrive at a balanced assessment of a card’s security from the issuer’s perspective. After all, one of the key aims of certification is to provide a basis by which potential purchasers of a product can decide whether it is appropriate for their needs.

Chapter 5

Side channel leakage 5.1

Introduction

Smart cards, RFID tags, wirelessly networked electronic devices and general purpose computers rely on cryptography to authenticate and secure communications over unprotected channels such as the electromagnetic spectrum or Internet. Moreover, cryptography implicitly assumes that secret keys can be kept secret both when they are being stored and when they are being used in the confines of an integrated circuit, processor or embedded system. Unfortunately, this assumption of secrecy may not be well founded because semiconductor based processor logic leaks information about its internal state (including any cryptographic key it may be using) via the side channels of conducted and radiated electromagnetic emissions. This phenomenon is known as side channel leakage. Side channel leakage has received considerable attention in the defense and intelligence communities since the discovery during World War I that battlefield telephones could be monitored remotely by amplifying weak ground-return loop currents [133]. In these early systems, a pair of phones was connected by a single insulated conductor with the circuit being completed via ground spikes to a common earth. An eavesdropper could detect these ground currents by connecting an amplifier to another pair of ground spikes placed within a few hundred meters of the monitored system. In the period between those early discoveries and the mid 1990s, very little work was reported in the open literature regarding exploitation or prevention of side channel leakage. The US National Security Agency (NSA) 105

106

Chapter 5. Side channel leakage

established a classified program code named Tempest in the early 1960s to investigate defensive Emissions Security (EMSEC) techniques. This was around the same time that the British government’s intelligence agency, GCHQ successfully monitored encrypted communications from the French embassy in London after they noticed that there was a very faint compromising signal on the telex cable in addition to the encrypted traffic. It was fortunate for GCHQ that the cipher machine directly leaked the plaintext in this way because the diplomatic code had resisted their cryptanalytic efforts [216]. This anecdote exemplifies the working principle that it is more difficult to attack the mathematical underpinnings of a cryptographic system than it is to find an exploitable flaw in the implementation. Since the seminal work of Kocher et al. [140, 139] side channel analysis has spawned a powerful range of attacks against smart cards and other trusted hardware. In Section 5.2 we review the basic principles of side channel analysis and briefly report on our investigations into the leakage characteristics of a programmable smart card and how these can be exploited to implement the relatively new correlation power analysis (CPA) attack technique against a symmetric cipher algorithm. With this work our aim was to explore and verify the correlation technique, recently described by Mangard [150] and Brier et al. [45]. The correlation approach has received considerably less attention compared to differential power analysis (DPA) which was pioneered by Kocher et al. [139] and is based on a statistical technique called ‘difference of means’. In Section 5.3 we turn the usual conception of side channel leakage as a vulnerability on its head by proposing a novel method which exploits the phenomenon, not as an attack tool but as a communication channel for a distance bounding protocol. Distance-bounding protocols have been proposed as a means of detecting relay attacks, also known as mafia fraud. Relay attacks present a serious threat to RF security devices (contactless smart cards, RFID tags and the like) because they undermine the implicit assumption that the device is physically close to the reader when it is operating. In applications such as physical access control this assumption of physical proximity is all-important. Distance-bounding protocols require a communication channel that can exchange single bits with extremely low latency - of the order of tens of nanoseconds (ns). This unconventional and technically demanding communication requirement has prompted Hancke and Kuhn to assert in a recent publication [117] that ultra wide band (UWB) radio is necessary to achieve a useful distance-bounding resolution. We analyse this

5.2. Attacking trusted hardware with side channel analysis

107

assertion and highlight some flaws in their argument. We then present our alternative method. Since the addition of UWB would add appreciable cost and complexity to contactless smart card integrated circuits, it could only be justified in the absence of simpler, lower cost alternatives. Our proposal is capable of detecting sophisticated relay attacks without resorting to the considerable expense and complexity of UWB radio. In the same paper, Hancke and Kuhn [117] also propose a very efficient distance-bounding protocol which is secure against mafia fraud, but which does not protect against a related variant, known as terrorist fraud. We address this gap by presenting a terrorist fraud resistant distance bounding protocol. In summary, the main contribution of this chapter is threefold: • The proposal of a novel communication method for distance bounding based on the phenomenon of side channel leakage, that has very low latency and which is comparatively inexpensive to implement; • Experimental validation of the timing resolution that the proposed communication technique can support when applied to ISO 14443 contactless smart cards; • The proposal of the first symmetric key based distance-bounding protocol which is resistant to terrorist fraud and is computationally efficient enough to be implemented in resource constrained devices.

5.2

Attacking trusted hardware with side channel analysis

5.2.1

CMOS power consumption and side channel leakage

The Complementary Metal Oxide Semiconductor (CMOS) logic gate is the basic building block of most integrated circuits and processors. Although there is only a negligible current leakage when a CMOS logic gate maintains the same logical state across a clock transition, it dissipates a comparatively large amount of power when its logical state switches from 0 to 1 or 1 to 0. As a consequence of this behaviour, it is possible to coarsely model the instantaneous power consumption of a CMOS circuit as the sum of the power dissipated by each transitioning

108


gate plus a Gaussian noise component. This is of great practical interest from a security perspective because processor instructions that directly manipulate data, (e.g. MOV, XOR) leak information about the data in the amount of power that the instruction consumes. For example, a MOV instruction with an operand of all zero bits consumes less power than one where all bits of the operand are set to ones. In fact, it is possible to ‘read’ the Hamming weight of the operand (the number of bits in the byte that are set to one) directly from the trace of the power consumption at the time the instruction is executed. Eight different operand Hamming weights can be clearly seen in Figure 5.1 as eight distinct peaks of increasing amplitude. We recorded these traces from a PIC16F84 smart card microcontroller executing a MOV instruction with operands of increasing Hamming weight. We observed the same pattern of data dependent power consumption with the XOR instruction. Consider that the operand may be a cryptographic key that is assumed to be securely protected by the processor. By monitoring the device’s power consumption, (a conducted emission) an attacker can discover important information about the key, possibly enough to violate the assumption of secrecy. A circuit also produces radiated emissions whose features are correlated, both directly and more subtly, to the instantaneous power consumption and therefore, to the data that the processor is manipulating. This is a simple consequence of the observation that a changing current flowing through a wire creates an electromagnetic field and the nature of the current can be inferred by monitoring the field. Since an integrated circuit is largely comprised of wires and current loops, each contributes its part to the complex radiated emission field. In 2001, Samyde and Quisquater demonstrated that useful and detailed information about the internal state of the device can be inferred by monitoring its electromagnetic emissions [186]. Moreover, coupling effects due to parasitic capacitance between wires in an integrated circuit can result in the logical data they carry being modulated on strong carriers such as the higher order harmonics of the clock frequency [4]. The information can be recovered by tuning a sensitive wide band demodulator to these carrier frequencies. In portable devices such as smart cards and RFID tags, effective electromagnetic shielding remains elusive due to size constraints so radiated side channel leakage is a serious issue. This is compounded by the fact that electromagnetic emissions can be monitored at a distance, leading to plausible, real-world attack scenarios. The electromagnetic side channel appears to


109

Figure 5.1: Power consumption traces of MOV instruction with operand Hamming weights from 1 to 8. be more difficult to sanitize than the conducted side channel whose information content can be somewhat reduced via filtering.

5.2.2

A correlation power analysis attack on DES

In the previous section we described information leakages that could be directly inferred by monitoring a single execution of a vulnerable instruction. By way of example, Figure 5.1 showed that the Hamming weight of the operand of a MOV instruction could be read from its corresponding power trace. This is known as simple side channel analysis, i.e., when useful information is inferred from the analysis of a single trace of a side channel. While knowledge of the Hamming weight reduces the number of possible values an unknown key can take, it does not disclose the actual value since the positions of the set bits remains unknown. The technique of differential side channel analysis (DSCA) or its more widely known specific embodiment, differential power analysis (DPA) can address this problem. DPA, first introduced by Kocher et al. [139] is a very powerful analysis method that measures side channel information over many runs using the same

110


secret key but different input data. The data is then statistically analysed to reveal whether a guessed key bit (or bits) is correct. As the word ‘differential’ in DPA would suggest, Kocher’s technique uses a statistical technique known as ‘difference of means’. This takes the form of splitting the data into two sets that would have different properties if the guessed key bit were correct, and hence be able to be distinguished using a statistical analysis. If the statistical analysis reveals no difference, the guessed key bit(s) is(are) assumed to be incorrect and another guess is tried. While DPA may have received the most attention in the literature, it is not the only statistical side channel analysis approach. We have investigated an alternative but lesser known method outlined in Mangard’s recent thesis [150] and introduced by by Brier et al. [45], to attack the DES algorithm [155]. One of the more compelling advantages that Brier et al. claim for their so-called correlation side channel analysis model is that is can work with a smaller number of power consumption measurements than DPA. Our attack is based on ideas that have been previously described in the literature, at least in general terms, so we make no claim of novelty. We provide a brief description of our implementation here to illustrate the basic principles of correlation side channel analysis and because this technique has received considerably less attention compared to Kocher’s seminal ‘difference of means’ approach. In order to measure the power consumption, we used a readily available smart card programmer, modified to include a current sensing resistor in the ground return of the onboard card holder. With a smart card inserted, the signals across the resistor were captured with a digital oscilloscope operating at a sampling rate of 200 MS/s. The digitised signals were transferred to a PC for further analysis. Figure 5.2 shows a typical captured waveform. We used a PIC16F84 based smart card which was programmed using PIC assembly code. To be vulnerable, the implementation being attacked must include an instruction that combines a few bits of the key with known input data to produce some intermediate result. This instruction should exhibit a data dependent side channel leakage. In our case, we exploit the fact that the Hamming weight of the result of an XOR operation leaks in the power consumption trace. Furthermore, in the final iteration of the DES round function, the round subkey is XORed with a data block whose value can be directly calculated from the output (ciphertext) by reversing the final permutation, so the attack preconditions are met.


111

Figure 5.2: Typical measured waveform across current sensing resistor. Our approach exploits the XOR combination of eight bit words of data and key in the DES round function1 immediately prior to S-box substitution. It is worth noting that more efficient software implementations of the DES algorithm may not be vulnerable to the attack technique we implemented, because they employ data handing optimisations to better exploit the eight bit hardware. These optimisations may break the necessary dependency of power consumption on instruction operands that are slices of key material instead of contiguous blocks. However, optimised versions may still fall to more algebraically sophisticated versions of correlation power analysis as described by Brier et al. [45]. The attack works as follows: we record discrete time/power traces for the algorithm as it processes approximately three hundred different plaintext inputs with the same key. The corresponding ciphertext outputs are also recorded. This produces a matrix where each row holds the time series of discrete power sample values for the algorithm as it processes a single ciphertext, and each column holds the instantaneous power consumption at time t. The traces must be carefully aligned so that power consumption data points in each column correspond to the same algorithmic ‘event’ across each of the 300 ciphertexts. An algorithmic event is represented by a column or vector of 300 discrete power values. One of these ‘event vectors’ (actually a few due to the high sampling rate, but for simplicity 1

For our analysis we use simulated data with the same statistical properties for the 48 bits that are combined with the key.

112


we will refer to one) will correspond to the targeted, vulnerable XOR operation. This concept is illustrated in Figure 5.3.

Figure 5.3: Instantaneous power consumption at time t across multiple traces represents an event vector. For each ciphertext we reverse the final few steps of the algorithm to calculate the data block (R32) that was XORed with the 48 bits of the final round subkey. Due to the structure of the DES algorithm, we do not need to know the correct key to be able to do this. Since we are attacking the subkey 8 bits at a time, we calculate the Hamming weight of the result of the XOR combination of the relevant 8 bits of the known data block with each of the 256 possible values of the subkey byte. We populate a matrix of 300 rows, each corresponding to a ciphertext, and 256 columns, each corresponding to a possible value of the subkey. The data values in a column contain the calculated Hamming weights of the intermediate XOR result for a single key guess across each of the 300 ciphertexts. A column can be thought of as a vector of hypothetical power consumption values for one ‘guess’ of the key. We take each of these 256 ‘guess’ vectors in turn and calculate its correlation with each of the t event vectors described in the previous paragraph. As we noted, one of the event vectors will correspond to the targeted XOR event. When the guess vector for the correct key is processed against the relevant XOR event vector, there will be a high degree of correlation (see Fig-


113

ure 5.4) because the power consumption of the XOR instruction (represented by the event vector) is a function of the Hamming weight of the XOR result (represented by the guess vector). More simply, the XOR event vector and correct guess vector comprise pairs of data points which each ‘swing in the same direction’. Incorrect guess vectors will not swing in the same direction across all pairs and will therefore not correlate to the same degree. This concept is illustrated in Figure 5.5. The high correlation reveals the correct subkey byte. We recalculate the guess vector matrix for the next subkey byte and repeat the process.

Figure 5.4: Correlation for correct and incorrect guess vectors. The 0.8 peak signifies the correct subkey. Note that we do not need to know where in a trace of t power values the XOR event occurs. The knowledge that somewhere there is a calculation of an intermediate result that directly combines key bits and known input bits via an instruction that leaks information about its operands is enough.

114


16

Hamming Weight / Voltage x10-2

14

12

10 Event Vector Correct Guess Vector Incorrect Guess Vector

8

6

4

2

0 1

2

3

4

5

Cipher Text

Figure 5.5: Event vector, correct and incorrect guess vectors.

5.2.3

Current practical significance of power analysis attacks

Most published attacks, including our own, are against unsecured software implementations of algorithms on programmable microcontrollers such as the popular PIC16F8 series or the Atmel AVR. Bespoke software implementations give the investigator a greater degree of experimental control and convenience compared to attacking a commercial smart card. For example, the implementation will commonly include marker code that changes the voltage level on an IO pin to trigger an oscilloscope precisely at the point of interest - perhaps the beginning of a targeted round or just the start of the algorithm. This reduces the quantity of data that needs to be collected and processed. Side channel analysis relies heavily on computationally intensive statistical processing, so the ability to precisely target the point of interest and thereby reduce the data analysis workload can often be a prerequisite for a successful attack. Needless to say, this type of triggering is not a supported feature on commercial smart cards. This is just one example of how attack scenarios reported in the academic literature often have what might be


115

regarded as an unfair advantage. Consequently, there is a risk that the already large and rapidly growing volume of published material on smart card attacks may leave a general impression of pronounced vulnerability that is not entirely justified - because most researchers are not attacking real-world targets. Indeed, these days, reports of black-box side channel analysis attacks (where the defensive countermeasures and implementation details are unknown to the attacker) against state of the art commercial smart cards are rare in the open literature, although it is hard to gauge how much this might also be due to legal impediments to publishing. The results that are obtained from programmable chips are certainly valid insofar as the PIC architecture does behave like a commercial smart card, at least at the level of logic elements (gates, bus lines etc.) because it is constructed using the same CMOS process technology. However, these experimental implementations will generally not implement the full range of now well-understood countermeasures found in state of the art commercial smart cards. In the academic literature, countermeasures are commonly implemented in isolation and found to be inadequate in the face of a newly proposed attack. For example, it is well known that masking techniques can be countered by higher order DPA attacks (see for example [153, 211]). Similarly, signal processing techniques can counter timing decorrelation measures [68]. But there is scant work reporting successful attacks on implementations where multiple defensive measures are used in concert. Carluccio et al. [56] report an unsuccessful attack on a currently-available DESFire contactless smart card that implements the triple DES algorithm. With 10,000 test samples recorded at a comparatively high sampling rate of 1 GHz, their differential electromagnetic attack was unable to recover the correct key. It is highly likely that the card they attacked uses a hardware DES engine, since hardware implementations are considerably faster than software and contactless cards require very short transactions times. When the algorithm is implemented in hardware, many algorithmic events are processed in parallel each clock cycle ¨ et and this tends to blur the leakage of any useful information. In [168], Ors al. note the absence of any successful published attacks against hardware AES implementations. They claim to demonstrate the feasibility such attacks by recovering eight key bits using 4000 traces against a Fastcore ASIC (application specific integrated circuit) implementation of the AES. The fact that they could recover only eight bits from a 128 bit key using such a large number of traces

116


underlines the degree of inherent attack resistance that hardware crypto engines have. There is still a pressing need for more work in this area to assess and quantify the apparent effectiveness of combined countermeasures since timing decorrelation, (internal clock jitter, random NOP cycles) power filtering and algorithm level masking would appear to make attacks very difficult in practice. The situation has certainly improved since 1998 when Kocher claimed that all commercially available smart cards could be broken with side channel analysis [139]. But even if we knew how to build devices that were provably secure against all attacks, it would not make sense to deploy them to replace all the units with known vulnerabilities because the less secure devices are likely to be cheaper. Real-world systems are designed, deployed and managed according to principles of risk management and the cost of risk mitigation or avoidance must be balanced against the potential loss. In the commercial world it makes no sense to spend ten dollars to avoid potentially losing five. Just as safes are rated according to the time and resources required to break them [32], so smart cards and other forms of trusted hardware need to be rated according to the time, expertise and equipment required to bypass their protections. In this regard there is still much to be learned from the older discipline of physical security. The development of the rating system for safes was driven largely by the insurance industry, with the US Underwriters Laboratories evaluating products and publishing independent reports. Insurance still does not figure prominently in the management of information security risks. In Chapter 4 we examined some of the challenges that need to be overcome before such a rating system will become possible.

5.3

Applying side channel leakage to distance bounding protocols

In this section, following a brief introduction to relay attacks and the distance bounding protocols that aim to detect them, we present a novel distance bounding protocol that is resistant to so called terrorist fraud. We then identify specific requirements for implementing distance bounding protection on an ISO 14443 contactless smart card. In response to these requirements we propose a novel communication method based on side channel leakage. We report the results of practical experiments to estimate the timing resolution of the proposed method.

5.3. Applying side channel leakage to distance bounding protocols

5.3.1

117

Introduction to relay attacks and distance bounding

Contactless ISO 14443 smart cards, also known as proximity cards and more loosely as RFID tokens, are playing an increasingly important role in distributed systems. They are used for physical and logical access control, as credit cards, electronic passports, driver licenses and other identity documents. Recently, Kfir and Wool [136], and Hancke and Kuhn [116] independently presented practical, low cost relay attacks on ISO 14443 contactless smart cards, highlighting their vulnerability to this type of fraud. The relay attack is particularly insidious because it works without the need to circumvent any cryptographic security protocols that may be in place. Moreover, relay attacks present a serious security threat to contactless smart cards because they undermine the implicit assumption that the device is physically close to the reader when it is operating. In applications such as physical access control this assumption of physical proximity is all-important. By virtue of limits imposed on readers by the standard, ISO 14443 cards have a short operating range of 10 cm from the card reader [124], though larger distances are physically possible [136]. There is an implicit assumption that if a reader is communicating with a card, that card must actually be within 10 cm of the reader. Furthermore, this close physical proximity is assumed to imply the authorisation of the cardholder who is required to keep the card in their possession and under their control. However, the first of these assumptions may not be well founded because an attacker can simply relay the RF messages from the reader to a legitimate card that is far away and relay the card’s responses back to the reader via interposed transceivers. The second assumption is similarly unsound because a card can be operated without the cardholder’s awareness, for example, while it remains in their pocket. The attacker only needs to get a rogue reader device close enough to the card to power it and to execute the transaction, which typically takes in the order of milliseconds. Kirschenbaum and Wool [138] have constructed a portable, extended-range reader device from electronic hobbyist supplies and tools. It boosts the read range to 25 cm and they identify simple improvements that they claim should extend the range to 35 cm. The rest of this Section is structured as follows. In Section 5.3.2 we review distance bounding protocols which have been proposed as a means of detecting relay attacks. We examine Hancke and Kuhn’s recent proposal in particular, and explain why it is not resistant to terrorist fraud. In Section 5.3.4 we describe

118


our new protocol. In Section 5.4.2 we present an analysis of the communication channel requirements for distance bounding. This analysis highlights the importance of low communication latency, which is not purely a function of the channel bit rate. We propose the use of side channel information leakage as a low latency communication mechanism. In Section 5.4.6 we report on investigations into adapting the existing load modulation circuitry in proximity cards to our proposed communication technique. We present experimental results indicating that a modified load modulation scheme can provide sufficient timing resolution to detect sophisticated relay attacks launched by well funded attackers. Our proposed approach avoids the additional cost and complexity of adopting UWB radio. In the protocol analysis we use the following notation: • We use ← to indicate assigment to a variable. If A is a set then x ← A assigns to x a random element of A according to the uniform distribution. • {0, 1}n denotes the set of all strings of bit-length n. • Given a string s, we use si to denote the ith least significant bit of s; • ID U is the identity string corresponding to user U . • time() is a function implemented at all parties that returns the internal clock time. To measure the time between two events we use two instructions, Start clock and Stop clock, such that Start clock ∆t assigns to = time() and Stop clock ∆t, assigns tf = time() and ∆t = tf − to . Note that we do not require clocks at different parties to be synchronised. • Ssk U (m) denotes the asymmetric digital signature of user U on message m. • Vpk U (σ, m) denotes verification of the signature over message m with the public key of user U .

5.3.2

Distance-bounding protocols

Distance-bounding protocols [42, 54, 187, 51, 117] have been proposed as a means of detecting relay attacks. A distance-bounding protocol is an authentication protocol between a prover A and a verifier B, whereby B obtains corroborating evidence about A’s claimed identity and physical proximity at the time the protocol


119

¯ ←−−−−−−−−−−−−−→ A¯ ←→ B A ←→ B Figure 5.6: Adversarial setting is run. Distance-bounding protocols can be thought of as traditional identification protocols enhanced with a distance-bounding mechanism. The former provides assurance as to the identity of the prover, while the latter allows the verifier to upper bound the distance which separates them. This dichotomy of distancebounding protocols into an identification mechanism and a distance-bounding mechanism is readily seen in most proposals, which can be easily decomposed into an identification part, matching some known identification protocol, and a distance-bounding part, consisting of multiple fast challenge-response rounds. The distance between prover and verifier is upper-bounded by measuring the time intervals between challenges being sent and responses being received. The first distance-bounding protocol was proposed by Brands and Chaum [42] to thwart mafia fraud - the name for relay attacks against identification protocols first coined by Desmedt [83]. In a mafia fraud, the adversary consists of two parts: ¯ sitting in between the real verifier B and a rogue prover A¯ and a rogue verifier B, ¯ simply relay the protocol messages prover A as shown in Figure 5.6. A¯ and B between A and B. Hence what the adversary achieves is to fool B into thinking ¯ This that he is directly communicating with A, when in reality he is talking to A. attack does not violate the traditional security requirements of identification protocols, however it may be a concern if the verifier incorrectly makes assumptions as to the proximity of the prover. For example, consider the case where B is an RF reader enforcing access control through a door and A uses an RF proximity card to authenticate to B. A successful mafia fraud attack would allow an ad¯ who is versary to open the door when A is sitting at a restaurant close by to B stealthily running the identification protocol with A’s card and relaying all the ¯ who is present near the door running the identification protocol information to A, ¯ Brands and Chaum [42] described with B using the messages received from B. two protocols that are secure against mafia fraud attacks. The underlying identification protocols are a signature based challenge-response mechanism for one of them, and a zero-knowledge identification protocol for the other. These protocols use public key cryptographic operations, which are computationally demanding for highly resource constrained devices.

120


Protocol 1 shows the signature-based distance-bounding mechanism that underlies Brands and Chaum’s original proposal [42]. It provides assurance that the source of a received message is close by within a given distance. In Protocol 1, this distance is parametised by the maximum challenge-response delay allowed, ∆tmax . The protocol requires a secure commitment scheme where commit(γ) denotes a commitment on γ. The commitment scheme has two phases: commit and open. In commit, A sends to B a value u that binds A to a bit string γ without revealing any information about γ. The commitment u stops A from asserting at a later point a different value for γ. In open A sends to B a value v that together with γ allows B to verify that u was a valid commitment on γ. Brands and Chaum’s protocol proceeds as follows: A starts the protocol by sending a commitment on an n-bit random string γ. The verifier B stores the commitment u sent by A, and generates a random n-bit string. A fast n-round challengeresponse phase begins then. At each round, B sends challenge bit αi , to which A must respond with βi = γi ⊕ αi . B measures the time ∆ti elapsed between challenge and response. Once the challenge-response phase finishes, A opens the commitment, thus revealing γ and v to B, who then verifies that the responses received in the previous phase were correct. The verifier also makes sure that all delays ∆ti are less than the bound ∆tmax . If all checks are successful, B outputs accept, otherwise B outputs reject. Desmedt [83] considered another type of active attack against identification protocols, which he called a terrorist attack. Here, unlike mafia fraud attacks where the prover is oblivious to the attack that is underway, the prover A con¯ to intentionally try to fool the verifier B as to A’s location. spires with A¯ and B Defending against terrorist attacks is more difficult, since A’s secret information (e.g. authentication keys) may be used in a manner which is differerent to what the protocol prescribes. Clearly, if A is prepared to release their secret authen¯ then the attack is trivially successful. When dealing with tication keys to A, terrorist attacks, we preoccupied ourselves with attacks where the prover does not reveal to accomplices secret information that will allow the accomplices to impersonate A in more than a single run of the protocol. In particular, A does not reveal the long term private key. To the best of our knowledge, the only distance-bounding protocol that protects against terrorist fraud and does not require trusted functionality is the protocol of Bussard [51]. His solution is also public-key based and uses zero-knowledge techniques, making it impractical for


A (Prover) γ ← {0, 1}n (u, v) ← commit(γ)

βi ← γi ⊕ αi s ← α1 kβ1 , . . . , αn kβn σ ← Ssk A (s)

B (Verifier) u −−−−−−−−−−−−−−→ For i = 1 to n do: α ←−−−−−−−i−−−−−−− βi −−−−−−−−−−−−−−→ End for γ, v, σ −−−−−−−−−−−−−−→

α ← {0, 1}n Start clock ∆ti Stop clock ∆ti s ← α1 kβ1 , . . . , αn kβn Check Vpk A (σ, s) = 1 Check γ = open(u, v) For i = 1 to n check: βi = γi ⊕ αi ∆tmax ≥ ∆ti End for

Protocol 1: Brands and Chaum’s distance-bounding protocol [42]

121

122


implementation in low-cost RF computing devices.

5.3.3

Hancke and Kuhn’s distance-bounding protocol

Hancke and Kuhn’s [117] distance-bounding protocol is highly efficient. The protocol (see Protocol 2) is based on a symmetric-key identification mechanism, where the prover and verifier share a common secret value s. The distance is parametised by the maximum challenge-response delay allowed, ∆tmax . The protocol starts by having A and B exchange random nonces rA and rB . The prover then applies a keyed hash function h to the concatenation of the nonces rA krB to get d. The prover splits d into two n-bit strings l and r. A fast n-round challengeresponse phase begins. At each round, B sends challenge bit αi , to which A must respond with the ith bit of l if βi = 0, and the ith bit of r if βi = 1. The correct response is thus determined by αi which A does not know in advance. This stops A from responding before receiving each αi . The verifier checks that the received response is correct. (He can do so, since he can also compute l and r.) Additionally, B measures the time ∆ti elapsed between challenge and response. B makes sure that all delays ∆ti are less than the bound ∆tmax . If all checks are successful, B outputs accept, otherwise B outputs reject. If B accepts, assuming that information cannot travel faster than the speed of light c, then the distance between A and B is upper-bounded2 by c∆tmax /2. Hancke and Kuhn [117] showed that the probability that a mafia fraud attacker n can make B falsely accept is bounded by 43 . Protocol 2 is not secure against terrorist fraud attacks. A remote A can always relay r and l to a rogue prover A¯ who is close by to B. Note that the time-critical phase does not start until B sends the first challenge bit, and that releasing r and l does not compromise the long-term secret s. As we have previously noted, to our knowledge, the only distance-bounding protocol that protects against terrorist fraud attacks is that of Bussard [51] and his solution is computationally expensive. The basic idea of Bussard’s protocol is to force the prover to give away their private key in order to mount a terrorist attack. The prover computes c = Ek (sk A ), the encryption of her long-term (important) private key sk A under a newly generated session key k. The verifier then sends challenge bits αi to the prover. If αi = 1, the prover must respond 2

A better bound can be obtained when we know the time ∆tp that it takes for A to process a challenge. In this case, the distance is bounded by c(∆tmax − ∆tp )/2.


Shared Information: Secret key s.

A (Prover) rA ← {0, 1}m d ← h(s, rA krB ) l ← β1 k · · · kβn r ← βn+1 k · · · kβ2n

B (Verifier) rB ←−−−−−−− −−−−−−− rA −−−−−−−−−−−−−−→

For i = 1 to n do: α ←−−−−−−−i−−−−−−− ( βi ←

li ri

: αi = 0 : αi = 1

βi −−−−−−−−−−−−−−→

rB ← {0, 1}m d ← h(s, rA krB ) l ← β1 k · · · kβn r ← βn+1 k · · · kβ2n α ← {0, 1}n Start clock ∆ti Stop clock ∆ti Check βi Check ∆tmax ≥ ∆ti

End for Protocol 2: Hancke and Kuhn’s distance bounding protocol [117].

123

124


with the bit ci from the ciphertext. If αi = 0, the prover returns the bit ki of the session key. Thus, in order to successfully and timely reply to the challenges the prover must be in possesion of c and k, and therefore of sk A .

5.3.4

New distance-bounding protocol

Bussard’s protocol [51] protects against terrorist fraud attacks, but its use of asymmetric techniques makes it computationally demanding. On the other hand, the more computationally efficient protocols published, based on symmetric key authentication, do not afford terrorist fraud resistance. In this section, we propose the first symmetric key based distance-bounding protocol which is resistant to terrorist fraud attacks and is efficient enough for implementation in low cost devices. We enhance the protocol of Hancke and Kuhn [117], which is to our knowledge the most efficient mafia-fraud resistant protocol, by applying the basic idea behind the terrorist fraud resistance of Bussard’s protocol. The result is shown as Protocol 3. The efficiency of the new protocol remains practically unchanged with respect to Hancke and Kuhn’s [117], the main difference being the addition of a symmetric encryption (in practice, an XOR operation as discussed below). In Protocol 3, we have made explicit the identities of prover and verifier by adding them in the initial exchange of nonces. Both A and B now use a keyed hash function f to derive a pseudo-random n-bit key k , which is used to encrypt the long-term shared secret s using a one-time pad. In practice, f can be a message authentication code (MAC) algorithm such as CBC-MAC or HMAC [86]. The fast challenge-response phase of the protocol is similar to Hancke and Kuhn’s, except that now the ith bit of the ciphertext c is returned when αi = 0 and the ith bit of the key k otherwise. Note that knowledge of k and c is equivalent to knowing the shared secret s, since s = k ⊕ c. B checks the correctness of each response. If any response bit is incorrect, perhaps due to channel noise, B will send an extra error message to A. This additional message indicates which responses were incorrect– this is required to protect against terrorist attacks as discussed below. Noise errors In practice, as discussed by Hancke and Kuhn [117] and further elaborated in Section 5.4.2, the communications link between prover and verifier during the fast


125

Shared Information: Secret key s.

A (Prover)

B (Verifier) ID B , rB ←−−−−−−−−−−−−−−

rA ← {0, 1}m k ← f (s, ID A kID B krA krB )

rB ← {0, 1}m

ID A , rA −−−−−−−−−−−−−−→

c←k⊕s

k ← f (s, ID A kID B krA krB ) c ← k ⊕ s, α ← {0, 1}n

For i = 1 to n do: α ←−−−−−−−i−−−−−−− ( βi ←

ci ki

: αi = 0 : αi = 1

βi −−−−−−−−−−−−−−→

Start clock ∆ti Stop clock ∆ti Check βi

End for h

error ←−−−−−−−−−−−−−−

i

Protocol 3: Distance bounding protocol resistant against terrorist attacks

126


challenge-response phase is unreliable. This means that the protocol should tolerate transmission errors during that phase, by increasing the number of challengereponse rounds according to the expected error rate. We refer the reader to Hancke and Kuhn’s paper [117] for the quantitative analysis.

5.4

Security of new protocol

Here, we informally analyse Protocol 3 with respect to security against mafia and terrorist fraud. We note that it is still an open problem to provide formal definitions of security against relay attacks. Mafia fraud Firstly we show that the new protocol is secure against mafia fraud. The adversarial setting corresponds with the one depicted in Figure 5.6. A does not ¯ and A is not close to B, which implies cooperate with the attackers A¯ and B, ¯ to pass on the challenge to A, get that it is not physically possible for A¯ and B the response from A and relay it back to B in time. Since f is pseudo-random, the one-time pad encryption c is also pseudorandom, i.e. it is impossible for an adversary to guess any bit ki or ci with ¯ can do is probability non-negligibly different from 1/2. Hence the best A¯ and B guessing the challenge bit before it is output by B and send it to A. This could ¯ withholds be done before the challenge-response phase starts. For example, B message 2 for a time long enough to allow him to complete a run of the protocol ¯ himself. B ¯ then passes to A¯ the value with A, using challenges α ¯ i chosen by B rA , the challenges α ¯1, . . . , α ¯ n , and the responses β¯1 , . . . , β¯n . A¯ then completes the protocol with B. Since B chooses the challenges αi uniformly at random, on average only half of the challenges α ¯ i will coincide. When this happens, A¯ can send the valid response β¯i ; otherwise, A¯ can only guess the right reponse with a ¯ fool the verifier into probability of 1/2. Overall, the probability that A¯ and B accepting is essentially (3/4)n , which is negligible. Terrorist fraud To see that the new protocol protects against against terrorist fraud, we argue that A must release significant information about s to the accomplice A¯ in order to have B accepting. Firstly notice that, in order to have B accepting, someone

5.4. Security of new protocol

127

close to B must have the right challenged bits of k and c, which only A and B can compute. Let’s consider how A can help A¯ to make B accept in a protocol run. Given that A is not close by, for each challenge bit αi , A will have to either ¯ or alternatively guess it in advance and pass the corresponding response to A, A can pass both the right ci and ki (and therefore si = ki ⊕ ci ). In general, let ¯ where s0i = ki0 ⊕ c0i may or (c0i , ki0 ) for i = 1, . . . , n be the values passed by A to A, may not be equal to si . Since A is not close by, (c0i , ki0 ) must be independent of αi . Clearly, if (c0i , ki0 ) has no information about A’s secret s, i.e. Pr[si = ki0 ⊕c0i ] = 1/2, then from the above discussion the probability that B accepts is at most (3/4)−n . Otherwise, assume that there are m instances for which c0i 6= ci or ki0 6= ki (but not both), i.e. in this case, A only discloses partial information about the secret s. Then the probability that B succeeds is 2−m . If A¯ computes s0i = c0i ⊕ ki0 , then m bits of the computed secret will be flipped with respect to the real secret s. A¯ n −1 can guess the position of these bits with probability m , which is much smaller than the probability of success. If, for example, n = 128 and m = 10, then the probability that B accepts is 2−10 and the probability that A¯ guesses the correct s by flipping m bits of s0 is less than 2−40 . However, notice that when B does not accept, B informs A¯ of the responses which were incorrect. Thus, for each βi that was incorrect, A¯ can compute the ith bit of the secret s; so on average A¯ learns m/2 bits of the secret s from each protocol run. In other words, the probability that B accepts, 2−m is exactly the same that the probability that A¯ learns all of the bits of s.

5.4.1

Comparison with existing schemes

Table 5.1 presents the list of distance-bounding protocols that we have found in the literature and classifies them according to the following criteria: • Identification technique: whether the underlying identification protocol is based on asymmetric, symmetric or zero-knowledge techniques (see Menezes [152]). • Unilateral/Mutual: whether the protocol authenticates the identity and proximity of one or both participants. • Mafia fraud resistance: does the protocol defend against mafia fraud attacks.

128


Protocol Type Uni/Mut Mafia Terrorist Brands & Chaum-I [42] asym uni yes no Brands & Chaum-II [42] zk uni yes no Sastry et al . [187] sym uni no no Capkun et al . [54] sym mut yes no Capkun & Hubaux [55] sym uni yes no Hancke & Kuhn [117] sym uni yes no Bussard [51] zk uni yes yes New proposal sym uni yes yes Table 5.1: Comparison of existing distance-bounding protocols • Terrorist fraud resistance: does the protocol defend against terrorist fraud attacks. The new proposal is the only scheme that employs symmetric authentication techniques and is secure against all types of attacks. The protocol by Capkun et al . [54] provides mutual entity authentication as well as proximity authentication, i.e. A and B are both prover and verifier of each other. We have tried to design a mutual distance-based protocol version of the new protocol, however, in terms of efficiency, it does not appear possible to do significantly better than running the fast challenge-response phase twice.

5.4.2

Communications requirements for distance bounding

In this section we analyse requirements and implementation issues associated with the communications channel used in the time critical phase of a distance bounding protocol. We identify communication architecture design flaws that may allow an attacker to indirectly defeat a distance-bounding protocol. With these vulnerabilities in mind, we propose a novel communication approach that exploits the underlying principle of side channel leakage, heretofore regarded as a security weakness, in a constructive way to provide the necessary distancebounding resolution for constrained devices (particularly, ISO 14443 contactless smart cards). The communication requirements for distance-bounding protocols are both demanding and unconventional - to achieve useful distance resolution they require extremely low communication latency but they do not require a correspondingly


129

high bit rate since in the time critical phase, they exchange single bits punctuated by processing delay. They do not require a communication channel that can detect and correct errors. Indeed, it may actually be a disadvantage because reliability mechanisms introduce overheads; more bits need to be exchanged but more importantly, an additional and possibly variable number of processing cycles are required for a reliable channel. As we noted in Section 5.3.4, bit errors caused by channel noise can be tolerated by simply increasing the number of challenge response rounds. The importance of predictable processing time If a contactless smart card system is protected by a timing based distancebounding protocol and an attacker wants to launch a relay attack against it in the style of Hancke [116] or Kfir [136], to be successful the attacker needs to absorb the delay that is introduced by the relay so that the round trip time falls in the range that the verifier will accept. Total round trip time for a challenge-response round comprises two main components: processing time and propagation time. For constrained (slow) devices the verifier must assume the processing time and deduce the propagation component by subtraction so the processing component must be small and invariant to the greatest extent possible. If the number of processing cycles is not small an attacker may be able to absorb the introduced delay by accelerating a legitimate card’s processing, (perhaps by providing it with a higher frequency clock signal). Some form of overclocking protection is therefore a requirement. Preventing accelerated prover processing ISO 14443 type contactless smart cards are passive devices that receive their power via inductive coupling with the 13.56 MHz magnetic alternating field generated by a reader device’s antenna coil [124]. The standard requires the reader to supply the RF operating field within a tolerance of ±7 kHz. Therefore, where a card uses the operating field as the source of its internal clock signal, it only needs to accept a frequency that is 0.05% greater than 13.56 MHz. There are two main approaches to stop an attacker from operating a card at a higher than intended frequency; phase locked loop (PLL) internal clock generators and high frequency filters. Internal PLL-based clock signal generators are an increasingly popular choice, particularly in microprocessor cards. They have the advantage

130


that the frequency of the generated signal is independent of the reader-supplied frequency. In the second case where the card uses a reader-supplied clock signal, high frequency protection usually takes the form of a low pass filter which resets the card when the filter threshold is exceeded. Tolerances of the order of a few percent are possible. It is therefore reasonable to assume that for appropriately designed hardware, an attacker can be limited to overclocking by no more than a few percent. If we also assume that the attacker cannot economically defeat a legitimate card’s protection mechanisms to extract the long term secret key to transfer it to a faster device, we can conclude that any successful run of a distancebounding protocol was executed with the real card. Under these assumptions the amount of introduced delay that can be absorbed is largely determined by the prover’s clock frequency and the number of clock cycles required to compute the response, (ignoring implementation specifics of the communication method which we examine shortly). If this number can be kept small, the verifier can account for the processing time with some accuracy, thus permitting a reliable allocation of the portion of total round trip time to propagation.

5.4.3

Timing Resolution for relay attack detection

What timing resolution is required to detect relay attacks? Realistic attack scenarios on contactless smart cards may involve relay distances as small as a few metres since legitimate cards are often found in the close vicinity of a card reader. The round trip signal propagation time for a relay attack of 3 meters is 20 ns so at first glance it would appear that the ability to detect delays of the order of 20 ns is necessary. This is a technically demanding requirement. ISO 14443 contactless smart cards support a base communication rate of 106 kbits/s. At this bit rate a signal propagates 2.8 km in one bit period and Hancke and Kuhn [117] have argued that this is inadequate for distance bounding, thus motivating their proposal of UWB radio. However, we believe it is possible to achieve significantly finer distance resolution than 2.8 km without resorting to the additional complexity of UWB. It is crucial to recognise that relay attacks introduce unavoidable delays beyond the signal propagation time. The rogue relay devices themselves each incur a circuit propagation delay known as group delay - the amount of time that the amplitude modulated signal is delayed by its passage through a device [131]. ¯ in two directions so there is The relayed signal needs to pass through A¯ and B


131

an additional delay component equal to four times the group delay3 . For example, Hancke’s relay attack introduces a total delay of between 15,000 and 20,000 ns (15-20 µs) where the round trip propagation time is only 333 ns. Thus the individual device group delay is of the order of 4 to 5 µs. Hancke’s attack was a proof of concept that used inexpensive RF relay equipment. Advanced microwave transceivers operating at gigahertz frequencies can have group delay in the order of tens of nanoseconds [23]. This type of equipment is typically found in signals intelligence applications and is both expensive and exotic4 . More commonly available and less costly equipment will have a significantly higher group delay and will therefore be easier to detect. For the purpose of our analysis we estimate a lower bound for total group delay introduced by the relay devices of 40 ns for well funded attackers. This figure will be much higher when standard, off-the-shelf equipment is used. Thus, when the signal propagation delay is included we assume the relay detection protocol must detect a minimum of 60 ns of total introduced delay for a 3 m attack.

5.4.4

Timing resolution for contactless card communication

In this section we analyse the timing resolution that a contactless smart card can support. We begin with a brief explantion of the card to reader communication method for ISO 14443 cards. ISO 14443 contactless smart cards communicate with the reader via load modulation. A resistor in the card’s power supply circuit is switched in and out of circuit in time with the data to be transmitted according to the subcarrier modulation method [99]. When the resistor is switched in, the card consumes more power and this increased consumption can be sensed as an amplitude change (as measured in the reader’s antenna circuit) in the 13.56 MHz carrier (fc ). For Type A cards, the data is baseband encoded using Manchester binary coding and this baseband signal is modulated on a 847 kHz subcarrier using amplitude shift keying (ASK). This modulated subcarrier signal is used to turn the load ¯ may directly commuKfir [136] reports simulation results indicating that a rouge verifier, B nicate with the reader B over a distance of up to 50m by directly modulating the RF sidebands. Thus it may be possible to avoid the last group delay incurred in A¯ for short range attacks though this is unclear since in our proposal we do not use side band modulation. 4 The Macom SMR-4820 Compact Microwave Search Receiver claims a group delay of