Trusted Systems - INTRUST 2010

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen TU Dortmund University, Germany Madhu Sudan Microsoft Research, Cambridge, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max Planck Institute for Informatics, Saarbruecken, Germany

6802

Liqun Chen Moti Yung (Eds.)

Trusted Systems Second International Conference, INTRUST 2010 Beijing, China, December 13-15, 2010 Revised Selected Papers

13

Volume Editors Liqun Chen Hewlett-Packard Labs Long Down Avenue Stoke Gifford Bristol BS34 8QZ, UK E-mail: [email protected] Moti Yung Columbia University Computer Science Department S.W. Mudd Building New York, NY 10027, USA E-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349 ISBN 978-3-642-25282-2 e-ISBN 978-3-642-25283-9 DOI 10.1007/978-3-642-25283-9 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011941150 CR Subject Classification (1998): C.2, K.6.5, E.3, D.4.6, J.1, H.4 LNCS Sublibrary: SL 4 – Security and Cryptology

© Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

These proceedings contains the 23 papers presented at the INTRUST 2010 conference, held in Beijing, China, in December 2010. INTRUST 2010 was the second international conference on the theory, technologies and applications of trusted systems. It was devoted to all aspects of trusted computing systems, including trusted modules, platforms, networks, services and applications, from their fundamental features and functionalities to design principles, architecture and implementation technologies. The goal of the conference was to bring academic and industrial researchers, designers, and implementers together with end users of trusted systems, in order to foster the exchange of ideas in this challenging and fruitful area. INTRUST 2010 built on the successful INTRUST 2009 conference, also held in Beijing in December 2009. The proceedings of INTRUST 2009, containing 16 papers, were published in volume 6163 of the Lecture Notes in Computer Science series. The program consisted of a workshop with nine invited talks and 23 contributed papers. The workshop, titled “Asian Lounge on Trust, Security and Privacy”, included the distinguished keynote speaker Andrew Yao (Tsinghua University), and four more keynote speakers—Jingtai Ding (University of Cincinnati), Xuejia Lai (Shanghai Jiaotong University), DongHoon Lee (Korea University) and Claire Vishik (Intel)—along with talks by Liqun Chen (HP Labs), Shujun Li (Universtiy of Konstanz), Ahmad-Reza Sadeghi (TU Darmstadt and Fraunhofer SIT) and Moti Yung (Google). Special thanks are due to these speakers and also to Ahmad-Reza Sadeghi for his initiation and organization of the workshop. The contributed papers were selected from 66 submissions from 18 countries. All submissions were blind-reviewed, i.e., the Program Committee members provided reviews on anonymous submissions. The refereeing process was rigorous, involving at least three (and mostly more) independent reports being prepared for each submission. The individual reviewing phase was followed by profound discussions about the papers, which contributed a lot to the quality of the final selection. A number of accepted papers were shepherded by some Program Committee members in order to make sure the review comments were addressed properly. We are very grateful to our hard-working and distinguished Program Committee for doing such an excellent job in a timely fashion. We believe that the result is a high-quality set of papers, some of which have been significantly improved as a result of the refereeing process. For these proceedings the papers have been divided into seven main categories, namely, implementation technology, security analysis, cryptographic aspects, mobile trusted systems, hardware security, attestation, and software protection.

VI

Preface

We also want to thank the conference General Chairs, Robert Deng, Yongfei Han and Chris Mitchell, the Organizing Chair Jian Li, and Publicity Chairs, Xuhua Ding, and Xing Zhang, for valuable assistance and for handling the arrangements in Beijing. Thanks are also due to easyChair for providing the submission and review webserver and to Yang Zhen for designing and maintaining the conference website. We would also like to thank all the authors who submitted their papers to the INTRUST 2010 conference, all external referees, and all the attendees of the conference. Authors of accepted papers are thanked again for revising their papers according to the feedback from the conference participants. The revised versions were not checked by the Program Committee, and so authors bear full responsibility for their contents. We thank the staff at Springer for their help with producing the proceedings. February 2011

Liqun Chen Moti Yung

INTRUST 2010

The Second International Conference on Trusted Systems Beijing, P.R. China December 13–15, 2010

Sponsored by Beijing University of Technology ONETS Wireless & Internet Security Company Singapore Management University The Administrative Committee of Zhongguangcun Haidian Science Park

General Chairs Robert Deng Yongfei Han Chris Mitchell

Singapore Management University, Singapore Beijing University of Technology and ONETS, China Royal Holloway, University of London, UK

Program Chairs Liqun Chen Moti Yung

Hewlett-Packard Laboratories, UK Columbia University and Google Inc., USA

Program Committee N. Asokan Endre Bangerter Boris Balacheff Feng Bao Kefei Chen Zhen Chen Zhong Chen James Davenport Xuhua Ding Lo¨ıc Duflot Dieter Gollmann David Grawrock

Nokia Research Center, Finland Bern University of Applied Sciences, Switzerland HP Laboratories, UK I2R, Singapore Shanghai Jiaotong University, China Tsinghua University, China Peking University, China University of Bath, UK Singapore Management University, Singapore SGDN, France Hamburg University of Technology, Germany Intel, USA

VIII

INTRUST 2010

Sigrid Grgens Dirk Kuhlmann Xuejia Lai Jian Li Jiangtao Li Peter Lipp Wenbo Mao Andrew Martin Yi Mu David Naccache Raphael Phan Bart Preneel Graeme Proudler Emily Ratliff Scott Rotondo Mark Ryan Ahmad-Reza Sadeghi Kouichi Sakurai Wenchang Shi Willy Susilo Qiang Tang Vijay Varadharajan Claire Vishik Guilin Wang Duncan S. Wong Shouhuai Xu Xing Zhang

Fraunhofer Institute for Secure Information Technology, Germany HP Laboratories, UK Shanghai Jiaotong University, China BJUT, China Intel, USA Graz University of Technology, Austria EMC Research, China University of Oxford, UK University of Wollongong, Australia ENS, France Loughborough University, UK KU Leuven, Belgium HP Laboratories, UK IBM, USA Oracle, USA University of Birmingham, UK Ruhr University Bochum, Germany Kyushu University, Japan Renmin University, China University of Wollongong, Australia University of Twente, The Netherlands Macquarie University, Australia Intel, USA University of Birmingham, UK City University of Hong Kong, China UTSA, USA BJUT, China

Steering Committee Liqun Chen Robert Deng Yongfei Han Chris Mitchell Moti Yung

HP Laboratories, UK SMU, Singapore BJUT & ONETS, China RHUL, UK Google & Columbia University, USA

Organizing Chair Jian Li

Beijing University of Technology, China

Publication Chairs Xuhua Ding Xing Zhang

Singapore Management University, Singapore BJUT, China

INTRUST 2010

External Reviewers Akihiro Sakai Alexandra Dmitrienko Beipeng Mu Ben Smyth Chris Heunen Christian Wachsmann Christos Ioannides Cornelius Namiluko Dalia Khader Daniel Hein Daniel Page Fagen Li Feng Xie Fuchun Guo Gideon Bibu Hans L¨ohr Jens Hermans Jessica Jones Jian Weng Jinli Meng Johannes Winter John Lyle Joseph Liu Kurt Dietrich Man Ho Au Marcel Winandy Martin Pirker Masakazu Soshi Nicky Mouha

Nicolai Kunzte Qingji Zheng Qiong Huang Rehana Yasmin Roderick Bloem Roel Peeters Ronald Toegl Saif Al-Kuwari Sebastian Faust Shoichi Hirose Steffen Schulz Stephan Krenn Tsz Hon Yuen Unal Kocabas Vincent Rijmen Wei Gao Wei Wu Weiqi Dai Wook SHIN Xianhui Lu Xinming Chen Yiyuan Luo Yizhi Ren Yuan Tian Yuan Wong Zhenxin Zhan Zhongmei Wan Ziye Yang

IX

Table of Contents

Implementation Technology Seamless Integration of Trusted Computing into Standard Cryptographic Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andreas Reiter, Georg Neubauer, Michael Kapfenberger, Johannes Winter, and Kurt Dietrich Design and Implementation of Document Access Control Model Based on Role and Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liangjian Mao, Shuzhen Yao, Kai Zhang, and Kouichi Sakurai Towards High-Performance IPsec on Cavium OCTEON Platform . . . . . . Jinli Meng, Xinming Chen, Zhen Chen, Chuang Lin, Beipeng Mu, and Lingyun Ruan

1

26 37

Security Analysis An Abstract Model of a Trusted Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . Cornelius Namiluko and Andrew Martin

47

Modeling TCG-Based Secure Systems with Colored Petri Nets . . . . . . . . . Liang Gu, Yao Guo, Yanjiang Yang, Feng Bao, and Hong Mei

67

Information Flow Graph: An Approach to Identifying Covert Storage Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Xiangmei Song, Shiguang Ju, Changda Wang, and Conghua Zhou

87

Trusted Subjects Configuration Based on TE Model in MLS Systems . . . Shangjie Li and Yeping He

98

Cryptographic Aspects (I) Key Exchange with Anonymous Authentication Using DAA-SIGMA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jesse Walker and Jiangtao Li

108

Revocation of Direct Anonymous Attestation . . . . . . . . . . . . . . . . . . . . . . . . Liqun Chen and Jiangtao Li

128

Measuring Random Tests by Conditional Entropyand Optimal Execution Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jialin Huang and Xuejia Lai

148

XII

Table of Contents

Cryptographic Aspects (II) Leakage Resilient Strong Key-Insulated Signatures in Public Channel . . . Le Trieu Phong, Shin’ichiro Matsuo, and Moti Yung Two-Head Dragon Protocol: Preventing Cloning of Signature Keys (Work in Progress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Przemyslaw Bla´skiewicz, Przemyslaw Kubiak, and Miroslaw Kutylowski Addressing Leakage of Re-encryption Key in Proxy Re-encryption Using Trusted Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Yanjiang Yang, Liang Gu, and Feng Bao

160

173

189

Mobile Trusted Systems Can Hand-Held Computers Still Be Better Smart Cards? . . . . . . . . . . . . . Sandeep Tamrakar, Jan-Erik Ekberg, Pekka Laitinen, N. Asokan, and Tuomas Aura

200

TruWalletM: Secure Web Authentication on Mobile Platforms . . . . . . . . . Sven Bugiel, Alexandra Dmitrienko, Kari Kostiainen, Ahmad-Reza Sadeghi, and Marcel Winandy

219

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders in MANETs (Work-in-Progress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dong Hao, Yizhi Ren, and Kouichi Sakurai

237

Hardware Security Hardware Trojans for Inducing or Amplifying Side-Channel Leakage of Cryptographic Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jean-Fran¸cois Gallais, Johann Großsch¨ adl, Neil Hanley, Markus Kasper, Marcel Medwed, Francesco Regazzoni, J¨ orn-Marc Schmidt, Stefan Tillich, and Marcin W´ ojcik An Emerging Threat: Eve Meets a Robot (Work-in-Progress) . . . . . . . . . . Kahraman D. Akdemir, Deniz Karakoyunlu, Taskin Padir, and Berk Sunar

253

271

Attestation On Leveraging Stochastic Models for Remote Attestation . . . . . . . . . . . . . Tamleek Ali, Mohammad Nauman, and Xinwen Zhang

290

Table of Contents

Interoperable Remote Attestation for VPN Environments (Work in Progress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ingo Bente, Bastian Hellmann, Joerg Vieweg, Josef von Helden, and Arne Welzel A Novel Reputation Computing Model (Work-in-Progress) . . . . . . . . . . . . Yongzhong Zhang, Qi Li, and Zhangxi Lin

XIII

302

316

Software Protection acTvSM: A Dynamic Virtualization Platform for Enforcement of Application Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ronald Toegl, Martin Pirker, and Michael Gissing

326

Software, Vendors and Reputation: An Analysis of the Dilemma in Creating Secure Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Craig S. Wright

346

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361

Seamless Integration of Trusted Computing into Standard Cryptographic Frameworks Andreas Reiter, Georg Neubauer, Michael Kapfenberger, Johannes Winter, and Kurt Dietrich Institute for Applied Information Processing and Communications (IAIK) Graz, University of Technology Inffeldgasse 16a, 8010 Graz, Austria {andreas.reiter,georg.neubauer,kapfenberger}@student.tugraz.at, {johannes.winter,kurt.dietrich}@iaik.tugraz.at

Abstract. Trusted Software Stacks (TSS) are the interfaces between applications and Trusted Platform Modules (TPMs). In order to avoid wrong usage of the stacks which could lead to security holes, they should provide an easy-to-use interface for developers. Moreover, they should be designed in a flexible way to adapt to new requirements resulting from specification or algorithm changes. However, the currently specified TSS interface is highly complex and requires a vast amount of training effort for developers to get familiar with it. Moreover, existing stacks are monolithic blocks of software - they either support the full range of TPM functions which makes them large or they support a customized subset of features which reduces their scope of use. In this paper, we propose a novel design for a Trusted Software Stack (TSS) that can be integrated into existing security frameworks. Instead of designing a new application programming interface (API), our stack uses the APIs from well known and established frameworks, allowing developers that are not familiar with Trusted Computing (TC) to easily adapt to this new technology. Furthermore, our stack supports multiple TPMs, dynamic component loading and Over-The-Air updates that allow the stack to support customized sets of features even after it has been deployed in the field. Moreover, the stack provides built-in support for user authentication and TPM access control. Our prototype stack is developed for the .NET programming environment, thereby eliminating common implementation faults like buffer overflows. Due to the managed nature of the .NET runtime environment, it is portable between different operating systems and can be used on desktop systems as well as on embedded systems without the need for recompiling it for the specific target architecture. Keywords: TPM, TSS, Trusted Computing, .NET.

1

Introduction

Trusted Computing is a security technology that has emerged over the recent years. The security for both desktop systems as well as embedded devices can be enhanced by using Trusted Platform Modules (TPMs) which provide L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 1–25, 2011. c Springer-Verlag Berlin Heidelberg 2011 

2

A. Reiter et al.

mechanisms for secure cryptographic operations and system integrity reporting. By using such a device, it is possible to create trusted computing platforms which are capable of reporting the current state of a platform in a trustworthy way. In order to provide access to the TPM, applications can rely on a trusted software stack (TSS). Various software stacks exist, e.g. TrouSerS [7] which is a C language based library that is available for Linux and recently for Windows systems. Moreover, there is jTSS [11] which has been developed for the Java programming language and µTSS [16]. All these stacks strictly follow the TSS specification published and maintained by the Trusted Computing Group (TCG). However, the TSS specification is not the only existing specification for security APIs. Such APIs have existed for a long time e.g. the Microsoft Crypto API, the Java Cryptography Architecture (JCA) [13] framework and the OpenSSL API [5]. These are well known and established security frameworks, which have been used for years and are essential parts of many of today’s security related applications. Furthermore, they have undergone a long development and enhancement cycle and, therefore, they are well investigated and mature security APIs. Hence, the question arises why common trusted software stacks do not take the advantages of these existing frameworks into account. In this paper, we show how a TSS can be designed to take advantage of such standardized security frameworks. Therefore, we propose an object-oriented framework which is purely implemented in C# and can be used on the market leading operating systems i.e. Linux and Windows. In our prototype implementation, we demonstrate the application of our newly designed TSS on Linux and Windows desktop systems as well as on mobile systems. Thus, we show how TC mechanisms like quote, seal or bind can be integrated into BouncyCastle’s[3] C# Security framework. Using managed environments like Java or .NET provides several advantages over unmanaged issues on low-level languages like C or C++, the most important one being that whole classes of typical software implementation errors, including buffer overflows, memory leaks and use of undefined or uninitialized data can be prevented due to the managed nature of the runtime environment. The TCG TSS API specification is focused on the C programming language and, therefore, can not directly benefit from built-in language support for objectoriented programming concepts like interfaces, classes and exceptions. Our proposed framework (further referenced as doTSS ) focuses on simplicity and usability. In contrast to the C centric TSS specification, our approach takes advantage of the object-oriented features of the C# programming language and takes existing security APIs into account. The remainder of this article is organized as follows: We introduce our system in section 1.3 and discuss related work in section 1.1. Section 1.2 outlines the main contributions of the paper, followed by an architectural overview in section 1.3. Major differences between doTSS and other TSS implementations are outlined in section 2. The following section 3 elaborates on selected API use case examples and demonstrates the seamless integration of our TSS into the .NET version of the

Seamless Integration of TC into Standard Cryptographic Frameworks

3

BouncyCastle cryptography framework. A discussion of design and implementation aspects of our stack follows in section 4. The discussion of implementation aspects is concluded by a brief evaluation of our prototype implementation on an embedded ARM processor board in section 4.4. Finally, section 5 concludes our contribution and gives an outlook to possible future work. 1.1

Related Work

Why is there a requirement for another trusted software stack? Several issues exist where current designs and implementations can be improved. In [16], St¨ uble et al. define several requirements for trusted software stacks. Although our approach goes in accordance with these requirements we have to extend their definitions and add additional requirements: First, there is developer confidence. Developers typically undergo a cost- and time-consuming training phase when they are introduced to a new technology, especially if this software is security related. The current TSS specification is about 757 pages long and introduces new interfaces and methods for operations that use already established procedures. For example signature creation, key creation or cipher operations - all these operations can rely on well standardized interfaces in all major programming languages and operating systems (e.g. Microsoft Crypto API [12], Java Cryptography Architecture [13]). However, the TSS specification has a different approach for using these features. Thereby forcing developers to relearn processes that they are already familiar with. Second, in our mobile world applications are often loaded and installed from a remote system via a wireless link. Using Over-The-Air (OTA) installation mechanisms is a common procedure that allows software on mobile devices to install missing or update existing stacks in a simple way. Moreover, OTA can be used to load parts of software during execution of this software. This technique can also be used by a TSS to load missing components or algorithms but requires the TSS to be designed in a highly modular fashion. Furthermore, the TSS software components have to be distributed as binary release without the requirement of recompilation. However, existing C and C++ based trusted software stacks do not meet this requirement, as they have to be recompiled for each corresponding destination platforms. Third is related to portability. A TSS should be portable between operating systems and devices. Moreover, applications and developers should be able to expect a common API on all of the platforms without any modifications of the application. Furthermore, the API should provide abstraction from the underlying TPM. The application should neither care about the actual TPM whether it is implemented in hardware or software nor after which specification it is implemented. The stack should also be capable of managing more than a single TPM. This is especially of interest on mobile platforms where multiple TPMs may be used or on desktop systems with virtual TPMs. Fourth, there is algorithm agility. Modern cryptographic frameworks can integrate new or modified algorithms without modifications of the framework in

4

A. Reiter et al.

a dynamical way. Hence, all algorithms - new and old - from a certain group (e.g. symmetric ciphers, asymmetric ciphers) can be used via a common interface. Developers can easily adapt to new algorithms without relearning. TrouSerS [7] is the first TSS available as an open source TCG compatible Software Stack written in the C programming language. It offers complete support for TPMs version 1.1 and support for TPMs version 1.2 (still under development). Because of the complex interface introduced by the Trusted Computing Group, the use of this stack requires in-depth knowledge of the TSS and TPM specification. jTSS [10] is a Java implementation of the TCG Software Stack specification. It is developed and maintained at the Institute for Applied Information Processing and Communication at Graz, University of Technology. It provides an object oriented interface to the developer, but does not - similar to TrouSerS - reduce the effort for a developer reading into the relevant parts of the TSS and TPM specifications. µTSS [16] is an object oriented trusted software stack published by Sirrix. The stack is written in the C++ programming language. In contrast to TrouSerS, the stacks design aims at applications on embedded systems and reducing the overall complexity. It provides a fully typed object oriented interface but still has some disadvantages introduced by the TCG Software Stack like single TPM support. The Public Key Cryptography Standard (PKCS#11) is published in the current version 2.30 [15] and defines the cryptographic token interface standard, short cryptoki, published by RSA Laboratories. It provides an API, written in the C programming language, for standardized communication to devices which hold a cryptographic token like a TPM. The high complexity of the specification requires a lot of effort in order to handle this API in the correct way. 1.2

Our Contribution and Background

Dietrich [9] has shown that complex cryptographic techniques like the Direct Anonymous Attestation (DAA) protocol perfectly fit into existing security APIs. He showed that DAA, which is basically a group signature scheme, can be integrated into the JCA/JCE security framework provided by Java allowing developers easy access and usage of the complex cryptographic protocol. A similar approach is used for our stack. Instead of defining new APIs, we rely on established, well-known APIs from existing security architectures. For our stack, we use BouncyCastle [3] which is a cryptographic framework available for Java and the .NET framework. It contains implementations for various asymmetric block ciphers, symmetric block ciphers, stream ciphers, hash functions and signature algorithms. It exports well defined interfaces where doTSS can be integrated seamlessly. The relevant interfaces provided by BouncyCastle for doTSS are the IAsymmetricCipher interface and the ISigner interface. The ISigner interface is implemented by signature generation and verification algorithms and is illustrated in figure 1b.

Seamless Integration of TC into Standard Cryptographic Frameworks

5

doTSS provides implementations of this interface for signature generation and verification as well as for quoting and can be used as illustrated in listing 6. Listing 1 shows a Listing 1. Signature generation using Bouncy- common signature generation usage scenario of the BounCastle cyCastle framework. It shows that an existing application, using the interfaces defined by BouncyCastle can easily be changed to use doTSS in order to perform a signing or quoting operation. The IAsymmetricCipher interface is implemented by asymmet//Do k e y and d a t a s e t u p h e r e // Encrypt d a t a w i t h p r i v a t e k e y ric ciphers like RSA or ECC and I A sy m m e t r i c Bl o c k Ci p h e r e n c r y p t e r = is illustrated in figure 1a. doTSS new RsaEngine ( ) ; e n c r y p t e r . I n i t ( t r u e , key . P r i v a t e ) ; provides implementations of this byte [ ] encrypted = e n c r y p t e r interface for un-/sealing and un. P r o c e s s B l o c k ( data , 0 , d a t a . Length ) ; /binding data as illustrated in listListing 2. Asymmetric encryption using ing 8 and listing 9. The same for BouncyCastle the signing operation applies here, if an existing program already uses the interfaces defined by BouncyCastle it can easily be changed to perform binding or sealing operation using doTSS instead of a local encryption. //Do k e y and d a t a s e t u p h e r e // Sig n d a t a w i t h p r i v a t e k e y ISigner signer = new R s a D i g e s t S i g n e r ( new S h a 1 D i g e s t ( ) ) ; s i g n e r . I n i t ( t r u e , key . P r i v a t e ) ; s i g n e r . BlockUpdate ( data , 0 , d a t a . Length ) ; byte [ ] s i g = s i g n e r . Ge n e r a t e S i g na tu re ( ) ;

(a) IAsymmetricBlockCipher interface

(b) ISigner interface

Fig. 1. Interface illustrations

1.3

Architecture Overview

The overall system architecture of doTSS follows a strict client/server model. Figure 2 gives a high-level overview of the major software components of the doTSS framework. The system is divided into a single server process and a variable number of client processes connecting to this server. The server runs as system service on a computer platform with access to one or more Trusted Platform Modules (TPM) typically residing on the same trusted platform.

6

A. Reiter et al.

Fig. 2. System architecture

Clients connect to the server process using various connection methods and transport mechanisms. Local clients connecting from the same platform normally use local inter-process communication transports like named pipes or Unix domain sockets. Connections to remote clients are established over network sockets. The transport layer security (TLS) protocol is used to provide authenticity, confidentiality and integrity of remote client connections. More details on the connection methods and transport mechanisms implemented in the doTSS framework can be found in section 4.3. Authentication of TSS clients - The TCG TSS [17] specification does not mandate the use of any particular authentication mechanisms when connecting to the server-side of a trusted software stack. At the time of this writing, none of the publicly available trusted software stacks like TrouSerS [7] or jTSS [10] implement authentication mechanisms for their clients. At first glance, explicit authentication of trusted software stack clients appears to be superfluous due to the authorization mechanisms and policies already found within the TPM itself. By design, no TPM object should be usable or migrateable without knowing the proper authorization secret. As a matter of fact, various considerations regarding the lack of any explicit authorization for TSS clients and the reliance on the TPM supported mechanisms and policies, have been made. The TPM command set includes a series of commands which do not require any authorization but can still pose a significant threat to the privacy of the TPM’s user. One example of such a privacy critical command is the TPM PCRRead command, which allows anybody to read all PCR values of the TPM, thus allowing malicious software to generate fingerprints of a platform without permission. In this context, malicious software should be understood as any piece of software trying to track a TPM user without consent, thus crippling his privacy demands. Another privacy critical command is the TPM ReadPubEk command when used on unowned TPMs or on TPMs where the owner has not disabled reading of the public part of the endorsement-key without authentication. The doTSS framework tries to address these issues using authentication and authorization on a per-client basis. After a client connects, it needs to authenticate

Seamless Integration of TC into Standard Cryptographic Frameworks

7

its user to the server. The actual authentication step is performed using a connection-method specific authentication mechanism. For local connections, doTSS supports credential passing mechanisms provided by the underlying operating system. Credential passing involves the operating system kernel to determine the user executing the client process on the local system. Unix domain sockets (Linux) and named pipes (Windows) systems provide very similar credential passing mechanisms which are tightly integrated with the operating system’s built-in user management. In the socket as well as in the named pipe case, the server is able to reliably determine the operating system user executing the client connection. This information can be leverage to authenticate local users and clients connecting to a doTSS server process. Remote users connecting to the local doTSS server can be authenticated through a simple username-password authentication scheme or through TLS client certificates. In fact, username-password authentication can be used together with client certificates in order to provide separate authentication of the platform connecting to the doTSS server (by means of the certificate) and the user or application running on this platform (by means of username and password). The authentication infrastructure implemented in the doTSS software stack is quite flexible and can be easily extended to support additional authentication methods. One possible future extension to the doTSS authentication infrastructure could be the inclusion of TLS extensions [8] for attestation support on the server and client side. Managing multiple TPMs. - As illustrated in figure 2, a single doTSS server process can simultaneously handle multiple TPMs of possibly different types. The types of TPMs supported by our software stack are explained in section 4.1. On the client side, it is possible to simultaneously communicate with one or more of the TPMs over a single server up-link connection. Support for simultaneous access to multiple TPMs at the server- and clientside fundamentally deviates from the singleton TPM centric design of classic TCG-style trusted software stack. Classic TCG-style stacks are designed upon the assumption that the server-component, named trusted core services daemon (TCSD) in TCG terminology, runs on a platform where only a single TPM is available and is exposed to clients. This assumption is certainly true for normal desktop PC platforms in the majority of use cases, however it fails for systems and platforms which include more than one TPM-backed virtualised compartment, like virtualised server systems or mobile platforms implementing the TCG mobile reference architecture. By directly supporting multiple TPMs in a single server instance, the doTSS architecture can significantly reduce the overhead required to setup and manage these kinds of server or mobile platforms.

2

Comparison to Classic TCG Trusted Software Stacks

As discussed in section 1, our framework should be easy to use without the steep learning curve needed by the TCG TSS architecture. Ideally, a developer should

8

A. Reiter et al.

be able to use the doTSS framework with almost no prior knowledge about the TSS or the TPM specifications. Moreover, it is desirable to avoid introduction of new API interfaces in places where suitable well-established APIs already exist in the target environment. Authentication and authorization. The doTSS architecture provides a fully configurable user/permission framework. Access control permissions can be set on per-user and per-group basis and a user can be member of an arbitrary number of groups. Permissions can be configured on an individual TPM command level. It is possible to restrict execution rights for any particular TPM command to a subset of the users or groups configured on the doTSS server. In addition to commandlevel permissions, access to the TPMs exposed by the server can be controlled on a per-user and per-group basis. Key storage. In contrast to a TCG TSS, the doTSS server does not maintain an internal key storage. Even if another user knows the usage secret of a key, he can not use it because the key is only available for the client who has the key in its own key storage. Furthermore, if one user loads the key and another wants to use it, the second user still needs the key blob in its own key store and has to provide the key-usage secret. Moreover, the doTSS framework does not maintain centralized persistent systems or user key stores in the way intended by the TCG TSS specification. Instead of providing central TSS-specific key stores, our framework reuses existing key storage solutions found in the used cryptography framework, thus avoiding unnecessary API duplication. Command blob generation. Current TCG based TSS implementations like jTSS or TrouSerS generate TPM command blobs on the client-side in order to allow proper computation of HMAC values needed by the TPM’s authorization protocols. This approach of command blob generation requires the client-side to have significant knowledge about the peculiarities of the destination TPM. With a client-based command blob generation strategy, any workarounds for any vendor-specific TPM behavior has to be implemented on the client side. The doTSS framework uses a different strategy for command blob generation, which simplifies dealing with vendor-specific TPM behavior. All command blobs are generated on the server side, nevertheless, the server does not get the unencrypted authorization secret. That is important because plain text authorization data must never leave the client side. Whenever the doTSS server generates a command blob for an command requiring authorization, it sends all authorization relevant parts of the blob to the client for further processing. The client completes authorization by locally computing the authorization HMACs and sending them back to the server, which in turn can assemble the final TPM command blob. Using this approach, the back-end is completely transparent to the client and the server could apply transparent workarounds for specific TPM devices which do not behave like they should. The client still retains full control over any authorized TPM commands executed on its behalf and can reject to compute the authorization HMACs for dubious requests.

Seamless Integration of TC into Standard Cryptographic Frameworks

9

Secret cache. The framework has an internal and protected secret cache which saves the entered secrets during lifetime of the application in a protected storage. It uses the operating system kernel to protect and encrypt a memory region. Only the framework itself has access to this protected memory. If the server requests a secret from the client (for whatever operation it is needed) the user is only bothered if the secret was not found in the secret cache. Once the user enters a secret, it is placed in the secret cache and can be used for subsequent requests without user interaction. 2.1

Connection and Context Setup

Connections to trusted software stacks in order to issue TPM commands are typically called ”Contexts”. Before anyone can use the TPM a context needs to be created. The creation of a context using TrouSerS is illustrated in listing 3. Context creation works quite i f ( T s p i C o n t e x t C r e a t e (& hContext ) straight forward, but due to the lack != TSS SUCCESS ) { // Error h a n d l i n g g o e s h e r e } of standardized exception and error i f ( T s p i C o n t e x t C o n n e c t ( hContext , handling facilities in the C language, g e t s e r v e r (GLOBALSERVER ) ) != TSS SUCCESS ) { error handling code easily disturbs // Error h a n d l i n g g o e s h e r e } the code flow. The example given in listing 3 shows just the two very Listing 3. Context creation using basic steps required to establish a conTrouSerS nection to the server-side of a classic TCG TSS. When starting to perform actual work, like loading keys or signing data, proper error handling code literally clobbers the control flow. jTSS models the TCG specified TSS C-API on top of an object oriented layer of Java classes. The jTSS equivalent of the session and context setup is shown in listing 4. The advantages of having exception support available for error handling are already visible in the short code snippet from listing 4. TrouSerS and jTSS follow the specified API interfaces for the TCG TSS try { Tc TssCo n t e x t F a c t o r y f a c t o r y very closely and have a strict asso= new Tc TssCo n t e x t F a c t o r y ( ) ; ciation between one context or conTc I Co n t e x t c o n t e x t = f a c t o r y . n e wCo n t e x t O b ject ( ) ; nection to the software stack and one context . connect ( ) ; singleton TPM instance. The doTSS } catch ( Tc TssE x c e p t i o n e ) { . . . } framework uses a different design and Listing 4. Context creation using jTSS differentiates between the context object representing the connection to the server-side of the software stack and the session objects representing the individual TPM sessions managed by the context object. Listing 5 illustrates the code sequence required to establish a connection to a local doTSS server over a Unix socket connection, followed by the authentication of the client and creation of two TPM session. The first part looks similar to jTSS code snippet shown before, however, without the authentication mechanisms. Before the client can use any TPM functionality it needs to authenticate itself to the server, for example by using

10

A. Reiter et al.

try { F r o n t E n d Co n nect io n conn = new U n i x S o c k e t Co n n e c t i o n ( ” /tmp/ d o t s s . s o c k ” ) ; conn . Connect ( ) ; C l i e n t C o n t e x t c t x = E n d p o i n t Co n t e x t . C r e a t e C l i e n t E n d p o i n t C o n t e x t ( conn ) ; ctx . Au th e n ti c ationCl ient . S e l e c tAu th e n ti c ati on ( ” unix auth ” ) ; ctx . Au th e n ti c ationCl ient . Authenticate ( ) ; TPMSession tpm1 = c t x . TPMClient . SelectTPMDevice ( ” tpm1” ) ; TPMSession tpm2 = c t x . TPMClient . SelectTPMDevice ( ”tpmEmu” ) ; } catch ( E x c e p t i o n e ) { . . . }

Listing 5. Context creation using doTSS

Unix socket credential passing as shown in listing 5. Once the client has been authenticated, access to TPMs is possible according to the access control rules configured at the server. Based on the authentication information provided by the client, the system operator can allow or deny groups of users to use specific TPM devices defined in the system configuration. The code complexity of the doTSS connection setup sequence is comparable to the jTSS and TrouSerS sequences, especially when taking into account that the two other stacks do not directly support any authentication or access control mechanisms.

3

Using the doTSS Client API

In this section, selected API usage scenarios for doTSS are discussed. doTSS reuses existing interfaces and frameworks wherever possible, in order to allow seamless integration with existing applications and libraries. The .NET framework itself only provides very basic abstractions for symmetric and asymmetric cryptography, which complicates the development of algorithm agnostic API interfaces. For this reason, doTSS uses the .NET version of the the BouncyCastle cryptography framework [3], which provides API interfaces roughly modeled after the Java cryptographic architecture. Mapping of TPM Functionality. The BouncyCastle cryptography framework provides abstractions for common cryptographic primitives like symmetric and asymmetric ciphers, message digests and public-key signatures. These interfaces are similar to the .NET framework counterpart, but provide a better abstraction in to use the same interface for different ciphers (e.g. for RSA and ECC). Many TPM primitives like signing, binding, sealing and quoting can be directly mapped to the corresponding primitives of the cryptography framework. This approach does not confront the developer with whole new interfaces, he can get started immediately without reading into any new framework specification. For sealing and binding, doTSS implements the IAsymmetricBlockCipher interface and, therefore, can be used in exactly the same way as any other asymmetric encryption operations available in the BouncyCastle framework. Similarly, doTSS provides implementations of the ISigner interface, effectively allowing the usage of the TPM signing operation as drop-in replacement for the signing primitives available in the BouncyCastle framework.

Seamless Integration of TC into Standard Cryptographic Frameworks

11

Data signing. The signing operation I S i g n e r si g Ge n = key . C r e a t e S i g n e r ( ) ; involves the TPM to sign some data or si g Ge n . I n i t ( f a l s e , n u l l ) ; verify a signature on the TPM, with a si g Ge n . BlockUpdate ( data , 0 , l e n g t h ) ; dedicated signing key, without reveal- b y t e [ ] s i g = si g Ge n . G e n e r a t e S i g n a t u r e ( ) ; ing the private data of the signing key. The CreateSigner operation returns Listing 6. Signing using doTSS a ready-to-use signature generation or verification object, and it does not require the developer to know any details (like hashing algorithm in use) about the key. The signatureverification process is done without interacting with the TPM, using the public portion of the signing key. Listing 6 illustrates the code snippet required to sign a block of data using the doTSS provided API. The only visible difference to a “normal” sign operation performed without a TPM is in the first line, where the ISigner object is created. Quoting. The quoting operation repcrs = ports the current state of the sys- TPMPCRSelection tpm . CreateEmptyPCRSelection ( ) ; tem in a secure way, meaning that p c r s . P c r S e l e c t i o n . S e t B i t ( 0 ) ; crSelection . SetBit ( 2 ) ; the quoting response message (from pp cc rr ss .. P PcrSelection . SetBit ( 4 ) ; the TPM to the system) cannot be I S i g n e r q u o t e r = . Cr e a t e Q u o t e r ( p c r s ) ; forged or be modified without be- qkey uoter . I n i t ( f a l s e , n u l l ) ; ing detected. To measure the state q u o t e r . BlockUpdate ( data , 0 , l e n g t h ) ; of a system, the TPM introduces so b=y t eq u[ ]o t es ri g. G e n e r a t e S i g n a t u r e ( ) ; called Platform Configuration Registers (PCR) where the state of the sysListing 7. Quoting using doTSS tem is measured (or extended) from a known and trusted state. The developer needs to specify the PCRs used for the quoting operation. To be sure that received data has not been modified on its way, the TPM signs the TPMPCRComposite structure and returns this structure and the signature. Additionally, some external anti-replay data may be supplied to the quoting operation, which is included in the signature generation process. This external data can be used to build a signature bound to a specific state of the TPM as illustrated in listing 7. Quoting and signing are very similar operations, which is clearly visible in the code snippet of the quoting example in listing 7. Apart from the TPM specific setup for the quote operation, only the standard ISigner interface is used to create the quoted blob. Binding. is the process of encrypting data with a dedicated binding key on the TPM without taking the current state of the TPM into account. The encryption part can be done locally without interacting with the TPM, because encryption uses the public part of the key. The decryption process involves the TPM, but this separation is transparent to the developer,

I A sy m m e t r i c Bl o c k Ci p h e r b i n d e r = key . C r e a t e B i n d B l o c k C i p h e r ( ) ; // Bind binder . I n i t ( true , n u l l ) ; b y t e [ ] bound = b i n d e r . P r o c e s s B l o c k ( data , 0 , length ) ; // Unbind binder . I n it ( false , null ) ; b y t e [ ] unbound = b i n d e r . P r o c e s s B l o c k ( bound , 0 , bound . Length ) ;

Listing 8. Binding using doTSS

12

A. Reiter et al.

who does not need to care about these details and does not need to know any key specific parameters like padding mode. Listing 8 illustrates the process of binding data. Sealing. is the process of encrypting data and taking into account a specified state of the system. During the sealing process, an information about used PCRs and their states at decryption time must be given. Therefore, it is possible to seal data at any TPM state but reveal (or unseal) encrypted data only in a prior specified one. Using doTSS data binding and TPMPCRSelection p c r s data sealing works nearly the same, = tpm . CreateEmptyPCRSelection ( ) ; crSelection . SetBit ( 0 ) ; except that sealing needs some extra pp cc rr ss .. P PcrSelection . SetBit ( 2 ) ; information, which PCRs should be p c r s . P c r S e l e c t i o n . S e t B i t ( 4 ) ; m m e t r i c Bl o c k Ci p h e r s e a l e r taken into account in the seal process. I A=sy key . CreateSealBlockCipher( pcrs ) ; The rest works the same as for data s e a l e r . I n i t ( t r u e , n u l l ) ; binding. Listing 9 illustrates the pro- b y=t e s[ ]e a sl ee ra l. ePdr o c e s s B l o c k ( data , 0 , cess of data sealing. Each TPM can length ) ; have a different amount of PCRs, but Listing 9. Sealing using doTSS should have a minimum amount defined in the TPM specification. In order to be able to use the whole set of PCRs, the CreateEmptyPCRSelection command creates an empty PCRSelection structure with the correct PCR count.

4

System Implementation

In this section and its subsections, we discuss the implementation of the client and server parts of the doTSS framework. Firstly, we emphasize on the architecture and implementation of the server-side components in subsection 4.1. Secondly, we elaborate on the client-side components of the doTSS framework in subsection 4.2. Finally, subsection 4.3 explains details of the protocol used for communication between the server and client parts. 4.1

Server Architecture

The server process resides on a trusted platform that has access to all TPM devices of interest. On Windows platforms it can run in the background as a Windows system service, on Linux it can run as daemon process respectively. For debugging purposes, the server process can be started as normal foreground console application on both platforms. Internally, the server is structured into a series of subsystems, which are responsible for dealing with different aspects of functionality, including handling of inbound client connections and management of attached TPM devices. The subsystems found in the typical configuration of the doTSS server are discussed in greater detail later in this section. The server subsystems expose a series of global components (see figure 3a), which are shared among all client contexts, and client specific components (see

Seamless Integration of TC into Standard Cryptographic Frameworks

(a) Global components

13

(b) Per-client components

Fig. 3. Global and per-client components of the doTSS server

figure 3b). Global components include server configuration management, access control settings and TPM context objects used to handle the backend connections to physical and virtual TPMs. Additionally, global listener objects are responsible for accepting inbound client connections over the various communication channels configured on the server. When accepting a new inbound client connection, the corresponding listener object triggers creation of a new client context and the associated per-client components. These client context specific components include per-session states, like authentication state and links to the global TPM context objects. Subsystems. Subsystems are the logical units for grouping related server and client functionality in the doTSS framework. Each connection can be associated with its own set of subsystems, which are responsible for handling requests and responses support on particular connections. Any requests or responses processed by the server or client frameworks are tied to a particular subsystem. The communication protocol described previously is tightly coupled with the doTSS subsystem design. Subsystems are registered dynamically during run-time at the server and the client side. From a connection-oriented view of the system, the only difference between the server and the client is that one party starts the listeners and the other party initiates a connection. The real difference then comes from the registered subsystems the other party can use. The authentication subsystem. handles user authentication based on the server configuration. Currently, this subsystem supports a couple of different authentication mechanisms, which are coupled to specific transport mechanisms. Unix domain sockets and named pipes used for local connections to the trusted software stack support implicit authentication of the operating system user running the client side application through credential passing similar to [4]. This information is used by the authentication subsystem to realize authentication of local stack users. Remote connections to the software stack are typically

14

A. Reiter et al.

established over a TLS protected TCP/IP socket connection. The authentication subsystem supports TLS client authentication, using client-side public key certificates as method of authenticating remote users. Alternatively, a simple username/password based authentication protocol can be used when TLS client authentication is not available or desirable. The TPM subsystem. handles all aspects of communicating with TPM devices, including construction of commands and parsing of response byte blobs. The server-side parts of the TPM subsystem are further decomposed into the externally visible subsystem command handling logic, an intermediate TPM common library, a TPM core library and a low-level TPM provider layer. Incoming client requests are routed to the command handling logic, which forwards the request to the core TPM library after performing any necessary permission checks. The TPM specific information is contained in the TPM core library. This library contains all byte-blob generators as specified in [18]. Furthermore, all structures that were defined in the TPM common library and are in use by the TPM, get extended with the capability to serialize to a TPM compatible format. The following hard- and software TPMs are currently supported by the TPM subsystems and its libraries: – – – –

Native Linux devices, normally located at /dev/tpmX Windows Vista/7 Trusted Base Services ETHZ TPM Emulator [6] running on linux IBM Software TPM [2] running on Linux or Windows

The incoming requests only describe what to do and not how to do it. This opens up new possibilities, as applications running with the doTSS framework do not need to take care of TPMs with some command incompatibilities or special characteristics. The server can transparently apply workarounds for specific TPMs, while the client still retains full control of any use of authorization secrets. Using the abstractions provided by the doTSS TPM subsystem, it is possible to transparently connect an application to another TSS, thus applying ideas similar to nested virtualization to trusted software stacks. The ability to expose multiple underlying (maybe classic) TSS instances through the simple doTSS API interface can be used to enable easy management of virtualized server environments. Command authorization. As discussed in the previous section, the client does not generate TPM byte blobs at all. All byte blobs are generated on the server. This complicates the process of command authorization. The simplest way would be that the server receives all information required for authorizing a command (including usage secrets) and calculate the authorization value on the server side. However, this is a bad solution as one main goal was that user secrets should not leave the client in plain-text. The command authorization now works in the following way (illustrated in figure 4).

Seamless Integration of TC into Standard Cryptographic Frameworks

15

– A client wants to execute a request for TPM A – The server accepts the command request, builds the command and executes it. After authorization handle setup and reservation (discussed in section 4.1), the byte blob is built. – We assume that the TPM command requires authorization. For this case, the server now needs the authorization value to proceed. Although the client is waiting for a response with the status of the command execution, the server can send a request to the ’TPM client subsystem’ registered on the client, at the same time. This request contains all relevant information for authorization value generation. If the required secret for authorization generation is not cached on the client, the user is asked. After authorization value generation, the value is sent back to the server, where the command is assembled and sent to the TPM. Authentication handle management. A TPM only supports a small number of concurrent authorization handles, but at least three to be able to execute a double authorized command with a transport session in use. To execute an authorized command, the authorization handle needs to be loaded into the TPM. The problem is that doTSS fully supports multiple concurrent users, who can execute commands concurrently. If one user executes a command, sets up the authorization handles and authorizes the command, the TPM would be blocked for other users while performing the last step, which can take some time because the user might be asked to enter a usage secret. In order to overcome this issue, the authorization handle manager was introduced which supports unloading and loading authorization handle contexts. With the help of the authorization handle manager the TPM can be used by another user, executing other authorized commands while waiting for another command to get authorized by the user. In the time the command gets authorized, the authorization handle manager might unload existing auth handle contexts, because the auth handle slots are needed by another command. Once the authorization of a command is complete, the auth handles used by this command are loaded back into the TPM and the command is executed.

Fig. 4. Illustration of the command authorization process

16

A. Reiter et al.

The typical number of concurrently loadable authorization handles depends on the TPM manufacturer and is usually less than 20. To avoid contention between different processes using the TPM, a near-to-fair ”swapping” algorithm is needed which selects the next handle to be swapped out, it should be a handle that is not needed for a long time. In this framework, the swapping algorithm is exchangeable, but the currently one and only implementation uses a ”Clock” approach, where handles that have not been used for a long time get swapped out before others. In practice, the algorithm used for authorization handle swapping is not really of importance, because in the end, it depends on the user how fast he can provide the user secret to the framework. The only important thing about the swapping algorithm comes in when talking about commands requiring double authorization. The authorization handle manager needs to take care that it does not swap in/out the assigned authorization handles alternately as this would result in an infinite loop with high TPM load. 4.2

Client Architecture

The client process can run on platforms supported by Mono and Microsoft .NET framework and connects to an available server process using one of the supported transport connection mechanisms discussed in section 1.3. Server and client-side of the doTSS framework share large parts of their code base. All aspects of the communication protocol discussed in section 4.3 are implemented in a common library used by the client- and by the server-side of the doTSS framework. There are only minor differences in the communication handling code of the client and server due to the symmetric design of the protocol library, which uses the same subsystem abstraction on both endpoints. The doTSS client-side is implemented as a library, which provides the interfaces of the Bouncy Castle cryptography provider. In addition to the implementations of the signature and cipher interfaces, there is a client context interface exposing connection management and authentication methods. Client side logic is intentionally kept simple and mostly consists of direct mappings of client API methods to request and response marshalling code. Notable exceptions are the client-side parts of the user authentication mechanism, the client-side keystore and the TPM object authorization callbacks. As mentioned earlier in section 2, no centralized key store is maintained by the server. Consequently, each client has to maintain its own local key-store. At the time of this writing, the doTSS framework provides a simple client-side key store implementation backed by a SQLite database. This default keystore implementation can be used if no better suitable key storage solution is available. New keys are automatically saved in the client keystore upon key creation, without the need for any additional program or user interaction. Each key entry in the key-store can be identified by its friendly name, which uniquely identifies the key locally and its global identifier, which uniquely identifies the key among all keys created on the TPM. The friendly name can be chosen by the user creating the key, and can be a readable text or any other kind of identifier. It makes the key-store more user-friendly and allows the user to identify the keys

Seamless Integration of TC into Standard Cryptographic Frameworks

17

by their friendly name. Further each key-entry contains a reference to its parent key, which is needed to load the key into the TPM, and of course the key-data exported from the TPM on key creation. Further, the server has the possibility to retrieve information about particular keys from the client. This information is identical to the information contained in the key-store and is needed for loading keys and rebuilding the key hierarchy. Appendix A shows the interaction between the server and the client during a normal key loading operation. 4.3

Client/Server Communication Protocol

Currently, the doTSS framework implements support for using TCP/IP sockets, Unix domain sockets (on Linux platforms) and named-pipes (on Windows platforms) as underlying transport mechanism for communication between the server and the client. The doTSS framework is designed to allow easy addition of further transport mechanisms, which can be statically compiled into the stack at build-time or dynamically loaded during run-time. The only requirement defined by the doTSS communication infrastructure is that the underlying transport mechanism must be able to provide some kind of reliable streaming interface, similar to TCP/IP or one of the local socket types mentioned above. The communication protocol used by the doTSS framework generally operates in half-duplex mode in order to keep the protocol and its implementation simple. After sending a packet over the transport link, the sender has to wait for an incoming packet from the far end of the link. The packet from the far end can either be the response to an earlier response submitted by the original sender or it can be a nested callback request from the far end.

Fig. 5. Connection framework

18

A. Reiter et al.

Figure 5 illustrates a complete request-response cycle. The cycle starts at the client, when a call to an API method requiring server interaction is received. The API call causes the corresponding client side subsystem (not shown in the figure) to generate a DataPacket object encoding the server request. This packet object is serialized by the client side packet transceiver engine and is sent to the server over the underlying transport connection. The server side de-serializes the received packet using its own packet transceiver engine and routes the resulting DataPacket object to the correct subsystem for further processing. In the simplest case, the responsible subsystem generates a DataPacket object representing the response to the inbound request and sends it back to the client. The return channel to the client works exactly the same way as the outbound data channel of the client discussed above. There are more complex cases, which require the server to request additional information from the client. To deal with such situations, a server-side subsystem can send nested request packets as response to inbound client requests, due to the fully symmetric design of the server and client side communication infrastructure. Figure 6 illustrates the layout of a request or response data packet. Each packet consists of a packet number, an indication of the packet direction (request vs. response), a unique identifier of the target subsystem together with a subsystem specific payload. The packet number is unspecified for data packets which do not require a response and is sequentially incremented for each data packet requiring a response packet. The packet number is reset if it reaches the maximum value 255, allowing one party to send at most 256 concurrent requests before the packet transmitter runs out of packet numbers. During our experiments with the doTSS framework, we found this upper bound on the number of concurrent requests to be more than adequate even for complex command sequences, like loading of key hierarchies, which require several concurrent callback requests from the server to the client. Each packet has an associated direction flag, indicating if it is a request or a response packet. The protocol handling code uses this flag to decide if a packet is about to start a new request to the local subsystem or if a packet is the response to a request submitted earlier by the local subsystem. Using the direction flag, it is easy to implement callback requests from the server to the client, without complicating the protocol too much. It is up to each server- and client-side subsystem to interpret the payload of any incoming packet. Each packet contains a unique subsystem identifier which indicates the origin and destination subsystem the packet belongs to. The payload

Fig. 6. Data packet layout

Seamless Integration of TC into Standard Cryptographic Frameworks

19

part of the packet is not interpreted by the generic protocol handling code and is under sole control of the involved subsystem. 4.4

doTSS on Embedded Systems

Our doTSS can be used on embedded systems without rebuilding. In order to demonstrate the feasibility of our proof-of-concept implementation, we provide estimations of the memory consumptions of the stack plus demonstrator applications. For testing purpose, we use a Gumstix evaluation board. The Gumstix is a very small computer board (computer-on-module or COM) but has a fairly powerful OMAP 3503 Application Processor with an ARM Cortex-A8 CPU (600 MHz). It also has 256 MB RAM and 256 MB NAND (flash) memory. To support programs implemented with the .NET framework, we decided to build a tailored version of Mono [1] for the Gumstix. Mono is a runtime and cross-development platform which runs .NET applications on different operating systems like Unix, Solaris or even on an iPhone. Our minimal runtime version consists of 6 packages i.e. mono-common, mono-gac, mono-jit, mono-runtime and libmono-posix2.0-cil. The total size of the Mono runtime on the Gumstix is about 15.7 megabytes in total (in comparison to the desktop version of the Mono runtime with about 70 megabytes in size). Additionally, we measured the sizes of the stack components on the Gumstix (see Table 1). Table 1. Stack Component Sizes TPM Server TPM Client BouncyCastle Crypto library 304.0 kB 360.0 kB 1.3 MB

In addition to cryptographic functions, the BouncyCastle library contains support for the transport layer security (TLS) protocol, the Cryptographic Message Syntax (CMS) format, PKCS#12, the time-stamping protocol and certificate path validation which increases the size of the library to 1.3 megabytes.

5

Conclusion and Future Work

In this paper, we discuss a design for a developer friendly Trusted Software Stack which utilizes established security frameworks. The stack is capable of loading components dynamically via the network or OTA and can be used unmodified and without recompilation on Windows and (embedded) Linux platforms. The modular design allows the stack to add, update or replace existing functionality even after it has been deployed in the field. The stack’s API is designed to bring the benefit of Trusted Computing to the C#.NET programming environment which is type-safety during compileand runtime. It supports multiple TPMs, making it the ideal stack for mobile devices and systems that have to manage many virtual TPMs. Moreover, by using established APIs from existing security frameworks, it is possible to reduce

20

A. Reiter et al.

the overall training time for developers to get familiar with Trusted Computing related mechanisms. Our current implementation is limited to the BouncyCastle security framework. Future enhancements might, therefore, include the integration of our stack design into other frameworks like the JCA and Java Cryptographic Extension [14] or the Microsoft CryptoAPI [12]. Acknowledgements. The authors would like to thank the anonymous reviewers for their comments and suggestions. This work has been supported by the European Commission through the FP7 project SEPIA under the grant agreement number 257433.

References 1. Cross Platform, open source .NET development framework, http://www.mono-project.com/ 2. IBM Software Trusted Platform Module, http://www.ibmswtpm.sourceforge.net/ 3. The Legion of the Bouncy Castle, http://www.bouncycastle.org/ 4. Mono credential passing, documentation http://www.go-mono.com/docs/index.aspx?tlink=18@ecmaf 5. OpenSSL API, http://www.openssl.org/ 6. Software-based TPM Emulator, http://www.tpm-emulator.berlios.de/ 7. TrouSerS, http://www.trousers.sourceforge.net/ 8. Barthe, G., Fournet, C. (eds.): TGC 2007. LNCS, vol. 4912. Springer, Heidelberg (2008) 9. Dietrich, K.: Anonymous credentials for java enabled platforms: A performance evaluation. In: Chen, L., Yung, M. (eds.) INTRUST 2009. LNCS, vol. 6163, pp. 88–103. Springer, Heidelberg (2010) 10. IAIK. jTSS, http://www.trustedjava.sourceforge.net/ 11. IAIK/OpenTC. jTSS Wrapper, http://www.trustedjava.sourceforge.net/ 12. Microsoft. Microsoft cryptoapi and cryptographic service providers (2010), http://technet.microsoft.com/en-us/library/cc962093.aspx 13. Oracle. Java Cryptography Architecture, http://download.oracle.com/javase/ 1.5.0/docs/guide/security/CryptoSpec.html 14. Oracle. Java Cryptography Extension, http://download.oracle.com/javase/1. 5.0/docs/guide/security/jce/JCERefGuide.html 15. PKCS#11: Cryptographic Token Interface Standard, CA. RSA Laboratories, Redwood City (2009), http://www.rsa.com/rsalabs/node.asp?id=2133 16. St¨ uble, C., Zaerin, A.: µTSS - A Simplified Trusted Software Stack (2010), http://www.sirrix.de/content/pages/forschungsarbeiten.htm 17. TCG. TCG Software Stack (TSS) Specification (March 7, 2007), specification http://www.trustedcomputinggroup.org/resources/ tcg software stack tss specification Specification version 1.2 Level 1 Errata A. 18. TCG. TPM Main Part 3 Commands (July 9, 2007), specification http://www.trustedcomputinggroup.org/resources/tpm_main_specification, Specification version 1.2 Level 2 Revision 103

Seamless Integration of TC into Standard Cryptographic Frameworks

A

21

Key Hierarchy Loading Example

A sample of how the key manager queries the client to rebuild the key hierarchy is illustrated in figure 7. A user wants to sign some data and sends a request to the server. First, the server tries to load the signing key. To achieve this, it needs to rebuild the key hierarchy, at least for the key to load. The server requests the parent key of the users signing key. This request is forwarded to the client, because currently the key-store only resides on the client side. The client then retrieves the parent of the requested key from the key-store and sends back its identifier. This procedure is repeated until the storage root key (SRK) is reached. Once the server knows all keys to load, it starts loading them from top to bottom, starting at the storage root key. For each key, it is required to retrieve the key-data from the key-store which resides on the client side. After the key hierarchy has been loaded, the server can execute the command the client sent in the beginning and returns the result. Using a TCG compliant stack, the user application does not have a key storage on its own, it uses a key storage supplied by the framework where all created keys are saved. The user application using the TCG stack needs to load the keys in the correct order (going down from top to bottom in the key hierarchy) and

Fig. 7. Example key hierarchy loading

22

A. Reiter et al.

explicitely call the key loading command several times for each key-UUID in the tree before the key can be used.

B B.1

More Comparison Examples Capability Retrieval Example

TPMs have commands to retrieve their capabilities like number of key slots, number of PCR values and so on. In this section for simplicity it is assumed that a context has already been set up. Using TrouSerS the retrieval of capabilities is illustrated in listing 10. The GetCapability command is pulRespDataLength ; divided into a capability field and UINT32 UINT32 subCap , subCapLength , numPcrs ; a subcap field, for each value in subCap = TSS TPMCAP PROP PCR ; = s i z e o f ( UINT32 ) ; the capability field there is a set subCapLength r e s u l t = Tsp i TP M Ge t Ca p a b i l i t y ( hTPM, of special values or more complex TSS TPMCAP PROPERTY, subCapLength , (BYTE ∗)&subCap , structures for the subcaps field. To &pulRespDataLength , use this command with a TSS, &pNumPCRs ) ; f ( r e s u l t != TSS SUCCESS ) { the developer needs to be aware of i // Error h a n d l i n g g o e s h e r e } all valid capability-subcap combinations and he needs to be aware Listing 10. Capability retrieval using of TPM compatible serialization of Trousers some data types, because the subcaps field can take different data types for different capability values and takes these values in a serialized form. This approach seems to be completely user unfriendly. The jTSS does this a bit more user friendly as illustrated in listing 11. long numberOfPCRs = tpm . g e t C a p a b i l i t y U I N T 3 2 ( T c T s s C o n s t a n t s . TSS TPMCAP PROPERTY, TcBlobData . newUINT32 ( T c T s s C o n s t a n t s . TSS TPMCAP PROP PCR ) ) ;

Listing 11. Capability retrieval using jTSS

Using jTSS the developer still needs to know all valid capability-subcap combinations and the expected return data type, but the developer does not need to know how to serialize in a TPM compatible way. Listing 12 illustrates the process of capability retrieval using mikroTSS. It Provides a typed interface. TPM &tpm = TPM: : g e t I n s t a n c e ( ) ; UINT32 numberOfPCRs = tpm . getNumberOfPCR ( ) ;

Listing 12. Capability retrieval using mikroTSS

Using doTSS the developer gets a fully typed interface for capability retrieval as illustrated in listing 13 and doTSS structures the available methods even more by dividing them by field of application (AdministrationClient, CapabilityClient, etc.)

Seamless Integration of TC into Standard Cryptographic Frameworks

23

u i n t numberOfPCRs = tpm . C a p a b i l i t y C l i e n t . GetPCRCount ( ) ;

Listing 13. Capability retrieval using doTSS

Using the doTSS approach the developer does not need to know anything about valid capability-subcap combinations and don’t has to take care about serialization or return types. The framework provides a fully typed application programming interface, without the need to know anything about TPM specifications. B.2

Key Creation and Usage Examples

The main difference between common TSS implementations and doTSS is that TSS implementations normally have a system wide key storage. This means all keys are identified by a global UUID. In contrast, doTSS saves all keys on the client side, identified by two values, a globally unique identifier chosen by the server and a local unique identifier (or friendly name) chosen by the user. The friendly names are very useful when browsing available keys and can easily be mapped to their global identifiers on the client side. Another big difference is that when using TSS implementations, the application itself needs to be aware of the key hierarchy and needs to load the keys in correct order. When using doTSS the server cares about the right order of key loading with the support of the client but without user interaction (except for entering secrets). That is a really big usability improvement. To keep the clearance this chapter will only compare jTSS to doTSS, the code for TrouSerS looks similar to jTSS like in the preceding chapters. // Setup t h e p a r e n t key o b j e c t (SRK) o f t h e key t o be c r e a t e d . . . TcIRsaKey s r k = c o n t e x t . c r e a t e R s a K e y O b j e c t ( T c T s s C o n s t a n t s . TSS KEY TSP SRK ) ; // . . . c r e a t e i t s p o l i c y o b j e c t . . . T c I P o l i c y s r k P o l i c y = c o n t e x t . c r e a t e P o l i c y O b j e c t ( T c T s s C o n s t a n t s . TSS POLICY USAGE ) ; // . . . and s e t i t s s e c r e t . . . s r k P o l i c y . s e t S e c r e t ( T c T s s C o n s t a n t s . TSS SECRET MODE SHA1 , TcBlobData . newByteArray ( T c T s s C o n s t a n t s . TSS WELL KNOWN SECRET ) ) ; srkPolicy . assignToObject ( srk ) ; //Then c r e a t e t h e key o b j e c t o f t h e key // t o be c r e a t e d , and s e t i t s par ameters TcIRsaKey mySigningKey = c o n t e x t . c r e a t e R s a K e y O b j e c t ( T c T s s C o n s t a n t s . TSS KEY SIZE 2048 | T c T s s C o n s t a n t s . TSS KEY TYPE SIGNING | T c T s s C o n s t a n t s . TSS KEY NON VOLATILE | T c T s s C o n s t a n t s . TSS KEY MIGRATABLE | T c T s s C o n s t a n t s . TSS KEY AUTHORIZATION ) ; // Create and s e t i t s u s a g e s e c r e t TcBlobData k e y U s a g e S e c r e t = TcBlobData . n e w S t r i n g ( ” u s a g e s e c r e t ” ) ; T c I P o l i c y k e y U s a g e P o l i c y = c o n t e x t . c r e a t e P o l i c y O b j e c t ( T c T s s C o n s t a n t s . TSS POLICY USAGE ) ; k e y U s a g e P o l i c y . s e t S e c r e t ( T c T s s C o n s t a n t s . TSS SECRET MODE PLAIN , k e y U s a g e S e c r e t ) ; k e y U s a g e P o l i c y . a s s i g n T o O b j e c t ( mySigningKey ) ; // Create and s e t i t s m i g r a t i o n s e c r e t TcBlobData k e y M i g r a t i o n S e c r e t = TcBlobData . n e w S t r i n g ( ” m i g r a t i o n s e c r e t ” ) ; TcIPolicy keyMigrationPolicy = context . createPolicyObject ( T c T s s C o n s t a n t s . TSS POLICY MIGRATION ) ; k e y M i g r a t i o n P o l i c y . s e t S e c r e t ( T c T s s C o n s t a n t s . TSS SECRET MODE PLAIN , k e y M i g r a t i o n S e c r e t ) ; k e y M i g r a t i o n P o l i c y . a s s i g n T o O b j e c t ( mySigningKey ) ; //Then l e t t h e TPM c r e a t e t h e key . . . mySigningKey . c r e a t e K e y ( s r k , n u l l ) ; // . . . and s t o r e t h e c r e a t e d key f o r l a t e r use . //The s t o r a g e i s a system wide s t o r a g e i d e n t i f y i n g i t s k e y s by so c a l l e d UUIDs TcTssUuid keyUUID1 = TcUuidFactory . g e t I n s t a n c e ( ) . generateRandomUuid ( ) ; c o n t e x t . r e g i s t e r K e y ( mySigningKey , T c T s s C o n s t a n t s . TSS PS TYPE SYSTEM , keyUUID1 , T c T s s C o n s t a n t s . TSS PS TYPE SYSTEM , TcUuidFactory . g e t I n s t a n c e ( ) . getUuidSRK ( ) ) ;

Listing 14. Asymmetric key creation using jTSS

24

A. Reiter et al.

Listing 14 shows the process of asymmetric key creation using jTSS. Before a new key can be created, the policies need to be set (usage secret, migration secret) and the user has to take care of loading the complete parent key hierarchy manually. Listing 15 shows the process of asymmetric key creation using doTSS. Before any key related methods can be used, a key-store needs to be opened/created. All key related functions can be used by acquiring a key handle which represents a single (not necessarily loaded) key. The secrets (usage secret and migration secret) can be set before creation, if the framework does not ask the user for providing one. //Open/ c r e a t e a key−s t o r e t o l o a d or s a v e k e y s I D i c t i o n a r y <s t r i n g , s t r i n g > arguments = new D i c t i o n a r y <s t r i n g , s t r i n g > ( ) ; arguments . Add ( ” f i l e ” , ” / path / t o / k e y s t o r e ” ) ; tpm . K e y s t o r e = TPMKeystoreProvider . C r e a t e ( ” S Q L i t e K e y s t o r e ” , arguments ) ; // Get a SRK c l i e n t h a n d l e C l i e n t K e y H a n d l e s r k = tpm . K e y C l i e n t . GetSrkKeyHandle ( ) ; // I n s t r u c t t h e TPM t o c r e a t e a s i g n i n g key w i t h t h e SRK as p a r e n t key . // This i s t h e s i m p l e s t o v e r l o a d i n g o f CreateKey f o r a non m i g r a t a b l e // 2048 b i t RSA key , b u t more o v e r l o a d i n g s e x i s t . C l i e n t K e y s i g n i n g K e y = s r k . CreateKey ( ” f r i e n d l y N a m e ” , TPMKeyUsage . TPM KEY SIGNING ) ;

Listing 15. Asymmetric key creation using doTSS

B.3

Data Binding Example

The process of binding encrypts the data with the private key of a specified binding key. This means that the data is bound to this TPM and can only be decrypted using the same TPM as for binding (or another TPM if the key has been migrated). In contrast to the seal operation, the bind operation does not take the current TPM state into account. TrouSerS, jTSS and µTSS use arbitrary interfaces as proposed by the TCG. The TCG specifications do not take any existing frameworks that are well known to software developers into account. They introduce all new interfaces and behavior. The three different approaches are illustrated in listing 16, 17 and 18. It is always assumed that the context setup and key setup are completed. // Data Bind r e s u l t = T s p i D a t a B i n d ( hEncData , hKey , ulDataLength , rgbDataToBind ) ; // e r r o r h a n d l i n g r e s u l t = T s p i D a t a U n b i n d ( hEncData , hKey , &pulDataLength , &prgbDataToUnBind ) ; // e r r o r h a n d l i n g . . .

Listing 16. Data binding using TrouSers

Listing 17 illustrates the process of data binding using jTSS. TcIEncData encData = c o n t e x t . c r e a t e E n c D a t a O b j e c t ( T c T s s C o n s t a n t s . TSS ENCDATA BIND ) ; encData . b i n d ( key , rawData ) ; TcBlobData boundData =encData . g e t A t t r i b D a t a ( T c T s s C o n s t a n t s . TSS TSPATTRIB ENCDATA BLOB, T c T s s C o n s t a n t s . TSS TSPATTRIB ENCDATABLOB BLOB ) ; TcBlobData unboundData =encData . unbind ( key ) ; // e r r o r h a n d l i n g

Listing 17. Data binding using jTSS

Seamless Integration of TC into Standard Cryptographic Frameworks

25

// / E x t r a c t b i n d i n g k e y from unbind k e y BindingKey bKey = ubKey . g e t Bi n d i n g K e y ( ) ; // / Bind t h e d a t a BYTEARRAY e n c r y p t e d = bKey . b i n d ( d a t a ) ; // / Unbind t h e d a t a BYTEARRAY r e s u l t = ubKey . unbind ( e n c r y p t e d ) ; // e r r o r h a n d l i n g

Listing 18. Data binding using µTSS

doTSS reuses existing interfaces where possible. The .NET programming language does not provide a real abstraction of asymmetric algorithms, therefore, we included the BouncyCastle framework [3], which provides the missing abstraction for asymmetric algorithms and for data signing as needed in appendix B.4. Listing 8 in section 3 illustrates the process of data binding using doTSS. B.4

Signing Example

The signing operation signs the data with the provided signing key on the TPM. The TCG specifications again propose new interfaces and do not reuse existing frameworks. Signature verification is done without interacting with the TPM, but the software developer needs to know some parameters of the signature operation, like the type of the key and the hashing operation in use. The signing process using jTSS with the TCG proposed interfaces is illustrated in listing 19. TcIHash hash = c o n t e x t . c r e a t e H a s h O b j e c t ( Tc TssCo st a n t s . TSS HASH SHA1 ) ; hash . updateHashValue ( d a t a ) ; TcBlobData s i g n a t u r e = hash . s i g n ( si g n K e y ) ;

Listing 19. Data signing using jTSS

The signing operation using doTSS is illustrated in listing 6 in section 3.

Design and Implementation of Document Access Control Model Based on Role and Security Policy Liangjian Mao1 , Shuzhen Yao2 , Kai Zhang2 , and Kouichi Sakurai1 1

Department of Informatics, Kyushu University, Fukuoka 812-0053, Japan [email protected], [email protected] 2 School of Software, BeiHang University, Beijing 100191, China {szyao,kzhang}@buaa.edu.cn

Abstract. To design a method of document access control with flexibility, generality and fine-granularity, we establish a document access control model, which is an abstract description for general scene of document access. Security policies are presented to describe security constraints, so as to meet security requirements of this model. In order to demonstrate the theories and strategies more intuitively, we design a prototype system of document access control based on XACML-RBAC framework to verify the validity of model and algorithms and the feasibility of mechanism. It realizes the authorization protection of the standard OFFICE documents. Keywords: Document Protection, Document Access Control, Security Policy, Information Flow, XACML-RBAC.

1

Introduction

1.1

Background and Motivation

Due to the electronic document’s characteristics of convenience to copy, modify and transfer, serious problems such as sensitive information disclosure might be caused. Therefore, the research on the protection of important document has been the hotspot of information security. The existing mechanisms have some limitations on the functionality, expandability and granularity of access control. One important problem is that they don’t support security policy quite well. When there are a large number of documents in the organization to protect, the privilege management may cause confusion or even security problem. This paper aims to create a Document Access Control Model, on the model base, using the document protection mechanism to implement authorization protection to documents. 1.2

Previous Works

The current document protection technique can be achieved mainly through file encryption, file format conversion and the control of peripherals as well as 

This paper is supported by the National Defense Basic Scientific Research Program of China under grant No. A2120061061, which was accomplished in Software Engineering Institute of BeiHang University.

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 26–36, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Design and Implementation of Document Access Control Model

27

network protocols [1]. For instance, Microsoft Word and Adobe Acrobat implement their security mechanisms through security passwords, digital signatures and other methods. The WaterBox7.2 system achieves document protection through limiting the use of some external devices and controlling the network protocol. The Cobra DocGuard system implements it through transforming documents which is in need of protection into other formats. The TotalFileGuard system utilizes transparent encryption and decryption. However, those document protection technologies have some limitations: file encryption and digital signature require users to have high security awareness and technical level, the method of file format conversion needs to use a specific reader and will change the using habits of users. Those technologies also lack the support of access control strategy. Lzaki and Tanaka [2] present an access control model for the object-based systems, and discuss how to control information flow through roles. But not refer to objects protection. Objects in the model are instances of the class, which are created with attribute values of the class. Security policies such as Suranjan and Vidyaraman provide the Document Control Domain (DCD) [3]. It can defense against insider abuse based on the principles of ”least privilege and minimum requirements”. But it can’t satisfy the security requirements of complex system. Specially, Dynamic Security Rules can enforce more specific and finer-grained controls of user’s operation actions. Besides, security policies are enforced according to user’s role in system. Microsoft Exchange 2010 delivers new, integrated e-mail archiving and retention functionality. RBAC [4] is a new permission model in Exchange 2010. But it cannot protect documents. Rights Management Services [5] is information protection technology that works with RMS-enabled applications to help safeguard digital information from unauthorized use. but it neither supports access control strategy nor assigns roles to different users. If a user copies the content of some document into another current open one, RMS can’t monitor the illegal information flow. Alban and Patrick [6] showed how to model dynamic security rules based on spatial contexts. They use these spatial contexts to write security policies for spatial applications, but not for dynamically controlling user’s operation and preventing hidden divulge of document information. we use a method based on analysis of information flow to implement creating Dynamic Security Rules.so as to find out the potential approach that leads the leak of information. 1.3

Challenging Issues

In order to protect documents and sensitive information, we implement a document control model, focusing on the following challenging issues: The major challenge is how to establish corresponding security policies according to security requirements. So we need to analyze security requirements firstly, and then discuss implementation of consistency of model state. Secondly, how to assign roles to different users, and define security constraints such as role separation of duty, times of role activation and role dependencies. How to create Dynamic Security Rules is an important issue. It can monitor user’s operations on document in different environment and find out the possible path of information disclosure.

28

1.4

L. Mao et al.

Our Contributions

(1) We implement a Document Access Control Model, which can solve the problem of insider information leakage for organization. This model has the functions to prevent: – Insiders can read without limits, copy, print and send the any touchable documents by mail. – Insiders copy the content of the original document to a new document, and then hold the title of the new document. – A user can copy the content of some document to another current open document, thus spreading the confidential information. (2) On the basis of analyzing security requirements of this model, we establish corresponding security policies including Static Security Rules and Dynamic Security Rules. (3) With regard to assigning roles to different users, we define security constraints such as role separation of duty relations, times of role activation and role dependency relations. (4) In order to verify the validity of model and algorithms and the feasibility of mechanism, we design and implement a Document Access Control System based on the model.

2

XACML-RBAC Framework

The XACML-RBAC framework [7] did not describe the role’s relationship. However, in the practical role-based access control system, the relationship between roles is closely interconnected. Roles can complete a task through their cooperation, so it is very necessary to extend the XACML-RBAC framework, and add constraints on role’s relationship. Here, we discuss three methods to describe the relationship of security constraints. (1) The restriction on role activation time. Users are constrained to activate certain role only within the scope of certain time. The starting and ending time is represented by the Policy/Rule/Condition element of Role Assignment PolicySet. (2) The restriction on times of role authorization. Role can only be granted to a fixed number of users, so that we can prevent the abuse of important privilege and improve system security. The number of maximum assignment is represented by the Policy/Rule/Condition element of Role Definition Policy file. (3) The description of roles separation of duty. One user is not permitted to own other conflict role’s property when it owns one role’s property. It includes two types of separation of duty policies such as static separation of duty and dynamic separation of duty.

Design and Implementation of Document Access Control Model

3

29

Document Access Control Model

Access control mechanism includes ”Discretionary Access Control”, ”Mandatory Access Control” and ”Role based Access Control” [3].This model uses the rolebased access control mechanism. Administrator classifies roles according to staff responsibilities, every role is held accountable for completing minimized privilege collection corresponding function. The model achieves separation of user and operation authority of controlled documents. There is a sample which implements resource protection by using role-based access control mechanism shown in Fig.1. In the sample, o1 , o2 and o3 are protected resource in system, user1 has rights of reading o1 , writing o2 and o3 through Manager role. With position changing of staff, new staff joining and appliance of new function, traditional access control mechanism needs to reset access control relation between staff and document. If document set is larger, it will bring a great burden to administrator. Role-based access control mechanism only resets authorization manner between staff and role, or allocation relation between role and operation authority, so that it greatly eases the burden of administrator. It is helpful to increase system security.

Fig. 1. Separation of Users and Access Right

We establish a Document Access Control Model by abstracting document operation scenario of internal network. It mainly includes Client Monitor, Policy Server, Security Policy, and User Operating Environment. They are introduced briefly as follows: (1) Client: The users of internal network enter into Document Access Control System through client. The client sends authentication request to server through collecting user information. Server authenticates users according to security policy which is made by administrator, and offers authorized role set to legal users. Users role activate request according to its functions. (2) Policy Server: It is the core components of Document Access Control Model, all files of access control strategy in system are deployed in server. Administrator only has rights to manage these security policies, which include role-user assignment strategy, role-authority allotment strategy, and various model security constraints.

30

L. Mao et al.

(3) Security Policy: It includes Static Security Rules and Dynamic Security Rules. Static Security Rules are a group of policy files made by administrator for implementing access control mechanism. Dynamic Security Rules are additional restrictions that Policy Server computes, according to specific accessing operation of users and scenarios. (4) User information and Operating Environment: User Information is used to verify user identity, only staff can obtain the operation authority of documents. Access control right of document is just to specific users, Server can authorize user only after obtaining user information. User Operating Environment includes some information of system when user operates document. User Operating Environment is one of computing evidences of Dynamic Security Rules. Fig.2 shows a diagram of Document Access Control Model, it describes interactions among each component of this model.

Fig. 2. Document Access Control Model Diagram

The main purpose of this model is to prevent information leakage caused by the information flow among different documents. Internal users send the opening document request, and then the request is sent to the security decision generation engine. After the engine receives the user’s controlled document request, using user environment information and security policies, it calculates the Dynamic Security Rules [6], and output control strategy for specified controlled documents.

Design and Implementation of Document Access Control Model

4

31

Security Requirements of Model

Security requirements of this model are used to implement policy management for administrator, and constrain operations such as user activating. It suits model requirements for practical system. In fact, the relation between role and role is not isolated, it may need multi-roles’ collaboration to finish a task. There are different constraints for staff in different duty department. Therefore, in order to implement fine-grained access control, we also must consider the relation of different roles and the realities of enterprise, and define some properties to meet the model. Security requirements Role-based Access Control Model mainly includes: (1) Rights Exclusion Principle, every right assigned to the same role must meet Exclusion relations of functions and rights. (2) Minimum Right Principle, right assigned to some role is minimum operation right set that this role needs to finish the task. (3) Separation of Static Duty doesn’t assign two Exclusion roles to the same user at the same time. (4) Separation of Dynamic Duty extends Separation of Static Duty on the concept, and the concept of ”active role” was introduced. (5) Maximum User Base Principle, if business needs to have restrictions on the number of users whom have this role in system when define roles, it will need to specify the maximum user base of this role in role definition. Except for the above five main security constraints, administrator can make more detailed rules according to actual condition of organization, such as user activated time [8], roles dependencies. Gavrila S.L [9] defines a set of security properties, which must satisfy with the status of RBAC database . According to the restriction on a set of standard operation, they can ensure the consistency of the status of RBAC database. These security properties mainly implement the restriction on role cardinality, role hierarchy and role separation of duty.

5

Security Policy of the Model

The Security Policy of Model includes Static Security Rules and Dynamic Security Rules. Static Security Rules are a set of security policies which already have been defined by system manager. They specify internal staff’s access permissions on documents in organization. They are static. Dynamic Security Rules are limitation on users’ operation for the Document Control model, according to the users’ current operation environment and static security policies. They are dynamic as the complement to Static Security Rules. Below we introduce respectively them. 5.1

Static Security Rules

Static Security Rules consist of access strategies and rules made in advance by the system according to known situation. They mainly include these constraint

32

L. Mao et al.

read

user1

user2

o1

s1

role r1 write

s2 role r2

read

o2

Fig. 3. Illegal Information Flow of Role-based Access Control Model

conditions such as the role-user assignment strategy, role-authority allotment strategy, separation of duty, roles dependence and user activation times [10]. Role-user assignment strategy is used to realize the corresponding relationship between users and roles. The system administrator assigns roles to staff according to their responsibility and function. Each user can have many roles, and each role also corresponds to multiple users. This strategy makes the management of the user more convenient. Role-authority allotment strategy is used to realize the corresponding relationship between roles and operation authorities of documents. Administrator can assign a minimum operation right set which meets the corresponding responsibility function to each role. 5.2

Dynamic Security Rules

The traditional document access control approaches, mainly assign access control authorities to users statically. Their access control granularities are coarser, and cannot dynamically adjust according to the change of operating environment. They cannot monitor and analyze operations, which authorized user access document within the authority range. They also cannot prevent receiving information filch [11], which resulted by authorized user separate or co-operation. For above problems, the Document Control model uses Dynamic Security Rules to implement a dynamic constraint. Dynamic Security Rules are Security rules automatically generated by the system when insiders access the document. By enforcing of these rules the safe usage environment of the document is established, it can avoid hidden divulge of the document information. The internal host controls access to documents together according to access control strategy (Static Security Rules) and Dynamic Security Rules. Dynamic Security Rules are additional conditions which need to meet the implementation of the security policy or access control strategy. As Fig.3 shows a simple demonstration of information leakage caused by users’ cooperation within the scope of authorization. In Role-based access control model, o1 and o2 are protected objects, user1 activates role r1 , user2 activates role r2 . r1 has read authority to o1 and write authority to o2 , r2 only own read authority to o2 . Suppose that we carry out the following steps: When user1 read the information of o1 and write it into o2 .If user1 sends o2 to user2 , and user2 reads o2 . We can see that through collaborative operation by two users, it can

Design and Implementation of Document Access Control Model

33

make user2 read the information to o1 . However, the access control strategy does not allow user2 to read the content of o1 . Thus, it is not enough to rely on the access control strategy. We need to monitor and analyze document access operations for authorized users within the scope of their permissions, and find out the possible path of information disclosure [2]. Then we guard against it, and achieve the protection of documents with Static Security Rules. The creation of Dynamic Security Rules is a important research goal, this paper uses the method based on information flow analysis to generate Dynamic Security Rules. Through the match between Static Security Rules and Dynamic Security Rules, we can monitor user’s operation on document in different operating environment. 5.3

Information Flow Analysis

Dynamic Security Rules use a method which dynamically control user’s operation and prevent hidden divulge of document information, on the basis of Document Access Control Model. This paper uses a method based on analysis of information flow to implement creating Dynamic Security Rules, according to current operation environment, analyzes document information flow dynamically and then find out the potential approach that leads the leak of information [12]. Consequently some measures can be taken to prevent it from happening, so that the document content can be protected. The Information Flow Analysis algorithm we proposed can find out the potential approach with time complexity O(D * P * V) where D is the number of protected documents, and P is the number of access permission, and V is the number of vertices.

6 6.1

Document Access Control System Implementation

In order to prove the feasibility and effectiveness of this model, the correctness of related algorithms and theories that involved in the process of research, we design and implement a Document Access Control system based on model. The Document Access Control system is based on the XACML-RBAC standard [6]. We use XACML-RBAC framework to define the core and layer criterion of RBAC and access control policies of system, so as to describe system’s user-role assignment, role-permission assignment and security constraints that the system satisfies. It includes static separation of duty, dynamic separation of duty, times of role activation and role dependency. When the administrator carries on role assignment, role revocation, permission assignment and permission revocation, or the user carries on role activation and role revocation, system judges whether these operations violate security attributes of system through using access control policy, thus ensuring that the system is stable, and persistently satisfying the security requirements of system. The Document Access Control system adopts framework design of C/S. It includes Client Monitor and Policy Server. The Client has Login, Information Collection, File System Directory Monitor and Client Communication modules,

34

L. Mao et al. Client Monitor

Policy Server

Login

Information Collection

Client Communication

File System Directory Monitor

Server Communication

Role Management

User Management

Identity Verification

Policy Management

User Environment Monitor

Illegal Information Flow Analysis

File Permission Management

Access Control Policy Files

Fig. 4. Document Access Control System

and the Server has Identity Verification, Role Management, User Management, File Permission Management, User Environment Monitor and Illegal Information Flow Analysis in several modules. Fig.4 shows every component of system and their relationships. The Client is deployed on each user host within the organization, and the user can only gain access control to documents via activating Client. It is mainly used for activating role and monitoring user environment. The Server is the core of the Document Access Control System. It includes following functions: (1) To implement user-role arrangement and role-permission arrangement through managing access control policies, which are deployed on server, only administrators have permission to read and write policy files. (2) Consistency of system status maintenance, to ensure that management to access control policies by administrator doesn’t violate security constraints of system. (3) To set document access permissions for other users with Rights Management Services, and implement authorized access to document by using approach based on certificate. 6.2

Evaluation

Through testing and validation of the documents access control system, it has achieved the anticipated effect basically and has been proved available and effective. It can realize security constraints such as separation of duties between roles, the role activation number of times, and the role dependence. Using the service of RMS can realize the authorized access to the standard format of documents. After the identity authentication to user, it can realize the authorized access to the documents in accordance with the system security policy. Access control strategy is still not very perfect for the Document Access Control System at present. It only realized the protection of the standard Office documents, for the protection of other formats documents had not provided support yet. Lacking of analysis of the user’s operation diary, it only realized the

Design and Implementation of Document Access Control Model

35

record of operational activities at this stage. Lack of monitoring of operational activities between users, the recessive revelation of information must through correspondence between users. So it is the key to monitor the correspondence activities between users to realize monitoring the information flow.

7

Conclusion and Future Work

In this paper, we establish a Document Access Control Model with specific feature of document operations, and design security policy by analyzing security requirements of model. The dynamic monitoring of user’s document operation in different operating environment is comprehensively implemented through Static Security Rules and Dynamic Security Rules coordination. We propose a method of document access control based on analysis of information flow, which is considered as the theoretical foundation of Dynamic Security Rules. It can calculate possible path of information leakage in the system by using Illegal Information Flow Analysis Algorithm. By combining the Security Policy of Model, we implement authorization protection to documents in internal network. Based on this model, we implement a document access control system. Combined with Microsoft Rights Management Services (RMS) technique [13], this system can protect OFFICE standard format documents such as Word, Excel, PowerPoint, Access, Outlook, and Visio. Our future work is to research how to provide protection with documents of other format. We will study non-standard format document protection such as PDF, media, video files and so on.

Acknowledgement The authors would like to thank the anonymous referees for their acute comments and suggestions.

References 1. Yu, Y., Chiueh, T.C.: A solution against information theft due to insider attack. In: Proceedings of the 4th ACM Workshop on Digital Rights Management, pp. 31–39 (2004) 2. Lzaki, K., Tanaka, K.: Information flow control in role-based model for distributed objects. In: Parallel and Distributed Systems, pp. 363–370 (2001) 3. Pramanik, S., Sankaranarayanan, V., Upadhyaya, S.: Security Policies to Mitigate Insider Threat in the Document Control Domain. In: Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC 2004), pp. 304–313 (2004) 4. Suranjan, P., Vidyaraman, S., Shambhu, U.: Security Policies to Mitigate Insider Threat in the Document Control Domain. In: Proceedings of the 20th Annual Computer Security Applications Conference, pp. 304–313 (2004) 5. Microsoft Windows Rights Management Services for Windows Server 2003 Helping Organizations Safeguard Digital Information from Unauthorized Use (October 2003)

36

L. Mao et al.

6. Gabillon, A., Capolsini, P.: Dynamic Security Rules for Geo Data. In: GarciaAlfaro, J., Navarro-Arribas, G., Cuppens-Boulahia, N., Roudier, Y. (eds.) DPM 2009. LNCS, vol. 5939, pp. 136–152. Springer, Heidelberg (2010) 7. Sun Microsystems, cs-xacml-rbac-profile-01, XACML Profile for Role Based Access Control (RBAC) (2004), http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf 8. Bertino, E., Bonatti, P.A., Ferrari, E.: TRBAC: A temporal role-based access control. ACM Transactions on Information and System Security 4(3), 191–223 (2001) 9. Gavrila, S.L., Barkley, J.F.: Formal Specification for Role Based Access Control User/Role and Role/Role Relationship Management. In: Proceedings of Third ACM Workshop on Role-Based Access Control, pp. 81–90 (1998) 10. Barkley, D.: Countering the Threat from Malicious Insiders.In: Computer Security Applications Conference, pp. 6–10 (2004) 11. Sandhu, R., Bhamidipati, V.: The ARBAC97 Model for Role-Based Administration of Roles. In: Proceeding of the Second ACM Workshop on Role-Based Access Control, pp. 41–50 (1997) 12. Steve, Z.: Challenges for information-flow security. Proceeding of the 1st International 13. Technical Overview of Windows Rights Management Services for Windows Server 2003. White paper. Microsoft Corporation (November 2003)

Towards High-Performance IPsec on Cavium OCTEON Platform Jinli Meng1 , Xinming Chen2,3 , Zhen Chen3 , Chuang Lin3 , Beipeng Mu2 , and Lingyun Ruan2 1

Department of Computer Science and Technology, Tsinghua University, Beijing, China 2 Department of Automation, Tsinghua University, Beijing, China 3 Research Institute of Information Technology (RIIT), Tsinghua University, Beijing, China [email protected], [email protected] {zhenchen,chlin}@tsinghua.edu.cn,{mubeipeng,rlyswf}@gmail.com

Abstract. Providing secure, reliable communications is a big challenge to guarantee confidentiality, integrity, and anti-replay protection, especially between endpoints in current Internet. As one of the popular secure communication protocol, IPsec usually limits the throughput and increases the latency due to its heavy encryption/decryption processing. In this paper, we propose a hardware solution to accelerate it. To achieve high performance processing, we have successfully designed and implemented IPsec on Cavium OCTEON 5860 multi-core network processor platform. We also compare the performance under different processing mechanisms and discover that pipleline works better than run-to-completion for different sizes of packets in our experiments. In order to achieve the best performance, we select different encryption algorithms and core numbers. Experimental results on 5860 processors show that our work achieves 20 Gbps throughput with AES128 encryption, 16 cores for 512-byte packet traffic. Keywords: network processor, multi-core, network security, IPsec, cryptography.

1

Introduction

Internet’s openness brings enormous benefits, as well as many security risks. In order to provide a trusting information exchange environment, many security mechanisms are used across the network. However, only about 10% of the infomation across the Internet are protected because of the encrypting performance and cost [1]. IPsec (IP security) is a protocol suite for securing IP communications, supplying confidentiality, data integrity, anti-replay attack that the IETF delimited for the network layer to provide security services. However, IPsec function greatly increases the load of the network devices [2]. Also there are multiple parameters in the implementation of IPsec, which provide trade-off between security and L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 37–46, 2011. c Springer-Verlag Berlin Heidelberg 2011 

38

J. Meng et al.

efficiency. The design, implementation and optimization of IPsec should be paid special attention to these parameters in order to enhance efficiency. In this paper, we focus on the IPsec implementation on network processors, because they provide hardware acceleration specialized for packet processing and encryption / decryption. The OCTEON family of Multi-Core MIPS64 processors is one of the industry’s most scalable, highest-performance, and lowest-power solution for intelligent networking applications. So our goal is to test and implement IPsec in this hardware platform in an efficient and high-performance way. We design, implement and test IPsec on OCTEON CN58XX platform. Different encryption algorithms such as AES, DES, 3DES have different impacts on performance. Different packet length from 64 bytes to 1280 bytes and different core numbers from 1 to 16 are also important factors for performance. The most important factor is the system mechanism. Two mechanisms, run-to-completion and pipeline, are implemented and discussed in this paper. Run-to-completion mechanism means to deal with the packets in the same flow in a core from the very beginning to the end, and pipeline mechanism means packets from the same flow can be processed in parallel in multiple cores sometimes. We discuss the reasons and give advices on how to construct high-performance IPsec implementation on multi-core platform. The rest of the paper is organized as follows: Section 2 gives an overview of Cavium OCTEON network platform and its two kinds of operating mechanisms named run-to-completion and pipeline, introductions about IPsec parameters and about encrypting algorithms are also included. Details of the design of our IPsec implementation are given in Section 3, including the data structures, processing procedure etc. Section 4 illustrates the performance experiments and three groups of performance data, analysis the best parameter combination for a better performance, and discusses the reasons why it should be. As a summary, in Section 5, we state our conclusion.

2 2.1

Background Cavium OCTEON

The OCTEON CN58XX family of multi-core MIPS64 network processors is released in 2008. It is an industrial solution for intelligent networking applications ranging from 100Mbps to 40Gbps. On OCTEON 58XX network processor, one network processor chip consists of 16 cores. Each core can be programmed separately [3–5], so they can provide solution for scalable networking equipments. 2.2

Run-to-Completion vs Pipeline

For multi-core processors, there are two ways to perform batch processing: runto-completion is to execute the whole processing of a flow in the same core. If the queue is blocked in run-to-completion mechanism, the processing will wait until unblocked. Pipeline is to divide the processing procedure of packet into several simple executives or stages, and one stage in one core. In this way, multiple cores can deal with packets in different stage from the same flow simultaneously, and

Towards High-Performance IPsec on Cavium OCTEON Platform

39

the completion of one processing needs multiple cores. Once a packet comes, the descheduled module selects the shortest queue of these cores where to put the packet. There is a POW (Packet order / Work Unit) also named SSO (Schedule / Synchronization / Order) module in Cavium OCTEON Network Processor[3, 4]. In pipeline mechanism, the processing is divided into several simple executors corresponding to different processing stages; every core has its own queue maintained by POW unit. These simple executors can be tagged with ORDERED, ATOMIC, and NULL. These tags can be switched among them. Multiple packets from the same flow with an ORDERED Tag Type may be processed in parallel by multiple cores, leading higher packet throughput. While ATOMIC Tag Types mean processing should be serialized: one-at-a-time in ingress-order. NULL Tag Types are neither ordered nor serialized: multiple cores can process multiple packets, and no packet order is maintained. Four relationship cases the packet and the waiting queue have: 1. Once a packet arrived, it will enter the queue. 2. Once a simple executive finished, and the tag is not NULL, the packet will be put back to the queue. 3. Once the simple executive is blocked, it will quit and de-schedule. 4. Once a simple executive finished, and the tag is NULL, the packet will run out of the system. 5. This is an endless loop. 2.3

IPsec

IPsec (IP security) is a protocol suite for securing communications in IP networks. The essence of IPsec is to add security fields between IP field and transport layer in original IP packet, which can be unpacked by receiver for verification. In our experiment, we will use ESP and transport mode to simplify the operations. Fig. 1 illusions the ESP header. SPI (Security Parameter Index) is the data structure to point to SA (Security Association), which records the shared secret key and related information. SN (Sequence Number) stores the counter of all the packets in one SA, in order to resist the replay attack. IV (Initialization Vector) is the initial vector of encryption algorithm, including AES, DES, and etc. Some algorithms need to pad to meet the requirement on packet length. In the end, the ESP tail HMAC (Hash Message Authentication Code) provides integrity guarantee. There are some consideration in our design and implementation of IPsec scheme in Cavium OCTEON CN58XX platform. Multi-algorithm supplies various confidentiality environments. Under our circumstances, the experiments are conducted to choose the best fit encryption algorithm on the consideration the tradeoff of performance and confidentiality. The number of used cores will also affect the performance. In the scenario of multi-core platform, different parallelization methods of IPsec scheme will result in different performance in throughput. There are run-to-completion and

40

J. Meng et al. 32 bits Security Parameter Index (SPI) Sequence Number (Replay Defense) Initialization Vector (IV) Data Padding Padding Length Next Header Hash Message Authentication Code

Fig. 1. Data structure of ESP tranport mode in IP payload

pipeline mechanisms [6–8] should be tested and evaluated for final IPsec scheme in multi-core platform. 2.4

Encrypting Algorithms

There are kinds of encrypting algorithms such as DES(Data Encryption Standard), 3DES(Triple DES), AES(Advanced Encryption Standard). 3DES is almost the same three DES rounds to enhance the safety of DES. AES is faster and safer than DES. For AES, the secret key can be 128 bits, 192 bits, 256 bits. All these algorithms are implemented with hardware.

3

IPsec Implementation

The IPsec processing procedure can be divided into six stages: Defragment, IPsec decrypt, Lookup, Process, IPsec encrypt, and Output. Table 1 shows the stages and corresponding tags (a tag is a special label of different stages). Defragment means to reconstruct IP packet with data fragment. In the IPsec decrypt stage, incoming packets should be decrypted and recovered to the original ones. While forwarding the packet, it needs to check the SPD table and SA table according to the hash value of five-tuple of the packet; that’s what Lookup stage does [3]. The Process stage involves the necessary processing of packets before sending them out, such as NAT translation or TCP sequence number adjustment. The IPsec encrypt stage performs IPsec encryption for packets according to SP. The Output stage places the packet into an output queue and let Tx driver sent it out [9, 10]. The state of a packet is switched from one stage to another. When a stage (except the last one) is finished, it switches its tag, re-enqueued, and de-scheduled. Table 1. IPsec stages Step Tag Defrag O tag={0,hash(IP src, IP dest)} IPsec decrypt A tag={1, IPsec SPI/SA} Lookup A tag={2, hash(IP src, IP dest, IP protocol, IP srcport, IP destport)} Process O tag={3, hash(IP src, IP dest, IP protocol, IP srcport, IP destport)} IPsec encrypt A tag={4, IPsec SPI/SA} Output queue A tag={5, Output Queue Index}

Towards High-Performance IPsec on Cavium OCTEON Platform

41

IORZBOXWBWDEOH .H\ VSGBSWU IORZ

3RLQW IORZ .H\ VSGBSWU HU

IORZLQWKHUDQJH IORZ

.H\ VSGBSWU 3RLQWHU 18// IORZ

63'WDEOH IORZLQWKHUDQJH

3RLQW .H\ VSGBSWU IORZ HU 3RLQW .H\ VSGBSWU IORZ HU )ORZ

3RLQW .H\ VSGBSWU 18// IORZ HU 3RLQW .H\ VSGBSWU 18// IORZ HU

3RLQW .H\ VSGBSWU IORZ HU

6DBSWU

3ROLF\B,'

6DBSWU

)ORZUDQJH

IORZLQWKHUDQJH .H\ IORZ

3ROLF\B,'

)ORZUDQJH



VDBOLVWBKHDG 3RLQW .H\ VSGBSWU 18// IORZ HU

)ORZUDQJH

IORZ

3ROLF\B,'

VSG,' ,' VSG,' ,'

2XWERXQG6$LQIR

2XWERXQG6$LQIR

VSG,'

VSG,'

6SGBSWU 18//

Fig. 2. Data structure and processing flowchart of OUTBOUND

These stages can be grouped into two classes: INBOUND that deals with input flows and OUTBOUND that deals with output ones. They will be detailed in the following parts. 3.1

OUTBOUND Design

Fig. 2 illustrates the data structure and flowchart from a five-tuple to a SA, and adding an IPsec header to the original packet. 1. The POW reads a packet and queue it in the flow according to their five-tuple and Tag-tuple. 2. According to the hash(IPsrc, IPdest, IP protocol, srcPort, destPort), the POW looks up the corresponding f low lut table item, and gets the appropriate spdID in the SPD table. If it does not hit, the POW searches the SPD table to get the correct flow range, and then updates the f low lut table. 3. According to the spdID, the POW gets the SA information from SA list. 4. Encrypt the packet and append the IPsec header to the packet. Then send the packet out. 3.2

INBOUND Design

Fig. 3 illustrates the data structure and flowchart from SPI, destination IP and protocol to a SA, recovering an IPsec packet to the original packet. 1. The POW reads packets and searches the inbound lut table using the index of SPI&63, destination IP and protocol.

42

J. Meng et al.

inbound_lut_table pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

Inbound SA

NULL pro=PRO,dst=DST,spi=SPI

sa_ptr*

pro&spi&dst

sa_ptr*

NULL

pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

NULL

pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

pro&spi&dst

sa_ptr*

PRO

DST

SPI

PRO

DST

... SPI

PRO

DST

pro=PRO,dst=DST,spi=SPI

pro&spi&dst

SPI

NULL

pro&spi&dst

sa_ptr*

NULL

Fig. 3. Data structure and processing flowchart of INBOUND

2. According to the tri-tuple arrays <SPI, destination IP, protocol>, the POW gets the SA information in Inbound SA table. 3. Decrypt the packet and remove the IPsec header of the packet.

4 4.1

Performance Evaluation Development Platform and Test Environments

The following experiments are based on a Radisys ATCA-7220 blade, which contains two Cavium OCTEON CN5860 Network Processor[11]. These two processors act as two endpoints of a link, and perform IPsec processing on all the packets passing throughput them. They are named DPB1 and DPB2 (Data Processing Block) in the following experiments. In the IPsec processing of DPBs, the plain text is encrypted and signed by the selected SA according to SPD, and the cipher text is decrypted and verified by the selected SA according to the flow table. An Agilent N2X testing device is used to send out a duplex traffic with 10 Gbps for each direction. The testing topology is shown in Fig. 4. 4.2

Experiment on Different Encryption Algorithms and Packet Length

In this experiment, a full-duplex traffic of 2×10 Gbps is used. All the 16 cores of each NP are used to achieve the best performance data. The signing algorithm is SHA1, and the schedule mechanism is pipeline. tag switch is performed in order to make the process correctly. Different encryption algorithms including

Towards High-Performance IPsec on Cavium OCTEON Platform

43

Agilent N2X 2*10Gbps

2*10Gbps

DPB2

DPB1

ATCA-7220 NP blade Fig. 4. The testing environment

22 AES128 AES192 AES256 DESCBC 3DES

Processing Speed (Gbps)

20 18 16 14 12 10 8 6 4

0

200

400

600

800

1000

1200

Packet Length (Bytes)

Fig. 5. Throughput of different encryption algorithms and packet length

AES128, AES192, AES256, DESCBC and 3DES are tested, and packet lengths from 64 to 1280 are evaluated respectively. The results are shown in Fig. 5. From this experiment, it can be seen that the longer the packet length is, the better the performance is. This is because there is a fixed work (e.g. five-tuple checking) for processing each packet, which is independent with packet length. So the processing time of each packet is almost the same. But the throughput increase slows down after 512 Bytes, because of the limited port speed. It seems that various encryption algorithms have almost the same influence on throughput, but AES still has a slightly better throughput value. For different key length of AES, 128 bits seems to have the best performance. And AES is more secure than DES. So we choose AES128 as our encryption algorithm under the condition of using all the 16 cores. 4.3

Experiment on Different Core Numbers

The second experiment also uses full-duplex traffic of 2×10 Gbps. The signing algorithm is SHA1 and the encryption algorithm is AES128. tag switch is

44

J. Meng et al.

22 64 128 256 512 1024 1280

20

Processing Speed (Gbps)

18 16 14 12 10 8 6 4 2 0

0

2

4

6

8

10

12

14

16

Core Number

Fig. 6. Throughput of different core numbers

performed. The schedule mechanism is pipeline. And in various packet length, the throughput under different core numbers is shown in Fig. 6. In Fig. 6, the throughput is almost linear to the core number, indicating a good scalability of this system. This result means there is little correlation between cores, and most of the IPsec steps are parallel, which makes core number not the limit in architecture design. It can be expected that if the core number is further increased, the processing ability can continue to grow, until it reaches a limitation such as memory bus speed or cache speed bottleneck. We hope further experiments to verify this conclusion. 4.4

Experiment on Pipeline and Run-to-Completion Mechanism

In this experiment, the core number is set to 16; the traffic is full-duplex with throughput of 2×10 Gbps. The signing algorithm is SHA1 and the encryption algorithm is AES128. The pipeline and run-to-completion schedule schemes are compared with each other under different packet length. The result is shown in Fig. 7. This experiment shows that pipeline mechanism is faster than run-tocompletion mechanism in performance. The first reason for this phenomenon is that the pipeline can process the packets from the same flow in parallel, so that the utilization of each core can be improved. On the other hand, the runto-completion mechanism may get stuck while accessing some critical region, leading to a poor utilization of each core, and the flow cannot be processed properly. The second reason is that the instruction data is divided into several small sets in pipeline mechanism. The instruction data may be large during some IPsec operations. Pipeline mechanism divides the instructions and each core only executes some of the instructions, which increase the cache locality. In contrast, the run-to-completion mechanism can cause a relatively low cache locality and

Towards High-Performance IPsec on Cavium OCTEON Platform

45

22 pipeline run−to−completion

Processing Speed (Gbps)

20 18 16 14 12 10 8 6 4

0

200

400

600

800

1000

1200

Packet Length (Bytes)

Fig. 7. Throughput of pipeline and run-to-completion mechanism

low hit-rate of cache, which leads to a lower throughput. We can come to a conclusion that the distance between pipeline and run-to-completion performance is larger with the growth of packet length. However, the throughput is up to 2×10 Gbps. And it will not increase anymore once the mechanism is no longer bottleneck of the experiments.

5

Conclusion

With one of the industry’s most scalable, highest-performance network processor solution for network security applications, Cavium OCTEON CN58XX is used to implement IPsec scheme to achieve 20 Gbps throughput with the packet of length 1024B in full encryption scheme, a record-breaking progress in academic and industrial research. Based on CN58XX, two parallelize mechanisms i.e., run-to-completion and pipeline, are proposed for the implementation of IPsec on Cavium platform, in order to achieve the optimal performance. Extensive experiments are conducted to evaluate the performance of these two mechanisms in real scenarios. The experiment results shows that the pipeline mechanism is the Best Current Practice for IPsec solution in multi-core platform, since it has a better throughput performance than the run-to-completion mechanism. We also give some insightful discussion and analysis of the performance results of these two mechanisms. Besides, the influence of core numbers and algorithms also mentioned in our experiments.

Acknowledgment This work is supported by Natural Science Foundation of China No. 90718040 with the title of ”Trusted Computing Environment and Trusted Software

46

J. Meng et al.

Design”, and National High-tech Program No. 2007AA01Z468 with the title of ”A Holistic UTM System Design and Implementation”, and Hosun Tech.

References 1. Kounavis, M.E., Kang, X., Grewal, K., Eszenyi, M., Gueron, S., Durham, D.: Encrypting the internet. In: SIGCOMM 2010, pp. 135–146 (2010) 2. Liu, Q.: Study and Implementation on IPsec VPN Gateway Based on Netfilter Mechanism. Master Thesis of Chongqing University (2009) 3. Cavium Networks: Cavium Networks OCTEON Plus CN58XX Hardware Reference Manual, pp. 221–235 (2008) 4. Cavium Networks: OCTEON Processor Packet Flow, pp. 21–52 (2008) 5. Cavium Networks: OCTEON Technical Presentation, p. 26 (2007) 6. Intoto Inc.: Virtual Private Network White Paper (2002) 7. RFC 2402: IP Authentication Header (AH) (1998) 8. RFC 2406: IP Encapsulating Security Payload (ESP) (1998) 9. Sang, S.L., Sang, W.L., Yong, S.J., Ki, Y.K.: Implementing High Performance VPN Router using Cavium’s CN2560 Security Processor. World Academy of Science, Engineering and Technology 9, 1307–6884 (2005) 10. Cavium Networks: Cavium Networks Announces Industry’s First 10Gbps IPsec and SSL PCI-Express Security Accelerators (2005) 11. Promentum ATCA-7220, http://www.radisys.com.cn/Products/ATCA/Processing-Modules/ Promentum-ATCA-7220.html

An Abstract Model of a Trusted Platform Cornelius Namiluko and Andrew Martin Oxford University Computing Laboratory Wolfson Building, Parks Road, Oxford OX1 3QD, UK {cornelius.namiluko,andrew.martin}@comlab.ox.ac.uk

Abstract. A trusted platform is a fundamental building block in most trusted computing based architectures. Although it can be constructed from a finite set of components, there are several ways of combining the components and several configuration options that affect trust-related properties. Examples of such properties may be specifying that a platform will not expose a secret or delegate a task to a rogue entity. Despite its importance, very little attention has been directed towards reasoning about the properties that result from the way the platform is constructed and configured. Reasoning about these properties enables one to understand their security implications. In order to reason about such properties, we propose an abstract model, based on CSP, in which a platform is treated as a potentially malicious composition of sub-systems that interact through communication of messages. The model enables instantiation of platforms with varying trust levels and verification against specified properties. The applicability of the model is demonstrated on a trusted grid platform. Keywords: Trusted Platform, CSP, Model, Reasoning.

1

Introduction

A trusted platform can be defined, according to the TCG’s1 definition of a trusted entity, as a system that operates in the expected manner for the intended purpose. Such a platform must be able to record and report its current configuration and to securely store data without exposing it to malicious code that may be resident on the platform. Furthermore, a trusted platform should ensure that programs running on it are isolated, processes running in the user space are separated from privileged processes and that hardware-based protections are provided [1]. A trusted platform plays a crucial role in many trusted computing based architectures [2–5]. Grawrock [1] describes it as a fundamental building block of trustworthy computing. Given the architectures’ dependency on the concept of a trusted platform, it is important to understand what a trusted platform is and reason about its properties when placed in a given environment. This is because we believe that any trust-related guarantees that an architecture will provide are determined by the properties of its building blocks and the interactions among them. 1

Trusted Computing Group: http://www.trustedcomputinggroup.org

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 47–66, 2011. c Springer-Verlag Berlin Heidelberg 2011 

48

C. Namiluko and A. Martin

Although a trusted platform can be constructed from a finite set of components, there are several ways of combining the components and several configuration options that affect trust-related properties. Given these options, how can we reason about the properties that result in a specific construction of a platform? In order to answer this question, the properties of constituent elements of a platform and the relationships among them must be understood [1]. Towards this end, we propose a model based on Communicating Sequential Processes (CSP), in which a platform is treated as a potentially malicious composition of sub-systems that interact using well defined interfaces. The model enables instantiation of platforms with varying trust levels and verification against specified properties. Its applicability is demonstrated on a case study on a trusted grid platform proposed by Cooper and Martin [6]. We begin with background material on trusted computing and CSP in Sections 2 and 3 respectively. In Section 4, we present the abstract model, explaining how the components interact to create a complete platform. In Section 5 we describe how platform instances are created using the model and how their properties are verified. A case study to demonstrate the applicability of the model is presented in Section 6 and observations about the model are made in Section 7. We present related work in Section 8 and conclusions and future work in Section 9.

2

Trusted Computing

Trusted computing is a combination of techniques that aim to provide a secure computing environment. It sprung from the realisation that “software alone can not protect itself” [7] and therefore introduces hardware based protection to improve the security of computer systems. It enables cryptographic platform identification, protected storage of security-sensitive information, integrity measurement of the software stack running on a platform and secure reporting of the recorded measurements to other entities (humans or machines). The main idea is to provide an immutable, implicitly trusted, entity from which to root trust for the entire platform. For this purpose, a functional specification [8] specifies a Trusted Platform Module (TPM) as a device that is securely installed on a platform in such a way that its operations cannot be influenced by the software running on the platform. The TPM has an internal structure comprising of a random number generator, an execution engine, volatile and non-volatile memory and an array of 20-byte storage areas called platform configuration registers (PCRs) [8]. The TPM enables secure storage of integrity measurements in the PCRs through the extend process, which appends data to the existing contents of a given PCR index using a cryptographic hash operation. This ensures that only the same data, extended in the same order, can produce a particular state of the PCR. Once integrity is recorded, a platform can authenticate its software stack to remote parties through a process called remote attestation [5, 10]. Cooper and Martin [6] describe remote attestation as “a powerful security primitive that allows a party to obtain assurance in the correct operation of a system that is beyond their physical control”. In this process, the entity wishing to rely on

An Abstract Model of a Trusted Platform

49

a platform challenges the platform. The challenged platform responds with an integrity report and the relying entity verifies the report to determine whether the platform is trustworthy or not. Several variations of attestation have been proposed [9–11] with a common aim of enabling more meaningful verification of integrity reports. Trusted computing also enables long-term secure storage of data. The main idea is to lock (seal ) data to some desired platform configuration so that it can only be released (unsealed ) when the platform attains the specified configuration. Another aspect of secure storage is applied in scenarios where some data is required to never leave the platform. In this case, the data is encrypted with a key, called non-migratable key, that can never leave the platform. 2.1

Trusted Platforms

A trusted platform combines hardware based cryptographic mechanisms, secure storage and attestation to ensure that it operate as expected and is able to prove to relying parties about its ability to operate within their expectations. In order to do this, several hardware and software components, in specific configurations, are combined to ensure that modifications in the software stack can be detected by relying parties and to guarantee that sensitive information never gets exposed even when the platform is compromised. The main mechanism for establishing trust in a platform involves creating a chain of trust from an immutable entity and ensuring that every entity in the chain is measured by the previous entity before it is loaded. Entities represent platform components, examples of which include operating system kernels, boot loader, integrity measurement agent and user space applications. The components reside on some storage medium and are loaded when they need to execute. Once executed, components perform some computations and participate in communication either with other components within the platform or with external entities. 2.2

The Need for Reasoning about Platform Properties

Proposed architectures [2–5] use common trusted computing mechanisms of integrity measurement, secure storage and attestation to build a trusted platform. Though the proposals use similar techniques, they differ in how the platform is constructed. For example, one proposal may choose to use a static root of trust over a dynamic root of trust or a TPM over a virtual TPM. Furthermore, the start-up order of the components on the platform and the configuration settings may differ from platform to platform. Though a platform may attest to the integrity of its components, an attacker cares less about that. Attackers would be interested in exploiting any opportunities arising from mis-configurations, design flaws and errors in the operation of the platform. To understand a platform’s capability to defend itself against attacks and to protect its computation and data requires reasoning about how it is constructed from its constituent components and how the components interact.

50

3

C. Namiluko and A. Martin

A CSP Primer

Communicating sequential processes (CSP) was developed by Hoare [12] as a notation for describing and reasoning about communicating concurrent systems. It comprises a language and mathematical models for describing systems and reasoning about properties that arise as a result of the way in which the compositions of systems interact [13]. It enables various analyses to be performed including; determinism - whether a system will always behave exactly the same way when given the same inputs; liveness - whether a system interacts with its environment; and deadlock-freedom - whether a system can make progress. Most interestingly, CSP is equipped with operators that enable sub-systems to be combined into more complex systems. CSP provide events, such as write, as primitives for atomic actions performed by a system. Events are then combined using operators into a process to indicate the steps a system performs. This can be as simple as STOP - which performs no event - or could be a combination of choices of events. The general structure of a process is an event followed (written ‘→ ’) by either another process or event. For example a process ‘write → P’ is a process that performs the event write and then performs events specified in the process P . Events may also be used to communicate data, in which case they are represented by a channel and the data carried on that channel. For example write.a.d might be used to represent an event in which some data, d , is written to some address, a. Operators are used to build complex processes. The external choice, 2 , operator enables the process to offer a choice of events to the environment while the internal or nondeterministic choice,  , operator represents a choice of events that will be selected without influence from the environment. Other operators of interest to our model include; hiding, \ , - where P \ A is a process with all the events in the set, A, hidden; alphabetised parallel, [AB], - where P [AB]Q is a process such that P and Q have to agree on the events in A ∩ B while they are free to communicate any other event; interleaving, ||| , - where P ||| Q is a process in which P and Q operate without agreeing on any events; and generalised or interface parallel, [| C|] , - where P [| C|] Q is a process where P and Q have to agree on all the events in the set C . The recursion operator, µ X • P, is used in most of our process definitions. It defines a process that performs any event in the set X before acting like the process P . For example, we write ‘2 code : Code • extend.code’ to represent a process that will offer a choice of extending any code from the set Code. A full set of operators and their properties can be found in Roscoe’s book [13]. CSP provides semantic models to enable reasoning about the properties of a concurrent system. A system’s properties can be verified by checking refinement using one of the semantic models, traces - MUT , failures - MUF or failures-divergences - MUFD . For example to check that a system, S , only performs a certain sequence of events, a process that performs the desired sequence is modeled as the specification, SPEC and the system, S , will serve as an implementation. Then assertions are written using CSP’s semantic models and verified using the model checker FDR, a defacto standard for verifying CSP specifications, licensed by Formal Systems

An Abstract Model of a Trusted Platform

51

(Europe) Limited2 . For example using the traces model, assert SPEC T P states that the process S will only perform events that SPEC can perform. FDR will indicate success or failure of the assertions giving counterexamples for failed assertions. 3.1

Why CSP

The previous section highlighted the fact that a platform will be composed of multiple components that are initially executed in a sequential order but branch into concurrent executions as more components are executed. Furthermore, the components communicate and exchange data among themselves and with external entities. For example, an attestation service component, will receive an attestation challenge from an external entity, communicate with the TPM to obtain a quote, communicate with a storage resource or another component to obtain the stored measurement log before sending the collected data to the entity that sent the challenge. We see from this setup, that components will run concurrently and communicate. CSP is designed to enable reasoning about the properties of concurrent systems that communicate [13] and therefore is ideal for such scenarios. CSP offers parallelism at no extra cost and a good choice of semantic models for reasoning about different types of properties. This enables us to verify properties of a platform with respect to some specifications and to relate one or more platforms through refinement. Furthermore, CSP has demonstrated its power as it has been successfully applied in the analysis of critical applications including security [14, 15], fault tolerance [16] and safety-critical systems [17]. We believe that its potential, combined with its success and inherent support for parallelism and communication, makes it a perfect tool for our model.

4

An Abstract Model

In this section, we propose a CSP-based abstract model of a trusted platform. The model is designed to: (i) be generic - capture any platform that falls within the definition of a trusted platform given above; (ii) enable varying trust-levels - different levels of trust can be assigned by the relying party based on the construction and configuration of the platform; and (iii) be instantiable - allow concrete implementations to be created from it. In the proposed model, we define a platform as a hierarchical composition of systems such that each high-level system is a composition of sub-systems that interact in a predefined manner. At the highest level are the runtime system, resources, applications and configurations. At the lowest level are the actual executable components with each component represented by a role it plays in the platform and a series of events representing the actual execution steps, protocol or algorithm that the component performs. As illustrated in Figure 1, the runtime system interacts directly with the resources using the resource interface and controls access to resources by providing 2

Formal Systems (Europe) Limited - http://www.fsel.com

52

C. Namiluko and A. Martin

Fig. 1. High-level view of a platform

a restricted service interface. Configurations are provided to all the components via the config interface. The platform is therefore constructed using CSP’s interface parallel operator, [| X|] , as shown below. The platform takes as arguments; a process that provides configuration information, initial data (such as memory contents) held in the resources, application logic for the applications that run on the platform and a set of interfaces through which the applications interact. Platform ( P l a t f o r m C o n f i gu r at io ns , Init_Res_Data , App_Runs , A p p _ I n t e r f a c e s) = ( ( R u n t i m e _ S y s t e m [|r e s o u r c e _ i n t e r f a c e|] R e s o u r c e s( I n i t _ R e s _ D a t a)) [|s e r v i c e _ i n t e r f a c e|] A p p l i c a t i o n s( App_Runs , A p p _ I n t e r f a c e s) ) [|c o n f i g _ i n t e r f a c e|] P l a t f o r m C o n f i g u r a t i o n s

4.1

Runtime System

A runtime system captures the life-cycle of a platform from start up through the period in which applications are executed up to the point when the platform is reset or shutdown. This is captured in the Runtime System process, which starts as a sequential process and later branches to support parallel execution of applications, as shown in Figure 2. The platform is initialised, init, after which the bios runs some selftest before loading the boot loader, BTL. The boot loader loads the operating system, Operating System, which in turn loads the application manager, AppManager . At every step of the loading process, a component is executed by getting its associated configuration, via config, reading the contents of the memory location specified in the configuration, via read, loading the code that has been read, via load , and then running the code, via run.

An Abstract Model of a Trusted Platform

53

Fig. 2. Runtime system - dotted arrows represent sequential operation while solid ones represent synchronisation R u n t i m e _ S y s t e m = 2 bcode : P o t e n t i a l B i o s C o d e • init → selftest . bios . bcode → (2 loc : P o t e n t i a l B t l L o c • config . bcode . btl . loc → (2 code : P o t e n t i a l B t l C o d e • read . M . loc . code → load . bcode . btl . code → extend . code → BTL ( code ))) BTL ( id ) = run . btl . id → ( 2 osloc : P o t e n t i a l O S L o c • config . id . os . osloc → (2 cod : P o t e n t i a l O S C o d e • read . M . osloc . cod → load . id . os . cod → extend . cod → O p e r a t i n g _ S y s t e m( cod ))) O p e r a t i n g _ S y s t e m( id ) = run . os . id → (2 apmloc : P o t e n t i a l A P M L o c • config . id . app_man . apmloc → (2 c : P o t e n t i a l A P M a n C o d e • read . M . apmloc . c → load . id . app_man . c → extend . c → run . app_man . c → ( 2 l : P o t e n t i a l T S S r v c L o c • config . c . ima . l → (2 ts : P o t e n t i a l T r u s t S e r v i c e • read . M . l . ts → load . code . ima . ts → extend . ts → ( run . ima . ts → ( AppManager ’( code , id ,{ ts })[|t s _ l o a d _ i n t e r f a c e|] T r u s t _ S e r v i c e s)) )))) AppManager ’( id , osid ) = 2 loc : P o t e n t i a l C o d e L o c • 2 rol : P o t e n t i a l C o d e R o l e • config . id . rol . loc → (2 code : P o t e n t i a l C o d e 2 R u n • read . M . loc . code → load . id . rol . code → run . rol . code → AppManager ’( id , osid )

The model is designed such that the application manager does not know the order in which to run applications and relies on the Platform Configurations process, outlined in Section 4.4, to enforce the order. T r u s t _ S e r v i c e s = ( Service ( s3 , S e c u r e _ S t o r a g e) ||| Service ( rs , R e p o r t i n g _ S e r v i c e)) [|{|run . role . x | role ← { s3 , rs } , x ← P o t e n t i a l T r u s t S e r v i c e|}|] Service ( ima , I n t e g r i t y _ M e a s u r e m e n t) Service ( role , s e r v i c e _ l o g i c) = 2 code : P o t e n t i a l T r u s t S e r v i c e • run . role . code → s e r v i c e _ l o g i c( code ) I n t e g r i t y _ M e a s u r e m e n t( id ) = 2 rol : P o t e n t i a l C o d e R o l e • ( if member ( rol , P o t e n t i a l T r u s t S e r v i c e R o l e) then 2 c : P o t e n t i a l T r u s t S e r v i c e • 2 ld : P o t e n t i a l L o a d e r • load . ld . rol . c → extend . c → run . rol . c → I n t e g r i t y _ M e a s u r e m e n t( id ) else 2 c : P o t e n t i a l A p p • 2 ld : P o t e n t i a l L o a d e r •

54

C. Namiluko and A. Martin load . ld . rol . c → ( if member ( rol , TcbRoles ) then extend . c → run . rol . code → I n t e g r i t y _ M e a s u r e m e n t( id ) else run . rol . code → I n t e g r i t y _ M e a s u r e m e n t( id )))

S e c u r e _ S t o r a g e( id ) = 2 ap : diff ( IMA_Measurable ,{ Garbage }) • 2 data : Secret • 2 blb : Blob • ( store . id . ap . data → seal . data . ap . blb → stored . id . ap . blb → S e c u r e _ S t o r a g e( id ) 2 retrieve . id . ap . blb → unseal . blb . data → r e t r i e v e d. id . ap . data → S e c u r e _ S t o r a g e( id )) R e p o r t i n g _ S e r v i c e( id ) = 2 n ’: Nonce • c h a l l e n g e.n ’ → (2 q : Quote • quote .n ’. q → response . q → R e p o r t i n g _ S e r v i c e( id ))

Trust services provide trusted computing functionality, including integrity measurement, reporting of the platform state and secure storage of data, to applications. The Trust Services process is a combination of the integrity measurement service, Integrity Measurement , secure storage service, Secure Storage, and reporting service, Reporting Service. The Integrity Measurement service records integrity for other trust services and all applications whose role is in the trusted computing base (TCB). The Secure Storage service provides secure storage by sealing the data to some state and allows retrieval of the stored data while the Reporting Service service accepts and responds to integrity challenges. 4.2

Resources

Resources are entities that enable the runtime system to provide the necessary services to applications. For example, an application that needs to store a secret will use the storage service, provided as part of trust services, which in turn uses the TPM, which is a resource. Several types of resources may exist on a platform; however, to keep the model simple, only two resources, a TPM and a simplified memory system, are considered. Memory is initialised with an identity and a map representing the initial contents of memory. It offers a read channel which accepts a location and returns the contents of the specified location and a write channel to modify the contents of a specified location. Memory ( id , map )= 2 loc : Address • ( read . id . loc ! get ( map , loc ) → Memory ( id , map ) 2 (2 data : Data • write . id . loc . data → Memory ( id , put ( map , loc , data ))))

The TPM is a resource that offers four basic operations of extend , seal , unseal , and quote. Though in reality these operations are complex, involving a number of intermediate steps such as loading keys, the model abstracts away from such details and concentrate on the core functionality of integrity measurement, secure storage and secure report. The TPM starts with an initial Good state, offers a choice of the four events and changes the state for every extend event. The two resources, TPM and Memory, do not interact directly and are thus interleaved. TPM = 2 c : Code • extend . c → TPM_Op ( newhash ( Good , c )) TPM_Op ( s ) = (2 c (2 n ’: Nonce (2 d : Secret (2 b : Blob •

: Code • extend . c → TPM_Op ( hash (s , c ))) 2 • quote .n ’. getQuote (n ’ , s ) → TPM_Op ( s ))2 • seal . d . c ! c r e a t e b l o b(d , c ) → TPM_Op ( s ))2 unseal . b ! g e t U n s e a l e d D a t a( b ) → TPM_Op ( s ))

R e s o u r c e s( cfg ) = TPM ||| Memory ( getMemId ( cfg ) , g e t M e m M a p( cfg ))

An Abstract Model of a Trusted Platform

4.3

55

Applications

Applications are a collection of functionality offered by the platform. Each application is specified as a tuple consisting of an identity and application logic and is capable of synchronising on events provided by the runtime system, platform configuration and other applications. The model provides dynamic specification of applications that run on the platform, using the algorithm outlined in Algorithm1. This allows platform implementations to specify the actual application logic such as protocols in which each application may engage. The implementations may use any desired channels, with a restriction that channels in the service interface are strictly for use between application-service and not application-application interactions. Algorithm 1. DynamicApplicationsProcess input output

: 1. Sequence, S , of tuples of the form (identity, application logic) 2. Sequence, I , of sets of channels on which applications synchronise : A CSP process combining all application logic using specified interfaces

13

if S has elements then P ← head(S) //get the first application logic; P1 ← head(tail(S)) //get the second application logic; sync ← head(I) //get the first synchronisation interface; P ← P |[ sync ]| P1 //synchronise P and P1 on sync; S ← tail(tail(S)) //get the remaining applications logic; I ← tail(I) //get the remaining syncronisation interfaces; while S has elements do P1 ← head(S) //get the first application logic from updated sequence; sync ← head(I) //get the first synchronisation interface from updated sequence; P ← P |[ sync ]| P1 //synchronise P and P1 on sync; S ← tail(S) //remove one application logic from sequence; I ← tail(I) //remove the interface that has just been used;

14

else

1 2 3 4 5 6 7 8 9 10 11 12

15 16

P ← SKIP ;

return P;

The algorithm accepts a sequence of application logic and a sequence of synchronisation interfaces. It iterates through the sequences and creates a process by synchronising consecutive application logic with interfaces in the interface sequence. The algorithm makes three assumptions: (i) the number of interfaces is always one less than the number of application logic - this means even if applications do not synchronise, their interface must always be specified; (ii) the order of interfaces in the sequence must match the order of synchronisation for the specified order of application logic - meaning each interface at position i will be used to synchronise the application logic in positions i and i + 1; and (iii) both sides engaged in a synchronisation must use the same name for the channel. This algorithm is implemented in the Applications process that is placed in parallel with the Runtime System. 4.4

Platform Configurations

Platform Configurations provide configuration information to all the other components on the platform. Configurations are used to specify the locations of the

56

C. Namiluko and A. Martin

code to run for each component within the platform and the order in which components are loaded. A complete platform configuration is a sequential composition of all the configuration parts where each part uses the generic form of a configuration as specified in the Configuration process. The Configuration process gets configuration data from the provided sequence and communicates it using the config channel. The config channel specifies the code that performs the configuration, the role of the component being configured and the actual configuration data, a memory location in this case. The getComponentLocation is a helper function that returns a sequence of locations for a given role. P l a t f o r m _ C o n f i g u r a t i o n s( C o m p o n e n t L o c s) = C o n f i g u r a t i o n( g e t C o m p o n e n t L o c a t i o n( ComponentLocs , btl )); C o n f i g u r a t i o n( g e t C o m p o n e n t L o c a t i o n( ComponentLocs , os )); C o n f i g u r a t i o n( g e t C o m p o n e n t L o c a t i o n( ComponentLocs , services )); C o n f i g u r a t i o n( g e t C o m p o n e n t L o c a t i o n( ComponentLocs , a p p l i c a t i o n s)) C o n f i g u r a t i o n( C o n f i g u r a t i o n S e q) = 2 code : P o t e n t i a l C f g L o a d e r • if null ( C o n f i g u r a t i o n S e q) then SKIP else let ( role , loc ) = head ( C o n f i g u r a t i o n S e q) within config . code . role . loc → C o n f i g u r a t i o n( tail ( C o n f i g u r a t i o n S e q))

5

Platform Instantiation and Property Verification

Having described the abstract model, how do we create more concrete implementations from it?. The main idea is to provide the actual values of all the configuration settings and the actual logic of the applications that run on the platform. Specifically, one has to provide: (i) initial memory content; (ii) locations of the components to be loaded on the platform and (iii) application logic for each application. 5.1

Initial Memory Contents

Initial memory contents are specified using a map of locations to the data contained in each location as shown in Initial Mem Map. Currently, the model is built to support one memory device and thus automatically assigns the content to that device. It can easily be extended to support multiple memory devices, for example by specifying a map of maps such as Mem Component Map. Initial Mem Map={(l,d)|l∈Address,d∈Code} Mem Component Map={(id,I )|id∈Identity,I ∈P Initial Mem Map}

5.2

Component Location Configuration

Component locations specify the memory locations that each component role uses. Rather than specifying where each executable code is located, the configuration specifies where each component role is expected to be found. This helps to capture the idea that component locations may contain malicious code. Each part of the configuration is specified as a tuple (RoleId , Address) while the entire

An Abstract Model of a Trusted Platform

57

configuration is specified as a sequence of tuples to capture the order of execution. Therefore a complete specification, as passed to Platform Configuration, is in the form: Configuration Map={|∀ i:[1,n]•ci ∈P(Role,Address)}

5.3

Application Logic

Application logic is specified using the generic structure App Logic Process (shown below). Each application logic is a process that represents the actual execution (e.g. protocol) that the application performs and observes the restriction on the use of the service interface. For example, an application, app1, that simply prints “hello” when it runs would be specified as App_Logic(app) =print.hello → SKIP. App Logic(id)=App logic Process|id∈Code,App logic Process∈ValidCSPProcess

5.4

Property Specification and Verification

The model enables specification and verification of behavioural properties using refinement. A CSP process with the desired behaviour is modelled to act as a specification and the platform being verified acts as an implementation. The implementation is then checked to verify whether it is a refinement of the specification or not. Consider two example properties that are inherent in any platform instantiated from this model: (i) SPEC tcb - every component whose role is in the TCB is measured and (ii) SPEC mb4r - every component that is measured is measured before it is executed. SPEC_tcb ( TCBRols ) = 2 c : Code • rol : Role • load . id . rol . c → if member ( rol , TCBRols ) then extend . c → SPEC_tcb ( TCBRols ) else SPEC_tcb ( TCBRols ) S P E C _ m b 4 r = 2 c : Code • rol : Role • id : Identity • load . id . rol . c → extend . c → run . rol . c → S P E C _ m b 4 r

Property verification is performed by carefully abstracting away events that are not necessary for the property being considered and then checking, using the model checker FDR, whether the resulting system refines the process representing the property. For example, the abstractions for the above specifications for a Platform, P , and the refinement checks would be as follows: -- for S P E C _ t c b system1 = P\ diff ( Events ,{|load , extend|}) assert SPEC_tcb T System1 -- for S P E C _ m b 4 r system2 = P\ diff ( Events ,{|load , extend , run|}) assert S P E C _ m b 4 r T System2

6

Case Study: Cooper’s Trusted Grid Platform

Cooper and Martin [6] argue that middleware in a grid architecture may be compromised and should therefore not be part of the trusted computing base (TCB). They propose an architecture in which a grid platform receives an encrypted job together with a job security manager (JSM) and runs the JSM which enforces

58

C. Namiluko and A. Martin

security policies on the job and attests to the execution of the job. In this section, we specify two platforms suitable for this architecture where the first runs malware while the second runs the expected code. We begin by presenting the desired properties for such a platform before discussing a set of processes that is common to both platform instances. The platform instances are then presented and their properties verified. We define the following variables to represent code that will run on the platforms. We use eveware 5x to represent malicious code, Garbage to represent meaningless information, Good and Bad for quotes coming from the TPM. Other variables include the boot loader, grub 4 2, operating system, linux 2 6, integrity measurement software, ima1 2, reporting service, ats 5, grid middleware, gt 5, a job security manager, jsm 1 9, storage service, rserv 1 8, application manager, appman1 2, and a job, snstv job. 6.1

Property Specification

The architecture imposes that the key used for encrypting/decrypting the job will only be released when a trustworthy TCB (including the JSM) is run. This property can be specified by splitting it into parts; a good trace, (PROP 1) specifying that the correct result, R1, can only be obtained if no malicious code was present in the TCB - and a bad trace, (PROP 2) - specifying that if malicious code is executed then Garbage will be received as the result, allowing the verifier to detect that something went wrong. PROP1 ( tcb ) = 2 mdwid : P o t e n t i a l M d w • 2 jid : JobId • if not null ( tcb ) then extend . head ( tcb ) → PROP1 ( tail ( tcb )) else c o m m _ r e s u l t s. jsm_1_9 . mdwid . jid . encrypt ( R1 , K ) → SKIP PROP2 ( tcb ) = extend . head ( tcb ) → PROP2 ’( false , tail ( tcb )) 2 extend . e v e w a r e _ 5 x → PROP2 ’( true , tail ( tcb )) PROP2 ’( isMal , tcb ) = 2 jsmid : P o t e n t i a l J S M • 2 k : JobKey • 2 mdwid : P o t e n t i a l M d w • 2 jid : JobId • if not null ( tcb ) then if length ( tcb ) == 1 and not isMal then extend . e v e w a r e _ 5 x → PROP2 ’( true , tail ( tcb )) else extend . head ( TCBSeq ) → PROP2 ’( isMal , tail ( tcb )) 2 extend . e v e w a r e _ 5 x → PROP2 ’( true , tail ( tcb )) else c o m m _ r e s u l t s. jsmid . mdwid . jid . encrypt ( Garbage , k ) → SKIP

6.2

Common Setup

In Cooper’s architecture, a platform consists of middleware (Middleware Run or Mal Middleware Run), an application that runs a job (Job App Run) and a job security manager (Jsm App Run). These applications interact with an external verifier or user (Verifier ). The middleware gets the encrypted job from the verifier and forwards to the JSM via the comm job channel. The JSM then obtains the key from the verifier via the key request channel, sending along a quote. The decrypted job is then passed from the JSM to the Job application by synchronising on the execute job channel. The results are sent from the JSM to the middleware and then to the verifier via the comm results channel.

An Abstract Model of a Trusted Platform

59

M i d d l e w a r e _ R u n( id ) = 2 enc_j : E n c r y p t e d J o b • 2 jid : JobId • 2 U : E x t e r n a l A g e n t • get_job . U . id . jid . enc_j → (2 jsmid : P o t e n t i a l J S M • comm_job . id . jsmid . jid . enc_j → (2 enc_r : E n c r y p t e d R e s u l t • c o m m _ r e s u l t s. jsmid . id . jid . enc_r → SKIP )) M a l _ M i d d l e w a r e _ R u n( id ) = 2 enc_j : E n c r y p t e d J o b • 2 jid : JobId • 2 U : E x t e r n a l A g e n t • get_job . U . id . jid . enc_j → write.M .l 8.eveware 5x → (2 jsmid : P o t e n t i a l J S M • comm_job . id . jsmid . jid . enc_j → (2 enc_r : E n c r y p t e d R e s u l t • c o m m _ r e s u l t s. jsmid . id . jid . enc_r → SKIP )) J o b _ A p p _ R u n( id ) = 2 j : Job • 2 r : Result • 2 jid : JobId • e x e c u t e _ j o b. jid . j . g e t R e s u l t( j ) → SKIP J s m _ A p p _ R u n( id ) = 2 mdwid : P o t e n t i a l M d w • 2 enc_j : E n c r y p t e d J o b • 2 jid : JobId • 2 japp : P o t e n t i a l J o b • comm_job . mdwid . id . jid . enc_j → (2 n ’: Nonce • 2 ks : E x t e r n a l A g e n t • c h a l l e n g e.n ’ → (2 q : Quote • response . q → k e y _ r e q u e s t. id . ks . jid . q → (2 k : JobKey • k e y _ r e s p o n s e. ks . id . jid . k → (2 r : Result • e x e c u t e _ j o b. jid . decrypt ( enc_j , k ). r → c o m m _ r e s u l t s. id . mdwid . jid . encrypt (r , k ) → SKIP )))) Verifier ( id ) = 2 mdwid : P o t e n t i a l M d w • 2 enc_j : E n c r y p t e d J o b • 2 jid : JobId • 2 enc_j : E n c r y p t e d J o b • get_job . id . mdwid . jid . enc_j → (2 jsmid : P o t e n t i a l J S M • 2 q : Quote • 2 enc_r : E n c r y p t e d R e s u l t • k e y _ r e q u e s t. jsmid . id . jid . q → if q == Good then k e y _ r e s p o n s e. id . jsmid . jid . K → c o m m _ r e s u l t s. jsmid . mdwid . jid . enc_r → SKIP ) else k e y _ r e s p o n s e. id . jsmid . jid . Garbage → c o m m _ r e s u l t s. jsmid . mdwid . jid . enc_r → SKIP ) M e m o r y _ C o n t e n t s = {( l1 , grub_4_2 ) ,( l2 , l i n u x _ 2 _ 6) ,( l3 , a p p m a n 1 _ 2) , ( l4 , ima1_2 ) , ( l5 , ats_5 ) , ( l6 , r s e r v _ 1 _ 8) , ( l7 , gt_5 ) , ( l8 , jsm_1_9 ) ,( l9 , s n s t v _ j o b) ,( l10 , e v e w a r e _ 5 x)} P l a t f o r m _ A p p _ I n t e r f a c e = <{|comm_results , comm_job |},{|e x e c u t e _ j o b|}> T C B E l e m e n t s = < grub_4_2 , linux_2_6 , appman1_2 , ima1_2 , ats_5 , rserv_1_8 , jsm_1_9 , snstv_job > S P E C _ g o o d = PROP1 ( T C B E l e m e n t s) SPEC_bad = PROP2 ( T C B E l e m e n t s)

6.3

Instantiating a Malicious Platform

A malicious platform is configured to run a malicious grid middleware, which replaces the JSM with a malicious one that does not enforce the policies as intended by the job owner. This allows the job data to be corrupted or stolen. M a l _ A p p _ R u n s = <( mdw , M a l _ M i d d l e w a r e _ R u n) ,( pep , J s m _ A p p _ R u n) ,( app , J o b _ A p p _ R u n) > M a l _ P l a t f o r m _ C f g = P l a t f o r m _ C o n f i g u r a t i o n s( M a l _ P l a t f o r m _ L o c _ C f g) M a l _ P l a t f o r m _ R e s o u r c e C f g = (M , M e m o r y _ C o n t e n t s) Mal_Platform_Loc_Cfg = <( btl , l1 ) ,( os , l2 ) ,( app_man , l3 ) ,( ima , l4 ) , rs , l5 ) ,( s3 , l6 ) , (mdw , l 10) ,( pep , l10 ) ,( app , l9 ) > M a l _ P l a t f o r m = Platform ( Mal_Platform_Cfg , M a l _ P l a t f o r m _ R es ou r ce Cf g , Mal_App_Runs , P l a t f o r m _ A p p _ I n t e r f a c e)

6.4

Instantiating a Non-malicious Platform

A non-malicious platform is configured to load the desired (not eveware 5x ) code for each component. Each of the applications mdw, pep and app are executed in line with the specified application logic.

60

C. Namiluko and A. Martin

N o n M a l _ A p p _ R u n s = <( mdw , M i d d l e w a r e _ R u n) ,( pep , J s m _ A p p _ R u n) ,( app , J o b _ A p p _ R u n) > N o n M a l P l a t f o r m _ C f g = P l a t f o r m _ C o n f i g u r a t i o n s( N o n M a l _ L o c _ C f g) N o n M a l _ R e s o u r c e C f g = (M , M e m o r y _ C o n t e n t s) NonMal_Loc_Cfg = <( btl , l1 ) ,( os , l2 ) ,( app_man , l3 ) ,( ima , l4 ) , ( rs , l5 ) ,( s3 , l6 ) ,( mdw , l7 ) ,( pep , l8 ) ,( app , l9 ) > N o n _ M a l _ P l a t f o r m = Platform ( N o n M a l P l a t f orm _C fg , N o n M a l _ R e s o urc eC fg , NonMal_App_Runs , P l a t f o r m _ A p p _ I n t e r f a c e)

The two platforms differ in that Mal Platform has a malicious middleware application, Mal Mdw Run, and the location specified for middleware is l 10 which contains malicious code represented by eveware 5x . 6.5

Property Verification, Results and Discussion

The two platforms specified are verified against the properties specified in Section 6.1 using refinement as outlined in Section 5.4. Abstractions are created in the same way for both platforms using the Abstract 4Props1N 2 function, which takes a process and returns another process with events on all channels other than extend and comm result hidden. We use the stable failures model for checking SPECgood because not only does it show what events the platform will perform but also what it will refuse to perform, referred to as refusals in CSP. However, for SPECbad , the trace model suffices as it is enough to show that the process can perform untrustworthy actions. A b s t r a c t 4 P r o p s 1 N 2( P )

= P\ diff ( Events ,{|extend , c o m m _ r e s u l t s|})

A b s t r a c t e d _ N o n _ M a l _ P l a t f o r m = A b s t r a c t 4 P r o p s 1 N 2( N o n _ M a l _ P l a t f o r m) Abstracted_Mal_Platform = A b s t r a c t 4 P r o p s 1 N 2( M a l _ P l a t f o r m) assert S P E C _ g o o d F A b s t r a c t e d _ N o n _ M a l _ P l a t f o r m assert S P E C _ g o o d F A b s t r a c t e d _ M a l _ P l a t f o r m

-- label : G o o d O n N o n M a l i c i o u s -- label : G o o d O n M a l i c i o u s

assert SPEC_bad T A b s t r a c t e d _ N o n _ M a l _ P l a t f o r m assert SPEC_bad T A b s t r a c t e d _ M a l _ P l a t f o r m

-- label : B a d O n N o n M a l i c i o u s -- label : B a d O n M a l i c i o u s

Malicious Platform Results and Discussion The malicious platform fails on SPECgood giving a counterexample trace shown below. On the other hand the assertion on SPECbad passes. 

Listing 1.1. Result - counterexample trace labeled ’GoodOnMalicious’

extend .grub 4 2, extend .linux 2 6, extend .appman1 2, extend .ima1 2, extend .ats 5, extend .rserv 1 8, extend .eveware 5x , extend .snstv job, comm results.eveware 5x .eveware 5x .j 1.Encrypt.(Garbage, Garbage)





The trace includes an extend .eveware 5x indicating that the JSM was replaced with eveware 5x . A further analysis of this system indicates that when eveware 5x requests for a key prentending to be JSM , the verifier detects that the platform is not trustworthy because the quote sent on the response channel is Bad . The verifier then sends Garbage as a key for decrypting the job, which when used to decrypt the job gives Garbage. The result of executing Garbage is

An Abstract Model of a Trusted Platform

61

also Garbage and hence the result sent back being Encrypt .(Garbage, Garbage). Therefore the malicious platform fails to satisfy SPECgood because some TCB components are not trustworthy. Non-malicious Platform Results and Discussion The non-malicious platform fails on SPECbad but passes SPECgood . The counterexample indicates that no malicious code was executed as part of the TCB, a condition enforced by SPECbad . The non-malicious platform never executes untrustworthy code in the TCB and never sends Garbage as a result. Listing 1.2. Result - counterexample trace for assertion labeled ’BadOnNonMalicious’



extend .grub 4 2, extend .linux 2 6, extend .appman12 , extend .ima1 2, extend .ats 5, extend .rserv 1 8, extend .jsm 1 9, extend .snstv job



6.6



Performance Results

FDR performs refinement check by translating the processes into state machines before normalising them and checking the specifications. Since both the Malicious and Non-Malicious platforms are based on the same underlying model and the same applications, the state machine generation and normalisation stage is the same for all specification. This took 8 seconds, with a total of 2,273 state machines generated and 512 buffers of 128K. 

Listing 1.3. Performance results for initial stage - i.e. state machine generation

Bisimulation reduced to 2 ,273 s t a t e s L o a d i n g . . . done Took 8(0+0) s e c o n d s −− N o r m a l i s i n g s p e c i f i c a t i o n −− N o r m a l i s a t i o n c o m p l e t e S t ar t i n g timer About t o s t a r t r e f i n e m e n t A sy n c h r o n o us I /O u n a v a i l a b l e wi t h t h i s b u i l d . U si n g 512 b u f f e r s o f 128K

 

Once the state machines have been normalised, FDR performs refinement checks for each of the assertions. Performance results specific to each assertion are shown below. Generally, the assertion checks were efficient, with the worst involving checks on 96 states and 135 transitions. 

Listing 1.4. Performance Results for assertion labeled ’GoodOnNonMalicious’

Re f i n e m e n t c h e c k : ∗ +..∗ R e f i n e c h e c k e d 95 s t a t e s With 134 t r a n s i t i o n A l l o c a t e d a t o t a l o f 10 p a g e s o f s i z e 128K Compaction p r o d u c e d 0 chunks o f 16K.





62



C. Namiluko and A. Martin Listing 1.5. Performance Results for assertion labeled ’GoodOnMalicious’

Re f i n e m e n t c h e c k : ∗ +..∗ + . . Tr a c e e r r o r a f t e r 42 s t a t e s

R e f i n e c h e c k e d 42 s t a t e s With 44 t r a n s i t i o n s A l l o c a t e d a t o t a l o f 10 p a g e s o f s i z e 128K Compaction p r o d u c e d 0 chunks o f 16K. Found 1 example







Listing 1.6. Performance Results for assertion labeled ’BadOnNonMalicious’

Re f i n e m e n t c h e c k : ∗ +..∗ + . . Tr a c e e r r o r a f t e r 53 s t a t e s

R e f i n e c h e c k e d 53 s t a t e s With 63 t r a n s i t i o n s A l l o c a t e d a t o t a l o f 10 p a g e s o f s i z e 128K Compaction p r o d u c e d 0 chunks o f 16K. Found 1 example





Listing 1.7. Performance Results for assertion labeled ’BadOnMalicious’

Re f i n e m e n t c h e c k : ∗ +..∗ R e f i n e c h e c k e d 96 s t a t e s With 135 t r a n s i t i o n s A l l o c a t e d a t o t a l o f 10 p a g e s o f s i z e 128K Compaction p r o d u c e d 0 chunks o f 16K.



7





Observations

In this section we highlight some of shortfalls and potential bottlenecks in the model and note some strategies for addressing them. 7.1

Application Specification

The process of specifying applications requires the implementor to understand what events to expose to what other applications as well as the order of the composition of interfaces. For example when a set of applications A, B , C interacting on interfaces X and Y are to be combined correctly, the implementor has to decide the order of synchronisation. For example they would have to choose between (A [| X|] B) [| Y|] C and A [| X|] (B [| Y|] C), as the interface parallel operator is not associative. A better approach might be to adopt the approach taken in Casper [15] - specifying application logic using a high-level language and translating the specifications into CSP.

An Abstract Model of a Trusted Platform

7.2

63

Extending Configurations

The model currently focuses on configuration settings for memory locations and the order of application execution. However, this does not give a complete picture as there are a number of other configuration options that impact on the trustworthiness of a platform. Our aim in this work was to demonstrate the applicability of the idea rather than to build a comprehensive list of configuration options. In future we intend to investigate what other configurations impact a platform’s trustworthiness and incorporate them into the model. 7.3

State Space Reduction

The approach of abstract system modeling cannot be separated from issues of state explosion - the state grows as more options are included in the model. Therefore, deliberate effort needs to be taken to keep the state space to a minimum. Some of the steps taken in this model include: (i) restricting available options - for example rather than allowing the boot loader to load any code on a given channel, we restrict to a set PotentialOSCode with only two options a good value, linux 2 6, and a bad value, eveware 5x ; (ii) restricting the applications to a minimum set - we identify the roles and create an application for each role; and (iii) distributing process state - where possible processes with multiple state variables were split into smaller interacting processes. 7.4

Performance and Scalability of the Model

The current model has been designed mainly to demonstrate the applicability of the idea. Not much attention was paid to other attributes such as performance and optimisation was mainly left to the model checker FDR. However, performance results on assertion checks were very encouraging. Model checking, in general, requires careful selection of states to model. While one may choose to model all the events that all applications on a platform will engage in, this may not be useful for understanding security and trust properties of a platform. Furthermore, this may not scale as most model checkers, including FDR, have a limit on the number of states they can analyse. What is required is, rather, a careful selection of events to include only those that may affect security or trust.

8

Related Work

Our work has been influenced in many respects by a number of previous authors. The idea of defining a platform as a composition of sub-systems is motivated by Grawrock’s [1] view of a trusted platform as consisting of inter-dependent elements with functional roles within a trusted platform. Our work demonstrates how such a platform can be constructed from these elements and how configuration settings of such elements impact the properties of a trusted platform. The idea of reasoning about security properties of systems has been around for a long time. The 1990 paper on a Logic of Authentication by Burrows, Abadi

64

C. Namiluko and A. Martin

and Needham [18] lead to what is commonly known as BAN logic, which enables the specification and reasoning about beliefs of trustworthy parties involved in an authentication protocol. Several extensions and variations to BAN logic have been proposed [19–21] mainly with the aim of improving on some problems identified in the original logic. However most of the work has been restricted to the specification and analysis of security protocols. Several authors have considered using logic to reason about trusted platforms. Parno [22] demonstrate how predicate logic could be used to formally reason about attacks on a trusted platform. Chen et al [23] similarly use predicate logic to analyse a trusted computing based secure bootstrap process. Our work takes a different approach in that rather than focusing on whether a platform satisfies given predicates, we demonstrate how the platform’s properties are built as a consequence of its construction. Datta et al [24] propose a logic (LS 2 ) for reasoning about secure systems and apply it towards reasoning about properties of some trusted computing primitives. The logic includes a programming language, semantics for the language and a proof system for establishing properties of a program written in LS 2 . In our model, the concept of an event corresponds to an action in LS 2 . However, our approach differs from LS 2 in that we enable different platforms (with different properties), to be instantiated from the same model, rather than having a fixed program. Furthermore, we make use of a well established reasoning framework provided within CSP. This has an advantage of inherently supporting parallelism and enabling reasoning about different aspects of a system. Martinelli and Petrocchi [25] proposed a framework that integrates analysis of security and trust. Using Crypto-CCS and RT family of languages, the framework enables trust and reputation management and security protocol analysis to be performed in a uniform manner.Whereas their framework focuses on the integration aspects, our work is more concerned with reasoning about the properties of a system rather than how its reputation relates to security. The software architecture model (SAM) [26] is a framework provides a dual formalism – petri-nets and temporal logic – for modeling and analysing software architectures. In SAM, a model is represented as a set of elements (components and connectors) that have behaviour, B, and a set of properties, S. The behaviour is captured using predicate transition nets and the properties are specified using temporal logic [26]. The elements are then grouped together to form a composition Ci = {Sij , B ij } which is in turn grouped into a configuration. SAM mainly concentrates on compositionality of components and does not look at how the configuration settings may affect the resulting combination.

9

Conclusion and Future Work

The construction of a trusted platform determines its trust related properties. In order to reason about these properties, we have proposed a model that enables trusted platforms of varying trust levels to be instantiated. The model enables platform instantiation by taking in the specifications of configuration information and application logic. The resulting platforms are then verified by

An Abstract Model of a Trusted Platform

65

refinement checks using one or more semantic models of CSP. We have further demonstrated the applicability of the model on a trusted grid architecture. In future, we intend to explore mechanisms for simplifying the specification of application logic and also to investigate how such a platform would fit into the bigger picture, i.e., how to compose such platforms into a distributed architecture such as a grid or cloud architecture. Acknowledgements. The work described here was supported by the Rhodes Trust and by a grant arising from a gift to the Computing Laboratory by Prof. Sir Tony Hoare. We would like to thank Prof. Bill Roscoe and Prof. Gavin Lowe for insights into this work and the members of the Software and Systems Security Research Group for their valuable feedback.

References 1. Grawrock, D.: Dynamics of a Trusted Platform: A Building Block Approach. Intel Press, Hillsboro (2009) 2. Cooper, A.: Towards a Trusted Grid Architecture. PhD thesis, Oxford University (2008) 3. L¨ ohr, H., Ramasamy, H., Sadeghi, A.R., Schulz, S., Schunter, M., St¨ uble, C.: Enhancing grid security using trusted virtualization (2007) 4. Santos, N., Gummadi, K.P., Rodrigues, R.: Towards trusted cloud computing. In: HOTCLOUD (2009) 5. England, P., Lampson, B., Manferdelli, J., Peinado, M., Willman, B.: A trusted open platform. Computer 36, 55–62 (2003) 6. Cooper, A., Martin, A.: Towards a secure, tamper-proof grid platform. In: CCGRID 2006: Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid, pp. 373–380. IEEE Computer Society, Washington, DC, USA (2006) 7. Challener, D., Yoder, K., Catherman, R., Safford, D., Van Doorn, L.: A practical guide to trusted computing. IBM Press (2007) 8. TCG: Trusted Platform Module (TPM) Specifiation (2008) 9. Sadeghi, A.R., St¨ uble, C.: Property-based attestation for computing platforms: caring about properties, not mechanisms. In: NSPW 2004: Proceedings of the 2004 Workshop on New Security Paradigms, pp. 67–77. ACM, New York (2004) 10. Haldar, V., Chandra, D., Franz, M.: Semantic remote attestation: a virtual machine directed approach to trusted computing. In: VM 2004: Proceedings of the 3rd Conference on Virtual Machine Research and Technology Symposium, p. 3. USENIX Association, Berkeley (2004) 11. Alam, M., Zhang, X., Nauman, M., Ali, T., Seifert, J.P.: Model-based behavioral attestation. In: SACMAT 2008: Proceedings of the 13th ACM Symposium on Access Control Models and Technologies, pp. 175–184. ACM, New York (2008) 12. Hoare, C.A.R.: Communicating sequential processes. Commun. ACM 21(8), 666–677 (1978) 13. Roscoe, A.W.: The Theory and Practice of Concurrency. Prentice Hall PTR, Upper Saddle River (1997) 14. Roscoe, A.W.: Modelling and verifying key-exchange protocols using csp and fdr. In: Proceedings of 1995 IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, Los Alamitos (1995)

66

C. Namiluko and A. Martin

15. Lowe, G.: Casper: a compiler for the analysis of security protocols. J. Comput. Secur. 6(1-2), 53–84 (1998) 16. Brock, N., Jackson, D.: Formal verification of a fault tolerant computer. In: Proceedings of IEEE/AIAA 11th Digital Avionics Systems Conference, 1992, pp. 132–137 (October 1992) 17. Cichocki, T., G´ orski, J.: Failure mode and effect analysis for safety-critical systems with software components. In: Koornneef, F., van der Meulen, M. (eds.) SAFECOMP 2000. LNCS, vol. 1943, pp. 382–394. Springer, Heidelberg (2000), doi:10.1007/3-540-40891-6 33 18. Burrows, M., Abadi, M., Needham, R.: A logic of authentication. ACM Trans. Comput. Syst. 8(1), 18–36 (1990) 19. Gong, L., Needham, R., Yahalom, R.: Reasoning about belief in cryptographic protocols. In: IEEE Symposium on Security and Privacy, p. 234 (1990) 20. Kailar, R., Gligor, V.: On belief evolution in authentication protocols. In: Proceedings of Computer Security Foundations Workshop IV, 1991, pp. 103–116 (June 1991) 21. Sufatrio, Y.R.: xtending ban logic for reasoning with modern pki-based protocols. In: Cao, J., Li, M., Wu, M.-Y., Chen, J. (eds.) NPC 2008. LNCS, vol. 5245, pp. 190–197. Springer, Heidelberg (2008) 22. Parno, B.: Bootstrapping trust in a ”trusted” platform. In: HOTSEC 2008: Proceedings of the 3rd Conference on Hot Topics in Security, pp. 1–6. USENIX Association, Berkeley (2008) 23. Chen, S., Wen, Y., Zhao, H.: Formal analysis of secure bootstrap in trusted computing (2007) 24. Datta, A., Franklin, J., Garg, D., Kaynar, D.: A logic of secure systems and its application to trusted computing. In: SP 2009: Proceedings of the 2009 30th IEEE Symposium on Security and Privacy, pp. 221–236. IEEE Computer Society, Washington, DC, USA (2009) 25. Martinelli, F., Petrocchi, M.: A uniform framework for security and trust modeling and analysis with crypto-ccs. Electronic Notes in Theoretical Computer Science 186, 85–99 (2007); Proceedings of the First Workshop in Information and Computer Security (ICS 2006) 26. Deng, Y., Wang, J., Tsai, J.J.P., Beznosov, K.: An approach for modeling and analysis of security system architectures. IEEE Trans. on Knowl. and Data Eng. 15(5), 1099–1119 (2003)

Modeling TCG-Based Secure Systems with Colored Petri Nets Liang Gu1 , Yao Guo1, , Yanjiang Yang2, Feng Bao2 , and Hong Mei1 1

Key Laboratory of High Confidence Software Technologies (Ministry of Education), Institute of Software, School of EECS, Peking University, China {guliang05,yaoguo,meih}@sei.pku.edu.cn 2 Institute for Infocomm Research, Singapore {yangyj,fengbao}@i2r.a-star.edu.sg

Abstract. With the rapid progresses in trusted computing related research and application, many trusted computing based security mechanisms have been proposed to defend against threats in open, dynamic and distributed environments. These mechanisms are supposed to serve as the security foundations in the underlying systems. However, the correctness of these security mechanisms still require further examination and validation. We propose a Colored Petri Nets (CPN or CP-nets) based approach to model the trusted computing based secure system. In particular, with CPN, we model process management, data protection and late launch mechanisms in the systems. Further, as case studies we use these models to investigate the memory protection mechanism in TrustVisor and remote attestation based on dynamic root of trust, respectively; and the results demonstrate that our models are indeed capable of depicting real secure system based on trusted computing. With the advantages of CPN based modeling and analysis (e.g., graphical representation, well defined semantics and a large number of formal analysis methods), our models can well serve as the foundation for formal analysis on the security properties of trusted computing enhanced systems.

1 Introduction Internet has become a critical infrastructure for information dissemination and sharing in our society. In this open, dynamic and distributed environment, it is, however, difficult to defend against software attacks in systems that span mutually distrust domains. As a countermeasure, Trusted Computing Group (TCG) has proposed a series of specifications on trusted computing [44], in which the computer hardware is extended with a Trusted Platform Module (TPM) [43]. The main idea of trusted computing is as follows: using the TPM as the root of trust, a trust chain can be built from the TPM to the 

This work is supported by the National Basic Research Program of China (973) under Grant No. 2009CB320703, the Science Fund for Creative Research Groups of China under Grant No. 60821003, National Key S & T Special Projects under Grant No. 2009ZX01039-001001 and the National High-Tech Research and Development Plan of China under Grant No.2009AA01Z139, and National Natural Science Foundation of China under Grant No. 60873238. and No. 60903178.  Corresponding author. L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 67–86, 2011. c Springer-Verlag Berlin Heidelberg 2011 

68

L. Gu et al.

final users through the operating system and upper layer applications. Since the introduction of TCG specifications, many TCG-based secure systems1 have been proposed from both the industrial and academical domains, such as the IBM Integrity Measurement Architecture [40], the BitLocker [35] from Microsoft, Terra [13], Flicker [34], TrustVisor [33]. Needless to say, the effectiveness of these secure systems is largely dependent upon the correct usage of the trusted computing related technologies within. Thus, it is crucially important to correctly build Trusted Computing Base with TCG technologies, and guarantee that the trust chain is built up to the applications. However, the theoretical study on trusted computing lags far behind its development. Indeed, for most of the existing trusted computing based secure systems, there still lacks formal verification on the (system) correctness from a theoretical point of view. From the perspective of formal study, we refer to the correctness of a secure system as that it functions according to the expected specifications. In this paper, our particular concerns are security related specifications. Recent formal studies on trusted computing mainly fall into two categories: on TCG specifications and on TCG-based secure systems. For the former (correctness study on TCG specifications), the majority of the existing formal modeling and analysis studies focus on key security mechanisms in the specifications [47,18], besides testing based analysis techniques [38,46]. Usually formal verification [47] and the universally composable (UC) framework [18] are employed to analyze the security properties. For the latter, analysis and verification of the TCG-based security mechanisms mainly rely on testing based methods, and only a few formal studies were proposed [1]. It is thus fair to say that formal verification on TCG-based secure systems still has a long way to go. On the positive side, the recent study of Logic of Secure System [12] based on the Protocol Composition Logic (PCL) [11] demonstrates the possibility of employing formal methods to analyze TCG-based secure systems. In this paper, we propose a formal study on TCG-based secure systems with Colored Petri Nets (CPN)[22,23,24]. In particular, CPN is employed to model and analyze the key security mechanisms in the systems, including process management, data protection and late launch. With the proposed models, we further conduct two case studies: the memory protection mechanism in TrustVisor [33]; and remote attestation based on dynamic root of trust [19,44,3]. The advantages of CPNs make it appropriate for modeling and analyzing TCG-based secure systems. Our CPN based approach has the following benefits: (1) the capability of graphical representation of CPN makes it possible to simulate the key mechanisms in a complex TCG-based system in a graphical way; with the colored token in CPN, it is possible to model complex system states; (2) the well defined semantics of CPN can exactly define the behavior of a target system that is augmented with TCG, and the widely studied CPN provides solutions to check properties of the target system including liveness and safety; (3) with a large number of formal analysis methods and tools that admit CPN, it is possible/convient to model and verify different security properties of a TCG-based system.

1

Without special notice, we will use the terms: secure system, secure system based on trusted computing and TCG-based secure system interchangeably in this paper.

Modeling TCG-Based Secure Systems with Colored Petri Nets

69

2 Preliminaries 2.1 Trusted Computing In the TCG specifications, a trusted platform is supposed to provide features such as secure storage and platform remote attestation. Trusted Platform Module (TPM) is the core and root of trust for a trusted platform. TPM is a tamper resistant, self-contained coprocessor, capable of providing a series of security functions, such as random number generator, key management, digital signature and hash function, etc. TPM contains a group of internal Platform Configuration Registers (PCRs). Equipped with a SHA-1 engine, TPM employs PCRs to provide PCR extend operation on specified machine state data m: P CR Extend(m) : P CRi ← SHA − 1(P CRi ||m). The content of the PCRs represents a integrity measurement of the state of the underlying machine. Remote attestation is a mechanism enabling the platform to attest to a remote entity of its integrity measurement contained in the PCRs. There are two types of trust chain for TCG based secure systems: one is built based on the static root of trust for measurement since the system’s booting up [44]; the other is based on the dynamic root of trust for measurement which is supported by the late launch [19,3]. The late launch can dynamically create a secure execution environment by setting up a secure virtual machine or secure kernel. The late launch mechanism works as follows: after receiving the request of late launch from the system, the CPU executes a privileged instruction (GET SEC[SEN T ER] for Intel, SKIN IT for AMD); the privileged instruction will enable several hardware protection mechanisms, including disabling Direct Memory Access by setting the relevant bits in the system’s Device Exclusion Vector (DEV), disabling the interrupts and debugging access; then the process will execute a specified loader module(Secure Loader Block (SLB) for AMD, Authenticated Module for Intel) at a given address; then the specified loader module will securely measure and load a secure execution environment (Secure Virtual Machine for AMD, Measured Launched Environment for Intel). Late launch allows to set up a secure execution environment without rebooting the system, thus enabling an application to run in a protected environment. 2.2 Colored Petri Nets Colored Petri Nets (CPNs) were introduced as a full-fledged language for the design, specification, simulation, validation and implementation of large software systems. CPNs combine the strength of Petri nets with the strength of programming languages and are widely employed in both academical and industrial areas for software system design, implementation, simulation and validation. CPNs have a series of good features that make it suitable for modeling and analyzing complex systems [22,24]. Below, we will give a brief introduction to CPN. For the definition of multi-set, please refer to [22,24]. For a set A, we use AMS to denote the set of all multi-sets over A, and 0 to denote the empty multi-set. Let A be a set. The power set of A, denoted as P owerSet(A) or 2A , is the set of all subsets of A including the empty set. A Colored Petri Net (CPN) can be represented as a tuple (Σ, P, T, A, N, C, G, E, M0 ), where

70

L. Gu et al.

– Σ is a finite set of color  sets,P , T and  A are finite sets of places,  transitions and arcs, respectively. P T =T A = A P =∅, and A ⊆ P × T T × P . There are two types of arcs for a transition: incoming arc and outgoing arc. When a transition takes place, incoming arcs indicate that the input places shall remove specified number of tokens, while outgoing arcs mean that the output places should add the specified number of tokens. The exact number is determined by the arc expression, defined by the expression function E.  – N is a node function N : A → P × T T × P and it specifies the source and destination of an arc. – C is a color function, and C : P → P owerSet(Σ). C(p) specifies the set of allowed colors for any token of place p. A token element is a pair (p, c), where p∈ P and c ∈ C(p). The set of all toke elements is denoted as T E = {(p, c)|p ∈ P c ∈ C(p)}. – G is a guard function, mapping each transition t to a boolean expression G(t). Let B stand for boolean type, which contains the elements {true, f alse}. Let T ype(v) denote the type of the variable v, and T ype(expr) stands for the type of the expression expr. V ar(expr)denotes the set of variables in expression expr. So ∀t ∈ T : T ype(G(t)) = B T ype(V ar(G(t))) ⊆ Σ. – E is an arc expression function, mapping each arc into an expression with type C(p)MS (multi-set over C(p)),  where p is the place of the given arc. That is ∀a ∈ A : T ype(E(a)) = C(p)MS T ype(V ar(E(a))) ⊆ Σ. – M0 is the initial marking of CPN, and M0 ∈ (T E)MS . In order to describe the behavior of CPN, weuse the following notations for all t ∈ T and  for all node pairs (x1 , x2 ) ∈ P × T T× P : A(t) = {a ∈ A|N (a) ∈ P × {t} {t} × P }; V ar(t) = {v|v ∈ V ar(G(t)) ∃a ∈ A(t) : v ∈ V ar(E(a)); A(x1 , x2 ) = {a ∈ A|N (a) = (x1 , x2 }; E(x1 , x2 ) = a∈A(x1 ,x2 ) E(a). A binding of a transition t is a function b defined  on V ar(t), which satisfies the following conditions: ∀v ∈ V ar(t) : b(v) ∈ T ype(v) G(t) < b >. For variable set V ar(t), b associates each variable v ∈ V ar(t) with an element b(v) ∈ T ype(t), and a binding b is usually expressed in the form < v1 = c1 , v2 = c2 , ..., vn = cn >, where V ar(t) = {v1 , v2 , ..., vn } and c1 , c2 , ..., cn are the data values such that ci ∈ T ype(vi) for 1 ≤ i ≤ n. Expression expr < b > means the value obtained by evaluating the expression expr by substituting the variables in V ar(expr) as their values in b. G(t) < b > means that the binding b satisfies the corresponding guard and its value should be true. The set of all bindings for transition t is denoted as B(t). A binding element is a pair (t, b), where t ∈ T and b ∈ B(t). The set of all binding elements is denoted by BE. A marking is a multi-set over T E and a step is a non-empty and finite multi-set over BE. The sets of all markings and steps are denoted as M and Y. Let M (p) denote the marking of a place p in the marking M . A binding element is enabled in a marking  M iff the following property is satisfied: ∀p ∈ P : (t,b) E(p, t) < b >≤ M (p). When a binding element (t, b) is enabled in the marking M1 , which is denoted by M1 [(t, b) , the transition t may be activated and the marking may be changed from M1 to M2 . We write this change as M1 [(t, b) M2 . When a step Y is enabled in the marking

Modeling TCG-Based Secure Systems with Colored Petri Nets

71

 M :∀p ∈ P : (t,b)∈Y E(p, t) < b >≤ M (p). Similarly, when a step Y is enabled to change the marking from M1 to M2 , then the change is denoted as M1 [Y M2 .

3 Modeling TCG-Based Secure Systems with CPN A TCG-based secure system builds the trust chain from the TPM up to the application layer. As shown in Figure 1, the upper layer applications send requests to the secure system via the interfaces provided by the secure system, and the secure system handles these requests and provides the corresponding security services to the applications, such as TPM based sealed storage, setting up secure execution environment based on late launch. The secure system serving as the security foundation for the upper layer applications, can present itself in various forms, e.g., virtual machine monitor, secure kernel, and operating systems. A formal study on the correctness of the secure system can provide definite confidence on the prescribed security functionalities promised by this foundation. In this section, we will model the mechanisms in TCG-based secure system with CPN. Application Layer Security Service

Security Request

Secure System RAM/DISK

CPU TXT/SVM

TPM

Fig. 1. TCG-based Secure Systems

The security properties of a computer system are mostly reflected by its behaviors, that is how the system behaviors handle specific information and whether they are in compliance with some given specifications. Computer systems usually deal with two types of information from the logical point of view: the data and program code, all of which physically exist in the form of data on specific storage devices; from the physical existence point of view, all data are located in RAM, DISK, CPU registers, TPM registers and other storage units. The operations that may change the states of data on computers are as follows: write, read, system reset, CPU computing. Isolation is the basic method for information protection in systems. For example, the virtual machine monitor isolates different domains and protects the processes running in a domain from attacks from another domain. For data protection, some privileged tags are usually employed to represent its protected states, thus restricting access to the protected data. In the system level, these privileged tags are directly bound with the locations of storage units. The CPN is capable of depicting the behaviors of secure systems and reasoning about their properties. Focusing on the internal mechanisms of TCG-based secure systems, we employ the Constrained by the System Interface Adversary model ( CSI ADVERSARY model) [14] for modeling and analyzing secure systems. All the attacks on the secure system

72

L. Gu et al.

should only be conducted by invoking the interfaces provided by the secure system, and there should be no other approaches for attacking or manipulating the secure system. For example, an attacker who wants to modify some specified information in the secure system, can only operate by invoking the system interfaces. It is also possible to conduct injection, interception and replay attacks on the secure system, and all these attacks are assumed to take place based on the operations on its open APIs. With this adversary model, the security property analysis on the secure system can concentrate on the system behaviors. With CPN, we try to make our model expressive enough to depict the main characteristics of the system, and reason with enough semantic support. Meanwhile, we try to keep the system model at a reasonable level of abstraction without dealing with too much lower level details. With the hierarchy representation capability of CPN, we will first give a high level model and then refine the elements in the model to more fine-grained models. We assume that some basic operations in a system are correct or verified in advance, such as read and write operations in the system, TPM operations like TPM extend, DMA operations etc. However, these lower level operations can still be further studied with CPN or other formal methods. 3.1 Basic Model The formal analysis on the secure system concerns whether the data and process related behaviors in the system are in compliance with the given specifications. The TCGbased secure system can be modeled as a Colored Petri Net: (Σ, P, T , A, N , C, G, E, M0 ). We use colored tokens and places in CPN to denote the states of data and processes in the secure system, and the operations on data and processes can be denoted as transitions in CPN. The place sets denote the major state categories of data and processes, and color sets denote the types of data and processes in these categories. The links from actions to states and states to actions are denoted by arcs. The required states of processes and data for enabling an action, and the states of processes and states after the action finishes can be modeled as an arc expressions. The constraints on system behaviors can be modeled as the guard function on transitions. Data is the most important concept in secure systems, and the target objects of all operations in the system can be considered as data. From the perspective of security objectives, data expression e ∈ Data can be denoted as following types: Data = {N um, K, K −1, Sig{e}, EncK {e}, SymencK {e}, H(e), P rog, Bool, Rec, Loc, N U LL} N um stands for numbers. K and K −1 stand for a public/private key pair, and K −1 is the inverse of key K. Sig{e} is the value of the data e signed by private key K. EncK {e} is the value of date e encrypted with public key K. SymencK {e} is the value of date e encrypted with symmetric key K (in this case, K == K −1 ). H(e) is the hash value of date. P rog stands for program in the form of data. Bool stands for data of boolean type, and Bool = {true, f alse}. REC stands for data of record type, which is used to record the states of objects. For example, the record of a data expression e can be denoted as {H(e), SigAIK −1 {H(e)}}. We use r to denote a record instance. N U LL is a special notation standing for no data.

Modeling TCG-Based Secure Systems with Colored Petri Nets

73

Loc is the storage location of data, which can be denoted by two factors: the location type and the location address. We consider the following types of physical storage location on computer: RAM, Disk, TPM static registers and dynamic registers, CPU registers. We use the following location types LocT ype= {RAM, Disk, T P M.spcr, T P M.dpcr, CP U.reg} to denote the types of the above storage locations. The location address of storage can be denoted by two numbers: LocAddr → N um × N um, where the former is the start address and the latter is the end address: (st, ed). Then we have Loc → LocT ype × LocAddr.  If ∃(st1 , ed1 ), (st2 , ed2 ) : st1 ≤ st2 ed1 ≥ ed2 then we say (st1 , ed1 ) is located in the address of (st2 , ed2 ), which is denoted as (st1 , ed1 ) ⊆ (st2 , ed2 ). We use l to denote a location instance. When a location l1 physicallyexists in the area of another address l2 , we say l1 ⊆ l2 . That is : ∃l1 , l2 : l2 .st ≤ l1 .st l2 .ed ≥ l1 .ed ⇒ l1 ⊆ l2 . Process is an important runtime concept in secure systems, and it is denoted as P roc → P rog×N ext×P arain ×P araout , where N ext : {progi |progi ∈ P rog}, P arain : Data, P araout : Data. In the following discussions, we will use pro to denote a variable or instance of process type, e for a variable or instance of data type, con for a variable or instance of boolean type. system_reset_ request_message app_request_ message HS

HS

data_manage

app_response_ message

process_manage

system_stop

Secure System

System_boot _request

Fig. 2. Overview of the CPN model for a TCG-based Secure System

A higher level of the CPN model of a TCG-based secure system is shown as Figure 2. The secure system commonly deals with the following events: accept and handle the data and process management requests from the upper layer applications; return the service or processing results to requesters; handle the system boot/reboot/shutdown requests. We consider the system boot and reboot as parts of the secure system because they can change the states of data and process in a system. The service requests from the upper layer applications have two types: one is the data protection request which is about security operations on specified data, such as data encryption or decryption, signing data with TPM, lock or unlock specified data area; the other type is the process handling request, such as the request for creating a secure execution environment for the specified program, or for terminating a specific process. These two types of requests are corresponding to the two places in Figure 2: app request message and app response message, respectively.

74

L. Gu et al.

The secure system provides the above services by combining two mechanisms: the data management and the process management. The data manage and process manage transitions in Figure 2 are corresponding to these two mechanisms. The secure system based on trusted computing supports two types of system boot: secure boot and authenticated boot. Secure boot guarantees the system will boot into a secure state, while authenticated boot will record all the boot information to support attestation on the boot process. The system reboot and boot requests are corresponding to the places system boot and system reset. The place system stop stands for the system shutdown. I/O operation is an important factor in real systems. However, in most of the existing studies [34,33], the I/O operations are considered as being untrusted in secure systems. For example, the DMA operations are considered to be unsafe for secure systems. Usually the asynchronous I/O should be disabled in privileged mode of the secure system by disabling all interrupts, and it is in fact the case for existing secure system implementations. When synchronous I/O are involved, the driver of the device should also be considered as part of the secure system, like the drivers for TPM security chip. For simplicity, Figure 2 does not specify the arc expression, as the later sections will further refine these transitions. 3.2 Process Management One of the key mechanisms in secure systems is process management, by which the secure system provides security services to the upper layer applications. From a structural perspective, the secure system usually consists of different programs or modules. From the runtime point of view, most of the existing secure systems are designed to execute in a single thread mode, e.g., Flicker[34] and TrustVisor[33]. In this paper, we also first consider the secure system executing in single thread mode. However, as CPN can naturally reason on the concurrency in systems, we may also discuss some concurrency features of the secure system in the future, and thus reflecting multi-cores for secure systems. We consider the execution of the secure system in two categories: one is the situation when the system is operating on some business logics, like the computational tasks, and the operation does not change the security state of the secure system; The other is when security operations change the security state of the secure system, such as data encryption and decryption, late launch and seal storage, etc. For the first kind of execution states, we record the system state as proc ex. Figure 3 is the CPN model for the process management mechanism in a TCG-based secure system. This model is generated by refining the higher level model in Figure 2. As mentioned above, the place proc ex stands for the executing state of the secure system when no security operations are involved. The tokens in places app rq msg and app rs msg denote the requests and responses between the secure system and upper layer applications. The tokens in place sys rb rq and sys bt rq stand for the requests on system reboot and boot, respectively. The token in place sys st stands for the number of system shutdown. The token in sys st also indirectly reflects the number of system boot, because during the execution of the secure system, the number of system boots is always one more than the number of system shutdowns. The tokens in place rec stand

Modeling TCG-Based Secure Systems with Colored Petri Nets

75

Bool

Num sys_st

sys_rt_rq n+1

n+1

n

Bool

con

n

sys_ter

sys_rt pro

sys_bt_rq

pro con

Prog*Data (pro, e)

app_rq_ msg

(pro, e') app_rs_msg Prog*Data

(pro, e')

latelaunch

(pro, e)

pro

proc_ex Proc

pro'

pro

pro

n'r

pro

data_mg

sys_bt

r

proc_sw r

rec

n'r

Rec n'r

Fig. 3. Process management

for the runtime records of objects in the secure system based on the TPM. Thus we get the place set for the process management mechanism: P1 = {proc ex, app rq msg, app rs msg, sys rb rq, sys bt rq,sys st, rec }. In order to depict the tokens in these places, we introduce the following color sets: C1 = { C1 (sys st) = N um, C1 (sys rt rq) = Bool, C1 (rec) = Rec, C1 (sys bt rq) = Bool, C1 (app rs msg) = P rog × Data, C1 (app rq msg) = P rog × Data, C1 (proc ex) = P roc} In the single-threaded secure system, the following operations can change the security state of the system: process/module switch, system boot, system termination, system reset, late launch, data management. Thus we get the transition set for the CPN model of process management mechanism: T1 ={ sys bt, proc sw, sys ter, sys rb, latelaunch, data mg } The arcs set and arc expression function are shown in the Figure 3. Specially, there is a constraint on the arc expressions between the place proc ex and the transition process switch: E1 (proc ex, proc sw).N ext == E1 (proc sw, proc ex).P rog which means the order constraint of process switch. Tokens in place sys rt rq and place sys bt rq denote the requests corresponding to system reboot and boot respectively, and they are of the type Bool. Only when the value of the token is true, the corresponding transition can be enabled. We use the guard function to express this constraint: G1 (sys rt) = (con == true), G1 (sys bt) = (con == true) When the system reboot request is true or the system boot is true, the corresponding transition should be enabled under any condition. That is :

76

L. Gu et al.

∀(sys bt, b) ∈ BE, ∀M1 ∈ M : (con == f alse) ⇒ M2 ∈ M : M1 [(sys bt, b) M2 ∀(sys rt, b) ∈ BE, ∀M1 ∈ M : (con == f alse) ⇒ M2 ∈ M : M1 [(sys rt, b) M2 which means: in any condition, if a condition con is true and the transitions sys bt and sys rt are enabled, then they must occur, i.e., the boot or reboot action must be allowed. sys bt and sys rt are enabled means that beside the condition is true, the system also requests these actions. The secure system consists of different programs and modules, and it is common that program/module switch happens during the system execution. The CPN model for process management should specially depicts the process switch. The process switch happens in two situations: when a module terminates its execution and starts another module/program; the executing module jumps to another module by invoking instructions like “JMP”. The process switch can only happen when the executing process has at least one next program to execute, and this is denoted as a guard function on transition proc sw: G1 (proc sw) = (pro.N ext = N U LL) Considering the secure system as a single-threaded system, the CPN model in Figure 3 only depicts the process switch while without taking into account the context switch. If the context switch is considered, it is natural to refine the transition proc sw into two parts: with and without context switch. System reboot may change the security state of the secure system. For example, in a remote attestation scenario, after the platform configurations are transferred to the challenger, the system can immediately reset the system to boot into a compromised system. The solution for this reboot is to introduce a boot counter which records the number of system boots. Our CPN model depicts this mechanism with an alternative solution: the sys st place holds the token whose color stands for the number of system shutdowns. The late launch mechanism is responsible for setting up a secure execution environment for given program codes. The data management mechanism is based on the hardware memory protection techniques to manage and protect the access to data. We will model these two transitions in the following subsections. 3.3 Synchronous I/O There are two types of I/O: synchronous and asynchronous. In the designs of existing secure systems, interrupts are usually disabled in privileged mode, thus the asynchronous I/O is not applicable for modeling secure systems. The I/O devices are usually accessed in the synchronous way, such as the TPM security chip. We will take the TPM as an example to depict the synchronous I/O operations in the secure system. Let’s consider the T P M P CR read operation in TPM. When place proc ex has a token pro1 = (program1 , {T P M P CR read}, para1 , para2 ); then after the transition proc sw occurs, the token in proc ex is replaced by pro2 = ( T P M P CR read, {program1 }, para2 , para3 ); when T P M P CR read finishes execution, the transition proc sw occurs again and the token in proc ex is replaced by pro3 = (program1 , {program2 }, para3 , para4 ), where program2 is the next process for program1 .

Modeling TCG-Based Secure Systems with Colored Petri Nets

77

3.4 Data Management Restriction on data access is an important mechanism to guarantee the integrity of program code and data. By modeling the data access control, we may analyze the data protection mechanism in secure systems. Secure systems usually use tags to identify the access privileges on specific data areas, and restrict applications from accessing to these areas. In this subsection, we model the data protection mechanism by refining the transition data mg in Figure 3. Consequently, Figure 4 is the CPN model for data management mechanism in the secure system. Data_Read_RQ (pro,l)

r_rq lock (pro.rq,l) lock_rq Data_Lock_RQ

lock'

(pro,rq,l)

lock lock'

unlock w_rq Data_Write_RQ

(pro,e)

r_rs

lock Proc*Data

Locker

lk

read

lock

unlk lock Locker

write

(pro,con)

w_rs Proc*Data

(pro,l,e)

Fig. 4. Data management

As mentioned in section 3.1, we consider the following storage locations for data LocT ype= {RAM, Disk, T P M.spcr, T P M.dpcr, CP U.reg}. There are two kinds of operations: read and write. We consider two types of access control restrictions on data: read lock and write lock, which restrict the corresponding actions on the target data. Then we have two operations on these restrictions respectively: lock and unlock. So, we have the following color sets to model the data management mechanism: Lock T ype = {r lk, w lk}; Lock OP = {lk, unlk}; Locker = Loc × Lock T ype × P rog; Data Read RQ = P roc × Loc; Data W rite RQ = P roc × Loc × Data; Data Lock RQ = Loc × Lock T ype × Lock OP ; In the following discussions, we use the following variables : rq : Data Lock RQ; l : Loc; lock : Locker, where Loc → LocT ype × LocAddr. We have the place set P2 ={r rq, w rq, lk rq, r rq, w rs, ld, unlk }. Tokens in r rq,w rq and lk rq stand for the corresponding action requests. Tokens in r rs and w rs stand for the results of read and write actions. Tokens in lk, unlk stand for the locked and unlocked states of storage locations. We have the color set: C2 = { C2 (r rw) = Data Read RQ, C2 (w rq) = Data W rite RQ, C2 (lk rq, ) = Data Lock RQ, C2 (r rs) = P roc × Data, C2 (w rs) = P roc × Data, C2 (lk) = Locker,C2 (unlk) = Locker}

78

L. Gu et al.

and the transition set: T2 = {lock, unlock, read, write} The arc set and the arcs expression function are shown in Figure 4. We assume that all the storage locations are unlocked at the initial time of the system, except some privileged locations, such as the boot address of the system, and the TPM dynamic registers. When the place unlk holds all the tokens, it means that all storage locations are unlocked. The data can only be accessed when it is unlocked. We use the guard function on read and write transition to depict the model restrictions as follows: (∃(pro1 × l1 ) ∈ T ype(M (r rq))

 G2 (read) = ∃(l2 × r lk × prog2 ) ∈ T ype(M (unlk) : l1 ⊆ l2 )

(∃(pro1 × l1 ) ∈ T ype(M (w rq))

 G2 (write) = ∃(l2 × r lk × prog2 ) ∈ T ype(M (unlk) : l1 ⊆ l2 )

Only when the target location is unlocked, the system may carry out read or write operation. This property of CPN model for data protection mechanism in secure systems can be expressed as follows: ∀(read, b) ∈ BE, ∀M ∈ M : b(l) ⊆ b(locker).Loc ⇒ M  ∈ M : M [(read, b) M  ∀(write, b) ∈ BE, ∀M ∈ M : b(l) ⊆ b(locker).Loc ⇒ M  ∈ M : M [(write, b) M  It is straightforward to employ the above model to depict security related data operations, e.g., the PCR operations in TPM. These operations can be expressed by the read and write model. For example, the PCR read can directly expressed by the read operation, while the PCR reset operation by privileged instructions can be expressed as write operation on specific registers. 3.5 Late Launch The late launch mechanism can set up a secure execution environment for the given application. We will refine the late launch transition in Figure 3 to model the late launch mechanism. The CPN model of late launch mechanism is shown in Figure 5. When an application requests the secure system to set up a secure execution environment for the given program code, the secure system stores the context and then invokes the privileged CPU instruction to launch the secure environment and records related information; then the given program code executes in the secure environment, and after finishing the execution, it returns the control to the secure system; Then the secure system records related information and then restores the context to resume execution. We have the places set: P3 = {lt lh rq, context, record, lt lh res, app sec exe}

Modeling TCG-Based Secure Systems with Colored Petri Nets

lt_lh_req Proc*Prog

(pro,app) ctx

context Ctx lt_lh_res

SEM_setup n'r

pro

record ctx

(pro,e)

79

Rec n'r

app_sec_exe

pro

Proc

SEM_quit

Proc*Data

Fig. 5. Late Launch

Tokens in place lt lh rq stand for the late launch request from the upper layer applications. Tokens in place lt lh res stand for the state after late launch finishes its execution. Tokens in place app sec exe stand for the execution state of the given program code in secure execution environment. As only one thread is allowed, we may restrict the number of tokens in app sec exe to be no more than 1. We add the following color set to depict the tokens in the late launch model (Ctx stands for Context): Ctx = P rog × N ext; ctx : Ctx; C3 = {C3 (lt lh req) = P roc × P rog, C3 (context) = Ctx, C3 (lt lh res) = P roc × Data, C3 (app sec exe) = P roc, C3 (record) = Rec} The transition set is T3 = {SEM setup, SEM quit}, where SEM setup and SEM quit stand for the set up and quit of secure execution environment. The arcs set and arc expression function are shown as in Figure 5.

4 Case Studies In this section, we will employ the above models to study the memory protection mechanism in TrustVisor [33] and remote attestation based on dynamic root of trust [19,3], respectively. 4.1 Memory Protection in TrustVisor TrustVisor is a special purpose secure hypervisor. It provides fine-grained protection mechanism to guarantee the integrity of program code and data for applications, under the assumption that the operating system may be malicious or tampered. TrustVisor employs the following mechanisms to provide stronger protection with acceptable overhead: hardware based virtualization [20], late launch [19,3], DMA protection [4] , 2D page walking [6] and virtualized TPM [5]. With these mechanisms, TrustVisor stands to setting up a secure execution environment to support the execution of the given program codes P AL specified by the application AP P . In TrustVisor, a system state has three modes: host mode, legacy guest mode and secure guest mode. In host mode, TrustVisor handles the control and it can access any location on the computer; in legacy guest mode, the operating system or the applications are executing, while the TrustVisor and the PAL of the APP are protected; in secure

80

L. Gu et al. Table 1. The protection status of objects in TrustVisor based system

PP PP Object PP Mode P

TrustVisor

host mode executing legacy guest mode protected secure guest mode protected

Untrusted Legacy OS accessible executing protected

APP accessible executing protected

PAL accessible protected executing

guest mode, the PAL is executing in the secure execution environment, and all other parts of the system are protected. The states of objects in TrustVisor for these three modes are shown in Table 1. We use the data management model presented in Section 3.4 to study the memory protection mechanism in TrustVisor. We can map the accessible and protected states to the locked and unlocked states in the model. The involved operations in the process of the system mode change can be considered as actions of lock, unlock, read and write, respectively. With these mappings, we are entitled to model the memory protection mechanism in TrustVisor as a CPN and analyze its properties accordingly. We consider an application app, which sends a request to TrustVisor for setting up a secure execution environment for the given program codes pal. To see whether the memory protection mechanism is designed correctly, the CPN model of the memory protection mechanism can be verified according to the following properties (T V stands for TrustVisor): 1. Host mode: ∀(read, b) ∈ BE, ∀M ∈ M : b(pro).P rog == T V ⇒ ∃M  ∈ M : M [(read, b) M  ∀(write, b) ∈ BE, ∀M ∈ M : b(pro).P rog == T V ⇒ ∃M  ∈ M : M [(write, b) M  2. Legacy guest mode:  ∀(read, b) ∈ BE, rog == OS b(pro).P rog == app   ∀M ∈ M : b(pro).P (b(l) ⊆ T V b(l) ⊆ pal) ⇒ M  ∈ M : M [(read,b) M  ∀(write, b) ∈  BE, ∀M ∈ M : b(pro).P rog == OS b(pro).P rog == app  (b(l) ⊆ T V b(l) ⊆ pal) ⇒ M  ∈ M : M [(write, b) M  3. Secure guest mode:   ∀(read, pal (b(l) ⊆ T V b(l) ⊆  b) ∈ BE, ∀M ∈ M : b(pro).P rog == OS b(l) ⊆ app) ⇒ M ∈ M : M [(read, b) M    ∀(write,  b) ∈ BE, ∀M ∈ M : b(pro).P rog == pal (b(l) ⊆ T V b(l) ⊆ OS b(l) ⊆ app) ⇒ M ∈ M : M [(write, b) M 4.2 Remote Attestation Based on Dynamic Root of Trust Remote attestation is a fundamental issue in trusted computing, and has attracted considerable attention [8,15,16,17,21,36,39,40,41]. In an open and dynamic environment, remote attestation provides a reliable way to establish trust among different platforms in mutually distrusted domains. The dynamic root of trust based remote attestation has been studied in recent years [3,15,19,33,34]. It is important to validate the correctness

Modeling TCG-Based Secure Systems with Colored Petri Nets

81

of these security mechanisms. Next, we will extend our above models to study remote attestation based on dynamic root of trust. A typical dynamic root of trust based remote attestation scenario is as follows: the application app runs on an open platform P , and a challenger CH requests to attest the execution of specific program codes pal. The remote attestation protocol runs as follows: first the challenger CH sends a request with a random nonce non, which is used to eliminate replay attack; when app is going to execute the pal, app will requests the secure system to set up a secure execution environment for the pal with late launch; when the secure system sets up the environment for pal, the states of related information will be recorded, including the environment, the pal and its inputs; then pal executes in the secure environment; after pal finishes its execution, the secure system will record the outputs of pal; the system resumes its execution and sends all records to the CH. The CPN model for remote attestation based on dynamic root of trust is shown in Figure 6. This model is based on the model of late launch in Section 3.5. The newly added elements are P4 = {RA rq, nonce, RA res, known − good record, RA result, exe f inished }, which are remote attestation request, random number, response of remote attestation from challenger, known-good measurements, result of remote attestation, respectively. The newly added transitions T4 = {RA challenge, RA response, verif y} denote remote attestation request from CH, remote attestation response from the target platform, and the verification on the returned records, respectively. 1'((app,app_next,input,output),pal)

lt_lh_rq Proc*Prog

(pro,app)

ctx

context Ctx

1'nonce1

SEM_setup pro'

RA_challenge

ctx

pro'

(pro,e)

SEM_quit

Bool con

nonce Num

non

n'r

record

n'r

RA_response

(pal,non)

Proc*Data

RA_result

Num

non lt_lh_res

RA_req

non

app_sec_exe Proc

non

non

n'(pal,non)

Rec

m'r

m'r

m'r

verify m'r

RA_res Rec

known-good_ record Rec

exe_finished Prog*Num

Fig. 6. Remote attestation based on dynamic root of trust

5 Related Work In this section, we will briefly review the related work in three areas: the TCG-based secure systems, CPN based formal studies (especially in security related applications), formal methods for TCG-based security mechanisms/systems. 5.1 Secure Systems Based on Trusted Computing Since the introduction of TCG specifications in 1999, many secure systems have been built around trusted computing. Terra [13] introduced a TPM based trusted virtual

82

L. Gu et al.

machine architecture geared towards both open and closed domains, thus supporting both legacy systems and security sensitive computations on the same hardware platform. The Integrity Measurement Architecture (IMA) [40] was essentially a TPM based integrity measurement and report mechanism in Linux. OSLO [29] establishes a secure boot mechanism with the assistance of the late launch technique, and Flicker [34] leverages on late launch to set up a secure execution environment for given program codes. With the debug facilities on CPU, [15] presents a fine-grained attestation scheme for legacy binary program at the function level. TrustVisor [33] is implemented as a special purpose security hypervisor with acceptable performance overhead. With the increasing emergence of trusted computing based systems and security mechanisms, formal studies on the design and implementation are essential in guaranteeing the correctness of these security foundations. 5.2 CPN Based Formal Studies Petri Nets have been widely used to model, analyze and validate various security mechanisms and systems, such as the security requirements [2], mandatory access control (MAC) [48,45,49,25], discretional access control (DAC) [31], and role based access control (RBAC) [37]. With the features of Petri Nets and the support of advanced programming languages, Colored Petri Nets is a good tool to model, analyze and validate complex systems [10]. For example, in BETA[32], an object-oriented language supporting distributed program execution, CPN is used to model and analyze the protocol of remote object invocation[26]; Nokia research center has conducted a series of formal studies on mobile computing and network related systems. In security related applications, CPN were also extensively used to study the security properties of systems. For instance, CPN and its tools have been used to study access control models, such as RBAC [37], Chinese Wall policy [48], and UCON [28]. CPN are also utilized to analyze and validate security models, such as the Bell-LaPadula model [31], the Biba model[49]. Shin [42] introduced an extended role based access control mechanism for a trusted operating system: E-RBAC, and conducted a formal study on E-RBAC with CPN. [27] makes use of CPN to model and analyze the Stateful Reference Monitor. It is now a proven fact that CPN is a wieldable tool for modeling and analyzing complex systems (including security related systems). 5.3 Formal Verification on Trusted Computing There exist some formal studies on TCG specifications and TCG based systems. Among many others, below are some examples. Bruschi et al. [7] conducted a formal study on the authorization protocol in TPM, and analyze the vulnerabilities in the protocol by model checking. [38] presented a test based method to verify the compliance between TPM and the TCG specifications. Zhang et al. [47] analyzed the trusted network connect (TNC) protocols within the universally composable (UC) framework. G¨urgens et al. [18] conducted a systematical security analysis of a large part of the TCG specifications with a formal automata model based on asynchronous product automata APA and a finite state verification tool SHVT. Predict logic was used to model and analyze the

Modeling TCG-Based Secure Systems with Colored Petri Nets

83

bootstrapping trust [9]. Based on the Protocol Composition Logic (PCL), Logic of Secure System is employed to analyze the remote attestation schemes based on static root of trust and dynamic root of trust [12]. While some progresses have been made, many of the existing trusted computing based systems and security mechanisms still require further formal study on their correctness, such as the IMA, Flicker, and TrustVisor. As such, the proposal in this paper is dedicated to contribute along this line of work.

6 Conclusion The trusted computing technology by TCG is proposed as a countermeasure to software attacks in an open environment. In practice, a (secure) system built upon the TPM must guarantee correctness. However, existing work still falls short of formal methods that model, analyze, and validate the correctness of TCG based systems. Aimed at contributing along this line of work, in this paper we proposed CPNs to be an appropriate tool, because of its inherent advantages in the formal study of complex systems. In particular, we established CPN models for various mechanisms in a TCG based secure system: process management, data management and late launch. With these models, we further conducted case studies on the memory protection mechanism in TrustVisor and remote attestation based on dynamic root of trust, and the results demonstrate that these models are indeed capable of modeling real secure systems. We stress that our models can serve as the foundation to support further formal analysis on the security properties of TCG-based secure systems. One of the future work is to simulate and analyze the properties of the derived CPN models, with the help of the relevant CPN tools. In addition, we shall further model TrustVisor to study its security properties based on its design. According to the recent progress in system verification [30], we also plan to employ CPNs to conduct formal study on the implementation of secure systems, e.g., Flicker.

References 1. Abadi, M., Wobber, T.: A Logical Account of NGSCB. In: de Frutos-Escrig, D., N´un˜ ez, M. (eds.) FORTE 2004. LNCS, vol. 3235, pp. 1–12. Springer, Heidelberg (2004) 2. Ahmed, T., Tripathi, A.R.: Static verification of security requirements in role based cscw systems. In: The Eighth ACM Symposium on Access Control Models and Technologies (SACMAT), pp. 196–203 (2003) 3. AMD. AMD64 Virtualization Codenamed Pacifica Technology–Secure Virtual Machine Architecture Reference Manual. Technical Report Publication Number 33047, Revision 3.01, AMD (May 2005) 4. AMD. Amd64 architecture programmer’s manual, vol. 2: System programming (2007) 5. Berger, S., Caceres, R., Goldman, K.A., Perez, R., Sailer, R., van Doorn, L.: vTPM: Virtualizing the Trusted Platform Module. In: Proceedings of the 15th USENIX Security Symposium, pp. 305–320. USENIX (August 2006) 6. Bhargava, R., Serebrin, B., Spadini, F., Manne, S.: Accelerating two-dimensional page walks for virtualized systems. In: Proceedings of the 13th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2008), Seattle, WA, USA, pp. 26–35. ACM, New York (March 2008)

84

L. Gu et al.

7. Bruschi, D., Cavallaro, L., Lanzi, A., Monga, M.: Replay attack in TCG specification and solution. In: ACSAC, pp. 127–137. IEEE Computer Society, Los Alamitos (2005) 8. Chen, L., Landfermann, R., L¨ohr, H., Rohe, M., Sadeghi, A.-R., St¨uble, C.: A protocol for property-based attestation. In: STC 2006, pp. 7–16. ACM Press, New York (2006) 9. Chen, S.-Y., Wen, Y., Zhao, H.: Formal analysis of secure bootstrap in trusted computing. In: Xiao, B., Yang, L.T., Ma, J., Muller-Schloer, C., Hua, Y. (eds.) ATC 2007. LNCS, vol. 4610, pp. 352–360. Springer, Heidelberg (2007) 10. CPN group at the Department of Computer Science in University of Aarhus. Examples of Industrial Use of CP-nets (2010), http://www.daimi.au.dk/CPnets/intro/example_indu.html 11. Datta, A., Derek, A., Mitchell, J.C., Roy, A.: Protocol Composition Logic (PCL). Electron. Notes Theor. Comput. Sci. 172, 311–358 (2007) 12. Datta, A., Franklin, J., Garg, D., Kaynar, D.: A logic of secure systems and its application to trusted computing. In: Proceedings of the 2009 30th IEEE Symposium on Security and Privacy, pp. 221–236. IEEE Computer Society, Washington, DC, USA (2009) 13. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: A Virtual MachineBased Platform for Trusted Computing. In: SOSP 2003, Bolton Landing, New York, USA, October 19-22 (2003) 14. Garg, D., Franklin, J., Kaynar, D., Datta, A.: Compositional system security with interfaceconfined adversaries. In: Mathematical Foundations of Programming Semantics (MFPS) Conference (April 6, 2010) 15. Gu, L., Cheng, Y., Ding, X., Deng, R.H., Guo, Y., Shao, W.: Remote attestation on function execution. In: Chen, L., Yung, M. (eds.) INTRUST 2009. LNCS, vol. 6163, pp. 60–72. Springer, Heidelberg (2010) 16. Gu, L., Ding, X., Deng, R.H., Xie, B., Mei, H.: Remote attestation on program execution. In: ACM workshop on Scalable Trusted Computing (STC), held in conjunction with the 15th ACM Conference on Computer and Communications Security (ACM CCS 2008) (2008) 17. Gu, L., Ding, X., Deng, R.H., Xie, B., Mei, H.: Remote platform attestation - the testimony for trust management. In: Yan, Z. (ed.) Trust Modeling and Management in Digital Environments: from Social Concept to System Development. IGI Global (2010), doi:10.4018/978-161520-682-7, ISBN-13: 978-1615206827 18. G¨urgens, S., Rudolph, C., Scheuermann, D., Atts, M., Plaga, R.: Security Evaluation of Scenarios Based on the TCG’s TPM Specification. In: Biskup, J., L´opez, J. (eds.) ESORICS 2007. LNCS, vol. 4734, pp. 438–453. Springer, Heidelberg (2007) 19. Intel Corporation. Intel Trusted Execution Technology — Preliminary Architecture Specification. Technical Report Document Number: 31516803, Intel Corporation (2006) 20. Intel Corporation. Intel Virtualization Technology for Directed I/O Architecture Specification. Technical Report Order Number: D51397-001, Intel Corporation (February 2006) 21. Jaeger, T., Sailer, R., Shankar, U.: PRIMA: policy-reduced integrity measurement architecture. In: SACMAT 2006, pp. 19–28. ACM Press, New York (2006) 22. Jensen, K.: Colored Petri Nets. In: Brauer, W., Reisig, W., Rozenberg, G. (eds.) APN 1986. LNCS, vol. 254, pp. 248–299. Springer, Heidelberg (1987) 23. Jensen, K.: Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use. EATCS Monographs on Theoretical Computer Science, vol. 1. Springer, Heidelberg (1992) 24. Jensen, K.: An Introduction to the Theoretical Aspects of Coloured Petri Nets. In: de Bakker, J.W., de Roever, W.-P., Rozenberg, G. (eds.) REX 1993. LNCS, vol. 803. Springer, Heidelberg (1994) 25. Y. Jiang, C. Lin, H. Yin, and Z. Tan. Security analysis of mandatory access control model. In IEEE International Conference on Systems, Man and Cybernetics, volume vol. 6, page 5013–5018, 2004.

Modeling TCG-Based Secure Systems with Colored Petri Nets

85

26. Jørgensen, J.B., Mortensen, K.H.: Modelling and Analysis of Distributed Program Execution in BETA Using Coloured Petri Nets. In: Billington, J., Reisig, W. (eds.) ICATPN 1996. LNCS, vol. 1091, pp. 249–268. Springer, Heidelberg (1996) 27. Katt, B., Hafner, M., Zhang, X.: Building a stateful reference monitor with Coloured Petri Nets. In: CollaborateCom, pp. 1–10 (2009) 28. Katt, B., Zhang, X., Hafner, M.: Towards a Usage Control Policy Specification with Petri Nets. In: Meersman, R., Dillon, T., Herrero, P. (eds.) OTM 2009. LNCS, vol. 5871, pp. 905–912. Springer, Heidelberg (2009) 29. Kauer, B.: OSLO: improving the security of trusted computing. In: Proceedings of 16th USENIX Security Symposium, pp. 1–9. USENIX Association, Berkeley (2007) 30. Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock, D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish, M., Sewell, T., Tuch, H., Winwood, S.: seL4: Formal verification of an OS kernel. In: Proceedings of the 22nd Symposium on Operating Systems Principles (SOSP 2009), Operating Systems Review (OSR), Big Sky, MT, pp. 207–220. ACM SIGOPS (October 2009) 31. Knorr, K.: Dynamic access control through Petri Net workflows. In: 16th Annual Computer Security Applications Conference (ACSAC), page 159 (2000) 32. Madsen, O.L., Moller-Pedersen, B., Nygaard, K.: Object Oriented Programming in the Beta Programming Language. Addison-Wesley Publishing Company, Reading (1993) 33. McCune, J.M., Li, Y., Qu, N., Zhou, Z., Datta, A., Gligor, V., Perrig, A.: TrustVisor: Efficient TCB Reduction and Attestation. In: IEEE Symposium on Security and Privacy (2010) 34. McCune, J.M., Parno, B.J., Perrig, A., Reiter, M.K., Isozaki, H.: Flicker: an execution infrastructure for TCB minimization. In: 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems, pp. 315–328. ACM, New York (2008), 1352625 35. Microsoft Corporation. BitLocker Drive Encryption: Technical Overview. New (optionally) TPM-based secure boot and filesystem encryption from MS Vista (2006) 36. Poritz, J., Schunter, M., Van Herreweghen, E., Waidner, M.: Property attestation—scalable and privacy-friendly security assessment of peer computers. Technical Report RZ 3548, IBM Research (May 2004) 37. Rakkay, H., Boucheneb, H.: Security analysis of role based access control models using colored petri nets and CPNtools. In: Gavrilova, M.L., Tan, C.J.K., Moreno, E.D. (eds.) Transactions on Computational Science IV. LNCS, vol. 5430, pp. 149–176. Springer, Heidelberg (2009) 38. Sadeghi, A.-R., Selhorst, M., St¨uble, C., Wachsmann, C., Winandy, M.: TCG inside?: a note on TPM specification compliance, pp. 47–56 (2006), 1179487 39. Sadeghi, A.-R., St¨uble, C.: Property-based attestation for computing platforms: caring about properties, not mechanisms. New Security Paradigms (2004) 40. Sailer, R., Zhang, X., Jaeger, T., van Doorn, L.: Design and Implementation of a TCG-based Integrity Measurement Architecture. In: Proceedings of the 13th USENIX Security Symposium, San Diego, CA, USA, August 9-13 (2004) 41. Shi, E., Perrig, A.: Van Doorn, L.: BIND: A Fine-Grained Attestation Service for Secure Distributed Systems. In: 2005 IEEE Symposium on Security and Privacy, S&P 2005 (2005) 42. Shin, W.: An extension of role based access control for trusted operating systems and its coloured petri net model, PhD thesis. Gwangju Institute of Science and Technology, Korea (2005), http://itslab.csce.kyushu-u.ac.jp/ssr/SSR-1/thesis-main.pdf 43. Trusted Computing Group. TPM main specification. Main Specification Version 1.2 rev. 85, Trusted Computing Group (February 2005) 44. Trusted Computing Group. TCG Specification Architecture Overview (Revision 1.4) (2007)

86

L. Gu et al.

45. Varadharajan, V.: Hook-up property for information flow secure nets. In: Computer Security Foundations Workshop IV, pp. 154–175 (1991) 46. Zhan, J., Zhang, H., Zou, B., Li, X.: Research on automated testing of the trusted platform model. In: ICYCS, pp. 2335–2339. IEEE Computer Society, Los Alamitos (2008) 47. Zhang, J., Ma, J., Moon, S.: Universally composable secure tnc model and eap-tnc protocol in if-t. Science China Information Sciences 53(3), 465–482 (2010) 48. Zhang, Z., Hong, F., Liao, J.: Modeling Chinese Wall Policy Using Colored Petri Nets. In: CIT 2006: Proceedings of the Sixth IEEE International Conference on Computer and Information Technology, p. 162. IEEE Computer Society, Washington, DC, USA (2006) 49. Zhang, Z., Hong, F., Liao, J.-G.: Verification of strict integrity policy via petri nets. In: The International Conference on Systems and Networks Communication (ICSNC), p. 23 (2006)

Information Flow Graph: An Approach to Identifying Covert Storage Channels Xiangmei Song, Shiguang Ju, Changda Wang, and Conghua Zhou Jiangsu University, Zhenjiang, 212013, China [email protected]

Abstract. The paper introduces a technique for detecting covert storage channels using a graph structure called an Information Flow Graph (IFG). The IFG can offer the information flows of the system for covert channel detection. By searching for the paths of an IFG, operation sequences can be gained, which will enhances the analyst’s understanding of the channels. To illustrate the technique, an example system is analyzed and the result is compared to two analysis approaches, the Shared Resources Matrix and the Covert Flow Trees. Keywords: multilevel security, covert channels, covert flow trees, shared resource matrix, information flow.

1

Introduction

Multilevel secure computer systems are used to protect hierarchic information by enforcing both mandatory and discretionary access controls. They can restrict the flow of information through legitimate communication channel [1] However, covert channels are usually beyond the scope of the security model. Covert channels usually signal information through system facilities not intended for data transfer. That is, the sending process alters some system attributes, and the receiving process monitors the alteration [2]. In order to decrease the threat of covert channels, several covert channel analysis techniques have been proposed and utilized in the past thirty years. Among these techniques are the Shared Resource Matrix methodology (SRM) [3], the Non-interference approach [4], the Information Flow analysis [5], the Covert Flow Trees methodology (CFT) [6], the Backward Tracking approach [7], and others. The SRM method is one of the most successful approaches for covert channel identification. The method starts from identifing shared resources. A shared resource is any object or collection of objects that may be referenced or modified by more than one subject. All identified shared resources are enumerated by a matrix structure, and then each resource is carefully examined to determine whether it can be used to transfer information from one subject to another covertly. The usage of the matrix structure makes the SRM method simple and intuitive. However, the shared resources matrix is helpless when constructing covert communication scenarios, and amount of analysis work by hand is enormous. Lots of research work to improve the SRM method has been done. The CFT method is virtually a transformation of the SRM method. Furthermore, McHugh [8] made three extensions to the matrix structure, and Shen and Qing [9,10] L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 87–97, 2011. © Springer-Verlag Berlin Heidelberg 2011

88

X. Song et al.

optimized the SRM method. The CFT method uses a tree structure instead of the shared resources matrix. Due to its tree structure, the CFT method is capable of recording flow paths and helpful to construct covert communication scenarios. But the covert flow trees usually are huge, and the construction of the trees could fall into infinite loop. To resolve the problem, a constraint parameter named REPEAT has to be introduced, which may lead to lose some potential covert channels. This paper presents a graph data structure that models the information flow from one system attribute to another. This data structure is referred to as an Information Flow Graph (IFG). The process for constructing an IFG is easy, and IFG can include almost information flows in a system. By searching for information flow paths, operation sequences can be offered that will help the analysis work for detecting covert channels. To demonstrate this technique, an example file system is analyzed. The result is compared to other covert channel analysis techniques.

2 2.1

The Information Flow Graph Approach Graph Notation and Semantics

The Information Flow Graph is a direct graph. Fig.1 shows the nodes that are used in the construction of IFG. SAR and SAO are subsets of SA, which is the collection of all shared attributes in the systems. Specially, SAO contains only one shared attribute, and v ∈ SA. op belongs to OP, which is the collection of all primitive operations in the system. The node in Fig.1 (a) is used to present a triple <SAR, op, v>, which describes the relation between operations and shared attributes. The triple means that during the execution of the operation op the shared attribute v is modified by op which references the shared attributes in SAR. In order to present that one attribute’s value can be returned by an operation as a function value, a specified attribute named output has been added to SA. Therefore, the triple <SAO, op, output> in Fig.1(b) means that the shared attribute in SAO is returned by the operation op. Fig.1(c) shows a special node named as the finish node which appears only once in an IFG and is only connected with such node as <SAO, op, output>. In the IFG, if one node is connected to another node except for the finish node by an oriented edge, such in as Fig.2, then v1 ∈ SARj means that the v1 attribute is modified by opi and then referenced by opj. The edge connecting the two nodes describes the dependency relationship between the operation opi and opj. A node like <SAO, op, output> must be connected to the finish node, which means the value of the attribute in SAO is returned by op, shown in Fig.3. In covert storage channels, there are two possible methods for recognizing the modification of an attribute [6], the direct recognition and inferred recognition. Correspondingly, Fig.3 shows the direct recognition that the receiver executes op that returns the attribute’ value. Fig.2 shows the inferred recognition that the receiver performs one operation to modify a shared attribute based on the value of other shared attribute, which is modified by another operation. Thus, every path in the IFG describes an information flow path from attribute to attribute in the systems.

Information Flow Graph: An Approach to Identifying Covert Storage Channels

89

Fig. 1. Nodes used in the Information Flow Graph

Fig. 2. Inferred recognition

2.2

Fig. 3. Direct recognition

Constructing An Information Flow Graph

The information for constructing an IFG can be the same as that used to constructing a Covert Flow Tree. Fig.4 illustrates an example IFG. The operation lists used to build this example is just the same one used in [6], defined as follows in Table 1.

Fig. 4. Example IFG representing information flows Table 1. Example operation lists Operation 1

Operation 2

Operation 3

Operation 4

Reference List:

Reference List:

Reference List:

Reference List:

D

A

B

A

Modify List:

Modify List:

Modify List:

Modify List:

A, B

B

Null

B, C

Return List:

Return List:

Return List:

Return List:

Null

Null

B

A

Attributes: A, B, C, D

Constructing an IFG has two main steps. The first step is to construct nodes. For each operation opi (1 ≤ i ≤ n, n is the number of the primitive operations in a system ) , Suppose SARi is the collection of all attributes in the operation opi’s Reference Lists, SAMi is the collection of all attributes in the operation opi’s Modified Lists, and SAOi is the collection of all attributes in the operation opi’s Return Lists. For ∀ vij ∈ SAMi (1 ≤ j ≤ mi, mi is the number of the attributes that are modified by opi), generate the triple <SARi,opi,vij>; and for ∀ vik ∈ SAOi (1 ≤ k ≤ oi, oi is the number of the attributes

90

X. Song et al.

whose values are returned by opi), generate triple <{vik},opi,output>. The two parts of products are just the triples used to construct nodes. For example, in Fig.4, for the operation op4, three nodes marked with gray color have been constructed according to the method above. For op4, SAR4 is {A}, SAM4 is {B,C}, then the triples are <{A},op4,B>and <{A},op4,C>; and SAO4is {A}, so <{A},op4,output> is constructed. Next, generate oriented edges among the nodes. First, for operation opi and opj (1 ≤ i, j ≤ n), if there is an attribute v that is modified by opi and referenced or returned by opj, then opj is dependent on opi in connection with v. In other words, for every two inequality operation, such as opi and opj, if having constructed the nodes <SARi,opi,v> and <SARj,opj,sm> in the first step, where v ∈ SARj , then an oriented edge should be generated from the former node to the latter one. Besides, for the node < {vik},opi,output>, it should be connected to the finish node. For example, in Fig.4, the edge from < {D},op1,A> to <{A},op4,output> is generated because the attribute A is modified by op1 and referenced by op4. And as the value of A is returned by op4, the node < {A},op4,output> is connected to the finish node. 2.3

Pruning the Information Flow Graph

When an IFG has been constructed, the IFG can be pruned before the analysis. The pruning work is a two-step process. First, remove the node that has indegrees but no outdegree, except for the finish node and the edges connected to it. Because only those paths that end with the finish node in the IFG may be potential covert storage channels. Second, identify and remove the starting nodes of the IFG provided that the paths started with those nodes cannot occur in practice. In a system, such pairs of operations often exist that one operation, named post-executed operation, must be executed consecutively after the execution of the other operation, named pre-executed operation, and the consecutive executions of the two operations can nullify each other’s effects, such as Lock_File and Unlock_File1. Almost no operation sequences are started with post-executed operations under the running circumstance. When analyzing the primitive operations of a system, such pairs of consecutive operations should be identified. And in this step, if a starting node presents a post-executed operation, then remove the node and the edges emitted from it. The two steps above should be done cyclically until there are no such nodes in the IFG. 2.4

Searching for Information Flow Paths

After an IFG has been pruned, the next task is to search for the information flow paths and get the operation sequences. An IFG includes all information flow paths in the system, but not all of them are covert storage channels. According to the minimum criteria that a covert storage channel must be satisfied [3], the value of the attribute used in a covert storage channel must be returned or output by the operation executed by the receiver. Therefore, only those paths that end with the finish node in the IFG may be potential covert storage channels. So, the problem of searching for the information flow paths in order to find out covert storage channels can be converted to seek for all paths to the finish node in the IFG. 1

The operation Lock_File and Unlock_File come from a file system used in [3], which is referred to following.

Information Flow Graph: An Approach to Identifying Covert Storage Channels

91

The search method for information flow paths in IFG consists of the following steps: Firstly, get the converse digraph of an IFG, named IFG-1. In IFG-1, the finish node is the only node without indegrees. Secondly, use the deep first search method to find out all the paths which are begin with the finish node in IFG-1. In order to avoid endlessly cycles while searching, one directed edge must appear only once in a path. Finally, convert the edges’ direction in paths. Fig.5 provides a serial of information flow paths generated from the IFG in Fig.4.

Fig. 5. Information flow paths generated from Fig.4

Fig.5 excludes the path from <{D},op1,A> to <{A},op4,C> because the ending node is not the finish node. The value of the attribute C cannot be returned or output, so it is useless for covert storage channels. The operation sequences can be gained from Fig.5. For example, in Fig.5 (a), the path illustrates that the sender can execute the operation op1to modify the attribute A, while the receiver can perform op4 to return A. Therefore, the path may be exploited as a covert storage channel through the attribute A. Table 2 provides a list of the operation sequences generated from the IFG in Fig.5. Table 2. Operation sequences generated from Fig.5 Sender performs: Operation 1

Receiver performs: (a) (attribute A, operation 4) (b) (attribute A, operation 4), (attribute B, operation 3) (c) (attribute A, operation 2), (attribute B, operation 3) (d) (attribute B, operation 3)

The operation sequences except for (d) shown in Table 2 are correspondent with those listed in [6] which only enumerates covert storage channels via attribute A. Using the method mentioned here, all information flow paths and covert storage channels can be included in one and only IFG. 2.5

Analyzing Operation Sequences

The next is to analyze the operation sequences. The analysis work is similar to the Covert Flow Trees approach. First, reduce or expand each operation sequence and

92

X. Song et al.

remove the redundant sequences. Second, identify and remove those operation sequences which require the sender and receiver to have privileges that would allow them to communicate legally. Finally, develop covert communication scenarios form the remaining operation sequences. More detail is in [6].

3

Example Analyses Using Information Flow Graph

This section presents the results from an example covert channel analyses using the IFG approach described in Section 2. A brief description of the example system is included, which is taken from [6], in order to provide an overview of the basic functions of the primitive operations and attributes. For more detailed descriptions of the system the reader is referred to [3], the paper from which the specification was taken. The operation description lists used in the construction of the IFG are also taken from [6], because the information used to construct the CFT and the IFG is just the same. 3.1

A Brief Description of the File System Example

The attributes of the system includes six file attributes, three process attributes, and one attribute associated with the global state of the system: Current_Process. Current_Process contains the ID of the process currently running on the CPU. The file attributes of the system are File_ID, Locked, Locked_By, Value, Security_Class, and In_Use. The three process attributes are Process_ID, access_Rights and Buffer. The operations are discussed in more detail in the following paragraphs. The Write_File operation is used by a process to change the contents of a file. The file is locked by the current process. The value of the file is modified to contain the contents of the current process's buffer. The Read_File operation is used by a process to interrogate the contents of file. If the current process is included in the in-use set for the file specified, the value of the file is copied to the current process's buffer. The Lock_File operation is used by a process to modify the contents of an articular file. A process must lock a file before modifying it and must unlock the file after the modification is complete. If the current process has write access for the specified file, if the file specified is unlocked, and if its in-use set is empty, then the file is locked, and its locked by attribute is set to the id of the current process. The Unlock_File operation makes a file accessible when a process is done modifying its contents. If the specified file's locked by attribute is the current process, the file is unlocked. The Open_File operation is used by a process to initiate retrieval of the contents of a file. This primitive guarantees that no other process is modifying the contents of the file being interrogated. If the current process has read access or the specified file and the file is not locked, the current process's id is added to the in-use set for this file. The Close_File operation is used when a process has completed interrogation of a file and wants to release it so that it can be modified. If the current process's id is an element of the in-use set for the specified file, then it is removed from that set. The File_Locked operation is used by a process to determine whether a file locked. If the current process has write access for the specified file, then, if the file is locked, a value of true is returned. If the file is unlocked the value false is returned. If the current process lacks write access for the specified file, the result is undefined.

Information Flow Graph: An Approach to Identifying Covert Storage Channels

93

The File_Opened operation is used by a process to determine whether a file is open for reading. If the current process has write access for the specified file, then, if the file's in-use set is nonempty, a value of true is returned. If it is empty the value false is returned. If the current process does not have write access for the specified file, the result is undefined. The View_Buf operation is introduced to explicitly state how a process is allowed to view its buffer attribute. The lists constructed from the operation descriptions are as in Table 3. Table 3. File system operation description lists Operation Write_File Read_File View_Buf Lock_File

Reference List Buffer, Current_Process, Locked_By, Locked Value, current_Process, In_Use Buffer Current_Process, Access_Rights, Locked, In_Use, Security_Class Unlock_File Locked, Locked_By, Current_Process Open_File Current_Process, Access_Rights, Security_Class, Locked, Close_File Current_Process, In_Use File_Opened Access_Rights, Security_Class, In_Use File_Locked Access_Rights, Security_Class, Locked

3.2

Modify List Value Buffer Null Locked, Locked_By Locked In_Use

Return List Null Null Buffer Null Null Null

In_Use Null Null

Null In_Use Locked

Example Information Flow Graph and Scenario List for File System Example

Fig.6 is the IFG constructed for the file system example. To make the analysis easier, two nodes marked with dark grey color is considered firstly.

Fig. 6. Example IFG representing the information flows

The triple <{Current_Process, In_Use}, Close_File, In_Use> describes the information flows by executing the operation Close_File. The node <{Current_Process, Access_Rights, Security_Class, Locked}, Open_File, In_Use> is the only one that connects to the marked node, which describes the information flows by executing the operation Open_File, shown in Fig.6. While Open_File and Close_

94

X. Song et al.

A_R: Acess_Rights; C_P: Current_Process; S_C: Security_Class; I_U: In_Use; L_B: Locked_By; L: Locked; V: Value; B: Buffer;W_F: Write_File; R_F: Read_File; V_B: View_Buf; L_F: Lock_File; U_F: Unlock_File; O_F: Open_File; C_F: Close_File; F_O: File_Opened; F_L: File_Locked

Fig. 7. Information flow paths generated from the pruned IFG

file are the pair of consecutive operations, they can nullify each other’s effects when existing in an operation sequence. Therefore they can be reduced from the operation sequence. And in the IFG, the dotted edge from <{Current_Process, Access_Rights, Security_Class, Locked}, Open_File, In_Use> to <{Current_Process, In_Use}, Close_File, In_Use> should be deleted . This results in the node <{Current_Process, In_Use}, Close_File, In_Use> has no indegree. Because Close_File is post-executed operation, the node <{Current_Process, In_Use}, Close_File, In_Use> and edges from it can also be deleted in the IFG. Similarly, the Lock_File and Unlock_File are the pair of consecutive operations. But they can nullify each other’s effects only on the Locked attribute. So the dotted edge from <{Current_Process, Access_Rights, Security_Class, Locked, In_Use}, Locked_File, Locked> to <{Current_Process, Locked, Locked_By}, Unlock_File, Locked> should be deleted, however the edge from <{Current_Process, Access_Rights, Security_Class, Locked, In_Use}, Locked_File, Locked_By> to <{Current_Process, Locked, Locked_By}, Unlock_File, Locked> should not be deleted. After doing this, the analysis work can begin. Fig.7 shows the information flow path generated from the pruned IFG. Each of information flow paths shown in Fig.7 presents a possible longest operation sequence in the file system. Every operation in the sequence except for the value-return operation may be executed by the sender who wants to communicate covertly with the receiver. Of the information flow paths in Fig.7, six distinct covert communication scenarios were identified. All of the covert scenarios assume the existence of an unopened and unlocked file Foo, such as in [6]. It is also assumed that the sender’s security level dominates that of the receiver’s. The covert communication scenarios and the information flow paths correspondingly are as follows:

Information Flow Graph: An Approach to Identifying Covert Storage Channels

Scenario A Sender Receive

To Signal 0 Lock_File(Foo) File_Locked(Foo)

95

To Signal 1 File_Locked(Foo)

Corresponding path: <{C_P,A_R,S_C,L,I_U},L_F,L> → <{L},F_L,output> To Signal 0 To Signal 1 Scenario B Sender Lock_File(Foo) Lock_File(Foo) Receiver Lock_File(Foo) Lock_File(Foo) Sender Unlock_File(Foo) Receiver File_Locked(Foo) File_Locked(Foo) Corresponding path: {C_P,A_R,S_C,L,I_U},L_F,L> → <{C_P,A_R,S_C,L,I_U},L_F,L_B> → <{C_P,L_B},U_F,L> → <{L},F_L,output> To Signal 0 To Signal 1 Scenario C Sender Open_File(Foo) Receiver Lock_File(Foo) Lock_File(Foo) Receiver File_Locked(Foo) File_Locked(Foo) Corresponding path: <{C_P,A_R,S_C,L},O_F,I_U> → <{C_P,S_C,I_U},L_F,L> → <{L},F_L,output> To Signal 0 To Signal 1 Scenario D Sender Open_File(Foo) Receiver Lock_File(Foo) Lock_File(Foo) Receiver Open_File(Foo) Open_File(Foo) Receiver Read_File(Foo) Read_File(Foo) Receiver View_Buf() View_Buf() Corresponding path: <{C_P,A_R,S_C,L,},O_F,I_U> → <{C_P,A_R,S_C,L,I_U},L_F,L> → <{C_P,A_R,S_C,L,},O_F,I_U> → <{C_P,VI_U},R_F,B> → <{B},V_B,output> To Signal 0 To Signal 1 Scenario E Sender Open_File(Foo) Receiver Lock_File(Foo) Lock_File(Foo) Receiver Write_File(Foo) Write_File(Foo) Receiver Unlock_File(Foo) Unlock_File(Foo) Receiver Open_File(Foo) Open_File(Foo) Receiver Read_File(Foo) Read_File(Foo) Receiver View_Buf() View_Buf() Corresponding path: <{C_P,A_R,S_C,L,},O_F,I_U> → <{C_P,A_R,S_C,L,I_U},L_F,L> → <{C_P,B,L,L_B},W_F,V> → <{C_P,VI_U},R_F,B> → <{B},V_B,output> and <{C_P,A_R,S_C,L,},O_F,I_U> → <{C_P,A_R,S_C,L,I_U},L_F,L_B> → <{C_P,B,L,L_B},W_F,V> → <{C_P,VI_U},R_F,B> → <{B},V_B,output> To Signal 0 To Signal 1 Scenario F Sender Open_File(Foo) Receive File_Opened(Foo) File_Opened(Foo) Corresponding path: <{C_P,A_R,S_C,L,},O_F,I_U> → <{I_U},F_O,output>

3.3

Comparison of IFG, CFT and SRM Analyses for the File System Example

This section identified those operation sequences found to support covert communication by the IFG analysis and compares the results to the Covert Flow Tree and the Shared Resource Matrix analysis.

96

X. Song et al.

The SRM channels are classified by the attribute that is modified by the sender and the first operation used to pass information about the attribute to the receiver or to another attribute [6], while the CFT and the IFG scenarios include the entire sequence of operations that is used to pass the information. Table 4 gives the comparative result. Table 4 shows that the IFG approach can find out all the covert storage channels that the SRM and CFT approach have identified. The detail of the covert communication scenarios is referred to [6]. Table 4. Correspondence between channel analysis techniques for the file system example SRM CFT Cover channel using File_Locked to Covert scenario A sense changes in Locked Covert channel using Lock_File to Covert scenario B sense changes in Locked Covert channel using Lock_File to Covert scenario C sense changes in In_Use Covert scenario D Covert scenario E Covert channel using File_Opened to Covert scenario F sense changes in In_Use

4

IFG Covert scenario A Covert scenario B Covert scenario C Covert scenario D Covert scenario E Covert scenario F

Comparison among SRM, CFT and IFG

The Shared Resource Matrix approach works well since it has been introduced. The major problem may be that it cannot afford the operation sequences which can help the analysis of covert channels. In contrast, the CFT approach, which can present the operation sequences by a tree structure. Compared with CFT, the IFG may have two advantages as follows: (1) The IFG can provide almost complete information flows of a system in one graph, while the CFT has to construct trees for every shared attribute that would be modified by operations. Usually the size of the tree structure is quite large. For example, the CFT representing the information flow via attribute In_Use for the file system example used 136 nodes. The IFG in Fig.6 only uses 11 nodes for all attributes that can be exploited for covert communication. (2) The CFT construction algorithm dependents on a parameter, called REPEAT, which is used to control the constructing CFT with infinite tree paths. The parameter defines the number of times any attribute may be repeated in an inference path, thus providing the analyst with a way to avoid cpu or memory exhaustion by controlling the depth of the CFT paths. But unsuitable value of REPEAT may result in missing covert channels. For example, when REPEAT set to 0, scenario D and E would not be discovered. While the IFG avoids this problem. Notwithstanding these advantages, IFG encounters problems similar to the CFT approach. In the IFG, pseudo communication paths still exist. One way to reduce pseudo communication paths is to consider a finer relationship between the referenced and modified attributes and to consider conditional modifies and references, on which our research group and others are working.

Information Flow Graph: An Approach to Identifying Covert Storage Channels

5

97

Conclusion and Future Work

This paper introduces a technique for detecting covert storage channels. The approach uses a graph structure, called an Information Flow Graph, in which can present the information flow paths and operation sequences. A method for constructing IFG is presented. To illustrate the IFG approach, one example file system is analyzed and the result is compared to previous channel analysis of the same system using the SRM and the CFT approach. In future work, other example system will be analyzed by the IFG approach. The emphasis will be put on research how to discover timing channels using the IFG and on automated tool for the construction of the IFG. Acknowledgements. This work was supported by the National Natural Science Foundation of China (Grant Nos. 60773049, 61003288), the Ph.D. Programs Foundation of Ministry of Education of China (Grant Nos. 20093227110005), the Natural Science Foundation of Jiangsu Province (Grant Nos. BK2010192), the People with Ability Foundation of Jiangsu University(Grant Nos.07JDG014), the Fundamental Research Project of the Natural Science in Colleges of Jiangsu Province (Grant Nos. 08KJD520015).

References 1. Bell, D.E., LaPadula, L.J.: Secure Computer Systems: Unified Exposition and Multics Interpretation. Mitre Crop., Bedford, MA, Tech. Rep. ESD_TR_75_306 (1975) 2. Kemmerer, R.A., Porras, P.A.: Covert Flow Trees: a Visual Approach to Analyzing Covert Storage Channels. IEEE Transactions on Software Engineering 17(11), 1166–1185 (1991) 3. Kemmerer, R.A.: Shared Resource Matrix Methodology: an Approach to Identifying Storage and Timing Channels. ACM Transactions on Computer Systems 1(3), 256–277 (1983) 4. Goguen, J., Meseguer, J.: Security Policies and Security Models. In: Proc. 1982 Symposium on Security and Privacy, pp. 11–20. IEEE Press, New York (1982) 5. Denning, D.E.: A Lattice Model of Secure Information Flow. Communications of the ACM 19(5), 236–243 (1976) 6. Porras, P.A., Kemmerer, R.A.: Covert Flow Tree Analysis Approach to Covert Storage Channel Identification. Comput. Sci. Dept., Univ. California. Santa Barbara, Tech. Rep. No. TRCS 90-26 (December 1990) 7. Qing, S.H., Zhu, J.F.: Covet Channel Analysis on ANSHENG Secure Operating System. Journal of Software 15(9), 1385–1392 (2004) 8. McHugh, J.: Handbook for the Computer Security Certification of Trusted Systems - Covert Channel Analysis. Technical Report, Naval Research Laboratory (February 1996) 9. Shen, J., Qing, S., Shen, Q., Li, L.: Covert Channel Identification Founded on Information Flow Analysis. In: Hao, Y., Liu, J., Wang, Y.-P., Cheung, Y.-m., Yin, H., Jiao, L., Ma, J., Jiao, Y.-C. (eds.) CIS 2005. LNCS (LNAI), vol. 3802, pp. 381–387. Springer, Heidelberg (2005) 10. Shen, J.J., Qing, S.H., Shen, Q.N., Li, L.P.: Optimization of covert channel identification. In: Proceeding of the Third IEEE International Security in Storage Workshop (SISW 2005), p. 13 (December 2005)

Trusted Subjects Configuration Based on TE Model in MLS Systems Shangjie Li1,2 and Yeping He1 1

National Engineering Research Center for Fundamental Software, Institute of Software, The Chinese Academy of Sciences, Beijing 100190, China 2 Graduate School, The Chinese Academy of Sciences, Beijing 100049, China {shangjie,yeping}@nfs.iscas.ac.cn

Abstract. Trusted subjects are inevitably parts of multi-level security systems or trusted networks. They can introduce security risk into system, as they don’t comply with *-property in Bell LaPadula model. It’s an important work to determine which subjects are trusted from hundreds and thousands of applications, and what their security requirements are during the developing and deploying secure operating systems. In this paper, an approach is proposed to address these issues based on information flow and risk analysis. Type enforcement specification is used as a base for information flow analysis and then finding out trusted subjects and their security requirements:security label range and security assurance level. Keywords: Secure Operating System, Trusted Subject, Risk-based Access Control, Risk assessment.

1

Introduction

Trusted subjects are indispensable parts of an secure operating system with MLS support[6][14][10]. To this day, almost all operating systems with MLS functionality are developed according to Bell-Lapadula model(BLP)[5] . If a system is implemented with respect to rigid BLP model[5][6], only one-way information flows are allowed. Bell[2] defined trusted subjects as those who can violate *-property which is the key property of BLP model. Further more, he also gave one important requirement for trusted subject:regardless of it’s violating *-property of BLP security model, there doesn’t exist information disclosure caused by the trusted subject. Therefore, trusted subjects are treated as important parts of secure operating system TCB. To accommodate trusted subjects in a secure operating system, it must assure that they are trustworthy enough not to disclose sensitive information. One simple method is that trusted subjects are developed with same security 

Supported by the National Natural Science Foundation of China(No. 90818012), the Knowledge Innovation Program of the Chinese Academy of Sciences(No. KGCXZYW-125) and the National Program for Core Electronics, Advanced Chips and Fundamental Software(2009ZX01039-002-001).

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 98–107, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Trusted Subjects Configuration Based on TE Model in MLS Systems

99

requirements as that of reference monitor of secure operating system. However, it will take too much time and money, as the number of trusted subjects is very enormous and the complexity of some trusted subjects may exceed reference monitor. It’s attractive to reuse some existing trusted subjects or to develop some low class trusted subjects under certain framework without decreasing overall security of operating system. As these trusted subjects are not trustworthy as reference monitor and have different assurance, they are called partially trusted subjects in some lectures[12][9]. When subjects with different trustworthiness coexist in a secure operating system, new challenges are introduced to various stages of secure operating system lifecycle. During the stage of design and development, one work is to find out which subjects are trusted and what their secure requirements are, in order for choosing correct development methodology. During stage of deployment, secure administrators must assess the configurations of trusted subjects to assure that the overall security risk of the secure operating system is acceptable. During the stage of operation, remote party may need to know whether the TCB including trusted subjects has achieved specified assurance requirements. However, it’s a tedious and error-prone work to determine which subjects are trusted from hundreds and thousands of applications, and what their security requirements are during the development of secure operating systems. It not only requires that developers acquaint with application functions, but also there exists intricate interactions among applications. At the time of the deployment of secure operating systems, determining the secure parameters(security label range) of trusted subject is another challenge, as misconfiguration will cause unpredictable risk. For example, cascade vulnerability problem is caused by misconfiguring some trusted subjects with low trustworthiness. In this paper, we address issues above by information flow analysis and risk analysis. We adopt type enforcement model as a tool to confine the privilege of trusted subjects. As a result, trusted subjects with different trustworthiness can coexist with each other, while the security of the entire secure operating system doesn’t decrease. In addition, an approach based on type enforcement security specifications is proposed to separate trusted subjects from a large amount of applications, and then determine their security requirements. Rest of the paper is organized as follows: We briefly introduce the related works in section 2. In section 3, information flow analysis is introduced to determine trusted subjects and their security label ranges from given TE specification. Section 4 elaborates how to determine the security assurance level of trusted subjects by risk analysis. The last section presents our conclusions and future work.

2

Related Works

The main work on trusted subjects focus on two aspects: limiting the privilege of trusted subjects[16][12] and developing more trustworthy trusted subject[7]. Bell[3][15][4] proposed the concept of subject security label range within which a trusted subject can perform read, alter or write objects arbitrarily.

100

S. Li and Y. He

However,there exists no criterion that can be used to determine the security label range of a trusted subject. Landauer et al.[13] categorized trusted subjects in term of the type of security processing they performed. And then a general security policy for trusted subject is proposed with a state machine model that made explicit user of the notion of locking part of the state in order to allow privileged actions to overlap. None the less, this model is not applicable to practical system. Wu et al.[16] attempted to apply least privilege principle to confine trusted subjects privilege. They proposed a new model called DLS(discrete label sequence). The lifecycle of a trusted subject is decomposed into a sequence of untrusted state and each untrusted state is designated a certain current security label. Only the predefined trusted request events can trigger the transition from one untrusted state to another. Thus, the capability of a trusted subject is under the control of a given discrete label sequence. In addition, policy analysis is a hot topic on system security. Hicks[11] analyzed compliance of the MLS policy with other information policy by logic specification and formal semantic. However, they focused on the compliance of policies, trusted subjects were omitted in their analysis.

3

Trusted Subjects Configuration

3.1

Notation for Trusted Subject

In this section, some notations about trusted subjects are clarified. In Bell LaPadula model, trusted subjects are excluded from the model. In network interpretation of Bell LaPadula model, a trusted subject s has a security label range label(s) = (amin , rmax ) in which subject can violate the constraint of *-property . Therefore, such subjects are called partially trusted subjects because they can only write down to a limited set of objects. Another important metric of a trusted subject is it’s trustworthiness. As secure computer systems, trusted subjects must be designed and developed carefully, then be evaluated to determine the their trustworthiness. Different security standards have different methods to depict it. For instance,in TCSEC[8] trustworthiness is depicted with security classes such as C2,...,A1, while in Common criterion(CC)[1] evaluation assurance levels ( EAL 1 to EAL 7) are used to denote degree with which one system complies with it security policy. For convenience, we unify the evaluation assurance levels in CC and security classes in TCSEC as security assurance levels . That is ,every trusted subject s has a security assurance level, denoted as eal(s). If the number of trusted subjects in the secure system is n , the security assurance levels of the n trusted subjects form a vector c1 , c2 , · · · , cn , called as a designation of security assurance levels. 3.2

Information Flow Graph

Trusted subjects are introduced because of the conflicts between one-way flow requirements of security policy and bidirectional information flow requirements of

Trusted Subjects Configuration Based on TE Model in MLS Systems

101

practical systems. Therefore, information flow analysis is an appropriate means to treat trusted subjects. Some notations about information flow and security policy are detailed in this section. Definition 1 (Entity Information Flow). An entity information flow graph is a directed graph G = (V, E) where V is the set of entities which include subjects and objects in the secure system. E is the set of edges in the graph. Each edge represents a information flow from one entity to another. That is, an edge (u, v) ∈ E, if 1. u is a subject and v is an object/subject, u has Write access to v; 2. u is an object/subject and v is a subject, v has Read access to u; Entity information flow graph is a synthetical result from all security policies and application functions, which reflects current configurations of practical systems. Security policy information flow graph is defined based on the meta-data of each policy, which is call security labels. Definition 2 (Security Policy Information Flow Graph). Let P be a security policy enforced on a system and LP be the set of security labels of policy P . The information flow graph of P is a directed graph GP = (LP , EP ), where EP is the set of edges of policy information flow graph of P . According to policy P , an edge (ls , ld ) ∈ EP if (1) subjects with label ls has Write access to objects with label ld , or (2) subjects with label ld has Read access for objects with label ls . In a information flow graph, if there exists a reachable path u, · · · , vi , · · · , v from vertex u to vertex v, this path is called an information flow path(IFP). There may exist many information flow paths between two vertices. We use u →G v to denote the set of information flow paths from u to v. Definition 3 (Policy Conflict). For an entity information flow graph G and a policy information flow graph GP of a security policy P , There exists two vertices u, v ∈ EG with labels lu , lv ∈ EGP respectively, such that u →G v = ∅ and lu →GP lv = ∅. 3.3

MLS Policy Information Flow Graph

As defined in Bell-LaPadula model, each MLS security label contains two part: linear sensitivity classification and categories. Among these security labels, domination relations is defined as follow: for l1 = (c1 , k1 ) and l2 = (c2 , k2 ) if c1 ≥ c2 and k1 ⊇ k2 , then l1 dominates l2 ,denoted as l1 ≤ l2 . Let LMLS be the set of security labels of MLS security policy. With respect to Bell-LaPadula model, if label l1 ∈ LMLS dominates label l2 ∈ LMLS (l1 ≥ l2 ), information in entity with label l2 can flow to entity with label l1 . Accordingly, policy information graph is generated with this domination relations and forms a security label lattice. 3.4

Type Enforcement Policy and Entity Information Flow Graph

Type enforcement (TE) model is a tabular-oriented mandatory access control model. In TE model subjects are partitioned into domains D and objects are

102

S. Li and Y. He

partitioned into types T . Access control authorizations are associated with both domains and types by domain-domain table(DDT) and domain-type table(DTT). Type enforcement model is a fine-grained mandatory access model as secure administrator can define domains and types flexibly with respect to system function requirements. For instance , SELinux has almost twenty thousand rules and 1,000 types, which can be used to make fine-grained authorization on applications. Policy specification of SELinux can almost outline the entire system. Information flows among domains and types have been analyzed by researcher[11]. According to the definition of information flow mentioned above, information flow graph about domains and types is generated. And then, if a subject s labeled with a domain d and an object o labeled with a type t are associated with an authorization a such that there exists a information flow from d to t in policy information flow graph, there must also exist an information flow from s to o in entity information flow graph. Information flows from objects to subjects, subjects to subjects in entity information flow graph are generated in the same way. 3.5

Determine the Trusted Subjects

When MLS policy information flow graph is applied to the entity information flow graph, information flows that are conflicted with MLS policy can be extracted from entity information flow graph . All the conflicting information flows form a conflict information flow graph, as depicted in figure 1. If a subinformation flow in the conflict information flow graph complies with MLS policy, it can be removed. Consequently, a minimal conflict information flow graph is generated when no valid information flow is found according MLS policy information flow graph. The subjects in such information flow graph are trusted subjects, as they may cause information disclosure without careful treatment. o5

s6 o7

o9

s7

o3

s5 o4

o1

s1

o2

s3

o8

s4

o6

Fig. 1. The conflict information flow graph

3.6

Security Label Range of Trusted Subjects

The security label range is another concern for a trusted subject. A trusted subject can Read and Write the objects with MLS label in this range. It’s an error-prone and tedious work to determine the MLS label range for every trusted

Trusted Subjects Configuration Based on TE Model in MLS Systems

103

subjects correctly. If the subject’s MLS label range is too large, it can be compromised to disclose high level information by attacker. If the subject’s MLS label range is too small, it will obstruct normal task of subject. In the MLS conflict information flow graph, a subject can obtain all information along the information flow path to it, the upper bound of the security label range of a subject s can be determined by information inflow. The direct information flows to the subject are the results of it’s Read like access, the set of objects the subject s read is denoted as DirIO(s). The upper bound of it’s security label range must dominate all security labels of objects on the direct inflows: lubr− max(s) =

max

oi ∈DirIO(s)

(fo (oi )).

The lower bound of subject security label range is determined by outflow of information from that subject, direct outflow specifically. Let DirOO(s) be the set of objects which s have Write access permission. The lower bound of the security label range of s can be calculated as follows respectively: glba− min(s) =

4 4.1

min

oi ∈DirOO(s)

fo (oi ).

Risk Information Flow Graph Risk of Trusted Subjects

As a trusted subject can both read and write objects with different security labels, it is potential to disclose high classification data to low level objects. Therefore, one important work during developing and deploying a secure system is assessing the risks due to trusted subjects. According to lectures about risk assessing, risk on some event is determined by the damage caused by that event and the occurrence probability of it. In brief, for an event e, p(e) is the probability of occurrence, and d(e) is the damage when e has actually happened, then the risk of e is risk(e) = p(e) ∗ d(e). Damage of Information Disclosure. The damage caused by a trusted subject can be determined by these the security label of source object(l1 ) and that of destination object (l2 ). Similar to the risk indices of Trusted Network Interpretation of the TCSEC[15], developer and evaluation can define damage indices with some common view. A damage index from l1 to l2 is denoted by dindex(l1 , l2 ). Table 1 presents an example damage indices definition. The columns are the sources classification of information disclosed and the rows denote the destination of leaked information; and then an entry (x,y) represents the damage index if information at the classification y is leaked to x. Although damage indices may be used to express the damages, they have less discrimination. We use an exponential function to amplify the loss when information at level l1 follows to level l2 : d(l1 → l2 ) = ea

dindex(l1 ,l2 )

−1

− e.

where a is a constant with respect to specific environments.

(1)

104

S. Li and Y. He Table 1. Damage Indices of Information Leaking dinex U N C S TS 1C MC

U 0 0 0 0 0 0 0

N 1 0 0 0 0 0 0

C 2 1 0 0 0 0 0

S 3 2 1 0 0 0 0

TS 4 4 3 2 0 0 0

1C 5 5 4 3 2 0 0

MC 6 6 5 4 3 1 0

The Leak Probability of Trusted Subjects . The security assurance levels of trusted subjects denote their trustworthiness. The lower the security assurance of a trusted subject is, the higher the leaking probability is. For convenience, we define the probability of information disclosure as a function: −k.eal(s)

p(s) = f (eal(s)) = eb

(2)

where b is anther environment constant. The developer, evaluator and user must reach an agreement on the value of b and a before developments and evaluations. 4.2

Risk Security

For every two objects oi and oj in the conflict information flow graph, all the information flow paths from oi to oj is a subgraph of the conflict information flow graph, and forms the disclosure channel from oi to oj , denoted as DCi→j . The probability of disclosing information from oi to oj is determined by the subjects on the DCi→j . Let sk be a subject on DCi→j and psk be the probability sk leaking information. We attach every psk to sk , omit the objects on DCi→j with exceptions of oi and oj . A probability network from oi to oj is constructed. For example, the disclosing channel from o1 to o4 contains subjects DCo1 →o4 = {s1 , s3 , s5 }. If for an assurance level designation, the probabilities of s1 ,s3 and s5 are 0.4, 0.5 and 0.6, figure 2 is the probability network. As the events of leaking information by subjects are independent, the resulting probability of the network is calculated with following rules according to classic probability theory. If two sub-information flows with probabilities px and py form an information flow in series, the leaking probability of the resultant information flow is the product of the probabilities of sub flows: p= px ∗py . On the other hand, if they are combined by parallel connection, the leaking probability of the resultant information flow is calculated as:p = px + py − px ∗ py . By applying these two rules recursively, the probability pi→j of the disclosure channel can be calculated. The probability of DCo1 −>o4 is 0.32 in figure 2. Finally , the risk of leaking information from oi to os can be formulated as follows riskoi →oj = pi→j ∗ d(fo (oi ), fo (oj )).

(3)

In MLS policy conflict graph, for any object o and another object oi ∈ OGC (o = oi )if there exists a disclosing channel from o to oi , the risk of this

Trusted Subjects Configuration Based on TE Model in MLS Systems

105

channel can be calculated according to equation (3). Among all the disclosing channels of an object o, the channel with maximal risk determines the risk of the object o . We call it as disclosing risk of object o, denoted as risko (o). Definition 4 (Risk Security). Let GC be a MLS policy conflict information flow graph of a system. T hreshold is the maximal risk that a system can accept in order for the confidentiality of the system. Under a designation of security assurance c1 , c2 , · · · , cn  of the trusted subject set T S(|T S| = n), if all objects in GC meet following condition: ∀oi ∈ OGC ⇒ risk(oi ) ≤ T hreshold then, the designation c1 , c2 , · · · , cn  is a risk security designation for the system. 4.3

The Assurance Requirements of Trusted Subjects

If the number of trusted subjects in conflict information flow graph is n according to MLS policy conflict information flow graph, the designation of security assurance levels is a vector c1 , c2 , · · · , cn  with n dimensions . Let v1 and v2 be two designations. v1 precedes v2 if and only if : for every component ci , v1 .ci ≤ v2 .ci . This relationship is denoted with notation . Apparently, if v1 precedes v2 and the designation v1 is risk security under a configuration, then v2 is risk security too. The relation  is a partial order relation and forms a lattice on the set of all designations. Figure 3 presents a designation lattice with three trusted subjects and two security assurance levels. In this diagram, we simplify the assurance levels as some intuitive numbers. Apparently, if there are m security assurance levels, n subjects in the MLS policy conflict information flow graph have mn combinations about designations. o1

(2, 2, 3)

(2, 3, 3)

(2, 3, 2)

(3, 2, 3)

(3, 2, 2)

(3, 3, 2)

0.4

(2, 2, 2) 0.5

(3, 3, 3)

0.6

o4

Fig. 2. Probability network Fig. 3. The lattice of assurance level designations

According to the TCSEC and Common Criterion, seven security assurance levels are defined to measure system security, and only levels above EAL 4 in CC or B1 in TCSEC support MLS. Therefore, only four options exist for every subject. It will generate 4n designations for n trusted subjects. Among the designations, those meeting the condition of risk security are called effective designations, the set of all effective designations is denoted as EDS.

106

S. Li and Y. He

When applying  relation to the effective designation set, the solid line part of figure 3 forms the precedence relationship of alternatives. Although designations in effective designation set meet the risk requirements, the higher the precedence of a designation is, the lower developing and buying corresponding applications cost. Therefore, the designations on the bottom of this incomplete lattice are the optimum solutions, because they meet the secure requirements at least cost. The optimum solution of designations is not unique, but a set. For instance, (2, 2, 3, ), (3, 2, 3) and (3, 2, 2) are three best designations for developers in figure 3. This result is reasonable, because the cost of the software isn’t determined by the security assurance level only and there are other factors that affect the cost of software development. The optimum solution set reduces the uncertainty vastly and also provides flexibility for software developments. Developers may choose an appropriate designation with respect to other factors such as software’s scale,complexity, which is out of range of this paper.

5

Conclusions

This paper proposed an approach for trusted subject deployment in secure operating systems. This approach made use of information flow graph and risk analysis to determine the security requirements of trusted subjects. Trusted subjects with different security assurance levels may coexist by applying type enforcement policy on them. By analyzing existing type enforcement security specifications, trusted subjects are separated automatically from numerous applications. As with the determination of security label range and security assurance level, it reduced the labors and error in identifying trusted subjects and their configurations.

References 1. 15408, I.: Common criteria for information technology security evaluation part 3: Security assurance components. Tech. Rep. CCMB-2009-07-003, Common Criteria (July 2009) 2. Bell, D.E.: Secure computer systems: A retrospective. In: Proceedings of the 1983 IEEE Symposium on Security and Privacy, pp. 161–162. IEEE Computer Society, Washington, DC, USA (1983) 3. Bell, D.E.: Secure computer systems: A network interpretation. In: 2nd Aerospace Computer Security Conference, pp. 32–39. IEEE Computer Society, Los Alamitos (1986) 4. Bell, D.E.: Security policy modeling for the next-generation packet switch. In: Proceedings of IEEE Symposium on Security and Privacy, pp. 212–216. IEEE Computer Society, Washington, DC, USA (1988) 5. Bell, D.E., LaPadula, L.J.: Secure computer system: a mathematical model. Tech. Rep. ESD-TR-73-278, Electronic System Division, Air Force Systems Commond (November 1973) 6. Bell, D.E., LaPadula, L.J.: Secure computer system:unified exposition and multics interpretation. Tech. Rep. MTR-2997 Rev.1, Mitre Corporation (March 1976)

Trusted Subjects Configuration Based on TE Model in MLS Systems

107

7. Chong, S., Myers, A.C.: Security policies for downgrading. In: Proceedings of the 11th ACM Conference on Computer and Communications Security, CCS 2004, pp. 198–209. ACM, New York (2004) 8. Department of Defense Trusted computer system evaluation criteria. Tech. Rep. DoD 5200.28-STD, Natioinal Computer Security Center (December 1985) 9. Foley, S.: A model for secure information flow. In: Proceedings of IEEE Symposium on Security and Privacy, pp. 212–216. IEEE Computer Society, Washington, DC, USA (1989) 10. Gligor, V.D., Chandersekaran, C.S., Chapman, R.S., Dotterer, L.J., Hecht, M.S., Jiang, W.D., Johri, A., Luckenbaugh, G.L., Vasudevan, N.: Design and implementation of secure xenix. IEEE Trans. Softw. Eng. 13(2), 208–221 (1987) 11. Hicks, B., Rueda, S., St.Clair, L., Jaeger, T., McDaniel, P.: A logical specification and analysis for selinux mls policy. In: Proceedings of the 12th ACM Symposium on Access Control Models and Technologies, SACMAT 2007, pp. 91–100. ACM, New York (2007) 12. Jan´ aˇcek, J.: Two dimensional labelled security model with partially trusted subjects and its enforcement using sELinux DTE mechanism. In: Zavoral, F., Yaghob, J., Pichappan, P., El-Qawasmeh, E. (eds.) NDT 2010. Communications in Computer and Information Science, vol. 87, pp. 259–272. Springer, Heidelberg (2010) 13. Landauer, J., Redmond, T., Benzel, T.: Formal policies for trusted processes. In: Proceedings of IEEE Symposium on Security and Privacy, pp. 31–40. IEEE Computer Society, Washington, DC, USA (1989) 14. Mayer, F.: An interpretation of a refined bell-la padula model for the tmach kernel. In: 4th Aerospace Computer Security Applications Conference, pp. 368–378. IEEE Computer Society Press, Los Alamitos (December 1988) 15. NCSC: Trusted network interpretation of the trusted computer system evaluation criteria. Tech. Rep. NCSC-TG-005, National Computer Security Center (July 1987) 16. Yan-Jun, W., Hong-Liang, L., Chen, Z.: A multi-level security model with least privilege support for trusted subject. Journal of Software 18(3), 730–738 (2007)

Key Exchange with Anonymous Authentication Using DAA-SIGMA Protocol Jesse Walker and Jiangtao Li Intel Labs, Hillsboro, Oregon, USA {jesse.walker,jiangtao.li}@intel.com

Abstract. Anonymous digital signatures such as Direct Anonymous Attestation (DAA) and group signatures are a fundamental building block for anonymous authentication. In this paper, we show how to incorporate DAA schemes into a key exchange protocol between two entities to achieve anonymous authentication and to derive a shared key between them. We modify the SIGMA key exchange protocol used in the Internet Key Exchange (IKE) standards to support anonymous authentication using DAA. Our key exchange protocol also extends to support group signature schemes instead of DAA. We present a secure model for key exchange with anonymous authentication derived from the CanettiKrawczyk key-exchange security model. We prove that our DAA-SIGMA protocol is secure under our security model.

1

Introduction

Anonymous digital signatures such as group signatures [22,2,5,6], Direct Anonymous Attestation (DAA) [7, 8, 23, 24, 13], and anonymous credentials [14, 15, 16] play an important role in privacy enhanced technologies, as they enable anonymous entity authentication. They allow an entity (e.g., a computer platform, or a hardware device) to create a signature without revealing its identity. In 1991 Chaum and van Heyst first introduced the concept of a group signature scheme [22]. In a group signature scheme, all group members share a common public key, yet each member has a unique private key. A group signature is anonymous to all verifiers except a trusted group manager. Many group signature schemes have been proposed, e.g., in [2,5,6,29]. Brickell, Camenisch, and Chen first introduced Direct Anonymous Attestation (DAA) [7]. DAA can be seen as a special group signature scheme. The trusted computing community extensively use DAA, and their work has simulated the development of many new DAA schemes, e.g., in [8, 23, 25, 24, 13]. For example, the Trusted Computing Group (TCG), a global industry standards body [35], adopted and standardized the original DAA scheme [7] in the Trust Platform Module (TPM) Specification v1.2 [34], and has been implemented and shipped in millions of TPMs. The same DAA scheme was recently adopted by ISO/IEC as an international standard [1]. Intel has implemented an extension of DAA called Enhanced Privacy ID [10, 11] in the Intel P55 Ibex Peak chipsets [12]. Recently, ISO/IEC L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 108–127, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Key Exchange with Anonymous Authentication

109

has begun development of new international standards on anonymous digital signatures, including group signature and DAA schemes, and on anonymous entity authentication using anonymous digital signatures. Use of DAA for anonymous authentication is straight-forward: a verifier sends a challenge message that includes a nonce to a group member; the group member authenticates to the verifier by signing the challenge with his private key. Verifying the DAA signature convinces the verifier that the group member is a valid DAA signer, but does not reveal who created the signature. This authentication method is limited because the group member does not verify the verifier’s credential and the authentication derives no shared key. Note that in the TPM usage, DAA is mainly used for signing attestation identity keys. Now consider the following scenario: a trusted computing platform requests to download a protected resource from an Internet server and may also upload sensitive data to the server. The platform must authenticate the server before sending such data. At the same time the server musts to verify the platform is indeed trusted to access the requested resource. DAA can be used in this example if the platform wants to authenticate to the server anonymously. However the na¨ıve authentication method in the previous paragraph does not work well in this scenario for the following reasons: 1. The platform and server need to mutually authenticate. 2. A session key is desirable derived to protect any sensitive information exchanged between the pair and to avoid repeated re-authentication when the exchange consists of more than a single request/response. A natural extension of DAA is to embed DAA in a Diffie-Hellman key exchange protocol, so that two entities can derive a shared session key as well as mutually authenticate. There have been several proposals to incorporate DAA into key exchange protocols. Balfe et al. [3] proposed anonymous authentication in peer-to-peer networks by embedding DAA with TLS and IPsec. Leung and Mitchell [32] introduced an anonymous authentication protocol based on DAA. Recently, Cesena et al. [20] proposed an anonymous authentication protocol based on TLS and DAA including a reference implementation. 1.1

Our Contribution

It is easy to design simple Diffie-Hellman (DH) based key exchange protocols, but it is easier to get them wrong. Many DH-based key exchange protocols are vulnerable to man-in-the-middle attacks or identity misbinding attacks [28]. Although the literature provides several proposals to use DAA in Diffie-Hellman key exchange protocols [3, 32, 20], to the best of our knowledge none present a formal security model and proof. This is the motivation of our paper. There are two contributions of this paper. We describe each contribution briefly as follows. A security model for key exchange with anonymous authentication. We give a rigorous treatment to anonymous authentication and introduce a new security model for key exchange with anonymous authentication. Our security

110

J. Walker and J. Li

model derives from the Canetti-Krawczyk key exchange security model [18, 19]. In the Canetti-Krawczyk security model, identity plays an important role in the proof of security. However in anonymous authentication, the identity of the entity who wants to be anonymous cannot be revealed in the key exchange. This creates a significant challenge in the definition of secure model and in the design of the key exchange protocol. A secure key exchange protocol with anonymous authentication. We develop a new key exchange protocol with anonymous authentication based on DAA and the SIGMA family of key exchange protocols from IPsec [31] and the Internet Key Exchange (IKE) standards [30]. We call our protocol the daa-sigma protocol. We present a formal security analysis of our daa-sigma protocol based on our security model. 1.2

Related Work

Besides using DAA for anonymous authentication in key exchange protocols [3, 32, 20], other mechanisms of anonymous authentication have been proposed recently. Cui and Cao proposed an anonymous authentication and key exchange protocol based on ring signatures [26]. Viet et al. proposed a password-based anonymous authentication key exchange protocol [36]. Chai et al. proposed an efficient password-based authentication scheme that preserves user privacy [21]. Besides the Canetti-Krawczyk model [18] for security analysis of key exchange protocols, other models and tools have been proposed in the literature. For example, Meadows used an automated protocol analyzer to study the security of key exchange protocols [33]. Datta et al. developed a symbolic logic analyzer for proving security properties of key exchange protocols [27]. Bellare and Rogaway formalized the security of key exchange protocols in the realistic setting of concurrent sessions [4]. In this paper, we choose to use the Canetti-Krawczyk key exchange model as the basis because this model is well established and has been used to analyze the security of the SIGMA key exchange protocol. 1.3

Organization of the Paper

The rest of this paper is organized as follows. We first introduce our notation and briefly review the DAA schemes and the SIGMA key exchange protocol in Section 2. We then propose the security model of key exchange protocol with anonymous authentication in Section 3. We present our daa-sigma protocol in Section 4 and give the security proof in Section 5. We discuss some extensions of our daa-sigma protocol in Section 6. We conclude our paper in Section 7.

2

Background and Building Blocks

In this section, we review our notations and terminologies, the basic concepts of DAA, and finally the SIGMA key exchange protocol.

Key Exchange with Anonymous Authentication

2.1

111

Notations

We use the following notations in this paper. Let P and Q to be two entities of the key exchange protocol. – – – – – – 2.2

mack (m): a message authentication code of m computed using the key k. [m]k : a concatenation of message m and mack (m). sigP (m): a signature of m created by the entity P . idP : an identity of the entity P . certP : a public key certificate of the entity P . prf: a pseudo-random function. Review of DAA

This section reviews the DAA specification and security model proposed in [9]. The security model in [9] is simpler and easier to understand than the original DAA definition [7]. There are four types of players in a DAA scheme: an issuer I, a TPM Mi , a host Hi and a verifier Vj . Mi and Hi form a platform in the trusted computing environment and share the role of a DAA signer Si . To simplify our notation, we treat the DAA signer as a single entity in the rest of this paper. A DAA scheme has following polynomial-algorithms or interactive protocols (Setup, Join, Sign, Verify, Link): Setup : On input of a security parameter 1k , I uses this randomized algorithm to produce a pair (gpk, isk), where isk is the issuer’s secret key, and gpk is the public key including the global public parameters. Join : A signer Si and the issuer I run an interactive join protocol. In the end of the protocol, Si outputs a secret key ski and a membership credential crei issued by I. We denote the ski and crei pair as the signing key of Si . Note that the value of ski is unknown to I. Sign : On input of gpk, ski , crei , a basename bsnj , and a message m, Si uses this algorithm to produce a signature σ on m. The basename bsnj can be either the name string of the verifier Vj or a special symbol ⊥ and it is used for controlling the linkability. Verify : On input of gpk, bsnj , m, a candidate signature σ on m, and a revocation list RL, Vj uses this deterministic algorithm to determine whether σ is valid. The revocation is out of the scope of this paper. Link : On input of two signatures σ0 and σ1 , Vj uses this deterministic algorithm to return linked, unlinked, or invalid signatures. The formal security definition of DAA can be found in [7, 9]. Informally, a DAA scheme is secure if the following properties hold: – Correctness. A signature created using a valid signing key can be verified by any verifiers correctly. – Anonymity. An adversary who are not in possession of a secret key sk cannot learn the identity of the signer of signatures created using sk. – Unforgeability. An adversary cannot forge a valid signature if he does not have a signing key or his signing keys have been all revoked.

112

J. Walker and J. Li

– User-controlled linkability. Signatures created by the same set of sk, cre, bsn can be linked, if bsn = ⊥. However, signatures cannot be linked if they are created using different bsn or if bsn = ⊥. If a signature σ was created using bsn = ⊥, then we call σ a random based signature; otherwise, we call σ a name based signature. For the daa-sigma protocol, we first focus on random based signatures. We shall discuss how to adopt name based signatures in Section 6. Let I be a DAA issuer. Let P be a DAA signer who has a valid signing key issued by I. We use the following notations in the rest of the paper: – idI : the identity of the issuer I. For simplicity, we assume I creates only one group public key gpk. One can figure out the corresponding gpk from idI . If the issuer creates multiple group public keys, we can use idG to denote the identity of the DAA group. – certI : a public key certificate of I issued by a certificate authority to certify the group public key gpk. – daa-sigP (m): a DAA signature on message m created by the entity P . Let skP be P ’s secret key and creP be P ’s membership credential, then daa-sigP (m) denotes Sign(gpk, skP , creP , bsn, m) where bsn = ⊥ if bsn is not provided as input. 2.3

Review of SIGMA Key Exchange Protocol

We now review the SIGMA key exchange protocol. This key exchange protocol is one of the Internet Key-Exchange (IKE) protocols [30] used to establish secret shared keys for use in the Internet Protocol Security (IPsec) standards [31]. The SIGMA key exchange protocol uses Diffie-Hellman key exchange with “signand-mac” mechanism. It is presented as follows: Let P and Q be two entities of the key exchange protocol, where P is the protocol initiator who activates the session and Q is the intended peer of the session. Let G be a cyclic group of prime order q where the Decisional Diffie-Hellman (DDH) problem is hard and g be a generator of G. Let s be a unique session identifier chosen by P , Q, or both. The SIGMA protocol has the following messages. Message 1 (P → Q) : s, g x Message 2 (P ← Q) : [s, idQ ]k1 , g y , sigQ (s, g x , g y ) Message 3 (P → Q) : [s, idP ]k1 , sigP (s, g y , g x ) In the above protocol, P chooses a random integer x and computes the ephemeral DH public key gx . Analogously, Q chooses a random integer y and computes its ephemeral DH public key gy . By exchanging g x and g y , both entities can compute g xy , but “man-in-the-middle” attackers cannot. Both entities then derive a session key k0 and a mac key k1 from g xy . In message 2, Q computes a mac of its identity using k1 and signs the ephemeral DH public keys (g x , g y ) using its signing key. P can verify the signature to ensure that the message 2 indeed comes from entity Q and verify the mac to ensure that Q knows k1 , thus knows the session key k0 as well. Similarly, P computes a mac of its identity and a signature

Key Exchange with Anonymous Authentication

113

of the DH public keys in message 3. After Q verifies the message 3, both entities have established a session key k0 and can use k0 for further communications.

3

Security Model

In this section, we first review the Canetti-Krawczyk key exchange model [18,19], and then describe how to extend this key exchange model to support anonymous authentication. Note that Canetti provided a newer security model on universal composability [17]. The Canetti-Krawczyk security model from [18, 19] provides sufficient machinery to address the problem space that concerns us. Thus it is unnecessary to use the more general and powerful formalism in [17]. 3.1

Review of Canetti-Krawczyk Key Exchange Model

This section reviews the Canetti-Krawczyk model [18] for authenticated key establishment protocols. A session key adversary, or SK-adversary, A is a probabilistic polynomial time algorithm that controls all communication between any parties using the set of queries specified in Table 1 below. An SK-adversary accomplishes this control by issuing queries to a set of oracles Os,P . An oracle Os,P represents the protocol instance identified by s initiated by principal P . This communications instance is called a session. Each oracle responds to the queries, and the outputs of all the oracles Os,P collectively represent the history of the protocol. The SK-adversary receives all output, and the uses this output to decide which oracles to activate next. A session is called exposed if an SK-adversary issues a session-key-reveal query against its oracle or an state-reveal or corrupt query against one of the session’s principals. As noted, the model uses the test query to formalize the efficacy of an attack. The adversary may apply the test query to any session that is not exposed. The test session returns a real or randomly generated key each with probability half and the adversary must guess whether the returned key is real. The adversary is called successful if it can distinguish the real key with probability significantly larger than 1/2. An instance of protocol execution results in a partnership or agreement between two oracle instances of principals’ communication. Partnership is a tricky notion, because the identity of the parties can be unknown before the protocol instance completes. In [18] Canetti and Krawcyzk accommodate this by allowing the communicating oracles to learn the identity of the other party from the protocol instance. Definition 1. Suppose oracle Os,P has accepted with output (P, s, Q). The oracle Os,R is called the matching session of Os,P if either 1. Os,R has accepted with output (R, s, S), where R = Q and S = P , or, 2. Os,R has not completed. With this background, it is possible to define security in the model.

114

J. Walker and J. Li Table 1. Adversarial Queries

Query Send(P, Q, s, m)

Description Oracle Os,P responds to message m to Q according to the protocol specification and decides whether to accept, reject, or continue. Accept means the oracle has completed the protocol with partner Q, a session id s, session key K, and Os,P signals its acceptance by including (P, s, Q) with its public output. Reject means the protocol failed. Continue means the oracle is waiting for its next protocol step. Os,P returns its decision to the adversary A. Session-Key-Reveal(P, Q, s) If an oracle Os,P has accepted and holds a session key K, the oracle returns K to SK-adversary A. Otherwise Os,P ignores this query. This query models a key leaking via break-ins, cryptanalysis, careless disposal of keys, and the like. State-Reveal(P ) If the oracle Os,P has accepted or holds a session key, it ignores this query. Otherwise the oracle returns its internal ephemeral session state, but no long-lived secrets. This query models the compromise of a single session. Corrupt(P ) P responds to this query by yeielding its entire internal state, including all of the state held by all its oracles Os,P , and any long-lived keys. Subsequently the SK-adversary controls all of P ’s actions. Expire-Session(P, Q, s) This query causes oracle Os,P to delete its session state, and oracle Os,P will henceforth ignore any subsequent Session-Key-Reveal query, because it no longer has the targeted session key. Test(P, Q, s) An SK-adversary A may use the test query only once. This query is used to measure that adversary’s efficacy at distinguishing a real session key from a randomly generated one. If Os,P has accepted with a session key K, then it selects a bit value b randomly; if b = 0, then it returns K and otherwise generates a random value K, which it returns instead. If the oracle has not accepted or does not have the session key, it does not respond to the test query.

Definition 2. A protocol π is called SK-secure if for all SK-adversaries A the following holds: 1. If two uncorrupted parties P and Q complete matching sessions Os,P and Os,Q of π with public outputs (P, s, Q) and (Q, s, P ), respectively, then the session key K output in these sessions is the same except with a negligible probability. 2. A succeeds in distinguishing the output from its test query with probability not more than 1/2 plus a negligible fraction.

Key Exchange with Anonymous Authentication

3.2

115

Security Model for Key Exchange with Anonymous Authentication

In this paper, we first consider unilateral anonymous authentication and use DAA as the fundamental building block for anonymous authentication. The case of mutual anonymous authentication and use of group signatures shall be discussed in Section 6. In our model, we always assume that the protocol initiator P has a DAA private key and the protocol responder Q has a regular signature key. In the example in Section 1 where a trusted platform mutual authenticates with an Internet server, it is natural to have the anonymous entity as the protocol initiator. If the adversary starts a session with the protocol initiator who does not have a DAA private key or with the protocol responder who does not have a regular signature key, the session would fail. Note that anonymous authentication in our model is different from anonymity without authentication, where P does not show any identity or signatures to Q. Anonymous authentication in our context means that P authenticates to Q as a member of a DAA group created by an issuer I, but Q does not learn the actual identity of P . Canetti and Krawcyzk prove that the SIGMA protocol in Section 2.3 is secure in the key exchange model described above. However, this security model assumes concrete identity of each party revealed during the protocol, so we will need to extend their model to accommodate anonymous authentication where the actual identity of the protocol initiator cannot be disclosed. The technical need is to have a specific identity to use to establish the matching sessions property. In particular, each party P must verify that the peer Q is the same entity throughout an instance of the protocol. To this end we make the following Definition 3. Suppose P is a member of a group identified by idI , and let f (x) denote a one-way function. A pseudo identity of P is a pair (idI , f (n)), where n is a randomly selected nonce. We substitute anonymous identity instances in place of concrete identities in the SIGMA protocol. A principal P outputs (Pˆ , s, Q) where Pˆ = (idI , f (n)), and argues that this is an appropriate identity for the Canetti-Krawcyzk key exchange model. Indeed, P ’s DAA signature proves its membership in a specific DAA group, but this by itself does not prove that the messages of the protocol instance are exchanged with one single group member. To accomplish this, the definition of pseudo identity requires P to send a commitment f (n) of the random value n to its peer Q, and then P proves it knows n as part of authentication. This allows the matching sessions property to be established, because an adversary cannot arrange for a second group member R to interject itself into the protocol, because R does not know the value of n. We now define security of key exchange with anonymous authentication in below. Definition 4. A key exchange protocol with anonymous authentication π is secure if it is SK-secure and anonymous.

116

J. Walker and J. Li

The property of SK-security follows the Canetti-Krawcyzk key exchange model and is defined as follows. Definition 5. A key exchange protocol with anonymous authentication π is SKsecure if for all polynomial-time SK-adversaries A the following holds: 1. If two uncorrupted parties P and Q complete matching sessions Os,P and Os,Q of π with public outputs (Pˆ , s, Q) and (Q, s, Pˆ ), respectively, where Pˆ is the pseudo identity of P , then the session key K for these two sessions is the same except with negligible probability. 2. A succeeds in distinguishing the output from its test query with probability no more than 1/2 plus a negligible fraction. We now define the anonymous property of a key exchange protocol with anonymous authentication. Roughly speaking, a key exchange protocol π is anonymous if the protocol initiator P remains anonymous to its peer in the key exchange session. The definition of anonymity follows the definition of the underlying anonymous digital signature schemes used in the protocol. For example using DAA, we define the anonymity of a key exchange protocol π by following the user-controlled-anonymity property of DAA in [9]. General speaking, a key exchange protocol with anonymous authentication π is anonymous if there is no probabilistic polynomial-time adversary can win the following game between a challenger C and an adversary A as follows: – Initial: C assigns each entity a unique DAA private key. C also assigns a unique identity and a regular signature key to A. – Phase 1: C is probed by A who makes the following queries: • Key exchange. A submits an entity’s identity P of his choice to C, who runs a key exchange protocol π using P as the protocol initiator with A as the protocol responder. • Corrupt. A submits an entity’s identity P of his choice to C, who responds with the DAA private key of P . – Challenge: At the end of Phase 1, A chooses two entities P0 and P1 of his choice. A must not have made any corrupt query on either P0 or P1 . To make the challenge, C chooses a bit b uniformly at random, then runs a key exchange protocol π using Pb as the protocol initiator with A as the protocol responder. – Phase 2: A continues to probe C with the same type of queries that it made in Phase 1. However, he is not allowed to corrupt either P0 or P1 . – Response: A returns a bit b . We say that the adversary wins the game if b = b . Definition 6. Let A denote an adversary that plays the game above. A key exchange protocol π is anonymous if for any polynomial-time adversary A, the probability of A in breaking the anonymity game is no more than 1/2 plus a negligible fraction.

Key Exchange with Anonymous Authentication

117

Note that the above definition of anonymity is generic to any group-based anonymous digital signature schemes. We can modify the above definition to be DAA specific such that the identity of the protocol initiator is unrevealed in the protocol but could be linkable under the entity’s control. Similarly, we can modify the above definition for group signatures such that the identity of the protocol initiator is anonymous but openable by a trusted group manager.

4

Proposed DAA-SIGMA Protocol

We now describe our daa-sigma key exchange protocol as follows. Our key exchange protocol builds on top of the SIGMA protocol with the following changes: (1) P uses its DAA private key to signs the ephemeral DH public keys and (2) P uses (idI , g x ) as its pseudo identity in the protocol where the one-way function is defined as f (x) = g x . We assume the following initial information. Let P and Q be the two parties of the daa-sigma key exchange protocol, where P is the protocol initiator who activates the session and Q is the intended peer of the session. – P has a DAA signing key issued by an issuer I whose identity is idI . P can use the DAA signing algorithm daa-sig to create DAA signatures. – Q has an identity idQ and a public-private key pair. Q can use his private key and a signature algorithm sig to create a signature. – Both entities agree on G, a cyclic group of prime order q in which the DDH problem is hard, and g, a generator of G. For example, one can choose primes p and q such that q|p − 1, and then choose a number g whose multiplicative order modulo p is q. – The protocol uses a message authentication code family mac and a pseudorandom function family prf. The daa-sigma protocol has the following messages and steps. Message 1 (P → Q) : s, gx Message 2 (P ← Q) : [s, idQ ]k1 , g y , sigQ (s, g x , g y ) Message 3 (P → Q) : [s, idI , g x , daa-sigP (s, g y , g x )]k1 Sending Message 1 1. P chooses a session id s. Or let s be a session id pre-negotiated by P and Q. 2. P picks a random x ← Zq and computes its ephemeral DH public key g x . 3. P sends s, g x to Q. Sending Message 2 1. 2. 3. 4. 5. 6. 7.

Q Q Q Q Q Q Q

picks a random y ← Zq and computes its ephemeral DH public key g y . computes g xy = (g x )y . derives two keys k0 = prfgxy (0), and k1 = prfgxy (1). securely erases y and g xy from its memory. computes mack1 (s, idQ ). computes sigQ (s, g x , g y ) using its private key. sends [s, idQ ]k1 , g y , sigQ (s, g x , g y ) to P .

118

J. Walker and J. Li

Receiving Message 2 1. 2. 3. 4. 5. 6. 7.

P computes g xy = (g y )x . P derives two keys k0 = prfgxy (0), and k1 = prfgxy (1). P securely erases x and g xy from its memory. P verifies mack1 (s, idQ ) using derived key k1 . P retrieves the public key of Q from idQ . P verifies sigQ (s, g x , g y ) using Q’s public key. If one of the above verification steps fails, the session is aborted and outputs “failure”.

Sending Message 3 1. 2. 3. 4.

P uses its DAA signing key to compute daa-sigP (s, g y , g x ). P computes mack1 (s, idI , g x , daa-sigP (s, g y , g x )). P sends [s, idI , g x , daa-sigP (s, g y , g x )]k1 to Q. P completes the session with public output ((idI , g x ), s, idQ ) and secret session key k0 .

Receiving Message 3 Q verifies mack1 (s, idI , g x , daa-sigP (s, g y , g x )) using derived key k1 . Q retrieves the DAA group public key of the issuer I from idI . Q verifies daa-sigP (s, g y , g x ) using the DAA group public key. If one of the above verification steps fails, the session is aborted and outputs of “failure”. 5. Q completes the session with public output (idQ , s, (idI , g x )) and secret session key k0 . 1. 2. 3. 4.

Note that we include the DAA signature daa-sigP (s, g y , g x ) in the MAC computation in message 3. This demonstrates the creator of the DAA signature is the same entity as the one who knows k0 and k1 .

5

Security Proof of the DAA-SIGMA Protocol

In Theorem 6 of [19] Canetti and Krawczyk prove that the SIGMA protocol is secure in their model. Our security proof of the daa-sigma protocol follows their security proof. We replace the signing algorithm of the protocol initiator P with the DAA signing algorithm and P ’s identity with the pseudo identity (idI , g x ), where idI is the identity of the issuer and g x is an ephemeral Diffie-Hellman value P generates. To prove the security of our daa-sigma protocol, we begin with a review of the definition of the Decisional Diffie-Hellman (DDH) assumption, which is the assumption underlying the security of all Diffie-Hellman based key exchange protocols. Assumption 1. Let G, generated by g, be a cyclic group of prime order q. The DDH assumption in G holds if the probability distributions of Q0={g,g x ,g y ,g xy  : x, y ← Zq } and Q1 = {g, g x , g y , g r  : x, y, r ← Zq } are computationally indistinguishable.

Key Exchange with Anonymous Authentication

119

In addition to the DDH assumption, the security of the key exchange protocol in Section 4 also depends on the security of the underlying cryptographic primitives, namely, digital signatures, message authentication codes, pseudo-random functions, and DAA. We have the following theorem. Theorem 1. Under the DDH assumption in G and assuming the security of the underlying cryptographic functions sig, mac, prf, daa-sig, the daa-sigma protocol in Section 4 is secure in the model defined in Section 3. To prove the above theorem, we prove the following two lemmas. Lemma 1. If the underlying DAA scheme is secure, the daa-sigma protocol is anonymous in the model defined in Section 3.2. Proof. In the daa-sigma protocol, the protocol initiator P reveals s and g x to its peer in the first message, and reveals [s, idI , g x , daa-sigP (s, g y , g x )]k1 in the final message. Since s and g x are randomly chosen at each session, if the DAA signature is anonymous, P only reveals its pseudo identity (idI , g x ) to its peer, but not the real identity. To prove the daa-sigma protocol is anonymous, we use the following reduction. Suppose there exists a polynomial-time adversary A that breaks the anonymity game in Section 3.2, we can construct an algorithm B that breaks the user-controlled-anonymity of DAA defined in [9] by interacting with A as follows: – – – – –

B B B B B

received isk and gpk from the challenger. creates n entities, but does not assign any DAA private key to each entity. chooses an identity idI for the DAA group and sends idI and gpk to A. picks a unique identity and a regular signature key for A. is probed by A with following two types of queries: • A makes a key exchange query on an entity P . If P has not been queried before, B first runs a join query with the challenger to create a DAA private key for P . Note that B does not know the DAA private key of P . B simulates the daa-sigma protocol with A as follows: 1. B randomly chooses a session id s and x. 2. B computes g x and sends s and g x to A. 3. B receives message 2 from A and validates the message. 4. B computes g xy and derives k0 and k1 by following the daa-sigma protocol. 5. B makes a sign query on P to the challenger with the message m = (s, g y , g x ) and obtains daa-sigP (s, g y , g x ). 6. B computes mack1 (s, idI , g x , daa-sigP (s, g y , g x )) using k1 . 7. B sends [s, idI , g x , daa-sigP (s, g y , g x )]k1 to A. • A makes a corrupt query on an entity P . If P has not been queried before, B first runs a join query with the challenger to create a DAA private key for P . B then makes a corrupt query to the challenger to obtain P ’s DAA private key. B forwards the private key to A.

120

J. Walker and J. Li

– B receives the challenge from A with entities P0 and P1 . B makes sure both entities have not been corrupted. B simulates the daa-sigma protocol with A as in the key exchange query above, except in step 5, B makes a challenge query to the challenger with P0 , P1 , and m = (s, g y , g x ) as input and obtains a DAA signature σ on (s, g y , g x ) using Pb ’s DAA private key, where b is unknown to B. In the end, B sends [s, idI , g x , σ]k1 to A to simulate the message 3 of the daa-sigma protocol. – A can continue make key exchange and corrupt queries to B as far as A does not make corrupt queries on either P0 or P1 . – A outputs b by guessing b. B outputs the same b . Let  be the probability that A succeeds in breaking the anonymity game of the key exchange protocol. B has the same probability  in breaking the usercontrolled-anonymity game of DAA. Lemma 2. Under the DDH assumption in G and assuming the security of the underlying cryptographic functions sig, mac, prf, daa-sig, the daa-sigma protocol in Section 4 is SK-secure in the model defined in Section 3.2. The proof of this lemma follows the security proof of the SIGMA protocol in [19]. Let us use the term Σ-attacker to denote an SK-adversary attacking against the daa-sigma protocol. We need to prove the two properties of secure key exchange protocol defined in Definition 5. P1. If two uncorrupted parties P and Q complete matching sessions ((idI , g x ), s, idQ ) and (idQ , s, (idI , g x )) respectively under the daa-sigma protocol then, except for a negligible probability, the session key output in these sessions is the same. P2. No efficient Σ-attacker can distinguish a real response from a random response with non-negligible probability. More precisely, if a given Σ-attacker we define 1. Preal (A) = Pr [A outputs 1 when given the real test session key] 2. Prandom (A) = Pr [A ouptus 1 when given a random test session key] then we need to prove that for any Σ-attacker A that |Preal (A)−Prandom (A)| is negligible. For the proof we assume that the Σ-attacker A never exposes the test session, which would represent an attack that does not undermine the protocol directly. 5.1

Proof of Property P1

The proof for the first property in [19] goes over unchanged if we substitute our notion of a pseudo identity for the identity of the initiator and if we replace the initiator’s signature scheme with DAA. Let A be a Σ-attacker and let P and Q be two uncorrupted entities that complete matching sessions ((idI , g x ), s, idQ ) and (idQ , s, (idI , g x )). We want to prove that both sessions output the same session key k0 regardless of A’s operations. It is enough to show that both entities compute the same DH value g xy from which k0 is derived.

Key Exchange with Anonymous Authentication

121

Let us use uP to denote the DH public key send in the message 1 by P where uP = g x with x chosen by P , and vP to denote the DH public key received in the message 2 of session s. Similarly, let uQ be the DH public key received by Q in the message 1 and vQ be the DH public key send by Q in the message 2 where vQ = g y with y chosen by Q. The signature produced by Q during the session s is sigQ (s, uQ , vQ ), while the signature that P verifies the message 2 is sigQ (s, uP , vP ). As s is unique per session, the first signature is the only one that Q ever produces with the value s as session id, then it must be that either all arguments of the first and second signatures are the same, or A creates a forgery on the second signature. As we assume sig is a secure signature scheme, it follows that except for a negligible probably, uP = uQ and vP = vQ . Now x the DH value computed by P is vPx = vQ = (g y )x = g xy , while the DH value y y x y xy computed by Q is uQ = uP = (g ) = g . Thus both compute the same session key. This concludes our proof of property P1. 5.2

Proof of Property P2

The strategy in [19] to prove the second property is to show that any attacker who can distinguish the real key from a random key with non-negligible probability can be used to construct a second attacker against the DDH assumption or one of the underlying primitives – the signature scheme sig, the MAC scheme mac, or the pseudo-random function prf. In our setting, we must replace the initiator’s signature with a DAA signature, and its identity with a pseudo identity. We now sketch the proof as follows. We show that any Σ-attacker A that succeeds in distinguishing between a real and a random response to the test session query, we can build a DDH distinguisher D that distinguishes triple (gx , g y , g xy ) from random triples (g x , g y , g r ) with the same success advantage as A, or there is an algorithm that we can construct explicitly that breaks one of the underlying cryptographic primitives (i.e., sig, mac, prf, or daa-sig). The distinguisher D gets input (g x , g y , z) where z is either g xy or g r for r ← Zq . D starts by simulating a run of A on a virtual instantiation of the daa-sigma protocol Σ and use the values g x and g y from the input triple as the DH public keys in the messages 1 and 2 of a randomly chosen session denoted s0 , initiated by A in this execution of the daa-sigma protocol. If A happens to choose this session s0 as its test session, then D can provide A with z as the response to the test query. In this case, if A outputs that the response was real then D will decide that z = g xy , otherwise, D will decide that z is random. One difficulty with the above strategy is that D actually changes the regular behavior of the parties in session s0 , e.g., it uses the value z to derive the key k1 used in the mac function, we have to show that the original ability of A to distinguish between “real” and “random”is not significantly reduced by the simulation changes. Canetti and Krawczyk [19] addressed the difficulty by defining a sequence of several simulators as follows which differ from each other by the way they choose k0 and k1 used in the simulation of the s0 session.

122

J. Walker and J. Li

ˆ S-real : ˆ S-rprf :

k0 ← prfgxy (0), k1 ← prfgxy (1)

ˆ S-allr : ˆ S-hybr :

k0 ← random(), k1 ← random()

ˆ S-rand :

k0 ← random(), k1 ← prfgxy (1)

k0 ← prfk (0), k1 ← prfk (1), k ← random() k0 ← random(), k1 ← prfk (1), k ← random()

ˆ ˆ S-real is the simulator that corresponds to a “real” run of A while S-rand corresponds to a “random” experiment where the session key in session s0 provided to A is chosen as a random and independent value k0 . The rest of the simulators are “hybrid” simulators. It was shown in [19] that either all the distributions generated by these simulators are computationally indistinguishable, or that a successful distinguisher against DDH or against prf family exists. From this we ˆ ˆ get a proof that S-real and S-rand are indistinguishable, and conclude that the values Prandom and Preal differ by at most a negligible quantity. In the security proof of property P2 by [19], several properties of the protocol are shown that related to the authentication elements such as signatures (Lemma 7 in [19]) and mac (Lemma 11 in [19]). In the daa-sigma protocol, we replace the protocol initiator’s signature with a DAA signature. We can show that – If A does not have access to any legitimate DAA private keys, then Lemma 7.4 in [19] can be used to break the unforgeability property of DAA. – If A does control some valid DAA private keys, then the commitment in the pseudo identity guarantees that the adversary cannot break the session key of two uncorrupted parties unless he can break DDH assumption. The above arguments easily follow the proof in [19]. The details will be given in the full paper.

6

Discussions and Extensions

In this section, we discuss several variants and possible extensions of the our daa-sigma protocol. 6.1

Using Group Signatures Instead of DAA

Although this paper primarily focuses on DAA, our daa-sigma protocol can be easily extended to support group signatures [2, 5, 6, 29]. Both DAA and group signatures are group-based anonymous signature schemes. Group signatures are different from DAA in that group signatures can be opened by a trusted authority and the identity of the actual signer can be extracted, whereas DAA signature cannot be opened. To use a group signature scheme in the key exchange protocol for anonymous authentication, we can replace the DAA signature in the daa-sigma protocol with a group signature. We called the modification as gs-sigma protocol. More

Key Exchange with Anonymous Authentication

123

specifically, we assume party P has a group private key issued by an issuer I. We use idI to denote the identity of the issuer and gs-sigP (m) to denote a group signature on m created by P . The gs-sigma protocol has the following messages Message 1 (P → Q) : s, g x Message 2 (P ← Q) : [s, idQ ]k1 , g y , sigQ (s, g x , g y ) Message 3 (P → Q) : [s, idI , g x , gs-sigP (s, g y , g x )]k1 This gs-sigma protocol is secure in the key exchange model for anonymous authentication defined in Section 3, if the DDH assumption holds and if the underlying sig, mac, prf, and gs-sig functions are secure. The security proof is straight-forward from Section 5. 6.2

Use Certificates Instead of Identities

In the daa-sigma protocol presented in Section 4, idI and idQ represent the real identities of the issuer and the party Q, respectively. We assume that P can obtain Q’s public key using idQ , and similarly Q can obtain P ’s DAA public key from the identity of the issuer idI . In practice, we can replace the identities with full certificates signed by a trusted Certificate Authority (CA). More specifically, assume all the parties share the public key of the trusted CA. If an entity has a regular public and private key pair, we assume it has a public-key certificate issued by the trusted CA. If an entity has a DAA private key, we assume it has a certificate issued by the trusted CA to certify the issuer and the DAA public key, denoted as certI . The certificate-based daa-sigma protocol is presented as follows. Message 1 (P → Q) : s, g x Message 2 (P ← Q) : [s, certQ ]k1 , g y , sigQ (s, g x , g y ) Message 3 (P → Q) : [s, certI , g x , daa-sigP (s, g y , g x )]k1 Note that, in the above protocol, the protocol participants P and Q do not need to retrieve public keys from the identities. Instead, they can use the public keys embedded in the certificate to verify the signatures in messages 2 and 3. Canetti and Krawczyk proved the certificate-based SIGMA protocol is secure in [19]. The security proofs for our certificate-based daa-sigma protocol work as well. 6.3

Supporting User-Controlled-Traceability and DAA Revocation

As we mentioned earlier, the DAA signing algorithm takes the verifier’s basename bsn as an optional input. If the basename is not given in the signing algorithm, we treat bsn = ⊥. DAA signatures are unlinkable if bsn = ⊥ and linkable otherwise. This feature is called user-controlled-traceability in [9], as the signer and verifier can negotiate whether to use basename. The daa-sigma protocol in Section 4 only supports unlinkable DAA signatures, but it can be easily extended to support user-controlled-traceability by passing the basename value in the protocol messages.

124

J. Walker and J. Li

Another important feature of DAA is revocation. A revocation method in DAA proposed in [10, 11] is called signature-based revocation, where the issuer can revoke a DAA signer without knowing the signer’s private key. In this revocation method, the issuer puts DAA signatures that are suspicious or were involved in malicious transactions to a revocation list denoted as sRL. The verifier can request the signer to prove that his DAA signing key did not generate those signatures in the revocation list. To support this type of revocation, the verifier needs to sends the revocation list to the signer so that signer can prove innocent. To support this revocation method in the daa-sigma protocol, the revocation list sRL needs to be passed in the protocol messages. We now extend the daa-sigma protocol to support the above two functionalities of DAA as follows. In the following protocol, variables in brackets are optional fields. Message 1 (P → Q) : s, g x , idI Message 2 (P ← Q) : [s, idQ , bsnQ , sRL]k1 , g y , sigQ (s, g x , g y ) Message 3 (P → Q) : [s, idI , g x , daa-sigP (s, g y , g x )]k1 To support user-control-traceability feature of DAA, Q can send its basename bsnQ in the message 2 so that P can create the DAA signature with bsnQ as input. To support signature-based revocation, P first reveals its DAA group (in this case, the identity of the issuer idI ) to Q who can find the corresponding revocation list sRL of the DAA group. Q then sends sRL to P in the message 2 so that P can prove he has not been revoked in the message 3 as part of the DAA signature. 6.4

Mutual Anonymous Authentication Using DAA

The daa-sigma protocol presented in Section 4 is a key exchange protocol with unilateral anonymous authentication. Take the example in Section 1, it is natural to have the protocol initiator as the anonymous entity. It may not make sense for mutual anonymous authentication over the Internet, as the protocol initiator needs to know who is the protocol responder in order to know where to send the first message. Mutual anonymous authentication may be useful for ubiquitous computing environments or for vehicle communication where two entities (e.g., mobile devices or cars) are already physically close to each other and want to authenticate to each other anonymously. We can extend the daa-sigma protocol to support mutual anonymous authentication as follows. Assume each protocol party have a DAA private key for computing anonymous signatures, i.e., P has a DAA key issued by an issuer I and Q has a DAA key issued by an issue I  , where I and I  could be the same entity or two separate entities. The messages 1 and 3 are the same as in the Section 4. In message 2, Q uses (idI  , g y ) as its pseudo identity instead of revealing its actual identity idQ in order to be anonymous in the key exchange.

Key Exchange with Anonymous Authentication

125

Message 1 (P → Q) : s, g x Message 2 (P ← Q) : [s, idI  , g y , daa-sigQ (s, g x , g y )]k1 Message 3 (P → Q) : [s, idI , g x , daa-sigP (s, g y , g x )]k1

7

Conclusions and Future Work

We presented in this paper a new security model for key exchange with anonymous authentication derived from the Canetti-Krawczyk key exchange model. We proposed a modification to the SIGMA key exchange protocol with DAA incorporated and with the notion of pseudo identity to achieve anonymous authentication. We proved our daa-sigma key exchange protocol is secure under the new security model. Future related research topics include 1. Provide a formal security model for mutual anonymous authentication and prove our mutual anonymous authentication protocol in Section 6 is secure. 2. Study how to incorporate DAA into SSL/TLS protocol with provable security under our new security model.

Acknowledgement We thank Liqun Chen for her suggestions on related work of anonymous authentication using ring signatures and anonymous password-based key exchange. We thank Emanuele Cesena for clarifying the DAA usage in the TPM. We thank anonymous INTRUST reviewers for their helpful suggestions.

References 1. ISO/IEC PAS DIS 11889: Information technology – Security techniques – Trusted platform module 2. Ateniese, G., Camenisch, J., Joye, M., Tsudik, G.: A practical and provably secure coalition-resistant group signature scheme. In: Bellare, M. (ed.) CRYPTO 2000. LNCS, vol. 1880, pp. 255–270. Springer, Heidelberg (2000) 3. Balfe, S., Lakhani, A.D., Paterson, K.G.: Trusted computing: Providing security for peer-to-peer networks. In: Proceedings of the 5th IEEE International Conference on Peer-to-Peer Computing, pp. 117–124 (August 2005) 4. Bellare, M., Rogaway, P.: Entity authentication and key distribution. In: Stinson, D.R. (ed.) CRYPTO 1993. LNCS, vol. 773, pp. 232–249. Springer, Heidelberg (1994) 5. Boneh, D., Boyen, X., Shacham, H.: Short group signatures. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 41–55. Springer, Heidelberg (2004) 6. Boneh, D., Shacham, H.: Group signatures with verifier-local revocation. In: Proceedings of 11th ACM Conference on Computer and Communications Security, pp. 168–177 (October 2004) 7. Brickell, E., Camenisch, J., Chen, L.: Direct anonymous attestation. In: Proceedings of the 11th ACM Conference on Computer and Communications Security, pp. 132–145. ACM Press, New York (2004)

126

J. Walker and J. Li

8. Brickell, E., Chen, L., Li, J.: A new direct anonymous attestation scheme from bilinear maps. In: Lipp, P., Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 166–178. Springer, Heidelberg (2008) 9. Brickell, E., Chen, L., Li, J.: Simplified security notions of direct anonymous attestation and a concrete scheme from pairings. International Journal of Information Security 8(5), 315–330 (2009) 10. Brickell, E., Li, J.: Enhanced Privacy ID: A direct anonymous attestation scheme with enhanced revocation capabilities. In: Proceedings of the 6th ACM Workshop on Privacy in the Electronic Society, pp. 21–30 (October 2007) 11. Brickell, E., Li, J.: Enhanced Privacy ID from bilinear pairing for hardware authentication and attestation. In: Proceedings of 2nd IEEE International Conference on Information Privacy, Security, Risk and Trust, pp. 768–775 (2010) 12. Brickell, E., Li, J.: Enhanced Privacy ID: Hardware attestation beyond TPM. In: First Workshop on Anonymous Digital Signatures: Mechanisms & Usages (2010), http://www.trust2010.org/workshop-anon.html 13. Brickell, E., Li, J.: A pairing-based DAA scheme further reducing TPM resources. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 181–195. Springer, Heidelberg (2010) 14. Camenisch, J., Lysyanskaya, A.: An efficient system for non-transferable anonymous credentials with optional anonymity revocation. In: Pfitzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol. 2045, pp. 93–118. Springer, Heidelberg (2001) 15. Camenisch, J., Lysyanskaya, A.: A signature scheme with efficient protocols. In: Cimato, S., Galdi, C., Persiano, G. (eds.) SCN 2002. LNCS, vol. 2576, pp. 268–289. Springer, Heidelberg (2003) 16. Camenisch, J., Lysyanskaya, A.: Signature schemes and anonymous credentials from bilinear maps. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 56–72. Springer, Heidelberg (2004) 17. Canetti, R.: Universally composable security: A new paradigm for cryptographic protocols. In: Proceedings of the 42nd IEEE Symposium on Foundations of Computer Science, pp. 136–145. IEEE Computer Society, Los Alamitos (2001) 18. Canetti, R., Krawczyk, H.: Analysis of key-exchange protocols and their use for building secure channels. In: Pfitzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol. 2045, pp. 453–474. Springer, Heidelberg (2001) 19. Canetti, R., Krawczyk, H.: Security analysis of IKE’s signature-based key-exchange protocol. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 143–161. Springer, Heidelberg (2002) 20. Cesena, E., L¨ ohr, H., Ramunno, G., Sadeghi, A.-R., Vernizzi, D.: Anonymous authentication with TLS and DAA. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 47–62. Springer, Heidelberg (2010) 21. Chai, Z., Cao, Z., Lu, R.: Efficient password-based authentication and key exchange scheme preserving user privacy. In: Cheng, X., Li, W., Znati, T. (eds.) WASA 2006. LNCS, vol. 4138, pp. 467–477. Springer, Heidelberg (2006) 22. Chaum, D., van Heyst, E.: Group signatures. In: Davies, D.W. (ed.) EUROCRYPT 1991. LNCS, vol. 547, pp. 257–265. Springer, Heidelberg (1991) 23. Chen, L., Morrissey, P., Smart, N.P.: Pairings in trusted computing. In: Galbraith, S.D., Paterson, K.G. (eds.) Pairing 2008. LNCS, vol. 5209, pp. 1–17. Springer, Heidelberg (2008) 24. Chen, L., Page, D., Smart, N.P.: On the design and implementation of an efficient DAA scheme. In: Gollmann, D., Lanet, J.-L., Iguchi-Cartigny, J. (eds.) CARDIS 2010. LNCS, vol. 6035, pp. 223–237. Springer, Heidelberg (2010)

Key Exchange with Anonymous Authentication

127

25. Chen, X., Feng, D.: Direct anonymous attestation for next generation TPM. Journal of Computers 3(12), 43–50 (2008) 26. Cui, H., Cao, T.: An novel anonymous authenticated and key exchange protocol. Journal of Networks 4(10), 985–992 (2009) 27. Datta, A., Derek, A., Mitchell, J.C., Warinschi, B.: Computationally sound compositional logic for key exchange protocols. In: Proceedings of 19th IEEE Computer Security Foundations Workshop, pp. 321–334 (2006) 28. Diffie, W., van Oorschot, P.C., Wiener, M.J.: Authentication and authenticated key exchanges. Designs, Codes and Cryptography 2(2), 107–125 (1992) 29. Furukawa, J., Imai, H.: An efficient group signature scheme from bilinear maps. IEICE Transactions 89-A(5), 1328–1338 (2006) 30. Harkins, D., Carrel, D.: The Internet key exchange (IKE). IETF RFC 2409 (November 1998) 31. Kent, S., Atkinson, R.: Security architecture for the Internet protocol. IETF RFC 2401 (November 1998) 32. Leung, A., Mitchell, C.J.: Ninja: Non identity based, privacy preserving authentication for ubiquitous environments. In: Krumm, J., Abowd, G.D., Seneviratne, A., Strang, T. (eds.) UbiComp 2007. LNCS, vol. 4717, pp. 73–90. Springer, Heidelberg (2007) 33. Meadows, C.: Analysis of the Internet key exchange protocol using the NRL protocol analyzer. In: Proceedings of IEEE Symposium on Security and Privacy, pp. 216–231 (1999) 34. Trusted Computing Group. TCG TPM specification 1.2 (2003), http://www.trustedcomputinggroup.org 35. Trusted Computing Group website, http://www.trustedcomputinggroup.org 36. Viet, D., Yamamura, A., Tanaka, H.: Anonymous password-based authenticated key exchange. In: Maitra, S., Veni Madhavan, C.E., Venkatesan, R. (eds.) INDOCRYPT 2005. LNCS, vol. 3797, pp. 244–257. Springer, Heidelberg (2005)

Revocation of Direct Anonymous Attestation Liqun Chen1 and Jiangtao Li2 1

Hewlett-Packard Laboratories, UK [email protected] 2 Intel Labs, USA [email protected]

Abstract. Direct Anonymous Attestation (DAA) is a special type of anonymous digital signatures, used by the Trusted Computing Group (TCG) for the purpose of computer platform attestation whilst preserving platform anonymity. Like any other anonymous cryptographic primitives, how to efficiently revoke an existing member who is no longer legitimate, is an important and challenging subject for DAA. In this paper, we first explain two general DAA revocation approaches and a number of different DAA revocation degrees. We then present a variety of revocation mechanisms, which enable us to achieve these approaches and degrees in the existing three types of DAA schemes. Some of these mechanisms have already been shown in the literature and others are newly proposed in this paper. Keywords: direct anonymous attestation (DAA), revocation, rekeybased revocation, verifier-local revocation.

1

Introduction

Direct Anonymous Attestation (DAA) is a special type of digital signatures that preserve signer’s privacy (i.e., DAA signatures are anonymous and optionally unlinkable). Here anonymity means that the identity of the signer is not revealed from his signatures and unlinkability means that whether two signatures were produced by the same signer cannot be determined from the signatures. A DAA scheme is often seen as a variant of a group signature scheme. A DAA signature, similar to a group signature, allows the signer to demonstrate knowledge of a signer’s individual private key with respect to a public key belonging to a group, and the signature is publicly verifiable by anybody who has access to the group public key. Unlike group signatures, DAA signatures are anonymous not only to signature verifiers, but also to the group manager who is in the possession of the associated group secret key. DAA allows a signature verifier to learn the signer’s identity if the verifier knows the signer’s private key, and DAA also allows a verifier to learn whether two signatures were produced by the same signer if the signer includes a special proof of such a link in both of the signatures. These features make DAA signatures attractive for many applications, one of which is remote anonymous authentication of trusted computing platforms, in which a platform attests certain information, such as the configuration of the L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 128–147, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Revocation of Direct Anonymous Attestation

129

platform, to a remote verifier whilst maintaining anonymity of the platform. The concept and the first concrete scheme of DAA were introduced by Brickell, Camenisch, and Chen [4]. Their DAA scheme was adopted by the industry standardization body Trusted Computing Group (TCG) in 2003, and specified in the TCG TPM Specification version 1.2 [26] that has recently been adopted by ISO/IEC as an international standard [1]. A number of DAA schemes have been developed since then, e.g. [23,7,5,15,16,19,13,18,9,14], and most of them have been proved secure under either the security model of [4] or the model of [6]. Observe that to be truly useful in practice, a DAA scheme must support dynamic group membership, which means supporting growing membership, i.e. new members can join without precipitating changes in the group public key or re-issuing group membership credentials for existing members, and as well as supporting shrinking group membership, i.e. illegitimate members can be revoked in an efficient way. The property of growing membership has been well-supported by all the existing DAA schemes. But shrinking group membership has not been given the same attention. For a variety of reasons, an existing group member can be no longer legitimate, e.g., the member’s private key has been hacked, the member might leave the group voluntarily, or he might be excluded by the group membership issuer. A typical example of using a DAA scheme is that in the TCG environment the DAA signer is a Trusted Platform Module (TPM) embedded in a computer platform. If the TPM has been corrupted and its DAA private key is publicly revealed, the TPM is considered to be an invalid group member and needs to be revoked from the group. Consider another example, suppose a DAA scheme is implemented in identity cards for college students. Each student can use his or her card to access college resources. If the identity card of a student is stolen or lost, or if the student has graduated from the college, the issuer (the college) may want to revoke the DAA private key of the student in the identity card. In any case, after a DAA signer is revoked, DAA verifiers should reject any signatures created by the signer. Although there have been a number of DAA signer revocation mechanisms presented in the literature, such as [4,7,16], to the best of our knowledge, this important topic has not been fully explored. This is the motivation of this paper. There are a number of contributions in this paper. We describe each contribution briefly as follows. Classification of DAA revocation techniques. We categorize a variety of DAA revocation solutions into two general approaches, and name them rekey-based revocation (rekey for short) and verifier-local revocation (VLR for short). We also introduce a number of different revocation degrees for DAA, namely key revocation, key+credential revocation, key+verifier revocation, and key+credential+verifier revocation; the details will be given in Section 2.2. New DAA revocation mechanisms. We review the existing DAA schemes within three categories, namely RSA-DAA, LRSW-DAA, and SDH-DAA, and then review the existing four DAA revocation solutions. After that, we propose a number of new DAA revocation mechanisms, covering both the rekey and VLR

130

L. Chen and J. Li

approaches. We demonstrate how these revocation mechanisms can be used with the three types of the existing DAA schemes. A comparison of all the DAA revocation solutions. We provide a comprehensive survey of all the DAA revocation mechanisms, including the already existing mechanisms and the new ones. We show comparisons of all the VLR methods, and comparisons between the rekey and VLR approaches. We also discuss how these two approaches can be used together in one application. The main purpose of this work is to introduce the concept of the two DAA revocation approaches and a number of practical revocation mechanisms. This paper provides neither a formal security model for DAA revocation nor a rigorous security proof of the proposed revocation mechanisms. We will leave the formalization of the security model and analysis to the future work. The rest of this paper is organized as follows. We first introduce in the next section the general concept of DAA revocation, including the meanings of the two general revocation approaches and security properties. We then review three types of the existing DAA schemes in Section 3 and review four existing DAA revocation solutions in Section 4. In the following two sections, we present the rekey and VLR revocation approaches, respectively, in details. We compare different revocation mechanisms and discuss how they can be used together in Section 7. We conclude the paper with the summary and future work in Section 8.

2 2.1

General Concept of DAA Revocation Two Approaches

In the literature, a DAA scheme involves four types of players: a set of DAA issuers ik ∈ I, TPMs mi ∈ M, hosts hi ∈ H and verifiers vj ∈ V. The index values, k, i, j, are polynomial. Each pair of mi and hi form a computer platform in the trusted computing environment and share the role of a DAA signer. Throughout the paper, for the purpose of simplicity, we may omit some of the index values, i.e., we make use of i, m, h and v instead of ik , mi , hi and vj . A DAA scheme DAA = (Setup, Join, Sign, Verify, Link) consists of the following five polynomial-time algorithms and protocols: – Setup: On input of a security parameter 1t , an issuer i uses this randomized algorithm to produce its secret key isk, and public key ipk (for simplicity we let ipk include all the system public parameters). We will assume that ipk is publicly known so that we do not need to explicitly provide it as input to other algorithms. – Join: This protocol, run between a signer (m, h) and an issuer i, creates the TPM’s secret key tsk and its DAA credential cre. The value tsk is generated (and then secretly kept) by m, and the value cre is generated by i based on isk and sent to h. – Sign: On input of tsk, cre, a basename bsn (either the name string of the verifier v or a special symbol ⊥), a message m to be signed and v’s nonce nV for freshness, m and h run this protocol to produce a signature σ.

Revocation of Direct Anonymous Attestation

131

– Verify: On input of m, bsn, a candidate signature σ for m, and a set of rogue signers’ secret keys, denoted by RogueList, v uses this deterministic algorithm to return either 1 (accept) or 0 (reject). Note that how to build RogueList is out the scope of a DAA scheme. – Link: On input of two signatures σ0 and σ1 , v uses this deterministic algorithm to return 1 (linked), 0 (unlinked) or ⊥ (invalid signatures). Note that, unlike Verify, the result of Link is not relied on RogueList. Generally speaking, DAA revocation can be achieved with either or both of the following two approaches: 1. Rekey-based Revocation. To revoke any illegitimate DAA signer(s), an issuer i updates its public key ipk (which might or might not involve updating the corresponding secret key isk) and then allows only the credentials of all legitimate signers to be updated accordingly. In the algorithms of Sign, Verify and Link, the newly updated keys and credentials will replace the old keys and credentials. To implement this revocation approach in a DAA scheme, we add a new algorithm called Rekey in DAA as follows: – Rekey: On input of the current values of ipk, isk, all crei for the legitimate signer (mi , hi ), and all crel for the illegitimate signer (ml , hl ), this randomized algorithm outputs the updated values of ipk, isk and crei . Note that the value isk may be the same after running Rekey. Note also that this algorithm may not require interaction between i and mi /hi . 2. Verifier-Local Revocation (VLR). To revoke a set of illegitimate DAA signers, a verifier v takes as an extra input a revocation list, say RL, to Verify and then only accepts any signatures from those signers who are not listed in RL. To implement this revocation approach in a DAA scheme, we slightly modify the above Sign and Verify algorithms in DAA to the following: – Sign: On input of tsk, cre, a basename bsn, (optionally) a revocation list RL1 along with an indication about which type of the proof is required in the signature, a message m to be signed and v’s nonce nV for freshness, m and h run this protocol to produce a signature σ. – Verify: On input of m, bsn, a candidate signature σ for m, and a revocation list RL, v uses this deterministic algorithm to return either 1 (accept) or 0 (reject). Note that a rogue signer must be included in RL so the set of rogue signers’ secret RogueList is covered by RL. Note also that how to build RogueList and RL is out the scope of this paper. The concept of VLR is a modification of the concept of VLR in group signatures [3]. The difference is that the DAA VLR is under the observation and cooperation of a signer, i.e., a signer and a verifier agree on a linking method to enable the verifier to build his own revocation list. Whereas in group signatures, VLR is a delegating function of the opening authority, and therefore is achieved transparently from signers. 1

Whether such a revocation list is needed or not is dependent on the specific VLR mechanism used.

132

L. Chen and J. Li

Remark 1. Users can choose to use any of the above two approaches in a DAA scheme, and can alternatively use both of them together in one DAA scheme. 2.2

Security Properties

In the literature, there are two security models used to define security of a DAA scheme. The first DAA security model introduced in [4] is presented using the ideal-system/real-system model and the second one introduced in [6] is presented with three notions: correctness, user-controlled-anonymity and user-controlledtraceability. The last two notions in the second model are each described by a game run between an adversary and a simulator. Due to limited space, we do not recall these two models here. Informally, these security definitions require the following four properties to be held in a DAA scheme: 1. Correctness. It ensures that a signature signed under a valid pair of tsk and cre verifies correctly. 2. Anonymity. An adversary not in possession of a tsk cannot trace the identity of the signer from its signature. 3. Unforgeability. An adversary, which has corrupted a set of tsk’s and their cre’s, finds it hard to forge a valid signature under a pair of tsk and cre, which are not in the set. 4. User-controlled traceability. On the one hand, given a single basename bsn (= ⊥), an adversary is not able to create two different signatures associated with bsn signed under the same tsk, but the output of the algorithm Link is 0 (unlinked). On the other hand, given two signatures σ0 and σ1 associated with two different basenames bsn0 and bsn1 respectively, an adversary not in possession of the relevant tsk(s) finds it hard to tell whether or not the two signatures are signed by the same signer. Broadly speaking, DAA revocation requires if a DAA signer has been revoked, the revoked signer is no longer able to create any valid DAA signatures. A valid signature means the verification algorithm with this signature outputs accept. But what do we mean that a signer is revoked? In order to answer this question, we first consider a few simple facts in use of a DAA scheme: – To create a signature, a signer needs a pair of tsk and cre. If tsk is compromised, the signer should be revoked, no matter whether the associated cre is compromised or not. – A signer might have two credentials cre0 and cre1 , both associated with a single tsk. The pair (tsk, cre0 ) might be revoked, but the pair (tsk, cre1 ) might still be valid. – Using a pair of tsk and cre, a signer might create signatures for different verifiers. The signer may be revoked or black-listed by one verifier, but may not be revoked by another verifier. In order to address the security notion of DAA revocation to cover the above facts, we identify the following four different revocation degrees for DAA, each of which indicates one specific level what we mean by that a signer is revoked:

Revocation of Direct Anonymous Attestation

133

– Key revocation. We say that a tsk is revoked if any signature signed under this key is rejected no matter which cre is used and no matter which verifier the signature was signed for. – Key+credential revocation. We say that a pair of tsk and cre are revoked if any signature signed under this key and credential pair is rejected no matter which verifier the signature was signed for. In that case, a signature signed under the same tsk but a different cre could still be valid. – Key+verifier revocation. We say that a tsk is revoked with a certain verifier if any signature signed under this key for this verifier is rejected no matter which cre is used. – Key+credential+verifier revocation. We say that a pair of tsk and cre are revoked with a certain verifier if any signature signed under this key and credential pair for this verifier is rejected. In this case, another signature signed under this key with a different credential or for a different verifier could still be valid. Remark 2. With this notion of DAA revocation, we assume that each signer has a single tsk and each verifier has a single bsn. If a user (or a verifier) has two keys (or two bsn values), he/she plays the role of two signers (or verifiers). Remark 3. We say a revocation mechanism holds the property of backward validation if a signature created before the signer is revoked remains valid even after the signer is revoked. This property is also called backward unlinkability in [25]. We notice that the property of backward validation is not always suitable for a DAA scheme, since it probably allows a revoked signer to create a signature and then to claim it was signed before revocation. Time stamps can sometimes avoid this drawback, but a time stamp is not usually included in the description of the DAA scheme. In our above notion of DAA revocation, in order to achieve backward validation, a certain time period can be included in the description of a verifier in the key+verifier revocation. However, there might be issues related to anonymity with time stamps; for example, the time-zone information contained by the time stamp results in a limitation of the anonymity protection as the signer can be related to a certain region. The users should take this concern into account when using time-stamps in any anonymous signatures, such as DAA.

3

Review Three Types of DAA Schemes

Since the original DAA scheme [4] was adopted by the Trusted Computing Group in 2003 [26], researchers have developed a large number of DAA schemes, such as [5,15,19,13,9,18,14], to list a few. For the purpose of this paper, we review the existing DAA schemes within three categories, as respectively shown in the following three subsections. The three categories cover most of the DAA schemes we know. Security of each category is based on a certain computationally-hard problem. Our review includes only the necessary information, which enables us to present our revocation mechanisms for these schemes in Sections 5 and 6, and we refer the details of these schemes to their original papers.

134

3.1

L. Chen and J. Li

The RSA-DAA Scheme

The original DAA scheme proposed by Brickell, Camenisch, and Chen [4] is based on the strong RSA assumption [22]. We now give a brief review of this scheme using the same notation as in the paper [4], and we denote this scheme RSADAA. In this scheme, the issuer’s private key is the factorization of a modulus n, and its public key includes (R0 , R1 , S, Z, n, Γ ). The signer’s secret is tsk = (f0 , f1 ) and the corresponding credential is cre = (e, A, v), such that the triple (e, A, v) is a Camenisch-Lysyanskaya signature [11] on (f0 , f1 ). See [4] for the sizes of these values. A DAA signature is a proof of knowledge of values f0 , f1 , A, e, and v under a given verifier’s base name bsn, such that Ae R0f0 R1f1 S v ≡ Z mod n and NV ≡ ζ f0 +f1 2

f

where the value ζ is computed from bsn and NV = ζ f0 +f1 2 by the signer. Both (ζ, NV ) are part of the signature. 3.2

f

mod Γ, mod Γ is computed

The LRSW-DAA Schemes

Several pairing based DAA schemes [5,15,16,18,14] have recently been proposed using the LRSW assumption [24]. We now give a brief review of these schemes, and denote this type of DAA schemes LRSW-DAA. Let e : G1 × G2 → GT be a computable bilinear map function. Note that the scheme in [5] makes use of a symmetric pairing, i.e. G1 = G2 . For simplicity, we do not distinguish between the LRSW-DAA schemes using symmetric or asymmetric pairings. In a LRSWDAA scheme, the issuer’s private key is (x, y) ∈ Zp for a prime p and the public key includes (p, P1 , P2 , X = [x]P2 , Y = [y]P2 ), where P1 ∈ G1 and P2 , X, Y ∈ G2 . The signer’s secret tsk is f ∈ Zp and the corresponding DAA credential cre is (A, B, C), which is a Camenisch-Lysyanskaya signature [12] of the value f . A DAA signature is a proof of knowledge of values f , A, B and C under a given base name bsn, such that A = [r]P1 , B = [y]A, C = [x + xyf ]A for a random r ∈ Zp , and K = [f ]J, where J is an element of G1 , GT or a different cyclic group, computed from bsn. 3.3

The SDH-DAA Schemes

A few pairing-based DAA schemes [19,13,9,8] were developed based on the Strong Diffie-Hellman (SDH) assumption [20]. We now give a brief review of these schemes, and denote this type of DAA schemes SDH-DAA. Let e : G1 ×G2 → GT be a computable bilinear map function. In a SDH-DAA scheme, the issuer’s private key is γ and its public key includes (p, g1 , h1 , h2 , g2 , w = [γ]g2 ), where p is a large prime, g1 , h1 , h2 ∈ G1 , and g2 , w ∈ G2 . The signer’s secret tsk is f ∈ Zq and the corresponding DAA credential is cre = (A, x) where x is randomly chosen from Zp and A = [1/(γ + x)](g1 + [f ]h1 ); note that (A, x) is a BBS

Revocation of Direct Anonymous Attestation

135

signature [2] on the value f . A DAA signature is a proof of knowledge of the values f , A, and x under a give base name bsn such that A = [1/(γ + x)](g1 + [f ]h1 ) and K = [f ]J, where J is an element of G1 or a different cyclic group, computed from bsn. Observe that in some SDH-DAA schemes [19,8], an extra value y is included, such that A = [1/(γ +x)](g1 +[f ]h1 +[y]h1 ) and cre = (A, x, y). As proved in [13], one can remove this value while maintaining the same security level. Therefore, in this paper, we do not distinguish between the SDH-DAA schemes with and without the y value.

4

Review of the Existing Revocation Solutions

Currently, there are four types of revocation solutions are known for DAA. The first two solutions were proposed in the original DAA paper [4], whilst the third and forth have recently been proposed in [7] and [16] respectively. The following is a brief summary of these four solutions: 1. Revocation is consequent upon a signer’s DAA secret becoming known. Anybody believing they have come into possession of a signer’s DAA secret (which, of course, should not happen) can put the secret into the rogue list RogueList and then check if this is truly the case by carrying out a check to verify whether a DAA signature from the signer was signed using the secret in RogueList or not - if yes, the signature is rejected as the signer’s DAA secret has clearly been compromised. 2. A verifier builds his own black list of unwelcome signers. In order to find whether a DAA signature was signed by a black-listed signer, the Verifier must require the signer to use a specific basename in his DAA signature. 3. In each DAA signature, a signer is required to prove, in a zero-knowledge proof manner, that his private signing key is not listed in a black list maintained by a revocation manager. 4. A DAA issuer updates his key either in a fixed interval or a flexible period. At each update of his keys the issuer also correspondingly updates each DAA credential it holds unless, from the issuer’s knowledge, a signer is no longer a legitimate DAA signer. We organize these four solutions into the two approaches described in Section 2.1: rekey-based revocation covering the solution 4, and verifier-local revocation covering all the other three solutions. In the next two sections, we will detail these two approaches and introduce a variety of mechanisms in each approach.

5 5.1

Rekey-Based Revocation An Overview

In a DAA scheme, a signer can create a valid signature if the signer holds a valid DAA credential, which is created by a DAA issuer using the issuer’s private key. The signature can then be verified by using the issuer’s public key.

136

L. Chen and J. Li

A rekey-based DAA revocation solution is that the issuer updates his public key (optionally with the private key as well) when needed. At each update of his keys the issuer also correspondingly updates each DAA credential it holds unless, from the issuer’s knowledge, a signer is no longer a legitimate DAA signer. Subsequent executions of the sign protocol are affected on the basis of the signer’s updated credential and the subsequent verification algorithm are also affected using the updated public key of the issuer. If a signer’s DAA credential has not been updated in correspondence with the updating of the issuer’s public key, verification of the signer’s DAA signature by the Verifier will fail thereby giving effect to revocation of the signer’s privilege of a legitimate DAA signer. A naive implementation of rekey is letting each legitimate signer rejoin the group by running the Join protocol. Obviously this is not an efficient solution. A better method is that the issuer can recompute each legitimate signer’s credential without the signer’s involvement. This type of solution is called non-interactive rekey. The general idea of this solution was introduced in [16]. In this paper, we will present some new implementations of this solution. The process of rekey can be done in a fixed time interval. The advantage of this choice is that each entity knows when the rekey process happens. The drawback is that any illegitimate signer cannot be revoked within the interval. The process of rekey can also be done flexibly when the group shrinks with some members leaving. Obviously the advantage and disadvantage of this choice is opposite to the previous one. The selection of the fixed interval, the flexible interval, and the length of the interval are dependent on applications. Observe that a DAA signature is not traceable from the corresponding DAA credential. Even if the credential is published, the DAA scheme can still hold the properties of user-controlled-anonymity and user-controlled-traceability. As a consequence, it is acceptable for the issuer to maintain a publicly available list of all signers’ credentials, or at least of those credential elements subject to updating. A few options on how the updated credential can be made available to the host have been suggested [16], see the following for a summary: – Each signer downloads its own credential value from the list. This assumes some appropriate identifier of each list entry is provided; alternatively the issuer can create an index, where each signer has an reference number, which is not linked to its secret or credential but uniquely indicates the signer - in this case, the signer may wish to check the message authentication of the published list before downloading the updated value and this can be done by using an ordinary signature scheme. – Although revocation of a signer need not result in removal of the corresponding entry from the public list maintained by the issuer (the non-updating of the updatable elements being adequate to effect revocation), it is preferable to remove such entries to minimise the size of the list. – If the issuer desires to make updated credential elements available only to their respective signers, he can encrypt each updated credential under a public key belonging to the signer (e.g., if the signer is a TPM and its host, this key could be the TPM’s public endorsement key). The issuer can choose

Revocation of Direct Anonymous Attestation

137

either listing the cipher-text rather than the plain-text on the public list maintained by the issuer, or making this information publicly unavailable. Details of how the issuer’s key and a signer’s credential are updated by the issuer will be given in the following three subsections, respectively for the RSADAA scheme, the LRSW-DAA schemes and the SDH-DAA schemes. 5.2

Rekey in the RSA-DAA Scheme

In the Join protocol of the RSA-DAA scheme reviewed in Subsection 3.1, the signer chooses secret keys f0 and f1 , picks a random value v , and then sends  the commitment U = R0f0 R1f1 S v mod n to the issuer. The issuer then picks v   and e, and computes A = (Z/U S v )1/e mod n. Let v = v  + v  . The signing key (f0 , f1 , e, A, v) satisfies the equation Ae R0f0 R1f1 S v = Z mod n. To support rekey, we assume the issuer stores at least the following items from the join protocol with each signer: the commitment U of the signer’s secret keys, the quantity e, and the quantity v  . Alternatively to storing U and v individually, the quantity   U S v can be stored. In a typical setting, the issuer stores U S v and the triple (e, A, v ) for each signer. We now describe a variety of updating methods as follows. The first one is a recall of [16]. 1. To update the issuer’s public key and the DAA credential of each currentlylegitimate signer, the issuer simply chooses a new value for Z, here called Z  , and, for each currently-legitimate signer computes a new value for A, here called A , as:  A = (Z  /U S v )1/e mod n. The issuer then publishes Z  to replace the value of Z in its previously published public key; the issuer also publishes a new non-interactive proof of the fact that R0 , R1 , S, Z, g, and h are computed correctly i.e. that g, h ∈ g  , S, Z ∈ h and R0 , R1 ∈ S. For each updated credential, the issuer makes the newly computed value A available to the corresponding signer to enable the signer to update its credential by replacing the previous value of A with A . 2. When the size of the group with all signers is small, the above updating process can be simplified as follows. Let G be the group, and suppose the value of ei for each i ∈ G is known to all the members of G. Let H be a subgroup of G, i.e. H ⊂ G. If the issuer wants to revoke all the members in H, he randomly chooses an integer r ∈ φ(n), computes Z  = Z r mod n and Z  = Z · Z  mod n, and publishes a = (Z  )1/

 i∈G\H

ei

mod n,

with the announcement that the value of ek for each k ∈ H has been revoked and the value Z in the public key has been updated to Z  . Each member

138

L. Chen and J. Li

who is still legitimate, say j ∈ / H, can update his own membership credential as  / =j ei mod n = A · (Z  )1/ej . A = A · a i∈G,i∈H,i Each revoked member k ∈ H is not able to update her membership credential. 3. Another alternative of rekey-based revocation for the RSA-DAA scheme is to use a dynamic accumulator mechanism, such as the one described in [10]. However, the extra proof of accumulator is required in both the signing algorithm and verification algorithm. We omit the details of the modification of the RSA-DAA signature and refer readers to [10]. 5.3

Rekey in the LRSW-DAA Schemes

In the Join protocol of a LRSW-DAA scheme reviewed in Subsection 3.2, the signer chooses a secret key tsk = f , and sends the commitment F = [f ]P1 to the issuer. The issuer then computes the credential cre = (A, B, C) for the signer, such that A = [r]P1 , B = [y]A, C = [x]A + [xyr]F = [x + xyf ]A. The issuer stores at least element C of the newly-computed credential cre for each signer; typically, the issuer will store the complete credential cre along with F . This method is a recall of [16]. To effect the rekey process, the issuer first updates its private key by picking a new x value (here called x ), and replaces the previous value x in its private key. Let β = x /x. The issuer updates its public key by computing X  = [β]X. The issuer then publishes the new public key (X  , Y ). For each currently legitimate signer, the issuer updates the signer’s credential cre = (A, B, C) by replacing the the credential element C with C  = [β]C. The issuer then makes C  available to the corresponding signer to enable the signer to update its copy of the new credential as cre = (A, B, C  ). The signer may optionally wish to verify that the updated credential is an CL signature on f associated with the issuer’s new public key; if so, the signer carries out the CL signature verification in respect of signature (A, B, C  ) on the signed message f . Note that since neither the value of the private signing key f , the value of the key commitment F , nor the values A and B of the credential are changed during the updating, so this updating process does not require the TPM to be involved. 5.4

Rekey in the SDH-DAA Schemes

The Join protocol in a SDH-DAA scheme reviewed in Subsection 3.3 is as follows. The signer chooses a secret key tsk = f , and sends the commitment F = [f ]h1 to the issuer. The issuer then computes the credential cre = (A, x) for the signer, such that A = [1/(γ + x)](g1 + F ). During the join protocol for each signer, typically, the issuer will store the complete credential cre along with F . To update the issuer’s key and the DAA credential of each currently-legitimate signer, there are at least three simple methods as follows:

Revocation of Direct Anonymous Attestation

139

1. The issuer chooses a new value for g1 ∈ G1 (here called g1 ), and for each currently-legitimate signer computes a new value for A, here called A , as: A = [1/(γ + x)](g1 + F ). The issuer then publishes g1 to replace the value of g1 in its previously published public key. For each updated credential, the issuer makes the newly computed value A available to the corresponding signer to enable the signer to update its credential by replacing the previous value of A with A . 2. Alternatively, the issuer does not compute and publish the value A . The issuer chooses a random g1 ∈ G1 and sets g1 = g1 + g1 as part of the new public key. The issuer computes and publishes an updating value A for each legitimate signer, where A = [1/(γ + x)]g1 . Each legitimate member than updates his own membership credential by computing A = A + A ∈ G1 . Note that A = [1/(γ + x)](g1 + F ) + [1/(γ + x)]g1 = [1/(γ + x)](g1 + F ). 3. The issuer first updates its private key by deriving a new value for γ (here called γ  ), and replaces the previous value for γ in its private key. For each currently legitimate signer, the issuer updates the signer’s credential cre by replacing the previous value of the credential element A with A = [1/(γ  + x)](g1 + F ). The issuer then publishes w = [w ]g2 ∈ G2 to replace the previous value of w in its public key, and for each updated credential, makes A available to the corresponding signer to enable the signer to update its copy of the credential as (A , x). The signer may optionally wish to verify that the updated credential is a signature on f associated with the issuer’s new public key; if so, the signer checks whether e(A , w + [x]g2 ) = e(g1 + F, g2 ) holds. For any of the above revocation methods introduced in this section, we do not require the TPM to be involved in the updating process.

6 6.1

Verifier-Local Revocation An Overview

In an ordinary digital signature scheme based on public key infrastructure (PKI), if a verifier holds a certificate revocation list (CRL), the verifier is allowed to distinguish whether or not each received signature is signed under a key in the list. This idea cannot directly be used in an anonymous digital signature scheme, such as a group signature scheme or a DAA scheme, since the verification process

140

L. Chen and J. Li

in these schemes makes use of the group public key instead of a signer’s membership certificate. Thus from the verifier’s view, the signature is not connected to the signer’s membership certificate. However, a similar idea can also be used in these two types of anonymous signatures. Instead of using a CRL, if a verifier holds a list of special information for each revoked signer, and it allows the verifier to distinguish whether or not each received signature is signed under a key corresponding to this information, then the revocation process can be done during the verification as well. In group signatures, this type of solution is called Verifier-Local Revocation (VLR) and this type of list is called Revocation List (RL). Boneh and Shacham [3] formalized the concept of a group signature scheme with VLR in which the RL is distributed only to the verifiers, and the revocation check process is transparent to signers. We adapt the same names of VLR and RL for DAA. However, actually, the concept of VLR in DAA is quite different from the one in group signatures. In a group signature scheme, the content of a RL is based on the property of traceability and provided by the opening authority, which is part of the group manager functionality. By holding the revocation list, the verifier plays the role of the delegatee of the opening authority. In the other words, the opening authority delegates his opening ability to these specific list of signers to the verifier. But in DAA, there is no such an opening authority. Finding the identity of a DAA signer is not a required property for a DAA scheme. However, a verifier playing the role of a service provider can create a shadow identifier for his client, the DAA signer. He can revoke such a DAA signer by revoking its shadow identifier. Unlike the VLR in group signatures, the DAA verifier must enforce a signer to cooperate in a VLR process by including a link proof associated with such a shadow identifier in his signature; that fortunately is a designed feature of DAA. Each verifier can build his own revocation list based on his own experiences with each signer. More specifically, in the literature, there are the following types of Revocation Lists (RLs) in a DAA scheme: RL1 The first type of RLs is a DAA rogue list, denoted by RogueList. The content of RogueList is the DAA secret key tsk of each corrupted TPM. The DAA verification process includes the rogue list check. This idea is a basic DAA functionality as introduced in [4]. RL2 The second type of RLs is a DAA basename related DAA secret key tsk link list. The content of the RL is a set of signatures signed with a special basename. This is a black list maintained by the verifier. If a signer has agreed to use the same basename, the verifier can reject any signature created under a key listed in the RL. This is another basic DAA functionality in [4]. A basename related VLR solution can also be seen as a behavior-based revocation method. A behavior-based revocation solution is an application oriented solution. Some application requires a signer to create a certain number of signatures to a particular event; for example, [17] shows such an application of using a DAA scheme to build a threshold anonymous announcement solution for vehicular ad-hoc networks (VANETs).

Revocation of Direct Anonymous Attestation

141

RL3 The third type of RLs is a list of all unwelcome DAA signatures. If a verifier maintains a black list with all the signatures which upset the verifier, the verifier can use this list as his RL. Alternatively, the verifier can receive a black list of signatures from the issuer. The verifier has to force a signer to proof his DAA signing key is not the same as anyone in the list. This proof is added to an ordinary DAA signature as a new part of the modified DAA signature and its existence is mandatory for such a DAA signature to be accepted. This idea was introduced in [7] and formalized in [8]. In this paper, we provide a new DAA VLR method, which uses the following type of RLs: RL4 The forth type of RLs is a DAA basename related DAA membership credential cre link list. The content of the RL is a set of signatures signed with a special basename. This is a black list maintained by the verifier. If a signer is agreed to use the same basename, the verifier is able to reject any signature signed under a credential cre listed in the RL. The different from RL2 is that it provides the key+credential+verifier revocation rather than key+verifier revocation, as defined in Subsection 2.2. The details of this method used in the RSA-DAA scheme and the SDH-DAA scheme will respectively be explained in the following two subsections. We have not figured out how this idea can be used in the LRSW-DAA schemes. Finding a similar linking proof for the LRSW-DAA scheme is an interesting open issue. 6.2

New VLR in the RSA-DAA Scheme

Recall that in the RSA-DAA scheme as reviewed in Subsection 3.1, a DAA signature is a proof of knowledge of values f0 , f1 , A, e, and v such that Ae R0f0 R1f1 S v ≡ Z mod n and NV ≡ ζ f0 +f1 2

f

mod Γ.

The value ζ is based on a given verifier’s base name bsn. Let GΓ be the subgroup of Z∗Γ of order ρ and HΓ be a collision-resistent hash function HΓ : {0, 1}∗ → GΓ . There are two options: if bsn =⊥, ζ ∈R GΓ created by randomly choosing, and if bsn =⊥, ζ = HΓ (bsn). The value NV enables the verifier to check the pair of f0 and f1 is not a rogue pair and also to link two signatures if bsn =⊥ is used in both the signatures. We now propose a new linkable proof based on both the values e and f = f0 + f1 2f , instead of f only. It is associated with a given verifier’s basename bsn represented as a pair bsnf and bsne , which may or may not be the same. Let Hf and He be two different hash-functions Hf : {0, 1}∗ → GΓ , He : {0, 1}∗ → GΓ . The modification to the original RSA-DAA scheme is as follows: – Compute ζf and ζe in one of the following three cases: 1. If bsnf = ⊥, choose ζf and ζe randomly from GΓ . 2. If bsnf = ⊥ and bsne = ⊥, set ζe = 1 and compute ζf = Hf (bsnf ).

142

L. Chen and J. Li

3. If bsnf = ⊥ and bsne = ⊥, compute ζf = Hf (bsnf ) and ζe = He (bsne ). – Compute NV = ζff · ζee mod Γ , ˜V = ζ rf · ζere mod Γ , where rf and re are the same values as in – Compute N f the original RSA-DAA scheme (refer to Section 3.1). ˜V in the original RSA-DAA scheme with these – Replace the values NV and N new values. What is in the revocation list is the value NV . Obviously Case 1 and Case 2 play the same roles as the random name mode and the base name mode of an ordinary DAA scheme, respectively. In Case 3, when two signatures include the same e value and f value and use the same base name bsn, they are linked. This case can be used in the situation that a signer does not want to provide the link based on the (f0 , f1 ) values, since they might be used for different applications, but does not mind to provide the link based on the e and f values, since that is used for a particular application. This new mechanism enables us to achieve the key+credential+verifier revocation as well as the key+verifier revocation. The extra operation (computing ζe , ζee and ζere ) in this modification can be done by the host, and the TPM’s workload does not increase. For a platform host, this extra cost is trivial. 6.3

New VLR in the SDH-DAA Schemes

Recall that in a SDH-DAA scheme as reviewed in Section 3.3, a DAA signature is a proof of knowledge of the values f , A and x such that A = [1/(γ + x)](g1 + [f ]h1 ) and K = [f ]J. The value J is computed based on a basename of a given verifier. There are two options: if bsn = ⊥, J is chosen at random in G1 (or another suitable cyclic group; for simplicity we omit difference from this); if bsn = ⊥, J = H(bsn) with a hash-function H : {0, 1}∗ → G1 . We propose a new linkable proof based on both the values x and f . Let Hf be a hash-function Hf : {0, 1}∗ → G1 and Hx be a hash-function Hx : {0, 1}∗ → G1 . Given a basename bsn = (bsnf , bsnx ), the modification to the original SDH-DAA scheme is as follows: – Compute Jf and Jx in one of the following three cases: 1. If bsnf = ⊥, choose Jf and Jx randomly from G1 . 2. If bsnf = ⊥ and bsnx = ⊥, set Jx = O and compute Jf = Hf (bsnf ), where O is point at infinity. 3. If bsnf = ⊥ and bsnx = ⊥, compute Jf = Hf (bsnf ) and Jx = Hx (bsnx ). – Compute K = [f ]Jf + [x]Jx ∈ G1 , ˜ = [rf ]Jf + [rx ]Jx ∈ G1 , where rf and rx are the same values as – Compute K in the original SDH-DAA scheme (refer to Section 3.3). ˜ in the original SDH-DAA scheme with these – Replace the values K and K new values.

Revocation of Direct Anonymous Attestation

143

What in the revocation list is the value K. The discussion on the previous linking proof for the RSA-DAA scheme is also suitable for this scheme. In summary, the first two cases are the same as the random base mode and name base mode of the original DAA scheme; the third case provides the key+credential+verifier revocation. The computation required in this modification can be done by the host, rather than the TPM.

7

Comparisons and Discussions

In this section, we compare different revocation methods and discuss how they can be used together. We start with performance measurements of a DAA revocation mechanism. 7.1

Performance Measurement

We identify the following performance measures of a DAA revocation mechanism: 1. 2. 3. 4. 5. 6. 7. 8.

Computational cost of Rekey by an issuer. Computational cost of Rekey by a TPM. Computational cost of Rekey by a host. Increased computational cost of Sign by a TPM. Increased computational cost of Sign by a host. Increased size of a DAA signature σ. Increased computational cost of Verify by a verifier. Increased size of an issuer’s public key ipk.

In these measures, the increased computational cost covers the extra computational operation for the purpose of revocation, and the increased size covers the extra length again for the purpose of revocation. Note that items 1-3 above apply for rekey-based revocation mechanisms whereas items 4-8 above are related to VLR mechanisms. 7.2

Comparisons of VLR Methods

We first compare the four VLR methods that are described in Section 6. The comparison is summarized in Table 1. As for the performance for a revocation process, RL2 has the best efficiency, whereas RL3 is least efficient. None of the four VLR revocation methods requires changing the size of a group public key. For RL1, neither the TPM nor the host needs to perform additional computation on the top of the ordinary DAA signing operation; the verifier needs to compute one exponentiation (denote as E in Table 1) per item in the revocation list. For RL2, again the signer does not need to do additional work besides computing an ordinary DAA signature; the verifier only needs to check the pseudonym in the signature (the N V value in RSA-DAA or the K value in LRSW-DAA and SDH-DAA) against its revocation list. For RL4, the ordinary Sign algorithm is slightly modified by adding a credential linking proof into the secret key linking

144

L. Chen and J. Li

proof, so the signer’s operation is slightly more expensive than the original one, but this extra job is constant and not linear to the size of the revocation list, and it can be done by the host rather than the TPM; therefore we consider this extra cost is trivial. The verifier’s operation is the same as in RL2. For RL3, both the TPM and the verifier need to provide extra operation in the revocation check, i.e., the TPM uses zero-knowledge proof to prove that it did not create those signatures in RL3, and the verifier validates the proof. Therefore RL3 is more expensive. Table 1. A comparison of different DAA VLR methods

TPM sign Host sign Verify Signature size Public key size Unknown tsk Random base mode Name base mode Sharing RL Multi cred. per tsk

RL1 No impact No impact 1 E per item No impact No impact Non-revocable Revocable Revocable Yes Linkable

RL2 No impact No impact Linear lookup No impact No impact Revocable Non-revocable Revocable No Linkable

RL3 3 Es per item No impact 2 Es per item Grows linearly No impact Revocable Revocable Revocable Yes Linkable

RL4 No impact 2 Es per sign Linear lookup No impact No impact Revocable Non-revocable Revocable No Not linkable

We now compare the revocation capabilities of the VLR methods in DAA. For RL1, a DAA signer is revoked if its signing key is revealed. If the adversary has a DAA signature key that is unknown to the verifier, then the verifier cannot revoke the adversary. For RL2 and RL4, the black list is built up based on the name base mode of DAA signing (i.e., bsn = ⊥). In other words, if a signer chooses to create the DAA signatures in the random base mode (i.e., bsn = ⊥), her signatures are unlinkable and cannot be revoked in RL2 and RL4; unless a verifier decides to reject all signatures in the random base mode. The RL3 method has better revocation capability, as it can revoke a corrupted DAA signer even if his private key is unknown and if he uses the random base mode. The drawback of RL3 is the efficiency. Observe that although a verifier can build his own RL2 and RL4, he cannot share the revocation lists with other verifiers, since different basenames are used. RL1 and RL3 can be shared among all verifiers. Also observe that RL2 and RL4 have similar functionality and efficiency. The main difference is that RL4 supports key+credential+verifier revocation rather than key+verifier revocation in RL2. Note that, if RL4 is used, then we have to modify RL1 and RL3 methods slightly in order to support RL4. For example, in SDH-DAA, the revocation list of RL1 contains a set of revoked f value. To support RL4, the pseudonym K in the signature is computed based on both f and x, therefore, the revoked list contains a set of revoked (f, x) pair.

Revocation of Direct Anonymous Attestation

7.3

145

Comparisons between Rekey and VLR Methods

The rekey-based revocation solution provides the key+credential revocation, and holds the property of backward and forward unlinkability. Any revoked member, say tsk and cre, is not able to create a signature which can be accepted in the verification process under the updated group public key ipk. However, any signatures created by the member tsk before the updating should still be valid under the previous group public key before the updating process. If the member is allowed to join another group or to rejoin this group, the member can still use tsk. His signature will still be valid. As discussed in Remark 3 of Section 2.2, extra care may be required, since the verifier might not be able to recognize when a signature was created, although he can see when the signer is legitimate. The significant advantages of rekey-based revocation, compared with the VLR methods, are the following: – It does not rely on knowledge of a compromised signer’s secret, unlike the RL1 method. – It does not require any extra proof or verification in the sign and verification process, unlike the RL3 method, and so is more efficient. – Since there is no need to update the TPM’s secret, the TPM is not involved in the whole revocation process, if the issuer does not want to send the updated credential encrypted under the TPM’s endorsement key. This is the same as in RL1, RL2, and RL4 methods. In general speaking, adding an elegant key updating scheme, as these described in Section 5, does neither bring an extra cost to the TPM in the key updating process, nor provide an extra computational cost in the signing process. The only downside is that the issuer needs to update his key to match with the group member shrinks. 7.4

Using Rekey and VLR Approaches Together

In a DAA scheme, we can support both rekey and VLR approaches together. For example, assume the issuer will perform credential update periodically using the rekey methods in Section 5, we can handle VLR methods with the following two options. 1. Between credential update, a verifier can build up his own revocation lists RL1, RL2, RL3, and RL4. After each credential update event, the verifier wipes out all the revocation lists and sets them to be empty sets. 2. Observe that tsk does not change during credential update. Furthermore, in the credential update methods in Section 5, the e value in RSA-DAA or the x value in SDH-DAA might not change either between credential update. Therefore, if a DAA signing key is revoked in one of the revocation lists (RL1, RL2, RL3, and RL4), then the DAA signer is still revoked in the revocation lists after credential update, unless the verifier resets the lists. This allows a verifier to build a different revocation list from the issuer. For example, for

146

L. Chen and J. Li

a given TPM, the issuer may think it is valid, and continue updating the DAA credential for the TPM. However, a verifier puts the TPM in one of his revocation lists, then it is up to the verifier whether to reset his revocation lists after credential update.

8

Conclusions

We have discussed how to support revoking group membership in DAA and suggested two categories of DAA revocation approaches, namely rekey-based revocation and verifier-local revocation. We have reviewed the existing DAA revocation mechanisms, proposed a number of new mechanisms, and demonstrated how to use these revocation mechanisms with the existing three types of DAA schemes. Future work includes study on how to modify the DAA security model to incorporate the revocation functions described in this paper and how to make a rigorous security analysis of these DAA mechanisms.

Acknowledgement We thank the anonymous INTRUST reviewers for their useful comments and suggestions to improve this paper.

References 1. ISO/IEC 11889: Information technology – Security techniques – Trusted platform module (2009) 2. Boneh, D., Boyen, X., Shacham, H.: Short group signatures. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 41–55. Springer, Heidelberg (2004) 3. Boneh, D., Shacham, H.: Group signatures with verifier-local revocation. In: Proceedings of 11th ACM Conference on Computer and Communications Security, pp. 168–177 (October 2004) 4. Brickell, E., Camenisch, J., Chen, L.: Direct anonymous attestation. In: Proceedings of the 11th ACM Conference on Computer and Communications Security, pp. 132–145. ACM Press, New York (2004) 5. Brickell, E., Chen, L., Li, J.: A new direct anonymous attestation scheme from bilinear maps. In: Lipp, P., Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 166–178. Springer, Heidelberg (2008) 6. Brickell, E., Chen, L., Li, J.: Simplified security notions of direct anonymous attestation and a concrete scheme from pairings. International Journal of Information Security 8(5), 315–330 (2009) 7. Brickell, E., Li, J.: Enhanced Privacy ID: A direct anonymous attestation scheme with enhanced revocation capabilities. In: Proceedings of the 6th ACM Workshop on Privacy in the Electronic Society, pp. 21–30 (October 2007) 8. Brickell, E., Li, J.: Enhanced Privacy ID from bilinear pairing for hardware authentication and attestation. In: Proceedings of 2nd IEEE International Conference on Information Privacy, Security, Risk and Trust, pp. 768–775 (2010)

Revocation of Direct Anonymous Attestation

147

9. Brickell, E., Li, J.: A pairing-based DAA scheme further reducing TPM resources. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 181–195. Springer, Heidelberg (2010) 10. Camenisch, J., Lysyanskaya, A.: Dynamic accumulators and application to efficient revocation of anonymous credentials. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 61–76. Springer, Heidelberg (2002) 11. Camenisch, J., Lysyanskaya, A.: A signature scheme with efficient protocols. In: Cimato, S., Galdi, C., Persiano, G. (eds.) SCN 2002. LNCS, vol. 2576, pp. 268–289. Springer, Heidelberg (2003) 12. Camenisch, J., Lysyanskaya, A.: Signature schemes and anonymous credentials from bilinear maps. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 56–72. Springer, Heidelberg (2004) 13. Chen, L.: A DAA scheme requiring less TPM resources. In: Bao, F., Yung, M., Lin, D., Jing, J. (eds.) Inscrypt 2009. LNCS, vol. 6151, pp. 350–365. Springer, Heidelberg (2010) 14. Chen, L.: A DAA scheme using batch proof and verification. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 166–180. Springer, Heidelberg (2010) 15. Chen, L., Morrissey, P., Smart, N.P.: Pairings in trusted computing. In: Galbraith, S.D., Paterson, K.G. (eds.) Pairing 2008. LNCS, vol. 5209, pp. 1–17. Springer, Heidelberg (2008) 16. Chen, L., Morrissey, P., Smart, N.P.: DAA: Fixing the pairing based protocols. Cryptology ePrint Archive, Report 2009/198 (2009), http://eprint.iacr.org/ 17. Chen, L., Ng, S.-L., Wang, G.: Threshold anonymous announcement in VANETs. IEEE Journal on Selected Areas in Communications, Special Issue on Vehicular Communications and Networks (2010) 18. Chen, L., Page, D., Smart, N.P.: On the design and implementation of an efficient DAA scheme. In: Gollmann, D., Lanet, J.-L., Iguchi-Cartigny, J. (eds.) CARDIS 2010. LNCS, vol. 6035, pp. 223–237. Springer, Heidelberg (2010) 19. Chen, X., Feng, D.: Direct anonymous attestation for next generation TPM. Journal of Computers 3(12), 43–50 (2008) 20. Cheon, J.H.: Security analysis of the strong Diffie-Hellman problem. In: Vaudenay, S. (ed.) EUROCRYPT 2006. LNCS, vol. 4004, pp. 1–11. Springer, Heidelberg (2006) 21. Fiat, A., Shamir, A.: How to prove yourself: Practical solutions to identification and signature problems. In: Odlyzko, A.M. (ed.) CRYPTO 1986. LNCS, vol. 263, pp. 186–194. Springer, Heidelberg (1987) 22. Fujisaki, E., Okamoto, T.: Statistical zero knowledge protocols to prove modular polynomial relations. In: Kaliski Jr., B.S. (ed.) CRYPTO 1997. LNCS, vol. 1294, pp. 16–30. Springer, Heidelberg (1997) 23. Ge, H., Tate, S.R.: A direct anonymous attestation scheme for embedded devices. In: Okamoto, T., Wang, X. (eds.) PKC 2007. LNCS, vol. 4450, pp. 16–30. Springer, Heidelberg (2007) 24. Lysyanskaya, A., Rivest, R.L., Sahai, A., Wolf, S.: Pseudonym systems. In: Heys, H.M., Adams, C.M. (eds.) SAC 1999. LNCS, vol. 1758, pp. 184–199. Springer, Heidelberg (2000) 25. Nakanishi, T., Funabiki, N.: Verifier-local revocation group signature schemes with backward unlinkability from bilinear maps. In: Roy, B. (ed.) ASIACRYPT 2005. LNCS, vol. 3788, pp. 533–548. Springer, Heidelberg (2005) 26. Trusted Computing Group. TCG TPM specification 1.2 (2003), http://www.trustedcomputinggroup.org

Measuring Random Tests by Conditional Entropy and Optimal Execution Order Jialin Huang and Xuejia Lai Department of Computer Science and Engineering Shanghai Jiaotong University, China

Abstract. The demands on the random sequences used in trusted computing environment are stricter than other applications. In practice, we usually produce these sequences using pseudorandom number generators, whose deterministic may cause certain security flaws. So there are various statistical tests to examine the quality of random sequences. NIST proposed a test suite containing 15 tests, which is widely used now. It is meaningful to give an overall comparison among these tests. There are two open problems mentioned by NIST for the requirements of a statistical test suite [13]: how to determine the independence and the coverage of a test suite. These two concepts are abstract and hard to measure. In this paper, we use the conditional entropy to construct a quantitative value for comparing the tests, partly solving these two problems. The result also shows the reasonableness of this approach. Also, we propose a basic method on how to determine the tests’ optimal execution order. With this order we can eliminate the non-random sequences after running the least number of tests in the average case. We show such an order under specific parameters. An interesting finding is that these two different approaches have a high similarity in the ranking of these tests. Keywords: random test, conditional entropy, execution order, NIST’s test suite.

1

Introduction

Random sequences are widely used in many computer applications, especially in trusted computing environment. In practice, trusted computing uses cryptography to help enforce a selected behavior. In most of the algorithms and protocols related to cryptographic security, the random sequences play a very basic and important role, so the demands on the randomness in this environment are higher. Once observed some non-random regularity in the sequences, the applications of trusted computing may face great risks. There are two approaches to generate such random sequences. Sequences with a higher level of randomness are usually generated through simulations of physical processes. Such sequences are highly 

This work is supported by the National Nature Science Foundation of China (Grant No. 60573032, 60773092, 61073149), the ministry of education´s doctor foundation (20090073110027) and the 13th PRP of Shanghai Jiao Tong University.

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 148–159, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Measuring Random Tests by Conditional Entropy

149

similar to real random sequences, however they have some disadvantages: more technical requirements; regular structures in the physical process which make the result sequences predictable; time-consuming. So we usually use pseudorandom number generators to obtain large amounts of high-quality sequences in a shorter time. Pseudorandom number generators adopt deterministic recursive functions to product random sequences, which provide fast speed and simple computation. However, its computability also causes security flaws for attackers. These two kinds of methods mentioned above both have defects, so it is necessary to use statistical tests to detect these defects. Each statistical test corresponds to a statistic and its distribution, which specify a kind of sequence’s property. A sequence generated with a small probability in a specified distribution is thought to be non-random. Since there are many such statistics, there are many different kinds of tests. One can choose tests according to the practical needs and eliminate corresponding sequences. A test suite is a package consisting of tests that are selected from various kinds of tests. This test suite is thought to be able to focus on different types of non-randomness as necessary and comprehensive as possible. In addition that randomness does not have a clear definition itself, it is hard to define a finite test suite considered to be enough. As Soto mentioned in [13], a reliable test suite should guarantee the independence among its tests, and this test suite also should have certain coverage. Several famous test suites are as follows: some empirical tests proposed by Knuth in The Art of Computer Programming [8]; five basic tests mentioned by Menezes in Handbook of Applied Cryptography [1]; The DIEHARD test suite CD published by Marsaglia [9]; The CryptXS test suite proposed by Gustafson [10]; The test suite containing 15 tests developed by NIST [2](the original version consists of 16 tests). These test suites have their own features while there are also some overlaps between them. When testing a sequence, we often ask the following questions: how to explain the results of tests more reasonable; When a sequence passes one test and fails in other one, how to compare the different conclusions made by these two tests. In order to solve these problems, it is important to understand the relationship between these statistical tests. When selecting a fixed number of tests, we could choose the tests which are relatively independent. Researches on these tests have been in progress and there are some results about the correlation of these tests: Hellekalek and Wegenkittl [16] gave some analysis on the correlation of Maurer’s ”Universal Statistical” test, the Serial test, and the Approximate Entropy test. They played these three tests on AES algorithm and showed their relation according to the mathematical theory and the experimental results; Turan [15]compared the Frequency test, the Overlapping Template Matching test, the Runs Test, the Lempel-Ziv Compression test, etc. 10 tests from the point of conditional probability. He showed these tests are not independent with each other by working them on all of the 20-bit and 30-bit sequences. However, Turan only considered one-dimensional case of these tests. It is the simplest case rarely appearing in practical applications. Most of the tests’ statistics focus on subsequences instead of the entire sequence. Therefore, we need a method to measure the advantages and disadvantages between so many kinds of tests. It

150

J. Huang and X. Lai

is important to construct a quantitative value to scale the abstract relevance of these tests. In this paper, we focus on the test suite developed by NIST [2]. It is applied to test random properties of AES algorithm [14], as well as to test some pseudorandom number generators [2]. This test suite is commonly used at present. Our Work. First, We apply the conditional entropy to measure the importance and contribution of one test in the whole test suite, which partly explains the two open problems proposed by Soto [13] : (a) the independence of the statistical tests, and (b) the coverage or span of the statistical tests. The independence of statistical tests seeks to determine whether or not there is any redundancy in the test suite. The coverage seeks to find the amount of the sequence properties involved in the test suite. These two problems are highly relevant: the dependence between the tests decides the actual coverage of the test suite. Since two tests may be so dependent that the properties of sequences they focus on are highly similar. In order to solve these two problems more reasonably, we consider such a concept: the real coverage of one test in the test suite. The definition of entropy is very suitable for describing a test, whose core is a discrete random variable when tested sequences are fixed-length. Moreover, since we usually need to adopt multiple tests to make a conclusion on the sequences, we need to compare one test with the others. So we use conditional entropy to measure the significance of one test in the whole test suite and show the result of tests’ rank in terms of this way. Second, we give a method to determine an execution order of the tests in NIST’s suite, which usually run by a default order in NIST’s source code. Running these tests with our order costs less time than with other orders for the same sequences. The interpretation of the empirical results can be conducted in any number of ways. NIST gave two approaches to explain the results for the generators. But in other cases, we need to judge whether a fixed length sequence is random. Since each test has its own feature, when a sequence passes some tests and fails in other tests, it is hard to conclude its randomness definitely. One sound explanation is : once a sequence fails in any one of these tests, it should be considered as non-random and eliminated. So the key of our method is how to eliminate these non-random sequences in the shortest time. Our approach is based on choosing the test which eliminates the most sequences every time. As so on, we could successively exclude all the non-random sequences after completing an average minimum amount of tests. The order decided by this way reduces the execution time in an average case and could be considered as optimal. We also find that these two different approaches have a high similarity on the ranking of the tests.

2 2.1

Preliminaries Principle of a Statistical Test

The statistical test is based on the hypothesis test, which is an important kind of statistic inference. Its fundamental principle is that, when a hypothesis is

Measuring Random Tests by Conditional Entropy

151

true, an event with small probability in this hypothesis is considered not going to happen. Once such an event has happened, we should suspect that if this hypothesis is true. For the statistical test, there are two hypotheses: the null hypothesis which considers the sequence being tested is random and the alternative hypothesis which considers the sequence being tested is non-random. Firstly, construct a statistic whose distribution has been known according to mathematical theory and practical application. Secondly, determine a critical value and compute the test statistic value on the sequence being tested. Compare this test statistic value to the critical value. If the statistic value exceeds the critical value, the null hypothesis for randomness is rejected. For each test, a conclusion is derived that the null hypothesis is rejected or accepted. Each test focuses on a kind of properties of the sequence and judges that whether a detailed sequence owns a property which happens with a small probability. The statistic and its distribution are the core of a test. 2.2

NIST Random Test Package Table 1. The property each test is designed to detect

Test Name 1 2 3 4 5 6 7

8

9 10 11

The Frequency Test

Properties

the number of ”1” in a sequence, e.g., 01101 is 3. Frequency Test within a the number of ”1” in a subsequence. Block The Runs Test the number of runs in a sequence,e.g.011-0-1 is 4. Test for the Longest-Run- the length of the longest run in a subof-Ones in a Block sequence. The Binary Matrix Rank transform the sequence into matrix and Test compute the rank. The Discrete Fourier make Fourier transform of the sequence Transform Test and compute its frequency amplitude. The Non-overlapping the number of non-overlapping occurTemplate Matching Test rences in a sequence,e.g.”11” appears 2 times in 0110101110. The Overlapping Tem- the number of overlapping occurrences plate Matching Test in a sequence,e.g.”11” appears 3 times in 0110101110. Maurer’s ”Universal Sta- the interval bits between the same fixed tistical” Test length template. The Lempel-Ziv Compres- different words appearing in a sequence, sion Test e.g. there are 3 words in ”0-1-01”. The Linear Complexity linear complexity of the subsequences. Test

152

J. Huang and X. Lai Table 1. (continued)

Test Name 12 13 14 15

16

3 3.1

Properties

The Serial Test

the frequency of fixed length templates, focus on their squares. The Approximate En- the frequency of fixed length templates, tropy Test focus on their entropy. The Cumulative Sums the max value of cumulative sums. Test The Random Excursions the frequency of visiting a specific disTest tance to the original position in a random walk. The Random Excursions the total amount of visiting a specific Variant Test distance to the original position in a random walk.

The Conditional Entropy of the Tests The Application of the Entropy

We apply the definition of conditional entropy to measure the importance and contribution of one test in the whole test suite, which partly explains the two open problems proposed by Soto [13] : (a) the independence of the statistical tests, and (b) the coverage or span of the statistical tests. The independence of statistical tests seeks to determine whether or not there is any redundancy in the test suite. The coverage or span of the statistical tests seeks to find the amount of sequence properties involved in the test suite. These two problems are highly relevant: the dependence between the tests decides the actual coverage of the test suite. In order to solve these two problems more reasonably, we consider such a concept: the real coverage of one test in the test suite. The reason why we consider this concept from the view of entropy is that, according to Shannon’s information theory, the entropy H(X) of a random variable X measures the average amount of information contained in X. As mentioned in Section 2.1, the core of one test is the statistic used in this test and the statistic’s probability distribution. When the length of sequences to be tested is infinite, the statistic approximately obeys a continuous distribution, for example, normal distribution or chi-square distribution. However when the sequences’ length is finite and fixed, the distribution turns to be discrete. So we can compute the entropy of the statistic to represent each test to some extent. The entropy of one test expresses its uncertainty on the sequence to be tested. Moreover, considering that the relevance of these tests, the definition of joint entropy and conditional entropy could measure the tests and their relationship more accurately. Since these two definitions get rid of the reduplicative information provided by multiple statistic values. The joint entropy H(X,Y) means the total amount of information

Measuring Random Tests by Conditional Entropy

153

contained in random variables X and Y, while the conditional entropy H(X|Y ) means the entropy of X in the condition of Y. These two definitions can be easily extended to multi-variables’ case. When multiple tests are executed, the joint entropy expresses the total information of the combination of these tests, and the conditional entropy gives the average remaining information of one test while other tests’ results are given. So from the point of conditional entropy, we can determine and compare each test’s contribution to the whole test suite. In our experiment, the length of the sequences to be tested is from 15-bit to 24-bit. We select twelve tests from NIST’s test suite(other four tests are not suitable for short sequences), and run each test on all of the sequences with the same length to obtain the discrete probability distribution. The formulas about the entropy are as follows: Entropy:  pi logpi (1) H(x) = − i

Joint Entropy: H(X1 , X2 , ..., Xn ) = −



p(x1 , x2 , ...xn )logp(x1 , x2 , ...xn )

(2)

Conditional Entropy: H(Xi |X1 , X2 , ..., Xi−1 , Xi+1 , ..., Xn ) = (H(X1 , X2 , ..., Xn ) −H(X1 , X2 , ..., Xi−1 , Xi+1 , ..., Xn ))

(3)

Particularly, in order to have a clearer comparison, we decide several critical values by choosing several significance levels and divide the statistics into two kinds: one is larger than the critical value, which means sequences with these statistics are random, and the other one is opposite. In this case, the entropy of the test is close to H(x) = −(αlogα + (1 − α)log(1 − α))

(4)

(not equal to because the discrete distribution has slight error to the theoretical continuous distribution). Then we compute the conditional entropy of each test according to (3) and (2), where the event Xi is the result(random or non-random) of test i for tested sequences and p(x1 , x2 , ..., xn ) is the joint probability for all tests’ possible results. 3.2

The Result and Analysis

These four tables correspond to four different significance levels; they are 5%, 10%, 20%, 30% respectively. Each column is for a different sequence’s length. Each entry in the table is the index of the test according to Table 1. We sort these tests in a descending order by their ratio of conditional entropy and entropy (Since when the sequence’s length is infinite, the entropy is equal to (4) for all of the tests and the conditional entropy can be a distinguishable mark. However, in

154

J. Huang and X. Lai

the discrete case, we should divide the conditional entropy by the actual entropy to correct the error and make sure the comparison is consistent). For example, considering the last column of Table2(1), we can draw the conclusion that when the sequence being tested is 24-bit, the ratio of conditional entropy and entropy of test 8 is the largest, the second is test 7,and so on, the smallest is test 12. From these four tables, we can draw several conclusions: Table 2. Tests’ descending order according to their conditional entropy length n 15 16 5%(1) 7 7 8 8 9 9 10 10 11 11 15 15 2 2 16 16 13 13 12 1 14 12 1 14 length n 15 16 20%(3) 9 8 8 16 16 15 15 9 7 7 10 10 2 2 11 11 14 1 13 14 1 13 12 12

17 7 8 9 10 2 11 15 16 13 12 14 1 17 8 9 15 7 16 10 2 11 14 12 1 13

18 7 8 9 10 11 2 15 16 13 12 14 1 18 8 9 15 7 16 10 2 11 1 14 13 12

19 7 8 9 10 11 2 15 16 13 1 14 12 19 8 9 15 7 16 10 2 11 13 12 14 1

20 8 9 7 10 2 11 15 16 13 12 14 1 20 9 7 15 16 10 8 2 11 14 1 12 13

21 8 9 7 10 2 11 15 16 13 14 12 1 21 9 7 15 16 10 8 2 11 14 1 13 12

22 8 7 9 10 2 11 15 16 13 1 14 12 22 9 7 15 16 10 8 2 11 14 12 13 1

23 8 7 9 10 2 11 15 16 13 12 14 1 23 9 7 15 16 8 10 2 11 14 1 13 12

24 8 7 9 10 11 2 15 16 1 14 13 12 24 9 7 15 16 10 8 2 11 14 12 13 1

length n 15 16 10%(2) 8 7 9 8 7 9 10 10 16 16 15 2 2 15 11 11 12 13 13 12 1 14 14 1 length n 15 16 30%(4) 9 9 16 16 15 15 7 7 8 8 10 10 2 2 11 11 14 13 1 14 13 12 12 1

17 7 8 9 10 2 15 16 11 1 13 14 12 17 9 16 15 7 8 10 2 11 14 1 13 12

18 7 8 9 10 11 15 2 16 13 14 12 1 18 9 16 15 7 8 10 2 11 14 1 12 13

19 7 8 9 10 11 2 15 16 13 12 14 1 19 9 16 7 15 8 10 2 11 1 14 13 12

20 8 7 9 10 11 2 15 16 1 14 13 12 20 9 16 15 7 8 10 11 2 14 1 13 12

21 8 7 9 10 11 2 15 16 13 12 14 1 21 9 16 15 7 8 10 2 11 1 14 12 13

22 8 7 9 10 11 2 15 16 1 13 14 12 22 9 16 15 7 8 10 2 11 14 1 12 13

23 8 7 9 10 11 2 15 16 14 13 1 12 23 9 16 15 7 8 10 11 2 13 14 12 1

24 8 7 9 11 10 2 15 16 13 14 12 1 24 9 16 15 7 8 10 2 11 14 1 12 13

Firstly, with a fixed length of the sequences to be tested, we could obtain a definite ranking on these tests under the same significance level. Take the last column in Table2(1) as an example, we can find that when the sequence being tested is 24-bit and the significance level of these tests are about 5%, the ratio of conditional entropy and entropy of test 8 is the largest, the second is test 7,and so on, the smallest is test 12. The ratio of test 8, which is closest to 1, means that even if other eleven tests’ results have been given, it is still hard to know the judgment of test 8 on the sequences to be tested. That is to say, it is still important and necessary to execute test 8 on these sequences. The test

Measuring Random Tests by Conditional Entropy

155

with slightly less importance than test 8 is test 7. And so on, the ratio of test 12 shows that when other eleven tests’ results have been given, the result made by test 12 nearly has been known in average. This means that it is the least meaningful to take test 12 now. Secondly, with the different sequences’ lengths, the sorting of these tests based on their ratio are generally consistent under the same significance level. Take Table 2(1) as an example, there are only slight differences between the columns. Test 7 and test 8 both focus on a fixed template’s occurrence in the sequence, and test 9 is the famous Maurer’s ”Universal Statistical” Test. These three tests are always in front positions of the list. The next are test 10 based on Lempel-Ziv compression and test 11 based on the linear complexity. Both test 12 and test 13 focus on the frequency of all the fixed length templates, and both test 1 and test 14 are highly relevant to the weight of a sequence. These tests are always in the last positions of the list. Test 15 and test 16 based on computing a random walk in a sequence are always before them. Thirdly, we can find that for different significance levels the sorting of these tests based on their ratio are largely similar, and have some significant changes in trends. The ranking of test 1, test 12, test 13 and test 14 are still at the end of the list. However, with the increase of significance level, the ranking of test 15, test 16 and test 9 are increasing, while test 7 and test 8 decrease. Last, it is interesting that when taking some specific critical values and sequence lengths, the conditional entropy of some tests would reduce to be zero, such as test 12 and test 13. In this condition, when the other tests have been completed, the judgment of such a test on the sequences also has been known definitely. This situation may be used as a reminding for choosing the parameters and critical values for the tests.

4 4.1

The Order of the Tests’ Execution The Way to Decide the Execution Order

We give a method to determine an execution order of the tests in NIST’s test suite. These tests usually run by a default order arranged in NIST’s source code. So it is natural to consider such a problem: whether there exists a proper order for these tests which makes the execution more efficient. The interpretation of the empirical results can be conducted in many ways. NIST gives two approaches to explain the results, and to determine whether the phenomenon of the generator is a statistical anomaly or a clear evidence of randomness. But in other cases, we need to judge whether a fixed length sequence is random. Given that the distinct feature of every test, it is usually thought that a sequence is random enough when it passes all of these tests. If a sequence fails in any one of these tests, we consider that it is non-random. So the problem turns to be that how to eliminate these non-random sequences in the shortest time. A proper execution order of these tests could reduce this time in an average case. According to the different results

156

J. Huang and X. Lai

of every test, we divide all of the n-bit sequences into different sets. Sequences in a subset can be considered as equivalent that all tests’ results on them are the same. For example, when the number of tests is 3, and the sequence’s length n is 20, we divide 220 sequences into 8 different sets: [0,0,0],[0,0,1],...,[1,1,1]. The mark [*,*,*] of each set represents each test’s result. The 0 represents that the corresponding test rejects the sequences in this set. The sequences in the set [0,0,0] fail in all of these three tests, while sequences in the set [0,0,1] fail in test 1 and test 2, and pass in test 3, and so on. As experiment in section 3, we select twelve tests from NIST’s test suite and take several different critical values. The sequences to be tested are from 15-bit to 24-bit. We determine the order of these twelve tests according to the following steps: 1. Divide all the sequences with the same length into 212 subsets as mentioned. According to our criteria for determining the randomness of a sequence, we do not need to consider the sequences in subset [1,1,...,1] 2. Sort the remaining 212 − 1 subsets based on their size by descending order. 3. Successively consider the subsets in the sorted list, and choose the test which rejects the sequences in current subset. We do not need to consider the subsets whose sequences have been rejected by any one of the tests selected previously. Once sequences in current subset are rejected by multiple tests which are all never chosen before, consider next subset as before until one of these tests is chosen. 4. Repeat step 3 until all the tests have been chosen. The order obtaining all the tests is the result order. 5. Summarize the final order obtained by above steps for the sequences with different lengths under the same significance level. The details of this step will be explained in the following paragraph. 4.2

The Result and Analysis

First we do not need to consider the sequences passing all of the tests, since these sequences have to be tested by all of the tests no matter how their execution order is. Under the assumption that all the fixed-length sequences are generated with equal probability, we first consider the test which eliminates the most sequences. For example, given that the sequence length is 19-bit, and the critical value is about 5%, the most number of sequences fails only in test 8, so we first carry test 8 when testing begins. Since in an average case, this test would eliminate the most sequences which would be judged to be nonrandom at last. By this way we could get rid of them after taking just one test. And so on, we could successively exclude all of the non-random sequences after completing an average minimum amount of tests. However, as mentioned in Section 3, there is slight error between actual discrete distribution and the theoretical continuous distribution. So the actual significance levels have differences with each other, which is also one of the reasons leading to the different sizes of the subsets. Thus when deciding the final order of the tests, we get rid of the

Measuring Random Tests by Conditional Entropy

157

data having a great deviation and just extract the relative order suggested in the condition that all the tests contained in this order have very close significances. For example, when sequences to be tested are 17-bit and the significance level is 10%, the actual significance levels of the twelve tests in our experiment are 14.346313%, 10.351563%, 5.273438%, 13.516235%, 10.040283%, 3.063965%, 10.937500%, 8.717346%, 9.806824%, 9.808350%, 9.939575%, 9.062958% respectively. Here we only consider the relative order containing the tests with the significance levels of 10.351563%, 10.040283%, 9.806824%, 9.808350%, 9.939575%, 9.062958%. The differences on significance levels between these tests could not influence their relative sorting. In Table 4, we show the order on two different significance levels. The entries are the index of the tests according to Table 1. The result shows a high consistence on these two orders, only with a minor difference about the position of test 9. As mentioned before, the purpose of this section is to decide an optimal order that can detect non-random sequences with average minimum number of time, so we should also take the efficiency of each test into consideration. We run 10 tests on 500 1500-bit sequences and take the average running time of each test. They are in Table 3(we do not consider test 9 here since it needs large sequence’s length):

Table 3. The running time for each test test 1 2 7 8 11 time(sec) 0.000662 0.000654 0.008476 0.000846 0.010990 test 12 13 14 15 16 time(sec) 0.059016 0.003646 0.000714 0.000680 0.000681

we also run the tests on sequences with other lengths, and the results are similar: test 11 and test 12 are conspicuously time-consuming than the other tests and test 7 is slightly time-consuming. It is also interesting to compare Table 4 with Table 2. The execution order sorted by this way is highly similar to the tests’ ranking which is decided according to their conditional entropy. Test 7 and test 8 whose relative conditional entropy are high also have a strong ability to eliminate non-random sequences, while test 1, test 12, test 13, test 14 whose relative conditional entropy are low have a weak ability to eliminate non-random sequences. With the increase in significance level, the ranking of test 15 and test 16 are increasing. This is also the same as Table 2. Finally, it is meaningful to compare our test order with NIST’s default order. We take data files with 300 1000-bit sequences, 500 1500-bit sequences to be tested. The total time needed in these two kinds of orders are in Table 5(we do not consider test 9 here since it needs large sequence’s length):

158

J. Huang and X. Lai Table 4. The result of test execution order Significance Level 5% Significance Level 10% 8 8 7 7 9 11 11 16 15 15 16 9 10 10 2 2 13 14 14 13 12 12 1 1

Table 5. Comparison for execution time of two orders Sequence’s Length Sequence’s Number NIST’s Order(sec) Our Order(sec) 1000 300 33.103 20.656 1500 500 64.982 36.410

However, the running time should be computed much more accurate because of the following reasons: the inaccuracy that computing time in Windows system; the effect caused by the differences of test parameters; the immature of our way to compute the time; the insufficient data being tested.

5

Conclusion

In this paper, we propose two methods to have an overall comparison among the tests in NIST’s test suite. Firstly we apply the conditional entropy to measure the contribution of one test in the test suite, which we also refer to a test’s relative ”coverage”. We partly explain the two open problems proposed by Soto, and compare the abstract relevance among the tests by constructing such a quantitative value. We analyze the result in our experiment and obtain several regular phenomenons. This result also shows the reasonableness of our approach. Then we give a method to determine an execution order of the tests in NIST’s test suite. This execution order could eliminate the non-random sequences in the shortest time in an average case, and therefore could be regarded as efficiently optimal. We also show the resulting order in our experiment. Moreover, we find an interesting phenomenon that the results obtained by these two methods are highly consistent.

Measuring Random Tests by Conditional Entropy

159

References 1. Menezes, A.J., Van Oorschot, P.C., Vanstone, S.A.: Handbook of applied crytography (1997) 2. Rukhin, A., Soto, J.: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications (2000) 3. Rukhin, A.: Approximate Entropy for Testing Randomness. Journal of Applied Probability 37(1), 88–100 (2000) 4. Preneel, B.: NESSIE: A European Approach to evaluate. Cryptographic Algorithms 5. Ryabko, B.Y.B., Monare, V.A.: Using Information Theory Approach to Randomness Testing (2004) 6. Ryabko, B.Y.B., Stognienko, V.S., Shokin, Y.I.: A New Test for Randomness and its Application to Some Cryptographic Problems (2004) 7. Shannon, C.E.: Communication Theory of Secrecy System, Bell System Technical Journal (1949) 8. Knuth, D.: The Art of Computer Programming Seminumerical Algorithms, 3rd edn. Addison-Wesley, Reading (1997) 9. Marsaglia, G.: The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness (1995) 10. Gustafsona, H., Dawson, E.P., Nielsenb, L., Caellib, W.: A Computer Package for Measuring the Strength of Encryption Algorithms (1994) 11. Gustafsona, H., Dawson, E.P., Golic, J.: Randomness Measures Related to Subset Occurrence (1996) 12. Coron, J., Naccache, D.: An Accurate Evaluation of Maurer’s Universal Test (1999) 13. Soto, J.: Statistical Testing of Random Number Generators, http://www.citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.33.7905&rep=rep1&type=pdf 14. Soto, J.: Randomness Testing of the AES Candidate Algorithms (2000) 15. Turan, M.S.: On Independence and Sensitivity of Statistical Randomness Tests (2008) 16. Hellekalek, P., Wegenkittl, S.: Empirical Evidence Concerning. In: AES (April 2003) 17. L’Ecuyer, P., Simard, R.: TestU01: A C Library for Empirical Testing and Random Number Generators 18. Wegenkittl, S.: Entropy Estimators and Serical Tests for Ergodic Chains

Leakage Resilient Strong Key-Insulated Signatures in Public Channel Le Trieu Phong1 , Shin’ichiro Matsuo1 , and Moti Yung2,3 1

2

NICT, Japan Columbia University 3 Google Inc.

Abstract. Key-insulation aims at minimizing (i.e., compartmentalizing) the damage of users from key exposures, and traditionally requires a private channel of communication between a user and a semi-trusted party called a helper to refresh the private keys. The configuration is highly suitable to architectures where the signer is a user application and the helper resides in the safer “trusted module,” yet the user wants to remain in control of the sensitive crypto operation. The private channel employed in the model, while acceptable in some settings, certainly limits the usage of key insulation schemes (in case the user sits across the network from the trusted environment). In 2009, Bellare, Duan, and Palacio (CT-RSA 2009) refined the model of key-insulation by considering public channels (namely, ones controlled by the adversary), and showed how to convert a key-insulated signature scheme from the private channel into the public one, using extra primitives such as key exchange protocols and symmetric encryption. In this paper, we show that the primitives may be redundant in specific cases. In particular, we revisit the original key-insulated signature scheme in the private channel given by Dodis, Katz, Xu, and Yung (PKC 2003), and show that, with a tweak, the scheme can be naturally proved secure in the public channel without any additional primitives. Next we consider the area of leakage resilient cryptographic schemes which has gained much interest recently. In particular, we consider the continual key leakage scenario of our design (which is more general than the model of key exposure), and argue that our proposal, while requiring an added helper component, nevertheless enjoys several advantages over the recent signature scheme of Faust et al. (TCC 2010) with the same purpose of allowing continual leakage. Our design demonstrates how when given a more complex architecture with some parts that are safer than others, a trade-off can be applied, exploiting the safer modules but keeping users in control; further we show how to do it while mitigating the effect of exposures and leakages. Keywords: signatures, key-insulation, public channel, continual key leakage.

1

Introduction

In applications employing cryptography, a serious threat of security is the exposure or leakage of secret keys due to malware, virus, and side channel attacks, or L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 160–172, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

161

other break-ins induced by unexpected flaws. Certainly, the exposure of a secret key may lead to the revocation of its corresponding public key. However, the revocation of certified public keys are proven costly and greatly troublesome in practice. Fortunately, there are developed technologies dealing with the threat, among which is key insulation [6, 7]. In a key insulated (KI) scheme, the user has a fixed public key pk whose lifetime is divided into stages 1, . . . , N ; and ideally, N may be set to be “any polynomial” without any loss in efficiency of the scheme. On the other hand, the user secret key will evolve with time: the secret key uski for stage i is computed at the end of stage i−1, and even if the (i−1)-th one uski−1 is compromised or leaked this does not affect the new key. The main features of this setting are as following: the public key pk is never revoked, even if any uski is exposed; and moreover, break-ins for all stages i ∈ I  {1, . . . , N } (ideally with no other limitations on I), will not affect security of other stages j ∈ I. Thus, in settings where key exposure is detected then in case of a detection, the user act is simple: moving to the next stage with a fresh secret key, without worrying about public key revocation. To reach their goals, KI schemes require an auxiliary and trusted party called a helper, who interacts with the user for key evolution. (To see a formal reason why the helper is mandatory, see Theorem 1 in Sect.3). This means KI splits works for evolving keys into trusted device and untrusted device. One may imagine that the helper is a cellphone, while the user is a laptop, communicating with each other via a wireless network, or two different chips in an architecture with two different protection mechanisms. Alternatively, the helper may be a server over the Internet. In general, in environment that employs some trusted component (either in the local architecture at some system hardware level, or across the network) the separation of duties added by schemes in the KI model is attractive, since it balances taking advantage of the availability of the trusted component (as a helper) while retaining the user control over its cryptographic operation (as a signer, say). The fact that the user application controls the operation while the key is minimally exposed is what we gain and it demonstrates how to design sensitive utilities in the presence of trusted modules/components. Most works [3, 6, 7, 10, 12, 13, 20] on key insulation have assumed that the interactions between the user and the helper are in a private, secure channel where there is no adversary involved in that communication. The private channel, while acceptable in some settings, is obviously not desirable in all cases, and limits the applicability of KI schemes. For example, the wireless network between the cellphone and laptop would be better viewed as a public network, where malicious entities can easily observe the information. Recently, Bellare, Duan, and Palacio [2] have realized this problem, and among other results, showed how to turn a private channel KI scheme into a public channel one, at the cost of employing additional cryptographic primitives such as key exchange (KE) and symmetric encryption (SE) schemes. While the transformation is generic, certainly adding primitives and worrying about additional keys has both theoretical (e.g., elegance and added assumptions) and practical (e.g., added secure storage) implications.

162

L.T. Phong, S. Matsuo, and M. Yung

The results of Bellare et al. [2] apply to both key-insulated encryption and signature schemes, and additionally requires that the schemes are “perfect” in the following sense: they must remain secure even after N − 1 (over N ) breakins. This manuscript will focus on signatures, and we will consider the (private channel) KI signature scheme by Dodis, Katz, Xu, and Yung (DKXY) in [7]. Bellare et al.’s results, in turn, tell us that the scheme can be converted into a public channel one, employing the KE and SE primitives. 1.1

Our Contribution

First, we show how to get rid of the KE and SE primitives, as used by Bellare et al. [2]. Namely, in Sect.4 we show that for the KI signature scheme of [7], perhaps somewhat surprisingly, by merely employing a little tweak, we can turn it into a provably-secure public-channel KI signature scheme. (See Table 1.) The construction is generic and secure in the standard model. We consider this result as the main contribution of this paper. Table 1. A comparison between Bellare et al.’s result and ours. KE stands for key exchange (e.g., Diffie-Hellman) scheme, and SE for symmetric encryption (having semantic security, e.g., CBC mode). Bellare-Duan-Palacio [2] (private-channel) DKXY [7] + KE + SE → public channel KI-signature scheme Ours (Sect.4) (private-channel) DKXY [7] → public channel KIsignature scheme (no KE, SE used)

Second, we examine the scenario of key leakage for both the helper and the user in our KI system, which is certainly more general than user keys’ exposures only. The scenario is important due to the leakage threats, and indeed the field of side channel attacks has gained recent momentum [4, 5, 9, 11, 15, 16, 21], considering attacks involving a range of partial to almost all secret information learning by the attacker. This threat is unexceptional for trusted devices. Beside stage exposures (as in previous works), in this paper we also consider the leakage of user secret key on every (other) stage; and furthermore, the leakage of the helper secret key. Our proposal is still secure even if a fraction of the user secret key for the targeted stage, as well as a fraction of the helper secret key, are leaked. And certainly, a user can freely reset its secret key without public-key revocation soon after he/she finds that the current key is compromised, either partially or totally. In our proposal, the value N can be set to be any polynomial, without any loss on efficiency, so the proposal can be practically seen as a continual leakageresilient signature scheme. It is worth noting that it is known in the literature (e.g., [1]) how to achieve continual leakage with helpers, so we do not consider this as the main contribution of our paper. Note that [1] assumes leakage-free helper while we allow leakage from the helper.

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

163

Table 2. A comparison between instantiations for continually leakage-resilient signatures. Both instantiations use the same building block, which is the generalized Okamoto-Schnorr signature scheme [1]. The value for log 2 (p) is typically 160. Instantiations Cold-boot Attack Helper? Sig. Size (bits) Approach Faust et al. [8] not proven secure no 540 log 2 (p) Tree-based Ours (Sect.5) proven secure yes 16 log2 (p) Certificate-based

A signature scheme tolerating continual leakage is also the goal of a recent paper of Faust et al. [8] (TCC 2010), which is also the first work on continual leakage for signatures. (For works on non-continual leakage, see for example [1, 14]). Faust et al. utilize the traditional tree-based approach of Lamport and Merkle [17, 18], and resort to the axiom “only computation leaks information” of Micali and Reyzin [19] in their construction (without helpers). Here, we use the certificate-based approach, in which the helper issues certificates for the user, and do not rely on the axiom for leakage. Therefore, our proposal, with a helper, provably resists the recent cold-boot attack [11]. Faust et al. [8] derived a concrete instantiation for their tree-based approach construction. For a concrete comparison (see Table 2), we give in Sect.5 an instantiation of our proposal, using the same building block as Faust et al. We show that with approximately the same level of security and leakage, the certificatedbased approach as in our proposal gives much shorter signatures than the treebased one.

2

Definitions

  Denote A(a); B(b) −→ (c; d) the protocol between parties A with input a and $ B with input b; and at the end, A obtains c while B obtains d. The symbol “ ← ” will be used for indicating processes with random coins. Public channel key update signature scheme. The scheme, abbreviated as PCKUS = (KG, KUP, SIGN, VRF), is described as follows. – KG: The generation algorithm, on input security parameter k, returns the system-wide public key params, the helper (initial secret) key hsk0 , and the user (initial secret) key usk0 . – KUP: The key-updating protocol KUP is run between the user and the helper to update keys at the beginning of any stage i > 0. Using the above  notation, the protocol can be written as User(uski−1 ); Helper(hski−1 ) −→ (uski ; hski ). The transcripts of KUP is public and particularly available to the adversary. – SIGN: The signing algorithm, on input i, a message m, and the user key uski , returns a signature (i, σ) for the current stage i. – VRF: The verifying algorithm, on input params, m, and a signature (i, σ), returns 0 (indicating rejection) or 1 (indicating acceptance).

164

L.T. Phong, S. Matsuo, and M. Yung

The above formalism of PCKUS is more compact and general than those in [2, 7], because all the (interactive or not) algorithms related to updating keys for the user and the helper are squeezed in our protocol KUP. In particular, KI signature schemes are a special case of the above formalism, when the helper secret key is kept unchanged. Signature schemes. Ordinary signature schemes can also be seen as a special case of the above key update signature scheme when KUP is empty, and hsk0 = ⊥, i = 0. Table 3. Oracles used in security definitions Oracle

Action

Initialize(k) Sign(i, m) Expose(i) Transcript(i) LeakageU(i, f ) LeakageH(j, g)

(params, hsk0 , usk0 ) ← KG(k). Return params. Return SIGN(i, m, uski ). Return uski and user’s used coins ωi in stage i. Return the transcript of KUP in stage i. Return f (uski , ωi ). Return g(hskj , j ).

$

Above, if either uski , or hskj , or the transcript of stage i is undefined, use KUP to get it from (hsk0 , usk0 ). The coins ωi consist of the ones used in generating uski (but not hski ), and in the SIGN algorithm in stage i. Similarly, j is the random coins used by the helper in stage j.

Security of PCKUS. We first describe some oracles in Table 3, and will formalize two notions for a public channel key update signature scheme: (1) Even the helper cannot forge signatures; and (2) Assuming that the helper is partially leaked, an adversary cannot forge signatures of uncorrupted stages, even when it has the key leakage information on those stages (and of course, secrets of the corrupted stages), and the transcripts of communication between the helper and the user. Expanding the terminology of [7], we call a scheme satisfying (2) by (L, L )-leakage-resilient key-insulated one, where L is the bounded leakage on the helper secret state, L is the bounded leakage in each (uncorrupted) stage. Additionally, if it satisfies both (1) and (2), we call it strong (L, L )-leakage-resilient key-insulated. Formal treatments are as follows. Notion (1) is defined by the following game: Initialize is run and params, hsk0 are given to the adversary A1 , who can arbitrarily access the oracle Sign. ∗ Finally, A , m∗ , σ ∗), and wins if (i∗ , m∗ ) was not queried to Sign  1 outputs (i ∗ and VRF params, m , (i∗ , σ ∗ ) = 1. Notion (1) is met if the probability Pr[A1 wins] is negligible. Notion (2), (L, L )-leakage-resilient key insulation, is defined by the following game: Initialize is run and params is given to the adversary A2 , who can arbitrarily access all oracles Sign, Expose, Transcript, LeakageU, and LeakageH many times. The restriction on LeakageU queries is that the leakage in

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

165

any (uncorrupted) stage is less than L bits, and on LeakageH queries is that the total leakage in all stages is less than L bits. Finally, A2 outputs (i∗ , m∗ , σ∗ ), ∗ ∗ and wins if i∗ was not queried  to Expose, (i , m ) was not queried to Sign, and ∗ ∗ ∗ VRF params, m , (i , σ ) = 1. Notion (2) is met if the probability Pr[A2 wins] is negligible for all poly-time A2 . Security of ordinary signature schemes. Having known that signature schemes are included as a special case in PCKUS, we can easily recall the standard (uf-cma) security notion by the oracles in Table 3. An adversary A against a signature scheme Ω is given params, and has access to the Sign oracle (the stage index i = 0). At the end, A produces (m∗ , σ∗ ), and wins if m∗ was not a signing query while the pair is valid. The signature scheme is uf-cma-secure if the probability Pr[A wins] is negligible for all poly-time A. Let us also recall the notion of L -leakage-resilience for signature schemes. In addition to the signing oracle as above, the adversary A gets access to the LeakageU oracle (for i = 0) whose output size is less than L . The rest is the same as above.

3

Some Impossibility Results

Theorem 1. If there is no helper (namely hsk0 = ⊥ and Helper is empty), all PCKUS schemes are insecure. Proof. The adversary will call Expose(0) to obtain usk0 . It then computes usk1 using KUP, generating coins for User if necessary. The adversary then returns SIGN(1, m, usk1 ) as the forgery for any m.   Active adversary in public channel. As in Table 3, we only consider eavesdroppers (passive adversaries) getting transcripts in the public channel between the helper and user. The security notion formalized above is the best one can hope for secure constructions of PCKUS, since there will be no construction resisting against active adversaries (who can additionally deliver messages out of order, inject its own messages, or modify messages), as shown by Bellare et al. in [2]. We recap their impossibility result below. Theorem 2 (Bellare, Duan, Palacio [2]). There exists no PCKUS scheme secure against active adversaries over a public channel. The above theorem, translating in a positive way, may serve as a guide for practitioners when setting up PCKUS schemes in practice. Namely, the public channel between the user and helper must be safe from active attacks as a condition for secure PCKUS. In particular, Theorem 2 implies that authentication between the user and the helper won’t help achieving security against active adversaries. The intuition is that active adversaries can easily make breaks-in and impersonate the user. On the other hand, when considering passive adversaries (as we do in this

166

L.T. Phong, S. Matsuo, and M. Yung Common input: params = (P K, pk) User(uski−1 ) uski−1 =(sk, ski−1 , pki−1 , certi−1 ) $ (pki , ski ) ← Kg’(k)

Helper(SK)

pk

−−−−−−i−−−→ cert

Set uski = (sk, ski , pki , certi )

certi = SigSK (i  pki )

←−−−−−−i−−−−

Fig. 1. The KUP protocol in our proposal

manuscript), there is again no need to consider authentication, since the adversary is not allowed to modify, or inject her own messages in the channel. What the adversary can do is just eavesdropping the messages flowing in the channel. The PCKUS scheme in [2], as well as ours in the next section are constructed regarding this fact.

4

Our Proposal

We use two signatures schemes Ω = (Kg, Sig, Vrf) and Ω  = (Kg’, Sig’, Vrf’). Our proposed PCKUS = (KG, KUP, SIGN, VRF), is described as follows. $

$

– KG: Run (SK, P K) ← Kg(k), (sk, pk) ← Kg(k). Set the system-wide public $ key params = (P K, pk) and helper key as hsk0 = SK. Run (sk0 , pk0 ) ← Kg’(k). Set user initial secret key usk0 = (sk, sk0 , pk0 , cert0 ) where cert0 = SigSK (0 pk0 ). – KUP: As depicted in Fig.1, at the beginning of stage i ≥ 1, the user with uski−1 = (sk, ski−1 , pki−1 , certi−1 ) runs Kg’(k) to get (pki , ski ), and then send pki to the helper (having hski−1 = SK). The helper returns certi = SigSK (i pki ) to the user, and again sets hski = SK. The user sets uski = (sk, ski , pki , certi ). (Note that the transcript of the protocol is (pki , certi ).) – SIGN: On input i, a message m, and the user key uski =(sk, ski , pki , certi), returns the signature (i, σ) where σ = Sigsk (i m), Sig’ski (m), pki , certi . – VRF: On input params, m, and a signature (i, σ), parse σ = (γ, δ, pki , certi ). Return Vrf(pk, i m, γ) ∧ Vrf’(pki , m, δ) ∧ Vrf(P K, i pki , certi ). Above, for readability, we omit to write the user’s coins explicitly. In stage i, the user’s coins ωi consist of those used for generating (pk, sk), (pki , ski ), and those used in the signing algorithm by Sig and Sig’. Relation with Dodis-Katz-Xu-Yung [7]. The above proposal originates from [7], but has a tweak in KUP: in [7], the helper generates a pair (pki , ski ) and sends (ski , pki , certi ) to the user; while in our proposal above, the user himself creates the pair and sends only pki . The change totally makes the security

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

167

measure turnaround: the proposal is secure (as proved below), while DKXY scheme [7] is insecure (in public channel, as considered here), intuitively since the key ski is sent in public. Formally, to see why the original DKXY scheme is insecure, consider an adversary A makes Expose(0) → usk0 = (sk, sk0 , pk0 , cert0 ), then Transcript(1) → (sk1 , pk1 , cert1 ). The adversary then has (sk, sk1 , pk1 , cert1 ), which is exactly the user key of stage 1, so it can forge signatures in the stage. The security of our proposal is ensured by the following result. Theorem 3. The proposed PCKUS is a strong key-insulated scheme in public channel against passive adversaries, with (L, L )-leakage-resilience, provided that the signature scheme Ω is L-leakage-resilient, and Ω  is L -leakage-resilient. Proof. Following directly from Lemmas 4 and 5 below.

 

Lemma 4. The helper cannot forge signatures of the PCKUS scheme. Proof. We have an adversary A1 requiring input (SK, P K, pk), querying (i, m) to the Sign oracle many times, and finally returning (i∗ , m∗ , σ ∗ ). We will build an adversary B attacking the uf-cma security of the scheme Ω. The adversary B, on $ input pk, generates (P K, SK) ← Kg(k) itself, and begins running A1 on input (SK, P K, pk). When A1 makes a signing oracle call (i, m), then B first submits i m to its own oracle to receive Signsk (i m). In addition, B itself generates   $ (pk  i , ski ) ← Kg’(k), and computes Sig’ski (m), certi = SigSK (i pki ) . Then Sigsk (i m), Sig’ski (m), pki , certi is returned to A1 as the answer on (i, m). At the end, when A1 outputs (i∗ , m∗ , σ∗ ), B returns (i∗ m∗ , σ∗ ) as the forgery of Ω. It is easy to see that the simulation is perfect, and B wins with the same probability of A1 . Since we assume that Ω is uf-cma-secure, we conclude that even the helper cannot produce forgeries in the proposal.   Lemma 5. The proposed PCKUS is (L, L )-leakage-resilient and key-insulated. (Assumptions on Ω and Ω  are as in Theorem 3.) Proof. Consider an adversary A2 (params) accessing the oracles Sign, Expose, Transcript, LeakageU, LeakageH, and finally outputs (i∗ , m∗ , σ∗ ) where σ ∗ ∗ = (γ ∗ , δ ∗ , pk∗ , cert∗ ). Recall the event A2 wins: queried to Expose,  i was not ∗ ∗ (i , m ) was not queried to Sign, and VRF params, m∗ , (i∗ , σ ∗ ) = 1. The final equation is equivalent to Vrf(pk, i∗ m∗ , γ ∗ ) = 1 ∧ Vrf’(pk ∗ , m∗ , δ ∗ ) = 1 ∧ Vrf(P K, i∗ pk∗ , cert∗ ) = 1. The calls of A2 to the oracles result in a list of (pki , ski ) containing in uski . Let E be the event that pk ∗ = pki∗ (in the case pki∗ does not exist, Pr[E] = 0). We have Pr[A2 wins] = Pr[(A2 wins) ∧ E] + Pr[(A2 wins) ∧ E]. We will prove that the both terms are negligible. First considering the event (A2 wins) ∧ E, we will build an adversary B against the L-leakage-resilient se$ curity of Ω. The adversary B receives P K as input, creates (sk, pk) ← Kg(k) itself, and gives params = (P K, pk) to A2 . The adversary B can answer queries

168

L.T. Phong, S. Matsuo, and M. Yung

from A2 , since it has for all stages i the secret key uski = (sk, ski , pki , certi ) by generating (pki , ski ) (if not existed yet) and using its own signing and leakage oracles (corresponding to SK) to produce certi = SigSK (i pki ) and to answer leakage queries. Details are as follows:   – Sign(i, m): Return (i, σ) where σ = Sigsk (i m), Sig’ski (m), pki , certi . – Expose(i): Return uski , and the randomness ωi using in creating (pk, sk), (pki , ski ), and in the Sign oracle above. – Transcript(i): Return (pki , certi ). – LeakageU(i, f ): Return f (uski , ωi ). – LeakageH(j, g): Forward g to the leakage oracle of B, and give A2 what B returns. Finally, B outputs (i∗ pk∗ , cert∗ ) as a forgery against Ω. Since we have Vrf(P K, i∗ pk ∗ , cert∗ ) = 1, B wins if A2 wins and E happens. The L-leakageresilient uf-cma security of Ω therefore ensures Pr[(A2 wins) ∧ E] is negligible. We now proceed to prove Pr[(A2 wins) ∧ E] is negligible by building an adversary B  against the L -leakage-resilient security of Ω  . The adversary B  receives pk  and is equipped with oracles Sig’sk (·) and Leakage(·). Since i∗ is not known to B  until the end, it will guess i∗ at the beginning. Let q be the total number of calls to A2 ’s oracles, then with probability more than 1/q (non-negligible), the guess will be correct. In what follows, we will treat pki∗ = pk . Since E occurs, we additionally get pki∗ = pk  = pk ∗ . The adversary B  generates itself $ $ (SK, P K) ← Kg(k), (sk, pk) ← Kg(k), gives params = (P K, pk) to A2 and simulates the oracle calls of A2 as follows.  – Sign(i, m): For i = i∗, return (i, σ) for σ = Sigsk (i m), Sig’ski (m), pki , certi = SigSK (i pki ) , in which B  itself creates (pki , ski ) if needed. If i = i∗ , call its own signing oracle on m to obtain Sig’sk (m); the other values can be produced by B  . – Expose(i): Note that i = i∗ . Return uski = (sk, ski , pki , certi ), and the randomness ωi using in creating (sk, pk), (pki , ski ), and in the Sign oracle above (in the case i = i∗ , B  certainly has uski and ωi ). – Transcript(i): Return (pki , certi ). – LeakageU(i, f ): B  needs to return f (uski , ωi ) for all i. If i = i∗ , then B has the whole (uski , ωi ), so the simulation is trivial. If i = i∗ , we write (1) (2) f (uski∗ , ωi∗ ) = f (sk, ski∗ , pki∗ , certi∗ , (ωi∗ , ωi∗ )). Here, ski∗ = sk  , and (1)   ωi∗ is all the coins used in creating (sk , pk ) and the oracle Sig’sk (·), while (2) ωi∗ is used in creating (pk, sk) and in algorithm Sig. Certainly, B  does not (1) (1) (1) (2) know sk  , ωi∗ , but sets f  (sk  , ωi∗ ) = f (sk, sk  , pk  , certi∗ , (ωi∗ , ωi∗ )), and calls its own leakage oracle on f  , returning to A2 what Leakage(f ) returns. – LeakageH(j, g): Return g(SK, j ) where j is the random coin used by the simulated-by-B  helper in stage j. Finally, B  outputs (m∗ , δ ∗ ) as the forgery against Ω  with (pk  , sk  ). The pair is valid, since Vrf’(pk ∗ = pk  , m∗ , δ ∗ ) = 1, and m∗ was never submitted to the oracle

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

169

Sigsk (·). Since Ω  is leakage-resilient uf-cma-secure, forgery is hardly possible, and hence Pr[(A2 wins) ∧ E] is negligible.   Active adversary. Having known the general impossibility result of Bellare et al. [2] (Theorem 2), we can conclude that the proposal is also insecure against active adversaries over the public channel. Concretely, as a case study, let us see why with our proposal. The adversary calls Expose(0) to obtain usk0 = (sk, sk0 , pk0 , cert0 ). It then runs Kg’(k) to get (pk1 , sk1 ) itself. Since the adversary is an active one, it is allowed to inject the message 1 pk1 over the channel to the helper, and receives cert1 =SigSK (1 pk1 ). It then sets usk1 = (sk, sk1 , pk1 , cert1 ), which is a well-formed secret key for stage 1, forging any message it wants for the stage.

5

A Concrete Instantiation

We will show a concrete scheme derived from the proposal in the previous section by using a recent leakage-resilient signature scheme [1, 14] as the building block for both Ω and Ω  , which is recalled below. Generalized Okamoto-Schnorr Signatures [1, 14]. The signature scheme works on a cyclic group (G, g, p) where g is the generator of order prime p (of size 160 bits). Let l ≥ 3 be a fixed integer, and H : {0, 1}∗ → Zp be a hash function modeled as a random oracle. The key generation algorithm KgOS generates l $ $ elements (g1 , . . . , gl ) ← Gl and the secret key sk = (sk[1], . . . , sk[l]) ← Zpl whose sk[j]

l gj size in bits is l·log2 (p). The public key is (g1 , . . . , gl , P = Πj=1

). The signing $

algorithm on input m and the secret key, generates r1 , . . . , rl ← Zpl and r l gj j , c = H(A, m). The signature on m is (A, c·sk[1]+r1 , . . . , computes A = Πj=1 c · sk[l] + rl ) whose size is (l + 1) log2 (p) bits. The verification algorithm Vrf OS l , α l on input (A, α1 , . . . , αl ), returns 1 if Πj=1 gj j = AP H(A,m) and 0 otherwise. The following theorem is independently proved in [1, 14], intuitively ensuring that the scheme can tolerate leakage up to half of the secret key (more generally, secret state). SigOS l ,

Theorem 6 ([1, 14]). The above signature scheme is (1/2−1/l)l log2 (p)-leakageresilient under the discrete logarithm assumption in (G, g, p), in the random oracle model. Viewing the signature schemes Ω and Ω  as the above generalized OkamotoSchnorr one, we now describe a concrete instantiation, denoted as PCKUSOS l , as follows. OS is run three times to produce (sk, pk), (SK, P K), (sk0 , pk0 ) – KGOS l : Here Kgl l l+1 ∈ Zp × G , denoted as follows.

170

L.T. Phong, S. Matsuo, and M. Yung

    sk[j]  l sk[1], . . . , sk[l] , g1 , . . . , gl , P = Πj=1 gj .     SK[j]  l (SK, P K) = SK[1], . . . , SK[l] , h1 , . . . , hl , Q = Πj=1 hj .      sk [j] l (sk0 , pk0 ) = sk0 [1], . . . , sk0 [l] , u1 , . . . , ul , U = Πj=1 uj 0 . (sk, pk) =

Set the system-wide public key params = (P K, pk) and helper key as hsk0 = SK, and the user initial secret key usk0 = (sk, sk0 , pk0 , cert0 ), where cert0 = SigOS l (SK, 0 pk0 ). – KUPOS l : At the beginning of stage i ≥ 1, the user (with uski−1 = (sk, ski−1 , pki−1 , certi−1 ) runs KgOS to get l     sk [j]  l (ski , pki ) = ski [1], . . . , ski [l] , gi1 , . . . , gil , Pi = Πj=1 gij i , and then send pki to the helper (having hski−1 = SK). The helper returns certi = SigOS l (SK, i pki ) to the user, and again sets hski = SK. The user sets uski = (sk, ski , pki , certi ). – SIGNOS key uski =(sk, ski , pki , certi ), l : On input i, a message m, and the  user OS returns the signature (i, σ) where σ = Sig (sk, i m), SigOS l l (ski , m), pki ,  certi whose size is 4(l + 1) log2 (p) bits. – VRFOS l : On input params, m, and a signature (i, σ), parse σ = (γ, δ, pki , certi ). Return Vrf(pk, i m, γ) ∧ Vrf’(pki , m, δ) ∧ Vrf(P K, i pki , certi ). Combining Theorems 3 and 6, we have the following result. Theorem 7. The scheme PCKUSOS is a strong key-insulated scheme in public l  channel, with (1/2 − 1/l)l log2 (p), (1/2 − 1/l)l log2 (p) -leakage-resilience under the discrete logarithm assumption in (G, g, p) in the random oracle model. Let us consider l = 3 for a concrete comparison with the leakage-resilient signature scheme of Faust et al. [8], who also chose the value for their instantiation with the generalized Okamoto-Schnorr signature scheme. We have 1 1 PCKUSOS l=3 is ( 2 log2 (p), 2 log 2 (p))-leakage-resilient; namely the scheme can tol1 erate 2 log2 (p) bit of information leakage on the helper secret key, and the same amount of leakage on each uncorrupted stage. Note that the helper secret key hski = SK is of 3 log2 (p) bits, and the user secret key for each stage uski is of (4l + 2) log2 (p) = 14 log2 (p) bits. Therefore, the scheme tolerates leakage of 1/6-th fraction of the helper key; and leakage of 1/28-th fraction of the user key which is comparable with that of [8] (of about 1/24-th or 1/36-th fraction). The signature size of PCKUSOS l=3 is 4(3 + 1) log2 (p) = 16 log2 (p) bits, namely the size of 16 group elements. In contrast, that of Faust et al. [8] is about 18 · 30 = 540 group elements (if we accept around 230 signing queries as normal), which is extremely long. These comparisons were reflected in Table 2 in the Introduction.

Acknowledgement We thank Bart Preneel for acting as the shepherd of this paper.

Leakage Resilient Strong Key-Insulated Signatures in Public Channel

171

References 1. Alwen, J., Dodis, Y., Wichs, D.: Leakage-resilient public-key cryptography in the bounded-retrieval model. In: Halevi, S. (ed.) CRYPTO 2009. LNCS, vol. 5677, pp. 36–54. Springer, Heidelberg (2009) 2. Bellare, M., Duan, S., Palacio, A.: Key insulation and intrusion resilience over a public channel. In: Fischlin, M. (ed.) CT-RSA 2009. LNCS, vol. 5473, pp. 84–99. Springer, Heidelberg (2009) 3. Bellare, M., Palacio, A.: Protecting against key-exposure: strongly key-insulated encryption with optimal threshold. Appl. Algebra Eng. Commun. Comput. 16(6), 379–396 (2006) 4. Biham, E., Shamir, A.: Differential fault analysis of secret key cryptosystems. In: Kaliski Jr., B.S. (ed.) CRYPTO 1997. LNCS, vol. 1294, pp. 513–525. Springer, Heidelberg (1997) 5. Boneh, D., DeMillo, R.A., Lipton, R.J.: On the importance of checking cryptographic protocols for faults. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 37–51. Springer, Heidelberg (1997) 6. Dodis, Y., Katz, J., Xu, S., Yung, M.: Key-insulated public key cryptosystems. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 65–82. Springer, Heidelberg (2002) 7. Dodis, Y., Katz, J., Xu, S., Yung, M.: Strong key-insulated signature schemes. In: Desmedt, Y. (ed.) PKC 2003. LNCS, vol. 2567, pp. 130–144. Springer, Heidelberg (2002) 8. Faust, S., Kiltz, E., Pietrzak, K., Rothblum, G.N.: Leakage-resilient signatures. In: Micciancio, D. (ed.) TCC 2010. LNCS, vol. 5978, pp. 343–360. Springer, Heidelberg (2010) 9. Gandolfi, K., Mourtel, C., Olivier, F.: Electromagnetic analysis: Concrete results. In: Ko¸c, C ¸ .K., Naccache, D., Paar, C. (eds.) CHES 2001. LNCS, vol. 2162, pp. 251–261. Springer, Heidelberg (2001) 10. Gonz´ alez-Deleito, N., Markowitch, O., Dall’Olio, E.: A new key-insulated signature scheme. In: L´ opez, J., Qing, S., Okamoto, E. (eds.) ICICS 2004. LNCS, vol. 3269, pp. 465–479. Springer, Heidelberg (2004) 11. Halderman, J.A., Schoen, S.D., Heninger, N., Clarkson, W., Paul, W., Calandrino, J.A., Feldman, A.J., Appelbaum, J., Felten, E.W.: Lest we remember: cold-boot attacks on encryption keys. Commun. ACM 52(5), 91–98 (2009) 12. Hanaoka, G., Hanaoka, Y., Imai, H.: Parallel key-insulated public key encryption. In: Yung, M., Dodis, Y., Kiayias, A., Malkin, T. (eds.) PKC 2006. LNCS, vol. 3958, pp. 105–122. Springer, Heidelberg (2006) 13. Hanaoka, Y., Hanaoka, G., Shikata, J., Imai, H.: Identity-based hierarchical strongly key-insulated encryption and its application. In: Roy, B.K. (ed.) ASIACRYPT 2005. LNCS, vol. 3788, pp. 495–514. Springer, Heidelberg (2005) 14. Katz, J., Vaikuntanathan, V.: Signature schemes with bounded leakage resilience. In: Matsui, M. (ed.) ASIACRYPT 2009. LNCS, vol. 5912, pp. 703–720. Springer, Heidelberg (2009)

172

L.T. Phong, S. Matsuo, and M. Yung

15. Kocher, P.C.: Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 104–113. Springer, Heidelberg (1996) 16. Kocher, P.C., Jaffe, J., Jun, B.: Differential power analysis. In: Wiener, M.J. (ed.) CRYPTO 1999. LNCS, vol. 1666, pp. 388–397. Springer, Heidelberg (1999) 17. Lamport, L.: Constructing digital signatures from a one-way function. Technical Report SRI-CSL-98, SRI International Computer Science Laboratory (October 1979) 18. Merkle, R.C.: One way hash functions and DES. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 428–446. Springer, Heidelberg (1990) 19. Micali, S., Reyzin, L.: Physically observable cryptography. In: Naor, M. (ed.) TCC 2004. LNCS, vol. 2951, pp. 278–296. Springer, Heidelberg (2004) 20. Phan, T.L.A., Hanaoka, Y., Hanaoka, G., Matsuura, K., Imai, H.: Reducing the spread of damage of key exposures in key-insulated encryption. In: Nguyˆen, P.Q. (ed.) VIETCRYPT 2006. LNCS, vol. 4341, pp. 366–384. Springer, Heidelberg (2006) 21. Quisquater, J.-J., Samyde, D.: Electromagnetic analysis (ema): Measures and counter-measures for smart cards. In: Attali, S., Jensen, T. (eds.) E-smart 2001. LNCS, vol. 2140, pp. 200–210. Springer, Heidelberg (2001)

Two-Head Dragon Protocol: Preventing Cloning of Signature Keys Work in Progress Przemysław Bła´skiewicz, Przemysław Kubiak, and Mirosław Kutyłowski Institute of Mathematics and Computer Science, Wrocław University of Technology {firstname.familyname}@pwr.wroc.pl

Abstract. Cryptographic techniques based on possession of private keys rely very much on the assumption that the private keys can be used only by the key’s owner. As contemporary architectures of operating systems do not provide such a guarantee, special devices such as smart cards and TPM modules are intended to serve as secure storage for such keys. When carefully designed, these devices can be examined and certified as secure devices for holding private keys. However, this approach has a serious drawback: certification procedure is expensive, requires very specialized knowledge and its result cannot be verified independently by an end-user. On the other hand, malicious cryptography techniques can be used to circumvent the security mechanisms installed in a device. Moreover, in practice we often are forced to retreat to solutions such as generation of the private keys outside secure devices. In this case we are forced to trust blindly the parties providing such services. We propose an architecture for electronic signatures and signature creation devices such that in case of key leakage, any use of leaked keys will be detected with a fairly high probability. The main idea is that using the private keys outside the legitimate place leads to disclosure of these keys preventing any claims of validity of signatures in any thinkable legal situation. Our approach is stronger than fail-stop signatures. Indeed, fail-stop signatures protect against derivation of keys via cryptanalysis of public keys, but cannot do anything about key leakage or making a copy of the key by a service provider that generates the key pairs for the clients. Our approach is a simple alternative to the usual attempts to make cryptographic cards and TPM as tamper resistant as possible, that is, to solve the problem alone by hardware means. It also addresses the question of using private keys stored in not highly secure environment without a dramatic redesign of operating systems. It can be used as a stand alone solution, or just as an additional mechanism for building trust of an end-user. Keywords: signature-creation device, electronic signature, cloning, tamper evidence, key compromise, legal undeniability. 

The paper is partially supported by Polish Ministry of Science and Higher Education, project N N206 2701 33.  Corresponding author: [email protected] L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 173–188, 2011. c Springer-Verlag Berlin Heidelberg 2011 

174

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

1 Introduction Almost all contemporary cryptographic techniques are based on secrecy of some cryptographic material. Usually, the protocols make a silent assumption that a party holding such a secret is its legitimate owner. In particular, authentication might be based on a proof of possession of a secret owned by the authenticated person, electronic signatures are nothing more but a proof that a person holding a secret has performed certain operation with the signed text. Therefore we require effective control over the keys by their owner and excluding any key leakage. In fact, the control should not only be effective - it should be also verifiable. As effective control over a whole computer system is unrealistic, the secrets are implemented by dedicated devices, such as smart cards and TPM’s. Trusting the smart cards. Validity of smart cards and other hardware units is taken for granted: in fact it is the manufacturer of the card, the card issuer and supervision authority (if any) that are trusted – and only this assures the users of their cards’ correctness. An upsetting fact is that once a key is leaked, there is no way of preventing a clone to be manufactured as well. So far, no leakage-evident devices have been deployed. In many cases a service provider is responsible for creating private keys and uploading them to a trusted device of the user. Consequently, confidentiality of the private keys depends not only on the device. This concerns in particular providing qualified certification services and is permitted explicitly by legislation in many countries (e.g. in Poland). In this case, the service provider must not retain copies of these keys (and any information that would enable to recover these keys, as well) with penalties for not fulfilling these obligations. However, it is relatively easy to hide this information so that proving key retention becomes practically infeasible. Finally, even if the keys are created in a trusted device, we can never be completely sure that the keys are not leaked. For instance, replacing some number of devices by identically looking smart cards but infected with kleptographic code [1] seems relatively easy to perform and extremely hard to identify. Therefore, considerable measures must be taken to assure that, should such clone be manufactured, it will be evident to the legitimate user and will enable him to expose the fraud, or at least revoke the validity of the clone (and thereby, its own smart card). An appealing case study of vulnerabilities occurring at system level rather than end-user level can be found in [2]. A standard way to convince the end-user about security of electronic devices is to set up a certification framework. Security targets are defined (e.g. as protection profiles) and the products are checked for fulfilling these conditions. The inspection process is very work intensive and requires insight into many details that cannot be published (as they are protected industrial secrets of the manufacturer). Moreover, the certification bodies themselves must guarantee the highest level of professional skills and honesty in performing their business. In an ideal case, the higher level of confidence can be reached because deployment of malicious or insecure devices requires collusion between manufacturers and the certification bodies. On the other hand, many opponents indicate that the number of manufacturers as well as certification bodies is very limited. In particular, most countries must rely on products not only manufactured but also certified abroad. From this perspective

Two-Head Dragon Protocol

175

it is easy to see why such smart cards can be distrusted: the producer may be forced by the state to collude and deliver unsafe products to third countries. Much as such conspiracy can be a myth, the potential risks must be taken into account, discouraging deployment of systems based solely on cryptographic tools, especially in countries that have no access to specialized technology and certification laboratories. Even if the process is under full control and high quality of devices is reasonably assured, the end-user may distrust them without any particular reasons. A good example is the situation in the UK, where any kind of electronic identity documents issued by the government is strongly opposed by majority of society distrusting the authorities. At the same time use of mobile phone does not raise any protests, despite data retention and effective location of every mobile phone bearer. Apparently, in order to break this psychological barrier new security mechanisms and arguments are necessary. The goal of this work is to propose protection methods that are independent from hardware tamper resistance and procedural measures. The intended solutions are not to replace these techniques, but to provide new mechanisms that are not based on trust to a certain party and that can be applied jointly. 1.1 Previous Work Tamper evidence. The concept of cryptographic tamper evidence was first introduced by Itkis [3]. The schemes were described, which made it possible to provide cryptographic proofs of breaking the system — a case normally impossible when the breach itself remains undiscovered. To achieve this, Itkis notes that both the original and the forged devices can be viewed as two separate processes that have originated from one common process at some point in time. After the separation, they randomly diverge from one another and therefore, at any later time, the measure of divergence between them can be taken. Specifically, Itkis appends to standard signatures a growing set of additional {signature, public-key} pairs, where the public-secret key pairs are randomly generated. Therefore, even if the adversary captures all secret keys corresponding to the current set of appended signatures at some given time, she has no knowledge of how future signatures will be generated. Consequently, her chances to forge valid signatures in the future are reduced to the problem of either signing without the knowledge of secret keys, or appending signatures with other than original public keys. Fail-stop signatures. In some sense, a similar question is addressed by fail-stop signatures ([4],[5]). They provide protection against a powerful adversary that may break a signature scheme by analyzing the public key and deriving a matching secret key. The idea is that the number of such keys is enormous, so the adversary cannot determine the exact key used by the legitimate user. Moreover, the algorithm guarantees that signing the same message with two different private keys corresponding to the same public key provides two signatures that can be used to solve a hard problem, infeasible for the signer. Our approach makes one step forward compared to the fail-stop signatures. We take care of the situation when the adversary gets access to all secret keys used by the signer.

176

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

Splitting responsibility between multiple entities. Increasing security of signatures can be achieved by splitting responsibility among many devices. One of such techniques is using a signing device and a home base [6] (see also [7]) which together form a forward secure signature scheme on the signing device and use the home base as a kind of a personal CA. Authenticating the keys is done with a hash chain stored by the home base. The main idea is that in case of compromise of the signing device its owner can delete the remaining still undisclosed parts of the hash chain. This way further usage of the signing device is prevented. This solution is effective as long as the adversary does not control both the keys from the signing device and the hash chain from the home base. Consequently, launching a successful attack is more involved. Forward secure signatures are also used in [8] as additional tool merely for user authentication, while signatures under documents might be made using any other scheme. The paper introduces a concept of a so called “grey period”, during which there may be some signatures for which we do not know who should be held accountable: the owner of the keys or the attacker who compromised the system. The aim is to reduce the length of grey periods, what improves accountability in the system and facilitates e-forensic analysis. Aim of our paper is different than accountability – we would like to deter the stronger part of the protocol (i.e. the card issuer or the card manufacturer) from using the keys of the cards owners. Another strategy that involves a third party is to use mediated signature schemes [9]. Here, cooperation between a signing device and a mediator is necessary to create a signature. Consequently, leaking a key from a device does not necessarily lead to creation of signatures by an adversary, as long as the mediator verifies that a legitimate person participates in signature creation. Partial secret revelation. This paper proposes a solution that may remind of that employed in e-money systems preventing double spending (see e.g. [10], [11]). In order to prevent the same e-money being used twice by the same user, during payment the spender reveals some partial information about his identity that is attached to the money token passed to the seller. This information alone cannot be used to reveal the spender’s identity, unless complementary information is provided during other purchases, made with the use of the copies of the original token. Then, the bank is able do reconstruct the identity of the double-spender. Finally, in [12], the concept of an electronic tamper-proof device that keeps track of all the operations and confirming validity of the spent money, the observer is introduced to the same merit. 1.2 Preliminaries Threat model. We address the situation when a device designated for generating signatures gets completely cloned. This includes not only the hardware, but also secret information embedded in the device. We foresee such event possible, given that the device manufacturer has no problem in copying the hardware and kleptographic attacks recovering secret keys exist (see e.g. [13],[14]) . Therefore, we are dealing with the situation where two identical devices (i.e. relating to the same user’s identity, using the

Two-Head Dragon Protocol

177

same keys and generating valid signatures) can exist. One of them is held by the owner of the keys, the second one, if exists, is illegally possessed by a third party. Specifically, if the identity of a user is ID, then for a sign procedure SignID (·) under message M and coupled procedure Ver(ID, ·) verifying the validity of the signature generated by user ID, i.e.:    true for valid ID’s signature under M , Ver ID, SignID (M ) = false otherwise. we have that for any message M the procedure Ver(ID, ·) returns true for results of SignID (·) executed in the original and the cloned cards. However, we do not require that for all messages M it holds that ID SignID orig (M ) = Signclone (M ) .

Legal aspects. In the light of the above definition it is obvious that our proposal deals with the problem of forged identities: if a signature can be generated on behalf of Alice without her consent, it means that -e-identity of Alice has been effectively stolen by the forger. This is a serious threats to the integrity and undeniability of electronic documents flowing in the system. Our position is that digital signatures should be designed so as to provide strong, undeniable proofs of fraud, that are based on the scheme’s properties only. Notation. In the remaining part of this work, we will use the following notation and concepts. By D we denote a cryptographic device that is in use by the legitimate user U . By t we denote a one-way counter embedded in D that can be incremented by one only. Due to security requirements we extend the concept of t in Sect. 3.1. Since in our scheme we combine two signature schemes, a deterministic and a probabilistic one, we denote their respective secret keys by KD and KP , prefixing with P ubl denotes corresponding public keys. We do not restrict ourselves to one particular probabilistic scheme, so where applicable we use C to denote such scheme and use notation C(M ; k) for a situation where k is the random parameter used by C. ·· is a bit-wise concatenation. In our scheme, Rq˜(·) is a pseudorandom number generator that produces numbers in the range [1, q˜]. Typically, M is a number representation of a message to be signed, p, q denote prime numbers and n some (large) composite number.

2 A Simple Solution In order to warm up, we first present a simple solution that might be used as a cheap but still effective alternative to high end protection of private keys. Each device storing the private keys can be equipped with a counter t, which is incremented by one after each operation. Then the valid signature for a message M would have a generic form (Sign(M, idx), idx)

178

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

for any signing algorithm Sign(·) and where idx is a current value of the counter t. Obviously, the duplicate is easily revealed when there are two signatures with the same value of t. This is a very simple and, at a glance, robust scheme. It works as long as the signing device increases the counter as stated and doesn not jump over certain values in order to make room for the cloned device. Since we assume that the manufacturer might be malicious, this can be triggered by an event that occurs after certification of the signing devices. Missing signatures with a certain sequence number can be explained by failures to end up a signing session: the signing device has to create a signature, to increment the counter and to transmit the signature. If the session terminates abnormally, the device cannot be sure whether the signer has received the signature. In this situation, what should be the proper value of the counter t? If according to a design decision, t can be set back to the previous value, then there is room for manipulations by the signer – the card cannot be sure if the transmission has really failed. If t cannot be set back, then the card can cheat and at some moments pretend a restart caused by a failure condition. Legal risk. One can safely assume that the algorithm Sign(·) is secure. If this is so, then the whole security of the scheme is shifted to the hardware. We argue that such complex and highly integrated chips as those used in crypto cards, are manufactured by highly specialized companies which, by the shear nature of their expertise, can be under the supervision of the state. Therefore, under certain conditions, a signature with repeated t could be easily claimed valid by the manufacturer, who is able to perform adequate tests showing that occasionally the counter can “freeze” due to inherent flaws caused by hardware’s degradation in time or by using the card in extreme conditions causing hardware faults. As the service provider is practically always in a better situation than an end-user in any legal dispute, a repetition of the index might be explained by manipulation of the end-user holding the card. Moreover, according to the current legal rules concerning qualified signatures, the signatures created with a secure signature-creation device are considered valid until the corresponding qualified certificate becomes revoked (like e.g. in Germany). All signatures created before revocation of the certificate are regarded valid and it is the signer’s responsibility to prove a fraud for each single signature. In particular, it is the signers duty to prove that double occurrence of an index is due to attack and not to a hardware failure. Unfortunately, it is hard to prove that no failure has occurred. The manufacturer can always claim that the user has exposed the card to extreme conditions to provoke a fault and in this way to put in question all signatures created with this card. On the other hand, the signer has no expertise and insider knowledge to challenge this argument. Last not least, the signing device can pretend a communication fault due to which a certain value of the counter becomes lost. 2.1 Target Application Area The scheme which we propose in the next section does not relay on the correctness of the hardware. It provides indisputable reasons to undermine all signatures made with suspicious device on the basis that the clone and a forged signature in fact do reveal

Two-Head Dragon Protocol

179

secret information. In other words, our scheme replaces a trace indicating that a device might be compromised with an evidence that a secret key has leaked out. This, obviously, provides the owner of the keys firmer grounds in legal proceedings. Also, note that in our proposition the fault is evident and can be confirmed by any independent party. While testing of intricate and complex hardware can be problematic without specialized equipment, in our scheme the test procedures can be performed relatively easily. Last not least, the mechanism of disclosing the keys is aimed for the most distrustful (or even “paranoic”) users. Target application area - issuing signature cards by banks for their customers. The following application of the protocol was proposed by Michał Tabor. Assume that a financial institution is responsible for issuing signature cards for its clients. An electronic signature can be regarded here as very reliable tool securing interests of the bank - the client cannot deny any operation signed digitally. On the other hand, if the signature cards are delivered by the financial institution it might also be the case that the keys loaded into the card are retained for malicious purposes and used in order to authenticate fraudulent operations. Delivering them by a third trusted party solves some of these problems but also increases the costs. If Two-Head Dragon protocol is implemented on the signature cards, then using the retained keys by the financial institution provides an undeniable proof that either the card itself is insecure, or the institution issuing the card has retained a copy of the keys. In both cases the interests of the client are secured so that he can accept without much risk the signature cards provided by the financial institution. On the other hand, the financial institution may depend on products has not gone through a costly formal certification process, as using leaked keys would be detected with high probability. Note that destroying cryptographic evidence of the former signatures does not introduce chaos in a banking accounting system. The record of operations can only be challenged by the owner of the account during a fixed time period, and the operations from the previous accounting period cannot be undermined (e.g. on the basis of the leaked keys).

3 Two-Head Dragon Protocol Since prevention of cloning of cryptographic keys is hardly possible, one has to use some magic. Instead of using smart cards that are only believed to be tamper-proof, we ask a dragon to execute all cryptographic operations. Apart from creating electronic signatures, a dragon is guarding fair use of signature keys. A dragon has two heads; each time when we ask for a signature, one of the heads responds. The answer is not merely a signature, but also a half of some incantation related to the signature. Which half is revealed depends on the the head: the left head reveals the left half, the right head reveals the right half of the incantation. However, a half of an incantation has no magical effect. The situation changes if two dragons get the same cryptographic keys. In fact, not immediately – as long as only one dragon is asked, nothing happens. However, if two

180

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

dragons are asked the same question, then it might happen that one dragon says the left side of the incantation and the other dragon says the right side of the incantation. Once all parts of the incantation are said, the magic starts to work: all signatures created with these keys get burned. In our protocol we try to emulate two-headed dragons and the incantations that burn signatures. Since generating a clone means that all secret information is in the possession of the attacker, the only data distinguishing the legitimate and illegitimate use of the device can be some pseudo-random bit indicated at the moment of signing. We utilise such a pseudo-random bit and combine a deterministic signature scheme with a probabilistic one. The one-bit pseudo-randomness is used to decide which part of the specifically crafted information in the deterministic scheme is revealed. Then, with probability 12 the complementary part can get revealed by the clone. On the whole, the information can be used to break the probabilistic scheme, which leads to a complete secret key disclosure to the public. Therefore, our scheme provides indisputable, cryptographic proof that the clone has been used. 3.1 Preliminaries Probabilistic signature scheme. The probabilistic signature to be used in our proposal should have the following property that we describe for ElGamal signatures. Recall that in ElGamal scheme x is a secret key, g is a publically known constant such that ordg = q˜ is a prime number. We know that for a given signature (r, s), with r = g k , s = k −1 (H(M ) − r · x), leaking the exponent k leads directly to revealing the secret signing key x. Indeed, x = r−1 (H(M ) − s · k). Note that ElGamal-like algorithms (DSA, ECDSA, Schnorr signature, . . .) all share this similar feature due to the fact that a random number k is used once to compute g k and once involved in modular arithmetic operations with the secret key. Deterministic signature scheme. The scheme described below uses Rabin-Williams signature algorithm (later denoted as RW-Sig). We follow the description from [15]: Choose factors p, q of the modulus n such that p ≡ 3 mod 8, q ≡ 7 mod 8 (so in particular, p ≡ q ≡ 3 mod 4). We are interested in the case “B = 0” from Table 1 in [15], that is, a message M to be signed is hashed alone, without any random bits prefixed to it. Let hash Hn be a Full Domain Hash [16] or a PSS padding [17] with salt of length zero, or with a fixed salt. In each of these cases Hn (M ) is a function of M only, and Hn (M ) ∈ {0, 1, . . . , n − 1}. Below we assume that Hn () is collision resistant. RW-Sig uses two additional parameters: e ∈ {−1, 1}, f ∈ {1, 2}. Note that for each of these parameters its value might be indicated by a single bit. They are used to format any Hn (M ) to get a quadratic residue modulo n. That is, for each Hn (M ) we might choose e, f such that (e · f )−1 · Hn (M ) mod n is a quadratic residue modulo n. Let us denote this residue by R.

Two-Head Dragon Protocol

181

The RW signature of M is a triple (e, f, s), where s2 ≡ (e · f )−1 · Hn (M ) mod n.

(1)

That is, s is a square root of R = (e · f )−1 · Hn (M ) mod n modulo n. In fact there are four such roots: If sp , sq are square roots from R, modulo p and q correspondingly, then from Chinese Remainder Theorem (CRT) we have four roots X1 , X2 , X3 , X4 modulo n, determined uniquely by the respective pairs modulo p and q: (sp , sq ), (p − sp , sq ), (sp , q − sq ), (p − sp , q − sq ). Note that X4 = n − X1 and X3 = n − X2 , and since n is odd, exactly  one element −1 in each pair (X1 , X4 ), (X2 , X3 ) is odd. Moreover, since −1 = = −1, as p ≡        p   q   q ≡ 3 mod 4, we have Xn1 = − Xn2 and Xn1 = Xn4 , Xn2 = Xn3 , i.e. both elements in each pair (X1 , X4 ), (X2 , X3 ) have the same value of Jacobi symbol, and the values of Jacobi symbol assigned to the pairs are different. All in all, each of the roots X1 , X2 , X3 , X4 , might be uniquely determined by two bits: the parity bit, and the bit indicating the sign of the Jacobi symbol. These two bits might be randomly chosen (with uniform probability distribution) in an unpredictable way. Note also that having two square roots Y1 , Y2 modulo n from the same value, and at least one of them is chosen uniformly at random from the four possible roots, and the choices are uncorrelated, then we have probability equal to 12 that Y1 ≡ ±Y2 mod n. Accordingly, Y1 −Y2 forms a nontrivial common divisor with n. For example, gcd(X1 − X2 , n) = q, gcd(X1 − X3 , n) = p. Secure one-way counter. The last building block of our scheme is a one-way counter t that we design in a way similar to [7] by means of a home base. During card deployment, the home base produces a hash chain of depth w = Δ·w for some w and Δ equal to say 80 + log2 w , and generates the final chain value W = H (w) (init) to be written in some extension field of the user’s certificate, where init is some initial value chosen randomly by the home base, and H (w) denotes w-fold composition of H. The certificate shall also be stored on the device. The t is always a hash value from the chain ending with W. The way t is incremented is as follows: let t be the current value of the counter stored in the device (initially it is W), and let t−Δ be a value submitted by the home base as the preimage of t with respect to function H (Δ) . The device checks if t = H (Δ) (t−Δ ), and if the equality holds the device makes the assignment t := t−Δ , which means incrementation of the counter. The portion of Δ consecutive values t−1 , . . . , t−Δ from the hash chain shall be used in the new signature. Verification of the signature includes counter checking: does the sequence H (Δ·i) (t), i = 1, 2, . . . , w contain W written in the certificate? The profits of using home base approach over a standard counter are twofold: – Firstly, it is impossible to mount an attack that we mention in Sect. 1 aimed at increasing the internal counter of the cloned card in order to make space for legitimate signatures, as it would require reversing the hash chain. – Secondly, the attacker is forced to use in the clone the already revealed elements of the chain. It will produce the same portion of Δ consecutive values t that have already been used by the legitimate device. As it will be shown later, such a collision is the pivoting point of our scheme necessary for fraud detection.

182

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

Additionally, the parameter w naturally limits the maximum number of signatures that given device can issue, but values as big as w = 216 are perfectly possible to obtain with this approach and making more than 216 signatures during lifetime of a single card seems infeasible for a regular use. 3.2 Card Deployment Before the signer starts to use his card, an initialization procedure is executed in order to make sure that it behaves properly. The procedure consists of the following steps: 1. Initially, the device holds two pairs of private and corresponding public keys: {(KD0 , KP0 ) , (KD1 , KP1 )}

(2)

{(P ublKD0 , P ublKP0 ) , (P ublKD1 , P ublKP1 )}

(3)

generated independently. The first key in each private key-pair is a key for RW-Sig (i.e., the factors of the public key nα , α = 0, 1), the second key is for the scheme C. 2. The device contacts Certificate Authority (CA) and CA commits to two pairs of elements: (α) (α) (α) (challengeCA, (c1 c0 )) (4) (α)

where challengeCA ∈ {0, 1, . . . , nα − 1} is randomly chosen with uniform prob(α) (α) ability distribution, (c1 c0 ) is a pair of random bits and α = 0, 1. 3. The device receives the commitments and submits its own choices: (α)

(α) (α)

(challengeDev , (d1 d0 )) (α)

where challengeDev ∈ {0, 1, . . . , nα − 1} is randomly chosen with uniform prob(α) (α) ability distribution, (d1 d0 ) is a pair of random bits and α = 0, 1. 4. CA reveals pairs (4) for α = 0, 1. 5. Both sides calculate (α)

(α)

challenge(α) = challengeCA + challengeDev mod nα , (α) (α) (α) (α) (α) (α) b1 b0 = c1 c0 ⊕ d1 d0 . for α = 0, 1, where ‘⊕’ denotes xor operation, and pair (α) (α)

(challenge(α) , (b1 b0 ))

(5)

is appended to pair (P ublKDα , P ublKPα ) of public keys, for α = 0, 1. 6. The public keys (3) are self-signed using C with key KPα in such a way that it involves also private keys KDα of the deterministic scheme. Namely, for α = 0, 1 the device creates signatures (α) (α)

CKPα ((P ublKDα , P ublKPα , challenge(α), b1 b0 ); kα ),

(6)

Two-Head Dragon Protocol

183

where 1 ≤ kα ≤ q˜. The number kα is generated with KDα : kα = Rq˜(sα ), where s2α ≡ (eα · fα )−1 · challenge(α) mod nα

(7)

(α) (α)

for some eα ∈ {−1, 1}, fα ∈ {1, 2}, and sα is indicated by bits b1 b0 . The function Rq˜ is pseudo-random number generator1 yielding values in the range [1, q˜]. Note that value challenge(α) is chosen with uniform probability distribution as (α) (α) well as the pair b1 b0 . Hence sα ∈ {0, 1, . . . , nα − 1} is implicitly indicated with uniform probability distribution. Note that by this procedure kα used in C is a function of the main part of RW signature of the challenge(α) (i.e., a function of sα ). The pairs of public keys (3), the pairs (5), and their self-signatures are put into the certificate for α = 0, 1. 7. At the beginning of personalization phase the user is given two pairs (3), two pairs (5), two signatures (6), and then tosses a symmetric coin. The result β ∈ {0, 1} indicates the pair whose private key KDβ

(8)

(i.e. the factorization of the modulus) must be revealed by the device. Then the user (and also the CA) might create the signature (eβ , fβ , sβ ) of the challenge(β) . Using sβ the private key KPβ is computed (by reconstruction of kβ ) and checked against the corresponding public key P ublKPβ . If sβ does not reveal KPβ , then the manufacturer of the device is caught cheating. 8. If everything is correct, the personalization process proceeds, the key (8) together with value β are inserted in some extension field of the certificate generated by CA. For the whole lifetime of the device the key pair P ublKD1−β , P ublKP1−β and the corresponding private keys are used for signing. The keys P ublKD1−β , P ublKP1−β are stated in the certificate as the signature verification keys. Note that if the device manufacturer tries to cheat γ times, in such a way that only one signature under key-pairs (3) is generated according to the formula (7), then the fraud is detected with probability 1 − ( 12 )γ . Consequently, we can safely assume that the manufacturer is unwilling to risk such a fraud. 3.3 Signature Creation and Verification As explained earlier, only one pair of public keys is used during the lifetime of device Dev. (α) (α) In the card deployment phase two random bits (b1 b0 ) were used for each signature made with RW Scheme. That was because we were interested in uniform probability distribution of values sα , which were used as seeds of the pseudo-rando number generator Rq˜. However, in each signature made by the device after the card deployment phase, ephemeral exponent k used by signature algorithm C will be independent of the 1

For example, Rq˜ can be based on a zipper hash [18], or any secure hash function combiner [19].

184

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

RW-Sig scheme. As after the card deployment phase we are interested only in the value of Jacobi symbol of the generated RW signature s (the Jacobi symbol indicates which half of incantation is returned by the dragon) the parity bit of generated s might be chosen by the device. Moreover, since having s from (1) it is easy to find e ∈ {−1, 1}, f ∈ {1, 2} fulfilling (1), we might identify RW signature (e, f, s) with s. Signature generation 1. In order to sign a message M the card receives a next portion of consecutive values from the hash chain ending with W: t−1 , . . . , t−Δ . (We have t−i+1 = H(t−i ), and the card checks correctness of values t−i ). ˜ ˜ is a cryptographically strong hash 2. Hash value H(M ) of M is calculated, where H function, yielding pseudorandom output. Let b1 , . . . , bΔ be the last Δ bits of the hash. 3. For each value t−i , i = 1, . . . , Δ, its square root si , i.e., its RW signature, is calculated by the signing device. Required value of Jacobi symbol of the square root si is indicated by bi (i.e., for each t−i half of incantation is indicated by the message M ). (This step is costly). 4. Concatenation of M , value t−Δ , and sequence S = s1 , . . . , sΔ is signed with the probabilistic scheme CP rob (the scheme CP rob includes some secure hash function H). The Two-Head-Dragon signature is: CP rob (M ||t−Δ ||S), t−Δ , S.

(9)

Signature verification by the user. Having access to M and user’s certificate anyone can check the following conditions: 1. Is t−Δ a value from the hash chain assigned to the user’s certificate? 2. Is the distance between t−Δ and the value W present in the user’s certificate divisible by Δ? 3. Is si a RW-signature of t−i , i = 1, . . . , Δ? ˜ 4. Has si the value of Jacobi symbol indicated by bit bi from the tail part of H(M )? 5. Is (9) a valid signature for M ||t−Δ ||S? 3.4 Situation of an Adversary In order to create a signature of M  , an adversary holding a clone of the original signing device must use some Δ consecutive values t−1 , . . . , t−Δ from user’s hash chain. At the same time message M  to be signed determines a sequence of bits b1 , . . . , bΔ , and the bits indicate halves of incantations (appropriate square roots) for the corresponding t−i . However, the scheme is designed in such a way that to make factorization of the modulus publicly known it suffices that for one i the bit bi (i.e., indication of value of the Jacobi symbol of the square root) is different from the bit calculated by the original card for hash value t−i . Next, due to deployment procedure, factoring the modulus used by RW signatures reveals the private key of CP rob .

Two-Head Dragon Protocol

185

To avoid invalidating all signatures (including the forged one) the adversary must modify M  and search for a sequence t−1 , . . . , t−Δ (starting at a distance from the value W being a multiplicity of Δ) such that bits b1 , . . . , bΔ will agree with those calculated by the original card for this sequence. This is quite unlikely, if the hash chain has capacity of w Two-Head-Dragon signatures and the adversary looks for a collision on Δ = 80 + log2 w bits.

4 Security Considerations 4.1 Remarks on Cloning Assumptions Imagine the cloning procedure at a point in time when the following information is available to the attacker: – the last value of hash chain W – the value hu currently stored in the card (hence also all values hi of the chain, for i ∈ {u, . . . , w − 1}). Of course, the cloner needs to generate t at some state, and it would be unwise if she copied the exact state of the original t. Indeed, she does not know any values in the hash chain before hu the card would be useless. On the other hand, setting t to its original state, i.e., t = W will allow her to use the already revealed elements of the chain. Consequently, we need to assume that a successful cloner is capable not only of rebuilding the hardware of the card, but also can alter the inner state of the card’s registers. 4.2 Composition Issues Below we discuss security of the scheme in the cryptographic sense. This is quite important, however we would like to underline that cryptanalytic strength of the algorithm is only one of the risks involved, and that if something bad happens (like leakage of secret keys due to new cryptanalytic methods, in particular for some particular keys), the attacker cannot use the keys just as in case of a physical attack. The scheme is composed from two secure signature schemes. They are used independently with exactly one exception: at the initialization phase the device yields a signature (1−β) (1−β) b0 ); k1−β )

CKP1−β ((P ublKD1−β , P ublKP1−β , challenge(1−β), b1

where the random exponent k1−β = Rq˜(s1−β ) is derived from a signature obtained with key KD1−β , namely s1−β is a part of RW signature. In order to show that this does not spoil security of the scheme we sketch a reduction proof. First consider a modified scheme S1 for which the number s described above is chosen at random instead of computing an RW signature. We consider an adversary that takes transcripts of the Two-Head Dragon protocol and tries to break at least one of the signature schemes involved (e.g., trying to get a private signing key). Let us

186

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

assume that Two-Head Dragon protocol is insecure, while the scheme S1 remains safe, i.e., there is an algorithm A that works for Two-Head Dragon but not for S1 . In this case we can build a distinguisher that takes as input a number of valid RW signatures and a value z. The distinguisher says if z is a value obtained by Rq˜ from a part of RW signature created according to (7). Indeed, we can generate the keys for C and a transcript of a Two-Head Dragon protocol with k = z. Then we apply A to break it. If we succeed, then the answer is “RW signature”. If we do not succeed, then the answer is chosen at random. If an adversary A has advantage 0 to break the system, if the algorithm from game S0 is applied, and advantage 1 if the algorithm from game S1 is applied, then the advantage of the distinguisher is at least |0 − 1 |/4. In this case the pseudorandom generator can be considered to be weak as it leaks information about the preimage of z. In particular, if we find that the Two-Dragon protocol is weak, then we discover a weakness of the pseudo-random number generator Rq˜, for which no nontrivial property of the preimage should be detectable2 . Also, such a weakness of Rq˜ may lead to irrelevance of random oracle model proofs for protocols, where Rq˜ is used as a pseudorandom number generator. So, we may assume that for functions Rq˜ strong enough breaking S1 is almost as difficult as breaking Two-Head Dragon protocol. Now consider a protocol S2 that differs from S1 so that k is chosen at random instead of being computed as Hq˜(s) from s chosen at random. Again, if there is an attack algorithm A that behaves in a different way for S1 than for S2 , we can build a distinguisher that distinguishes the values produced by Hq˜ from a random seed and the values produced by a fully random generator. (Note that probability distributions can be different there, even for full domain hashes.) So, as before either the pseudo-random number generator Rq˜ shows a serious weakness, or S2 is as weak as S1 protocol. However, S2 is the scheme where both signature algorithms are executed in a fully independent way. So, using a simulator argument built similarly as before, we may show that insecurity of the Two-Head Dragon protocol would lead directly to a weakness of at least one of the schemes involved. To get a formal proof in more classical setting (without referring to properties of pseudorandom number generators) we might apply the random oracle model to the Two Head Dragon protocol and treat Rq˜ as a random oracle. Knowing that RW signature scheme is the inversion of the Rabin encryption scheme, and considering the encryption scheme E G (x) = f (r)||G(r) ⊕ x from page 4 of [20], where G is a random generator and f might be squaring (in our case r = sα from formula (7)), we might borrow the first proof from Appendix A of [20] to prove security of our scheme in the random oracle model.

5 Final Remarks 5.1 Further Applications Limiting the number of signatures to be used. One of the possibilities with our scheme is to provide services that can be used only a limited number of times. A request M becomes accepted if and only if it is signed according to our scheme. The counter 2

In this case, use of Rq˜ for digital commitments should be avoided.

Two-Head Dragon Protocol

187

in this case must have the range corresponding to the number of allowed requests. Any attempt to clone access card and use it at multiple locations would lead to revealing the private key and therefore serve as an evidence of a fraud. Private keys in unprotected environment. Due to lack of appropriate hardware devices or just due to ease of use, sometimes it is admitted to store private keys in an environment that in not protected by hardware means. The users might store their keys in (encrypted) files on a disk, even if the system administrator and the operating system may misuse their access right to clone and use these keys elsewhere for own purposes. In particular, this is the case for such popular products as ssh protocol. In this case it is enough just to prevent misuse of the cloned keys. Two-Head Dragon protocol does not prevent cloning the keys from the disk. However, any attempt to use them outside the attacked system will show security breach with high probability.

6 Conclusion In this paper we presented the Two-Head Dragon Signature Scheme that uses easily available randomness to provide a level of security against cloning the signing device. We made strong assumptions regarding the cloning procedure, i.e. we assumed that all secret information present in the device is available to the attacker. However, our scheme provides 12 probability (for each single signature) of revealing that another device is in operation and uses the same secret material for creating signatures. As electronic means of authorization are getting more widespread, we believe that the problem of fraudulent devices needs further attention to assure the end-users’ safety and privacy. Our Two-Head Dragon Scheme fits well in this problematics, adding a new technique to the landscape: an undeniable cryptographic proof of malicious use of the device claimed to be secure. What we aim for is not only a mechanism that can be checked by cryptographers, but simple enough so that security mechanism can be understood and trusted by an average user. Recently it became widespread accepted that such an approach is necessary in the area of electronic voting. We think that such an approach is necessary as well in the field of electronic signatures: one should have good (and simple) reasons to trust the system even if the hardware, software and even a cryptographic algorithms might be faulty. The proposed schemes have to convince the reader that there are solutions satisfying these conditions and we are not doomed to trust blindly black-box devices, their manufacturers and evaluators.

References 1. Young, A., Yung, M.: Kleptography: Using cryptography against cryptography. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 62–74. Springer, Heidelberg (1997) 2. Drimer, S., Murdoch, S.J., Anderson, R.J.: Thinking inside the box: System-level failures of tamper proofing. In: IEEE Symposium on Security and Privacy, pp. 281–295. IEEE Computer Society, Los Alamitos (2008) 3. Itkis, G.: Cryptographic tamper evidence. In: CCS 2003: Proc. 10th ACM Conference on Computer and Communications Security, pp. 355–364. ACM, New York (2003)

188

P. Bła´skiewicz, P. Kubiak, and M. Kutyłowski

4. Pfitzmann, B., Waidner, M.: Fail-stop-signaturen und ihre anwendung. In: Pfitzmann, A., Raubold, E. (eds.) VIS. Informatik-Fachberichte, vol. 271, pp. 289–301. Springer, Heidelberg (1991) 5. van Heyst, E., Pedersen, T.P.: How to make efficient fail-stop signatures. In: Rueppel, R.A. (ed.) EUROCRYPT 1992. LNCS, vol. 658, pp. 366–377. Springer, Heidelberg (1993) 6. Itkis, G., Reyzin, L.: Sibir: Signer-base intrusion-resilient signatures. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 499–514. Springer, Heidelberg (2002) 7. Zhou, J., Bao, F., Deng, R.H.: Validating digital signatures without tTP’s time-stamping and certificate revocation. In: Boyd, C., Mao, W. (eds.) ISC 2003. LNCS, vol. 2851, pp. 96–110. Springer, Heidelberg (2003) 8. Xu, S., Yung, M.: Expecting the unexpected: Towards robust credential infrastructure. In: Dingledine, R., Golle, P. (eds.) FC 2009. LNCS, vol. 5628, pp. 201–221. Springer, Heidelberg (2009) 9. Boneh, D., Ding, X., Tsudik, G., Wong, C.M.: Instantenous revocation of security capabilities. In: USENIX Security Symposium (2001), http://www.usenix.org/events/sec01/full_papers/boneh/ boneh_html/index.html 10. Chaum, D., Fiat, A., Naor, M.: Untraceable electronic cash. In: Goldwasser, S. (ed.) CRYPTO 1988. LNCS, vol. 403, pp. 319–327. Springer, Heidelberg (1990) 11. Brands, S.: An efficient off-line electronic cash system based on the representation problem. Technical report (1993) 12. Chaum, D., Pedersen, T.P.: Wallet databases with observers. In: Brickell, E.F. (ed.) CRYPTO 1992. LNCS, vol. 740, pp. 89–105. Springer, Heidelberg (1993) 13. Young, A., Yung, M.: A space efficient backdoor in RSA and its applications. In: Preneel, B., Tavares, S. (eds.) SAC 2005. LNCS, vol. 3897, pp. 128–143. Springer, Heidelberg (2006) 14. Young, A., Yung, M.: An elliptic curve backdoor algorithm for RSASSA. In: Camenisch, J., Collberg, C.S., Johnson, N.F., Sallee, P. (eds.) IH 2006. LNCS, vol. 4437, pp. 355–374. Springer, Heidelberg (2007) 15. Bernstein, D.J.: Proving tight security for Rabin-Williams signatures. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 70–87. Springer, Heidelberg (2008) 16. Bellare, M., Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols. In: ACM Conference on Computer and Communications Security, pp. 62–73 (1993) 17. Bellare, M., Rogaway, P.: The exact security of digital signatures - how to sign with RSA and Rabin. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 399–416. Springer, Heidelberg (1996) 18. Liskov, M.: Constructing an ideal hash function from weak ideal compression functions. In: Biham, E., Youssef, A.M. (eds.) SAC 2006. LNCS, vol. 4356, pp. 358–375. Springer, Heidelberg (2007) 19. Fischlin, M., Lehmann, A.: Multi-property preserving combiners for hash functions. In: Canetti, R. (ed.) TCC 2008. LNCS, vol. 4948, pp. 375–392. Springer, Heidelberg (2008) 20. Bellare, M., Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols (1995), http://cseweb.ucsd.edu/~mihir/papers/ro.pdf

Addressing Leakage of Re-encryption Key in Proxy Re-encryption Using Trusted Computing Yanjiang Yang1 , Liang Gu2 , and Feng Bao1 1

2

Institute for Infocomm Research, Singapore {yyang,baofeng}@i2r.a-star.edu.sg Key Lab. of High Confidence Software Technologies, Peking University [email protected]

Abstract. Proxy re-encryption is a cryptographic primitive enabling a proxy holding a re-encryption key to convert a ciphertext originally intended for Alice (delegator) into an encryption of the same message for Bob (delegatee). Proxy re-encryption is a useful tool, having many applications. However, we observe that the issue of re-encryption key leakage, where the delegatee acquires the re-encryption key from the proxy, has been neglected by virtually all of the existing work. Possession of the re-encryption key allows the delegatee to decrypt the delegator’s ciphertexts by himself, without necessarily turning to the proxy for conversion, which may contradict the delegator’s interest. In this work, we present a method to address this issue using trusted computing technology. Our proposal represents yet another application of trusted computing. Keywords: Proxy re-encryption, trusted computing.

1

Introduction

Proxy re-encryption is a public key primitive to achieve delegation of decryption rights, allowing a proxy possessing a re-encryption key to convert a ciphertext originally generated under Alice’s public key into one that can be decrypted by Bob using his own private key. During the conversion, the proxy learns nothing on the underlying plaintext and either of Alice’s private key and Bob’s. In this context, Alice is delegator and Bob is delegatee. In the sequel, we use Alice and delegator (resp. Bob and delegatee) interchangeably. Proxy re-encryption is a very useful primitive, having many applications in distributed file systems [1,2], Mixnets [10], digital rights management [16], encrypted email forwarding [3], law enforcement [7], and so on. As a result, a lot of efforts have been dedicated to the study of proxy re-encryption. State of the Art of Proxy Re-Encryption. Proxy re-encryption evolves from the idea of delegation of decryption rights, which was first proposed by Mambo and Okamoto [14] as a better-performance alternative to the trivial approach of decrypt-then-encrypt (i.e., decrypt the ciphertext to Alice using her private key and then encrypt using Bob’s public key). Shortly after that, Blaze, Bleumer L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 189–199, 2011. c Springer-Verlag Berlin Heidelberg 2011 

190

Y. Yang, L. Gu, and F. Bao

and Strauss [3] furthered this line of research by proposing the notion of “atomic proxy cryptography”, which is eventually developed into proxy re-encryption. Dodis and Ivan [7] were the first to realize unidirectional delegation of decryption (rights). The basic idea for their ElGaml-based scheme is to partition the private key of Alice into two shares, and one is given to the proxy and the other to Bob. Their scheme is not “pure” proxy re-encryption, as decryption by Bob also needs the share from Alice (in proxy re-encryption, decryption should only involve Bob’s private key). Moreover, their scheme is not key optimal, due to the fact that the number of secrets held by Bob grows with the number of delegations he accepts. Ateniese et al. [1,2] presented novel unidirectional proxy re-encryption schemes based on bilinear pairings. Their schemes are non-transitive, collusion resilient, non-interactive, and key optimal, among others (see shortly the desired features of proxy re-encryption). However, Ateniese et al.’s schemes are only secure against chosen-plaintext attack (CPA). Canetti and Hohenberger [4] gave a construction of CCA-secure bidirectional proxy re-encryption scheme. Subsequently, Libert and Vergnaud [11] presented a unidirectional scheme with CCA security. Both of these constructions use bilinear pairings. Proxy re-encryption has also been studied in the identity-based public key setting [9,5,13]. All the above CCA-secure proxy re-encryption schemes are based on bilinear pairings. Weng et al. [8] were thus motivated to construct CCA-secure proxy re-encryption without using pairings. As pairing operations are still computationally costly, Weng et al.’s constructions are of particular interest, especially in applications that use resource limited devices. However, Weng et al.’s schemes do not satisfy collusion resilience, in the sense that the proxy and the delegatee together can recover the delegator’s private key. This is a serious setback in practice. Very recently, Chow et al. [6] solved this problem by extending Weng et al.’s scheme, in such a way that the key of a user consists of two components, with one component being used to mask the other. Shao and Cao [15] also proposed a CCA-secure proxy re-encryption scheme without pairings, which was later found not secure [6,17]. Our Contributions. We observe that all of the aforementioned proxy reencryption schemes suffer from the re-encryption key leakage problem, where the delegatee directly gets the re-encryption key from the proxy, e.g., by collusion or intrusion, such that the delegatee by himself can convert and access the delegator’s messages. To the best of our knowledge, Libert and Vergnaud [12] are the only one to have considered this problem, and their solution is to trace the proxy who leaks the re-encryption key. Such a “tracing-after-the-incident” deterrence strategy is not effective, and a more satisfactory strategy should be “prevention-before-the-incident”. However, it turns out not possible to technically implement this strategy in the standard setting of proxy re-encryption. To get over this obstacle, we propose to extend the standard setting of proxy re-encryption with trusted computing technology. In particular, the proxy machine is equipped with a trusted hardware, and conversions to be performed by the proxy must enlist the help of the trusted hardware. This makes it futile

Addressing Leakage of Re-encryption Key in Proxy Re-encryption

191

for the delegatee to acquire the re-encryption key. We instantiate the idea by presenting a concrete scheme, based upon Chow et al.’s unidirectional proxy reencryption scheme without pairings [6], which is the state of the art of its kind in the literature.

2

Preliminaries

2.1

Model of Unidirectional Proxy Re-encryption

A (single hop) unidirectional proxy re-encryption scheme consists of the following algorithms: – Setup(κ): The setup algorithm takes as input a security parameter κ, and outputs the system parameters param. For brevity, hereafter we assume that param is implicitly included in the input of the following algorithms. – KeyGen(i): The key generation algorithm generates the public/secret key pair (pki , ski ) for user i. – ReKeyGen(ski , pkj ): The re-encryption key generation algorithm takes as input the private key ski of the delegator and the public key pkj of the delegatee. It outputs a re-encryption key rki→j . Preferably, the algorithm is executed by the delegator only, without invoking to the delegatee. – Enc(pki , m): The encryption algorithm takes as input a public key pki and a message m, and outputs a ciphertext that can be converted by the proxy using ReEnc below. – ReEnc(rki→j , ci ): The re-encryption algorithm takes as input a re-encryption key rki→j and a ciphertext ci under public key pki . It outputs a (converted) ciphertext cj of the same message under public key pkj . – Dec(skj , c): The decryption algorithm takes as input of a private key skj and a ciphertext c, and outputs a message m ∈ M or the error symbol ⊥.

The security notions associated with proxy re-encryption are CCA security of encryption and re-encryption, and security of master secret. Informally, the former requires that a ciphertext generated by Enc(.,.) is CCA secure, and the corresponding converted ciphertext from ReEnc(.,.) remains CCA secure. For the latter, it mandates that even if the (dishonest) proxy colludes with the delegatee, it is still impossible for them to derive the delegator’s private key. 2.2

Review of Chow et al.’s Scheme

We recall the basic construction of Chow et al.’s scheme [6]. - Setup(κ): On input a security parameter κ, this algorithm decides a cyclic group Gp of prime order p, and selects g, which is a generator of Gp . Selects five hash functions H1 , H2 , H3 , and H4 such that H1 : {0, 1}l0 × {0, 1}l1 → Zp∗ , H2 : Gp → {0, 1}l0 +l1 , H3 : Gp → Zp∗ , H4 : {0, 1}∗ → Zp∗ . Outputs the system parameters param = (p, Gp , g, H1 , H2 , H3 , H4 , l0 , l1 ). - KeyGen(i): To generate the public/private key pair for user i, this key generation  algorithm picks randomly xi , xi ∈ Zp∗ , and then sets pki = (pki,1 , pki,2 ) = (g xi , g xi )  xi and ski = (ski,1 , ski,2 ) = (xi , xi ). We can view (g , xi ) as the user’s main key,  and (g xi , xi ) as the ancillary key.

192

Y. Yang, L. Gu, and F. Bao

- ReKeyGen(ski , pkj ): On input user i’s private key ski and user j’s public key pkj , this algorithm generates the re-encryption key rki→j from user i to j as below: 1. Pick v  ∈R {0, 1}l0 , π ∈R {0, 1}l1 . Compute v = H1 (v  , π). v 2. Compute V = g v , and W = H2 (pkj,2 ) ⊕ (v  ||π). v   i→j ). 3. Define rki→j = H (pk )·x +x . Return rki→j = (V, W, rk 3 i,2 i i Remark. It is apparent that the proxy (having rki→j ) together with the delegatee (having skj,2 ) can compute H3 (pki,2 ) · xi + xi instead of xi and xi . - Enc(pki , m): On input a public key pki and a plaintext m ∈ {0, 1}l0 , the encryption algorithm works as below: 1. Pick u ∈ Zp∗ , ω ∈ {0, 1}l1 , and compute r = H1 (m, ω). H (pk ) H (pk ) 2. Compute D = (pki,13 i,2 · pki,2 )u , E = (pki,13 i,2 · pki,2 )r , F = H2 (g r ) ⊕ (mω), s = u + r · H4 (D, E, F ) mod p. 3. Output the ciphertext ci = (D, E, F, s). Remark. The intuition behind the construction is as follows: the components (E, F ) can be viewed as a variant of the hashed ElGamal encryption with CCA-security; while the components (D, s) can be viewed as a Schnorr signature on the messages (E, F ) under the verification/signing key pair (E, r). - ReEnc(rki→j , ci ): On input a re-encryption key rki→j , a ciphertext ci under public key pki , this algorithm converts/re-encrypts the ciphertext as follows:  i→j ). 1. Parse ci as ci = (D, E, F, s) and rki→j as rki→j = (V, W, rk H (pki,2 )

2. Check whether (pki,13

· pki,2 )s = D · E H4 (D,E,F ). If not, output ⊥. (r·(H (pk

)·x +x ))·

v

3 i,2 i  i→j i r·v H3 (pki,2 )·xi +x  = E rk i = g 3. Otherwise, compute E =g ,  F, V, W ). and output ciphertext c˜j = (E, - Dec(skj , c˜j ): On input a private key skj = (x, x ) and converted ciphertext c˜j =  F, V, W ), this algorithm first computes (v  , π) = W ⊕ h2 (V x ) and (mω) = (E,  v1 ), and returns m if V = g H1 (v ,π) and E  = g H1 (m,ω)·v hold; returns ⊥ F ⊕ H 2 (E otherwise.

This scheme is proven secure in terms of CCA security and master secret security, and details of the proof can be found in [6].

3

Our Method

As mentioned earlier, it is not possible to prevent the leakage of re-encryption key in the standard setting of proxy re-encryption, where delegator, proxy, and delegatee are the only participants of the system, and each of the delegator and the delegatee has a key pair for public key encryption. We get over this problem by extending the standard setting of proxy re-encryption to equip the proxy machine with a trusted hardware, such that the proxy (although having re-encryption key in possession) cannot perform re-encryption without the assistance of the trusted hardware. 3.1

Overview of the Method

Extended Setting. Making use of trusted computing technology, we propose to equip the proxy machine with a tamper-resistant trusted hardware such as IBM Cryptographic Coprocessor or TPM (Trusted Platform Module) defined in

Addressing Leakage of Re-encryption Key in Proxy Re-encryption

193

the TCG specifications. The trusted hardware is a secure coprocessor, capable of moderate computation and providing a limited amount of secure internal storage. While residing within a host machine, the trusted hardware generates a secure computing environment independent of the underlying host. We require that the trusted hardware holds a key pair (pkT C , skT C ) for public key encryption, where the public key pkT C is publicly verifiable while the private key skT C resides within the hardware and no one (including the host operator) can extract it out. CPA security of the encryption suffices for our use. Basic Idea. Given that the trusted-hardware-augmented proxy is in place, a trivial solution to the re-encryption key leakage problem is to let the trusted hardware manage the re-encryption key and delegate the re-encryption procedure to the trusted hardware. However, this method is clearly not desirable, considering the limited resources and computation capabilities of the trusted hardware. We should incur upon the trusted hardware as minimum workload as possible. The basic idea of our actual method is as follows. When a sender generates a ciphertext to the delegator, she/he additionally encrypts the resulting ciphertext with the trusted hardware’s public key; consequently, during re-encryption the proxy has to first ask the trusted hardware to decrypt using its private key, and then converts the resulting ciphertext as usual. As such, as re-encryption must need the trusted hardware’s private key, even the delegatee obtains the re-encryption key, he by himself still cannot perform reencryption. In other words, it is futile for the delegatee to have the re-encryption key, unless he also has the trusted hardware’s private key. Unfortunately, it is not appropriate to trivially encrypt the delegator’s entire ciphertext with the trusted hardware’s public key, as that will also make it impossible for the delegator to decrypt. Recall that although the ciphertext is intended to be converted, it is generated towards the delegator in the first place. Hence, the main challenge is that on the one hand, the delegator’s ciphertext needs to be further wrapped under the trusted hardware’s key, while on the other hand, this extra layer of encryption should not affect the delegator’s ability for decryption. We resolve this difficulty by cleverly exploiting the structure of the ciphertext in Chow et al.’s scheme: only a part of the delegator’s ciphertext is encrypted to the trusted hardware, and the remaining part still allows the delegator to decrypt and recover the plaintext. We achieve this by slightly modifying Chow et al.’s scheme. As final notes, for clarity purposes we outline the comparison between the standard setting for proxy re-encryption and the extended setting we are considering in Figure 1. The Figure is self-explanatory, and we do not bother to elaborate it further. 3.2

Modifying Chow et al.’s Scheme

Our method needs a slightly modified variant of Chow et al.’s scheme [6]. To avoid repetition, below we only highlight the modifications that we need to make to Chow et al.’s scheme. Recall that in the Enc(pki , m) algorithm, the ciphertext

194

Y. Yang, L. Gu, and F. Bao

(pkTC,skTC) (rkA->B)

cA

cA=Enc(pkA,m)

Proxy

(rkA->B)

cB

cA

Alice (pkA,skA)

Bob (pkB,skB)

Delegator

Delegatee

Standard Paradime of Proxy Re-Encryption

cA=Enc(pkA,m)

Proxy

cB

Alice (pkA,skA)

Bob (pkB,skB)

Delegator

Delegatee

Our Extended Paradime

Fig. 1. Comparison Between Standard Setting and Extended Setting

is defined to be c = (D, E, F, s), where D = ((pki,1 )H3 (pki,2 ) · pki,2 )u , E = ((pki,1 )H3 (pki,2 ) · pki,2 )r , F = H2 (g r ) ⊕ (mω), s = u + r · H4 (D, E, F ) (mod p), with u ∈R Zp∗ , ω ∈R {0, 1}l1 , and r = H1 (m, ω). The main modification we need to do is to partition E into two parts (E1 , E2 ), i.e., E1 = (pki,1 )H3 (pki,2 )·r , E2 = (pki,2 )r , and accordingly, s = u + r · H4 (D, E1 , E2 , F ) (mod p). Naturally, in the ReEnc(rki→j , ci ) algorithm, the proxy accordingly needs to first compute E = E1 · E2 , and then performs the re-encryption as in the original scheme. The above modifications are quite simple and straightforward, and they do not affect the security of the scheme. Indeed, following the proofs given in [6] (with slight adjustments in response to the above modifications), we can prove that the modified scheme satisfies CCA security and master secret security. We thus have the following theorem, and the detailed proof is omitted, as most of it is a repetition of those in [6]. Theorem 1. (Security of Modified Scheme) The above variant of Chow et al.’s scheme satisfies CCA security and master secret security, as defined in the standard model of proxy re-encryption. 3.3

Details of Our Method

We are now ready to present our method to address the issue of re-encryption key leakage in the extended setting where the proxy is equipped with a trusted hardware, and the trusted hardware is capable of public key encryption/decryption. The trusted hardware has a certified key pair (pkT C , skT C ) for a standard public key encryption scheme, and we let ET C (.) (resp. DT C (.)) denote encryption under pkT C (resp. decryption with skT C ). Our scheme is based on the above variant of Chow et al.’s scheme, and only differs in Enc(·, ·) and ReEnc(·, ·), and other algorithms remain the same as in the variant scheme. To be specific, below we give a detailed description of the two algorithms in our scheme, and especially, the alterations needed to done are highlighted in [square].

Addressing Leakage of Re-encryption Key in Proxy Re-encryption

195

– Enc(pki , m): 1. Pick u ∈ Zp∗ , ω ∈ {0, 1}l1 , and compute r = H1 (m, ω). 2. Compute D = ((pki,1 )H3 (pki,2 ) · pki,2 )u , E1 = ET C ((pki,1 )H3 (pki,2 )·r ) , E2 = (pki,2 )r , F = H2 (g r ) ⊕ (mω), s = u + r · H4 (D, E1 , E2 , F ) mod p. 3. Output the ciphertext ci = (D, E1 , E2 , F, s). – ReEnc(rki→j , ci ):  i→j ). 1. Parse ci = (D, E1 , E2 , F, s), and rki→j = (V, W, rk 2. Ask the trusted hardware for decryption of E1 , who returns E1 = DT C (E1 ) , and then compute E = E1 · E2 . 3. Check whether ((pki,1 )H3 (pki,2 ) · pki,2 )s = D · E H4 (D,E1 ,E2 ,F ) holds. If not, output ⊥. (r·(H3 (pki,2 )·xi +xi ))·

 i→j  = E rk 4. Otherwise, compute E =g  F, V, W ). and output ciphertext c˜j = (E,

v H3 (pki,2 )·xi +x i



= g r·v ,

Correctness of the scheme is straightforward. It is also easy to see the intuition on how the re-encryption key leakage problem is solved: the re-encryption algorithm needs (pki,1 )H3 (pki,2 )·r , which is encrypted under pkT C and can be decrypted only by the trusted hardware. Therefore, even if the delegatee acquires the re-encryption key, he still cannot perform re-encryption as he has no access to the trusted hardware. As such, leakage of the re-encryption key to the delegatee is of no help to him, i.e., having the re-encryption key does not help the delegatee to re-encrypt using the re-encryption key (and then perform decryption using his own private key). It remains to see why the delegator is still enabled to decrypt the ciphertext, although she has no access to the trusted hardware either. In fact, the knowledge of (E2 , F ) suffices to allow the delegator to recover the plaintext m. To see this, it is easy to see that the delegator can still compute g r (which in turn can  be used to undo F ) by only using E2 = (pki,2 )r = g x ·r and ski,2 = x . As a matter of truth, (E2 , F ) alone constitutes a ciphertext of a CCA secure ElGamal  encryption with respect to (pki,2 = g x , ski,2 = x ). 3.4

Security Analysis

With a trusted hardware being introduced into our (extended) setting, it seems that the existing security model (in terms of CCA security and master secret security) for standard proxy re-encryption, e.g., the one in [6]), does not suit our scheme, and a new model accommodating the trusted hardware is needed. However, we argue that as the access to the trusted hardware is exclusively given to the proxy and hidden from other entities, it is not unreasonable to abstract the proxy and the trusted hardware into a single (logical) entity. In particular, the decryption operation performed by the trusted hardware during re-encryption is treated as an inherent part of the re-encryption algorithm, and the key pair (pkT C , skT C ) possessed by the trusted hardware is treated as a part of the re-encryption key held by the proxy (i.e., the re-encryption key of the proxy is now (skT C , rki→j ).

196

Y. Yang, L. Gu, and F. Bao

Of course, pkT C is treated as a part of the delegator’s public key). Through this layer of abstraction, it is not necessary to establish a new security model, and we can still discuss the security of our scheme within the existing one. It should be a clear fact our method does not affect the master key security of the above variant of Chow et al.’s scheme. Thus, below we focus on CCA security of our scheme. Intuitively, at least our scheme does not weaken (if not strengthen) the CCA security of the variant of Chow et al.’s scheme. Indeed, there exists an obvious reduction from the security of our scheme to the security of the variant of Chow et al.’s scheme. Theorem 2. (Security of Our Scheme) Security of the variant of Chow et al.’s scheme implies the security of our scheme. Proof. Suppose there exists an adversary A that breaks the CCA security of our above

scheme, we construct an adversary B that breaks the CCA security of (the variant) of Chow et al.’s scheme. In fact, the construction of B is quite simple. But to be specific, the details are given as follows. Given the system parameter of (the variant) of Chow et al.’s scheme, B establishes a key pair (pkT C , skT C ) for each proxy and uses it to simulate the behavior of the corresponding trusted hardware on top of Chow et al.’s scheme to A. That is, to augment Chow et al.’s scheme with (pkT C , skT C ) as described above. To answer a re-encryption or decryption oracle query from A, B first performs decryption upon E1 using skT C , and then accesses the corresponding oracle of Chow et al.’s scheme and returns to A whatever the oracle returns. To answer a re-encryption key generation oracle access, B returns to A the reply of the corresponding oracle of Chow et al.’s scheme, together with a corresponding skT C . The simulation by B is perfect. When given a challenge ciphertext of Chow et al.’s scheme, B encrypts the E1 part using pkC , and challenges the resulting ciphertext to A; finally, B outputs whatever A outputs. Clearly, B distinguishes the challenge ciphertext with an advantage no less than that A distinguishes of hits challenge. This completes the proof. 

Finally, note that for CCA security and master secret security, our scheme does not require any extra security property on the public key encryption of the trusted hardware, except correctness (i.e, decryption inverses encryption). Of course, to qualify for addressing leakage of re-encryption key, the encryption should be at least CPA secure.

3.5

Discussions

In this section, we discuss several important issues associated with our method. Certification of Public Keys. The first issue to discuss is the certification of users’ public keys. Specifically, a user’s key material includes two components (pki,1 =  g x , ski,1 = x) and (pki,2 = g x , ski,2 = x ), both are ElGamal-type key pairs. In practice, the certificate (under a PKI) for a public key does not necessarily cover both components. In particular, we can treat (pki,1 , ski,1 ) as the main key, with usage beyond the setting of proxy re-encryption, e.g., it is a key pair in the regular sense, used for encryption and digital signature. In contrast, we see (pki,2 , ski,2 ) as an ancillary key, specific to proxy re-encryption. Consequently, it

Addressing Leakage of Re-encryption Key in Proxy Re-encryption

197

suffices to only certify (pki,1 , ski,1 ) under the PKI, while (pki,2 , ski,2 ) is certified by (pki,1 , ski,1 ). Further, recall that in our method, a sender who encrypts data to a user must also use the public key pkT C of the trusted hardware of the user’s proxy. Usually, the trusted hardware’s public key is certified by a different PKI, which would incur additional overhead upon the sender for key verification. A better method is that the delegator herself is responsible for verification of the proxy hardware’s public key (under its PKI), and after verification, she includes and certifies the public key as a part of her certificate. The consequence is that senders only need to trust the PKI for pki,1 . As such, Figure 2 depicts the structure of a user’s public key certificate.

certify

certify pki,1

PKI

pki,2 pkTC

Fig. 2. Structure and Certification Relationship of User Certificate

Proxy Invisibility. It is evident that in our method, the sender needs to be aware of the existence of the proxy (more precisely, the proxy’s trusted hardware). This clearly compromises proxy invisibility, which is a feature may be desired in certain applications (see Section 1). However, by our above suggestion to embed the trusted hardware’s public key into the delegator’s certificate, we have already mitigated this concern, in the sense that all that a sender sees is the delegator’s public key and certificate. Time Limited Delegation. Ateniese et al. [1,2] suggested time limited delegation, such that a delegation is temporary, only valid for a short period of time. Temporary delegation facilitates revocation of delegation. They proposed an efficient mechanism to renew delegation by assuming the existence of a trusted universal server, who periodically broadcasts a new system parameter; using this new parameter, all users re-establish re-encryption keys with their respective proxies. A drawback of this method is that all users’s delegations are forced to expire after a period. A more satisfactory solution should be such that only the delegation of the user who wants to revoke expires, while others’ remain valid. In general, a delegator renewing her key can trivially achieve this objective, but it is clearly not satisfactory either. Our scheme can better implement the general approach of key renewing: the delegator only renews the ancillary key, while keeping the main key intact; after renewal, the main key again certifies the new ancillary key.

198

4

Y. Yang, L. Gu, and F. Bao

Conclusion

In this paper, we proposed an extended setting of proxy re-encryption by equipping the proxy with a trusted hardware, in order to address the leakage of reencryption key. We proposed a concrete scheme, based on a variant of Chow et al.’s scheme: a portion of the delegator’s ciphertext is further wrapped with the trusted hardware’s public key; consequently, the proxy has to first turn to the trusted hardware for decryption of the wrapped part, in order to perform reencryption. As such, it is futile for the delegatee to acquire the re-encryption key. An interesting (yet challenging) part of our method is that the additional layer of encryption under the trusted hardware’s public key does not affect the delegator’s decryption capability, although she does not have access to the trusted hardware. Our method is specific to Chow et al.’s scheme. A generic method that is applicable to proxy re-encryption in general is our future work. Our proposal demonstrates the utility of the trusted computing technology, and can be viewed as yet another application of trusted computing.

References 1. Ateniese, G., Fu, K., Green, M., Hohenberger, S.: Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage. In: Proc. NDSS 2005, pp. 29–43 (2005) 2. Ateniese, G., Fu, K., Green, M., Hohenberger, S.: Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage. ACM Transactions on Information and System Security (TISSEC) 9(1), 1–30 (2006) 3. Blaze, M., Bleumer, G., Strauss, M.: Divertible Protocols and Atomic Proxy Cryptography. In: Nyberg, K. (ed.) EUROCRYPT 1998. LNCS, vol. 1403, pp. 127–144. Springer, Heidelberg (1998) 4. Caneti, R., Hohenberger, S.: Chosen-Ciphertext Secure Proxy Re-Encryption. In: Proc. ACM CCS (2007) 5. Chu, C., Tzeng, W.: Identity-Based Proxy Re-Encryption without Random Oracles. In: Garay, J.A., Lenstra, A.K., Mambo, M., Peralta, R. (eds.) ISC 2007. LNCS, vol. 4779, pp. 189–202. Springer, Heidelberg (2007) 6. Chow, S.M., Weng, J., Yang, Y., Deng, H.: Efficient Unidirectional Proxy ReEncryption. In: Bernstein, D.J., Lange, T. (eds.) AFRICACRYPT 2010. LNCS, vol. 6055, pp. 316–332. Springer, Heidelberg (2010) 7. Dodis, Y., Ivan, A.-A.: Proxy Cryptography Revisited. In: Proc. of NDSS 2003 (2003) 8. Deng, H., Weng, J., Liu, S., Chen, K.: Chosen-Ciphertext Secure Proxy Reencryption without Pairings. In: Franklin, M.K., Hui, L.C.K., Wong, D.S. (eds.) CANS 2008. LNCS, vol. 5339, pp. 1–17. Springer, Heidelberg (2008) 9. Green, M., Ateniese, G.: Identity-Based Proxy Re-Encryption. In: Katz, J., Yung, M. (eds.) ACNS 2007. LNCS, vol. 4521, pp. 288–306. Springer, Heidelberg (2007) 10. Golle, P., Jakobsson, M., Juels, A., Syverson, P.F.: Universal Re-Encryption for Mixnets. In: Okamoto, T. (ed.) CT-RSA 2004. LNCS, vol. 2964, pp. 163–178. Springer, Heidelberg (2004)

Addressing Leakage of Re-encryption Key in Proxy Re-encryption

199

11. Libert, B., Vergnaud, D.: Unidirectional Chosen-Ciphertext Secure Proxy Reencryption. In: Cramer, R. (ed.) PKC 2008. LNCS, vol. 4939, pp. 360–379. Springer, Heidelberg (2008) 12. Libert, B., Vergnaud, D.: Tracing Malicious Proxies in Proxy Re-Encryption. In: Galbraith, S.D., Paterson, K.G. (eds.) Pairing 2008. LNCS, vol. 5209, pp. 332–353. Springer, Heidelberg (2008) 13. Matsuo, T.: Proxy Re-Encryption Systems for Identity-Based Encryption. In: Takagi, T., Okamoto, T., Okamoto, E., Okamoto, T. (eds.) Pairing 2007. LNCS, vol. 4575, pp. 247–267. Springer, Heidelberg (2007) 14. Mambo, M., Okamoto, E.: Proxy Cryptosystems: Delegation of the Power to Decrypt Ciphertexts. IEICE Trans. Fund. Electronics Communications and Computer Science E80-A/1, 54–63 (1997) 15. Shao, J., Cao, Z.: CCA-Secure Proxy Re-encryption without Pairings. In: Jarecki, S., Tsudik, G. (eds.) PKC 2009. LNCS, vol. 5443, pp. 357–376. Springer, Heidelberg (2009) 16. Smith, T.: DVD Jon: Buy DRM-less Tracks from Apple iTunes (January 2005), http://www.theregister.co.uk/2005/03/18/itunespymusique 17. Zhang, X., Cheng, M.-R., Li, X.: Comments on Shao-Caos Unidirectional Proxy ReEncryption Scheme from PKC 2009. Cryptology ePrint Archive, Report 2009/344 (2009), http://www.eprint.iacr.org/

Can Hand-Held Computers Still Be Better Smart Cards? Sandeep Tamrakar1, Jan-Erik Ekberg2, Pekka Laitinen2 , N. Asokan2 , and Tuomas Aura1 1

Aalto University School of Science and Technology, Finland [email protected], [email protected] 2 Nokia Research Center, Helsinki {jan-erik.ekberg,pekka.laitinen,n.asokan}@nokia.com

Abstract. Smart cards using the ISO/IEC 7816 interface are widely used for authentication, ticketing and legacy secure applications. When used with host computers, the smart card typically connects to the host computer over a USB or RS232 smart card reader. This paper presents implementations of an architecture where a Trusted Execution Environment (TrEE) in a smartphone is used as the security foundation for implementing security modules based on the ISO/IEC 7816 smart card standard. The smartphone software emulates both the smart card reader and the card, and thus no new drivers are needed in the host to enable the use of the smart card emulation. Keywords: Security, Smart Cards, Platform Security, Smartphone Security.

1

Introduction

Smart cards are widely used as a secure place to store sensitive information such as private keys, account numbers, passwords etc. The tamper-resistant environment provided by the smart card ensures the security of the stored data. In addition, smart card also provides an isolated environment capable of processing the sensitive information without exposing it to the external environment. However, smart cards are inflexible in the sense that the card often only serves a single purpose and is unusable once the service expires. Thus, a user subscribing to multiple services from multiple service providers ends up with many cards that need to be carried everywhere for service use. In addition, the user may also have to carry a card-reader in order to be able to use services from common host devices such as personal computers which are typically not equipped with built-in smartcard readers. The lack of a user-interface (UI) on the card implies that smart cards have no trusted path [30] to the user. Thus they are vulnerable to spoofing, PIN-stealing, and man-in-the-middle attacks. Ten years ago, Balfanz and Felten [3] presented an architecture where a Software Smart Card (SSC) functionality is implemented on a Personal Digital Assistant (PDA) rather than as a separate hardware module. Their main argument L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 200–218, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Can Hand-Held Computers Still Be Better Smart Cards?

201

still holds true today — as the embedded device has a direct interface to the user, it can provide a trusted UI for inputting authorization PINs. However, the past decade has also advanced the state of technology significantly, and the dedicated, slow, unconnected PDAs of the late 90’s have been replaced by smartphones. The new devices not only manage the user’s data, calendar and address book, but also provide a wealth of sensing and communication interfaces, and most importantly provide 3rd party programmability. The smartphones of today are in essence very close to personal computers when it comes to openness and feature richness. Thus, it is reasonable to ask whether SSCs in such modern personal handheld devices can still be better than smart cards. This paper re-explores and refines the SSC concept in a world where the PCs and laptops already include established APIs for accessing hardware credentials like smart cards. Also, the almost ubiquitous smartphones come with secure execution environments, direct communication channels of their own and standardized wired and wireless interfaces compatible with desktops and laptops. With respect to Balfanz and Felten’s work [3], this paper presents a revised SSC architecture and reference implementation that seamlessly integrates with legacy host computers over several communication interfaces while also providing trusted execution for the tokens and a configuration server for smart card templates. With these mechanisms in place we can securely support virtually any kind of smart card templates and applications. Thus, we claim that a smartphone with a Trusted Execution Environment (TrEE) and SSC is architecturally well positioned to replace physical smart cards in many scenarios. The paper is organized as follows. We initiate the discussion by introducing the use-case setting for the work, and security requirements for the credential implementation in Section 2. Important background technologies as well as relevant standards and APIs are described in Section 3. Our architecture is presented in Section 4. Sections 5 and 6 describe the implementation, performance measurements and a security analysis. Some earlier works are briefly explained in Section 7. Section 8 provides conclusions and further work. Finally, acknowledgements section ends the paper.

2

System Requirements and Use Cases

For smart cards, there are standard specifications [22] that define the security requirements for smart cards of different security levels. The main property that the smart card specifications emphasize is the property of isolation. Credential secrets as well as the code that operates on them must be isolated both from the host device that uses the smart cards, and internally between the respective credential algorithms and security domains that may exist on the smart card. As we in this work will diverge from the traditional hardware-oriented view, we consider the following security requirements for the SSC smart card and the system as a whole:

202

S. Tamrakar et al.

1. Isolation of the smart card credential from system software and from other credentials, and protection from hardware attacks against the isolated environment that hosts the credentials. 2. Privacy and integrity and sometimes confidentiality of smart card communication. The traditional smart card satisfies mainly the isolation property but it is assumed that the credential is physically attached to the host computer (by means of a local wire like a serial port or a USB bus), and it is considered acceptable to e.g. transport PIN codes in the clear between the user application and the card. When the local channel constraints are lifted, the security requirements of that channel must be revisited. 3. Secure communication channel to the host computer: If the smart card is connected to the host by a personal area radio network like Bluetooth, or remotely via the Internet, issues related to device pairing and endpoint authentication must be accounted for. Another aspect of endpoint authentication exists if we want to identify the calling application with respect to the smart card credential. 4. Provisioning system integrity and confidentiality. If smart card credentials or their secrets are remotely provisioned, then the credential provisioning to the smart card should be cryptographically secure. Secure provisioning also implies a need for SSC device authentication as well as user authentication. Our initial objective was to implement a software stack and interface that would in terms of functionality be indistinguishable from a smart card reader and a smart card. Since USB is nowadays ubiquitous both in host computers and on smartphones, we chose this channel to be the primary interface between the peers. This set-up was tested with the PKCS#15 template of Finnish Electronic Identity Card (FinEID)1 , the citizen electronic identity in Finland. Presently we can use all available host computer drivers for this card with our SSC setup. We wanted to go further, though. The ISO/IEC 7816 smart card interface has been used for more than 20 years, and a wealth of credentials like Id Cards, SIMs, payment cards, electronic wallets, public transport tickets, credit cards and even physical keys adhere to this messaging interface. When implemented as software, these credentials can potentially be purchased on the Internet, remotely provisioned, and depending on policy further be backed up, moved between TrEEs, remotely managed and even copied. In our architecture, none of these new features need to be visible to existing legacy systems that use the ISO/IEC 7816 Application Protocol Data Unit (APDU) credential interface to communicate. Also, remote access to software credentials can potentially be arranged in a more convenient manner than with physical smart cards, which need a reader attached directly to the host computer. Since the smartphone can communicate over a variety of networks, it may be possible to use them to connect our SSC to the computer. Additionally, parallel access to the credential — locally from the smartphone as well as from an attached host computer — can be used 1

Finnish Electronic Identity Card:http://www.fineid.fi

Can Hand-Held Computers Still Be Better Smart Cards?

203

for multi-factor or multi-channel authentication or to cryptographically bind communication sessions to each other.

3

Background

In this section, we briefly describe some of the standards and middlewares used for accessing smart cards from a host computer as well the TrEE used in our SSC. 3.1

Standards in the Field

ISO/IEC 7816 Smart Card Standards is an international standard published and maintained jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It describes different features and usages of Integrated Circuit(s) Cards (ICC), i.e. smart cards. We describe some of the parts of this standard that are relevant to this work: ISO/IEC 7816-3 defines the power and signal structures for operating smart cards as well as two asynchronous half-duplex transmission protocols. Especially it defines the format for the “Answer to Reset” (ATR) sequence which specifies the communication capabilities of a smart card [11]. ISO/IEC 7816-4 describes how application data residing on the smart card is organized into a hierarchical file structure, its access rights, and the commands used to access and update the data [12]. ISO/IEC 7816-8 defines commands for private-key operations and extended PIN functionality [13]. Card lifecycle management commands (like file deletion) are defined in ISO/IEC 7816-9 [14]. The ISO/IEC 7816-15 defines a common syntax and format for storing, managing and accessing cryptographic information (i.e. PKCS#15 information) on the card, essentially outlining a card profile for RSA/X.509-enabled authentication credentials [10]. A fully functional smart card emulator must support most of the command set defined in these specifications. PKCS#11 is a Public Key Cryptogrphy Standard (PKCS) published by RSA Laboratories that defines a standard interface for accessing cryptographic services on different kinds of portable cryptographic devices such as Smart Cards, USB Tokens, PCMCIA cards. The standard is also known as Cryptographic Token Interface (Cryptoki) [18]. Cryptoki presents a common logical model, called cryptographic token, to applications. The model is independent of underlying cryptographic hardware. Cryptoki also handles application (and token) multiplexing, and provides a session context for the communication. Personal Computer / Smart Card (PC/SC) is a specification developed and maintained by the PC/SC workgroup. It defines an interface for applications to access smart card services. Its main component, the ICC Resource Manager, is responsible for coordinating and managing all the access to the smart cards present in the system [28,29].

204

S. Tamrakar et al.

The resource manager first identifies and records all smard card (reader) resources available in the system. It also observes events like card insertions and removals to maintain an accurate state representation. It also manages application multiplexing and specifically controls the communication sequences for accessing services on smart cards. Since the cards are single threaded devices, they often require a sequence of commands to complete a single function. Following this communication sequence ensures the integrity of the final results [29]. 3.2

Trusted Hardware

During the last decade, several types of TrEEs have emerged based on the general-purpose secure hardware. These have been incorporated into PCs and smartphones, and are nowadays widely deployed. Available technologies include the Trusted Platform Module (TPM) [27] that by definition is a self-contained, stand-alone secure element. An associated processor feature, the Dynamic Root of Trust for Measurement (DRTM), sets up a limited TrEE [20] within the logic confines of an Intel VTx or AMD processors. For smartphones, a number of designs like Mobile Trusted Modules (MTM) [7], M-Shield [26] and ARM TrustZone [1] are available. These are either hardware agnostic (e.g. MTM), or augment the processing core for increased security. The latter can be typically combined with isolated RAM and ROM residing within the ASIC as well as with some amount of chip-specific “write-once —read many times” memory, typically implemented with E-fuses. The principle of a TrEE is to set up an isolated environment safe from attackers and eavesdroppers operating within the OS and the system software, and preferrably also from attackers that perform hardware attacks like memory-bus eavesdropping or physical side-channel attacks. To achieve isolation, a dedicated processing mode (in some cases even a dedicated processing core) provides a computing context with its own registers and I/O handling within the TrEE. Memory chips accessible only from that dedicated processing mode provide secure storage locations (code, stack and heap) for the programs that are executed in the isolation. Non-volatile E-fuses are often uniquely accessible from the TrEE, thus providing a storage that can be used as a trust root (e.g. a public key hash) and seed material for cryptographic key generation. The entry to the TrEE is often subject to the issuer control, i.e. the code to be executed in the TrEE context has to be cryptographically signed which an entry process (e.g. in ARM TrustZone a ’monitor’) validates before executing [1,26]. These mechanisms together set up a system that is logically very close to a smart card — an isolated environment with its own processing and storage capability. The TrEE setup chosen for this work is the On-board Credentials (ObC) architecture [2,6,16]. For the target implementation, the design uses ARM TrustZone on processors by Texas Instruments. In short, ObC relies on the isolation properties of the underlying hardware. Additionally, it provides a provisioning system and a byte-code interpreter with an extensive cryptographic API for the

Can Hand-Held Computers Still Be Better Smart Cards?

205

implementation of credential alogrithms (ObC Programs). The constrained internal memory capacity of the TrEE is overcome by support for piecewise execution of the byte-code credential. A system service, the Credential Manager, manages the code invocation i.e. the execution of the credentials in the context of the TrEE. In addition, it also servers as the application interface (API) towards ObC-enabled applications. The implementation also includes hardware-specific and proprietary mechanisms for getting a device key, generated within ObC, certified by a Certification Authority.

4

Architecture

Our main motivation when designing the SSC architecture has been to make it compatible with existing host hardware and software. A requirement to install some new drivers is always an impediment to deployment. Fortunately for us, the smart card communication stack is well specified and also very cleanly layered between the ISO/IEC 7816 APDUs and their transfer protocols. Thus, we can separate the Smart Card Engine (SCE) from the interface device (IFD). We have chosen to emulate a USB smart card reader interface as the primary IFD for exposing the SSC to the host computer. For convenience, we separate the notion of a smart card (instance) from a smart card template. The template corresponds to an uninitialized card, and when secrets are generated or files written to the smart card the template is instantiated. Thereafter, the smart card instance is what corresponds to a traditional smart card. The SCE provides the basic features of an ISO/IEC 7816 smart card command set, i.e. the ISO/IEC 7816-4 file system processing as well as some other wellspecified APDUs like the authentication primitives as defined in ISO/IEC 7816-8. The SCE will keep smart card instances separate and protects secrets like PINs or secret keys using ObC. For legacy cards, like ticket cards for public transport or One Time Password (OTP) cards, extended APDU command sets can be provided as plug-in packages. Such a package contains a card-template specific SCE plug-in as well as the needed ObC programs (and possibly secrets). The SSC can accommodate a number of smart cards and smart card templates in the same device. The user can manage the set of active smart cards through the Smart Cards Selection Engine. The Local Authentication Engine queries the user for PINs and passwords related to the smart card files and operations. Even though the USB IFD is our main host computer interface, we have also implemented alternative IFDs. In one demonstration, we implemented a door lock, i.e. an embedded device in its own right, that remotely queried the SSC in the smartphone through an IFD over TCP/IP. With remote access e.g. Bluetooth IFDs, the IFD channel itself must however implement some secure pairing protocol and depending on the use case, also ensure APDU integrity and

206

S. Tamrakar et al.

Smart Card Provisioning Server (SCPS)

Authentication Server

Smart card Templates

E.g. TLS connection

Legacy Smart card Middleware Stack

Smart card Selection Engine

Local Authentication Engine

SCE plugin

ISO/IEC 7816-15 based File System

Smart Card Engine

Web Browser

PKCS#11 library

Host Computer

ISO/IEC 7816 based communication

IFD Emulator

OS Kernel

TrEE (ObC)

Smartphone

Fig. 1. Our SSC Architecture

confidentiality protection. On the upside, the alternative channels provide some interesting use cases for remote authentication as well as proximity-triggered operation. Our smart card emulation will run all cryptographic operations inside the ObC TrEE. In its basic form, the credential emulates an RSA smart card. The system operates in a way where signatures and decryption operations are done within the TrEE, and since the private RSA keys never leave that environment in plaintext form, the system is conceptually close to a physical smart card. By choosing ObC as the building block we are not limited to RSA tokens only. Any credential algorithm that can be implemented as an ObC program using the byte-code interpreter can be used to emulate the corresponding smart card application. Thus, the system is extensible e.g. towards travel card standards (say Mifare DESFire 2 ), one-time token cards or even systems like the GSM/UMTS SIM algorithms and interfaces. The implementation described in this paper is focused specifically on RSA credentials, though. In addition to providing smart card access over IFDs to the host computers, smartphone local operation is also enabled, e.g. for smartphone browser authentication. In this way, the same credential or smart card can be seamlessly accessed both from an external host computer as well as from the smartphone itself. The overall architecture is depicted in the Figure 1. In the next subsections, some additional architectural details will be given.

2

Mifare DESFire: contactless Multi-Application IC with DES and 3DES security.

Can Hand-Held Computers Still Be Better Smart Cards?

207

Fig. 2. Legacy Smart Card Middleware Stack on the host computer

4.1

Host Computer Smart Card Middlewares and Smart Card Filesystem

A diagram of the legacy smart card middleware stack on a host computer is provided in Figure 2. Applications that require cryptographic operations call a PKCS#11 library (Cryptoki) for accessing cryptographic tokens. The Cryptoki library provides a standard interface for accessing services on various cryptographic devices [18]. However, native Windows applications such as Internet Explorer and Microsoft Outlook instead use a legacy cryptographic framework provided by Microsoft [4]. This framework includes a cryptographic API (CryptoAPI), through which applications access Cryptographic Service Providers (CSP). In general, a CSP provides cryptographic functionality to its caller, redirecting the cryptographic requests to the underlying cryptographic device attached to the system. In a similar manner, Mac OS X defines the Common Data Security Architecture (CDSA) for cryptographic services. Here applications use the Common Security Service Manager (CSSM) APIs provided by CDSA for interacting with CSPs [19]. The PC/SC Resource manager maintains and controls the active smart card resources. Microsoft has implemented the PC/SC stack that provides the PC/SC functionalities on Windows OS. The pcsc-lite daemon developed by the MUSCLE3 project provides the PC/SC functionality on Linux and Mac OS. IFD handlers establish and manage the low-level communication channels between the smart card (reader) and the PC/SC resource manager. The USB CCID driver is a typical IFD handler. 3

MUSCLE: Movement for the Use of Smart Cards in a Linux Environment www.linuxnet.com

208

S. Tamrakar et al.

MF

EF

EF

DF

DF

EF

DF

EF

EF

Fig. 3. Smart Card File Structure

A Smart card stores information in files. The files are organized in a treelike structure as in the Figure 3. The Master File (MF) is the root of the file system. ISO/IEC 7816-4 defines two types of files: Dedicated Files (DF), which represent subdirectores and Elementary Files (EF), which contain application information. Any file can be PIN-protected. A smart card may contain multiple applications. Each application corresponds to a DF. Information common to all the application as well as data related to the card life-cycle management are stored directly under the MF. An application can be selected by using a unique application identifier [12]. The smart card is typically accessed using synchronous APDU commandresponse pairs. In the most typical configuration, APDUs share a common header format and are limited to carrying at most 255 bytes of payload. Even simple operations like reading a specified files are translated into sequence of APDUs which are managed by the PC/SC manager. 4.2

Smart Card Provisioning Server

One important element in our architecture is the smart card provisioning server (SCPS). Such a component is essential since physical smart cards almost without exception come pre-provisioned with file structures and applications that are specific to the smart card use case, its manufacturer or both. Even for generic crypto cards, all of which in principle adhere to a common standard, the same applies. The cards differ to such a high degree that the driver components on the host side have been tailored to each specific card to be interoperable. As one main target for our design is to be seamless in terms of specification, we have had to adapt to this reality. In its current instantiation, the SCPS is a web service that interacts with the smart card engine over HTTP, typically directly over the phone’s own network connection. The user selects the card template based on his current needs and the smart card engine contacts the SCPS. If the SCPS knows the template, it will return an ATR and a complete ISO/IEC 7816-15 application file system image, possibly even including root certificates. The smart card engine checks the authenticity of the package, and then installs the file system into persistent memory. The certificate enrolment is done as its own procedure, separate from this provisioning step. Currently, only the ISO/IEC 7816-15 feature set is supported by our SCPS. However, the power of the TrEE can enable it to securely provision secrets

Can Hand-Held Computers Still Be Better Smart Cards?

209

and keys that form the content of a possibily PIN-protected “smart card files”, and to provision algorithms, i.e. smart card applications that will be usable in the context of a given smart card template. SSC device

SCPS EP KSCP S (SK, H(P KSSC )), devCertP KSSC



  

AESK (ISO7816f ilesystem)

-

basic smart card template setup

AESK (SCEplugin) AESK (ObCP rov(secret), metadatax) AESK (ObCP rov(ObCP rogram), metadatay )

advanced template setup

Fig. 4. Provisioning protocol overview

The template provisioning protocol is outlined in Figure 4. To address privacy concerns with customized templates, a context with both confidentiality and integrity protection is set up between the smart card emulation component and the SCPS. This context is achievable using e.g. TLS with server authentication. However, to make TrEE-assisted template context binding possible (or even move to completely TrEE-based smart card emulation in the future) we use a more lightweight protocol based on a AES-EAX authenticated encryption (AE), where a SSC device-generated session key SK is transported in encrypted format to the SCPS, and subsequently used to protect the protocol messages and bind the protocol flow to the SSC device. The advanced template setup includes secrets and programs that will be run inside the TrEE. These messages are protected all the way into the TrEE, and form an inner provisioning channel without server authentication4 . For this, we use the ObC provisioning, described in [16], which is based on the device certificate devCertP KSSC sent to the SCPS in the first protocol message. We augment the ObC provisioning messages with metadata that describes the binding between the provisioned TrEE programs and secrets and the relevant data and functions in the SCE template. For example, a provisioned TrEE program may constitute a proprietary authentication function bound to a ISO/IEC 7816 command in the relevant template, and a provisioned TrEE secret can be mapped to an elementary (key) file only accessible to e.g. the provisioned function. 4.3

Credential Life-Cycle

As long as the SSC is used to emulate existing smart cards, the life-cycle model needs to adapt to existing models. We foresee that a typical life-cycle of a simple credential, say a generic authentication card would look as follows: 4

The outer TLS channel should be server authenticated in order to protect against man in the middle attacks for the ISO/IEC 6816 filesystem. For credential secrets, the ObC provisioning is man in the middle resistant due to certificate binding of the provisioned data.

210

S. Tamrakar et al.

– The user buys a SSC-capable smartphone. – When the user decides to use a specific type or brand of card, he will download its smart card template from a central server. For integrity, the SCPS protocol forms a session where each message is integrity protected, and where the protocol endpoints can be authenticated. If the smart card were more esoteric than a generic crypto card, the template will also include an SCE plug-in and TrEE code. In the simple case, the template consists of an ATR vector and ISO/IEC 7816-15 file layout. – The user instantiates one or several copies of the smart card template on his device. Every instance will get its own filesystem image and persistent storage for secrets managed by the TrEE. – The user selects one of the instances. After selection, the smart card instance is visible through the IFD towards external host computers or to the smartphone browser. – A smart-card-specific enrollment step is carried out. For PKCS#15 cards, this may imply either generating a new key in the card (in this case within the TrEE) or using an existing key. In either case, the public component of the key, along with possibly existing certificates for that key, is released to the host computer which can enroll it with a relevant certificate authority (CA). The host computer will write the certificate returned by the CA to an ISO/IEC 7816-4 file on the SSC. – After a completed enrollment, the smart card instance is ready to be used. E.g. in client authentication with TLS, the host computer will query the SSC for the key certificate as well as ask the SSC to sign a challenge. The PIN query that accompanies the signature can be answered by the user either on the host computer or, preferably, on the smartphone. – The credential lifetime ends when its certificate expires or when the certificate is put on a revocation list by the relevant service infrastructure or when the smartphone user decides to erase the credential.

5

Implementation

Our implementation runs on host computers with all major OSs: Windows (XP, Vista, 7), Linux (Debian, Ubuntu), Mac OS X (Snow Leopard). The SSC is implemented on Nokia N900 with Linux OS (Maemo 5) and Nokia X6 with Symbian OS. The IFD handlers for USB card readers are readily available for all host systems. Microsoft provides the generic USB CCID driver for Windows, and the MUSCLE project provides the same interface for Linux and Apple Macintosh. Our SSC driver is compatible with all of these. In Maemo, the kernel provides a composite USB Gadget framework that allows any embedded Linux device to act as a USB slave device. This framework provides necessary APIs for handling USB communication between the SSC host

Can Hand-Held Computers Still Be Better Smart Cards?

Fig. 5. Smartphone SSC connected with Windows Host PC via USB connection

211

Fig. 6. IFD Choices

Fig. 7. Accessing Trusted Server

and the driver. Our USB CCID (emulator) driver is implemented in the gadget framework5. Towards the host computer, it provides the USB smart card reader descriptors during initialization and then represents the reader in further communication. Towards the SCE, the driver sets up a device file interface (/dev/ttyGS* 6 ). The SCE daemon connects to the character device and handles 5 6

Linux-USB Gadget API framework http://www.linux-usb.org/gadget where * represents a port number associated during the gadget driver setup

212

S. Tamrakar et al.

all the APDU commands as well as coordinates ObC invocations, the smart card template provisioning, local authentication and smart card instance selections. On Symbian, the driver and the SCE are not cleanly separated due to the lack of a driver abstraction similar to the Gadget framework. The TCP/IP IFD for remote card access, was also implemented in Symbian. In our tests, we have mainly used the FinEID card template. For the host computers, the Finnish government distributes the mPollux DigiSign Client card reader 7 software (by Fujitsu-Siemens) which includes the necessary CSP and Cryptoki interfaces on all three OSs. On Linux host computers, we also tested interoperability with OpenSC, an open-source project that provides PKCS#11 interfaces to applications such as the Firefox web browser and email clients. We have tested our system against FINEID-aware servers, e.g. in Figure 7, as well as performed email signing tests on Linux (with Thunderbird & Evolution) and Windows (Microsoft Outlook, Thunderbird). 5.1

Speed Measurements

In 1999, Balfanz and Felten [3] measured quite modest speeds for SSC operations — a 1024-bit RSA signature took on average 25 seconds and key generation could take up 30 minutes. The data transfer and processor speeds for PDAs and smartphones have significantly improved since then and we can now determine that an SSC actually operates faster than a legacy smart card. Table 1. Speed comparison between SSC and one real smart card (units are in seconds with 95% confidence interval) Initialization Signature Smart Card 7.40 (±0.7) 1.09 (±0.004) Nokia X6 (symbian) 3.76 (±0.22) 0.38 (±0.007) Nokia N900 (maemo) 1.08 (±0.2) 0.50 (±0.012)

Table 1 shows the average time for our system to associate with a host on a Windows machine compared to a physical smart card inserted in an USB reader. During the association phase the CSP will identify the card and load user certificates from the card into its own memory. The table also shows signature generation times for a 1024-bit RSA key. The data shows that our system initializes significantly faster than a real smart card. This is because the smart card and reader processors are slower than the smartphone CPUs. The reference RSA smart card is a Gemalto (Setec) SetCos 4.3 card.

6

Security Analysis

In this section we provide an informal analysis of the security properties achieved by our architecture. 7

mPollux DigiSign Client card reader software http://www.intermin.fi/vrk/fineid/home.nsf

can be downloaded from

Can Hand-Held Computers Still Be Better Smart Cards?

213

The isolation of credential secrets will be guaranteed by the TrEE and the ObC, as is outlined in [16]. The integrity of the ISO/IEC 7816-15 file system information is protected by platform security in Symbian, and by basic UNIX file permissions in the Maemo OS. We assume that only non critical data and integrity protected data like certificates are stored in plain text within this file system. However, for this ISO/IEC 7816 filesystem, an attacker with root privileges may perform a denial of service attack or even a roll back attack in TrEE without statefullness protection. The roll back threat can be alleviated by using external trusted memories [5] . The physical isolation properties of the TrEE cannot be assumed to be of the same level as a standalone smartcard. Good smartcards provide e.g. side channel protection and tamper proof operations. Current TrEEs based on isolated on chip memories usable only in a dedicated processor mode will not achieve as good protection against these more advanced attack mechanisms. The secure communication channel between the host computer and the SSC device will depend on the IFD channel. In the case of USB, the fact that the channel is wired will provide the necessary assurance for the user. In case of Bluetooth, the BT pairing protocol and the resulting secure sessions will provide an encrypted (although not integrity-protected) channel for APDU transmission. In the demonstration where TCP/IP was used, an intermediary Internet server provided a password-protected session context, through which the host computer and the SSC could communicate. Integrity and confidentiality for this setup can be provided for example, with TLS. Confidentiality and integrity of the data exchange with the SCPS is guaranteed by the ObC provisioning protocol [16]. The SSC has a device certificate that certifies a provisioning key. For smart card templates transferred to the device, family keys [16] are generated and sent to the device encrypted by the device key. Further, each device secret and secret credential code related to the template is encrypted with an authenticated encryption primitive, using a derivation of the family key, for transfer to the SSC. Further, endorsement statements can be constructed and transferred to device for endorsing the right for a given ObC program, i.e. a smart card application, to operate on secrets in a given family. Based on this family-related information, the ObC provides domain isolation for provisioned secrets and any further keys generated in the context of the ObC programs endorsed to the family. In the case of reusable smart card templates, no secrets are provided during provisioning and there will be, within the domain, a mapping between generated secrets and smart card instances. The security of this mapping is currently managed by platform security alone. An attack on this mapping would not expose the secrets but there is a potential credential mis-use threat. The selection of smart cards and PIN inputs are managed on the phone. Thus, they are protected by platform security on the SSC device as well as by the fact that, when used from a remote host computer, the user interface is in a physically separate device. Neither of these mechanisms fully guarantees the trustworthiness of the interface but the resulting security is still significantly

214

S. Tamrakar et al.

better than, for example, if the PIN input happened on a host computer that does not have hardware-assisted platform security, and is susceptible to viruses and root-kits. The PIN protects the unauthorized use of the SSC by an attacker with physical device access (theft). In case, PIN validation is performed inside the TrEE in the same context as the requested cryptographic operation then the flash reading attacks and virus / rootkit attacks can be mitigated. Thus, for the device theft (device borrowing) scenario, the phone trustworthiness is from the users’ perspective roughly comparable to the case where the phone includes a physical smart card. However, physically removing a smartcard eliminates some further attacks (e.g. brute-forcing the PIN). This feature is not trivially achievable with an SSC. Solutions to this issue have been considered in [15].

7

Related Work

To our knowledge the presented SSC architecture is the first one that uses a TrEE to secure the smart card credential operations. The inclusion of the SCPS in this context is also new to the research community. However, the following earlier work defines the fundaments for implementing a software based smartcard. Several network-assisted PKI approaches such as Virtual Soft Tokens [17,23] and Virtual Smartcards [8,24] have been proposed. The Virtual Soft Token uses a password that encrypts a private key and the encrypted private key is stored on a server. Later, the user establishes a secure connection to the server using the password and retrieves the encrypted private key. The key is then decrypted locally before its use. In the case of Virtual Smartcard, the private key is split into two parts: a human readable password and a secret component. The secret component is stored away from the user in a remote server and is never revealed. E.g. when signing a message, the message is first securely transfered to the server where the first secret component performs the first half of the signing operation and the user’s part then operates on the result of the network server to produce a complete result. Either key component can never produce the result by itself. These solutions require real-time network connectivity to work. Ion and Dragovic in [9] proposed an enhanced secure trusted payment method to be used on Point of Sale (POS) terminal by combining the features of smartphone and a smart card. The smartphone and the card both share a secret based on which the phone generates a one time password to be used as a PIN during payment. The card generates a one time visual token based on the payment information provided by the POS terminal. This token is displayed on the POS terminal and is scanned by the phone using its built-in camera. An associated phone application then decodes the token and displays the information for user verification. Once the user has verified the token, the phone generates a one time PIN to be used on the POS terminal for confirming the payment. The method requires additional application support both on the smart cards and the POS terminals. Another approach proposed by Schuba et al.[25] utilizes a GSM SIM as a security token. While accessing an online service from a browser on a computer,

Can Hand-Held Computers Still Be Better Smart Cards?

215

the server redirects the browser to the Identity Provider (IDP) Server for authentication. At this point, the browser must establish a secure connection with the phone. Within the secure connection, the authentication is carried out using challenge/response method based on a uniquely shared secret between the SIM and the IDP. Once authenticated, the user can access online services. This method requires active involvement of the 3rd party for authentication as well as some additional middleware on the computer, service provider server, and on the SIM. The work by Morgner and Oepen in their Master’s thesis [21] augments the approach by Balfanz and Felten [3]. Implemented in an OpenMoko smartphone, their method does not require modification of the host computer’s middleware stack. Their SSC interfaces with the host computer using a USB connection, and the smart card emulation core emulates two specific cards (the German passport, Schlumberger CryptoFlex cards). They do not, however, provide any hardwarebased isolation for credential secrets, nor does their architecture mention any extensibility beyond the two implemented card types.

8

Conclusions and Future Work

Our implementation is only in its early stages, i.e. we currently implement only the support for PKCS#15 card variants. The possibility to implement any legacy smart card functionality using a full-blown SCPS implementation will be a next step. This will most likely expose some new architectural challenges, also in security terms, in the interfaces between the SCE, its plug-ins, and the TrEE code. We also plan to explore some of the new usage patterns made possible by this architecture in the context of user studies and usable security. Still, we can at this stage already conclude that our design makes it possible to leverage the security of TrEEs to implement and provision SSCs. This is proven not only in a theoretical sense but our real-world reference implementation running on two different mobile OSs and compatible with the three mainstream host computer OSs shows that no unsurmountable technical obstacles remain to deploy such technology. The SSC architecture described in this paper allows personal devices such as smartphones to be better smartcards, despite the fact that the personal devices have become comparable to personal computers in terms of connectivity and openness. The flexibility of SSCs will add new types of usages models to the smart card ecosystem. It paves the way for smartphones to become “personal trusted devices”.

Acknowledgements The first part of the work was supported by Nokia Research Center, Helsinki. The later part of this work was supported by TEKES as part of the Flexible Services program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT), and by the Aalto University MIDE project OtaSizzle. The first author’s work was done while visiting Nokia Research Center, Helsinki.

216

S. Tamrakar et al.

References 1. ARM. Technical reference manual: Arm 1176jzf-s (trustzone-enabled processor), http://www.arm.com/pdfs/DDI0301D_arm1176jzfs_r0p2_trm.pdf 2. Asokan, N., Ekberg, J.-E.: A platform for onboard credentials. In: Tsudik, G. (ed.) FC 2008. LNCS, vol. 5143, pp. 318–320. Springer, Heidelberg (2008) 3. Balfanz, D., Felten, E.W.: Hand-held computers can be better smart cards. In: SSYM 1999: Proceedings of the 8th Conference on USENIX Security Symposium, p. 2. USENIX Association, Berkeley (1999) 4. Microsoft: TechNet library - Smart Cards, http://technet.microsoft.com/en-us/library/bb742533.aspx (accessed 2010) 5. Ekberg, J.-E., Asokan, N.: External authenticated non-volatile memory with lifecycle management for state protection in trusted computing. In: Chen, L., Yung, M. (eds.) INTRUST 2009. LNCS, vol. 6163, pp. 16–38. Springer, Heidelberg (2010) 6. Ekberg, J.-E., Asokan, N., Kostiainen, K., Rantala, A.: Onboard credentials platform: Design and implementation. Technical Report NRC-TR-2008-001, Nokia Research Center (August 2008), http://research.nokia.com/files/NRCTR2008007.pdf 7. Ekberg, J.-E., Kylanpaa, M.: Mobile trusted module. Technical Report NRC-TR-2007-015, Nokia Research Center (November 2007), http://research.nokia.com/files/NRCTR2007015.pdf 8. Ganesan, R.: Yaksha: augmenting kerberos with public key cryptography. In: Proceedings of the 1995 Symposium on Network and Distributed System Security (SNDSS 1995), p. 132. IEEE Computer Society, Washington, DC, USA (1995) 9. Ion, I., Dragovic, B.: Don’t trust pos terminals! verify in-shop payments with your mobile phone. In: SPMU 2008, Sydney, Australia (May 2008) 10. ISO/IEC 7816-15: Identification cards - Integrated circuit cards - Part 15: Cryptographic information application, 1st edn. ISO, Geneva, Switzerland (2004) 11. ISO/IEC 7816-3: Identification cards - Integrated circuit cards - Part 3: Cards with contacts - Electrical interface and transmission protocols, 3rd edn. ISO, Geneva, Switzerland (2006) 12. ISO/IEC 7816-4: Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange, 2nd edn. ISO, Geneva, Switzerland (2005) 13. ISO/IEC 7816-8: Identification cards - Integrated circuit cards - Part 8: Commands for security operations. 2nd edn. ISO, Geneva, Switzerland (2004) 14. ISO/IEC 7816-9: Identification cards - Integrated circuit cards - Part 8: Commands for card management, 2nd edn. ISO, Geneva, Switzerland (2004) 15. Kostiainen, K., Asokan, N., Ekberg, J.-E.: Credential disabling from trusted execution environments. In: Aura, T., Nyberg, K. (eds.) Preproceedings of the 15th Nordic Conference on Secure IT Systems (Nordsec 2010), pp. 162–177. Aalto University School of Science and Technology (December 2010) 16. Kostiainen, K., Ekberg, J.-E., Asokan, N., Rantala, A.: On-board credentials with open provisioning. In: Proceedings of the 4th International Symposium on Information, Computer, and Communications Security, ASIACCS 2009, pp. 104–115. ACM, New York (2009) 17. Kwon, T.: Virtual software tokens - A practical way to secure PKI roaming. In: Davida, G.I., Frankel, Y., Rees, O. (eds.) InfraSec 2002. LNCS, vol. 2437, pp. 288–302. Springer, Heidelberg (2002)

Can Hand-Held Computers Still Be Better Smart Cards?

217

18. RSA Laboratories (ed.) PKCS # 11: Cryptographic Token Interface Standard. v2.20, RSA Laboratories (2004) 19. Mac OS X Reference Library: Security Architecture, http://www.developer.apple.com/mac/library/documentation/Security/ Conceptual/Security Overview/Architecture/Architecture.html 20. McCune, J.M., Parno, B.J., Perrig, A., Reiter, M.K., Isozaki, H.: Flicker: an execution infrastructure for tcb minimization. In: Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, Eurosys 2008, pp. 315–328. ACM, New York (2008) 21. Morgner, F., Oepen, D.: Eine virtualisierte smartcardarchitektur f¨ ur mobile endger¨ ate. Master’s thesis, Institut f¨ ur Informatik Systemarchitektur, Humboldt University, ZuBerlin (2009) 22. NIST. Security requirements for cryptographic modules, http://csrc.nist.gov/publications/PubsFIPS.html 23. Perlman, R., Kaufman, C.: Secure password-based protocol for downloading a private key. In: Proceedings of the 1999 Network and Distributed System Security (1999) 24. Sandhu, R., Bellare, M., Ganesan, R.: Virtual smartcards versus virtual soft tokens. In: Smith, S. (ed.) 1st Annual PKI Research Workshop, pp. 89–94. Dartmouth College Computer Science Department (April 2002) 25. Schuba, M., Gerstenberger, V., Lahaije, P.: Internet id - flexible re-use of mobile phone authentication security for service access (2004), http://www1.ericsson.com/res/thecompany/docs/ journal conference papers/service layer/internet id nordsec.pdf 26. Srage, J., Azema, J.: M-Shield mobile security technology, TI White paper (2005), http://focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf 27. Trusted Platform Module (TPM) Specifications, https://www.trustedcomputinggroup.org/specs/TPM/ 28. PCSC Workgroup (ed.) Interoperability Specification for ICCs and Personal Computer Systems - Part 1. Introduction and Architecture Overview. Revision 2.01.01, PC/SC Workgroup Specifications (September 2005) 29. PCSC Workgroup (ed.) Interoperability Specification for ICCs and Personal Computer Systems - Part 5. ICC Resource Manager Defination. Revision 2.01.01, PC/SC Workgroup Specifications (September 2005) 30. Yee, K.-P.: User interaction design for secure systems. In: Deng, R.H., Qing, S., Bao, F., Zhou, J. (eds.) ICICS 2002. LNCS, vol. 2513, pp. 278–290. Springer, Heidelberg (2002)

218

A

S. Tamrakar et al.

Abbreviations

AMD APDU API ARM ASIC BT CA CCID CDSA CryptoAPI CSP CSSM DF DRTM eFUSE EF GSM HTTP ICC IDP IEC IFD VTx ISO MF MSs MTM MUSCLE NFC ObC OS OTP PC PCMCIA PC/SC PDA PIN PKCS PKI POP POS RAM ROM RS232 RSA SCE SCPS SIM SSC TCP/IP TLS TPM TrEE UI UMTS USB

Advanced Micro Devices Application Protocol Data Unit Application Programming Interface Advanced RISC Machine Application Specific Integrated Circuit Bluetooth Certification Authority Chip/Smart Card Interface Device Common Data Security Architecture Cryptographic Application Programming Interface Cryptographic Service Provider Common Security Service Manager Dedicated File Dynamic Root of Trust for Measurement on-chip, non-volatile, one-time programmable memory Elementary File Global System for Mobile Hyper Text Transfer Protocol Integrated Circuit(s) Cards Identity Provider International Electrotechnical Commission InterFace Device (Intel) Virtualization processor architecture International Organization for Standardization Master File Microsoft Mobile Trusted Module Movement for the Use of Smart Cards in Linux Environment Near Field Communication On-board Credential Operating System One Time Password Personal Computers Personal Computer Memory Card International Association Personal Computer / Smart Cards Personal Digital Assistant Personal Identification Number Private Key Cryptography Standards Private Key Infrastructure Post Office Protocol Point Of Sale Random Access Memory Read Only memory Recommended Standard 232 Rivest, Shamir and Adleman Smart Card Engine Smart Card Provisioning Server Subscriber Identity Module Software Smart Card Transmission Control Protocol / Internet Protocol Transport Layer Security Trusted Platform Module Trusted Execution Environment User Interface Universal Mobile Telecommunications System Universal Serial Bus

TruWalletM: Secure Web Authentication on Mobile Platforms Sven Bugiel1 , Alexandra Dmitrienko2, , Kari Kostiainen3 , Ahmad-Reza Sadeghi1 , and Marcel Winandy2 1

Fraunhofer-Institut SIT Darmstadt, Technische Universit¨ at Darmstadt, Germany {sven.bugiel,ahmad.sadeghi}@cased.de 2 System Security Lab, Ruhr-University Bochum, Germany {alexandra.dmitrienko,marcel.winandy}@trust.rub.de 3 Nokia Research Center, Helsinki, Finland {kari.ti.kostiainen}@nokia.com

Abstract. Mobile phones are increasingly used as general purpose computing devices with permanent Internet connection. This imposes several threats as the phone operating system (OS) is typically derived from desktop counterparts and, hence, inherits the same or similar security shortcomings. In particular, the protection of login credentials when accessing web services becomes crucial under phishing and malware attacks. On the other hand many modern mobile phones provide hardwaresupported security mechanisms currently unused by most phone OSs. In this paper, we show how to use these mechanisms, in particular trusted execution environments, to protect the user’s login credentials. We present the design and implementation proposal (based on Nokia N900 mobile platform) of TruWalletM, a wallet-like password manager and authentication agent towards the protection of login credentials on a mobile phone without the need to trust the whole OS software. We preserve compatibility to existing standard web authentication mechanisms.

1

Introduction

Today’s smartphones offer compelling computing and storage capacity allowing the realization of various applications such as web browsing, e-mailing, multimedia entertainment, location tracking, and electronic purchase. The mobile web browser on the phone enables users to access standard Internet web sites, including those that require an authentication of the user (typically username/ password). However, the popularity of mobile phones and the vast number of supported applications makes these platforms also more attractive to attackers. While smartphones are very flexible computing devices, they generally do not provide sufficient security to protect user credentials. As their operating systems 

Supported by the Erasmus Mundus External Co-operation Window Programme of the European Union.

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 219–236, 2011. c Springer-Verlag Berlin Heidelberg 2011 

220

S. Bugiel et al.

are derived from desktop counterparts, they are vulnerable to malware, phishing and physical attacks. While wallet-like authentication agents [1,2,3,4,5] exist that automatically manage mutual authentication between the user’s computing device and a remote web server, they have been demonstrated for PCs only, where resource constraints are not vital. Due to the resource constraints of mobile devices, the development of such secure systems is more challenging than for PCs, in particular to provide a secure (graphical) user interface – although promising research prototypes have been demonstrated recently [6]. Currently, the only solutions available for mobile phones to secure user credentials are password managers, which are essentially simple password databases. They encrypt all passwords with a master password but do not offer sophisticated protection against malware or classical phishing attacks. On the other hand, many modern mobile phones are already equipped with a hardware-supported secure trusted execution environment (TrEE) which allows the secure and isolated execution of certain code, and which can also protect certain amount of data persistently. However, usually the size of the code and data that can be processed in a TrEE is very small, thus wallet-like architectures developed for PCs are not directly suitable. If the authentication protocols are changed and public key-based credentials are used, the TrEE can be used to provide a secure on-board credentials platform (ObC) [7]. However, an ObCbased authentication is not compatible with existing web-based authentication on most servers. Thus, the challenge we have to face is to provide a reliable and secure protection of login credentials on a mobile phone that can take advantage of hardwaresupported security mechanisms while using the standard OS on the phone, and while being compliant to standard web authentication schemes. Contribution. In this paper, we present T ruW alletM , a hardware-assisted wallet-based web authentication as a mechanism to protect user credentials from malware, phishing and physical attacks on mobile platforms. We present the design and implementation proposal of our solution, which also meets important usage requirements: (i) compatibility with existing password-based web authentication, (ii) software reuse of legacy OS and legacy web-browser on smartphones, and (iii) not noticeable performance overhead. To the best of our knowledge, no other solution exists for mobile phones that meets these requirements. Our key design solution, which allows us to meet these requirements, is to split a single SSL/TLS connection between the user device and the server into two logically separated channels, where one is protected by TrEE and is used to transmit passwords, and another one is intended for conventional data. Our design relies on the availability of a Trusted Execution Environment (TrEE) to protect the execution of critical code from tampering. Such TrEEs can be provided by commodity secure hardware for mobile devices such as M-Shield [8] and ARM TrustZone [9].

TruWalletM: Secure Web Authentication on Mobile Platforms

2

221

Model and Requirement Analysis

In this section we consider the model and the security and functional objectives and requirements that are desired. We then discuss in Section 6 which of them can be achieved by our T ruW alletM design and implementation proposal on top of currently available general purpose mobile platforms. System model and use case. Our system model involves the following parties: (i) a user, (ii) a device (mobile platform), (iii) a web server, and (iv) an adversary. We consider application scenarios where a user deploys his mobile device to access services provided by remote web servers (over the Internet). The access is granted through an authentication protocol where the user authenticates using username/password. Adversary model. The main goal of the adversary is to obtain unauthorized access to credentials and the services (provided by the web servers) that usually the user has access to. The threats in this context are: – Software attacks. The adversary may inject malicious software into a device, or exploit the vulnerabilities of the existing application (e.g., web browser). This allows the adversary to access user credentials in device memory, read them out from the login form of the browser when they are inserted by the user during login procedure, eavesdrop on the user input interface (e.g., keyloggers) and communication channel with the web-server, invoke credentials usage or launch phishing attacks1 . – Password-related attacks. The adversary may perform dictionary or bruteforce attack in order to recover passwords, or the adversary may apply the credentials, he has learned from an attacked web-server, to other web-services of the user, as many users tend to reuse credentials for different web-sites. – Physical Attacks. The adversary may obtain physical access to the device (e.g., by stealing the device or accessing it while it is left unattended), invoke the authentication procedure on behalf of the user, or tamper with the underlying hardware. Security objectives. Our security objectives to address these threats are: – Protection of user credentials. User credentials must not be accessible or forged by unauthorized entities (protection of integrity and confidentiality). This requirement ensures that the adversary cannot impersonate the legitimate user. – Trusted path. A secure channel between the user and the web server must be established. This requirement ensures that the user is communicating with a correct web server and that operations are invoked by the legitimate user. 1

Here the adversary attempts to trick users to reveal their credentials to a server under his control, for instance by luring the user to a faked web-site (classical phishing), or by malware displaying forged login pages (malware phishing).

222

S. Bugiel et al.

Functional objectives. In addition to the security aspects, our T ruW alletM design should consider important functional objectives that are essential for practical deployment: – Software Reuse. For many mobile platforms installing an alternative OS is not an available option. Also, the browser should be used as is, as installing a patch originating from a third party developer might not be possible2 . – Interoperability. As the majority of web servers rely on password authentication, our solution supports this method. Other authentication methods, such as OAuth, are complementary to our work and can be easily integrated into our architecture. – Low performance overhead. We require imposed performance overhead to be feasible for mobile devices. We require that users should not notice any delay while they are browsing Internet web pages, but we accept more significant delays for short time periods for performing critical operations such as authentication. Assumptions. We rely on availability of a secure hardware which provides a Trusted Execution Environment (TrEE) with following features: (i) isolated secure code execution, (ii) secure storage, (iii) integrity protection of secure execution environment. Such TrEEs can be provided by general purpose secure hardware such as M-Shield [8] and ARM TrustZone [9]. We assume the TrEE provided by secure hardware is tamper-protected3 . For secure communication between the device and the remote web server we utilize SSL/TLS protocol. We assume that all cryptographic primitives of SSL/TLS protocol are secure. Also, we rely on a trustworthy SSL/TLS Public Key Infrastructure (SSL-PKI) used (implicitly) to authenticate the server during SSL/TLS channel establishment. We do not consider denial-of-service (DoS) attacks, since in the context of our adversary model it is impossible to prevent them. In fact, an attacker who has control over the user environment or even has physical access to the device can always cause DoS, e.g., by switching off the device. We do not consider attacks where an already established server connection is misused by malware (such as transaction generators), but rather concentrate on protection of user credentials. However, our design can be extended with an transaction confirmation agent similar to the solutions in [3,11].

2 3

For instance, the Android security architecture would require the patch to be signed with the same developer signing key as the patching application. It is tamper protected to some degree, e.g., resistant against standard side-channel attacks. However, the severeness of hardware attacks depends on the effort: an example is the recently reported hardware attack on the Trusted Platform Module (TPM) [10].

TruWalletM: Secure Web Authentication on Mobile Platforms

3

223

Architecture and Design Decisions

3.1

Design Decisions

It is a challenging task to design an architecture which fulfills requirements defined in Section 2. For instance the requirement to reuse software (particularly OS) rules out virtualization-based approaches to provide runtime isolation of the critical code operating on user credentials. Instead, our design relies on isolated execution of trusted code within the TrEE. However, currently TrEEs provided by commodity secure hardware are very resource constrained, e.g., M-Shield has about 10-20 Kb memory available in the secure mode. On the other hand, a standard user/password authentication protocol assumes transmission of the password to the server through a SSL/TLS connection. In our design this implies running the code handling SSL/TLS communication within the TrEE in order to (i) protect user credentials and (ii) be compatible with legacy web-servers. However, this is not possible due to size of this code. Thus, one of the main challenges we face is to handle SSL/TLS channels with a web server in a secure way as this cannot be done within the TrEE. We overcome these limitations by letting the trusted and untrusted code cooperate in establishing a secure channel between the user platform and the web server. Handling SSL/TLS connection in collaboration with trusted code running within the TrEE is expensive as it requires multiple switches between normal and secure execution mode4 . On the other hand, high performance overhead contradicts the requirement to keep performance overhead acceptable. To address this problem, we use two separated logical SSL/TLS subchannels over a single SSL/TLS connection to the server: One is partially handled within TrEE and is used for performing security sensitive operations such as login, registration or password change, while another one does not require invocations of the secure side and is used for transmitting conventional data (i.e., the content of web pages). To manage two logical SSL/TLS subchannels, we utilize the standard SSL/TLS resume mechanism, which is intended to reinstate a previously negotiated SSL/TLS session between a client and a server. SSL/TLS resume mechanism is widely supported, according to statistics provided by [12], 91% of web servers support SSL/TLS resume protocol. 3.2

Architecture

Components. The execution environment of a mobile platform is divided into two isolated parts: “open world” and the TrEE. T ruW alletM consists of two main components, WalletHelper (in open world) and WalletCore (in TrEE). The main work is done by WalletHelper (e.g., parsing pages), while WalletCore is only intermittently invoked to perform security-critical operations. “Open world” also contains an operating system (OS), a commodity mobile web browser WebBrowser, a secure storage SecureStorage and a trusted user interface TrustedUI. 4

A single invocation of secure side requires about 1.9 ms for M-Shield TrEE.

224

S. Bugiel et al.

KƉĞƌĂƚŝŶŐ^LJƐƚĞŵ

hƐĞƌ

^^>ŚĂŶŶĞů ĂƚĂ

tĞď ƌŽǁƐĞƌ

>ŽŐŝŶ͕ ƉĂƐƐǁŽƌĚ Ě

dƌƵƐƚĞĚh/ W<

tĂůůĞƚ ,ĞůƉĞƌ

hƐĞƌ/  ^ĞĐƵƌĞ^ƚŽƌĂŐĞ Ő

^^>ŚĂŶŶĞů ĂƚĂ ǁŽƌĚƐ WĂƐƐǁ

ĂƚĂ

tĞď ^ĞƌǀĞƌ tĞď^ĞƌǀĞƌ

tĂůůĞƚŽƌĞ

dƌƵƐƚĞĚdžĞĐƵƚŝŽŶŶǀŝƌŽŶŵĞŶƚ;dƌͿ

DŽďŝůĞWůĂƚĨŽƌŵ

Fig. 1. TruWalletM Architecture

WebBrowser is typically used by the user as a tool to login to remote web servers. SecureStorage is a database where passwords and other security sensitive data are stored persistently and securely. TrustedUI provides trusted user interface between TrEE and the user. The user customizes TrustedUI by adding a unique phrase or a background picture such that he can distinguish TrustedUI from interfaces forged by malware [13,14]. User-specific interface elements are stored within the secure storage and are accessible only by the TrustedUI component. WalletHelper and WebBrowser are untrusted to handle user credentials, also the OS may run arbitrary software including malware. In contrast, TrustedUI is (partly) trusted, although it is an OS-side component. Ideally, TrustedUI should reside within the TrEE. However, the constraint resources of contemporary trusted execution environments, e.g., 20 kB of secure RAM for M-Shield, prohibit such an implementation at the present time. Thus, in our current architecture TrustedUI is realized as an OS component5 . However, future generations of the TrEE may provide the required capabilities to implement a fully trusted path between the user and the TrEE, because hardware vendors continue to extend their TrEE’s capabilities6 . For now, trust into the OS components can be provided by ensuring the component’s integrity by means of secure boot. 7 – a mechanism currently supported by TrEEs. However, secure boot does not protect against runtime attacks, thus trust to this component is limited. In Section 6 we will discuss security implications of runtime compromise. WalletHelper acts as an SSL/TLS proxy and maintains two SSL/TLS connections, one to a web server WebServer and another one to WebBrowser. SSL/TLS connection to WebBrowser is a regular one and is not protected by additional measures. In contrast, SSL/TLS connection with WebServer is established in 5

6 7

Although the availability of such an interface would greatly enhance the security of our architecture, the problem of implementing a TrEE-based (G)UI is orthogonal to the work in this paper. For example, the next-generation M-Shield increases the size of secure RAM to 40-60 kB. The boot process is terminated in case the integrity of a component to be loaded could not be verified (e.g., it does not match to a securely stored reference value) [15].

TruWalletM: Secure Web Authentication on Mobile Platforms

225

cooperation with WalletCore and consist of two logical subchannels. WalletCore protects the shared secret with WebServer and controls switching of subchannels. When login, registration or password change protocols are initiated, the logical channel is switched to WalletCore. Before passwords are used, WalletCore ensures they belong to the appropriate web server. When the protocols have been accomplished, the logical channel is switched back to WalletHelper. In this way regular communication does not require invocation of WalletCore and, thus, does not impose additional overhead. To prevent unauthorized credential usage by other users, the wallet requires user authentication (e.g., a user password) to login into the wallet. The authentication is done through TrustedUI. In this way, passwords stored by the wallet are bound to the corresponding user.

4

Use Cases and Protocols

In this section we describe the following use case scenarios: establishing SSL/TLS connection and managing two logical SSL/TLS subchannels, initialization, registration, login and password change. We also provide corresponding protocols. 4.1

Establishing SSL/TLS Connection and Managing Two Logical SSL/TLS Subchannels

Figure 2 illustrates the SSL handshake protocol. The client and server exchange ClientHello and ServerHello messages and negotiate the required system parameters. In the following steps the server’s certificate CertS is sent and verified, the SSL/TLS session key Sc is generated (which is never disclosed to WalletHelper) and sealed8 (together with pre-master secret P M S and the hash value hash(CertS )). The resulting session-token STc is stored in a secure storage and can be loaded and unsealed later using the session identifier SID. ChangeCipher messages exchanged by WalletHelper and WebServer indicate they are ready to switch to the newly-negotiated parameters and the secret key. All following messages should be encrypted using Sc . All messages which are exchanged between WalletHelper and WebServer are standard messages of SSL/TLS handshake and can be found in the corresponding specification [16]. Managing two logical SSL/TLS subchannels. To split a single SSL/TLS channel into two logical parts, we utilize the SSL/TLS resume protocol, which allows the re-negotiation of an SSL/TLS session key from the previously negotiated SSL/TLS parameters. For switching the channel to WalletHelper, the SSL/TLS channel is resumed and WalletCore discloses the renegotiated SSL/TLS session key to WalletHelper. Disclosing a new session key preserves backward secrecy, as untrusted WalletHelper cannot decrypt data transmitted previously by 8

Sealing means protecting an object so that only a certain set of entities can access or use it.

226

S. Bugiel et al.

Mobile Pl tf Platform

Wallet C Core

VerifyCertS PMSіGenRndNm() y( ) Scc іDeriveSessionKey(PMS) STc =Seal(hash(CertS)||Sc||PMS) StoreToken(STc,SID) PMSencіEnc(PKS,PMS) STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) ClientFinishedіgetFinished(Sc)

Wallet Helper H l

Web SServer

1.Client/ServerHello 2.CertS/ServerDone

3.SID,CertS 4.PMSenc

5.PMSenc

7.SID,getFinished

Legend SID=SSLsessionID Sc=SSLsessionkey(not knownbymWalletHelper) CertS =SSLservercertificate (SKS,PKS)=serverkeypair PMS = Pre master secret PMS=PreͲmastersecret STc =SSLsessiontoken

PMSіDec(SKS,PMSenc) ScіDeriveSessionKey(PMS)

6.ChangeCipher

8.ClientFinished 9.Client/ServerFinished

Fig. 2. SSL/TLS handshake

Mobile Platform

Wallet Core

Wallet Helper

Web Server 1.ClientHello 2.ServerHello

STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) ShіDeriveSessionKey(PMS) STh =Seal(hash(CertS)||PMS) StoreToken(STh,SID)

3.SID,getResumed 4.Sh

Legend SID=SSLsessionID Sc =SSLsessionkey(not k knownbymWalletHelper) b W ll H l ) Sh=SSLsessionkey(known bymWalletHelper) STc =oldSSLsessiontoken STh =newSSLsessiontoken PMS=PreͲMasterSecret

5.ChangeCipher 6.Client/ServerFinished

ShіDeriveSessionKey(PMS)

Fig. 3. Resume SSL/TLS connection and switch logical channel to WalletHelper

WalletCore. The logical channel between WalletHelper and WebServer is switched back to WalletCore by resuming the current SSL/TLS connection and deriving a new session key unknown by WalletHelper. We depict the protocol of switching logical channel to WalletHelper in Figure 3, and illustrate the complementary protocol for switching the logical channel back to WalletCore in Figure 4. In both diagrams, all protocol messages between WalletHelper and WebServer follow the flow of the SSL resume protocol, as specified in [16]. In the secure side, in both cases WalletCore obtains pre-master secret P M S from an SSL session token and derives a new session key. Note, that the session key Sc is included in the token STc , as it is used by WalletCore. In contrast, the session key Sh is not included to session token STh , because it is disclosed to WalletHelper and should never be used by WalletCore. Login/registration/password page forms can be delivered either via http (e.g., Facebook), or via already established SSL/TLS connection (e.g., Google). In the former case, SSL/TLS connection is established when the user presses, e.g., the login or register button. To handle this case, T ruW alletM establishes the SSL/TLS connection and uses the first negotiated session key for authentication,

TruWalletM: Secure Web Authentication on Mobile Platforms

Mobile Platform

Wallet Core

SThіLoadToken(SID) hash(CertS)||PMSіUnseal(STh) ScіDeriveSessionKey(PMS) STc =Seal(hash(CertS)||Sc||PMS) StoreToken(STc,SID)

Wallet Helper

Web Server 1.ClientHello 2.ServerHello

3.SID,getResumed 4.ChangeCipher

227

Legend PMS=PreͲMasterSecret SID=SSLsessionID Sc=SSLsessionkey(not SSL i k ( knownbymWalletHelper) STh =oldSSLsessiontoken STc =newSSLsessiontoken

ScіDeriveSessionKey(PMS)

5.SID,getFinished STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) ClientFinishedіgetFinished(Sc)

6.ClientFinished

6.Client/ServerFinished /

Fig. 4. Resume SSL/TLS connection and switch logical channel to WalletCore

i.e., the logical SSL/TLS channel is directly established between the WalletCore and WebServer. In the latter case, T ruW alletM discloses the session key immediately after SSL/TLS session is established such that the user can surf web-pages delivered via SSL/TLS connection, i.e., the logical channel is established between the WalletHelper and WebServer. However, when a user’s credentials have to be sent to WebServer, e.g., after the login button is pressed, the current SSL/TLS session is resumed in order to switch to the logical SSL/TLS channel between WalletCore and WebServer for a secure transmission of the credentials. 4.2

TruWalletM Initialization

When T ruW alletM is installed on a mobile platform, a few initialization steps are required: (1) the web browser is configured to work with T ruW alletM as SSL/TLS proxy, (2) the user should customize the trusted user interface by adding user-specific interface elements such as a background picture, and (3) the user may want to install passwords for web servers he has already signed up with. Passwords for existing web accounts are added to T ruW alletM by visiting the login page of a web server and pressing the login button. This triggers T ruW alletM to search for a password in its database and subsequently to prompt the user with a dialog requesting to specify the missing login and password. We require the user to first visit the login page, instead of directly entering login/password into T ruW alletM , in order to bind the user password to the server certificate. However, we want to avoid a man-in-the-middle attack during the initialization, e.g., a malicious program that replaces the server certificate by a valid certificate of a different site. Therefore, we follow the approach of [17] and display a list of few destinations (among them the userrequested one) and ask the user to explicitly choose the destination again. As shown in [17] this prevents the user from associating the right credentials to the wrong site.

228

S. Bugiel et al.

Mobile Platform

Trusted UI

Wallet Core

2.lgnRequest Promptuserforlgn

Wallet Helper

1.SID,parsPg

Web Server

parsPg і parse(reqPg)

3.lgn

STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) pwdіGenRnd() PTіSeal(pwd||hash(CertS)) StorePwd(lgn hash(CertS),PT) StorePwd(lgn,hash(Cert ) PT) regPgіInsert(parsPg,lgn,pwd) regPgencіEnc(Sc,regPg) STcіLoadToken(SID) h h(C tS)||Sc||PMSіUnseal(ST hash(Cert ||PMSіU l(STc) ackіDec(Sc,ackenc)

4.regPgenc

Legend SID=SSLsessionID Sc=SSLsessionkey(not y p ) knownbymWalletHelper) CertS =SSLservercertificate regPg=registrationpage reqPg=reg.requestpage parsPg=parsedreg.req.page lgn = login; pwd = password lgn=login;pwd=password STc =SSLsessiontoken PT=passwordtoken PMS=preͲmastersecret

5.reqPgenc 6.ackenc 7.SID,ackenc

regPg і Dec(Sc,regPgenc) Storelgn,pwd ackenc і Enc(Sc,ack)

8.ack

Fig. 5. Registration of a new account

Alternatively, existing accounts can be installed via out-of-band (OOB) channel, e.g., by means of secure provisioning [7]. This protocol can securely deploy credentials, so that they are only known to the provisioning entity and programs executing in the TrEE of the target device. This protocol makes use of a device-specific key-pair (typically available on mobile platforms with TrEE) whose private part resides only in and never leaves the TrEE. Also, OOB channel can be used not only at initialization phase, but later on as well at any time the user wishes to install new passwords. 4.3

Registration

To sign up for a new account, the user visits a registration page of the corresponding web server and presses the “sign up” button. This action launches the registration protocol (Figure 5). Before the protocol starts we assume a registration request page reqP g is delivered to T ruW alletM either through SSL connection or http. At protocol start, WalletHelper parses reqP g and sends a parsed registration request page parsP g to WalletCore (step 1). WalletCore invokes TrustedUI to obtain user login lgn from the user (steps 2-3), loads the SSL/TLS session token STc from the secure storage and unseals it. Next, it generates a new high entropy password pwd, seals it together with a hash of SSL/TLS certificate CertS (extracted from STc ) and stores the resulting password token P T in a secure storage. After that, it fills in pwd into parsP g and sends it over the established SSL/TLS channel to WebServer (steps 4-5). WebServer validates lgn and pwd and responds with acknowledgment (steps 6-7). Finally, WalletCore passes the decrypted acknowledgment to WalletHelper (step 8).

TruWalletM: Secure Web Authentication on Mobile Platforms

Mobile Platform

Wallet Core

Trusted UI

2.loginRequest Promptuserforlgn

Wallet Helper

1.SID,parsPg

Web Server

parsPgіparse(lgnPg)

3.lgn

STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) PTіLoadPwd(lgn,hash(CertS)) pwd||hash(CertS)’іUnseal(PT) Compare(hash(CertS),hash(CertS)’) authPgіInsert(parsPg,lgn,pwd) authPgencіEnc(Sc,authPg) STcіLoadToken(SID) іLoad Token(SID) hash(CertS)||Sc||PMSіUnseal(STc) ackіDec(Sc,ackenc)

4.authPgenc 5 authPgenc 5.authPg 6.ackenc

229

Legend SID=SSLsessionID Sc=SSLsessionkey(not knownbymWalletHelper) y p ) CertS =SSLservercertificate lgnPg=loginpage parsPg=parsedloginpage authPg=authenticationpage lgn = login pwd = password lgn=login,pwd=password PT=passwordtoken STc =SSLsessiontoken PMS=preͲmastersecret

authPgіDec(Sc,authPgenc) Verifylgn,pwd AckencіEnc(Sc,ack)

7.SID,ackenc 8.ack

Fig. 6. Password authentication to the web server

4.4

Login

The most typical usage scenario for T ruW alletM is to login to a service provided by a web server. To trigger the login procedure, the user visits a login page. The login page is delivered to WalletHelper either via http connection or via SSL/TLS channel established between WalletHelper and WebServer. Next, the protocol proceeds as depicted in Figure 6. WalletHelper parses a login page lgnP g and sends it parsed, i.e., in a specially prepared format, to WalletCore together with the identifier of the SSL/TLS session, SID (step 1). WalletCore invokes TrustedUI to obtain a login name lgn from the user (steps 2-3). Next, WalletCore loads and unseals session token STc , loads password token associated with lgn and the particular web server. Also, WalletCore compares the hashes of the certificates obtained from STc and P T to verify the binding of the password to WebServer. If positive, lgn and pwd are inserted into the parsed login page parsP g, and the resulting authP g is sent to WebServer encrypted under the SSL/TLS session key ((steps 4-5). WebServer verifies whether the submitted lgn and pwd belong to an authorized user, and replies with acknowledgment on successful verification (steps 6-7). Finally, WalletCore relays the decrypted acknowledgment to WalletHelper (step 8). Note, if the user is not yet registered at this site, T ruW alletM will proceed as explained in Section 4.2. 4.5

Password Change

The last usage scenario we consider is a password change. To change the password, the user visits the password change web-page of the corresponding web server. The page is delivered to T ruW alletM either via http connection or via the SSL/TLS channel established between WalletHelper and WebServer.

230

S. Bugiel et al.

Mobile Platform

Trusted UI

Wallet Core

2.loginRequest Promptuserforlogin

Wallet Helper

1 SID parsPg 1.SID,parsPg

Web Server

parsPgіparse(chgPg)

3.lgn

STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) PTіLoadPwd(lgn,hash(CertS)) pwd1||hash(CertS)’іUnseal(PT) Compare(hash(CertS),hash(CertS)’) pwd2 і GenRnd() pwdPgіInsert(parsPg,lgn,pwd1,pwd2) pwdPgencі Enc(Sc,pwdPg) PTіSeal(pwd2||hash(CertS)) StorePwd(lgn,hash(CertS),PT) STcіLoadToken(SID) hash(CertS)||Sc||PMSіUnseal(STc) ackі Dec(Sc,ackenc)

Legend SID=SSLsessionID Sc=SSLsessionkey(not knownbymWalletHelper) CertS =SSLservercertificate chgPg=pwdchangepage parsPg=parsedchgPg pwdPg=passwordpage PT=passwordtoken STc =SSLsessiontoken = SSL session token lgn=login pwd1 =oldpassword pwd2 =newpassword PMS=preͲmastersecret

4.pwdPgenc 5.pwdPgenc 6.ackenc 7.SID,ackenc

pwdPg і Dec(Sc,pwdPgenc) Verifylgn,pwd1 Storepwd p 2 ackenc і Enc(Sc,ack)

8.ack

Fig. 7. Password change

Password change protocol is shown in Figure 7. WalletCore gets the parsed password change page parsP g and the identifier of the SSL/TLS session, SID, from WalletHelper and a user login lgn from TrustedUI (steps 1-3). Next, it loads and unseals an SSL session token STc and a password token P T . When a password pwd1 is extracted from P T , its binding to WebServer is verified by comparing the hashes of the certificates obtained from P T and STc . If positive, WalletCore generates a new password pwd2 and fills in lgn, pwd1 and pwd2 into the parsed password change page parsP g. Next, this page is sent to WebServer via the established SSL/TLS channel (steps 4-5). WebServer verifies whether pwd1 corresponds to the authorized user, replaces the old password with a new one, and acknowledges upon success (steps 6-7). Finally, the decrypted acknowledgment is passed to WalletHelper (step 8).

5

Implementation

The implementation of T ruW alletM is a work in progress. Currently, it is implemented as a user space component, but it is being ported to run in the TrEE of a Nokia N900 smartphone, running Maemo OS [18]. The Nokia N900 emulates the M-Shield secure hardware. By default, M-Shield is not available to third party developers. However, the On-board Credentials platform (ObC) [7] provides the means to leverage the TrEE. Thus, in our implementation, we build the WalletCore on top of ObC. A detailed description of the ObC architecture can be found in [7]. In a nutshell, it provides a bytecode interpreter residing in the TrEE, which can execute lightweight bytecode, compiled from scripts written in assembly code. Moreover, the interpreter provides an interface for commonly used cryptographic primitives.

TruWalletM: Secure Web Authentication on Mobile Platforms

231

Furthermore, the provisioning subsystem of ObC enables in our implementation the out-of-band provisioning of users’ passwords. The sealing functionality provided by the interpreter is used to implement SecureStorage. When sealed, data is encrypted under a key that is never available outside the TrEE. Further, this key is cryptographically bound to scripts, thus isolating the SecureStorage from other, unauthorized (and potentially malicious) scripts. WalletHelper is implemented as two subcomponents. The first is written in the C programming language and implements the communication with the WalletCore, the interaction with the user, and the parsing of the received login pages. The second component implements the SSL/TLS proxy functionality and is based on the open-source SSL/TLS Java proxy Paros [19]. The WalletCore functionality is currently implemented as part of the first subcomponent of WalletHelper, but will be ported to a set of ObC assembly scripts, which will be invoked by WalletHelper when needed. The TrustedUI component is currently implemented as part of the OS, because the constraint resources of contemporary TrEEs prohibit a full user interface implementation in the secure execution environment. We have tested our current T ruW alletM prototype with several public websites, such as web e-mail services, eBay, or Amazon. Registration, login, and password change work transparently and without noticeable performance overhead for the user, despite the running SSL/TLS proxy. The performance tests have been implemented based on the open-source wget 9 tool, which was used to login via SSL/TLS to the websites mail.rub.de and checkyourbets.com utilizing T ruW alletM . The test was performed 10 times. The induced performance penalty for the first website averaged 0.4s and increased the required login time from 1.3s to 1.7s. The performance penalty for the second website was 0.2s and increased the login time from 1.5s to 1.7s. The memory consumption during these tests is acceptable with approximately 60 kB resident RAM, including Paros. Regarding the performance of our architecture, we do not expect a significant overhead when WalletCore is implemented on top of ObC instead of as a user space process. The performance of bytecode executing on the ObC interpreter is slightly slower compared to native code. This is due to the performance penalty of bytecode interpretation and additional switches from the insecure side to the ObC interpreter on TrEE side. According to our experiments with other similar ObC scripts we can estimate that execution of WalletCore would take 10-20 ms. This cost is negligible compared to the execution time required for the necessary operations during an TLS/SSL connection, e.g., cryptographic operations. Moreover, the invocations of WalletCore will be limited to the steps required to ensure the secrecy of the user’s credentials and to the initial steps of the TLS/SSL connection. By providing the session keys for the remaining parts of the TLS/SSL connection to the WalletHelper, the bulk of the operations during the connection will be performed in the insecure environment and do not add any further overhead. Thus, the performance overhead imposed by migrating the WalletCore on top of ObC will be minimal. 9

http://www.gnu.org/software/wget/

232

S. Bugiel et al.

Based on our experience in implementation of other ObC scripts, we envision following challenges in porting WalletCore as ObC script: First, implementing fully flexible X.509 certificate parsing and verification under the constraints of limited TrEE resources has turned out to be challenging. Second, in many cases verification of a single certificate is not enough, but rather full certificate chain verification is needed. Since existing TrEEs on mobile devices are constrained in resources, full certificate chains cannot be verified in one go, but rather chaining of subsequent ObC script executions is needed. The ObC Interpreter provides support for such statefulness. Third, flexible certificate verification implies that multiple trust roots (e.g. hashes of CA public keys) are fixed to the WalletCore script implementation. This increases the size and complexity of the WalletCore script implementation.

6

Security Considerations

Protection of user credentials. The user credentials are protected by the following means: (i) run-time isolation. All operations on user credentials (except user input) are performed within the TrEE. As the TrEE is isolated from the rest of the system in terms of processing and memory, that guarantees protection of the user’s credentials at run-time from potentially malicious OS and other OS-side components. (ii) secure storage. Sealing with a key that is protected by the TrEE and bound to authorized scripts provides secure storage of persistently stored credentials outside the TrEE. When sealed, credentials cannot be unsealed by malware or an adversary performing physical attacks; (iii) strong passwords. T ruW alletM generates high-entropy passwords which are unique for each account to prevent dictionary, brute-force and reuse credential attacks; (iv) blind passwords. Classical and malware phishing attacks are prevented because the passwords are unknown to the user. T ruW alletM either creates the passwords within the TrEE and does not reveal them to the user (as proposed in [20]), or, when entered by the user, requests the user to initiate a password change (i.e., to visit a password change page of the associated web server); (v) tamperresistant TrEE. As discussed in Section 2 (assumptions), we assume that TrEE is tamper-resistant against standard physical attacks aiming to access the security sensitive information within TrEE. Trusted path. The trusted path between the user and the web server is composed of two parts: (i) between the TrEE and the web server, and (ii) between the user and the TrEE. The first part is provided by the SSL/TLS channel: Passwords are transmitted to the server through an SSL/TLS protected connection, this prevents the adversary from eavesdropping on the communication channel with the web-server. The web-server and the TrEE are mutually authenticated, that prevents manin-the-middle and phishing attacks. The TrEE authenticates the web-server by validating the SSL/TLS certificate, and the server authenticates the TrEE by means of the password authentication protocol. This part of the trusted path is

TruWalletM: Secure Web Authentication on Mobile Platforms

233

secure, because the server certificate is verified within TrEE and credentials associated with the SSL/TLS channel (such as a pre-master secret key and a session key) are protected by the TrEE. Also, passwords used during the authentication protocol are available only within the TrEE. The second part of trusted path is provided by means of the trusted user interface TrustedUI. TrEE authenticates the user by means of user login upon the start of T ruW alletM , while the user authenticates TrEE by recognizing a customized interface element, e.g., a unique phrase or background image. This customized element is securely stored in the secure storage and is accessible only by the TrustedUI component. We rely on a customizable user interface since some studies show positive results of such an approach [14], however, this is an issue that requires extensive usability tests since other studies say users tend to ignore security hints [21]. To protect user credentials from malware such as keyloggers, malicious webbrowser and phishing programs, the user enters his passwords only via the trusted user interface. However, as in current implementation TrustedUI is realized as OS-side component, we can only guarantee its integrity at system (re)boot (by means of secure boot). Thus, the user can enter his passwords securely via TrustedUI only immediately after system reboot, but later on security guaranties do not hold anymore as TrustedUI is susceptible to runtime compromise. Discussion on runtime compromise of TrustedUI. In general, a compromised TrustedUI does not provide secure user input from the user to the TrEE, e.g., during the initialization of T ruW alletM the entered password can be disclosed by a compromised TrustedUI. Another issue relates to the registration protocol. As it is initiated by an untrusted component, WalletHelper, it can omit the invocation of WalletCore or substitute the server certificate with another valid one for a malicious website, while the compromised TrustedUI indicates a successful and secure execution of the protocol. The out-of-band provisioning of credentials (as was discussed in Section 4.2) can mitigate these issues in certain cases like the initialization. However, to provide a fully trusted path, either runtime integrity monitoring mechanisms or a TrEE-based user interface are required, which are both currently infeasible for mobile devices. The former either requires extra hardware support (e.g., [22]) or utilizes virtualization technology (e.g., [23]) which is hardly affordable for mobile devices due to the induced overhead and also contradicts to our requirement on software reuse. The latter is infeasible due to the very limited resources of contemporary TrEE.

7

Related Work

As mentioned earlier, on desktop PCs there exist wallet-like authentication agents [1,2,3,4,5] that automatically manage mutual authentication between the user and a web server. To prevent malware from disclosing the credentials based on run-time attacks against the wallet, the wallet is generally executed in an environment that isolates it from the rest of the software stack that is responsible for

234

S. Bugiel et al.

web browsing. This is similar to the TrEE we use in our design here, however, on the PC-based wallets, the isolated execution is achieved by running the trusted and untrusted parts in different virtual machines that are controlled by a trusted virtual machine monitor. For instance, TruWallet [1] uses a virtualization-based security kernel for isolation and a Trusted Platform Module (TPM) [24] to bind the credential data to the wallet. In contrast, Delegate [4] is a web proxy running on a physically different machine and not on the same device the user runs the browser. Besides the protection of the login credentials, SpyBlock [3,11] also protects against malicious software that misuses authenticated sessions to issue illegitimate transactions (so called transaction generators). The trusted authentication agent is therefore extended with a transaction confirmation component. But this design can be applied to all wallet-like solutions, and, thus, to our T ruW alletM as well. To overcome with some of the problems of username/password authentication, alternative authentication protocols have been proposed. For instance, the PAKE protocol for password-assisted key exchange may be used, e.g., [25,26,27]. PAKE protocols can be used for mutual authentication, i.e., it is not necessary to transmit username and password over the SSL/TLS channel during login. The simple remote password (SRP) protocol [27] can be used as well. RFC5054 [28] specifies the use of SRP for SSL/TLS authentication. However, these protocols have the drawback that (i) their security-sensitive operations are not appropriately isolated when used on standard operating systems, and (ii) they are not compatible to legacy web server as they require to change the server logic. Another alternative is to use challenge-response protocols to verify knowledge of a shared secret between client and server, e.g., as used in TruWallet [1]. However, this again requires to change the authentication verification method at the server, which was one aspect we wanted to avoid in our design.

8

Conclusion and Future Work

In this paper, we present a secure wallet-based system and protocols for protecting user credentials on mobile devices used to access Internet services. Our solution does not rely on a secure operating system, but exploits hardware security features, in particular Trusted Execution Environment (TrEE) available on many modern mobile phones. It is fully compatible with legacy software (e.g., standard browsers and standard OSes) and standard web authentication methods (here password-based authentication and SSL). It does not impose noticeable performance overhead during transfer of conventional data, but slightly slows down communication when transferring user passwords (e.g., during login/registration/password change). We propose a prototype implementation on a Nokia N900 device with M-Shield technology. Our design assumes the availability of a trusted user interface. Currently this interface is implemented as part of the OS, because the constraint resources of contemporary TrEEs prohibit a full user interface implementation in the secure execution environment. The security issues imposed by this design decision, especially a run-time compromise of the interface leading to credential misuse or

TruWalletM: Secure Web Authentication on Mobile Platforms

235

potential disclosure, have been pointed out. However, recognizing the trend of device manufacturers to further extend their devices’ TrEE capabilities, we argue that our proposed architecture is fundamentally a step into the right direction towards hardware secured user credentials on mobile end-user devices. The challenge of implementing a TrEE-based GUI (and generic I/O inside the TrEE) is orthogonal to the work presented in this paper. Our further ongoing work concerns the design and development of a confirmation channel and migration protocols. The former assures a user that a certain transaction has been correctly performed while the latter allows the user to securely transfer his credentials from a mobile platform to another platform. This protocol is required to enable users to login from different platforms, because in our solution users do not know their actual (high-entropy) passwords (this is to avoid phishing attacks).

References 1. Gajek, S., L¨ ohr, H., Sadeghi, A.R., Winandy, M.: TruWallet: trustworthy and migratable wallet-based web authentication. In: STC 2009: Proceedings of the 2009 ACM Workshop on Scalable Trusted Computing, pp. 19–28. ACM, New York (2009) 2. Gajek, S., Sadeghi, A.R., St¨ uble, C., Winandy, M.: Compartmented security for browsers – or how to thwart a phisher with trusted computing. In: 2nd International Conference on Availability, Reliability and Security (ARES 2007), pp. 120–127. IEEE Computer Society, Los Alamitos (2007) 3. Jackson, C., Boneh, D., Mitchell, J.: Spyware resistant web authentication using virtual machines (2006), http://www.crypto.stanford.edu/spyblock/ 4. Jammalamadaka, R.C., van der Horst, T.W., Mehrotra, S., Seamons, K.E., Venkasubramanian, N.: Delegate: A proxy based architecture for secure website access from an untrusted machine. In: 22nd Annual Computer Security Applications Conference (ACSAC 2006), pp. 57–66. IEEE Computer Society, Los Alamitos (2006) 5. Kwan, P.C.S., Durfee, G.: Practical uses of virtual machines for protection of sensitive user data. In: Dawson, E., Wong, D.S. (eds.) ISPEC 2007. LNCS, vol. 4464, pp. 145–161. Springer, Heidelberg (2007) 6. Selhorst, M., St¨ uble, C., Feldmann, F., Gnaida, U.: Towards a trusted mobile desktop. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 78–94. Springer, Heidelberg (2010) 7. Kostiainen, K., Ekberg, J.E., Asokan, N., Rantala, A.: On-board credentials with open provisioning. In: Proc. of the 4th ACM Symposium on Information, Computer, and Communications Security (ASIACCS 2009). ACM, New York (2009) 8. Azema, J., Fayad, G.: M-Shield mobile security technology: making wireless secure. Texas Instruments White Paper (2008), http://focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf 9. Alves, T., Felton, D.: TrustZone: Integrated hardware and software security. Information Quaterly 3 (2004) 10. Heise Security: Hacker extracts crypto key from TPM chip (2010), http://www.h-online.com/security/news/item/ Hacker-extracts-crypto-key-from-TPM-chip-927077.html 11. Jackson, C., Boneh, D., Mitchell, J.: Transaction generators: Root kits for web. In: 2nd USENIX Workshop on Hot Topics in Security (HotSec 2007), pp. 1–4. USENIX Association (2007)

236

S. Bugiel et al.

12. Ristic, I.: Internet SSL server survey. In: BlackHat, USA (2010) 13. Dhamija, R., Tygar, J.D.: The battle against phishing: Dynamic security skins. In: SOUPS 2005: Proceedings of the 2005 Symposium on Usable Privacy and Security, pp. 77–88. ACM, New York (2005) 14. Bank of America: Identity Theft Fraud Protection from Bank of America (2010), http://www.bankofamerica.com/privacy/sitekey 15. Itoi, N., Arbaugh, W.A., Pollack, S.J., Reeves, D.M.: Personal secure booting. In: Varadharajan, V., Mu, Y. (eds.) ACISP 2001. LNCS, vol. 2119, pp. 130–144. Springer, Heidelberg (2001) 16. Network Working Group: The transport layer security (TLS) protocol. version 1.2. Standards track (2008), http://tools.ietf.org/html/rfc5246 17. Wu, M., Miller, R.C., Little, G.: Web Wallet: Preventing Phishing Attacks by Revealing User Intentions. In: 2nd Symposium on Usable Privacy and Security (SOUPS 2006), pp. 102–113. ACM, New York (2006) 18. Maemo: Project website (2010), http://maemo.org 19. Paros: Project website (2010), http://www.parosproxy.org 20. Gajek, S., Sadeghi, A.R., Stuble, C., Winandy, M.: Compartmented security for browsers - or how to thwart a phisher with trusted computing. In: ARES 2007: Proceedings of the The Second International Conference on Availability, Reliability and Security, pp. 120–127. IEEE Computer Society, Washington, DC, USA (2007) 21. Schechter, S.E., Dhamija, R., Ozment, A., Fischer, I.: The emperor’s new security indicators. In: SP 2007: Proceedings of the 2007 IEEE Symposium on Security and Privacy, pp. 51–65. IEEE Computer Society, Washington, DC, USA (2007) 22. Petroni Jr., N.L., Fraser, T., Molina, J., Arbaugh, W.A.: Copilot - a coprocessorbased kernel runtime integrity monitor. In: Proceedings of the 13th USENIX Security Symposium, USENIX, pp. 179–194 (2004) 23. Baiardi, F., Cilea, D., Sgandurra, D., Ceccarelli, F.: Measuring semantic integrity for remote attestation. In: Chen, L., Mitchell, C.J., Martin, A. (eds.) Trust 2009. LNCS, vol. 5471, pp. 81–100. Springer, Heidelberg (2009) 24. Trusted Computing Group: TPM Main Specification, Version 1.2 rev. 103 (2007) 25. Bellovin, S.M., Merritt, M.: Encrypted key exchange: Password-based protocols secure against dictionary attacks. In: IEEE Symposium on Security and Privacy (S&P 1992), pp. 72–84 (1992) 26. Jablon, D.P.: Strong password-only authenticated key exchange. Computer Communication Review 26, 5–26 (1996) 27. Wu, T.: The secure remote password protocol. In: Network and Distributed System Security Symposium (NDSS 1998), pp. 97–111. The Internet Society, San Diego (1998) 28. Taylor, D., Wu, T., Mavrogiannopoulos, N., Perrin, T.: RFC5054: Using the secure remote password (SRP) protocol for TLS authentication (2007), http://www.ietf.org/rfc/rfc5054

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders in MANETs (Work-in-Progress) Dong Hao1, , Yizhi Ren2, , and Kouichi Sakurai1 1 2

Graduate School of Informatics, Kyushu University, Fukuoka, Japan School of Software Engineering, Hangzhou Dianzi University, China {haodong,ren,sakurai}@itslab.csce.kyushu-u.ac.jp

Abstract. One of the most challenging issues in Mobile Ad-Hoc Network (MANET) is that the insiders are untrustworthy in packet forwarding stage. All the nodes which loss data-packets over a preset threshold can be generalized as Suspicious Insiders. To intimidate these suspicious insiders and reduce packet dropping, surveillance is the most direct and easiest method. In this paper, we propose a novel surveillance mechanism to monitor the packet dropping of suspicious insiders. On one hand, our work provides the monitor with optimal strategies which will maximize its long term utility; On the other hand, our work presents an on-demand monitoring scheme which will balance the tradeoff between security and resource consumption. First, we utilize a reputation scheme to distinguish suspicious insiders from legitimate members, and quantify the threat level of the suspicious insiders. Then taking into consideration security and resource consumption, we utilize game theory to analyze the interaction between monitor and suspicious insider. Finally, optimal mixed-strategy is computed to identify the best way for the monitor to respond to the suspicious insider. Keywords: Suspicious Insider, Game Theory, Surveillance, Reputation.

1

Introduction

1.1

Background and Motivation

Mobile Ad-Hoc Networks (MANETs) are usually distributed, dynamic, and selforganized [1]. Lacking of settled communication infrastructures, the performance of MANETs depends on the cooperation among insider nodes. And the communication between these insider nodes relies on multi-hop and packet-forwarding. Current versions of ad hoc routing protocols, as DSR, AODV, TORA, DSDV,  

The first author is supported by the governmental scholarship from the China Scholarship Council. The second author was also supported by the governmental scholarship from the China Scholarship Council while he studied in Kyushu University.

L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 237–252, 2011. c Springer-Verlag Berlin Heidelberg 2011 

238

D. Hao, Y. Ren, and K. Sakurai

STAR [9] only detect if the destination is accepting data packets, but they otherwise assume all the insiders cooperate in data forwarding stage. However, actually, data packet may be dropped due to various reasons [6]. Packet-dropping [16] has negative impact on the overall performance of the network. Experiment has showed that if 10% − 40% of the nodes in the network drop data packet, then the average throughput degrades by 16% − 32% [3]. To capture the packet-dropping action and punish misbehaving insiders, the most direct and easiest method is to monitor the behavior of the insiders [2,6]. We call this monitoring action surveillance. In many trust systems and secure routing protocols for MANET [1,2,4,5,6], surveillance component is essential to maintain the reputation and history behavior of insiders. However, in these systems and protocols, monitor component is running on every single node at any time, and is always running at a fixed security intensity. This unilevel monitoring scheme has two major problems:(1) Monitoring the legitimate members permanently will unnecessarily consume large amount of energy, which is stringent in MANET. (2) Because different suspicious insiders have different threat level, this fixed security intensity is not flexible and can not perfectly satisfy the continually changing security requirements. 1.2

Related Works

In MANAETs, there exists three kinds of insiders: the malicious, selfish, and legitimate [16]. The goal of a malicious node is to destroy the data transmission [6]; a selfish node will try to preserve its own resources and refuse forwarding others’ packets; and even legitimate nodes are possible to loss packets due to channel congestion, link error and other network problems. Selfish and malicious insiders have been extensively studied in literature, such as reputation systems [1, 2, 4, 5] and intrusion detection systems [7, 10, 16]. However, there is not so much work on how to balance security assurance and resource consumption in the presence of suspicious insiders. Surveillance techniques are often used for the detection of packet dropping from suspicious insiders. The most direct and basic surveillance technique is promiscuous overhearing [6]. Watchdog [3] is a classical surveillance technique working under this promiscuous overhearing mode. CONFIDANT [4],CORE [5], TRP [8], etc..., are protocols which adopt Watchdog as their surveillance components. However, Watchdog has a significant drawback: it is vulnerable of spoofing attacks [6]. X. Xue et.al proposed SWAN(Secured Watchdog for Ad hoc Networks) which combines Authentication technology [6] with Watchdog to enhance the security capability. It is more secure than original Watchdog. However, it is also high resource consuming. Game Theory [15] has recently become prevalent in many engineering applications, notably in wireless network communication. It provides a rich set of mathematical tools and models for multitude of decision making in network security [16]. However, there is not much work on using game theory to analyze the interaction between suspicious insiders and surveillance nodes. And to our best

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

239

knowledge, this is the first work that utilizes game theory to design surveillance mechanism for the suspicious insiders. 1.3

Challenging Issues

In MANETs, the extremely limited resource is the biggest obstacle for establishing a tough surveillance mechanism to intimidate suspicious insiders [6]. Therefore, to design an efficient and economical surveillance mechanism, we should take both security and resource consumption into consideration. The following three items are the challenging issues for designing surveillance mechanism. (1) Distinguish Suspicious and Legitimate. Not like wired network in which members are managed by a central certification authority(CA), MANET insider’s character is hard to identify. How to distinguish suspicious insiders from legitimate members is a problem [10]. Furthermore, even if well distinguished, how to quantify the threat level of suspicious insiders is another problem. (2) Design On-demand and Multilevel Surveillance. On the one hand, legitimate insiders are trustable. They will never intend to misbehave or attack the network. If permanently monitor those legitimate nodes, a large amount of resource will be wasted and the lifetime of the network will be reduced [6,10]. On the other hand, suspicious insiders are various in threat-level. Those nodes which are more likely to drop data-packet should be monitored more intensely. Therefore, a multilevel and on-demand surveillance scheme should be designed. (3) Stimulate the Monitors. The monitors themselves are also rational [15], and not willing to consume their private resource to serve the public security. In this case, even if the monitor is aware of suspicious neighbor’s threat, it may still refuse to run surveillance. How to stimulate these surveillance nodes to monitor suspicious insiders is also a problem. 1.4

Our Contributions

In this paper, we focus on the above challenging issues, and propose a novel surveillance mechanism. The main contributions of our work are as follows: (1) Reputation-Based Threat Analysis. In our mechanism, we establish a reputation based threat analysis method to predict the prospective packet-dropping probability of suspicious insiders. First, we utilize a reputation evaluation component Global Evaluation Record (GER) [1] to classify insiders into suspicious and legitimate. Then by using Bayes’ rule [17], we compute the suspicious insider’s prospective packet-dropping probability which quantitatively reflects its threat level. (2) On-Demand Surveillance Scheme. On the foundation of the threat analysis, we put forward a multi-level and on-demand surveillance scheme. Then we define a mixed strategy game between a suspicious insider and the monitor. By solving this surveillance game, we get the thresholds for a monitor to adjust

240

D. Hao, Y. Ren, and K. Sakurai

its monitoring intensity. Then the monitor is able to adopt Optimal Surveillance Strategies [15]. This kind of strategies will not only reduce resource consumption, but also keep up with the continually changing security requirement. (3) Game-Theoretical Incentive Scheme. To motivate the rational monitors to cooperate, in our work, we set the reward and penalty rules for them. The monitor’s gain/loss are directly relevant to the overall payoff of the current route. The system will reward the cooperating monitors and punish the violating monitors. To maximize its overall utility, the monitor should obey the Nash equilibrium strategy [15]. If not, it will suffer loss. In this way, the incentive-compatible surveillance scheme is realized.

2

Threat Analysis

In this section, we will analyze the threat level of MANET insiders in a quantitative way. Firstly, we introduce a reputation evaluation component Overall Evaluation Record (OER) which is based on node’s historical behavior record. Comparing OER with a preset threshold, we classify MANET nodes into two types. One is legitimate members, the other one is suspicious insiders. After that, by mean of Bayes’ rule [17], the prospective packet-dropping probability of a suspicious insider is calculated. This prospective probability can be used as a threshold for the monitor to adjust its surveillance intensity. 2.1

Reputation Mechanism

Reputation mechanism has been successfully used in many e-business systems. In MANETs, the chief objective of reputation mechanisms is to quantify the historical packet forwarding performance of insiders. However, it can also be applied as a quantification approach to indicate the prospective behavior of insiders. In our scheme, we extract the overall reputation evaluation(OER) component from a reputation mechanism SORI [1], and utilize it as the basic reputation mechanism. We assume every insider N maintains a neighborhood list N . In this list, for each of its neighbor node i, node N keeps two metrics: RFN (i) and HFN (i). Here RFN (i) denotes the number of packets that node N has requested node i to forward, HFN (i) denotes the total number of packets that have been forwarded by i and observed by N . With this two metrics, the local reputation evaluation is recorded as a 3-tuple: RF (i) LERN (i) = {GN (i), CN (i), H(t)}. The first entry GN (i) = HFNN (i) denotes the credibility that node i earned from the perspective of node N ; the second entry CN (i) = RFN (i) denotes the confidence node N has in node i; and H(t) = {a(1), a(2), ..., a(t)} is the historical behavior sequence of node i until a discrete time instant t. Here, a(t) is the behavior that node i takes at time t, which can either be Forwarding(F ) or Dropping(D ). Based on the changes of RFN (X) and HFN (X), node N will periodically update LERN (X). In addition, if GN (X) changes significantly, node N will

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

241

broadcast it to its neighbors. Every neighbor node i will exchange LERi (X) with each other through broadcast. Then the overall evaluation reputation of node X from the perspective of node N can be concluded as:  i∈N ,i=X GN (i) · [Ci (X) · Gi (X)]  OERN (X) = (1) j∈N ,j=X GN (j) · Cj (X) It is assumed that in a route which links the source node S and the destination node D, node N and X are two neighbor insiders, and X is in the downstream of N . With the above overall evaluation reputation(OER), N will evaluate the reputation of X and report it to the source node S by adding it into the RREP [6] message. Consequently, S will be aware of the reputation of all the insiders on its route. 2.2

Misbehavior Prediction

Suspicious insiders are the nodes which have lost data-packets over a preset threshold, either accidentally or intentionally. Given the quantitative reputation OER, and a pre-established reputation threshold η, the insiders can be classified into two types: Legitimate and Suspicious. Definition 1. Let τ ∈ T denote the type of an insider, and T = {l, s} where l and s denote legitimate type and suspicious type, respectively. Given η as the threshold of reputation OER, for any insider X and its upstream neighbor N , if OERN (X) < η, node X will be considered as suspicious from N ’s perspective. Otherwise, node X can be seen as legitimate. If X is considered as suspicious, S will entrust N to monitor it. It is worth noting that, being suspicious does not necessarily mean the node X will drop every single packet it has received. As a rational malicious node intends to gain reputation and do not want to be isolated from the network, it will drop packets selectively. The objective of node N is to intimidate insider X, as well as to preserve its own resource as much as possible. Thus node must make a decision about which monitoring level it should adopt. For this purpose, N will quantify the threat level of X and predict its prospective packet-dropping probability. By using Bayes’ theorem, node N is able to compute node X’s prospective packetdropping probability at time t + 1: γt+1 (D |s ) =

Pt (D) · Pt ( s| D) Pt (D) · Pt ( s| D) + Pt (F ) · Pt ( s| F )

(2)

In this equation, γt+1 is the prospective packet-dropping probability of the suspicious node X ant time t + 1. s denotes suspicious type. D and F denote the action Drop and Forward, respectively. Pt (D) and Pt (F ) are the overall packet dropping probability and overall packet forwarding probability of node X, respectively. Based on the illustration of HFN (X) and RFN (X), we can let  Pt (F ) =

 N ∈N N ∈N

HFN (X) RFN (X) ,

and Pt (D) = 1 − Pt (F ). Furthermore Pt ( s| D) can be

242

D. Hao, Y. Ren, and K. Sakurai

considered as the ratio of the number of suspicious neighbors that have dropped packets to the total number of neighbors that have dropped packets. In this equation, the bottom part equals Pt (s), which is the probability for X being N (X) suspicious at time t. In the current scheme, we let Pt (s) = 1−OER . 1−η With this formula, based on the history behavior record of the suspicious insider X, the monitor N is able to predict its posterior packet-dropping probability at next time instant. This posterior probability γt+1 will be used for the prospective surveillance strategy choice, which we will discuss in the next section.

3

Surveillance Game

In this section, we use game theory to analyze the interaction between the monitor and the suspicious insider. We first introduce three surveillance levels: TRUST, Watchdog, and SWAN. Then we introduce the reward and punishment rules. After that, considering security requirement and resource consumption, we construct a mixed strategy game within monitor and suspicious insider. By computing the Nash Equilibrium [15] of this game, we obtain the thresholds for launching high-level surveillance and low-level surveillance, respectively. Then, comparing these two thresholds with the prospective packet dropping probability which is proposed in Section 2, the monitor is able to choose an optimal surveillance level which will maximize its long-term overall utility. Through such game solutions, the network reaches to a balance between resource consumption and security assurance. This is so called on-demand and multilevel surveillance. Our on-demand multilevel surveillance scheme is resource preserving and also strictly coincided with the constantly changing security requirement. 3.1

Multilevel Surveillance

We assume every node in the MANET is capable of carrying out three level surveillance. One is TRUST which means no monitor. Another one is basic surveillance Watchdog. And the last one is high level surveillance SWAN. Watchdog and Pathrater is first proposed by Marti [3]. It is widely used in many trust and reputation systems as a detection and monitoring component [2, 4, 5]. And it also has low computational overhead. However, Watchdog is vulnerable to spoofing attacks: a suspicious node X may transfer a packet that its upstream neighbor (node N ) can overhear the transmission while its downstream neighbor can not overhear. Because of its vulnerability to spoofing attack, Watchdog has higher false negative rate [7]. Therefore, it cannot be relied on as the only method for observations. Some other technique should be used as a implementation for Watchdog. We introduce SWAN(secured Watchdog) into our mechanism. SWAN combines SUCV and TESLA [14] to provide Watchdog with message authentication which can detect spoofing packet dropping attack. It is showed that SWAN has higher detection accuracy rate than simple Watchdog, however, it also consumes more resource. We employe it as a high intensity surveillance.

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

243

In brief, in our mechanism, there are three surveillance levels: TRUST, which means no surveillance on the suspicious insider; low-level surveillance Watchdog which has lower detection rate but is resource-efficient; and the high-level surveillance SWAN which has higher detection rate but is more resource consuming. For a monitor N , the most significant task is to make decisions about when to trust an insider, and when to adjust from low intensity surveillance to high intensity surveillance. Next we will utilize game theory to help the monitor to make this decision. 3.2

Reward and Punishment Scheme

To motivate the intermediate nodes to cooperate in the packet forwarding stage, it is essential to define a reward and punishment scheme for the insiders. Each time the source node S sends its data packet to the destination node D, it should pay the the forwarding action of every cooperative intermediate node. As well, those insiders which are found dropping the data packets will be punished in the form of reputation. As we have already illustrated in section 2, all the insiders will maintain the reputation of nodes within its neighborhood. Here, we assume in a specific route that links S and D, the upstream nodes are aware of the reputation of the down stream nodes in this same route. For instance, in classical routing protocol AODV and DSR, each node will hold a routing table which maintains information of the routers in the discovered route paths [9]. So it is feasible to integrate the reputation record into the routing table. If a source node S wants to send its data packet to the destination node D, it will first check reputation OER of all the intermediate nodes the route to D, if there is a suspicious node in this route, S ask the upstream neighbor of this suspicious insider to lunch monitoring. Based on this, our reward and punishment rule is as follows: If the packet is successfully transmitted to the destination node, then the source node S will increase its trust-level to all the intermediate nodes in this path. It will reward this route by increasing the credibility of the intermediate nodes. We let the reward to the whole route is V , and the reward to each node on this route is a partition of V . With this kind of reward, the credibility of node X in the opinion of S will be increased. Moreover, the monitor N will be paid with additional reputation for its monitoring the suspicious. Otherwise, in the case a suspicious insider X drops data packet: (1) If this misbehavior is captured by its upstream monitor N , to punish the misbehaving node X which drops data packet, node N should decrease the reputation of node X dramatically, by L, and send the decreased reputation to other nodes (nodes within its neighborhood and nodes in the route). And the monitor will be rewarded with a certain quantity of reputation. (2) If the monitor didn’t monitor or didn’t detect the dropping behavior successfully, the route will suffer loss V . Each node’s loss is a partition of V . It is worth noting that, to avoid bad mouthing attack [6] lunched by a single monitor node, all the one hop neighbors of a suspicious insider X should be entrusted to monitor its behavior.

244

3.3

D. Hao, Y. Ren, and K. Sakurai

Surveillance Game Model

The interaction between the suspicious insider X and the monitor N can be modeled as a two-player mixed strategy game which we called surveillance game. Because neither the monitor nor the suspicious insider can see its opponent’s strategy, this game can be seen as a static game. Besides, as the reward and punishment rule is implemented in every single insider, the strategy set and utility function of these two players are public information. Consequently, this surveillance game is a static game of complete information. It is worth noting that: by solving this game using pure strategy game, there is no Nash Equilibrium. So we use mixed strategy game [15] to analyze the interaction between node N and X. Definition 2. A surveillance game between the monitor N and the suspicious insider X is described as a 4-tuple: G = {Γ ; Si; Pi ; Ui }. Here i ∈ Γ and Γ = {N, X} denotes the player set. Si is pure strategy set for player i. Pi is the mixed strategy set, which is a probability distribution over Si . Ui is the expected utilities for player i. For reference convenience, we list frequently used notations in Table 1. In the following part, the surveillance game will be constructed. As well, the elements of this game will be described in detail. – Player Set: Γ = {X, N }; The suspicious node X and the surveillance node N are two players in the game. X is in the one-hop downstream of N . Table 1. Notations Parameters V L ϕH ϕL k1 , k3 k2 , k4 k0 D CX S CN W CN GN GX

Meanings The total reward that S gives to the intermediate nodes between S and D. The punishment to suspicious insider X, if its packet-dropping is successfully detected by the monitor. The accuracy rate of high level surveillance SWAN The accuracy rate of low level surveillance Wathdog The partition that N shares from payoff asset V , if packet dropping is detected by SWAN and Wathdog, respectively. The partition that N endures from lost asset −V , if packet dropping is undetected by SWAN and Wathdog, respectively. The partition that N endures from total loss asset −V , if X drops packet under no monitor. X’s cost of dropping data packet. N’s cost of running high-level surveillance SWAN. N’s cost of running low-level surveillance Watchdog. N’s payoff under a certain game status. X’s payoff under a certain game status.

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

245

– Suspicious Node’s Pure Strategy Set: SX = {D, F }; D, F denote Drop and Forward, respectively. Suspicious node can either drop or forward the data packet. – Surveillance Node’s Pure Strategy Set: SN = {S, W, T }; S, W , T denote running SWAN, Watchdog, and TRUST, respectively. Surveillance node can choose a strategy from these three monitoring levels. – Suspicious Node’s Mixed Strategy Set: PX = {(p, 1 − p)}; As we illustrate above, X’s pure strategy set is SX = {D, F }. Mixed strategy (p, 1 − p) is a probability distributions over SX . We define the probability for strategy Drop is p, on the contrary, the probability for strategy Forward is 1 − p. – Surveillance Node’s Mixed Strategy Set: PN = {(x, y, 1 − x − y)}; The pure strategy set for surveillance node N is SN = {S, W, T }. Mixed strategy (x, y, 1 − x − y) is a probability distribution over SN . We define x as the probability to run SWAN, y as the probability to run Watchdog, and 1 − x − y as the probability to run TRUST. The following Table 2 is the joint probability distribution over SX and SN : Table 2. Mixed Strategy Two-dimensional Joint Distribution Strategy SWAN Watchdog Drop px Forward (1-p)x

py (1-p)y

TRUST p(1-x-y) (1-p)(1-x-y)

– Suspicious Node’s Payoffs: X’s payoff when it drops packet under N ’s high-level monitoring: D GX (D, S) = −CX + V · (1 − ϕH ) + (−L) · ϕH

X’s payoff when it drops data packet while N is running low-level monitoring: D GX (D, W ) = −CX + V · (1 − ϕL ) + (−L) · ϕL D And payoff when it drops packet but is trusted by N : GX (D, T ) = −CX +V – Surveillance Node’s Payoffs: N ’s payoff when it executes high-level monitor SWAN while X drops packet: S GN (D, S) = −CN + V · ϕH · k1 + (−V ) · (1 − ϕH ) · k2

N ’s payoff when it executes low-level monitor Watchdog while X drops packet: W GN (D, W ) = −CN + V · ϕL · k3 + (−V ) · (1 − ϕL ) · k4

N ’s payoff when it executes TRUST while X drops: GN (D, T ) = (−V ) · k0 . S W And GN (C, S) = −CN , GN (C, W ) = −CN , GN (C, T ) = 0 are the payoffs when X forward and N executes SWAN, Watchdog, TRUST, respectively.

246

D. Hao, Y. Ren, and K. Sakurai Table 3. Payoff Bi-Matrix Strategy



Drop Forward

SWAN GX (D, S) GN (D, S)  0 S −CN



Watchdog GX (D, W ) GN (D, W ) 0 S −CN



TRUST GX (D, T ) GN(D, T ) 0 0



– Utility Functions: After we proposed the mixed strategy joint distribution matrix and the utility bi-matrix, now we can define the overall utility functions for both X and N . Utility function for X:   UX (pX ; pN ) = pX · pN · GX (sX , sN ) (3) sX ∈{D,F } sN ∈{S,W,T }

Utility function for N : UN (pX ; pN ) =





pX · pN · GN (sX , sN )

(4)

sX ∈{D,F } sN ∈{S,W,T }

At a discrete time instant t, the player X and N both have strategy set. The suspicious node X chooses its strategy from set PX , and the monitor N chooses its strategy from set PX . Either X’s and N ’s strategy is a probability distribution over its pure strategy set. Furthermore, as we illustrated in Section 2, node N is able to predict node X’s packet dropping probability, then it will choose a mixed strategy to respond to X’s strategy. The joint strategy will bring utility for both players. And for the monitor N , its objective is to maximize it long-term overall utility. 3.4

Game Solutions

In this surveillance game, the monitor intends to maximize its long-term overall utility, and it will monitor the suspicious node at a certain probability. Our objective is to find the Nash equilibrium where there is no incentive for either monitor or suspicious node to deviate from the corresponding strategy. The Nash equilibrium shows one of the choices in the collections of optimal strategies made by node N and node X. By finding the optimal strategy, we can afford node N with the best way to response to X’s packet dropping probability which has been calculated in Section 2. In this part, we will use nonlinear programming method to find the game solution. As we illustrated in Table 3, for each array, the top value is the payoffs for suspicious node X, and the bottom value is the payoff for surveillance node N . By using Table 2 and Table 3, the overall expected utilities of node X and node N are recorded as UX (p; x, y) and UN (p; x, y), respectively. The monitor N ’s objective is to maximize its own expected utility UN (p; x, y). By investigating

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

247

the utility matrix, we can see there is no dominant strategy, which indicates that, the pure Nash Equilibrium does not exist. So we find the mixed strategy Nash Equilibrium of this game [15]. According nonlinear programming theory, the Nash Equilibrium is a solution to the optimization problems. And we can find the best mixed strategy of N by making partial derivative of UN (p; x, y) with respect to the parameter x and y, respectively. Firstly, by making partial derivative of the utility function with respect to parameter x, we get the the following equation which describes the relationship of utility of N and the packet-dropping probability of X: ∂UN (p; x, y) S = [(k1 + k2 ) · V · ϕH + (k0 − k2 ) · V ] · p − CN ∂x

(5)

To find the relationship between the suspicious insider’s packet-dropping probability γ, and the monitor’s strategy for running SWAN, we record: δ=

S CN [ϕH · k1 − (1 − ϕH )k2 + k0 ] · V

(6)

Given this equation, if the suspicious insider X’s packet-dropping probability N p < δ, then ∂U < 0 , UN is a monotonically decreasing function of x. UN ∂x N reaches its maximum value when x = 0. If p = δ, then ∂U ∂x = 0, UN is a ∂UN constant value function. At last, when p > δ, then ∂x > 0, UN is an increasing function of x. UN reaches its maximum value when x = 1. The significant of δ is that: it can be regarded as a threshold value for node N to make a decision when to execute high-intensity surveillance SWAN. Comparing this threshold δ with the expected packet dropping probability γ which is presented in Section 2, The surveillance node is able to choose a rational strategy for running SWAN. In a same way, we make partial derivative of the utility function with respect to parameter y: ∂UN (p; x, y) W = [(k3 + k4 ) · V · ϕL + (k0 − k4 ) · V ] · p − CN ∂y

(7)

and get another threshold value: λ=

W CN [ϕL · k3 − (1 − ϕL )k4 + k0 ] · V

(8)

The strategy for running Watchdog: If the predicted packet-dropping probability of node X is lower than λ, then the optimal strategy for the surveillance node N is not to run low-level monitoring Watchdog. If the predicted packet-dropping probability of node X equals λ, running Watchdog at any probability will incur the same utility to surveillance node N . And at last, if γ > λ, the best strategy for node N is to run Watchdog permanently.

248

3.5

D. Hao, Y. Ren, and K. Sakurai

Decision Making

As we illustrated above, δ is the threshold for high-level monitor, and λ is the threshold for low-level monitor. To realize the multi-level and on-demand surveillance, these two thresholds should be taken into consideration together. Consider Equation(6) and (8), if we set k1 ≈ k2 , and k3 ≈ k4 , because ϕH is significantly greater than ϕL (Experiments in [14] shows the accuracy of SWAN), then the probability λ is lower than δ. Comparing these two thresholds with suspicious insider X’s posterior packet-dropping probability γ(t), the monitor N is able to make a decision about which intensity-level should be adopt to monitor X. Figure.1 shows the relationship between surveillance strategies and the two threshold factors δ and λ. We call λ as lower threshold and δ as higher threshold. With these two threshold which we illustrate in Figure.1, we can develop the optimal surveillance strategy for the monitor N . And we can also provide the network manager with effective solutions to incentive the insiders to monitor each other, and improve the performance of the network. (1) In the monitor’s point of view: If γ is less than lower threshold λ, then γ locates between [0, λ], the optimal strategy is neither to run low-intensity monitor Watchdog nor run high-intensity monitor SWAN. In this case, node X will be trusted. It is worth noting that, being trusted not necessarily mean the suspicious node prone to be legitimate. The reason for node N to trust the suspicious is for the sake of maximizing its long-term utility. If the value of γ locates between [λ, δ], it means the predicted misbehaving probability of X is larger than the lower threshold λ but less than higher threshold δ. Then the optimal strategy for surveillance node is to run low-level monitor Watchdog but not to run high-level monitor SWAN. Finally, if γ locates between [δ, 1], according to the rule, surveillance node should both run high-intensity monitor SWAN and low-intensity monitor Watchdog. However, obviously, SWAN is a

Fig. 1. Value-intervals of predicted probability γ and corresponding strategies

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

249

secured Watchdog and overcomes the drawbacks of Watchdog. Therefore, in this situation, running high level monitor SWAN is the optimal strategy. (2) In the network manager’s point of view: For the equation of δ, the parameters k1 , k2 , k0 and ϕH are variables. The values of these four variables have direct influence on the probability δ. To a MANET manager, his objective is to make the interval [0, δ] become smaller which reduce the possibility of γ locates between [0, δ]. By increasing k1 , k2 , k0 and ϕH , this goal can be achieved. In other words, to incentive the surveillance node to execute monitoring, MANET manager should bind the suspicious insider’s gain and loss with the network’s overall payoff more tightly. Moreover, improving the monitor accuracy should also be considered. From the above, based on the predicted packet dropping probability γ, and the dual-threshold δ and λ, a multilevel and on-demand surveillance scheme is realized. This surveillance scheme takes both detection accuracy and resource consumption into consideration. It maximize the monitor’s long-term overall utility, and also balance the trad-off between security assurance and resource preserving.

4

Case Study

This subsection discuss the numerical analysis of the anti-suspicious surveillance game. Consider a network with 25 insiders. Each insider obtains the overall evaluation reputation(OER) of all its one-hope neighbors. When the source node S wants to communicate with the destination node D, a route path will be discovered between them. All the nodes on this route varies in reputation. We Assume there are 8 nodes in this route path, and their reputations are as follows: We set the reputation threshold for suspicious is η = 0.25, the 7th intermediate node X’s reputation OER is less than the preset threshold. Therefore it is considered as a suspicious insider. The source node S will entrust X’s upstream node N to monitor it. Both the high level surveillance SWAN and low level surveillance Watchdog confront with false positive rate and false negative rate [7]. According to the historical monitoring accuracy, we assume overall detection rate of high level surveillance SWAN is ϕH = 90%. Correspondingly, the overall detection rate of low level surveillance Watchdog is assumed to be ϕL = 70%. If data packet is successfully forwarded to the destination, each node in the current route will be rewarded in the form of reputation OER. Hence, we let the asset of this whole route is V = 1. And the monitors will be rewarded/punished with extra bonus which is a proportion of V . In our case, if Table 4. Reputation of Insiders Insiders Reputation

1

2

3

4

5

6

7

8

0.9501 0.7468 0.6068 0.4860 0.8913 0.7621 0.1763 0.8214

250

D. Hao, Y. Ren, and K. Sakurai

Fig. 2. Optimal strategies for monitor N and suspicious insider X

packet is successfully forwarded from S to D, we set the basic sharing proportion for each intermediate node is 1/8. Thus, for the monitor, its extra reward is 0.3 while the punish is 0.1. Then we can define the cost of running SWAN is S W = 0.3; the cost of running Watchdog is CN = 0.15. As we need to ensure CN S that CN < V · k1 , we can let k1 = k3 = 0.4, k2 = k4 = 0.1. Then according to the equation(6) and equation(8), the upper threshold δ is found to be 0.3750, while the lower threshold λ is 0.5455. The following graphs plot the optimal decisions for N to run SWAN and Watchdog, and the optimal decision for X to drop data-packet, respectively. The first graph expounds the optimal strategy for running SWAN, while the second graph describes the optimal strategy for running Watchdog. Combining this two decisions, the multilevel surveillance scheme can be realized. The third graph is the strategy for a suspicious insider. These three curve surfaces intersect at a unique Nash Equilibrium point. By following this Nash Equilibrium, the surveillance node will maximize its long term utility, regardless of what packetdropping probability the suspicious insider will follow.

5

Conclusion

In this paper, we propose a novel surveillance mechanism to observe the packetdropping behavior of suspicious insiders. We first introduce a reputation based

A Game Theory-Based Surveillance Mechanism against Suspicious Insiders

251

scheme to quantify the threat-level of a suspicious insider. And then, based on this quantified threat level, we used Mixed-Strategy Game to analyze the interaction between the monitor and suspicious insider. Finally, by finding the solution of this game, we find the equilibrium between security and resource consumption, and design an on-demand surveillance mechanism for the monitor. This surveillance mechanism will provide the monitor with optimal monitoring strategies, and balance the trade-off between security requirement and resource consumption. In our future work, we will consider the collusion between suspicious insiders and investigate the black/gray hole attacks by using game theory.

Acknowledgement This paper is coauthored with Yizhi Ren during his study in Kyushu University. The authors would like to thank the anonymous referees as well as the INTRUST conference audiences for their acute comments and suggestions.

References 1. He, Q., Wu, D., Khosla, P.: SORI: A secure and Objective Reputation-Based Incentive Scheme for Ad Hoc Networks. In: IEEE Wireless Communications and Networking Conference (WCNC 2004), Atlanta, GA, USA (March 2004) 2. Paul, K., Westhoff, D.: Context Aware Detection of Selfish Nodes in DSR Based Ad-hoc Networks. In: Proceedings of the IEEE Globecom Conference, Taipeh, Taiwan. IEEE, Los Alamitos (2002) 3. Marti, S., Giuli, T., Lai, K., Baker, M.: Mitigating Routing Misbehaviour Inmobile Ad Hoc Networks. In: International Conference on Mobile Computing and Networking (MobiCom 2000), pp. 255–265 (2000) 4. Buchegger, S., Boudec, J.Y.L.: Performance Analyis of the CONFIDANT Protocol: Cooperation of Node - Fairnes. In: Daynamic Ad-Hoc Networks. In: Proceedings of IEEE/ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC), Lausanne, CH (June 2002) 5. Michiardi, P., Molva, R.K.: CORE: A Collaborative Reputation Mechanism to Enforce Node Cooperation in Mobile Ad Hoc Networks. In: Sixth IFIP Conference on Security Communications, and Multimedia (CMS 2002), Portoroz Slovenia (2002) 6. Anjum, F., Mouchtaris, P.: Security for Wireless Ad Hoc Networks. WileyInterscience, Hoboken (2007) ISBN:0471756881 7. Bace, R.G.: Intrusion detection. Macmillan Publishing Co., Inc., Indianapolis (2001) 8. Xue, X.Y., Leneutre, J., BenOthman, J.: A Trust-based Routing Prtocol for Ad Hoc Networks. In: Proceeding of Mobile and Wireless Communications Networks, pp. 251–262 (October 2004) 9. Royer, E.M., Toh, C.K.: A review of current routing protocols for ad hoc mobile wireless networks. IEEE Personal Communications, 46–55 (April 1999) 10. Rachedi, A., Benslimane, A., Otrok, H., Mohammed, N., Debbabi, M.: A Secure Mechanism Design-Based and Game Theoretical Model for MANTEs. Mobile Networks and Applications 15(2), 191–204 (2010) 11. Liu, D., Wang, X.F., Camp, J.L.: Game Theoretic Modeling and Analysis of Insider Threats. International Journal of Critical Infrastructure Protection, 75–80 (2008)

252

D. Hao, Y. Ren, and K. Sakurai

12. Ayday, E., Fekri, F.: A Protocol for Data Availability in Mobile Ad-Hoc Networks in the Presentce of Insider Attacks. Ad Hoc Networks 8(2) (March 2010) 13. Janzadeh, H., Fayazbakhsh, K., Dehghan, M., Mehran, S.: A Secure Credit-Based Cooperation Stimulating Mechanism for MANETs Using Hash Chains. Future Generation Computer Systems 25(8), 926–934 (2009) 14. Xue, X., Leneutre, J., Chen, L., Ben-Othman, J.: SWAN: A Secured Watchdog for Ad hoc Networks. International Journal of Computer Science and Network Security (IJCSNS) 6(2), 209–218 (2006) 15. Gibbons, R.: Game Theory for Applied Economics. Princeton University Press, Princeton (1992) 16. Alpcan, T., Basar, T.: Network Security: A Decision and Game Theoretic Approach, November 30. Cambridge University Press, Cambridge (2010) 17. Bernardo, J.M., Adrian, F., Smith, M.: Bayesian Theory. John Wiley & Sons, Chichester (2000)

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage of Cryptographic Software Jean-Fran¸cois Gallais1 , Johann Großsch¨ adl1, Neil Hanley2 , Markus Kasper3 , 5 5 Marcel Medwed , Francesco Regazzoni , J¨ orn-Marc Schmidt4 , Stefan Tillich6 , and Marcin W´ ojcik6 1

5

University of Luxembourg, Luxembourg 2 University College Cork, Ireland 3 Ruhr University Bochum, Germany 4 Graz University of Technology, Austria Universit´e catholique de Louvain, Belgium 6 University of Bristol, United Kingdom

Abstract. Malicious alterations of integrated circuits (ICs), introduced during either the design or fabrication process, are increasingly perceived as a serious concern by the global semiconductor industry. Such rogue alterations often take the form of a “hardware Trojan,” which may be activated from remote after the compromised chip or system has been deployed in the field. The devious actions of hardware Trojans can range from the disabling of all or part of the chip (i.e. “kill switch”), over the activation of a backdoor that allows an adversary to gain access to the system, to the covert transmission of sensitive information (e.g. cryptographic keys) off-chip. In the recent past, hardware Trojans which induce side-channel leakage to convey secret keys have received considerable attention. With the present paper we aim to broaden the scope of Trojan side-channels from dedicated cryptographic hardware to general-purpose processors on which cryptographic software is executed. In particular, we describe a number of simple micro-architectural modifications to induce or amplify information leakage via faulty computations or variations in the latency and power consumption of certain instructions. We also propose software-based mechanisms for Trojan activation and present two case studies to exemplify the induced side-channel leakage for software implementations of RSA and AES. Finally, we discuss a constructive use of micro-architectural Trojans for digital watermarking so as to facilitate the detection of illegally manufactured copies of processors.

1

Introduction

A hardware Trojan can be defined as a malicious modification of an integrated circuit (IC) or system, introduced during either the design or fabrication process [8]. Hardware Trojans pose a serious issue to the semiconductor industry as chip fabrication is no longer done on-site but outsourced to cheaper facilities around the globe. The security implications of malicious modification of hardware, as well as techniques to detect such modification, are currently a very active area L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 253–270, 2011. c Springer-Verlag Berlin Heidelberg 2011 

254

J.-F. Gallais et al.

of research in both academia and industry [1,10,15,29]. Hardware Trojans can encompass any malicious functionality subversively placed into a system by an adversary, with a view to modifying the system’s intended behavior and/or its properties at a later date [8]. This modification of functionality may allow the adversary to deactivate an entire chip [14], gain access to the system through a secret backdoor [16], or extract confidential information (e.g. cryptographic keys) [18]. A classification of different Trojan types according to their physical characteristics, activation methods and subsequent payload is given in [25]. Hardware Trojans present a serious security threat to applications relying on smart cards, Trusted Platform Modules (TPMs) and similar hardware tokens that are implicitly trusted. For example, Trusted Computing (TC), as specified by the Trusted Computing Group (TCG) [26], is based on a TPM serving as a root of trust 1 (or trust anchor ) for the platform to which it is attached. A hardware Trojan maliciously inserted into a TPM can have disastrous consequences to the security and trustworthiness of a system. However, hardware Trojans are not only problematic for “classical” TPMs, but also when TPM-functionality is implemented in software and executed on a processor containing a hardware Trojan. More generally (and as emphasized in [28]), if the processor can not be trusted, no security guarantees can be provided by the system. One of the first references of secret key leakage from a system due to tampering in the manufacturing stage appears in [30], where the authors look at the implications of so-called black box cryptography and the possibilities for subtle information leakage concealed from the user. As noted in [8], the opportunities for an adversary to insert a hardware Trojan into an IC are not just limited to the fabrication stage of a chip. Larger hardware designs typically use IP cores from third-party vendors, which introduces another exploitable loophole since external IP of a certain complexity can not be exhaustively tested to prove its functionality. In the recent past, the threat posed by malicious alterations of IP cores that implement cryptographic operations (e.g. secret-key encryption) has been actively discussed in the literature. For example, Lin et al describe in [18] so-called Trojan Side-Channels (TSCs) and present the design of an AES core that “artificially” leaks secret information. Other case studies based on hardware implementations of secret-key algorithms are reported in [17] and [15]. A Trojan Side-Channel (TSC) is defined in [18,17] as an artificial (i.e. Trojaninduced) side-channel suitable for the covert leakage of secret information. Previous work on side-channel analysis in the realm of hardware Trojans focussed solely on utilizing the power or EM profile of ICs to obtain “fingerprints,” which facilitate the detection of Trojans via statistical tests [1]. Lin et al [18] were the first to change this perspective and proposed intentionally-introduced side-channel leakage as a building block for Trojan circuitry. They showed that Trojans comprising just 100 gates can generate sufficient side-channel leakage to reveal secret-key bits of an AES core implemented in an FPGA. More precisely, Lin et al [18] demonstrated how spread-spectrum communication (i.e. CDMA) can 1

The TCG defines a root of trust as “a component that must always behave in the expected manner, because its misbehavior can not be detected”.

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

255

be utilized in a TSC design to distribute the leakage of single bits of the secret key over many clock cycles. From a hardware perspective, the spread-spectrum TSC circuit is relatively small; it basically consists of an LSFR-based PRNG and a dedicated leakage generator. However, the spread-spectrum technique allows for leaking key bits below the effective noise-power level of the AES core, which makes the TSC circuit relatively hard to detect. A more formal treatment of the leakage mechanism and detection methods of spread-spectrum TSC circuits is given in [17]. With the present paper we aim to extend the scope of TSCs from dedicated cryptographic hardware to general-purpose processors on which cryptographic software is executed. We introduce novel micro-architectural TSCs that induce (or amplify) side-channel leakage through “faulty” computations or a variation of the latency (and power consumption) of certain instructions. Such variations can be realized, for example, by stalling the processor’s pipeline for a few cycles or by flushing the cache. The malicious pipeline stalls and/or cache flushes are invoked by the execution of specific instructions on operands that have a certain pattern (or if the result has a certain pattern, e.g. contains a zero-byte). Microarchitectural TSCs can be designed to leak significant information, to allow an adversary to easily recover the secret key, e.g. via Simple Power Analysis (SPA) [19] or an SPA-like attack. We also introduce and discuss different mechanisms for Trojan activation triggered by the execution of specific instructions on operands of a certain form. Since our hardware Trojans are completely passive until activated remotely, they can not be detected through functional testing during chip fabrication. In order to demonstrate the “functioning” of a micro-architectural TSC, we present two case studies; one is based on a software implementation of a simple challenge-response protocol using the AES, while the other exemplifies Trojaninduced side-channel leakage of an RSA exponentiation. Both case studies are conducted in a chosen-input scenario. We do not assume that the attacker has control over the cryptographic software executed on the processor (i.e. the software can be any crypto library, even one which is unknown to the attacker) as our TSCs were designed with the goal of leaking information regardless of the software implementation details for AES and RSA2 . Although the purpose of our micro-architectural TSCs is essentially the same as that of Lin et al’s TSCs [18], namely to reveal the secret key through artificial (i.e. Trojan-induced) side-channel leakage, there exist a number of fundamental differences. First and foremost, our micro-architectural Trojans target cryptographic software implementations instead of cryptographic hardware. A second major difference is the quantity and quality of the Trojan-induced side-channel leakage. The micro-architectural TSCs introduced in this paper leak clearly observable information that allows for mounting of an SPA-like attack (i.e. a small 2

However, we make some basic assumptions on the implementation of the cryptographic algorithms. In the case of AES, we assume that the xor instruction is used to add round keys. For the RSA example, we insist that the modulo multiplication is performed with help of the mul instruction.

256

J.-F. Gallais et al.

number of power traces is sufficient to reveal key material), whereas Lin et al’s TSCs leak secrets below the noise level over several cycles, which necessitates complex statistical postprocessing similar to a DPA attack. Moreover, the two micro-architectural TSCs we present also leak information via timing variations and could even be designed to introduce computational faults in the execution of instructions. A third difference lies in the activation of the Trojan; our TSCs contain a dedicated mechanism that allows for remote activation, whereas Lin et al’s TSC circuit is simply triggered by the start of an encryption operation. We also discuss a constructive use of micro-architectural Trojans for digital watermarking so as to facilitate the detection of illegally manufactured copies of a processor core. The idea of using a TSC in a constructive way was originally described in [2], where side-channel leakage due to a hardware Trojan is used as a watermark for IP protection. In this scenario, the Trojan physically leaks some information at the hardware level, which an “adversary” (in this case the IP owner) with the required knowledge can use to gain a certain benefit, e.g. to quickly detect illegally manufactured copies of microchips without doing a full reverse-engineering. We present a Trojan that allows one to induce side-channel leakage for digital watermarking through the execution of the mul instruction on two operands of a certain value only known to the IP owner. Executing the mul instruction on these operands stalls the pipeline for a number of cycles.

2

Preliminaries and Related Work

Our work on micro-architectural TSCs is related to the work of Lin et al [18,17] as mentioned before. Furthermore, there exist some similarities between TSCbased attacks and bug attacks, micro-architectural side-channel attacks, as well as classical fault attacks. 2.1

Bug Attacks

Bug Attacks, as introduced in [5], combine fault analysis (see Section 2.3), with buggy hardware to recover secret information from a system. Such bugs have been discovered in a number of processors; well-known examples are the Intel 80286 popf bug and a bug in the Pentium processor’s floating point unit. With the increasing complexity of microprocessors, it is very likely that more design errors will slip through functional testing and remain undetected. A hardware bug of a processor can, in some way, be seen as an unintended (or accidental ) hardware Trojan. Note that higher chip complexity also implies a bigger chance of deliberately inserted hardware Trojans to remain undetected. Some concrete attacks on different RSA [22] and Pohlig-Hellman [20] implementations are presented in [5], each assuming execution on a processor with a buggy multiplier. It is possible to extend this attack to elliptic curve cryptosystems as they also make use of hardware multipliers in processors. The attack in [7] serves to demonstrate how the secret exponent of RSA, implemented using the Chinese Remainder Theorem (CRT), can be extracted via a single chosen

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

257

Fig. 1. Overlaid (left) and individual (right) power consumption traces showing ARM7 multiplications that take 2, 3, 4 and 5 clock cycles (top left to bottom right) [13]

chiphertext. An attack on an RSA implemention without CRT, even in presence of the Optimal Asymmetric Encryption Padding (OAEP) [3] countermeasure, is also described in [7]. The relevance of the attack with regard to symmetric-key primitives performing integer multiplications is briefly mentioned. 2.2

Micro-Architectural Side-Channels

Micro-architectural attacks exploit certain features or effects of commodity processor components (e.g. cache sub-systems, branch prediction units) to induce or amplify side-channel leakage. Recently, micro-architectural cryptanalysis on basis of cache hits or misses as well as branch mis-predictions has been studied extensively, and several successful attacks are reported in the literature. These attacks allow an adversary to extract secret keys from cryptographic software implementations, even if they feature dedicated side-channel countermeasures that would completely prevent leakage on processors without cache sub-system or branch prediction unit. Note that the adversary does not necessarily need to have physical access to a processor to accomplish a cache or branch-prediction attack since information about the secret key typically leaks through both the power (including EM) and the timing side-channel. Hence, these attacks can be mounted remotely, even over the Internet. In 2009, a new micro-architectural side-channel was discovered, namely the early-termination mechanism of integer multipliers in embedded processors like the ARM7TDMI [13]. In short, the ARM7TDMI contains a (32 × 8)-bit multiplier that executes a (32 × 32)-bit multiplication a × b in an iterative fashion by processing 8-bit digits of the 32-bit operand b at a time. The result of the first iteration, in which a is multiplied by the least significant digit of b, is fed back into the multiplier and “combined” with the intermediate products of the following iterations to finally yield the full 64-bit result. After each iteration, the multiplier checks whether the remaining digits of b are all 0; if this is the case

258

J.-F. Gallais et al.

the multiplication is terminated “early” and the result is immediately returned [13]. Due to this early termination, the latency of multiply instructions, such as mul or umull, is not constant but varies by up to three clock cycles depending on the magnitude of operand b. An attacker can easily observe the differences in the latency of the multiply instruction, either in a coarse-grained fashion (via variations in execution time) or in a fine-grained fashion (through differences in the power consumption of a particular mul or umull instruction as illustrated in Figure 1). Exploiting the early-termination mechanism makes SPA attacks relatively straightforward to conduct, and may even allow one to attack an implementation with integrated SPA countermeasures that does not leak any information when executed on a processor with a constant-latency multiplier. A description of such attacks on SPA-resistant software implementations of RSA and ECC is given in [13]. Note that not only public-key schemes, but also symmetric ciphers, such as RC6 and a specific 32-bit AES implementation, are vulnerable to SPA-like attacks when executed on an ARM7TDMI processor. Besides the ARM7TDMI, there exist a number of other (embedded) processors with early-terminating multipliers, including (but not limited to) the StrongARM SA-1100, the MIPS32 4Km, and certain PowerPC models. In some sense, the early-termination mechanism can be seen as an accidental hardware Trojan. 2.3

Fault Attacks

A fault attack uses an erroneous output of a device to recover the secret stored in the device. In order to get hold of an erroneous output, one usually has to disturb the device during the execution of a cryptographic algorithm. The way in which this disturbance takes place is called the fault model; it describes the fault by a set of parameters, such as the timing precision and its effect on the data values. Fault models can range from bit-flips, which occur at an uncertain point in time, over time-accurate random byte faults to faults which influence the program flow, e.g. skipping instructions or function calls. The most famous fault attack is probably the Bellcore attack [7], where one of the two exponentiations of a CRT-RSA computation is disturbed. For this attack, the public key and a single erroneous output are enough to factor the RSA modulus and thus recover the secret key. For other attacks on public-key schemes, more erroneous outputs are needed [24]. However, due to the existence of a public key, usually no correct output (as in a differential fault attack) is required. Obtaining a correct and faulty output pair is, in many cases, not even possible due to the probabilistic nature of public-key schemes. In contrast, fault attacks on secret-key schemes are often differential [6]. In a differential attack the same computation has to be executed with and without a fault so that the attacker obtains pairs of faulty and correct outputs and can observe the difference. The only non-differential attacks on secret-key schemes are high-level attacks, such as skipping of individual rounds [9] or deleting the S-box table [23]. Thus, we mostly restrict our scope in this paper to differential fault attacks.

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

259

Regarding to the precision of the fault induction, a hardware Trojan allows for more data accuracy, but is potentially harder to time than a straightforward fault attack. This is because fault injection on symmetric ciphers usually takes place in the last rounds. However, the intermediate values of the last rounds are unknown to the attacker and, hence, can not be used to activate the Trojan and invoke the fault injection. A simple way to overcome this problem is to trigger on the plaintext (which is processed in the first round), but delay the occurrence of the erroneous behavior to a later round.

3

Activation Mechanisms

In this section we introduce and discuss different activation options for a Trojan, focusing in particular on the possibility of parametrizing such an activation. Following the Trojan circuit taxonomy suggested in the paper of Wolff et al [29], we divide a Trojan into two main parts: the activation mechanism, which is often also called trigger, and the payload sections. More precisely, the trigger is the portion of the malicious circuit that is devoted to the activation of the payload whenever pre-defined conditions occur. Such conditions might be external or internal and, thus, we can further distinguish between external and internal activation mechanisms [25]. Typically, to handle external activation, an external condition monitor is necessary, which can be implemented using an antenna or some type of sensor, as outlined in [25]. The internal activation instead exploits conditions that occur internally in the chip. Possible examples are a set of predefined input patterns, particular values that are stored into a counter, or even a sequence of special logic values that appear on the activation nets. Internal triggers can be implemented as a set of combinatorial gates or as a sequential circuit, which typically generate a negligible area and performance overhead. The activation condition for a hardware Trojan should be carefully selected and designed so as to prevent accidental triggering. In particular, it is required that the activation sequence has a very small probability to appear by chance during the “normal” operation of the processor. This requirement is of crucial importance to avoid the detection of a Trojan. In fact, if the activation sequence is very rare, it also helps the malicious hardware to remain undetected during the chip testing phase based on functional testing or the automatic generation of test patterns (ATPG). An activation mechanism can be extended to support parametrization, which allows an adversary to enable a different behavior of the Trojan to cater for different attack scenarios. In certain cases, it can be advantageous when the hardware Trojan supports explicit deactivation. An example is differential fault analysis, for which both a correct and a faulty result of a cryptographic operation are needed. The same mechanism that activates a Trojan can also be used for its deactivation, e.g. the first recognition of a pre-defined input pattern or input sequence activates the Trojan, and the second recognition of this pattern deactivates the Trojan. In the context of this paper, we are interested in gaining information on the secret key used in AES as well as RSA encryption operations. Our focus will be

260

J.-F. Gallais et al.

primarily on activation mechanisms triggered by the recognition of a particular input pattern or a specific input sequence. However, since the data containing the activation pattern (resp. sequence) is supplied from outside (e.g. in the form of a plaintext that is sent to the processor to become encrypted), our activation mechanism belongs to the “external” category according to the definition from [25]. In the following, we propose two possible activation scenarios, the first one can be used to trigger a Trojan that is designed to reveal the secret key of AES software running on the processor, while the second is geared towards RSA and other public-key cryptosystems executing mul instructions. 3.1

Method 1: Snooping the Data Bus

In the first case, the trigger mechanism is attached between the processor core and the data cache to snoop and check all data transmitted over the bus. The analysis of the data is done without any effect until the pre-defined activation sequence is identified. In this paper, we assume that the activation sequence is fixed (“hard-coded”) in the trigger, i.e. it can not be changed after fabrication of the chip. Moreover, since we are dealing with a Trojan specifically designed for attacking the AES algorithm, we decided to rely on an activation sequence of 16 bytes, which is also the size of an AES plaintext block. Such a length is sufficient to significantly reduce the possibility of accidental activation; nevertheless, we select a completely random sequence, which is extremely unlikely to appear when considering ASCII characters as input plaintext. In order to support parametric execution of our Trojan, we split the 16 bytes of the activation sequence into two sets: the first one, consisting of 12 bytes, is the actual activation pattern; the second set, which has a length of 4 bytes, contains the parameter(s) that can be passed to the Trojan during activation. Even though in this case the activation pattern is reduced to 12 bytes, a total of 296 possible inputs is sufficient to prevent accidental activation of the Trojan. The probability of undesired activation can be further decreased by using a simple counter to keep track of the total number of recognized activation patterns, and triggering the Trojan only after a specific number of them. We propose to use the same pattern for both activation and deactivation of the hardware Trojan since this is the best possible solution for minimizing the area overhead. Once activated, the Trojan can perform the devious task it has been designed for, which in our case is leaking information about cryptographic keys through e.g. fault injection, pipeline stalls, or cache flushes. In Section 5 we describe an attack in detail, using an AES-based challenge-response authentication protocol as a case study. In such a protocol, one entity (the “verifier”) sends a nonce (a “challenge”) to the other entity (the “prover”), who has to respond with the encrypted nonce to prove its knowledge of the secret key. Let us assume that the prover’s AES software runs on a trojanized processor and the attacker plays the role of a verifier. To activate the Trojan, the attacker simply sends a nonce containing the pre-defined activation pattern to the prover. In our example the nonce has a length of 16 bytes (i.e. four 32-bit words) to match the block size of the AES. The AES software running on the verifier’s processor will, at some

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

261

point, load the four 32-bit words into the register file and, thereby, trigger the activation mechanism. 3.2

Method 2: Snooping Operands of Instructions

The second trigger mechanism we introduce in this paper is based on execution of the multiply instruction. Various public-key cryptosystems, such as RSA and Elliptic Curve (EC) schemes over prime fields, perform long-integer arithmetic operations, in particular modular multiplication. Therefore, software implementations of these cryptosystems execute a large number of mul instructions. In addition, some block ciphers (e.g. RC6, IDEA, DFC, MultiSwap, Nimbus), the stream cipher Rabbit, as well as the message authentication code UMAC also rely on integer multiplication. There exists even an optimized implementation of the AES that makes use of the mul instruction to speed up the MixColumns transformation [12]. In this subsection, we introduce a mechanism for Trojan activation through multiplication of a specific pair of input operands a, b. The two operands have a length of 32 bits when taking a 32-bit processor as example, which means that the probability of an accidental activation of the Trojan (i.e. the probability that a mul on exactly these operands is executed by chance during “normal” operation) is 2−64 . Similarly, on a 64-bit processor, the probability of accidental activation is 2−128 . Of course, the exact probability also depends on whether the order of the two operands is relevant; a trigger can be designed such that a multiplication of the form a × b is, or is not, the same as b × a. The activation circuit we describe in this subsection is “directly” integrated into the processor core and snoops on the instruction decoder and the operand buses that connect the register file with the multiplier. We assume a conventional RISC architecture with a 3-operand instruction format (two source registers and one destination register); consequently, there are two buses over which the operands are transferred from the register file to the functional units and the multiplier. Whenever the trigger circuit detects the decoding of a mul instruction, it also checks whether the two operands transferred over the buses have specific pre-defined values. If this is the case, the trigger activates the payload section of the Trojan to perform one (or more) of the devious actions we discuss in the next section. In the most basic case, the Trojan simply induces a bit flip (or another kind of fault) in the execution of the mul instruction by which it was activated. However, a Trojan can also be designed to leak side-channel information through one or more of the subsequent instructions that are executed after the triggering mul instruction. It is, of course, also possible to use other instructions besides mul to activate a Trojan. However, the mul instruction has the advantage that its execution requires several clock cycles on standard processors; hence, the circuitry for comparing operands can be easily implemented without increasing the critical path of the processor. A natural question to ask is whether (and how) an adversary can provoke the execution of a mul instruction with exactly the two operands a, b that activate the trigger. Biham et al [5] describe an example of a bug attack with relevance

262

J.-F. Gallais et al.

to our setting. Let us assume a CRT-based implementation of RSA decryption running on a trojanized processor. The RSA software decrypts ciphertexts via a private key unknown to the adversary. However, the adversary knows the public key (E, N ) corresponding to this private key, where N denotes √ the modulus. In order to activate the Trojan, the adversary first computes C = N , rounded to the nearest integer. This C is guaranteed to be between the two factors P and Q of N , and any number close to C is also likely to meet this condition [5]. In other words, when P is the smaller of the two factors of N (i.e. P < Q), then P < C < Q is always satisfied (see [5] for details). The adversary replaces the two least significant words of C by a and b and inputs this “poisoned” ciphertext to the RSA decryption function. The first computation step of CRT-based RSA decryption is to reduce the ciphertext C mod P and mod Q. However, as C < Q, it happens that (C mod Q) = C. The next step is to square the reduced ciphertexts modulo P and Q, respectively. Note that the squaring of C modulo Q involves a multiplication of a by b, which is exactly the operation that fires the trigger. In summary, the adversary can activate the Trojan by feeding the decryption function a carefully manipulated ciphertext.

4

Effects of the Trojan

As already stated in Section 3, a hardware Trojan consists of a trigger and one or more payload sections, whereby the latter actually implement the disruptive effect(s) of the Trojan. In this paper we are concerned with micro-architectural Trojans that induce (resp. amplify) side-channel leakage of cryptographic software. A micro-architectural Trojan may convey information about secret keys by introducing a computational fault (e.g. a bit-flip) during the execution of a certain instruction, or by varying the latency and, hence, power consumption profile of one or more instructions (e.g. through deliberately-induced pipeline stalls). Consequently, leakage via both the timing and the power side-channel is possible. Depending on the form of leakage, the adversary has to analyze either faulty results, timing variations, or power traces to get the secret key, similar to a “conventional” fault, timing, or SPA attack, respectively. There are several ways of how a Trojan designer can organize the interplay between trigger and payload. As described in Section 3, our micro-architectural Trojan is triggered either by the recognition of a pre-defined sequence of words on the data bus, or by the execution of the mul instruction on two pre-defined operands. The leakage of information, however, always occurs through execution of certain instructions, which we call trojanized instructions in the rest of this paper. Note that not necessarily every execution of a trojanized instruction induces information leakage. Whether or not the execution of a trojanized instruction actually leaks information depends on the kind of attack the Trojan has been designed for. Three different scenarios are possible: – In the simplest case, only the very first execution of a trojanized instruction (after triggering) leaks information; all subsequent executions of the same instruction are carried out normally. It is also possible to delay the leakage

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

263

for a certain period of time (e.g. one can design a Trojan payload so that the 10th execution after the triggering leaks, or the first execution after 1,000 clock cycles). On the other hand, Trojan activation and information leakage can even take place in one and the same clock cycle, e.g. by execution of a mul instruction that activates a Trojan to flip a bit of the result (similar to a bug attack [5]). In all of these examples, information leakage is induced in just one execution of a trojanized instruction; all other executions of this instruction do not “artificially” leak. Hence, this kind of Trojan payload is mainly relevant in the context of fault attacks. – The payload of a Trojan can also be designed in such a way that a certain number of executions of a trojanized instruction leak information, not just a single execution as above. The number of leaking executions can either be fixed or “programmable” if the trigger supports parameterization (see Section 3). After these leaking executions have been completed, the trojanized instruction is again executed in a normal way without artificial information leakage. The Trojan can induce leakage either immediately after activation or delayed by a certain number of clock cycles. In the following subsection we describe an example in which 16 consecutive executions of a trojanized load or xor instruction allow an attacker to obtain parts of the secret key used in an AES implementation. – Finally, the payload can induce leakage in every execution of a trojanized instruction until the Trojan is explicitly deactivated. Such a deactivation is typically realized in the same way as activation, e.g. by the recognition of a pre-defined sequence of four words on the data bus, or by execution of the mul instruction on two pre-defined operands. This kind of Trojan is suited for timing and power analysis attacks. In the following subsections we provide detailed examples of how a trojanized instruction can leak information by inducing faults or variations in latency and power consumption. 4.1

Fault Induction

Fault induction is the simplest way in which a micro-architectural Trojan can leak information; in the best case, a single bit-flip is sufficient to obtain the full secret key used in a software implementation of a cryptographic algorithm. In this subsection, we look at two different scenarios: In the first, a look-up table outputs zero instead of the actual value. In the second scenario, a trojanized instruction flips one bit of the result. Zero Look-Ups. We assume a software implementation of the AES that performs the S-box operation using a look-up table. In the following example, the trojanized instruction is the load, but a similar attack can be mounted if the Trojan manipulates the xor operation. Our attack requires that 16 consecutive executions of the load instruction (namely exactly those loads doing the S-box look-ups of a round of AES) return zero instead of the actual table entry. All

264

J.-F. Gallais et al.

subsequent loads are executed in a normal way, i.e. without manipulation of the loaded entries. The zero look-ups set each byte of the state matrix to a known deterministic value, namely zero in our example. Setting all bytes of the state to a known value during encryption or decryption can be seen as equivalent to reducing the number of rounds to the amount of rounds performed after these zero look-ups. For example, a Trojan that sets the state matrix to zero at the beginning of the final round allows an attacker to directly obtain the last round key. A similar attack can be mounted when the Trojan manipulates the xor instruction (which is used for key addition) during one round of AES encryption or decryption. The big advantage of this method is that no correct encryption of the same plaintext is required as for differential fault attacks. A practical implementation of the proposed zero look-up attack requires one to deal with two main issues: The first issue is the need to delay the effect of the Trojan for a certain period of time, i.e. the zero look-ups should not take place immediately after activation of the Trojan. When using the trigger mechanism presented in Section 3.1, the Trojan is activated at the beginning of the encryption, i.e. when the plaintext is loaded from memory into registers. However, the actual fault injection has to take place in one of the last rounds (as explained in Subsection 2.3), which means that typically several AES rounds are executed between the triggering and the zero look-ups. If the trigger supports parameterized activation as described in Section 3, the attacker can pass the delay to the Trojan, either as number of clock cycles or as number of load instructions that need to be executed normally. Finding the correct delay may require some “trial and error” unless the attacker knows which AES implementation is running on the target processor. A second issue to consider and deal with in practice are context switches, which can lead to unforeseen errors. Single Bit-Flip in Instruction Execution. If only one, or a few, bits of the result of a trojanized instruction are manipulated, the injected fault meets the models required by “traditional” fault attacks on symmetric ciphers (as shown in [11,21,27]) as well as RSA [5]. In the case of AES and other block ciphers, a good candidate for a trojanized instruction is the xor, which is typically used to add round keys. For example, Tunstall et al [27] present a differential attack on AES that allows one to reduce the search space for the secret key from 2128 to 28 with one pair of correct and faulty ciphertext, assuming a random byte fault being injected at a known position of the state in the 8th round. Again, when using a trigger mechanism which activates the Trojan at the beginning of the encryption, the fault injection (e.g. flipping a bit in the result of an execution of the xor instruction) needs to be delayed to one of the last rounds, which can be achieved in the same way as in the previous example. Delaying the fault injection is not necessary for Trojans designed to leak the secret key of RSA [22] and other public-key cryptosystems. A natural candidate for implementing the trigger mechanism is the mul instruction executed on two specific pre-defined 32-bit operands as detailed in Subsection 3.2. The mul can also be the trojanized instruction for injecting a fault, e.g. by flipping a bit of the result. In the simplest case, the same execution of mul that triggers the Trojan

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

265

can also introduce the fault in the computation of the algorithm; this is exactly the scenario of a bug attack as described in [5] for a CRT-based implementation of RSA. We refer to [5] for a detailed explanation of how an attacker can reveal the secret key used in an decryption operation with a chosen ciphertext. Deliberately introduced multiplication faults can also be used to gain information about the secret keys of symmetric ciphers which require the execution of the mul instruction (e.g. IDEA, RC6, DFC). In particular, if the encryption (or decryption) result of an algorithm that multiplies subkeys by intermediate values is known to be incorrect, the attacker may be able to draw information about this subkey. 4.2

Timing Variation

A micro-architectural Trojan can leak information about the secret key used in a software implementation of a cryptographic algorithm by varying the latency of certain instructions. Obvious candidates for trojanized instructions are the xor when attacking secret-key cryptosystems, such as the AES, and the mul in case of RSA and other public-key cryptosystems. The simplest way to vary the latency of a trojanized instruction is most likely to stall the processor’s pipeline for a certain number of cycles. A second way for conveying information through the timing side channel is to flush the cache at certain points of time during the execution of an algorithm, which introduces additional delay that could make an attack similar to the one in [4] feasible. In the following, we describe how a micro-architectural Trojan can leak information about the secret key used in a software implementation of the AES (resp. RSA) algorithm via a manipulation of the latency of the xor (resp. mul) instruction. Any software implementation of the AES algorithm uses the xor instruction to add the round keys to the state (or to the plaintext at the beginning of an encryption). Imagine a Trojan that, if activated, manipulates the latency of the xor instruction depending on its result in the following way: when the least significant byte (LSB) of the 32-bit result of the xor is zero (and all other bytes are non-zero), then the pipeline is stalled by one clock cycle. Similarly, when the second (resp. third) least significant byte is zero (and all other bytes are non-zero), the Trojan stalls the pipeline for two (resp. four) cycles. The pipeline is stalled for eight cycles if the most significant byte (MSB) is zero, but all others are not. Consequently, the latency of the trojanized xor instruction can vary between one clock cycle (if all bytes are non-zero) and 16 clock cycles (if all bytes are zero). As mentioned before, the first round-key is xored directly with the plaintext at the beginning of the encryption. If now the LSB of the plaintext is identical to the LSB of the first round-key, the LSB of the result of the xor is zero, which causes the Trojan to stall the pipeline for one cycle, thereby leaking the LSB of the first round-key. The attacker can simply obtain the LSB of the first round-key by “feeding” the encryption function 256 plaintexts with LSBs ranging from 0 to 255. One of these plaintexts will provoke a pipeline stall for a cycle; the LSB of this plaintext is exactly the LSB of the first round-key. The other bytes of the round-key can be obtained in the same way.

266

J.-F. Gallais et al.

A similar attack can be mounted against RSA and other public-key schemes when the Trojan increases the latency of the mul instruction depending on the magnitude of one of the two operands, e.g. the multiplicand. The Trojan stalls the pipeline for one cycle if the MSB of the multiplicand is zero (but all of the other bytes are non-zero). Analogously, if the second (resp. third, fourth) most significant byte of the multiplicand is zero (and all other bytes non-zero), then the pipeline is stalled for two (resp. four, eight) cycles. In summary, the Trojan increases the latency of the mul instruction by between one cycle (MSB of the multiplicand is zero) and 15 cycles (all bytes of the multiplicand are zero). The effect of increasing the mul latency can, in a way, be seen as the “inverse” of the early-termination effect discussed in Subsection 2.2 and may be referred to as late-termination effect. A Trojan increasing the mul latency as described allows the adversary to distinguish modular multiplications from modular squarings (similar to the attacks exploiting the early-termination mechanism [13]), even if the modular exponentiation would not leak any information when executed on a Trojan-free processor. We refer to [13] for more details on how one can obtain the secret exponent of an RSA implementation by exploiting operand-dependent variations in the latency of the mul instruction. 4.3

Variation of Power Consumption

A disadvantage of the timing side-channel is that it leaks information about the secret key in a rather “coarse-grained” way as an attacker can only observe the overall execution time of a cryptographic algorithm. The power side channel, on the other hand, allows for a more “fine-grained” observation of the latency of a trojanized xor (resp. mul) by monitoring the power consumption of individual executions of these instructions. As mentioned before, our Trojan can increase the latency of the xor (resp. mul) instruction artificially by stalling the pipeline for a certain number of cycles depending on the bytes of the result (resp. the multiplicand). The cycles in which the processor does not execute instructions (because of a stalled pipeline) have notably less power consumption than cycles in which the processor operates normally (see Figure 1). This property can be explained by the fact that, at the circuit level, the power consumption of a gate is composed of a static component (which is constant and typically low) and a (relatively high) dynamic component. The latter is determined by switchings occurring at the outputs of the gates [19]. When little switching activity takes place (due to the pipeline stall), the power consumption of the processor drops down to its static part, which is easily observable using a typical measurement setup for a power analysis attack. The information leaked via the power consumption of the xor and mul instruction is the latency of individual executions of these instructions, which can be used to mount attacks as described above. Note that a micro-architectural Trojan may also be used in a “constructive way” for digital watermarking of a processor core [2]. An integer multiplier can be designed such that for one particular pair of operands, the pipeline is stalled for some clock cycles. Such a pair of inputs cannot be easily guessed, and hence allows a processor designer or vendor to reliably identify his IP using a typical

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

267

power analysis measurement setup. The IP owner (or any other entity knowing the correct operand pair) just needs to observe the power consumption profile of the processor core to detect pipeline stalls during the multiplication of this pair of operands. Identifying an IP block with the help of a digital watermark is orders of magnitude cheaper than a full reverse engineering.

5

Case Studies

In the following, we demonstrate with two examples how a micro-architectural Trojan can be used to mount attacks against software implementations of AES and RSA, respectively. Both examples are conducted in a chosen-input scenario (i.e. chosen plaintext in the case of AES, chosen ciphertext for RSA). 5.1

Attacking AES

We use a simple AES-based challenge-response authentication protocol to explain the attack. The protocol works as follows: One entity (the “verifier”) sends a nonce (“challenge”) to the other entity (the “prover”), which has to respond with the encrypted nonce to prove possession of the secret key. Such challengeresponse protocols have numerous practical applications ranging from access control systems to radio frequency identification (RFID). Let us assume that the prover’s AES software runs on a trojanized processor and that the attacker plays the role of a verifier. The goal of the attacker is to obtain the secret AES key used by the prover. In order to activate the Trojan, the attacker first sends a nonce containing the pre-defined activation pattern to the prover. As explained in Subsection 3.1, the prover will at some point in time load the challenge from memory to the register file, which activates the Trojan. Once activated, the Trojan can leak through variations in the latency of the xor instruction (see Section 4.2). We assume that the attacker has the ability to measure the power consumption of the trojanized processor when running the prover’s AES code. In order to obtain the least significant byte (LSB) of the first round-key, the attacker just sends 256 challenges with 256 different values for the LSB (ranging from 0 to 255) to the prover. One of these 256 challenges contains an LSB that is identical to the LSB of the round key; the execution of the xor instruction adding the identical LSBs together will stall the pipeline for a cycle, which the attacker will be able to observe through the processor’s power consumption profile. In this way, he gets the LSB of the first round key; the remaining bytes can be obtained in a similar way. 5.2

Attacking RSA

Let us assume an SSL (or TLS) server running on a trojanized processor. The SSL software is using a CRT-based RSA implementation to perform secret-key operations (i.e. decryption and signature generation [22]). In our example, the attacker plays the role of a client wishing to establish a secure connection with

268

J.-F. Gallais et al.

the SSL or TLS server. His goal is to obtain the secret RSA key the server uses for key establishment. Possession of this secret key would allow the attacker to decrypt all encrypted communication between the server and other clients. In essence, the SSL protocol is composed of two sub-protocols, one of which is the handshake protocol for authentication and key establishment. When using an RSA-based cipher suite, the secret key shared between a client and a server is established via key transport: The client generates a random number, encrypts it under the server’s public RSA key, and sends the result to the server. The server has to perform an RSA decryption to obtain the shared secret. In order to activate the Trojan, the attacker sends a “manipulated” ciphertext instead of an encrypted random number to the server. This manipulated ciphertext has to be generated exactly as described in Section 3.2. In short, the manipulated ciphertext is an integer C corresponding to the square root of the modulus N (rounded to the next-nearest integer), in which the two least significant 32-bit words are replaced by the two operands that active the trigger when a mul instruction is executed on them. The rest of the attack now depends on how the Trojan leaks information. If the Trojan injects a fault in one execution of the mul instruction, then the attack is essentially the same as Biham et al’s bug attack described in [5]. On the other hand, if the Trojan causes variations in the latency (and power consumption) of the mul instruction, an attack can be mounted in a similar way as the early-termination attack from [13].

6

Conclusions

In this paper, we introduced micro-architectural Trojans, a new class of hardware Trojans specifically designed to induce (or amplify) side-channel leakage of cryptographic software. A trojanized processor can leak information about a secret key through faulty computations or variations in the latency (as well as power consumption) of certain instructions. We also proposed novel softwarebased mechanisms for Trojan activation and exemplified their operation in two case studies on attacking AES and RSA. Our micro-architectural Trojans pose a serious security threat since they can be applied to attack arbitrary software implementations of cryptographic algorithms (including AES and RSA), even when they are protected by sophisticated countermeasures against timing and power analysis attacks that completely prevent side-channel leakage on genuine processors. Therefore, malicious fabs with the ability to inject Trojans concern not only cryptographic hardware, but also cryptographic software. Acknowledgements. The research described in this paper was supported, in part, by the EPSRC under grant EP/H001689/1 and the European Commission through the ICT Programme under contract ICT-2007-216676 ECRYPT II. The information in this paper reflects only the authors’ views, is provided as is, and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

Hardware Trojans for Inducing or Amplifying Side-Channel Leakage

269

References 1. Agrawal, D., Baktır, S., Karakoyunlu, D., Rohatgi, P., Sunar, B.: Trojan detection using IC fingerprinting. In: Proceedings of the 28th IEEE Symposium on Security and Privacy (S&P 2007), pp. 296–310. IEEE Computer Society Press, Los Alamitos (2007) 2. Becker, G.T., Kasper, M., Moradi, A., Paar, C.: Side-channel based watermarks for integrated circuits. In: Proceedings of the 3rd IEEE International Workshop on Hardware-Oriented Security and Trust (HOST 2010), pp. 30–35. IEEE Computer Society Press, Los Alamitos (2010) 3. Bellare, M., Rogaway, P.: Optimal asymmetric encryption. In: De Santis, A. (ed.) EUROCRYPT 1994. LNCS, vol. 950, pp. 92–111. Springer, Heidelberg (1995) 4. Bernstein, D.J.: Cache-timing attacks on AES (2005) (preprint), http://cr.yp.to/papers.html#cachetiming 5. Biham, E., Carmeli, Y., Shamir, A.: Bug attacks. In: Wagner, D. (ed.) CRYPTO 2008. LNCS, vol. 5157, pp. 221–240. Springer, Heidelberg (2008) 6. Biham, E., Shamir, A.: Differential fault analysis of secret key cryptosystems. In: Kaliski Jr., B.S. (ed.) CRYPTO 1997. LNCS, vol. 1294, pp. 513–525. Springer, Heidelberg (1997) 7. Boneh, D., DeMillo, R.A., Lipton, R.J.: On the importance of checking cryptographic protocols for faults. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 37–51. Springer, Heidelberg (1997) 8. Chakraborty, R.S., Narasimhan, S., Bhunia, S.K.: Hardware Trojan: Threats and emerging solutions. In: Proceedings of the 14th IEEE International High Level Design Validation and Test Workshop (HLDVT 2009), pp. 166–171. IEEE Computer Society Press, Los Alamitos (2009) 9. Choukri, H., Tunstall, M.: Round reduction using faults. In: Proceedings of the 2nd Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC 2005), pp. 13–24 (2005) 10. Defense Science Board Task Force. High performance microchip supply. Technical report, Defense Science Board (DSB), Washington, DC, USA (February 2005), http://www.acq.osd.mil/dsb/reports/ADA435563.pdf 11. Dusart, P., Letourneux, G., Vivolo, O.: Differential fault analysis on A.E.S. In: Zhou, J., Yung, M., Han, Y. (eds.) ACNS 2003. LNCS, vol. 2846, pp. 293–306. Springer, Heidelberg (2003) 12. Gladman, B.R.: A specification for Rijndael, the AES algorithm. Algorithm specification (2007), http://gladman.plushost.co.uk/oldsite/cryptography technology/ rijndael/aes.spec.v316.pdf 13. Großsch¨ adl, J., Oswald, E., Page, D., Tunstall, M.: Side-channel analysis of cryptographic software via early-terminating multiplications. In: Lee, D., Hong, S. (eds.) ICISC 2009. LNCS, vol. 5984, pp. 176–192. Springer, Heidelberg (2010) 14. Jin, Y., Kupp, N., Makris, Y.: Experiences in hardware Trojan design and implementation. In: Proceedings of the 2nd IEEE International Workshop on HardwareOriented Security and Trust (HOST 2009), pp. 50–57. IEEE Computer Society Press, Los Alamitos (2009) 15. Jin, Y., Makris, Y.: Hardware Trojans in wireless cryptographic ICs. IEEE Design and Test of Computers 27(1), 26–35 (2010)

270

J.-F. Gallais et al.

16. King, S.T., Tucek, J., Cozzie, A., Grier, C., Jiang, W., Zhou, Y.: Designing and implementing malicious hardware. In: Proceedings of the 1st USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET 2008), pp. 1–8. USENIX Association (2008) 17. Lin, L., Burleson, W.P., Paar, C.: MOLES: Malicious off-chip leakage enabled by side-channels. In: Proceedings of the 27th IEEE/ACM International Conference on Computer-Aided Design (ICCAD 2009), pp. 117–122. ACM Press, New York (2009) 18. Lin, L., Kasper, M., G¨ uneysu, T., Paar, C., Burleson, W.P.: Trojan side-channels: Lightweight hardware trojans through side-channel engineering. In: Clavier, C., Gaj, K. (eds.) CHES 2009. LNCS, vol. 5747, pp. 382–395. Springer, Heidelberg (2009) 19. Mangard, S., Oswald, E., Popp, T.: Power Analysis Attacks: Revealing the Secrets of Smart Cards. Springer, Heidelberg (2007) 20. Pohlig, S.C., Hellman, M.E.: An improved algorithm for computing logarithms over GF (p) and its cryptographic significance. IEEE Transactions on Information Theory 24(1), 106–110 (1978) 21. Quisquater, J.-J., Piret, G.: A differential fault attack technique against SPN structures, with application to the AES and KHAZAD. In: Walter, C.D., Ko¸c, C ¸ .K., Paar, C. (eds.) CHES 2003. LNCS, vol. 2779, pp. 77–88. Springer, Heidelberg (2003) 22. Rivest, R.L., Shamir, A., Adleman, L.M.: A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM 21(2), 120–126 (1978) 23. Schmidt, J.-M., Hutter, M., Plos, T.: Optical fault attacks on AES: A threat in violet. In: Proceedings of the 6th International Workshop on Fault Diagnosis and Tolerance in Cryptography (FDT 2009), pp. 13–22. IEEE Computer Society Press, Los Alamitos (2009) 24. Schmidt, J.-M., Medwed, M.: A fault attack on ECDSA. In: Proceedings of the 6th International Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC 2009), pp. 93–99. IEEE Computer Society Press, Los Alamitos (2009) 25. Tehranipoor, M., Koushanfar, F.: A survey of hardware Trojan taxonomy and detection. IEEE Design and Test of Computers 27(1), 10–25 (2010) 26. Trusted Computing Group. TCG Specification Architecture Overview (Revision 1.2) (2004), https://www.trustedcomputinggroup.org/groups/ TCG 1 0 Architecture Overview.pdf 27. Tunstall, M., Mukhopadhyay, D.: Differential fault analysis of the Advanced Encryption Standard using a single fault. Cryptology ePrint Archive, Report 2009/575 (2009), http://www.eprint.iacr.org 28. Waksman, A., Sethumadhavan, S.: Tamper evident microprocessors. In: Proceedings of the 31st IEEE Symposium on Security and Privacy (S&P 2010), pp. 173–188. IEEE Computer Society Press, Los Alamitos (2010) 29. Wolff, F.G., Papachristou, C.A., Bhunia, S.K., Chakraborty, R.S.: Towards Trojanfree trusted ICs: Problem analysis and detection scheme. In: Proceedings of the 11th Conference on Design, Automation and Test in Europe (DATE 2008), pp. 1362–1365. IEEE Computer Society Press, Los Alamitos (2008) 30. Young, A., Yung, M.: The dark side of “Black-box” cryptography, or: Should we trust capstone? In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 89–103. Springer, Heidelberg (1996)

An Emerging Threat: Eve Meets a Robot (Work-in-Progress) Kahraman D. Akdemir, Deniz Karakoyunlu, Taskin Padir, and Berk Sunar Department of Electrical and Computer Engineering, Worcester Polytechnic Institute, 100 Institute Road, Worcester, MA 01609, USA {kahraman,deniz,tpadir,sunar}@wpi.edu

Abstract. In this work, we study the emerging security threats in a quickly proliferating field: robotics. The next generation robots embody most of the networking and computing components we normally use for everyday computing. Thus, the next generation robots virtually inherit all of the security weaknesses we are struggling with today. To make things worse, vulnerabilities in robots are much more significant, as they physically interact with their surroundings which include human beings. In this paper, we first provide a classification of potential physical attacks on robots. In addition, we outline a concrete active attack and propose a countermeasure. Keywords: Side-channel attacks, fault injection, information leakage, countermeasures, robotics.

1

Introduction

Since the development of the first modern operating systems and computer networks we have witnessed the discovery of numerous vulnerabilities and security issues. We are accustomed to attacks targeting platforms at the operating system, network or at the implementation levels. For example, viruses, worms, malware, privilege escalation attacks, denial-of-service attacks, intrusion, SQL injection, re-routing, cold-boot attacks, side-channel attacks, manufacturer attacks etc. are commonly known types of attacks. These attacks target essentially all components of the greater network, ranging from high end platforms such as desktops, laptops, pay-tv-boxes, gaming platforms, to low-end devices such as netbooks, cell-phones, RFIDs, and internet enabled embedded devices. What is common to all of these platforms is that the harm done in an attack is isolated to loss of service or of digital data, or financial loss or to the violation of the individual’s privacy. Only on rare occasions such attacks may escalate to a life threatening situation. For instance, a number of such attacks have appeared recently that target medical devices (e.g., see [14]). While such attacks are fairly limited, these studies have drawn a significant level of attention from both researchers and the public primarily due to the direct harm inflicted on humans. L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 271–289, 2011. c Springer-Verlag Berlin Heidelberg 2011 

272

K.D. Akdemir et al.

There is a new emerging technology, however, that pushes the threat to a whole new level. The quick proliferation of robotics, may have severe security consequences. The vulnerabilities posed by robots are much more significant as they interact in many more and unpredictable ways with their surroundings including human beings. For instance, even a simple denial of service attack on the Wi-Fi connection of a walk assisting robot (such as HAL5 of University of Tsukuba, Japan [51]) may result in loss of balance and harm the disabled person it is assisting. To make things worse, the next generation robots embody essentially all of the available networking and computing components we normally use for everyday computing. Therefore, robots inherit virtually all security vulnerabilities that we currently see in computer networks.1 Furthermore, the electromechanical parts of robots which enable them to perform sophisticated physical tasks open the door to greater harm and even physical injury. In summary, we have a newly emerging field that carries all the vulnerabilities of traditional hardware and software components that is used in applications where an attack has direct physical consequences. A valid question at this point would be whether we can use the standard countermeasures that were developed in the last decade to prevent physical attacks on cryptographic devices to protect robots as well. The problem is that robots are put together for an inherently different purpose than cryptographic devices. Robots sense and accordingly interact with their surrounding. This differentiates robots from other types of embedded applications where the input to the computation is restricted to the data input. In cryptographic applications any type of input other than the data channel is severely restricted. In robots, the sources of information on which decisions formed are many and diverse in nature. Therefore, the existing countermeasures will not provide adequate protection against physical attacks targeting robots. While the severity of the threat is clear, compared to other computation platforms, the level of deployment of robots in non-industrial applications is relatively low. However, non-industrial robotics is still a young field, and virtually all market forecasts predict a significant increase in the deployments over the next decade. Much of the increase of the robotics volume is expected to be in emergency and rescue, in the health and elderly-care, in the leisure and entertainment market and in the defense industry [60]. The same reference projects that the leisure and entertainment robotics installations to increase by over 3 times in only 3 years (2008-2011). More specifically, according to data provided by the U.S. Census Bureau, MetLife, ABI Research and other specialists, Gecko Systems International Corp. in a somewhat optimistic study projects the growth of the elder-care robot market to steadily grow to reach $83 Billion in 2014. The growth expectancy can also be gauged from research spending. According to a recent congressional report, the rest of the world led by Japan, Korea, and the European Union, has recognized the irrefutable need to advance robotics technology and have made research investment commitments totaling over $1 billion 1

From a purely security research standpoint robots provide the perfect micro-universe of all computing and communication protocols to study system security.

An Emerging Threat: Eve Meets a Robot

273

[11]. Given the severity of the threat and the tremendous growth projections of robot deployments, it becomes essential to investigate the notions of security and trust in this new field.

2

What is a Robot?

Over the past decade, robotics engineering has evolved to become a rather diverse field covering a wide spectrum of applications. With advances in enabling technologies, i.e. electronics, and computers, and components such as sensors and actuators, intelligent vehicles are now capable of assisting human drivers in urban environments, vacuum cleaning, mowing lawns, assisting the elderly and performing medical rehabilitation. Robots are becoming a common household appliance. Table 1 shows a summary of robot categories and cites some of their applications. Despite the fact that the number of applications are growing steadily, this field is still relatively young. Therefore manufacturers have not seriously considered any security and privacy weaknesses yet. When we look inside an autonomous robot we see essentially a micro-universe of all computational devices. Figure 1 shows the components of the humanoid robot Nao designed and manufactured by Aldebaran Robotics [2]. It is equipped with a 500 MHz AMD CPU, Wi-Fi and Ethernet hardware, and runs a Linux operating system. Moreover, NAO’s limbs and hands have 25 degrees of freedom, each equipped with a dedicated microcontroller, numerous sensors and actuators. To interact with its surrounding Nao has stereo vision, and voice recognition and synthesis firmware. With each joint being controlled by a dedicated microcontroller this 23 inch tall robot houses more than two dozen microcontrollers. Given all the components built into this robot it makes a perfect testbed for studying embedded system security problems. As will be discussed in the next section, these standard robotics components are susceptible to attacks. Table 1. Classification of Robots Categories

Applications Walk-aid robots for elderly and handicapped Medical and Rehabilitation people, high precision micro-surgery robots, drug delivery micro-robots Household Utility robots such as vacuum cleaners, lawn mowers Unmanned vehicles, driver assistance robots such Automative as emergency stop assistant, adaptive cruise control, brake assist, pre-crash system, automatic parking system Security and Privacy Robotic video security and surveillance systems Public safety Search and rescue robots and sensor systems Unmanned aircraft systems, unmanned underwater Military vehicles, infiltration, surveillance and combat robots

274

K.D. Akdemir et al.

Fig. 1. The embedded components and sensors on Nao [2]

3

Security of Robotics

So far there has been only a few studies focusing on the security of robots. In [13], the authors survey several security vulnerabilities in household robots. However, the study is limited to the wireless network layer. Similarly, [45] concentrates only on vulnerabilities in wireless communication security. In [19], the authors focus on security issues related to swarm robotics; yet they do not cover sidechannel based physical attacks. In contrast, in this paper we are interested in physical attacks on robots. More specifically we are interested in – side-channel information leakage and – susceptibility of robots to active attacks. The idea of deducing secret information from cryptographic chips through physical channels, i.e. side-channel analysis (SCA), was first proposed by Paul Kocher in 1996 [28,29] and further developed in [49,15,37,9,10,3,4,61,54]. SCA can be broadly classified into passive and active attacks. In passive side-channel attacks, the adversary observes implementation specific characteristics of the device to reveal internal secrets. Power and timing analysis are the most popular passive attacks. These attacks exploit the correlation between the internal secret and the power usage or execution time profiles. Electromagnetic (EM) emanation, temperature, and sound are other types of information sources for passive attacks. Compared to active side-channel attacks, passive attacks are harder to detect, because the attacker monitors the behavior of the system, and does not actively interact with it.

An Emerging Threat: Eve Meets a Robot

275

Boneh et al. [8] demonstrated that active fault injection attacks are also extremely effective in terms of breaking otherwise impervious cryptographic schemes. The main idea of active attacks is to inject faults into a device through side-channels. Thereby the device under attack is forced into a rogue state resulting in an unintended operation. Such faulty executions may be used to gain access to the secret information, such as the cryptographic key. Typically active faults are harder to introduce, but they tend to be more effective than passive attacks. Variations in the external voltage lines, external clock transients, temperature variations, and bit-flips using optical laser beams [55,52] are some of the many active fault attack techniques found in the literature. More information about side-channel attacks can be found in the survey papers of Bar-El et al. [6] and Naccache [44]. To see how side-channel attacks relate to robots all we have to remember is that robots are electro-mechanical devices. The electrical components carry out computations, and the mechanical parts carry out the movements, both resulting in side-channel leakage about internal operations of a robot. Due to the limited observable physical properties of integrated circuits (ICs), an adversary needs high-precision measurement equipments, and performs a large number of measurements usually followed by an intensive post-processing step in order to deduce useful information. In contrast, mechanical processes are macro operations with higher orders of physical information leakage. Hence, it is much easier to obtain information from a robot’s physical channels than from those of cryptographic chips. We should point out however that for most interesting applications it becomes difficult to get physically close to the robot. Therefore, the most viable side-channel attacks on robots are those that can be mounted at a distance i.e. EM leakage [31] and acoustic attacks [54] and attacks on the ultrasound and infrared sensor channels we introduce in this paper. For example, just from the sound of a robot, we can gather information about the position, speed, and direction of the robot. Similarly the EM fingerprint of a health-care robot may leak personal information about the patient it is treating, e.g. type and frequency of medicine use, vital information about the patient such as blood pressure and insulin levels, etc. Passive side-channel attacks do not only lead to privacy violations but can also be used to gain unfair advantage over competitors in accessing shared resources. For instance, in robot assisted driving a robot may deduce the planned actions of the other cars through the EM leakage and monopolize the road. A similar attack may be run in autonomous robot competitions. This scenario is quite plausible since mechanical motors are typically run by pulse width modulated electrical signals which leak via the EM channel. Hence, a robot may deduce another robot’s action (before the action is executed) at a distance, using leakage rather than using the intended visual channel or the standard arbitration algorithm. Similarly, the EM leakage may be used to predict the intention and tactics of robot swarms. Furthermore, robotic ultrasound and infrared sensors typically work by sending physical signals and observing their reflections. Even if the signal coming from a sensor does not carry

276

K.D. Akdemir et al.

a lot of information, they could still assist the attacker to find out the location, velocity, and target the robot. Passive attacks allow an attacker to collect leakage information. In contrast, active attacks may directly alter the robots behavior. To mount a successful fault attack on a traditional embedded system, one normally needs to circumvent the shielding mechanism. Meanwhile, robots by definition are physical devices that constantly sense characteristics of their surroundings, and plan actions based on a built perception of their environment. Therefore, active physical attacks can even be more effective on robots, since robots by design interact with their environment, and act autonomously. For example, consider an intelligent ground vehicle whose objective is to autonomously drive in highly unstructured and dynamic urban environments. This will require effective path planning and navigation, static and dynamic obstacle avoidance, self-localization and 3D world mapping algorithms. Robots can sense their environment using a number of devices: stereo vision cameras, 2D LIDAR (Light Detection and Ranging) sensors, and additional ultrasonic and/or infrared rangefinders, GPS (Global Positioning System) receivers, an IMU (Inertial Measurement Unit), and wheel encoder feedback. This creates numerous opportunities for active attacks. For instance, an attacker could just keep sending the robot false signals in order to disorient it or even restrict it to within a virtual fence. Robots are built with safety measures to ensure that the sensor and control system are reliable in detecting and tracking dynamic objects surrounding robot. However, these safety measures are against non-malicious faults, and are usually not equipped with adversary detection and prevention mechanisms. Once a robot is manufactured and tested against natural errors, it is expected to conform its design specifications unless there is a mechanical or electrical failure. On the other hand, side-channel attacks pose a significant security risk for robots and autonomous applications. The possible side-channel attacks on robots and their countermeasures are yet to be identified and understood. In the following we present several possible side-channel attack scenarios: – A prominent application for robots is assisting elderly, sick or disabled people. Robots of this type are in close contact with people, and when they malfunction the results can be a disaster. An active physical attack that will confuse the robot can cause injuries to the person the robot is assisting. For example, robots that assist handicapped people for walking are already sold on the market. Attacks on these robots, even a denial of service attack, could lead to injuries. – Electricity carried through a conductor will produce a magnetic field that varies with current that is passing through the conductor. The changes in this magnetic field will induce another electric field. This principle is actually used in hall effect sensors for proximity switching, positioning, speed detection, and current sensing applications, which allows a low cost feedback and monitoring alternative to slow image and video processing. Using an antenna and a receiver, an adversary can also monitor the activities of a robot from the EM emanations of its electronic units. Moreover, in a competitive

An Emerging Threat: Eve Meets a Robot

277

environment, if the attacker can deduce information about the control signals of robot, he can anticipate its moves, and act in advance. – Car manufacturers are developing several autonomous systems for their new models such as emergency stop assistants, adaptive cruise controls, brake assistance systems, pre-crash systems, automatic parking systems, etc. All of these systems are susceptible to active side-channel attacks which could result in car accidents. Furthermore, a GPS based vehicle navigation or crash avoidance system could give information about the location of the vehicle, which will compromise the privacy of the passengers. A group of Cornell researchers have shown that spoofing GPS receivers is also possible [23]. Using false GPS signals an adversary could route the vehicle to a specific location, e.g. into a trap. – Robotic video security and surveillance systems allow people to watch their valuables in their homes via devices that can access the Internet. This security measure unintentionally creates a new channel that may be exploited to attack the facility intended to be protected. If an attacker can tap into the communication line, he will also be able to keep a close eye on the facility. Moreover, an active attacker could cause robot’s sensors to malfunction. For example if robot is sensing motions, a fake intrusion that will take robot’s attention, but not high enough to cause an alarm could keep robot busy. Another example would be using jamming signals to decrease or diminish the sensing capability of the robot. If the robot is not programmed to be alarmed in such a case, it will continue monitoring the house without really detecting intrusions. This will result in a false sense of security for the owner of the house.

4

A Simple Active Attack and a Countermeasure

In order to demonstrate the vulnerability of ultrasound range sensors against active fault attacks, we conducted a preliminary experiment where we implemented a successful attack on an actual robot. As proof of concept, we built the simple robot shown in Figure 2 which is using the VEX Robotic Design System [58]. As seen in the figure, there are two motors that are controlled using pulse width modulation (PWM) attached to the rear tires. In addition, we added a VEX ultrasonic range finding module [59] to the front of our robot. This is a proximity sensor that is used to measure the distance to an obstacle by measuring the time it takes to receive back a transmitted ultrasound wave. The ultrasound device can measure distances ranging from 3 inches to 10 feet. The transmitter produces a 250µs ultrasonic pulse with a frequency of 40kHz. Once the echo is received, the microcontoller on our robot computes the round-trip delay and the distance from the obstacle. We programmed our robot to turn left when it is 5 inches away from an obstacle. It is also important to mention that the pulse generation and distance measurement are implemented once every 100ms, which provides sufficient resolution. One possible attack against this sensor is to send a similar ultrasonic pulse and cause the robot to turn left even when there are no obstacles around. To

278

K.D. Akdemir et al.

(a) Front view

(b) Side view

Fig. 2. Simple robot we used in our experiments

implement this attack, we used another identical ultrasonic range finder module and another VEX controller which are shown in Figure 3. Basically, by imitating the reflection which would normally be received from an obstacle, we managed to trick the robot to take left turns at various distances. One problem we encountered while conducting this attack was to induce our fault injection within the correct time interval. When checking for a distance of 5 inches, the transmitted sound wave is expected to return in (5 × 2)/(1135 × 12) = 0.73ms, where the speed of sound is 1135 ft/s. In other words, the naive attack we implemented initially did not work because we could not hit this time interval. The main reason behind this is that our ultrasound transmitter was generating pulses every 100 ms as seen in Figure 4(a), where the pulse width is approximately 12µs. As a result, the probability of the ultrasound wave generated by the transmitter arriving to the robot within this 0.73 ms interval was less than 1%. To solve this problem, we tapped into the control signal that triggers the pulse generation of the attack sensor. Next, we applied the control signal shown in Figure 4(a) using a function generator. By this, we increased the resolution of the generated pulses of the attack sensor. We tested the new attack sensor and observed that our attack was successful in introducing faulty distance readings to the robot. Using this attack, we achieved to trick the robot to take left turns any time we wanted. There are many ways to avoid such an attack. As a first solution, we developed a countermeasure which transmits two ultrasound (IR) pulses and checking both

Fig. 3. Ultrasound attack setup; transmitter (left) inject faults into the ultrasound proximity sensor (right)

An Emerging Threat: Eve Meets a Robot

279

v d

Obstacle

R .t r Transmitted Received

100ms

2d vs

2(d−VRtr) vs Required Rt r (1−v/vs )

12us

(a) Original (top) and Hacked (bottom) enables.

(b) Proposed sensor security scheme

Fig. 4. Attack and Protection details

of the received echoes to determine if there is actually an obstacle ahead of the robot. The important point is that the second pulse is transmitted after some random time interval, where the random mask is generated using a pseudo random number generator (PRNG) located on the robot. This protocol can be formalized using the following variables. R is the pseudo random number (kbits), v is the speed of the robot, vs is the speed of the sound (light), d is the searched distance where a specific action will be taken (turning left in our case), d is the distance error tolerance which is the measure of how much our robot can deviate from the searched distance d, and finally tr is the pulse resolution that is supported by the micro-controller on the robot. Protocol 1. (Randomized Pulse Redundancy) 1. Robot sends the first sensor pulse. 2. It generates a random number R < 2k . 3. It waits for Rtr seconds and sends the second pulse. 4. After receiving the first echo, it waits for the second echo. 5. If the second echo arrives before Rtr (1 − v/vs ) seconds, robot halts/stops. 6. Else if it receives the second echo after exactly Rtr (1 − v/vs ) seconds, received a fault-free sensor data. So, it implements the function it is programmed to use. 7. Else if the second echo arrives later than Rtr (1 − v/vs ) seconds after the first echo, repeat steps 1 through 6 again. Assume that our robot transmitted two ultrasound (IR) pulses with a time distance of Rtr , as shown in Figure 4(b). In this case, (assuming our robot has a distance of exactly d to an obstacle) the first pulse will return after 2d/vs seconds after the first transmitted pulse (assuming v/vs ≈ 0). In addition, since the robot is still moving towards the obstacle, the second pulse will return (d − vRtr )/vs seconds after the second pulse is transmitted. As a result, the required pulse train that will cause the robot to take action will be as shown in Figure 4(b).

280

K.D. Akdemir et al.

Note that Rtr − 2d/vs + 2d/vs − 2vRtr /vs =Rtr (1 − 2v/vs ) ≈ Rtr . Essentially, the attacker needs to generate this exact pulse shape in order to trick the robot into thinking that there is an obstacle ahead. Note that in this equation, the attacker will not be able to determine the value of the random value R. Hence, the success probability of the attacker will be 1/2k . In other words, depending on the size of the random number space, this protection scheme detects errors with exponentially high probability. This countermeasure technique can be summarized as shown in the following protocol. It is also important to note that there is a trade-off between the security of the sensor and the distance error tolerance variable d . The distance error tolerance is a measure of how much the robot passes the searched distance before realizing that there is an obstacle ahead. The maximum possible value of d is 2k tr v, where we use 2k to represent the largest possible random value R. As can be observed, the variable k determines both the security level and the error distance margin of the sensor. Since the value of tr (100ms) is relatively large in the ultrasound sensor used in our experiments, this solution causes a large distance error margin. For example, for a 6-bit random space and robot speed of 0.5m/s, the error margin caused by our scheme becomes d =26 × 100 × 10−3 × 0.5=3.2m. This may not be acceptable for small d values. However, note that for a sensor that has higher pulse generation resolution, this method can provide high security with acceptable distance error margin. For example, if tr =1µs, the error becomes d =26 ×10−6 ×0.5=32µm for the same case. In this case, successful fault injection probability is 1/64. As a result, by increasing the value of k, it is possible to exponentially decrease this probability. For example, for this last case, if our robot can tolerate an error distance margin of 1cm, then we can use a random space of 14-bits. This decreases the attacker’s success probability to 2−14 .

5

Active Attacks on Robots

In this module, we discuss active attack techniques targeting the sensor technologies commonly used in robots. An autonomous robot decides on its action based on inputs received from these sensors. By attacking the sensors, the adversary can cause robot suicides and vandalism [13], denial of service, and even can gain full control of the robot. Ultrasound Sensors The first sensor type that is commonly used by robots is ultrasound sensors. Ultrasound sensors are mainly used for range finding purposes. As demonstrated by the simple active attack in Section 4 ultrasound sensors may be attacked to falsify readings and potentially control the motions of a robot from a distance. An advanced attacker, could imprison a surveillance robot in an electronic jail with a slightly more elaborate attack that uses multiple transmitters. Similarly, household robots such as Roomba can be led to the stairs and be broken. In addition, cars that use such sensors for park assistance or for automatic parking can be forced to crash. Even further, an assistant robot that leads a blind person

An Emerging Threat: Eve Meets a Robot

281

securely through a pedestrian walkway can be similarly attacked if the robot is using an ultrasound sensor. Infrared Sensors Another common sensor type that could be vulnerable in an adversarial setting is infrared (IR) sensors which are utilized in high-tech robots. These IR devices are also used as proximity sensors similar to ultrasound sensors. Instead of using ultrasound waves, IR sensors use infrared light which is not visible to the human eye. Sharp GP2Y0A21YK [20] infrared proximity sensor is one of these devices where a range of 10 cm-80 cm can be measured. Since distance measurements are implemented in a similar manner, the attack scenarios we outlined for ultrasound devices should apply to IR sensors as well. Robots can also use IR for motion detection. In order to achieve this, special pyroelectric devices made of crystalline materials are used. These devices can measure IR fluctuations using special lenses which are used to focus infrared signals. The parallax passive IR (PIR) sensor [21] is a good example of these devices. In their current form, these devices could be vulnerable against active attacks, i.e. an adversary could cause faulty readings on these sensors using external IR sources. For example, security surveillance robots that use these sensors in order to detect intruders can be tricked into generating false signals. Another potential application of IR motion sensors in the future could be the smart traffic lights. These lights detect the motion of the cars at intersections and accordingly minimize the waiting time of the drivers at the traffic lights. An adversary could exploit these sensors to either gain unfair advantage over other drivers or to cause accidents. Similarly, future robots could also utilize infrared heat sensors in order to measure the amount of heat in the surrounding environment. VEX infrared flame sensor [22] is one of these devices. These sensors could be used by fire detection and rescue robots in the future. Furthermore, it is envisioned that in the future, similar sensors will be used by unmanned flying robots to detect forest fires. In both cases, an attacker could introduce faulty readings into these devices and cause serious harm. Another possible application of the IR sensors is line tracking. This is one of the most common methods robots use in order to follow a specific route. VEX line follower [38] is a good example of these devices. Basically, these devices shine an infrared light on the surface. The sensor than picks up the reflected infrared radiation. Depending on the intensity of the received light, the sensor decides if the surface is dark or light. By using a few of these sensors next to each other, a robot can track a line on the surface. For example, robots in any warehouse or supermarket could carry the goods by following specific patterns on the floor. In addition, unmanned aircrafts could use this type of a mechanism in order to taxi at the airports. Robot waiters in restaurants could follow different colored lines to serve the food to the correct tables. All of these robots are vulnerable to active attacks which target their IR line tracking system implemented simply by shining an IR laser on the surface right below these sensors.

282

K.D. Akdemir et al.

Hall Effect Sensors Hall effect sensors that are used by robots as part of their encoder circuits could also be a target for active attacks. These sensors detect fluctuations in magnetic field and are utilized for position and motion sensing and wheel rotation sensing. Using this feedback information, the controller on the robot corrects its motion or decides on future actions. These sensors could be attacked using EM fault injection attacks. Active EM attacks are proven to be to cause bit-flips in microcontrollers and SRAM memory cells [48,53] to reveal secrets cryptographic devices. A similar attack scenario could be applied to the Hall effect sensors on robots. For example, the attacker could alter the feedback signals by interfering with the magnetic fields associated with these sensors. All that he needs to do is to generate an EM pulse with similar wavelength/frequency of the Hall effect sensors.

6

Information Leakage Attacks on Robots

In this section, we identify information leakage channels in robots and investigate possible sources of privacy violation. Note that besides privacy violation, information leakage may also be exploited to gain unfair advantage such as in accessing a shared resource in a group setting. EM Emanations The first passive side-channel we discuss on robots is EM emanations. During the operation of electronic circuits (i.e. ICs, sensors, connection cables, etc.), they leak EM waves at various frequencies. An attacker could use this leakage to recover secret internal to the device. For example, Kuhn showed that by collecting EM waves leaked from the monitor cables of computers, the displayed data on a CRT monitor can be reconstructed by an adversary [30,31,32] at a distance up to 30 feet even through walls. Furthermore, EM emanations picked up by a simple coil can recover secret keys from cryptographic devices such as RFIDs and FPGAs [41]. First of all, EM emanations emitted from the actuators of a robot to deduce its position and planned motion. DC motors commonly used in robots are controlled by a pulse-width-modulated signal. Note that each pulse is transferred into the frequency domain as a sync function. As a result, it may be possible to receive these pulses using a finely tuned antenna, process them, and estimate the motion of targeted robot. Using this method, an attacker or a robot can follow its opponents without any visual clues even behind walls. In addition, most high-tech robots have a built-in CCD or CMOS camera as a visual sensor. These cameras can be used for complex sensing tasks such as pattern recognition. While the captured frames are being sent to the microcontroller on the robot, the transmission lines do leak side-channel information through EM channels [31]. By exploiting this leakage, an attacker can recover

An Emerging Threat: Eve Meets a Robot

283

what the robot has captured. Any robot that has a camera attached to it will be vulnerable against this attack scenario. For example, security surveillance robots that regularly take pictures of inside a house, will be susceptible to this sort of attack. Acoustic Emanations Another information leakage channel on robots is the acoustic emanations. These attacks are very similar to EM attacks of Section 6, yet uses acoustic leakage instead of EM leakage. Acoustic side-channel attacks have already been proven to be effective in extracting the executed instructions on CPUs [54]. In another attack the acoustic leakage from keyboards is used to recover key strokes and passwords at a distance and through walls [5,62]. We propose to explore similar acoustic leakage from robots. We believe devices such as micro-electromechanical-systems (MEMS) accelerometers and gyros are especially vulnerable since acoustic sound waves are generated by their moving parts. As a result, position and acceleration information associated with a robot may be compromised at a distance using this kind of an attack. Another possible source of acoustic side-channels we propose to investigate is the motor/servo system on the robot. By listening to the sound of these motion based devices, the attacker can induce information about the motion characteristics of a robot. This information potentially gives the attacker an opportunity to estimate and track the motion characteristics of the robot under attack. Table 2. Robot components and vulnerabilities against side-channel attacks. (= vulnerable, ✕= not vulnerable). Component Active Attacks Passive Attacks Ultrasound proximity sensors  ✕ Optical/Infrared proximity sensors  ✕ Optical/Infrared heat sensors  ✕ Optical/Infrared motion sensors  ✕ Line-tracking sensors  ✕ Servos/Motors ✕  Gyros/Accelerometers ✕  Cameras ✕  GPS   Hall Effect sensors  

7

Countermeasures

In Table 2 we summarize the vulnerability of different components of a robot against active and passive side-channel attacks as discussed in Sections 5 and 6. In this section, we will investigate methods and protocols to protect robots against these attacks.

284

K.D. Akdemir et al.

Countermeasures Against Active Attacks As the first part of this section, we investigate countermeasures against active fault injection attacks that are discussed in Section 5. Securing sensors against these attacks is an important and difficult problem. Robots that have been deployed so far assume the integrity of the sensed data. Similarly leakage is almost always overlooked. However, as discussed in detail in the first two modules this will not be the case when there is an intelligent adversary. Hence, having trustworthy sensors and secure sensing protocols is crucial for the trustworthiness of all the robotic systems. In this modules, we will briefly discuss some of these solutions. Randomized pulse redundancy: This approach is mainly the countermeasure we developed to protect against the proximity sensor attack in Section 4. Note that this exact same method can be used against infrared sensor attacks that are discussed in Section 5. One advantage of this scheme is its simplicity. This technique does not require any form of data encoding/decoding. It is mainly based on randomized delays. Sensor redundancy: Another possible approach is applying sensor redundancy. Temporal and hardware redundancy are some of the simple methods proposed in the literature against active attacks. Double-Data-Rate (DDR) computation [39,40], dual-rail encoding [12,33] and concurrent error detection (CED) [7,27,16,43] are some of these solutions. These solutions mainly depend on repeating the computation of a function and checking to see if the results match. A mismatch points to a fault injection and appropriate measures are taken by the circuit in this case. A similar approach can be applied for sensor security as well. Basically, by increasing the number of sensors that check for the same environmental variable, we can decrease the attacker’s success rate. In this case, the attacker has to fool all of the sensors simultaneously. If the results obtained by the sensors do not match, the robot will understand that there is a fault being injected and behave accordingly. However, this solution does not provide a high level of security especially when the attacker is an advanced one. Time stamp: Using time stamp information is another possible countermeasure against active fault attacks. In this method, a time stamp information is attached to the sensor information that is transmitted. The robot will essentially check the time stamp information of the received echoes to determine the authenticity of the received sensor data. Data coding: The application of fault detection techniques (which are normally used to protect cryptographic circuits) to protect signals generated by active sensors of a robot is another potential solution. Linear coding is one of these methods. This technique is already proven to be effective in protecting the finite state machines of cryptographic hardware against fault attacks [17]. We propose applying a similar approach to secure sensor data. In this approach, sensor data will be encoded using a linear coding scheme. In this case, every time the robot receives sensor information, it can check if the received data is a valid codeword.

An Emerging Threat: Eve Meets a Robot

285

Note that in this solution, the transmitted and received pulses will have to carry information. Essentially, a valid codeword represents a fault-free sensor data and an invalid codeword indicates an adversarial fault injection. Nonlinear codes could also be used in a similar fashion. Non-linear robust error detection codes [26], provide one of the most effective defense mechanism against active fault attacks. Potential applications of this coding scheme, e.g. protection of the Advanced Encryption Standard (AES) datapath, finite state machines are described in [36,35,25,24,34,1]. Countermeasures Against Information Leakage Attacks One possible solution against passive side-channel attacks is EM shielding. The shielding can be applied to the entire robot or to individual components. In addition, existing countermeasures proposed to prevent leakage from cryptographic devices can be used in the robotics setting. In order to avoid simple power analysis and timing attacks, side-channel attack aware algorithms that implement operations in a data independent manner were proposed. Furthermore, several classes of countermeasures such as using noise generators to confuse attackers by adding random noise to the power signatures [47], feeding idle datapath units with random data to provide a more uniform data profile [18], using masking techniques [42,46], and using power balanced IC libraries that have data independent power consumption characteristics [56,57,50] are the main approaches used against differential power analysis. Similar approaches can be used against acoustic side-channel attacks. For instance, by generating random acoustic sound waves in a similar frequency range as the acoustic waves transmitted from the components on the robot, acoustic side-channel information can be hidden.

8

Conclusion

It can be argued that the last mile in computing is the interaction of physical devices with humans. This gap is being bridged with robots and devices that directly interact with humans. On the robots side secure sensing technologies are crucial to gather authentic information from the environment. From the human perspective it is absolutely essential that the physical devices around us including robots are trustworthy. This paper aims to illustrate this gap.

References 1. Akdemir, K.D., Hammouri, G., Sunar, B.: Non-linear Error Detection for Finite State Machines. In: Youm, H.Y., Yung, M. (eds.) WISA 2009. LNCS, vol. 5932, pp. 226–238. Springer, Heidelberg (2009) 2. Aldebaran Robotics, http://www.aldebaran-robotics.com/en/ 3. Anderson, R., Kuhn, M.: Tamper Resistance–a Cautionary Note. In: The Second USENIX Workshop on Electronic Commerce, Oakland, CA, USA, vol. 2, pp. 1–11 (1996)

286

K.D. Akdemir et al.

4. Anderson, R., Kuhn, M.: Low Cost Attacks on Tamper Resistant Devices. In: Christianson, B., Lomas, M. (eds.) Security Protocols 1997. LNCS, vol. 1361, pp. 125–136. Springer, Heidelberg (1998) 5. Asonov, D., Agrawal, R.: Keyboard acoustic emanations. In: IEEE Symposium on Security and Privacy, pp. 3–11. Citeseer (2004) 6. Bar-El, H., Choukri, H., Naccache, D., Tunstall, M., Whelan, C.: The sorcerer’s apprentice guide to fault attacks. Proceedings of the IEEE 94, 370–382 (2006) 7. Bertoni, G., Breveglieri, L., Koren, I., Maistri, P., Piuri, V.: Error analysis and detection procedures for a hardware implementation of the advanced encryption standard. IEEE Transactions on Computers 52(4), 492–505 (2003) 8. Boneh, D., DeMillo, R., Lipton, R.: On the importance of checking cryptographic protocols for faults. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 37–51. Springer, Heidelberg (1997) 9. Chari, S., Rao, J., Rohatgi, P.: Template Attacks. In: Kaliski Jr., B.S., Ko¸c, C ¸ .K., Paar, C. (eds.) CHES 2002. LNCS, vol. 2523, pp. 13–28. Springer, Heidelberg (2003) 10. Clavier, C., Coron, J., Dabbous, N.: Differential Power Analysis in the Presence of Hardware Countermeasures. In: Paar, C., Ko¸c, C ¸ .K. (eds.) CHES 2000. LNCS, vol. 1965, pp. 252–263. Springer, Heidelberg (2000) 11. Computing Community Consortium, A.R.f.U.R.F.I.t.R.: (2009), http://www.us-robotics.us 12. Cunningham, P., Anderson, R., Mullins, R., Taylor, G., Moore, S.: Improving Smart Card Security Using Self-Timed Circuits. In: Proceedings of the 8th International Symposium on Asynchronus Circuits and Systems. IEEE Computer Society, Washington, DC, USA (2002) 13. Denning, T., Matuszek, C., Koscher, K., Smith, J., Kohno, T.: A Spotlight on Security and Privacy Risks with Future Household Robots: Attacks and Lessons. In: Proceedings of the 11th International Conference on Ubiquitous Computing (Ubicomp 2009), Orlando, FL, USA, pp. 105–114 (2009) 14. Fu, K.: Inside risks, reducing the risks of implantable medical devices: A prescription to improve security and privacy of pervasive health care. Communications of the ACM 52, 25–27 (2009) 15. Gandolfi, K., Mourtel, C., Olivier, F.: Electromagnetic Analysis: Concrete Results. In: Ko¸c, C ¸ .K., Naccache, D., Paar, C. (eds.) CHES 2001. LNCS, vol. 2162, pp. 251–261. Springer, Heidelberg (2001) 16. Gaubatz, G., Sunar, B.: Robust finite field arithmetic for fault-tolerant public-key cryptography. In: Breveglieri, L., Koren, I. (eds.) FDTC 2006. LNCS, vol. 4236, pp. 196–210. Springer, Heidelberg (2006) 17. Gaubatz, G., Sunar, B., Savas, E.: Sequential circuit design for embedded cryptographic applications resilient to adversarial faults. IEEE Transactions on Computers 57(1), 126–138 (2008) 18. G¨ urkaynak, F., Oetiker, S., Kaeslin, H., Felber, N., Fichtner, W.: Improving DPA Security by Using Globally-Asynchronous Locally-Synchronous Systems. European Solid-State Circuits Conference (ESSCIRC 2005), Grenoble, France, pp. 407–410 (2005) 19. Higgins, F., Tomlinson, A., Martin, K.: Survey on Security Challenges for Swarm Robotics. In: Fifth International Conference on Autonomic and Autonomous Systems, ICAS 2009, pp. 307–312. IEEE, Los Alamitos (2009) 20. General purpose type distance measuring sensors. SparkFun Database (December 2009),

An Emerging Threat: Eve Meets a Robot

21.

22.

23.

24.

25.

26. 27.

28.

29. 30. 31.

32. 33.

34.

35.

36.

287

http://www.sparkfun.com/datasheets/Components/GP2Y0A21YK.pdf, http://www.sparkfun.com/datasheets/Components/GP2Y0A21YK.pdf Pir sensor. Parallax Database (December 2009), http://www.parallax.com/dl/docs/prod/audiovis/pirsensor-v1.2.pdf, http://www.parallax.com/dl/docs/prod/audiovis/pirsensor-v1.2.pdf Infrared flame sensor for vex. Techno-stuff Database (December 2009), http://www.techno-stuff.com/VIRFL.htm, http://www.techno-stuff.com/VIRFL.htm Ju, A.: Researchers raise uncomfortable questions by showing how GPS navigation devices can be duped. Cornell University Chronicle (2008), http://www.news.cornell.edu/stories/Sept08/GPSSpoofing.aj.html Karpovsky, M., Kulikowski, K., Taubin, A.: Robust protection against faultinjection attacks on smart cards implementing the advanced encryption standard. In: DSN 2004: Proceedings of the 2004 International Conference on Dependable Systems and Networks, p. 93. IEEE Computer Society, Washington, DC, USA (2004) Karpovsky, M., Kulikowski, K.J., Taubin, A.: Differential fault analysis attack resistant architectures for the advanced encryption standard. In: Proc. World Computing Congress (2004) Karpovsky, M., Taubin, A.: A new class of nonlinear systematic error detecting codes. IEEE Trans. Info Theory 50(8), 1818–1820 (2004) Karri, R., Wu, K., Mishra, P., Kim, Y.: Concurrent error detection schemes for fault-based side-channel cryptanalysis of symmetric block ciphers. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 21(12), 1509–1517 (2002) Kocher, P.: Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 104–113. Springer, Heidelberg (1996) Kocher, P., Jaffe, J., Jun, B.: Differential Power Analysis. In: Wiener, M. (ed.) CRYPTO 1999. LNCS, vol. 1666, pp. 388–397. Springer, Heidelberg (1999) Kuhn, M.: Optical time-domain eavesdropping risks of CRT displays. In: IEEE Symposium on Security and Privacy, pp. 3–18. Citeseer (2002) Kuhn, M.: Electromagnetic eavesdropping risks of flat-panel displays. In: Martin, D., Serjantov, A. (eds.) PET 2004. LNCS, vol. 3424, pp. 88–107. Springer, Heidelberg (2005) Kuhn, M.: Security limits for compromising emanations. In: Rao, J.R., Sunar, B. (eds.) CHES 2005. LNCS, vol. 3659, pp. 265–279. Springer, Heidelberg (2005) Kulikowski, K., Venkataraman, V., Wang, Z., Taubin, A., Karpovsky, M.: Asynchronous balanced gates tolerant to interconnect variability. In: IEEE International Symposium on Circuits and Systems, ISCAS 2008, pp. 3190–3193 (2008) Kulikowski, K., Wang, Z., Karpovsky, M.: Comparative Analysis of Robust Fault Attack Resistant Architectures for Public and Private Cryptosystems. In: Proceedings of the 2008 5th Workshop on Fault Diagnosis and Tolerance in Cryptography, pp. 41–50. IEEE Computer Society, Washington, DC, USA (2008) Kulikowski, K., Karpovsky, M., Taubin, A.: Robust codes for fault attack resistant cryptographic hardware. In: Workshop on Fault Diagnosis and Tolerance in Cryptography (FTDC 2005) (2005) Kulikowski, K.J., Karpovsky, M.G., Taubin, A.: Fault attack resistant cryptographic hardware with uniform error detection. In: Breveglieri, L., Koren, I., Naccache, D., Seifert, J.-P. (eds.) FDTC 2006. LNCS, vol. 4236, pp. 185–195. Springer, Heidelberg (2006)

288

K.D. Akdemir et al.

37. Lee, J., Jung, S., Lim, J.: Detecting Trapdoors in Smart Cards Using Timing and Power Analysis. In: Khendek, F., Dssouli, R. (eds.) TestCom 2005. LNCS, vol. 3502, pp. 275–288. Springer, Heidelberg (2005) 38. Line follower kit. VEX Robotics Database (December 2009), http://www.vexrobotics.com/docs/inventors-guide/ line-follower-5-1-06.pdf, http://www.vexrobotics.com/docs/inventors-guide/ line-follower-5-1-06.pdf 39. Maistri, P., Leveugle, R.: Double-Data-Rate Computation as a Countermeasure against Fault Analysis. IEEE Transactions on Computers 57(11), 1528–1539 (2008) 40. Maistri, P., Vanhauwaert, P., Leveugle, R.: Evaluation of Register-Level Protection Techniques for the Advanced Encryption Standard by Multi-Level Fault Injections. In: 22nd IEEE International Symposium on Defect and Fault-Tolerance in VLSI Systems, DFT 2007, pp. 499–507 (2007) 41. Matthews, A.: Low cost attacks on smart cards: The electromagnetic side-channel. Next Generation Security Software (September 2006) 42. Messerges, T.: Securing the AES Finalists Against Power Analysis Attacks. In: Schneier, B. (ed.) FSE 2000. LNCS, vol. 1978, pp. 150–164. Springer, Heidelberg (2001) 43. Mitra, S., McCluskey, E.: Which concurrent error detection scheme to choose? In: Proc. Int. Test Conference (ITC), pp. 985–994. IEEE, IEEE Press, Los Alamitos (2000) 44. Naccache, D.: Finding faults. IEEE Security and Privacy 3(5), 61–65 (2005) 45. Noubir, G.: SWARM: Secure Wireless Ad hoc Robots on Mission A course where wireless security meets robotics. In: Proceedings of the 10th Colloquium for Information Systems Security Education (CISSE 2006), Adelphi, MD, USA, pp. 82–89 (2006) 46. Oswald, E., Mangard, S., Pramstaller, N.: Secure and Efficient Masking of AESA Mission Impossible. Tech. rep., Technical Report IAIK-TR 2003/11/1 (2004), http://www.eprint.iacr.org/ 47. Pramstaller, N., Gurkaynak, F., Haene, S., Kaeslin, H., Felber, N., Fichtner, W.: Towards an AES Crypto-chip Resistant to Differential Power Analysis. In: European Solid-State Circuits Conference (ESSCIRC 2004), Leuven, Belgium, pp. 307–310 (2004) 48. Quisquater, J.J., Samyde, D.: Eddy current for magnetic analysis with active sensor. In: Proceedings of Esmart, pp. 185–194 (2002) 49. Quisquater, J., Samyde, D.: ElectroMagnetic Analysis (EMA): Measures and Counter-Measures for Smart Cards. In: Attali, S., Jensen, T. (eds.) E-smart 2001. LNCS, vol. 2140, pp. 200–210. Springer, Heidelberg (2001) 50. Regazzoni, F., Badel, S., Eisenbarth, T., Grobschadl, J., Poschmann, A., Toprak, Z., Macchetti, M., Pozzi, L., Paar, C., Leblebici, Y., et al.: A Simulation-Based Methodology for Evaluating the DPA-Resistance of Cryptographic Functional Units with Application to CMOS and MCML Technologies. In: International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (IC-SAMOS 2007), Samos, Greece, pp. 209–214 (2007) 51. Sankai, Y.: Leading edge of cybernics: Robot suit hal. In: SICE-ICASE International Joint Conference (2006) 52. Schmidt, J., Hutter, M.: Optical and em fault-attacks on crt-based rsa: Concrete results. In: Austrochip 2007: Proceedings of the 15th Austrian Workshop on Microelectronics (2007)

An Emerging Threat: Eve Meets a Robot

289

53. Schmidt, J., Hutter, M.: Optical and em fault-attacks on crt-based rsa: Concrete results. In: Proceedings of the Austrochip, pp. 61–67. Citeseer (2007) 54. Shamir, A., Tromer, E.: Acoustic cryptanalysis: on nosy people and noisy machines, http://www.people.csail.mit.edu/tromer/acoustic 55. Skorobogatov, S., Anderson, R.: Optical Fault Induction Attacks. In: Kaliski Jr., B.S., Ko¸c, C ¸ .K., Paar, C. (eds.) CHES 2002. LNCS, vol. 2523, pp. 2–12. Springer, Heidelberg (2003) 56. Tiri, K., Akmal, M., Verbauwhede, I.: A Dynamic and Differential CMOS Logic with Signal Independent Power Consumption to Withstand Differential Power Analysis on Smart Cards. In: European Solid-State Circuits Conference (ESSCIRC 2002), Florence, Italy, pp. 403–406 (2002) 57. Toprak, Z., Leblebici, Y.: Low-Power Current Mode Logic for Improved DPA-Resistance in Embedded Systems. In: International Symposium on Circuits and Systems (ISCAS 2005), Kobe, Japan, vol. 2, pp. 1059–1062 (2005) 58. Inventor’s guide. VEX Robotics Database (December 2009), http://www.vexrobotics.com/docs/inventors-guide/main-2008/ vex-inventors-guide-07022008.pdf, http://www.vexrobotics.com/docs/inventors-guide/main-2008/ vex-inventors-guide-07022008.pdf 59. Ultrasonic sensor kit. VEX Robotics Database (December 2009), http://www.vexrobotics.com/docs/inventors-guide/ vex-robotics-ultra-sonic-5-2-06.pdf, http://www.vexrobotics.com/docs/inventors-guide/ vex-robotics-ultra-sonic-5-2-06.pdf 60. Executive Summary World Robotics 2008 (2008), http://www.worldrobotics.org/downloads/2008_executive_summary.pdf 61. Yen, S., Joye, M.: Checking Before Output Not Be Enough Against Fault-Based Cryptanalysis. IEEE Transactions on Computers 49(9), 967–970 (2000) 62. Zhuang, L., Zhou, F., Tygar, J.: Keyboard acoustic emanations revisited. In: Proceedings of the 12th ACM Conference on Computer and Communications Security, pp. 373–382. ACM, New York (2005)

On Leveraging Stochastic Models for Remote Attestation Tamleek Ali1 , Mohammad Nauman2 , and Xinwen Zhang3 1

Institute of Management Sciences, Peshawar, Pakistan Computer Science Research and Development Unit (csrdu), Pakistan 3 Huawei Research Center, usa [email protected], [email protected], [email protected] 2

Abstract. Remote attestation is an essential feature of Trusted Computing that allows a challenger to verify the trustworthiness of a target platform. Existing approaches towards remote attestation are largely static or too restrictive. In this paper, we present a new paradigm in remote attestation that leverages recent advancements in intrusion detection systems. This new approach allows the modeling of an application’s behavior through stochastic models of machine learning. We present the idea of using sequences of system calls as a metric for our stochastic models to predict the trustworthiness of a target application. This new remote attestation technique enables detection of unknown and zero-day malware as opposed to the known-good and known-bad classification currently being used. We provide the details of challenges faced in the implementation of this new paradigm and present empirical evidence supporting the effectiveness of our approach.

1

Introduction

One of the main objectives of Trusted Computing (tc) is to create a system for the establishment of trust on a remote platform. This concept is termed as remote attestation. The most popular and well adopted technique for this purpose is the Integrity Measurement Architecture (ima) [1]. It allows a target platform to report the hashes of all loaded executables to an authorized remote challenger. The challenger can verify that all of the loaded executables were in fact benign, by comparing the hashes against known-good ones. However, this technique does not cater to the problems posed by execution of the known-good code in a malicious way. Buffer overflow attacks and, in recent times, returnoriented programming [2] are clear examples of such issues. It has therefore been accepted widely [3,4,5,6,7] that dynamic behavior attestation should be investigated as the means of establishing trust on a platform. In traditional security research, some of the most successful behavior measurement techniques revolve around the concept of sequences of system calls originating from an application [8,9,10]. In the context of remote attestation, measurement of behavior through system calls has been studied previously in [3]. However, in our opinion, there are limitations to this approach that keep it L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 290–301, 2011. c Springer-Verlag Berlin Heidelberg 2011 

On Leveraging Stochastic Models for Remote Attestation

291

from being deployed in real-world scenarios. For one, it requires the challenger to statically analyze the source code of the target application (or a disassembly of the executable if the source is unavailable). This is a complex process and might lead to a resistance from the mainstream security audience. The magnitude of this problem increases significantly when we consider the large number of applications that typically execute on a platform and interact with each other in intricate patterns. Secondly, this technique requires the reporting of all system calls to the challenger – a rather tall order considering the huge number of calls made by a typical application in a short span of time [11]. We argue that the problem of deciding upon the trustworthiness of an application has been thoroughly studied in related fields such as intrusion detection systems (ids). Some of the techniques of ids seem to be useful for remote attestation. However, due to the differences in their protection goals, directly applying intrusion detection techniques for remote attestation is not viable. There are several facets of this argument: 1. In an ids, analysis is done locally and can thus operate on real-time data. In remote attestation, on the other hand, the analysis has to be performed remotely. This places a restriction on the amount of information that can be transmitted over the network in an acceptable time window and thus used for the purpose of attestation.1 2. In order to be able to trust the validation performed by an ids on the target platform, the ids will have to be a part of the trusted computing base. This is infeasible due to the size and complexity of typical ids code. 3. Remote attestation has the added advantage of being supported by cryptographic hardware. This can be leveraged to add strength to the measurement engine. Another way of looking at this is that ids techniques employ softwarebased solutions alone. It has been shown that it is not possible to provide tamper-proof security without the use of hardware-based solutions [12]. 4. ids are more concerned with protecting local resources while attestation aims at verifying the integrity of the remote platform before releasing sensitive data to or initiating communication with it. In this paper, we present the idea of using the techniques developed for intrusion detection to facilitate dynamic behavior attestation of a remote platform. In particular, we discuss how sequences of system calls can be modeled through stochastic machine learning techniques to decide upon the behavior of a target application executing on a remote platform. The limitations of having to measure the system calls on a remote platform and reporting them to the challenger in an efficient and trustworthy manner are discussed at length. Finally, we present the details of our experimental results to show that the new remote attestation technique is not only feasible but also very effective in identifying malicious behavior on a target platform. 1

It also leads to privacy concerns but we refrain from commenting on those issues here.

292

2 2.1

T. Ali, M. Nauman, and X. Zhang

Background Dynamic Remote Attestation

Several approaches have been proposed in the past to cater to problems caused by the static nature of ima [1]. Loscocco et al. [4] proposed measuring kernel data structures at runtime for attestation purposes. These structures are to be compared with those generated by debug kernels running in a pristine environment to decide upon the trustworthiness of the target platform. prima [13] considered information flows between the target application and other executables on the system to render some dynamism in the remote attestation paradigm. Modelbased Behavioral Attestation [6] and subsequent efforts [14] have used the concept of behavior measurement to verify the trustworthiness of a target application based on the stakeholder’s policies. Davi et al. [5] have used taint analysis and dynamic tracing to address the issues of static load-time measurement. Similarly, Gu et al. [3,15] have proposed the use of measuring the set of system calls made by a target application at runtime and comparing them with the benchmark. The benchmark is obtained by statically analyzing the calls made by a pristine copy of the application – either through source code analysis or a disassembly process in case the source is not available. All of these approaches are too inflexible to be operable in heterogeneous environments since even the slightest change to the target environment or application can cause the target to be tagged as being malicious. We believe that the approach presented by Gu et al. [3] has a lot of potential but has several limitations: 1. Reporting all system calls made by a process to a remote platform is a serious bottleneck. The number of calls made by a typical mail server, for example, may easily reach several million within the span of a few days’ uptime [11]. 2. The sequence of calls made at runtime can be significantly different from the order expected as a result of code analysis. This can lead to a large false positive rate when identifying malicious behavior of an application. 3. The approach presented by Gu et al. does not consider levels of trustworthiness of an application. A target is either trusted or untrusted with no ‘gray areas’ in between. We believe that the use of stochastic models developed for intrusion detection systems can provide a foundation for better, more dynamic and flexible remote attestation techniques. Below, we discuss some of the relevant aspects of these systems. 2.2

Stochastic Models for Intrusion Detection Systems

Intrusion detection is a highly mature field of research and has seen many simple to complex techniques. Intrusion detection systems (ids) fall in two major categories: host-based and network-based. In this paper, we focus on host-based intrusion detection systems as our focus is on identifying anomalies in target platforms

On Leveraging Stochastic Models for Remote Attestation

293

themselves rather than on the attacks made on the systems. Within host-based ids, two major approaches are signature-based and anomaly-based [16]. Signaturebased systems are akin to ima and use hashes of executables to detect malicious applications. These systems are easier to build and are very accurate in identifying known malicious code [17]. However, detecting zero-day malware is virtually impossible with these systems [16]. To detect malicious behavior of executables, anomaly-based ids were proposed. These build profiles of ‘good’ and ‘bad’ behavior and judge unknown executables based on their patterns of execution. One of the most significant efforts at anomaly-based intrusion detection is Sequence Time Delay Embedding or stide [8]. It defines the behavior of an application based on the sequence of system calls it makes. Subsets of these sequences are defined using predetermined, fixed-width windows. Calls within individual windows are used as patterns for behavior matching. Unknown code is measured against these windows to decide whether it is acting suspiciously or not. Since the inception and successful demonstration of stide, several techniques [9,10,18,19,20] have built on this concept to enhance anomaly-based intrusion detection. For our purposes, we use the most recent (and empirically successful) work proposed by Mehdi et al. [9] We explain our rationale for this choice in Section 3. Here, we cover the basics of this technique as it is at the heart of our proposed architecture. Mehdi et al. propose the concept of a hypergram, which is a structure capable of storing system calls made by an executable. It captures information such as the sequence in which the calls were made as well as the distance (spatial difference, as opposed to temporal) between elements of the sequence. Formally, a hypergram is a point in a hyperspace of n dimensions, each representing a specific system call. The occurrence of a system call causes the hypergram to move along the dimension associated with that call. The exact semantics of the move are defined as follows. For each program, the hypergram is initialized to lie at the origin of the hypercube of n dimensions, each representing a critical system call that needs to be measured. Afterwards, on the occurrence of each system call i: 1. The hypergram is diminished along all dimensions by a factor of δi . The new position of the hypergram γ along dimension i at time instance t is given by: γit = γit−1 ∗ δi . A small value of δ for a system call ensures that calls made in the distant past eventually lose their ability to define the behavior. Calls made in the recent past have more effect on the behavior. 2. The hypergram is moved along the dimension i. The position is updated as:  i γit = γit +αi ∗ βiβ+γ t where α is the addition factor and β is the sloping factor. i The value of the addition factor defines the effect that each occurrence of the system call has on the hypergram and β ensures that extremely large values of γ along one dimension do not skew the data unnecessarily if a particular system call is made extensively by a program. Finally, after each move, the values of hypergrams, along all dimensions, are rounded off to the nearest integer. In our experiments, we did not see a reason

294

T. Ali, M. Nauman, and X. Zhang

to enforce this last step (cf. Section 4). Using these semantics, a hypergram is capable of storing the complete history of the system call sequence leading up to it. We argue that the na¨ıve approach of using this technique directly for remote attestation is not a feasible solution. Our reasons are three-fold: (1) The number of updations to the hypergram is the same as the number of system calls made by an application. As has been argued before, this is a rather large number and reporting the log of such a huge number of updations is simply not possible in the context of remote attestation. (2) This approach uses an in-execution classifier that produces results in real-time. Remote attestation, by nature, requires a postexecution analysis and thus would require a difficult classification approach. (3) In the work of Mehdi et al. [9], there is no mechanism of reporting the hypergrams to a remote party in a trustworthy manner. We therefore believe that in order to leverage this model for the purposes of remote attestation, we would need to come up with an architecture that can address all three of these issues.

3

Leveraging Stochastic Models for Remote Attestation

In order to cater to the problems presented in the previous section, we propose the introduction of stochastic models in the area of remote attestation to enable detection of unknown and zero-day malware as opposed to the known-good and known-bad classification currently being used. Specifically, we use the constructs of intrusion detection through hypergrams in collaboration with the reporting facilities provided by the Trusted Platform Module (tpm) [21]. Our reasons for choosing this specific intrusion detection technique are as follows: 1. Hypergrams allow the aggregation of a large number of system calls, capturing sequences of these calls and the displacement between each call; 2. they have been shown to be highly accurate in the area of local ids; and 3. they provide a flexible model that can be tailored to a specific scenario by tweaking the parameters of the model. Figure 1 shows the proposed architecture in detail. There are two aspects of this architecture: 1) Trusted measurement and reporting mechanisms at the target platform and 2) verification mechanisms at the challenger end. 3.1

Hypergram Measurement and Reporting

Chain-of-trust: In order to establish the chain of trust from the Trusted Platform Module (tpm) to our logging mechanism, we use the constructs of tcg. The chain-of-trust up to the bootloader is established as per tcg specifications [21]. Moreover, the trustworthiness of the kernel is established through trusted grub – a trusted boot loader that measures the kernel and extends its hash into a pcr before passing control onto it. The kernel itself does not have to have ima enabled for our architecture to work. In-kernel behavior measurement is done through a different approach described below.

On Leveraging Stochastic Models for Remote Attestation

Challenger

Target Pla orm Linux Kernel

syscall

Target Applica on

AƩestaƟon Module

Pris is ne System

Machine Learning Module

Linux Kernel

syscall

securityfs

Hλ

Known Good Applica on

Hypergram Log

LSM Hooks

LSM Hooks A esta on M Mo Module

295

PCR Verifier

Hypergram Verifierr H

Training and Test Data Compromised mpromised System

TPM

Hρ

Hypergram LLog H

Linux Kernel

Malware LSM Hooks

syscallll syscal

Fig. 1. Behavior Attestation through Stochastic Models

Hypergram Measurement: Capturing critical system calls made by an executable is a fairly trivial task. We implemented this logging mechanism in a fashion similar to ima by creating a custom Linux Security Module (lsm) – labeled scbm (for system call behavior monitor ). An lsm [22] allows the execution of custom functions in the kernel space on the execution of certain kernel operations. The purpose is to allow a pluggable architecture for defining access control models and policies. The lsm is notified whenever system calls are made. In our implementation, however, we are only interested in logging certain system calls that we identified as being critical (see Section 4.1). For example, the system call for mapping files to memory, mmap, is recorded through the file_mmap hook, file operations such as open, close, read and write through inode_permission and file_permission, socket operations through socket_connect etc.2 In each of these routines, we call a measurement function that calculates the values of the hypergram associated with the originating executable (as defined in Section 2.2). The new hypergram value can be retrieved from scbm/scbm_hypergram_log_lv file in the securityfs. Moreover, the hash computed over this new hypergram value is extended into pcr-11. Hypergram Reporting: The task of reporting the measured hypergrams is far from trivial. As mentioned in Section 2.1, the typical syscall trace can easily reach up to millions of lines. Transmitting such a huge log over a network readily becomes a bottleneck for any remote attestation technique. On the other hand, if the complete log is not reported, the value of the pcr cannot be verified simply from the pcr quote structure. This is a problem not only for our architecture but also for any technique that aims to report the syscall trace to a challenger. However, the novelty of our approach is that it utilizes hypergrams that, by definition, incorporate the complete history of the syscall trace leading up to them. Therefore, in our scenario, it is possible to come up with a solution to this dilemma. For this purpose, we introduce the concept of local verification. When an attestation request is received, a piece of trusted code within kernel space performs 2

We refer the reader to the source of security_operations structure in the linux kernel at include/linux/security.h for the details of these and other hooks.

296

T. Ali, M. Nauman, and X. Zhang

local verification of the hypergram log created during the measurement process. We call this log hypergram log for local verification (Hλ ). Hashes of entries in Hλ are aggregated in the same manner as the pcr_extend operation of the tpm. The aggregated value is compared with the expected value retrieved from the pcr_quote operation over pcr-11 to ensure that none of the entries in Hλ has been tampered with. This process is termed as local verification of Hλ . Upon successful verification, the final values of hypergrams associated with each process are stored in another log file termed as hypergram log for remote verification (Hρ ). With each entry in Hρ , pcr-12 is extended with the hash of the entry. Thus, Hρ contains one entry per process thus significantly reducing the size of the log. Moreover, since the final hypergram value is a function of the complete history of the system calls made by that process, no information loss occurs as a result of this operation. Finally, Hρ and pcr_quote over pcr-12 is returned to the challenger where it can be verified and validated as described below. 3.2

Verification through Stochastic Models

Once the hypergram log (Hρ ) and pcr quote are received at the challenger end, they must be verified in order to establish the trustworthiness of the target application(s). The pcr verification procedure is straight-forward. The aggregate expected value of the pcr is compared with the value returned as pcr_quote. If the values match, Hρ can be considered trustworthy and can be used to measure the trustworthiness of the target application. For the establishment of the trustworthiness of the behavior, we utilize stochastic models of machine learning techniques. For this purpose, as per the general practice, the known-good and known-bad hypergram values must first be collected. This data is called training data and was collected using the same syscall logging mechanism described in the previous section. We collected benign hypergrams from applications running in a pristine, sandboxed environment. The collection of malicious hypergrams is a little more cumbersome as the environment has to be reset to a pristine state after the dataset for each malicious application has been collected. Several malicious executables can be found on popular virus databases such as VX Heavens [23]. Moreover, a test set has to be collected in the same manner in order to test the effectiveness of the stochastic model being used. Once the malicious and benign behaviors have been modeled, the hypergrams received from the target platform can be classified as either benign or malicious based on the model (or classifier ) being used for the classification. Our proposed architecture is model-neutral in that no model-specific transformation is performed at the target platform. All model-specific operations are carried out at the challenger side. Therefore, the classifier used by each challenger can be different and can be upgraded without having to modify the target architecture. Notice that no machine learning algorithms have been utilized on the target side. Only the hypergram-based ids technique is used for measuring the hypergrams. The machine learning part of our proposed architecture operates on the challenger end.

On Leveraging Stochastic Models for Remote Attestation

297

Currently, we have investigated several models of machine learning for the purpose of this classification. These include na¨ıve bayes [24], bayesian networks [25], J48 [26], and 0R. Results achieved by these models are discussed in Section 4. Here, we would like to risk belaboring the obvious by mentioning why this classification cannot be carried out at the target platform thus removing the need for trustworthy reporting of the hypergrams. If such an architecture is used, the complete classification system would have to reside within each of the target platforms. This would not only increase the size of the trusted computing base significantly, but also add excessively to the administrative overhead of deploying and maintaining the attestation system.

4

Evaluation

4.1

Experiment Setup

In order to ensure that our results can be reproduced, we have utilized the traces of system calls available in the datasets provided by unm [11]. For the sake of simplicity, we created a tool – HypergramGenerator (hGen) – for generating hypergrams from the traces of these system calls. hGen is capable of taking stide [8] input format system call sequences and a mapping file and generating hypergrams. It allows the user to specify the critical system calls as well as to set the δ, α and β parameters . The hypergrams produced by hGen are used to train the stochastic model based on different machine learning techniques [24,25,26,27]. The hGen tool was used to generate training data including both malicious and benign behaviors from the unm datasets for inetd, ps and login. As our workbench, we used the popular Wikato Environment for Knowledge Analysis (weka) tool [28]. Approximately 20% of the data was used for training and the rest was used as a testset. Similar to [9], we found out that including the scarcely used system calls in the dataset significantly reduced the accuracy of the model. We therefore used the hGen tool to find the most-oft used system calls and then identified the critical calls from among these. The experiments were run using manually configured values of the three model parameters δ, α and β as we were unable to use the reasoning proposed by [9] to automate the process. We then utilized the different machine learning algorithms to come up with the best possible stochastic model for our datasets. 4.2

Evaluation Criteria

To measure the effectiveness of our approach, we use the widely-adopted concept of Receiver Operating Characteristics (roc) curves [29]. An roc curve is a line graph of true positives (on the y-axis) against false positives (on the x-axis) for different threshold values. The Area Under the Curve (auc) of the roc is a measure of how well the model performs. The higher the auc, the more accurate is the model.3 We calculated the auc for each of the models we applied on the hypergrams. The results of our experiments follow. 3

See [30] for the latest details on the roc curve-based model evaluation.

298

T. Ali, M. Nauman, and X. Zhang

True Positive Rate

1

0.51 NaÏve Bayes J48 ZeroR BayesNet

0.42

0.13

0.57

1

False Positive Rate

Fig. 2. ROC curves for different learning models

Table 1. Comparison of AUCs for different learning models Classifier Na¨ıve Bayes 0R J48 BayesNet (with Genetic Search) In-execution classifier [9]

4.3

AUC 59.14 62.19 78.65 85.72 87.85

Results

Figure 2 shows the roc curves for the different machine learning algorithms we used for attestation purposes i.e. na¨ıve bayes, bayesian networks, 0R and J48. Table 1 shows the auc values for the different classifiers. Na¨ıve bayes and 0R performed quiet poorly in this scenario. J48 (the weka implementation of C4.5 algorithm) provided better results than these two. Using BayesNet, we were able to achieve the auc of 85.72. Note that we do not have access to the in-execution classifier developed by Mehdi et al. [9] and the values under that column are taken from their original paper. Note also that we have not been able to reproduce the auc level achieved by Mehdi et al. However, we are operating in a different scenario under different constraints. Also, we believe that this is the start of a new approach in remote attestation and is likely to get better as more and more efforts are put in this area.

5

Discussion

One of the most important points to note in our technique is that we have provided a rather limited training set to our machine learning models. One might argue that, as with traditional remote attestation techniques, we are only providing known-good and known-bad hypergram values to our attestation module. The number of possible hypergrams that might be generated as a result of execution on the target platform is potentially infinite. Despite this fact, the results obtained are promising. The reason is exactly our rationale for choosing machine

On Leveraging Stochastic Models for Remote Attestation

299

learning techniques for attestation. Machine learning models are capable of operating on limited and noisy data [27, Chapter 2]. They are frequently used to predict unknown information based on incomplete input knowledge. Here, we have leveraged this strength of machine learning models to cater to the fact that it is impossible to predict all paths of execution for any target application. Of course, the more accurate information we have about known-good and knownbad hypergrams (i.e. the larger the training and test data), the more accurate our model will be. Secondly, in this paper, we have only discussed the behavior of a single application and, by extension, define the trustworthiness of the target platform. The trustworthiness of the platform is assumed to be synonymous with the trustworthiness of all applications executing on the platform. We have not modeled the behavior of the platform as a whole. This might form a potentially useful future direction in this line of research. Third, as discussed in Section 2.1, none of the existing attestation techniques have the ability to predict levels of trustworthiness. A target is either trustworthy or it is not. The technique proposed in this paper, in its current form has the same limitation. However, this is due to the fact that typical machine learning algorithms apply a threshold for classification. By removing this threshold application step, we may be able to output the level of trustworthiness rather than the class. This would require the development of a new ‘classifier’, which forms part of our future work. Finally, we would like to point out an issue that this paper has not addressed. The avid tc developer may have noticed that the local verification step, detailed in Section 3, breaks the chain-of-trust. A malicious application may somehow alter the local verification procedure and simply report a ‘known-good’ hypergram to the challenger. We are currently working on addressing this issue by exploring the semantics of executing the local verification mechanism in a secure execution environment such as one proposed by Flicker [31]. While it might pose some implementation difficulties, the procedure is trivial at the conceptual level. Such an implementation would restore the chain-of-trust and provide the challenger assurance that the local verification mechanism was indeed correct.

6

Conclusions

In this paper, we have presented a new remote attestation technique that utilizes the constructs of machine learning for the purpose of remote attestation. The end result is a flexible attestation mechanism that can measure the dynamic behavior of a target application and, by extension, the target platform. We have presented the details of the implementation, the challenges faced and the empirical results in the favour of the proposed system. We believe that this is a new avenue in remote attestation research and will lead to several new and improved techniques of remotely verifying the behavior of a platform in a flexible and scalable manner.

300

T. Ali, M. Nauman, and X. Zhang

References 1. Sailer, R., Zhang, X., Jaeger, T., van Doorn, L.: Design and Implementation of a TCG-based Integrity Measurement Architecture. In: SSYM 2004: Proceedings of the 13th Conference on USENIX Security Symposium (2004) 2. Shacham, H.: The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86). In: Proceedings of the 14th ACM conference on Computer and Communications Security (CCS 2008), pp. 552–561. ACM, New York (2007) 3. Gu, L., Ding, X., Deng, R., Xie, B., Mei, H.: Remote Attestation on Program Execution. In: STC 2008: Proceedings of the 2008 ACM Workshop on Scalable Trusted Computing. ACM, New York (2008) 4. Loscocco, P.A., Wilson, P.W., Pendergrass, J.A., McDonell, C.D.: Linux Kernel Integrity Measurement Using Contextual Inspection. In: STC 2007: Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, pp. 21–29. ACM, New York (2007) 5. Davi, L., Sadeghi, A., Winandy, M.: Dynamic integrity measurement and attestation: towards defense against return-oriented programming attacks. In: Proceedings of the 2009 ACM Workshop on Scalable Trusted Computing, pp. 49–54. ACM, New York (2009) 6. Alam, M., Zhang, X., Nauman, M., Ali, T., Seifert, J.P.: Model-based Behavioral Attestation. In: SACMAT 2008: Proceedings of the Thirteenth ACM Symposium on Access Control Models and Technologies. ACM Press, New York (2008) 7. Nauman, M., Khan, S., Zhang, X.: Beyond Kernel-level Integrity Measurement: Enabling Remote Attestation for the Android Platform. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 1–15. Springer, Heidelberg (2010) 8. Forrest, S., Hofmeyr, S., Somayaji, A., Longstaff, T.: A sense of self for unix processes. In: Proceedings of IEEE Symposium on Security and Privacy, 1996, pp. 120–128 (1996) 9. Mehdi, B., Ahmed, F., Khayyam, S., Farooq, M.: Towards a Theory of Generalizing System Call Representation For In-Execution Malware Detection. In: ICC 2010: Proceedings of the IEEE International Conference on Communications (2010) 10. Mutz, D., Robertson, W., Vigna, G., Kemmerer, R.: Exploiting execution context for the detection of anomalous system calls. In: Kruegel, C., Lippmann, R., Clark, A. (eds.) RAID 2007. LNCS, vol. 4637, pp. 1–20. Springer, Heidelberg (2007) 11. University of New Mexico: Computer Immune Systems – Datasets, http://www.cs.unm.edu/~ immsec/systemcalls.htm (accessed May, 2010) 12. Pearson, S.: Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall PTR, Upper Saddle River (2002) 13. Jaeger, T., Sailer, R., Shankar, U.: PRIMA: Policy-Reduced Integrity Measurement Architecture. In: SACMAT 2006: Proceedings of the Eleventh ACM Symposium on Access Control Models and Technologies, pp. 19–28. ACM Press, New York (2006) 14. Nauman, M., Alam, M., Ali, T., Zhang, X.: Remote Attestation of Attribute Updates and Information Flows in a UCON System. In: Chen, L., Mitchell, C.J., Martin, A. (eds.) Trust 2009. LNCS, vol. 5471, pp. 63–80. Springer, Heidelberg (2009) 15. Gu, L., Cheng, Y., Ding, X., Deng, R., Guo, Y., Shao, W.: Remote Attestation on Function Execution. In: Trust 2009: Proceedings of the 2009 International Conference on Trusted Systems (2009)

On Leveraging Stochastic Models for Remote Attestation

301

16. Axelsson, S.: Intrusion detection systems: A survey and taxonomy. Technical report, Department of Computer Engineering, Chalmers University (2000) 17. Kr¨ ugel, C., T´ oth, T.: Using decision trees to improve signature-based intrusion detection. In: Vigna, G., Kr¨ ugel, C., Jonsson, E. (eds.) RAID 2003. LNCS, vol. 2820, pp. 173–191. Springer, Heidelberg (2003) 18. Hofmeyr, S., Forrest, S., Somayaji, A.: Intrusion detection using sequences of system calls. Journal of Computer Security 6(3), 151–180 (1998) 19. Hofmeyr, S., Forrest, S.: Architecture for an artificial immune system. Evolutionary Computation 8(4), 443–473 (2000) 20. Wilson, W., Feyereisl, J., Aickelin, U.: Detecting Motifs in System Call Sequences. In: Kim, S., Yung, M., Lee, H.-W. (eds.) WISA 2007. LNCS, vol. 4867, pp. 157–172. Springer, Heidelberg (2008) 21. TCG: TCG Specification Architecture Overview v1.2, pp 11–12. Technical report, Trusted Computing Group (April 2004) 22. Wright, C., Cowan, C., Morris, J., Smalley, S., Kroah-Hartman, G.: Linux security module framework. In: Ottawa Linux Symposium. Citeseer (2002) 23. Heavens, V.X.: Information and hosting for computer viruses, http://vx.netlux.org/ (accessed June 02, 2010) 24. Bayes, T.: Learning Bayesian networks: The combination of knowledge and statistical data. Philosophical Transactions of Royal Society of London 53, 370–418 (1763) 25. Heckerman, D., Geiger, D., Chickering, D.: Learning Bayesian networks: The combination of knowledge and statistical data. Machine Learning 20(3), 197–243 (1995) 26. Quinlan, J.: C4.5: programs for machine learning. Morgan Kaufmann, San Francisco (1993) 27. Witten, I., Frank, E.: Data Mining: Practical machine learning tools and techniques. Morgan Kaufmann Pub., San Francisco (2005) 28. Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., Witten, I.: The WEKA data mining software: An update. ACM SIGKDD Explorations Newsletter 11(1), 10–18 (2009) 29. Lippmann, R., Fried, D., Graf, I., Haines, J., Kendall, K., McClung, D., Weber, D., Webster, S., Wyschogrod, D., Cunningham, R., et al.: Evaluating intrusion detection systems: the 1998 DARPA off-line intrusion detection evaluation. In: Proceedings of DARPA Information Survivability Conference and Exposition, DISCEX 2000, vol. 2 (2000) 30. Ali, M., Khan, H., Sajjad, A., Khayam, S.: On achieving good operating points on an ROC plane using stochastic anomaly score prediction. In: Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS 2009), pp. 314–323. ACM, New York (2009) 31. McCune, J., Parno, B., Perrig, A., Reiter, M., Isozaki, H.: Flicker: An execution infrastructure for TCB minimization. In: Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pp. 315–328. ACM, New York (2008)

Interoperable Remote Attestation for VPN Environments (Work in Progress) Ingo Bente, Bastian Hellmann, Joerg Vieweg, Josef von Helden, and Arne Welzel Trust@FHH Research Group Fachhochschule Hannover - University of Applied Sciences and Arts Ricklinger Stadtweg 120, 30459 Hannover, Germany {ingo.bente,joerg.vieweg,bastian.hellmann,josef.vonhelden}@fh-hannover.de [email protected]

Abstract. This paper describes an approach to perform a Remote Attestation in VPN environments, using Trusted Network Connect techniques. The solution is based on the VPN connection set up to authenticate the user, and the afterwards established VPN tunnel to perform a TNC handshake. In this handshake the Remote Attestation takes place. The result of this Attestation is then used by the Policy Enforcement Point to configure a packet filter. The initial configuration of this packet filter allows only communication with the Policy Decision Point and according to the Attestation result, the configuration is changed to either allow or forbid network access. The approach is completely independent of the used VPN solution, thus realising interoperability. The approach is also compared against other ideas for a VPN-based Remote Attestation. Furthermore, this paper also describes an implementation of this approach. Keywords: Trusted Network Connect, Trusted Computing, Virtual Private Networks, Remote Attestation, Network Access Control.

1

Introduction

Heterogeneity and mobility are two major properties of modern networks. Arbitrary, mobile endpoints connect to different networks on demand and use available services. One example scenario are employees working on-site at the customer connecting both to their companies and to the customer’s network. This highly dynamic topology of modern networks causes new threats network operators have to face: e.g. users that exploit the provided services (peer-to-peer) or endpoints compromised by malware that can potentially spread around the network to which the endpoint is connected. To counter the threats mentioned above, a Remote Attestation could be used to verify the integrity state of a connecting endpoint, thus protecting the network L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 302–315, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Interoperable Remote Attestation for VPN Environments

303

against the potential malicious components placed on the endpoint. Performing such a Remote Attestation may be straightforward within local networks. Trusted Network Connect [17] is one open source standard allowing to do this. VPN environments are one common technique to allow connections to a network from arbitrary locations. While the connecting endpoints in such environments may be physically located far away from the network they are connecting to, the same threats as when locally connecting arise. As with local networks, a Remote Attestation would be a reasonable approach to counter those threats. Due to the specific VPN architecture, there are some problems when trying to perform such an Attestation. This paper proposes an approach to avoid such problems, allowing to do an Remote Attestation within arbitrary VPN environments while leaving the VPN components untouched. Contribution. Our solution proposed in this paper enhances a VPN environment in conjunction with TNC components to allow an interoperable Remote Attestation. While there are already other approaches to solve the problem of performing a Remote Attestation in such environments, our idea avoids the problem of changing the VPN components. This means by using our approach one is able to perform a Remote Attestation of an endpoint via a VPN connection without customizing the VPN components at all, thus making this approach real interoperable. In general, we achieve this by using a special component which needs to be added to the network, acting as a interpreter between TNC specific communication and a enforcement component in the network. Outline. The remainder of this paper is organized as follows: Related work is discussed in section 2. Section 3 gives a short introduction to Trusted Computing and TNC. In section 4 we present our main contribution: the concept of performing an interoperable Remote Attestation within an arbitrary VPN environment. Following the main contribution, section 5 evaluates the approach and give an overview about the practicability. A conclusion is given in section 6.

2

Related Work

Some work has been done in the area of allowing a Remote Attestation in VPN environments, in particular by Sadeghi and Schulz [11]. Their latest Paper on this topic [12] proposes an approach to extend the IKEv2 protocol [6] to additionally support Remote Attestation. The approach supports ongoing exchange of Attestation data during the IPSec [7][9] connection. The main goals were simplicity and efficiency, so there were made only minor changes to the IKEv2 protocol and some extensions. In the phase of Security Association (SA) negotiation the proposed approach would now also negotiate the usage of Remote Attestation and which protocol to use, in addition to the standard procedure. This is done by using a new Transform Substructure, so that different Remote Attestation protocols can be offered and accepted, as the other protocols in the SA negotiation. After the initial SA negotiation, when the last IKE AUTH exchange was done and the communication is secured, remote Attestation payloads

304

I. Bente et al.

would be exchanged. They consist of the generic payload header, a data length field to support fragmentation of long Attestation messages, and the Attestation data itself. The data of the payload is then handled by an external Attestation Service (AS). The proposal describes an interface in order to communicate with the AS, mainly consisting of five methods for establishing a connection between the IKEv2 server and the AS, for exchanging Attestation data and for granting or denying access of the authenticating client. Denying would result in revoking all SAs negotiated between the peers. The Attestation Service can be run locally on the IKEv2 server and also on a remote system, though the connection has to be additionally secured in this case. In the step of creating keys for further communication between the peers another key would be generated, called the Shared Attestation Key, which can be used as input for Attestation protocols. Compared to our approach of creating an interoperable method for using VPNs to allow Remote Attestation, the design is strongly connected to IPSec and the IKEv2 protocol. As the protocol itself is changed, the software used in an existing VPN network would have to be changed, too. Besides this approach, there is more research related to this topic by Baiardi and Sgandurra. Their work is mainly about Remote Attestation within overlay networks [1] but they rely also on a VPN environment. This environment is based upon OpenVPN. To allow a Remote Attestation within this OpenVPN enhanced VPN environment, they extended OpenVPN itself. That is, they implemented a specific plug in which adds Remote Attestation to the OpenVPN components. This concept is similar to the first approach of Sadeghi and Schulz. Both ideas rely on the possibility to customize and extend the VPN components. Taking a closer look at current IT-infrastructures, it is often impossible to change such VPN components or to replace them against enhanced variants. While those approaches itself seem to be well working, their practicability is rather limited. Due to this there is a need for an interoperable approach which allows to use Remote Attestation in VPN environments in real world scenarios. This approach will be shown in the remainder of this paper.

3

Trusted Computing and Trusted Network Connect in a Nutshell

Trusted Computing Group (TCG). The environment of modern IT-networks has changed over the last years. Compared to the past, the systems became more and more dynamic and heterogeneous, as more and more mobile devices like PDAs and notebooks, join and leave such a network. Therefore, the security of those systems, which are sometimes not under control of the network administrators, is critical to the security of the network. An approach to this problem is defined by the Trusted Computing Group (TCG) [23], a non-profit organization, consisting of over 100 members. They specify an open, vendor-neutral framework for trustworthy hardware and software. The term of Trust by their means is, that a trustworthy component always behaves in an expectable manner, regardless if it is a good or a bad behaviour. For example, a trustworthy malware-program

Interoperable Remote Attestation for VPN Environments

305

can be trusted to always behave bad. The main challenge is to securely obtain the status of a platform, with all its installed components, to make a decision whether the system is trustworthy or not. Trusted Platform Module (TPM). Therefore, the Trusted Platform Module (TPM) [21] [19] [20] was developed. It is not specified, whether a TPM has to be implemented in software or hardware, but in most cases it is a passive hardware chip with several features, like measuring and assuring, that the measurement is correct. A TPM is always bound to a certain platform, for example a motherboard. The TPM can only respond to the commands from the CPU and return a result. Measurements are done as SHA-1 digests and stored in Platform Configuration Registers (PCR), which reside in a secure area of the chip. On the start up of the system, the registers are empty, and adding values to a register is implemented by extending its previous value. The new value, i. e. the new measurement, is concatenated to the old value of the register. After that, this intermediate result is then hashed again and is placed as the new value in the register. This extend mechanism allows to store an unlimited number of measurements in the TPM. Furthermore, it is not possible to intentionally set the value of a PCR to a desired value. As the order of measurements is important, each measurement is also stored in a Stored Measurement Log (SML) on the platform. Using all entries from the SML, the current value of the PCR can be generated; if they are different, the SML must be manipulated and thus probably the system. The TPM also holds different types of keys. The first one is the Endorsement Key (EK), which is usually generated by the manufacturer and placed inside the chip. It identifies the chip, and its private part never leaves the chip. As the EK cannot be used for signing, another type of keys is available. The Attestation Identity Key (AIK) is used for signing PCR values. In contrast to the EK, it is created by the owner of the TPM and there can be more than one AIK per chip. There are two methods to proof, that an AIK belongs to a valid TPM: AIK-CA [2] and DAA [3]. Chain of Trust. An important point when measuring software is to ensure that the component who does the measurement is not manipulated. This means, that each measuring component itself has to be measured prior to their execution. The simplified flow of measurements is as follows: A component which wants to load another component, has to measure that before it gives control to the other component. The first component which starts on a regular computer is the BIOS, so the first component being measured would usually be this BIOS. When the BIOS is measured and loaded, it will measure and load the boot loader, which then measures and loads the operating system. The OS itself could then continue to measure applications. This leads to a Chain of Trust, where one has to trust the starting point (the Trust anchor). Trusted Network Connect (TNC). TNC (as a Network Access Control approach) allows network operators to decide whether an endpoint gets access to their network or not based on the endpoint’s current integrity state. The network

306

I. Bente et al.

operator of a TNC protected network can specify a policy that every endpoint must comply with before network access is granted. An enterprise could enforce that any endpoint that wishes to connect to the corporate network must have an Anti Virus software running whose virus signature is up-to-date. Special TNC [17] software components are responsible for gathering the necessary data reflecting the integrity state of an endpoint and communicating this data to the TNC protected network. This process is referred to as assessment in context of TNC. A policy specified by the network operator of the TNC protected network defines what kind of data is gathered during the assessment phase. If the integrity check fails, several access restrictions can be enforced. In addition to being open, TNC distinguishes itself from other Network Access Control (NAC) solutions by leveraging the capabilities of Trusted Platforms as proposed by the TCG [13]. In this case, TNC can be considered as an implementation of Remote Attestation. This implies, that the TNC handshake which takes place when an endpoint wants to access a TNC protected network, is the Remote Attestation step, thus TNC is by design capable of performing a Remote Attestation. Components of TNC. The environment in a TNC extended network consists of three different components, the Access Requestor (AR), the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). The AR wants to gain access to a network and has to authenticate (i.e. to proof its integrity) itself to the PDP. The PDP decides if the AR is allowed to join the network, based on the identity and the status/integrity of the client. It then enforces the decision by sending the resulting recommendation to the PEP. The PEP grants or denies network access to the endpoint, based on this received recommendation. In a example situation, the AR could be a notebook who wants to join a network. The PDP could be a server which is located in the network, and the PEP could be 802.1x-capable switch. To allow or deny the access to the network, the PDP tells the PEP to open or close the ports, which are used by the AR. Software Layers. The specification also defines three layers for the components on the AR and the PDP. On the lowest layer, called the Network Access Layer (NAL), the technical network access via 802.1x or VPN is implemented. The components are the Network Access Requestor (NAR) on the AR, and the Network Access Authority (NAR) on the PDP. The next layer is the Integrity Evaluation Layer (IEL), which is called TNC client on the AR and TNC server on the PDP. This layer is responsible for forwarding and receiving integrity measurement messages between AR and PDP. The PDP also has to decide, what general recommendation to build with the help of all incoming measurements, and afterwards send that to the PEP. The highest layer is the Integrity Measurement Layer (IML). It consists of an arbitrary number of software-pairs on both AR and PDP. The component on the AR, called Integrity Measurement Collector (IMC) [15], is responsible for measuring specific features on the client machine, like the state of the Anti Virus software, port-status or platform identity via a Platform Trust Service (PTS). Its counterpart on the PDP, called Integrity Measurement Verifier (IMV)

Interoperable Remote Attestation for VPN Environments


       




    

 !    

   

 $  $




 ! "#  "






      










 


307

 


 


 

    





   


   

%&'()*++ !,"
, (

 ,-!,"
.!!


 




  
  !/

Fig. 1. TNC architecture version 1.3 [17]

[16], compares these measurements to a policy of allowed (and not allowed) values, and builds a recommendation for each IMC/IMV-pair. There may be, for example one special IMC/IMV-pair which simply takes PCR values out of the TPM (by doing a TPM Quote) and compares them against reference values, thus realising a simple Remote Attestation. Besides this simple pair, there may be more complex pairs, where one could for example perform a Property Based Attestation [4]. The components communicate via interfaces specified by the TCG, thus allowing interoperability between TNC components. Platform Trust Services (PTS). The software on the AR which creates the measurements, has to be trusted. In the case that an attacker gains access to the machine, he could manipulate the IMC to always send false responses about its state. These attacks are known as Lying Endpoint attacks. To prevent those, the measurement components have to be included in the Chain of Trust. The TCG therefore defines an interface called Platform Trust Service (PTS) [14]. This helps to detect manipulated measurement components and thus an untrustworthy machine. The PTS is one core component inside the TNC architecture which makes it possible to perform a Remote Attestation.

4

Interoperable Remote Attestation for VPN Environments

As already stated, Virtual Private Networks are commonly used nowadays and are usually integrated as a core component of a (companies) network. To perform a real interoperable Remote Attestation when connecting with an endpoint via such a VPN system, the VPN system itself should remain untouched by the

308

I. Bente et al.
 

 $  





  
   

          

      ! 

##

%
 &   

 (    

 "  

  

  


$   ' & "

Fig. 2. VPN Attestation Architecture

Attestation process. This is necessary as it is usually not possible to extend the VPN systems itself to support Remote Attestation. To achieve this goal of VPN solution independence, we propose the use of Trusted Network Connect in conjunction with a special component. Figure 2 gives an overview of our proposed architecture. Access Requestor. The connecting Endpoint consists of the TNC components and the (standard) VPN client. The TNC components are already described in section 3. Besides the TNC specific components, there is the VPN client which is not influenced by our solution, i.e. whether the VPN application itself, nor the configuration needs to be changed. Policy Enforcement Point. The PEP consists of several logical entities: the VPN Gateway, the so called PEP Daemon (PEPd) and a packet filter or similar enforcement system. The VPN Gateway is the corresponding component to the VPN Client which is located on the Access Requestor. As with the VPN Client, it is also unchanged to support the Remote Attestation. This means there is no need to adapt the VPN Gateway to support the Remote Attestation and TNC. Next to the VPN Gateway, there is the PEP Daemon (PEPd). The PEPd listens for TNC access decision made by the Policy Decision Point and forwards them (in an appropriate format) to the enforcement component- usually a packet filter. The PEPd is a core component of this approach as it allows the Remote Attestation via standard and legacy VPN components. The last component, the packet filter enforces the decision it receives from the PEPd. In a real world scenario, the PEPd would reconfigure the filter rules of the packet filter to support the access decision made by the PDP. Policy Decision Point. The PDP is a standard TNC component, described in detail in section 3. It verifies the measurement values received from the AR and generates a policy based access decision (the recommendation). This decision is then send to the PEP which enforces it. Based on the result of the measurement verification, the access decision could be allow, which grants the AR the right to enter the network. It could also be isolate which puts the AR in a special isolation environments allowing to take further steps or it can completely deny network access.

Interoperable Remote Attestation for VPN Environments

309

As mentioned above, there is no need to change any of the VPN components or to use special VPN components. Besides adding the TNC architecture, which is possibly already implemented for direct (i.e. non-VPN connections) network access, the only components which need to be installed or altered are the PEPd and the packet filter. Figure 2 shows the PEPd and the packet filter located on the PEP, along with the VPN Gateway. In a real world scenario, those components belong logically together but there is no need to place them on the same machine or system. This means that an already installed packet filter in the network could be used to enforce TNC access decisions. Having all these components, the general idea to achieve the goal of an interoperable Remote Attestation via the VPN is to first perform the VPN connection set up between the Access Requestor (i.e. the connecting endpoint) and the VPN Gateway. The important fact concerning the VPN connection is, that at this time, the packet filter limits the connection possibilities of the VPN client. This means that the VPN Client is able to connect to the PDP trough the established tunnel while being unable to connect to any other network component, thus only allowing the TNC handshake. After this handshake is completed, the PDP may instruct the packet filter to allow arbitrary, based on the networks policy, network connections. As the access decision of the PDP is communicated via the IF-PEP protocol [18] a direct connection between the PDP and the packet filter would counter interoperability as the packet filter would need to understand the IF-PEP protocol. To preserve interoperability, which means in this case that the packet filter can remain untouched, the PEPd is used. The access decision of the PDP will be transmitted, using the IF-PEP protocol, to the PEPd which is listening for IF-PEP specific communication. After it receives the decision, it reconfigures the packet filter to match the access decision. Depending on which kind of packet filter is used, this could be for example a simple enhancement of filter rules. The idea of a separated daemon awaiting IF-PEP communication allows to use arbitrary enforcement systems, for instance besides the simple packet filter there could also be a complex firewall system (usually consisting of several systems) which will be reconfigured by the PEPd to enforce the access decision. That is, to enhance an already given network, the only things that need to be added are the TNC components along with the PEPd and, if it does not exist already, an enforcement system. There is no need to change any of the existing systems. This is the main advantage of the proposed approach. To perform a Remote Attestation using this approach, there are several steps necessary. The next section will give a closer look at those stages. 4.1

Detailed Communication Flow

The overall communication flow when using our approach can be divided into two stages: A VPN stage and the Attestation stage. While the VPN stage is the same as when using the VPN stand alone, the Attestation stage is mandatory to perform Remote Attestation. Figure 3 gives an overview of the general procedure when using our approach. Besides the already mentioned phases, the most important thing are the depicted steps:

310

I. Bente et al.


 ! 




  



    




 "#  
  


  








     






 







   

  





      

 

    

 

Fig. 3. Communication Flow

1. The VPN User Authentication step is the first step to be done. It is performed when an endpoint wants to connect to a network via a VPN connection. First, the endpoint initiates the VPN connection itself. Usually, the user needs to authenticate himself. This step is solely VPN based, thus the VPN client communicates with the VPN Gateway to perform the authentication. If this authentication is successful the VPN connection is established which typically means that the endpoint is able to perform IP-based network communication via the VPN tunnel. By using our approach, this communication is limited by the packet filter, i.e. the endpoint is only to allowed to communicate with the PDP inside the network. This prevents the endpoint from accessing other network components, thus successfully isolating it. 2. After a successful VPN authentication and with an established VPN tunnel (IP-based communication), the endpoint can perform a TNC handshake. This TNC handshake allows to verify that the endpoint is compliant to the networks policy. In detail, the endpoint must measure certain property, collect those measurements and send them to the Policy Decision Point. The PDP may order the endpoint to provide additional information. The security of this process relies on the features of TNC and Trusted Computing. 3. If the PDP has enough information, it verifies (i.e. it compares it against one ore more policies) those information and will make a decision. This decision could be network access for the endpoint or only a limited/isolated access and even complete access may be denied. The process measuring and comparing may run several times, as the PDP can always request more information from the endpoint. This and the previous step realise the Remote Attestation. 4. Having the decision, the PDP communicates it via the IF-PEP protocol to the Policy Enforcement Point. The PEPd listens for IF-PEP communication, thus receiving the access decision from the PDP. This means, instead of

Interoperable Remote Attestation for VPN Environments

311

transmitting the decision directly to the enforcing component, our approach uses the PEPd to mediate between the PDP and the enforcing component. This is the main reason for keeping all standard and legacy components untouched. 5. The PEPd needs to know which component is responsible for enforcing access decisions. With this knowledge, it is able to perform a reconfiguration of this component, to successfully enforce the access decision made by the PDP. In our approach, a packet filter enforces those decisions. 6. With the instructions of the PEPd, the packet filter can now change the filter rules. The initial rules, only allowing traffic from the VPN client to the PDP will be changed to either grant network access completely, to isolate the VPN client or to deny network access. 7. The last step is the standard TNC notification of the endpoint. The PDP sends the access decision to the client to inform it. After these steps are finished, the endpoint may have network access (according to the decision). The Remote Attestation itself is performed in the TNC handshake steps, the VPN steps will not be touched. This is the main difference compared to other approaches, which usually change the VPN communication itself to allow a Remote Attestation. As one may have noticed, this approach relies on a already established IPbased connection (the VPN tunnel). It is mandatory to use the IF-T for TLS protocol binding within the TNC phases. Without using the IF-T for TLS, there is no way but changing the VPN components to perform a TNC-based Remote Attestation. As IF-T for TLS is a standard TNC protocol and well specified, this limitation is no drawback at all. 4.2

Implementation

We have successfully implemented our approach, showing that it is working in VPN scenario without changing VPN components. Our implementation is based on the open source TNC@FHH [22] TNC implementation in conjunction with OpenVPN [10] as VPN solution. OpenVPN was not changed in any way. It consists of the following four core components, which extend the TNC@FHH solution: Library for common functions (libtncvpn). The libtncvpn-library provides support for basic SSL-handling, defines the format for IF-T for TLS protocol messages between the different components and also defines a data structure for endpoints. Every endpoint is defined by its IP address and its last time of assessment. The IF-T for TLS messages are defined by an envelope and a pair of version request and respond-messages. Another message-type which is defined by the library is the simplified IF-PEP protocol, used to send recommendation results from the PDP to the PEPd. This means that this library is mandatory to use IF-T for TLS, SSL-Handling and the IF-PEP communication.

312

I. Bente et al.

Network Access Authority (NAA) and PDP. The NAA component handles the incoming requests from the AR and delivers them to the IEL. It was extended to support IF-T for TLS communication. It also sends the result of the assessment to the PEP. The IML is provided by the TNC server implementation of TNC@FHH. The configuration of the server contains a list which maps PEPs, defined by their IP-address and netmasks. If a client tries to authenticate via TNC, the server sends the result of the handshake to the PEP which is responsible for this client. pepd. The PEP component enforces the recommendations of the PDP for clients, that are requesting access. The enforcement is done by using standard iptables [5] as a packet filter. Incoming recommendations, which could be allow or deny, result in adding a specific rule to iptables which allows or denies network access for the client. This rule change is performed by the PEPd, which was also added by us. In detail this PEPd takes the received recommendation and simply runs an appropriate script to change the rules of iptables on the PEP. The PEPd also memorizes all incoming recommendations and their timestamps. An assessment scheduler is responsible for checking the duration of the validity of the recommendations. Every 10 seconds, it checks if the time since the last recommendation for a specific endpoint is greater than 5 minutes, and if so, it enforces a denying rule for iptables. In the current implementation, the clients have to take care of re-assessing itself, by repeating the handshake. Network Access Requestor (NAR). The NAR component offers mechanisms to start a connection between an AR to a PDP via a TLS session (based on the IFT for TLS protocol and running inside the established VPN tunnel). It initializes and performs the basic TLS handshake and provides a secure channel for further IF-T TNCCS messages. The communication between the OpenVPN client component and the installed IMCs on the client is done via the libtnc-library [8]. Libtnc reads the configuration in /etc/tnc, loads and uses the installed IMCs and creates IF-T TNCCS 2.0 batches, which then are send to the PDP by the OpenVPN client. Those components, mentioned above, together with TNC@FHH, libtnc, OpenVPN and iptables allow to use our approach in real world VPN scenario. We have run several tests with our environment, which were overall successful.

5

Evaluation and Practicability

As we have implemented this approach, there are first results allowing to evaluate the practicability of this approach. Several special requirements need to be fulfilled to successfully use this approach: – The TNC solution must support the use of the IF-T for TLS binding. Without this binding, there is no way of communicating between the TNC Client and the Policy Decision Point.

Interoperable Remote Attestation for VPN Environments

313

– There must be a stand alone enforcement component to control communication and traffic of the connecting endpoint. Without this, no enforcement is possible at all. Usually, this is some kind of reconfigurable packet filter. – In addition to the VPN, TNC and enforcement components, the PEPd must be placed appropriately. The requirement of being able to use IF-T for TLS is easy to fulfil as it is a standard TNC protocol. This means usually, to be TNC-compliant, the TNC components already support this protocol. This implies that there are no additional steps necessary. The enforcement component as well as the PEPd are stand alone systems which can be easily place into an existing network. Thus this requirement is also easy to fulfil, compared against customizing already existing components like the VPN solution. Besides those requirements, the pre-condition of having TNC and VPN components must be fulfilled as well. It is easy to recognize, that this approach allows to add Remote Attestation support to (already existing) VPN environments in a comfortable manner. I.e. all legacy and standard components remain untouched, there is no need to change them. This is the main benefit compared against other approaches, thus rendering this idea practicable.

6

Conclusion and Future Work

VPN environments are one common technique nowadays. This paper shows an approach for allowing a Remote Attestation in such an environment. It uses Trusted Network Connect and adds special components to the network for this purpose. Compared against other approaches, this idea does not rely on the customization of the VPN components. Instead by adding stand alone components, it ensures a maximum of interoperability as commodity systems must not be changed. This makes it possible to use this approach in arbitrary scenarios. The network operator only needs to add the required systems, which is usually a lot easer than changing systems like the VPN Gateway. Additionally it may also be impossible to change those systems (for example due to closed source restrictions). Our implementation shows that this approach is working in a real world scenario and with real VPN components. Question arise on the topic of the integration of the VPN and TNC components on the endpoint. At the moment, both components work stand alone which may be inconvenient and not transparent to the user. Future work should make the connection process as transparent to the user as possible, thus finding a way to integrate both components on the endpoint without losing interoperability.

Acknowledgements This work was funded by the German Federal Ministry of Education and Research (BMBF) within the tNAC (1704B08) research project.

314

I. Bente et al.

References 1. Baiardi, F., Sgandurra, D.: Attestation of integrity of overlay networks. Journal of Systems Architecture (2010) (in press) (corrected proof), http://www.sciencedirect.com/science/article/B6V1F-508PPYT-1/2/ 59cabe0d98e91e12c75b03d76b270d9f 2. Brickell, E., Camenisch, J., Chen, L.: Direct anonymous attestation. In: CCS 2004: Proceedings of the 11th ACM Conference on Computer and Communications Security, pp. 132–145. ACM, New York (2004) 3. Camenisch, J.: Better privacy for trusted computing platforms. In: Samarati, P., Ryan, P.Y.A., Gollmann, D., Molva, R. (eds.) ESORICS 2004. LNCS, vol. 3193, pp. 73–88. Springer, Heidelberg (2004) 4. Chen, L., Landfermann, R., L¨ ohr, H., Rohe, M., Sadeghi, A.R., St¨ uble, C.: A protocol for property-based attestation. In: STC 2006: Proceedings of the First ACM Workshop on Scalable Trusted Computing, pp. 7–16. ACM, New York (2006) 5. Netfilter and Iptables Project Homepage, http://www.netfilter.org/ (accessed on 2010/08/04) 6. Kaufman, C.: Internet key exchange (ikev2) protocol (2005), http://tools.ietf. org/html/rfc4306 7. Kent, S., Atkinson, R.: Security architecture for the internet protocol (1998), http://tools.ietf.org/html/rfc2401 8. libtnc Website, http://sourceforge.net/projects/libtnc/ (accessed on 2010/08/04) 9. Maughan, D., et al.: Internet security association and key management protocol (isakmp) (1998), http://tools.ietf.org/html/rfc2408 10. OpenVPN Website, http://openvpn.net/ (accessed on 2010/08/04) 11. Schulz, S., Sadeghi, A.R.: Secure VPNs for trusted computing environments. In: Chen, L., Mitchell, C.J., Martin, A. (eds.) Trust 2009. LNCS, vol. 5471, pp. 197– 216. Springer, Heidelberg (2009) 12. Schulz, S., Sadeghi, A.R.: Extending ipsec for efficient remote attestation. In: Sion, R. (ed.) Financial Cryptography. LNCS. Springer, Heidelberg (January 2010), Workshop on Real-Life Cryptographic Protocols (RLCPS) 13. TCG Infrastructure Work Group: Reference Architecture for Interoperability (Part I) (June 2005), http://www.trustedcomputinggroup.org/ resources/infrastructure_work_group_reference_architecture_for_ interoperability_specification_part_1_version_10, specification Version 1.0 Revision 1 14. TCG Infrastructure Working Group: Platform Trust Services Interface Specification (IF-PTS) (November 2006), http://www.trustedcomputinggroup.org/ files/temp/6427263A-1D09-3519-ADEE3EFF23C8F901/IWG%20IF-PTS_v1.pdf, specification Version 1.0 15. TCG Trusted Network Connect Work Group: TNC IF-IMC (February 2007), http://www.trustedcomputinggroup.org/resources/tnc_ifimc_ specification, specification Version 1.2 Revision 8 16. TCG Trusted Network Connect Work Group: TNC IF-IMV (February 2007), http://www.trustedcomputinggroup.org/resources/tnc_ifimv_ specification, specification Version 1.2 Revision 8 17. TCG Trusted Network Connect Work Group: TNC Architecture for Interoperability (May 2009), http://www.trustedcomputinggroup.org/resources/tnc_ architecture_for_interoperability_specification, specification Version 1.4 Revision 4

Interoperable Remote Attestation for VPN Environments

315

18. TCG Trusted Network Connect Working Group: TNC IF-PEP: Protocol Bindings for RADIUS (February 2007), http://www.trustedcomputinggroup.org/files/ resource_files/8CC5592B-1D09-3519-AD45F0F893766F6B/TNC_IF-PEP_v1.1_ rev_0.7.pdf, specification Version 1.1 Revision 0.7 19. TCG Trusted Platform Module Work Group: TPM Main Part 2 TPM Structures (October 2006), http://www.trustedcomputinggroup.org/files/resource_ files/E14876A3-1A4B-B294-D086297A1ED38F96/mainP2Structrev103.pdf, specification Version 1.2 Level 2 Revision 103 20. TCG Trusted Platform Module Work Group: TPM Main Part 3 Commands (October 2006), http://www.trustedcomputinggroup.org/files/resource_files/ E14A09AD-1A4B-B294-D049ACC1A1A138ED/mainP3Commandsrev103.pdf, specification Version 1.2 Level 2 Revision 103 21. TCG Trusted Platform Module Work Group: TPM Main Part 1 Design Principles (July 2007), http://www.trustedcomputinggroup.org/files/resource_files/ ACD19914-1D09-3519-ADA64741A1A15795/mainP1DPrev103.zip, specification Version 1.2 Level 2 Revision 103 22. TNC at FHH Website, http://www.trust.inform.fh-hannover.de/ (accessed on 2010/08/04) 23. Trusted Computing Group: Glossary, http://www.trustedcomputinggroup.org/ developers/glossary/ (accessed on 2010/08/06)

A Novel Reputation Computing Model (Work-in-Progress) Yongzhong Zhang1, Qi Li1, and Zhangxi Lin2 1

School of Economics and Finance, Xi’an Jiaotong University Xi’an, Shaanxi, China {yzzhang,liq}@mail.xjtu.edu.cn 2 The Rawls College of Business Administration, Texas Tech University Lubbock, TX, USA [email protected]

Abstract. With the growth of e-commerce, online reputation system has become the important character in many e-commerce sites. The trust between seller and customer established relying on the reputation system. This make the fairness and accuracy of reputation computing model are very important. Current, most reputation computing models cannot reach the objectives, because they didn't consider the number of objects’ ratings. In this paper, we propose a novel computing model which use one-way random effects model. This model introduces the random effects, and considers the number of objects' ratings. the random effects is predicted by BLUP(Best linear unbiased Prediction).We have evaluated the difference of top k lists by this model from that by average model in real data sets, and proof the fairness and accuracy of this model using cases. Keywords: One-way random effects model, best linear unbiased prediction, reputation computing model, rating.

1

Introduction

In most on-line business transactions, buyers and sellers have had little information about each other. This type of business has introduced new risks: the seller might not deliver the item, or the item the buyer got might not be as the seller described [1,2]. These risks are an important restraint to the growth of on-line business [3]. One of the main methods by which e-commerce sites cut down these risks is to use reputation system. Current, most of online transactions are completed in specified promise. The reputation system plays the great role for this [4]. Many business websites, the trust between seller and customer established relying on the reputation system. For example, Amazon deployed reputation system. After every transaction is completed, the buyer has a chance to comment the seller and the product. The comments include rating and text. The range of rating is among 1 to 5, explains the comment is good or bad. The larger the rating is, the better the comment L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 316–325, 2011. © Springer-Verlag Berlin Heidelberg 2011

A Novel Reputation Computing Model

317

is. The reputation system of many business websites is similar as that of Amazon, such as ebay, Netflex and Yahoo!. According to the definition of Ref.[5], Reputation is what is generally said or believed about a person’s or thing’s character or standing. Reputation is collected and process information about one partner’s former behavior as experienced by others. Reputation systems are purposed to aggregate information about participants’ past behavior, and making people easy to choose the right object. According to a recent survey[6], models for the computing reputation can be classified into several categories, such as summation model, average model, Discrete trust model, Probabilistic/Bayesian models, Belief theory model, Networks/graphs models, and flow model. Research on the fairness of the reputation computing models include which proposes a set of mechanisms to eliminate or significantly reduce the negative effects of a fraudulent behavior [7], Ref.[8] which uses exponential smoothing policy to process and aggregate reputation information to provide sustained incentives for sellers to behave honestly over time, Ref.[9] which describes a statistical filtering technique for excluding unfair ratings by case that unfair ratings have a different statistical pattern than fair ratings. The reputation system provides the reputation scores of sellers and items to new customer. Generally the higher the item reputation scores is, the more the buyer purchase. When online user determines the item to purchase, he/she will compare different items of the same type, and decide which one will be bought. Reputation score of item or seller is the important factor which effects his/her purchasing decision. So the system accurately and fairly reflects the service of sellers and quality of items is essential. The reputation system need plays this role. That can be well to prevent the fraud. Currently, the problem of reputation computing model is that the number of items’ ratings is not considered. Because the items’ sales object to the long-tail theory, most of users aren’t concerned most of items, which make the number of most of items’ ratings very low, and only the number of small of items’ rates very high. Now, the reputation system only lists the number of items’ ratings, doesn’t correctly express the influence of the number on reputation score. For example, in Amazon site, the average rating of one item is 4.5, and the number of ratings is 3; another item, the average rating is 4, and the number of ratings is 50. The current reputation system cannot determine which reputation is better, so the user is hard to decide which one to purchase according to reputation system. To sole above problems, we use one-way random model [10,11] to calculate the reputation score. This model introduces the random effects, and considers the number of objects’ ratings. This model can estimate any number of items’ ratings. Random effects use best linear unbiased prediction (BLUP) [12] to estimate, which can get more accurate p-values, so it is statistically fair to calculate the reputation scores.

2

Model Introduction

According to Ref.[10,11], computing reputation score by One-way random effects model can be described as

318

Y. Zhang, Q. Li, and Z. Lin

y

⋯

µ

γ

ε

(1)

⋯

Where i=1, ,n, j=1, ,ni is the jth rate of ith item. n is the number of item, and ni is number of item i ratings,

is the average rating in the whole item ratings. The vector γ γ ,

item random effects. The vector ε ε ,

,ε

,γ

is

is random errors. γ and ε are

norm distribution independently as following. ~ 2.1

0,

,

~

0,

The Variance Component Estimation

Variances σ and σ are usually unknown, we can compute variances using sample data [10,11] . ∑

Let

µ

1 nn

y

∑

(2)

y

∑

1

SSW and SSB can be respectively the sum of squares due to differences within items and the sum of squares due to difference between items. Then it can be shown that 1

(3) 1

1 1 Using Formula (3) and (4), we can conclude

(4)

.

A Novel Reputation Computing Model

2.2

319

Random Effects Estimation

Random effects estimation use Best Linear Unbiased Prediction (BLUP)[12].The one way random effect model can be formulated in vector notation as follows. ,

,

where Linear model of form is considered as y

Iγ

Iµ

ε

We consider problems of prediction related to the random effects contained in γ. Under the MVN assumption (multivariate normality) | G and R are

Diagonal matrix, Diagonal elements equal to

respectively, and other elements are zero.

is

,

identity matrix.

We can conclude. (5) ε

y

y

(6)

Using formula (1),(2),(5) and (6), we can compute conclude.

. From formula (6), we can

0 So,we can conclude. 1

is the prediction of item i.

(7)

320

3

Y. Zhang, Q. Li, and Z. Lin

Experiment

The objective of experiments using a real-life data set is to show that one-way random effects model results are more intuitively correct than Average model’s. To highlight the difference between one-way random effects model and Average model, we analysis top 50 items using two models respectively. Subsequently, we show case how the results by one-way random effects model are more reasonable, with the aid of specific real-life small data sets. 3.1

Data Set

We chose the Data Set from GroupLens (www.grouplens.org) for our experiments. This data set contains ratings by users of the movie recommendation site MovieLens (www.movielens.org). There were 943 reviewers, 1682 objects (movies), and 1000,000 ratings (1-5). 3.2

Comparison of Top Reputation Lists

This part of the experiment compares difference of reputation ratings produced by the one-way random effects model and that by Average model. Because calculation methods of two modes have different, we cannot compare reputation scores produced by two models directly. To do so, we calculate top 50 reputation lists using two models respectively. Movies are ranked in descending order of its reputation scores. Because of large number of movies, the ranks may range from 1 to the thousands. For simplicity and ease of comparison, we only compare top 50 reputation lists. It is reasonable in reality life, because online users only are care about the movies in top lists.

Fig. 1. The movies of top 50 by Average model correspond to rank by one-way random effects model

A Novel Reputation Computing Model

321

We compare the rank lists assigned to each move by One-way random effects model and Average model. Figs. 1 and 2 are scatter plots of input as top 50 by Oneway random effects model and Average model respectively. A point in Fig.1 represents a movie, and x represents the rank by Average model, and y represents the rank by One-way random effects model. A point in Fig.2 represents a movie, and x represents the rank by One-way random effects model, and y represents the rank by Average model.

Fig. 2. The movies of top 50 by one-way random effects model correspond to rank by Average model

If the ranks assigned by One-way random effects model and Average model are generally similar, these points would line up along the diagonal. This is not appearance in Fig. 1 and 2. In Fig. 1, there are large variances around the diagonal. For example, points (1,363), (16,1)represent that movies may be given as extremely different ranks as 1 and 16 by Average model and 363,1 by One-way random effects model respectively. For many movies, One-way random effects model and Average model have assigned them different ranks. The front ranks see greater different than the back ranks. One possible reason could be that One-way random effects model introduces the random effects and consider the number of movies’ ratings, which make the rank of the items which have the small number and high average rating (those items have high rank by average model) sharply drop. In Fig. 2, most points line up above the diagonal. This means the most movies’ ranks are higher assigned by One-way random effects model than by Average model. The reason is random effects is introduced, which make the rank of the items which have the big number and relatively high average rating (those items have relatively high rank by average model) substantially rise.

322

Y. Zhang, Q. Li, and Z. Lin

3.3

Difference at Top k Lists

In practice, the top lists are usually very concerned. We now go on to show that there are still significant differences at the top ranks. We compare the top k lists by the one-way random effects model with that by the Average model. . In other words, we have two top k lists, V being the top k lists of the Average model, and R being the lists of one-way random effects model after deleting all movies not among the top k lists of the one-way random effects model. We use the following two well-known measures to quantify the difference of the rankings of R and V. First, Kendall’s tau metric [13,14], counts the number of pairs for which R and V disagree on two lists. As shown in formula (8). |

, |

,

|

, 1 /2

(8)

where k is the size of top k lists. i,j is item(movie). The rank of i in R is R(i), and in V , is V(i). Kendall only considers the difference of pair order in two lists. k(k-1)/2 is the maximum number of pairs. Second, Spearman’s footrule metric [13,14] counts sum of the absolute difference between R(i) and V(i) for each item i in two lists. as shown in (9). Where k is the size of top k lists. S is the maximum possible aggregate difference. When k is even, S equal to k*k/2 , and when k is odd, S equal to (k+1)(k-1)/2. For any item i, the absolute different is |R(i)-V(i)|. ∑

|

|

(9)

Two metrics output a difference value, which ranges from 0 (same list) to 1 (reversed list). Table 1 gives the different values between one-way random effects model and average model at the top k lists, where k 20,50 . Table 1. Rank difference at top k Top 20

Top 50

Kendall

0.658

0.524

Spearman

0.860

0.832

These different values are relatively high, as one-way random effects model considers the number of movies’ ratings, and results in different rank positions. These values are above 0.5 (1 as reversed list), which means ranks by one-way random effects model are very differently from by Average model. In table 1, the values computed by Spearman are larger than by Kendall, which means differences of two

A Novel Reputation Computing Model

323

lists computed by Spearman are bigger than by Kendall. The values of top 20 is larger than that of top 50, which means the difference of back lists is reduced. This result is the same as Fig. 1. Although we focus on effectiveness, and don’t consider computational complexity, we note that both one-way random effects model and Average model have almost the same computation speed. We use the thinkpad t400 as hardware platform, and write programs by SAS software. Average model complete in 36.84 seconds, and one-way random effects model complete in 73.60 seconds. So those two models have almost the similar complexity. The one-way random effects model can be used to compute the large data sets. 3.4

Small Data Sets Analysis

We now use small data sets in Amazon site to show that the rank list produced by one-way random effects model are more intuitively correct than that by average model. We analyze some cases where one-way random effects model significantly disagrees with Average model on lists. Examples explain. First, we discuss the case of Motorola milestone, whose profile is given in Table 2. This phone is assigned rank 1 by Average model and 4 by oneway random effects model (see table 3). The reason of lower rank by One-way random effects model is this phone doesn’t have enough evidence to proof it is good, because it only two ratings. Our Second case is nokia n900, whose profile is given in Table 2. This phone is assigned rank 4 by Average model and 1 by one-way random effects model (see table 3). This phone has enough evidence to proof it is good, because the number of rating 5 is 89 and the number of rating 1 is only 6. The third case is Motorola razr v3. This phone is assigned rank 9 by Average model and 10 by one-way random effects model (see table 3). This phone has enough evidence to proof it is bad, because the number of rating 5 is 55 and the number of rating 1 is 57. Table 2. Small data sets 5 star

4 star

3 star

2 star

1 star

LG KM900

1

4

0

1

0

Nokia 5800

117

69

21

18

32

Nokia N900

89

41

19

12

6

Samsung i9000

4

5

1

4

4

Nokia x6

10

8

1

2

0

HTC a6262

4

4

1

1

1

HTC diamonds

1

1

0

0

0

Motorola razr v3

55

54

29

21

57

Motorola Milestone

2

0

0

0

0

Blackberry 8900

31

9

4

2

7

324

Y. Zhang, Q. Li, and Z. Lin

Table 3. Rank lists of small data sets Average model

One-way random effects model

Motorola milestone

1

4

HTC diamonds 2

2

6

Nokia x6

3

2

Nokia N900

4

1

Blackberry 8900

5

3

Nokia 5800

6

5

lg km900

7

8

htc a6262

8

7

Motorola razr v3

9

10

Samsung i9000

10

9

We can show more that the difference between Average mode and One-way random effects model in table 2 and 3. But those are similar one of above 3 cases. To summarize, we have shown that the phone rank is dropped by One-way random effects model when this phone have not enough evidence, and the phone rank is risen when this phone have much good evidence, and the phone rank is dropped when this phone have much bad evidence. Those cases seem that rank assigned by one-way random effects model are more intuitively correct and fair than that by average model.

4

Conclusion

We have considered the problem of comparing the reputation scores of different items. We highlight the limitations of average model, which fail to take into account the number of objects’ ratings. Based on these observations, we use the One-way random effects model, which introduces the random effects, and evidence (the number of objects’ ratings) effects the rank of object. Experiments on real-life data sets show that the rank by One-way random effects model is very different from that by Average model. The case proofs that the One-way random effects model is more reasonable than Average model. Acknowledgments. This work is partially supported by Center for Advanced Analytics and Business Intelligence (CAABI) of Texas Tech University. We thank Professor Peter Westfall for valuable ideas.

A Novel Reputation Computing Model

325

References 1. Houser, D., Wooders, J.: Reputation in auctions: theory and evidence from eBay. Journal of Economics and Management Strategy 15(2), 353–369 (2006) 2. Resnick, P., Zeckhauser, R., Friedman, E., Kuwabara, K.: Reputation systems. Communications of the ACM 43(12), 45–48 (2000) 3. Fouss, F., Achbany, Y., Saerens, M.: A probabilistic reputation model based on transaction ratings. Information Sciences 180, 2095–2123 (2010) 4. Resnick, P., Zeckhauser, R.: Trust among Strangers in Internet Transactions: Empirical Analysis of eBay’s Reputation System. The Economics of the Internet and ECommerce 11, 127–157 (2002) 5. Bharadwaj, K.K., Al-Shamri, M.Y.H.: Fuzzy computation models for trust and reputation. Electronic Commerce Research and Applications 8, 37–47 (2009) 6. Jøsang, A., Ismail, R., Boyd, C.: A survey of trust and reputation systems for online service provision. Decision Support Systems 43(2), 618–644 (2007) 7. Dellarocas, C.: Immunizing online reputation reporting systems against unfair ratings and discriminatory behavior. In: Proceedings of the 2nd ACM Conference on Electronic Commerce, pp. 150–157. ACM Press, New York (2000) 8. Fan, M., Whinston, A.B.: Evaluation and design of online cooperative feedback mechanisms for reputation management. IEEE Transactions on Knowledge and Data Engineering 17(2), 244–254 (2005) 9. Withby, A., Josang, A., Indulska, J.: Filtering out unfair ratings in Bayesian reputation systems. The Icfain Journal of Management Research 4(2), 48–64 (2005) 10. Peixoto, J.L., Harville, D.A.: Comparison of Alternative Predictors Under the Balanced One-Way Random Model. Journal of the American Association Association 81(394), 431–436 (1986) 11. Donner, A.: A Review of Inference procedures for the Intraclass Correlation Coefficient in the One-way Random Effects Model. International Statistical Review 54(1), 67–82 (1986) 12. Robinson, G.K.: That BLUP is a Good Thing: The Estimation of Random Effects. Statistical Science 6(1), 15–32 (1991) 13. Dwork, C., Kumar, R., Naor, M., Sivakumar, D.: Rank Aggregation Methods for the Web. In: Proceedings of the Tenth International Conference on World Wide Web, pp. 613–622. ACM Press, Hong Kong (2001) 14. Fagin, R., Kumar, R., Sivakumar, D.: Comparing Top K Lists. SIAM J. Discrete Mathematics 17(1), 134–160 (2003)

acTvSM: A Dynamic Virtualization Platform for Enforcement of Application Integrity Ronald Toegl, Martin Pirker, and Michael Gissing Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology, Inffeldgasse 16a, A–8010 Graz, Austria {rtoegl,mpirker}@iaik.tugraz.at, [email protected]

Abstract. Modern PC platforms offer hardware-based virtualization and advanced Trusted Computing mechanisms. Hardware primitives allow the measuring and reporting of software configurations, the separation of application execution environments into isolated partitions and the dynamic switch into a trusted CPU mode. In this paper we present a practical system architecture which leverages hardware mechanisms found in mass-market off-the-shelf PCs to improve the security of commodity guest operating systems by enforcing the integrity of application images. We enable the platform administrator to freely and deterministically specify the configurations trusted. Furthermore, we describe a set of tools and operational procedures to allow flexible and dynamic configuration management and to guarantee the secure transition between trusted platform configurations. We present our prototype implementation which integrates well with established Linux distributions.

1

Introduction

The ever evolving PC platform now integrates hardware that offers enhanced security to selected services. The concept of Trusted Computing extends the standard PC architecture with trust anchors such as the Trusted Platform Module (TPM) [49]. Also, commodity platforms [23] now provide hardware Virtualization with strong isolation of partitions (i.e. virtual machines) and novel mechanisms for safer computing. These hardware primitives can be used to exactly determine the software configuration of a system. A software platform may then collect and report expressive information on its configuration - an important precondition to leverage local integrity enforcement or remote attestation in distributed systems. Unfortunately, there is little available system software employing those technologies. In recent years, a number of security-oriented virtualization platforms have been proposed or partially prototyped using specialized hypervisors (i.e. virtual machine monitors) to enable remote attestation [32,13], to protect code integrity [33,44] or to isolate critical code at runtime [20,46,16], some also employing a dynamic switch into specially protected CPU modes [45,31,30]. However, there L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 326–345, 2011. c Springer-Verlag Berlin Heidelberg 2011 

A Dynamic Virtualization Platform for Enforcement of Application Integrity

327

is currently no approach that both supports unlimited types of guest operating systems and takes advantage of hardware security features like strong memory isolation and integrity enforcement. In this paper1 , we present the acTvSM software platform which demonstrates that by a combination of up-to-date mass-market PC hardware and available open source software an enhanced security level (see Section 4.5) can be achieved. For protection at runtime our design integrates a dynamic root of trust for measurement (DRTM) with a virtualization platform offering hardware-isolation of partitions. With this platform, we restrict the execution of critical partitions to trustworthy, integrity enforced configurations. Also, our contribution includes mechanisms that allow the practical application of sealing and remote attestation by providing deterministic configuration measurements into the TPM. To this end, we modify the file system structure so that we achieve a separation of non-volatile storage into read-only, administrator-controlled areas, ephemeral in-memory space, and encrypted per-application logical volumes. Considering operational problems, we describe a set of administrative procedures and novel mechanisms which help us retain flexibility in the face of configuration changes and guarantee secure transition between trusted states. Our prototype implementation2 demonstrates good integration with established Linux distributions and does not add runtime overhead. Outline. The remainder of this paper is organized as follows: Section 2 provides an introduction to Trusted Computing, Trusted Execution and Virtualization technologies. Section 3 presents our platform architecture. We discuss its properties and describe platform operations. Section 4 details the prototype implementation of our architecture and presents performance and a security analysis. In Section 5 we discuss related work. The paper concludes in Section 6.

2

Security Mechanisms of Commodity PC Hardware

2.1

TCG’s Trusted Computing

Trusted Computing as it is available today is based on specifications of the Trusted Computing Group (TCG). The core hardware component is the Trusted Platform Module (TPM) [49]. Similarly to a smart card the TPM features tamper-resilient cryptographic primitives, but is physically bound to its host device. An integrated circuit contains implementations of public-key cryptography, key generation, cryptographic hashing, and random-number generation. With these components the TPM is able to enforce security policies on hierarchies of secret keys to protect them from software attacks by any remote attacker. A unique Endorsement Key (EK) identifies each TPM. The TPM helps to guarantee the integrity of measurements of software components by offering a set of Platform Configuration Registers (PCRs), which can 1 2

The design of the platform presented here was first sketched in [35], and the hypervisor integrity mechanisms were presented in [36]. Available for download from [34].

328

R. Toegl, M. Pirker, and M. Gissing

only be written to via the one-way extend operation. PCRs are reset to defined values at platform boot. On version 1.2 TPMs, a PCR with index i, i ≥ 0 in state t may then be extended with input x by setting P CRit+1 = SHA-1(P CRit ||x) with P CRit0

⎧ 20 ⎪ ⎨0xFF = 0x0020 ⎪ ⎩ 0x0020

17 ≤ i ≤ 22 with static boot 17 ≤ i ≤ 22 after dynamic (re-)boot else.

PCRs can be used to exactly document the software executed on a machine by implementing the transitive trust model. Here, each software component is responsible to measure the following component before invoking it. Every caller computes hash values and extends a PCR with the result, before any of this executable code is allowed to run. In the simplest case, which we call static, this is done starting from the BIOS, covering bootloader, kernel, and system libraries etc., up to application code. Ultimately, a chain of trust is established where the full Trusted Computing Base (TCB), meaning the fundamental base system which needs to be trusted, and configuration of the platform is mapped to PCR values. If such a PCR configuration fulfills the given security or policy requirements, we refer to the system state as a trusted state. The TPM can also bind data to the platform by encrypting it with a nonmigratable key, which never leaves the TPM’s protection. An extension to this is sealing, where a key may only be used with a specific PCR configuration. Thus, decryption of sealed data can be restricted to a trusted state of the computer. A current state may also be signed and quoted in the Remote Attestation protocol [48,13,40]. TPMs also provide a limited amount of non-volatile memory (NVRAM) to store user- or owner-supplied information. 2.2

Virtualization

Virtualization is a methodology of dividing the resources of a computer into multiple execution environments, by applying concepts such as time-sharing [47], hardware and software partitioning, machine simulation or emulation. Hardware architectures can be designed to offer complete virtualization [37] in hardware and then host unmodified operating systems in parallel. Only recently, the PC platform has been modified accordingly (see [1] for an overview). Commonly, virtualization is controlled by a singleton hypervisor, a superior control entity which directly runs on the hardware and manages it exclusively. It enables the creation, execution and hibernation of isolated partitions, each hosting a guest operating system and the virtual applications building on it. Such a system provides multiple isolation layers: Standard processor privilege rings and memory paging protect processes executing within a virtualization. Hardware support for monitoring all privileged CPU instructions enables the

A Dynamic Virtualization Platform for Enforcement of Application Integrity

329

hypervisor to transparently isolate virtualization instances from each other. Finally, the chipset is able to block direct memory accesses (DMA) of devices to defined physical memory areas, thus allowing the hypervisor to control device I/O. 2.3

Dynamic Switch to Trusted State

Modern platforms from AMD [2] and Intel [23] extend the basic TCG model of a static chain-of-trust anchored in a hardware reboot. They provide the option of a dynamic switch to a trusted system state. In this paper we focus on Intel’s Trusted Execution Technology (TXT), which we build our implementation on. Similar functionality is provided by AMD’s Secure Virtual Machine (SVM). A so-called late launch is initiated by the special Intel TXT CPU instruction GETSEC[SENTER]. It stops all processing cores except one. The chipset locks all memory to prevent outside modification by DMA devices and resets PCRs 17 to 22. A special Intel-provided and cryptographically signed Authenticated Code Module (ACM) starts a fresh chain-of-trust after setting the platform into a well-defined state. This provides a Dynamic Root of Trust for Measurement (DRTM). Subsequently, a Measured Launch Environment (MLE) [26] is first measured and then executed. Piece-by-piece the MLE decides which system resources to unlock and thus cautiously restores normal platform operation. The platform remembers that she is running in “secrets” mode and automatically enforces memory scrubbing whenever a system (re)boot is initiated. The ACM is also capable of enforcing specific Launch Control Policies (LCPs). Here, the ACM measures the MLE and compares it with the trusted LCP stored in the non-volatile memory of the TPM. Changes to the LCP can only be authorized by the TPM owner. Any other, not authorized software configuration is not allowed to continue; the ACM will reset the platform.

3

An Integrated Architecture for Enhanced Security on Off-the-shelf PC Platforms

In the following we present our design of the acTvSM virtualization platform, which is able to enforce the integrity of software services. It is built for flexible operation and allows for the practical protection of commodity software. 3.1

Identification of Platform Security Properties

First, we present the security goals we want to achieve and the leitmotifs we want our architecture to follow. Defined platform states. The main objective of our platform is to guarantee that only well-defined software configurations are executed. The key prerequisite for building a chain of trust that precisely describes such a software state is to start measuring from a well-defined, known secure hardware state. Intel’s

330

R. Toegl, M. Pirker, and M. Gissing

TXT with its DRTM provides exactly this. Furthermore, the advanced hardware isolation primitives of TXT platforms allow us to contain (malicious) code so that it cannot alter other partitions’ memory (and thus state). Consistent, expressive and deterministic chain-of-trust. In order to document a system’s configuration the platform must be able to account for what components are involved in the boot process. We use the TPM provided set of PCRs to guarantee the integrity and authenticity of measurements, but special care must be taken to achieve expressive PCR values. Mapping the intricacies of PC system configurations into a few PCRs is a difficult task: For a deterministic result the measurements must be stable, the number of measurements finite, and their order constant. These properties allow us to calculate the expected PCR values a priori. Only then it becomes practically feasible to seal data and the desired executable code to known-good configurations. Integrity Guarantees in Trusted States. A security sensitive application and its working data should never be stored on platform storage media in plaintext. Instead, we encrypt the file system by default, and only when the platform attains the good running configuration defined by the system administrator, access and modifications are possible. As unsealing can only occur at runtime, this prevents off-line attacks and limits attacks by running maliciously modified software. Transparent encryption implicitly provides us with integrity protection of executables and keys can be managed automatically, as they are protected by sealing. Attestation friendly. An independent remote third-party should be able to request an attestation of the services offered on the platform. Protection of privacy is an essential requirement for Remote Attestation and PCR information should not unnecessarily link the service to the platform manufacturer, owner, operator or user - instead, if an application requires this information it should explicitly and transparently to the user include it in the reporting process. The TXT measurement chain provides this separation of concerns as is starts from the ACM, identifying only the general chipset generation and the following components. Another challenge is keeping track of known-good system PCR configurations. This proves extremely challenging due to the high number of possible combinations found in today’s complex and ever-updated operating systems [18]. However, with virtualization in place the hypervisor can be assigned to perform this task. In our architecture, we choose to do measurements of complete file system images instead. We measure at file system granularity and therefore greatly simplify the comparison against known-good values. This allows practical application of Remote Attestation. Appropriate Usability. We do not want to restrict the choice of software the platform may execute. Our platform should allow to install any application and define it as trusted. In its partitions, it may also execute images which contain general purpose software, which does not require or provide elevated security levels. The overhead to maintain configuration integrity and to perform updates should be reasonable. Mechanisms to back-up applications and data must exist.

A Dynamic Virtualization Platform for Enforcement of Application Integrity

331

We believe that appropriate usability is needed for practical applications and so we target professional system administrators, who we entrust with the critical maintenance operations of the platform. 3.2

Proposed Architecture

We now outline a practical architecture for use on contemporary PC platforms. The components used in our architecture can be broken down into different blocks, namely Secure Boot, Base System, Trust Management and Virtualization partitions. Figure 1 illustrates the roles and execution flow of each of these blocks. For implementation details see Section 4. The Secure Boot block is responsible for initializing the system to a predefined configuration. This requires close cooperation of hardware and software. We use an Intel TXT enabled physical platform. Upon power-on, the platform performs a conventional boot, but does not start an operating system; instead, a Measured Launch Environment (MLE) is prepared and a TXT late launch is performed. This is accomplished by cooperation of a bootloader that prepares the system and the hardware-vendor provided Authenticated Code Module (ACM). The precise, desired software configuration can be specified by the administrator in the form of two policies stored in the TPM. The Launch Control Policy (LCP) is evaluated by the ACM and specifies which MLE is allowed to be executed. The MLE is configured with a Verified Launch Policy (VLP), which contains known-good values for measurements of the system kernel and its configuration. For the remainder of the paper we assume that the platform is built around the Linux Kernel. The temporary inmemory filesystem environment initramfs contains code and data to configure devices and to perform complex initialization operations, especially PCR extend and unsealing, early in the boot process. Thus, a secure boot is performed into a hardware guaranteed state and the chain of trust is extended over the kernel and its configuration. If the measurements do not match the expected values provided by the policies, the platform will shut down. Else, the startup code unseals the cryptographic keys needed to mount the file system which contains the Base System. Also, an unbroken chain-of-trust is ensured by measuring the filesystem image of the Base System into a PCR before it is mounted. Together with the kernel, the Base System takes the role of the hypervisor. It manages the hardware, provides virtualization services to virtual applications and protects their integrity at run-time. As a critical component, it must be a mature, reliable technology and actively maintained with regular security updates. To support deterministic PCR measurement, the Base System file system must be read-only. A seemingly contradiction is the requirement of a read-write file system for Linux platform operation. To solve this dilemma, we merge a ephemeral file system with the measured image. As changes to the Base System do not survive a reboot of the platform - except by explicit patching or system update (see Section 3.3) - this ensures robustness of the base system image to malicious modifications.

332

R. Toegl, M. Pirker, and M. Gissing

Unseal

App Late Launch Bootloader Boo Power on

Unseal

initramfs

App

…

App

TVAM Base System

Measure

BIOS

MLEE ACM

Linux Kernel with KVM

Measure

Chipset, Ch hips CPU & TPM

t Fig. 1. Overview of the interaction of the main components of the platform. Trusted components are green, untrusted are red. The timeline indicates the different phases of platform boot and operations.

Management of the virtual applications itself is done by a component called TVAM, the Trusted Virtual Application Manager. It is the central component which manages the import, initialization, startup, cleanup etc. of virtual applications. The images only exist encrypted on storage media. The cryptographic key to decrypt and run a specific application is sealed to a specific system (PCR) configuration. TVAM therefore unseals key data, and if the system is in exactly the trusted configuration, TVAM is able to startup a virtualization partition, mount it and execute the desired application. Another task of TVAM is to calculate future trusted states, prepare the necessary policies and to reseal data and keys. Virtualization Partitions. may host any system normally running standalone. This can be a unmodified out-of-the-box Linux or Windows system, or a special purpose system. Multiple partitions can be started in parallel, connected by network interfaces. This allows to set-up multiple services. TVAM is capable of continuing the chain-of-trust into the application layer by measuring virtual partition images before start. However, if stable PCR measurements are expected the image must be read-only with read-write storage provided externally. 3.3

Operating the Platform

In the previous section, we outlined the basic components for booting the system and starting one or more partition. We now identify and describe basic platform operations which allow the initialization and long-term maintenance of our setup. Installation. In order to start from an initial trusted state the software needs to be distributed on a trusted medium. A root of trust for installation can be ensured by read-only media such as CD-ROM and appropriate organizational

A Dynamic Virtualization Platform for Enforcement of Application Integrity

333

measures. Once booted from it, the installation routine wipes the system’s harddisk(s) and installs a default configuration of the platform. Immediately, the measurement values for the MLE, the platform’s filesystem, kernel and initial ramdisk are calculated and appropriate policies are stored in the TPM. Already in this early stage, the platform is ready to do its first reboot into trusted mode. Update and Application Mode. After a successful late launch, the platform runs in Update Mode, where it waits for maintenance commands. In Update Mode the platform is capable of upgrading software packages. At the end of this process, the same procedure is triggered that was run during installation. If no external login attempt is received, the platform switches into Application Mode. In this mode TVAM unseals the decryption key of application images and mounts them. TVAM then extends a PCR to document the state transition and finally starts the applications. Base System Update and Resealing. In Update Mode the platform is capable of upgrading software packages of the base system. A remote administrator can login and update the system as needed. After that, the base system image is assembled, compressed and linked in the bootloader menu. As all data blobs holding the decryption keys for the application partitions are sealed to the old platform state, they must be (re)sealed to the new one. If the kernel or its initramfs was updated, a new VLP is written into the TPM. This also applies to a MLE update, where a new LCP needs to be written. Small Updates. The full update procedure outlined in the previous paragraph may be cumbersome for minor configuration changes such as a change of a static IP address in some configuration file. Instead, a “patch” facility allows the remote administrator to provide a patch file on a separate partition. The authenticity of the patch is guaranteed by a cryptographic signature added by the administrator - the certificate to validate it is contained within the platform image. Upon next full system update these patches are automatically integrated into the system. This mechanism allows for small bug fixes and easy distribution of pre-configured system platform images for instance in homogeneous datacenters, where machines only vary in small configuration details. Application management. TVAM provides a comprehensive feature set for the management of application images. This allows the import, backup and deletion of images, along with the required encryption and TPM (un)sealing operations. The simplest way to install an application image is to import a raw disk image. This allows the convenient creation and customization of virtual applications on remote hosts. TVAM will create an encrypted storage space and copy the raw data to it. The access secret is sealed to the trusted platform configuration and stored. Since our architecture can handle multiple secrets for each encrypted disk, the administrator can also provide a backup secret, which can be stored securely, i.e. on a smart card. This allows the administrator to decrypt the image even in case the TPM would be damaged or failed. This flexibility is also useful for migrating an image to a different machine.

334

R. Toegl, M. Pirker, and M. Gissing

External Reboot. A remote way to force a reboot of the platform is an important feature for administration. Intel TXT capable platforms are usually combined with a set of features called Intel Active Management Technology (AMT) [24]. AMT allows, amongst other features, externally triggered reboots as well as serial console redirection via a network connection. A reboot will cause the platform to boot into a trusted state, regardless of the runtime state it was before. In some environments this may be warranted at a regular basis to limit the attack surface. Trusted Administration Channel. The Administrator can access the platform via SSH in Update Mode. Remember that a policy update process requires the TPM owner password. Before the administrator provides this password, she a) must confirm that she is connected to the right platform and b) that the platform is in the correct Update Mode configuration. The first constraint demands that the client must verify that the server always presents the same trusted public key. Second, we seal the SSH daemon’s private key to Update Mode. If no external log-in attempt is received, the platform switches into Application Mode. This is performed as follows. The SSH daemon is stopped and its private key is removed, and the PCRs are extended to document the state transition and prevent further access to the TPM sealed blobs. Finally, applications are started.

4

Implementation

We assembled a prototype of the platform described in Section 3. The following subsections give an in-depth description of implementation details and our storage management concept and provide a security analysis. 4.1

Components

In theory, any Linux distribution can be customized for our architecture. In practise, a substantial number of patches and changes were needed to assemble a working prototype and available Trusted Computing utilities needed modifications. Secure boot is accomplished by using a standard bootloader (GRUB3 ) along with SINIT and tboot [25]. SINIT is Intel’s implementation of an ACM, while tboot is Intel’s prototype implementation of an MLE (see Section 2.3). Upon boot GRUB loads SINIT, tboot, the kernel and its initramfs into memory and executes tboot, which sets up the ACM and then late-launches into it. The authenticity and integrity of the ACM code is guaranteed under an Intel private key, of which the public part is hardwired into the chipset. The ACM’s task is then to measure the tboot binary and compare it to the LCP. Tboot takes over and continues to measure the kernel and initramfs and compares them against the VLP. Once the integrity of the kernel and its environment has been assured, control is passed to it and the standard boot process continues. Customized 3

http://www.gnu.org/software/grub/

A Dynamic Virtualization Platform for Enforcement of Application Integrity

335

64-bit ports of tools from IBM’s TPM-utils[41] provide the PCR extend and unsealing capabilities in the initial ramdisk (initramfs) environment. In our architecture, we use a customized Linux operating system augmented with the Kernel-based Virtual Machine (KVM) [38,28] hypervisor module, which is fully maintained in mainline Linux. KVM can run multiple virtual machines on x86 CPUs equipped with virtualization mode extensions. It extends the Linux Kernel to offer, besides the existing Kernel and User modes, an additional Guest process mode. Each virtual machine offers private virtualized hardware like a network card, hard disk, graphics adapter, etc. Those virtual devices are forwarded to QEMU [6], a fast software emulator. QEMU can emulate all standard hardware devices of a x86 platform, including one or several processors. For the Base system, we use packages from the x86 64 Debian Linux lenny4 release. It acts as the host for the virtualization partitions. This is a pragmatic choice for a robust base system, as Debian is known for its emphasis on a stable code base, frequent security releases and conservative approach to adding immature features. To support current Trusted Computing and virtualization hardware we need to add selected packages from the Debian testing tree. For example, only Linux kernels 2.6.32 or newer integrate Intel TXT support and drivers for chipsets that implement it. Scripts for installation, initial ramdisk management and rebuilding of the Base System image are taken from Debian and customized to our needs. The system bootstrap scripts for creation of distributable and bootable CDs for initial installation are taken from GRML Linux5 , a distribution specialized for system administrators. The runtime architecture of our platform is outlined in Figure 2. After successful boot, the architecture supports several virtual applications. Raw hard disk storage space and the hardware TPM are assigned to the emulated hardware provided to each virtual application. The implementation of the Trusted Virtual Application Manager in the Base System is scripted in the Ruby language. TVAM offers operations to define new trusted system states and re-seal the base system and applications to them. It also adds and removes system states from the list of trusted states in the launch policies. It allows to import an application image into the platform, start, stop, list and remove virtual applications. The more complex operations such as calculating trusted states, sealing, unsealing or policy creation and storage in TPM NV-RAM are performed by jTpmTools and jTSS from IAIK’s “Trusted Computing for Java“ project [34]. After boot, PCR 17 holds the LCP and details on the MLE [26]. PCR 18 contains the measurements (hashes) of MLE and kernel module and the respective command lines (4 hashes). PCRs 19-22 contain the elements described in the VLP - the modules defined in the bootloader configuration (kernel, SINIT module, tboot binary and initramfs). The read-only image of the Base System is extended to PCR 14. PCR 13 is assigned for the measurement of virtual applications. We use PCR 15 to indicate the transition from Update to Application 4 5

http://www.debian.org/releases/lenny/ http://grml.org/

336

R. Toegl, M. Pirker, and M. Gissing

Virtual Application Guest Mode

Normal User User Process

1:*

Guest Mode

App

App

OS

OS

QEMUI/O

QEMUI/O

TVAM

LinuxKernel

KVMDriver 1:1

Hardware

Fig. 2. The hardware platform consists of RAM, CPU, TPM and harddisk storage. KVM/QEMU runs applications providing isolated memory and defined storage areas. TVAM is the process that manages the base system configuration and set-up, start and tear-down of applications. The hardware TPM can be forwarded to applications.

Mode. These state descriptions can be used to seal data, especially file system encryption keys, to known good values in all phases of the boot process. 4.2

Disk Storage Management

We use a complex disk layout with different file systems to create a measurable platform. Such a on-disk structure is automatically generated at initial installation and maintained by the TVAM. An exemplary layout of our architecture’s structures is depicted in Figure 3. In the example, the system harddisk is /dev/sda and divided into two partitions. The first partition (sda1) contains a read-write filesystem hosting all the components necessary for the platform boot process. This encompasses the bootloader, tboot, SINIT and Linux kernel plus associated initramfs images. The

A Dynamic Virtualization Platform for Enforcement of Application Integrity

337

/dev/sda /dev/sda1

/dev/sda4

ext3

lvm physical volume

/boot

lvm volume group STORELV

LOGLV

ASCLV

ASLV

AGCLV

BSLV

ext3

ext3

LUKS

LUKS

LUKS

LUKS

ext3

raw

ext3

squashFS q

config

image

config

/

/store/

LUKS

ext3

BSLV LUKS

ext3

asckb/ askb/

/var/log agckb/ overlay/

one application one application one application one application

Fig. 3. The detailed disk layout of the platform. All trusted code and data of the base system and of the virtual applications is stored on logical volumes (LV) and sealed to PCR states. See Section 4.2 for a detailed description and explanation of the acronyms.

remainder of the harddisk storage (sda4) is allocated as a Logical Volume Manager (LVM)6 dynamically managed space, which is assigned to a single LVM volume group. This volume may be assembled from multiple physical volumes distributed over multiple physical disks, enabling online resizing and RAID technologies. The LVM managed volume group contains both plaintext and encrypted logical volumes (LVs). These block devices are transparently encrypted with Linux kernel’s dm-crypt subsystem. Each LV contains either a file system for use on the platform, or raw storage which is assigned to, and managed by, virtual partitions. dm-crypt encrypts block devices with symmetric AES keys, called masterkeys. Each encrypted LV contains a Linux Unified Key Setup (LUKS) [19] partition header, which is responsible for key management. LUKS provides 8 key slots that encrypt the same masterkey with different access secrets. If a client knows one correct secret for one of the key slots, it may decrypt and access the data. This abstraction layer adds flexibility and provides several advantages: The masterkey can be generated with high entropy, independent of user input or password memorization. Key slot secret changes do not require re-encryption of the whole block device. Key slots can also be assigned to maintenance processes, such as 6

http://sourceware.org/lvm2/

338

R. Toegl, M. Pirker, and M. Gissing

backup. The plaintext logical volume STORELV contains the TPM sealed data structures holding the primary access secrets for the encrypted logical volumes. As a running Linux system requires some writable file system, the root ”/“ file system of the platform is assembled from multiple layers via aufs7 . Figure 4 illustrates this process which is performed at boot time. Base System Logical Volumes BASELV contain compressed read-only squashfs images which contain binaries and configuration files of the Base System. They are measured by initramfs. aufs merges this squashfs with an in-memory tmpfs to provide writable, but ephemeral storage. In addition, we copy administrator signed configuration patches from STORELV, after verification of the signature. Thus, we create a runtime read-write file system which is based on authenticated images with robust and deterministic hash values. In Update Mode, we can even create these images and pre-calculate their expected measurement values in situ. This unique feature enables our platform to update from one trusted configuration to another without exposing sealed data. overlay.tar.gz etc/

BSLV LUKS

merge aufs

squashFS ext3

memory tmpfs

copy

/ … etc/

/

/

… read only

read/write /

Fig. 4. The writable platform root file system is merged at boot time from a read-only static image and an in-memory file system. An authentic configuration patch for minor adjustments is integrated.

In the scenario of a service that encompasses multiple partitions running in parallel, i.e. a webservice front-end, a database partition and a firewall partition, configuration files for such application groups are stored in the Application Group Specific Configuration Logical Volume AGCLV. The configurations 7

http://aufs.sourceforge.net/

A Dynamic Virtualization Platform for Enforcement of Application Integrity

339

specify which virtual partitions are to be started, which platform resources are assigned to them, and how they interconnect. Each Application Specific Logical Volume ASLV contains one virtual partition application image. The configuration in the AGCLV specifies if additional logical volumes containing Application Specific Configuration data ASCLV (or simply more mass storage) are attached. The LOGLV keeps system logs. 4.3

Performance

The prototype size of the Base System installation image is 402 MB. We use a HP dc79008 with Intel Core 2 Duo E8400 CPU clocked at 3GHz, 4GB RAM, Intel Q45 Express Chipset and Infineon TPM 1.2 as reference platform. Installation and setting up the encrypted file systems on such a system is done in just under 15 minutes. The measurement and integrity enforcing mechanisms of our platform are only performed at boot time, which takes 57 seconds from power-on to displaying the login-prompt. The added delay by the late launch at boot time is 5 seconds. The Base System kernel boot time and runtime performance of applications is not different to what can be expected from a Linux/KVM platform with hard disk encryption done in software and QEMU device emulation and not influenced by our measurement and boot-time enforcement process. 4.4

Shared TPM Access

Several different services may access the singleton TPM. The Base System needs the hardware TPM only at start-up. After that, it can be assigned to application partitions, one at a time. We enhanced QEMU to allow byte stream forwarding to the /dev/tpm interface in the base system in a non-blocking manner. Consequently, one virtualized partition can run Trusted Computing applications at a time. More general approaches have been proposed to solve multiplexing of the hardware TPM for multiple partitions, for example virtual software TPMs [7,43]. Full support in the acTvSM platform is planned for future work. 4.5

Security Analysis

The previous sections gave an overview of the workings of our platform. In this section we reflect on several of the security design features, their consequences and countermeasures. Attacker Model. As we base our platform on TCG’s TPM and Intel’s TXT technology our assumptions on the adversary and possible attacks closely follow those of the hardware designers [23]. Attackers will attempt either to modify the state measurements, extract cryptographic materials from hardware, manipulate code execution, or attempt control of the base platform or the applications executing on top of it. Commodity devices can only be assumed to protect against 8

Note that in our experiments some other hardware platforms suffered permanent damage during late launch due to BIOS bugs.

340

R. Toegl, M. Pirker, and M. Gissing

very simple hardware attacks. Hardware security therefore depends on physical access control and diligent operational procedures in datacenters and other deployment scenarios. Thus, we consider software and network attacks only. Further, attackers are also assumed to have control over external network traffic, but are unable to break cryptography [14]. Also, we do not consider side effects of System Management Mode (SMM), the overruling processor mode for low-level system event management by the BIOS. In contrast to TCG’s security model we fully trust the system administrator to handle and back-up secrets and key material of the platform and of applications. Security Analysis. Our platform does not protect all data on the system at all times. However, the TPM protects the sensitive cryptographic data (keys) that the platform uses to guarantee the integrity of itself and of the applications. The platform fully utilizes the hardware based PCR mechanisms that protect measurements in the chain-of-trust of the components booted. Thus, a malicious boot with a following attempt to start a virtual application will fail if any part in the chain of trust was modified. Therefore, our platform can ensure that a trusted system state is reached after boot. However, the general time-of-check-time-of-use [8] problem remains: As the security of a program is in general undecidable, successful runtime attacks cannot be ruled out. Still, they are much more difficult to perform in our architecture when compared to systems without TXT based integrity enforcement. Within each partition, priviledged system software supports normal user applications which communicate to the outside. Security history suggests that (almost) any application can be exploited remotely and taken control of. The malicious elevation of application privileges to system privileges may follow. Horizontally, such a compromised partition will be contained by the Intel VT feature. Vertically, attackers could further attempt to jail-break from the KVM/QEMU environment, the security of which is not easy to assess: KVM itself is a rather small piece of code encouraging security evaluation, but QEMU, which provides the emulation for devices associated with a KVM instance is more complex. Further, QEMU runs as standard user process in the base system and is not hardware isolated. Naturally, the more devices are emulated by QEMU, the higher is the possibility of a bug which would allow tampering. If an attacker succeeds as far as obtaining root privileges in the Base System layer, access to the encrypted application file images currently mounted at that time is possible, as the required key material is kept in kernel memory. Still, a security break-out would not be able to permanently modify the Base System, since updating the secure boot chain to a new configuration requires a rewrite of the policies in the TPM, which can only be performed with TPM owner permission. However, the owner password is neither stored on the system nor transmitted in clear text. The next reboot will either restore a trusted state or fail. Therefore, our platform empowers the administrator to freely define what is known-good and trusted. It also clearly defines the boundaries of each service, so that those exposed interfaces can be inspected meticulously. We believe that this

A Dynamic Virtualization Platform for Enforcement of Application Integrity

341

allows an structured approach for forming an informed opinion on the security of specific configurations and enforcing it in practice.

5

Related Work

Security critical code can be isolated using hardware security co-processors [3], like the IBM 4758 [15]. An early example of extending the trust from dedicated hardware security modules into applications is given in the Dyad System [50]. AEGIS [4] is an early mechanism to support secure boot on PC platforms assuming a trusted BIOS. The Enforcer platform [29] and IBM’s Integrity Measurement Architecture [42] show how to integrate TCG-style static measurements into the Linux environment. While this collects precise information, it does not always allow to identify a limited number of possibly good configurations. Instead of individual files, file system images have been used to transport user software and data with SoulPads [10] or Secure Virtual Disk Images in grid services [22] between platforms. Early demonstration of a system that makes use of the advantages of virtualization for security and trust are PERSEUS [33] and Terra [20]. The Nizza virtualization architecture [46] extracts security critical modules out of legacy applications, transferring them into a separate, trusted partition with a small TCB. None of these platforms relied on the TPM. Microsoft’s now apparently inactive NGSCB [17] envisioned the security critical Nexus kernel to provide an environment for security critical services, while running a legacy OS in parallel. The EMSCB [16] platform demonstrates TPMbased Trusted Computing on an L4-based virtualization platform. The OpenTC [32] project demonstrated a system based on a static chain-of-trust from the BIOS to the bootloader via Trusted Grub to Xen [5] or L4 hypervisors, and into application partitions measured and loaded from CD images. An example of a trusted installation medium is described in [12]. [13] describe a Xen-based platform which is focussed on Remote Attestation. Schiffman et al. [44] describe an all-layer (Xen hypervisor to application) integrity enforcement and reporting architecture for distributed systems. Cabuk et al. [9] propose to use a softwarebased root of trust for measurement to enforce application integrity in federated virtual platforms, i.e. Trusted Virtual Domains [11]. Other recent proposals have directly supported hardware virtualization or a dynamic switch to a trusted system state. Vasudevan et al. [51] discuss general requirements for such systems. BIND [45] uses AMD’s Secure Virtual Machine (SVM) [2] protection features to collect fine grained measurements on both input and the code modules that operate on it so that the computation results can be attested to. Flicker [31] isolates sensitive code by halting the main OS, switching into AMD SVM, and executing with a minimal TCB small, short-lived pieces of application logic (PALs). PALs may use the TPM to document their execution and handle results. TrustVisor [30] is a small hypervisor initiated via the DRTM process. It assumes full control and allows to manage, run and attest multiple PALs in its protection mode, however without the repeated DRTM mode switch

342

R. Toegl, M. Pirker, and M. Gissing

costs incurred by the Flicker approach. Intel’s P-MAPS [39] launches a tiny hypervisor parallel to a running OS to protect process integrity, hidden from the OS. The hypervisor authenticates code and data areas, which are protected inplace and can only be accessed via well-defined interfaces. LaLa [21] performs a late launch from an instant-on application to boot a fully fledged OS in the background. OSLO [27] is an OS loader module which implements a dynamic switch to a measured state in the OS bootchain on AMD SVM systems.

6

Conclusions

In this paper we present a practical architecture for mass-market off-the-shelf PC hardware that combines Trusted Computing and hardware virtualization to provide a platform that offers integrity guarantees to the applications and services it hosts. Our architectures achieves a distinct set of characteristics, the combination of which sets it apart from previous results. We take advantage of Intel TXT to shorten the chain-of-trust and make use of the KVM hypervisor to separate service partitions. This choice of virtualization technology frees us from restrictions in the choice of guest operating systems and at the same time isolates memory areas of virtual applications by hardware mechanisms. While other approaches measure the executed binaries only on fragment ([45,31,30]), or process ([39]) granularity, we measure a structured set of file systems. This contribution simplifies the problem of defining known good states and allows to do integrity enforcement in practical scenarios. Besides just sealing to current states, our architecture allows to calculate future trusted configurations, with trusted state transitions that do not expose data. We empower administrators to easily customize and update the platform offered and to enforce these configuration. Our prototype implementation shows that any OS or application can be run inside the partitions, and that commodity Linux distributions can be adapted this way.

Acknowledgments ¨ This work was supported by the Osterreichische Forschungsf¨ orderungsgesellschaft (FFG) through project acTvSM, funding theme FIT-IT, no. 820848. We thank Andreas Niederl and Michael Gebetsroither for insightful discussions and their help in implementing the prototype and the anonymous reviewers for their helpful comments on the paper.

References 1. Adams, K., Agesen, O.: A comparison of software and hardware techniques for x86 virtualization. In: Proceedings of the 12th International Conference on Architectural Support for Programming Languages and Operating Systems, pp. 2–13. ACM, San Jose (2006)

A Dynamic Virtualization Platform for Enforcement of Application Integrity

343

2. Advanced Micro Devices: AMD64 Virtualization: Secure Virtual Machine Architecture Reference Manual (May 2005) 3. Anderson, R., Bond, M., Clulow, J., Skorobogatov, S.: Cryptographic processors-a survey. Proceedings of the IEEE 94(2), 357–369 (2006), doi:10.1109/JPROC.2005.862423 4. Arbaugh, W.A., Farber, D.J., Smith, J.M.: A secure and reliable bootstrap architecture. In: Proceedings of the 1997 IEEE Symposium on Security and Privacy, p. 65. IEEE Computer Society, Los Alamitos (1997) 5. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., Warfield, A.: Xen and the art of virtualization. In: SOSP 2003: Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles, pp. 164–177. ACM, New York (2003) 6. Bellard, F.: Qemu, a fast and portable dynamic translator. In: ATEC 2005: Proceedings of the annual conference on USENIX Annual Technical Conference, p. 41. USENIX Association, Berkeley (2005) 7. Berger, S., C´ aceres, R., Goldman, K.A., Perez, R., Sailer, R., van Doorn, L.: vTPM: virtualizing the trusted platform module. In: USENIX-SS 2006: Proceedings of the 15th Conference on USENIX Security Symposium, pp. 305–320 (2006) 8. Bratus, S., D’Cunha, N., Sparks, E., Smith, S.W.: Toctou, traps, and trusted computing. In: Lipp, P., Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 14–32. Springer, Heidelberg (2008) 9. Cabuk, S., Chen, L., Plaquin, D., Ryan, M.: Trusted integrity measurement and reporting for virtualized platforms. In: Chen, L., Yung, M. (eds.) INTRUST 2009. LNCS, vol. 6163, pp. 180–196. Springer, Heidelberg (2010) 10. C´ aceres, R., Carter, C., Narayanaswami, C., Raghunath, M.: Reincarnating pcs with portable soulpads. In: Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services, pp. 65–78. ACM, Seattle (2005) 11. Catuogno, L., Dmitrienko, A., Eriksson, K., Kuhlmann, D., Ramunno, G., Sadeghi, A.R., Schulz, S., Schunter, M., Winandy, M., Zhan, J.: Trusted virtual domains - design, implementation and lessons learned. In: Chen, L., Yung, M. (eds.) INTRUST 2009. LNCS, vol. 6163, pp. 156–179. Springer, Heidelberg (2010) 12. Clair, L.S., Schiffman, J., Jaeger, T., McDaniel, P.: Establishing and sustaining system integrity via root of trust installation. In: Computer Security Applications Conference, Annual, pp. 19–29 (2007) 13. Coker, G., Guttman, J., Loscocco, P., Sheehy, J., Sniffen, B.: Attestation: Evidence and trust. In: Chen, L., Ryan, M.D., Wang, G. (eds.) ICICS 2008. LNCS, vol. 5308, pp. 1–18. Springer, Heidelberg (2008), http://dx.doi.org/10.1007/ 978-3-540-88625-9_1 14. Dolev, D., Yao, A.C.: On the security of public key protocols. IEEE Transactions on Information Theory (1981) 15. Dyer, J., Lindemann, M., Perez, R., Sailer, R., van Doorn, L., Smith, S.: Building the ibm 4758 secure coprocessor. Computer 34(10), 57–66 (2001) 16. EMSCB Project Consortium: The European Multilaterally Secure Computing Base (EMSCB) project (2004), http://www.emscb.org/ 17. England, P., Lampson, B., Manferdelli, J., Willman, B.: A trusted open platform. Computer 36(7), 55–62 (2003) 18. England, P.: Practical techniques for operating system attestation. In: Lipp, P., Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 1–13. Springer, Heidelberg (2008)

344

R. Toegl, M. Pirker, and M. Gissing

19. Fruhwirth, C.: New methods in hard disk encryption. Tech. rep., Institute for Computer Languages, Theory and Logic Group, Vienna University of Technology (2005), http://clemens.endorphin.org/publications 20. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: A virtual machine-based platform for trusted computing. In: Proceedings of the 19th Symposium on Operating System Principles(SOSP 2003), pp. 193–206. ACM, New York (October 2003) 21. Gebhardt, C., Dalton, C.: Lala: a late launch application. In: Proceedings of the 2009 ACM Workshop on Scalable Trusted Computing, pp. 1–8. ACM, Chicago (2009) 22. Gebhardt, C., Tomlinson, A.: Secure Virtual Disk Images for Grid Computing. In: 3rd Asia-Pacific Trusted Infrastructure Technologies Conference (APTC 2008). IEEE Computer Society, Los Alamitos (October 2008) 23. Grawrock, D.: Dynamics of a Trusted Platform: A Building Block Approach. Intel Press, Hillsboro (February 2009) ISBN: 978-1934053171 24. Intel Corporation: Intel active management technology (amt), http://www.intel. com/technology/platform-technology/intel-amt/index.htm 25. Intel Corporation: Trusted Boot (2008), http://sourceforge.net/projects/ tboot/ 26. Intel Corporation: Intel Trusted Execution Technology Software Development Guide (December 2009), http://download.intel.com/technology/security/ downloads/315168.pdf 27. Kauer, B.: Oslo: improving the security of trusted computing. In: SS 2007: Proceedings of 16th USENIX Security Symposium on USENIX Security Symposium, pp. 1–9. USENIX Association, Berkeley (2007) 28. Kivity, A., Kamay, V., Laor, D., Lublin, U., Liguori, A.: kvm: the Linux Virtual Machine Monitor. In: OLS 2007: Proceedings of the Linux Symposium, pp. 225–230 (2007) 29. Marchesini, J., Smith, S., Wild, O., MacDonald, R.: Experimenting with tcpa/tcg hardware, or: How i learned to stop worrying and love the bear. Tech. rep., Department of Computer Science/Dartmouth PKI Lab, Dartmouth College (2003) 30. McCune, J.M., Li, Y., Qu, N., Zhou, Z., Datta, A., Gligor, V., Perrig, A.: TrustVisor: Efficient TCB reduction and attestation. In: Proceedings of the IEEE Symposium on Security and Privacy (May 2010) 31. McCune, J.M., Parno, B.J., Perrig, A., Reiter, M.K., Isozaki, H.: Flicker: an execution infrastructure for tcb minimization. In: Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pp. 315–328. ACM, Glasgow (2008) 32. OpenTC Project Consortium: The Open Trusted Computing (OpenTC) project (2005-2009), http://www.opentc.net/ 33. Pfitzmann, B., Riordan, J., Stueble, C., Waidner, M., Weber, A., Saarlandes, U.D.: The perseus system architecture (2001) 34. Pirker, M., Toegl, R., Winkler, T., Vejda, T.: Trusted computing for the JavaT M platform (2009), http://trustedjava.sourceforge.net/ 35. Pirker, M., Toegl, R.: Towards a virtual trusted platform. Journal of Universal Computer Science 16(4), 531–542 (2010), http://www.jucs.org/jucs_16_4/ towards_a_virtual_trusted 36. Pirker, M., Toegl, R., Gissing, M.: Dynamic enforcement of platform integrity (a short paper). In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 265–272. Springer, Heidelberg (2010)

A Dynamic Virtualization Platform for Enforcement of Application Integrity

345

37. Popek, G.J., Goldberg, R.P.: Formal requirements for virtualizable third generation architectures. Commun. ACM 17(7), 412–421 (1974) 38. Qumranet: KVM - Kernel-based Virtualization Machine (2006), http://www. qumranet.com/files/white_papers/KVM_Whitepaper.pdf 39. Ravi Sahita, U.W., Dewan, P.: Dynamic software application protection. Tech. rep., Intel Corporation (2009), http://blogs.intel.com/research/ trusted%20dynamic%20launch-flyer-rlspss_001.pdf 40. Sadeghi, A.R., St¨ uble, C.: Property-based attestation for computing platforms: caring about properties, not mechanisms. In: Hempelmann, C., Raskin, V. (eds.) NSPW, pp. 67–77. ACM, New York (2004) 41. Safford, D., Kravitz, J., Doorn, L.v.: Take control of tcpa. Linux Journal (112), 2 (2003), http://domino.research.ibm.com/comm/research_projects. nsf/pages/gsal.TCG.html 42. Sailer, R., Zhang, X., Jaeger, T., van Doorn, L.: Design and implementation of a TCG-based integrity measurement architecture. In: Proceedings of the 13th USENIX Security Symposium, USENIX Association, San Diego (2004) 43. Scarlata, V., Rozas, C., Wiseman, M., Grawrock, D., Vishik, C.: Tpm virtualization: Building a general framework. In: Pohlmann, N., Reimer, H. (eds.) Trusted Computing, pp. 43–56. Vieweg (2007) 44. Schiffman, J., Moyer, T., Shal, C., Jaeger, T., McDaniel, P.: Justifying integrity using a virtual machine verifier. In: ACSAC 2009: Proceedings of the 2009 Annual Computer Security Applications Conference, pp. 83–92. IEEE Computer Society, Washington, DC, USA (2009) 45. Shi, E., Perrig, A., Van Doorn, L.: Bind: a fine-grained attestation service for secure distributed systems. In: 2005 IEEE Symposium on Security and Privacy, pp. 154–168 (2005) 46. Singaravelu, L., Pu, C., H¨ artig, H., Helmuth, C.: Reducing TCB complexity for security-sensitive applications: three case studies. In: EuroSys 2006: Proceedings of the ACM SIGOPS/EuroSys European Conference on Computer Systems 2006, pp. 161–174. ACM, New York (2006) 47. Strachey, C.: Time sharing in large, fast computers. In: IFIP Congress (1959) 48. Trusted Computing Group: TCG infrastructure specifications, https://www. trustedcomputinggroup.org/specs/IWG/ 49. Trusted Computing Group: TCG TPM specification version 1.2 revision 103 (2007) 50. Tygar, J., Yee, B.: Dyad: A system for using physically secure coprocessors. In: Technological Strategies for the Protection of Intellectual Property in the Networked Multimedia Environment, pp. 121–152. Interactive Multimedia Association (1994) 51. Vasudevan, A., McCune, J.M., Qu, N., van Doorn, L., Perrig, A.: Requirements for an Integrity-Protected Hypervisor on the x86 Hardware Virtualized Architecture. In: Acquisti, A., Smith, S.W., Sadeghi, A.-R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 141–165. Springer, Heidelberg (2010)

Software, Vendors and Reputation: An Analysis of the Dilemma in Creating Secure Software Craig S. Wright School of Computing and Mathematics Charles Sturt University Wagga Wagga, NSW, Australia [email protected]

Abstract. Market models for software vulnerabilities have been disparaged in the past citing how these do little to lower the risk of insecure software. This leads to the common call for yet more legislation against vendors and other producers in order to lower the risk of insecure software. We argue that the call for nationalized intervention does not decrease risk, but rather the user of software has an economic choice in selecting features over security. In this paper, we investigate the economic impact of various decisions as a means of determining the optimal distribution of costs and liability when applied to information security and in particular when assigning costs in software engineering. The users of a software product act rationally when weighing software risks and costs. The choice of delivering features and averting risk is not an option demanded by the end user. After all, it is of little value to increase the cost per unit of software if this means that users purchase the alternative product with more features. We argue that the market models proposed are flawed and not the concept of a market itself. Keywords: Security, Derivatives, Vulnerability Market, Software Development, Game theory, SDLC (Software Development Life Cycle), DMCA (Digital Millennium Copyright Act), IDS (Intrusion Detection System), MTTF (Mean Time To Failure), Ploc (per (source) Lines of Code).

1 Introduction This paper seek to argue that a well-defined software risk derivative market would improve the information exchange for both the software user and vendor removing the oft touted imperfect information state that is said to belie the software industry. In this way, users could have a rational means of accurately judging software risks and costs and as such the vendor could optimally apply their time between delivering features and averting risk in a manner demanded by the end user. After all, it is of little value to increase the cost per unit of software by more than an equal compensating control. Arora, Telang and Xu [2, 3] asserted that a market based mechanism for software vulnerabilities will necessarily underperform a CERT-type mechanism. The market that they used was a game theoretic pricing game [14]. In the model reported, the L. Chen and M. Yung (Eds.): INTRUST 2010, LNCS 6802, pp. 346–360, 2011. © Springer-Verlag Berlin Heidelberg 2011

Software, Vendors and Reputation: An Analysis of the Dilemma

347

players in the market do not report their prices1. These players use a model where information is simultaneously distributed to the client of the player and the vendor. The CERT model was touted as being optimal. It relies on waiting until a patch was publically released and only then releasing the patch to the public. This ignores many externalities and assumes the only control is a patch in place of other alternative compensating controls. Consequently, the examined "market" model is in itself sub-optimal. It both creates incentives to leak information without proper safeguards and creates vulnerability black-markets. As criminal groups and selected security vendors (such as Penetration testers and IDS vendors) have an incentive to gain information secretly2, they have an incentive to pay more for unknown vulnerabilities in a closed market. This means that a seller to one of these parties has a reputational incentive to earn more through not releasing information as the individual's reputation will be based on their ability to maintain secrecy. This misaligned incentive creates a sub-optimal market. As a consequence, the market reported (Arora, Telang and Xu 2005; Kannan and Telang 2004) was suboptimal. This CERT based model was an inefficient market. This does nothing to imply that all markets are less effective. The skewed incentivisation structure recommended in the paper was the source of the inefficiency and not the market itself. This simply highlights the need to allow efficient markets to develop rather than seeking to create these through design. The other argument posed comes as a consequence of information asymmetry. It is asserted [14] that software vendors have an informational advantage over other parties. The vendor does have access to source code (which is also available for Linux and other open source providers), but it can be proved that this does not provide the levels of information asymmetry that are asserted. Software vendors have a reputational input to their value [8,20]. Telang & Wattal [20] did note that the market value of a software vendor is influenced through reputational costs and those vulnerabilities correlate significantly with a decrease in the companies traded price, a view supported by others [8]. "Vulnerability disclosure adversely and significantly affects the stock performance of a software vendor. We show that, on average, a software vendor loses around 0.63% of market value on the day of the vulnerability announcement. This translates to a dollar amount of $0.86 billion loss in market value. We also show that markets do not penalize a vendor any more if the vulnerability is discovered by a third party than by the vendor itself." These results demonstrate that a vendor has an incentive to minimize the vulnerabilities found in their products. If an excessive number of vulnerabilities continue to impact a vendor, their market capitalization suffers as a consequence. This 1

2

E.g. iDefense Ltd. And other similar providers have a semi-closed market with limited information exchange. Criminal groups have an incentive to maximize the time that vulnerabilities remain unknown as this extends the time that they have to exploit these bugs. Penetration Testers etc. have similar incentives as the trade secret of an unknown zero day vulnerability can provide them with a competitive advantage. This also goes to reputational motives for both parties.

348

C.S. Wright

justification offers strong evidence that a vendor does not have an incentive to hide information (as third party vulnerability researchers cause an equal loss in capitalization). It has to be expected that any vulnerability known by the vendor will be uncovered. If the vendor fixes this flaw before release, the cost is minimized and at the limit approaches the cost of testing, (that is a zero incremental cost to that which would be expressed later). If the vendor discovers a vulnerability in the software they produce, the result is a 'strongly dominated' motive to fix the bug. Hence, any remaining bugs are those that have not been uncovered by the vendor and which are less economical to find (through an increase in testing). It can thus be demonstrated that the vendor knows no more than the user at the point of software release as to the state of bugs in a product. Testing is far less expensive earlier in the development cycle3. Figure 1 displays the expected utility of testing as the development progresses through an SDLC. Early in the process, the software developer has the greatest returns in testing and bug finding. As the development progresses, the returns are reduced as the process required and the costs associated with finding and correcting software vulnerabilities increases. The utility is lowest when the software has been shipped to the user. At this point, fixing flaws is an expensive process for both the user and the vendor. This leaves the optimal solution to find as many bugs as possible as early in the development process as is feasible. This contrasts with the increasing costs of finding bugs (Figure 2). This leaves the optimal solution for the vendor based on the discovery of as many bugs as possible as early in the development process as is feasible (as a bug discovered early in the process can cost as much as 10x less [6] than one discovered later)4. It does not mean that all bugs or vulnerabilities will be found as the cost of finding additional vulnerabilities quickly exceeds the returns.

Fig. 1. Decreasing utility of testing as the SDLC progresses 3

4

NIST http://www.cse.lehigh.edu/~gtan/bug/localCopies/nistReport.pdf, see also Impact of Software Vulnerability Announcements on the Market Value of Software Vendors – an Empirical Investigation. See http://www.cse.lehigh.edu/~gtan/bug/localCopies/nistReport.pdf

Software, Vendors and Reputation: An Analysis of the Dilemma

349

Fig. 2. Each vulnerability costs more than the last to mitigate

The widespread use of Open Source software (such as Linux) and the limited differential in discovering bugs using source code reviews demonstrates that the vast majority of software flaws in commercial software are discovered early in the development process (it is highly unlikely that commercial software developers are less effective than open source developers and that the rate of errors is likely to be similar if not lower). It has been estimated that it takes 5,000 man hours of use to discover the average software vulnerability. This amount of time creates a great amount of expense for software development when it has to be completely conducted internally. An open market on the other hand distributes this expense in an optimal manner and provides a source of information as to the true cost of the vulnerability. This information is created as the true costs of developing patches and can be compared to alternatives where patching is more costly. A vulnerability market provides information on discovery and vendor action (for instance Microsoft vs. Adobe vs. Linux etc) allowing clients to better select software vendors, mitigating the "Market for Lemons" [15] that has been proposed. It has been demonstrated already that software vendors do not have more knowledge of bugs than users (or these would have been fixed prior to release) and hence do not have an advantage in information asymmetry when it comes to finding software flaws that may result through product interactions. The market for lemons requires that the vendor knows the level of flaws better than the user. To many this may seem a common sense outcome, the vendor has access to source code, wrote the program and ran the development process. This is a flawed view as we have demonstrated as it is in the vendor’s interest to mitigate vulnerabilities as early as possible. More importantly, the vendor is punished for bugs [19, 22].

350

C.S. Wright

1.1 A Legislative Approach Many information security professionals call for legislation and penalties against software vendors who have bugs in their software. This paper examines the economic impact of several approaches to enforcing software security and demonstrates that a market-based approach is the most effective. In most existing jurisdictions, the introduction of an exculpatory rule in contracts allows for the negation of a legal ruling (the default rule) where both parties have (through the contract) expressly consented to the contrary. Just as carmaker is not liable for the life of an engine exceeding 60,000km unless there is an express warranty stating this, an express exculpatory rule for software does not exist unless the vendor offers this in a warranty clause5. Legislation can make many superficial exculpatory clauses either invalid or redundant. Such exclusion would include negligence. In some cases, the exculpatory clause merely restates the existing perspective of the law. Where an exculpatory clause is permissible, the final assignment of liability does not depend on the preliminary distribution of liability. If the default rule is that a software vendor is liable for software vulnerabilities, but the vendor’s profitability is greater where it does not suffer liability, then the vendor will print a label stating that is it not liable. In the case of software, this could be a click wrap agreement. In this paper, we investigate the economic impact of various policy decisions as a means of determining the optimal distribution of costs and liability when applied to information security and in particular when assigning costs in software engineering. 1.2 Risk Assignment and Software Contracts In economic terms, we want to assign liability such that the optimal damage mitigation strategy occurs. The victim will mitigate their damages where no damages for breach apply in respect of the optimal strategy and payoffs. The rule that creates the best incentives for both parties is the doctrine of avoidable consequences (marginal costs liability). Mitigation of damages is concerned with both the post-breach behaviors of the victim and the actions of the party to minimize the impact of a breach. In a software parlays', this would incur costs to the user of the software in order to adequately secure their systems. This again is a trade-off. Before the breach (through software failures and vulnerabilities that can lead to a violation of a system's security), the user has an obligation to install and maintain the system in a secure state. The user is likely to have the software products of several vendors installed on a single system. Because of this, the interactions of the software selected and installed by the user span the range of multiple sources and no single software vendor can account for all possible combinations and interactions. Any pre-breach behavior of the vendor and user of software needs to incorporate the capability of the vendors to both minimize the liability attached to their own products, as well as the interactions of other products installed on a system. It is 5

Software vendors offer limited warranties that provide some protection for the user, but this is limited. The vendor cannot account for the actions of the user and a failure to install the software with the use of adequate controls may result in the loss. See Appendix 1.

Software, Vendors and Reputation: An Analysis of the Dilemma

351

feasible to deploy one of several options that can aid in the minimization of the effects of a breach due to a software problem prior to the discovery of software vulnerabilities, these include: 1. The software vendor can implement protective controls (such as firewalls) 2. The user can install protective controls 3. the vendor can provide accounting and tracking functions The following steps further facilitate in minimizing the effects of software vulnerabilities: 1. The vendor can employ more people to test software for vulnerabilities 2. The software vendor can add additional controls Where more time is expended on the provision of software security by the vendor (hiring more testers, more time writing code etc), the cost of the software needs to reflect this additional effort, hence the cost to the consumer increases. This cost is divisible in the case of a widely deployed Operating System (such as Microsoft Windows) where it is easy to distribute the incremental costs across additional users. Smaller vendors (such as small tailored vendors for the Hotel accounting market) do not have this distributional margin and the additional controls could result in a substantial increase in the cost of the program. This is not to say that no liability does or should apply to the software vendor. The vendor in particular faces a reputational cost if they fail to maintain a satisfactory level of controls or do not respond to security vulnerabilities quickly enough or suffer too many problems. The accumulation of a large number of software vulnerabilities by a vendor has both a reputational cost to the vendor as well as a direct cost to the user (these costs include the time to install and the associated downtime and lost productivity). Consequently, a user can conduct an investigation into the accumulation of software vulnerabilities and the associated difficulty of patching or otherwise mitigating flaws prior to a purchase> These costs are thereby assigned to new vendors even if they experience an exceptionally low rate of patching/vulnerabilities. The user can act with knowledge of costs where it is efficient for them to do so. As users are rational in their purchasing actions, they will incorporate the costs of patching their systems into the purchase price . The probability of a vulnerability occurring in a software product will never approach zero. Consequently, it follows that the testing process used by the vendor is expressible as a hazard model [5]. In this, it is optimal for the vendor to maximize their returns such that they balance the costs of software testing against their reputation [22]. The provision of a market for vulnerabilities leads to a means of discovering the cost of finding vulnerabilities as an optimal function. In this way, the software vendor maximizes their testing through a market process. This will result in the vendor extending their own testing to the point where they cannot efficiently discover more bugs. The prices of the bugs that sell on market are definite and the vendor has to pay to either purchase these from the vulnerability researcher (who has a specialization in uncovering bugs) or increase their own testing. The vendor will continue to increase the amount of testing that they conduct until the cost of their testing exceeds the cost of purchasing the vulnerability. The potential pool of vulnerability researchers is

352

C.S. Wright

larger than the potential pool of in-house testing roles. The pool of vulnerability researchers would also increase unto a point where the cost of training to become a vulnerability researcher matches the demand of the consumer to fund vulnerabilities. This market also acts as an efficient transaction process for the assignment of negligence costs. The user still has to maintain the optimal level of controls that are under their influence (installation, patching frequency etc), whilst the vendor is persuaded to pay the optimal level of costs for testing and mitigation.

2 Software Derivative Markets One possible solution to the limited and sub-optimal markets that currently exist would be the creation of Hedge funds for software security. Sales in software security based derivatives could be created on forward contracts. One such solution is the issuing of paired contracts (such as exist in short sales of stocks6). The first contract would be taken by a user and would pay a fixed amount if the software has suffered from any unmitigated vulnerabilities on the (forward) date specified in the contract. The paired contract would cover the vendor. If the vendor creates software without flaws (or at least mitigates all easily determinable flaws prior to the inception of the contract) the contract pays them the same amount as the first contract. This is in effect a 'bet' that the software will perform effectively. If a bug is discovered, the user is paid a predetermined amount. This amount can be determined by the user to cover the expected costs of patching and any consequential damages (if so desired). This allows the user to select their own risk position by purchasing more or less risk as suits both the risk tolerance and the nature of the user's systems. Such a derivative (if an open market is allowed to exist) would indicate the consensus opinion as to the security of the software and the reputation of the vendor. Such an instrument would allow software vendors and users to hedge the risks faced by undiscovered software vulnerabilities. These instruments would also be in the interest of the software vendor's investors as the ability to manage risk in advance would allow for forward financial planning and limit the negative impact that vulnerability discovery has on the quoted prices of a vendors capital. 2.1 Selective Survival If the vendor creates the low feature version for $200 and the full featured secure version for $800, the user can choose the level of protection. Taking a survival model of Windows 98 and one for Windows XP [7], the client can calculate the expected difference from each product. If Windows 98 has an expected compromise rate (without other compensating controls) of once per 6.2 days and Windows XP has an expected rate of 52.5 days when the firewall is enabled7 we can calculate the cost per 6

7

Short selling involves an investor anticipating a decrease in the price or an item. This involves selling a chattel that the investor does not own through a contract agreement. If the goods sell higher than anticipated, the investor losses money as they have to purchase the goods at the (now higher) market rate. In each case we are presuming that the Centre for Internet Security (www.cisecurity.org) standards for installing the software have been reasonably met.

Software, Vendors and Reputation: An Analysis of the Dilemma

353

incident. If the user has a mean cost per incident of $3208, we see that the Windows 98 option has an expected annual cost to the organization of $19,040 ($18,840 damage plus $200) whereas Windows XP has an expected cost of $3,825 ($3,025 damage plus $800). Hence, most companies with a need to secure systems selected the more secure option and installed Windows XP over Windows 98. The initial costs did not reflect the overall costs to the organization. Likewise, home users (who rarely calculate the costs of compromise) where more likely to install the cheaper option. To extend the analogy, assume that a software vendor can create a perfect version of software for a mean cost of $20,0009 and the flawed version at the standard costs of under $1,000. Where the expected damages do not exceed $19,000 per copy of software, we see that it remains in the user's interests to select the lower security option as the expected losses are lower. More generally, for an organization with n users and an expected cost Cs = nPs (where Ps is the cost per user of the secure software product) against CI = nPI (with PI being the cost per user of the insecure software product), the cost of deploying either option is based on the expected losses for each option with a loss function defined as Ds < DI. As such, if (Cs – Ds) < (CI – DI) it is in the interest of the company to take the secure option. Where (Cs – Ds) > (CI – DI), the economical solution is to install the less secure version of the software and self-insure against the loss. As a means of maximizing the allocations of risk and costs, the vendor could offer liability-free and full-liability versions of their product, the later sold at a reduced price. The vendor could then control their risk using a hedging instrument10. A market evaluation of the risk being traded would provide better information than that which the vendor has alone11. With this in mind, the user could also purchase the same derivative as the vendor. The cost to the user to purchase the software plus risk insurance would be less than purchasing the "more secure" version from the vendor as the vendor would hedge the risk it faces and add a transactional cost as well as a return (at the firms IRR). Both parties are better off where the vendor produces the optimized version of their product and where the vendor does not assume liability for bugs. Simply put, the vendor will provide a warranty (which acts as an insurance policy for the user) in cases where it can charge more for the provision of the warranty than it costs to provide the warranty. This cost could be either from a hedging instrument or through an investment in more testing. However, it must be noted that no increasing testing will make software invulnerable to all attacks and remove the ability for flaws to be discovered. As such, the cost of the hedged derivative will decrease, but will not go to zero. The argument against this form of market is imperfect information. Many people argue that the software vendor has more knowledge than the user. This is untrue for 8

9 10 11

The quantitative data that this statement is derived from is to be released in a follow-up paper next year. Which is an extremely low estimate. As discussed earlier. Not only does the market pooled knowledge feed into the price of the derivative, but the vendor's knowledge of their own product does as well.

354

C.S. Wright

several reasons. The vendor has no incentive to hide vulnerabilities as each vulnerability impacts the share price of the vendor through a decrease in capital [20]. Next, the vendor would be competing on the same derivative markets as the users. The vendor’s knowledge would be quickly and efficiently transferred through the market mechanism. The end result is that a derivatives based strategy does not allow for information asymmetry and would disprove entirely the assertion that software vendors operate a "market for lemons". From this we can see that the lack of liability does not require that the software vendor does not have the appropriate incentive to provide the optimal amount of testing and hence security (as well as to add the optimal levels of external controls) to the user. If more testing is cost effective in economically providing more secure software, that is if the additional testing is cost effective, the software vendor will conduct this testing whether it is liable for security flaws or not. The incentive to provide security is no different than the incentive to provide other characteristics and features. A vendor will add software extensions that can reduce the overall security of a system if the user values these to a greater extent than their costs. Safety (and security in general) is a tie-in good. Amenities cost something. Vendors provide amenities if consumers (users) are willing to pay the cost of obtaining these. "Cars come with batteries and tires, but not always with stereo equipment or antitheft devices and rarely with driving gloves and sunglasses" [23]. What is demonstrated by those organizations with a defensive (and hence secure) coding regime is a lower variability in output. The mean coding time will remain similar, but the test time can be expected to be distributed differently for the organization that codes with a defensive posture than that of the organization that leaves too little time for testing. This increase in the standard deviation of produced results (or variability) increases the risk to the all parties (vendor and user). 2.2 Imperfect Information At present, it can be demonstrated that neither side (the user or the vendor) is informed as to the true risks and costs of software. The vendor does not know the situation of the user (for the most part) and the user may not have an easily accessibly means of determining the risk from software. Worse, neither side is likely to know the risk posed from integrating multiple software products. This asymmetry can be modeled. If we take two hypothetical firms, SecureSoft and BuggySoft each with 50% of the market for their software products and give SecureSoft a mean time between failures12 (MTBF) of 86 days and BuggySoft a MTBF of 17 days. In each case, the cost of a compromise is determined to have a mean of $400 (with). Next, assume that the average user (and purchaser of the software) cannot tell the difference. This is that the user sees a MTBF of 52 days for either software vendor. 12

For simplicity, we will assume that this is a vulnerability leading to a catastrophic flaw such as a remote "root" compromise. It is possible to model non-destructive failure processes using “sickness – recovery – death” survival models, but these are outside the scope of this paper.

Software, Vendors and Reputation: An Analysis of the Dilemma

355

This situation is known as 'adverse selection' in economics. If the users are liable and they self-insure, they will not be able to determine the relative level of vulnerabilities with respect to SecureSoft or BuggySoft. The cost of purchase will only be probabilistically determined (although, there are only small odds that an overlap event13 will occur) when the software vulnerability is uncovered. If the software vendor were liable for more than one (1) vulnerability each 90 days, we would expect SecureSoft to breach around 40% of the time for an expected cost of $1,622 per annum. BuggySoft on the other hand would be expected to breach 100% of the time for an expected cost of $8,588 per annum. The difference in value of $6,966 is what BuggySoft would have to pay to its customers each year. As such, SecureSoft could market itself as a more secure option. If the user-base did not believe that BuggySoft and SecureSoft are different, SecureSoft could offer $6,965 worth of liability insurance to its users whereas BuggySoft would not be able to match this price (all other aspect being equal). As a result, even an argument for enforced liability insurance has a weakness. In the absence of liability legislation, the more secure software vendor would still desire to offer insurance to its users where it is cost effective to do so. By doing this, SecureSoft could add benefit to its users by insuring for loss to a level that is not cost effective for BuggySoft. This price differential would gradually win business for SecureSoft and increase its market share. The consequence is that although users see an equal distribution of problems initially, over time, the information asymmetry decreases and the market starts to favor the most secure provider. The difficulty in these circumstances is not comparing which product is more secure, but is an issue of trading security against features. If BuggySoft added a management interface included with its software package that users valued at $8,000, they would be able to outsell SecureSoft even with the insecurities and added risk. From this example, we see the inherent issue with software security. Users value many aspects of a product and value these against the overall value that they assign to the product. As a result, an insecure product with saleable features will commonly sell for more than the secure version (even where users do not actually use the added features). 2.3 Optimal Derivatives Design under Dynamic Risk Measures The game theoretic approach to this can be modeled looking at the incentives of the business and programming functions in the organization. Programmers are optimists [6]. As Brooks [6] noted, "the first assumption that underlies the scheduling of systems programming is that all will go well". Testing is rarely considered by the normal programmer as this would imply failure. However, the human inability to create perfection leads to the introductions of flaws at each stage of development. In the model presented by Brooks [6], as a program moves to a "Programming Product" and then to "a Programming Systems Product"14, there are incremental 13

14

Where the survival time of the first company falls in the expected range of the other company. Through the addition of a "Programming System" with the addition of Interfaces and a System Integration Phase.

356

C.S. Wright

additions that extend the estimates of the programming team. At each phase these can be expressed as a function of effort expressed in the lines of code, lc. We can express the mean effort xl required to code a number of lines and the variability15, σ l in achieving this outcome. This allows us to represent the coding effort as a representation of the stages of development: c

(

In (1), H xlc , σ lc

(

)

c

(

) (

)

F ( x) = 9 H xlc , σ lc G xlc , σ lc + ε

(1)

) is the function of systematizing [6, p6] the code. The expression

G xlc , σ lc is the productization [6, p6] of the code. The derivative would require the firm to publish their productivity figures; •

Lines of code per programmer (and standard Deviation);

•

Bug-incidence figures;

• • •

Estimating and project rules/methodology Software design methodology Secure Programmer measures16.

lc, xl and c

σl

blc and σ b

c

t and σ t

Many see this as proprietary data and would be loath to share, but as more in the market take-up the use of such a derivative in managing their own risk, the incentives for others to follow increase. We can also demonstrate that as t → max t and σ t → 0 that the volatility in coding σ lc and σ b decrease with the number of reported bug incidents bl → 0 as t → max t . More metrics would be required based on the methodologies and coding practices used with different computer languages expected to exhibit different responses16. As the skill of the programming team ( t → max t & σ t → 0 ) increases through group training, secure coding practices and in-line testing, the volatility in coding σ lc → 0. As the incremental returns on t diminish as t → max t and the cost of training continue to grow linearly16, we can see that the optimal position for any software vendor is to have a skilled team that maximizes returns. At this point, additional training becomes economically unviable and does not create further returns for the organization17. We also see that it is in the interest of the firm to minimize the variance in skill levels between programming staff (aim to have σ t → 0 ). This of course adds costs as junior staff would be less productive in that they would have to work with more senior staff18 in order to both cross train and to ensure that the junior employees maintain an acceptable level of production and testing. This exercise of joining junior and senior staff would create a return function depicted by Brookes [6, p19] for a "Time versus number of workers - task with c

15 16

17

18

Standard Deviation (where σ = Variance2 ). That is, Cost(t) = at + b where there is an initial cost plus a linear increase in the costs of developing the programmer skills. This investment may still be made by the individual programmer with returns to the organization and also for further personal gains (investment in personal capital). Also reducing the output of the senior staff.

Software, Vendors and Reputation: An Analysis of the Dilemma

357

complex interrelationships". The output of the junior/senior staff unit would be lower than the senior staff level (initially) but would lower variability and increase the skill levels of the junior staff and hence over time σ t → 0 . Due to staff turn-over19 and the increasing costs of maintaining more skilled programmers, this would also have a negative feedback on the vendor’s production costs. This would also need to be optimized rather than maximized if the vendor is to maximize returns. 2.4 No More Lemons

The fallacy of the mainstream analysis of deflation can be used to demonstrate the fallacy of aligning a market for lemons to computer software. This game model has people refrain from spending when they anticipate falling prices. As people expect prices to fall, they believe that they will get a better price if they consume later (or that they will get more secure software for the same price).This drop in consumption results in a consequential price fall, and the whole cycle repeats. The argument made is that prices will spiral uncontrollably downward.

Fig. 3. Training Software developers in Security adds utility

Robert Murphy [14] addressed this issue and demonstrated its fallacy: One could construct an analogous argument for the computer industry, in which the government passes regulation to slow down improvements in operating systems and processing speed. After all, how can computer manufacturers possibly remain viable if consumers are always waiting for a faster model to become available? … The solution to this paradox, of course, is that consumers do decide to bite the bullet and buy a computer, knowing full well that they would be able to buy the same performance for less money, if they were willing to wait… (There's no point in holding out for lower prices but never actually buying!) (pp. 68–9) 19

F. J Corbato' (MIT) – “A long duration project needs to incorporate a turnover rate of at least 20% per annum. New hires need to be technically trained and also require time to be able to effectively integrate into the existing team”.

358

C.S. Wright

Some users do wait for patches to be proven and others use "bleeding edge software" (and some never patch). The model is more rightly based on a distribution of users centered on an install time slightly after the release date. This model can help us combat George Akerlof's lemons model20 of the used-car market has been applied to the computer industry. Akerlof argued that asymmetric information would result in the owners of good used cars being driven from the market. Contrary to the equilibrium suggested in this model, good used cars sell. One can state that just because owners of good cars may not be able to obtain as high a price as they would like, it does not follow that they will refuse to sell at all. Likewise, just as users do not know the state of security or how many bugs exist in software, software is still sold. The "real balance effect": as prices fall, the value of money rises People's demand to hold money can be satisfied with less money as price deflation occurs. This in part explains why people will eventually spend, even when they expect prices to continue to fall. The same process applies to software. Users see value in the features and processes they purchase software for. These are offset against the costs which include both the monetary costs as well as the costs of maintenance (patching) and security (and other) flaws. Failure has a cost and this is incorporated in to the price of software to the user. The result is that users buy and install software even when they expect more bugs/vulnerabilities to be found.

3 Conclusion Just as car dealers buff the exterior and detail the upholstery of a used car, neglecting the work that should be done on the engine, software vendors add features. Most users are unlikely to use even a small fraction of these features, yet they buy the product that offers more features over the more secure product with fewer features. The issue here is that users buy the features over security. This is a less expensive option for the vendor to implement and provide. The creation of a security and risk derivative should change this. The user would have an upfront estimate of the costs and this could be forced back to the software vendor. Where the derivative costs more than testing, the vendor would conduct more in-depth testing and reduce the levels of bugs. This would most likely lead to product differentiation (as occurred in the past with Windows 95/Windows NT). Those businesses will to pay for security could receive it. Those wanting features would get what they asked for. It is argued that software developers characteristically do not correct all the security vulnerabilities and that known ones remain in the product after release. Whether this is due to a lack of resources or other reasons, this is unlikely to be the norm and would be rectified by the market. The cost of vendors in share price [1] and reputational losses exceed the perceived gains from technical reasons where the fix might break existing applications. The application is already broken in the instance of a security vulnerability.

20

See 15 for various derived models.

Software, Vendors and Reputation: An Analysis of the Dilemma

359

Users could still run older versions of software and have few if any bugs. The issue is that they would also gain no new features. It is clear that users want features. They could also choose to use only secure software, but the costs of doing so far outweigh the benefits and do not provide a guarantee against the security of a system being compromised. As such, the enforced legislation of security standards against software vendors is detrimental. A better approach would be to allow an open market [4] based system where vendors can operate in reputational and derivative markets. At the end of any analysis, security is a risk function and what is most important is not the creation of perfectly security systems, but the correct allocation of scarce resources. Systems need to be created that allow the end user to determine their own acceptable level of risk based on good information.

References 1. Arora, A., Telang, R.: Economics of Software Vulnerability Disclosure. IEEE Security and Privacy 3(1), 20–25 (2005) 2. Arora, A., Telang, R., Xu, H.: Optimal Time Disclosure of Software Vulnerabilities. In: Conference on Information Systems and Technology, Denver CO (October 23-24, 2004) 3. Arora, A., Telang, R., Xu, H.: Optimal Policy for Software Vulnerability Disclosure. Management Science 54(4), 642–656 (2008) 4. Bacon, D.F., Chen, Y., Parkes, D., Rao, M.: A market-based approach to software evolution. Paper presented at the Proceeding of the 24th ACM SIGPLAN Conference Companion on Object Oriented Programming Systems Languages and Applications (2009) 5. Beach, J.R., Bonewell, M.L.: Setting-up a successful software vendor evaluation/qualification process for ‘off-the-shelve’ commercial software used in medical devices. In: Proceedings of Sixth Annual IEEE Symposium on Paper presented at the Computer-Based Medical Systems (1993) 6. Brookes, F.: The Mythical Man-Month. Addison-Wesley, Reading (1995) 7. Campodonico, S.: A Bayesian Analysis of the Logarithmic-Poisson Execution Time Model Based on Expert Opinion and Failure Data. IEEE Transactions on Software Engineering 20, 677–683 (1994) 8. Cavusoglu, H., Cavusoglu, H., Zhang, J.: Economics of Security Patch Management. In: The Fifth Workshop on the Economics of Information Security, WEIS 2006 (2006) 9. Cohen, J.: Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice). Smartbearsoftware.com (2006) 10. de Villiers, M.: Free Radicals in Cyberspace, Complex Issues in Information Warefare. 4 Nw. J. Tech. & Intell. Prop. 13 (2005), http://www.law.northwestern.edu/journals/njtip/v4/n1/2 11. Dijkstra, E.W.: Notes on structured programming Structured programming, ch. I, pp. 1–82. Academic Press Ltd., London (1972) 12. Kannan, K., Telang, R.: Market for Software Vulnerabilities? Think Again. Management Science (2004) 13. Mills, H.D.: Top-down programming in large systems. In: Rustin, R. (ed.) Debugging Techniques in Large Systems. Englewoods Cliffs, Prentice-Hall, N.J (1971) 14. Murphy, R., Regnery, P.: The Politically Incorrect Guide to the Great Depression and the New Deal (2009)

360

C.S. Wright

15. Nissan, N., Roughgarden, T., Tardos, E., Vazirani, V. (eds.): Algorithmic Game Theory. Cambridge University Press, Cambridge (2007), P14, Pricing Game; P24, Algorithm for a simple market; P639 Information Asymmetry 16. Nizovtsev, D., Thursby, M.: Economic analysis of incentives to disclose software vulnerabilities. In: Fourth Workshop on the Economics of Information Security (2005) 17. Ounce Labs, 2, http://www.ouncelabs.com/about/news/ 337-the_cost_of_fixing_an_application_vulnerability 18. Ozment, A.: Bug auctions: Vulnerability markets reconsidered. In: Third Workshop on the Economics of Information Security (2004) 19. Perrow, C.: Normal Accidents: Living with High-Risk Technologies. Princeton University Press, Princeton (1984/1999) 20. Telang, R., Wattal, S.: Impact of Software Vulnerability Announcements on the Market Value of Software Vendors – an Empirical Investigation (2004), http://www.infosecon.net/workshop/pdf/telang_wattal.pdf 21. Turing, A.: On computable numbers, with an application to the Entscheidungsproblem. Proceedings of the London Mathematical Society 42(2), 230–265 (1936) 22. Weigelt, K., Camerer, C.: Reputation and Corporate Strategy: A Review of Recent Theory and Applications. Strategic Management Journal 9(5), 443–454 (1988) 23. Donald, D.: Economic Foundations of Law and Organization (2006)

Appendix 1 In a decision that can be related to software flaws, Mercedes Benz (NSW) v ANZ and National Mutual Royal Savings Bank Ltd (unreported), the Supreme Court of New South Wales considered if a duty to avert fraud would occur in cases where there is an anticipated prospect of loss. The Mercedes Benz employee responsible for the payroll system fraudulently misappropriated nearly $1.5 million by circumventing controls in the payroll software. Mercedes Benz alleged that the defendants, ANZ and NMRB, were negligent in paying on cheques that where fraudulently procured by the employee and in following her direction. The plaintiff's claim was dismissed by the court. It was held that employers who are careless in their controls to prevent fraud using only very simple systems for the analysis of employee activities would be responsible for the losses that result because of deceitful acts committed by the organizations’ employees.s

Author Index

Akdemir, Kahraman D. Ali, Tamleek 290 Asokan, N. 200 Aura, Tuomas 200 Bao, Feng 67, 189 Bente, Ingo 302 Bla´skiewicz, Przemyslaw Bugiel, Sven 219

271

173 Mao, Liangjian 26 Martin, Andrew 47 Matsuo, Shin’ichiro 160 Medwed, Marcel 253 Mei, Hong 67 Meng, Jinli 37 Mu, Beipeng 37

Chen, Liqun 128 Chen, Xinming 37 Chen, Zhen 37 Dietrich, Kurt 1 Dmitrienko, Alexandra Ekberg, Jan-Erik

219

Namiluko, Cornelius 47 Nauman, Mohammad 290 Neubauer, Georg 1

200

Gallais, Jean-Fran¸cois 253 Gissing, Michael 326 Großsch¨ adl, Johann 253 Gu, Liang 67, 189 Guo, Yao 67 Hanley, Neil 253 Hao, Dong 237 He, Yeping 98 Hellmann, Bastian 302 Huang, Jialin 148 Ju, Shiguang

Lai, Xuejia 148 Laitinen, Pekka 200 Li, Jiangtao 108, 128 Li, Qi 316 Li, Shangjie 98 Lin, Chuang 37 Lin, Zhangxi 316

87

Kapfenberger, Michael 1 Karakoyunlu, Deniz 271 Kasper, Markus 253 Kostiainen, Kari 219 Kubiak, Przemyslaw 173 Kutylowski, Miroslaw 173

Padir, Taskin 271 Phong, Le Trieu 160 Pirker, Martin 326 Regazzoni, Francesco Reiter, Andreas 1 Ren, Yizhi 237 Ruan, Lingyun 37

253

Sadeghi, Ahmad-Reza 219 Sakurai, Kouichi 26, 237 Schmidt, J¨ orn-Marc 253 Song, Xiangmei 87 Sunar, Berk 271 Tamrakar, Sandeep 200 Tillich, Stefan 253 Toegl, Ronald 326 Vieweg, Joerg 302 von Helden, Josef 302

362

Author Index

Walker, Jesse 108 Wang, Changda 87 Welzel, Arne 302 Winandy, Marcel 219 Winter, Johannes 1 W´ ojcik, Marcin 253 Wright, Craig S. 346

Yang, Yanjiang 67, 189 Yao, Shuzhen 26 Yung, Moti 160 Zhang, Kai 26 Zhang, Xinwen 290 Zhang, Yongzhong 316 Zhou, Conghua 87