Privacy-preserving protocols and applications for trusted platforms

Privacy-Preserving Protocols and Applications for Trusted Platforms Hans Löhr

Dissertation zur Erlangung des Grades eines Doktor-Ingenieurs der Fakultät f¨ ur Elektrotechnik und Informationstechnik an der Ruhr-Universität Bochum

Thesis submitted: Thesis defended: First Supervisor: Second Supervisor:

ii

October 2011 December 2011 Prof. Dr.-Ing. Ahmad-Reza Sadeghi Prof. Dr. Chris Mitchell

Summary Privacy is a crucial precondition for a functioning free and democratic society. Recent developments in information and communication technology – in particular, the recent trend towards outsourcing IT services, computation and data storage to “the cloud” – present major challenges regarding the privacy of end users. Trusted Computing (TC) is an IT security paradigm, where a combination of trusted hardware and software is used to improve the overall security of a system. As system security is a necessary precondition for effective privacy protection, TC technology can provide benefits in this regard. However, trusted hardware such as the Trusted Platform Module (TPM) introduces unique identifiers and cryptographic keys, which may lead to new privacy concerns. In this thesis, we take steps towards addressing security and privacy concerns in different application scenarios, and on various technical levels. The scientific contributions of this work include several privacy-preserving cryptographic protocols, as well as TC-based security architectures that can be used for privacy and data protection. In particular, we present the following: • We propose two cryptographic schemes that provide privacy-preserving unsplittable multi-coupons, an electronic equivalent of paper-based coupon booklets. Our first scheme enforces a predetermined order on the redemption of coupons, whereas our second scheme allows the user to redeem coupons in any order and generalizes the first one to support a federation of vendors. Both solutions provide unlinkability of user transactions, similar to existing paper-based coupon booklets. • We present two property-based attestation (PBA) protocols that prove to a remote verifier that the platform provides a given (security) “property”, without disclosing the exact platform configuration. Our first PBA protocol uses certificates of a trusted authority which certifies the configurations that provide a certain property. Based on these certificates, the platform proves to the verifier that its current configuration provides the desired property. Our Second PBA protocol does not require a certificate authority. Here, the platform proves to the verifier that its configuration is included in a set of accepted configurations, where both prover and verifier agree that they provide the desired property. Both protocols rely on a (small) trusted hardware component: a slightly modified TPM. • We show how to combine the standard protocols Transport Layer Security (TLS) and Direct Anonymous Attestation (DAA) to obtain secure communication channels with anonymous authentication. An advantage of our solution is that DAA is supported by current TPMs, which keep authentication credentials protected by hardware. Hence, in contrast to purely software-based anonymous authentication, legitimate users cannot just copy their credentials and distribute them to others. • We present a security architecture for distributed computing that supports the use of standard grid solutions inside virtual machines running on top of a trusted virtualization layer. We use a TPM in conjunction with trusted virtualization to provide confidentiality and integrity of grid computations and data. Moreover, we propose an offline attestation protocol, where customers bind their grid jobs to secure platforms based on “attestation tokens” published by grid providers.

iii

• With Trusted Privacy Domains, we propose a comprehensive privacy framework that can be used in numerous networked scenarios, including applications of cloud computing. Technologically, privacy domains are based on the security concept of Trusted Virtual Domains (TVDs) that are used to enforce and manage privacy policies. We present an overall framework and contributions to building blocks of privacy domains. In particular, we introduce security protocols to deploy TVDs on a platform and for virtual machines (“compartments”) to join TVDs. These protocols guarantee that all platforms and virtual machines of a TVD comply to the TVD policy. Moreover, we present a TVD implementation on OpenSolaris, and a key management solution to transparently encrypt mobile storage devices in a TVD. We also sketch how privacy domains can help to protect patients’ data in the e-health cloud. • To protect users’ authentication credentials for web services, we propose a security architecture based on TC and virtualization, where a trusted wallet (TruWallet) stores credentials and automatically handles logins. Moreover, we show how a mobile trusted wallet can improve security in e-health scenarios. The scientific achievements in this thesis constitute important building blocks and novel concepts for the effective protection of end-user data. Although the results presented here cannot provide a holistic privacy solution for all imaginable purposes, they show that for many applications, secure and privacy-friendly systems can be developed based on modern technologies without prohibitive cost.

iv

Acknowledgements First and foremost I would like to thank my supervisor, Ahmad Sadeghi, for providing me with the great opportunity to work on such interesting topics for this thesis. Furthermore, I would like to thank my second advisor, Chris Mitchell, for agreeing to act as external referee for my thesis and for his kind support. I would also like to thank all the co-authors of my scientific publications. Without them the scientific contributions in this thesis, which most often stem from true team work, would not have been possible. Moreover, I would like to thank all my colleagues at the Horst G¨ ortz Institute for IT-Security, as well as our numerous cooperation partners from European (and other) research projects, for the great working environment and their friendship. The long list of these co-workers, colleagues and friends includes, in no particular order, Marcel Winandy, Luigi Catuogno, Biljana Cubaleska, Timo Kasper, Christian St¨ uble, Anoosheh Zaerin, Liqun Chen, Mark Ryan, Mark Manulis, Christian Wachsmann, Thomas Schneider, Sebastian Gajek, Frederik Armknecht, Martin Unger, Yassin Gasmi, Patrick Stewin, Tim G¨ uneysu, Thomas Eisenbarth, Christof Paar, Jörg Schwenk, Marko Wolf, André Osterhues, Ammar Alkassar, Alexandra Dmitrienko, Lucas Davi, Atanas Filyanov, Zećir Hadˇzic, Steffen Schulz, Stefan Schulz, Markus Rohe, Rainer Landfermann, Jamshid Shokrollahi, Alberto Nicolás Escalante Ba˜ nuelos, Claire Vishik, Christian Cachin, Dries Schellekens, Dirk Kuhlmann, Matthias Schunter, Kurt Dietrich, Martin Pirker, Gianluca Ramunno, Emanuele Cesena, Davide Vernizzi, and many others. Finally, I would like to thank my family, my friends back home in N¨ urnberg, and my girlfriend Agnes. Without their continuous love and friendship I would not have been able to finish this thesis.

v

vi

Contents I.

Introduction and Background

1. Introduction 1.1. Motivation and Objectives . . . . . . . . . . 1.2. Overview of this Thesis . . . . . . . . . . . 1.2.1. Structure . . . . . . . . . . . . . . . 1.2.2. Content and Scientific Contributions

1 . . . .

. . . .

. . . .

. . . .

3 3 5 5 5

2. Cryptographic Background 2.1. Basic Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . 2.2. Commitment Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Pedersen Commitments . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Damg˚ ard-Fujisaki Commitments . . . . . . . . . . . . . . . . . 2.3. Zero-Knowledge Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Zero-Knowledge Proofs of Knowledge . . . . . . . . . . . . . . 2.3.2. The Fiat-Shamir Heuristic and Signature Proofs of Knowledge 2.4. The Camenisch-Lysyanskaya Anonymous Credential System . . . . . . 2.4.1. CL Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2. Zero-Knowledge Protocols for CL signatures . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

9 9 9 10 10 10 11 11 12 12 13

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

15 15 15 18 18 18 20 20 20 21 21 23 23 24 25 26

. . . . . . . . . . . . . . . . . . . . . . . . of this Thesis

. . . .

. . . .

3. Background on Trusted Platforms 3.1. Trusted Platforms . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Architecture of a Trusted Platform . . . . . . . . . . . 3.1.2. Related Approaches to Trusted Platform Architectures 3.2. Fundamental Trusted Computing Concepts . . . . . . . . . . 3.2.1. Trusted Boot . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Trusted Storage . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Remote Attestation . . . . . . . . . . . . . . . . . . . 3.2.4. Overview of TC Technologies . . . . . . . . . . . . . . 3.3. The TCG Approach to Trusted Computing . . . . . . . . . . 3.3.1. The Trusted Platform Module (TPM) . . . . . . . . . 3.3.2. Authenticated Boot based on the TPM . . . . . . . . 3.3.3. Sealing and Binding . . . . . . . . . . . . . . . . . . . 3.3.4. TCG Attestation . . . . . . . . . . . . . . . . . . . . . 3.3.5. Direct Anonymous Attestation (DAA) . . . . . . . . . 3.3.6. Trusted Software Stack (TSS) . . . . . . . . . . . . . .

II. Privacy-Preserving Protocols

. . . .

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

. . . .

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

. . . .

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

. . . .

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

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

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

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

27

vii

Contents 4. Electronic Multi-Coupon Schemes 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Desired Security Properties . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Contribution and Organization . . . . . . . . . . . . . . . . . . . . 4.2. Brief Overview of our Constructions . . . . . . . . . . . . . . . . . . . . . 4.2.1. Privacy-Protecting Unsplittable Multi-Coupons with Fixed Order of Redemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Privacy-Protecting Unsplittable Multi-Coupons with Arbitrary Order of Redemption for Federated Environments . . . . . . . . . . . 4.2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption . . . . . . . 4.4.1. Security Framework for Multi-Coupon Schemes . . . . . . . . . . . 4.4.2. Our Multi-Coupon Scheme with Fixed Order of Redemption . . . 4.4.3. Security Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. MCS with Arbitrary Redemption for Federated Environments . . . . . . . 4.5.1. Model and Security Framework . . . . . . . . . . . . . . . . . . . . 4.5.2. Our Federated Multi-Coupon Scheme . . . . . . . . . . . . . . . . 4.5.3. Security of the Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . . .

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

32 33 34 34 34 39 41 43 43 48 52 55

5. Cryptographic Protocols for Property-Based Attestation 5.1. Introduction and Background . . . . . . . . . . . . . . . . . . . . 5.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Delegation-Based Protocol for PBA . . . . . . . . . . . . . . . . . 5.3.1. Delegation of Property Evaluation to a Certificate Issuer . 5.3.2. Protocol for PBA with CL Signatures as Certificates . . . 5.3.3. Security Parameters . . . . . . . . . . . . . . . . . . . . . 5.3.4. Property-Configuration Certificates . . . . . . . . . . . . . 5.3.5. Signing Algorithm . . . . . . . . . . . . . . . . . . . . . . 5.3.6. Verification Algorithm . . . . . . . . . . . . . . . . . . . . 5.3.7. Revocation Check of a Certificate . . . . . . . . . . . . . . 5.3.8. Rogue TPMs . . . . . . . . . . . . . . . . . . . . . . . . . 5.4. Security of the Delegation-Based PBA Scheme . . . . . . . . . . 5.4.1. Formal Security Model . . . . . . . . . . . . . . . . . . . . 5.4.2. Proof of Theorem 5.4.1 . . . . . . . . . . . . . . . . . . . 5.5. PBA without TTP based on Ring Signatures . . . . . . . . . . . 5.5.1. System Model for PBA . . . . . . . . . . . . . . . . . . . 5.5.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3. Ring Signatures . . . . . . . . . . . . . . . . . . . . . . . . 5.5.4. Our PBA Scheme without TTP . . . . . . . . . . . . . . . 5.6. Security of the PBA Scheme without TTP . . . . . . . . . . . . . 5.6.1. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2. Security Analysis . . . . . . . . . . . . . . . . . . . . . . . 5.7. Conclusion and Future Work . . . . . . . . . . . . . . . . . . . .

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

57 57 59 60 60 61 62 62 65 65 65 66 66 68 70 76 77 78 79 79 82 82 83 86

6. Anonymous Authentication with TLS and DAA

viii

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

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

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

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

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

. . . .

29 29 30 31 32

. 32

87

Contents 6.1. 6.2. 6.3. 6.4.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . Anonymous Authentication: Objectives and Model . . Background: Transport Layer Security (TLS) . . . . . Protocols for TLS-Based Anonymous Authentication . 6.4.1. Join Protocol . . . . . . . . . . . . . . . . . . . 6.4.2. TLS-DAA Handshake . . . . . . . . . . . . . . 6.5. Security Considerations . . . . . . . . . . . . . . . . . 6.6. Lightweight Anonymous Authentication for Embedded 6.7. Conclusion and Future Work . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Devices . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

87 90 91 92 92 93 96 97 97

III. Trusted Platform-Based Security and Privacy Architectures with Applications 99 7. A Security Architecture and Offline Attestation for Distributed 7.1. Enhancing Grid Security Using Trusted Virtualization . . . 7.2. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1. System Model and Notation . . . . . . . . . . . . . . 7.2.2. Usage Scenario . . . . . . . . . . . . . . . . . . . . . 7.2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 7.3. A Trusted Grid Architecture . . . . . . . . . . . . . . . . . 7.4. A Protocol for Scalable Offline Attestation . . . . . . . . . . 7.5. Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . 7.6. Discussion and Related Work . . . . . . . . . . . . . . . . . 7.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .

Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

101 101 103 103 104 104 104 106 108 110 111

8. Towards Trusted Privacy Domains 113 8.1. Trusted Privacy Domains: Vision and Basic Architecture . . . . . . . . . . 113 8.1.1. The Need for Trusted Privacy Domains . . . . . . . . . . . . . . . . 113 8.1.2. Framework for Privacy Domains . . . . . . . . . . . . . . . . . . . . 114 8.2. Trusted Virtual Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 8.2.1. Trusted Virtual Domains as a Building Block for Privacy Domains . 116 8.2.2. Implementation of TVD protocols . . . . . . . . . . . . . . . . . . . 119 8.3. Key Management for Mobile Storage Devices in TVDs . . . . . . . . . . . . 123 8.3.1. Mobile Storage Devices for TVDs . . . . . . . . . . . . . . . . . . . . 124 8.3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 8.3.3. Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 8.3.4. The Offline Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 8.3.5. Our Key Management Solution . . . . . . . . . . . . . . . . . . . . . 127 8.3.6. MSD Access Control Management . . . . . . . . . . . . . . . . . . . 130 8.4. Implementing TVDs on OpenSolaris: Usable Secure Desktop Environments 135 8.4.1. The Need for a Usable Secure Desktop Environment . . . . . . . . . 136 8.4.2. Realizing TVDs on OpenSolaris . . . . . . . . . . . . . . . . . . . . . 136 8.4.3. Summary of OpenSolaris TVDs and Future Work . . . . . . . . . . . 140 8.5. Securing the E-Health Cloud based on Privacy Domains . . . . . . . . . . . 140 8.5.1. Introduction to the E-Health Cloud and Related Security and Privacy Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

ix

Contents 8.5.2. Model of the E-Health Cloud . . . . . . . . . . . . . . . . . . . . . . 142 8.5.3. Problems of E-Health Clouds . . . . . . . . . . . . . . . . . . . . . . 145 8.5.4. Secure E-Health Infrastructure . . . . . . . . . . . . . . . . . . . . . 147 8.5.5. Open Research Challenges in the Context of Electronic Health Records151 8.6. Remaining Challenges for Privacy Domains and Related Work . . . . . . . 152 8.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 9. A Trusted Wallet for Secure Web Authentication 9.1. Introduction to Wallet-Based Web Authentication . . . . 9.2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 9.2.1. Threats and Security Objectives . . . . . . . . . . 9.2.2. Architecture . . . . . . . . . . . . . . . . . . . . . 9.2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . 9.2.4. Usage Overview . . . . . . . . . . . . . . . . . . . 9.3. Secure User Authentication . . . . . . . . . . . . . . . . . 9.4. Secure Wallet Data Migration . . . . . . . . . . . . . . . . 9.5. Implementation of TruWallet on a PC . . . . . . . . . . . 9.6. Security of TruWallet . . . . . . . . . . . . . . . . . . . . 9.7. A Mobile Trusted Wallet to Enhance E-Health Security . 9.7.1. Problem Scenario . . . . . . . . . . . . . . . . . . . 9.7.2. Mobile Wallet Architecture . . . . . . . . . . . . . 9.7.3. Building Blocks for a Mobile Security Architecture 9.7.4. Wallet Prototype on Nokia N900 . . . . . . . . . . 9.7.5. Mobile Wallet Implementation . . . . . . . . . . . 9.8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9.9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

155 155 157 157 158 159 159 160 162 163 165 166 167 169 170 171 172 174 177

IV. Conclusion

179

10.Concluding Remarks

181

Bibliography

183

V. Appendix

209

Publications by the Author

211

x

Part I.

Introduction and Background

1

1. Introduction In this chapter, we motivate our research and present the objectives of this thesis. Moreover, we give an overview over the contents of the subsequent chapters. In particular, we highlight the scientific contribution and describe the structure of this thesis.

1.1. Motivation and Objectives Privacy is a fundamental human need and an essential right in any functioning free and democratic society (see, for instance, the seminal paper by Warren and Brandeis [WB90]). In our modern world, where computers and particularly the Internet gain more and more importance for our lives, digital privacy becomes a relevant concern (see, for instance, Directive 95/46/EC of the European Parliament and of the Council [EC95]).1 Recent trends like outsourcing of computation and data into the “Cloud”, electronic government, the prominence of social networks such as Facebook, Linkedin, MySpace, etc. enable many new opportunities for our society, but they also create new threats to the privacy of individuals. Malicious software (malware) – e.g., viruses and Trojan horses – spies on users on behalf of criminals or foreign and domestic government agencies, thus violating fundamental interests of citizens. Malware also provides examples that illustrate the close relationship between IT security and digital privacy: For instance, the goal of an attacker might be to steal money from a victim by manipulating an online banking transaction, thus violating the security of the online banking system. However, banking data could contain privacy-sensitive information, which might be leaked by the malware. Another, even more obvious, example comes from the domain of electronic health: Electronic health records contain highly privacy-sensitive data, which can only be kept confidential when the records are stored, processed, and transferred in a secure way. As these scenarios demonstrate, secure systems are usually necessary (but often not sufficient) to guarantee privacy. Hence, this thesis not only discusses privacy alone, but also covers IT security aspects. For realistic applications to provide privacy for end-users, secure system architectures are necessary – but privacy needs to be taken into account explicitly. Trusted Computing (TC) is a security paradigm, where a combination of trusted hardware and software components (the Trusted Computing Base (TCB)) provides security guarantees for the overall system. TC technology, where hardware components provide features such as secure storage of cryptographic keys, encryption, digital signatures, and more, offers security benefits compared to software-only solutions. Thus, TC technology can be used for security architectures, which may enable benefits for end-user privacy (e.g., because they provide better confidentiality for user data as well as improved protection against malware attacks than conventional systems). Some TC hardware, in particular 1

This thesis only covers digital systems, therefore, we will usually use the short term privacy instead of digital privacy. Analogously, we will often use the term security instead of IT security.

3

1. Introduction the Trusted Platform Module (TPM) [Tru07b] which has been specified by the Trusted Computing Group (TCG) 2 [Tru11], offers advanced cryptographic features for privacypreserving protocols. Such hardware enables new protocols and applications for privacy protection. However, TC technology also introduces unique identifiers and cryptographic keys, which can lead to new privacy risks: Unless care is taken, individual systems could be identified and traced based on trusted hardware, maybe throughout their entire lifetime. Digital signatures, generated inside the hardware, might even provide a “proof”3 that a certain platform was engaged in a given interaction. Therefore, it is paramount for the privacy of end-users that the use of TC technology is examined carefully, with a focus on privacy. Another important issue in the areas of privacy and security are conflicting objectives of different parties. For instance, in a networked scenario, a service provider might want to ensure that only authorized (paying) customers can access a service. Hence, the provider typically demands that users identify themselves and authenticate before they can use the service. However, users might want to keep private, when they are accessing the service and the exact nature and content of their transaction.4 Thus, here provider and users have seemingly conflicting objectives: authentication (provider’s security objective) versus anonymity (users’ privacy objective). In many concrete cases with (apparently) conflicting objectives (the service provider mentioned above is just one example), it is possible to devise dedicated solutions that take into account the requirements of all parties and provide multilateral security. We will present some cryptographic protocols that fulfill different requirements of different protocol participants in this thesis, including a solution for the example of the service provider just mentioned (see Chapter 6). Of course, the topics privacy and data protection are not limited to the area of technology: They have social, political, and legal dimensions that are at least as important as their technical aspects. However, we believe that technical solutions should support privacy and data protection wherever possible – usually together with other measures, such as legal regulation. Therefore, we will consider technical measures in this thesis (from the perspective of a computer scientist). Research objectives. This thesis aims at the development of technical solutions that have the potential to improve end-user privacy in practical scenarios, and which are able to provide security guarantees to all participants and stake holders. Towards this goal, this thesis strives to meet the following objectives: • The development of dedicated privacy-preserving cryptographic protocols for a number of application scenarios; these protocols should guarantee the fulfillment of (sometimes seemingly conflicting) security requirements to all parties that participate in the protocols. 2

3

4

4

The TCG is a consortium of leading industry players and issues specifications and recommendations in many areas of IT security (see Chapter 3 for more information on the TCG and the TPM). I.e., in practice, it would be virtually impossible to forge such a “proof” without physically attacking the trusted hardware component. Think of an online newspaper subscription where paying customers may read any article at any time. In this scenario, customers might not want the provider to know which articles they are reading and when.

1.2. Overview of this Thesis • The design of novel security solutions for several application scenarios – with a focus on the protection of privacy-sensitive user data; for this, we want to propose security architectures that benefit from Trusted Computing and virtualization technology. The concrete topics that are addressed in this thesis aim to provide significant scientific contributions as steps towards effective privacy protection in the future.

1.2. Overview of this Thesis In this section, we give a brief overview of this thesis and summarize the scientific contributions it contains.

1.2.1. Structure The remainder of this thesis is structured as follows: The remainder of Part I (the rest of Chapter 1, as well as Chapter 2 and Chapter 3) summarizes the content of this thesis and briefly recalls the background in cryptography as well as Trusted Computing that is used throughout this thesis. Part II (Chapters 4–6) presents scientific contributions in the area of privacy-preserving protocols, whereas Part III (Chapters 7–9) contains scientific contributions in the area of security architectures (see Section 1.2.2 for an overview of the scientific achievements). Finally, Part IV (Chapter 10) concludes this thesis. The appendix contains a short CV and a list of the author’s publications.

1.2.2. Content and Scientific Contributions of this Thesis In this thesis, we take steps towards addressing security and privacy concerns in different application scenarios, and on various technical levels. The scientific contributions of this work include several privacy-preserving cryptographic protocols, as well as TC-based security architectures that can be used for privacy and data protection. The scientific contributions of this thesis have been published in a number of peer-reviewed conference and workshop proceedings [CBL+ 07, AEL+ 08, CLL+ 06, CLMS08, CLR+ 10, LRS+ 07, LSVW09, LPR+ 10, CLM+ 09, LSW10b, GLSW09, DHL+ 11a, DHL+ 11b]. In particular, we present the following: • Privacy-Preserving Multi-Coupon Schemes (Chapter 4):

Multi-Coupons are the electronic equivalent of paper-based coupon booklets: a collection of individual coupons that can be redeemed to an entity that accepts valid coupons in conjunction with the “booklet”, but which cannot be separated and redeemed independently. We present two different cryptographic schemes that provide privacy-preserving unsplittable multi-coupons. Our first scheme (published in [CBL+ 07]) supports multicoupons, where the individual coupons must be redeemed in a pre-determined order that has to be fixed when the “vendor” issues a multi-coupon to a “user”. Our second scheme (published in [AEL+ 08]) generalizes the first scheme, in that it supports a federation of vendors instead of a single vendor, i.e., any vendor that is a member of the federation can issue multi-coupons that are accepted by other vendors in the federation. Moreover, this scheme supports unsplittable multi-coupons, with

5

1. Introduction an arbitrary order of redemption: The user can choose which individual coupon to redeem dynamically, yet the multi-coupon is still unsplittable. Both of our multi-coupon schemes provide anonymity to the user (similar to paperbased coupon booklets without the name or other personal data of the user). More precisely, they provide unlinkability between protocol executions. • Cryptographic Protocols for Property-Based Attestation (Chapter 5):

Attestation protocols are protocols using trusted hardware to prove to a remote entity that a platform is in a specific state, i.e., that a specific software stack is running on a specific hardware configuration. However, disclosing the exact software and hardware configuration to a remote verifier introduces privacy risks. We present two property-based attestation (PBA) protocols that do not disclose the exact platform configuration, but instead prove to a remote verifier that the configuration provides a given (security) property. Our first PBA protocol (published in [CLL+ 06]) uses certificates of a trusted authority which certifies the configurations that provide a certain property. Based on these certificates, the platform proves to the verifier that its current configuration provides the desired property. Our Second PBA protocol (published in [CLMS08]) does not require a certificate authority. In this protocol, the platform proves to the verifier that the configuration is within a set of accepted configurations, where both prover and verifier agree that they provide the desired property. Both protocols rely on a (small) trusted hardware component: a slightly modified TPM.

• Anonymous Authentication with TLS and DAA (Chapter 6):

Anonymous Authentication protocols provide cryptographically secure authentication without identification: they ensure that only legitimate users (those that have been issued an authentication credential) can authenticate successfully, but they do not identify the user during the process. We show how to combine the standard protocols Transport Layer Security (TLS) and Direct Anonymous Attestation (DAA) to obtain secure communication channels with anonymous authentication (published in [CLR+ 10]). An advantage of our solution is that DAA is supported by current TPM chips and keeps its authentication credentials protected by hardware. Hence, legitimate users cannot just copy their credentials and distribute it to others – which is an issue with all purely software-based anonymous authentication schemes.

• A Security Architecture and Offline Attestation for Distributed Computing (Chapter 7): Grid computing is a computing paradigm that enables outsourcing of computations. Most current grid computing solutions use standard operating systems and a layer of middleware that is designed to protect the grid computing provider from malicious grid jobs. However, they do not provide confidentiality or integrity of the jobs that are submitted to the grid provider. We present a security architecture for grid computing based on virtualization technology that supports the use of standard grid solutions inside virtual machines that

6

1.2. Overview of this Thesis run on top of a trusted virtualization layer (published in [LRS+ 07]). We use a TPM in conjunction with trusted virtualization to provide confidentiality and integrity of grid computations and data. For this, we propose a scalable offline attestation protocol, where platforms that provide grid computing services publish an “attestation token” that is used by customers to bind their grid jobs to secure platform configurations. • Trusted Privacy Domains (Chapter 8):

With “Trusted Privacy Domains”, we present the vision of a comprehensive privacy framework that can be used in numerous networked scenarios, including applications of cloud computing. Technologically, Trusted Privacy Domains are based on the security concept of Trusted Virtual Domains (TVDs) that are used to enforce and manage privacy policies.

We present an overall framework (published in [LSVW09]) and contributions to building blocks of privacy domains. In particular, we introduce security protocols to deploy TVDs on a platform and for virtual machines (“compartments”) to join TVDs (published in [LSVW09]). These protocols guarantee that all platforms and virtual machines of a TVD comply to the TVD policy. Moreover, we present an implementation of the TVD concept on OpenSolaris (published in [LPR+ 10]), and a key management solution to transparently encrypt mobile storage devices in a TVD (published in [CLM+ 09]). We also sketch an application scenario of trusted privacy domains to protect patients’ data in the e-health cloud (published in [LSW10b]). • A Trusted Wallet for Secure Web Authentication (Chapter 9):

Web services and platforms such as social networks (e.g., Facebook, MySpace) store and process privacy-sensitive user data. Hence, the users’ authentication data – usually usernames and passwords – must be protected adequately from various attacks, including malicious software and social engineering (phishing). To protect users’ authentication data, we propose a security architecture based on TC and virtualization, where a trusted wallet stores authentication data (e.g., passwords) and automatically handles logins (published in [GLSW09]). Moreover, we show how a mobile trusted wallet can be used for secure authentication in e-health scenarios (published in [DHL+ 11b]).

The scientific achievements in this thesis constitute important building blocks and novel concepts for the effective protection of end-user data. Although the results presented here cannot provide a holistic privacy solution for all imaginable purposes, they show that often, privacy protection based on modern technologies is possible without prohibitive cost.

7

8

2. Cryptographic Background In this chapter, we briefly introduce the cryptographic building blocks and notation that will be used in several chapters of this thesis. Particularly in Part II of this thesis, we assume that the reader is familiar with basic cryptography, hence, this chapter is only meant to introduce some notation and recall some of the more advanced cryptographic techniques. Cryptographic primitives and notation specific to one chapter only will be introduced in the respective chapter. For more background on cryptography in general, refer to standard textbooks (e.g., [KL08, Sti02]) and the Handbook of Applied Cryptography [MvOV97]. For a more formal introduction to the theoretical foundations, refer to [Gol01, Gol04].

2.1. Basic Cryptographic Primitives We assume that the reader is familiar with the basic cryptographic primitives of encryption, cryptographic hash functions, and digital signatures. For more information, refer to [MvOV97] or standard textbooks on cryptography such as [KL08, Sti02]. Encryption. In this thesis, we will usually employ asymmetric encryption. We denote encryption of a message m with a public key PK as x ← EncPK (m), and the decryption of a ciphertext x with a private key SK is denoted as m ← DecSK (x). Cryptographic hash functions. h ← Hash(m).

A cryptographic hash of a message m is denoted by

Digital signatures. A digital signature scheme consists of three algorithms: key generation GenKey(), signature generation Sign(), and signature verification Verify(). With σ ← Sign(sk; m) we denote the signature on a message m signed by the signing key sk. The return value of the verification algorithm ind ← Verify(vk; m, σ) is a Boolean value ind ∈ {acc, rej}. A certificate on a quantity Q with respect to a verification key vk is denoted by cert(vk; Q), a signature generated by applying the corresponding signing key.

2.2. Commitment Schemes A commitment scheme is a cryptographic scheme with two phases: the commit phase, where a commitment to a message is created by a committer, and the open phase, where the message is revealed to a receiver. In the commit phase, the committer C commits to a message m (using a cryptographic key) in such a way that the commitment Cm is 1. binding, i.e., the committer cannot open it to a different message m0 later, and

9

2. Cryptographic Background 2. hiding, i.e., the receiver does not learn the message m unless the commitment is opened. In the open phase, an opening key is used to retrieve the message m from the commitment. Because of the binding property of the scheme, this demonstrates that m is the original message the committer has used in the commit phase before. Note that commitments can be used in cryptographic protocols without ever opening them: zero-knowledge proofs (see Section 2.3 below) can be applied to prove certain properties of the committed value to a receiver, which might be enough to achieve the goal of the protocol.

2.2.1. Pedersen Commitments The Pedersen [Ped92] commitment scheme works as follows: Let sk m com be the secret m commitment key. A commitment to a message m (m ∈ ZQ ) is computed as Cm := g m hsk com mod P . P is a large prime, h is a generator of a cyclic subgroup GQ ⊆ Z∗P of prime order Q and Q|P − 1. g is chosen randomly from hhi; furthermore, logh (g) is unknown to the committing party. Both the message m and sk m com are taken from ZQ . The Pedersen commitment scheme as described above is perfectly hiding and computationally binding, assuming the hardness of the discrete logarithm problem in a subgroup of Z∗P of prime order (for P prime).

2.2.2. Damg˚ ard-Fujisaki Commitments In this thesis, we also apply the integer commitment scheme (DF commitment scheme) from [DF02], with the following parameters (as in [Lip03]): two bases g, h ∈ QRn (quadratic residues modulo n), and an RSA modulus n (where n = p·q with p = 2p0 +1 and q = 2q 0 +1 where p, q, p0 , q 0 are prime numbers) as a public key. A commitment to x (x ∈ Z) has the form Cx = g x · hr , where r is a random value. Note that the advantage of this scheme is that the commitment is actually to an integer (not just modulo n), assuming a polynomially bounded adversary. In fact, the DF integer commitment scheme is computationally binding and computationally hiding. As shown in [Lip03], this scheme can be extended to commit to a tuple of integers (x1 , . . . , xk−1 ). For this, a tuple (g1 , . . . , gk , n) of k bases gi ∈ QRn (for 1 ≤ i ≤ k) is used to generate commitments of the form Cx1 ,...,xk−1 = g1x1 · · · gkr .

2.3. Zero-Knowledge Proofs Informally, zero-knowledge (ZK) proofs are cryptographic protocols, where a prover convinces a verifier that a certain statement is true without revealing anything else to the verifier. In this thesis, we will use ZK proofs where provers convince verifiers that they know some secret – without revealing the secret. Hence, we will briefly introduce this special case (ZK proofs of knowledge) below. For a formal introduction to the vast area of ZK proof system, refer to [Gol01].

10

2.3. Zero-Knowledge Proofs

2.3.1. Zero-Knowledge Proofs of Knowledge Zero-knowledge proofs of knowledge (ZK PoKs) are interactive protocols carried out between two parties: a prover and a verifier. During such a protocol run, a verifier is convinced with overwhelming probability that the prover is aware of some secret and that a certain predicate related to this secret is true. However, the verifier does not learn anything beyond this assertion. By PoK{(˜ x1 , . . . , x ñ ) : R(˜ x1 , . . . , x ñ )} we denote an interactive zero-knowledge proof of knowledge, where a prover proves to a verifier that she knows a witness (˜ x1 , . . . , x ñ ) such that the relation R holds, and the verifier does not gain any useful information beyond this assumption. Several protocols in this thesis will contain some proofs of knowledge of relations among discrete logarithms under exponential one-way homomorphisms. To describe the semantics of these proofs we apply the notation suggested by Camenisch and Stadler [CS97]. Example: interval proof.

For instance, PoK{(α, β) : g α hβ ∧ α ∈ [a, b]}

denotes a zero-knowledge proof of knowledge that a prover is aware of some secret values α and β such that y = g α hβ holds and, moreover, that α is contained in the interval [a, b]. g, h, y are elements of some group G with hgi = hhi = G provided as common input to both parties; this holds for the integers a and b as well. Example: proof of equality of representations. P proves that she is able to open two commitments C1 and C2 (for two possibly different instances of the commitment scheme), such that certain components of the openings are equal. For example, r˜

˜ = y˜} PoKEqRep{(˜ x, r˜x , y˜, r˜y ) : C1 = g1x˜ g2r˜x ∧ C2 = gˆ1y˜gˆ2y ∧ x denotes the proof that the exponents x ˜ and y˜ are equal. Depending on the cryptographic assumption the one-way property of a given homomorphism is based on, the soundness of the corresponding zero-knowledge proof is valid under the same assumption1 . Furthermore, all proofs of knowledge occurring in this thesis feature the statistical zero-knowledge property. In the case where the verifier chooses the challenge uniformly at random, we obtain an honest verifier zero-knowledge (HVZK) proof of knowledge protocol.

2.3.2. The Fiat-Shamir Heuristic and Signature Proofs of Knowledge Using a cryptographic hash function, the PoKs described above can be turned into noninteractive PoKs according to the Fiat-Shamir heuristic [FS87]. We add the prefix NI(“non-interactive”) to the PoKs to indicate that a non-interactive proof is used instead of an interactive protocol, e.g., NI-PoKSigOnCommit to denote a non-interactive proof of knowledge of a signature on a commitment. 1

provided that the verifier’s challenge is chosen smaller than the smallest factor of the order of the underlying group

11

2. Cryptographic Background If additional data (a “message”) is hashed, the NI-PoK becomes a signature on this message (as in Schnorr signatures [Sch91]) and is called a signature of knowledge (SoK), or sometimes signature proof of knowledge. Since the actual protocol for a SoK remains the same, we use the same notation as for NI-PoK, with simply appending the message (as in NI-PoKSigOnCommit{. . .}(m)). The security of SoKs can be shown in the random oracle model (ROM). Although in general, a “security proof” in the ROM does not always ensure that the protocol fulfills a useful security property, in practice, it is assumed that the Fiat-Shamir heuristic is secure, as long as a cryptographically strong hash function is used. For a more general and formal treatment of SoKs, see [CL06].

2.4. The Camenisch-Lysyanskaya Anonymous Credential System With anonymous credential schemes, credentials can be issued to users, who can then use these credentials anonymously, e.g., for anonymous authentication – i.e., they do not identify the user, but only prove that the user possesses a valid credential. The Camenisch-Lysyanskaya credential system is a very flexible scheme that also supports credentials containing “attributes”. These attributes (e.g., numbers) are included in the credentials, and later properties of these attributes can be proven to verifiers, using ZK proofs. Technically, an anonymous credential system comprises a signature scheme and a number of protocols that can be used with it. Here, we briefly introduce the CL signature scheme together with protocols that will be used in Part II of this thesis.

2.4.1. CL Signatures In this thesis, we repeatedly use a variant of the Camenisch-Lysyanskaya (CL) signature scheme [CL02], as also used in [BCC04], for signing a tuple of messages X := (x1 , . . . , xm ), where xi ∈ {0, 1}`x (i = 1, . . . , m) and `x denotes the maximum binary length for each xi . The CLS [CL02] is a signature scheme with efficient protocols based on the strong RSA assumption. There exist protocols for this scheme that enable users to sign committed values and prove knowledge of a signature (see below). CLS .Setup(1κ ). The signer S generates an RSA modulus n = pq (with p = 2p0 + 1, q = 2q 0 + 1, and p, p0 , q, q 0 prime), and such that n has size `n := 2κ, where κ is a security parameter. Then S chooses numbers a, b, c ∈R QRn , where a, b are called bases. The public key CLS PK is (a, b, c, n), and the secret key CLS SK is the prime p. CLS .Sign(x, CLS SK ). To sign a message x ∈ [0; 2`m ), the signer chooses a random prime e of size è := `m + 2, a random number s of size at most `s := `n + `m + `, where ` −1 is another security parameter, S computes v ← (ax bs c)e (mod n), and outputs (e, s, v). CLS .Verify(x, σ, CLS PK ). For (e, s, v) := σ, the algorithm tests if v e ≡ ax bs c (mod n), x ∈ [0; 2`m ), s ∈ [0; 2`s ), e is è bits long, and outputs true or false, accordingly. Randomizing CL signatures. In [CG04], the authors remark that the CL signature has the ability to be randomized. This means that the signature (A, e, v) can be masked to (Aˆ := AS w , e, vˆ := v − we) with an arbitrary value w. From the verifier’s point of view, ˆ e, vˆ) and (A, e, v) are both valid signatures on X. (A,

12

2.4. The Camenisch-Lysyanskaya Anonymous Credential System

2.4.2. Zero-Knowledge Protocols for CL signatures The CL signature scheme allows the following useful protocols: Signature on a committed value and PoK of this signature. Signature generation on commitments is a protocol from [CL02] between a user U and a signer S, who knows the secret key CLS SK . Let CLS PK := (a, b, c, n) be the corresponding public key. The common input to U and S is a commitment Cx , for which U (supposedly) knows an opening (x, rx ) : Cx = ax brx . At the end of the protocol U obtains a signature σ := (e, s, v) on x, while x is statistically hidden from S. We denote this protocol as: σ ← SigOnCommit{U(x, rx ), S(CLS SK )}(Cx ). For a commitment Cx0 , U can prove knowledge of (x, rx0 , e, s, v) [CL02], such that (x, rx0 ) is an opening of Cx0 , and (e, s, v) is a valid signature on x, where x and σ are hidden by the zero-knowledge property of the protocol. We denote this protocol as: 0 PoKSigOnCommit{(˜ x, r˜x0 , σ ˜ ) : Cx0 = ax˜ br˜x ∧ CLS.Verify(˜ x, σ ˜ , CLS PK )}. Extension to tuples. The CL signature scheme can be extended to sign message tuples (x1 , . . . , xk ) by introducing k bases ai [CL02]. The extended scheme for k-tuples will be denoted by CLSk . The protocols above can be extended to support multiple messages, and selective message disclosure. E.g., abusing notation, we denote by SigOnCommit{ U(˜ x1 , r˜x1 ), S(CLS3 SK )}(Cx1 , x2 , x3 ) a protocol to generate a signature on a 3-tuple (x1 , x2 , x3 ), where the message x1 is blinded by a commitment Cx1 , and two messages x2 and x3 are disclosed in clear. Similarly, by PoKSigOnCommit{(˜ x3 , r˜x3 , σ ˜ ) : Cx3 = ax3˜3 br˜x3 ∧ CLS3 .Verify((x1 , x2 , x ˜3 ), σ ˜ , CLS3 PK )} we denote the corresponding PoK that U knows a signature σ on a tuple (x1 , x2 , x3 ), where x1 and x2 are disclosed to the verifier, but x3 is kept blinded. Again, the variables with ˜ are kept secret. Implementations. The CL credential system (including the signature scheme and ZK protocols) has been implemented and shown to be practical. For instance, the Identity Mixer (Idemix) system implements CL credentials for identity management in web scenarios [CV02, BBC+ 09], and they have been implemented on Java cards [BCGS09].

13

14

3. Background on Trusted Platforms In this chapter, we introduce basic Trusted Computing (TC) concepts and provide an overview of existing technology to build trusted platforms. We place a particular focus on the approach of the Trusted Computing Group (TCG) [Tru11] to TC. We assume that the reader is familiar with basic concepts of secure computing systems. For an introduction, see text books on system security, such as [Gas88] or [SM08].

3.1. Trusted Platforms In this section, we introduce the basic ideas and the architecture of trusted platforms, as we use in this thesis. We present well-known concepts, mainly based on the Perseus security framework [PRS+ 01], that has been further developed in our research and development projects EMSCB [Eur08a], OpenTC [Ope09b], and others. In Section 3.1.2, we give a short overview of some related approaches.

3.1.1. Architecture of a Trusted Platform A trusted platform is a computing platform that enforces a security policy. It consists of trusted and untrusted components: • Trusted components must work correctly (i.e., they have to be “trusted”) in order to enforce the security policy. • Untrusted components can be important for the functionality of the trusted platform, but a failure (or compromise) of them cannot lead to a violation of the security policy. The security policy defines what a “secure state” means for the platform, i.e., it states what may (and may not) happen on the system. Thus, the security policy depends on the application scenario for the trusted platform. The set of all trusted hard- and software components (for a given application scenario) is called the Trusted Computing Base (TCB) (for that application scenario). Basic architecture. In Figure 3.1, we show the architecture of trusted platforms, as we consider in this thesis. For our purpose, a trusted platform consists of a hardware layer, a trusted software layer, and an application layer. The hardware layer includes a subset of hardware that must be trusted to function correctly in order to enforce a security policy (usually, this includes processor, memory, chipset, and other parts). In particular, the trusted hardware provides dedicated security features (e.g., encryption, digital signatures, secure key storage). We call the hardware providing these features Trusted Computing (TC) hardware. The trusted software layer (or security kernel) contains the software components that must be trusted in all (or most) application scenarios for the trusted platform to enforce

15

3. Background on Trusted Platforms

Figure 3.1.: Basic architecture of a trusted platform. the security policy.1 We divide the trusted software layer into two sub-layers: a virtual machine monitor (VMM) and security services. The virtual machine monitor provides isolated virtual machines (VMs), also called compartments, in which legacy operating systems can be executed. The security services provide dedicated security functionality (e.g., secure storage) that can be used from any compartment. Typically, they use TC hardware for this. The application layer consists of isolated compartments that may either contain legacy operating system with conventional applications, or native applications that have been explicitly developed for the trusted platform. Such native applications might be used for security-critical tasks that must not be influenced by other software, and where the huge code-base of a typical legacy operating system (e.g., a full Windows or Linux operating system) should not be included in the application’s TCB. For other applications, it might be secure enough to use a (minimal) legacy operating system in an isolated compartment. In this manner, they can still be separated from other, arbitrary software that could be running in a different compartment. In any case, this architecture featuring isolated compartments enables the secure use of critical software alongside insecure, arbitrary software in other VMs. The VMM. Modern virtualization technology provides various possibilities to realize a VMM for trusted platforms. As demonstrated in the EMSCB project [Eur08a], a conceptually very appealing approach is to use a microkernel (e.g., from the L4 family [Lie95]) together with a resource management layer (providing basic operating system functionality, e.g., input/output functionality, memory management, task scheduling, etc.) as VMM to provide isolated com1

16

For specific scenarios, certain additional applications (from the application layer) may also be part of the TCB.

3.1. Trusted Platforms partments. Para-virtualized legacy operating systems, most notably a Linux-variant called L4Linux, can be executed on top of this microkernel. However, other VMMs can also be used. For instance, the OpenTC project also used the Xen hypervisor [BDF+ 03a] (beside an L4 microkernel) as VMM in trusted platforms, and the RUBTrust / MediTrust project [RUB11], is employing VirtualBox [Ora11]. Security services. The security services of the trusted software layer can differ depending on the scenario the trusted platform is intended for. Ideally, they are implemented natively on top of the VMM. As a prototype, however, they can also be implemented in a VM based on a (minimal) legacy operating system. Later, for production systems, they can be reimplemented as native services without changing the rest of the platform.

Figure 3.2.: A trusted platform with several security services, including a secure user interface for interaction with users. In Figure 3.1, we show security services running on a trusted platform. Since the actual services may differ from case to case, we describe them in the chapters where they are used. As typical examples, however, we briefly present three of them here: A secure Storage Management service encrypts data that is used by compartments (or other security services) and only decrypts it for the owner compartment. Hence, data used by different VMs is also isolated when stored persistently. Encryption keys are protected with the help of TC hardware (see below for more details). A Compartment Manager starts and stops compartments. It also assigns secure, unique identities to compartments, so that no VM can impersonate another (e.g., when requesting data from the storage management). A Secure Graphical User Interface (GUI) interacts with (human) users. It provides a trusted path from the user to a compartment, i.e., it ensures that users always know which compartment is interacting with them – including that (i) the users’ inputs get to the

17

3. Background on Trusted Platforms right compartment and cannot be captured by others; and (ii) that the user always knows which compartment displays the information shown on the screen. In Part III of this thesis, specific security services will be introduced when needed.

3.1.2. Related Approaches to Trusted Platform Architectures Research into secure system architectures has a long-standing history that cannot be covered exhaustively here.2 Thus, we just briefly discuss recent approaches to trusted platforms that are based on similar concepts as the architecture described above, notably virtualization and trusted computing. A particularly noteworthy early security kernel leveraging virtualization technology was the VAX security kernel [KZB+ 90]. It was designed to be security-certified at a high level (the “A1” level from the orange book [Dep85]) and supported legacy operating systems in untrusted VMs. The system ensured that VMs were completely unprivileged and could not circumvent the VMM, which controlled communication between VMs. For the development of the VAX security kernel, the hardware had to be changed to support self-virtualization. Binding a key to the configuration of the underlying TCB has been realized with secure coprocessors [JSM01, SW99] and with TPMs on Linux [MSMW03]. Terra [GPC+ 03a] is also a VMM-based architecture using Trusted Computing functionality to provide attestation of VMs to remote parties. In that approach, a legacy operating system (Windows or Linux) with VMWare [SVL01] is employed as trusted software layer. With sHype and Deuterium, Sailer et al. [SJV+ 05, MBC+ 06] investigated the enforcement of MAC policies at the level of the virtualization layer, using the XEN hypervisor [BDF+ 03b]. Sailer et al. [SZJvD04] also proposed an integrity measurement architecture for Linux. Such an architecture can be useful for the measurement and reporting of VM states in the trusted platform architecture we presented above. Similarly, although the proposed system of Jaeger et al. [JSS06] focuses on improving the integrity checking of SELinux, its underlying principles can be used for verifying the correctness of the trusted software layer in our trusted platform architecture. Nizza [HHF+ 05] is an architecture for secure systems that is very similar to the Perseusbased [PRS+ 01] architecture described above. Nizza also employs a trusted software layer based on the L4 microkernel [Lie95] and uses the TPM as trusted hardware component.

3.2. Fundamental Trusted Computing Concepts In this section, we describe the fundamental TC concepts trusted boot, trusted storage, and attestation at a high level. The description of Trusted Boot and Trusted Storage in this section is based on the security patterns we published in [LSW10a]. The particular approach taken by the TCG will be introduced subsequently (see Section 3.3).

3.2.1. Trusted Boot Trusted boot ensures that violations of integrity properties of the software stack that is booted on a platform can be either prevented (secure boot) or detected (authenticated boot). 2

18

The most relevant early work is certainly the concept of a security kernel [And72, SDP73, LWS+ 74, AGS83, Fra83].

3.2. Fundamental Trusted Computing Concepts Users of security-sensitive applications want to be sure about the operational integrity of their applications and execution environment. Unauthorized changes to the application code or the operating system may lead to unintentional program behavior or violation of security goals. Users trust the hardware, but they need a way to verify that the software loaded on this hardware has not been tampered with. Authenticated boot and secure boot provide solutions for this. 3.2.1.1. Authenticated Boot Authenticated boot works as follows: Based on the assumption that the hardware of the computer system is correct, the integrity of lower layer boot modules is checked and control is transferred to the next stage only after an “integrity measurement” (a checksum) is written to a place that is protected by trusted hardware. Hence, every stage is responsible for checking (“measuring”) the integrity of the next stage. Usually, a cryptographic hash value is used as a checksum. This ensures that it is not feasible for an attacker to generate a different module with the same checksum. The sequence of these integrity checks builds a chain of trust: If the first module of such a sequence of integrity checks has already been modified in an unauthorized or malicious way, then the user cannot trust on subsequent integrity checks. The modified module could cheat or even skip any integrity checking. Therefore, the very first boot module is the root of trust for the whole chain of integrity measurements and needs to be protected against unauthorized modifications. To protect the initial boot module and to reliably construct the chain of trust, the root of trust is realized in hardware. Hardware is assumed to be more secure than software because it cannot be changed (or read out) as easily as software. Moreover, hardware security modules can be protected against various physical attacks – at least to some extend. After the completion of the boot process, the integrity measurements be digitally signed by TC hardware and reported to remote parties, which can then verify if the platform has booted the desired software. Moreover, the TC hardware can restrict the usage of security features (in particular, the use of cryptographic keys) to system states, where certain integrity measurements have been recorded. The most widespread example for authenticated boot is the TCG approach based on a TPM (see Section 3.3). 3.2.1.2. Secure Boot Secure boot works similar to authenticated boot, however, integrity measurements are verified at each stage of the chain of trust, before the next stage is executed. If this verification fails, the boot process is aborted. For this, the integrity measurement can be either compared to a reference value, or digital certificates are verified. In both cases it is vital that the verification data (i.e., either the reference value or the key used to verify the certificates) is protected against unauthorized modifications. If the system boots, users know implicitly that no integrity violations occurred – otherwise, system boot would have aborted. Examples for secure boot implementations include the AEGIS secure boot architecture [AFS97], the Cell Broadband Engine processor [Shi06], and mobile architectures that

19

3. Background on Trusted Platforms follow the recommendations of the Open Mobile Terminal Platform (OMTP) [Ope09a].

3.2.2. Trusted Storage Trusted storage provides confidentiality and integrity for stored data, and additionally enforces access restrictions on entities that want to access data. In particular, the trusted storage grants access to the data only to authorized, unmodified components that meet these restrictions. Usually, the realization of trusted storage is based on the following concept: A root key is used to encrypt and decrypt data and other keys (which in turn can protect data or other keys). The usage of the root key is controlled by some “root key control” component. Root key and the control component are both protected by trusted hardware, i.e., the secret part of the root key never leaves the hardware, and the control component cannot be manipulated or replaced by users or other software programs (typically, it is either implemented directly in hardware, or as firmware of the TC hardware). The control component verifies the integrity of applications and their execution environment – or, more precisely, an integrity measurement that corresponds application and execution environment – before it performs cryptographic operations on behalf of an application. Examples for implementations of trusted storage are provided by the TPM (see Section 3.3, sealing and binding), and by security extensions of mobile platforms (see Section 3.2.4, ARM TrustZone and TI M-Shield).

3.2.3. Remote Attestation Remote attestation (or attestation for short) enables a remote party (the verifier) to verify the integrity state of a platform over the network. Based on authenticated boot, TC hardware can sign integrity measurements from the “chain of trust”. For this, the TC hardware needs a signing key (an “attestation key”), where the corresponding public verification key is either known to the verifier, or where a certificate for public key exists. This attestation key must be protected by hardware such that attackers cannot generate (forged) attestations themselves. Moreover, it must not be possible to use the attestation key to sign arbitrary data – otherwise, the verifier cannot distinguish whether a signature was on a real integrity measurement, or just on some other data that looks like a legitimate measurement. Hence, attestation keys must only be used to sign a fixed, specified data format where verifiers can recognize legitimate integrity measurements, or they must be completely restricted to sign integrity measurements only.

3.2.4. Overview of TC Technologies Several TC technologies exist. In this thesis, we focus on the most relevant for common current end-user hardware, i.e., PCs and mobile phones. However, other TC technologies than the ones introduced here exist, such as the IBM 4758 secure coprocessor [DLP+ 01] or based on the security features of the Cell Broadband Engine processor [Shi06]. The TCG and the TPM An industrial approach towards the realization of the Trusted Computing functionality within commodity computing platforms is the initiative of the Trusted Computing Group

20

3.3. The TCG Approach to Trusted Computing (TCG) [Tru11] (see Section 3.3 for more details). The TCG has published many specifications amongst which the most important one is that of the Trusted Platform Module (TPM) [Tru07b]. Currently, TPMs are implemented as small, tamper-evident hardware modules embedded in commodity platforms, providing (i) a set of cryptographic functionalities, (such as hardware-based random number generation, digital signature, encryption, hashing), (ii) the protection of cryptographic keys, (iii) the authentication of platform configuration (attestation), and (iv) cryptographic sealing of sensitive data to particular system configurations (thus preventing this data to be accessed under a changed configuration). The TCG defines a limited set of commands, and the firmware of the TPM cannot be programmed by end-users to execute arbitrary functions. Millions of platforms (PCs, notebooks, and servers) being sold today are equipped with TPMs. In Section 3.3, we describe the TCG approach, and in particular the TPM, in more detail. Mobile Platform Security One of the most interesting and relevant security extensions for current smartphone CPUs is ARM TrustZone [AF04], which allows the partitioning of the memory and the CPU of a device into two domains: the so-called secure-world and the normal-world. While untrusted applications (e.g., user applications) are executed in the normal-world, security critical code is executed in the secure-world. The information flow between both the secure and the normal-world is controlled by a secure monitor, which is controlled by the secure-world operating system. Another security extension is Texas Instruments M-Shield [AF08] which is similar and binary compatible with ARM TrustZone. Both the M-Shield and TrustZone security extensions provide a trusted execution environment (TrEE) that can only be accessed by trusted applications. The TCG specifies a Mobile Trusted Module (MTM) [Tru10], a variant of the TPM, specifically adapted for mobile platforms. It is very similar to the TPM, but some of the TPM’s features are optionally for MTMs, additional functionality has been added (most notably secure boot), and MTMs may be implemented (partially) in software.

3.3. The TCG Approach to Trusted Computing The Trusted Computing Group (TCG) [Tru11] has published several specifications that aim at standardizing and establishing the concepts of Trusted Computing. The TCG approach requires conventional hard- and software to be extended by several trusted components that can be at different abstraction layers (hard- and software). These components must be trusted by all involved entities.

3.3.1. The Trusted Platform Module (TPM) The core component specified by the TCG is the Trusted Platform Module (TPM), which constitutes the basis for other security and trust functionalities. The TPM provides a secure random number generator, non-volatile tamper-resistant storage, cryptographic functions like RSA encryption/decryption, key generation algorithms, and the SHA-1 hash function. The TCG has published two versions, 1.1b [Tru02] and 1.2 [Tru07b], of

21

3. Background on Trusted Platforms the TPM specification. Version 1.2 provides more and improved functionality, in particular support for privacy-enhanced cryptographic protocols such as Direct Anonymous Attestation (DAA) [BCC04] and four concurrent monotonic counters. Other improvements introduced with version 1.2 concern several functional optimizations including mechanisms that enable efficient concurrent use of the TPM by different software, and the possibility for the TPM to communicate to other trusted hardware components, e.g., trusted graphics controllers or input devices. TPM-Protected keys. The TPM protects a variety of (special-purpose) encryption and signing keys. These keys can either be migratable or non-migratable. A migratable key can be transferred from one TPM to another (e.g., for backup purposes) whereas a nonmigratable key must never leave the TPM that created it. The most important TPM keys are the Endorsement Key (EK), the Attestation Identity Keys (AIKs), and the Storage Root Key (SRK). The EK is an (RSA) encryption key that uniquely identifies a TPM. Hence, it is privacy sensitive and should not be used directly. Its main purpose is to authenticate the TPM to the certificate issuing entity when a trusted platform asks for certificates on Attestation Identity Keys (AIKs). AIKs are pseudonyms that are used in the attestation protocols (see Section 3.3.4) to hide the TPM’s real identity (i.e., the EK). The EK is generated during the production of the TPM and can be generated inside or outside the TPM and injected by a vendor specific method. The EK must be non-migratable and should be certified by the TPM vendor by an Endorsement Credential, which attests that the EK indeed belongs to a genuine TPM. The EK can be deleted from the TPM if this feature has been enabled by the TPM manufacturer. However, depending on the trust model, the recreation of a deleted EK usually requires the interaction of the TPM manufacturer since a new Endorsement Credential must be issued. In corporate environments, the IT department may act as certifying instance that issues Endorsement Credentials for the TPMs of the company. However, these Endorsement Credentials will only be accepted by entities who trust the IT department. The Storage Root Key (SRK) encrypts all keys entrusted to the TPM and allows the TPM to securely manage a (theoretically) unlimited number of keys by storing their encryptions (under the SRK) outside the TPM. The SRK must be a non-migratable RSA encryption key that is created when setting up the TPM for a new user (TPM Owner ). An existing SRK will be deleted during this process, which means that all keys that have been encrypted with the old SRK will become inaccessible. This securely erases all data that has been protected by the deleted SRK. Note that the (optional) maintenance feature allows to transfer the SRK from the TPM of a defective platform to the TPM of a replacement platform of the same type. However, this requires the interaction with the platform manufacturer. TPM signatures. The TPM can create a TPM signature σM . The existing TCG technology provides two types of TPM signatures. The first type is a DAA signature [BCC04]. With a DAA signature, a verifier is convinced that a TPM has signed a given message, which is either an Attestation Identity Key (AIK) or an arbitrary data string, but the verifier cannot learn the identity of the TPM. The second type of TPM signature is a conventional digital signature; currently, RSA is the only supported signature scheme.

22

3.3. The TCG Approach to Trusted Computing For the purpose of attestation, a TPM generates such a signature using an AIK as signing key, which could either be certified by a Privacy-CA, or it could be introduced by the TPM itself using a DAA signature. For simplicity, we do not distinguish these two cases, and denote by σM := SignM(skM ; m) the output of TPM’s signing algorithm on input the TPM’s signing key skM and a message m, and by VerM(vkM ; σM , m) the corresponding verification algorithm, which on input the TPM’s verification key vkM outputs 1 if σM is valid and 0 otherwise. In Sections 3.3.4 and 3.3.5, we describe TCG attestation with Privacy-CA and DAA in some more detail. Platform Configuration Registers (PCRs). TPM version 1.2 protects a set of 24 registers (160 bit), called Platform Configuration Registers (PCRs). The TPM ensures that the value of a PCR can only be modified as follows: PCRi+1 ← SHA1(PCRi ||I), where PCRi is the old register value, PCRi+1 is the new register value, and I is the input (e.g., the SHA-1 hash value of a soft- or firmware binary). This process is called extending a PCR. Hash values computed during this process are called measurements in TCG terminology.

3.3.2. Authenticated Boot based on the TPM During the boot process of a trusted platform, the PCRs of the TPM are extended by the hash digest (measurement) of the firm- and software binaries of each hard- and software component of the platform before it is loaded and executed (authenticated or trusted boot). The set of values of the PCRs is called platform configuration. This concept requires that every component takes and extends the measurement of each component it is transferring control to (e.g., a TCG-enhanced bootloader measures the operating system), which establishes a chain of trust. The security of this chain strongly relies on explicit security assumptions on the first component of the chain, which is called Core Root of Trust for Measurement (CRTM) in TCG terminology. In addition to the reporting of measurements to the TPM, detailed information on (e.g., the name and version of) the measured software is stored in a logfile, called Stored Measurement Log (SML). Due to efficiency reasons, the SML is managed outside the TPM (e.g., on the platform’s hard disk) whereas its integrity can be verified using the measurements (i.e., the PCR values). The TPM/CRTM is a passive by default, which means that it must be explicitly activated to measure the BIOS and bootloader while the integrity measurements of all other firmware and software must be initiated by the software that loads these components. Therefore, secure TCG-enabled operating systems and services that ensure the correct measurement of all loaded software components are required.

3.3.3. Sealing and Binding Data can be cryptographically bound to a certain platform configuration by the sealing operation of the TPM. The unseal operation releases the decrypted data only if the current configuration (software and/or hardware) equals the configuration which has been defined at the time the data was sealed. Binding is like conventional asymmetric encryption where encrypted data can only be recovered by the TPM that knows the corresponding secret key (no platform configuration check is required).

23

3. Background on Trusted Platforms When a public / private key pair for encryption / decryption is created, the TPM not only generates the cryptographic key pair, but also a information about the key, in particular, the key type and usage restrictions (such as PCR values that have to be present for using the key). This information is stored in a data structure together with the cryptographic key, which is then cryptographically integrity-protected and encrypted, based on the SRK (or another TPM-protected parent key). The resulting key blob can then be stored outside the TPM (e.g., on a hard disk) without further protection. When a user wants to unseal or unbind data, the key blob with the corresponding key must first be loaded into the TPM. Before using this key, the TPM verifies that the key blob has not been modified, and that all usage conditions are met.

3.3.4. TCG Attestation The TCG attestation protocols are used to give assurance about the platform configuration to a remote party, called verifier. To guarantee integrity and freshness, PCR values and a fresh nonce N provided by the verifier are digitally signed with an Attestation Identity Key (AIK), which is under the sole control of the TPM. For the certification of AIKs, two approaches have been specified by the TCG: using a Privacy-CA, and direct anonymous attestation. For the first approach, a trusted third party, the Privacy Certification Authority (Privacy-CA), has to guarantee the pseudonymity of AIKs and provide evidence that an AIK indeed belongs to a genuine TPM. To obtain a certificate for an AIK (Attestation Credential, cert(AIK )), the TPM must send its Endorsement Credential (that includes its public EK) to the Privacy-CA. If the Privacy-CA is convinced that the public EK indeed belongs to a genuine TPM (e.g., by verifying the Endorsement Credential), it issues an Attestation Credential and encrypts it with the public EK of the TPM. The Attestation Credential can only be decrypted by the TPM that knows the corresponding secret EK. On the one hand, this procedure ensures that only genuine TPMs can obtain Attestation Credentials. On the other hand, however, the Privacy-CA can link all AIKs (and thus all transactions) of a TPM by means of the EK [KSS07]. In order to overcome this problem, version 1.2 of the TPM specification defines a cryptographic protocol, called Direct Anonymous Attestation (DAA) [BCC04], which will be explained in Section 3.3.5. During the attestation protocol, the attesting platform transmits its SML, the signed PCR values, and its certified AIK to the (remote) verifier. To verify the attested platform configuration, the verifier recomputes the PCR values based on the SML and a set of reference measurements and verifies the signature generated by the TPM. The reference measurements are provided by validation credentials, which are digital certificates issued by the hard- or software manufacturers of the measured components or other qualified validation entities. One drawback of the TCG approach is the disclosure of the exact soft- and hardware configuration of the attested platform to the verifier. This can be exploited by attackers or used to discriminate against users. Thus, an alternative solution to TCG attestation, called Property-Based Attestation (PBA), has been proposed (see Chapter 5). Another draw back is limited scalability: Since any minor modification of the components that are to be attested leads to completely different hash values, an enormous amount of different values can be expected in any practical system. This creates considerable management issues that can soon become intractable, in particular, when considering

24

3.3. The TCG Approach to Trusted Computing a large number of inhomogeneous complex systems. Some PBA approaches also try to mitigate this issue, although our cryptographic protocols in Chapter 5 do not address it directly.

3.3.5. Direct Anonymous Attestation (DAA) DAA [BCC04, Tru07b] is an anonymous credential system that has been designed specifically to encapsulate security-critical operations in a cost-effective secure hardware module. DAA offers various features, such as linking signatures and tagging rogue participants. Here, we concentrate on the most relevant components for our purpose. A DAA scheme involves the following parties: A DAA issuer I which issues DAA credentials; a security module M (e.g., a TPM) and a host H which generate a secret key SK , obtain DAA credentials and create DAA signatures; and a verifier V which checks the correctness of DAA signatures. DAA consists of the following algorithms and protocols: • Setup: On input of a security parameter, I uses this algorithm to generate a secret key SK I and a set of public parameters, including the issuer public PK I . In practical schemes, I must prove the validity of PK I . We denote by Cred I the set of PK I and such a proof of validity (this is a public parameter). • Join: This protocol runs between I that issues a credential, and H and M that work together to obtain this credential. M generates a secret key SK and, supported by H, a commitment Co n SK . On input of Ca nd SK I , I generates Cred DAA , a DAA credential associated with SK . The value Cred DAA is given to H3 , while SK is only known to M. In practical schemes, M must append a proof that it is a genuine security module to C( e.g., a TPM must include its EK certificate). In this case, I has to validate such a proof (e.g., the EK certificate) before issuing Cred DAA . • Sign: On input of SK , Cred DAA , a basename bsn (the name of V for pseudonymity, or the empty string for full anonymity), the verifier’s nonce nV (for freshness) and a message m, M and H run this protocol to obtain a signature σDAA on m. In fact, σDAA is a signature proof of knowledge demonstrating that M and H possess a valid credential, which does not include any information about their identities. • Verify: On input of a message m, a candidate signature σDAA for m, a basename bsn, a nonce nV and the issuer public key PK I , V runs this algorithm to return either accept or reject. Note that σDAA does not include any information about the signer. In practical schemes, this algorithm gets a list of rogue participants as input to avoid accepting a signature made by a rogue M. How to deal with such a list is out of the scope of this thesis. 0 • Link: On input of two signatures σDAA and σDAA , V runs this algorithm to return linked, unlinked or invalid signatures.

Different DAA variants have been proposed [BCC04, BCL09, CMS08, Che10]. For the purpose of this thesis, [BCC04] and [CMS08] are particularly relevant: The original DAA scheme based on the strong RSA assumption – which has been specified by the 3

Depending on the underlying DAA protocol, Cred DAA may also be forwarded to M. However, we omit this technical detail in the following.

25

3. Background on Trusted Platforms TCG and implemented in TPM v1.2 – and a more recent proposal based on elliptic curve cryptography and asymmetric pairing4 .

3.3.6. Trusted Software Stack (TSS) The TCG specified a platform-independent software interface for accessing TPM functions, called Trusted Software Stack (TSS) [Tru07a]. The TSS is compatible to existing cryptographic APIs (e.g., MS-CAPI or PKCS#11) to allow current and future applications without explicit TCG support to use the cryptographic functions provided by the TPM. However, in order to take full advantage of the TPM functionalities applications must support the TSS directly. The current TSS specification is highly complex, which makes its usage very difficult and error-prone for application developers and unsuitable for embedded devices or security kernels. This motivated the development of a scalable, compact object-oriented TSS that allows to use only a subset of the provided functionality as it is required, e.g., for embedded systems, mobile devices, or in the context of a security kernel [SZ10].

4

26

Security flaws have been noticed in this scheme, and a preprint of a fixed version is available at eprint.iacr.org/2009/198.

Part II.

Privacy-Preserving Protocols

27

4. Electronic Multi-Coupon Schemes In this chapter, we present two privacy-preserving multi-coupon schemes with strong unsplittability, together with formal security models and proofs of security. The material in this chapter has been published in [CBL+ 07] and in [AEL+ 08]. The first scheme and an early version of the second scheme are also described in [Esc08] (including quite a detailed introduction to the cryptographic background).

4.1. Introduction Paper-based coupon schemes are successfully used by enterprises for various marketing purposes like providing discounts, increasing sales within a period of time (via coupons with some specified validity period), setting up prepayment models, attracting new customers, and establishing long-term relationships (loyalty) with them. From an abstract point of view, a coupon is some information that gives a customer the right to claim a good or service from a vendor. The procedure in which a vendor provides a customer with a new coupon is called issue. The procedure in which the customer pays using the obtained coupon is called redeem. Here, the vendor verifies that the coupon is valid and authentic, and provides the customer with the specified good or service. Coupons can be used only once. In the following, we denote by object the good or service implied by a coupon. Any item that can be bought may become an object in practice, e.g. cloths, songs, books, videos, medicines, tickets, and even immaterial services: discounts, access to computer resources or facilities, etc. In contrast to widely used paper-based coupon schemes, electronic coupons (e-coupons) have gained acceptance relatively slowly [PG04], and are still waiting for their breakthrough. One of the reasons for this development is insufficient security of available schemes. A multi-coupon (MC ) [CES+ 05, Ngu06] denotes a collection of e-coupons that is handled as a single unit, i.e., the electronic equivalent of a paper-based coupon booklet, where individual coupons can only be redeemed when presented together with the booklet. In this chapter we consider multi-coupon schemes (MCS ) that protect the privacy of the customers, and encourages loyalty of clients by providing unsplittability [CES+ 05], i.e., two users cannot redeem coupons from the same MC separately and independently. Consider prepaid-goods, where a vendor, hoping for a long-term client relation, sells many goods at once at a cheaper price compared to that of separately sold goods. In this case sharing would allow a group of users to buy a single MC , and obtain goods at a subsided price, but without giving loyalty in return. First, we focus on a basic MC framework where the only involved parties are many customers (users) and a single vendor. Then we generalize this framework to a setting with several cooperating vendors. From the security point of view, threats in MC systems are different from those in paper-based coupon systems. First, it is very easy to create a perfect (digital) copy of

29

4. Electronic Multi-Coupon Schemes an electronic MC , whereas copying a paper-based booklet requires much higher effort. Second, when dealing with an MCS , we must also consider attacks in which different users collude and attempt to cheat the vendor. For the federated scenario with cooperating vendors, we also have to take into account collusions of malicious vendors. Moreover, in the digital world privacy and anonymity of customers becomes more important since the vendor may try to infer and store additional information about them including purchase habits, gender, age, etc. This would harm privacy and allow client profiling and price discrimination [Odl03], e.g., different customers are offered the same goods by the same vendor, but at different prices.

4.1.1. Desired Security Properties We focus on unforgeability, unlinkability, and unsplittability because, as pointed out in [CGH06, CES+ 05, Ngu06], these are the essential properties of a MCS . Unforgeability. There is an intrinsic monetary value associated to any coupon, explicitly or implicitly. Therefore, vendors want their multi-coupons to be unforgeable, in the sense that no coalition of users should be able to redeem more coupons than it has been rightfully allowed. Unlinkability. It must be infeasible for a vendor to link a redeem procedure for a customer to the corresponding issue procedure, or to link two different redeem procedures with the same customer. This implies anonymity of customers. Unsplittability. Weak unsplittability (WU) [CES+ 05], also known as all-or-nothing sharing, intuitively, requires that whenever a user intends to share a single coupon with a second user, she has to provide her with all the secret information related to the involved MC . This, however, would make possible the complete redemption of the MC by the second user. Thus, in case that both users do not trust each other, WU discourages sharing. A stronger version, called (ordinary) unsplittability, requires that it is infeasible for an adversary to produce more autonomous redemption algorithms than the number of multicoupons he has rightfully obtained, where by autonomous we mean that such algorithms do not share any information gained during the redemption. In other words, if a user gives a single coupon to another user, then that second user has to send back some information to the first user after redeeming; otherwise the first user cannot spend further coupons from that multi-coupon. Hence, sharing is more cumbersome with this stronger version of unsplittability than with weak unsplittability because it requires a trust relationship and additional interaction between the users. Framing resistance and claimability. To support business models where the vendor which provides the user with a service (in return for a coupon) can charge money from the issuer of the coupon, additional requirements must be met. During the redemption protocol, the issuer of the coupon must be identifiable, and other vendors must be protected from incorrectly being held responsible for issuing this coupon. In our generalized scheme (Section 4.5.1), we actually define two requirements, framing resistance (the requirement

30

4.1. Introduction of the issuer) and claimability (the requirement of the redeeming vendor). Although payment issues are important for the deployment of an MCS in practice, they cannot be completely solved by cryptographic techniques. Hence, these issues are out of scope of this thesis. Here, we assume that it suffices that a judge can execute an algorithm Claim to verify that a coupon, issued by a given issuer, has been redeemed to a given vendor.

4.1.2. Contribution and Organization We start with a brief overview of our constructions in Section 4.2, and give a description of related work on multi-coupon schemes in Section 4.3. In Section 4.4.1, we define the syntax and correctness of an MCS , and propose a precise security model for MCS s that includes a strong form of unsplittability without relying on all-or-nothing sharing. Thereafter, in Section 4.4.2, we propose a construction of a privacy-protecting MCS which satisfies our stronger requirements and provides additional features for practical applications, e.g., different attributes for individual coupons within one multi-coupon and validity periods thereof. In this scheme, individual coupons of a multi-coupon must be redeemed in an order that is fixed when the multi-coupon is issued. Redeem complexity (both computation and communication) is constant w.r.t. the size k of the multi-coupon (i.e., the number of coupons it contains), and complexity of the protocol for issuing multi-coupons is linear in k, which is the best we can get when each coupon has individual attributes. Additionally, we prove the security of our scheme in the proposed security model in Section 4.4.3. If an MCS is to be used with a federation of vendors, the restriction on a fixed order of redemption can be an undesirable limitation: imagine that the vendors want to offer an MC with coupons for different types of goods. In that case, customers certainly would want to decide themselves in which order they want to redeem their coupons. Hence, we need a non-sequential MCS , where the coupons can be redeemed in arbitrary order. Yet our first scheme offers nice features that we want to retain in a non-sequential MCS , in particular, coupon objects (attributes). These allow to have different types of coupons in one multicoupon. We extend our first scheme in two important aspects: our second scheme can be used by a group of vendors (which also introduces new security requirements), and we do not require the order of redemption of the individual coupons to be fixed when the MC is issued (i.e., users can choose arbitrarily during the redeem protocol which coupon they want to spend). In Section 4.5.1, we present our generalized model for a federation of vendors and arbitrary order of redemption, and in Section 4.5.2 we present our second scheme. We demonstrate the security of this scheme in Section 4.5.3. Redeem complexity (both computation and communication) of our second scheme is constant w.r.t. the size k of the MC (i.e., the number of coupons it contains), and complexity of the protocol for issuing MC s is linear in k, which is the best we can get when each coupon has individual attributes (like coupon objects). If all coupons in an MC are the same (i.e., no coupon objects are used), ideas from [CHL05] can be used to further reduce the complexity. Finally, in Section 4.6, we conclude this chapter and provide some insights into possible improvements and future work.

31

4. Electronic Multi-Coupon Schemes

4.2. Brief Overview of our Constructions Before introducing our security models, constructions, and proofs in detail in subsequent sections, we want to give a brief overview of our two privacy-preserving unsplittable multicoupon schemes: Our first scheme [CBL+ 07] supports one vendor and many users. Individual coupons in a multi-coupon may have different attributes (“coupon objects”) and have to be redeemed in a fixed order which is determined when the multi-coupon is issued. Our second scheme [AEL+ 08] is a generalisation of the first scheme that supports a federation of cooperating vendors. Moreover, it allows the user to choose dynamically which individual coupon from a multi-coupon to redeem. Coupons may have individual attributes, as with the first scheme.

4.2.1. Privacy-Protecting Unsplittable Multi-Coupons with Fixed Order of Redemption In our first scheme, each single redeemable coupon (id , ob, sq, σ, σ 0 ) is specified by a coupon identifier id , a coupon sequence number sq, a coupon’s object ob (i.e., the good or service represented by the coupon1 ), a signature σ on the tuple (id , ob, sq), and a signature σ 0 on sq. A coupon is not redeemable if it lacks σ 0 . A multi-coupon M of size k is a list of k single coupons with consecutive sequence numbers, where at least the first coupon must be redeemable. In the issue protocol, the user obtains a multi-coupon where the coupon identifiers are kept private by the user, and all other attributes are known to both user and vendor. After the issue procedure, only the first coupon is redeemable, but every coupon has a valid signature σi , for 0 ≤ i < k. During the redemption of the i-th single coupon with sequence number sq i , the user obtains a 0 signature σi+1 on the sequence number sq i + 1, and hence the next coupon in the list becomes redeemable. In order to redeem a coupon, the user must prove that the coupon has never been used before (by disclosing id ), and that it is indeed redeemable (by proving that σ is a valid signature on id , ob and sq, and that σ 0 is a valid signature on sq). Informally, the vendor’s knowledge about elements of a single coupon depends on the actual procedure, i.e., id is hidden during the issue protocol, and disclosed to the vendor during redemption; sq, σ, σ 0 are known to the vendor during issuing, but hidden during the redeem protocol; ob is known to the vendor during both the issue and the redeem protocols. Our scheme utilizes a digital signature scheme with efficient protocols that allows to obtain a signature on a (partially) blinded tuple (i.e., some elements of the tuple are disclosed, while others are only committed to), and to prove the knowledge of a signature on a (partially) blinded tuple without disclosing any useful information, other than the fact that the signature is valid.

4.2.2. Privacy-Protecting Unsplittable Multi-Coupons with Arbitrary Order of Redemption for Federated Environments In our second scheme, a group of vendors V with common databases DB , DB 0 (trusted by the vendors) executes protocols with users U to issue and redeem coupons (cf. Figure 4.1). 1

The vendor must publish an official coding of coupon’s objects as integers.

32

4.2. Brief Overview of our Constructions

Figure 4.1.: A multi-coupon scheme supporting a federation of cooperating vendors. The databases are used only during the redeem protocol. A multi-coupon M contains k individual coupons, which include, among other information, a coupon identifier id . The coupons are all cryptographically tied to M , which has an MC identifier mid and a freshness identifier fid . To simplify the description below, we temporarily omit coupon objects ob and the MC identifier mid . In the Issue protocol, a user U obtains an MC from a vendor V with one signature on each individual coupon, and one signature validating the freshness fid , signed by the issuing vendor V . The signatures on the individual coupons (on id ) prevent U from forging coupons, whereas the signature on the MC (on fid ) ensures its freshness, which is used to prevent splitting. In the Redeem protocol, the user U redeems a single coupon from an MC to a vendor V 0 . For this, he has to prove knowledge of a signature on the single coupon and that the MC is fresh. Double redemption of coupons is prevented by the vendor V 0 through a lookup in a central database DB of coupon identifiers. Similarly, V 0 queries the central database DB 0 of freshness IDs to verify the freshness of the MC . If the current coupon id and freshness ID fid have not already been used, then they are inserted into the corresponding database. Afterwards, the database DB sends a signature certDB to the vendor V 0 certifying that V 0 is responsible for the redemption of this coupon. V 0 will need this signature as an evidence to charge the coupon issuer. At the end of Redeem, a new fid is generated and signed by V 0 , so that this protocol can be executed repeatedly, as long as there are coupons left in the MC . After redemption, the Claim algorithm can be executed by any party to verify that a user redeemed a coupon originally issued by a vendor V to a vendor V 0 , and thus, that V 0 is entitled to charge V for the corresponding coupon. The input to this algorithm is the coupon ID id , a (non-interactive) proof of knowledge of a signature on id , and the certificate certDB given by DB to V 0 during Redeem. The certificate is used to prevent double charging. Note that the databases do not participate in this algorithm.

4.2.3. Notation For a finite set S, s ∈R S denotes the assignment of an element sampled uniformly from S to the variable s. Let AlgA be a probabilistic algorithm. By outA ← AlgA (inA ) we denote that the variable outA is assigned the output of AlgA ’s execution on input inA . We denote by (AlgA (inA ), AlgB (inB )) a pair of interactive algorithms with private inputs inA and inB , respectively, and write (outA , outB ) ← (AlgA (inA ), AlgB (inB )) to denote the assignment of AlgA ’s and AlgB ’s private outputs after their interaction to the variables outA and outB , respectively.

33

4. Electronic Multi-Coupon Schemes

4.3. Related Work Syverson et al. [SSG97] introduced the concept of unsplittability in the context of unlinkable serial transactions to discourage sharing, and suggested an extension of their scheme to implement coupon books. Later, Chen et al. [CES+ 05] described the properties that a privacy-protecting multi-coupon system must provide, justified the use of unsplittability over other means to discourage sharing (e.g., hiding credit card numbers in the multi-coupons), and proposed an unforgeable, unlinkable, and weakly unsplittable scheme. However, their construction is less practical because of an expensive proof of knowledge used in the redemption, whose complexity is linear in k (i.e., the number of coupons in the multi-coupon). More recently, Nguyen [Ngu06] addressed some disadvantages of [CES+ 05], and defined a security model for MCS s, followed by an efficient construction based on a verifiable pseudorandom function and bilinear groups. Its issue and redeem complexity is constant w.r.t. k, it offers the same security properties as in [CES+ 05], and adds a new feature to revoke multi-coupons. It is arguable whether revocation is indeed necessary for a MCS , since in real life it is unusual that a vendor revokes issued coupon booklets, and this operation might be costly. One drawback of both above mentioned schemes is that every issued multi-coupon must contain the same number of coupons, i.e., k is a system parameter fixed for all multicoupons. This limitation, as pointed out in [Ngu06], can be overcome in both schemes by extending the issue protocol. However, this extension is impractical, i.e., for [Ngu06] a term k − m0 is added to the complexity of the issue protocol, where m0 (0 < m0 < k) is the number of issued single coupons. Another drawback of these schemes is that there is no concept of coupon’s object (or coupon’s type [CGH06]). Hence, all coupons are valid for the same purpose. As previously explained in [CES+ 05, Ngu06], most related schemes (e.g., e-cash, digital credentials) cannot be employed as privacy-protecting unsplittable MCS s because they have different usage patterns [PV04, BCB05], are inefficient in this setup [NSN05], or lack at least one of the required properties [Bra02], in particular unsplittability. Some e-cash systems can be used as unlinkable or at least anonymous MCS s (e.g. [CHL05, CGH06]). However, they are (unintentionally) at most weakly unsplittable.

4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption In this section, we present a security framework (in Subsection 4.4.1) and propose a cryptographic scheme (in Subsection 4.4.2) for privacy-preserving multi-coupons with strong unsplittability and a fixed order of redemption. We prove the security of our scheme (in Subsection 4.4.3) with respect to our security framework.

4.4.1. Security Framework for Multi-Coupon Schemes First, we introduce a formal security framework for multi-coupon schemes, which later on will be used to prove the security of our single-vendor scheme with fixed order of redemption.

34

4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption 4.4.1.1. General Multi-Coupon Schemes We consider a basic framework where the participants are a single vendor V and a collection of users Ui . The following definition is general in that it does not account for specific coupon features such as revocation, coupon objects, or validity periods. We will refer to any particular user simply by U. Definition 4.4.1 (Multi-Coupon Scheme). A multi-coupon scheme (MCS) consists of a set of protocols: {Setup, Issue, and Redeem}, which are specified by the following algorithms. Setup algorithm. (PK , SK ) ← Setup(1κ ) is the initialization algorithm executed by the vendor once to generate one instance of the multi-coupon scheme. It takes as input the security parameter κ, and outputs a public key PK (which from now on we assume to include the security parameter κ coded in unary, and a system parameter kmax representing the maximum allowed number of coupons per MC ), and a secret key SK (which might include PK ). Issue protocol. In order to obtain a MC with k coupons, U performs the following protocol with V : ((resu , M ), resv ) ← (Issueu (k, PK ), Issuev (k, SK )), where, from now on, the subindices u and v denote user and vendor algorithms, respectively. The output flags resu , resv ∈ {acc, rej} indicate success or failure according to the user or vendor, resp. Issueu outputs the flag resu and a multi-coupon M , whereas Issuev only outputs the flag resv . Redeem protocol. After U has obtained the multi-coupon M she redeems it to V by performing the protocol ((resu , M 0 ), (resv , s0 )) ← (Redeemu (M , PK ), Redeemv (s, SK )). Redeemu outputs an updated multi-coupon M 0 , and a flag resu just like in issue, and Redeemv outputs a new vendor’s internal state s0 , which is initially set to the empty string, and a flag resv . The correctness requirement states that an honest user who obtains a MC from a fresh honest vendor must be able to redeem all the coupons it contains. Definition 4.4.2 (Correctness). A multi-coupon scheme is correct if the following experiment returns true with overwhelming probability (for any k ∈ [1, kmax ]), where resIs and resRe are the output flags of the issue and redeem algorithms, respectively, and si is the vendor’s state, which is updated after each redemption. (PK , SK ) ← Setup(1κ ); s1 ← ε; ((resIsu , M1 ), resIsv ) ← (Issueu (k, PK ), Issuev (k, SK )); for i = 1 to k do: ((resReiu , Mi+1 ), (resReiv , si+1 )) ← (Redeemu (Mi , PK), Redeemv (si , SK)); if (resIsu , resIsv , resRe1u , resRe1v , . . . , resReku , resRekv ) = (acc, . . . , acc) return true; else return false; 4.4.1.2. Adversarial Model and Security Requirements In this section we present a solid security framework that covers a wide range of adversarial actions. We begin by defining the queries available to the adversary, and then we define the security requirements. An adversary is a p.p.t. algorithm A, which can play the role of, either, a vendor and a group of users, or only of a group of users. A can interact with the other participants

35

4. Electronic Multi-Coupon Schemes through a set of queries, which cannot be interleaved.2 Without loss of generality, we let the adversary be specified by a sequence of algorithms (e.g. A := (A1 , A2 , A3 )). Honest parties are assumed to communicate over secure channels. Depending on the degree of independence from the adversary, we consider two types of users: scheduled and corrupted users. Users belonging to the set of scheduled users (SU) execute honest algorithms if requested by the adversary, but remain honest otherwise. The adversary has full control over the corrupted users, grouped in the set CU, and is provided with their previous protocol views. Additionally, the adversary might act as a group of malicious users. Similar to [KTY04], we allow the adversary to interact with the system through a set of queries handled by an interface, which partially simulates the MCS , executes protocols with the adversary, and records certain user’s or vendor’s activities. The queries available to an adversary differ depending on whether he is playing the vendor’s role or only a user coalition. We distinguish between two types of interfaces. The first interface (I1 ) is employed to model a MCS facing a collusion of users, and is used to define unforgeability, and unsplittability. The second interface (I2 ) models a MCS controlled by a malicious vendor, and is only employed to define unlinkability. Interface 1 (I1 ). In this case the adversary plays a collusion of users, and the interface plays the vendor and the honest users. I1 maintains the vendor’s state s, and some counters, which are updated in each query: ctr M : number of non-empty multi-coupons rightfully provided to the adversary, ctr C x : number of available (used and unused) coupons given to x, and ctr Rx : number of coupons redeemed by x, where x denotes one of the participants, and can be either A to denote the adversary, or some arbitrary string U to denote a particular user. Now we present the queries and the actions performed by the interface. I1 .GetPK. Returns the vendor’s PK to the adversary. I1 .Issuev (k). If k < 1 or k > kmax the interface aborts (halts and returns rej), otherwise it simulates the Issuev algorithm playing the vendor, and interacts with the adversary, who plays the user. The counters are updated as follows: ctr M ++, ctr C A +=k (where ++ and +=k denote increment by 1 and k, resp.). I1 .Issueu (U, k). If k < 1, k > kmax , U ∈ SU, or U ∈ CU, then the interface aborts, otherwise it simulates a protocol run between an honest user U and the vendor. U is an arbitrary value specified by the adversary to the interface, which allows the adversary to refer to precisely the same user later on. The user’s view of the protocol is stored in a transcript, and the variables are updated: SU ← SU ∪{U}, ctr C U ← k, ctr RU ← 0. In our security model every existing user has exactly one multi-coupon: a real world honest user with m multi-coupons can be simulated by m users, each one having a single multi-coupon. I1 .Redeemv . The interface performs the Redeemv algorithm, enabling the adversary to redeem one of his coupons. If the interaction is successful (resv = acc) the counters are updated as follows: ctr RA ++, ctr M ← min(ctr M, ctr C A − ctr RA ). (An adversary with at most ctr C A − ctr RA unused coupons is not allowed to have more than ctr C A − ctr RA non-empty multi-coupons.) These counters are important for the unforgeability and unsplittability requirements. 2

36

This reflects the properties of existing schemes, and simplifies the construction.

4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption I1 .Redeemu (U). The interface simulates a Redeem protocol run between the honest user U and the vendor (both algorithms Redeemu and Redeemv are simulated). If resv = acc the interface stores the user’s view in the transcript, and sets ctr RU ++. The only information returned to the adversary is resv . I1 .Corrupt(U). The interface first verifies that U ∈ SU, otherwise it aborts. Then it sets SU ← SU \ {U}, CU ← CU ∪ {U }, and finally it gives to the adversary the user’s previous protocol views, which are extracted from the transcript. The counters are updated: ctr C A +=ctr C U , ctr RA +=ctr RU , and if ctr C U > ctr RU , then ctr M +=1. Interface 2 (I2 ). This interface is capable of simulating a collection of honest users scheduled by the adversary, who plays the vendor. Again we use SU and CU to denote sets of scheduled and corrupted users resp., and the counters ctr C x and ctr Rx with the same meaning as in I1 . The following queries are provided: I2 .GetPK-SK. The interface gives the pair (PK , SK ) to the adversary. I2 .Issueu (U, k). If k ∈ [1, kmax ] and U ∈ / SU ∪ CU the interface executes the Issueu algorithm (otherwise it aborts). Then, the interface sets SU ← SU ∪ {U}, ctr C U ← k, ctr RU ← 0, and appends its protocol view to the transcript. I2 .Redeemu (U). If U ∈ / SU or ctr C U = ctr RU , then the interface aborts (the second condition prevents the interface from trying to overuse a multi-coupon). Then it executes the Redeemu algorithm simulating the honest user U. The vendor stores the user’s view in the transcript, and sets ctr RU ++. I2 .Corrupt(U). This query is handled exactly as in I1 . 4.4.1.3. Unforgeability Informally, unforgeability means that no group of users (controlled by A), with ctr C A coupons in total (comprised in, say, m multi-coupons), should be able to redeem ctr RA > ctr C A coupons. More formally, this property is defined as follows. Definition 4.4.3 (Unforgeable MCS ). A multi-coupon scheme is unforgeable if there is no p.p.t adversary A := (A1 , A2 ) that can win the forgeability game in Fig. 4.2 (ForgeGame(A, κ) = broken) with non-negligible probability (in κ). An adversary A first interacts with the interface I1 (i.e., queries GetPK, Issuev (·), Issueu (·, ·), Redeemv , Redeemu (·), and Corrupt(·)). A wins if he is able to redeem an additional coupon after having redeemed the same number of coupons he has rightfully obtained. Note that any adversary A0 who achieves ctr RA > ctr C A , can be transformed into an adversary A, who wins the ForgeGame at the expense of at most a polynomial factor in the success probability. 4.4.1.4. Unsplittability Informally, a MCS is unsplittable if it is infeasible for an adversary A rightfully holding at most ctr M non-empty MC s to generate ctr M + 1 shares s0 , . . . , sctr M , which can be used each to autonomously redeem at least one coupon. This must hold, even though A might have ctr C A − ctr RA ≥ ctr M unused coupons.

37

4. Electronic Multi-Coupon Schemes ForgeGame(A, κ): (PK , SK ) ← Setup(1κ ); σ ← AI11 (1κ ); if (ctr C A 6= ctr RA ) then return unbroken; (resA , resv ) ← (A2 (σ), I1 .Redeemv ); if (resv = acc) then return broken; else return unbroken;

SplitGame(A, κ): (PK , SK ) ← Setup(1κ ); (s0 , . . . , sctr M ) ← AI11 (1κ ) for i = 0 to ctr M do: (resiA , resiv ) ← (A2 (si ), I1 .Redeemv ); M = acc) then if (res0v = acc ∧ · · · ∧ resctr v return broken; else return unbroken;

Figure 4.2.: Forgeability and Splittability Games. Definition 4.4.4 (Unsplittability). A multi-coupon scheme is unsplittable if there is no p.p.t. adversary A := (A1 , A2 ) capable of winning the splittability game in Fig. 4.2 (SplitGame(A, κ) = broken) with non-negligible probability (in κ). In the splittability game the adversary first interacts with the interface I1 , and outputs ctr M + 1 indexed states (shares) s0 , . . . , sctr M . Then he sequentially executes ctr M + 1 redemption algorithms A2 (si ), for 0 ≤ i ≤ ctr M . The adversary wins if each one of the ctr M + 1 redemption algorithms succeeds. We remark that, inside the “for loop” in Fig. 4.2, A2 (si ) does not depend on the information obtained in the execution of A2 (sj ) with i 6= j. The adversary’s only input is a state si (for some i); this ensures the autonomous redemption. In contrast, the interface I1 implicitly updates the vendor’s state. 4.4.1.5. Unlinkability Informally speaking, unlinkability means that an adversary playing the role of the vendor cannot recognize (significantly better than by a random guess) which honest user redeems a coupon when such a user is randomly selected from a pair of users of his choice (equivalently with MC s instead of users). In [CGH06] a simple definition of unlinkability is proposed. However, the adversary cannot further interact with the users after the challenge took place. The number of unused coupons left in the selected pair of MC s can be easily used by the adversary to link the protocols. This problem is (almost) solved in [Ngu06] by hiding the number of unused coupons of the pair of challenged MC s from the adversary. However, this is done (in part) by requiring that none of the challenged MC s is ever emptied, hence the adversary is unrealistically prevented from using the last coupons within the challenged MC s. Definition 4.4.5 (Unlinkability). A multi-coupon scheme is unlinkable if there is no p.p.t. adversary A := (A1 , A2 , A3 ) with non-negligible linkability advantage, which is defined as: Advlink (A, κ) = Pr[LinkGame(A, κ) = broken] − 1/2. For the linkability game (see Figure 4.3), the adversary A first interacts with the interface I2 (queries GetPK-SK, Issueu (·, ·), Redeemu (·), and Corrupt(·)), and outputs the user identities U0 and U1 , of two scheduled users that have at least one unused coupon left (i.e. ctr C x > ctr Rx , for x ∈ {U0 , U1 }). Then, b is randomly selected from {0, 1}, and the redemption algorithm Redeemu (Ub ) is executed with A. Afterwards, A is given a set of queries I2 (m0 , m1 , U0 , U1 ), similar to those of I2 , except that the users U0 and U1

38

4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption LinkGame(A1 , A2 , A3 , κ): (PK , SK ) ← Setup(1κ ); (U0 , U1 , s) ← AI12 (1κ ); if not (U0 ∈ SU ∧ U1 ∈ SU ∧ ctr C U0 > ctr RU0 ∧ ctr C U1 > ctr RU1 ) then return unbroken; b ← {0, 1}; m0 ← ctr C U0 − ctr RU0 − 1; m1 ← ctr C U1 − ctr RU1 − 1; (resUb , s) ← (I2 .Redeemu (Ub ), A2 (s)); I (m ,m ,U ,U ) d ← A32 0 1 0 1 (s); if (resUb = acc ∧ d = b) then return broken; else return unbroken;

Figure 4.3.: The unlinkability game. cannot be corrupted, and at most m0 Redeemu (·) queries can be made for the user U0 and m1 queries for U1 , where m0 (resp. m1 ) is the number of unredeemed available coupons minus one held by user U0 (resp. U1 ) before A2 redeems. This hides the number of unused coupons from A, thus avoiding the problem mentioned above. Finally, A outputs d. If d = b the adversary won the game, otherwise he lost. Theorem 4.4.1. Unsplittability is strictly stronger than unforgeability. Proof (Sketch). (⇒) The condition ctr C A = ctr RA in the forgeability game implies ctr M ≤ 0. Therefore, an adversary A against ForgeGame is also an adversary against SplitGame with at least the same success probability. E.g., if ctr M = 0, then A “splits zero multi-coupons into one”. For the other direction (:) consider the schemes proposed in [CES+ 05, Ngu06] which are unforgeable but not unsplittable.

4.4.2. Our Multi-Coupon Scheme with Fixed Order of Redemption We propose the first unsplittable MCS where each coupon has an individual object, and coupons belonging to the same MC must be redeemed in certain linear order, which is fixed during the issue procedure. The scheme can be easily extended with validity periods and arbitrary attributes for each coupon. In contrast to previous proposals [CES+ 05], the number of coupons contained in a multi-coupon is not fixed, but is upper-bounded by kmax . Therefore, no inefficient step is required for issuing a fraction of the maximum number of coupons [Ngu06]. This is useful, for instance, to implement a personalized electronic discount booklet, where variable discounts are offered in certain order. The components of our construction are two instances of the CL signature scheme: CLS , for messages in [0, 2`m ), and CLS3 , for messages in [0, 2`m )3 . Setup(1κ ). The vendor V generates an instance of the CLS3 signature scheme: (CLS3 PK , CLS3 SK ) := ((a1 , a2 , a3 , b, c, n), p) ← CLS3 .Setup(1κ ), and the CLS signature scheme: (CLS PK , CLS SK ) := ((ˆ a, ˆb, cˆ, n ˆ ), pˆ) ← CLS .Setup(1κ ). We assume that CLS3 and CLS have the same parameters `n , `m , è , `, and `s . Additionˆ ∈R QR . ally, V generates two instances of the CS by computing g, h ∈R QRn , and gˆ, h n ˆ

39

4. Electronic Multi-Coupon Schemes These commitment schemes are only used in the PoKSigOnCommit protocol. Finally, V initializes a counter on sequence numbers: χsq ← 1, stores SK := (CLS3 SK , CLS SK ), pubˆ and creates an empty database DB of coupon lishes PK := (CLS3 PK , g, h, CLS PK , gˆ, h), identifiers. Common input: public keys CLS PK = (ˆ a, ˆb, cˆ, n ˆ ), CLS3 PK = (a1 , a2 , a3 , b, c, n), number of single coupons k, object identifiers obi , i = 0, . . . , k − 1 User’s input: − Vendor’s input: private keys CLS SK = pˆ, CLS3 SK = p User U sq0 , σ0′

Vendor V sq0 ← χsq ; χsq ← χsq + k + 1; σ0′ ← CLS .Sign(sq0 , CLS SK );

?

CLS .Verify(sq0 , σ0 , CLS PK ) = true for each i = 0, . . . , k − 1 do idi ∈R (0, 2ℓm ); ridi ∈R (0, 2ℓn ); i ridi ; Cidi ← aid 1 b end do;

Cid0 , . . . , Cidk−1 for each i = 0, . . . , k − 1 do σi ← SigOnCommit{U(idi , ridi ) : V(CLS3 SK )}(Cidi , obi , sqi ) sqi+1 ← sqi + 1; end do;

sqi+1 ← sqi + 1;

Figure 4.4.: Issue protocol for multi-coupons with fixed order of redemption.

Issue. In this protocol (Figure 4.4) the user U interacts with the vendor V to obtain k coupons with objects ob i , for 0 ≤ i < k. First, V chooses a new sequence number sq 0 ← χsq , updates the counter χsq ← χsq +k+1, computes σ00 ← CLS .Sign(sq 0 , CLS SK ), and sends both sq 0 and σ00 to U. Then, U randomly chooses k coupon identifiers id i , for 0 ≤ i < k, and commits to them by computing the commitments Cid i , which are sent to V . Afterwards, for each i, 0 ≤ i < k, U executes the SigOnCommit protocol to obtain a CLS3 signature σi on (id i , ob i , sq 0 + i), where id i is kept blinded in Cid i , and ob i , sq 0 + i are known by the V . Notice that only the first coupon is redeemable. Redeem. In the redeem protocol (Figure 4.5) U selects her next unused redeemable sq 0 coupon (id i , ob i , sq i , σi , σi0 ) from her MC , commits to sq i via Csq i ← a3 i brsq i , Csq ← i 0 r sq a ˆ i ˆb sq i using the appropriate moduli n and n ˆ of the two signature schemes, and sends 0 id i , ob i , Csq i , and Csq to V . The vendor checks that id i is not in the database, and i 0 inserts it. Then, U proves that Csq i and Csq are commitments to the same sequence i number sq i . Then, U uses PoKSigOnCommit to prove in zero knowledge that she knows a CLS3 signature σi on the tuple (id i , ob i , sq i ) without disclosing σi . Additionally, U proves to V the knowledge of a CLS signature σi0 on sq i , without disclosing any useful 0 information about it to V . Finally, if every PoK succeeded, U obtains a signature σi+1 on

40

4.4. Our Multi-Coupon Scheme with Fixed Order of Redemption Common input: public keys CLS PK = (ˆ a, ˆb, cˆ, n ˆ ), CLS3 PK = (a1 , a2 , a3 , b, c, n), ˆ g, h for internal use of PoKSigOnCommit protocols bases gˆ, h, User’s input: single coupon (idi , obi , sqi , σi , σi′ ) Vendor’s input: private keys CLS SK = pˆ, CLS3 SK = p, data base DB for coupon ids User U ′ Csq i

Vendor V ln

′ rsq , rsqi i

∈R (0, 2 ); ′ ←a ˆsqi ˆbrsqi ;

i rsq i; Csqi ← asq 3 b

′ Csq , Csqi , idi , obi i r ˜′

sq ˜′

′ ′ ˜ i ˆ sqi PoKEqRep{(sq ˜ i , r˜sqi , sq ˜ ′i , r˜sq ) : Csq =a ˆsq b ∧ Csqi = a3 i br˜sqi ∧ sq ˜ i = sq ˜ ′i } i i r ˜′

′ ′ ˜ i ˆ sqi ′ ,σ PoKSigOnCommit{(sq ˜ i , r˜sq ˆsq b ∧ CLS .Verify(sq ˜ i, σ ˜i′ , CLS PK )} i ˜i ) : Csqi = a sq ˜

PoKSigOnCommit{(sq ˜ i , r˜sqi , σ ˜i ) : Csqi = a3 i br˜sqi ∧ CLS3 .Verify((idi , obi , sq ˜ i ), σ ˜i , CLS3 PK )}

check that idi is not in DB; sqi+1 ← sqi + 1; add idi to DB; ′ ′ ′ ′ a ˆ ; ← C Csq a ˆ; ← Csq Csq sqi i+1 i i+1 ′ ′ σi+1 SigOnCommit{U(sqi+1 , rsqi ) : V(CLS SK )}(Csqi+1 ) ←

Figure 4.5.: Redeem protocol for multi-coupons with fixed order of redemption.

sq i+1 := sq i + 1, i.e., her next coupon becomes redeemable. In the description above, it is assumed that U always outputs rej in case any obtained signature is invalid. Similarly, V must output rej in case any PoK fails.

4.4.3. Security Proofs In this section we present a number of theorems stating the properties of our scheme. Theorem 4.4.2. The MCS proposed in Section 4.4.2 is correct. The correctness of the scheme follows from its definition and from the correctness of its building blocks (proof omitted). Theorem 4.4.3. The MCS proposed in Section 4.4.2 is unsplittable. Proof (Sketch). Assume A is an adversary against unsplittability. It is possible to construct an algorithm B, which outputs a forgery to one of the signatures CLS3 or CLS with at least half the success probability of A (minus some negligible term). B simulates the interface I1 , and must answer the queries made by A. The only steps which B cannot trivially simulate are those which require the generation of a signature. To accomplish this he has black box access to A, and access to two signature oracles CLS3 .Sign(·, CLS3 SK ) and CLS .Sign(·, CLS SK ) (for two randomly chosen secret keys CLS3 SK and CLS SK unknown to B). Each time B must sign a message sq 0 in clear, he simply queries the CLS oracle.

41

4. Electronic Multi-Coupon Schemes The execution of the SigOnCommit protocol, in both the issue and redeem procedures, can be simulated towards A as described in the proof of [CL02, Lemma 6.1], where the actual signature computation is outsourced to the corresponding signature oracle. Because of the soundness of every zero-knowledge PoK in the Issue and Redeem protocols, we can assume that during the protocol executions, B can extract (by using rewinding) all the witnesses for each PoK from A. This allows B to obtain the attributes of all coupons, both issued and redeemed. It is possible to prove that the number of unused redeemable coupons provided to A in the unsplittability game is at most ctr M (here it is important that B updates the counter χsq to avoid signing the same sequence number twice). In the last part of the unsplittability game A is able to redeem ctr M +1 coupons. Hence B is able to extract from A the information of ctr M + 1 redeemable coupons (id i , ob i , sq i , σi , σi0 ), for 0 ≤ i ≤ ctr M . In particular, at least one of these coupons has a signature σi on (id i , ob i , sq i ) or σi0 on sq i , which was not queried to the respective signature oracle and therefore is an existential forgery of one of the signature schemes. In order to identify the forgery, B stores every signature-message pair queried to the signature oracles. Theorem 4.4.4. The MCS proposed in Section 4.4.2 is unforgeable. Proof. The theorem trivially follows from Theorems 4.4.1 and 4.4.3. Coupon objects are useful features that unavoidably come at a price: they can be trivially used by the vendor to link protocol runs (e.g. by assigning unique coupon objects to each user). Hence, our construction does not meet unlinkability as in Definition 4.4.3. However, in practice, if there are many redeemable coupons at any time for each possible coupon object, then this information by itself does not substantially harm privacy. Theorem 4.4.5. The MCS of Section 4.4.2 restricted to constant coupon objects is unlinkable. Proof (Sketch). Without loss of generality, assume we can guess the users U0 and U1 challenged by A. The proof is based on the existence of simulators for each one of the proofs of knowledge employed in the protocols, and can be organized as a sequence of games [Sho04]. We can construct a series of modified games from the unlinkability game, by substituting, one by one, every PoK and every commitment used in the Issue and Redeem protocols executed by the users U0 and U1 . The hiding property of the commitment scheme can be used to replace the commitments by random values. In each transition, the adversary’s success probability is modified only by a negligible amount. In the last game, the adversary’s view regarding the users U0 and U1 is completely simulated, thus his success probability is exactly 1/2. This implies that his linkability advantage for the original game is negligible. Complexity and Extensions. The computation and communication complexity of the issue protocol is linear in k, while the redemption complexity is constant in k. This improves the complexity of the scheme in [CES+ 05], which is linear for both issue and redeem, but is less efficient than the scheme in [Ngu06], which has constant complexity for both protocols. However, for many applications the scheme in [Ngu06] is less practical than ours, because it lacks specific attributes per coupon, and it only offers weak unsplittability.

42

4.5. MCS with Arbitrary Redemption for Federated Environments It is possible to extend the scheme by adding additional attributes to each coupon. For instance, we can easily implement validity periods by adding two attributes t a and t b , such that a coupon is only valid if a publicly known time variable belongs to the interval [t a , t b ]. Furthermore, by using standard zero-knowledge interval protocols [Bou00], it is possible for a user to prove that the coupon is valid at some precise date/time, without disclosing either t a or t b . Note that this has a similar effect on unlinkability as coupon objects.

4.5. Our Multi-Coupon Scheme with Arbitrary Order of Redemption for Federated Environments In this section, we generalize the security framework from Subsection 4.4.1 (in Subsection 4.5.1) to a federation of vendors, supporting an arbitrary order of redemption of individual coupons. We propose a cryptographic scheme (in Subsection 4.5.2) for this model and prove the security (in Subsection 4.5.3) with respect to the generalized security framework.

4.5.1. Model and Security Framework Our model for multi-coupon schemes with arbitrary order of redemption for federated environments generalizes the model from Section 4.4.1. 4.5.1.1. Components of a General Federated MCS Generalizing the model from Section 4.4.1, the involved parties are a set of vendors V and a set of users U, where nV = |V| denotes the number of vendors in the federation. We will refer to any particular user simply by U, and V , V 0 will denote particular vendors. We assume that each vendor V has a unique identity IDV which is publicly known. Common system parameters for the cryptographic building blocks (like commitment and signature schemes) will be omitted in the notation for better readability. Definition 4.5.1 (Multi-Coupon Scheme). A multi-coupon scheme (MCS) for a federation of vendors V consists of a set of protocols and algorithms {Setup, Issue, Redeem, Claim}: Setup algorithm. (PK , {SK Vi }1≤i≤nV ) ← Setup(1κ , nV ) is the (in general, distributed) initialization algorithm executed by the vendors once to generate one instance of the MCS , where κ is the security parameter, nV is the number of vendors. It outputs a public key PK (which includes 1κ and kmax , the maximum allowed number of coupons per MC ), and a set of secret keys {SK Vi }1≤i≤nV .The vendors’ states are initialized to the empty string. Issue protocol. In order to obtain an MC with k coupons, U performs the following protocol with a vendor V : ((resu , M ), resv ) ← (Issueu (k, V , PK , ob 0 , . . . , ob k−1 ), Issuev (k, SK V , ob 0 , . . . , ob k−1 )) where, from now on, the subindices u and v denote user and vendor algorithms, respectively. The common input ob 0 , . . . , ob k−1 specifies coupon objects (individual attributes) for the k individual coupons in the MC that is to be issued. The output flags resu , resv ∈ {acc, rej} indicate success or failure. Issueu outputs resu and a multi-coupon M , whereas Issuev only outputs resv .

43

4. Electronic Multi-Coupon Schemes Redeem protocol. A multi-coupon M (issued by V ) is redeemed to V 0 via the protocol ((resu , M 0 ), (resv , crn, ob, π, s0 )) ← (Redeemu (M , m, PK ), Redeemv (s, SK V 0 )). The parameters to Redeemu are the multi-coupon M from which the user wants to redeem a coupon, a specification m of the coupon to be redeemed3 , and the public key PK of the MCS . The vendor algorithm takes the vendors’ state s and the private key of the redeeming vendor SK V 0 as input. Redeemu outputs an updated multi-coupon M 0 and a flag resu just like in Issue, and Redeemv outputs a new state s0 of the vendors, a unique coupon reference number crn, an object ob, a proof π that a user redeemed a coupon to V 0 (with reference number crn and object ob, issued by V ), and a flag resv . Claim algorithm. To verify that a coupon with reference number crn issued by V has indeed be redeemed to vendor V 0 , the (public) algorithm Claim can be run to verify a proof π, i.e., res ← Claim(crn, ob, π, V 0 , V ). The result res is true if π proves that V issued a coupon with object ob that was redeemed to V 0 with reference number crn; otherwise, res is false. crn is used to identify a redeemed coupon, i.e., it can be noticed, when the same redeemed coupon is claimed twice.

Correctness (informal). Any MCS must fulfill the correctness requirement: if all participants in the protocol are honest, each individual coupon from each MC that was issued by any vendor can be redeemed successfully at any vendor (equal to or different from the issuer), regardless of the order of redemption, i.e., a user can redeem any coupon that she hasn’t spent yet at any time.

4.5.1.2. Security Framework Here, we generalize the adversarial model from Section 4.4.1 to a federation of vendors. The security requirements are defined by games, and it can be shown that our scheme meets these requirements (see Section 4.4.3). An adversary is a p.p.t. algorithm A, which can play the role of either a collusion of vendors and users, or only of a group of users. Without loss of generality, we let the adversary be specified by a sequence of algorithms (e.g., A := (A1 , A2 , A3 )). Honest parties are assumed to communicate over secure channels. We consider two types of users (resp. vendors): honest and corrupted users (resp. vendors). Users (resp. vendors) belonging to the set of honest users (resp. vendors) execute algorithms of the MCS if requested by A, but remain honest otherwise. A has full control over the corrupted users and vendors, and he is provided with their previous protocol views. Similar to [KTY04], we allow A to interact with the system through a set of queries4 handled by an interface, which partially simulates the MCS , executes protocols with A, and records certain user’s or vendor’s activities. Note that the interfaces do not restrict A in any way – they control the actions of the honest parties on behalf of A. Correctness of the scheme can be easily verified (proof omitted). 3

4

44

Details depend on the scheme; e.g., m could be the index in a list of all coupons in a multi-coupon or an ID. Like in existing schemes, queries must not be executed concurrently, which simplifies model and construction.

4.5. MCS with Arbitrary Redemption for Federated Environments 4.5.1.3. Framing resistance and claimability. During the redemption protocol, the original issuer of the coupon must be identifiable (to allow the redeeming vendor to claim money from the issuer), and other vendors must be protected from false claims. It must be ensured that a vendor who issued an MC can always be held responsible for all coupons from this MC . We break down this property into two requirements: (1) framing resistance: a collusion of vendors and users must never be able to claim that another vendor issued a coupon with a specific object, when he didn’t; and (2) claimability: an honest vendor who redeemed a coupon must always be able to claim money for it. Interface I1 . In the games defining “claimability” and “framing resistance”, the adversary A plays the role of a coalition of all users and has the capability to corrupt vendors. Counters ctr CV ,ob (initially 0) for each coupon object ob are defined for each vendor V , counting the coupons with object ob, that were issued by V . The following queries are provided to A. I1 .Issue v (V , k, ob 0 , . . . , ob k−1 ). If k ∈ [1; kmax ] and V is an honest vendor, the Issue v algorithm is executed. The counter for each coupon object ob is increased by the number of times ob occurs in the MC issued by V , i.e., ∀λ ∈ [0; k − 1] : ctr CV ,ob λ ++. I1 .Redeem v (V 0 , V ). If V 0 is an honest vendor, the Redeem v protocol is executed for V 0 , i.e., A wants to redeem a coupon (issued by V ) to V 0 . I1 .Corrupt(V ). A receives all secrets of V (and V is removed from the set of honest vendors). In the FrameGame (see Fig. 4.6), A can interact with the system via the interface I1 . A outputs the identity V of the vendor he wants to “frame” (in order to win this game, A has to choose an uncorrupted vendor), an object ob, and a set of coupon reference numbers CRN with a corresponding set Π of pairs (π, V 0 ) of proofs that V 0 was involved in the redemption of a coupon with object ob issued by V . If Claim succeeds for all of these proofs and there are more elements in CRN than coupons (with object ob) issued by V (i.e., |CRN | > ctr CV ,ob ), A wins the game, because then A must be able to claim coupons V did not issue. (Of course, all elements of the set must be distinct – i.e., A cannot “replay” the same crn multiple times). FrameGame(A, κ, nV ): (PK , {SK Vi }1≤i≤nV ) ← Setup(1κ , nV ); (V , ob, CRN , Π) ← AI1 (1κ , PK ); if V uncorrupted ∧ |CRN | > ctr CV ,ob ∧ (∀crn ∈ CRN : ∃(π, V 0 ) ∈ Π : Claim(crn, ob, π, V 0 , V ) = true) return broken; else return unbroken;

ClaimGame(A, κ, nV ): (PK , {SK Vi }1≤i≤nV ) ← Setup(1κ , nV ); (V 0 , V , sA ) ← AI11 (1κ , PK ); if V 0 corrupted return unbroken; (Res A , (resv , crn, ob, π, s0 )) ← (A2 (sA ), I1 .Redeem v (V 0 , V )); if (resv = acc ∧ Claim(crn, ob, π, V 0 , V ) = false) return broken; else return unbroken;

Figure 4.6.: The games FrameGame and ClaimGame.

45

4. Electronic Multi-Coupon Schemes SplitGame(A, κ, nV ): (PK , {SK Vi }1≤i≤nV ) ← Setup(1κ , nV ); I0

(s, V , Vj00 , . . . , Vj0K ) ← A11 (1κ , PK ) if K < ctr MV return unbroken; for λ ← 0 to K do: (resA , resv ) ← (A2 (s), I10 .Redeem v (V , Vj0λ )); if (resv 6= acc) return unbroken; return broken;

Figure 4.7.: The game defining unsplittability (SplitGame), where I10 is the interface I1 without Corrupt queries. Definition 4.5.2 (Framing resistance of an MCS ). An MCS is resistant against framing if there is no p.p.t adversary A that can win the FrameGame in Fig. 4.6 (i.e., FrameGame(A, κ, nV ) = broken for some number of vendors nV ≥ 1) with non-negligible probability (in κ). To break the ClaimGame(see Fig. 4.6), A successfully redeems a coupon to an uncorrupted vendor V 0 , but V 0 cannot claim money for it (i.e., the Claim algorithm fails). In the first phase, A1 can interact arbitrarily with the honest vendors via I1 . He must output an issuer V of a coupon (possibly corrupted) and an uncorrupted vendor V 0 , and an arbitrary state sA for the second phase. To win the game, A2 must be able to redeem a coupon, allegedly issued by V , to V 0 , but Claim must fail for this coupon. A2 ’s output Res A is discarded. Definition 4.5.3 (Claimability of an MCS ). An MCS is claimable if there is no p.p.t adversary A := (A1 , A2 ) that can win the ClaimGame in Fig. 4.6 (i.e., ClaimGame(A, κ, nV ) = broken for some number of vendors nV ≥ 1) with probability > 0. 4.5.1.4. Unforgeability and unsplittability. No coalition of users should be able to redeem more coupons than have been issued by the vendors. Moreover, multi-coupons should be unsplittable (cf. [CBL+ 07]): We require that if a user U0 shares an MC with a user U1 , as soon as one user redeems a single coupon, the other one cannot redeem any more without interacting with the user who redeemed first (note that sharing can always be achieved by copying all the data). In the games, we have to restrict the queries that are available to A: he is not allowed to corrupt vendors, because a vendor could issue as many coupons as he likes – and hence “unforgeability with corrupted vendors” would make no sense. Moreover, we consider unsplittability to be a requirement of the entire federation. Therefore, we do not need to model corruptions: We assume that in the games defining unforgeability and unsplittability, all users but no vendors are corrupted. Furthermore, we have to count the difference between the coupons (separately for each object ob) a vendor V issued, and the number of coupons (issued by V , with ob) that were already redeemed, i.e., the number of coupons issued by V with object ob that are available to the adversary. Thus, a counter ctr DV ,ob (initially 0) is introduced for

46

4.5. MCS with Arbitrary Redemption for Federated Environments each issuer V , which is increased during issue, and decreased after a successful Redeem (possibly at a different vendor V 0 ). For the definition of unsplittability, it is important to know how many MC s issued by V that still contain redeemable coupons the users may have. In an unlinkable MCS , this cannot be done precisely; therefore, the MC counter ctr MV (initially 0) is just an upper bound on the users’ MC s (with valid redeemable coupons). To count the MC s the users might have, ctr MV is increased by one whenever V issued a coupon. After successful redemption, the MC counter is adjusted if the number of coupons issued by V that are still available to A is smaller than the number of MC s (issued by the same vendor): ctr MV ← min(ctr MV , ctr DV ). Interface I10 . The modified interface I1 without Corrupt queries, but with counters ctr MV and ctr DV ,ob is denoted by I10 . Intuitively, to win the splittability game (see Fig. 4.7), A has to create more (in the game: K + 1) “shares” than he has MC s (at most ctr MV ≤ K), which can be redeemed independently from each other. The state of A2 is reset after each Redeem to the state s that was output by A1 ; i.e., information gained in one execution of Redeem is not available in the other executions. Definition 4.5.4 (Unsplittability of an MCS ). An MCS is unsplittable if there is no p.p.t adversary A that can win the SplitGame in Fig. 4.7 (i.e., SplitGame(A, κ, nV ) = broken for some number of vendors nV ≥ 1) with non-negligible probability (in κ). In the unforgeability game, the adversary A can interact with the system via I10 , and he has to output the identity of an arbitrary vendor, an object ob of his choice. If more coupons (with object ob) issued by this vendor have been redeemed than the vendor originally issued (i.e., ctr DV ,ob < 0), A wins. We omit the formal definition of unforgeability, which is analogous to the definition of unsplittability. 4.5.1.5. Unlinkability. To ensure privacy and anonymity of the customers, we require that the vendors should not be able to link a Redeem procedure of a customer to the corresponding Issue procedure, nor to another Redeem procedure where the customer used the same MC . Unlinkability for one user has to be provided against a collusion of vendors and other users. In the unlinkability game (see Fig. 4.8), the adversary A can play colluding users and vendors – and yet, transactions of an honest user have to be unlinkable. Two users (chosen by A) have to be uncorrupted, and in a random order, each user redeems one coupon (specified by A). If A can guess which user redeemed first with a probability greater than 1/2, he wins the game. It has to be ensured that both users use MC s issued by the same vendor, that either both coupons are still available or both already spent, and that both coupons have the same object. Otherwise, A could use such information to trivially link the users. Moreover, either both redemptions must succeed, or both must fail. Interface 2 (I2 ). As we assume all vendors are corrupted, we only need to specify queries where the interface invokes Issue and Redeem for honest users. We do not model corruption of users, because this does not weaken the model: A could not gain anything, since the users are completely independent from each other, and A could just simulate honest users by himself.

47

4. Electronic Multi-Coupon Schemes The interface I2 has to maintain data structures describing the multi-coupons each (honest) user holds: ctr U (initialized to 0) counts the number of MC s that were issued to user U. ILU is the list of vendors that issued the MC s, and arrays of boolean values CLU [i, j] are used to describe if the j-th coupon in the i-th MC issued to U is already redeemed or not. The objects of all coupons that have been issued to U are stored in a two-dimensional array: OLU [i, j] (initially 0) holds the object of the j-th coupon in U’s i-th MC (issued by vendor ILU [i]). I2 .Issue u (U, k, V , ob 0 , . . . , ob k−1 ). If user U is uncorrupted, the interface runs the Issue u algorithm on behalf of U, for issuer V . If the algorithm succeeds, the multi-coupon data of U is updated: ILU [ctr U ] ← V ; ∀λ ∈ [0; k − 1] : (CLU [ctr U , λ] ← 1; OLU [ctr U , λ] ← ob λ ; ) ctr U ++. I2 .Redeem u (U, α, β, V 0 ). If user U is honest, the Redeem u algorithm is run on behalf of U to redeem the coupon number β from multi-coupon number α at vendor V 0 (unless CLU [α, β] = 0). The interface updates the list to remove the coupon that was spent: CLU [α, β] ← 0. LinkGame(A, κ, nV ): (PK , {SK Vi }1≤i≤nV ) ← Setup(1κ , nV ); (U0 , U1 , α0 , β0 , α1 , β1 , V 0 , sA ) ← AI12 (κ, PK ); if U0 corrupted ∨ U1 corrupted ∨ ILU0 [α0 ] 6= ILU1 [α1 ] ∨ CLU0 [α0 , β0 ] 6= CLU1 [α1 , β1 ] ∨ OLU0 [α0 , β0 ] 6= OLU1 [α1 , β1 ] return unbroken; c ∈R {0, 1}; s0 , (resUc , MU0 c ) ← (I2 .Redeem u (Uc , αc , βc , V 0 ), A2 (sA )); A s00A , (resU1−c , MU0 1−c ) ← (I2 .Redeem u (U1−c , α1−c , β1−c , V 0 ), A2 (s0A )); b ← AI32 (s00A ); if (b = c) ∧ (resU0 = resU1 ) return broken; else return unbroken;

Figure 4.8.: The game defining unlinkability. Definition 4.5.5 (Unlinkability of an MCS ). An MCS is unlinkable if there is no p.p.t adversary A := (A1 , A2 , A3 ) that can win the LinkGame in Fig. 4.8 with non-negligible advantage (i.e., Advlink (A, κ, nV ) = Pr[LinkGame(A, κ, nV ) = broken] − 1/2 must be non-negligible in κ for A to win, for some nV ≥ 1).

4.5.2. Our Federated Multi-Coupon Scheme In this section, we present our unsplittable privacy-preserving multi-coupon scheme for federated environments, supporting redemption of coupons in an arbitrary order. 4.5.2.1. Our Construction for Federated Environments Overview. A multi-coupon M of size k ≤ kmax consists of its identifier mid , a freshness identifier fid , a signature σ 0 on the pair (fid , mid ), and a list of k individual coupons, where kmax is the maximal number of coupons an MC can contain. Each individual

48

4.5. MCS with Arbitrary Redemption for Federated Environments coupon (id , ob, σ) is specified by a coupon identifier id , a coupon’s object ob (i.e., the good or service represented by the coupon5 ), and a signature σ on the tuple (id , ob, mid ). Depending on the business model, the object IDs in an MC could either be chosen by the user, or they could be determined by the issuer. We model object IDs as common input to the issue protocol, leaving this decision to the concrete application. We require that all signatures and non-interactive proofs in the protocols are always verified by the recipient. If the verification fails, the protocol is aborted, and the respective party outputs rej (subsequently, verification steps will be omitted). All public keys and parameters for the underlying protocols are known to all participants in the scheme (e.g., the federation of vendors could maintain a server with a directory of all public keys). The coupon reference number crn from our formal definitions is implemented by a unique ID id i for each individual coupon. Setup. For the setup of the MCS , the vendors have to create keys6 : one common CLS2 key pair (PKFed , SKFed ) for the federation, where all vendors know the private key, and one CLS3 key pair (PKV , SKV ) for each individual vendor V . Moreover, the vendors have to create two empty common databases DB (for coupon IDs) and DB 0 (for freshness IDs), where all vendors can create new entries (of course, this can be implemented by two tables in one database). Every vendor is allowed to insert entries into the databases, but no vendor is allowed to delete them. DB possesses a key pair (PKDB , SKDB ) of an arbitrary signature scheme, e.g., RSA, to issue certificates to vendors which inserted coupon IDs. Remark. In this instantiation, the public key mentioned in Def. 4.5.1 consists of PKFed and PK Vi ; the secret key from Def. 4.5.1 includes SKFed and SK Vi . Issue. The Issue protocol is shown in Fig. 4.9. In step 1, the multi-coupon identifier mid is selected by the vendor, whereas the freshness ID fid 0 and IDs for the individual coupons id i are chosen by the user. The vendor only obtains commitments Cfid 0 , Cid 0 , . . . Cidk−1 to the values chosen by the user. In step 2, the user receives a signature σ00 on (mid , fid 0 ) with the secret key of the federation SKFed , and in step 3, he obtains signatures Signi on (Cid i , mid , ob i ) with the signing key SKV of the issuer. Redeem. The Redeem protocol for the (j + 1)-th redemption from a multi-coupon, where 0 ≤ j ≤ k − 1, is shown in Fig. 4.10. During the first Redeem from a multi-coupon (i.e., j = 0), the freshness ID fid 0 and corresponding signature σ00 from Issue is used and updated; in subsequent redemptions, the freshness ID and signature from the previous execution of Redeem are used and updated. In step 1, the user blinds mid by commitments (otherwise, the vendor could use mid to link transactions), and sends the data of the coupon he wants to redeem (id i , ob i , fid j ), together with the ID of the issuer IDV , to the vendor V 0 . In step 2, U proves that the two commitments to mid are actually commitments to the same number. In step 3, the user proves knowledge of the signature Signi, and the vendor obtains a signature of knowledge π 0 that allows him later to prove that this coupon was redeemed to him. In step 4, the user proves knowledge of a signature σj0 on (fid j , mid ). The vendor has to verify that both id i and fid j are fresh by querying the databases (i.e., he checks that these values are not yet in DB and DB 0 ), and inserts these entries. After 5 6

The vendors must publish an encoding of coupon’s objects as integers. We do not use group signatures, because coupon issuers should be identifiable.

49

4. Electronic Multi-Coupon Schemes Common input: public keys PKV = (a1 , a2 , a3 , b, c, n), PKFed = (ˆ a1 , a ˆ2 , ˆb, cˆ, n ˆ ), number of single coupons k, object identifiers obi , i = 0, . . . , k − 1 User’s input: − Vendor’s input: private keys SKV = p, SKFed = pˆ User U

Vendor V

Step 1: fid 0 ∈R (0; 2`m ); rfid 0 ∈R (0; 2`n ); fid Cfid 0 ← a ˆ1 0 ˆbrfid 0 ;

mid

mid ∈R (0; 2`m );

for each i = 0, . . . , k − 1 do

idi ∈R (0; 2`m ); ridi ∈R (0; 2`n ); i rid i Cid i ← aid ; 1 b end for; Step 2: σ0 0

←

Cfid 0 , Cid 0 , . . . , Cid k−1

SigOnCommit{U (fid 0 , rfid 0 ), V (SKFed )}(Cfid 0 , mid )

Step 3: for each i = 0, . . . , k − 1 do σi ← SigOnCommit{U (id i , rid i ), V (SKV )}(Cid i , mid , ob i ) end for; return (mid , fid 0 , σ00 , {(idi , σi )}0≤i ctr CV ,ob in the FrameGameensures that there are more distinct coupon IDs id i than signatures for coupons with object ob have been queried by V . Therefore, one of the NI-SoKs π does not correspond to a coupon issued by V and A must have produced a forgery of a CL signature. B can identify the forgery using the data stored during Issue, and outputs it as the required existential forgery of a CLS3 signature. Of course, this only works, if the vendor challenged by the adversary is actually the vendor V guessed by B at the beginning of the simulation.

52

4.5. MCS with Arbitrary Redemption for Federated Environments Since the probability of an adversary to forge a CL signature is negligible, so is the probability of A to win the FrameGame. Theorem 4.5.2. The MCS of Section 4.5.2 provides claimability, i.e., for all p.p.t adversaries A and for all nV ≥ 1, Pr[ClaimGame(A, κ, nV ) = broken] = 0. Proof (sketch). The checks in the Claim algorithm are a subset of the checks performed in Redeem by the vendor. Therefore, the condition in the ClaimGame is a contradiction (i.e., the adversary A can never win). 4.5.3.3. Unsplittability Theorem 4.5.3. Assuming the security of CL signatures against existential forgery, the MCS of Section 4.5.2 is unsplittable, i.e., for all p.p.t adversaries A and for all nV ≥ 1, the probability Pr[SplitGame(A, κ, nV ) = broken] is negligible (in κ) in the random oracle model. Proof (sketch). We show unsplittability by reduction, similar to the reduction in the proof of Theorem 4.5.1: Assuming an adversary A against SplitGame, we construct an adversary B against the security of the CL signature scheme (i.e., B will produce an existential forgery of a CL signature). B has to simulate the interface I10 , and play the SplitGame with A. To do so, B has black-box access to two signature oracles: one for CLS2 , and one for CLS3 (these oracles can be used in the simulation because vendors cannot be corrupted). If A wins the game, B has to come up with an existential forgery of one of the signature schemes. With the help of the signature oracles, B can simulate everything required by I10 towards A. [CL02] shows how to simulate the SigOnCommit protocol (see the proof of Lemma 6.1). To compute signatures, B queries the corresponding oracle. B stores all message-signature pairs in order to identify forgeries. The non-interactive version of the protocol can also be simulated: For this to succeed, B just selects a random challenge to create NI-SigOnCommit and later (when A wants to verify the non-interactive proof) patches the random oracle accordingly. Because of the soundness of the ZK-PoKs in the Issue and Redeem protocols, we can assume that B can extract all witnesses for each PoK from A (the existence of efficient knowledge extractors for the sub-protocols we use is shown in [CL02]). Thus, B obtains all secrets from all coupons, which are used by B to identify the forgery. Note that although rewinding is used for the knowledge extraction, B is still efficient, because each sub-protocol can be rewound independently from the previous ones. In the SplitGame, A has to output an issuer V he wants to challenge. To win the game, A must redeem more coupons than he still has multi-coupons left from the coupons issued to him by V (the counter ctr MV in I10 keeps track of this number). B can extract the contents of ctr MV + 1 coupons (for which the redeem protocol with a vendor simulated by B succeeded). In particular, B can extract all the signatures. Since “replaying” is prevented by the databases in the Redeem protocol, B can extract ctr MV + 1 different CLS2 signatures on pairs (fid , mid ), and ctr MV + 1 corresponding CLS3 signatures. But ctr MV is an upper bound on the number of multi-coupons the adversary holds, thus either a CLS2 signature was forged (which can be detected, since the corresponding pair

53

4. Electronic Multi-Coupon Schemes (fid , mid ) was not signed by the oracle), or a CLS3 signature was forged (which can also be identified by the extracted secrets). That one of these cases must occur can be seen as follows: Breaking the SplitGamewithout forging a CLS2 signature is only possible, when the counter ctr MV has been decreased at least once – only in this case, there are more CLS2 signatures with a fid which is not in the database that were created by the oracle than ctr MV . But ctr MV is only decreased when so many single coupons have been spent that at least one MC must be empty – which means there are not enough CLS3 signatures created by the oracle (on coupons with a mid with a valid freshness signature) to break the SplitGame. Hence in this case, a CLS3 signature must be forged. B outputs a signature that was not created by the oracle: it must be an existential forgery of one of the signature schemes. 4.5.3.4. Unforgeability It can be shown that our scheme is unforgeable by a reduction similar to the one above. But in this case, the counter ctr DV ensures that there is a forgery of a CLS3 signature. Note that unsplittability can be broken by forging a CLS2 signature or a CLS3 signature, whereas to break unforgeability, an adversary has to forge a CLS2 signature. Theorem 4.5.4. Assuming the security of CL signatures against existential forgery, the MCS of Section 4.5.2 is i.e., for all p.p.t adversaries A and for all nV ≥ 1, Pr[ForgeGame(A, κ, nV ) = broken] is negligible (in κ) in the random oracle model. Because of the similarity of the proof of unforgeability and the proof of unsplittability, we do not give a full prove here. Proof (idea). It can be shown by a reduction (very similar to the one used to prove unsplittability of the scheme) that the security of the CL signatures against existential forgery implies unforgeability of our scheme. The main difference is that here the existential forgery is not necessarily a CLS2 signature, it could also be a CLS3 signature. 4.5.3.5. Unlinkability Informally, unlinkability is achieved because the vendor’s knowledge about elements of a single coupon depends on the actual procedure. During Issue, id and fid 0 are hidden, whereas mid , σ, σ00 are known to the vendor. During Redeem, id and fid 0 are disclosed to the vendor, but mid , σ, σ00 are hidden. fid j (0 ≤ j < k) is hidden from the vendor during the j-th run of Redeem, but disclosed during the (j + 1)-th run; σj0 (0 ≤ j < k) is known to the vendor during the j-th run of Redeem, but hidden during the (j + 1)-th run. The objects ob are known to the vendor during both Issue and Redeem. To prove that our scheme fulfills the unlinkability requirement defined in Figure 4.8, we have to assume that the vendors cannot use the coupon objects as “fingerprints” in order to link different transactions: If a certain coupon object is unique to a user, this could be used for linking. Hence, the definition of LinkGame excludes “trivial linking” by objects. In practice, we assume that there is only a small number of different objects, but a large number of users. Thus, for each object, there should be several users who possess coupons with that object. Hence, privacy should be preserved, for practical purposes.

54

4.6. Conclusion and Future Work Theorem 4.5.5. The MCS of Section 4.5.2 is unlinkable, i.e., for all p.p.t adversaries A and for all nV ≥ 1, Advlink (A, κ, nV ) is negligible (in κ) in the random oracle model. Proof sketch. Our proof is organized as a sequence of games [Sho04] and uses the simulators in the random oracle model for each one of the PoKs, NI-PoKs, and NI-SoKs employed in the protocols. We construct a series of modified games from the unlinkability game in Figure 4.8, by substituting each PoK, each NI-PoK, and every commitment used in the Issue and Redeem protocols executed by honest users. The hiding property of the commitment scheme is used to replace the commitments by random values. In each transition, the adversary’s success probability is modified only by a negligible amount. In the last game, the adversary’s view regarding the users U0 and U1 is completely simulated (in the random oracle model), thus his success probability is exactly 1/2 (i.e., his linkability advantage is 0). This implies that his linkability advantage for the original game is negligible.

4.6. Conclusion and Future Work In this chapter, we introduced privacy-protecting multi-coupon systems, which improve on previous proposals with regard to various aspects: better efficiency than [CES+ 05], weaker assumptions than [Ngu06], and stronger security requirements. In particular, we provide an improved security model with a stronger definition of unsplittability, which discourages sharing of multi-coupons without relying on the all-or-nothing principle. Unlike alternative approaches, our schemes do not encode valuable information into the coupons to dissuade users from sharing them. Therefore, they can be considered more privacy-friendly. Moreover, they can be extended with additional attributes such as validity periods. In addition, we generalized our security model for multi-coupon schemes to a federation of cooperating vendors. We designed an efficient scheme for this setting where coupons can be redeemed in arbitrary order, and which is provably secure in this model. Future work may focus on dynamic aspects of multi-coupon schemes, considering the case where vendors join and leave the federation. A further topic could be the design of more efficient schemes, in particular for special cases (e.g., without the support for coupon attributes, or for just a small number of attributes).

55

56

5. Cryptographic Protocols for Property-Based Attestation In this chapter, we present two cryptographic protocols for property-based attestation. The material in this chapter has been published in [CLL+ 06] and [CLMS08].

5.1. Introduction and Background A fundamental issue in interaction between computing platforms is “trust” or “trustworthiness” – whether a remote platform behaves in a reliable and predictable manner, or will be (or already has been) subject to subversion. Cryptographic mechanisms support the establishment of secure channels and authorized access, but without assurance about the integrity of the communication endpoints. Commodity computing platforms suffer from inherent vulnerabilities due to high complexity, and lack of efficient protection against tampering or malware. Hence, an important subject of current research is to develop mechanisms for gaining assurance about the trustworthiness of remote peers regarding their integrity, platform configuration, and security policies. As explained in Chapter 3, the concept of Trusted Computing aims at resolving such issues. TCG binary attestation. One of the main features supported by the TPM is the so-called trusted integrity measurement: As described in Section 3.3, a hash value of the platform state is computed during the boot process and stored in specific registers of the TPM, the Platform Configuration Registers (PCRs),those state is also called the platform’s configuration. Of potential interest is the offered functionality called binary attestation, which allows a remote party (verifier) to get an authentic report about the binary configuration of another platform (prover), given by the prover’s TPM signature on the configuration. Deficiencies of TCG binary attestation. TCG binary attestation suffers from several shortcomings: The slightest change in the measured software or configuration files – whether security-relevant or not – will lead to a changed binary configuration. In general, it is not clear, how a verifier should derive the trustworthiness of a platform from such a binary value. System updates and backups are highly non-trivial; the multitude of different versions of many pieces of software cause serious manageability problems. From the privacy point of view, binary attestation bears several risks: (1) The TPM’s public key needed to verify an attestation could be used to identify a TPM and trace a platform. To solve this problem, Brickell et al. [BCC04] introduced the Direct Anonymous Attestation (DAA) protocol (cf. Section 3.3.5). Improvements of DAA and alternative DAA schemes (e.g., [BL07, BCL08, Cam04]) are orthogonal to our work and could be used as a building block for our protocol. (2) Typically the information about the configuration of a computing platform or application is revealed to a remote party requesting the state of

57

5. Cryptographic Protocols for Property-Based Attestation a platform. This information can be misused to discriminate against certain configurations (for example, operating systems) and even vendors, or may be exploited to mount attacks. Property-based attestation. One general concept to overcome shortcomings of the TCG’s binary attestation is to transform the binary attestation into the property-based attestation (PBA), as described by Sadeghi and St¨ uble [SS04], and by Poritz et al. [PSVW04]. The basic idea of PBA requires a computing platform to attest that it fulfills the desired (security) requirements, so-called ‘properties’, without revealing a respective software or/and hardware configuration. The formal definition of properties as well as the development of various practical solutions for PBA are still active areas of ongoing research. Our contribution. In this chapter, we propose two cryptographic protocols for PBA: a delegation-based protocol that relies on a third party to issue property-configuration certificates, and a protocol without trusted third party (TTP). We also propose system models and prove the security of our schemes in these models. Both protocols require an additional TPM command (the same one for both schemes) that enables the TPM to sign a cryptographic commitment on PCR values. Note that the TPM supports all operations and functionalities required for such a command, i.e., it could be implemented in a firmware update. However, the TPM specification would have to be extended. Our first solution (published in [CLL+ 06]) requires an off-line TTP to publish a list of trusted configurations and respective certificates which attest that the configurations provide specific properties. A prover can use the signed configurations and certificates to prove to a verifier that it has appropriate configurations associated with the certified properties, without disclosing the specific configurations, which the platform holds. The drawback of delegation-based solutions is that such a TTP might not be available or/and desirable in many real applications, for example if two entities/users want to have a private communication with each other. They have their own understanding of the relation between various configurations and security properties. They do not need (and do not want) to ask any kind of TTPs to certify a correlation between the configurations and properties. However, they still want to keep their platform configuration information secret from each other. Hence, we propose a second solution (published in [CLMS08]) that does not require the involvement of a TTP to certify properties. In this protocol, a platform (equipped with a TPM) convinces a remote party that its configuration satisfies a given property. For this, the two parties first agree on a set of trusted configuration specifications, which they both consider to be trustworthy, i.e., associated with a well-defined security property or properties. The platform then proves that its configuration specification is in this set. In our protocol, TPM and the host software compute the proof jointly. For some applications, it might be unrealistic to assume that the parties in the attestation protocol can decide themselves which configurations are trustworthy and which are not, and thus they still have to rely on third parties in practice. Our protocol has the advantage that even in this case no global trusted party is necessary: both participants can choose independently how to agree on trustworthy configurations or they can delegate this decision to other parties – but in contrast to delegation-based solutions, both participants can decide independently whom to trust. Further, we define formal security models for PBA, which we also use in our proofs of security. We specify a real world / ideal world security model for the delegation-based approach, whereas for the protocol without TTP, we explicitly define the the main security

58

5.2. Related Work requirements evidence authentication and configuration privacy in a game-based model. While evidence authentication guarantees an unforgeable binding between the platform and its configuration specification, configuration privacy guarantees the non-disclosure of the configuration specification. In our PBA protocol without TTP, these requirements are achieved through the use of a ring signature (cf. Section 5.5.3), i.e., configuration privacy results from the anonymity of the signer, whereas evidence authentication is based on the unforgeability of the signature. Moreover, the cryptographic technique employed in our protocol may be of independent interest: We show how ring signatures can be used for efficiently proving the knowledge of an element in a list without disclosing it. Outline. First, we give an overview of related work in Section 5.2. Then we present our delegation-based solution in Section 5.3 and demonstrate its security in Section 5.4. We describe our approach to PBA without a TTP in Section 5.5 and demonstrate its security in Section 5.6. Finally, we conclude the chapter in Section 5.7.

5.2. Related Work Marchesini et al. [MSMW03, MSWM03, MSW+ 04] propose a software architecture based on Linux providing attestation and sealing. The architecture allows to bind short-lifetime data (e.g., application data) to long-lifetime data (e.g., the Linux kernel) and to allow access to the data only if the system is compatible with a security policy certified by a security administrator. Moreover, these papers suggest to use a certification authority that certifies the trustworthiness of certain configurations of long-lifetime data. Thus, the proposed architecture is very similar to a hybrid approach based on property certificates as we use in our delegation-based PBA scheme. The concept of PBA was first introduced by Sadeghi and St¨ uble [SS04], and by Poritz et al. [PSVW04]. Sadeghi and St¨ uble [SS04] propose and discuss several protocols and mechanisms that differ in their trust models, efficiency and the functionalities offered by the trusted components. The basic idea in [PSVW04] is to engage a protocol between verifier and attestor to prove that the attested platform satisfies the verifier’s security requirements. Their solution is based on property certificates that are used by a verification proxy to translate binary attestations into property attestations. Moreover, this work briefly discusses two deployment scenarios: The verification proxy as a dedicated machine and the verification proxy on the verified platform. The authors of [HCF04] propose semantic remote attestation – using language-based trusted virtual machines (VM) to remotely attest high-level program properties. The general idea behind this approach is the use of a trusted virtual machine that checks the security policy of the code that runs within the VM. Since the trusted VM still has to be binary attested, semantic remote attestation is a hybrid solution with code analysis. Attestation in the context of web service security is covered by Yoshihama et al. [YEN+ 05]. The authors propose that property certificates could be used to facilitate the evaluation of the trustworthiness of binary configurations (i.e., PCR values). Moreover, they suggest the possibility of using a trusted third party as validation service to perform the attestation on behalf of the relying party (i.e., the verifier in our model). However, the actual attestation procedure itself remains binary and does not provide configuration privacy.

59

5. Cryptographic Protocols for Property-Based Attestation

Figure 5.1.: Abstract model of the attestation scenario with certificate issuer CI, platform PF, host H, TPM M and verifier V

Another solution for PBA is proposed by K¨ uhn et al. [KSS07]. In their work, the authors suggest a modified system boot architecture, such that not binary hash values of files are stored by the TPM, but instead abstract values representing properties, e.g., a public key associated with a property certificate. However, this approach also requires a TTP to issue certificates for properties and the bootloader must be binary-attested. More recent research shows, how PBA can be used for securely migrating mobile agents based on a TPM or MTM [GNV09]. For their property-dependent agent transfer protocol, Gallery et al. also rely on property certificates, i.e., they are using a delegation-based PBA approach. A different strand of research addresses trust modeling and specification of properties for attestation (e.g., [NVHA08, NVH09, NV11]). Work in such directions is important for understanding what properties could be and how some form of PBA could be applied in various scenarios. However, in this thesis, we consider this topic out of scope. Nagarajan et al. [NVHG09] survey and classify various approaches to property-based attestation and remaining challenges. However, their focus is on the system models and conceptual approaches to PBA, not on cryptographic protocols such as our proposals.

5.3. Delegation-Based Protocol for PBA In the following, we present our cryptographic protocol for delegation-based PBA (cf. [CLMS08]).

5.3.1. Delegation of Property Evaluation to a Certificate Issuer In this section, we explain the general idea of delegation-based property-based attestation. Figure 5.1 illustrates the abstract model with certificate issuer, platform, host, attestor, TPM and verifier. In the following, we introduce the involved roles. Roles A platform, denoted by PF, represents our main IT system, i.e., it consists of all (software and hardware) components of a system. The Trusted Platform Module (TPM) is denoted by M, and is one of the main components of a platform PF. The TPM has a predefined set of computational and cryptographic capabilities (see Section 3.3.1) and is trusted by all parties. A host H is the other main component of PF, in which a TPM M is embedded. The host includes the software running on the platform PF. The

60

5.3. Delegation-Based Protocol for PBA TPM can only communicate with other parties (external to the platform) via the host. A verifier is denoted by V and is a party that wants to verify the attestation result of some platform. The certificate issuer, denoted by CI, is the party that certifies mappings between properties and configurations attesting that a given platform configuration cs fulfills a desired property p by means of a property certificate σCI (see Figure 5.1). Note that for security protocols, such as PBA or DAA, a trusted component (trusted by the platform or platform owner) is needed within the host that can establish secure channels to the attestor.1 More precisely, this component must belong to the Trusted Computing Base (TCB). Otherwise, the host can easily disclose to the verifier the configuration of the corresponding platform or/and application in the context of PBA (or the TPM identity in the context of DAA). The delegation-based principle is well-suited to the TCG trust model and the related infrastructure that already requires trust in third parties (e.g., Privacy-CA, certificate issuer in the context of DAA, or Migration Authority for migratable keys [Tru07b]). Our approach is a hybrid attestation, which means a two-level chain of attestations, where the first attestation is based on binary configurations (by the TPM) and the second one based on properties (by the corresponding PBA service). For a general property-based attestation, we assume in our model that applications are attested by the operating system. We stress that in this way, we only need to establish a trusted attestation service on top of a binary attestor (here TPM) still being conform to TCG. We do not elaborate on this service at this stage due to space restrictions and only consider the cryptographic proof protocols for proving the possession of a valid propertycertificate conform to the platform’s configuration. Note that CI confirms the correctness of the correspondence between the platform configuration and certain properties according to defined criteria. However, following common practice, such organizations are only liable for intentional misbehavior and not for undetected weaknesses (compare with safety and security tests or common criteria). Parties like CI are fully trusted, i.e., by the attestor and the verifier, since both have to assume that CI certifies only configurations that really have the attested property. To prevent a flood of desired properties, the involved parties can, e.g., define earmarked property profiles together. For instance, for end-users one could define a privacy-protecting Common Criteria [Com99] protection profile, while content providers define a content-protecting profile. The TTP then certifies whether given configurations are compatible to that protection profiles. If the TTP is a governmental authority, it can also analyze whether a given platform configuration protects the consumer’s privacy, e.g., by certifying that it is compatible to privacy laws.

5.3.2. Protocol for PBA with CL Signatures as Certificates In this solution, we describe a concrete property-based attestation protocol, which consists of property certificates, a PBA signing algorithm, a verification algorithm and a revocation check process. This protocol holds the security properties of unforgeability and unlinkability. Informally, unforgeability means that a PBA signature can only be produced with the involvement of a valid TPM to the actual platform configuration; unlinkability means that from the PBA signature and its verification protocol, a verifier is not able to deduce 1

This trusted component could be a service of a trustworthy operating system.

61

5. Cryptographic Protocols for Property-Based Attestation the specific configuration of the platform. The basic idea is as follows: the host H proves that there is a valid link between the conventional binary attestation signature σM , generated by the trusted component (here the TPM), and the certificate (represented by the signature σCI ) of a certificate issuer CI attesting that the configuration specification cs i provides the property specification denoted by ps. Here, the prover obtains the corresponding certificate σCI as secret input, and the verifier takes the public key vkCI of the certificate issuer and the property specification ps as individual input. The prover proves directly that its configuration complies with the one in the certificate without showing the certificate. Note that the revocation process in this protocol does not involve a trusted party. A prover can convince a verifier that its configuration is not among a given set of revoked configurations. It is not necessary for a trusted third party to provide the set of revoked configurations, which could be negotiated directly between the prover and verifier.

5.3.3. Security Parameters In this section, we enumerate the security parameters `x (y) used in the PBA protocol specified below with their required bitlength y. `cs (160) indicates the size of a configuration value cs, while `ps (160) determines the binary length of a certain property ps. `∅ (80) denotes the security parameter controlling the statistical zero-knowledge property and `H (160) is the output length of the hash function used for the Fiat-Shamir heuristic. For Pedersen’s commitment scheme, the size of the modulus P is set to `P (1632) and the size of the order Q of the sub group of Z∗P to `Q . The parameters `P and `Q should be chosen such that the discrete logarithm problem in the subgroup of Z∗P of order Q, with P and Q being primes such that 2`Q > Q > 2`Q −1 and 2`P > P > 2`P −1 , has acceptable computational difficulty. Furthermore, `n (2048) indicates the size of an RSA modulus, while è (368) and `0e (120) are parameters occurring in the blinded CL signature scheme. Finally, `v (2536) is the size of v, a random value which is part of the certificate. Moreover, we require the following constraints among the security parameters: `Q > `cs + `H + `∅ + 2, è ≥ max{`cs , `ps } + 2,

and

`v ≥ `n + max{`cs , `ps } + `∅ .

5.3.4. Property-Configuration Certificates An acceptable configuration attestation is certified by a certificate issuer CI. The procedures of key generation, certificate issuing and verification are described in Figure 5.2. We denote the corresponding protocols with (skCI , vkCI ) ← KeyGen(1`n ),

σCI ← IssueCertCI(skCI , (csi , ps)),

and

ind ← VerifyCertCI(vkCI , (csi , ps), σCI ).

62

5.3. Delegation-Based Protocol for PBA

1. Key generation: On input 1`n , create a special RSA modulus n = pq of length `n where p and q are strong primes. Choose, uniformly at random, R0 , R1 , S, Z ∈ QRn . Output the public verification key vkCI = (n, R0 , R1 , S, Z) and the secret signing key skCI = p. We denote this algorithm with (vkCI , skCI ) ← KeyGen(1`n ). 2. Signing algorithm: Given a property specification ps ∈ {0, 1}`ps and a set of the corresponding configuration specifications csi ∈ {0, 1}`cs with i = 1, ..., t. The property certificate on each configuration specification is issued as follows. On input (csi , ps) with ps ∈ {0, 1}`ps and csi ∈ {0, 1}`cs , choose a random prime number ei of length è ≥ max(`ps , `cs ) + 2, and a random number vi of length `v = `n + max(`ps , `cs ) + `∅ . Compute the value Ai such that Z ≡ Aei i · R0csi · R1ps · S vi mod n. The signature on the message (csi , ps) is the tuple σCI := (Ai , ei , vi ). We denote this algorithm with σCI ← IssueCertCI(skCI , (cs i , ps)). 3. Verification algorithm: Let i ∈ {1, ..., t}. To verify that the tuple (Ai , ei , vi ) is a signature on message (csi , ps), check that Z ≡ Aei i · R0csi · R1ps · S vi mod n, and check that 2è > ei > 2è −1 . We denote this algorithm with ind ← VerifyCertCI(vkCI , (csi , ps), σCI ). Figure 5.2.: Issuing a Certificate of a Property and Configuration Map.

63


Players: TPM M and the corresponding Host H TPM’s input: skM . Host’s input: σCI := (Ai , ei , vi ). Common input: vkCI = (n, R0 , R1 , S, Z), par com := (g, h, P, Q) , csi , ps, Nv (nonce provided by the verifier). 1. The TPM performs as follows a) Choose a random Nt ∈R {0, 1}`∅ .

b) Choose a random r ∈R {0, 1}`Q and compute the commitment Ccsi := g csi hr mod P . c) Generate a TPM signature σM := SignM(skM , par com kCcsi kNv kNt ).

d) Send to host σM with the values Ccsi , r and Nt .

2. The host performs the following steps to finish the proof: a) Choose at random w ∈ {0, 1}`n . b) Compute Aˆ = Ai S w mod n and vˆ = vi − wei . ˆ ei , vˆ). c) Create a masked signature σ ˆCI = (A,

3. The host computes the signature of knowledge protocol NI-PoK{(csi , ei , vˆ, r) : Z/R1ps ≡ ±Aêi R0csi S vˆ (mod n) ∧ Ccs i = g csi hr (mod P ) 0

csi ∈ {0, 1}`cs +`∅ +`H +2 ∧ (ei − 2è ) ∈ {0, 1}è +`∅ +`H +1 }(Nv , Nt )

in the following steps: a) Computes Z 0 = Z/R1ps mod n. b) Pick random integers 0

rv ∈R {0, 1}è +`n +2`∅ +`H +1 , re ∈R {0, 1}è +`∅ +`H , rcs ∈R {0, 1}`cs +`∅ +`H , rr ∈R {0, 1}`Q +`∅ +`H .

c) Compute Z˜0 := Aˆre R0rcs S rv mod n and C˜i := g rcs hrr mod P . d) Compute c := Hash(vkCI kpar kpskCcs kZ˜0 kC˜i kNv kNt ). i

e) Compute sv := rv + c · vˆ, scs := rcs + c · csi , se := re + c · (ei − 2è −1 ) and sr := rr + c · r over the integers. ˆ σM , Nt , Ccs , c, sv , scs , se , sr ). f) The PBA signature will be σPBA := (A, i

Figure 5.3.: The PBA Signing Algorithm.

64

5.3. Delegation-Based Protocol for PBA Players: Verifier V; Verifier’s input: vkCI , vkM , par com , ps, σPBA , Nv . The verifier verifies the signature by performing as follows: 1. Verify σM w.r.t. vkM on the message (par com kCcsi kNv kNt ). If positive go to the next step. è −1 −c g scs hsr mod P . 2. Compute Zˆ0 := Z 0−c Aˆse +c2 R0scs S sv mod n and Cî := Ccs i

?

?

3. Verify that c = Hash(vkCI kpar kpskCcs i kZˆ0 kCî kNv kNt ), scs ∈ {0, 1}`cs +`∅ +`H +1 and ?

0

se ∈ {0, 1}è +`∅ +`H +1 .

Figure 5.4.: The Verification Protocol.

5.3.5. Signing Algorithm The signature procedure is a protocol among the TPM M and the host H and is presented in Figure 5.3. As a result of the protocol, the host will have created a masked signature σPBA , which is based on a TPM signature σM on the message Ccs i , where Ccs i is the commitment to configuration specification cs i . From the masked signature, the verifier will be convinced that the platform has a valid configuration associated with a given property ps. The protocol is denoted by (M : σM ; H : σPBA )

←

PBASign(M : skM ; H : σCI ; vkCI , par com , csi , ps, Nv ),

where the commitment parameters are par com := (g, h, P, Q) and the public verification key of certificate issuer CI is vkCI = (n, R0 , R1 , S, Z).

5.3.6. Verification Algorithm The verification protocol (see Figure 5.4) checks if a given signature σPBA is correct, i.e., whether the input to the signing protocol was a configuration with a valid property certificate and a correct TPM signature. The protocol is denoted by ind ← PBAVerify(vkPBA , σPBA , Nv ), where vkPBA := (vkCI , vkM , par com , ps) is the verification key corresponding to the signature σPBA .

5.3.7. Revocation Check of a Certificate If for any reason, e.g., due to system security updates, a set of configuration specifications becomes invalid, the corresponding list will be published (usually by CI) so that possible verifiers can access it. Suppose that CSrevoked = {csj }j=1,...,τ is the set of invalid configuration specifications, either from a public list or negotiated between prover and verifier. Then the revocation check protocol in Figure 5.5, performed by a host H and a verifier V, checks whether the

65

5. Cryptographic Protocols for Property-Based Attestation configuration which was used for signing some property is contained in the set of revoked configurations CSrevoked . This protocol is denoted by (V : ind; H : σR )

←

PBARevoke(V : −; H : csi , r; par com , f, Ccsi , CSrevoked ),

i where csi is the host configuration, r = skcom is the key for opening the commitment, f 6= g 6= h is a generator of GQ , and Ccsi is the host’s commitment to the configuration csi . Technically, this proof is derived from a zero-knowledge protocol to prove the inequality of two discrete logarithms presented in [CS03]. The host shows that the configuration csi , to which it committed during PBASign (), is not equal to any of the revoked configurations csj . To achieve this, he proves the knowledge of both exponents in the commitment (i.e., csi and r) and that csi 6= csj (∀j = 1, . . . , τ ). To prove these inequalities, the technique introduced in [CS03] by Camenisch and Shoup is used. If csi = csj for some j, the verifier would notice this in step 5e, because in this case he would get Dj = 1.

5.3.8. Rogue TPMs If a TPM is broken, there must be a possibility to recognize this. In our scheme, the TPM signs the configuration by using a signing key, usually an AIK. If this AIK has been signed using a DAA signature, then the tagging will be covered by the DAA rogue tagging, and a potential verifier can check this. If other mechanisms such as a Privacy-CA are used to certify the AIK, then this AIK will be put on revocation lists. In any case, the problem of rogue tagging corrupted TPMs is out of scope of the PBA protocol.

5.4. Security of the Delegation-Based PBA Scheme We analyzed the security of the PBA protocol in a formal model based on the simulatability paradigm, as proposed in [Can00] and [PW01]. The ideal-world specification fulfills the requirements unforgeability and unlinkability – and, according to the proof, the real-world protocol implements this specification. The security proof of DAA [BCC04] uses a similar approach. We show that the security of the PBA protocol relies on CL signatures (cf. [CL02]) and Pedersen commitments (cf. [Ped92], Section 2.2), which in turn are based on the strong RSA assumption and the discrete logarithm assumption in the corresponding algebraic structures (see Section 2.4.1). We summarize this result in the following theorem. Theorem 5.4.1. The above protocol implements a secure property-based attestation system under the discrete logarithm assumption and the strong RSA assumption in the random oracle model. The basic idea of the proof (see Section 5.4.2) is to specify an ideal world, where a trusted party T ensures the security properties. The protocol is said to be secure if for every (polynomially bounded) adversary in the real world, there exists an adversary in the ideal world, such that both settings cannot be distinguished (except with negligible probability). This is achieved by the introduction of a simulator into the ideal world that has black-box access to the real-world adversary and acts as ideal-world adversary. Such a simulator is constructed independently from the actual adversary and hence works for all possible adversaries. Then the proof is concluded by showing that both worlds are indistinguishable.

66

5.4. Security of the Delegation-Based PBA Scheme

Players: Host H and Verifier V. Common input: (par com , f, Ccsi , CSrevoked ), where par com := (g, h, P, Q) and CSrevoked = {csj }j=1,...,τ ; Host’s input: (csi , r). 1. The host and verifier compute Gj = Ccs i /g csj (mod P ) (j = 1, ..., τ ). 2. The host computes F = f r (mod P ) and sends F to the verifier. 3. The host randomly picks β ∈ {0, 1}`Q , computes Dj := hrβ G−β j (mod P )(j = 1, ..., τ ) and sends Dj to verifier. 4. The host computes the signature of knowledge by performing as follows: n NI-PoK (csi , r, α, β) : Ccsi = g csi hr (mod P ) ∧ F = f r (mod P ) ∧

∧ 1 = f α F −β ∧ Dj = hα G−β for j = 1, ..., τ j

a) Pick random integers

o

rcs ∈R {0, 1}`cs +`∅ +`H , rr ∈R {0, 1}`Q +`∅ +`H , rα ∈R {0, 1}`Q +`∅ +`H , rβ ∈R {0, 1}`Q +`∅ +`H .

b) Compute C˜i := g rcs hrr mod P , F˜ := f rr mod P , −r D˜0 := f rα F −rβ mod P and D˜j := hrα Gj β for j = 1, ..., τ . c) Compute c := Hash(gkhkCcsi kF kC˜i kF˜ kD˜0 kD˜1 k...kD˜τ ).

d) Compute scs := rcs + c · csi , sr := rr + c · r, sα := rα + c · α and sβ := rβ + c · β. (Note that α := r · β mod Q.) e) Send the signature σR := (c, scs , sr , sα , sβ ) to the Verifier.

5. The verifier verifies the signature as follows: ?

a) Verify that scs ∈ {0, 1}`cs +`∅ +`H +1 . c mod P , Fˆ := f sr /F c mod P , b) Compute Cî := g scs hsr /Ccs i −s Dˆ0 := f sα F −sβ mod P , and Dˆj := hsα Gj β /Djc mod P (∀j = 1, ..., τ ). c) Compute cˆ := Hash(gkhkCcsi kF kCî kFˆ kDˆ0 kDˆ1 k...kDˆτ ).

d) If cˆ = c, accept the proof, otherwise reject the proof.

e) If Dj 6= 1 holds for j = 1, ..., τ , Ccs i was not committed to any of Gj (j = 1, ..., τ ), the verifier accepts Ccs i . Figure 5.5.: The Revocation Check Protocol.

67


5.4.1. Formal Security Model Here, we present a formal security model for property-based attestation protocols. The proof approach is simulation-based, as proposed in the frameworks of [Can00] and [PW01]. The security proof of Direct Anonymous Attestation (DAA) [BCC04] is based on a similar model. 5.4.1.1. Overview We summarize the ideas underlying the security models. In this context, consider two worlds, a real world and an ideal world. Real System (RS) In the real system, the parties (principals) running the underlying cryptographic protocol are denoted by P. The adversary A controls some of these parties, which are denoted by P ∗ . In other words, dishonest parties are subsumed into the adversary. The environment E provides each honest party with inputs and interacts with A. After being invoked by the environment, the honest party interacts with other parties as specified by the protocol and reveals the corresponding output to E at the end of the protocol run. Ideal System (IS) The involved parties are the same as in the real system, however, without cryptographic protocols being performed. Instead, an ideal trusted party T replaces the functionality of the cryptographic protocol and takes care of all transactions between other parties. Hence, each party sends its input to T that provides the corresponding output. Security of a Cryptographic System A cryptographic protocol is said to implement a functionality securely if for every adversary A and every environment E there exists a simulator S controlling the same parties in the ideal system as A does in the real system such that the environment cannot distinguish whether it runs in the real system interacting with A or in the ideal system interacting with the simulator S. 5.4.1.2. The Real System In the real system, all parties have to perform the cryptographic operations according to the protocol. If the protocol is secure, this implements the ideal functionality as specified by the ideal trusted party. 5.4.1.3. The Ideal System The ideal system is modeled to have all desired properties by construction, but makes the unrealistic assumption that a trusted party (T ), a machine that is trusted by all parties, is available. A simulator (S) is introduced to simulate the real-world adversary towards the environment. In the following, the various parties of the ideal world are described briefly.

68

5.4. Security of the Delegation-Based PBA Scheme Environment Adversary P

*

*

P2

1

P4

P3

Figure 5.6.: The real system Environment

Simulator Adversary P

1

*

P

P3

2

*

P4

Trusted Party T

Figure 5.7.: The ideal system, together with a simulator encapsulating a real-world adversary Trusted Party In the ideal world, a trusted party T carries out all operations specified in the protocol (in a correct manner), where only the interface is important, implementation details are not considered. T communicates via “status messages”; no actual cryptographic operations are performed. Environment The environment E is a machine that can be regarded as “whatever is external to the current protocol execution”. It provides the inputs for all participating parties, i.e., it distributes them. Honest Parties The honest parties Px act according to the protocol. In the ideal world, they communicate with the trusted party T via status messages. Adversary and Corrupted Parties The corrupted parties Py∗ can communicate arbitrarily among each other. Together, they form the so-called adversary A. The Simulator The simulator S integrates a real-world adversary into the ideal system in order to show that every real-world adversary can be simulated in the ideal system. S controls input and output of the corrupted parties Py∗ to and from T . The simulator translates ideal-world status messages from T to a corrupted party into real world (crypto) messages, seemingly coming from other real-world parties, and vice versa: A’s (crypto) messages are translated to ideal-world operations for T .

69

5. Cryptographic Protocols for Property-Based Attestation The goal of this simulation is that the environment E cannot (computationally) distinguish the ideal world from the real world (except with negligible probability). Therefore, all attacks that can be carried out in the real world can also happen in the ideal world, where the latter is secure by construction. Thus, if the simulation succeeds, the system is secure.

5.4.2. Proof of Theorem 5.4.1 The proof of security presented here follows the security model discussed in Section 5.4.1. It consists of the specification of an ideal-world trusted party and of a simulator. Finally, we argue that the real world (with an adversary A) is indistinguishable from the ideal world (with the simulator S). Note that we do not simulate the certificate issuer CI, since it is considered to be a trusted third party. 5.4.2.1. Assumptions • Each TPM has a unique identifier but the number of hosts/TPMs is not fixed. However, we do not state the identifiers explicitly in our proof in order to avoid clumsy notation. Implicitly, they are used by the trusted party T and parties participating in the protocol to address messages to the intended recipient. • If a TPM is corrupted then the corresponding host and consequently the platform are corrupted, as well. This assumption is reasonable because in practice, it is much harder to subvert the TPM hardware than to attack the software running on a PC. Therefore, any adversary that is able to corrupt a TPM, might as well corrupt the host, too. 5.4.2.2. Ideal-World Trusted Party T for the PBA Protocol In the ideal system, the trusted party T supports the following operations: • Setup: If an (honest) TPM has to be simulated, we have to generate a secret key. • PBA-Sign: A host H shows that its configuration is certified to fulfill a certain property as follows: 1. H informs T that he wants to sign w.r.t. property ps and with nonce Nv . 2. T asks M if it wants to sign (with Nv ).

3. If M agrees to sign, M sends its configuration csi to T and T informs H that M created a TPM signature. If M doesn’t agree to sign, T reports a failure to M. 4. H informs T that he wants to generate the PBA signature. 5. T returns success to H.

• PBA-Verify: A verifier V checks if a host H signed a certain property by PBA-Sign as follows: 1. V informs T that he wants to verify if H signed w.r.t. property ps.

70

5.4. Security of the Delegation-Based PBA Scheme 2. T checks whether H has created a PBA signature w.r.t. property ps and returns the result (valid or invalid) to V. • PBA-CheckRevocation: A verifier checks that the configuration signed by H corresponds to a valid configuration that has not been revoked. This is proceeded as follows: 1. V informs T that he wants to verify that the signature of property ps from H does not correspond to one of the revoked configurations on the list (cs1 , . . . , csτ ). 2. T asks H if he wants to participate in the revocation check protocol with V w.r.t. the configurations (cs1 , . . . , csτ ). 3. If H agrees, T tells V whether H’s configuration csi is on the list or not. 5.4.2.3. The Simulator In the following, the simulator is described for all cases of the ideal-world operations, where it is triggered by messages sent to and from the adversary. For this, we have to distinguish different cases for the individual operations, depending on which parties are corrupted and which are honest. Ideal World Setup If an (honest) TPM has to be simulated, the simulator needs a secret key skM to generate TPM signatures. Such a key is generated as an attestation identity key AIK, chosen as AIK = (skM , vkM ). The corresponding public key vkM is used for signature verification and is given to the adversary. Simulation of PBA-Sign We distinguish three cases (see assumptions): In the first case, both host H and TPM M are honest, in the second case, we consider a corrupted host H∗ and an honest TPM M, and in the third case, both host H∗ and TPM M∗ are corrupted. The cases where host and TPM are either both honest or both corrupted are trivial because the simulator is not even triggered. Corrupted Host H∗ , Honest TPM M . Figures 5.8 and 5.9 show real and ideal world for this case. Environment

A H*

TPM

Figure 5.8.: PBA-Sign in the real system for corrupted host H∗ and honest TPM M

71

5. Cryptographic Protocols for Property-Based Attestation Environment

S

A

A H*

TPM

Trusted Party T

Figure 5.9.: PBA-Sign in the ideal system for corrupted host H∗ and honest TPM M If the trusted party T informs the simulator S that M signed (and committed to) a configuration csi w.r.t. a nonce Nv , S has to generate such a signature for the adversary H∗ . For this purpose, it computes a commitment Ccsi := g csi · hr mod P

and creates a TPM signature using the secret key skM

σM := SignM(skM , parcom kCcsi kNv kNt ). Simulation of PBA-Verify For PBA-Verify, two cases where the simulator is triggered have to be distinguished: an honest host (as signer) with a corrupted verifier and a corrupted host with an honest verifier. Honest Host H, Corrupted Verifier V ∗ . The simulator S receives a notification from T that H signed property ps (w.r.t. nonce Nv ). Thus, S has to simulate the respective event in the real world: it has to provide V ∗ with a signature σPBA . As an honest host implies an honest TPM, S has to simulate both H and M towards the adversary. This situation is illustrated in Figure 5.10. This simulation can be done as follows: 1. First, S chooses a valid configuration csi with a corresponding property certificate σCI and the following values uniformly at random: sv ∈R {0, 1}è +`n +2`∅ +`H +2 0

se ∈R {0, 1}è +`∅ +`H +1 r ∈R {0, 1}`Q

c ∈R {0, 1}`H

scs ∈R {0, 1}`cs +`∅ +`H +1 sr ∈R {0, 1}`Q +`∅ +`H +1

Nt ∈R {0, 1}`∅ w ∈R {0, 1}`n

ˆ 2. Then the simulator computes A: Aˆ := Ai · S w mod n,

72

5.4. Security of the Delegation-Based PBA Scheme Environment

A

S

A V*

H

Trusted Party T

Figure 5.10.: PBA-Verify in the ideal system for honest host H and corrupted verifier V ∗ where Ai comes from the property certificate σCI = (Ai , ei , vi ) corresponding to the configuration csi and S is publicly known. 3. Next, the TPM signature and commitment have to be generated: • S calculates

Ccsi := g csi · hr mod P.

• It signs the configuration with a TPM key skM σM := SignM(skM , parcom kCcsi kNv kNt ). 4. S computes Zˆ0 and Cî as follows: è −1 Zˆ0 := Z 0−c · Aˆse +c2 · R0scs · S sv mod n −c Cî := Ccs · g scs · hsr mod P, i

where Z 0 := Z/R1ps mod n. 5. Finally, S patches the random oracle such that c = Hash(vkCI kparkpskCcsi kZˆ0 kCî kNv kNt ) ˆ σM , Nt , Ccs , c, sv , scs , se , sr ) to the adversary V ∗ . and sends σPBA := (A, i If the adversary verifies σPBA , the verification succeeds because the signature was constructed such that the verification equations of the PBA-Verify algorithm are fulfilled. This can be checked by straight-forward calculations. Corrupted Host H∗ , Honest Verifier V. In this scenario, illustrated in Figure 5.11, the simulator receives a signature from the adversary H∗ , which it has to verify. Therefore, S performs the real-world protocol PBA-Verify to simulate a real-world verifier towards the adversary. If this fails, the signature is ignored – just like it would be ignored by an honest party in the real world.

73

5. Cryptographic Protocols for Property-Based Attestation Environment

A

S

A H*

V

Trusted Party T

Figure 5.11.: PBA-Verify in the ideal system for corrupted host H∗ and honest verifier V Otherwise, the adversary either produced a correct signature, or he had to break one of the underlying cryptographic schemes of the property-based attestation protocol, which in turn would mean that he had to break a cryptographic assumption. S uses standard rewinding techniques to obtain the adversary’s secrets (eCL , csCL , vˆCL ) from the CL signature and its secrets (cscom , rcom ) from the commitment. We now distinguish two cases: • If csCL does not represent the desired property, a property certificate had to be forged. In this case, the strong RSA assumption can be broken by the following reduction, using two simulators SCL and S 0 : SCL translates the flexible RSA instance into a public key for the CL signature scheme. Moreover, SCL provides two operations, adaptive signature queries and forgery and uses S 0 as adversary.2 The adversary uses the queries to obtain signatures and tries to produce a forged signature/message pair, using A as an oracle to obtain ˆ eCL , vˆCL ) of the CL signature. If S 0 succeeds in forging a CL signature, a forgery (A, SCL solves the given instance of the flexible RSA problem. To obtain the forged signature, S 0 has to simulate the PBA-scenario towards the adversary A. • If csCL does represent the desired property, the simulator S checks whether csCL = cscom . If this holds, the adversary did not cheat and the entire simulation succeeds. Otherwise (csCL 6= cscom ), the adversary was able to break the soundness property of the signature of knowledge, which can be split into two sub-proofs: The proof of representation of the commitment scheme (cscom , r) and the proof of representation ˆ eCL , vˆCL ). This means that it could break either one of of the CL certificate (A, these sub-proofs, i.e., either the discrete logarithm or the strong RSA assumption has been broken. The reduction uses a simulator that can break at least one of the two assumptions. It uses the cheating provers for both cases. 2

As noted in [BCC04], the existence of the simulator SCL follows from the security of the CL signature scheme, which was proved in [CL02].

74

5.4. Security of the Delegation-Based PBA Scheme Simulation of PBA-CheckRevocation be considered.

Again, the two cases (H, V ∗ ) and (H∗ , V) have to

Honest Host H, Corrupted Verifier V ∗ . In this case, the simulator has to simulate the host’s part of the PBA-CheckRevocation protocol towards the adversary (a corrupted verifier). The simulation proceeds as follows: 1. S chooses the following values uniformly at random: scs ∈R {0, 1}`cs +`∅ +`H +1

sr ∈R {0, 1}`Q +`∅ +`H +1

sα ∈R {0, 1}`Q +`∅ +`H +1

sβ ∈R {0, 1}`Q +`∅ +`H +1

c ∈R {0, 1}`H

F ∈R GQ

Dj ∈R GQ \ {1} for all revoked configurations

{csj }1≤j≤τ

2. S sends Dj and F to the corrupted verifier V ∗ . 3. S computes the following values: Gj := Ccsi /g csj mod P Fˆ := f sr F −c mod P

−c mod P Cî := g scs hsr Ccs i −s s Dˆ0 := f α F β mod P −s Dˆj := hsα Gj β Dj−c mod P

4. S patches the random oracle, such that c = Hash(gkhkCcsi kF kCî kFˆ kDˆ0 kDˆ1 k...kDˆτ ). 5. S sends σR := (c, scs , sr , sα , sβ ) to V ∗ . If the adversary verifies σR , the verification succeeds because the signature was constructed such that the verification equations of the PBA-CheckRevocation protocol are fulfilled. This can be checked by straight-forward calculations. Corrupted Host H∗ , Honest Verifier V. The simulator – acting as an honest verifier – checks the adversary’s signature σR as specified by the PBA-CheckRevocation protocol. If this check fails, S rejects H∗ ’s configuration (just as an honest party in the real world would). Otherwise, apply standard rewinding techniques, just as in the verification protocol, to gain (csi , r, α, β). Afterwards, distinguish two cases: Either the adversary’s configuration csi is not on the revocation list (and therefore the adversary’s proof is correct), or the adversary was able to forge the signature of knowledge. We can use the same reduction argument as in the verification protocol, except that only Pedersen commitments are invoked. Hence, only the discrete logarithm assumption has to be broken.

75

5. Cryptographic Protocols for Property-Based Attestation 5.4.2.4. Indistinguishability of Real World and Ideal World with Simulator It remains to argue that the above simulation succeeds, i.e., that no environment can distinguish the ideal world (with the simulator S) from the real world (with adversary A), except with negligible probability. Note that this implies that the adversary cannot (computationally) distinguish between the two cases, because otherwise he could present different messages to the environment, thereby allowing E to distinguish the two cases as well. It has to be shown that the signatures forged by the simulator during the simulation of PBA-Verify and PBA-CheckRevocation are computationally indistinguishable from realworld signatures. In both cases, there are several s∗ chosen at random, where in the real world, the corresponding values are computed from secret values. Since these parameters are statistically indistinguishable, they are also computationally indistinguishable. Moreover, c is chosen at random by the simulator, whereas in the real world, it is the result of the hash function. But since we are in the random oracle model, these distributions are indistinguishable because the hash function is implemented by a random oracle. When simulating PBA-CheckRevocation, S also selects a random F and random Dj for all revoked configurations. These are computationally indistinguishable from the realworld values because of the statistical indistinguishability of the underlying commitment scheme from random values. We have demonstrated how the proposed PBA protocol holds the property of indistinguishability of the real world and ideal world based on the security model specified above. We have also shown how the simulator, in the simulation, is able to forge a CL signature or to break the Pedersen commitment scheme with the help from the adversary, when the adversary breaks the PBA protocol. Based on the security proof of the CL signature in [CL02], an algorithm of forging a CL signature can be used to break the hardness of the strong RSA problem. Based on the security analysis of the Pedersen commitment scheme in [Ped92], an algorithm of breaking the Pedersen commitment scheme can be used to break the hardness of the discrete logarithm problem. Therefore, Theorem 5.4.1 in Section 5.4 follows.

5.5. PBA without TTP based on Ring Signatures In this section, we propose a protocol for PBA, which is based on ring signatures. The TPM generates a signature on a commitment to the configuration cs P . Then the host H creates a proof, using a ring signature, that cs P is in the agreed set CS of configurations with the given property. The verifier V verifies the TPM signature and the ring signature. Note that in our protocol, the TPM is trusted by all parties, but its resources are restricted, and it can execute only a very limited set of instructions. The host H is not trusted by the verifier V, hence the protocol has to protect evidence authentication against a malicious host. H cannot be prevented from disclosing its own configuration cs P , thus for configuration privacy, we have to assume that H is honest.

76

5.5. PBA without TTP based on Ring Signatures

Prover Host

CS = {cs1 ,...,csn } csP є CS

Property-based attestation protocol

Verifier CS = {cs1 ,...,csn }

TPM PCRs: csP

Figure 5.12.: PBA system model.

5.5.1. System Model for PBA The following system model for PBA will serve as the basis for the security model in Section 5.6. Involved parties. A PBA protocol involves two participants: a prover P and a verifier V. The prover is a platform consisting of a host H and a trusted module TPM M (see Figure 5.12). To cover multiple executions of the protocol we consider multiple instances and use indices to distinguish among their participants, i.e., Pi , Vi . Each instance includes a single protocol execution with some unique session identity (SID) and two participants Pi and Vj are treated as communication partners (in the same instance) if they share the same SID. Assumptions. It is assumed that the communication between a host Hi and its TPM Mi is through a secure channel (private and authentic), and that Mi and Vi communicate via Hi . We omit the indices i and j of the participants in an instance when no risk of confusion exists. Moreover, the TPM is trusted by all parties and possesses a secret (signing) key skM which is unknown to the host. The corresponding public (verification) key is available to both P and V; see also “trust relations” in Section 5.6.1. Properties and configurations. Each prover P has a configuration value denoted cs P , which is an authenticated record about its platform’s configuration. The value cs P is known to both the host H and TPM M, and it is computed by M from correctly measured configuration information, stored securely in special-purpose registers – the platform configuration registers (PCRs). As a result, H cannot modify this value without being detected. This is guaranteed by the properties of secure measurement and reporting based on the trusted computing technology [Tru07b]. It is assumed that before running the PBA protocol, P and V have already agreed on a set of configuration values denoted CS = {cs 1 , ..., cs n } that satisfy the same property. So, we say that a configuration value cs satisfies a given property associated with CS , if and only if cs ∈ CS . Definition of PBA. A property-based attestation (PBA) scheme consists of the following three polynomial-time algorithms:

77

5. Cryptographic Protocols for Property-Based Attestation • Setup: Given the security parameter 1κ , this probabilistic algorithm selects a set of public parameters that are necessary to run the PBA protocol, and produces a private/public key pair for each TPM. • PBA-Sign: On input a configuration value cs P , a list of admissible configurations CS , and a nonce Nv , this (distributed) randomized algorithm outputs a signature σ on cs P . • PBA-Verify: On input a candidate signature σ and CS , this deterministic algorithm outputs 1 (accept) if σ is a valid signature on a value from CS , or 0 (reject) otherwise.

5.5.2. Solutions In this section, we sketch two high-level solutions for PBA without relying on trusted parties to certify the link between configurations and properties. Basically, P has to prove that its configuration value cs P belongs to the agreed set CS = {cs 1 , . . . , cs n }. More precisely, V would accept a proof if and only if: (i) The proof is created by a valid TPM. If TPM anonymity is required, the DAA scheme [BCC04] can be used to provide this feature. (ii) The proof is a fresh response to a specific challenge from V. (iii) The proof ensures that cs P = cs j for an index j ∈ {1, 2, . . . , n}, but does not reveal the value of j. Such a proof implements PBA-Sign, whereas PBA-Verify is the verification of the proof. In Setup, the keys for the TPM and system parameters are generated. Solution 1: TPM as single signer. The proof can be achieved by a new TPM command defined as follows: 1. TPM takes as input a list of configurations CS and a nonce N . The nonce is assumed to be chosen by the verifier V. 2. TPM checks for each cs j ∈ CS if cs P = cs j , until either a match is found, or the entire list has been checked. 3. If cs P is in the list, the TPM generates a signature on (1, N, CS ); otherwise, the TPM generates a signature on (0, N, CS ), which is then forwarded to V. The obvious drawbacks of this approach are: TPM operations depend on the size n of CS (O(n) in a straightforward implementation, and O(log n) if CS is a sorted list). As the TPM’s memory is very limited, this would either impose a severe restriction on the size of CS , or the transfer of the list would have to be split up, causing further complexity of the TPM-command and slowing down the communication between host and TPM, due to the overhead. Solution 2: TPM shares signer role with host. In this solution, the TPM signs a hidden version – a commitment – of the configuration cs P , and the host completes the proof that the hidden configuration is in the set CS . A similar approach is used in the DAA protocol [BCC04]. Our PBA protocol proposed in Section 5.5.4 is an elegant and efficient example of this solution. It makes use of ring signatures in that the host computes n public keys for a ring

78

5.5. PBA without TTP based on Ring Signatures signature scheme from the configurations in CS and the commitment to cs P (which was signed by the TPM), and determines the secret key that corresponds to cs P . The signer anonymity of the ring signature scheme ensures that the verifier does not learn which key has been used for signing, thus cs P is not disclosed. Our construction guarantees that the prover succeeds only if the hidden configuration cs P is indeed in CS . Current TPMs support all operations (random number generation, modular exponentiation, and signature generation) needed by our protocol. However, the TCG currently does not specify a command to create and sign a commitment to a configuration which is stored inside the TPM. To implement such a command, only firmware changes would be required. Other protocols for similar solutions could be developed, for instance based on existing zero-knowledge proofs (e.g., [CS97, FO97, CM99]) or zero-knowledge sets [MRK03].

5.5.3. Ring Signatures The notion of a ring signature was first introduced by Rivest et al. [RST01]. It allows a signer to create a signature with respect to a set of public keys. Successful verification convinces a verifier that a private key corresponding to one of the public keys was used, without disclosing which one. In contrast to group signatures, no group manager is needed. For various security definitions for ring signatures see [BKM06]. Recent efficient ring signature schemes which are provably secure in the standard model (i.e., without using random oracles) are proposed in [SW07, CGS07], where in [CGS07] a signature with size √ only O( n) is proposed. Dodis et al. [DKNS04] showed that ring signatures with constant size in the number of public keys can be achieved in the random oracle model. Unfortunately, none of these schemes can be used easily for our purposes: In our protocol, we employ a construction, where the public keys for the ring signature are computed from commitments formed by the TPM. We show how this can be done efficiently for Pedersen commitments (cf. Section 2.2) and public keys of the form y = g x mod P , where x is the corresponding secret key. However, the schemes above use keys of different types. In Figure 5.13, we recall an efficient ring signature scheme from [AOS02], which we propose to use for our PBA solution. The scheme is a generalization of the Schnorr signature scheme [Sch91]: Intuitively, the product in step 2(b) corresponds to combined commitments for individual Schnorr signatures, in step 2(c) and 2(d), the challenges for the individual Schnorr signatures are derived from a single challenge, and in step 2(e), the secret key is used to compute s. The verification equation, where the sum of the challenges is compared to a hash value, ensures that a valid signature cannot be created without a secret key xj . The scheme is provably secure in the random oracle model, under the discrete logarithm assumption. We denote the generation of a ring signature σr on message m with respect to the public key ring {yi }1≤i≤n and with private signing key x by σr := SigRing(x; {yi }; m). Signature verification is denoted by VerRing({yi }; σr , m). For simplicity, we omit the public parameters g, P, Q and the range of the index i in our notation.

5.5.4. Our PBA Scheme without TTP In this section, we detail the protocols for our ring signature-based PBA scheme without trusted third party and discuss some of its noteworthy properties. After that, in

79

5. Cryptographic Protocols for Property-Based Attestation 1. Key generation. Let κ be a security parameter. On input 1κ , create g, P and Q. A signer Si (i = 1, ..., n) chooses xi ∈R {0, 1}`Q and compute yi = g xi mod P . Output its public key (g, P, Q, yi ) and the corresponding secret key xi . 2. Signing algorithm SigRing(xj ; {yi }; m). A signer who owns secret key xj generates a ring signature on a message m with public key list (g, P, Q, yi ) (i = 1, ..., n), where j ∈ {1, ..., n} as follows: a) Choose α, ci ∈R {0, 1}`Q for i = 1, ..., n, i 6= j. Q b) Compute z = g α ni=1,i6=j yici mod P . c) Compute c = Hash(gkP kQky1 k...kyn kmkz).

d) Compute cj = c − (c1 + ... + cj−1 + cj+1 + ... + cn ) mod Q. e) Compute s = α − cj · xj mod Q.

f) Output the signature σr = (s, c1 , ..., cn ).

3. Verification algorithm VerRing({yi }; σr , m). To verify Pn that the tuple σr = (s, c1 , ..., cn ) iss ac1ringcnsignature on message m, check that i=1 ci ≡ Hash(gkP kQky1 k...kyn kmkg y1 ...yn mod P ). Figure 5.13.: A Ring Signature Scheme [AOS02]

Section 5.6, we demonstrate the security of this scheme. 5.5.4.1. Security Parameters We suggest the following security parameters (values in parentheses indicate realistic values3 for current TPMs): • `cs (160): the size of the value of cs P . • `∅ (160): the security parameter for the anti-replay value (nonce). • `P (1024): the size of the modulus P . • `Q (160): the size of the order Q of the subgroup of Z∗P . The parameters `P and `Q should be chosen such that the discrete logarithm problem in the subgroup of Z∗P of order Q with P and Q being primes such that 2`Q > Q > 2`Q −1 and 2`P > P > 2`P −1 , is computationally hard. 5.5.4.2. Setup We assume that V can verify TPM signatures (including revocation verification) and that H and V have agreed on a set of configurations CS . 3

80

Examples based on the use of SHA-1 [Nat02] as a hash function (like in current TPMs), and recommendations of the US National Institute of Standards and Technology (NIST) for similar applications (see, for instance, [Nat06]); changes corresponding to stronger hash-functions, such as SHA-256, can be made straightforwardly.

5.5. PBA without TTP based on Ring Signatures

H

TPM

V

cs P , CS = {cs 1 , . . . , cs n }

cs P , skM

vkM ,CS = {cs 1 , . . . , cs n }

?

?

Nv

Nv

Nv ∈R {0, 1}`∅

r ∈R Z∗Q C := g cs P hr mod P σM := SignM(skM ; (C, Nv ))

C, r, σM -

yj := C/g cs j mod P (for j = 1, . . . n) σr := SigRing(r; {yj }; Nv )

?

OK

C, σM , σr-

VerM(vkM ; σM , (C, Nv )) yj := C/g cs j mod P (for j = 1, . . . n) VerRing({yj }; σr , Nv )

?

OK

?

OK

Figure 5.14.: The protocol of the PBA scheme. Common input: g, h, P, Q Prior to the execution of the PBA protocol, the parties have to agree on the following parameters, which can be used for several protocol runs (potentially with different sets CS ): primes P and Q, generators g and h of a subgroup of Z∗P of order Q (i.e., the discrete logarithm problem is hard in hgi = hhi). The discrete logarithm logg (h) mod P must be unknown to H. 5.5.4.3. Signing and Verifying Protocol The attestation procedure executed between a TPM (M), its host (H), and a verifier (V) is described in Figure 5.14. As a result of the protocol, the host creates a ring signature σr , which is based on a TPM signature σM on the message C, which is a commitment to cs P . The TPM has to create and sign C, which it then opens towards H. To create the ring signature, the host uses the value r as the secret key (if cs P ∈ CS , this works, because yj = hr mod P for some j). From the ring signature, the verifier is convinced that the platform has been configured with one of the set of acceptable configuration specifications, CS = {cs 1 , · · · , cs n }, without knowing which one. 5.5.4.4. Protocol Properties Our protocol has some interesting properties: First, no trusted third party is needed for this protocol. The only exception is the certification of TPM keys: The verifier may rely on a DAA issuer or a Privacy-CA to ensure that the TPM key belongs to a valid TPM, depending on the TPM signature scheme (see Section 3.3.1). However, this is completely independent from the PBA protocol, and

81

5. Cryptographic Protocols for Property-Based Attestation neither a DAA issuer nor a Privacy-CA could breach the configuration privacy of our protocol. Second, the configuration set CS is created flexibly, dependent on the agreement between prover P and verifier V. One approach to negotiate the set of acceptable configurations could be analogous to the SSL/TLS handshake: The prover sends a proposal for CS to V, who can then select an appropriate subset. However, our protocol allows for different ways to agree on CS ; the particular method can be chosen according to a concrete application scenario. Third, the size n of the set CS affects the configuration privacy. If n is small, V might have a high probability in guessing the configuration cs P . Therefore, to keep cs P private, P should execute the protocol only if CS is of acceptable size. Moreover, P has to ensure that V cannot learn cs P by running the PBA protocol multiple times with different configuration sets, because in the case of several successful attestations, V would know that cs P is in the (possibly small) intersection of the sets used in the protocol executions. This example shows that P should install a privacy policy which prevents such abuses of the PBA protocol. Fourth, note that the overhead of the TPM compared to binary attestation is small. Additionally, the TPM has to form the commitment C, which must be signed instead of cs P . So the overhead is just choosing a random number r and performing a modular multi-exponentiation modulo P (with two exponents). As with binary attestation, the TPM has to generate one digital signature (e.g., 2048 bit RSA). The TPM’s computation does not depend on the size of CS .

5.6. Security of the PBA Scheme without TTP Here, we define a formal (game-based) security model based on the system model from Section 5.5.1, and state theorems about the security of our PBA scheme.

5.6.1. Security Model Adversary model. The adversary A is a PPT algorithm and an active adversary that has full control over the communication channel between H and V. This is modeled by the query of the form send(E, m) which allows A to address a message m to an entity E ∈ {H, V}. In response, A receives a message which would be generated by E according to the protocol execution. In the definition of entity authentication, in which malicious hosts should also be considered, A is also given access to another query sendTPM(m) by which it can communicate with M. We assume that m contains the identity of the sender (as chosen by A). Moreover, when considering evidence authentication, the adversary may corrupt the host via the query corruptH , which returns the configuration cs P to A (cs P is H’s only secret). We assume that A cannot corrupt the TPM. In reality, a hardware attack would be necessary to corrupt a TPM, i.e., we limit the adversary to software-only attacks, which is the assumption of the TCG [Tru07b]. In case a real-world adversary succeeds in attacking the TPM, our protocol has to rely on the revocation mechanisms for TPM signatures. Evidence authentication. We formalize the intuitive security requirement that A should not be able to pretend that P has a configuration cs P satisfying the property that has to

82

5.6. Security of the PBA Scheme without TTP be attested (i.e., cs P ∈ CS ), when in fact the property is not fulfilled (i.e., cs P 6∈ CS ). Let Gameev-auth (1κ ) be the following interaction between P, V, and A. Before the A interaction, A chooses a platform with a valid TPM M and with a configuration cs P 6∈ CS . Then A is given access to send(E, m), sendTPM(m), and corruptH queries to any P chosen by A. Uncorrupted parties behave as specified by the protocol. A wins, if it outputs a PBA signature σ, such that PBA-Verify accepts σ. We denote the success probability of A by Succcf-priv (1κ ) := Pr[Gameev-auth (1κ ) = win], and its maximum over all PPT adversaries A A A (running in time κ) as Succcf-priv (1κ ). A PBA protocol provides evidence authentication if Succcf-priv (1κ ) is negligible in κ. Configuration privacy. The security requirement that the configuration cs P of P should be kept private is captured by the following game. For this requirement, host H and TPM M of P have to be honest because P could always send cs P to A. Let Gamecf-priv (1κ ) be the following interaction between P, V and A. A is given access A to send(E, m) queries. Moreover, A may access sendTPM(m) and corruptH queries for all but one prover P chosen adaptively by A, which has to remain honest. At the end of the interaction, A outputs an index i. A wins if i is the index of P’s configuration in the set CS = {cs 1 , . . . , cs n }, i.e., if cs P = cs i . We denote the advantage of A (over a random (1κ , n) := | Pr[Gamecf-priv (1κ ) = win] − 1/n|, and its maximum over all guess) with Advcf-priv A A PPT adversaries A (running in time κ) as Advcf-priv (1κ , n). A PBA protocol provides configuration privacy if Advcf-priv (1κ , n) is negligible in κ. Security of PBA. A PBA scheme is secure, if and only if it provides both evidence authentication and configuration privacy. Trust relations. The TPM is assumed to be trusted by both host and verifier. For evidence authentication, a PBA protocol must ensure that a malicious host cannot cheat an honest verifier, whereas for configuration privacy, it must prevent a verifier controlled by A from determining the configuration of an honest host.

5.6.2. Security Analysis The following theorems demonstrate the security of our PBA scheme. For the proofs, see below. Theorem 5.6.1 (Evidence Authentication). The PBA protocol presented in Section 5.5.4 provides evidence authentication (in the random oracle model), assuming the security of the ring signature scheme, the security of TPM signatures, and the hardness of the discrete logarithm assumption. In more detail: Succcf-priv (1κ )

≤

q 2 /2`∅ + εTPM + εring + εdlog ,

where q is the number of protocol runs, `∅ is polynomial in the security parameter κ, εTPM is the probability of an adversary to forge a TPM signature, εring is the probability to forge a ring signature, and εdlog is the probability to solve the underlying discrete logarithm problem.

83

5. Cryptographic Protocols for Property-Based Attestation Remark. Our proof does not directly use the random oracle model, however, it is required by the ring signature scheme we use. Theorem 5.6.2 (Configuration Privacy). The PBA protocol presented in Section 5.5.4 provides configuration privacy against computationally unbounded adversaries, due to the unconditional signer anonymity of the ring signature scheme and perfect hiding of the commitment scheme. Remark. Although our definition of configuration privacy assumes a PPT adversary (which would be reasonable for practical purposes), our protocol offers even unconditional security, because we use a perfectly hiding commitment scheme and an unconditionally signer-anonymous ring signature scheme. 5.6.2.1. Proof of Evidence Authentication Proof. We structure the proof as a sequence of games [Sho04], where a PPT adversary A (see Section 5.6.1 for the adversary model) interacts with a simulator S. The first game is Gameev-auth . In each subsequent game, a new “event” is introduced. S aborts, whenever A this event occurs. We show that each event can only happen with negligible probability for any PPT adversary, hence the probability for A to win game Gi+1 , denoted by Pr[wini+1 ], differs only by a negligible amount from its probability Pr[wini ] to win game Gi . G0 The initial game is Gameev-auth , where S plays the game with A by simulating the A honest parties as specified by the protocol. A chooses a platform with a configuration cs P 6∈ CS of his choice (as specified in Section 5.6.1), and S simulates the honest TPM M of this platform. A wins Gameev-auth , and hence G0 , if it manages to A output σ = (C, σM , σr ) such that S (acting as an honest verifier) accepts σ as a proof that cs P ∈ CS , although actually cs P 6∈ CS . Because G0 is Gameev-auth , we A cf-priv κ have Pr[win0 ] = Succ (1 ). G1 In the event that S, acting as a verifier, chooses a nonce Nv that already occurred in a previous protocol run, S aborts the simulation. For this comparison, S records all nonces. As Nv is chosen randomly by S, the probability ε1 of this is ≤ q 2 /2`∅ (which is negligible in the security parameter), where q denotes the number of protocol runs. Hence, Succcf-priv (1κ ) ≤ Pr[win1 ] + ε1 . G2 S simulates protocol execution as before, with the difference that all TPM signatures are obtained from the corresponding signing oracle. In the event that S receives an output (C, σM , σr ) from A, where σM was not created previously by S, the simulation is aborted. In this case, A provided S with a forgery of a TPM signature. The probability εTPM of this event is the probability of a forgery of a TPM signature. Thus, Succcf-priv (1κ ) ≤ Pr[win2 ] + ε1 + εTPM . G1 covers replay attacks by estimating the probability that the same nonce occurs twice, and G2 covers forgeries of TPM signatures. It remains to estimate the probability Pr[win2 ]. We consider two cases: either A wins in G2 by forging the ring signature (with probability εring ), or without it. Since we are interested in the overall probability of A winning in G2 , we do not require from S to detect which of these distinct cases occurs.

84

5.6. Security of the PBA Scheme without TTP If no forgery of the ring signature occurred, but A wins G2 , A must know a secret key r0 matching one of the public keys used to compute the ring signature. Hence, A must 0 know r0 , such that hr = C/g cs j = g cs P −cs j hr mod P for some j ∈ {1, . . . , n}. Because cs P 6= cs j , we have r 6= r0 , thus A could compute the discrete logarithm logg (h) = (cs P − cs j )/(r0 − r) mod Q. The probability of the adversary to win the last game is Pr[win2 ] = εring + (1 − εring ) · εdlog ≤ εring + εdlog , where εdlog is the probability to solve the underlying discrete logarithm problem. Thus, in total, Succcf-priv (1κ ) ≤ ε1 + εTPM + εring + εdlog , which is negligible in κ if the TPM signature and ring signature schemes are secure and the underlying discrete logarithm problem is hard. Note that although our proof is in the standard model, the ring signature scheme in [AOS02] requires the random oracle model. 5.6.2.2. Proof of Configuration Privacy Proof. For the proof of configuration privacy, we demonstrate that Advcf-priv (1κ , n), the maximum advantage over all A in Gamecf-priv , is negligible in κ, even if the adversary is A computationally unbounded. For this, we construct a simulator S that plays Gamecf-priv A with some A, simulating the honest parties. The goal of A is to break the configuration privacy of the PBA scheme, and the simulator’s goal is to break either the perfect hiding property of the commitment scheme or the unconditional signer ambiguity property of the ring signature scheme. We play the game twice. In the first case, we assume that the ring signature is secure and show how S can break the commitment scheme. In the second case, we assume that the commitment scheme is secure, and hence, we show how S can break the ring signature scheme. Case 1. In this case, S is given a commitment C = g cs P · hr mod P with cs P ∈ CS , and plays Gamecf-priv with A. A Once S receives a send query with a nonce Nv from A, it uses C in the PBA protocol execution as the TPM’s commitment (without knowing cs P and r), and creates a TPM signature σM = SignM(skM ; (C, Nv )). The computationally unbounded simulator S can compute α, such that h = g α mod P , and k, such that C = g k = g cs P +αr mod P . Although S knows neither cs P nor r, it can establish n equations k = cs j + α · rj (for j = 1, . . . , n). Thus, S can compute n pairs (cs j , rj ), and create the ring signature σr = SigRing(rj ; {yj }; Nv ), where yj = g αrj = hrj mod P , with any of these rj as a signing key. Because of the signer ambiguity of the ring signature scheme, S can choose an arbitrary rj (for j ∈R {1, . . . , n}). S sends C, σM , and σr to A. At the end of the game, A outputs an index i. S attacks the perfect hiding property of the commitment scheme by using the pairs (cs j , rj ) computed above, and opening the commitment to (cs i , ri ). Because we assume that the ring signature is secure, the probability of S to break the commitment scheme successfully is the probability of A to determine i with cs i = cs P . Thus, a non-negligible advantage Advcf-priv implies that S can break the perfect hiding property. Case 2. In this case, S is given public/private key pairs (yj , xj ) (j = 1, . . . , n) for the ring signature scheme, and access to a signature oracle for ring signatures under this key ring.

85

5. Cryptographic Protocols for Property-Based Attestation S can use the oracle to query ring signatures on arbitrary messages. The unconditional signer ambiguity states that S should not be able to find out which private key was used for signing (although S knows all public and private keys). S chooses k ∈R ZQ , and computes cs j = k − xj mod Q for j = 1, . . . , n. Then, S starts to play Gamecf-priv with A. A k Once S receives a send query with a nonce Nv from A, it computes C := g mod P and σM := SignM(skM ; (C, Nv )). S uses the ring signature oracle to create a ring signature σr on the message Nv , and sends C, σM , and σr to A. At the end of the game, A outputs an index i. Since the commitment C was chosen randomly, the only possibility of A to win Gamecf-priv is to break the signer ambiguity of A the ring signature. S also outputs i to indicate that xi was used to generate the signature, thus breaking the unconditional signer ambiguity of the ring signature scheme.

5.7. Conclusion and Future Work The concept of property-based attestation (PBA) has been proposed to overcome several deficiencies of the (binary) attestation scheme proposed by the Trusted Computing Group (TCG). Among others, the TCG attestation reveals the system configuration to third parties that could misuse it for privacy violations and product discrimination. In this chapter, we proposed two cryptographic schemes for property-based attestation. In our protocols, the TPM has to compute only one commitment and one signature. All necessary operations (random number generation, modular exponentiation, and signature generation) are supported by current TPMs. However, the TCG currently does not specify a command to create and sign commitments to a configuration which is stored inside the TPM. Furthermore, the cryptographic technique used in our second scheme might be of independent interest: We demonstrate how a ring signature can be employed to prove membership in a list. Our protocols can improve privacy for users, because they do not reveal the PCR values directly to the verifier. However, for effective privacy protection, the number of binary configurations with a given property must be large enough; in the extreme case, where only one single binary configuration satisfies a property, our protocols do not achieve any privacy benefits. Moreover, a privacy-preserving cryptographic protocol alone is not enough to guarantee privacy in practice. The verifier could learn additional information about a user’s configuration through other channels, e.g., by OS fingerprinting (see, e.g., [Lyo09]). However, additional countermeasures can be used to eliminate (or at least to reduce) these channels. And most importantly, our PBA protocols prevent that the verifier obtains an exact report of the system configuration that is even cryptographically signed by the TPM – which is a much more serious privacy issue than heuristic guesses about the system. Future work may include the investigation of how to determine meaningful properties. Moreover, a generic approach based on any ring signature scheme, an efficient scheme with a security proof in the standard model (i.e., without using random oracles), and the design of a PBA protocol with sub-linear communication and computation complexity in the size of the configuration set CS are still open problems.

86

6. Anonymous Authentication with TLS and DAA In this chapter, we introduce a solution for a confidential and anonymously authenticated channel based on the two standard protocols Transport Layer Security (TLS) [DR08] and Direct Anonymous Attestation (DAA) [BCC04]. The material in this chapter has been published in [CLR+ 10].

6.1. Introduction Anonymous authentication (see, e.g., [Cha85, SPH99, TS06, NSN05, Lin06]) is a widely studied cryptographic concept that allows to authenticate users (e.g., check if they are authorized to access a service) while maintaining their privacy (i.e., the users’ identities are not disclosed). As an application scenario, consider an online subscription service where users can access contents with their client devices, for instance news sites and services for real-time information about stock market prices. Service provider and users have different objectives, which intuitively may seem to be in conflict: The service provider requires that only subscribed users access the service; users desire to be anonymous because access details are personal and sensitive information (e.g., which stocks they are interested in). Anonymous authentication resolves this issue by providing both authentication (provider’s requirement), and user privacy. A particularly powerful means for anonymous authentication are anonymous credential systems (see, e.g., [Cha85, CL01]): Users obtain credentials from an issuer and can use them to access (online) services from different providers, but their communication remains unlinkable even in case the providers collude with the issuer. Basing on such systems, it is possible to extend classical authentication primitives to take into account the privacy aspects of the users. Unfortunately, the direct application of fully anonymous credential systems in practice, e.g., for online subscription services, poses a serious problem: Dishonest users can share their credentials with others, hence allowing a potentially very large group of (actually unauthorized) users to access the service. With a fully anonymous solution implemented in software, this cannot be prevented, because users can just copy all necessary authentication data (i.e., the credential). To some extent, this threat can be mitigated by using pseudonyms instead of full anonymity: The service provider might detect if a single pseudonym is used too often within a short period of time and thus conclude that the credential has been shared. As an alternative, a valuable secret (e.g., a master key that is important to the user) can be embedded into the credential in such a way that users have to share this secret in order to share their credentials. For this to work as intended, all users of the system need to have such a valuable secret that they do not want to share with others.

87

6. Anonymous Authentication with TLS and DAA As we elaborate in related work below, current solutions either do not consider sharing of credentials explicitly [SPH99, Lin06, NSN05, TS06], they offer the possibility to use pseudonyms [BBC+ 09, BLP05, Cha85], or they support all-or-nothing sharing [CL01, BBC+ 09]. As another solution, hardware security modules can be used to prevent users from copying credentials. At a first glance, this approach seems to be an expensive specialpurpose solution with limited applicability. However, current PCs are already equipped with a cost-effective security chip, the Trusted Platform Module (TPM) [Tru07b]; this device implements a hardware security module specified by the Trusted Computing Group (TCG) [Tru11].1 As described in Section 3.3, the TPM supports a cryptographic protocol called Direct Anonymous Attestation (DAA) [BCC04, Tru07b] that is a kind of anonymous credential system. DAA mitigates a major privacy issue: Each TPM is endowed with an encryption key, called Endorsement Key (EK), which is embedded at manufacturing time and, together with its certificate, represents a unique cryptographic identity for the TPM. DAA allows the TPM to create anonymous signatures based on a “credential” that has been issued by a Trusted Third Party, the DAA issuer, which must inspect the EK certificate of the TPM in order to ensure that only genuine TPMs can obtain credentials. Contribution. In this chapter, we propose a generic framework that combines TLS with DAA for implementing an anonymous authentication system. Our framework employs a hardware security module in order to prevent unauthorized sharing of credentials. Our framework is flexible to adapt to different scenarios with different security requirements. We provide a high-security solution based on a TPM as security module, which prevents the sharing of authentication credentials. We also present a pure software implementation (based on a newer version of the DAA protocol [CMS08]), which has better performance, but where sharing of credentials is possible unless additional countermeasures are taken. Our framework supports both full anonymity and pseudonymity, allowing for different business models and enhancements. For instance, our implementation can be combined with remote attestation (a feature to report the integrity state of a platform, supported by the TPM) to achieve an anonymous trusted channel 2 . We provide an implementation based on OpenSSL and the TPM [Tru07b], together with experimental results (see [CLR+ 10]). Related work. Anonymous authentication is a topic that has been studied extensively in the scientific literature (see, e.g., [Cha85, SPH99, TS06, NSN05, Lin06]), and a plethora of cryptographic protocols have been proposed. Although there exist proposals to use secure hardware tokens such as smart cards for anonymous authentication (see, e.g., [Lin06]), to our knowledge the question of preventing clients from cloning authentication credentials has not been considered widely. However, some authors (e.g., in [CL01]) propose all-ornothing sharing. In contrast, our proposal for anonymous authentication is the first to 1

Although recent news about attacks (e.g., [Rob10]) show that TPM chips cannot guarantee security against highly determined and well-equipped adversaries, they still offer security against software attacks as much as any smart card used for security-critical applications, and against basic hardware attacks that do not require costly specialized equipment. 2 A trusted channel is a secure channel ensuring integrity of its endpoints (e.g., [GPS06, AGS+ 08]).

88

6.1. Introduction include detailed protocols and an implementation that prevents cloning based on widely deployed security hardware: The TPM.3 Since their introduction by Chaum [Cha85], various anonymous credential systems have been proposed. Of particular importance for this work is the Camenisch-Lysyanskaya (CL) credential system [CL01]. This scheme forms the basis for all DAA schemes, and hence also for our proposal. Variants of CL credentials based on the strong RSA4 assumption [CL01], and based on pairings over elliptic curves [CL04] exist. Recently, a credential system using strong RSA-based CL credentials, called Idemix, has been implemented within the PRIME project [BBC+ 09, ACK+ 10]. Compared to Idemix, we employ a hardware security module to prevent credential sharing, and our software implementation uses a more efficient pairing-based variant of DAA than the Idemix implementation, which is based on RSA. Moreover, Idemix’ protocols have to be executed over a TLS connection (or another implementation of a secure channel), whereas our solution explicitly combines TLS and DAA. On the other hand, the objectives of PRIME (and Idemix) are set in a much wider scope than just anonymous authentication (which is the topic of this chapter). Bichsel et al. [BCGS09] present an implementation of CL credentials that uses a JavaCard as hardware module, providing portable credentials and multi-application support. This solution prevents credential sharing, provided the JavaCard is secure. However, users need additional hardware (JavaCard and a terminal/reader), whereas our solution uses TPMs that are integrated in many recent computers. Leung and Mitchell [LM07] introduce an anonymous authentication protocol based on DAA. Like our proposal, their protocol uses DAA for client authentication and conventional public key cryptography (based on X509 certificates) to authenticate the server. However, they discuss neither copying of credentials (although by using TPMs their solution prevents this), nor the combination with a standard protocol for a secure channel (such as TLS). Further, they do not present an implementation. Moreover, Balfe et al. [BLP05] propose pseudonymous authentication in peer-to-peer networks by employing DAA with TLS and IPsec, but they only sketch how such results can be achieved. In contrast, we provide a detailed design and implementation. Finally, we note that some vulnerabilities have been found in DAA which may lead to privacy violation (e.g., [SRC07]), and fixes have been proposed. However, since we focus on the design of a general framework that allows to use a generic DAA scheme together with TLS, any strict improvement of DAA that counters these vulnerabilities can be included in our framework, by only fixing DAA implementation without affecting the rest of the system. Other fixes not strictly related to the DAA core (e.g., choice of parameter values) might also require a review of our protocols. However, our design approach (see Section 6.4.2) enables easy protocol updates and flexible DAA version negotiation. Anonymous communication is required by all schemes that are supposed to provide anonymous authentication, otherwise information from the communication system could be used to break the anonymity of the authentication scheme. Various solutions for anonymous communication have been proposed and implemented, including mix networks [Cha81], onion routing [GRS99, STRL00], and Crowds [RR98]. Our proposal does 3

The same solution could be used based on a Mobile Trusted Module [Tru10], specified by the TCG for mobile platforms, if they support DAA (which is optional for MTMs). 4 The strong RSA assumption was introduced in [BP97].

89

6. Anonymous Authentication with TLS and DAA not address the problem of anonymous communication, instead, it can be implemented on top of any such system. Structure. The remainder of this chapter is organized as follows: Section 6.2 introduces objectives and model of our solution, Section 6.3 provides a background on TLS and DAA, and Section 6.4 presents our work in more details. In Section 6.5, we sketch a security analysis, and finally, Section 6.7 concludes the chapter and mentions some future work.5

6.2. Anonymous Authentication: Objectives and Model Requirements. A practical anonymous authentication system should satisfy the following requirements6 : 1. (Correctness) Users with valid credentials must be able to (anonymously) authenticate to the server. 2. (Unforgeability) Users must not be able to forge an authentication, i.e., they must not be able to authenticate without having obtained a valid credential. 3. (Unclonability) Valid credentials must be unclonable, i.e. cannot be copied. 4. (Unlinkability) It must be possible to have unlinkable sessions (also called full anonymity). 5. (Pseudonymity) Alternatively, it must be possible to link sessions. 6. (Practicability) All protocols should be based on well-established standards, and the implementation should based on widely used software libraries and hardware components. R4 and R5 are (mutually exclusive) privacy requirements and express the properties of anonymous authentication. A real system should be flexible and implement both options, to be chosen at runtime. R1, R2 and R3 are security requirements that, in general, should be met by any authentication scheme. However, a non-anonymous scheme, even if using weak credentials like username and password, could allow to identify intrusions and misuse – e.g., by performing a statistical analysis of the accesses – and to revoke the related credentials. With anonymous systems, instead, misuse detection is much more difficult; therefore for an anonymous authentication scheme, R3 is a mandatory requirement which could be optional for non-anonymous systems. R6 emphasizes that realistic solutions must be based on standards, otherwise it is unlikely that they are ever deployed in practice. Furthermore, the solution should allow simple retrofitting of existing applications. 5

A brief description of the implementation as well as timings of DAA primitives and details of the RFC-compliant data structures for TLS-DAA can be found in the full version of [CLR+ 10]. 6 Note full user anonymity (or pseudonymity) requires the prevention of traceability at all communication layers. However, this work focuses on the transport layer only.

90

6.3. Background: Transport Layer Security (TLS)

User U Security Module M

Join protocol

Host H

Join protocol

Service Provider Issuer I

obtain CredDAA

obtain SK

Sign protocol compute σDAA from SK and CredDAA

TLS-DAA Handshake bind σDAA to TLS channel

Verifier V verify σDAA

Application Data (protected by TLS)

Figure 6.1.: Model for anonymous authentication based on TLS and DAA. Model and Overview. We give a model and high-level overview of our solution for anonymous authentication. The protocols are detailed in Section 6.4. Our solution is based on the usage of the TLS protocol together with DAA, which allows either for anonymous or pseudonymous authentication (see Section 3.3.5). Figure 6.1 presents the model of our proposal: A security module M, a host H, an issuer I and a verifier V. The user U owns a platform that consists of M and H – according to DAA design, M carries out the security critical operations, while H computes the more computationally intensive operations – and the service provider plays the role of I to issue credentials (Join protocol) and of V to authenticate U (TLS-DAA Handshake). In this chapter, we consider client anonymous authentication only. However, our solution is designed so that it can be extended with server anonymous authentication (e.g., for peerto-peer scenarios). The Join protocol runs only once at time of subscription. M and H interact with I to obtain a secret key SK , and a DAA credential Cred DAA on SK . When U wants to anonymously authenticate to a service, H engages a TLS-DAA Handshake with V. During the execution of the protocol, M and H compute a DAA signature σDAA using SK and Cred DAA , binding together DAA authentication and TLS session (see Section 6.4.2 for details). After successful verification of σDAA , H and V can exchange data over the secure TLS channel. We designed our framework to be flexible enough to support different variants of DAA and multiple designs and implementations of M. In our solution, M is instantiated by the TCG-proposed TPM, the design of which ensures that the DAA credentials are bound to the TPM and it is not possible to generate a valid signature without using the TPM chip itself.

6.3. Background: Transport Layer Security (TLS) TLS [DR08] is a protocol that provides a secure channel (data authentication, integrity and confidentiality) between a client C initiating the communication and a server S listening

91

6. Anonymous Authentication with TLS and DAA Server S

Client C

ClientHello (with HelloExtensions)

ServerHello (with HelloExtensions), Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone SupplementalData, Certificate, ... ... TLS Handshake continues as usual ... Finished Finished protected application data

Figure 6.2.: TLS Handshake with client Hello Extensions and Supplemental Data messages. for incoming connections. TLS is composed of several sub-protocols. In the following, we will only focus on the Handshake, because the other sub-protocols are not affected by our proposal. To add functionality to TLS, Hello Extensions [BWNH+ 06, DR08] have been standardized: C can propose one or more extensions and S may accept them or not. Since Hello Extensions may deeply change the Handshake flow and affect its security, new extensions must be defined via RFC to be validated. Furthermore, Hello Extensions are backward compatible: By specification, S must ignore any extension it does not know. Hello Extensions are carried over ClientHello and ServerHello messages (of limited size) in a single client-server interaction. Supplemental Data [San06] has been standardized as new Handshake messages SupplementalData (client and server) to transmit supplemental application data during the Handshake, for instance data useful to take authentication and authorization decisions. By specification, Supplemental Data can carry multiple data, SupplementalDataEntry, for different applications; they must be negotiated through a Hello Extension, and must be processed only after the Handshake finishes. In Figure 6.2, we present the Handshake messages that are relevant for our framework.

6.4. Protocols for TLS-Based Anonymous Authentication In this section, we describe our enhancement of TLS based on Hello Extensions and Supplemental Data (cf. Section 6.3) to incorporate DAA for anonymous authentication. We present the Join protocol and the TLS-DAA Handshake, using the TPM as security module. I must run DAA Setup (cf. Section 3.3.5) before the Join protocol starts. Usually, one party – the service provider – will play the roles of both issuer I and verifier V.

6.4.1. Join Protocol Join is a protocol between U and I , to let U obtain DAA credentials: More specifically, M will generate a secret key SK , and H will obtain the associated DAA credential Cred DAA .

92

6.4. Protocols for TLS-Based Anonymous Authentication User U TPM M

Host H

conventional TLS session

Issuer I

Initiate TLS session (unmodified handshake) CredI

verify CredI

conventional DAA Join initiate DAA Join generate SK

Proof that SK is generated in secure environment (within M) CredDAA

Figure 6.3.: Join protocol with a TPM as security module: a conventional TLS session is used to protect the communication between host and issuer during the (unmodified) DAA Join protocol. For clarity, a simplified abstract version of DAA Join is shown. This protocol is executed only once, then multiple anonymous TLS sessions with possibly distinct servers can be based on the credentials obtained. Basically, H and I open a conventional TLS session – without any modification – that is used to encapsulate a DAA Join providing integrity and confidentiality of messages exchanged over the network and authentication of I . We recall that in this phase anonymity is not required (in fact, U often must be identified, for instance to collect payments). Our protocol is shown in Figure 6.3 and proceeds as follows: 1. A conventional TLS session is initiated to protect all subsequent messages from outside adversaries (i.e., attackers that cannot compromise H or I ). 2. H retrieves I ’s credential Cred I and verifies its validity. 3. M, H and I execute the DAA Join protocol as specified by the TCG (cf. Section 3.3.5). For brevity, we only show the main steps here: a) H instructs M to initiate the DAA Join and, as a consequence, M generates SK . b) M and H together prove to I that SK has been generated in a secure environment, i.e. a genuine TPM (cf. Section 3.3.5). c) If the proof is correct, I issues Cred DAA to H.

6.4.2. TLS-DAA Handshake For our solution, we combine DAA with the TLS protocol by defining appropriate Hello Extensions and Supplemental Data for client authentication (formal specification are given in the full version of [CLR+ 10]). In our scenario, the DAA verifier V plays the role of TLS server S and anonymously authenticates H (i.e., the TLS client C) and M.

93

6. Anonymous Authentication with TLS and DAA User U

TPM M

Host H

ClientHello (with DAAAuthExt)

Verifier V

(bsn, nv ) ← DAA Verifier Init() ServerHello (with DAAAuthExt[nv , bsn])

unmodified DAA Sign

KS ← TLS KeyGen() SelfCert S ← X509 CertIssue(KS )

CertificateRequest . . . other TLS data . . .

σDAA ← DAA Sign(CredDAA , bsn, nv , SelfCert S ) Use SK

DAA Sign

SupplementalData (with DAAAuthSupplDataEntry[σDAA ]) Certificate[SelfCert S ] ... TLS Handshake continues as usual ... Finished OK ← DAA Verify(σDAA , PK I , bsn, nv , SelfCert S )

Figure 6.4.: Our anonymous authentication protocol based on TLS (cf. Figure 6.2) and DAA. For clarity, the (conventional, unmodified) DAA Sign protocol is shown without details. We first give an overall description of our solution, then we detail the protocol. H and V negotiate the usage of the anonymous authentication via TLS Hello Extensions. Then H performs a TLS client authentication using SelfCert S , an X509 certificate that must be freshly-generated (and signed by a freshly-generated key) for each different TLS session to guarantee anonymity. Further, H and M run the DAA Sign protocol: They compute σDAA over SelfCert S to prove possession of DAA credentials issued by I in the Join protocol (see Section 6.4.1). Finally, H sends σDAA to V via a Supplemental Data message to be verified. Our protocol relies on the following functions as an interface to DAA7 : • (bsn, nV ) ← DAA Verifier Init() is run by V to generate a nonce nV (used for freshness) and the basename bsn, that can be either fixed for pseudonymity, or the empty string for full anonymity. • σDAA ← DAA Sign(Cred DAA , bsn, nV , m) is run by H to initiate the DAA Sign protocol with M and obtain a DAA signature σDAA on the message m. • OK ← DAA Verify(σDAA , PK I , bsn, nV , m) is run by V to invoke DAA Verify. The details of our anonymous authentication protocol are shown in Figure 6.4 and its flow is described below: 1. H starts the TLS Handshake by sending a ClientHello message containing a Hello Extension DAAAuthExt which informs V to use DAA for anonymous authentication. 7

94

For TPMs, the TCG specifies these as part of the TCG Software Stack (TSS) [Tru07a].

6.4. Protocols for TLS-Based Anonymous Authentication Complying with TLS best practice, DAAAuthExt contains a list of supported DAA protocols (allowing for future extensions) and DAA operation modes (full anonymity or pseudonymity). 2. V uses the function DAA Verifier Init to generate nV and bsn. Then, in the ServerHello message, V sends to H the Hello Extension DAAAuthExt, that contains the chosen DAA protocol, operation mode, nV and bsn. For full anonymity, bsn is left empty. Moreover, V requests the TLS client authentication by sending a CertificateRequest message. 3. H prepares for the anonymous authentication by generating a new key pair KS for TLS client authentication (e.g., an RSA or DSA key pair), and issuing a self-signed certificate SelfCert S for this key8 . For full anonymity, SelfCert S must not contain any data that might identify U; for pseudonymity, it may contain additional data useful to link U’s sessions. 4. H invokes the DAA Sign function, resulting in running the DAA Sign protocol between H and M to obtain a signature σDAA on SelfCert S . For this, H and M use respectively Cred DAA and SK obtained during the Join protocol. 5. H sends σDAA to V in a DAAAuthSupplDataEntry carried by the client SupplementalData message, and sends SelfCert S in the ClientCertificate message (as during the standard TLS Handshake). 6. Then the TLS Handshake continues as usual. As in a conventional TLS session, H authenticates by computing a signature with KS over all messages previously exchanged between H and V. 7. After the Finished messages have been exchanged, V verifies σDAA by invoking DAA Verify to validate the anonymous authentication9 . We assume V has its own list of trusted DAA issuers, including the issuer’s key PK I . In case of pseudonymity, V runs the DAA Link algorithm with input σDAA and signatures previously received. How V handles the output of such an algorithm is applicationdependent and out of the scope of this work. Discussion. An alternative to using Supplemental Data would be defining a new ciphersuite for TLS where the client authenticates with a DAA signature instead of, e.g., an RSA signature (note that this solution would also require the use of Hello Extensions for negotiating security parameters). We chose to use Supplemental Data mainly for flexibility reasons: Different versions of DAA have different optional features that may require to exchange additional data. For instance, the TCG specifications [Tru07a] offer the possibility to selectively reveal attributes of the credential and introduce new DAA principals (e.g., 8

Note that it is possible to precompute and store several keys KS with their certificates SelfCert S for use in later sessions. If pseudonymity is in use, it is possible to optimize the process by generating only one single KV and SelfCert V for each verifier instead of for each session. 9 The verification of σDAA is delayed until this step to comply with [San06]: To prevent a modification of the normal protocol flow, it mandates that the Supplemental Data are ignored until the TLS handshake finishes; any action involving the data carried by SupplementalData must be performed after the handshake is completed.

95

6. Anonymous Authentication with TLS and DAA the Anonymity Revocation Authority); therefore, in the TCG version of DAA, additional information may be exchanged. Moreover, our framework is adaptable to scenarios which require to transport additional data between client and server (e.g., information about the platform configuration). Finally, encapsulating the DAA signature into Supplemental Data allows to define a specific optimization for reconnecting to the same hostname (see [CLR+ 10] for details). Implementation and Efficiency. A prototype based on OpenSSL [The11] has been implemented according to a modular architecture, showing that (i) TLS-DAA using current TPM hardware is practical, albeit very slow (because of the slow computation of DAA primitives by the TPM) and (ii) TLS-DAA using a software implementation of a modern ECC-based DAA variant is quite efficient. In [CLR+ 10], we elaborate on the implementation and efficiency aspects.

6.5. Security Considerations As explained in the following, the security of our solution is based on the security of DAA and TLS. For both protocols, security proofs in (idealized) formal models exist (see, e.g., [BCC04, GMP+ 08]). In this section, we give an informal analysis of our protocols with respect to the requirements listed in Section 6.2, based on the assumption that DAA and TLS are secure (and are used in a secure mode). Assumptions. For this analysis, we assume that it is infeasible for the adversary A to compromise M. This assumption is motivated by the fact that current TPMs provide (limited) tamper-evidence / tamper-resistance. Moreover, we do not consider so-called relay attacks, i.e., attacks where A poses as a man-in-the-middle between H and V and simply forwards all data that is relevant for authentication. Note that although this allows some limited shared use of credentials among users, it still requires (online) interaction of an authorized M with V for each authentication. Since H could also forward all traffic that it obtains over an authenticated link, this kind of “online sharing” cannot be prevented by an authentication mechanism alone. Informal security analysis. During the Join protocol, I must verify that M is genuine and will provide unclonability of credentials. With TPM, this is done by verifying the EK certificate (cf. Section 6.3 and 6.4). Since the EK is unique to a specific TPM, it is privacy-sensitive data which must not be disclosed to outsiders. In our protocol, the EK certificate is protected by TLS, like all messages of the DAA Join protocol. Our protocols fulfill requirements R1 and R2, because authentication is successful only when the DAA signature σDAA can be verified correctly. σDAA is used to authenticate the certificate SelfCert S used for TLS, hence it is bound to the TLS channel. Thus, the unforgeability of DAA signatures implies that only users with valid DAA credentials can authenticate successfully to V. Breaking requirement R2 implies forging a DAA credential, which would also break the security of the underlying DAA scheme. Unclonability of credentials (requirement R3) is achieved based on the assumption that A cannot attack M. When using a TPM, the DAA secret key SK is protected by the TPM

96

6.6. Lightweight Anonymous Authentication for Embedded Mobile Devices (i.e., when stored outside the chip, it is always encrypted with a key only the TPM can access), and unless the TPM can be attacked successfully (e.g., by hardware attacks), the secret is never disclosed to H and thus cannot be copied. Therefore, our solution meets requirement R3. Unlinkability (requirement R4) follows from the unlinkability of DAA signatures and from the fact that SelfCert S and the corresponding key KS are freshly generated for distinct TLS sessions and do not contain any identifying information. In addition, no other data that allows linking is transmitted. However, in [SRC07], the authors discovered a weakness in the DAA protocol for the case when I and V collude or are under the control of a single party, as in our subscription service scenario. To fix this issue, as suggested in [SRC07], bsn must be chosen properly, which requires additional steps in the protocol (H must either choose bsn, or verify that it has been formed correctly). Such fixes can be incorporated into our solution, but are not implemented yet. The possibility of DAA to provide pseudonymity instead of full anonymity means that, in such case, DAA signatures can be linked to a pseudonym. This implies that our protocols also offer pseudonymous authentication (requirement R5) by using the same bsn for multiple authentications.

6.6. Lightweight Anonymous Authentication for Embedded Mobile Devices For resource-constraint mobile and embedded devices, DAA still imposes a considerable performance overhead. Hence, it makes sense to design specifically optimized protocol variants for anonymous authentication with such devices. In [CDL+ 10], we proposed such an optimized scheme and presented an implementation for ARM TrustZone [AF04]. Our lightweight anonymous authentication scheme for mobile devices prevents copying and sharing of credentials based on hardware security features, as in our TPM-based scheme described above. This scheme provides • Anonymity and untraceability of mobile embedded devices against service providers, • Secure device authentication even against collusions of malicious service providers, and • Support for revocation of authentication credentials. In [CDL+ 10], we prove the security of this lightweight variant of DAA, evaluate the efficiency of this approach, and demonstrate its suitability for mobile devices based on an implementation on ARM TrustZone.

6.7. Conclusion and Future Work In this chapter, we presented an anonymous authentication system combining TLS with DAA. Our system supports both full anonymity and pseudonymity, and prevents credential cloning by employing a hardware security module. We designed our framework to be flexible enough to support different variants of DAA, as well as multiple designs and

97

6. Anonymous Authentication with TLS and DAA implementations of the security module – which is instantiated by the TCG-proposed TPM in our solution. To demonstrate the feasibility of our solution, we implemented a prototype based on OpenSSL, and we provided two implementations for DAA: one employing the TPM, and another as pure software implementing a more recent version of DAA based on elliptic curve cryptography and pairings. Future work might be to consider the extension of anonymous authentication to the server side (e.g., for peer-to-peer scenarios) and the coupling of our pure software implementation of DAA with security mechanisms such as Intel TXT [Int07a] to guarantee credential unclonability, with (hopefully) better performance than our current TPM-based solution. Moreover, our framework could be enhanced with remote attestation to provide anonymous trusted channels.

98

Part III.

Trusted Platform-Based Security and Privacy Architectures with Applications

99

7. A Security Architecture and Offline Attestation for Distributed Computing Distributed computing, such as grid applications and cloud computing, demand increasingly sophisticated functional and security requirements. Current techniques mostly protect the resource provider from attacks by the grid user, while leaving the user comparatively dependent on the well-behavior of the provider. We present the key components for a trustworthy grid architecture and address this trust asymmetry by using a combination of trusted computing and virtualization technologies. We propose a scalable offline attestation protocol, which allows the selection of trustworthy partners in the grid with low overhead. By providing multilateral security, i.e., security for both the grid user and the grid provider, our protocol increases the confidence that can be placed on the correctness of a grid computation and on the protection of user-provided assets. Although the focus of this chapter is on security and not directly on privacy, the possibility to protect potentially sensitive data and code is an essential requirement for effective privacy protection in many practical application scenarios. This is particularly relevant in modern cloud computing scenarios where out-sourcing of data storage and computation is becoming increasingly common. The results presented in this chapter have been published in [LRS+ 07].

7.1. Enhancing Grid Security Using Trusted Virtualization Grid computing, as one of the predecessors of what is now termed “cloud computing”, has been very successful in enabling massive computing efforts. Traditional grid computing has mainly been employed within the academic domain (cf. projects such as SETI@HOME or distributed.net) and, although important, these applications usually have less stringent security requirements than commercial IT systems. The recently developed concepts and terminology in the area of cloud computing comprise a number of different technologies, including grid computing. Hence, grid computing can be viewed as a special case of cloud computing. For the purpose of this chapter, we stick to the more traditional terminology for the sake of precision, and because the results presented here have been developed and published before the widespread acceptance of the term “cloud computing”. However, this does not preclude the application of the concepts from this chapter to other cloud computing scenarios. Security is built into modern grid toolkits (e.g. the Globus toolkit [FKT01]) used at the provider sites (parties that offer resources for use in the grid). Secure channels, authentication, unsupervised login, delegation, and resource usage [FKTT98] are all handled by the toolkit. These mechanisms usually do not protect the grid user (the person or entity wishing to utilize resources). The user is forced to trust the provider, often without the possibility of verifying whether that trust is justified. However, in much of the literature on grid security (e.g., [HKS+ 05]),

101

7. A Security Architecture and Offline Attestation for Distributed Computing the user is not regarded as trustworthy. This trust asymmetry could potentially lead to a situation in which the grid provider causes large damage to the user with little risk of detection or penalty. An attacker might publish confidential data or sabotage the entire computation by providing false results. These problems are most evident in computational grids, especially in mobile code [FPV98] scenarios. Other grids, such as storage or sensor grids, may also suffer from the negative consequences of this trust asymmetry. Because of this problem, companies are reluctant to utilize available grid resources for critical tasks. Given this state of affairs, Mao et al. [MMJZ06] have advocated the use of the emerging Trusted Computing (TC) technology for the grid. In a similar vein, Smith et al. [SFEF06] more closely examine scenarios that could benefit from TC techniques. TC can be used to enforce multilateral security, i.e., the security objectives of all parties involved are taken into account. A trustworthy grid environment that enforces multilateral security would offer a number of benefits. Even sensitive computations could be performed on untrusted hosts. Most personal computers used today possess computing abilities in excess of what is required for casual or office use. These resources could be leveraged to run grid jobs in parallel to the users’ normal workflow and provide the computational power necessary for next-generation modeling and simulation jobs, without costly investments into new infrastructure. Enterprises could utilize the already-present office machines more fully, resulting in an earlier return on their investment. A large percentage of the platforms in large-scale grids are built using general-purpose hardware and software. However, it is easy and cheap for existing platforms to incorporate a TPM (see Section 3.3.1). In fact, the chip is already incorporated into many new generalpurpose computers, hence often already present in the hardware used by existing grids. Therefore, in this chapter, we want to leverage the TPM for security benefits in grid computing. One approach to securing computing systems that process potentially malicious code (such as in many number-crunching grid applications) is to provide a virtualized environment. This technique is widely used for providing “V-Servers,” i.e., servers running several virtual machines that may be rented to one or several users. Although users have full control over the virtual environment, they cannot cause damage outside that environment, except possibly through attempts at resource monopolization, for example, by “fork bombing.” Although virtualization offers abstraction from physical hardware and some control over process interaction, there still are problems to be solved. For example, in the x86 architecture, direct memory access (DMA) devices can access arbitrary physical memory locations. However, hardware innovations such as Intel’s VT-x [Int07b]1 and AMD’s Virtualization Technology [Adv09]2 aim to address these problems and could eventually lead to secure isolation among virtual machines. Virtualization technology can be leveraged for building a trustworthy grid environment, especially because several works, such as [SJV+ 05], have already begun to consider architectures that feature policy enforcement in the virtualization framework. Our Contribution. To address the trust asymmetry in grid computing explained above, we propose a realistic security architecture that uses TC functionality and enforces mul1 2

VT-x (and the Trusted Execution Technology, TXT) were formerly known as LaGrande technology. formerly code-named Pacifica;

102

7.2. Preliminaries tilateral security in a grid scenario. Leveraging a combination of the isolation (between virtual machines) provided by virtualization and a trusted base system, our design is able to protect confidentiality and integrity in a multilateral fashion. We feel our compartmented security design offers a stronger level of protection than many current techniques can provide. Using our security architecture, we propose a grid job submission protocol that is based on offline attestation. The protocol allows a user to verify that a previously selected provider is in a trusted state prior to accessing a submitted grid job, with little overhead and improved resistance to attack. Our protocol also guarantees transitive trust relations if the provider in turn performs further delegations to other providers.

7.2. Preliminaries 7.2.1. System Model and Notation We consider the following abstract model of the grid. A grid user U can attempt to access any grid provider P. Each participant in the grid is considered to be a partner-andadversary that potentially intends to harm other participants but also provides services. A participant can be depended upon to execute a given task correctly only if it can prove its inability to cause damage (break a partner’s security policy). A platform PF is a single physical host. It can host one or more logical participants of either role. We consider delegation to be modeled as one participant being both a provider and a user. Every participant has its own, distinct policy. Each component of PF is an independent actor offering some interface(s) to other components, and usually utilizing interfaces offered by other components. The set of providers and users need not be static, but can grow and shrink dynamically as new resources are being added to the grid virtual organization (VO), and some participants leave the VO. However, joining and leaving are not the focus of this chapter. For our purposes, a job image is a tuple J = (data, C, SPP ), where data may be an invocation to some predefined interface or carry executable code. For security purposes, both input data and executable code have the same requirements and can be protected using the same techniques. Therefore, we do not distinguish between “code” and “data,” and refer to both as data. C represents the credentials of the user U, which may be needed to gain access to the provider P. The user also passes a policy SPU as part of its invocation, which specifies constraints to be upheld for that particular job. The job, once scheduled, can communicate directly with U (subject to the policy SPU ). A platform PF always has exactly one state s describing the status of the TCB rather than a particular VM. This state comprises all code running as part of the TCB. TCB components are critical to the correct functioning of the system and need to be trusted. Adding, removing, or modifying such a component changes s. However, s will not change because of “user actions,” such as installing application software, browsing the web, or executing a grid job. Furthermore, the system will not allow any party (not even system administrators) to alter the TCB without changing s. s0 is the reported state of the platform, possibly different from s. We assume that s and s0 can be encoded as a configuration (or metrics) conf, a short representation of the state (e.g., a hash value) as determined by a measurement facility M (e.g., the TPM) of the platform. A specific aspect of the

103

7. A Security Architecture and Offline Attestation for Distributed Computing user’s security policy SPU is the acceptset, which contains the conf values of all states s considered to be trustworthy by that policy. K denotes an asymmetric cryptographic key pair, with private part SKK and public part PKK . EncPKK (X) denotes a piece of data X encrypted with a public key PKK .

7.2.2. Usage Scenario We consider the following scenario: When a node joins the grid, it generates and publishes an attestation token τ , which can be used by potential partners to obtain assurance about the node’s trustworthiness. Grid users retrieve attestation tokens from different grid nodes and select a token indicating a configuration they are willing to trust. The selection decision is made offline, and incurs negligible overhead on the part of the user. Once an acceptable provider has been found, users can submit jobs that can only be read by the selected node in the configuration they consider as trustworthy. If the node has changed to another configuration, communication will fail. The main advantage of this approach is that the creation of the attestation tokens is decoupled from the process of job submission, while still providing freshness. In addition, these tokens are transferable and their correct creation can be verified without interacting with their creators.

7.2.3. Requirements In this chapter, we focus on security requirements, namely integrity and confidentiality. Providing integrity means protection against unauthorized modifications. For instance, user U should not be able to alter aspects of provider P to elevate its privilege level. Similarly, P should be prevented from modifying U’s job. Both the user and provider may require confidentiality, i.e., they may require their sensitive data be guarded against unauthorized disclosure. U may utilize confidential data as part of J, and demand that this data not be disclosed to any party other than J’s execution environment. Similarly, P may want to ensure that a malicious grid job cannot collect secrets stored on P’s platform (such as signature keys) and forward them to U.

7.3. A Trusted Grid Architecture Figure 7.1 shows the abstract building blocks of our Trusted Grid Architecture (TGA). The hardware platform provides a TPM and untrusted storage. The Trusted Software Layer (TSL) consists of the attestation, grid management, compartment management, and storage management components. The TSL provides both security functionalities and virtualization of the hardware. The TCB consists of the TSL and the trusted hardware components. Security policies have to be enforced by the TCB, but a detailed treatment of policy enforcement is outside the scope of this chapter. Other works, such as [SJV+ 05] and [NJM03], have examined some necessary properties of policy engines. Proper design of a minimum set of trusted services can help to achieve a TCB with the highest possible resistance to attacks. Additional guarantees about runtime behavior and state (e.g., [GPC+ 03b]) may be provided by a dedicated service or as an extension to our attestation service.

104

7.3. A Trusted Grid Architecture

Figure 7.1.: The Trusted Grid Architecture

We now provide an overview of the TGA components (see also the background on trusted platforms given in Section 3.1.1). Hardware: The core trusted hardware componen of our architecture is a TPM (see Section 3.3). Recall that each TPM possesses a number of platform configuration registers (PCRs), at least 16 as of version 1.2 of the specification [Tru07b]. During system boot, the main software components (BIOS, bootloader, OS kernel, etc.) are measured. The measurement procedure involves computing a configuration conf, i.e., the cryptographic hash of the software components, and securely storing the hash in the TPM. For the TGA, we use four TPM operations: secure key generation, measurement, certification, and sealing. The TPM features a hardware random-number generator and implements generation of RSA key pairs K = (PKK , SKK ). For these key pairs, usage limitations can be defined, in particular sealing, which marks the private key as not being migratable and usable only when a specified subset of the PCRs contain the same values as were present during key generation. It is possible to obtain a certificate stating which usage conditions apply to a key pair (as represented by its public key PKK ) from the TPM, signed by one of its Attestation Identity Keys (AIKs; generated by the TPM). The private key of an AIK cannot be extracted from the TPM, i.e., it is non-migratable, and it cannot be used to certify migratable keys. AIKs can be certified by a Certification Authority (CA), or they can be proved to be valid AIKs anonymously by means of Direct Anonymous Attestation (DAA) [BCC04]. Such a certificate or proof is denoted as certCA (PKAIK ). The TPM can report the platform configuration to other parties by signing the values of the PCRs with an AIK, which guarantees that the TPM generated the signed structure because an AIK cannot be used to sign arbitrary data. For our purposes, we use signed KeyInfo structures that are considered as certificates. A KeyInfo structure of a sealed key includes the selection of PCRs that were used for sealing, their values at the time of key generation, the values of the selected PCRs needed to use the sealed key (i.e., the conf of reported state s0 ), and an indication whether a key is migratable. We use an AIK to

105

7. A Security Architecture and Offline Attestation for Distributed Computing sign such a structure with the certifyKey operation of the TPM and denote the resulting certificate by certAIK (PKK ). These restricted keys enable data sealing. Data sealed to a certain configuration of the system is encrypted with a public key whose corresponding private key is accessible only to a certain state and platform. If the data is successfully decrypted, this indicates that the state the key was sealed to is the actual state of that machine. Attestation Service (AS): The AS provides metrics about the state s to remote parties by means of an attestation token τ := (PKAIK , PKK , certCA (PKAIK ), certAIK (PKK )). From conf (contained in certAIK (PKK )), the user U is able to distinguish a trusted state s0 from an untrusted one because the values uniquely identify a set of programs that have been loaded since booting the platform, and possibly also the state of certain critical configuration files. The certificate certAIK (PKK ) identifies the key K as being sealed to conf and gives the assurance that the private key SKK can be used only in the reported state s0 . The user U can make its trust decision “offline” by examining the conf contained in τ . If conf is indicative of a trusted state s0 , SKK will be accessible to the provider P only if P still is in the same configuration. As the token does not change over time, it can be distributed to other parties. If the state s of P ever changed, τ would automatically become invalid, although an explicit revocation might still be beneficial. Further details of this attestation mechanism and its security will be discussed in Section 7.4. Compartment Management Service (CMS): This component creates virtual machines (VMs; also called compartments), which run on top of the TCB, and keeps track of the identity of compartments by assigning a unique identifier (ID) to each of them. The VMs are isolated from each other and can only communicate over well-defined interfaces. The CMS only manages VMs locally and does not address migration or delegation in the grid. Storage Management (SM): The storage component provides trustworthy and nonvolatile storage based on an untrusted hard disk. In particular, data stored by one compartment in one configuration is retrievable only by that compartment in the same configuration – even if the machine has entered an untrusted state in the meantime. To achieve this property, all data is encrypted and MAC-authenticated by a sealed key. Grid Management Service (GMS): The GMS handles the actual grid job submission. It is responsible for receiving jobs, checking their access, and instantiating them. It will use the CMS to create a private compartment for each job. The GMS does any special pre-processing that the job needs before it is ready for execution. Once such pre-processing has been done, a VM image has been created from J, which can then be booted by the CMS. Furthermore, the GMS takes the policy of the user and notifies an enforcement component (not shown in Figure 7.1) of the restrictions and rights declared therein. It also handles the freshness verification of the attestation token τ when a job is submitted (described in Section 7.4).

7.4. A Protocol for Scalable Offline Attestation Attestation is the process of securely reporting the configuration of a party to a remote challenger. The most commonly discussed type of attestation requires a remote challenger to provide a random nonce N, which is then signed (together with a hash over a subset of the current PCR values) by the TPM using an AIK . As freshness is achieved by means of

106

7.4. A Protocol for Scalable Offline Attestation 1. U verifies certCA (PKAIK ), certAIK (PKK ), and conf ∈ accept[U]. Upon verification, U randomly chooses nonces N and N0 , and a session key κ. U sends EncPKK (κ) and Encκ (N) to P. 2. P forwards EncPKK (κ) to M. Common input: attestation token τ = (PKAIK , PKK , certCA (PKAIK ), certAIK (PKK )) U’s input: P’s input:

job J and the accept set accept[U ]

accept set accept[P ] M’s input: SKK , s0SKK , current state s

3. M decrypts κ if s = s0SKK and returns κ to P. 4. P decrypts N and sends Encκ (N, accept[P]) to U. 5. U verifies N and whether accept[P] ⊆ accept[U]; upon verification, U sends Encκ (N0 , J) to P. 6. P decrypts N0 and J, and sends N0 to U. U verifies N0 .

Figure 7.2.: Submission Protocol submit ()

a random nonce, each interaction necessitates a new attestation (and thus, a new TPMgenerated signature). However, TPM signature generation is slow, and TPM commands generally cannot be parallelized. In addition, without appropriate countermeasures, this technique could potentially be vulnerable to a race between a successful attestation and a change of state prior to further interactions depending on the trusted state. If the state of the system changes after attestation has concluded, but before any further interactions take place, this change would not be noticed by the remote party. Also, without connecting attestation to a PKI identity, an attestation challenge could be relayed to a trusted platform by an attacker (by forwarding the trusted platform’s reply to the verifier). Scalable offline attestation is intended to enhance some aspects of current attestation systems. Having an attestation token that can be distributed freely within the VO as an informational item is advantageous, because this token states the current configuration of a provider P, without requiring the prospective user to interact with that provider right away. The user can collect such tokens over time, and select the most appropriate configuration offline. As such a token cannot guarantee freshness, some verification has to occur when the user contacts the provider of his choice. We propose a sealed key approach, in which the provider’s TPM allows usage of the private key only if the provider is in the same state as the key was stored in. The approach partitions the verification of P’s state into two phases: token creation and freshness verification. A provider P creates an attestation token together with its TPM. The attestation service instructs the TPM to create a non-migratable key sealed to a collection of PCRs. Then, the attestation service uses the TPM’s certifyKey operation to create a certificate certAIK (PKK ) with an AIK. The attestation service then constructs the attestation token τ from the public key PKK , the certificate of this key, certAIK (PKK ), the public part of the AIK, PKAIK , and a certificate of the AIK, certCA (PKAIK ). The private key SKK is accessible only in the provider’s state at the time of token generation, s0 , because

107

7. A Security Architecture and Offline Attestation for Distributed Computing the certification is done using the TPM-internal AIK, which cannot be misused, even by the platform owner. The attestation service then publishes the token. Publication of the attestation token τ in effect becomes an advertisement stating that a certain state s0 will be maintained at P. The protocol shown in Figure 7.2 includes the actual submission of the job and addresses freshness verification. If the conf contained in the token is considered good by the user U, then U generates a symmetric session key κ and encrypts the key using PKK . The session key can be decrypted by the provider’s TPM only if its state still matches the state at the time of τ ’s creation, i.e., P’s reported state s0 . Verification of P’s ability to access SKK is sufficient to ensure that P is actually in the state that was advertised by conf. The rationale for including the session key is twofold. First, asymmetric cryptography is by orders of magnitude slower than symmetric methods. Second, the key’s inclusion reduces the necessary TPM operations from the signature generation (in traditional schemes) to a single asymmetric decryption. The submission protocol further guarantees transitive trust. As the job gets delegated from one provider to other providers, it is assured that each party that is entrusted with the job’s data will satisfy the original submitter’s requirements. This is done by ensuring that each platform X that gains control of the user U’s job J must satisfy the condition, accept[X] ⊆ accept[U]. Extensions. To keep platform identities private, our protocol can be combined with DAA (cf. Section 3.3.5), which could be used to certify AIKs. However, as long as a fixed AIK is used (i.e., as long as an attestation token stays constant), protocol runs executed by the same platform are linkable. Thus, pseudonymity can be achieved easily, but to obtain full anonymity (with unlinkable protocol executions), new AIKs would have to be generated for each transaction, hence eliminating the benefit of using attestation tokens. Divising an efficient scheme that combines the benefit of attestation tokens with anonymity could be an interesting aspect of future research. Moreover, as the platform has to reveal its actual configuration, it is in effect exposing potentially sensitive information to another party. Integrating guarantees about configuration privacy into our proposal could be an interesting aspect for future research. In particular, property-based attestation and sealing schemes (e.g., see Chapter 5 and [SS04]) could be integrated into our TGA to address some of the well-known limitations of binary attestation.

7.5. Security Analysis Security of Offline Attestation. The offline attestation mechanism proposed in Section 7.4 is secure against man-in-the-middle attacks. If a user U seals a job to a trustworthy attestation token τ , only the platform in possession of the private part of key K can unseal the job, and only if it is in the state indicated by τ . An adversary cannot decrypt the job, even if it is running on the platform with the TPM that holds the private key, if conf (corresponding to the platform’s current state s) does not match conf 0 contained in τ (corresponding to the platform’s reported state s0 ). Conventional techniques need to include additional verification (such as tying an AIK to a PKI identity) to achieve the same assurance as ours.

108

7.5. Security Analysis Delegation with transitive trust ensures that every provider P that gets a job J can only access J if the provider is in a state s that is trusted by the original submitter U, i.e., conf ∈ accept[U] (where conf corresponds to s). Transitive trust is achieved during delegation without communication with the submitter because the provider that wishes to transfer a job attests other providers offline prior to transmitting the job. The delegating provider P1 acts as user of the new provider P2 and verifies that accept[P2 ] ⊆ accept[P1 ], which immediately implies that accept[P2 ] ⊆ accept[U]. Hence, the policy of the new provider P2 is also acceptable to the original user. Moreover, offline attestation is secure against replay attacks, under the assumption that state changes can only occur between protocol runs. Replaying of old, trustworthy attestation tokens does not help an adversary: the TPM will not allow decryption if the current PCR values do not match the values the key was sealed against. Our protocol has the following drawbacks. Like conventional attestation, our protocol is vulnerable to TPM compromises. A compromised TPM can expose the secret key to an adversary, which enables the adversary to attest to arbitrary states. Revocation of AIKs is necessary to limit the potential damage such attacks may cause. As with conventional attestation, another risk of offline attestation is corruption of the running TCB. If an adversary can corrupt the TCB while the system is running, it could change the system’s state s without changing the PCRs. Thus, s would deviate from s0 , but the TPM would still allow the sealed key to be used. Integrity Protection. Because we can establish a secure (confidential and integrity-protected) channel from user U to provider P using standard tools such as TLS, we need not consider in-transit modifications. Thus, for the purpose of this analysis, P receives an unaltered job J. We need to consider two kinds of integrity requirements for that image: before being instantiated and while executing. As results are reported directly, their integrity can again be achieved by established solutions. If job execution is delayed by the GMS, the job image and policy are stored in trusted storage. The key of the storage service is stored sealed, which guarantees that access to it is granted only to the same job in the same system state. In an untrusted state, no access is granted. Therefore, if a piece of data X in the storage service is altered, the signature of that data item cannot be updated, and the modification is detected the next time the data is retrieved from the storage service. While job J is executing, the isolation properties of our system guarantee that no untrusted application can gain access to the memory regions assigned to J, and hence, integrity is guaranteed. Circumventing such barriers would require breaching the TCB, which would contradict our assumption. As the TCB is based on a virtualization layer, even attack scenarios like “blue pill” [Rut06] are ineffective, because such rootkits can only virtualize conventional systems that do not use virtualization techniques themselves. However, even if such a system were able to virtualize a virtualization layer, it would either need to compromise the TCB, or it would have to be loaded before the TGA (and thus, be measured in the boot process). Confidentiality Protection. The two mechanisms employed for protecting the integrity of stored data and in-memory data also protect confidentiality. The CMS enforces isolation between the VMs and foils in-memory eavesdropping, i.e., one process accessing data inside the virtual memory of another process. Sealing prevents untrusted configurations from

109

7. A Security Architecture and Offline Attestation for Distributed Computing decrypting data stored in non-volatile storage. Violating confidentiality implies breaching the TCB for the in-memory scenario, as the TCB enforces virtualization and therefore, limits each application to its own VM, whereas decrypting stored data outside of a trusted state would necessitate breaking the encryption scheme used, which we likewise consider infeasible.

7.6. Discussion and Related Work Integration of Legacy Systems. To maintain interoperability with legacy systems, we aim to provide the means to continue using applications designed for existing grid toolkits (such as Globus [FKT01]), without giving up the advantages our architecture offers. One possible way for such an integration would be to provide an executable image for each toolkit supported. Whenever an invocation for a service using that toolkit is received, it is instantiated, and the request forwarded to that instance. However, the grid toolkit must be part of the TCB. After all, a malicious provider might use a good base configuration, and put all its attack code into a modified toolkit image. The attestation token τ should contain measurements of all execution environments available as “default installations” on the platform. Thus, the benefits of our proposal become applicable without forcing the user to significantly change its use of the grid. Alternatively, a grid job may consist of a full, bootable VM. While this is a radically different approach from traditional grid methods, it does not imply further trusted code, which is desirable to keep the TCB small and of low complexity. Implementation. We have started implementing the core components of the TGA architecture in the PERSEUS framework [PRS+ 01], which is based on a micro-kernel with paravirtualized Linux. The framework’s design allows its porting to other systems (such as Xen), and features a strong separation of responsibilities even among the TCB (by running services as separate compartments), which significantly simplifies verification. Prototypes of the core TGA components have already been demonstrated in the context of the OpenTC [Ope09b] and European Multilaterally Secure Computing Base [EMS08] projects. Related Work. Several authors have suggested methods to increase the reliability of grid computation without TC technology. For instance, task replication or the introduction of quiz tasks [ZLGD05] to detect misbehaving providers aimed at protecting the integrity of the results of grid computations. However, these techniques are wasteful in terms of resources and often not resistant to multiple colluding adversaries. Using virtualization to improve grid security has been proposed in numerous works (e.g., [CAG+ 06]). Sailer et al. [SJV+ 05, MBC+ 06] investigated the possible enforcement of MAC policies at the level of the virtualization layer. Sailer et al. [SZJvD04] also proposed an integrity measurement architecture for Linux. Such an architecture could be useful for the measurement and reporting of VM states in our TGA. Similarly, although the proposed system of Jaeger et al. [JSS06] focuses on improving the integrity checking of SELinux, its underlying principles could be used for verifying the correctness of the Trusted Software Layer of our TGA.

110

7.7. Conclusion The Daonity (e.g., see [MYC06]) project aims to strengthen the grid security infrastructure by integrating TC technology into the Globus toolkit. However, as Mao et al. [MYC06] remark, the current version of Daonity does not take the operating system into account. For instance, an administrator could bypass the TC-based security mechanisms. To prevent such attacks, a system architecture with virtualization on top of a security kernel, as we propose in this chapter, could be used. Recently, Cooper et al. [CM06] proposed a security architecture for delegation on the grid based on TC and virtualization technologies. They describe a delegation service for enforcing local and global delegation policies. Offline attestation techniques, such as the one we propose, may be useful for their delegation service, whereas our solution in turn could benefit from their idea of enforcing hierarchical policies. Dinda [Din04] proposed a novel scheme to protect the assets of the grid user against a malicious provider in order to address trust asymmetry. Similar to that proposal, encrypted computation (see, e.g., [ACCK00]) offers interesting results for some problems. By performing computations on encrypted data without decrypting it, some tasks can be completed without ever revealing plain text. However, these techniques have limited use outside the domain of some algebraic problems, and their widespread adoption seems unlikely.

7.7. Conclusion In this chapter, we proposed a protocol for scalable offline attestation based on a grid security architecture that uses virtualization and Trusted Computing technology. Our approach allows the grid user to choose a provider with a trustworthy configuration without interaction, by just selecting an attestation token. The attestation token is published by the provider once and does not have to be generated individually for every potential user. The job submission protocol then ensures that the provider can access the job only in the state considered trustworthy by the user. Future work might include the implementation of job migration, the support for nodes joining and leaving the grid dynamically, and the integration of existing grid infrastructure into our trusted grid architecture.

111

112

8. Towards Trusted Privacy Domains In this chapter, we present the concept of privacy domains, a comprehensive security and privacy framework for the protection of sensitive data in networked environments according to user-controlled privacy policies. While the construction of usable and practicable privacy domains for complex application scenarios remains a vision that requires future research efforts, various building blocks and proofs of concepts for limited use cases have been realized. In addition to the vision and framework of privacy domains, we develop technological building blocks and present steps towards the realization. In particular, we present some work in the area of Trusted Virtual Domains (TVDs), an important security concept to enforce policies in networked environments. Moreover, we demonstrate how privacy domains could be applied to protect patient data in an e-health scenario. The material presented in this chapter has been published in [LSVW09, CLM+ 09, CLM+ 10, LPR+ 10] and [LSW10b].

8.1. Trusted Privacy Domains: Vision and Basic Architecture With the growing use of the Internet, users need to reveal an increasing amount of private information when accessing online services, and, with growing integration, this information is shared among services. Although progress was achieved in acknowledging the need to design privacy-friendly systems and protocols, there are still no satisfactory technical privacy-protecting solutions that reliably enforce user-defined flexible privacy policies. Today, the users can assess and analyze privacy policies of data controllers, but they cannot control access to and usage of their private data beyond their own computing environment. In this chapter, we propose a conceptual framework for user-controlled formal privacy policies and examine elements of its design and implementation. In our vision, a Trusted Personal Information Wallet manages private data according to a user-defined privacy policies. We build on Trusted Virtual Domains (TVDs), leveraging trusted computing and virtualization to construct privacy domains for enforcing the user’s policy. A simple privacy policy for trusted privacy domains functioning between different organizations and entities across networks is described as an example. We present protocols for establishing TVDs, extend them for the use of mobile storage devices (such as pen drives, USB disks, etc.) and describe a TVD implementation based on OpenSolaris. Finally, we describe an application scenario in the area of e-health and identify future research challenges in this area.

8.1.1. The Need for Trusted Privacy Domains Global connectivity and easy access to distributed applications and digital services over the Internet changed the paradigm of both business and consumer use of information. The Internet offers new opportunities to individuals, e.g., e-commerce and social network

113

8. Towards Trusted Privacy Domains services. In addition to personal computers, mobile devices, such as smart phones, allow users to access numerous services through mobile networks from any location. Together with the new opportunities, new security threats also developed, rapidly growing in number and sophistication. Some security threats, such as identity theft, one of the fastest growing crimes on the Internet, also can cause privacy violations [Ant10, Eve05]. But privacy issues are much broader: individuals frequently generate and reveal a significant amount of personal and sensitive information when they use a service such as online shopping or social networking. Even if a transaction is not personalized, it always leaves a trail that can be aggregated with other information and analyzed, potentially leading to privacy leaks. Also, as devices access networks and services, information about these accesses can be recorded.1 The users have to trust the application provider to treat their personal data in an appropriate manner, e.g., according to best practices and regulatory requirements reflected in privacy policies. The users can read statements about privacy policies on websites, but the policies do not allow for flexibility in disclosing data necessary to access the service. There are few2 technical means to support this kind of enforcement. Ideally, the users should be able to grant access to their sensitive information only when the systems are trustworthy and should be allowed to revoke this permission. Technical measures in the areas of modern IT security and cryptography provide only partial solutions. Because of the inherent vulnerabilities resulting from high complexity of systems, common computing platforms require careful and attentive system administration skills, and complete protections against execution of malicious code and tampering is impossible.

8.1.2. Framework for Privacy Domains We propose to support the enforcement of privacy policies by establishing trusted domains [LSVW09], termed trusted privacy domains. These policies enable the user (individual or organization) to specify fine-grained instructions for the use of private information. As the level of online activities increases and entities or organizations with complex rules interoperate, the policies may become very complex and benefit from automatic enforcement. The proposed architecture provides mechanisms to protect sensitive and private information across IT domains and systems. The deployment of Trusted Computing technologies for privacy protection can help achieve this goal. To ensure that private information is not re-distributed to unauthorized parties, it needs to be technically bound to only those receivers that are known to comply with the policies. Communication endpoints need to attest reliably to their compliance to specified policies. To enforce policies, we propose a “guardian agent” (cf. [GLSW09]) for the user: a Trusted Personal Information Wallet (TPI Wallet) that controls access to sensitive data as well as the transfer of such data between platforms, and performs “verification” of the trustworthiness of a remote IT system, i.e., compliance to a specified policy. The verification helps to guarantee the enforcement of the user’s privacy policy when sensitive 1

2

Revealing private information is sometimes necessary or unavoidable outside of the Internet (e.g., in supermarkets, due to surveillance, etc.). Although we do not study these methods to gain information about individuals, we note that the revealed information inside and outside the Internet can potentially be linked. Auditing and certification are examples for at least some technology-related methods, e.g., product evaluation according to Common Criteria or certification according to ISO 27001/27002 for information security management systems in enterprises.

114

8.1. Trusted Privacy Domains: Vision and Basic Architecture information is transmitted to remote systems. Figure 8.1 shows an abstract illustration of the proposed concept.

Figure 8.1.: Basic idea of the overall architecture In order to achieve technical enforcement of the security and privacy policies, we develop a security architecture that allows the user to share sensitive information between computing platforms while ensuring the participating platforms have technical means to comply with the policies.

Figure 8.2.: Envisioned architecture for policy enforcement Figure 8.2 shows a high-level view of the process of policy enforcement. A privacy policy in a machine-readable format is incorporated into the wallet. (step 1). The wallet interprets the policy and configures security and privacy services of the underlying computing platform (step 2). The security services enforce the policy by controlling communication between applications in different domains (step 3). To reliably enforce the policy, trusted security & privacy services have to run on all participating platforms, e.g., based on a security-enhanced hypervisor [SVJ+ 05], which allows the system owners to use legacy applications and operating systems in virtual machines, eliminating the need for new client and server side applications. For data transmission, we propose new protocols based on existing attestation schemes of TC technology. When a user or application agent of another platform requests to

115

8. Towards Trusted Privacy Domains access sensitive information (step 4), the security services of the source platform first verify the trustworthiness of the target platform using attestation mechanisms (step 5) to ensure the destination provides the required security mechanisms to enforce the policy. After successful verification, the wallet migrates the requested data (step 6) to another wallet on the target platform (if no wallet is running, a new wallet is started on the destination platform). The wallet on the destination platform acts as policy decision module and configures the security services of the target to enforce the defined policy. Service providers do not need to implement additional functionality on their server side (except for the underlying security layer) to interpret the policy or a clearinghouse for the policy interpretation. The wallet will interpret the policy and use the underlying security services of each platform to enforce it. In the remainder of this chapter, we discuss Trusted Virtual Domains (TVDs) – the main building block for privacy domains – and show how privacy domains based on TVDs can be used to enforce simple user policies. Afterwards, in Chapter 9, we introduce a wallet for protecting users’ login data – which can be seen as a special case of the TPI Wallet.

8.2. Trusted Virtual Domains In this section, we give an overview of the concept of Trusted Virtual Domains – as a building block for privacy domains – and enhance it with protocols that allow (virtual) machines to securely join a domain.

8.2.1. Trusted Virtual Domains as a Building Block for Privacy Domains As a first step towards realizing privacy domains and policy enforcement as described before, we employ the concept of Trusted Virtual Domains [GJP+ 05, BGJ+ 05]. In this section, we briefly review this concept and describe its novel application as privacy policy enforcement as well as our implementation. 8.2.1.1. Concept of TVDs A Trusted Virtual Domain (TVD) is a coalition of virtual and/or physical machines that trust each other based on a security policy that is uniformly enforced independently of the boundaries of physical computing resources. It leverages the combination of TC and virtualization techniques in order to provide confinement boundaries for an isolated execution environment – a domain – hosted by several physical platforms. Moreover, the TVD infrastructure contains a trusted virtualization layer, also called virtual machine monitor (VMM), and the physical components on which the virtual machines (VMs) rely to enforce the policy. In particular, the main features of TVDs and the TVD infrastructure are: • Isolation of execution environments. The underlying VMM provides containment boundaries to virtual machines (also called compartments) from different TVDs, allowing the execution of several different TVDs on the same physical platform. • Trust relationships. A TVD policy defines which platforms (including VMM) and which virtual machines are allowed to join the TVD. For example, platforms and

116

8.2. Trusted Virtual Domains their virtualization layers as well as individual virtual machines can be identified via integrity measurements taken during their start-up. • Transparent policy enforcement. The Virtual Machine Monitor enforces the security policy independently of the compartments. • Secure communication channels. Virtual machines belonging to the same TVD are connected through a virtual network that can span over different platforms and that is strictly isolated by the virtual networks of other TVDs. A TVD-enforcing system supports the creation of virtual networks on physical or virtual systems. Members of a TVD can “see” and access other TVD members, but it is closed to non-members. Different instances of several TVDs can execute on the same physical platform because the underlying virtual machine monitor isolates virtual machines of different TVDs in separate compartments and isolated virtual networks.

Figure 8.3.: Conceptual view of trusted virtual domains (TVDs) Figure 8.3 shows an example of three TVDs (identified by colors) distributed over different physical machines. The decision whether a virtual or real machine is allowed to join the TVD is enforced based on a TVD policy. A special node in the TVD (TVD Master ), e.g., implemented as a central server, controls the access to the TVD by following the admission control rules specified in the TVD policy. These rules include integrity measurements of the platforms and virtual machines that are allowed to join the domain. TC technology is used to establish trust in the reported measurements, e.g., following the Trusted Computing Group (TCG) approach, hash values of the software boot stack (BIOS, bootloader, virtualization layer as well as loaded virtual machines) are stored in and signed by a Trusted Platform Module (TPM) and reported to the TVD Master during attestation (see Section 3.3 for more on the TPM and attestation). The TVD Master can reliably verify whether the reported values comply with the TVD policy and whether it can rely on the enforcement mechanisms of the local platforms.3 3

The definition of the required integrity measurement values in the TVD policy presupposes the knowledge about the security properties of the corresponding software. In practice, trust can be achieved via independent trusted third parties that evaluate and certify IT products according to standards like Common Criteria [Com09].

117

8. Towards Trusted Privacy Domains 8.2.1.2. Related Work on TVDs The TVD concept. TVDs were first proposed by Griffin et al. [GJP+ 05] and Bussani et al. [BGJ+ 05]. Recent research describes secure network virtualization [CDRS07], and discusses the management of TVDs in data centers [BCP+ 08]. The OpenTC project [Ope09b] and related efforts have addressed some areas of implementing TVDs in the context of enterprise rights management [GSS+ 08] and managing virtual data centers [CDE+ 10]. A major issue is how the domain can be managed securely: individual machines must be able to join a domain only if they fulfill the requirements for joining, and the procedures for a platform to leave a domain must be securely constructed. These aspects of TVDs have not been studied in details yet. We describe the TVD establishment and join protocols and how TC functionality is used (see Section 7.6). The idea of applying the TVD concept to secure information sharing has been addressed by Katsuno et al. [KKW+ 06]. We extend this idea to privacy policy enforcement. Previous TVD implementations. To implement a TVD, a security kernel with support for virtualization and Trusted Computing is needed. TVDs have been implemented as research prototypes (see, e.g., [CDE+ 09]), and recently, a Common Criteria protection profile4 for a security kernel with support for Trusted Computing functionality has been certified [LSS+ 09]. Operating systems evaluated and certified according to this protection profile would constitute an appropriate basis for industry-grade TVDs. TVDs have been realized based on different virtualization technologies, for instance, within the research and development projects EMSCB [EMS08] and OpenTC [Ope09b]. Trusted Computing support based on the TPM has been implemented – in particular, the authenticated boot process and attestation functionality of the TPM for the TVD Master to verify the client platform integrity, and for the protection of cryptographic keys. Within EMSCB and OpenTC, two interoperable implementations have been implemented, based on the Xen hypervisor [BDF+ 03b] and the L4 microkernel [Lie95] respectively, with various Linux and Windows versions as guest operating systems. Sirrix security technologies5 is offering a commercial product line called Turaya, which also supports TVDs [CLM+ 10, AH09]. 8.2.1.3. Realizing a Simple Privacy Policy with TVDs Let us consider a very simple privacy policy: only members of a particular TVD have access to the private information. The TVD policy expresses the requirements for virtual machines to join the TVD and to access this information. The TVD policy is used to implement the privacy policy, and the TVD infrastructure provides the policy enforcement for the wallet. TPI Wallet as TVD Master. The TPI Wallet can act as TVD Master. In this case, it is directly responsible for policy enforcement, and no special software agent (apart from the 4

The Common Criteria are an international standard that aims at permitting comparability between the results of independent security evaluations [Com09]. A protection profile is a template for the evaluation of a concrete product: it specifies implementation-independent security requirements for a class of products. 5 See http://www.sirrix.com

118

8.2. Trusted Virtual Domains components of the TVD infrastructure) has to be started on other platforms. All parties that want to access the information have to join the TVD first. As they request to join, the wallet (acting as TVD Master) verifies the security properties of the joining parties using attestation. If the verification succeeds, the joining party becomes a member of the TVD and can then access sensitive information. The wallet can specify a set of “good” values for the platform configuration that are necessary to access the data. Application scenarios for the case where the wallet is the TVD Master include those where the private information of one user is distributed to “homogeneous” data consumers, e.g., in an e-health scenario, the medical data and health records of patients are only accessible to computing platforms of medical personnel, but not to systems used by other departments. TPI Wallet as virtual machine. In other classes of scenarios, where users belonging to a group want to exchange private data, it is unrealistic to have a virtual domain managed by a user’s TPI Wallet. In these cases, a trusted party could provide a TVD Master responsible for policy enforcement for the group. The TPI Wallet of a user who wishes to exchange information within a group could attest the responsible TVD Master (e.g., using TCG attestation) before joining. If this attestation includes both the platform configuration of the TVD Master and the TVD policy, the wallet can ensure that information is only distributed within a TVD, where the master enforces a TVD policy that complies to the user’s own privacy policy. The wallet can migrate to any node in the TVD (using conventional VM migration), or it could transfer data to VMs running on other platforms. The required verification of the security properties of the destination is handled by the TVD establishment. In the next section, we are going to detail the protocols that are used to ensure the trustworthiness of parties that join a TVD.

8.2.2. Implementation of TVD protocols The security objective of our TVD protocols is to enforce that only virtual machines that are allowed by the TVD policy can join the TVD – and only when they are running on a platform with a configuration that is allowed by the TVD policy. Our prototype is based on the idea that a local proxy of the corresponding TVD Master, the TVD Proxy, is running on each physical platform that is supposed to execute virtual machines as part of a TVD. The TVD Proxy is responsible for the local enforcement of the TVD policy and performs the admission control for joining virtual machines. Since instances of multiple TVDs should be able to run isolated on one computing platform, there can be several TVD Proxies (one for each corresponding TVD) on one platform. The main components of the trusted virtualization layer are as follows (see also Figure 8.4): • TVD-Proxy-Factory: service that creates and manages TVD Proxies. During the establishment of the TVD, the TVD Master deploys the policy P and corresponding credentials S (cryptographic keys and certificates for, e.g., network encryption) to the TVD-Proxy-Factory. To “verify” the trustworthiness of the platform and its virtualization layer, the TVD Master requests a remote attestation of the integrity measurements, using trusted computing functionality of a TPM [Tru07b].

119

8. Towards Trusted Privacy Domains • CompartmentManager : service responsible for starting and terminating virtual machines (compartments) and taking integrity measurements of the virtual machines on start-up. This service also defines access rights for communication between active compartments. • TrustManager : service providing an interface to the underlying TPM and used to create new binding keys, generate certificates for these keys, and unbind data encrypted with a binding key. The binding key is protected by the TPM and bound to the integrity measurements of the underlying platform and its trusted virtualization layer. The certificate includes these integrity measurements and permits a remote party to establish a trusted channel to the platform, i.e., a secure channel (providing confidentiality and integrity) bound to the integrity of the endpoint(s).

Figure 8.4.: TVD implementation architecture We have implemented this design based on an existing security kernel, Turaya6 , which comprises two layers: a hypervisor layer based on an L4 microkernel and resource management services (memory management, I/O drivers), and a trusted software layer providing security services, e.g., secure storage, virtualized network, compartment management, and trusted channel establishment. The L4 microkernel ensures isolation of processes and controls inter-process communication (IPC). Compartments can be native L4 tasks or para-virtualized Linux instances (L4Linux). Communication between compartments can be allowed or denied by applying access rights to their IPC interfaces. The microkernel enforces the IPC access control. To support wallet functionality, it is necessary to establish a TVD and attach a virtual machine to the TVD. A TVD is established in two phases: 1. Deploy TVD: First, the local TVD infrastructure must be set up, including the deployment of the TVD policy and TVD credentials from the TVD Master to the trusted virtualization layer of the local platform. 2. Join TVD: When policy and credentials are deployed, the local TVD Proxy enforces the policy and determines if local VMs are allowed to join the TVD. 6

http://www.emscb.com/content/pages/turaya.htm

120

8.2. Trusted Virtual Domains Staged establishment of the TVD was selected to avoid a central admission control that would result in considerable performance trade-offs. In this approach, the TVD policy enforcement is partially delegated to the local platforms, but the TVD Master must verify the trustworthiness (integrity state) of the platforms to establish if they can be trusted. This is done during the deployment phase. For a more detailed treatment of the implementation of TVDs, including the deploy and join protocols, see [CDE+ 09]. 8.2.2.1. Deploy TVD The Deploy TVD protocol has to ensure that the TVD can only be deployed on platforms whose platform configuration is allowed by the TVD policy. Hence, platform integrity is the main requirement to be met by this protocol. When TVD-Proxy-Factory receives a request to deploy a TVD, TrustManager generates a binding certificate cert := (P KBind , CT CB ). The TrustManager uses the TPM to generate a new binding key pair (SKBind , P KBind ), where the secret key part is protected by the TPM and bound to the integrity measurement of the trusted virtualization layer (CT CB ). The TVD-Proxy-Factory requests deployment from the TVD Master of the desired TVD and sends the binding certificate, including the binding key P KBind . Local Platform TVD-Proxy-Factory

TrustMgr TPM

TVD Master

ResourceMgmt

getCert()

cert

generate binding key certify binding key cert := (PK bind , CTCB ) requestDeployTVD(cert)

tvd bind

verify cert tvd bind := bind PK bind (P, S)

unbind (tvd bind ) P, S

(P, S) := unbind SK bind (tvd bind )

createProxy(P ) configureTVD(S)

TVD Proxy

Figure 8.5.: TVD deployment protocol. The TVD Master checks whether the integrity measurement of the platform matches the TVD policy. If it does, the TVD Master encrypts the TVD policy P and the corresponding TVD credentials S with the binding key P KBind , and sends the encrypted data to the local TVD-Proxy-Factory. See Figure 8.5. The TVD-Proxy-Factory requests the TrustManager to unbind the data and retrieves the TVD policy and credentials (P, S). It creates a new TVD Proxy, passes the TVD policy P to it and configures the underlying resource management services (e.g., virtual

121

8. Towards Trusted Privacy Domains network switch) with the credentials S. Now the TVD infrastructure is set up locally and ready to join virtual machines. 8.2.2.2. Join TVD The Join TVD protocol has to ensure that only virtual machines that are allowed by the TVD policy can join the TVD. The protocol is running locally on a platform where the TVD has been deployed previously, and no interaction with the TVD master is required. The user creates the VM using the CompartmentManager. The CompartmentManager measures the integrity of the VM image (i.e., hashing the image file), stores the measurement for future requests (during runtime), starts the VM in a compartment, and returns a compartment identifier (unique during runtime of the platform). The user can request to join the compartment to the TVD by passing the compartment ID to the TVD Proxy. The TVD Proxy obtains the integrity measurement m of the given compartment ID from the CompartmentManager. If the value m is listed in the TVD policy P as allowed to join, the TVD Proxy configures the underlying resource management to connect the compartment to the virtual resources of the TVD, e.g., “plugging” a virtual network connector to the VM.7 Local Platform CompartmentMgr

User

TVD Proxy

ResourceMgmt

startCompartment(image) m := measure(image) create(image)

Compartment

compID joinTVD(compID, tvd )

getMeasurement(compID) m Is m in P allowed? setAccessrights(compID) connectTVD(compID, tvd )

Figure 8.6.: TVD join protocol.

8.2.2.3. Security Considerations In the following, we argue that our two stage deploy/join procedure allows only virtual machines that are admitted by the TVD policy and which are running on platforms with platform configurations that are admitted by the TVD policy to join a TVD. 7

The details of the resource isolation and realization of TVDs on this level are out of scope for this thesis. Cabuk et al. [CDRS07] show how to realize network isolation based on VLAN tagging.

122

8.3. Key Management for Mobile Storage Devices in TVDs Security of Deploy TVD In our Deploy TVD protocol, the TPM creates a certificate (based on the TPM CertifyKey/TPM CertifyKey2 command), which certifies the conditions under which the newly generated binding key can be used, in particular, the PCR values that have to present within the TPM. Assuming a correct TPM as well as a TVD policy that only admits platform configurations with a correct and complete “chain of trust” and security kernel, this implies that the binding key can only be used by legitimate software on a legitimate platform that correctly enforces the TVD policy. As the TVD Master verifies this certificate and encrypts the TVD policy and TVD credentials with the corresponding binding key, it thus ensures that policy and credentials can only be decrypted by the correct platform. Remark. Our protocol does not address how the platform knows which TVD master to contact, and how it is ensured that it is connected to the correct master. We assume that an authenticated channel to the master is set up correctly over which the Deploy TVD protocol is executed. Note, however, that a run of the Deploy TVD protocol with a “wrong” or “rogue” TVD master cannot compromise the security of the “correct” TVD. However, note that in any case, the freshly generated binding key prevents replay of old TVD policies. Security of Join TVD In the Join TVD protocol, the compartment is measured before it is started by the CompartmentManager (in the simplest case, a cryptographic hash of the image is computed). Assuming a correct platform and security kernel as well as a secure measurement procedure, this implies that no virtual machine can impersonate a different virtual machine. Since the TVD Proxy checks the measurement of the virtual machine according to the TVD policy before joining it to the TVD, and because TVD credentials are only deployed to correct platforms running a correct security kernel, only virtual machines that are allowed by the TVD policy can join the TVD.

8.3. Key Management for Mobile Storage Devices in TVDs Mobile Storage Devices, such as USB flash drives, offer a flexible solution for the transport and exchange of data. Nevertheless, in order to prevent unauthorized access to sensitive data, many enterprises require strict security policies for the use of such devices with the effect of rendering their advantages rather unfruitful. Trusted Virtual Domains (TVDs) provide a secure IT infrastructure offering a homogeneous and transparent enforcement of access control policies on data and network resources, however, the current model does not specifically deal with Mobile Storage Devices. In this section, we present an extension of the TVD architecture to incorporate the usage of Mobile Storage Devices. Our proposal addresses three major issues: coherent extension of TVD policy enforcement by introducing architectural components that feature identification and management of transitory devices; transparent mandatory encryption of sensitive data stored on mobile devices; and highly dynamic centralized key management service. In particular we address offline scenarios allowing users to access and modify data while being temporarily disconnected from the domain. We also present a prototype implementation based on the Turaya security kernel.

123

8. Towards Trusted Privacy Domains

8.3.1. Mobile Storage Devices for TVDs Amongst the strengths of TVDs is the transparent enforcement of access control policies – platforms and users logically assigned to the same TVD can access distributed data storage, network services, and remote servers without executing any additional security protocols, while the resources belonging to different TVDs are strictly separated and, thus, remain inaccessible. In this section, we extend the security concept of TVDs to capture the use of Mobile Storage Devices (MSDs) such as portable hard drives and USB sticks, which offer additional flexibility for the transport of data across multiple working locations and devices (e.g., work stations, printers, cell phones, cameras, etc.). The non-triviality of this task results from the diverse security risks with regard to the data stored on MSDs. For example, MSDs can be easily lost or stolen, and consequently the confidentiality of data becomes an issue. Once left unattended by the user, MSDs can be manipulated with the goal to breach the integrity of the data or to disseminate corrupted data or malicious code once the device is re-connected to the enterprise platform. Many security solutions for MSDs adopted in practice rely on a mixture of different techniques. In fact, the choice of appropriate mechanisms is guided by trade-off between their costs and offered benefits [PKvM08, BCG+ 09]. Recent surveys indicate that existing security policies vary across organizations from none to very restrictive ones disallowing MSDs at all [Eur08b, Fab07, Wir08]. The deployment of MSDs is a challenging task for the current TVD model. Indeed, TVD infrastructures that want to take the major advantages of versatility of mobile storage devices have to address two main objectives: On the one hand, they should be efficient enough to reduce the overhead of enforcing security policies; on the other hand, they have to be secure enough to reduce the efforts requested to users and consequently reducing the effects of human errors. In this section, we present an enhanced secure management model for MSDs within the framework of TVDs. We address the usage of mobile storage devices to transport data within a domain by pursuing a separation between data storage and centralized key management. This separation is necessary to achieve offline data access, e.g., to allow a platform that is temporarily disconnected from the domain to process the data while preserving the desired security properties.

8.3.2. Related Work The widespread use of Mobile Storage Devices (e.g., memory cards, USB sticks, transportable solid-state hard disks), that allow users to move files among different workstations, poses several problems, primarily related to data confidentiality and integrity. In order to cope with these problems, cryptographic mechanisms, i.e., encryption and digital signatures are useful means. Cryptographic filesystems [Bla93, CCSP01, LKMS04, KRS+ 03] embed encryption mechanisms into the filesystem operation, featuring a way to encrypt data and metadata without any effort by user level applications. This makes it possible to have good performance and fine-grained security. In particular, the Plutus filesystem [KRS+ 03] features lazy reencryption [BCO05] at the level of single file-blocks and the key rotation mechanism to efficiently generate and manage new encryption keys. Traditionally, cryptographic filesystems provide a client-server architecture in which

124

8.3. Key Management for Mobile Storage Devices in TVDs the former is trusted and features file content encryption, integrity verification and key management and the latter (untrusted) simply acts as storage for encrypted files. Although several encrypted filesystem can be used also to encrypt local storage devices, they best fit the networked scenario. Solutions that focus on local storage encryption vary between full disk encryption enforced by hardware or software security modules and creating encrypted partition on local devices [Mic06, Tru04]. In this case, the aim is guaranteeing the data confidentiality even if the device is stolen and connected to another computer. The Virtual Private File System [WH08] leverages on virtualization to assure confidentiality whereas data is accessed through a possibly compromised operating system. Sensitive applications run in a trusted compartment and access their own separated storage through a filesystem layer that features data secrecy, integrity and recoverability and relies on the untrusted filesystem provided by a virtualized legacy operating system. Encrypted filesystems as those mentioned above are built on top of a specific operating system and are generally not portable. This may introduce inacceptable constrains in a large scale environment. Moreover, distributed encrypted filesystems have, in many cases, their own key management infrastructure which may not be easily interoperable with other existing infrastructures (e.g., PKIs, LDAP). This introduces some redundancies and administrative overhead. Conversely, local storage encryption facilities essentially protect personal devices and workstation and do not feature any distributed key management service. The VPFS also suffers from this shortcoming. In contrast, our solution works for a wide range of applications and operating systems due to the virtualization approach. In fact, any application that can run in a VM transparently benefits from the underlying encryption mechanism. Moreover, it is possible to use the same mobile storage device with its encrypted data on various heterogeneous platforms since the TVD infrastructure provides an abstraction of the underlying encryption mechanism and its key management. Several architectures aim at enforcing sophisticated security policies within large scale and multi-domain environments and are built on top of a filesystem encryption layer. In particular, the Concord framework [SK08] allows organizations to monitor data while it is accessed by mobile equipment and makes it possible to enforce the access policies even in a disconnected scenario. Institution’s data are stored in encrypted form and encryption keys are shared (through a threshold encryption scheme) by a trusted policy enforcer and the user mobile device (e.g., a laptop). In order to access data, the user and the enforcer have to cooperate in order to reconstruct the data encryption key. This approach allows the infrastructure to promptly deny the access to data if it realizes the client has been compromised. In the disconnected scenario, the infrastructure restricts the user privileges to read-only accesses to a subset of organizational data. The role of the enforcer is played by a “disconnected” policy enforcer to which only a limited subset of encryption key shares has been delivered. To the best of our knowledge, Concord is the approach closest to our proposal. In our architecture, Concord’s user machine and policy enforcer are collapsed into the same platform, though as different compartments, namely the virtual machine and the TVD Proxy. However, our solution features a less restricted off-line scenario (Concord’s disconnected mode does not allow users to modify protected data). Moreover, the virtual storage management in TVDs is in general more flexible and transparent to the user. Traceability and reversibility of data modification is an important feature when allowing full data access within the offline scenario and can be achieved through so-called file

125

8. Towards Trusted Privacy Domains versioning services, available both at application level [Tic82, BP01] and at filesystem level [CDB04, MRWHZ04, SGSG03, PB05]. In particular, several recent proposals address security and integrity checks for stored data, as well as verifiable audit trails [SV02, CG09, PBAB07]. However, these systems do not fit our requirements since they have not been designed to handle totally passive storage devices.

8.3.3. Problem Description TVDs (see Section 8.2.1 for background) introduce a homogeneous and transparent infrastructure that aims at the separation between multiple domains with different security and trust policies. Enterprises and other organizations often have to deal with data of more than one security level. As a consequence, they separate their workflows to meet the different security requirements of their domains, e.g., working with confidential (internal) and public documents at the same time. The application of a TVD infrastructure can help these organizations to transparently enforce their security policies. The incorporation and usage of mobile storage devices in TVDs would increase the flexibility of users in their workflows, but poses a challenging task in the design of the overall security architecture. MSDs are regularly employed to store copies of documents that the user may take home or to another office, raw data to be processed elsewhere, or on-the-fly data backups. In particular, MSDs are frequently used offline, i.e., plugged to any platform while it is not connected to the domain network (e.g., a laptop on the airplane). MSD deployment raises several concerns about data confidentiality and integrity. Adversaries could intercept (steal) devices and try to read private data or even to make unauthorized changes. While encryption and digital signatures can achieve confidentiality and integrity of data stored on MSDs, the average human user is likely to be unskilled to properly configure and use standard security solutions. This may increase the probability of human errors and result in ineffective data protection. Moreover, users may feel any security policy as a nuisance that introduces overhead in their tasks and, therefore, try to circumvent or ignore it. One important issue is that MSDs are passive components, thus enforcement of security policies relies on the computer they are connected to. We may assume the policy is correctly enforced as long as the MSDs are used within the TVD boundaries. This assumption is in general no longer true if any MSD is used outside its domain, e.g., when is connected to an outsider computer. Our aim is to extend the TVD model with the benefits of using MSDs, allowing the transparent binding of an MSD to a certain TVD so that only platforms of the same TVD can access the stored data. Deploying MSDs within the TVD requires some refinement to the model due to the following concerns: • Device identification. An MSD can move from a workstation to another without any control by the TVD infrastructure. Hence, whenever an MSD is plugged in, the platform should be able to distinguish the device and the domain this device belongs to. • Dynamic Device Management. Unlike weighty storage devices, MSDs may unpredictably appear and disappear within the domain, according to the users’ needs.

126

8.3. Key Management for Mobile Storage Devices in TVDs This requires the introduction of an MSD management infrastructure in order to handle, e.g., creation and distribution of encryption keys.

8.3.4. The Offline Scenario As mentioned above, MSDs are also used offline (i.e., the policy-enforcing platform is not connected to the domain), which introduces additional security problems. Almost all duties related to policy enforcement (e.g., authentication, key distribution, etc.) rely on interactive protocols. But policy rules may change, platforms may join/leave the domain (and should no longer access data), (disclosed) encryption keys may be revoked (and new ones should be generated and distributed). Whenever a policy change occurs, these changes have to be promptly propagated to all platforms in order to prevent further disclosure or sensitive data. Hence, allowing offline platforms to access domain data stored on MSDs needs to fulfill the following security requirements: • Delegation. Each domain platform should be able to enforce a policy (this means online and offline). For instance, each platform should store locally an instance of the policy and any credentials needed to enforce the policy. • Delayed revocation. The notification of revocation of any platform, compartment, or device to offline platforms is delayed to the time they will re-connect to the domain network. In the meantime, data processed by these platforms and transferred over the domain through a mobile device may be made partially (or totally) invalid because of revocation. In order to validate data on mobile storage devices, every platform should be able to verify whether the data has been processed by a revoked platform. • Authentication and data integrity. Access and data modification should be infeasible for outsiders. • Traceability and recovery. Domain members should be able to track unauthorized data modifications and to reconstruct the previous data layout.

8.3.5. Our Key Management Solution In this section, we describe our solution to incorporate key management for mobile storage into the TVD framework. 8.3.5.1. System Operation Figure 8.7 shows an example TVD-enabled infrastructure in which two different TVDs are deployed. Each physical platform executes one or more virtual machines belonging to one of the existing TVDs. Several MSDs are available to the users and assigned to different existing TVDs. Usage example. A user is working on the virtual machine VM 1 and plugs in a USB pen drive D1 to the platform P1 , e.g., to make a backup of some files. The system on platform P1 identifies the device (see below for details), verifies whether it has been assigned to the

127

8. Towards Trusted Privacy Domains same TVD as VM 1 , and retrieves the cryptographic keys that are used to encrypt and decrypt data on it. At this point, a further refinement of the device access control can be achieved on a per-VM basis. To this end, a set of rules that defines access privileges to each device in the TVD (device access policy) has been added to the TVD policy. For each device, these rules state which operations and privileges (e.g., read, write) are granted to each virtual machine in the TVD. If everything succeeds, the device is made available to VM 1 and can be mounted and accessed by VM 1 , subject to constraints stated by the device access policy (e.g., read-only or write-only). Finally, if it is consistent with the access privileges of VM 1 , the user’s data can be copied. Data stored on D1 can be accessed only by those virtual machines which joined the TVD that D1 has been assigned. In particular, let D1 be attached to platform P3 which runs two virtual machines, V M3 and V M4 (see Figure 8.7). The virtual machine V M3 – which is in the same TVD as D1 – can access D1 , whereas V M4 cannot.

Figure 8.7.: Example of using MSDs in an environment with two TVDs named red and blue, respectively.

We emphasize that device identification, key retrieval, and encryption/decryption are performed automatically by the platform when the device is plugged in. This is completely transparent to VM 1 , and the guest operating system does not need any special software. No additional operation from the user (e.g., further authentication besides login, or providing keys) is required to handle data stored on the device. Moreover, we stress that data encryption is mandatory (as defined in the TVD policy), thus the user cannot choose to not encrypt data once the mobile storage device has been assigned to a TVD. Moreover, mobile storage devices that are not assigned to the correct TVD cannot be attached to VM 1 , hence accidental data leakage on unencrypted devices is prevented.

128

8.3. Key Management for Mobile Storage Devices in TVDs 8.3.5.2. Virtual Storage Management To manage virtual storage containers, we add two components to the virtualization layer of the TVD platforms: an MSD Manager, which recognizes MSDs, and a virtual MSD (vMSD) component, which enforces the TVD policy and handles encryption / decryption of data. With each MSD, a security record containing security-related information is associated and stored in a Domain Device Directory (DDD) at the TVD master. On every platform, Local Device Directories (LDDs) partially replicate the DDD of every domain that has been deployed to that platform (i.e., an LDD caches information from the DDD to enable offline access and reduce communication to the TVD master).

8.3.5.3. Device Initialization New mobile storage devices are assigned to a TVD through an initialization procedure. When an unassigned MSD is plugged in to a platform, the user is asked whether the system may initialize it. The initialization requires the cooperation of the TVD Master. Indeed, the TVD Proxy running on the platform requires the TVD Master to generate the identification record and the security record (see Section 8.3.6.2) for the new MSD. The former is sent back to the platform and stored to the device via the vMSD whereas the latter is saved in the domain device directory and propagated to the requesting platform via the key retrieval procedure. The device access policy can be determined at different levels. Users can explicitly provide the rules they need for their devices, or some general rules, stated both at platform or at domain level can be applied as default policy. Anyway, it is the TVD Master which writes the requested rules to the TVD policy. When an MSD should be removed from a TVD, it can be de-initialized by simply deleting its security record from the Domain Device Directory (see Section 8.3.6.2).

8.3.5.4. Revocation Any user, virtual machine or platform, may leave the TVD for administrative reasons or can be revoked because any kind of corruption has been discovered. In both cases, the administrator has to edit the TVD policy and any other involved data structures at the TVD Master (e.g. the Domain Device Directory). Administrative revocations can be integrated within the setup and configuration procedures featured by the employed network management framework, so that, while modifying the layout of the network, administrators can consistently update the TVD policy. The TVD architecture allows the TVD Master to realize whether platforms or virtual machines have been corrupted when they try to respectively deploy or join the TVD. The consequent failure can be notified to the administrator who can adopt the needed measures through the management facilities. The architecture presented in this section does not feature any mechanism to automatically detect run-time intrusions. We discuss details of revocation in Section 8.3.6.4.

129


8.3.6. MSD Access Control Management In this section we describe the realization of our MSD access control management. First, we briefly describe the enabling technologies, mainly cryptographic primitives we use, followed by a description of the initialization phase, and how the access control of MSDs is handled. Last but not least we present the more advanced feature of key revocation. 8.3.6.1. Building Blocks In our architecture we apply two cryptographic primitives: a symmetric encryption scheme with lazy revocation for data encryption and an identity-based signature scheme for data authentication. Our solution is intended to be independent from the employed cryptographic primitive, so we base our design on a general model like the one discussed in [BCO05]. Therefore, we briefly recall terminology and notation needed in the following. For more details, we refer to [BCO05]. Lazy Revocation A group of users share some data encrypted with the same symmetric encryption algorithm. In general, a validity time (timeslot) is assigned to each key. So, if t is the current timeslot, all keys ki generated at times i < t, are considered revoked. At time t, all group members know the current key kt . Whenever a user leaves the group, the current key is revoked and the new key kt+1 is generated and delivered to the remaining group members. The lazy revocation concept is based on the assumption that protecting old data from revoked users is not necessary since they could have accessed the data already and disclosed it to outsiders or other parties. Hence, previously encrypted data are not re-encrypted, whereas new data will be encrypted with the new key in order to preserve confidentiality. Each user still needs old keys to read data encrypted at previous timeslots. To avoid that participants store all revoked keys, several schemes [BCO06, NSW05] provide users with a single user master key Kt for each timeslot t. Kt can be used to extract all keys ki (0 ≤ i ≤ t). This kind of schemes is characterized by a trusted status for each timeslot t. The initialization algorithm of the lazy revocation scheme generates the initial engine state E0 related to the timeslot t = 0. User master key K0 is derived from E0 . When a revocation occurs, the scheme updates its state taking current state Et to the new state Et+1 , hence, a new master key Kt+1 is derived and delivered. Revoked users still know Kt , but cannot use it to extract the new key kt+1 . Identity-Based Signature Let W = {w1 , . . . , wn } be a group of identities (of users or platforms), represented as binary strings. An Identity-Based Signature (IBS) scheme [GQ90, GHK06] is initialized by a trusted Key Generation Center (KGC) which generates the master secret key SK and the corresponding master public key P K. Then, using SK and an identity w, KGC can derive the appropriate secret signing key SKw , which it then securely transports to w. This allows w to generate own signatures σw on any message of its choice, which can be verified by others using the identity w and the master public key P K. 8.3.6.2. Initialization For each TVD, we assume a TVD Master, which is always online in order to handle new key retrieval requests from the various platforms. The TVD Master creates and manages

130

8.3. Key Management for Mobile Storage Devices in TVDs for each mobile storage device the states Et and master keys Kt for lazy revocation, as well as the master secret key SK and master public key P K for the identity-based signature scheme. To allow each platform to verify signatures made by the TVD Master, we assume a public-key infrastructure that enables the TVD Master to issue certificates for new master public keys. In particular, the initialization (“coloring”) of a new mobile storage device D for a TVD works as follows. Let the TVD be identified by (have the color) tvdID. Assume M to be the TVD Master of tvdID. Once the blank device D is connected to a platform P, the Virtual Storage Management of P formats the device and requests the local TVD Proxy belonging to tvdID to generate an identification record IR for the device. The TVD Proxy contacts the TVD Master to issue the record containing a newly generated device-id d and tvdID. Figure 8.8 shows the corresponding protocol. Platform P Storage Mgmt

MSD D

TVD Proxy

ResourceMgmt

attach to P request IR

request new IR generate (m, E0 , PK , SK ) derive SK M from SK store {d, (E0 , PK , SK , W, RL)} in DDD

format D

send IR, r

derive SK P from SK derive K0 from E0 IR := d, tvdID, sig SK M (d, tvdID) r := {d, (K0 , PK , SK P , W, RL)}

store r in LDD send IR store IR

Figure 8.8.: Device coloring protocol. Beside the creation of the identification record, M also initializes encryption and signature schemes for D. M creates the tuple (E0 , P K, SK, W, RL), where E0 is the initial state of the symmetric encryption scheme, P K is the master public key and SK the master secret key for the IBS scheme, W is the set of writers (it is given as input to the initialization procedure) and RL, initially empty, is the set of revoked writers. All these information associated to D are stored in a newly created entry in the Domain Device Directory (DDD) on M. M derives its own signing key SKM from SK. M signs the identification record (d, tvdID) under SKM and sends the result IR := (d, tvdID, sig[SKM ](d, tvdID)) to the TVD Proxy, which in turn stores it to the device. Now we have D.id = d and D.owner = tvdID. The latter indicates to which TVD the mobile storage device is assigned, i.e., the “color” of the TVD. Note that storing files from different TVDs on the same device is logically equivalent to having one device for each TVD. Here, for simplicity, we consider only the second case. Note that neither Ei nor SK are delivered to any platform, they are stored and processed only on the TVD Master M. Indeed, M distributes to each platform P the key

131

8. Towards Trusted Privacy Domains management record r = (d, (Kt , P K, SKP , W, RL)) where: Kt is the current master key for encryption, and SKP is the signing key of the platform P which was derived from SK by the TVD Master. The record r is stored in the Local Device Directory (LDD) of the corresponding TVD Proxy on P. Device De-Initialization A device can be “uncolored” by deleting its identification record (by formatting it) and erasing its corresponding entries in the global (DDD) and local device directories (LDD). Entries in both directories can have an expiration time, to avoid that the TVD Master keeps information about devices forever. 8.3.6.3. MSD Access Control Mechanism When a device D assigned to the TVD is attached to the platform P, which hosts VMs of the same domain, then the Virtual Storage Management of P extracts the identification record IR from the device. If the device is recognized, i.e., D.owner is this TVD and the signature of IR is valid, then the MSD Manager requests the corresponding TVD Proxy to search for the record indexed by d=D.id in its Local Device Directory in order to obtain the device keys. If the entry is not found because the device has not been attached to this platform yet before, the query is forwarded to the TVD Master M. 8.3.6.4. Revocation of Cryptographic Keys Both encryption and signing keys can be revoked in three cases: • Member revocation: Whenever a platform, VM, or user is no longer member of the domain, the TVD Master updates the encryption key (and revokes the signing key if any). • Key disclosure: Whenever it is known that a key has been disclosed to unauthorized parties (e.g., due to malicious users or compromised platforms), the corresponding key must be revoked. • Expiration: Creating and updating keys are bound to a timer. Suppose that at time t, revocation of kt is requested, M updates the encryption engine taking it from state Et to state Et+1 , derives the new master key Kt+1 . Kt+1 is delivered to platforms that can extract the new encryption key kt+1 . To revoke the signing key SKw , the TVD Master M adds w to the revocation list RL. If the revoked key has to be replaced by a new one, M generates a new writer-id w0 , puts it into the set W of write-enabled nodes and sends it to the node previously known as w. Moreover, M sends the new revocation list RL to all other platforms. All data signed with the revoked key SKw are no longer accepted by any platform. Key revocation may occur asynchronously with respect to device access and the periodical update requests by TVD members. Therefore we setup a key event notification system in which the TVD Master notifies a revocation to all platforms hosting VMs of the domain by raising an appropriate event or alarm. Once the event notification has been received, each online platform renews its keys. Event notifications are queued and are delivered to offline platforms once they connect to the TVD.

132

8.3. Key Management for Mobile Storage Devices in TVDs 8.3.6.5. Offline Scenario We briefly revisit how requirements raised in the offline (but also online) scenario are addressed by our MSD access control management: • Delegation: Once the TVD deploy protocol [LSVW09] has been carried out, the TVD Proxy locally stores an instance of the TVD policy and a certain set of MSD key management records. Hence, it is allowed to enforce the policy and guarantee the access to the subset of MSDs whose keys are stored in the Local Device Directory LDD. • Lazy revocation: Whenever a key revocation occurs, new data, encrypted with the newly generated key, do not overwrite the previous ones, hence, the old data are still available for offline platforms to which the new key has not been delivered. Revoked members, for instance layed-off employees, can still access old data. However, they could have copied the data already before revocation. The only concern is about data encrypted with a key the revoked member possesses, and where the revoked member obtains access to the device after revocation. We distinguish two cases: If data are written by an offline platform, they are encrypted with the old key, and hence are accessible to the revoked member. This cannot be prevented as long as offline writing should be supported. In the case the platform is online when writing, the data are written before revocation. Although it may be the case that the revoked member has never seen that data, we cannot guarantee this, because the data could already have been shared over the TVD network. Depending on the application requirements, we could re-encrypt all data at revocation time to further limit data leakage. However, this would incur performance overhead. • Authentication and integrity are provided by the identity based signature scheme. Data written to a mobile storage device is digitally signed with the key assigned to the platform the device is attached to. Unauthorized changes afterwards can easily be detected by verifying the signature. • Traceability and recovery: Employing a versioning file service allows to keep track of all modification made to the data, enabling offline platforms to access to the most recent version they can decrypt. Moreover, whenever a revocation occurs, it is possible to retrieve and delete all changes performed by the revoked platform. 8.3.6.6. Accessing an MSD Figure 8.9 illustrates how an MSD is accessed by a compartment on an implementation based on the L4 microkernel (see [CLM+ 09] for details). When a physical MSD is connected to the platform, the MSD Manager reads the identification record from the device, and forwards it to the appropriate TVD proxy, which consults the TVD policy. A vMSD is created and obtains the cryptographic keys from the TVD proxy. The vMSD is connected to a compartment according to the TVD policy. Now the compartment can access the MSD, and all cryptographic operations are performed automatically by the vMSD.

133


Figure 8.9.: Attaching a “red” MSD to a TVD platform. 8.3.6.7. Security Considerations Concerning External Storage Introducing external storage into a system can lead to new security risks. It might be easier for attackers to gain physical possession of external devices than to obtain an internal hard disk. However, due to the transparent encryption of all external storage by the TVD infrastructure, outside attackers who are not part of the TVD cannot access the data. Moreover, viruses or Trojan horse programs could be stored on USB sticks that are plugged into a system. On commodity operating systems such as Windows, this is a serious threat because programs from USB storage will be automatically executed when the device is attached, and even when the automatic execution of programs from USB storage is disabled, users could manually start malware-infected programs from USB sticks. With the TVD architecture, we can prevent malware from entering the TVD via USB sticks, because only data from a storage container belonging to the same TVD as a given compartment will be connected to that compartment by the security kernel. Encryption and decryption happens transparently for the compartment of the TVD, and the data cannot be accessed from outside the TVD. For the security kernel, external storage such as a USB disk is just a passive storage device. No programs will be executed from it automatically, neither in the security kernel, nor in any TVD. Malware that is stored on USB sticks from within the TVD cannot be prevented from being read or executed in another compartment of the same TVD (which might be on an different computer system). The TVD infrastructure itself only isolates and protects the TVD from adversaries from the outside, not from malicious software that is already part of the TVD. However, the TVD infrastructure should help to ensure that only secure systems can become members of the TVD by mechanisms such as the integrity verification of all platforms before joining.

134

8.4. Implementing TVDs on OpenSolaris: Usable Secure Desktop Environments

8.4. Implementing TVDs on OpenSolaris: Usable Secure Desktop Environments In this section, we briefly introduce an implementation of TVDs based on the OpenSolaris operating system, as presented in [LPR+ 10]. We leverage several existing operating system features (e.g., lightweight virtualization, multi-level security labels, a secure graphical user interface) and extend OpenSolaris with several components for automated management and policy enforcement to create a usable implementation of TVDs. In contrast to most existing TVD implementations, this work primarily focuses on secure desktop environments and the end-user experience instead of servers and data centers. Common usage procedures that are insecure without additional protection in ordinary environments are realized for TVDs in a secure way: external storage devices are encrypted transparently for the user, copy-and-paste works as usually but is restricted according to a security policy, etc. Moreover, we provide a central management for the administration of working environments and security policies. This includes automated mechanisms for the efficient deployment of images for work flow-specific user environments. While the incorporation of the TVD concept in data centers [BCP+ 08, CDE+ 10] can be expected to be available in the near future, only few research prototypes address the realization on desktop systems [CDE+ 09]. However, a practical and usable implementation of TVDs for end-users must focus on a secure desktop environment and the end-user experience. Hence, in this section, we aim to answer the question whether it is possible to transform an off-the-shelve (secure) operating system, where users may have already certain experience with, into a TVD-enforcing platform that is usable for end-users. For this purpose, we have chosen the OpenSolaris8 operating system because it is freely available, it uses a desktop system that is known from the popular Linux operating system, and offers in addition advanced security features of a multi-level security (MLS) system based on the Trusted Extensions [Fad06], derived from Trusted Solaris [Sun]. In [LPR+ 10], we present our TVD implementation: • We present a secure desktop environment for TVDs that realizes separation of data and applications for each TVD and that offers a transparent encryption of external storage devices according to a TVD policy. We leverage existing security features of OpenSolaris. These include a secure graphical user interface system, Solaris “zones” as isolated execution environments, and Solaris’ support for mandatory access control and labeled virtual networks. • We show how to map the non-hierarchical TVD security model to the MLS system of OpenSolaris. Our implementation does not modify the OpenSolaris kernel nor any of the core security features. Our TVD layer can be installed as additional software package which is integrated into the OpenSolaris security framework. • Our implementation offers an automated mechanism for efficient deployment of zone images, which represent the VMs of a TVD, and has a central management of images and TVD policies, which can be easily maintained by an administrator via a webbased graphical frontend. 8

See http://www.opensolaris.org

135

8. Towards Trusted Privacy Domains • In contrast to most existing TVD implementations, our system has a more usercentric focus and is very easy to set up, manage, and use. For example, the user or administrator is not burdened with the task of key handling and key management. A transparent encryption and automatic key management protects data that is stored on remote network servers or mobile storage devices such as USB flash drives. As our system is based on widely deployed and tested code of OpenSolaris, our solution should be stable and efficient enough to be accepted by end-users as well as security administrators. This is not an incremental contribution because it shows how to realize advanced (non-hierarchical) TVD concepts on an off-the-shelve secure operating system with (hierarchical) MLS support. Our implementation is using standard OpenSolaris components and will be made available for download as open source software.

8.4.1. The Need for a Usable Secure Desktop Environment The problem with existing TVD implementations (cf. Section 8.2.1) is that they are not directly suitable for a desktop environment, e.g., they lack a TVD-specific user interface or they require large virtual machine images to be downloaded. Moreover, they are and not easy to implement [CDE+ 09] and they are not widely deployed or tested by a large user-base. Therefore, a solution for a security system has to be developed with desktop users in mind but without breaking compatibility and familiar user experience. Ideally, we want to have an off-the-shelf operating system that (from a user’s or administrator’s perspective) can be easily transformed to a TVD-enforcing platform, e.g., by installing additional software components and then simply defining the TVD policies as needed. However, commonly used mainstream operating systems lack support for essential security functionality, such as isolated execution environments [LSS+ 09] or secure user interface systems [EMO+ 93, FSW09]. Some of the previously stated requirements and problems are solved by current implementations of multi-level security systems. For example, the freely available Solaris Trusted Extensions (TX) [Fad06], which are shipped with Solaris 10 and OpenSolaris and which originate from Trusted Solaris [Sun], implement military and commercial-grade multi-level security with fine grained mandatory access control on information flow even on the desktop. However, MLS is a hierarchical security model, whereas TVDs are supposed to separate domains, without a specific hierarchy between them. Hence, the nonhierarchical TVD security model has to be mapped onto the OpenSolaris MLS system. Although Trusted Extensions provide network separation, process isolation, and a secure desktop, the TVD concept demands more. The problem is to integrate a central common policy and management into the transformed MLS system to allow features like transparent encryption of external storage. This approach has to fulfill the requirements of a TVD system while allowing a good user experience on the desktop. Moreover, we have constructed a TVD system that is able to fulfill the TVD requirements on the desktop, hence demonstrating that it is possible to use the relatively rigid MLS approach in a dynamic TVD environment.

8.4.2. Realizing TVDs on OpenSolaris The general idea of our architecture is to use the built-in lightweight OS-level virtualization features of OpenSolaris, called zones, for isolation of data and applications. We

136

8.4. Implementing TVDs on OpenSolaris: Usable Secure Desktop Environments Logical TVD Networks

TVD GREEN

TVD RED

TVD RED

TVD BLUE

TVD Layer

TVD Layer

OpenSolaris

OpenSolaris

TVD Platform

TVD Platform

TVD BLUE

TVD RED

TVD GREEN

TVD Layer

OpenSolaris TVD Platform Management Network

TVD Policies Home-Directories Images

TVD Administration

TVD Management

Storage Server

Figure 8.10.: Architecture Overview therefore have designed and implemented an architecture in which the different TVDs are separated from each other by this virtualization technique. A global zone executes the necessary management code, and deploys and starts the virtualized environments (zones) of the TVDs. Our system relies on the OpenSolaris kernel which enforces and provides security features such as mandatory and discretionary access control. For intra-TVD communication, our TVD layer establishes logical links between the virtualized environments on different platforms that belong to the same TVD. This logical network is completely isolated from any network traffic from outside that TVD, thus establishing secure channels between the TVD members. The transmission of policies and keys, as well as management messages, is separated in another logical network which cannot be accessed by any TVD. This management network is also used for accessing the network storage that is provided to every user as persistent storage mechanism. Our architecture is illustrated in Figure 8.10. Secure Separation of Data and Applications One of the main aspects of TVDs is the separation of data and program execution and therefore the isolation and mediation of access to shared resources. In our implementation, the data is isolated by using the OpenSolaris zones, which provide isolation of the execution context of programs running inside of TVDs. As we rely on OpenSolaris features, we can use the existing MLS-aware desktop which is illustrated in Figure 8.11 as a secure GUI. The image shows the trusted path and two applications running in two TVDs on the same desktop. To enforce the separation of the TVDs, we configure the system to forbid copy & paste data transfers between different TVDs and to notify the user with a pop-up. In order to support a centrally controlled management of TVDs, some parts of the OpenSolaris operating system have been modified.

137


Trusted Path

Word processor running in the context of TVD : RED

Word processor running in the context of TVD : BLUE

Forbidden attempt to copy and paste data between TVDs

Figure 8.11.: The OpenSolaris Trusted Desktop (from [LPR+ 10]) To separate the network traffic of different TVDs, we use labeled IP. This implies that – in contrast to some other TVD implementations that virtualize network traffic on ISO/OSI layer 2 (as described in [CDRS07]) – our TVD framework currently only supports IPbased network traffic. However, in particular for desktop environments, support for IPbased network traffic should be sufficient for most application scenarios. The necessary configuration of IP address ranges, as well as the restriction of members of a TVD to the corresponding address range, is centrally managed by the TVD Master. To enforce this network policy automatically, we have implemented a security service in our TVD layer, which configures virtual network connections and parameters whenever a new TVD is added to the platform. Transparent Storage Encryption on OpenSolaris Another aspect of the TVD security model, which is especially important in the context of end-user desktop systems, is the protection of data that is stored on external storage devices. These storage devices can be in data center, e.g., on a file server hosting home directories of users, on some cloud storage service such as Amazon S3, or mobile such as USB flash drives which users can carry around with them. As data isolation is one of the key concepts of TVDs, we have to design the TVD system such that no data can leave the control of the TVD framework. The only case when this is allowed is when the data is encrypted with keys that are under the control of the TVD Master server. As presented in Section 8.3, transparent storage protection for TVDs can be realized by creating encrypted containers that are able to store the data inside of them. These containers do not reveal any information about their content to an adversary. Even file names are protected and cannot be determined by an adversary. The containers could reside on networked storage servers or on storage devices like USB sticks, and their keys are stored by the master which provides the necessary management abilities. When a storage device has stored such an encrypted container and is plugged into the computer, it is instantly recognized by the system and the data is made available to the correct TVD without the need for user interaction. The same is true for remote storage, e.g., encrypted home directories. They are mounted into the right place before the control is transferred

138

8.4. Implementing TVDs on OpenSolaris: Usable Secure Desktop Environments

Access data on a mounted USB stick

Assign new USB stick to TVD Icon to release USB stick

Figure 8.12.: Desktop TVD components for mobile storage devices (from [LPR+ 10])

to the user. We have implemented a security service in our TVD layer on OpenSolaris that transparently realizes the functionalities as described above. Moreover, to offer the user a management option for mobile storage devices (MSD), we have added GUI elements to the system. As we can see in Figure 8.12, the user is able to label new USB sticks, if it is allowed by the policy. Moreover, we added an application that enables the user to safely remove the device from the system again, as depicted in the screenshot.

Architecture Overview Our architectural design follows that of previous TVD implementations (e.g., [CDE+ 09]). The central management component is the TVD Master, which handles most of the configuration automatically. Moreover, it distributes the different policies and encryption keys to the TVD platforms. On the platforms, the TVD Proxy is the central component, created by the ProxyFactory on demand for each TVD. The Proxy and ProxyFactory are responsible for the correct policy deployment and enforcement. Before a Proxy can be created, the CompartmentMgr is instructed to download the requested computing environment, i.e., the filesystem containing applications and their configuration data to be executed in a zone, from the image server. Afterwards, the Proxy obtains the keys that are bound to the TVD for our transparent storage encryption solution. The Proxy invokes the ResourceMgr with these keys to mount the remote home directories. All components of the TVD layer on a platform run in the global zone, which is protected by the OpenSolaris MLS implementation from any access from all other zones. The actual TVDs on the other hand run as non-global zones, which can be seen in Figure 8.13. To enforce isolation of TVDs, zones are assigned multi-level security labels. OpenSolaris enforces a mandatory access control policy based on those labels. Images of zones that can be started in a given TVD are stored on an image server and can be downloaded to platforms that joined this TVD. For efficient zone deployment, we use ZFS data sets. For a detailed description of our implementation refer to [LPR+ 10].

139

8. Towards Trusted Privacy Domains TVD GREEN

TVD RED

Global Zone Image Server

Proxy

NIC

TVD Master

Proxy

ResourceMgr Compartment Mgr

ProxyFactory

Computing Environments

Trusted Extensions

Policy

GUI extension

OpenSolaris Kernel

Figure 8.13.: A TVD Platform in Detail. The components ProxyFactory, Proxy, CompartmentMgr, ResourceMgr, and GUI extension are part of our TVD layer implementation, which is added to the OpenSolaris security framework.

8.4.3. Summary of OpenSolaris TVDs and Future Work In this section, we have shown that it is possible to implement TVDs for end-user desktop systems based on a components-off-the-shelf (COTS) operating system, namely OpenSolaris. Our TVD framework features integrated management and transparent data encryption, an efficient deployment of zone images, and puts a particular focus on usability and ease of administration. Our implementation adds a TVD layer to the OpenSolaris system without any modification to the existing operating system kernel or core security features. All features described in here can be managed via a central administration GUI which creates and maintains the TVD policy. In the future, interoperability with other TVD implementations could be added, because this solution for desktop and existing implementations for data centers complement each other very well and could cover many current enterprise scenarios. Moreover, the OpenSolaris-based prototype still lacks support for the Trusted Platform Module (TPM), which is required to measure and verify the integrity of the whole platform from the startup of the kernel to the deployment of zones. Further work is necessary on securing the network in combination with the TPM to allow the deployment of TVDs in hostile and uncontrolled environments.

8.5. Securing the E-Health Cloud based on Privacy Domains Modern information technology is increasingly used in healthcare with the goal to improve and enhance medical services and to reduce costs. In this context, the outsourcing of computation and storage resources to general IT providers (cloud computing) has become very appealing. E-health clouds offer new possibilities, such as easy and ubiquitous access to medical data, and opportunities for new business models. However, they also bear new risks and raise challenges with respect to security and privacy aspects. In this section, we point out several shortcomings of current e-health solutions and standards, particularly they do not address the client platform security, which is a crucial

140

8.5. Securing the E-Health Cloud based on Privacy Domains aspect for the overall security of e-health systems. To fill this gap, we present a security architecture for establishing privacy domains in e-health infrastructures. Our solution provides client platform security and appropriately combines this with network security concepts. Moreover, we discuss further open problems and research challenges on security, privacy and usability of e-health cloud systems.

8.5.1. Introduction to the E-Health Cloud and Related Security and Privacy Issues The application of information technology to healthcare (healthcare IT) has become increasingly important in many countries in the recent years. There are continuing efforts on national and international standardization for interoperability and data exchange. Many different application scenarios are envisaged in electronic healthcare (e-health), e.g., electronic health records [Gem, SAA+ 06, RHL+ 10], accounting and billing [Kas, Sof06], medical research, and trading intellectual property [HCL+ 10]. In particular e-health systems like electronic health records (EHRs) are believed to decrease costs in healthcare (e.g., avoiding expensive double diagnoses, or repetitive drug administration) and to improve personal health management in general. Examples of national activities are the e-health approach in Austria [SAA+ 06], the German electronic Health Card (eHC) system [Gem] under development, or the Taiwan Electronic Medical Record Template (TMT) [RHL+ 10]. In Germany each insured person will get a smartcard that not only contains administrative information (name, health insurance company), but also can be used to access and store medical data like electronic prescriptions, emergency information like blood group, medication history, and electronic health records. The smartcard contains cryptographic keys and functions to identify the patient and to encrypt sensitive data. The TMT in Taiwan concentrates on a standardized document data structure to ease information sharing, but also contains a similar infrastructure based on smartcards allowing to share and transfer EHRs. A common approach in all these systems is to store medical data in central data centers, which build the core concept of a centrally managed healthcare telematics infrastructure. On the international basis the ISO (Technical Committee 215) [Int] and the Health Level 7 consortium (HL7) [Hea11] define standards for e-health infrastructures. While they also include specifications for security and privacy aspects, their main focus is currently the interoperability and definition of common document exchange formats and nomenclature of medical data objects. Obviously e-health systems store and process very sensitive data and should have a proper security and privacy framework and mechanisms since the disclosure of health data may have severe (social) consequences especially for patients. For example, banks or employers could refuse a loan or a job if the data about the health of a person is available. If health data is leaked outside the system deliberately or accidentally, the responsible health professionals or IT providers would have to face severe legal penalties for violating privacy laws. When addressing privacy regulations with technical solutions, we are faced with a number of difficulties: E-Health systems must accommodate various work flows, not only related to the patients’ medical data, but also accounting and billing of treatments, medication, etc. Moreover, for smartcard-based solutions, the system must ensure that there is some way to access medical data (which might be life-critical in some situations) even if

141

8. Towards Trusted Privacy Domains the owner of the smartcard is unable to authenticate to the system, e.g., because he or she is unconscious. In other situations, data must be accessed when the smartcard owner is not present, e.g., in case a relative buys medication for the patient at a pharmacy. Addressing such issues in an appropriate way presents a major challenge for research and industry. In particular, we can observe that current e-health solutions and standards mainly focus on network security and access control policies, however, they do not address the client platform security appropriately [SLK10], i.e., the security of the software and hardware that is used by health professionals locally. In this section, we discuss the general problems of e-health systems and provide a technical solution for the protection of privacy-sensitive data, which has not been appropriately addressed yet for end-user systems. In particular, our contributions are as follows: • We describe an abstract model of e-health clouds (Section 8.5.2), which comprises the common entities of healthcare telematics infrastructures. Based on this model, we outline three main problem areas for security and privacy (Section 8.5.3), namely (i) data storage and processing, (ii) management of e-health infrastructures, and (iii) usability aspects of end-users. • We present a security architecture for privacy domains in e-health systems (Section 8.5.4) which leverages on modern security technology of commodity platforms. This architecture extends the protection of privacy-sensitive data from centrally managed secure networks to the client platforms of the end-users. For each application area a separate privacy domain is established and it is enforced both centrally and locally on each platform. Our solution presents results from some ongoing research and development e-health projects where our results cover the problem areas (i) and partially (ii). We also discuss the remaining research problems (Section 8.5.5).

8.5.2. Model of the E-Health Cloud This section gives an overview of typical e-health infrastructures as they are available as products or planned to be deployed in national healthcare information technology projects. We present an abstract model of the resulting e-health clouds. In the past, health care providers (such as the family doctor) have stored medical records of their patients on paper locally. This allowed a controlled environment with easy management of data privacy and security: keeping the paper records in a locked cabin at the doctor’s practice. Even the increasing use of personal computers and modern information technology in medical institutions allowed for a moderate effort to manage privacy and confidentiality of individual medical records. This was due to the decentralized and locally managed infrastructure of each institution. But nowadays outsourcing of IT infrastructure (e.g., cloud computing) and other services (e.g., billing processing and accounting for medical practices) leads to a complex system where privacy-sensitive data are stored and processed at many different places. Hence, it becomes attractive to store and process healthcare data “in the cloud” (at outsourced data providers that can be accessed via the Internet). While such e-health systems promise a more cost-efficient service and improved service quality, the complexity to manage data security and privacy increases, too.

142

8.5. Securing the E-Health Cloud based on Privacy Domains In order to identify and discuss the different problems areas, we present first a simple model and then extend it to an advanced model of the “e-health cloud”. We identify the involved parties and main components that are relevant for the focus of this section. Terminology

Throughout this section, we use the following terms:

Health professional : person who delivers health care services, e.g., physician, dentist, pharmacists, etc. Health care provider : organization that provides services of health professionals, e.g., doctor’s practice or hospital. Personal Health Record (PHR): database of medical data objects and health-related data managed by a patient. Electronic Health Record (EHR): database of medical data objects and health-related data managed by health professionals. Note that sometimes the distinction between PHR and EHR is not made clearly in the literature. But due to different legal implications in certain countries (e.g., in Germany) it is important to distinguish between the two. Simple Model of the E-Health Cloud We first consider a simple model that underlies commercial systems like Google Health9 , Microsoft HealthVault10 , and ICW LifeSensor11 . In these systems patients store their own health-related data on certain web servers: the so-called Personal Health Record (PHR). In this model, patients track, collect, and manage the information about their health at online web sites. They can enter dates and periods of sickness, their appointments with doctors, and any other data related to their health. Patients can also import data in their PHRs they get from health professionals, such as x-ray photos or laboratory tests from their family doctor or dentist. The PHRs are stored on a server of a third party in the cloud. The PHR server provider is responsible for ensuring data protection. Typically, patients can define role-based access rights for individual health professionals. For example, they can define full access to their family doctor, but only restricted access to some data to their fitness trainer or health coach. The advantages of such an approach are that the PHR is accessible from everywhere because of the centralized management (IT outsourcing). The patient can easily give one doctor access to data and test results that were determined by another doctor, when the data is stored in the PHR. This can help to avoid double examination. Moreover, due to the individual management of PHRs by the patients, it is expected that people are more aware of their own health. This could reduce the healthcare costs in the long term as well. However, from a technical perspective this model has a great disadvantage regarding patients’ privacy. On the one hand, patients need to manage complex access rights and need to understand their implications. On the other hand, they need to rely on the robustness and correctness of the security mechanisms implemented at the PHR server provider. In general, it may be possible for the server provider to gain access to the data stored in PHRs. 9

https://www.google.com/health/ http://www.healthvault.com/ 11 https://www.lifesensor.com 10

143

8. Towards Trusted Privacy Domains Advanced E-Health Cloud Infrastructure In contrast to PHRs, which are managed by the patients, Electronic Health Records (EHR) are managed by health professionals only. In most countries this involves different legal requirements and a clear distinction between PHRs and EHRs. As a result, infrastructures that involve EHRs are usually more complex than our simple e-health cloud model. Figure 8.14 shows the advanced model, which not only involves more parties (e.g., health insurances), but also includes some technical means to enforce data security and privacy of EHRs.

Other Services

Billing Service

EHR Server

Figure 8.14.: Advanced E-Health Cloud model. Health professionals manage health records of patients and smartcards are used for authentication, signatures, and en-/decryption of data. The general requirement in this model is still the functional and semantic interoperability of the data stored in EHRs. The EHRs are created, maintained, and managed by health care providers, and can be shared (via the central EHR server in the cloud) with other health professionals. But storing and processing EHRs is not the only service that can be outsourced to the cloud. The health care providers can use billing services that manage their billing and accounting with the health insurances of the patients. This is a typical scenario that can be found in practice: Many doctors outsource the billing to third party providers. Those billing services accumulate the billing of several patients for different health insurances, but also for various health care providers at the same time. As a consequence, privacy becomes an even more important aspect in this model because health insurances or billing services should not be able to access private details of EHRs. To protect the EHR data, smartcards are typically used to (1) authenticate health professionals and patients, (2) sign EHR documents to provide authenticity, (3) encrypt the

144

8.5. Securing the E-Health Cloud based on Privacy Domains EHR data before they are stored in the cloud, and (4) authorize the access to EHR data. Data and services of the e-health cloud can only be accessed with special interface connections to the telematics infrastructure boundary. This interface connection is typically a special hardware device that establishes secure network connections via a Virtual Private Network (VPN) to the e-health data centers. Due to the increased privacy requirements, many countries define standards and specifications for national e-health infrastructures that include technical means for security and privacy. However, existing security concepts in e-health concentrate on controlling access to data (e.g., smartcard-based access control to web-based PHRs and EHRs), protection of data transfer (encryption for confidentiality, digital signatures for integrity and authenticity), and network security (firewalls, VPNs). The latter focuses on the separation of different networks, e.g., administrative networks of health insurances from EHR servers and from other applications. However, little care is taken on what happens after access to data is allowed, i.e., how data is processed and stored on end-user client platforms. Viruses or Trojan Horse programs can corrupt data and eavesdrop on patients records, violating both legal and individual privacy requirements. Example: The German electronic Health Card (eHC) system [Gem, Gem09a] under development defines that in the compulsory health insurance system, each patient has an eHC smartcard. The eHC is mainly used for storing administrative data (for billing with the health insurance), but also includes functionality to encrypt medical records that are going to be stored on EHR servers, and to authorize access to EHR data. When a medical doctor wants to upload or download EHR data of a patient, this patient has to provide his/her eHC and to enter a PIN in order to initiate encryption (upload) or to authorize access (download). Moreover, medical doctors have their own smartcard, the Health Professional Card (HPC), which is used to digitally sign documents that are stored in a patient’s EHR, and to authenticate themselves as legitimate medical personnel. Each health care provider has to have a special smartcard reader where the eHC and the HPC are inserted whenever access to the EHR is requested. A special connector locally interconnects the computing platforms of the health care provider with the smartcard reader and the telematics infrastructure. The connector is also used to connect to other networks that provide additional applications, but which are not part of the telematics system itself [Gem09b]. The client platforms and the local networks of health care providers are out of scope of the healthcare telematics security requirements. In addition, when patients want to administer their personal data or manage access rights, they also need to use corresponding client platform systems. In both cases it is completely up to the end-users to secure their systems appropriately. Thus, the software on these computer systems can be identified to be the most likely attack target [SKMK09], as they are standard PC systems with commodity operating systems that offer standard services, e.g., e-mail and Internet access. Other countries in Europe (e.g, Austria [SAA+ 06]) or Asia (e.g., Taiwan [RHL+ 10]) plan similar architectures.

8.5.3. Problems of E-Health Clouds In this section, we give a systematic overview of the threats in the privacy-sensitive context of e-health clouds. The processing of healthcare data of patients has technical, but also

145

8. Towards Trusted Privacy Domains legal problems that one has to deal with. In this thesis, we focus on the technical aspects. We therefore analyze three different problem areas. 8.5.3.1. Data Storage and Processing Security and privacy issues exist where the medical data of the health records are stored and processed, i.e., at the PHR or EHR server and, of course, at the local computer infrastructure of health care providers. Access control mechanisms and data encryption can ensure confidentiality of the medical data, and great efforts are done in this direction in many specifications, such as the German eHC [Gem], and standardizations, such as HL7 [Hea11] and ISO/TC 215 [Int]. Data Centers. Storing privacy-sensitive data in central data centers bears the risk of information leakage to unauthorized entities. Sensitive data must be sufficiently protected, e.g., by means of strong cryptographic encryption. Moreover, it must be possible to administer and maintain the data center without letting administrators gain access to patient data. Client Platforms. The security of end-user systems is another problem that is rarely dealt with. Most specifications that we are aware of define this as “out of scope”. End-user systems are the PCs and network infrastructure at the doctor’s practice or the computing platforms of information systems in hospitals. Especially, medical doctors who run their own small practice do usually not have the competence and time to professionally manage their IT systems to be sufficiently protected against malware threats. On the other hand, they use their computer systems not only for accessing health records of their patients, but also for other applications, such as billing systems, or Internet browser. But today’s commodity operating systems that are used do not offer sophisticated security mechanisms nor are they implemented in a robust way as high-assurance systems. Due to architectural limitations they do not offer sufficient runtime protection of applications and operating system software, they lack information flow control mechanisms and secure user interfaces. All this makes these systems vulnerable to malware attacks that could steal passwords and secret data, or leak privacy-sensitive data to illegitimate destinations on the Internet. Mobile Storage Devices. Moreover, those computer systems are usually used by several persons, e.g., medical assistants, and they may connect them with mobile storage devices, such as USB memory sticks, for transferring data to other platforms. Data that is transferred in this way usually leaves the control of any security mechanisms of the e-health infrastructure. 8.5.3.2. Management of E-Health Infrastructure On a larger scale, the whole infrastructure of an e-health cloud has several risks that threaten the privacy of health data. Both medical and administrative data of patients are processed at several places in the e-health cloud, and the usage of smartcards and access control mechanisms alone does not provide the necessary protection. Cryptographic Key Management. Complex infrastructures must be managed and this comprises additional security and privacy issues. The usage of encryption requires management of cryptographic keys, smartcards must be personalized and issued to their users. One question that is often insufficiently answered in this context concerns who is in control of the cryptographic keys. A naive approach would say the patient of course. But how to

146

8.5. Securing the E-Health Cloud based on Privacy Domains handle lost or stolen cards when the encryption keys are lost as well? Do the card issuer or the EHR server have backup copies of the keys? But backup strategies must also take into account the privacy requirements of health data. For example, in many European countries, and especially in Germany, it is required by law that the patients themselves have the full data sovereignty over their health data. This means no other party is allowed to circumvent privacy decisions and access rights definitions of the patient regarding EHR data. But if the card issuer or even the EHR server providers maintain backup copies of the cryptographic keys for reasons of issuing backup smartcards in case of theft or loss, they could in principle decrypt and access the EHR data directly. Management of Certificates. As in any public key infrastructure, certificates must be managed to ensure authenticity of key holders (smartcards, connectors, server, etc.). This includes issuing and distributing certificates as well as updating revocation lists. Management of Hardware/Software Components. Besides the cryptographic infrastructure, other components must be managed and maintained as well. This includes the hardware and software components that are used at EHR servers, billing servers, and computing devices of health care providers. Security-critical components, such as smartcard readers or connectors to protected networks, should be certified and tested properly. The installation and update of software components requires a secure distribution mechanism. On the one hand, it must be possible to allow changes in software configuration due to legitimate updates. On the other hand, unauthorized and malicious changes (e.g., due to malware attacks), must be detectable to stop further usage or to exclude the infected components from the e-health infrastructure. 8.5.3.3. Usability and User Experience Finally, our third problem area is concerned with the end users, i.e., the health professionals and the patients. If security controls and configurations are too complicated, ordinary people would not be able to use them or would try to ignore or circumvent them. For example, remembering a PIN for the smartcard may be too hard for older patients. People tend to write the PIN on paper or even on the smartcard in these cases, which renders the security aspect of having the PIN at all useless. From the perspective of health professionals, there are other issues. As mentioned before, doctors are not IT professionals and they might be overstrained with the configuration and secure setup of all the software components. Moreover, IT-related tasks that delay their own (medical) processes will disturb them and they will tend to ignore or circumvent them. For example, inserting smartcards and entering PINs in a smartcard reader whenever they want to access an EHR might be too time consuming – or even impossible in case a patient wants to consult his/her doctor via telephone.

8.5.4. Secure E-Health Infrastructure The problem areas above show that e-health clouds impose a variety of security and privacy risks. Ideally, all of them should be solved technically and transparently for the users. In the following we present a technical solution to address particularly the end-user platform security issue. Compared to other efforts, especially national and international standardizations, this topic is not addressed sufficiently.

147

8. Towards Trusted Privacy Domains We propose to base a secure e-health infrastructure on privacy domains to ensure fundamental security and privacy properties. In this section, we first introduce privacy domains for healthcare systems. Then we discuss our realization based on a security kernel and TVDs.

8.5.4.1. Privacy Domains for E-Health In the context of e-health, privacy protection of the patients’ data is a primary concern. Technological solutions should be employed to support legal and contractual regulations. We propose to use privacy domains for the patients’ medical data as a technical measure to support the enforcement of privacy and data protection policies: Systems (e.g., a client PC) must be able to partition execution environments for applications into separate domains that are isolated from each other. Data is kept within a privacy domain, and the domain infrastructure ensures that only authorized entities can join this domain. Moreover, data leakage from the domain is prevented by the security architecture and the domain infrastructure. Therefore, the same system can be used for different work flows that are strictly isolated. Figure 8.15 illustrates the privacy domains applied to our e-health cloud model.

EHR Server

Billing Service

Other Services

Figure 8.15.: Privacy Domains in the E-Health Cloud. For each application a privacy domain is established in the cloud and also enforced on the client platforms of the health care providers. An important aspect for the deployment of any new infrastructure in practice is the integration of legacy systems. With our concept of privacy domains, it is possible to reuse existing applications running on a legacy operating system within a privacy domain. Furthermore, data import into the domain can be accomplished via gateways and filters to connect the privacy domain infrastructure to legacy systems. The Trusted Personal Information Wallet could act as such a gateway, and further control usage of sensitive data by applications. However, a large benefit can already be achieved by employing TVDs to restrict data to their respective domains, as we briefly illustrate in the following.

148

8.5. Securing the E-Health Cloud based on Privacy Domains 8.5.4.2. Application Scenario As an example, consider a doctor who wants to use an accounting software to submit bills to health insurances via a dedicated healthcare network12 , and another system to store and process patients’ medical data. In addition, the doctor needs web access and must be able to send and receive e-mails. These different work flows should be separated from each other: The health insurance should not get access to the detailed medical data, and security problems arising from Internet access and vulnerabilities in the web browser should not influence the accounting process, or have impact on the medical data. Only the correct accounting software may connect to the healthcare network. However, it might be desirable for the doctor to be able to send medical data from an EHR concerning a particular case to a specialized colleague or healthcare organization using the normal e-mail client – but without risking the disclosure of such data to malware that might have infected the e-mail software, or to attackers in the Internet. The accounting software or applications processing the medical data might require specific (perhaps outdated) operating systems (e.g., Windows XP), whereas the web browser (and the operating system on which it runs) should always be updated to include the latest security patches. To achieve these objectives, three privacy domains with different requirements are used. One privacy domain, the accounting domain, is restricted to software authorized to access the accounting network. The doctor uses a virtual machine which is part of this TVD and runs the accounting software. A second privacy domain, the e-health domain, is dedicated to the storage and processing of EHRs. The doctor runs software in this TVD to access a patient’s medical data. A third domain – which is neither part of the accounting domain, nor of the e-health domain – contains untrusted programs such as a web browser (e.g., Firefox) and e-mail client (e.g., MS Outlook). Only this VM is allowed to access the Internet without restrictions; the accounting software is restricted to connect to accounting servers, software in the e-health domain is only allowed to connect to relevant e-health servers. Its software, including the operating system, can be updated independently from the other domains. The graphical user interface shows the different domains framed in different colors to help the user distinguish them from each other. When medical data is stored on external storage (e.g., a USB disk) or transferred to the e-mail client via copy-and-paste, the system automatically encrypts the data with a key that is accessible only in the corresponding privacy domain. The encrypted data can be moved to another machine (either by physically transporting a USB disk, or by sending it via the Internet). When it reaches the correct domain again, the system on the target platform decrypts the data. Encryption and decryption is completely transparent to users – they will only notice that the data can only be read properly with applications executing in the correct privacy domain. To export data to legacy systems a special gateway is introduced. This is necessary, for instance, when medical data have to be accessed by some doctor or hospital that is not (yet) connected to the privacy domain. A dedicated gateway allows for better control of the data. If data export is only possible via a dedicated gateway, unintentional disclosure of sensitive data can be prevented. 12

In Germany, there already exists such a network, called KV-SafeNet [Kas], which is already used by many doctors and healthcare institutions.

149


Unrestricted Internet Access

User

TVD-Master for Accounting-TVD

Secure GUI

Application for processing EHRs

Webbrowser, E-Mail-Client

TVDProxy for E-Health-TVD

Accounting and billing software (e.g., KVSafenet application)

Accounting Server

Webserver

TVDProxy for AccountingTVD TVD-Master for E-Health-TVD

Security Kernel

Hardware

E-Mail Server E-Health Server

Trusted Hardware

Figure 8.16.: TVDs with client platform, servers, and TVD masters. 8.5.4.3. Our Realization using TVDs The major goals of this proposal include the separation of medical data from other data such as billing and accounting, as well as the integration of e-health cards into the system. Our realization is based on Trusted Virtual Domains (see Sec. 8.2). This realization could be extended with a suitable TPI Wallet, e.g., to handle more fine-grained user-controlled policies for specific data such as EHRs. Figure 8.16 shows the structure of a TVD with a client platform and a TVD master for each domain. On the client platform, a security kernel enforces the isolation of the different domains according to the TVD concept, including a secure GUI. As presented in Section 8.3, we extended the TVD model with the benefits of using mobile storage devices, allowing the transparent binding of devices to a certain TVD so that only platforms of the same TVD can access the stored data. In the same way, other external storage – such as storage provided by Cloud Computing – can be incorporated into TVDs. From the point of view of the TVD architecture, the storage service provides a container for data, just like a mobile storage device. In the German eHC system, man-in-the-middle attacks between client platforms and the healthcare telematics boundary are possible because of missing identification and authentication of the corresponding devices, i.e., the connector box and the client platform [SLK10]. In contrast to this, our proposal allows for mutual device authentication based on security hardware modules attached to the devices, such as the Trusted Platform Module (TPM) [Tru07b]. For the communication between the connector and the client platform, a secure channel is proposed, but not enforced in the German eHC system. Encryption of the communication is optional, and an authentication of the devices is missing [SKMK09, SLK10]. In contrast, with our proposed architecture and the usage of TVD technology, all client platforms and software components running on them are authenticated by means of attestation functionality using trusted computing technology [Tru07b]. Only successfully authenticated components and platforms will be able to establish a trusted channel to the central e-health infrastructure in order to access data of the corresponding privacy

150

8.5. Securing the E-Health Cloud based on Privacy Domains domain. As we have seen previously (cf. 8.2), TVDs have been shown to be practical in a number of different contexts. Although some implementations are research prototypes rather than production-ready systems, various implementations based on different security kernels exist, supporting all kinds of operating systems.

8.5.5. Open Research Challenges in the Context of Electronic Health Records There are a number of issues with electronic health data that need to be taken into account by systems for EHRs, which are not completely solved by current proposals: • Absence of the patient: The patient is not necessarily present when the EHR needs to be accessed. In this case, using an eHC with a PIN does not work. For this, various example scenarios exist: Often, the data is entered into the system only after the patient left the doctor. Moreover, the patient is not present at the doctor’s office during preparation of a visit by the doctor at the patient’s home. Furthermore, a patient might not be present in person, but is represented by a relative or friend, or a patient consults a doctor remotely, e.g., by phone. • Inability of the patient to authenticate: The patient might be unable (physically or mentally) to remember and enter a PIN. Examples scenarios include elderly patients and handicapped people who cannot authenticate by entering a PIN. In emergencies, e.g., in case the patient is unconscious, the patient must be represented by someone else. Moreover, in particular people who only need to authenticate infrequently, tend to forget their PINs. • Confidentiality of existence: The mere existence of an EHR for a given person could already imply that this person received medical treatment, and thus must be kept confidential to avoid violating privacy laws. • Client anonymity: Client anonymity is often not considered at all, but in the context of healthcare, a patient’s privacy might be violated by tracking of users or client systems in some scenarios. For instance, if a patient buys medicine in a pharmacy using an electronic prescription, the pharmacist should not be able to trace or identify the patient. • Non-repudiation of emergency access: In case of emergency, health professionals might need to access data urgently in situations, where the patient is unable to authorize this. In such cases, access should be possible, but is important for legal reasons that the person accessing the data can be identified and held responsible. Moreover, this person should not be able to deny the fact that he/she accessed the data. These issues are not adequately addressed by most current e-health systems, and hence are important research challenges to address. Note that solutions to these problems are orthogonal to the network and platform security issues addressed by our work on privacy domains for e-health systems. We anticipate that future solutions can readily be integrated into TVD-based privacy domains.

151


8.6. Remaining Challenges for Privacy Domains and Related Work Privacy policies. Privacy policy languages are designed to translate the privacy policies for users and organizations into statements that can be interpreted by IT systems. In [KCLC07], the authors give an overview of common policy languages. W3C’s Platform for Privacy Preferences (P3P) was designed to express website privacy policies in machinereadable format [CLM+ 02], and P3P Preference Exchange Language (APPEL) is used to express privacy preferences of an individual and to query the P3P data [Cra02, CLM05]. CPExchange was developed to facilitate business-to-business communication about privacy policies [BH00]. For internal privacy policies of organizations, IBM proposed Enterprise Privacy Authorization Language (EPAL) [SAH+ 03]. Another language for describing both privacy and security policies in a machine readable format is the eXtensible Access Control Markup Language (XACML) [Mos05]. Other initiatives, such as DPAL [STM+ 06], and XPref [AKSX03], addressed various aspects of expressing privacy requirements and related concepts. Due to the growth of services that require the transfer of context sensitive information (e.g., time and location), the Internet Engineering Task Force (IETF) initiative started work on Geopriv, a language that can express policies for granting access on the basis of presence and location information [STM+ 06]. In addition to the earlier work on access control policies and (privacy) languages, recent research has analyzed and developed methodologies for evaluating actual policies to compare them with the policies the users desired to use, e.g., Bauer et al. [BCR+ 08] conducted user study of access control policies. Cornwell et al. [CFH+ 07] have analyzed policy management in different applications in mobile computing and developed applications where users can define policies to control the usage of private information, e.g., location-based or contextual information. Sadeh et al. [SHC+ 08] analyzed user interfaces for policy definition and mechanisms for auditing the disclosure of private information. We conclude that, while the need to ensure user control and enforcement of privacy policies was recognized, most research so far focuses on formal languages defining privacy and related policies in various contexts, user requirements for such policies, and approaches for applications to incorporate user controlled flexible policies. However, little attention was given to the mechanisms to support automatic enforcement and interpretation of these policies. In this chapter, we propose an approach to policy enforcement that takes into consideration the results of earlier research, including user requirements and design of formal policy languages. The new framework offers a realistic approach to the control and enforcement of privacy policies in a variety of contexts. We think that TVDs can help construct the privacy domains to support privacy protection of sensitive data that need to be shared. The process to build domains where the protection of sensitive data is governed by privacy policies determined by users still needs to be defined. Policy management for privacy domains remains a major challenge as complex privacy policies need to be enforced within a domain, when a machine joins or leaves the domain, and for inter-domain communication. Trusted Personal Information Wallet. The idea of the Trusted Personal Information Wallet is derived from previous work [GSSW07], which uses a password wallet as authentication agent to access web sites (see also Chapter 9). It protects private data (credentials)

152

8.7. Conclusion of a user during the authentication to a remote server. This approach uses Trusted Computing technology to ensure that the wallet is executed in a trusted environment. In addition to protecting the credentials, some existing “wallets”, in particular SpyBlock [JBM06], protect against the unintentional disclosure of sensitive information (like credit card numbers, name, address, etc.) as a result of malicious transactions [JBM07] (for transaction confirmation based on trusted hardware, see also [FMSW11]). Since the Trusted Personal Information Wallet acts as an agent for the user’s private data and it can migrate data to other platforms, it is comparable to mobile agents. Wilhelm et al. [WSB00] propose to use a tamper-resistant hardware to provide a secure execution environment for mobile agent code. Balfe and Gallery [BG07] outline how attestation can be used to ensure that an agent only visits host platforms behaving in an expected manner and that access to the private agent data complies to the desired security policies. In [XF07], the main approach is the protection of an agent’s private cryptographic key by binding the key to a TPM. In contrast, the wallet (agent) in the framework proposed here does not directly use the TPM, but relies on the TVD infrastructure to (automatically) deploy a trusted execution environment and enforce privacy policies.

8.7. Conclusion In this chapter, we proposed a conceptual framework for privacy policy management and enforcement to ensure security and trust for sharing of private or sensitive information. We as first steps towards the realization of trusted privacy domains, we extended and enhanced the TVD concept in several ways, and showed practical (future) applications: • We presented protocols for TVD deployment on a platform as well as for VMs joining a TVD • We demonstrated how mobile storage devices can be incorporated securely into TVDs. • We presented a TVD implementation for OpenSolaris. • We showed how TVDs can be applied in ehealth scenarios. Moreover, we listed a number of remaining challenges that would have to be overcome to truly achieve the goal of trusted privacy domains for heterogeneous, distributed environments. We believe that Trusted Computing technology, in particular the concept of trusted virtual domains (TVDs), can efficiently support privacy policy enforcement. We think that future research will lead to the development of trusted privacy-enhancing architectures that will be applicable to several use cases, e.g., e-commerce, enterprise rights management, e-health, and other areas. Here we outline only the first steps towards the definition of such architectures. In addition, the definition and enforcement of more complex privacy policies will be a subject of future work.

153

154

9. A Trusted Wallet for Secure Web Authentication In this chapter, we present TruWallet, a wallet-based authentication solution that improves previous proposals for protecting web authentication. Our implementation uses a small virtualization-based security kernel with trusted computing support and works with standard TLS-based authentication solutions for the web, where only minor modifications and extensions are required. It is interoperable so that we can re-use existing operating systems and applications like web browsers. We also present an adaptation of TruWallet for mobile devices with an application in the e-health domain: the protection of electronic health records. The material in this chapter has been published in [GLSW09] and [DHL+ 11b, DHL+ 11a].

9.1. Introduction to Wallet-Based Web Authentication Identity theft has become one of the fastest growing crimes on the Internet, leading to huge financial losses and privacy concerns [ID-05, Ant10] because of rising online fraud [Int08b] and software attacks [SAN07]. Among the most prominent attacks are phishing and pharming, where users are lured to faked sites and asked to disclose their identity credential information. Attackers exploit the fact that the average Internet user is unable to distinguish a legitimate site from a fake one – even though browser vendors introduced improved user interfaces [DTH06]. Moreover, attackers benefit from weak issuing policies of certificate authorities [Kre06, CR11] or the use of over-aged cryptographic algorithms to generate TLS certificates [SSA+ 08]. An additional powerful class of attacks are cross-site-scripting, request forgery or malware attacks. They compromise and infiltrate the user’s computing platform with malicious code (e.g., browser scripts, keyloggers or transaction generators) [tra06, JKK06, KKVJ06, PMM+ 07]. Commodity operating systems, suffering from various conceptual shortcomings, do not mitigate the impact of these attacks appropriately. Beside architectural security problems and the inherent vulnerabilities resulting from high complexity, today’s operating systems require careful system administration skills that ordinary users typically do not have. Several approaches have been proposed to address the mentioned attacks. Delegated identity management systems exist, where the user calls a trusted third party in form of a distributed server for hosting and providing identity information. Examples include Google’s single-sign on and Microsoft’s Cardspace protocols. However, they turned out to have deficiencies [ACC+ 08, GSC08, GP06, KR00, PW03]. On-board credentials (ObC; cf. [KEAR09]) are another recent approach to address these threats, particularly on mobile platforms. ObC use hardware features (such as Trusted Computing technology) to protect credentials and provide a promising and flexible credential system, in particular for mobile devices. However, the model assumes that secret

155

9. A Trusted Wallet for Secure Web Authentication data is “provisioned” explicitly for this system. In Section 9.7, we present an approach that uses ObC in the context of securing web authentication from a mobile device, and yet enables the use of existing web services with authentication via username-password. Against this background, wallet-like approaches have gained much attention (e.g., [PM04, GSSW07, JBM06, JBM07, JvdHM+ 06, KD07]). A wallet calls an authentication agent in an isolated trusted environment to separate the handling of credentials from the normal web browsing (see also [RJM+ 05, WML06]). Most of the existing proposals counteract specific attacks. They do not provide a general approach to protect against all attacks in the wild (see Section 9.8 for more discussions). However, a desired property is that the user relies on a self-contained solution that protects against any threat of identity theft – be it a phishing or be it malware attack. To protect average Internet users against these threats, we present the design and implementation of TruWallet, a wallet-based approach for secure web authentication. TruWallet consists of (i) a trusted wallet acting as web proxy to perform the user login at web sites, and (ii) a security kernel that provides a secure environment for the wallet and a secure user interface as trusted path between the user and the wallet. Moreover, we adapt our solution to mobile platforms, using trusted hardware features of modern mobile devices (via ObC) to securely store wallet data. As our main contribution, we address the previously mentioned objectives as follows: • We propose a method to achieve a TLS-PKI-independent login, assuming trustworthy TLS certificates only during the registration phase (Section 9.3). Our protocols establish a shared secret between TruWallet and server during registration which is then used for server authentication during login. • We present an efficient and secure migration protocol for the wallet data using trusted computing functionality based on Trusted Platform Modules (TPMs) [Tru07b] and security services interfacing the TPM (Section 9.4). Our protocol allows the user to securely transfer the secrets to a wallet on another platform in order to access web sites from there. • As a proof of concept, we developed a prototype implementation based on a microkernel architecture that supports virtualization and trusted computing functionality (Section 9.5). We are able to re-use existing operating systems (Linux in our prototype) and applications like commodity web browsers. • We adapt TruWallet for mobile devices. In particular, we consider an application from the area of electronic healthcare: secure access to electronic health records (EHRs). • We present a prototype of our mobile TruWallet that leverages hardware security features of the Nokia N900 mobile phone. Our approach has the advantage that the user may install arbitrary software in the same security context the browser is executed (because the wallet runs in an isolated, i.e. protected execution environment). TruWallet works with standard TLS-based authentication solutions for the web except that minor modifications and extensions on the server-side are necessary. TruWallet, including the security kernel, is based on open source and can be installed on x86 PCs equipped with a TPM. The mobile TruWallet is based on Maemo (a Linux variant developed by Nokia), and runs on a Nokia N900 smartphone.

156

9.2. System Overview

9.2. System Overview In this section we describe the threats and security objectives, and give an overview of TruWallet’s architecture and its usage.

9.2.1. Threats and Security Objectives TruWallet addresses the following threats: 1. (Phishing) Classical phishing and pharming attacks lure the user to faked web sites; 2. (Weak Policies) Weak issuing policies of TLS certificates or choice of weak cryptographic algorithms allow the attacker to retrieve a valid TLS certificate; 3. (XSS) Cross-site scripting (XSS) or cross-site request forgery attacks exploit server vulnerabilities in order to inject malicious script code into the browser; 4. (Malware 1) Malicious software on client system compromises system components and applications; 5. (Malware 2) Malicious software makes unauthorized use of system components and applications; For example, the malware could wait for the user to log in at a web site and subsequently generate fake transactions. 6. (Unauthorized Access) Unauthorized access of the client system where the attacker impersonates a legitimate user by misusing active browser sessions or stealing credentials. To address the threats, we need a comprehensive solution that protects both the web authentication mechanism and the software running on the client system. Our main objectives are therefore: 1. (Password Protection) Passwords must be unique for each site, resistant to dictionary attacks, and protected from unintentional disclosure; 2. (Secure Execution) Secure execution environment for security-critical components and a trusted path to the user to prevent malware attacks; 3. (Secure Storage) Secure storage environment for credentials when the system is offline (i.e., powered off); 4. (Less Dependencies on Certificates) Reduced dependencies from TLS certificates to mitigate weak issuing policies of certificate authorities; 5. (Secure Migration) Secure migration of credentials among different platforms, where the migration mechanism must ensure that each platform complies to the user’s security policy.

157

9. A Trusted Wallet for Secure Web Authentication

9.2.2. Architecture Our system model consists of several parties (see Figure 9.1): A user interacts with a computing platform through a secure graphical user interface secure GUI. A browser is used to render web pages that it gets from the wallet, which is acting as a proxy. The wallet obtains the requested pages from the server, blinds security-sensitive fields (e.g., password) on the pages presented to the browser, and fills in login credentials when logging into a website. For this, TruWallet has to handle two different TLS sessions: one between wallet and browser, and one between wallet and server. The secure GUI controls the input/output devices and multiplexes the screen output of the browser and of the wallet. Moreover, it always indicates the name of the application the user is currently interacting with via a reserved area on the screen, hence providing a trusted path between user and application. The TruWallet architecture is based on a security kernel, which is a small trusted software layer belonging to the TCB, providing trusted services and isolated compartments. Thus, the security kernel ensures runtime security of the system. Compartments contain arbitrary software, e.g., a complete legacy operating system (Linux in our case), and may communicate only via well-defined interfaces. In particular, a malicious compartment cannot read arbitrary memory of other compartments. In our solution, browser and wallet run in different compartments, and we assume that arbitrary software (including malware like Trojan horses and viruses) may be running in the browser compartment. Hence, the browser is assumed to be untrusted and any security-enhancing tools based on browser plugins may be modified or deactivated. Therefore, our solution is based on a trusted component (wallet) that is executed in a separated compartment. In our implementation, we realize the compartmentalization by using the isolation property of virtual machines combined with the resource sharing control of the underlying microkernel. The wallet compartment is trusted, which is motivated by the fact that the complexity of the wallet is much lower than that of a web browser. Moreover, the user cannot install arbitrary software (which may be malicious or flawed) in the wallet compartment. To prevent unauthorized access by other users to the platform and, hence, the sensitive data, the security kernel requires an overall user authentication (e.g., a user password) to login into the whole system. In this way, the credentials stored by the wallet are bound to the corresponding user.1 Trusted Computing (TC) hardware and TC-enabled software is used to provide trusted boot, i.e., based on a “chain of trust”, the integrity of the software stack including the TCB can be verified during data migration. Moreover, TC hardware can be used for secure storage, i.e., encryption keys protected by the hardware can only be used if load-time integrity of the system is maintained. As already mentioned before, our implementation on a PC uses a TPM as TC hardware (see Sections 9.4 and 9.5). The credentials stored by the wallet are bound to the TCB to prevent an adversary from gaining access to the data by replacing software (e.g., booting a different OS). In Section 9.7, we also present an approach, where mobile trusted hardware is used instead of a TPM. An alternative way of using TC hardware would be to execute the trusted software via hardware-based dynamic root of trust, using hardware support of modern CPU architec1

In fact the security kernel has to provide comprehensive user access control as in typical operating systems, including system login and screen lock functionality, in order to prevent unauthorized access to the wallet. However, the details of those mechanisms are out of scope of this thesis.

158

9.2. System Overview

Figure 9.1.: Architecture of TruWallet tures [AMD07, Int08a]. Instead of measuring the whole software stack at boot time, the CPU allows to execute trusted code in a special mode where integrity measurements are taken dynamically and stored in the TPM until the trusted code execution ends [MPP+ 07]. In principle, such an approach reduces the amount of needed TCB code. However, when the trusted code is executed, the remaining system code (the operating system, browser, etc.) is halted until the trusted code terminates. This mechanism is intended to (repeatedly) execute small trusted code pieces and resume again. We did not choose dynamic root of trust in our design because the trusted code does not only need to insert passwords (which would be a relatively small functionality), but we also need to authenticate the server, verify the authenticity of the TLS channel, and provide a trusted GUI so that the user can always be sure about the application interacting with. Thus, significant parts of the system need to execute very often or in parallel, which would introduce a noticeable performance overhead when using dynamic root of trust. This becomes of even more importance when the wallet is enhanced with additional functionality like transaction confirmation, where trusted code needs to inspect the network traffic continuously.

9.2.3. Assumptions Our solution is based on the following assumptions: First, the user is trained to enter credentials only into the wallet (single credential store mechanism). In our PC-based implementation, the user can establish a trusted path to the wallet by pressing a secure attention key. Second, the wallet can rely on a PKI during registration at a server (minimal PKI). A PKI is needed to prevent attacks like DNS-spoofing during the setup/registration process. The wallet relies on a correct TLS certificate to identify a remote site. However, we aim at minimizing this assumption: to protect sensitive user data during a later session, it is important to highlight that we do not rely on a trustworthy TLS-PKI.

9.2.4. Usage Overview Registration of a new account at a website with the wallet works almost the same way as in existing approaches, with two differences: first, the user enters sensitive data (e.g., passwords) only into TruWallet (never into the browser); second, TruWallet generates a

159

9. A Trusted Wallet for Secure Web Authentication high-entropy password that is unique for this account. To log into a previously registered site, the user just opens the login page in the browser and clicks on the “login” button. TruWallet is acting as man-in-the-middle proxy and automatically checks if the server is authorized to obtain the credentials before it fills in the login credentials on behalf of the user (for details, see Section 9.3). Note that, since the wallet is also an TLS proxy, several TLS connections (and hence user logins) can be handled simultaneously, e.g., when the user opens several websites in multiple browser tabs or instances. Each TLS connection between a browser tab or instance has a corresponding TLS connection between the wallet and the respective web server. To enable the user to access web sites from another computer, we propose a secure migration scheme for the wallet to transfer or synchronize its data with a trusted wallet running on the other device. We use TC functionality to establish a trusted channel ensuring the integrity of the target system to transfer the data (Section 9.4).

9.3. Secure User Authentication In the following, we describe a scheme for registration and login, based on the idea of TLS session-awareness [OHB08]. Our schemes rely on TLS certificates only during registration, and require only minimal changes of client and server. Registration. When the user registers at a website for the first time, a setup step is needed to enable logins that are independent from TLS certificates later on. Note that this is the case when the wallet first learns about the site and creates a corresponding login/password entry. Hence, this step is completely transparent to the user. We require that a TLS connection is used for registration, and that the wallet verifies the TLS certificate of the remote site.2 We use the TLS server finished message to infer an additional shared secret ss := SERVER FINISHED. The server finished message is derived by computing the hash of the protocol transcript (provided the protocol did not abort). A transcript trnscrpt includes all the messages the wallet has received from and sent to the server, respectively. It is important to note that the TLS protocol requires to authenticate and encrypt the finished value, using the derived session key. No attacker perceives the finished message in plain text. At the end of the registration, wallet and server store the shared secret ss securely. Login. Our login protocol uses TLS only to provide a secure (confidential) channel. For the crucial server authentication, the shared secret ss from the registration protocol is used. The logging proceeds as follows: The server S authenticates in challenge-and-respond protocol by proving knowledge of the shared secret ss. For ease-of-implementation, we utilize the TLS transcript trnscrpt as a challenge. Our approach makes use of the fact that the transcript includes a randomly chosen nonce from client. In fact, it would be sufficient to use this nonce alone without security loss. The server answers to the challenge by computing the response R := HMACss (trnscrpt), where HMAC() denotes a keyed-hash 2

At this point, we have to trust the certificate. Later on, we are independent from any changes/updates of the TLS certificate. Note, there exist no authenticated protocols without setup assumptions. Yet, this is an open research problem. We stress the fact that in this chapter, the goal is to minimize the setup assumptions.

160

9.4. Secure Wallet Data Migration message authentication code, ss the shared secret key between wallet and server, and trnscrpt the login transcript of the TLS protocol. Without any modification to the native TLS implementation, the response message R is postponed to the last server message, i.e., the server finished message of the TLS handshake protocol. The wallet runs the TLS protocol in the normal way and aborts, if the protocol does so. Next, the wallet verifies that R is a valid response. If R 6= HMACss (trnscrpt), it aborts the protocol. Otherwise, authentication proceeds as usual (username and password are transmitted).

Security. The use of the TLS message SERVER FINISHED to derive the shared secret ss ensures that no adversary can compute ss. It can be shown that computing the finished value is reducible to the security of the TLS protocol. Furthermore, the server’s response in the login protocol cannot be forged by an adversary (even if the adversary managed to obtain a valid TLS certificate and acts as a man-in-the-middle) because an HMAC keyed with ss is used to tie the authentication to the TLS sessions. Man-in-the-middle attacks are not possible in the login protocol – even if the adversary managed to obtain a valid certificate – because the check of the server’s response performed by the wallet succeeds only if both parties use the same shared authentication secret ss. This is only possible for the two endpoints of the TLS channel. These considerations imply that the wallet only executes the normal (password-based) login with a party that possesses the shared secret which was computed during registration, and hence only the server where the user registered can obtain the user’s credentials. Attackers cannot re-compute ss, because for this, they need access to the ephemeral secrets from the TLS handshake during registration, which were known only to the two (trusted) endpoints: TruWallet and the web server. Thus, even a full compromise of the TLS PKI cannot help an attacker to recover ss.

Discussion. Essentially, any password-authenticated key exchange (PAKE) protocol where the server proves knowledge of the password could be used instead of our registration and login protocols, as long as it is used in a way that ensures resistance against man-in-themiddle and replay attacks (see, e.g., [BM92, Jab96, Wu98]). PAKE protocols can be used for mutual authentication, i.e., using PAKE, it is not necessary to transmit username and password over the TLS channel during login. However, note that not all authors explicitly discuss and analyze the important (for our case) requirement that the server proves knowledge of the password. In particular, the simple remote password (SRP) protocol [Wu98] is well-suited for our purpose, and RFC5054 [TWMP07] specifies the use of SRP for TLS authentication. A detailed security analysis (including a proof) is provided in [Wu98]. Our custom protocols are easier to implement than a PAKE protocol because only minor modifications to existing software are needed. Both, the TLS handshake and the login procedure remain unchanged in our protocols, whereas PAKE protocols require a dedicated key exchange protocol. However, a complete implementation of RFC5054 as a standard-compliant authentication solution might be beneficial in many scenarios and could be the preferred approach for a production-quality implementation.

161

9. A Trusted Wallet for Secure Web Authentication Destination Platform

Source Platform StorageMgmt

TruWallet request Trusted Channel

TPM

TrustMgr

TruWallet

request Trusted Channel

TPM CreateWrapKey() generate PK Bind , SK Bind ESK Bind := encryptSRK (PK Bind , ESK Bind )

loadData()

(PK Bind , ESK Bind )

wd

TPM CertifyKey(PK Bind ) (PK Bind , cert Bind ) ewd := Tspi Data Bind(PK Bind , wd )

cert bind

(PK Bind , cert Bind )

ewd unbind(ewd ) TPM LoadKey(ESK Bind ) SK Bind := decryptSRK (ESK bind ) TPM Unbind(ewd ) verify(TCB conf ) wd := decryptSK Bind (ewd ) wd

wd

Figure 9.2.: Migration of the wallet data based on a trusted channel

9.4. Secure Wallet Data Migration To protect the confidentiality of the wallet data on persistent storage, the wallet data is sealed, i.e., encrypted with a key that is bound to the configuration (integrity measurements) of the wallet’s TCB and shielded by the TPM. If the user wants to use the wallet on another platform, e.g., in order to switch to another machine or because of hardware replacement, the sealed data would become inaccessible. We also do not want to expose the wallet data to a platform the user does not trust. Hence, we need to check the “trust status” of the target platform before we re-bind the wallet data. A trusted channel is a secure channel (i.e., authenticity, integrity and confidentiality) with the additional feature that it is bound to the configuration of the endpoint(s). The idea is to embed an attestation of the involved endpoint(s) in the establishment of the secure channel [GPS06, STRE06]. Hence, each endpoint can get an assurance whether the counterpart complies with trust requirements before the secure channel is settled. Besides the wallet, we consider two trusted components of the security kernel to take part in the migration procedure: (1) the Storage Management provides an abstraction of persistent storage to other compartments, here especially the wallet, and enforces additional security requirements to protect confidentiality and integrity by means of encryption and sealing. (2) the Trust Manager provides an abstraction of the functionality of a TPM and is the only software component that directly communicates with the TPM. When the user wants to migrate or copy the wallet data from one platform (source) to another (target), then a trusted channel between the two platforms, i.e., between two wallet instances, must be established (see Figure 9.2). The wallet on the target platform calls the Trust Manager of its platform to initiate the trusted channel. The Trust Manager uses the

162

9.5. Implementation of TruWallet on a PC TPM to create a new asymmetric key pair as binding key (PKBind , SKBind ). The TPM creates the key pair, encrypts the private key part with the SRK, and returns PKBind and the encrypted private key ESKBind . Note that decryption of the private key is now bound to the configuration of the TCB as measured during the boot process and represented by the values of the PCRs of the TPM, i.e., TCB conf . Moreover, the Trust Manager requests the TPM to sign the public key with an AIK in order to create a certificate certBind . The Trust Manager returns certBind , PKBind and ESKBind to the wallet, which then sends the binding key PKBind and the certificate certBind to the source platform. The wallet on the source platform can now verify the certificate and decide whether the target platform complies to the wallet’s trustworthiness requirements. Therefore, it needs the public key of the AIK of the target platform and the certificate from the PrivacyCA. Then, the source wallet loads its data from the Storage Management and encrypts the data wd with the binding key PKBind . The encrypted wallet data ewd is sent to the target wallet, which then requests the Trust Manager to unbind ewd . Therefore, the Trust Manager first calls the TPM to load the key ESKBind into the TPM, and then requests the TPM to unbind ewd . The TPM in turn verifies with verify(TCB conf ) whether the TCB configuration (i.e., its integrity measurement) is the same as at creation time of the binding key. If this is the case, the TPM proceeds and first decrypts ESKBind to retrieve the private part of the binding key, which it uses subsequently to decrypt the wallet data. The decrypted data wd is returned to the Trust Manager and the wallet, respectively. After execution of the migration protocol, the wallet on the destination platform can securely store the data persistently using the Storage Management on this platform. Discussion. Once a trusted channel is established, it can be re-used for subsequent wallet synchronization between the platforms. The binding of the key pair to the configuration of the TCB guarantees that no other platform and even no modified system booted on the same platform can decrypt the key and, hence, the wallet data. However, for each device the user wants to use TruWallet, the user has to (i) establish a trusted channel, and (ii) if the TCB or the wallet have to be updated, the trusted channel has to be reestablished. In principle, it is not necessary that both platforms are online for migration. The binding certificate can be computed beforehand. Of course, the user has to know the potential destination platforms a-priori, but can transfer the data on offline storage, e.g., on a memory stick. Requiring a certificate for the AIK from the Privacy-CA introduces another PKI dependency, but we expect very few AIK certificates (typically one to four TPMs for the platforms the user wants to use, e.g., laptop, home PC, office PC, mobile device). However, the number of certificates for usual TLS server authentication is much higher (e.g., 10–20 web sites or more used by one user).

9.5. Implementation of TruWallet on a PC We implemented a prototype of TruWallet on top of the Turaya security kernel3 , which is based on an L4 microkernel [Lie95]. Besides virtualization, Turaya provides TC support based on a TPM and a secure GUI. Moreover, using Turaya allows us to re-use and extend the open source Wallet-Proxy developed by Gajek et al.[GSSW07]. 3

www.emscb.org/content/pages/turaya.htm

163

9. A Trusted Wallet for Secure Web Authentication In our prototype, the user compartment contains a Linux OS with arbitrary applications chosen by the user. As web browsers, we use Opera and Firefox. The TruWallet compartment is realized based on a minimally configured Linux OS, where only TruWallet (including an HTTP/HTTPS proxy) is running. In contrast to the user compartment, the user is not allowed to install applications into the wallet compartment. The Security Services of our Trusted Software Layer are either implemented as minimal Linux compartments (e.g., the TrustManager), or native L4 processes (such as the secure GUI and Storage Management). For some more details of our PC-based implementation, see [GLSW09]. Registration. In practice, different methods are used to register users at a service. Users obtain an initial password via an out-of-band channel (e.g., by email), they might want to set up an existing account for use with TruWallet, or the initial password is entered in a registration form prior to the first login. To register a new account, the user enters non-sensitive data (login name) in the browser. The wallet recognizes password fields in the registration form and indicates (via the secure GUI) that the user has to switch to the wallet compartment by pressing a secure attention key. In case the user already possesses a password, the user enters the password into a special input form displayed by the wallet. Otherwise, the wallet generates a new password. The wallet submits the complete data to the server, and the user can switch back to the browser and use the web site. If an existing password is used, TruWallet reminds the user to initiate a password change as soon as possible (see Section 9.5). In contrast to existing password managers, which in such cases associate the URL of the registration form with the login data, TruWallet offers the user a checkbox to indicate registration forms. At the next login, the user can associate the login data stored at registration time to the actual URL of the login form. Login. Now that the user has registered and the wallet setup for this site is complete, the password is filled in automatically whenever the user logs in. The wallet recognizes the URL of the login form, thus, whenever users log in, they just enter their username (the password form should be blocked) and click on the “submit” button. The wallet fills in the password automatically based on the URL and username. Hence, TruWallet supports multiple accounts at one web site. Password change. As proposed in [GSSW07], TruWallet must change the user’s password to a unique high-entropy secret. The new password should not be known to the user because otherwise the user could be tricked to disclose it unintentionally to a phishing site. For this, TruWallet sets the new password to pw new := hash(pw old , r), where pw old is the password chosen by the user and r is a random value. However, a fully automated generic approach to change passwords which works for any website is unrealistic, given the enormous variety of different procedures employed on the Internet. We conducted a survey on popular websites – including several banking sites, Amazon, eBay, PayPal, Walmart, and others – which led to the conclusion that a simple heuristic for finding out how to change passwords (such as looking for links with a specific text, like “change password”) is not sufficient. The difficulties finding the right links and URLs include: HTML-tags enclosing parts of the actual text link (e.g., for emphasis), complex framesets partially generated dynamically using JavaScript, multi-column forms with

164

9.6. Security of TruWallet multiple options for the user, forms where users have to prove their identity by inserting additional information (different from the old password), etc. In our approach, the user has to initiate the password change on the web site and switch to the wallet compartment. TruWallet displays a special input form offering two options for each password field: “generate new password” and “fill in old password”. The user selects the appropriate options, and the wallet submits the completed form to the server. TruWallet stores the new login data.

9.6. Security of TruWallet Our solution realizes Objective 1 (Password Protection) by generating new high-entropy passwords not known to the user. Moreover, the wallet verifies the legitimacy of the server before disclosing the password. This mitigates Threat 1 (Phishing). Assuming TLS certificates were trustworthy during initial registration, we provide security against certificate hijacking during any later login. This means that our login procedure is resistant against Threat 2 (Weak Policies) by following Objective 4 (Less Dependencies on Certificates). Our approach works without modification of the TLS handshake protocol. Hence, the security properties of TLS remain unchanged. To address the threat Threat 3 (XSS), we isolate the usage and storage of credentials from the browser. The wallet performs all tasks related to establish authenticated connection to a web server, including storage and management of session cookies. Hence, attacks such as cross-site scripting and cross-site request forgery, which attack the browser, cannot obtain these credentials. The security kernel and the use of trusted computing functionality achieve Objective 2 (Secure Execution) and 3 (Secure Storage). During runtime, the security kernel isolates compartments by default and allows only controlled inter-process communication. Thus, malware running in one compartment cannot read or modify the data and configuration of other compartments. The TCB cannot be compromised during runtime because of the assumption that it is small enough to be verified and tested thoroughly, and based on the fact that the user cannot install arbitrary applications within trusted compartments. Hence, the only “entry-point” for malware is the user compartment, which is isolated from the wallet compartment. TruWallet only routes network traffic between the browser and network. If software components are modified in order to compromise the system, the modification of trusted components will result in different integrity measurements taken during the boot process and recorded in the TPM. Thus, the wallet data cannot be unsealed and remains encrypted. The security in this case is based on the security of the encryption and the protected key storage of the TPM. This addresses Threat 4 (Malware 1) on the local platform. Moreover, our secure migration protocol for copying or transferring wallet data to another device realizes Objective 5 (Secure Migration) to address Threat 4 (Malware 1) on target platforms. TruWallet ensures that the target provides at least the same security properties as the source platform – reflected by the integrity measurements verified during the attestation of the target system. Transaction security can be provided to protect sensitive data after the login process by incorporating transaction confirmation functionality [JBM07, JvdHM+ 06, KD07, FMSW11] into the trusted wallet compartment. Our modular architecture allows for an

165

9. A Trusted Wallet for Secure Web Authentication easy integration of such extended functionalities. This would mitigate Threat 5 (Malware 2). Threat 6 (Unauthorized Access) can be prevented by typical user access control (system login at start-up, screen lock when leaving the computing device).

9.7. A Mobile Trusted Wallet to Enhance E-Health Security The usage of mobile phones as multi-purpose assistant device in healthcare has been proposed in several application scenarios. Its usefulness is derived from its mobility and flexibility, i.e., today’s smartphones offer appropriate computing and storage capacity allowing the realization of various applications that can be used basically from everywhere. For instance, healthcare professionals can use a mobile phones to download and share electronic health records of their patients [BP10]. In other scenarios, patients use their mobile phones to provide personal health data, e.g., taken from additional bio-sensors, to a medical information and diagnosis system [HPL08]. While smartphones are very flexible and cost-efficient computing devices, they generally do not offer sufficient security mechanisms to protect the data they operate on. This is mainly due to the architectural shortcomings of their operating systems, which are derived from the same (security) architecture as desktop operating systems. Typical examples are Google Android [And10], Apple iOS [App10], Symbian [Sym10], and Windows Mobile [Mic10]. Although, some of them provide more sophisticated security mechanisms than their desktop counterparts, e.g., application-oriented access control in Android [Goo10], they still suffer from fundamental security problems due to their large code base and complexity, lacking of strong isolation of applications (secure execution) and insufficient protection of stored data (secure storage). Recent attacks on smartphones demonstrate their vulnerability [IW10, Ven10, AV10]. But the secure operation of a mobile phone is an important aspect when a user is working with security and privacy-sensitive data such as personal health records on the device. Especially in healthcare telematics infrastructures, the end-user systems of health professionals have been identified as an insecure and less specified component [SLK10]. Malware on the user’s computing platform could steal passwords that are used to access healthcare information systems, manipulate data such as medical prescriptions, or eavesdrop on and copy private data such as personal health records. While the connection of stationary desktop systems to the healthcare telematics may be protected by additional secure hardware network components like, e.g., special firewalls and gateway routers, the situation gets worse when mobile phones are used. Due to their mobility and changing connectivity (wireless LAN or GSM network), mobile phones may usually only use Virtual Private Network (VPN) technology to secure the connection. But the necessary credentials, like user passwords and VPN keys, are not sufficiently protected against malware on the device, and, hence, could be accessed by unauthorized parties. However, modern smartphone hardware offers advanced security functionality, which are embedded in their processors, but generally not used by the mainstream mobile operating systems. For instance, ARM TrustZone [AF04] and Texas Instruments M-Shield [AF08] offer secure boot4 functionality, secure storage and secure execution environments for 4

Secure boot means that a system terminates the boot process in case the integrity check of a component to be loaded fails.

166

9.7. A Mobile Trusted Wallet to Enhance E-Health Security security-critical functions, which are isolated based on hardware mechanism from other processes running on the phone. On the other hand, previous works on secure operating systems, e.g., [Fra83, KZB+ 90], have shown how to achieve strong isolation for secure execution and to have less complexity for the trusted computing base, i.e., the code that all security relies upon. The concept of a security kernel [And72] incorporates all relevant functionality needed to enforce the security into a kernel that is isolated and protected from tampering by other software and small enough to be verifiable for its correctness and security. While earlier systems suffered mostly from poor performance in those days, recent CPU hardware technology, especially their virtualization support, and the development of efficient microkernel software architectures [Lie95] allow for the realization of security kernels with low performance overhead while maintaining compatibility to existing applications. For example, Turaya [EMS08] and the OpenTC security architecture [Ope09b] are research efforts that take advantage of these technologies to develop a security kernel on modern CPU hardware. We therefore propose a security architecture leveraging TruWallet for accessing e-health services on mobile phones (as published in [DHL+ 11b, DHL+ 11a]). We use TruWallet to protect the user’s login credentials and to perform the authentication to e-health (or other) servers on behalf of the user. Thus, users are protected from being tricked into entering their credentials in malicious applications or faked web sites, and takes advantage of the underlying security framework to protect the credentials from malicious software potentially running on the phone. Subsequently, we present an implementation of a wallet for mobile phones based on the Nokia N900 platform. This implementation uses hardware security features that are offered by the mobile device.

9.7.1. Problem Scenario We consider a scenario in which electronic health records (EHRs) of patients are stored on a local server of a healthcare provider, e.g., in a hospital. Health care professionals, like doctors and nurses, are equipped with mobile computing devices (smartphones) on which they can create, edit, and view EHRs. The EHRs are stored on the e-health server, and the smartphones communicate with the server via wireless network connections. For instance, the access of medical data can be realized with web-based applications, using standard web browser software on mobile devices. Figure 9.3 depicts the scenario we consider.

Figure 9.3.: Usage Scenario: Accessing electronic health records with a mobile device. Since EHRs are very security-sensitive private data, and in most countries protected under strong privacy laws, unauthorized access to these data must be prevented. An

167

9. A Trusted Wallet for Secure Web Authentication adversary may try to eavesdrop or manipulate the sensitive data. As mentioned before, end-user devices are typically the least specified and least secured devices in healthcare infrastructures. Hence, an adversary would most likely try to attack the mobile phone and its communication connection to the server in order to illegitimately access medical data. Studies like [VKM+ 08] have analyzed how to secure the data transfer, i.e., via encryption (for confidentiality), digital signatures (for integrity and authenticity), and user authentication (for legitimacy of access). However, the protection of the critical cryptographic keys that are needed for those mechanisms is not addressed appropriately. Hence, an attacker who gains access to these keys can circumvent any other protection mechanism. Therefore, in this section we concentrate on an adversary model in which the attacker targets the mobile computing device of health care professionals in order to obtain the secret login credentials or keys that are needed to access the EHR server. Once the adversary has access to these credentials, he can download or modify all medical data from the server to which the credentials allow access to. To achieve this goal, the adversary can follow two strategies: • Direct Access: The adversary tries to directly access the sensitive data or keys. He could try to manipulate software running on the phone to access the data, or he could steal the device and try to access the data. The former could be achieved by letting the users install malicious software (malware, such as Trojan horses) without their notice, e.g., when they browse to a website containing malicious code that exploits a vulnerability of the phone’s software to install the malware. Doctors may use their phones also for other tasks and they may want to download additional applications to run them on the phone, which could create the vulnerability for such an attack. • Indirect Access: The adversary tries to trick the users to enter their passwords into a faked EHR viewer application. The faked application looks like the real one, but instead of logging into the server, it sends the passwords to the adversary. The faked application could be installed on the phone in the same way as malware described above. The problem with a commodity mobile phone operating system (OS) is that it cannot provide a sufficient level of protection for the applications or stored credentials. A mobile phone OS that is directly derived from a desktop OS (e.g., Linux or Windows) has limited protection capabilities, i.e., simple process isolation and access control. However, malicious applications can modify or eavesdrop data of other applications since they are running with the same user privileges as other applications. A more advanced OS, e.g., like SELinux [LS01], can enforce mandatory access rules, which provide a stronger isolation of different applications from each other. For instance, a text editor could only edit text files, whereas an audio application could not modify text files. The application of such a system in a mobile e-health scenario has been shown earlier [AAH+ 07]. However, SELinux is a very complex system with security policies that are hard to configure correctly even for moderately complicated scenarios. Moreover, due to a relatively large code base, it is infeasible to perform a comprehensive formal (or even semi-formal) verification of the correctness and security of SELinux. Another example is Android [Goo10], which provides a similar application-oriented access control, i.e., it defines for each application different access rules and privileges – in contrast to

168

9.7. A Mobile Trusted Wallet to Enhance E-Health Security

Figure 9.4.: Using TruWallet to secure the access of EHRs user-oriented access control as in normal Linux and Windows, where all programs of one user share the same access rights. Nevertheless, even advanced mobile phone OS’s still suffer from ineffective protection against unauthorized modifications of programs or even modifications of the OS itself. An adversary could install on the user’s phone additional (faked) programs or replace existing programs. The user has seldom a chance to notice the modification, and critical data like credentials could be transferred to the adversary.

9.7.2. Mobile Wallet Architecture General idea. Our security architecture aims to protect against the attacks described above. To counter direct access attacks, we use our TruWallet architecture on a security kernel that isolates different applications, supports secure boot, and provides secure storage. Hence, authentication data is stored encrypted, and can only be accessed by the legitimate application (TruWallet) when the correct (unmodified) system has been booted. We recall that our wallet architecture aims to prevent indirect attacks by letting the wallet handle all authentication procedures. During a normal authentication, users do not enter passwords (this is automatically done by the wallet), hence they cannot accidentally disclose them towards a fake application that tries to spoof the look and feel of the legitimate EHR viewer or another application trusted by the user. In this usage scenario, our wallet-based security architecture provides two levels of protection (cf. Figure 9.4): 1. Protection of authentication data: As described above, TruWallet protects the user’s credentials (username and password) against unauthorized access. This approach is generic, and can be used also for other scenarios (e.g., web applications like eBay or Amazon). Indeed, TruWallet can be used simultaneously by different applications, yet it only authenticates each application to the server where it has been registered as legitimate application before. 2. Protection of medical data: An isolated EHR viewer (which can be a special-purpose browser) is used to view EHRs. This viewer cannot be modified because a fixed program image is executed, which is measured by the security kernel by computing

169

9. A Trusted Wallet for Secure Web Authentication a cryptographic hash and compared to a known-good reference value. This ensures that all modifications of the EHR viewer can be detected. In case a browser is used as EHR viewer, this browser is only allowed to contact the EHR server and cannot connect to other sites. System model. For our medical application scenario, we introduce an EHR viewer into our system model for TruWallet, which thus consists of the following parties : A user interacts with a computing platform through a secure graphical user interface secure GUI. An EHR viewer is used to render content that it gets from TruWallet, which is acting as a proxy. TruWallet obtains the requested content from the server, blinds securitysensitive fields (e.g., password) on the pages presented to the browser, and fills in login credentials when logging into the system. As already described above, TruWallet has to handle two different SSL sessions: one between wallet and EHR viewer, and one between wallet and server. The secure GUI controls the input/output devices and multiplexes the screen output of the EHR viewer and of the wallet. Moreover, it always indicates the name of the application the user is currently interacting with via a reserved area on the screen, hence providing a trusted path between user and application. Furthermore, our architecture includes a compartment for non-medical data and applications. This compartment is strictly separated from the EHR viewer and can be used for arbitrary applications.

9.7.3. Building Blocks for a Mobile Security Architecture To implement our security architecture for mobile e-health scenarios, several building blocks for mobile environments are required: • Trusted hardware for mobile platforms which supports features to protect cryptographic keys and verify the system integrity; • A secure hypervisor layer for mobile platforms to provide isolated execution environments for applications; • A security kernel with a secure GUI for mobile platforms to provide a trusted path between the user and applications, and with secure storage for applications; • A trusted wallet (TruWallet) to handle authentication and protect the user’s credentials. In the following, we briefly introduce the first three building blocks, before we focus in more detail on the implementation of a trusted wallet on a mobile phone in the next section. Trusted hardware for mobile platforms. The architecture of TruWallet relies of trusted hardware for performing security critical operations. To instantiate TruWallet architecture on a mobile phone, we have to use mobile hardware security extensions instead of a TPM (which is not available on current phones). On mobile platforms, general-purpose secure hardware such as M-Shield [AF08] and TrustZone [AF04] is available. In this section, we focus on M-Shield, because this hardware extension is available in some current mobile phones, including Nokia N900 (which we used for our prototype).

170

9.7. A Mobile Trusted Wallet to Enhance E-Health Security M-Shield provides a small amount of dedicated on-chip ROM and RAM as well as one-time programmable memory for device keys which are accessible only in a special execution mode of the main CPU – the Trusted Execution Environment (TrEE). A secure state machine (SSM) guarantees secure switching between both processor modes, thus the TrEE and normal execution environment are isolated from each other. M-Shield enables the TrEE on a device with the following features: (i) isolated secure code execution; (ii) secure boot; (iii) hardware-based secure storage. Secure hypervisor for mobile devices. Several microkernels for mobile and embedded devices have been implemented, for instance the commercially available L4 microkernels OKL4 [Ope10] and PikeOS P4 [BFB09]. These microkernels provide isolation between user space applications, just like their counterparts on other platforms (e.g., on PCs). Therefore, they can be used for a secure hypervisor layer for a security kernel on mobile phones. In particular, the seL4 microkernel has been formally verified for correctness [KEH+ 09], hence taking an important step towards building a formally verifiable security kernel on top of a microkernel. Security kernel with secure GUI for mobile devices. The Turaya Trusted Mobile Desktop [SSFG10] implements a security kernel with a secure user interface for mobile devices. Its TCB consists of a hypervisor layer and a trusted software layer. The hypervisor layer is implemented on top of an L4 microkernel, which has been ported to the Nokia N900 mobile phone. The Trusted Software Layer contains a number of security services, such as a secure graphical user interface (called TrustedGUI), a virtual private network (VPN) client, and a file encryption service.

9.7.4. Wallet Prototype on Nokia N900 In order to demonstrate the feasibility of running a trusted wallet on a mobile phone, we have implemented Mobile TruWallet, a mobile version of trusted wallet, on a Nokia N900 device. Architecture of our mobile TruWallet prototype. Instead of realizing the full implementation of a security kernel, for which we refer to the works of [BFB09, KEH+ 09, SSFG10], we have implemented the wallet on Maemo [Mae10], which is based on Linux and provides standard operating system process isolation and discretionary access control. The architecture of Mobile TruWallet we have implemented is depicted in Figure 9.5. As it can be seen, TruWallet resides on the operating system side, but also operates on secrets at the same time, e.g., maintains a TLS channel to the web-server and also performs authentication with the user passwords. However, our generic architecture assumes that TruWallet is isolated from the rest of the system. This assumption is reasonable to some extend in the context of existing operating systems for Nokia mobile phones: Symbian OS and Maemo. Their platform security enables, with different degrees, process isolation. The microkernel-based Symbian OS provides process execution isolation and enforces control on inter-process communication via a capability mechanism, while Maemo’s security model is based on Discretionary Access Control (DAC) which enforces security by process ownership.

171


Figure 9.5.: Mobile TruWallet Architecture

We achieved process isolation on Maemo by creating a Mobile TruWallet process under a unique UserID and defining restrictive access rights to that UserID. Note that for this prototype, we rely on the standard Unix/Linux discretionary access control security framework, and there is always the threat that an administrator (root account) with the super-user access rights is compromised. However, we implemented the wallet as if it was running on a security kernel. This approach allows us to concentrate on the wallet-specific aspects for the prototype (i.e., performance, user interface, compatibility to the mobile web browser and web sites, etc.). In a later stage, the wallet can be easily adapted to a security kernel system like the L4-based one on N900 [SSFG10]. Using security features of mobile hardware. Nokia N900 device is features Texas Instrument’s M-Shield security extensions. We utilize M-Shield functionality for secure boot as well as the TrEE, and we also use a secure storage functionality implemented on top of M-Shield. Only authenticated programs, so-called protected applications (PAs), can be executed within the TrEE of M-Shield. However, protected applications have to be authorized, i.e., certified, by the device’s M-Shield stakeholder, most likely the device manufacturer. As did not want to obtain a certificate from the device manufacturer for a custom PA, we built on a general purpose API for the M-Shield TrEE that allows third parties to benefit from the TrEE: Nokia’s On-board Credentials platform (ObC) [KEAR09] provides the means to develop programs for the TrEE without involving the device manufacturer. In our prototype, we implement the secure storage functionality of our mobile TruWallet on top of ObC. A more detailed description of the ObC architecture can be found in [KEAR09, KDE+ 10].

9.7.5. Mobile Wallet Implementation We implement TruWallet as two components: the wallet itself and a proxy. In our prototype, the wallet is implemented in the C programming language, contains about 2600

172

9.7. A Mobile Trusted Wallet to Enhance E-Health Security lines of code, and runs as separate process with a unique UserID. For the HTTP/HTTPS proxy, we use Paros [Par10], which is an open-source implementation in Java. The proxy executes as a process with the same UserID as the wallet process. We define restrictive access rights on this UserID so that other processes cannot access the data or code of TruWallet (i.e., the wallet and proxy processes). Accessing health records. The wallet uses the libxml library to parse web sites and web forms in order to search for password fields. Whenever it finds such fields, these forms are inserted into a cache, and the password fields are disabled before the forms are displayed in the web browser or EHR viewer5 . This prevents the user from accidentally typing passwords into a potentially malicious or faked web site. Instead, users just provide their user name and simply click the submit or login button in the mobile web browser. Hence, when physicians want to access a health record from the e-health server, they simply open the EHR viewer on the phone and click the login button. Before sending the data to the server, the wallet replaces the disabled password field automatically with the password of the physician’s account on the e-health server. This process runs transparently, so physicians just see the EHR viewer application, and when the login is completed, they can access the health records on the server. Registration. Before physicians can use TruWallet to login to websites like the e-health server, they have to register their account in the wallet on the phone. Therefore, the wallet also looks for registration forms. When the user tries to access a website with the browser for the first time, the wallet asks the user for an existing password or it can create a new one. Figure 9.6 shows a corresponding screenshot, where the wallet dialog pops up after the user opened a website (with a login field) in the browser for the first time.

Figure 9.6.: Screenshot of Mobile TruWallet when registering an existing password Once the password has been provided (or newly generated), the wallet stores the credentials in a specific file. During runtime, the access to this file is only granted to the UserID of the wallet. Hence, other programs cannot read or modify the stored credentials. When the device is going to be shut off, this file is sealed using the ObC platform as mentioned before. Users can view a list of the stored accounts in wallet, as the screenshot in Figure 9.7 shows. For example, it shows a web-based e-mail account and “ehealth.local”, which is our local EHR server in our prototype. We realized the user interface based on the Hildon GUI framework [Hil10] on Maemo. 5

For our prototype, we used a dedicated web browser as EHR viewer.

173


Figure 9.7.: Screenshot of Mobile TruWallet showing registered services Interoperability. We have tested our mobile TruWallet implementation with several public websites, like web e-mail services, eBay, Amazon, etc. Registration and login work transparently and without noticeable performance overhead for the user. Hence, it should be easy to integrate web-based e-health services on our platform. Special-purpose EHR viewers or other medical applications can be supported as well as long as they use SSL/TLS and web-based login procedures. Other authentication protocols could also be integrated, but may require some effort to adapt TruWallet.

9.8. Related Work Wallet-based web authentication. Wu et al. [WML06] introduce Web Wallet, which is a browser extension and distinguishes between input of sensitive data and service usage by strictly deactivating login forms in the browser. The user has to press a special security key whenever she wants to enter sensitive data. The wallet checks the destination site using TLS certificates and other indicators (e.g., site popularity) and if unsure asks the user to explicitly choose the destination site from a list. Although this approach reduces the risk of classical phishing attacks, it does not isolate the wallet from the browser and hence lacks protection against malware that modifies the wallet or fakes its user interface. Jackson et al. [JBM06, JBM07] present SpyBlock, a browser extension that requests authentication as well as confirmation of transactions from the user by calling a separated confirmation agent. The browser runs in a virtual machine and, hence, virtualization is used to isolate the agent from the browser and to provide a trusted path to the user. However, in contrast to our PC-based implementation, they use a type 2 virtual machine monitor (VMM)6 and the agent runs on the host OS (Windows Vista), and they have no further protection of the agent, i.e., no secure storage like binding the agent data to the platform configuration. Thus, if the host OS gets compromised, malware may be able to manipulate the agent. In our approach, the wallet runs on a small (minor complexity) security kernel and we use a TPM [Tru07b] to seal the wallet data to the platform and its TCB. Moreover, SpyBlock does not realize Objective 1 (Password Protection) because it uses password hashing based on a master password and the domain name of the web site, which a phisher can compute if the user is tricked to enter the master password somewhere. The master password is used to derive all other passwords. Thus, for migrating the 6

According to [Gol72], a type 1 VMM executes directly on hardware, whereas a type 2 VMM needs a host operating system to run on. VMWare Workstation [SVL01] is an example for a type 2 VMM, and Xen [BDF+ 03b] a type 1 VMM (also called hypervisor ).

174

9.8. Related Work authentication data to other platforms, users would need to disclose the master password to all platforms they desire to use, which is a security risk if a platform is compromised. SpyBlock uses a shared secret key between the agent and the web site to compute a MAC of the transaction based on the shared secret which the server can verify, and cryptographically binds the result of a password-authenticated key exchange (PAKE) protocol to the TLS channel, which could be used to obtain a login that is independent from the TLS-PKI (cf. Section 9.3). However, this does not seem to be a goal of the authors. Impostor has been proposed by Pashalidis and Mitchell [PM04] to provide a centralized authentication service (single-sign-on) to enable authentication to legacy web services via one-time passwords from “untrusted” devices. For this, Impostor implements a proxy that handles authentication to the legacy web services, similar to our wallet-proxy TruWallet. However, the focus of this work is different: Impostor is meant to be used from untrusted devices, whereas TruWallet leverages trusted hardware and software components on the client – hence, in contrast to impostor, we provide a trusted path to the user and do not require a web server for our proxy. Delegate [JvdHM+ 06] is a web proxy to store credentials and to authenticate to web sites on behalf of the user. The web proxy is running on a different machine and not on the same device the user runs the browser. To realize the trusted path, they use a trusted mobile phone. Thus, they use physical isolation to separate the browser from the authentication part. However, this approach requires users to have an extra device (the phone) besides their PC and an online connection to the proxy for each login request. In contrast to their approach, TruWallet uses a TPM as trusted device attached to the platform the user operates on and a security kernel to isolate browser and credentials on the same platform. Hence, users need to rely only on one platform to perform web authentications. Kwan and Durfee [KD07] define a protocol framework for the interoperation between an untrusted compartment and a trusted compartment (Vault) handling sensitive user data. They use virtual machines and a type 1 VMM to isolate the compartments and to provide a trusted path to Vault. However, they do not address classical phishing directly because users have to enter passwords into Vault at each login and verify the legitimacy of web sites on their own. Gajek et al. [GSSW07] present Wallet-Proxy, a trusted wallet to store passwords and to automatically perform the login on behalf of the user. They propose to replace the user-provided password with a hash of the original password concatenated with a random value. However, they do not present details of how the wallet can define a new password for existing or newly registered accounts. In contrast to our approach, they heavily rely on a PKI, i.e., TLS certificates, in order to authenticate web servers during the login process. They also use a TPM to seal the wallet data to the platform configuration (integrity measurements of the wallet and its underlying TCB). While sealing provides a secure storage on one platform, our solution allows to securely migrate the wallet data to another machine. Trusted Computing and virtualization. Binding a key to the configuration of the underlying TCB has been realized with TPMs [MSMW03] and secure coprocessors [JSM01, SW99]. Asokan et al. [AES+ 07] describe a protocol for a trusted channel to realize license transfer in a DRM scenario. Our trusted migration protocol is a novel application of this

175

9. A Trusted Wallet for Secure Web Authentication license transfer. We require less components and less protocol steps since our trusted channel is not needed to transfer huge amount of media data like in their DRM scenario, and we do not have a freshness requirement, i.e., replaying wallet data is not a security problem in our scenario. Since we use sealing to protect the wallet data during persistent storage and migration, respectively, an appropriate integrity measurement mechanism during boot-up of the system is an essential step. Performing integrity checks during the boot process [AFS97], extending the measurement of loaded modules during runtime [SZJvD04], and binding secrets to only correct integrity measurements [MSMW03] are well explored concepts. Using virtualization to implement secure browsers has been explored by Cox et al. [CHGL06]. They isolate different web applications by running instances of web browsers in separated virtual machines. Other works [IB01, RGL07, GTK08] achieve even more fine-grained control by decomposing the web browser functionalities into single processes and applying process protection mechanisms of the operating system. However, browser security is complementary to our work because it does not protect against classical phishing attacks. Our wallet architecture adds a trusted component besides the browser to handle web authentication. Xen [BDF+ 03b] is a prominent hypervisor architecture. sHype [SJV+ 05] adds policycontrolled isolation enforcement and resource sharing to Xen. Terra [GPC+ 03a] is another VMM architecture using trusted computing functionality to provide attestation of VMs to remote parties. In contrast to these hypervisors, an L4-microkernel-based VMM has the advantage of running small native processes besides VMs, which we use to implement security services like the Storage Management and Trust Manager. This reduces the code size of the TCB one has to trust compared to full VM installations. The Turaya Trusted Mobile Desktop [SSFG10] implements a security kernel with a secure user interface for mobile devices. Its TCB consists of a hypervisor layer and a trusted software layer. The hypervisor layer is implemented on top of an L4 microkernel, which has been ported to the Nokia N900 mobile phone. The Trusted Software Layer contains a number of security services, such as a secure graphical user interface (called TrustedGUI), a virtual private network (VPN) client, and a file encryption service. An implementation such as the Turaya Trusted Mobile Desktop can be used as an underlying security kernel for our architecture.

Protecting electronic health records on smartphones. The protection of EHRs on smartphones has been addressed in [ALG+ 10, GGP+ 09]. However, the focus of these works is the encryption of the health records and storing the encrypted records directly on the mobile device. This approach is orthogonal to ours, as we do not consider to store the health records on the phone, but rather to protect viewing and accessing them. In both cases, health records have to be shown in plaintext on the device at some point of time. Our architecture ensures their runtime protection by executing the EHR viewer in a separate application environment. In addition, our approach protects the authentication credentials by leveraging trusted hardware functionality, whereas the approaches of [ALG+ 10, GGP+ 09] employ a software-only solution.

176

9.9. Conclusion

9.9. Conclusion We have presented TruWallet, a wallet-based architecture for secure web authentication. TruWallet allows users to automatically authenticate to web sites without revealing their long-term secrets to untrusted applications or faked web servers. It prevents the user from being tricked into revealing credentials by generating high-entropy passwords that even the user does not know. Moreover, we have presented secure registration and login protocols requiring only minimal changes to existing server software. Furthermore, we propose a secure migration protocol to be able to use wallet data on different platforms. Our implementation based on trusted virtualization technology is a proof of concept on PC platforms. Only minor changes in user behavior are required, e.g., entering sensitive data into the wallet instead of the web interface. Moreover, we adapted our wallet architecture for mobile platforms, and presented an implementation on the Nokia N900 smartphone, which uses security features of the mobile hardware (notably a Trusted Execution Environment). For this, we employed Nokia’s OnBoard Credentials (ObC). We demonstrated how such a mobile wallet could be useful in an e-health scenario to securely access electronic health records from mobile devices. In contrast to previous solutions, we (i) achieve the additional requirements of secure storage and trusted migration bound to the state of the wallet and its underlying TCB using trusted computing functionality available in many computing platforms, and (ii) reduce the high dependency on TLS certificates for server authentication. We demand a trusted PKI only for registration when creating a new account at a server, and for establishing trusted migration. Future work might include the extension of TruWallet with transaction confirmation and the capability to protect other data than authentication credentials based on privacy policies. Moreover, our mobile wallet prototype could be integrated with a trusted virtualization layer and a secure user interface for mobile devices.

177

178

Part IV.

Conclusion

179

10. Concluding Remarks In this thesis, we proposed privacy-preserving cryptographic protocols for a number of different applications, and we presented security architectures for various usage scenarios which can improve privacy protection. For this, we employed modern cryptographic techniques and state-of-the-art hardware with dedicated security features. In particular, our achievements are: • A cryptographic scheme for privacy-preserving unsplittable multi-coupons that enforces the redemption of coupons in a fixed order (Chapter 4); • A cryptographic scheme for privacy-preserving unsplittable multi-coupons that supports federations of cooperating vendors and allows users to determine the order of coupon redemption dynamically (Chapter 4); • A cryptographic protocol for property-based attestation based on property-certificates issued by a trusted third party (Chapter 5); • A cryptographic protocol for property-based attestation that enables users to negotiate “accepted configurations” without a certificate issuer trusted by both parties (Chapter 5); • An Anonymous authentication solution based on transport layer security (TLS) and direct anonymous attestation (DAA) (Chapter 6); • A security architecture and a scalable offline attestation scheme for distributed (grid) computing (Chapter 7); • A framework for trusted privacy domains, based on trusted virtual domains (TVDs) (Chapter 8); • Protocols for deploying and joining TVDs (Chapter 8); • A key management solution for mobile storage devices in TVDs (Chapter 8); • A prototypical implementation of TVDs on OpenSolaris (Chapter 8); • A wallet-based solution for secure web authentication (TruWallet). (Chapter 9); • Application scenarios for privacy domains and TruWallet in the context of electronic healthcare to better protect electronic health records (Chapters 8 and 9). Our work shows that better privacy and security for users is a goal that can be achieved in many cases without sacrificing the security of other stake holders. However, secure, privacy-friendly solutions are often more complex and may incur overhead and cost, compared to simpler approaches which do not consider security, and particularly privacy, of

181

10. Concluding Remarks end-users to be essential objectives. Hence, without sufficient awareness for these concerns, secure and privacy-friendly solutions will not be developed and applied in practice, except in few cases. Only pressure from a large number of people, acting as customers and citizens, can improve this situation by insisting that privacy and security are essential for them. Future research could include the combination of different approaches presented in this thesis – such as enhancing trusted virtual domains (cf. Chapter 8) with property-based attestation (cf. Chapter 5). This could lead to further improvements in the development of privacy-friendly security solutions. Moreover, secure systems that have reached a certain maturity (e.g., implementations of trusted virtual domains) could be evaluated in practice – for instance, by extensive user studies, as they are planned in the RUBTrust/MediTrust project [RUB11].

182

Bibliography [AAH+ 07] Berthold Agreiter, Muhammad Alam, Michael Hafner, Jean-Pierre Seifert, and Xinwen Zhang. Model driven configuration of secure operating systems for mobile applications in healthcare. In Proceedings of the ACM International Workshop on Model-Based Trustworthy Health Information Systems (MOTHIS’07), 2007. [ACC+ 08] Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cuellar, and Llanos Tobarra Abad. Formal Analysis of SAML 2.0 Web Browser Single SignOn: Breaking the SAML-based Single Sign-On for Google Apps. In 6th ACM Workshop on Formal Methods in Security Engineering (FMSE’08), pages 1–10. ACM, 2008. [ACCK00] Joy Algesheimer, Christian Cachin, Jan Camenisch, and G¨ unter Karjoth. Cryptographic security for mobile code. Technical Report RZ 3302 (# 93348), IBM Research, 2000. [ACK+ 10] Claudio Ardagna, Jan Camenisch, Markulf Kohlweiss, Ronald Leenes, Gregory Neven, Bart Priem, Pierangela Samarati, Dieter Sommer, and Mario Verdicchio. Exploiting cryptography for privacy-enhanced access control: A result of the PRIME project. Journal of Computer Security, 18:123–160, 2010. [Adv09]

Advanced Micro Devices, Inc. AMD I/O Virtualization Technology (IOMMU) Specification. http://support.amd.com/us/Processor_TechDocs/ 34434-IOMMU-Rev_1.26_2-11-09.pdf, 2009.

[AEL+ 08] Frederik Armknecht, Alberto N. Escalante, Hans Löhr, Mark Manulis, and Ahmad-Reza Sadeghi. Secure Multi-Coupons for Federated Environments: Privacy-Preserving and Customer-Friendly. In Proceedings of the 4th International Conference on Information Security Practice and Experience (ISPEC’08), volume 4991 of Lecture Notes in Computer Science, pages 29–44. Springer, 2008. [AES+ 07] N. Asokan, Jan-Erik Ekberg, Ahmad-Reza Sadeghi, Christian St¨ uble, and Marko Wolf. Enabling fairer digital rights management with trusted computing. In 10th Information Security Conference (ISC’07), volume 4779 of Lecture Notes in Computer Science, pages 53–70. Springer, 2007. [AF04]

Tiago Alves and Don Felton. TrustZone: Integrated Hardware and Software Security. Whitepaper, http://www.arm.com/pdfs/TZ%20Whitepaper.pdf, July 2004.

[AF08]

Jerome Azema and Gilles Fayad. M-ShieldTM mobile security technology: making wireless secure. Texas Instruments White Paper, February 2008. http: //focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf.

183

Bibliography [AFS97] William A. Arbaugh, David J. Farber, and Jonathan M. Smith. A secure and reliable bootstrap architecture. In IEEE Symposium on Security and Privacy (S&P’97), pages 65–71. IEEE Computer Society, 1997. [AGS83] Stanley R. Ames, Morrie Gasser, and Roger R. Schell. Security kernel design and implementation: An introduction. Computer, 16(7):14–22, 1983. [AGS+ 08] Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, and Davide Vernizzi. An efficient implementation of trusted channels based on OpenSSL. In Proceedings of the Third ACM Workshop on Scalable Trusted Computing (STC’08), pages 41–50. ACM Press, 2008. [AH09]

Ammar Alkassar and Rani Husseiki. Data leakage prevention in trusted virtual domains. In Information Security Solutions Europe (ISSE’09). Vieweg+Teubner Verlag, 2009.

[AKSX03] Rakesh Agrawal, Jerry Kiernan, Ramakrishnan Srikant, and Yirong Xu. An XPath-based preference language for P3P. In Proceedings of the 12th International World Wide Web Conference (WWW’03), pages 629–639, 2003. [ALG+ 10] Joseph A. Akinyele, Christoph U. Lehmann, Matthew D. Green, Matthew W. Pagano, Zachary N. J. Peterson, and Aviel D. Rubin. Self-protecting electronic medical records using attribute-based encryption. Cryptology ePrint Archive, Report 2010/565, 2010. http://eprint.iacr.org/2010/565. [AMD07] AMD. AMD64 architecture programmer’s manual volume 2: System programming. Technical Report Publication Number 24593, Revision 3.14, AMD, September 2007. [And72]

James P. Anderson. Computer security technology planning study. Technical Report ESD-TR-73-51, AFSC, Hanscom AFB, Bedford, MA, October 1972. AD-758 206, ESD/AFSC.

[And10]

Android Open Source Project. Project website. http://www.android.com, 2010.

[Ant10]

Anti Phishing Working Group. Phishing Activity Trends Report(s), 2005-2010. http://www.antiphishing.org.

[AOS02] Masayuki Abe, Miyako Ohkubo, and Koutarou Suzuki. 1-out-of-n signatures from a variety of keys. In Advances in Cryptology – ASIACRYPT’02, volume 2501 of Lecture Notes in Computer Science, pages 415–432. Springer, 2002. [App10]

Apple Inc. iOS website. http://www.apple.com/iphone/ios4, 2010.

[AV10]

Mayank Aggarwal and Troy Vennon. Study of BlackBerry proof-of-concept malicious applications. Technical Report White paper, SMobile Global Threat Center, Jan 2010.

184

Bibliography [BBC+ 09] Patrik Bichsel, Carl Binding, Jan Camenisch, Thomas Groß, Thomas HeydtBenjamin, Dieter Sommer, and Greg Zaverucha. Cryptographic protocols of the identity mixer library. Technical Report RZ 3730 (#99740), IBM Research, 2009. [BCB05] Carlo Blundo, Stelvio Cimato, and Annalisa De Bonis. Secure e-coupons. Electronic Commerce Research, 5(1):117–139, 2005. [BCC04] Ernie Brickell, Jan Camenisch, and Liqun Chen. Direct anonymous attestation. In Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS’04), pages 132–145. ACM Press, 2004. [BCG+ 09] Adam Beautement, Robert Coles, Jonathan Griffin, Christos Ioannidis, Brian Monahan, David Pym, Angela Sasse, and Mike Wonham. Modeling the human and technological costs and benefits of USB memory stick security. In Managing Information Risk and the Economics of Security, pages 141–163. Springer, 2009. Presented at the 7th Workshop on the Economics of Information Security (WISE’08). [BCGS09] Patrik Bichsel, Jan Camenisch, Thomas Groß, and Victor Shoup. Anonymous credentials on a standard Java Card. In Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS’09). ACM Press, 2009. [BCL08] Ernie Brickell, Liqun Chen, and Jiangtao Li. A new direct anonymous attestation scheme from bilinear maps. In Proceedings of the First International Conference on Trusted Computing and Trust in Information Technologies (TRUST’08), Lecture Notes in Computer Science. Springer Verlag, March 2008. [BCL09] Ernie Brickell, Liqun Chen, and Jiangtao Li. Simplified security notions of Direct Anonymous Attestation and a concrete scheme from pairings. International Journal of Information Security, 8(5):315–330, October 2009. [BCO05] Michael Backes, Christian Cachin, and Alina Oprea. Lazy revocation in cryptographic file systems. In Proceedings of the Third International IEEE Security in Storage Workshop (SISW’05), pages 1–11. IEEE Computer Society, 2005. [BCO06] Michael Backes, Christian Cachin, and Alina Oprea. Secure key-updating for lazy revocation. In Computer Security - ESORICS 2006, 11th European Symposium on Research in Computer Security, Hamburg, Germany, September 18-20, 2006, Proceedings, volume 4189 of Lecture Notes in Computer Science, pages 327–346. Springer, 2006. [BCP+ 08] Stefan Berger, Ram´ on C´ aceres, Dimitrios Pendarakis, Reiner Sailer, Enriquillo Valdez, Ronald Perez, Wayne Schildhauer, and Deepa Srinivasan. TVDc: Managing security in the trusted virtual datacenter. SIGOPS Operating Systems Review, 42(1):40–47, 2008. [BCR+ 08] Lujo Bauer, Lorrie F. Cranor, Robert W. Reeder, Michael K. Reiter, and Kami Vaniea. A user study of policy creation in a flexible access-control system. In SIGCHI Conference on Human Factors in Computing Systems (CHI’08). ACM, 2008.

185

Bibliography [BDF+ 03a] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP’03), pages 164–177. ACM Press, 2003. [BDF+ 03b] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Timothy L. Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In 19th ACM Symposium on Operating Systems Principles (SOSP’03), pages 164–177. ACM Press, 2003. [BFB09] Jacques Brygier, Rudolf Fuchsen, and Holger Blasum. PikeOS: Safe and secure virtualization in a separation microkernel. Technical report, Sysgo, September 2009. [BG07]

Shane Balfe and Eimear Gallery. Mobile Agents and the Deus Ex Machina: Protecting Agents using Trusted Computing. In Proceedings of the 2007 IEEE International Symposium on Ubisafe Computing (UbiSafe’07). IEEE Computer Society, 2007.

[BGJ+ 05] Anthony Bussani, John Linwood Griffin, Bernhard Jansen, Klaus Julisch, Guenter Karjoth, Hiroshi Maruyama, Megumi Nakamura, Ronald Perez, Matthias Schunter, Axel Tanner, Leendert Van Doorn, Els A. Van Herreweghen, Michael Waidner, and Sachiko Yoshihama. Trusted Virtual Domains: Secure foundations for business and IT services. Technical Report RC23792, IBM Research, 2005. [BH00]

Kathy Bohrer and Bobby Holland. Customer Profile Exchange (CPExchange) Specification, Version 1.0. Technical report, October 2000.

[BKM06] Adam Bender, Jonathan Katz, and Ruggero Morselli. Ring signatures: Stronger definitions, and constructions without random oracles. In Proceedings of the Third Theory of Cryptography Conference (TCC’06), volume 3876 of Lecture Notes in Computer Science, pages 60–79. Springer, 2006. [BL07]

Ernie Brickell and Jiangtao Li. Enhanced Privacy ID: A direct anonymous attestation scheme with enhanced revocation capabilities. In Proceedings of the 6th Workshop on Privacy in the Electronic Society (WPES’07), pages 21–30. ACM Press, 2007.

[Bla93]

Matt Blaze. A cryptographic file system for unix. In ACM Conference on Computer and Communications Security, pages 9–16, 1993.

[BLP05] Shane Balfe, Amit D. Lakhani, and Kenneth G. Paterson. Securing peer-topeer networks using Trusted Computing. In Trusted Computing, pages 271–298. IEEE Computer Society, 2005. [BM92]

186

Steven M. Bellovin and Michael Merritt. Encrypted key exchange: Passwordbased protocols secure against dictionary attacks. In IEEE Symposium on Security and Privacy (S&P’92), pages 72–84. IEEE Computer Society, 1992.

Bibliography [Bou00]

Fabrice Boudot. Efficient proofs that a committed number lies in an interval. In EURCRYPT, number 1807 in Lecture Notes in Computer Science, pages 431–444. Springer Verlag, 2000.

[BP97]

Niko Barić and Birgit Pfitzmann. Collision-free accumulators and fail-stop signature schemes without trees. In Advanced in Cryptology – Proceedings of EUROCRYPT ’97, volume 1233 of Lecture Notes in Computer Science, pages 480–494. Springer, 1997.

[BP01]

Berliner and Polk. cvshome.org/.

[BP10]

Giuliano Benelli and Alessandro Pozzebon. Near field communication and health: Turning a mobile phone into an interactive multipurpose assistant in healthcare scenarios. In Biomedical Engineering Systems and Technologies, International Joint Conference, BIOSTEC 2009, Revised Selected Papers, volume 52 of Communications in Computer and Information Science, pages 356– 368. Springer, 2010.

[Bra02]

Stefan Brands. A technical overview of digital credentials. research report, February 2002. Available at http://www.xs4all.nl/#brands/.

Concurrent versions system (cvs), 2001.

http://www.

[BWNH+ 06] Simon Blake-Wilson, Magnus Nystrom, David Hopwood, Jan Mikkelsen, and Tim Wright. Transport Layer Security (TLS) Extensions. RFC 4366 (Proposed Standard), April 2006. Obsoleted by RFC 5246. [CAG+ 06] Edjozane Cavalcanti, Leonardo Assis, Matheus Gaudêncio, Walfredo Cirne, Francisco Brasileiro, and Reynaldo Novaes. Sandboxing for a free-to-join grid with support for secure site-wide storage area. In Proceedings of the First International Workshop on Virtualization Technology in Distributed Computing (VTDC’06). IEEE Computer Society, 2006. [Cam04] Jan Camenisch. Better privacy for trusted computing platforms. In Proceedings of 9th European Symposium On Research in Computer Security (ESORICS’04), volume 3193 of Lecture Notes in Computer Science, pages 73–88. Springer Verlag, 2004. [Can00]

Ran Canetti. Security and composition of multiparty cryptographic protocols. Journal of Cryptology, 13(1):143–202, 2000.

[CBL+ 07] Liqun Chen, Alberto Escalante B., Hans Löhr, Mark Manulis, and Ahmad-Reza Sadeghi. A privacy-protecting multi-coupon scheme with stronger protection against splitting. In Proceedings of the 11th International Conference on Financial Cryptography and Data Security (FC’07), volume 4886 of Lecture Notes in Computer Science, pages 29–44. Springer, 2007. [CCSP01] Giuseppe Cattaneo, Luigi Catuogno, Aniello Del Sorbo, and Pino Persiano. The design and implementation of a transparent cryptographic file system for unix. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, June 25-30, 2001, Boston, Massachusetts, USA, pages 199–212. USENIX, 2001.

187

Bibliography [CDB04] Brian Cornell, Peter A. Dinda, and Fabián E. Bustamante. Wayback: A userlevel versioning file system for Linux. In Proceedings of Usenix Annual Technical Conference, FREENIX Track, pages 19–28. USENIX Association, 2004. [CDE+ 09] Luigi Catuogno, Alexandra Dmitrienko, Konrad Eriksson, Dirk Kuhlmann, Gianluca Ramunno, Ahmad-Reza Sadeghi, Steffen Schulz, Matthias Schunter, Marcel Winandy, and Jing Zhan. Trusted Virtual Domains – Design, implementation and lessons learned. In International Conference on Trusted Systems 2009 (INTRUST’09). Springer Verlag, 2009. [CDE+ 10] Serdar Cabuk, Chris I. Dalton, Konrad Eriksson, Dirk Kuhlmann, HariGovind V. Ramasamy, Gianluca Ramunno, Ahmad-Reza Sadeghi, Matthias Schunter, and Christian St¨ uble. Towards automated security policy enforcement in multi-tenant virtual data centers. Journal of Computer Security, 18(1):89– 121, 2010. [CDL+ 10] Liqun Chen, Kurt Dietrich, Hans Löhr, Ahmad-Reza Sadeghi, Christian Wachsmann, and Johannes Winter. Lightweight anonymous authentication with TLS and DAA for embedded mobile devices. In Proceedings of the 13th Information Security Conference (ISC’10), volume 6531 of Lecture Notes in Computer Science, pages 84–98. Springer, 2010. Full version available at http://eprint.iacr.org/2011/101.pdf. [CDRS07] Serdar Cabuk, Chris I. Dalton, HariGovind Ramasamy, and Matthias Schunter. Towards automated provisioning of secure virtualized networks. In Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS’07), pages 235–245. ACM Press, 2007. [CES+ 05] Liqun Chen, Matthias Enzmann, Ahmad-Reza Sadeghi, Markus Schneider, and Michael Steiner. A privacy-protecting coupon system. In Financial Cryptography and Data Security (FC’05), volume 3570 of Lecture Notes in Computer Science, pages 93–108, Berlin, 2005. Springer-Verlag. [CFH+ 07] Jason Cornwell, Ian Fette, Gary Hsieh, Madhu Prabaker, Jinghai Rao, Karen Tang, Kami Vaniea, Lujo Bauer, Lorrie F. Cranor, Jason Hong, Bruce McLaren, Mike Reiter, and Norman Sadeh. User-controllable security and privacy for pervasive computing. In 8th IEEE Workshop on Mobile Computing Systems and Applications (HotMobile 2007). IEEE Computer Society, 2007. [CG04]

Jan Camenisch and Jens Groth. Group signatures: Better efficiency and new theoretical aspects. In The Fourth International Conference on Security in Communication Networks (SCN’04), Revised Selected Papers, volume 3352 of Lecture Notes in Computer Science, pages 120–133. Springer, 2004.

[CG09]

Christian Cachin and Martin Geisler. Integrity Protection for Revision Control. In Proceedings of the 7th International Conference on Applied Cryptography and Network Security (ACNS’09), pages 382–399. Springer, 2009.

[CGH06] Sébastien Canard, Aline Gouget, and Emeline Hufschmitt. A handy multicoupon system. In Applied Cryptography and Network Security (ACNS’06), pages 66–81, 2006.

188

Bibliography [CGS07] Nishanth Chandran, Jens Groth, and Amit Sahai. Ring signatures of sub-linear size without random oracles. In Proceedings of ICALP’07, volume 4596 of Lecture Notes in Computer Science, pages 423–434. Springer Verlag, 2007. [Cha81]

David Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM, 24(2):84–88, 1981.

[Cha85]

David Chaum. Security without identification: Transaction systems to make big brother obsolete. Commun. ACM, 28(10):1030–1044, 1985.

[Che10]

Liqun Chen. A DAA scheme requiring less TPM resources. Proceedings of the Fifth China International Conference on Information Security and Cryptology (Inscrypt’09), 2010. Also available at Cryptology ePrint Archive, Report 2010/008.

[CHGL06] Richard S. Cox, Jacob G. Hansen, Steven D. Gribble, and Henry M. Levy. A safety-oriented platform for web applications. In IEEE Symposium on Security and Privacy (S&P’06), pages 350–364. IEEE Computer Society, 2006. [CHL05] Jan Camenisch, Susan Hohenberger, and Anna Lysyanskaya. Compact e-cash. In EUROCRYPT’05, number 3494 in Lecture Notes in Computer Science, pages 302–321. Springer Verlag, 2005. [CL01]

Jan Camenisch and Anna Lysyanskaya. An efficient system for non-transferable anonymous credentials with optional anonymity revocation. In Advanced in Cryptology – Proceedings of EUROCRYPT 2001, volume 2045 of Lecture Notes in Computer Science, pages 93–118. Springer, 2001.

[CL02]

Jan Camenisch and Anna Lysyanskaya. A signature scheme with efficient protocols. In Third Conference on Security in Communication Networks (SCN’02), volume 2576 of Lecture Notes in Computer Science, pages 268–289. Springer Verlag, 2002.

[CL04]

Jan Camenisch and Anna Lysyanskaya. Signature schemes and anonymous credentials from bilinear maps. In CRYPTO, volume 3152 of Lecture Notes in Computer Science, pages 56–72. Springer, 2004.

[CL06]

Melissa Chase and Anna Lysyanskaya. On signatures of knowledge. In Advances in Cryptology – Proceedings of the 26th Annual International Cryptology Conference (CRYPTO’06), volume 4117 of Lecture Notes in Computer Science, pages 78–96. Springer Verlag, 2006.

[CLL+ 06] Liqun Chen, Rainer Landfermann, Hans Löhr, Markus Rohe, Ahmad-Reza Sadeghi, and Christian St¨ uble. A protocol for property-based attestation. In Proceedings of the First ACM Workshop on Scalable Trusted Computing (STC’06), pages 7–16. ACM, 2006. [CLM+ 02] Lorrie F. Cranor, Marc Langheinrich, Massimo Marchiori, Martin PreslerMarshall, and Joseph Reagle. The Platform for Privacy Preferences 1.0 (P3P 1.0) specification. Technical report, April 2002.

189

Bibliography [CLM05] Lorrie F. Cranor, Marc Langheinrich, and Massimo Marchiori. A P3P Preference Exchange Language 1.0 (APPEL 1.0). Technical report, June 2005. WWW Consortium. [CLM+ 09] Luigi Catuogno, Hans Löhr, Mark Manulis, Ahmad-Reza Sadeghi, and Marcel Winandy. Transparent mobile storage protection in trusted virtual domains. In Proceedings of the 23rd Large Installation System Administration Conference (LISA’09), pages 159–172. USENIX Association, 2009. [CLM+ 10] Luigi Catuogno, Hans Löhr, Mark Manulis, Ahmad-Reza Sadeghi, Christian St¨ uble, and Marcel Winandy. Trusted Virtual Domains: Color your network. Datenschutz und Datensicherheit (DuD), 5:289–298, 2010. [CLMS08] Liqun Chen, Hans L¨ ohr, Mark Manulis, and Ahmad-Reza Sadeghi. Propertybased attestation without a trusted third party. In Proceedings of the 11th Information Security Conference (ISC’08), volume 5222 of Lecture Notes in Computer Science, pages 31–46. Springer, 2008. [CLR+ 10] Emanuele Cesena, Hans Löhr, Gianluca Ramunno, Ahmad-Reza Sadeghi, and Davide Vernizzi. Anonymous authentication with TLS and DAA. In Proceedings of the 3rd International Conference on Trust and Trustworthy Computing (TRUST’10), volume 6101 of Lecture Notes in Computer Science, pages 47–62. Springer, 2010. [CM99]

Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes. In Advances in Cryptology – Proceedings of EUROCRYPT’99, volume 1592 of Lecture Notes in Computer Science, pages 107–122. Springer Verlag, 1999.

[CM06]

Andrew Cooper and Andrew Martin. Trusted delegation for grid computing. In Second Workshop on Advances in Trusted Computing (WATC’06 Fall), Tokyo, Japan, 2006.

[CMS08] Liqun Chen, Paul Morrissey, and Nigel Smart. Pairings in Trusted Computing. In Pairing-Based Cryptography (Pairing’08), volume 5209 of Lecture Notes in Computer Science, pages 1–17. Springer, 2008. [Com99] Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation, 08 1999. Version 2.1, adopted by ISO/IEC as ISO/IEC International Standard (IS) 15408 1-3. Available online at http://csrc.ncsl.nist.gov/cc/ccv20/ccv2list.htm. [Com09] Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation, Version 3.1, July 2009. http: //www.commoncriteriaportal.org/thecc.html. [CR11]

190

Eric Chabrow and Jeffrey Roman. Why certificate security matters. Bank Information Security Articles, http://www.bankinfosecurity.com/articles. php?art_id=4067, 2011.

Bibliography [Cra02]

Lorrie F. Cranor. Web Privacy with P3P. O’Reilly & Associates, September 2002.

[CS97]

Jan Camenisch and Markus Stadler. Proof systems for general statements about discrete logarithms. Technical Report TR 260, Department of Computer Science, ETH Z¨ urich, March 1997.

[CS03]

Jan Camenisch and Victor Shoup. Practical verifiable encryption and decryption of discrete logarithms. In Advances in Cryptology – Proceedings of CRYPTO’03, volume 2729 of Lecture Notes in Computer Science, pages 126–144. Springer, 2003.

[CV02]

Jan Camenisch and Els Van Herreweghen. Design and implementation of the idemix anonymous credential system. In Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS’02), pages 21–30. ACM Press, 2002.

[Dep85]

Department of Defence. Trusted Computer System Evaluation Criteria (“Orange Book”). Technical Report DoD 5200.28-STD, U.S. Department of Defence, 1985.

[DF02]

Ivan B. Damg˚ ard and Eiichihiro Fujisaki. A statistically hiding integer commitment scheme based on groups with hidden order. In ASIACRYPT’02, number 2501 in Lecture Notes in Computer Science, pages 125–142. Springer Verlag, 2002.

[DHL+ 11a] Alexandra Dmitrienko, Zecir Hadzic, Hans Löhr, Ahmad-Reza Sadeghi, and Marcel Winandy. Securing the acess to electronic health records on mobile phones. In Biomedical Engineering Systems and Technologies (BIOSTEC’11) – Revised Selected Papers, Communications in Computer and Information Science. Springer, 2011. (to appear). [DHL+ 11b] Alexandra Dmitrienko, Zecir Hadzic, Hans Löhr, Ahmad-Reza Sadeghi, and Marcel Winandy. A security architecture for accessing health records on mobile phones. In Proceedings of the 4th International Conference on Health Informatics (HEALTHINF’11), pages 87–96. SciTePress, 2011. [Din04]

Peter A. Dinda. Addressing the trust asymmetry problem in grid computing with encrypted computation. In LCR ’04: Proceedings of the 7th Workshop on Languages, Compilers, and Run-Time Support for Scalable Systems, pages 1–7. ACM Press, 2004.

[DKNS04] Yevgeniy Dodis, Aggelos Kiayias, Antonio Nicolosi, and Victor Shoup. Anonymous identification in ad hoc groups. In Advances in Cryptology – Proceedings of EUROCRYPT’04, volume 3027 of Lecture Notes in Computer Science, pages 609–626. Springer Verlag, 2004. [DLP+ 01] Joan G. Dyer, Mark Lindemann, Ronald Perez, Reiner Sailer, Leendert van Doorn, Sean W. Smith, and Steve Weingart. Building the IBM 4758 secure coprocessor. IEEE Computer, 34(10):57–66, 2001.

191

Bibliography [DR08]

Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard), August 2008.

[DTH06] Rachna Dhamija, J. D. Tygar, and Marti Hearst. Why Phishing Works. In Conference on Human Factors in Computing Systems (CHI’06), pages 581–590. ACM, 2006. [EC95]

European Parliament and Council of the European Union. Directive 95/46/EC of the European Parliament and of the Council of 24 october 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. Official Journal of the European Communities, (L 281):31–50, 1995.

[EMO+ 93] Jeremy Epstein, John McHugh, Hilarie Orman, Rita Pascale, Ann MarmorSquires, Bonnie Danner, Charles R. Martin, Martha Branstad, Glen Benson, and Doug Rothnie. A high assurance window system prototype. Journal of Computer Security, 2(2):159–190, 1993. [EMS08] EMSCB Project Consortium. The European Multilaterally Secure Computing Base (EMSCB) project. http://www.emscb.org, 2005–2008. [Esc08]

Alberto Nicol´ as Escalante Ba˜ nuelos. Privacy-protecting multi-coupon schemes with stronger protection against splitting. Master’s Thesis, 2008.

[Eur08a] European Multilaterally Secure Computing Base (EMSCB) Project. Towards trustworthy systems with open standards and trusted computing, 2008. http: //www.emscb.de/. [Eur08b] European Network and Information Security Agency (ENISA). Secure USB Flash Drives, June 2008. http://www.enisa.europa.eu/doc/pdf/ publications/SecureUSBdrives_180608.pdf. [Eve05]

Joris Evers. Phishers get personal, May 2005. http://news.com.com/ Phishers+get+personal/2100-7349_3-5720672.html.

[Fab07]

Michael Fabian. Endpoint security: managing USB-based removable devices with the advent of portable applications. In Proceedings of the Fourth Annual Conference on Information Security Curriculum Development (InfoSecCD’07), pages 1–5. ACM, 2007.

[Fad06]

Glenn Faden. Solaris trusted extensions: Architectural overview, April 2006.

[FKT01] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid: Enabling scalable virtual organizations. International Journal of Supercomputer Applications, 3(15), 2001. [FKTT98] Ian Foster, Carl Kesselman, Gene Tsudik, and Steven Tuecke. A security architecture for computational grids. In Proceedings of the Fifth ACM Conference on Computer and Communications Security (CCS’98). ACM Press, 1998.

192

Bibliography [FMSW11] Atanas Filyanov, Jonathan M. McCune, Ahmad-Reza Sadeghi, and Marcel Winandy. Uni-directional trusted path: Transaction confirmation on just one device. In Proceedings of the 41st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’11). IEEE Computer Society, 2011. (to appear). [FO97]

Eiichiro Fujisaki and Tatsuaki Okamoto. Statistical zero knowledge protocols to prove modular polynomial relations. In Advances in Cryptology – Proceedings of CRYPTO’97, volume 1294 of Lecture Notes in Computer Science, pages 16–30. Springer Verlag, 1997.

[FPV98] Alfonso Fuggetta, Gian Pietro Picco, and Giovanni. Vigna. Understanding code mobility. IEEE Transactions on Software Engineering, 24(5), 1998. [Fra83]

Lester J. Fraim. SCOMP: A solution to the multilevel security problem. In IEEE Computer, pages 26–34. IEEE Computer Society, 1983.

[FS87]

Amos Fiat and Adi Shamir. How to prove yourself: practical solutions to identification and signature problems. In Proceedings on Advances in cryptology— CRYPTO ’86, pages 186–194, London, UK, 1987. Springer-Verlag.

[FSW09] Thomas Fischer, Ahmad-Reza Sadeghi, and Marcel Winandy. A pattern for secure graphical user interface systems. In The Third International Workshop on Secure systems methodologies using patterns (SPattern’09), Proceedings of the 20th International Workshop on Database and Expert Systems Applications, pages 186–190. IEEE Computer Society, 2009. [Gas88]

Morrie Gasser. Building a Secure Computer System. Van Nostrand Reinhold, 1988. Available online at http://cs.unomaha.edu/~stanw/gasserbook.pdf.

[Gem]

Gematik - Gesellschaft f¨ ur Telematikanwendungen der Gesundheitskarte. http: //www.gematik.de.

[Gem09a] Gematik. Einf¨ uhrung der Gesundheitskarte - Gesamtarchitektur, Version 1.7.0. http://www.gematik.de/upload/GA_ZentraleDienste_5171.zip, August 2009. [Gem09b] Gematik. Einf¨ uhrung der Gesundheitskarte - Netzwerkspezifikation, Version 2.0.0. http://www.gematik.de/upload/GA_ZentraleDienste_5171.zip, August 2009. [GGP+ 09] Ryan W. Gardner, Sujata Garera, Matthew W. Pagano, Matthew Green, and Aviel D. Rubin. Securing medical records on smart phones. In Proceedings of the First ACM Workshop on Security and Privacy in Medical and Home-Care Systems, SPIMACS ’09, pages 31–40. ACM, 2009. [GHK06] David Galindo, Javier Herranz, and Eike Kiltz. On the generic construction of identity-based signatures with additional properties. In Advances in Cryptology – Proceedings of ASIACRYPT’06, volume 4284 of Lecture Notes in Computer Science, pages 178–193. Springer, 2006.

193

Bibliography [GJP+ 05] John L. Griffin, Trent Jaeger, Ronald Perez, Reiner Sailer, Leendert van Doorn, and Ram´ on C´ aceres. Trusted Virtual Domains: Toward secure distributed services. In Proceedings of the First IEEE Workshop on Hot Topics in System Dependability (HotDep’05). IEEE Computer Society, 2005. [GLSW09] Sebastian Gajek, Hans Löhr, Ahmad-Reza Sadeghi, and Marcel Winandy. TruWallet: Trustworthy and migratable wallet-based web authentication. In Proceedings of the 4th ACM Workshop on Scalable Trusted Computing (STC’09), pages 19–28. ACM, 2009. [GMP+ 08] Sebastian Gajek, Mark Manulis, Olivier Pereira, Ahmad-Reza Sadeghi, and J¨ org Schwenk. Universally composable security analysis of TLS. In Provable Security – Second International Conference, ProvSec 2008, pages 313–327, 2008. [GNV09] Eimear Gallery, Aarthi Nagarajan, and Vijay Varadharajan. A propertydependent agent transfer protocol. In Proceedings of the Second International Conference on Trusted Computing (TRUST’09), volume 5471 of Lecture Notes in Computer Science, pages 240–263. Springer, 2009. [Gol72]

Robert P. Goldberg. Architectural Principles for Virtual Computer Systems. PhD thesis, Harvard University, 1972.

[Gol01]

Oded Goldreich. Foundations of Cryptography – Volume I Basic Tools. Cambridge University Press, 2001.

[Gol04]

Oded Goldreich. Foundations of Cryptography – Volume II Basic Applications. Cambridge University Press, 2004.

[Goo10]

Google Android. Security and permissions. http://developer.android.com/ intl/de/guide/topics/security/security.html, 2010.

[GP06]

Thomas Groß and Birgit Pfitzmann. SAML artifact information flow revisited. In IEEE Web Services Security Symposium (WSSS’06), pages 84–100. CERIAS, 2006.

[GPC+ 03a] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, and Dan Boneh. Terra: A virtual machine-based platform for trusted computing. In 19th ACM Symposium on Operating Systems Principles (SOSP’03), pages 193–206. ACM, 2003. [GPC+ 03b] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, and Dan Boneh. Terra: A virtual machine-based platform for trusted computing. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP’03), 2003. [GPS06] Kenneth Goldman, Ronald Perez, and Reiner Sailer. Linking remote attestation to secure tunnel endpoints. In Proceedings of the First ACM Workshop on Scalable Trusted Computing (STC’06), pages 21–24. ACM Press, 2006. [GQ90]

194

Louis C. Guillou and Jean-Jacques Quisquater. A ”paradoxical” indentity-based signature scheme resulting from zero-knowledge. In Advances in Cryptology – Proceedings of CRYPTO’88, volume 403 of Lecture Notes in Computer Science, pages 216–231. Springer, 1990.

Bibliography [GRS99] David M. Goldschlag, Michael G. Reed, and Paul F. Syverson. Onion routing. Commun. ACM, 42(2):39–41, 1999. [GSC08] Sebastian Gajek, J¨ org Schwenk, and Xuan Chen. On the insecurity of microsoft’s identity metasystem cardspace. Technical Report HGI TR-2008-004, Horst G¨ ortz Institute for IT-Security, Ruhr-University Bochum, 2008. [GSS+ 08] Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Marcel Winandy, Rani Husseiki, and Christian St¨ uble. Flexible and secure enterprise rights management based on trusted virtual domains. In Proceedings of the Third ACM Workshop on Scalable Trusted Computing (STC’08), pages 71–80. ACM, 2008. [GSSW07] Sebastian Gajek, Ahmad-Reza Sadeghi, Christian St¨ uble, and Marcel Winandy. Compartmented security for browsers – or how to thwart a phisher with trusted computing. In Proceedings of the Second International Conference on Availability, Reliability and Security (ARES’07), pages 120–127. IEEE Computer Society, 2007. [GTK08] Chris Grier, Shuo Tang, and Samuel T. King. Secure web browsing with the OP web browser. In IEEE Symposium on Security and Privacy (S&P’08), pages 402–416. IEEE Computer Society, 2008. [HCF04] Vivek Haldar, Deepak Chandra, and Michael Franz. Semantic remote attestation: A virtual machine directed approach to trusted computing. In USENIX Virtual Machine Research and Technology Symposium, May 2004. [HCL+ 10] Chien-Yeh Hsu, Yen-Chen Chen, Ren-Chyuan Luo, Hsiao-Hsien Rau, ChienTe Fan, Bai-Sheng Hsiao, and Hung-Wen Chiu. A resource-sharing platform for trading biomedical intellectual property. IT Professional, 12:42–49, 2010. [Hea11]

Health Level Seven International (HL7). HL7 homepage. http://www.hl7.org, 2011.

[HHF+ 05] Herman H¨ artig, Michael Hohmuth, Norman Feske, Christian Helmuth, Adam Lackorzynski, Frank Mehnert, and Michael Peter. The Nizza secure-system architecture. In Proceedings of the First International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom’05). IEEE Computer Society, 2005. [Hil10]

Hildon Application Framework. Project website. http://live.gnome.org/ Hildon, 2010.

[HKS+ 05] Kai Hwang, Yu-Kwong Kwok, Shanshan Song, Mi Cai Yu Chen, Ying Chen, Runfang Zhou, and Xiaosong Lou. Gridsec: Trusted grid computing with security bindings and self-defense against network worms and ddos attacks. In Lecture Notes in Computer Science, volume 3516, pages 187–195, 2005. [HPL08] Dongsoo Han, Sungjoon Park, and Minkyu Lee. THE-MUSS: Mobile u-health service system. In Biomedical Engineering Systems and Technologies, International Joint Conference, BIOSTEC 2008, Revised Selected Papers, volume 25

195

Bibliography of Communications in Computer and Information Science, pages 377–389. Springer, 2008. [IB01]

Sotiris Ioannidis and Steven M. Bellovin. Building a secure web browser. In FREENIX Track: 2001 USENIX Annual Technical Conference, pages 127–134. USENIX Association, 2001.

[ID-05]

ID theft ring hits 50 banks, security firm says, 2005. http://news.cnet.com/ 2100-7349_3-5823591.html.

[Int]

International Organization for Standardization (ISO). Technical Committee 215, Health Informatics. http://www.iso.org/iso/iso_technical_committee? commid=54960.

[Int07a]

Intel Corp. Intel trusted execution technology home page. http://www.intel. com/technology/security, 2007.

[Int07b]

Intel Corp. Intel virtualization technology home page. http://www.intel.com/ technology/virtualization, 2007.

[Int08a]

Intel Corporation. Intel trusted execution technology software development guide. Technical Report Document Number: 315168-005, Intel Corporation, June 2008.

[Int08b]

Internet Crime Complaint Center. 2008 Internet Crime Report. http://www. ic3.gov/media/annualreport/2008_IC3Report.pdf, 2008.

[IW10]

Vincenzo Iozzo and Ralf-Philipp Weinmann. RalfPhilipp Weinmann & Vincenzo Iozzo own the iPhone at PWN2OWN. http://blog.zynamics.com/2010/03/24/ ralf-philipp-weinmann-vincenzo-iozzo-own-the-iphone-at-pwn2own, March 2010.

[Jab96]

David P. Jablon. Strong password-only authenticated key exchange. Computer Communication Review, 26(5):5–26, 1996.

[JBM06] Collin Jackson, Dan Boneh, and John Mitchell. Spyware resistant web authentication using virtual machines. http://crypto.stanford.edu/spyblock/, 2006. [JBM07] Collin Jackson, Dan Boneh, and John Mitchell. Transaction generators: Root kits for web. In Proceedings of the Second USENIX Workshop on Hot Topics in Security (HotSec’07), pages 1–4. USENIX Association, 2007. [JKK06] Nenad Jovanovic, Engin Kirda, and Christopher Kruegel. Preventing cross site request forgery attacks. In IEEE International Conference on Security and Privacy in Communication Networks (SecureComm’06). IEEE Computer Society, 2006. [JSM01] Shan Jiang, Sean Smith, and Kazuhiro Minami. Securing web servers against insider attack. In 17th Annual Computer Security Applications Conference (ACSAC’01), pages 265–276. IEEE Computer Society, 2001.

196

Bibliography [JSS06]

Trent Jaeger, Reiner Sailer, and Umesh Shankar. PRIMA: policy-reduced integrity measurement architecture. In Proceedings of the Eleventh ACM Symposium on Access Control Models and Technologies (SACMAT’06), pages 19–28, 2006.

[JvdHM+ 06] Ravi C. Jammalamadaka, Timothy W. van der Horst, Sharad Mehrotra, Kent E. Seamons, and Nalini Venkasubramanian. Delegate: A proxy based architecture for secure website access from an untrusted machine. In Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC’06), pages 57–66. IEEE Computer Society, 2006. [Kas]

Kassen¨ arztliche Bundesvereinigung. KV-SafeNet homepage. http://www.kbv. de/12705.html.

[KCLC07] Ponnurangam Kumaraguru, Lorrie F. Cranor, Jorge Lobo, and Seraphin Calo. A survey of privacy policy languages. In Workshop on Usable IT Security Management (USM’07): Proceedings of the Third Symposium on Usable Privacy and Security (SOUPS’07). ACM, 2007. [KD07]

Peter C. S. Kwan and Glenn Durfee. Practical uses of virtual machines for protection of sensitive user data. In Information Security Practice and Experience Conference (ISPEC’07), pages 145–161. Springer, 2007.

[KDE+ 10] Kari Kostiainen, Alexandra Dmitrienko, Jan-Erik Ekberg, Ahmad-Reza Sadeghi, and N. Asokan. Key attestation from trusted execution environments. In Proceedings of the Third International Conference on Trust and Trustworthy Computing (TRUST’10), pages 30–46. Springer, 2010. [KEAR09] Kari Kostiainen, Jan-Erik Ekberg, N. Asokan, and Aarne Rantala. On-board credentials with open provisioning. In Proceedings of the Fourth International Symposium on Information, Computer, and Communications Security (ASIACCS’09), pages 104–115. ACM, 2009. [KEH+ 09] Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch, and Simon Winwood. seL4: Formal verification of an OS kernel. In Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP’09), pages 207–220. ACM, 2009. [KKVJ06] Engin Kirda, Christopher Kr¨ ugel, Giovanni Vigna, and Nenad Jovanovic. Noxes: A client-side solution for mitigating cross-site scripting attacks. In Proceedings of the 2006 ACM Symposium on Applied Computing (SAC’06), pages 330–337. ACM, 2006. [KKW+ 06] Yasuharu Katsuno, Michiharu Kudo, Yuji Watanabe, Sachiko Yoshihama, Ron Perez, and Reiner Sailer an Leendert van Dorn. Towards Multi-Layer Trusted Virtual Domains. In The Second Workshop on Advances in Trusted Computing (WATC’06 Fall), Tokyo, Japan, November 2006. Japanese Ministry of Economy, Trade and Industry (METI).

197

Bibliography [KL08]

Jonathan Katz and Yehuda Lindell. Introduction to ModernCryptography. Chapman & Hall/CRC, 2008.

[KR00]

D. Kormann and A. Rubin. Risks of the passport single signon protocol. Computer Networks, 33(1–6):51–58, 2000.

[Kre06]

Brian Krebs. The new face of phishing. Washington Post, 2006. http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_ of_phishing_1.html.

[KRS+ 03] Mahesh Kallahalla, Erik Riedel, Ram Swaminathan, Qian Wang, and Kevin Fu. Plutus: Scalable secure file sharing on untrusted storage. In Proceedings of the FAST ’03 Conference on File and Storage Technologies, March 31 - April 2, 2003, Cathedral Hill Hotel, San Francisco, California, USA. USENIX, 2003. [KSS07] Ulrich K¨ uhn, Marcel Selhorst, and Christian St¨ uble. Realizing property-based attestation and sealing with commonly available hard- and software. In STC ’07: Proceedings of the 2007 ACM workshop on Scalable trusted computing, pages 50–57. ACM, 2007. [KTY04] Aggelos Kiayias, Yiannis Tsiounis, and Moti Yung. Traceable signatures. In EUROCRYPT’04, number 3027 in Lecture Notes in Computer Science, pages 571–589. Springer Verlag, 2004. [KZB+ 90] Paul A. Karger, Mary E. Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. A VMM security kernel for the VAX architecture. In IEEE Symposium on Security and Privacy (S&P’90), pages 2–19. IEEE Computer Society, 1990. [Lie95]

Jochen Liedtke. On micro-kernel construction. In Fifteenth ACM Symposium on Operating System Principles (SOSP’95), pages 237–250. ACM Press, 1995.

[Lin06]

Andrew Yehuda Lindell. Anonymous authentication. Aladdin Knowledge Systems Inc., http://www.aladdin.com/blog/pdf/AnonymousAuthentication. pdf, 2006.

[Lip03]

Helger Lipmaa. On diophantine complexity and statistical zero–knowledge arguments. In ASIACRYPT’03, number 2894 in Lecture Notes in Computer Science, pages 398–415. Springer Verlag, 2003.

[LKMS04] Jinyuan Li, Maxwell N. Krohn, David Mazières, and Dennis Shasha. Secure untrusted data repository (sundr). In OSDI, pages 121–136, 2004. [LM07]

Adrian Leung and Chris J. Mitchell. Ninja: Non identity based, privacy preserving authentication for ubiquitous environments. In Ubiquitous Computing (UbiComp’07), volume 4171 of Lecture Notes in Computer Science, pages 73–90. Springer, 2007.

[LPR+ 10] Hans L¨ ohr, Thomas Pöppelmann, Johannes Rave, Martin Steegmanns, and Marcel Winandy. Trusted virtual domains on OpenSolaris: Usable secure desktop environments. In Proceedings of the 4th ACM Workshop on Scalable Trusted Computing (STC’10), pages 91–96. ACM, 2010.

198

Bibliography [LRS+ 07] Hans L¨ ohr, HariGovind Ramasamy, Ahmad-Reza Sadeghi, Stefan Schulz, Matthias Schunter, and Christian St¨ uble. Enhancing grid security using trusted virtualization. In Proceedings of the 4th International Conference on Autonomic and Trusted Computing (ATC’07), volume 4610 of Lecture Notes in Computer Science, pages 372–384. Springer, 2007. [LS01]

Peter Loscocco and Stephen Smalley. Integrating flexible support for security policies into the Linux operating system. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, pages 29–42. USENIX Association, 2001.

[LSS+ 09] Hans L¨ ohr, Ahmad-Reza Sadeghi, Christian St¨ uble, Marion Weber, and Marcel Winandy. Modeling trusted computing support in a protection profile for high assurance security kernels. In Proceedings of the 2nd International Conference on Trusted Computing (TRUST’09), volume 5471 of Lecture Notes in Computer Science, pages 45–62. Springer, 2009. [LSVW09] Hans L¨ ohr, Ahmad-Reza Sadeghi, Claire Vishik, and Marcel Winandy. Trusted privacy domains – challenges for trusted computing in privacy-protecting information sharing. In Proceedings of the 5th International Conference on Information Security Practice and Experience (ISPEC’09), volume 5451 of Lecture Notes in Computer Science, pages 396–407. Springer, 2009. [LSW10a] Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. Patterns for secure boot and secure storage in computer systems. In Proceedings of the 4th International Workshop of Secure System Methodologies Using Patterns (SPattern’10), In Proc. of Fifth International Conference on Availability, Reliability and Security (ARES’10), pages 569–573. IEEE Computer Society, 2010. [LSW10b] Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. Securing the e-health cloud. In Proceedings of the First ACM International Health Informatics Symposium (IHI’10), pages 220–229. ACM, 2010. [LWS+ 74] Steven B. Lipner, William A. Wulf, Roger R. Schell, Gerald J. Popek, Peter G. Neumann, Clark Weissman, and Theodore A. Linden. Security kernels. In AFIPS National Computer Conference, pages 973–980. AFIPS Press, 1974. [Lyo09]

Gordon “Fyodor” Lyon. Nmap OS fingerprinting. http://www.insecure.org/ nmap/nmap-fingerprinting-article.html, 2009.

[Mae10]

Maemo. Project website. http://maemo.org, 2010.

[MBC+ 06] Jonathan M. McCune, Stefan Berger, Ramón Cáceres, Trent Jaeger, and Reiner Sailer. DeuTeRiuM – A system for distributed mandatory access control. In Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC’06). IEEE Computer Society, 2006. [Mic06]

Microsfot Corp. Bitlocker drive encryption, 2006. http://technet.microsoft. com/en-us/windows/aa905065.aspx.

199

Bibliography [Mic10]

Microsoft. Windows mobile website. windowsmobile, 2010.

http://www.microsoft.com/

[MMJZ06] Wenbo Mao, Andrew Martin, Hai Jin, and Huanguo Zhang. Innovations for grid security from trusted computing. In The 14th International Security Protocols Workshop (SPW’06), Revised Selected Papers, volume 5087 of Lecture Notes in Computer Science, pages 132–149. Springer, 2006. [Mos05]

Tim Moses. eXtensible Access Control Markup Language (XACML) version 2.0. Technical report, Oasis, 2005.

[MPP+ 07] Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael K. Reiter, and Arvind Seshadri. Minimal tcb code execution. In IEEE Symposium on Security and Privacy (S&P’07), pages 267–272. IEEE Computer Society, 2007. [MRK03] Silvio Micali, Michael O. Rabin, and Joe Kilian. Zero-knowledge sets. In Proceedings of the 44th Symposium on Foundations of Computer Science (FOCS’03), pages 80–91. IEEE Computer Society, 2003. [MRWHZ04] Kiran-Kumar Muniswamy-Reddy, Charles P. Wright, Andrew Himmer, and Eres Zadok. A Versatile and User-Oriented Versioning File System. In Proceedings of the Third USENIX Conference on File and Storage Technologies (FAST’04), pages 115–128. USENIX Association, 2004. [MSMW03] Rich Macdonald, Sean Smith, John Marchesini, and Omen Wild. Bear: An open-source virtual secure coprocessor based on TCPA. Technical Report TR2003-471, Department of Computer Science, Dartmouth College, 2003. [MSW+ 04] John Marchesini, Sean W. Smith, Omen Wild, Alex Barsamian, and Joshua Stabiner. Open-source applications of TCPA hardware. In Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC’04). ACM, 2004. [MSWM03] John Marchesini, Sean W. Smith, Omen Wild, and Rich MacDonald. Experimenting with TCPA/TCG hardware, or: How I learned to stop worrying and love the bear. Technical Report TR2003-476, Department of Computer Science, Dartmouth College, 2003. http://www.cs.dartmouth.edu/~sws/abstracts/ mswm03.shtml. [MvOV97] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbook of Applied Cryptography. CRC Press, 1997. Available online at http://www. cacr.math.uwaterloo.ca/hac/. [MYC06] Wenbo Mao, Fei Yan, and Chunrun Chen. Daonity—grid security with behaviour conformity from trusted computing. In Proceedings of the First ACM Workshop on Scalable Trusted Computing (STC’06), 2006. [Nat02]

National Institute of Standards and Technology (NIST). Secure hash standard (SHS), August 2002. FIPS PUB 180-2.

[Nat06]

National Institute of Standards and Technology (NIST). Digital signature standard (DSS), March 2006. FIPS PUB 186-3 (Draft).

200

Bibliography [Ngu06]

Lan Nguyen. Privacy-protecting coupon system revisited. In Financial Cryptography and Data Security (FC’06), number 4107 in Lecture Notes in Computer Science, pages 266–280. Springer Verlag, 2006.

[NJM03] Ricardo Nabhen, Edgard Jamhour, and Carlos Maziero. A policy based framework for access control. In Proceedings of ICICS, pages 47–59, 2003. [NSN05] Lan Nguyen and Rei Safavi-Naini. Dynamic k-times anonymous authentication. In Proceedings of the Third International Conference on Applied Cryptography and Network Security (ACNS’05), volume 3531 of Lecture Notes in Computer Science, pages 318–333. Springer, 2005. [NSW05] Dalit Naor, Amir Shenhav, and Avishai Wool. Toward securing untrusted storage without public-key operations. In Proceedings of the 2005 ACM Workshop On Storage Security And Survivability (StorageSS’05), pages 51–56. ACM, 2005. [NV11]

Aarthi Nagarajan and Vijay Varadharajan. Dynamic trust enhanced security model for trusted platform based services. Future Generation Comp. Syst., 27(5):564–573, 2011.

[NVH09] Aarthi Nagarajan, Vijay Varadharajan, and Michael Hitchens. ALOPA: Authorization Logic for Property Attestation in Trusted Platforms. In Proceedings of the 6th International Conference of Autonomic and Trusted Computing (ATC’09), volume 5586 of Lecture Notes in Computer Science, pages 134–148. Springer, 2009. [NVHA08] Aarthi Nagarajan, Vijay Varadharajan, Michael Hitchens, and Saurabh Arora. On the applicability of trusted computing in distributed authorization using web services. In Data and Applications Security XXII, 22nd Annual IFIP WG 11.3 Working Conference on Data and Applications Security (DBSec’08), volume 5094 of Lecture Notes in Computer Science, pages 222–237. Springer, 2008. [NVHG09] Aarthi Nagarajan, Vijay Varadharajan, Michael Hitchens, and Eimear Gallery. Property based attestation and trusted computing: Analysis and challenges. In Proceedings of the Third International Conference on Network and System Security (NSS’09), pages 278–285. IEEE Computer Society, 2009. [Odl03]

Andrew Odlyzko. Privacy, economics, and price discrimination on the internet. In Proceedings of the 5th International Conference on Electronic Commerce (ICEC’03), pages 355–366, New York, NY, USA, 2003. ACM Press.

[OHB08] Rolf Oppliger, Ralf Hauser, and David A. Basin. Ssl/tls session-aware user authentication revisited. Computers & Security, 27(3-4):64–70, 2008. [Ope09a] Open Mobile Terminal Platform Consortium. OMTP advanced trusted environment: OMTP TR1 (v1.1), 2009. Recommendation document, available online at http://www.omtp.org/Publications.aspx. [Ope09b] OpenTC Project Consortium. The Open Trusted Computing (OpenTC) project. http://www.opentc.net, 2005–2009.

201

Bibliography [Ope10]

Open Kernel Labs. OKL4 project website. http://okl4.org, 2010.

[Ora11]

Oracle Corporation. VirtualBox website. http://www.virtualbox.org, 2011.

[Par10]

Paros. Project website. http://www.parosproxy.org, 2010.

[PB05]

Zachary N.J. Peterson and Randall C. Burns. Ext3cow: A Time-Shifting File System for Regulatory Compliance. ACM Transactions on Storage (TOS), 1(2):190–212, 2005.

[PBAB07] Zachary N.J. Peterson, Randall C. Burns, Giuseppe Ateniese, and Stephen Bono. Design and implementation of verifiable audit trails for a versioning file system. In Proceedings of the Fifth USENIX conference on File and Storage Technologies (FAST’07), pages 20–20. USENIX Association, 2007. [Ped92]

Torben Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In Advances in Cryptology – Proceedings of CRYPTO’91, volume 576 of Lecture Notes in Computer Science, pages 129–140. Springer Verlag, 1992.

[PG04]

Kristen Park and Miguel Gómez. The coupon report: A study of coupon discount methods. Technical report, Department of Applied Economics and Management, Cornell University, 2004. http://aem.cornell.edu/research/ researchpdf/rb0407.pdf.

[PKvM08] Simon Edward Parkin, Rouaa Yassin Kassab, and Aad P. A. van Moorsel. The impact of unavailability on the effectiveness of enterprise information security technologies. In Proceedings of the Fifth International Service Availability Symposium (ISAS’08), volume 5017 of Lecture Notes in Computer Science, pages 43–58. Springer, 2008. [PM04]

Andreas Pashalidis and Chris J. Mitchell. Impostor: A single sign-on system for use from untrusted devices. In Proceedings of IEEE Global Telecommunications Conference 2004 (Globecom’04), volume 4, pages 2191–2195. IEEE Press, 2004.

[PMM+ 07] Niels Provos, Dean McNamee, Panayiotis Mavrommatis, Ke Wang, and Nagendra Modadugu. The ghost in the browser analysis of web-based malware. In First Workshop on Hot Topics in Understanding Botnets (HotBots’07), pages 4–4. USENIX Association, 2007. [PRS+ 01] Birgit Pfitzmann, James Riordan, Christian St¨ uble, Michael Waidner, and Arnd Weber. The PERSEUS system architecture. Technical Report RZ 3335 (#93381), IBM Research, April 2001. [PSVW04] Jonathan Poritz, Matthias Schunter, Els Van Herreweghen, and Michael Waidner. Property attestation—scalable and privacy-friendly security assessment of peer computers. Technical Report RZ 3548, IBM Research, May 2004. [PV04]

202

Pino Persiano and Ivan Visconti. An efficient and usable multi-show nontransferable anonymous credential system. In Financial Cryptography and Data Security (FC’04), number 3110 in Lecture Notes in Computer Science, pages 196–211. Springer Verlag, February 2004.

Bibliography [PW01]

Birgit Pfitzmann and Michael Waidner. A model for asynchronous reactive systems and its application to secure message transmission. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 184–200. IEEE Computer Society, 2001.

[PW03]

Birgit Pfitzmann and Michael Waidner. Analysis of liberty single-sign-on with enabled clients. IEEE Internet Computing, 7(6):38–44, 2003.

[RGL07] Charles Reis, Steven D. Gribble, and Henry M. Levy. Architectural principles for safe web programs. In 6th Workshop on Hot Topics in Networks (HotNets’07). ACM, Nov 2007. [RHL+ 10] Hsiao-Hsien Rau, Chien-Yeh Hsu, Yen-Liang Lee, Wei Chen, and Wen-Shan Jian. Developing electronic health records in Taiwan. IT Professional, 12:17– 25, 2010. [RJM+ 05] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh, and John C. Mitchell. Stronger password authentication using browser extensions. In Proceedings of the 14th USENIX Security Symposium. USENIX Association, 2005. [Rob10]

Jordan Robertson. Supergeek pulls off ‘near impossible’ crypto chip hack. http://www.nzherald.co.nz/technology/news/article.cfm?c_id= 5&objectid=10625082&pnum=0, February 2010. News article at NZ Herald.

[RR98]

Michael K. Reiter and Aviel D. Rubin. Crowds: Anonymity for web transactions. ACM Trans. Inf. Syst. Secur., 1(1):66–92, 1998.

[RST01] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to leak a secret. In Advances in Cryptology – Proceedings of ASIACRYPT’01, volume 2248 of Lecture Notes in Computer Science, pages 552–565. Springer, 2001. [RUB11] RUBTrust/MediTrust Project Consortium. RUBTrust/MediTrust Project Website. http://www.rubtrust-meditrust.de, 2011. [Rut06]

Joanna Rutkowska. Blue pill. Presented at the Symposium on Security for Asia Network 2006 (SyScan’06), 2006. http://theinvisiblethings.blogspot. com/.

[SAA+ 06] Thomas Schabetsberger, Elske Ammenwerth, Stefan Andreatta, Gordon Gratl, Reinhold Haux, Georg Lechleitner, Klaus Schindelwig, Christian Stark, Raimund Vogl, Immanuel Wilhelmy, and Florian Wozak. From a paper-based transmission of discharge summaries to electronic communication in health care regions. International Journal of Medical Informatics, 75:209–215, 2006. [SAH+ 03] Matthias Schunter, Paul Ashley, Satoshi Hada, G¨ unter Karjoth, and Calvin Powers. Enterprise Privacy Authorization Language (EPAL 1.1). Technical report, IBM, 2003. [San06]

Stefan Santesson. TLS Handshake Message for Supplemental Data. RFC 4680 (Proposed Standard), October 2006.

203

Bibliography [SAN07] SANS Institute. SANS Top-20 2007 Security Risks. http://www.sans.org/ top20/2007/top20.pdf, November 2007. [Sch91]

Claus-Peter Schnorr. Efficient signature generation by smart cards. Journal of Cryptology, 4(3):161–174, 1991.

[SDP73] Roger R. Schell, Peter J. Downey, and Gerald J. Popek. Preliminary notes on the design of secure military computer systems. Technical Report MCI-73-1, The MITRE Corporation, 1973. [SFEF06] Matthew Smith, Thomas Friese, Michael Engel, and Bernd Freisleben. Countering security threats in service-oriented on-demand grid computing using sandboxing and trusted computing techniques. Journal of Parallel and Distributed Computing, 66(9):1189–1204, 2006. [SGSG03] Craig A. N. Soules, Garth R. Goodson, John D. Strunk, and Gregory R. Ganger. Metadata Efficiency in Versioning File Systems. In Proceedings of the Second USENIX Conference on File and Storage Technologies (FAST’03), pages 43–58. USENIX Association, 2003. [SHC+ 08] Norman Sadeh, Jason Hong, Lorrie F. Cranor, Ian Fette, Patrick Kelley, Madhu Prabaker, and Jinghai Rao. Understanding and capturing people’s privacy policies in a mobile social networking application. Journal of Personal and Ubiquitous Computing, 2008. [Shi06]

Kanna Shimizu. The Cell Broadband Engine processor security architecture. http://www.ibm.com/developerworks/power/library/pa-cellsecurity/, April 2006.

[Sho04]

Victor Shoup. Sequences of games: a tool for taming complexity in security proofs, 2004. Report 2004/332 http://eprint.iacr.org/2004/332.

[SJV+ 05] Reiner Sailer, Trent Jaeger, Enriquillo Valdez, Ramón Cáceres, Ronald Perez, Stefan Berger, John L. Griffin, and L. van Doorn. Building a MAC-based security architecture for the Xen open-source hypervisor. In Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC’05), pages 276–285. IEEE Computer Society, 2005. [SK08]

Gautam Singaraju and Brent Hoon Kang. Concord: A secure mobile data authorization framework for regulatory compliance. In Proceedings of the 22nd Large Installation System Administration Conference (LISA’08), pages 91–102. USENIX Association, 2008.

[SKMK09] Ali Sunyaev, Alexander Kaletsch, Christian Mauro, and Helmut Krcmar. Security analysis of the german electronic health card’s peripheral parts. In ICEIS 2009 - Proceedings of the 11th International Conference on Enterprise Information Systems, Volume ISAS, Milan, Italy, May 6-10, 2009, pages 19–26, 2009. [SLK10] Ali Sunyaev, Jan M. Leimeister, and Helmut Krcmar. Open security issues in german healthcare telematics. In Proceedings of the Third International Conference on Health Informatics (HEALTHINF’10), pages 187–194. INSTICC, 2010.

204

Bibliography [SM08]

Sean Smith and John Marchesini. The Craft of System Security. Addison Wesley, 2008.

[Sof06]

Damian Sofsian. An introduction to medical billing. e-healtharticles.com/Detailed/1449.html, April 2006.

http://www.

[SPH99] Stuart Schechter, Todd Parnell, and Alexander Hartemink. Anonymous authentication of membership in dynamic groups. In Third International Conference on Financial Cryptography (FC’99), volume 1648 of Lecture Notes in Computer Science, pages 184–195. Springer, 1999. [SRC07] Ben Smyth, Mark Ryan, and Liqun Chen. Direct Anonymous Attestation (DAA): Ensuring privacy with corrupt administrators. In ESAS, pages 218– 231, 2007. [SS04]

Ahmad-Reza Sadeghi and Christian St¨ uble. Property-based attestation for computing platforms: Caring about properties, not mechanisms. In Proceedings of the 2004 New Security Paradigms Workshop (NSPW’04). ACM SIGSAC, ACM Press, 2004.

[SSA+ 08] Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger. MD5 considered harmful today— creating a rogue CA certificate. In The 25th Chaos Communication Congress (25C3), December 2008. http://www.win.tue.nl/hashclash/rogue-ca. [SSFG10] Marcel Selhorst, Christian St¨ uble, Florian Feldmann, and Utz Gnaida. Towards a trusted mobile desktop. In Trust and Trustworthy Computing (TRUST 2010), volume 6101 of Lecture Notes in Computer Science, pages 78–94. Springer, 2010. [SSG97] Paul F. Syverson, Stuart G. Stubblebine, and David M. Goldschlag. Unlinkable serial transactions. In Financial Cryptography and Data Security (FC’97), number 1318 in Lecture Notes in Computer Science, pages 39–56. Springer Verlag, 1997. [Sti02]

Douglas R. Stinson. Cryptography – Theory and Practice. Hall/CRC, 2002. Second Edition.

Chapman &

[STM+ 06] Henning Schulzrinne, Hannes Tschofenig, John Morris, Jorge Cuellar, James Polk, and Jonathan Rosenberg. A document format for expressing privacy preferences. http://tools.ietf.org/html/ draft-ietf-geopriv-common-policy-11, August 2006. [STRE06] Frederic Stumpf, Omid Tafreschi, Patrick Rder, and Claudia Eckert. A robust integrity reporting protocol for remote attestation. In Second Workshop on Advances in Trusted Computing (WATC’06 Fall), Tokyo, Japan, 2006. [STRL00] Paul F. Syverson, Gene Tsudik, Michael G. Reed, and Carl E. Landwehr. Towards an analysis of onion routing security. In Workshop on Design Issues in Anonymity and Unobservability, volume 2009 of Lecture Notes in Computer Science, pages 96–114. Springer, 2000.

205

Bibliography [Sun]

Sun Microsystems. Trusted Solaris 8 Operating System. http://www.sun.com/ software/solaris/trustedsolaris/. Accessed on June 2010.

[SV02]

Jonathan S. Shapiro and John Vanderburgh. Access and integrity control in a public-access, high-assurance configuration management system. In Proceedings of the 11th USENIX Security Symposium, San Francisco, CA, USA, August 5-9, 2002, pages 109–120. USENIX, 2002.

[SVJ+ 05] Reiner Sailer, Enriquillo Valdez, Trend Jaeger, Ronald Perez, Leendert van Doorn, John Linwood Griffin, and Stefan Berger. sHype: Secure hypervisor approach to trusted virtualized systems. Technical Report RC23511, IBM Research, February 2005. [SVL01] Jeremy Sugerman, Ganesh Venkitachalam, and Beng-Hong Lim. Virtualizing I/O devices on VMware workstation’s hosted virtual machine monitor. In Proceedings of the USENIX Annual Technical Conference, General Track, pages 1–14, 2001. [SW99]

Sean W. Smith and Steve Weingart. Building a high-performance, programmable secure coprocessor. Computer Networks, 31(8):831–860, April 1999.

[SW07]

Hovav Shacham and Brent Waters. Efficient ring signatures without random oracles. In Proceedings of Public Key Cryptography (PKC’07), volume 4450 of Lecture Notes in Computer Science, pages 166–180. Springer Verlag, 2007.

[Sym10] Symbian Foundation Community. Project website. http://www.symbian.org, 2010. [SZ10]

Christian St¨ uble and Anoosheh Zaerin. µTSS – A Simplified Trusted Software Stack. In Proceedings of the Third International Conference on Trust and Trustworthy Computing (TRUST 2010), volume 6101 of Lecture Notes in Computer Science, pages 124–140. Springer Verlag, 2010.

[SZJvD04] Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert van Doorn. Design and implementation of a TCG-based integrity measurement architecture. In Proceedings of the 13th USENIX Security Symposium, pages 223–238. USENIX Association, 2004. [The11]

The OpenSSL Project. OpenSSL website. http://www.openssl.org, 2011.

[Tic82]

Walter F. Tichy. Design, Implementation, and Evaluation of a Revision Control System. In Proceedings of the 6th International Conference on Software Engineering, pages 58–67. IEEE Computer Society, 1982.

[tra06]

New Trojans plunder bank accounts, 2006. 2100-7349_3-6041173.html.

[Tru02]

Trusted Computing Platform Alliance (TCPA). Main specification. http://www.trustedcomputinggroup.org/resources/tcpa_main_ specification_version_11b, February 2002. Version 1.1b.

206

http://news.cnet.com/

Bibliography [Tru04]

TrueCrypt Foundation. Truecrypt - free open-source on-the-fly encryption, 2004. http://www.truecrypt.org/.

[Tru07a] Trusted Computing Group. TCG Software Stack Specification Version 1.2, Level 1, Errata A. http://www.trustedcomputinggroup.org/resources/ tcg_software_stack_tss_specification, 2007. [Tru07b] Trusted Computing Group. TPM main specification, version 1.2 rev. 103, July 2007. http://www.trustedcomputinggroup.org/resources/tpm_main_ specification. [Tru10]

Trusted Computing Group, Mobile Phone Work Group. Mobile Trusted Module Specification, Version 1.0 rev. 7.02, 2010. http: //www.trustedcomputinggroup.org/resources/mobile_phone_work_ group_mobile_trusted_module_specification.

[Tru11]

Trusted Computing Group. trustedcomputinggroup.org, 2011.

[TS06]

Isamu Teranishi and Kazue Sako. k-times anonymous authentication with a constant proving cost. In Public Key Cryptography (PKC’06), volume 3958 of Lecture Notes in Computer Science, pages 525–542. Springer, 2006.

TCG

website.

https://www.

[TWMP07] David Taylor, Tom Wu, Nikos Mavrogiannopoulos, and Trevor Perrin. RFC5054: Using the secure remote password (SRP) protocol for TLS authentication, 2007. http://www.ietf.org/rfc/rfc5054. [Ven10]

Troy Vennon. Android malware. A study of known and potential malware threats. Technical Report White paper, SMobile Global Threat Center, Feb 2010.

[VKM+ 08] Demosthenes Vouyioukas, George Kambourakis, Ilias Maglogiannis, Angelos Rouskas, Constantinos Kolias, and Stefanos Gritzalis. Enabling the provision of secure web based m-health services utilizing xml based security models. Security and Communication Networks, 1(5):375–388, 2008. [WB90]

Samuel Warren and Louis D. Brandeis. The right to privacy. Harvard Law Review, 4(5):193–220, 1890.

[WH08]

Carsten Weinhold and Hermann Härtig. VPFS: Building a virtual private file system with a small trusted computing base. In Proceedings of the 2008 EuroSys Conference (EuroSys’08), pages 81–93. ACM, 2008.

[Wir08]

Wired. Under worm assault, military bans disks, USB drives, November 2008. http://www.wired.com/dangerroom/2008/11/army-bans-usb-d.

[WML06] Min Wu, Robert C. Miller, and Greg Little. Web Wallet: Preventing Phishing Attacks by Revealing User Intentions. In Proceedings of the Second Symposium on Usable Privacy and Security (SOUPS’06), pages 102–113. ACM, 2006.

207

Bibliography [WSB00] Uwe G. Wilhelm, Sebastian M. Staamann, and Levente Buttyan. A pessimistic approach to trust in mobile agent platforms. IEEE Internet Computing, 4(05):40–48, 2000. [Wu98]

Thomas Wu. The secure remote password protocol. In Network and Distributed System Security Symposium (NDSS’98), pages 97–111. The Internet Society, 1998.

[XF07]

Hequn Xian and Dengguo Feng. Protecting mobile agents’ data using trusted computing technology. Journal of Communication and Computer, 4(3):44–51, 2007.

[YEN+ 05] Sachiko Yoshihama, Tim Ebringer, Megumi Nakamura, Seiji Munetoh, and Hiroshi Maruyama. WS-Attestation: Efficient and fine-grained remote attestation on web services. In Proceedings of the 2005 IEEE International Conference on Web Services (ICWS’05), pages 743–750. IEEE Computer Society, 2005. [ZLGD05] Shanyu Zhao, Virginia Lo, and Chris Gauthier-Dickey. Result verification and trust-based scheduling in peer-to-peer grids. In Proceedings of the Fifth IEEE International Conference on P2P (P2P’05). IEEE Computer Society, 2005.

208

Part V.

Appendix

209

Publications by the Author Publications in Peer-Reviewed Conference and Workshop Proceedings [1] Thomas Hupperich, Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. Flexible patient-controlled security for electronic health records. In Proceedings of the 2nd ACM SIGHIT International Symposium on Health Informatics (IHI’12), pages 727– 732. ACM, 2012. [2] Alexandra Dmitrienko, Zecir Hadzic, Hans Löhr, Ahmad-Reza Sadeghi, and Marcel Winandy. A security architecture for accessing health records on mobile phones. In Proceedings of the 4th International Conference on Health Informatics (HEALTHINF’11), pages 87–96. SciTePress, 2011. [3] Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. Securing the e-health cloud. In Proceedings of the First ACM International Health Informatics Symposium (IHI’10), pages 220–229. ACM, 2010. [4] Hans L¨ ohr, Thomas P¨ oppelmann, Johannes Rave, Martin Steegmanns, and Marcel Winandy. Trusted virtual domains on OpenSolaris: Usable secure desktop environments. In Proceedings of the 4th ACM Workshop on Scalable Trusted Computing (STC’10), pages 91–96. ACM, 2010. [5] Liqun Chen, Kurt Dietrich, Hans Löhr, Ahmad-Reza Sadeghi, Christian Wachsmann, and Johannes Winter. Lightweight anonymous authentication with TLS and DAA for embedded mobile devices. In Proceedings of the 13th Information Security Conference (ISC’10), volume 6531 of Lecture Notes in Computer Science, pages 84–98. Springer, 2010. Full version available at http://eprint.iacr.org/2011/101.pdf. [6] Emanuele Cesena, Hans L¨ ohr, Gianluca Ramunno, Ahmad-Reza Sadeghi, and Davide Vernizzi. Anonymous authentication with TLS and DAA. In Proceedings of the 3rd International Conference on Trust and Trustworthy Computing (TRUST’10), volume 6101 of Lecture Notes in Computer Science, pages 47–62. Springer, 2010. [7] Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. Patterns for secure boot and secure storage in computer systems. In Proceedings of the 4th International Workshop of Secure System Methodologies Using Patterns (SPattern’10), In Proc. of Fifth International Conference on Availability, Reliability and Security (ARES’10), pages 569–573. IEEE Computer Society, 2010. [8] Luigi Catuogno, Hans L¨ ohr, Mark Manulis, Ahmad-Reza Sadeghi, and Marcel Winandy. Transparent mobile storage protection in trusted virtual domains. In Proceedings of the 23rd Large Installation System Administration Conference (LISA’09), pages 159–172. USENIX Association, 2009.

211

Publications by the Author [9] Sebastian Gajek, Hans L¨ ohr, Ahmad-Reza Sadeghi, and Marcel Winandy. TruWallet: Trustworthy and migratable wallet-based web authentication. In Proceedings of the 4th ACM Workshop on Scalable Trusted Computing (STC’09), pages 19–28. ACM, 2009. [10] Hans L¨ ohr, Ahmad-Reza Sadeghi, Christian St¨ uble, Marion Weber, and Marcel Winandy. Modeling trusted computing support in a protection profile for high assurance security kernels. In Proceedings of the 2nd International Conference on Trusted Computing (TRUST’09), volume 5471 of Lecture Notes in Computer Science, pages 45–62. Springer, 2009. [11] Hans L¨ ohr, Ahmad-Reza Sadeghi, Claire Vishik, and Marcel Winandy. Trusted privacy domains – challenges for trusted computing in privacy-protecting information sharing. In Proceedings of the 5th International Conference on Information Security Practice and Experience (ISPEC’09), volume 5451 of Lecture Notes in Computer Science, pages 396–407. Springer, 2009. [12] Liqun Chen, Hans L¨ ohr, Mark Manulis, and Ahmad-Reza Sadeghi. Property-based attestation without a trusted third party. In Proceedings of the 11th Information Security Conference (ISC’08), volume 5222 of Lecture Notes in Computer Science, pages 31–46. Springer, 2008. [13] Frederik Armknecht, Alberto N. Escalante, Hans Löhr, Mark Manulis, and AhmadReza Sadeghi. Secure Multi-Coupons for Federated Environments: PrivacyPreserving and Customer-Friendly. In Proceedings of the 4th International Conference on Information Security Practice and Experience (ISPEC’08), volume 4991 of Lecture Notes in Computer Science, pages 29–44. Springer, 2008. [14] Liqun Chen, Alberto Escalante B., Hans Löhr, Mark Manulis, and Ahmad-Reza Sadeghi. A privacy-protecting multi-coupon scheme with stronger protection against splitting. In Proceedings of the 11th International Conference on Financial Cryptography and Data Security (FC’07), volume 4886 of Lecture Notes in Computer Science, pages 29–44. Springer, 2007. [15] Hans L¨ ohr, HariGovind Ramasamy, Ahmad-Reza Sadeghi, Stefan Schulz, Matthias Schunter, and Christian St¨ uble. Enhancing grid security using trusted virtualization. In Proceedings of the 4th International Conference on Autonomic and Trusted Computing (ATC’07), volume 4610 of Lecture Notes in Computer Science, pages 372–384. Springer, 2007. [16] Liqun Chen, Rainer Landfermann, Hans Löhr, Markus Rohe, Ahmad-Reza Sadeghi, and Christian St¨ uble. A protocol for property-based attestation. In Proceedings of the First ACM Workshop on Scalable Trusted Computing (STC’06), pages 7–16. ACM, 2006.

Other Publications [17] Alexandra Dmitrienko, Zecir Hadzic, Hans Löhr, Ahmad-Reza Sadeghi, and Marcel Winandy. Securing the acess to electronic health records on mobile phones. In

212

Publications by the Author Biomedical Engineering Systems and Technologies (BIOSTEC’11) – Revised Selected Papers, Communications in Computer and Information Science. Springer, 2011. (to appear). [18] Ammar Alkassar, Biljana Cubaleska, Hans Löhr, Christian St¨ uble, Ahmad-Reza Sadeghi, and Marcel Winandy. MediTrust: Secure client systems for healthcare IT to protect sensitive data of patients. In Med-e-Tel – Global Telemedicine and eHealth Updates: Knowledge Ressources, volume 4, pages 385–389. ISfTeH, 2011. [19] Luigi Catuogno, Hans L¨ ohr, Mark Manulis, Ahmad-Reza Sadeghi, Christian St¨ uble, and Marcel Winandy. Trusted Virtual Domains: Color your network. Datenschutz und Datensicherheit (DuD), 5:289–298, 2010.

213