Information Security Theory and Practice. Smart Devices, Pervasive Systems, and Ubiquitous Networks: Third IFIP WG 11.2 International Workshop, WISTP ... Computer Science Security and Cryptology)

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 University of Dortmund, 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 of Computer Science, Saarbruecken, Germany

5746

Olivier Markowitch Angelos Bilas Jaap-Henk Hoepman Chris J. Mitchell Jean-Jacques Quisquater (Eds.)

Information Security Theory and Practice Smart Devices, Pervasive Systems, and Ubiquitous Networks Third IFIP WG 11.2 International Workshop, WISTP 2009 Brussels, Belgium, September 1-4, 2009 Proceedings

13

Volume Editors Olivier Markowitch Université Libre de Bruxelles 1050 Bruxelles, Belgium E-mail: [email protected] Angelos Bilas Foundation for Research and Technology – Hellas Institute of Computer Science Vassilika Vouton, Heraklion 70013, Greece E-mail: [email protected] Jaap-Henk Hoepman TNO / Radboud University Nijmegen 9701 BK Groningen, The Netherlands E-mail: [email protected] Chris J. Mitchell Royal Holloway, University of London Egham, Surrey TW20 0EX, UK E-mail: [email protected] Jean-Jacques Quisquater Université Catholique de Louvain 1348 Louvain-la-Neuve, Belgium E-mail: [email protected] Library of Congress Control Number: 2009932597 CR Subject Classification (1998): E.3, K.6.5, D.4.6, C.3, C.2, I.1 LNCS Sublibrary: SL 4 – Security and Cryptology ISSN ISBN-10 ISBN-13

0302-9743 3-642-03943-X Springer Berlin Heidelberg New York 978-3-642-03943-0 Springer Berlin Heidelberg New York

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. springer.com © IFIP International Federation for Information Processing 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12738540 06/3180 543210

Preface

This volume contains the 12 papers presented at the WISTP 2009 conference, held in Brussels, Belgium in September 2009. WISTP 2009 was the third international workshop devoted to information security theory and practice. WISTP 2009 built on the successful WISTP 2007 and 2008 conferences, held in Heraklion, Crete, Greece and Seville, Spain in May 2007 and May 2008, respectively. The proceedings of WISTP 2007 and WISTP 2008 were published as volumes 4462 and 5019 of the Lecture Notes in Computer Science series. This workshop received the following support: – – – – – – –

Co-sponsored by IFIP WG 11.2 Small System Security Co-sponsored by VDE ITG Technical sponsorship of the IEEE Systems, Man & Cybernetics Society Supported by the Technical Committee on Systems Safety and Security Organized in cooperation with the ACM SIGSAC Supported by ENISA Supported by the Institute for Systems and Technologies of Information, Control and Communication (INSTICC)

These proceedings contain 12 original papers covering a range of theoretical and practical topics in information security. For the purposes of the organization of the WISTP program, the papers were divided into four main categories, namely: – – – –

Mobility Attacks and Secure Implementations Performance and Security Cryptography

The 12 papers included here were selected from a total of 27 submissions. The refereeing process was rigorous, involving at least three (and mostly four or five) independent reports being prepared for each submission. 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. We are also happy to acknowledge the support and collaboration of the MASTER research project. MASTER is a collaborative project funded under the EU 7th Research Framework Program. It is aligned to Strategic Objective 1.4: Secure, dependable and trusted infrastructures, as defined by the European Commission in the 2007/08 FP7 ICT Work Program. The conference incorporates a session devoted to describing the work of this project. We would like to thank the General Chairs, Angelos Bilas and Olivier Markowitch, the local organizers Jérôme Dossogne, Olivier Markowitch, and Naïm Qachri,

VI

Preface

the Workshop Chair Jean-Jacques Quisquater and the Publicity Chairs Claudio Ardagna, Ioannis G. Askoxylakis, Joonsang Baek, and Gerhard Hancke. We would also like to thank Damien Sauveron for his tireless support during the whole process of organizing the workshop, setting up and maintaining the conference review website, and taking care of all kinds of behind-the-scenes arrangements. Finally we would like to thank all the authors who submitted their papers to WISTP 2009, all external referees, all the attendees of the conference, and last, but by no means least, our five distinguished invited speakers, namely: – – – – –

Gildas Avoine, Université Catholique de Louvain, Belgium Jean-Pierre Delesse, Eurosmart, Brussels, Belgium Steve Purser, ENISA, Crete, Greece Vincent Rijmen, Katholieke Universiteit Leuven, Belgium Doug Tygar, UC Berkeley, USA

This conference was the third in an annual series of conferences devoted to the study of security and privacy of pervasive systems, and we look forward to WISTP 2010, due to take place in Passau, Germany in April 2010. June 2009

Jaap-Henk Hoepman Chris Mitchell

WISTP 2009

Third International Workshop on Information Security Theory and Practice Brussels, Belgium September 1–4, 2009

General Chairs Angelos Bilas Olivier Markowitch

FORTH-ICS and University of Crete, Greece Université Libre de Bruxelles, Belgium

Local Organizers Jérôme Dossogne Olivier Markowitch Naïm Qachri

Université Libre de Bruxelles, Belgium Université Libre de Bruxelles, Belgium (Chair) Université Libre de Bruxelles, Belgium

Workshop/Panel/Tutorial Chair Jean-Jacques Quisquater Université Catholique de Louvain, Belgium

Publicity Chairs Claudio Ardagna Ioannis G. Askoxylakis Joonsang Baek Gerhard Hancke

University of Milan, Italy FORTH-ICS, Greece Institute for Infocomm Research (I2R), Singapore Royal Holloway, University of London, UK

Program Chairs Jaap-Henk Hoepman Chris J. Mitchell

TNO and Radboud University Nijmegen, The Netherlands Royal Holloway, University of London, UK

VIII

Organization

Program Committee Rafael Accorsi Manfred Aigner François Arnault Ioannis G. Askoxylakis Christophe Bidan Pierre-François Bonnefoi Serge Chaumette Estíbaliz Delgado Tassos Dimitriou Pierre Dusart Sara Foresti Flavio Garcia Theodoulos Garefalakis Dieter Gollmann Stefanos Gritzalis Gerhard Hancke Olivier Heen Sotiris Ioannidis Sokratis Katsikas Evangelos Kranakis Deok-Gyu Lee Konstantinos Markantonakis Fabio Martinelli Keith Mayes Jan de Meer Sjouke Mauw Stefaan Motte Jose Onieva Rolf Oppliger Pierre Paradinas Erik Poll

University of Freiburg, Germany Technical University Graz, Austria University of Limoges, France FORTH-ICS, Greece Supélec, France University of Limoges, France University Bordeaux 1, France European Software Institute, Spain Athens Information Technology, Greece University of Limoges, France University of Milan, Italy Radboud University Nijmegen, The Netherlands University of Crete, Greece TU Hamburg-Harburg, Germany University of the Aegean, Greece Royal Holloway, University of London, UK INRIA, France FORTH-ICS and University of Crete, Greece University of Piraeus, Greece Carleton University, Canada Electronics and Telecommunications Research Institute, Korea

Royal Holloway, University of London, UK IIT-CNR, Italy Royal Holloway, University of London, UK Brandenburg Technical University, Germany University of Luxembourg, Luxembourg NXP Semiconductors, Belgium University of Malaga, Spain eSECURITY Technologies, Switzerland INRIA and CNAM, France Radboud University Nijmegen, The Netherlands Joachim Posegga University of Passau, Germany Jean-Jacques Quisquater Université Catholique de Louvain, Belgium Kai Rannenberg Goethe University Frankfurt, Germany Konstantinos Rantos Hellenic Ministry of Interior, Public Administration and Decentralisation, Greece Damien Sauveron University of Limoges, France

Organization

Frank Stajano Michael Tunstall Paulo Jorge Esteves Veríssimo Erik Zenner Alf Zugenmaier

IX

University of Cambridge, UK University of Bristol, UK University of Lisbon, Portugal Technical University of Denmark, Denmark Docomo Research Labs, Germany

Steering Committee Angelos Bilas Serge Chaumette Dieter Gollmann Konstantinos Markantonakis Jean-Jacques Quisquater Damien Sauveron

FORTH-ICS and University of Crete, Greece University Bordeaux 1, France TU Hamburg-Harburg, Germany Royal Holloway, University of London, UK Université Catholique de Louvain, Belgium University of Limoges, France

External Reviewers Samia Bouzefrane Carlos Cid Julien Cordry Gabriele Costa Ton van Deursen David Galindo Martin Johns Aliksandr Lazouski Marinella Petrocchi

Evgenia Pisko Henrich C. Poehls Saša Radomirović Evangelos Rekleitis Ruben Rios Thomas Sirvent Markus Tschersich Harald Vogt Christian Weber

Sponsoring Institution Université Libre de Bruxelles, Belgium

Main Sponsors Since the early stages of the inception of the workshop, the organizers have received positive feedback from a number of high-profile organizations. With the development of a strong Program and Organizing Committee, this developed into direct financial support. This has enabled the workshop organizers to strengthen

X

Organization

significantly their main objective of providing a high-standard academic workshop. The support has made a major contribution toward keeping the workshop registration costs as low as possible, and at the same time enabling us to offer a number of best paper awards. We would therefore like to express our gratitude to every single organization who has helped us financially, as listed below. We also look forward to working together with them on future WISTP events.

Table of Contents

Mobility On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Olivier Heen, Gilles Guette, and Thomas Genet A Mechanism to Avoid Collusion Attacks Based on Code Passing in Mobile Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marc Jaimez, Oscar Esparza, Jose L. Mu˜ noz, Juan J. Alins-Delgado, and Jorge Mata-D´ıaz Privacy-Aware Location Database Service for Granular Queries . . . . . . . . Shinsaku Kiyomoto, Keith M. Martin, and Kazuhide Fukushima

1

12

28

Attacks and Secure Implementations Algebraic Attacks on RFID Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ton van Deursen and Saˇsa Radomirovi´c

38

Anti-counterfeiting Using Memory Spots . . . . . . . . . . . . . . . . . . . . . . . . . . . . Helen Balinsky, Edward McDonnell, Liqun Chen, and Keith Harrison

52

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emmanuelle Dottax, Christophe Giraud, Matthieu Rivain, and Yannick Sierra

68

Performance and Security Measurement Analysis When Benchmarking Java Card Platforms . . . . . . Pierre Paradinas, Julien Cordry, and Samia Bouzefrane Performance Issues of Selective Disclosure and Blinded Issuing Protocols on Java Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hendrik Tews and Bart Jacobs Energy-Efficient Implementation of ECDH Key Exchange for Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christian Lederer, Roland Mader, Manuel Koschuch, Johann Großsch¨ adl, Alexander Szekely, and Stefan Tillich

84

95

112

XII

Table of Contents

Cryptography Key Management Schemes for Peer-to-Peer Multimedia Streaming Overlay Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

128

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks for Monitoring Linear Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keith M. Martin and Maura B. Paterson

143

PKIX Certificate Status in Hybrid MANETs . . . . . . . . . . . . . . . . . . . . . . . . Jose L. Mu˜ noz, Oscar Esparza, Carlos Ga˜ n´ an, and Javier Parra-Arnau

153

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

167

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks Olivier Heen1 , Gilles Guette2 , and Thomas Genet1 1

INRIA Bretagne Atlantique, Rennes, France [email protected], [email protected] 2 Universit´e Rennes 1, Rennes, France [email protected]

Abstract. More and more mobile devices feature wireless communication capabilities. They can self-organize in a mobile ad hoc network in order to communicate and maintain connectivity without any infrastructure component. In this context, some devices may benefit from established trust relations in order to communicate private data. Various solutions already exist for establishing and detecting such trust relations. But is it still possible to detect a trust relation in an unobservable manner? That is, in a way that an attacker cannot understand whether devices share a trust relation or not. We exhibit a solution to this problem. Our solution guaranties the anonymity and the unobservability of participants against passive and active attackers. The security properties of the solution are machine checked with the AVISPA framework [2] and the SPAN tool [5]. The main applications could be found in mobile ad hoc networks and in vehicular networks [6,7] where anonymity and unobservability contribute to a better privacy.

1

Introduction

These last years we see an explosion of the number of mobile devices featuring wireless capabilities. Such devices can self-organized as the nodes of a Mobile Ad hoc NETwork, a MANET. Some nodes can join and leave the MANET at any time according to their moves and communication range. The notion of trust naturally appears in MANET: some nodes can establish long term trust relations in order to better communicate the next time they meet. Typically, trusted nodes may exchange private data while the other nodes only exchange public data. The so-called resurrecting duckling [13] is a well known-solution for the establishment and detection of trust relations between nodes. Other solutions like [11] are particularly suitable for home networks. According to many solutions the user contributes to the establishment of the trust relations, and later on the nodes detect their trust status as soon as they start to communicate without any user intervention. By trust status we mean the fact of sharing a trust relation or not. O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 1–11, 2009. c IFIP International Federation for Information Processing 2009 

2

O. Heen, G. Guette, and T. Genet

In the same time, privacy becomes a serious concern in a variety of domains including many typical application fields of MANET: home networks, Personal Area Networks (PAN), vehicular networks (VANET) [14,1], etc. The greater the ability of devices to communicate, the greater the risk of disclosing private information. In the field of VANET for instance, malicious observers should not trace the moves of a vehicle for a long period of time, simply based on its network communications [12]. In some cases, even the existence of a trust relation between two nodes must remain private. This can be the case when the nodes belong to a same group of interest, friends, family etc. In the field of VANET, this can be critical for unmarked police cars: they should not be disclosed by their trust relation. In this paper, we address the following question: is it possible to detect trust relations in MANET in an anonymous and unobservable manner? In particular, can two communicating nodes detect their trust status and still be sure that no untrusted node has detected it either? We mainly focus on the existence of a solution to the problem, in presence of passive or active attackers. To do so, we use a binary notion or trust: a node does trust another node, or does not. Note that some more graduated notions of trust exist, with for instance a parameter for the intensity of trust or taking in account the number of positive vs. negative experiences with other nodes. . . We do not formally consider these notions. Instead we consider that any non-null trust is a maximal trust, and bring unobservability in this worst case. The section 2 provides the necessary definitions as well as the constraints we will respect in the design of the solution. The section 3 provides the appropriate notations and gives a full description of our solution. The section 4 gives arguments for the proof of the security, the anonymity and the unobservability properties. A significant part of the verification is performed using the AVISPA [2] framework together with the animation tool SPAN [5].

2 2.1

Preliminaries Definitions

Firstly, we give the definition related to the nodes and the trust relation. Node: A node A is a communicating device with a pair of keys denoted −1 (KA , KA ). No key in the pair will be public. The node set is noted N . We define the trust relation for which we want to achieve unobservability against some attackers. Trust relation: A node B trusts another node A, denoted BA, if B knows the key KA . We can see that BA does not imply that AB. Trust community: The trust community of a node B, denoted TB , is the set of nodes trusted by B. TB = {A ∈ N , BA}. We give in the following the most common definition of the anonymity and some related concepts. These definitions are taken from [9,8]. Anonymity set: An anonymity set is a set of nodes having the same attributes and capable to perform the same actions.

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks

3

Anonymity: A node remains anonymous if we cannot identify it in an anonymity set. Sender (resp. receiver) anonymity is provided when a message analysis do not allow determining its sender (resp. receiver) in the anonymity set. Unobservability: There is unobservability of an event when an attacker cannot deduce the existence of this event. There is unobservability of the sender (resp. receiver) when an attacker cannot deduce that a message was sent (resp. received). We will first provide a solution for the unobservability of a trust relation against a passive attacker. Passive attacker: A passive attacker can dump every message sent on the network. She does not know, a priori, any cryptographic key. Then, we will refine this solution to thwart an active attacker. Active attacker: An active attacker can dump, add, remove and modify every message on the network. We say that ”the attacker is the network”. Note that this kind of attacker is also called a Dolev-Yao attacker. 2.2

Trust Relation

Numerous trust models exist, coming from the simple secret key sharing to certificate chains. For further information on the different trust models, read [3] or [11]. The model we use is particularly adapted to the MANET. We give here the main characteristics and some use cases. Establishment of trust: The trust relation BA is established by transmitting KA to B over a secure channel. Note that if A changes its key or if B forgets KA it will be necessary to rebuild the trust relation. If B does not trust A anymore it just has to remove KA from its key database. Extension of trust (a.k.a recommendation): In the case BA, B can decide to recommend A to another node X; it just has to send KA to X over a secure channel. In the example of vehicular network, a truck B can trust road equipment A (base station, toll, etc. ) and transmit this trust to another truck X, even if A is not here during the key transmission.

3

Our Solution

Figure 1 gives all the notations used in this paper. Our solution is based on three significant techniques: renewable pseudonyms, message encryption, periodical broadcast. The general format of a message in our protocol is: {i.0.db}K −1 .{j.0.db}K −1 .g i a.m A

B

where {i.0.db}K −1 is a pseudonym of the sender, {j.0.db}K −1 is a pseudonym A B of the receiver, g i a Diffie-Hellman value, m the encrypted payload. Note that since an observer should not distinguish anything, all the messages must respect the same format.

4

O. Heen, G. Guette, and T. Genet Notation A, B, C . . . −1 KA , KA {i.0.db}K −1 A

BA TA

Definition Notation Definition Network nodes g Diffie-Hellman generator Key pair of node A P rivate Message to protect a pseudonym of node A P ublic Other message B trust A m1 , m2 . . . Trust community of A db

i, j, k . . . and R Fresh random numbers (never used before)

Random messages Public number like 0xDEADBEEF Encryption / Decryption algorithm using key K

{}K

Fig. 1. Notations

Our solution builds a Diffie-Hellman key and tries to authenticate this key by using the information contained in the pseudonyms. The authentication will succeed only when a trust relation exists, otherwise the nodes know that they do not share any trust relation (refer to [4] for more information about authenticated Diffie-Hellman exchanges). We now provide the sequence of message according to our solution in various cases. Case BA (B knows KA ) and A starts 1. A → All : {i.0.db}K −1 .R.g i .m1 (with R some padding) A



2. B checks that {{i.0.db}K −1 }KA = i .0.db and g i = g i A

3. B → All : {i.j.db}KA .{i.0.db}K −1 .g j .m2 A



4. A checks that {{i.j.db}KA }K −1 = i .j  .db and i = i and g j = g j A

5. A → All : {i.0.db}K −1 .{i.j.db}KA .g k .{P ublic}gij A

6. B → All : {i.j.db}KA .{i.0.db}K −1 .g l .{P rivate}gij A

At the step 2, B detects that {i.0.db}K −1 is a pseudonym of a trusted node. A A simple manner for detecting this is to sequentially1 try all the keys in TB until the key KA successfully decrypts the pseudonym of A. At the step 4, A detects that {i.j.db}KA is a pseudonym of a trusted node, nevertheless A does not know that this node is B. The nodes A and B may then continue to use there pseudonym in the further exchanges. They can send as many encrypted messages as they need, with A sending encrypted P ublic messages and B sending P ublic or P rivate messages: A → All : {i.0.db}K −1 .{i.j.db}KA .g l .{P ublic}gij A B → All : {i.j.db}KA .{i.0.db}K −1 .g m .{P rivate}gij A

1

If B trusts a lot of nodes the set TB is large and the detection can take a lot of time. There exist many ways to improve the efficiency, like trying to decrypt with the most often used key first.

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks

5

If one node changes its pseudonym, a new detection of trust will happen and re-establish the communication. Case without trust relation: We describe in this section the sequence of exchanged message between two nodes A and C that do not share any trust relation. Nevertheless, A and B want to communicate with each other. 1. A → All : {i.0.db}K −1 .R.g i .m1 (with R some padding) A 2. B → All : {j.0.db}K −1 .{i.0.db}K −1 .g j .m2 B A 3. A → All : {i.0.db}K −1 .{j.0.db}K −1 .g k .{P ublic}gij A

B

In this case, A and B do not share any key and then they cannot collaborate for checking the Diffie-Hellman values. The key used to encrypt the payload is the Diffie-Hellman key g ij generated with the third parts of the messages 1 and 2. Note that a man-in-the-middle attack is possible here against the Diffie-Hellman part of the solution; this point is further discussed in 4.4. Case BA and B starts: This case is not managed in a particular way : since messages are periodically broadcasted one cannot predict if A or B starts the protocol. Here, B starts as in the case without trust. Since A does not trust B, A continues as in the case without trust. Only then B has the possibility to detect the trust relation. At this point the situation is exactly the same as when A started the communication. In particular B will drop its old pseudonym {j.0.db}K −1 for choosing a pseudonym of the form{j.k.db}KA very much like in B step 3 when A starts. Case AB and BA: This case is not managed in a particular way: depending on which node starts the case AB or the case BA is resolved first. Nevertheless, once the anonymous secure channel is built between A and B, it is always possible for a node to ask the authentication of the other node, for instance by signing a random value. For instance, if the case BA is resolved first, A can authenticate itself to B by sending: A → All : {i.0.db}K −1 .{i.j.db}KA .g l . A {n.{n}K −1 }gij , B checks {n}K −1 = n and n = n. A

4 4.1

A

Analysis of the Solution Basic Security Properties

Our solution must provide confidentiality of communications between nodes A and B when BA. We use the AVISPA framework to prove this property. We first write a full specification of the protocol (given in appendix), then we specify the secrecy property and we run the AVISPA detection tools. The specification corresponds to the case BA and we check the two situations: when A starts the communication and when B starts the communication. No attack was found. The case AB is verified by symmetry of the roles of A and B.

6

4.2

O. Heen, G. Guette, and T. Genet

Anonymity Properties

We first remark that all the participants X to a communication are using pseudonym {i.0.db}K −1 . In order to keep the long term secret KX undisclosed, the X cryptographic algorithm {}K −1 must reveal nothing about its key. This is one X basic property of asymmetric encryption algorithms. We also remark that the nodes are regularly updating their pseudonyms. In particular, they choose a new pseudonym each time they want to establish a trusted connection with other nodes. Thus, one single node can use many pseudonyms at a same time: some for untrusted relations, some other for trusted relations. Depending of whether there is trust or not, the way pseudonyms are built varies but neither form of the pseudonyms reveals anything about long term secrets. Since no permanent secret is revealed, the effective anonymity only relies on the size of the anonymity set. If the anonimity set is restricted to one single device, of course the anonimity does not hold. But in the case of VANET for instance, the typical anonymity set is the set of all pseudonyms used by all vehicles communicating in the attacker’s vicinity during the observation period. 4.3

Unobservability against Passive Attackers

Regarding unobservability, our solution exhibits three properties: 1. All communications are broadcasted. 2. All nodes are regularly sending messages. 3. All message components are encrypted or have the form g i . According to [8] §8, properties 1 and 3 imply receiver unobservability. Properties 2 and 3 imply sender unobservability. These to properties imply message unobservability, which in turns implies the unobservability of the trust relation by the argument hereafter: Ad absurdum, we assume message unobservability but not trust relation unobservability. We consider the shortest message sequence that leads the attacker to observe the trust relation. We consider the last message of this sequence: it is responsible for the detection of the trust relation (otherwise this message can be removed from the sequence, which contradicts the assumption that this is the shortest). We remark that attacker is not able to detect the trust relation without observing this last message (otherwise this also contradicts the assumption that the sequence is the shortest). Thus, reading just the last message, the attacker detects the trust relation. In other terms, the attacker is able to observe the last message, which contradicts message unobservability. In order to better illustrate the unobservability property, we provide the two tables hereafter. The first table shows the case BA and what a passive attacker can deduce. The second table shows the case without trust and what a passive attacker can deduce. α, β, γ are observed pseudonyms that the attacker cannot decrypt. The gx are observed g i values that the attacker cannot reduce (she does not know i). The mx are observed encrypted payloads.

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks

Communication when BA A → All : {i.0.db}K −1 .R.gi .m1

7

Observations of a passive attacker X1 → All : α.β.g1 .m1

A

B → All : {i.j.db}KA .{i.0.db}K −1 .gj .m2

X2 → All : γ.α.g2 .m2

A → All : {i.0.db}K −1 .{i.j.db}KA .gk .{P ublic}gij

X3 → All : α.γ.g3 .m3

A

A

B → All : {i.j.db}KA .{i.0.db}K −1 .gl .{P rivate}gij X4 → All : γ.α.g4 .m4 A

Communication when there is no trust A → All : {i.0.db}K −1 .R.gi .m1

Observations of a passive attacker X1 → All : α.β.g1 .m1

B → All : {j.0.db}K −1 .{i.0.db}K −1 .gj .m2

X2 → All : γ.α.g2 .m2

A

B

A

A

B

B

A

A → All : {i.0.db}K −1 .{j.0.db}K −1 .gk .{P ublic}gij X3 → All : α.γ.g3 .m3 B → All : {j.0.db}K −1 .{i.0.db}K −1 .gl .{P ublic}gij X4 → All : γ.α.g4 .m4

We see that the passive attacker observes the same information in both tables. In fact, the general expression of what the passive attacker observes at step n in both cases is obs(n): ⎧ ⎪ ⎨X1 → All : α.β.g1 .m1 obs(n) = Xn → All : γ.α.gn .mn ⎪ ⎩ Xn → All : α.γ.gn .mn

4.4

if n = 1, if n = 2p, if n = 2p + 1

Active Attack against Unobservability

We show here an attack found by the OFMC tool of AVISPA. The countermeasure is given in 4.5 but we find it profitable to precisely explain the attack as it is illustrative for: – the concrete benefit of using automated verification tools; – one way to defeat unobservability while keeping anonymity; – the power of active attackers and the practical conditions of the attack. If there is no trust between A and B (see 4.4) the secrecy of their subsequent communications only depends on the Diffie-Hellman key agreement performed within the third part of each message. Thus the secret only holds against a passive attacker but not against an active attacker because she can perform a man-in-the-middle attack. The practical conditions of this attack may be very complicated but one variant is much simpler. This variant is automatically found by OFMC tool of AVISPA: the figure 2 shows the corresponding message sequence chart as redrawn by the tool SPAN [5]. The attack works as follows: 1. The attacker D captures a pseudonym, for instance {j.0.db}K −1 . B 2. The node A normally starts a communication by sending: A → All : {i.0.db}K −1 .R.g i .m1 (with R some padding) A

8

O. Heen, G. Guette, and T. Genet

Fig. 2. Verification of an active attack against unobservability, as found by AVISPA and displayed by SPAN

3. The active attacker D regularly tries to answer A by sending: D → All : {j.0.db}K −1 .{i.0.db}K −1 .g.m. B A Note that the third part of the message is g (in fact any low power of g will work, like g 2 , g 3 . . .). 4. If A continues the protocol normally, it will send a message with an encrypted payload: A → All : {i.0.db}K −1 .{j.0.db}K −1 .g k .{P ublic}gi . A B Note that the encryption key g i is known by any node having received the first message. Note that some tools that we used are proven complete [15]: when no attack is found this means that there is no attack involving an arbitrary number of intruder operations. This attack is not serious per se since it only discloses information that nodes are willing to send even without trust relation. But the attack has consequences over the unobservability of the trust relation between the nodes with pseudonyms {i.0.db}K −1 and {j.0.db}K −1 : if the active attacker is able to decrypt the A B P ublic payload, this means that there is no trust relation between these nodes. Otherwise the attacker cannot decrypt the payload and then deduces that the node with pseudonym {i.0.db}K −1 detected g i  = g. This case only happens if a A trust relation exists. This attack only defeats the unobservability of the trust relation. The anonymity is still guaranteed, since there is still no way for the attacker to infer A from {i.0.db}K −1 nor to infer identity information from the P ublic payload. A

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks

4.5

9

Countermeasure

The countermeasure repairs unobservability when a message of the form {j.0.db}K −1 .{i.0.db}K −1 .g k .m is received and when the abnormal situation j  =k B A is detected (in the above description of the attack, we had k = 1). In this case, the detecting node can suspect an attack. We modify its behavior so that it falls back to a non-trust behavior instead of continuing to enforce trust. In particular it will compute the Diffie-Hellman key g jk and send public data, like {P ublic}gjk . Of course, the attacker will be able to decrypt this data. But, since decryption will always work, she will not learn anything about the trust relation. The trust relation will be successfully detected and enforced only if there is not attack, that is in the nominal case: {j.0.db}K −1 .{i.0.db}K −1 .g k .m and j = k. B

A

It might be argued that the protocol now silently fails when a node detects an attack, thus giving the attacker an additional way to perform a denial-ofservice attack. This is true but in our attacker model the attacker already have the possibility to block all messages (as often in presence of mobile wireless communications).

5

Conclusion

Privacy issues in network communications become more and more important. In particular in MANET or VANET users take care about their privacy and do not want to reveal anything about their activities and personal or professional travels. In certain cases, just detecting that Bob has meet Alice on some place may reveal partial information about industrial secrets or vendor strategies. In this kind of networks, we have provided a solution for detecting a particular trust relation between two nodes in an anonymous and unobservable way. We believe that these two properties will be of first importance in a near future in the design of security protocols, for instance in the RFID research field [16,10]. In future work, we plan to address some complexity issues of our solutions: decreasing the complexity of trust detection algorithm, reduce the use of asymmetric cryptography and add appropriate cryptographic puzzles for mitigating the exhaustion of computation resources. It is also suitable to study different trust models, not necessarily based on asymmetric cryptography.

Acknowledgment The author would like to thank Ciar´ an Bryce for valuable discussions and appreciation. The author would like to thank the WISTP 2009 reviewers for many in depth comments and useful remarks.

10

O. Heen, G. Guette, and T. Genet

References 1. D¨ otzer, F.: Privacy issues in vehicular ad hoc networks. In: Danezis, G., Martin, D. (eds.) PET 2005. LNCS, vol. 3856, pp. 197–209. Springer, Heidelberg (2006) 2. Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Compagna, L., Cuellar, J., Drielsma, P.H., He´ am, P.C., Kouchnarenko, O., Mantovani, J., M¨ odersheim, S., von Oheimb, D., Rusinowitch, M., Santiago, J.S., Turuani, M., Vigan` o, L., Vigneron, L.: The AVISPA Tool for the Automated Validation of Internet Security Protocols and Applications. In: Etessami, K., Rajamani, S.K. (eds.) CAV 2005. LNCS, vol. 3576, pp. 281–285. Springer, Heidelberg (2005) 3. Balfanz, D., Smetters, D., Stewart, P., Wong, H.: Talking to strangers: Authentication in adhoc wireless networks. In: Symposium on Network and Distributed Systems Security (NDSS 2002), San Diego, California (February 2002) 4. Blake-Wilson, S., Menezes, A.: Authenticated Diffie–Hellman key agreement protocols. In: Tavares, S., Meijer, H. (eds.) SAC 1998. LNCS, vol. 1556, pp. 339–361. Springer, Heidelberg (1999) 5. Boichut, Y., Genet, T., Glouche, Y., Heen, O.: Using Animation to Improve Formal Specifications of Security Protocols. In: 2nd Conference on Security in Network Architectures and Information Systems (SARSSI 2007), pp. 169–182 (2007) 6. Fonseca, E., Festag, A., Baldessari, R., Aguiar, R.: Support of Anonymity in VANETs - Putting Pseudonymity into Practice. In: IEEE Wireless Communications and Networking Conference (2007) 7. Gerlach, M., Festag, A., Leinm¨ uller, T., Goldacker, G., Harsch, C.: Security Architecture for Vehicular Communication. In: Workshop on Intelligent Transportation (2007) 8. Pfitzmann, A., Hansen, M.: Anonymity, unobservability, and pseudonymity: A consolidated proposal for terminology. Draft (July 2008) 9. Pfitzmann, A., K¨ ohntopp, M.: Anonymity, unobservability, and pseudonymity a proposal for terminology. In: Federrath, H. (ed.) Designing Privacy Enhancing Technologies. LNCS, vol. 2009, pp. 1–9. Springer, Heidelberg (2001) 10. Di Pietro, R., Molva, R.: Information confinement, privacy and security in RFID systems. In: Biskup, J., L´ opez, J. (eds.) ESORICS 2007. LNCS, vol. 4734, pp. 187–202. Springer, Heidelberg (2007) 11. Prigent, N., Bidan, C., Andreaux, J.P., Heen, O.: Secure long term communities in ad hoc networks. In: SASN 2003: Proceedings of the 1st ACM workshop on Security of ad hoc and sensor networks, pp. 115–124. ACM, New York (2003) 12. Schneier, B.: Blog article, tracking automobiles through their tires (December 2006) 13. Stajano, F., Anderson, R.J.: The resurrecting duckling: Security issues for ad-hoc wireless networks. In: Malcolm, J.A., Christianson, B., Crispo, B., Roe, M. (eds.) Security Protocols 1999. LNCS, vol. 1796, pp. 172–194. Springer, Heidelberg (2000) 14. Toh, C.K.: Research challenges in intelligent transportation networks. Keynote Speach at IFIP Networking 2008, Singapour (May 2008) 15. Turuani, M.: Security of Cryptographic Protocols: Decidability and Complexity. PhD thesis, Universit´e of Nancy 1 (2003) 16. van Deursen, T., Mauw, S., Radomirovi´c, S.: Untraceability of RFID protocols. In: Onieva, J.A., Sauveron, D., Chaumette, S., Gollmann, D., Markantonakis, K. (eds.) WISTP 2008. LNCS, vol. 5019, pp. 1–15. Springer, Heidelberg (2008)

On the Unobservability of a Trust Relation in Mobile Ad Hoc Networks

11

Appendix We provide here the formal specification of the protocol, as used for the verification of security properties within the AVISPA framework. role node (A:agent,Ka:public_key,KeyRing:(agent.public_key) set,SND,RCV:channel(dy)) played_by A def= local State :nat, Ni,Nj,Nj0,N0,Nb0:text, Pa,Pb,Mx,R,Dh,Mauth,Private,K:message, Kx:public_key, X:agent init State:=0 transition a0. State=0 /\ RCV(start) =|> State’:=1 /\ Ni’:=new() /\ N0’:=new() /\ Pa’:={Ni’.N0’.db}_inv(Ka) /\ R’:=new() /\ Mx’:=new() /\ SND(Pa’.R’.exp(g,Ni’).Mx’) ab1. State=1 /\ RCV(Pb’.Pa.exp(g,Nj’).Mx’) /\ Pb’={Ni.Nj’.db}_Ka =|> State’:=2 /\ K’:=exp(exp(g,Nj’),Ni) /\ Mauth’:=new() /\ N0’:=new() /\ SND(Pa.Pb’.exp(g,N0’).{Mauth’}_K’) /\ witness(A,b,bob_alice_na,Mauth’) ab2. State=2 /\ RCV(Pb.Pa.Dh’.{Private’}_K) =|> State’:=3 ac1. State=1 /\ RCV({R’}_inv(Kx’).Pa.Dh’.Mx’) =|> State’:=2 /\ Pb’:={R’}_inv(Kx’) /\ K’:=exp(Dh’,Ni) /\ Mauth’:=new() /\ N0’:=new() /\ SND(Pa.Pb’.exp(g,N0’).{Mauth’}_K’) ac2. State=2 /\ RCV(Pb.Pa.Dh’.{Private’}_K) =|> State’:=3 ba0. State=0 /\ RCV(Pa’.R’.exp(g,Ni’).Mx’) /\ Pa’= {Ni’.N0’.db}_inv(Kx’) /\ in(X’.Kx’,KeyRing) =|> State’:=5 /\ Dh’:=exp(g,Ni’) /\ Nj’:=new() /\ Pb’:={Ni’.Nj’.db}_Kx’ /\ Mx’:=new() /\ K’:=exp(Dh’,Nj’) /\ SND(Pb’.Pa’.exp(g,Nj’).Mx’) ba1. State=5 /\ RCV(Pa.Pb.Dh’.{Mauth’}_K) =|> State’:=6 /\ N0’:=new() /\ Private’:=new() /\ SND(Pb.Pa.exp(g,N0’).{Private’}_K) /\ request(X,A,bob_alice_na,Mauth’) /\ secret(Private’,sec,{A,X}) bc0. State=0 /\ RCV({Ni’.N0’.db}_inv(Kx’).R’.Dh’.Mx’) /\ not(in(X’.Kx’,KeyRing)) =|> State’:=7 /\ Pa’:={Ni’.N0’.db}_inv(Kx’) /\ Nj’:=new() /\ Nb0’:=new() /\ Pb’:={Nj’.Nb0’.db}_inv(Ka) /\ Mx’:=new() /\ K’:=exp(Dh’,Nj’) /\ SND(Pb’.Pa’.exp(g,Nj’).Mx’) bc1. State=7 /\ RCV(Pa.Pb.Dh’.{Mauth’}_K) =|> State’:=8 /\ N0’:=new() /\ Private’:=new() /\ SND(Pb.Pa.exp(g,N0’).{Private’}_K) end role role environment() def= local KeyMapA,KeyMapB,KeyMapC,KeyMapD:(agent.public_key) set, SND,RCV:channel(dy) const a,b,c,d,i:agent, ka,kb,kc,kd,ki:public_key, g,db:text, sec,nb,alice_bob_nb,bob_alice_na:protocol_id init KeyMapA:={} /\ KeyMapB:={a.ka} /\ KeyMapC:={} /\ KeyMapD:={a.ka,b.kb} intruder_knowledge={a,b,c,d,g,ki,inv(ki)} composition node(a,ka,KeyMapA,SND,RCV) /\ node(b,kb,KeyMapB,SND,RCV) end role goal secrecy_of sec authentication_on bob_alice_na end goal environment()

A Mechanism to Avoid Collusion Attacks Based on Code Passing in Mobile Agent Systems Marc Jaimez, Oscar Esparza, Jose L. Mu˜ noz, Juan J. Alins-Delgado, and Jorge Mata-D´ıaz Universitat Polit`ecnica de Catalunya, Departament Enginyeria Telem` atica, 1-3 Jordi Girona, C3 08034 Barcelona, Spain {marc.jaimez,oscar.esparza,jose.munoz,juanjo,jmata}@entel.upc.es

Abstract. Mobile agents are software entities consisting of code, data, state and itinerary that can migrate autonomously from host to host executing their code. Despite its benefits, security issues strongly restrict the use of code mobility. The protection of mobile agents against the attacks of malicious hosts is considered the most difficult security problem to solve in mobile agent systems. In particular, collusion attacks have been barely studied in the literature. This paper presents a mechanism that avoids collusion attacks based on code passing. Our proposal is based on a Multi-Code agent, which contains a different variant of the code for each host. A Trusted Third Party is responsible for providing the information to extract its own variant to the hosts, and for taking trusted timestamps that will be used to verify time coherence. Keywords: Mobile agent security, malicious hosts, collusion attack, code passing.

1

Introduction

Mobile agents are software entities that move code and data to remote hosts. Mobile agents can migrate from host to host performing actions autonomously on behalf of a user. The use of mobile agents can save bandwidth and permits an off-line and autonomous execution in comparison to habitual distributed systems. Mobile agents are especially useful to perform functions automatically in almost all electronic services, like electronic commerce and network management. Despite their benefits, massive use of mobile agents is restricted by security issues [16,10]. In this scenario, two main entities are considered to study the security weaknesses: the mobile agent (or simply agent) and the executing host (or simply host). These are the main attacks: (1) the agent attacks the host: the protection of the host from malicious agent attacks can be achieved 

This work is funded by the Spanish Ministry of Science and Education under the projects CONSOLIDER-ARES (CSD2007-00004), SECCONET (TSI2005-07293C02-01), ITACA (TSI2007-65393-C02-02), P2PSEC (TEC2008-06663-C03-01) and, by the Government of Catalonia under grant 2005 SGR 01015 to consolidated research groups.

O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 12–27, 2009. c IFIP International Federation for Information Processing 2009 

A Mechanism to Avoid Collusion Attacks

13

by using sand-boxing techniques and a proper access control [7]; (2) attacks to the communications: the protection of the agent while it is migrating from host to host can be achieved by using well-known cryptographic protocols [12]; and (3) the host attacks the agent: there is no published solution to protect agents completely from these attacks. This later attack is known as the problem of the malicious hosts. This paper introduces a new mechanism which avoids collusion attacks based on code passing. In a code passing attack, a host sends the agent’s code to another host which is not the next proper destination host, but another further in the itinerary; this host can analyze the agent’s code before arriving through the legal route. Collusion attacks are difficult to prevent or detect, and for this reason most of current approaches do not support them. Only few approaches try to limit them by using itinerary protection techniques [3,2,15]. Our mechanism involves using a different agent for each host to be resilient to these collusion attacks. To do so, we generate different variants of the code, which are merged to build up a Multi-Code Agent (MCA), which is the final entity that is sent to the hosts. When receiving the MCA, each host request to a Trusted Third Party (TTP) some extracting instructions, that is, some information that each host needs to extract its own variant from the MCA. This request is also used to obtain a trusted time reference to control the time coherence among all the hosts. This MCA has been constructed to avoid that two or more colluding hosts analyze their variants to locate possible vulnerabilities within the agent’s code. Moreover, the time references are used to limit the time of execution in the hosts, so suspicious behaviors could be detected. The rest of the paper is organized as follows: Section 2 describes the main published approaches to protect mobile agents; Section 3 details the proposed mechanism to avoid collusion attacks; finally, some conclusions can be found in Section 4.

2

Malicious Hosts

The attacks performed to a mobile agent by an executing host are considered the most difficult problem regarding mobile agent security [11,10]. It is difficult to detect or prevent the attacks performed by a malicious host during the agent’s execution. Malicious hosts could try to get some profit of the agent reading or modifying any part of the agent due to their complete control on the execution. Moreover, if two or more malicious hosts collude to perform an attack, the task of protecting the agent becomes even more difficult to achieve. These are some published approaches that deal with the problem of the malicious hosts. Some authors think that the only solution to this problem is the use of a closed tamper-proof hardware subsystem where agents can be executed in a secure way [23,22,14], but this forces each host to buy a hardware equipment and to consider the hardware provider as trusted. The environmental key generation [18] makes the agent’s code impossible to decrypt until the proper conditions happen on the environment. However, there is no protection once the code has been decrypted. Hohl presents obfuscation [8] as the mechanism to assure the execution

14

M. Jaimez et al.

integrity during a period of time, but this time depends on the capacity of the malicious host to analyze the obfuscated code. The use of encrypted programs [20] is proposed as the only way to give privacy and integrity to mobile code. The difficulty here is to find functions that can be executed in an encrypted way. Vigna [21] introduces the idea of cryptographic traces that the agent takes during execution. The origin host asks for the traces if it wants to verify execution, but verification is only performed in case of suspicion. Suspicious hosts can be detected by controlling the agent’s execution time in the hosts [6,4], but even with this complement the use of traces is still too expensive. Some other later approaches are also based on the use of Vigna’s traces [24,13], but none of them solves the problem in a satisfactory way. In [5], the authors use software watermarking techniques to detect manipulation attacks, but not collusion attacks. Roth [19] presents the idea of cooperative agents that share secrets and decisions and have a disjunct itinerary. This fact makes collusion attacks difficult, but not impossible. In [9], Hohl defines the reference states as these that have been produced in reference (trusted) hosts. Some proposals based on reference executions [1,17] have been presented, but they add too much communication overhead.

3

Multi-Code Agent

In this paper, we present a new mechanism which makes mobile agents resilient to collusion attacks based on code passing. As we mentioned previously, collusion attacks have been barely studied in mobile agent systems. In a code passing attack, a host sends the agent’s code to another host which is not the next proper destination host, but another further in the itinerary; thanks to that, this host can analyze the agent’s code before it arrives through the legal route. Figure 1.a shows a collusion attack based on code passing: the origin host sends the mobile agent to Host-1, which executes the agent properly and sends it to the next host (Host-2) using the appropriate itinerary. At the same time, Host-1 sends the agent’s code to another host in the itinerary, say Host-4, so this will have more time to analyze it in order to locate possible vulnerabilities. To avoid this, we generate different variants of the code, which are merged to build up a Multi-Code Agent (MCA), which is the final entity that is sent to the hosts. When receiving the MCA, each host requests to a TTP some extracting instructions, that is, some information that each host needs to extract its own variant. This request is also used to obtain a trusted time reference to control the time coherence among all the hosts. This MCA has been constructed to avoid that colluding hosts analyze their variants to locate vulnerabilities in the code. The time references are used to limit the time of execution in the hosts, so suspicious behaviors could be detected. Figure 1.b shows the main idea of this new mechanism. The origin host sends the MCA to the first agent in the itinerary, Host-1. This asks for the extracting instructions to the TTP in order to obtain its own variant. This request is also used to get a trusted time reference from the TTP. After that, Host-1 executes

A Mechanism to Avoid Collusion Attacks

15

&ROOXVLRQ URXWH

$JHQW

$JHQW +RVW 

2ULJLQ +RVW

D

$JHQW +RVW 

$JHQW +RVW 

+RVW 

5HODWLRQVKLS

&ROOXVLRQ URXWH 0XOWL&RGH $JHQW 0XOWL&RGH $JHQW

0XOWL&RGH $JHQW

+RVW 

2ULJLQ +RVW

E

0XOWL&RGH $JHQW

0XOWL&RGH $JHQW

+RVW 

+RVW 

+RVW 

773 5HODWLRQVKLS

Fig. 1. The code passing problem

its variant, and sends the MCA to the next host in the itinerary, Host-2. Host-1 could send the MCA (or even its variant) to another host, say Host-4 trough the collusion route. However, Host-4 cannot extract its own variant because it needs its extracting instructions, which should be provided by the TTP. As well, Host-4 cannot ask for its extracting instructions before Host-3 because the TTP controls the time coherence. 3.1

Codification Part

The codification part begins with the modification of the original agent in order to obtain different variants of it (see Figure 2.a). As it is shown, the original agent has a Code section, which contains the whole Bytecode of the agent. The original agent also has a Results section, which refers to the data structure where the results of the execution will be stored. We need to slightly modify the Code and Results sections of the original agent to construct a variant for each host in the agent’s itinerary. In this particular example, there are three variants of the original agent because the agent is going to be executed in three different hosts. These new variants of the agent have to accomplish two basic functions: providing a different Bytecode, and providing a different data structure for the results of the execution. After obtaining all the variants, the codifier takes the Bytecode of each of them and builds the MCA. This process is divided in three steps: Merging, Meshing up, and Compressing. The merging step (see Figure 2.b) involves taking the Bytecode of all agents and putting them all together in a single file. The meshing up step (see Figure 2.c) involves mixing the

16

M. Jaimez et al. 2ULJLQDO $JHQW &RGH

5HVXOWV 0XOWL&RGH $JHQW

0HUJLQJ

0L[LQJ

&RPSUHVVLQJ

&RGH  9DULDQW 

5HVXOWV  &RGH 

5HVXOWV 

9DULDQW 

5HVXOWV  5HVXOWV  5HVXOWV  5HVXOWV  &RGH 

5HVXOWV 

5HVXOWV 

5HVXOWV  5HVXOWV 

G

5HVXOWV 

9DULDQW  E

F

5HVXOWV  D

Fig. 2. Codification part

code instructions of the different agent variants. And finally, the compressing step (see Figure2.d) involves eliminating redundancy. At the end of the codification part, we have the MCA, which includes a Code section which contains the Bytecode of all the agent variants, and a Results section where the execution results of each host will be stored. Creation of the new agents. The Multi-Code agent contains the code of all the variants of an original agent. These variants have to accomplish two basic functions: providing a different Bytecode (we want each host to execute a different agent), and providing a different data structure for the results of the execution (we want to verify that each host has executed the right agent). The process of creating the new agent variants is divided in two steps: Step1. Modification of the code to obtain different data structures. In this step we modify the Results section of the original agent to obtain a Results section for each variant. Each of these must contain an Identity Mark, which is a data structure that will demonstrate that each host has executed its own variant.

A Mechanism to Avoid Collusion Attacks

17

The way that each host uses to put all this information (the values themselves, their order and their relationships) within the results section is how this host in particular implements its Identity Mark. This Results section is finally fitted within the MCA, and sent to the next host. Step2. Modification of the code to obtain Bytecode variability. The goal of this step is to obtain a set of new agent variants that will perform the same tasks than the original agent, but using a different code. We need the agents to be different and difficult to analyze. However, we recommend the agents to have a similar structure (same classes, methods, names, variables, etc) and use the code of the methods to introduce differences among variants. If we take into account this restriction, we will be able to reduce significantly the length of the MCA and the length of the extraction instructions. Just notice that using the same structure for all the variants does not directly mean that we have to maintain the structure of the original agent. To illustrate the importance of maintaining the basic structure of the classes in each agent variant, we will give a simple example with an original agent and two variants of it. Figure 3.a shows the code of the original agent, which has a single class named OriginalAgentCode. The class contains a single method named method1() that calculates a simple arithmetic operation a = 10 + 20 and returns the value of the result. In the example, we take the same structure of the original agent to create the new agent variants (one class and one method), but we add two new variables, b and c, to make the code of the method different. These new variables will allow us to perform the same arithmetic operation in different ways. Figure 3.b shows the code of the first variant, and Figure 3.c shows the code of the second variant. We have measured the size of this example in terms of Bytecode, and both variants weight 3328 bits, but only 144 bits are different (only a 3.42% of the Bytecode is different from one variant to another). These similarities are due to the fact that we have used the same structure for the two variants. If there were

SXEOLF FODVV 2ULJLQDO$JHQW&RGH ^

SXEOLF FODVV 2ULJLQDO$JHQW&RGH$ ^

SXEOLF FODVV 2ULJLQDO$JHQW&RGH% ^

LQW PHWKRG ^

LQW PHWKRG ^ LQW D    UHWXUQ D ` `

D

LQW PHWKRG ^

LQW D LQW E LQW F

LQW D LQW E LQW F

D  E   D F D  E UHWXUQ F

F  D F   E D  F UHWXUQ E

`

`

`

`

E

Fig. 3. Original code and two agent variants

F

18

M. Jaimez et al.

more than two hosts in the agent’s itinerary, we would need more agent variants, and we should implement the same arithmetic operation in other ways. Building an Identity Mark. The Identity Mark is a vector that contains n values. These values could correspond to execution results Ri or to intermediate values Vj . A simple example of the implementation of an Identity Mark with n = 5 is shown in Figure 4. The Host executes its variant and obtain two values corresponding to execution results (R1 , R2 ) and three intermediate values (V 1 , V 2 , V 3 ). With all these values, the agent builds a data structure that implements its particular Identity Mark, and which also contains the execution results. Finally, this data structure is sent to the origin host using the MCA. The strength of the Identity Mark is based on two main characteristics: 1. The order of the values: the Identity Mark is an ordered vector of n values. So then, n! possible Identity Marks are possible by simply ordering the values in different ways. Hence, the probability of generating the particular Identity 1 Mark of a certain variant will be n! . In the example of 4, the Identity Mark contains five values (R1 , R2 , V 1 , V 2 , V 3 ), which could be stored following one hundred and twenty different sequences. 2. The intermediate values: not only the order of the values is specific for each agent, but the values themselves are obtained in a different way depending on each agent. We assume that values corresponding to execution results (Ri ) cannot be changed. However, intermediate values Vj can be computed in different ways. For instance in the example of Figure 4, the computation of V 2 in Agent A may depend on R1 , V 1 or some other input data only used in Agent A code. On the other hand, the computation of V 2 in Agent B may depend only on R2 . Thanks to that, a host cannot establish any direct relationship between V 2 from Agent A, and V 2 from Agent B. As it can be directly deduced, increasing the number of values n of the the Identity Mark vector provides much more possibilities to protect the agent from collusion attacks. In Subsection 3.5, a detailed example of a collusion attack

+RVW  ([HFXWLRQ 5HVXOWV 5

2WKHU YDOXHV 9

5

0XOWL&RGH $JHQW

9

9

5HVXOWV  5HVXOWV 

9

5

9  5 9 

5HVXOWV 

Fig. 4. Example of an Identity Mark

A Mechanism to Avoid Collusion Attacks

19

is provided, and it is stated that even if a host has analyzed the code of another agent variant, the probability of generating a valid Identity Mark for its designated variant is very low. Merging. On this step, the java files are compiled, the class files are obtained, and finally these class files are merged to build the MCA. Following with the previous example proposed in Section 3.1, we compile the OriginalAgentCodeA.java file and the OriginalAgentCodeB.java file, and we obtain two new files: the OriginalAgentCodeA.class file and the OriginalAgentCodeB.class file. A detailed example of the merging process concerning the Bytecode is given in Figure 5. Starting from the original Agent (Figure 5.a), the two new agents variants are created. Figure 5.b corresponds to the specific Bytecode of the Original Agent A, which is colored black. Figure 5.c corresponds to the specific Bytecode of the Original Agent B, which is Grey colored. Finally, Figure 5.d shows the resultant Bytecode of the MCA (without mixing and compressing). For simplicity, the rest of the Bytecode code, which is shared by both agents (variant A and variant B) and the MCA, is not shown in Figure 5.

2ULJLQDO$JHQW 

1RQ 0L[HG 0XOWL&RGH $JHQW 

ELSXVK  LVWRUHB



LVWRUHB



LORDGB



ELSXVK 



LORDGB

2ULJLQDO$JHQW$

2ULJLQDO$JHQW%



ELSXVK 



ELSXVK 



LVWRUHB



LVWRUHB



ELSXVK 



LORDGB



ELSXVK 



LORDGB



LDGG



LDGG



LVWRUHB



LVWRUHB



LORDGB



LORDGB



LORDGB



LORDGB

 LDGG

 LDGG

 LVWRUHB

 LVWRUHB

 LORDGB

 LORDGB

 LUHWXUQ

 LUHWXUQ

E

F

0HUJLQJ



ELSXVK 



D

0L[HG 0XOWL&RGH $JHQW



ELSXVK 



ELSXVK 

ELSXVK 



LVWRUHB



LVWRUHB



ELSXVK 



LORDGB



LORDGB



ELSXVK 



LVWRUHB



LORDGB



LVWRUHB



LDGG



ELSXVK 



LVWRUHB



LORDGB



LORDGB



LORDGB



LORDGB

 LDGG

)LQDO 0XOWL&RGH $JHQW

 ELSXVK 

 LDGG  LVWRUHB

 LVWRUHB  LORDGB

 LDGG

 LVWRUHB

 LUHWXUQ

 LDGG

 LORDGB

 ELSXVK 

 LVWRUHB

 LORDGB

 LVWRUHB

 LORDGB

 LVWRUHB

 LORDGB

 LDGG

 LORDGB

 LORDGB

 LVWRUHB

 ELSXVK 

 LORDGB

 LVWRUHB

 LORDGB

 LORDGB

 LDGG

 LDGG

 LORDGB

 LVWRUHB

 LDGG

 LUHWXUQ

 LORDGB

 LVWRUHB

 LORDGB

 LVWRUHB

 LDGG

 LORDGB

 LVWRUHB

 LORDGB

 LORDGB

 LUHWXUQ

 LUHWXUQ

 LUHWXUQ

I

H

G

0L[LQJ

&RPSUHVVLQJ

Fig. 5. A Bytecode view of the Multi-Code Agent construction

20

M. Jaimez et al.

Mixing. We have started from an Original Agent, which has been modified to obtain two different implementations of it. After that, these new agents have been merged to build up a single MCA. Now, the code of the agents is going to be mixed up. Before the mixing, the black and grey Bytecode is separated in two areas, and it is easy to identify them by an attacker. After the mixing, an attacker will have difficulties to identify which Bytecode corresponds to each variant. A detailed example of the mixing process concerning the Bytecode is given in Figure 5.e, which shows a possible final distribution of the Bytecode instructions after the mixing process. It is important to stress that the new instruction distribution order, in the Mixed Multi-Code Agent, could be any. The more altered is the instruction order in the MCA, the more difficult is to understand the Bytecode. However, the complexity and length of the extracting instructions increases among the alteration of the instruction order. In our case, we are going to preserve the natural order of the instructions in order to simplify the extracting instructions. Compressing. The last modification in the Multi-Code codification part is compressing the Bytecode instructions. As a result of the mixing process, some consecutive Bytecode instructions are equal, and every time this duplicity happens, we can erase one of the duplicated instructions (see Figure 5.f). Although the length of the code is reduced, the compressing factor is very low if we take into account the whole agent code. In the case of the example, the length of the MCA before the compressing step is 3472 bits, and the length after the

$JHQW $

0XOWL&RGH $JHQW

$JHQW %



ELSXVK 



ELSXVK 





LVWRUHB



LVWRUHB





LVWRUHB





ELSXVK 





LORDGB





LORDGB







ELSXVK 



 LDGG

 LDGG

 LDGG

 LVWRUHB

 LVWRUHB





 LVWRUHB

 LVWRUHB

 LORDGB

 LORDGB

 LORDGB

 LORDGB

 LORDGB





 LORDGB

 LORDGB

 LDGG

 LDGG

 LDGG

 LVWRUHB

 LVWRUHB





 LVWRUHB

 LVWRUHB

 LORDGB

 LORDGB





 LORDGB

 LORDGB

 LUHWXUQ

 LUHWXUQ

 LUHWXUQ

 

ELSXVK 

 

LORDGB

E

D

ELSXVK 

$JHQW $ ([WUDFWLQJ ,QVWUXFWLRQV 9HFWRU

LVWRUHB 





   

G

LORDGB ELSXVK 

$JHQW % ([WUDFWLQJ ,QVWUXFWLRQV 9HFWRU 





   

H

F

Fig. 6. Generating the Extracting Instructions

A Mechanism to Avoid Collusion Attacks

21

compressing step is 3424 bits. This means that we have reduced the MCA’s length only by a factor of 1.38%. However, compression is necessary to add some extra complexity to the resulting code. For an attacker, it is more difficult to extract a certain agent if some of the instructions have been erased. Extracting instructions. When a certain Host receives the MCA, it has to extract its corresponding agent variant. To do so, the Host needs to know which of the Bytecode instructions belongs to its own agent. This information is what we call Extracting Instructions. The information contained in the Extracting Instructions is a list of memory positions. These memory positions indicate which Bytecode instructions do not belong to the agent that is being extracted (blacklist). Figure 6 shows the process of generating the Extracting instructions. The MCA contains a compressed mixture of the different agent variants (see Figure 6.a). The black cells contain the Bytecode instructions of agent A; the grey cells contain the Bytecode instructions of agent B; and white cells contain Bytecode instructions that are shared by both agents. For instance, to obtain agent A, we only need to preserve the cells that contain Bytecode instruction of agent A (Figure 6.b); and the same with agent B (Figure 6.c). Once the cells containing other Bytecode instructions are identified, we store this information in a vector (Figure 6.d, Figure 6.e). 3.2

Distribution Part

Before sending the agent, the origin host must send the whole set of extracting instructions to the TTP (one for each host). The TTP will be in charge of their management. Thus, the origin host is free from having to stay on line while the agent is roaming the net. This process is shown in Figure 7: – Step 1: The origin host sends the set of extracting instructions (I1 , I2 ,..., IN ) to the TTP for their management (in our example N = 2). – Step 2: The origin host sends the MCA to the first host in the itinerary (Host-1). After this step, the origin host stays offline until the MCA arrives from the last host carrying all the results. – Step 3: Host-1 receives the MCA and request the extracting instructions to the TTP. – Step 4: The TTP authenticates Host-1, and it sends I1 , which are the extracting instructions that corresponds to Host-1. It also stores the time in which Host-1 asked for its extracting instructions T1 . – Step 5: Host-1 extracts and executes its variant, and it appends the results of its execution D1 to the MCA before sending the whole package to the next host Host-2. – Step 6 and 7: The rest of hosts of the itinerary perform the same actions than Host-1. – Step 8: When the last host has asked its extracting instructions, the TTP sends back the collected timestamps (T1 , ..., TN ) to the origin host. – Step 9: The last host sends back the MCA containing all the execution results (D1 , ... ,DN ) to the origin host.

22

M. Jaimez et al.

 

7

7UXVW 6HUYHU





5HVSRQVH ,QVWUXFWLRQ

,

,

,QVWUXFWLRQ

5HTXHVW

7

,5 HT

,5 HVS



 0XOWL&RGHG $JHQW

' 0XOWL&RGHG $JHQW



 +RVW RULJLQ

+RVW 

+RVW 

'



' 0XOWL&RGHG $JHQW

Fig. 7. Distribution of the Multi-Code Agent

3.3

Timestamps Verification

The TTP has been storing a time reference for each valid Instruction Request message sent by the hosts. Thanks to that, it is possible to calculate the period of time in which the agent variant has been available for a host. Figure 8 draws the timeline of part of the distribution part to show that the TTP gets the timestamps just when it sends the Instruction Response message to the hosts. These timestamps are used by the origin host to verify the time coherence of the execution. The origin host can calculate Ti = Ti+1 − Ti . This period of time (Ti ) includes the extraction time of the agent, the execution time of the agent, the transmission time of the Multi-Coded Agent to the next host, the propagation delay, and the time interval between the reception of the MCA, and

7LPHVWDPS 7

7LPHVWDPS 7 ¨7

7 7 ¨70D[

,5HV

,5HV 773

,5HT

([WUDFW ([HFXWLRQ

'

7L

0&$

¨7+RQHVW +RVW

7L

+RVW 

'

0&$

,5HT

([WUDFW ([HFXWLRQ

+RVW  +RQHVW

'L

0&$

,5HT L ,5HV 773

¨70DOLFLRXV +RVW

'

0&$

,5HT

([WUDFW

"""""""""""""""""""

+RVW  0DOLFLRXV

Fig. 8. Timestamps storing

([HFXWLRQ

'M

0&$

,5HT L ,5HV 773

A Mechanism to Avoid Collusion Attacks

23

the Instruction Response message. With this information, the origin host will be able to estimate accurately the execution time of the agent. Depending on the computational capabilities of the hosts, and the resources needed for the agent to execute, the origin host can estimate a maximum allowed time of execution (TMax ). In case that any Ti is greater than this value, the hosts will be suspicious of performing malicious activities. Figure 8 shows two time-lines, one in which Host-2 acts honestly, and another one in which acts maliciously. If Host-1 acts honestly, the origin host will detect that THonestHost < TMax . On the other hand, if the origin host detects that TMaliciousHost > TMax , Host-2 is suspicious of performing malicious actions. 3.4

Data Coherency Verification

As mentioned earlier, each agent has a particular Identity Mark, which is codified on the execution results. By checking these Identity Marks, we will be able to verify which variant has been executed by each host. At the end of the process, the Origin Host receives the MCA with the execution results of all the hosts. Then, one by one it takes the results of each Host, and extracts its Identity Mark. If the Identity Mark corresponds to the proper host, there is a positive match and we assume that this particular host has executed its proper variant. Otherwise, we assume that the Host has executed any other agent variant, and we tag it as malicious because it has performed a collusion attack. 3.5

An Example of a Collusion Attack Based on Code Passing

As we explained previously, in a code passing attack, the first colluding host sends the code of its agent to a second colluding host further in the agent’s itinerary. This second colluding host will have more time to analyze this code to find possible vulnerabilities. Afterwards, the second host will try to obtain a favorable execution when it receives the agent from the legal route. We are trying to avoid this kind of attack using a Multi-Code Agent. Let us suppose that the MCA has an itinerary of twenty hosts, and two of them are willing to collude to perform a code passing attack. The origin hosts builds a MCA including twenty variants of the original agent, one for each host in the itinerary. Figure 9 gives an overview of the actions taken by the colluding hosts (Host-1 and Host-13) trying to perform the code passing attack. Host-1 receives the MCA from the origin host, and it asks the TTP for its extracting instructions. Once Host-1 has its extracting instructions, it sends all the information to Host 13 (the MCA, its extracting instructions, its variant, or whatever other information that could be used to attack the agent). After that, Host-1 continues with the execution of its Agent Variant (Host-1 extracts Variant A, Host-2 extracts Variant B, ..., Host-13 extracts Variant M, etc). At this point, while the MCA follows its normal route (see Figure 9.a), Host-13 has received privileged information from the collusion route (see Figure 9.b). Thanks to that, Host 13 has extra time to analyze all this information (the MCA, the extracting instructions of Host-1, Variant A) to guess how Variant M will be and try to tamper it

24

M. Jaimez et al.

2ULJLQ +RVW

7LPHOLQH

0&$

,5HT

7

0&$  ,5HVS

+RVW 

773

+RVW 

0&$

,5HVS

E

 ([WUDFWLQJ 9DULDQW 0

7

+RVW 

 ([WUDFW 9DULDQW $

7

E

 ([HFXWH 9DULDQW $

0&$

 5HVXOWV IRU 9DULDQW $ 

+RVW 

$ $ $ $ $ Â $QDO\]H 9DULDQW $

E

 0RGLI\LQJ 9DULDQW $ WR REWDLQ D IDYRXUDEOH H[HFXWLRQ

7

+RVW 

$

0&$

,5HT

7

 )DYRXUDEOH 5HVXOWV 

773

+RVW 



$



$

$





$



 ([WUDFW 9DULDQW 0

,5HVS

E

 ([HFXWH 9DULDQW 0  5HVXOWV IRU 9DULDQW 0 

0 0 0 0 0 Â 8VH LQIRUPDWLRQ IURP 9DULDQW $ WR PRGLI\ 9DULDQW 0 H[HFXWLRQ

0&$

+RVW 

7 D

DQDOLV\V

 $WWDFK IDYRXUDEOH 5HVXOWV IURP 9DULDQW $ H[HFXWLRQ

E

+RVW  E

Fig. 9. A collusion attack based on code passing

before the execution. The first attack that Host-13 can attempt is trying to guess which instructions are part of its Variant M (see Figure 9.b1). This is impossible before obtaining the corresponding extracting instructions from the TTP, because all instructions of the MCA are susceptible of being part of Variant M. Another attack that Host 13 can try to perform is using Variant A to infer which are the intentions of the agent, and trying to understand how the Identity Mark is created to forge variant M when the MCA arrives from the legal route. As Host-1 has sent its extracting instructions to Host-13, it can extract Variant A and execute it. This execution will create a vector with the values [A1 A2 A3 A4 A5 ]. But this vector in particular does not correspond to the identity mark of Host-1 (because the values depend on the host in which we have executed the variant, in this case Host-13), nor to the identity mark of Host-13 (because we have executed variant A, not variant M). Host-13 can try to analyze these values to understand how the Identity Mark is constructed (see Figure 9.b2). However, this analysis

A Mechanism to Avoid Collusion Attacks

25

will only provide the particular way in which Host-1 should construct the vector, but there are n! possible ways of ordering these values (in this particular example, the number of values of the vector is n = 5), and only one correspond to Host-13. In addition, some of these five values correspond to execution results (Ri ), and the rest corresponds to intermediate values (Vi ), but in fact the host does not know the type of each of these values. As it is shown in Figure 10.a, Host 13 cannot extrapolate the relationship between Ai and V i or Ri . At last, Host-13 can also try to modify the code of Variant A to obtain a favorable execution. This tampered execution will generate different values [A∗1 A∗2 A∗3 A∗4 A∗5 ] (see Figure 9.b3) that could be used later to compare with the values obtained in a honest execution. When finally Host 13 receives the MCA from Host 12 (from the legal route), it asks the TTP for its extracting instructions and obtain its Variant M. Now, Host 13 has a limited time to execute Variant M, so it cannot expend much time in a deep analysis of the code. For that reason, the only thing it could do is to execute its Variant M honestly to obtain [M 1 M 2 M 3 M 4 M 5 ], and use the previous experience to modify these values and obtain a favorable execution (see Figure 9.b4). This would be possible to achieve in case that both variant A and M build the values of the Identity Mark vector in the same way, but each agent calculates these values in a different way

)LUVW DWWHPSW ([HFXWLQJ DQG GHHS DQDOL]\LQJ 9DULDQW $

6HFRQG DWWHPSW ([HFXWLQJ DQG TXLFN DQDOL]\LQJ 9DULDQW 0

8VLQJ UHVXOWV RI H[HFXWLRQ

8VLQJ UHVXOWV RI 9DULDQW $ DQG 9DULDQW 0 H[HFXWLRQ

$

$

$

$

$

0 0 0 0 0

"

"

"

"

"

"

"

"

"

9

5

9

5

9

9

9

5

9

1RW HQRXJK LQIRUPDWLRQ WR XQGHUVWDQG WKH ,GHQWLW\ 0DUN 6WUXFWXUH

([HFXWLQJ D PRGLILHG YHUVLRQ RI 9DULDQW $ $



$



$



$



"

$ $ $ $ $ "

" "

5

"

"

"

"

9 5 9 5 9

1RW HQRXJK LQIRUPDWLRQ WR XQGHUVWDQG WKH ,GHQWLW\ 0DUN DQG QRW HQRXJK WLPH WR REWDLQ D IDYRXUDEOH H[HFXWLRQ RI 9DULDQW 0

E

$

2EWHQWLRQ RI IDXYRUDEOH 5HVXOWV

D

Fig. 10. Understanding the Identity Mark

26

M. Jaimez et al.

and in a different order. In conclusion, Host 13 cannot determine the identity mark structure (see Figure 10.b).

4

Conclusions

This paper introduces a new mechanism to avoid collusion attacks based on code passing. The mechanism is based on building a Multi-Code Agent which contains different variants of an original agent code. Each agent variation is executed in a different host, and thanks to that, any information shared by colluding hosts is useless. The introduction of a TTP, which takes charge of distributing the extraction instructions and collecting timestamps, allows us to detect and avoid code passing attacks. Although the Multi-Code Agent contains different agent variants; the length of the Multi-Code Agent is practically equal to the length of a single agent. Therefore, we avoid the wasting of bandwidth, which is a typical drawback when using several agents. With the inclusion of an identity Mark in the results section of the agent variants, we could verify that each host has executed its specified agent variant. Finally, the use of the TTP to obtain trusted timestamps allows us to limit the time used by the hosts to execute the agents.

References 1. Benachenhou, L., Pierre, S.: Protection of a mobile agent with a reference clone. Computer Communications 29(2), 268–278 (2006) 2. Borrell, J., Robles, S., Serra, J., Riera, A.: Securing the Itinerary of Mobile Agents through a Non-Repudiation Protocol. In: IEEE International Carnahan Conference on Security Technology (1999) 3. Westhoff, D., Schneider, M., Unger, C., Kaderali, F.: Methods for Protecting a Mobile Agent’s Route. In: Zheng, Y., Mambo, M. (eds.) ISW 1999. LNCS, vol. 1729, p. 57. Springer, Heidelberg (1999) 4. Esparza, O., Mu˜ noz, J.L., Soriano, M., Forn´e, J.: Punishing Malicious Hosts with the Cryptographic Traces Approach. New Generation Computing 24(4), 351–376 (2006) 5. Esparza, O., Mu˜ noz, J.L., Soriano, M., Forn´e, J.: Secure brokerage mechanisms for mobile electronic commerce. Computer Communications (Elsevier) 29(12), 2308–2321 (2006) 6. Esparza, O., Soriano, M., Mu˜ noz, J.L., Forn´e, J.: Implementation and Performance Evaluation of a Protocol for Detecting Suspicious Hosts. In: Horlait, E., Magedanz, T., Glitho, R.H. (eds.) MATA 2003. LNCS, vol. 2881, pp. 286–295. Springer, Heidelberg (2003) 7. Haridi, S., Van Roy, P., Brand, P., Schulte, C.: Programming languages for distributed applications. New Generation Computing 16(3), 223–261 (1998) 8. Hohl, F.: Time Limited Blackbox Security: Protecting Mobile Agents From Malicious Hosts. In: Vigna, G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 92–113. Springer, Heidelberg (1998) 9. Hohl, F.: A Framework to Protect Malicious Hosts Attacks by Using Reference States. In: International Conference on Distributed Computing Systems, ICDCS (2000)

A Mechanism to Avoid Collusion Attacks

27

10. Jansen, W.: Countermeasures for Mobile Agent Security. In: Computer Communications, Special Issue on Advanced Security Techniques for Network Protection (2000) 11. Jansen, W., Karygiannis, T.: Mobile Agent Security. Special publication 800-19, National Institute of Standards and Technology, NIST (1999) 12. Kinny, D.: Reliable agent communication - a pragmatic perspective. New Generation Computing 19(2), 139–156 (2001) 13. Leung, K.-K., Ng, K.: Detection of Malicious Host Attacks by Tracing with Randomly Selected Hosts. In: Yang, L.T., Guo, M., Gao, G.R., Jha, N.K. (eds.) EUC 2004. LNCS, vol. 3207, pp. 839–848. Springer, Heidelberg (2004) 14. Ma˜ na, A., Lopez, J., Ortega, J.J., Pimentel, E., Troya, J.M.: A framework for secure execution of software. International Journal of Information Security 3(2), 99–112 (2004) 15. Mir, J., Borrell, J.: Protecting Mobile Agent Itineraries. In: Horlait, E., Magedanz, T., Glitho, R.H. (eds.) MATA 2003. LNCS, vol. 2881, pp. 275–285. Springer, Heidelberg (2003) 16. Oppliger, R.: Security issues related to mobile code and agent-based systems. Computer Communications 22(12), 1165–1170 (1999) 17. Ouardani, A., Pierre, S., Boucheneb, H.: A security protocol for mobile agents based upon the cooperation of sedentary agents. J. Network and Computer Applications 30(3), 1228–1243 (2007) 18. Riordan, J., Schneier, B.: Environmental Key Generation Towards Clueless Agents. In: Vigna, G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 15–24. Springer, Heidelberg (1998) 19. Roth, V.: Mutual protection of cooperating agents. In: Vitek, J. (ed.) Secure Internet Programming. LNCS, vol. 1603. Springer, Heidelberg (1999) 20. Sander, T., Tschudin, C.F.: Protecting mobile agents against malicious hosts. In: Vigna, G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 44–60. Springer, Heidelberg (1998) 21. Vigna, G.: Cryptographic traces for mobile agents. In: Vigna, G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 137–153. Springer, Heidelberg (1998) 22. Wilhelm, U.G., Staamann, S., Butty´ an, L.: Introducing trusted third parties to the mobile agent paradigm. In: Vitek, J. (ed.) Secure Internet Programming. LNCS, vol. 1603. Springer, Heidelberg (1999) 23. Yee, B.S.: A sanctuary for mobile agents. In: DARPA workshop on foundations for secure mobile code (1997) 24. Yu, C.M., Ng, K.W.: A flexible tamper-detection protocol for mobile agents on open networks. In: International Conference of Information and Knowledge Engineering (IKE 2002) (2002)

Privacy-Aware Location Database Service for Granular Queries Shinsaku Kiyomoto1, Keith M. Martin2 , and Kazuhide Fukushima1 1

KDDI R & D Laboratories Inc. 2-1-15 Ohara, Fujimino-shi, Saitama 356-8502, Japan [email protected] 2 Information Security Group, Royal Holloway University of London Egham, Surrey TW20 0EX, UK [email protected]

Abstract. Future mobile markets are expected to increasingly embrace location-based services. This paper presents a new system architecture for location-based services, which consists of a location database and distributed location anonymizers. The service is privacy-aware in the sense that the location database always maintains a degree of anonymity. The location database service permits three different levels of query and can thus be used to implement a wide range of location-based services. Furthermore, the architecture is scalable and employs simple functions that are similar to those found in general database systems. Keywords: Location-based services, Privacy, k-anonymity.

1

Introduction

Future mobile markets are expected to increasingly embrace location-based services. These permit roaming users to locate local service providers (hotels, railway stations etc.), as well as enabling services that track a mobile user such as child safety applications. Although it creates many new service opportunities, the ability to locate and track mobile users also represents a threat to location privacy [3] if location information falls into the hands of unauthorized parties. It is clear that location-based services cannot be offered without users providing some degree of location information, so the demand for services and the desire for location privacy have the potential to conflict. There are three common approaches to obfuscating location information to provide privacy-aware location-based services [13]: 1. Kido et. al. proposed a false dummy method [10], where a user sends n different locations to a location database server, with only one of them being correct (the rest are “dummies” that mask the true location). While effective for location privacy, this type of masking is obstructive for location-based service providers. O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 28–37, 2009. c IFIP International Federation for Information Processing 2009 

Privacy-Aware Location Database Service for Granular Queries

29

2. Hong and Landay introduce an architecture based on landmark objects [9], where users refer to the location of a significant object (landmark) in their vicinity, rather than sending an exact location. This scheme makes it difficult to control the granularity of location information and thus may not be suitable for some types of location-based services. 3. For many service providers it is sufficient to provide approximate, rather than exact location information. The idea of location perturbation is to blur the exact location information. Recent research [13] has focused on establishing location anonymity in a spatial domain. This approach uses a location anonymizer, which is a trusted server that anonymizes location information within a defined anonymizing spatial region (ASR). Location anonymity is provided to the extent that an attacker cannot determine precisely where a given user is in the ASR (although they do know that they are located in the ASR). Location perturbation provides an attractive compromise approach, but most existing schemes have two potentially restrictive features: 1. They utilize a centralized location anonymizer which gathers location information for all users, thus creating a potential bottleneck. 2. They focus on private queries, which seek the approximate location of a specific user, but do not permit other types of location-based query such as personal tracking services (see Section 3.2). In this paper, we propose a new system architecture for location-based services which avoids the bottleneck of a centralized anonymizer and can be used to support granular service queries. More particularly: – Location information is registered in a common location database, but the task of anonymizing location information is distributed across a number of independent location anonymizers. This provides better scalability and reliability than the centralized approach. – The location database accepts three types of queries, public, private, and personal, which can be used to implement a variety of different locationbased services. – Location anonymization uses structured location information and satisfies a notion of anonymity for public databases called k-anonymity (see Section 3.3) even when there is an unbalanced distribution of users. Furthermore, users can control the granularity of location information provided to the other parties if desired.

2

Related Work

Various location perturbation techniques have been suggested for obfuscating location information. Gruteser and Grunwald [8] suggested “blurring” the user’s location by subdividing space in such a way that each subdivision has at least

30

S. Kiyomoto, K.M. Martin, and K. Fukushima

k − 1 other users. Gedik and Liu [6] adapted this to allow users to have personalized values of the masking parameter k. Mokbel et. al. presented a hierarchical partitioning method to improve the efficiency of location perturbation [14], however it was shown in [7] that this fails to provide location anonymity under non-uniform distribution of user locations. Selection of optimal subdivision spaces was investigated in [12,1]. Finally, in [7] a decentralized approach without an anonymizer was considered in order to realize a good load balancing property, however communication between users is required to calculate anonymized location information. More generally, private information retrieval models privacy leakage from queries to a database. Several schemes have been proposed to hide query information from the database that receives the queries [5]. Thus these schemes focus on privacy of query senders, which are the service providers in our scenario. In contrast, we wish to protect privacy of users who register location data with a location database. Another approach to protecting data privacy in a database is to use searchable encryption schemes [16,4]. These provide secure search functions for encrypted data. However, these schemes require a cryptographic computation for each record in the database, making them relatively inefficient. Bellare et. al. [2] proposed an efficient searchable encryption scheme that retrieves data in time logarithmic to the size of the database, however it has a relatively high false-positive response. Thus it would seem that the problem of providing privacy-aware locationbased services in an efficient and scalable manner remains open.

3 3.1

Preliminaries System Architecture

The system architecture is shown in Figure 1. The system consists of the following four entities: – Location Database. This centralized database stores location information of users. The location database is assumed to be honest and allows public access to registered location information. – User Terminals. We assume that users carry mobile devices with embedded positioning capabilities which have access to a wireless network. As in previous research, it is assumed that the network address of a user terminal is a virtual address that changes when the terminal moves and which cannot be used to identify its real location. – Location Anonymizers. These trusted servers receive location information from user terminals and register/update anonymized location information to the location database. They are responsible for checking whether it is “safe” (from a privacy perspective) to register location information. We assume that secure and authenticated communication channels exist between location anonymizers and the other entities.

Privacy-Aware Location Database Service for Granular Queries

Location Location Anonymizer Location Anonymizer Anonymizer

Anonymized Location Info .

Public/Private Query

Location Database

Results

31

Service Service Service Provider Provider Provider

Number of Records

Location Info.

Personal Query

Results

Users Users User Terminal Service Request Service

Fig. 1. System Architecture

– Service Providers. Service providers provide a variety of location-based services to user terminals using location information from the location database.

3.2

Service Model

A general service model is now described consisting of three types of location database query. Public and private queries were previously defined in [13], however we extend the service model to include personal queries: – Public Queries. These are general queries regarding user location information. An example is a query about the approximate number of users in a certain area. Public queries are the least threatening to location privacy since they often only require approximate answers and do not involve specific user identities. – Private Queries. These relate to approximate location information of a specific user. Location privacy is clearly threatened by this type of query, hence the importance of applying suitable location perturbation techniques. – Personal Queries. These relate to exact location information of a user. Personal queries should only be satisfied if the inquirer is authorized to extract such information from the location database. Personal queries can be used to enable user tracking.

3.3

Location Privacy Requirement

The main location privacy requirement of our system is that service providers should only know the granularity of location information of a user that they

32

S. Kiyomoto, K.M. Martin, and K. Fukushima

are entitled to. As a measure of anonymity of location information we adopt the notion of k-anonymity of a public database [15], which is satisfied if each database record is indistinguishable from at least k−1 other records with respect to specific identifying attributes. In our context, if the location database provides k-anonymity then any (private) query which requires location obfuscation should result in the attributes defined in the query (normally defining an ASR) matching at least k potential locations stored in the location database. This results in the inquirer having a predefined degree of uncertainty about the exact location of the target user. 3.4

Representation of Location Information

We represent location information using an intuitive hierarchical structure, which could be instantiated by geopolitical boundaries (country, state, city, street, post code) or topographical coordinates (such as structured granularity of GPS data). Location information of user i is represented as an l-tuple of attributes (A1i , A2i , . . . , Ali ), where Aji is more fine-grained than Aj−1 in the hierarchy of i location information. Users can thus control disclosure of their location information by concealing attributes beyond a specific layer of granularity. For example, if user i wishes to only reveal three layers of location information then they specifiy their location as (A1i , A2i , A3i , −, . . . , −), where − is an empty field. 3.5

Anonymized Identifiers for Location Database

An important feature of our system is that each location database entry is indexed in the location database using an anonymized identifier, which is randomly generated. This anonymized identifier distinguishes the location database entry from all others, but the relationship between this anonymized identifier and the user should only be known by the user themselves and any parties (service providers) authorized by them. We will use the notation Iijt to denote an anonymized identifier associated with a location database entry for user i at time t that reveals j layers of location information. Hence the location database entry itself will be denoted by (Iijt , A1it , A2it , . . . , Ajit , −, . . . , −).

4

Operation of the Location Database Service

We now explain how our privacy-aware location database service operates. 4.1

Functions of Location Database

The location database has five functions: – Register. On inputting a record (Iijt , A1it , . . . , Ajit , −, . . . , −), the register function adds this record to the location database. – Delete. On inputting anonymized identifier Iijt , the delete function removes the record in the location database that is indexed by Iijt .

Privacy-Aware Location Database Service for Granular Queries

33

– Count. On inputting a query (A1it , . . . , Ajit , −, . . . , −), the count function outputs the number of records in the location database that have the same attribute values. – Search. On inputting anonymized identifier Iijt , the search function outputs the record in the location database that is indexed by Iijt . – Refer. On inputting a range (group) of attributes, the refer function outputs all records in the location database that have matching attributes. 4.2

Registration of Location Information

We now explain the critical process of registering location information on the location database. A user first contacts their chosen location anonymizer and submits location information. The location anonymizer then generates anonymized identifiers and prepares potential location database entries. However, these potential entries will only be registered by the location anonymizer after they have checked that registering this location information does not contravene the required level of k-anonymity. If the location information does not conform to k-anonymity then the location anonymizer modifies the entry before registering it. Prior to submitting location information to a location anonymizer, the user provides the location anonymizer with an initial anonymized identifier and secret keys that will be needed for the database entry randomization function (see Section 4.4). The process of registering location information is as follows: 1. User i at time t sends location information (A1it , A2it , . . . , Alit ) to the location anonymizer. 2. The location anonymizer generates l anonymized identifiers Iijt (for j = 1, . . . , l), as described in Section 4.3. 3. The location anonymizer generates l potential database entries of the form (Iijt , A1it , A2it , . . . , Ajit , −, . . . , −) (for j = 1, . . . , l) from the location information. 4. For j = 1, . . . , l: (a) The location anonymizer submits a count query for the potential database entry indicated by Iijt to the location database. (b) The location database returns the number of matching entries z(Iijt ) to the location anonymizer. (c) If z(Iijt ) ≥ k then the location anonymizer registers the tuple indexed by Iijt with the location database. (d) If z(Iijt ) < k then for λ = j, . . . , l the location anonymizer replaces the potential database entry indexed by Iiλt with: j j λ λ (Iiλt , A1it , A2it , . . . , Aj−1 it , f (kit , Ait ), . . . , f (kit , Ait ), −, . . . , −),

where the generation of kijt is explained in Section 4.4. The location anonymizer then registers the replacement database entries indexed by Iijt , . . . , Iiλt with the location database and sets j = l + 1 (to halt the subprotocol).

34

S. Kiyomoto, K.M. Martin, and K. Fukushima

In the above process, as soon as one prospective database entry fails the test for k-anonymity, both this entry and all entries containing more fine-grained location information (which will also by default fail the k-anonymity test) are randomized and registered with the location database. Note that one problem with this process is that if the location database fails to satisfy k-anonymity with respect to certain location attributes then it will never satisfy k-anonymity with respect to these since such entries are never registered with the location database. One solution to this is that location anonymizers cache failed prospective database entries along with their deficiency (how far short of k-anonymity the database was with respect to them). Once the location anonymizer receives enough new prospective database entries to account for this deficiency, they recheck the location database and, if appropriate, block registers the cached entries (and deletes the corresponding randomized entries). Such a technique could also be used when initially populating the location database. 4.3

Generation of Anonymized Identifiers

In our system the location anonymizers generate anonymized identifers, rather than have them sent to them by users. This is simply for reasons of efficiency, as it saves bandwidth. It is thus important for the generation of anonymized identifiers to be synchronized between users and location anonymizers. In addition, since user devices may have restricted power, an efficient process for generating anonymized identifiers is desirable. We thus use a one-way hash function chain [11] to generate anonymized identifiers, as follows: Iij0 ← H(Ii00 |rij ),

rij ∈R {0, 1}n,

Iijt ← H(Iijt−1 |rij ),

where n is a security parameter, | is concatenation of data, Ii00 is an initial identifier of user i, rij is an n-bit random number for the j-th tuple of attributes, and H is a one-way hash function. 4.4

Randomization Function

We use a randomization function to transform an attribute of location information into a random value. The randomization function should be a trap door one-way function because authorized service providers or users should be able to obtain the original values from outputs of the randomization function. We assume that a symmetric key encryption scheme f (k, A) is used for the randomization function, where the data A is encrypted using secret key k. A user prepares at most l keys for encrypting each tuple of location information. The j-th tuple is encrypted by a secret key kijt . Thus, only the parties that have received kijt from the user can obtain the original values. The secret keys for encrypting tuples are also updated as kijt ← H(kijt−1 |rij ), where kij0 is the original secret key.

Privacy-Aware Location Database Service for Granular Queries

4.5

35

Queries

The procedures for each type of query, which it is assumed are conducted over secure channels, are described as follows: Public Query. A service provider sends a public query using the refer function to the location database, and the location database forwards the results to the service provider. Private Query. The principle behind private queries is that when a service provider requires j-level location information (A1it , . . . , Ajit , −, . . . , −) for user i in order to provide their service, the user should only inform the service provider of the anonymized identifier Iijt . A private query proceeds as follows: 1. The user requests that a service provider provides a location-based service by providing the service provider with the appropriate anonymized identifier. 2. The service provider sends a request to the location database using the search function. 3. The location database forwards the record of the identifier. (In the event that the search fails, the service provider requests that the user updates their location information.) 4. The service provider checks whether the record includes the location information required for the service. If some of the attributes in the record are encrypted (randomized) and these attributes are needed for the service, the service provider requests that the user sends the corresponding secret keys. If the user accepts the request, the user sends the secret keys to the service provider, who then decrypts the attributes. 5. The service provider provides the location-based service to the user. Personal Query. A personal query is essentially an l-level location information request. It can thus be conducted in exactly the same way as a private query, except that any user (service provider) conducting a personal query will need to be supplied by the target user with Iilt and, if necessary, the information required to decrypt any randomized location database entry fields.

5

Scheme Properties

In this section, we briefly summarize the main properties of the proposed scheme. – Distributed Workload. Most of the effort required to operate the scheme is conducted by a distributed network of location anonymizers, who take on the main effort required to prepare location database entries and conduct k-anonymity checks of the location database. By distributing this effort the scheme is more scalable than centralized approaches. – Anonymized Location Database Entries. The location database satisfies k-anonymity of database entries at all times. If a new location database entry does not satisfy this property then it is randomized before being registered.

36

S. Kiyomoto, K.M. Martin, and K. Fukushima

– Anonymized Location Database Indexing. Entries in the location database use anonymized identifiers, which means that it is impossible for an attacker to determine whether two database entries relate to the same user. On the other hand, these identifiers are efficiently computed by repeated applications of a hash function for both users and location anonymizers, who can also synchronize their computation. – User Control of Location Information. Users have full control over the granularity of location information released to service providers. They execute that control by providing service providers with the appropriate anonymized identifier that references the relevant entry in the location database. – Support for Granular Queries. The scheme supports a variety of types of location database query. By deploying trapdoor one-way functions to mask location database entries that do not satisfy k-anonymity, any service providers who require database entries to be unmasked can do so by being sent the trapdoor information directly by the user.

6

Conclusion

We have proposed a privacy-aware location database service that supports different types of location-based service. The architecture is scalable and employs simple functions that are similar to those found in general database systems. Although the architecture distributes the main computational burden amongst location anonymizers, the scheme still relies on a centralized location database. One possible extension of this architecture would be to consider whether the location database could be structured to permit a degree of parallelization of the location database operations. Another issue that could be investigated in more detail is the maintenance of k-anonymity of the location database over time. While location database entries are normally short-lived, it may still be desirable to update randomized database entries in the event that k-anonymity becomes satisfiable or unsatisfiable, having originally not been. The advantage of upgrading to full entries is that it saves the computational costs associated with unmasking a randomized database entry in the event that the location described in the entry is required by a service provider.

References 1. Bamba, B., Liu, L., Pesti, P., Wang, T.: Supporting anonymous location queries in mobile environments with privacygrid. In: Proc. of 17th International World Wide Web Conference (WWW 2008), pp. 237–246 (2008) 2. Bellare, M., Boldyreva, A., O’Neill, A.: Deterministic and efficiently searchable encryption. In: Menezes, A. (ed.) CRYPTO 2007. LNCS, vol. 4622, pp. 535–552. Springer, Heidelberg (2007) 3. Beresford, A.R., Stajano, F.: Location privacy in pervasive computing. IEEE Pervasive Computing 2(1), 46–55 (2003)

Privacy-Aware Location Database Service for Granular Queries

37

4. Boneh, D., Waters, B.: Conjunctive, subset, and range queries on encrypted data. In: Vadhan, S.P. (ed.) TCC 2007. LNCS, vol. 4392, pp. 535–554. Springer, Heidelberg (2007) 5. Gasarch, W.: A survey on private information retrieval. Bulletin of the EATCS 82, 72–107 (2004) 6. Gedik, M., Liu, L.: A customizable k-anonymity model for protecting location privacy. In: Proc. of the 25th International Conference on Distributed Computing Systems (ICDCS 2005), pp. 620–629 (2005) ´ Anonymous location-based 7. Ghinita, G., Kalnis, P., Skiadopoulos, S.: PRIVE: queries in distributed mobile systems. In: Proc. of 16th International World Wide Web Conference (WWW 2007), pp. 371–380 (2007) 8. Gruteser, M., Grunwald, D.: Anonymous usage of location-based services through spatial and temporal cloaking. In: Proc. of the 1st International Conference on Mobile Systems, Applications, and Services (MobiSys 2003), pp. 163–168 (2003) 9. Hong, J.I., Landay, J.A.: An architecture for privacy-sensitive ubiquitous computing. In: Proc. of the 2nd International Conference on Mobile Systems, Applications, and Services (MobiSys 2004), pp. 177–189 (2004) 10. Kido, H., Yanagisawa, Y., Satoh, T.: An anonymous communication technique using dummies for location-based services. In: Proc. of IEEE International Conference on Pervasive Services 2005 (ICPS 2005), pp. 88–97 (2005) 11. Lamport, L.: Password authentication with insecure communication. Cummunications of the ACM 24(11), 770–772 (1981) 12. Mascetti, S., Bettini, C.: A comparison of spatial generalization algorithms for lbs privacy preservation. In: Proc. of the 1st International Workshop on Privacy-Aware Location-Based Mobile Services (PALMS 2007), pp. 258–262 (2007) 13. Mokbel, M.F.: Towards privacy-aware location-based database servers. In: Proc. of the 22nd Internationl Conference on Sata Engineering Workshops (ICDEW 2006), pp. 93–102 (2006) 14. Mokbel, M.F., Chow, C.Y., Aref, W.G.: The new casper: Query processing for location services without compromising privacy. In: Proc. of the 32nd International Conference on Very Large Data Bases (VLDB 2006), pp. 763–774 (2006) 15. Samarati, P., Sweeney, L.: Generalizing data to provide anonymity when disclosing information. In: Proc. of the 17th ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems (PODS 1998), p. 188 (1998) 16. Song, D.X., Wagner, D., Perrig, A.: Practical techniques for searches on encrypted data. In: Proc. of IEEE Symposium on Security and Privacy 2000, pp. 44–55 (2000)

Algebraic Attacks on RFID Protocols Ton van Deursen and Saˇsa Radomirovi´c University of Luxembourg {ton.vandeursen,sasa.radomirovic}@uni.lu Abstract. This work aims to identify the algebraic problems which enable many attacks on RFID protocols. Toward this goal, three emerging types of attacks on RFID protocols, concerning authentication, untraceability, and secrecy are discussed. We demonstrate the types of attacks by exhibiting previously unpublished vulnerabilities in several protocols and referring to various other flawed protocols. The common theme in these attacks is the fact that the algebraic properties of operators employed by the protocols are abused. While the methodology is applicable to any operator with algebraic properties, the protocols considered in this paper make use of xor, modular addition, and elliptic curve point addition. Keywords: Formal verification, algebraic methods, RFID, security protocols, attacks.

1

Introduction

There are two main approaches to prove cryptographic protocols secure. The approach based on formal languages considers protocol messages on a high abstraction level and misses implementation details, but is therefore automatable. The computational approach is more accurate but also much more difficult due to the necessity of manual proofs. This work deals with algebraic verification methods which we consider to be a combination of the two mentioned approaches in the following sense. As in formal methods, we evaluate the security of protocols by considering the free term algebra generated by the messages exchanged between principals of the protocols and acted on by the standard Dolev–Yao adversary [1]. We also consider cryptographic primitives, such as hash functions and encryptions to be perfect. As in the computational approach, we study how much information is being leaked through terms to which operators with algebraic properties are applied. We are not aiming to prove protocols secure, but rather to understand how algebraic properties of operators and functions used in communication protocols can make these protocols fail to achieve security goals. Towards this goal, we present three emerging types of vulnerabilities discovered by analyzing recently published RFID protocols. The investigation of algebraic properties is a particularly useful tool for the discovery of vulnerabilities in RFID protocols. The resource constraints imposed 

Ton van Deursen was supported by a grant from the Fonds National de la Recherche (Luxembourg).

O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 38–51, 2009. c IFIP International Federation for Information Processing 2009 

Algebraic Attacks on RFID Protocols

39

on RFID tags have led to a plethora of proposals for protocols employing xor, modular addition, cyclic redundancy check functions, and custom-made hashlike functions. Attempting to prove all such protocols secure in a computational security model is tedious and overkill, since a significant number of the proposed protocols turn out to be flawed. Automated tools based on formal methods approaches currently fail to verify the security of most of these protocols, because they cannot verify some of the desired security properties, such as untraceability of tags, or do not consider flaws related to partial leakage of keys. While our approach is not automatable in general, we do expect that for the types of vulnerabilities described in this paper, the automatic detection of attacks ought to become possible in the foreseeable future. The types of attacks we present are what we call algebraic replay attacks targeting the challenge-response mechanism in authentication protocols in Section 3, attribute acquisition attacks on untraceability of tags in Section 4, and cryptanalytic attacks on secrecy of keys and tag identities in Section 5.

2 2.1

Preliminaries Terminology, Notation, and Conventions

A reader refers to the actual RFID reader as well as a potential database or server communicating with the reader, since in all protocols considered this communication takes place over a secure channel. An agent can be a tag or a reader, while a role refers to the protocol steps a tag or reader is expected to carry out. A run is the execution of a role by an agent. For convenience and intuition, we will refer to certain attacks on protocols as quality-time attacks. These are attacks in which the adversary interacts with a tag in absence of an honest or trusted RFID reader. The point of such an attack is to send carefully designed challenges to the tag in order to obtain information which can later be used to impersonate a reader or the tag, trace the tag, or attack any other security requirement of a protocol. Quality-time attacks are facilitated by the mobile and wireless nature of RFID tags. The attacks can be carried out on tags that happen to be in the vicinity of an adversary for a short period of time or on tags the attacker is able to isolate from their environment for an extended period of time. We simplify the presented protocols whenever possible by leaving out irrelevant steps, communications, and terms. The description given suffices to reconstruct the attacks on the original protocols. When referring to the untraceability property of a protocol, we mean the tag’s untraceability. For the reader’s convenience, when describing a protocol, we consistently use k for a shared secret key, h for hash functions, r1 , . . . , rn for nonces, and ID for the tag’s ID. Whenever additional functions and variables are needed we use the notation that was originally chosen by the authors of the protocol. When an attack consists of several runs, the terms used in a second run are primed. We represent protocols graphically using message sequence charts, such as in Figure 1. Every message sequence chart shows the role names, framed, near

40

T. van Deursen and S. Radomirovi´c k, ID R

k, ID T

nonce r1

r1 nonce r2 g˜ := h(r1 ⊕ r2 ⊕ k) ID2 := rotate(ID, g˜)

r2, LeftHalf (ID2 ⊕ g˜) find k, ID consistent with r2, LeftHalf (ID2 ⊕ g˜) for g˜ := h(r1 ⊕ r2 ⊕ k) ID2 := rotate(ID, g˜) RightHalf (ID2 ⊕ g˜)

Fig. 1. Flawed authentication protocol

the top of the chart. Above the role names, the role’s secret terms are shown. Actions, such as nonce generation, computation, and assignments are shown in boxes. Messages to be sent and expected to be received are specified above arrows connecting the roles. It is assumed that an agent continues the execution of its run only if it receives a message conforming to the specification. Other conditions that need to be satisfied are shown in diamond boxes. For instance, in Figure 1, the role names are R and T , both know the secret terms k and ID. R generates the nonce r1 before sending the first message. After reception of the first message, T generates a nonce and computes the response. The reader accepts the response only if it can find a pair k, ID which produces the same term when the computation shown is applied to it. If the response is accepted, the reader continues by computing and sending the last message. 2.2

Security Properties and Adversary Models

In terms of Lowe’s authentication hierarchy [2], we consider recent aliveness to be the most appropriate authentication requirement for RFID protocols. Recent aliveness captures the fact that the tag needs to have generated a message as a consequence of a reader’s query. We consider the notion of untraceability as defined by Van Deursen et al. [3] which captures the intuition that a tag is untraceable if, for any two protocol runs, an adversary cannot tell whether the same tag was executing both runs or two different tags were executing the runs. Finally, terms that are not in the adversary’s knowledge are said to be secret. We perform our security analyses in the Dolev–Yao intruder model [1]. In this model, the adversary may eavesdrop on any message exchanged between tag and

Algebraic Attacks on RFID Protocols

41

reader, modify or block any message sent from tag to reader or vice versa, and may inject his own messages making them look like they were sent by tag or reader. The models by Avoine [4], Juels and Weis [5], Vaudenay [6], Damg˚ ard and Pedersen [7], and Paise and Vaudenay [8] extend the adversary’s power with capabilities specifically tailored to the RFID setting. These capabilities will however not be necessary for the attacks presented in this paper.

3

Algebraic Replay Attacks on Authentication

A common way to authenticate RFID tags is by means of the following challengeresponse mechanism. The RFID reader challenges the tag with a nonce r1 to which the tag replies with a term derived from the nonce r1 , some information s identifying the tag, and potentially a nonce r2 generated by the tag. If present, the nonce r2 serves as the tag’s challenge to the reader in mutual authentication protocols or as a “blinding term” to achieve tag untraceability. We can thus represent the tag’s reply to the reader’s challenge as the term r2 , g(r1 , r2 , s) with the understanding that r2 may be constant or empty. The reader verifies the authenticity by applying the inverse of the function g to the term and checking whether the response contains r1 and a valid s. If g is a one-way function then the reader verifies the authenticity of the tag by computing the function g(r1 , r2 , s) and comparing it to the received value. The reader can compute this function, since it generated the value r1 itself, the value r2 is supplied by the tag, and the reader has a database with values of s for every tag it may authenticate. We now argue that the following two properties are necessary in order for the challenge-response mechanism to guarantee recent aliveness of the tag. Freshness. For fixed r2 and s the range of the function r1 → g(r1 , r2 , s) must be large. More precisely, given r2 , s, the adversary’s advantage in guessing g(r1 , r2 , s) correctly for an unknown, randomly chosen r1 must be negligible. ARR. Let Os (x) be an oracle which upon input x randomly chooses y and returns y and g(x, y, s). If s is unknown, then given access to a polynomial number of queries Os (x1 ), . . . , Os (xl ) to the oracle, it is infeasible to compute g(r1 , r2 , s) for a given r1  ∈ {x1 , . . . , xl } and any r2 . If the freshness property is satisfied, then as stated, the probability of the adversary guessing g(r1 , r2 , s) is negligible. Thus with overwhelming probability, a response r2 , g(r1 , r2 , s), to the reader’s challenge r1 must have been generated after the challenge was sent. This property is obviously necessary for recent aliveness and in particular excludes classic replay attacks. The ARR (algebraic replay resistance) property guarantees that there is no efficient algorithm to compute a response r2 , g(r1 , r2 , s) to the challenge r1 even after having observed previous challenge-response pairs. Clearly, an attacker’s ability to compute such a response violates recent aliveness and this property is thus necessary for recent aliveness. Such an attack generalizes replay attacks in that instead of merely replaying previously observed information, the attacker combines previously obtained challenge-response pairs to compute the response

42

T. van Deursen and S. Radomirovi´c

to a fresh challenge. Hence, we refer to attacks on challenge-response authentication protocols exploiting the lack of the ARR property as algebraic replay attacks. It is obvious that for a function g(r1 , r2 , s) to have the ARR property, it must preserve the secrecy of s. Indeed, cryptographic hash functions are frequently used for the type of challenge-response mechanism considered here. Since the collision resistance property of cryptographic hash functions does not seem necessary for the challenge-response mechanism, the question arises whether all one-way functions satisfy the ARR property and the answer is negative. It is certainly false for all homomorphic one-way functions. Consider, for instance, the Rabin function, defined by x → x2 mod N for certain composite integers N . If (r1 , r2 , s) → g(r1 , r2 , s) = (r1 r2 s)2 mod N is a Rabin function, then given only one challenge-response pair, r1 , g(r1 , r2 , s) it is easy to compute responses for any challenge r1 , since g(r1 , r2 , s) = g(r1 , r2 , s) · (r1 /r1 )2 . Furthermore, even non-homomorphic one-way functions will in general not have the ARR property if their argument has algebraic properties. As demonstrated in the examples below, there are several protocols that fail to achieve recent aliveness for this very reason. In these protocols the challenge-response construction can typically be represented as g(r1 , r2 , s) = f (r1 ◦ r2 , s), where f is a (non-homomorphic) cryptographic hash function and ◦ denotes an operator with the following algebraic property. Given a, b, and c, it is easy to find d with a ◦ b = c ◦ d. This construction clearly does not have the ARR property, regardless of the properties of f . The algebraic replay attack on such a protocol works as follows. An adversary observing one execution of the protocol learns r1 , r2 , and f (r1 ◦ r2 , s). When challenged with r1 , the adversary finds r2 such that r1 ◦ r2 = r1 ◦ r2 and replies with r2 , f (r1 ◦ r2 , s). The attack succeeds because f (r1 ◦ r2 , s) = f (r1 ◦ r2 , s). Examples of operators ◦ for which this type of attack succeeds are xor, modular addition, and any associative operator for which it is easy to compute left inverses. 3.1

Examples

We highlight two recent examples of algebraic replay attacks and present several new attacks. – Chien and Chen [9] implement the challenge-response mechanism by composing the cyclic redundancy check (CRC) function with xor. To a challenge r1 , the tag responds with r2 , CRC(EP C, r1 , r2 ) ⊕ k, where EP C is a constant representing the identity of the tag. The attack on this protocol has been first reported by Peris-Lopez et al. [10, §4.2]. It uses the fact that CRC is a homomorphism, i.e. CRC(a) ⊕ CRC(b) = CRC(a ⊕ b). To attack the protocol, the adversary observes one protocol execution. When challenged with r1 the adversary computes the xor of the observed response CRC(EP C, r1 , r2 ) ⊕ k with CRC(0EP C , r1 , 0r2 ) ⊕ CRC(0EP C , r1 , 0r2 ). The terms 0EP C and 0r2 are 0-bit strings of length

Algebraic Attacks on RFID Protocols

43

equal to the length of EP C and r2 , respectively. Because CRC is a homomorphism, the computation will result in a correct response CRC(EP C, r1 , r2 ) to the challenge r1 . – The protocol proposed by Lee et al. [11], described in detail in Section 4, is vulnerable to an algebraic replay attack in which the adversary needs to observe three protocol executions or perform a quality-time attack consisting of three queries. The algebraic replay attack can then be executed by solving a small system of equations yielding a constant particular to the tag. While this constant does not reveal the tag’s secret information, it can still be used to compute the correct response to a reader’s challenge. This attack has been first described by Bringer et al. [12]. The protocols by Chien and Huang [13], Kim et al. [14], Lee et al. [15], and Song and Mitchell [16], are vulnerable to algebraic replay attacks abusing the fact that a hash-like function or a cryptographic hash function is composed with xor and fit into the challenge-response construction with the function f (r1 ◦ r2 , s) shown above. We illustrate a complete attack on the protocol proposed by Chien and Huang [13], depicted in Figure 1 above. The reader is referred to the full version of the paper [17] for detailed attacks on the other protocols. The reader R and tag T share secrets k and ID. The reader starts by sending a random bit string r1 . The tag generates a random string r2 and hashes the xor of r1 , r2 , and the secret k. This hash and ID are used as input for a function in which the ID is rotated by a value depending on the hash. The tag computes the xor of the rotated ID and the hash, before sending the left half of the resulting bits and r2 to the reader. The reader performs the same operations on every pair of ID and k until it finds the corresponding tag. It then sends the right half of the corresponding bits to the tag. To impersonate a tag, it suffices to notice that the tag’s response to the reader’s challenge only depends on r1 ⊕ r2 and a shared secret. The composition of functions applied to the xor and shared secret can be represented by the function f , defined above. Thus, the adversary can carry out a quality-time attack by challenging a tag with any r1 to obtain a valid combination of r1 , r2 , and Left(ID2 ⊕ g˜). This information suffices for the adversary to be able to respond to any future challenge r1 received from a reader. When challenged, the adversary sets r2 = r1 ⊕ r1 ⊕ r2 and sends r2 , Left(ID2 ⊕ g˜).

4

Attribute Acquisition Attacks on Untraceability

A simple, necessary condition for tag untraceability is that an adversary, which has observed a particular tag once, must not be able to recognize the tag as being the same tag in the future. To make this more precise, we call a term, which the adversary can derive from one or more runs of a tag and which identifies the tag to the adversary, a unique attribute of the tag. The necessary condition for a tag to be untraceable then is that the adversary must not be able to derive a unique attribute for the tag. Should the adversary be able to compute a unique

44

T. van Deursen and S. Radomirovi´c

attribute, then we refer to the adversary’s steps to arrive at such a term as the attribute acquisition attack. A simple unique attribute can be found in protocols where the tag’s answer to a challenge c is merely a function f (c, k) of the challenge and a secret (or collection of secrets) k and does not involve any nonce created by the tag. In this case, c is under the adversary’s control, k is unique to the tag, and the adversary learns f (c, k) after one round of communication with the tag. Thus for constant c chosen by the adversary, f (c, k) is a unique attribute of the tag whose secret is k. To prevent long-term traceability in protocols that employ the challengeresponse mechanism described, the tag typically updates its secret k at the end of a run. The secret k must therefore also be updated by the reader and in order to avoid desynchronization attacks, the tag needs to authenticate the communicating reader before updating k. Yet, a tag following such a protocol can still be traced by an adversary between two updates by querying the tag and then aborting the protocol. Furthermore, if the update of the secret k at the end of the protocol involves operators with algebraic properties, it is frequently possible for the adversary to compute a unique attribute for the tag which will be valid after the update. References to such protocols are given in the examples section below. To find unique attributes in general, consider a given RFID protocol in a formal trace model such as the one proposed by Cremers and Mauw [18] or the strand spaces model of Thayer F`abrega et al. [19]. Then the unique attribute for the tag role can be obtained, if it exists, by computing the intersection of the adversary’s knowledge with the set of terms which can be constructed from constants that are unique to the tag and terms that are under the adversary’s control. Such a term can be found effectively, provided that the intersection is non-empty. To find a term in the intersection for the special class of challenge-response protocols in which the tag includes a fresh nonce r in its reply f (c, k, r) to a challenge c, the adversary needs to find challenges c1 , . . . , cl and an efficiently computable function g(x1 , . . . , xl ), such that g(f (c1 , k, r1 ), . . . , f (cl , k, rl )) = g˜(c1 , . . . , cl , k) does not depend on the tag’s nonces r1 , . . . , rl . In this case g˜(c1 , . . . , cl , k) is the unique attribute. The attribute acquisition problem displayed in this form is more amenable to solutions by algebraic methods, as the following examples show. 4.1

Examples

We give three examples of attacks that have not been reported in literature. The first two examples are described in more detail in the full version of this paper [17]. 1. A simple attribute acquisition attack exists on the protocol proposed by Kim et al. [20]. In this protocol, the tag’s response can be represented by

Algebraic Attacks on RFID Protocols

45

f (c, k, r) = k1 ⊕ r, h(c, k2 ) ⊕ r, where k = k1 , k2 is the tag’s secret, c the reader’s challenge and r the tag’s nonce. To find a unique attribute, the attacker challenges the tag with a constant c1 and computes the unique attribute by taking the xor of the two terms in the response: k1 ⊕ r ⊕ h(c1 , k2 ) ⊕ r = k1 ⊕ h(c1 , k2 ) = g˜(c1 , k). 2. The protocols by Li and Ding [21], Osaka et al. [22], and Yang et al. [23] are stateful protocols that update the shared secrets between reader and tag at the end of a successful protocol execution. The updates take the old secret and a fresh value exchanged in the protocol execution, and apply an operator with algebraic properties to obtain the new secret. By observing the messages exchanged in a protocol execution, the attacker can fabricate a challenge to which the tag will respond with the same term: the unique attribute. In other words, the attacker uses his knowledge to “undo” the update of the tag. In the simplest of these, the protocol by Osaka et al. [22], the reader’s challenge is c, the tag’s response is f (c, k) = h(k ⊕ c), where k is the tag’s secret. The tag updates its secret by computing the xor of it with a third message r it receives from the reader. Disregarding other flaws this protocol suffers from, the attribute acquisition attack consists in challenging the tag the first time with a constant c1 . After an update with message r the tag is challenged with c1 ⊕ r. After the next update with message r , the tag is challenged with c1 ⊕ r ⊕ r and so forth. The tag’s response to these challenges is each time h(k ⊕ c1 ). 3. A more challenging example is the authentication protocol proposed by Lee et al. [11] and shown in Figure 2. The protocol is based on a fixed, system-wide elliptic curve over a finite field. The points P , Y = yP , x1 P , x2 P on the elliptic curve are publicly known, the scalar y is only known to the reader, and the scalars x1 , x2 are unique to each tag and only known to the tag. The elliptic curve is assumed to have been chosen such that the computational Diffie-Hellman problem is hard, that is, given only the points xP , yP , and P on the elliptic curve, it is hard to compute xyP . In the protocol, the reader challenges the tag with a random number r2  = 0 to which the tag responds with two points T1 = r1 P , T2 = (r1 + x1 )Y on the elliptic curve and a scalar v = r1 x1 + r2 x2 . Using this information, the reader can infer the tag’s identity. Thus, this protocol, too, is a challenge-response protocol with challenge r2 and a response that can be written as f (r2 , k, r1 ) = r1 P, (r1 + x1 )yP, r1 x1 + r2 x2 , where k = x1 , x2 . The points P and yP are constant. To find a unique attribute, the adversary needs to find challenge terms c1 , . . . , cl and functions g, g˜ such that (l) g(f (c1 , k, r1 ), . . . , f (cl , k, r1 )) = g˜(c1 , . . . , cl , k), where g˜ does not depend (l) on the tag’s random numbers r1 , . . . , r1 . If we write f (c, k, r1 ) = T1 , T2 , v as in the protocol specification, and recall that primes indicate terms transmitted in the second run, then g(f (c, k, r1 ), f (c, k, r1 )) =

T1 − T1 = x−1 1 P v − v

46

T. van Deursen and S. Radomirovi´c y, P, x1P, x2P R nonce r2

x1, x2, P, Y = yP T r2 r2  =0 nonce r1 T1 := r1P T2 := (r1 + x1 )Y v := r1x1 + r2x2 T 1 , T2 , v

find x1P = y −1 T2 − T1 (vP − x1T1)r2−1 = x2 P

Fig. 2. Protocol with untraceability flaw

depends only on the first part of the secret k = x1 , x2 . Thus g˜(k) = x−1 1 P is a unique attribute. From the definition of the function g, it is now easy to obtain the attribute acquisition attack. By carrying out a quality-time attack, the adversary challenges the tag twice with the same value c. The information received from the tag in the two runs can be used to compute the term x−1 1 P as follows. Observe that v − v  = (r1 − r1 )x1 and T1 − T1 = (r1 − r1 )P , thus, multiplying T1 − T1 with the inverse of v − v  modulo the order of the elliptic curve, the attacker obtains x−1 1 P. Note that after executing this quality-time attack, it suffices for the adversary to challenge any given tag only once with the previously used value c to determine whether the presented tag is equal to the tag identified by x−1 1 P. A similar attack on untraceability of the protocol in Figure 2 was independently found by Bringer et al. [12]. The authors observe that for any two protocol executions, the following equations hold: r2 v  − r2 v = (r2 r1 − r2 r1 )x1 r2 T1 − r2 T1 = (r2 r1 − r2 r1 )P The attacker may then combine these two equations to obtain x−1 1 P and proceed as described above.

Algebraic Attacks on RFID Protocols

5

47

Cryptanalytic Attacks on Secrecy

The authentication and untraceability properties of RFID protocols often rely on the secrecy of shared keys. In some cases, revealing parts of a secret key may already be enough to trace the tag. If sufficiently many bits of a key can be revealed, brute-forcing the remaining bits may become feasible. Formal methods approaches typically do not consider attacks in which an adversary may learn just a few bits of a key, since keys are modeled as atomic terms. If we assume that operators with algebraic properties are applied to terms sent back and forth between a reader and a tag, then a natural point of attack is to set up equations involving the terms on whose secrecy a protocol depends. Such equations may be obtained by observing several protocol runs, but also by selectively modifying parts of messages. In other words, one may attempt to apply any cryptanalytic method known to mankind. While this is hardly an original strategy, it turns out to be quite successful in the domain of RFID protocols. One reason for this is the popularity of simple operators with algebraic properties. The other reason is due to the simple structure of typical RFID protocols. The reader challenges the tag with a nonce r to which the tag responds with a message involving that nonce and a secret k. This leads to a function r  → f (k, r) which can be compared to a cipher m  → C(k, m) or keyed hash function x  → h(k, x). The tag’s response can further be analyzed by forwarding a modified version of it to the reader and checking the reader’s response. For RFID protocols with three or more messages, a tag-generated nonce, may frequently be considered as a known plaintext. Finally, stateful RFID protocols, i.e. RFID protocols in which the tag upon successful completion of the protocol updates its secret ID or cryptographic key, can be analyzed by taking advantage of algebraic relations between previous and future ID’s or keys. 5.1

Examples

There are several examples of cryptanalytic attacks in the literature. – In the HB+ protocol of Juels and Weis [24], tags use the binary inner product and xor operator to hide their secret keys while proving knowledge of it. The attack by Gilbert et al. [25] breaks secrecy of a tag’s key by first modifying the messages exchanged between reader and tag, then observing the reader’s behavior, and finally using the observed information to set up and solve a system of linear equations. – Van Deursen et al. [3] use information obtained through eavesdropping on executions of the Di Pietro and Molva protocol [26] to expose two thirds of the bits of a tag’s secret key. In the protocol execution, bits of the tag’s secret key are combined with random nonces using xor and logical and and or operators and then sent from the tag to the reader. The attack is carried out by solving a system of linear equations derived from the observed

48

T. van Deursen and S. Radomirovi´c

messages which yields two thirds of the secret key’s bits. This is enough to break untraceability. It furthermore permits a brute force attack on the remaining bits in order to break authentication. – In the protocols of Peris-Lopez et al. [27,28,29], logical and and or operators are used in addition to xor and modular arithmetic leading to information leaks exploited by Alomair et al. [30] and Li and Wang [31]. – Vajda and Butty´ an have proposed several lightweight authentication protocols in [32]. Their first protocol uses xor and bit permutations to update keys shared between reader and tag. The attack of Alomair et al. [30] correlates keys across updates thereby breaking authentication. Vajda and Butty´ an’s second protocol is vulnerable to an active attack in which the adversary recovers the shared secret by querying the tag with a challenge of his choice and analyzing the response. For a concrete, simple example of a hitherto unknown attack, consider the protocol proposed by Kang and Nyang [33]. In this protocol, the tag generates a random value r0 from a small domain and a random value r1 of length n. The tag sends the two hashes h(ID, r0 ), h(r1 , k) and ID ⊕ r1 to the reader. Using h(ID, r0 ), the reader finds ID by trying out all combinations of values for ID stored in its database and of all possible values for r0 . This is possible for the reader because r0 is chosen from a small domain and the number of IDs stored in its database is very small compared to the number of possible IDs. Using ID the reader retrieves k from its database, and using ID ⊕ r1 and ID, the reader finds r1 and may then verify the correctness of the value of h(r1 , k). The reader then generates a random value r2 of length n and sends ID ⊕ r2 and h(r1 , r2 ) to the tag. The tag verifies these and sends r1 + r2 mod 2n back to the reader. Both tag and reader update the ID by xor -ing it with r1 ⊕ r2 . The protocol is depicted in Figure 3.

k, ID R

k, ID T

Query

nonce r0, r1 h(ID, r0), h(r1, k ), ID ⊕ r1 nonce r2 h(r1, r2), ID ⊕ r2 r1 + r2 mod 2n k := r1 + r2 mod 2n

k := r1 + r2 mod 2n

ID := ID ⊕ r1 ⊕ r2

ID := ID ⊕ r1 ⊕ r2

Fig. 3. Several bits of ID leak in every run

Algebraic Attacks on RFID Protocols

49

Since hash functions are assumed to be perfect, we consider the terms ID⊕r1 , ID ⊕ r2 , and r1 + r2 mod 2n , setting up a system of equations involving the variables ID, r1 , r2 , and the values observed during runs of the protocol. A moment’s thought shows that we may combine the first two equations to obtain r1 ⊕ r2 . For convenience, we set V = r1 + r2 mod 2n and W = r1 ⊕ r2 . Let V [i] be the i-th bit of V , and similarly for W , r1 , and r2 . Furthermore, let V [1] be the least significant bit of V . By comparing addition modulo 2n with xor it is easy to see that V [i + 1]  = W [i + 1] only if there is a carry bit in the computation of V [i]. If this is the case, then r1 [i]  = r2 [i] ⇔ W [i] = 1 and r1 [i] = r2 [i] = 1 ⇔ W [i] = 0. Since the latter case determines r1 [i] and r2 [i] uniquely, it follows that it can be used to find the i-th bit of ID. More bits from ID can be obtained by noticing that a carry bit in V [i] followed by no carry bit in V [i + 1] implies r1 [i + 1] = r2 [i + 1] = 0. Since r1 and r2 are chosen at random, on average, every communication session leaks roughly n−1 bits of ID. Revealing all bits of ID, once sufficiently many 4 bits are known, can be achieved with a brute-force search over possible values for ID and r0 and comparing their hash to h(ID, r0 ). Revealing all bits of ID is made a little more complicated by the fact that reader and tag update ID at the end of every protocol execution by setting it to ID ⊕ r1 ⊕ r2 . The adversary may therefore need to keep track of two or three consecutive protocol executions between the tag and reader before performing the exhaustive search in order to completely reveal the tag’s ID. Knowing the ID, the adversary can impersonate both tag and reader and furthermore trace the tag.

6

Conclusion and Future Work

By analyzing simple necessary conditions for authentication and untraceability and studying information leakage in secret terms, we have found three categories of attacks on recently published RFID protocols. The attack methods are particularly suitable for RFID protocols since they take advantage of algebraic properties of operators and functions typically used in these protocols. The methods used to find algebraic replay and attribute acquisition attacks are sufficiently straight-forward that we expect them to be easily implementable in a tool-supported verification framework. The tool-supported verification of secrecy and authentication properties in presence of associative and commutative operators is already a very active research area. The automatic verification of untraceability will be considered in future work following the procedure outlined in Section 4. An indication for how some of the cryptanalytic attacks may be automated can be obtained from the attack presented in Section 5. By representing all atomic terms as bit vectors, the system of equations of atomic terms can be expanded to a larger system over the finite field of two elements involving the bits of the vectors as variables. Such a system can, in principle, be solved using SAT solvers or Gr¨ obner basis algorithms.

50

T. van Deursen and S. Radomirovi´c

References 1. Dolev, D., Yao, A.: On the security of public key protocols. IEEE Transactions on Information Theory IT-29(2), 198–208 (1983) 2. Lowe, G.: A hierarchy of authentication specifications. In: CSFW, pp. 31–44 (1997) 3. van Deursen, T., Mauw, S., Radomirovi´c, S.: Untraceability of RFID Protocols. In: Onieva, J.A., Sauveron, D., Chaumette, S., Gollmann, D., Markantonakis, K. (eds.) WISTP 2008. LNCS, vol. 5019, pp. 1–15. Springer, Heidelberg (2008) 4. Avoine, G.: Adversary model for radio frequency identification. Technical Report LASEC-REPORT-2005-001, Swiss Federal Institute of Technology (EPFL), Security and Cryptography Laboratory (LASEC), Lausanne, Switzerland (September 2005) 5. Juels, A., Weis, S.: Defining strong privacy for RFID. In: IEEE International Conference on Pervasive Computing and Communications – PerCom 2007, New York, USA, pp. 342–347. IEEE Computer Society Press, Los Alamitos (2007) 6. Vaudenay, S.: On privacy models for RFID. In: Kurosawa, K. (ed.) ASIACRYPT 2007. LNCS, vol. 4833, pp. 68–87. Springer, Heidelberg (2007) 7. Damg˚ ard, I., Pedersen, M.Ø.: RFID security: Tradeoffs between security and efficiency. In: Malkin, T.G. (ed.) CT-RSA 2008. LNCS, vol. 4964, pp. 318–332. Springer, Heidelberg (2008) 8. Paise, R.I., Vaudenay, S.: Mutual authentication in RFID: Security and privacy. In: ACM Symposium on Information, Computer and Communications Security (ASIACCS 2008), pp. 292–299. ACM Press, New York (2008) 9. Chien, H.Y., Chen, C.H.: Mutual authentication protocol for RFID conforming to EPC class 1 generation 2 standards. Computer Standars & Interfaces, Elsevier Science Publishers 29(2), 254–259 (2007) 10. Peris-Lopez, P., Hernandez-Castro, J.C., Estevez-Tapiador, J., Ribagorda, A.: Cryptanalysis of a novel authentication protocol conforming to EPC-C1G2 standard (2007) 11. Lee, Y.K., Batina, L., Verbauwhede, I.: EC-RAC (ECDLP based randomized access control): Provably secure RFID authentication protocol. In: Proceedings of the 2008 IEEE International Conference on RFID, pp. 97–104 (2008) 12. Bringer, J., Chabanne, H., Icart, T.: Cryptanalysis of EC-RAC, a RFID identification protocol. In: Franklin, M.K., Hui, L.C.K., Wong, D.S. (eds.) CANS 2008. LNCS, vol. 5339, pp. 149–161. Springer, Heidelberg (2008) 13. Chien, H.Y., Huang, C.W.: A lightweight RFID protocol using substring. In: Kuo, T.-W., Sha, E., Guo, M., Yang, L.T., Shao, Z. (eds.) EUC 2007. LNCS, vol. 4808, pp. 422–431. Springer, Heidelberg (2007) 14. Kim, K.H., Choi, E.Y., Lee, S.M., Lee, D.H.: Secure EPCglobal class-1 gen-2 RFID system against security and privacy problems. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4277, pp. 362–371. Springer, Heidelberg (2006) 15. Lee, S., Asano, T., Kim, K.: RFID mutual authentication scheme based on synchronized secret information. In: Symposium on Cryptography and Information Security, Hiroshima, Japan (January 2006) 16. Song, B., Mitchell, C.J.: RFID authentication protocol for low-cost tags. In: Wireless Network Security (WISEC), pp. 140–147 (2008) 17. van Deursen, T., Radomirovi´c, S.: Attacks on RFID protocols (version 1.0). Cryptology ePrint Archive, Report 2008/310 (July 2008), http://eprint.iacr.org/2008/310

Algebraic Attacks on RFID Protocols

51

18. Cremers, C., Mauw, S.: Operational Semantics of Security Protocols. In: Leue, S., Syst¨ a, T.J. (eds.) Scenarios: Models, Transformations and Tools. LNCS, vol. 3466, pp. 66–89. Springer, Heidelberg (2005) 19. Thayer F` abrega, F., Herzog, J., Guttman, J.: Strand spaces: Why is a security protocol correct? In: Proc. 1998 IEEE Symposium on Security and Privacy, Oakland, California, pp. 66–77 (1998) 20. Kim, I.J., Choi, E.Y., Lee, D.H.: Secure mobile RFID system against privacy and security problems. In: SecPerU 2007 (2007) 21. Li, Y., Ding, X.: Protecting RFID communications in supply chains. In: ASIACCS, pp. 234–241 (2007) 22. Osaka, K., Takagi, T., Yamazaki, K., Takahashi, O.: An efficient and secure RFID security method with ownership transfer. In: Wang, Y., Cheung, Y.-m., Liu, H. (eds.) CIS 2006. LNCS, vol. 4456, pp. 778–787. Springer, Heidelberg (2007) 23. Yang, J., Park, J., Lee, H., Ren, K., Kim, K.: Mutual authentication protocol for low-cost RFID. In: Handout of the Ecrypt Workshop on RFID and Lightweight Crypto (July 2005) 24. Juels, A., Weis, S.: Authenticating Pervasive Devices with Human Protocols. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 293–308. Springer, Heidelberg (2005) 25. Gilbert, H., Robshaw, M., Sibert, H.: An active attack against HB+ – a provably secure lightweight authentication protocol (July 2005) (manuscript) 26. Di Pietro, R., Molva, R.: Information confinement, privacy, and security in RFID systems. In: Biskup, J., L´ opez, J. (eds.) ESORICS 2007. LNCS, vol. 4734, pp. 187–202. Springer, Heidelberg (2007) 27. Peris-Lopez, P., Hernandez-Castro, J.C., Estevez-Tapiador, J.M., Ribagorda, A.: M2 AP: A minimalist mutual-authentication protocol for low-cost RFID tags. In: Ma, J., Jin, H., Yang, L.T., Tsai, J.J.-P. (eds.) UIC 2006. LNCS, vol. 4159, pp. 912–923. Springer, Heidelberg (2006) 28. Peris-Lopez, P., Castro, J.C.H., Est´evez-Tapiador, J.M., Ribagorda, A.: EMAP: An efficient mutual-authentication protocol for low-cost RFID tags. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4277, pp. 352–361. Springer, Heidelberg (2006) 29. Peris-Lopez, P., Castro, J.C.H., Est´evez-Tapiador, J.M., Ribagorda, A.: LMAP: A real lightweight mutual authentication protocol for low-cost RFID tags. In: Printed handout of Workshop on RFID Security – RFIDSec 2006 (July 2006) 30. Alomair, B., Lazos, L., Poovendran, R.: Passive attacks on a class of authentication protocols for RFID. In: Nam, K.-H., Rhee, G. (eds.) ICISC 2007. LNCS, vol. 4817, pp. 102–115. Springer, Heidelberg (2007) 31. Li, T., Wang, G.: Security analysis of two ultra-lightweight RFID authentication protocols. In: IFIP SEC 2007, Sandton, Gauteng, South Africa, IFIP (May 2007) 32. Vajda, I., Butty´ an, L.: Lightweight authentication protocols for low-cost RFID tags. In: Second Workshop on Security in Ubiquitous Computing – Ubicomp 2003, Seattle, WA, USA (October 2003) 33. Kang, J., Nyang, D.: RFID authentication protocol with strong resistance against traceability and denial of service attacks. In: Molva, R., Tsudik, G., Westhoff, D. (eds.) ESAS 2005. LNCS, vol. 3813, pp. 164–175. Springer, Heidelberg (2005)

Anti-counterfeiting Using Memory Spots Helen Balinsky, Edward McDonnell, Liqun Chen, and Keith Harrison Hewlett-Packard Laboratories, Long Down Avenue, Stoke Gifford, Bristol, BS34 8QZ, UK {helen.balinsky,edward.mcdonnell,liqun.chen,keith.harrison}@hp.com

Abstract. We propose a new hardware and software solution for anticounterfeiting that puts product authentication directly into the hands of end-users, enabling them to be confident of the authenticity of a product regardless of the integrity of the distribution chain. This is made possible by a new type of tamper-resistant hardware chip, called “memory spot”, which has a unique combination of small size, very fast on-air data rate, relatively large memory, and integrated security features, in conjunction with a novel authentication protocol. In addition, the low cost of these new chips makes our proposed solution even more compelling than possible alternatives. Example applications include pharmaceutical anti-counterfeiting, asset tracking, secure-ID, brand protection and warranty fraud prevention. We will take pharmaceutical anti-counterfeiting as an example to explain our solution. A prototype system has been built to demonstrate the feasibility of the proposed system. Keywords: RFID, authentication.

1

memory

spot,

anti-counterfeiting,

package

Introduction

There is no doubt that counterfeiting of consumer products is a rapidly growing problem; in particular counterfeiting of pharmaceutical products creates enormous health and safety issues as recent examples have demonstrated. The war between counterfeiters and anti-counterfeiting is on-going. Traditional anticounterfeiting technology includes barcodes, holograms, tags, special printings, etc. According to the accords with the US FDA (Food and Drug Administration) recommendation, there is a unique identification for every unit of packaging [1], [2]. Researchers of information security and cryptography have made use of RFID (Radio-Frequency Identification) in this area, e.g. [3], [4], [5]. A more recently work by Staake et al [6] has proposed building an RFID-based supply chain security system, where each product has an RFID tag, which holds a unique hardware identity number; this number can be traced from supplier, distribution center, and port to consumer. For stronger protection, the RFID tag can also hold a secret key to support cryptographic mechanisms. In order to achieve O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 52–67, 2009. c IFIP International Federation for Information Processing 2009 

Anti-counterfeiting Using Memory Spots

53

security of the supply chain, the RFID tag must have a Physical Unclonable Function (PUF). Supply chain security using RFID has become well-known and has been considered to be a successful solution for anti-counterfeiting in the research community. However, in real practical applications, a traditional supply chain still dominates the marketplace. This chain includes multiple entities, such as many wholesalers, but only two entities, i.e. the manufacturer and retailer, are visible to a customer (end-user). The secure supply chain requires the involvement of many entities between the manufacturer and retailer. Most likely it would take many years to build such a secure supply chain in practice. Furthermore, in some applications, such as pharmaceutical anti-counterfeiting, revealing and verifying all details of every entity in the supply chain could be difficult and unnecessary, because there may be some requirement on anonymity. In this paper, we provide two contributions to the anti-counterfeiting research. Our first contribution is use of a new type of tamper-resistant hardware chip, called “memory spot”, instead of using ordinary RFID devices. Compared with RFID, the memory spot is much smaller and therefore suits pharmaceutical applications very well. Our second contribution is a simple authentication scheme, called the package authentication scheme. Our goal with this scheme is not to make it a replacement of RFID in supply chain security, but we suggest this scheme could either be used alone before the RFID supply chain security is ready or be used as a supplement for the RFID secure supply chain. Our proposed hardware and software solution is well suited to the general authentication problem for goods or items that are stored or transferred over potentially non-secure channels [7]. This solution has wide applicability and can be applied to the anti-counterfeiting of pharmaceuticals and other goods, as well as to warranty fraud, asset tracking, secure-ID, brand protection and many others. Such a wide spread of applications is made possible by the unique technical attributes of the memory spots. We define the authenticity and validity of goods or drugs to mean that they are the products they claim to be (i.e. they match their prescription, description, list of installed parts, etc.), that they are made by the stated manufacturer and that they have not expired. The problem is addressed by providing an enduser product authentication solution, rather than the current process of remote verification through a referential system ([8], [9]).The proposed solution also tackles the grey market problem, where otherwise genuine drugs or goods are resold into a different geography than originally intended. The proposed solution brings authentication directly to the point of sale. It is a new multi-level authentication scheme that increases the confidence that the consumer or end-user has in the product. Confidence level is extremely important as demonstrated in trials of the solution proposed in [8]. This also makes last minute product recalls not only possible, but extremely easy to achieve. At the time that the customer checks the authenticity of the product, he is connected to an up-to-date website that can also provide the recall information. This avoids the latency problem of the conventional recall distribution chain.

54

H. Balinsky et al.

The leading and most advanced area in combating counterfeit goods, the pharmaceutical market, is currently realizing that the best time and place to check whether products are genuine and come from the original manufacturer, is when they are finally delivered to the end-user, regardless of how many times they have changed hands on the way. It was strongly emphasized at the PanEuropean Summit for Pharmaceutical Manufacturers [10] and in a report by Forrester [11] that in order to ensure that drugs are safe and efficacious they should be authenticated when pharmacists deliver them to the patient. Our solution is therefore both extremely relevant and timely. The remainder of the paper is arranged as follows. We will introduce the functionality of memory spots in Section 2, followed by the proposed product authentication scheme in Section 3. In Section 4, we will analyze potential threats and the security of our solution. In Section 5, we will show some brief comparisons between our solution and some already existing solutions, and we will conclude the paper in Section 6 with some comments on future work in this research topic.

2

Overview of Memory Spot Functionality

In our solution, we make use of memory spots [12] as a replacement for RFID devices. A memory spot is a tamper-resistant hardware chip. A micrograph of the memory-spot chip is shown in Figure 1. The unique features of the

Fig. 1. A micrograph of a memory-spot chip

memory spot are its small size (2 mm2 ), its very fast (10 Mb/s) on-air data rate, relatively large memory sizes and its processor. Figure 2 shows the size comparison of the chip alongside pencils and a laboratory prototype of a memory-spot reader/writer. A memory spot tag deployed for the pharmaceutical anti-counterfeiting solution proposed in this paper holds the following functionalities:

Anti-counterfeiting Using Memory Spots

55

Fig. 2. (left to right) Size comparison of the chip alongside pencils; a laboratory prototype of a memory-spot reader/writer

1. It can provide between 32 KB and 512 KB of Write Once Read Many (WORM) type of memory, which is sufficient for high resolution images of packaging (a so-called “fingerprint”), together with full product provenance, expiry date, etc. 2. It has a restricted access function to its memory, by which we mean the contents of the memory cannot be read by an unauthorized user, but can be accessed by the on-board challenge-response circuitry (this memory is used for holding a secret shared by a batch of memory spots). 3. It has a unique non-clonable and non-modifiable factory programmed identity ID that is read correctly in a trustworthy manner by a memory spot reader. 4. It is physically very small (2 mm2 in area and 0.3 mm thick) and can be fitted securely and unobtrusively into something as small as a vial, a blister pack or the seal on top of a bottle of pills. 5. The access range to the memory spot tag is physically restricted to less than 2 mm, so it is reasonably easy to shield the tag to prevent reading or writing until the packaging is actually broken. 6. It has challenge-response circuitry, i.e. it can compute a response to a challenge value by using the stored secret. This function allows the memory spot to play the role of an on-board challenge response authenticator (based on a standard cryptographic primitive) which defends against cloning and impersonation attacks. Note that a basic solution of this application works even if the memory-spot does not have the functions of restricted access memory and challenge response circuitry. This means that the memory spot is a storage only device with a unique ID, which could also be a cheaper option. However, in that case, memory spot authentication cannot be performed. Therefore, the basic solution might be vulnerable to an impersonation attack that is specified below. In the remaining

56

H. Balinsky et al.

part of the paper, we do not discuss this basic solution in detail because the assumption of no impersonation attack might be too strong in the real world.

3

The Package Authentication Scheme

As mentioned before, the goal of our package authentication scheme is to provide an authentication mechanism for a traditional supply chain environment, in which there are multiple middle-men but only the manufacturer and retailer are visible to the end-user. Our authentication process is therefore run at the point of final sale for a product. Authentication at the point of sale requires trusted electronic data to be delivered to an end-user simultaneously with the item. This is a considerable challenge. In this section we present the simple and practical package authentication scheme that uses the unique features of the memory spot, as specified in Section 2. 3.1

Design Principles

According to the FDA, for a variety of reasons, counterfeit drugs are currently most likely to be introduced into the distribution chain where there are multiple wholesalers [1], [2], [13]. As we cannot trust the whole chain, we trust: – The foundry: that they make memory spot chips as specified above and that they do not have leaks of memory spots without preprogrammed ID. – The pharmaceutical company: that they originate the correct drugs in the correct packaging. – The actual dispensing pharmacist: that the genuine authentication application is used. When memory spot readers are ubiquitous the pharmacist can be removed from the list of trusted parties. Before that time they can be replaced by independent authentication kiosks. There are two distinct parties involved in the authentication process: the manufacturer, for example a pharmaceutical company, and the end-user. By enduser we mean anyone who is authenticating a product. It could be a pharmacist or retailer, either when they receive and authenticate a wholesale package of goods or when they dispense an individual drug to a consumer. It could also be a consumer, who verifies the drug at the point of sale themselves. The memory spot tags employed by this solution have a physically enforced WORM memory (Write Once, Read Many times) which is only ever written to by the manufacturer and under the same secure conditions as when the drugs or goods are manufactured. After the required data has been written, the write functionality is irreversibly disabled in the hardware so that no new data can be added or the existing data altered. Also, there is some restricted access memory, where the manufacturer can store a secret H , but which can only be accessed for reading by the on-board processor through its challenge-response circuitry. In the following a couple of subsections, we will describe the actual processes followed by the manufacturer and the end-user with reference to the schematic diagram shown in Figure 3.

Anti-counterfeiting Using Memory Spots

57

Fig. 3. The Package Authentication Protocol

3.2

Parameters

To simplify further reading in Table 1 we provide a short list of the parameters, which are used in the specification of the proposed package authentication scheme. Anything with a star ∗ is a retrieved version of the original data that has possibly been altered. 3.3

Creation of an Authentic Package

In the process of setup the manufacturer creates a public and private key pair for the purpose of making digital signatures. An authenticated copy of the public key should be made available to the end-user, and the corresponding private key is held securely by the manufacturer. This part can be done by using an ordinary asymmetric cryptographic technique, such as PKI therefore we will not discuss it further. A flowchart of the manufacturer’s procedure of creating an authentic package for each product described below is shown in Figure 4. During manufacturing a memory spot P is securely attached or embedded in each unit of packaging or item for sale. Each package is assigned two unique random integer numbers. Let us call them login L and nonce N to approximately reflect their roles. A range for both login and nonce should be selected to ensure that there is a sparse distribution of used numbers, so by knowing one or a few numbers it is impossible to infer other logins and nonces. L and N are stored in a secure database owned by the manufacturer, where L is used as a primary key entry for a particular unit or item. The database entry also includes a flag to indicate its status. Then, a description D of the product is generated. For a medicine it is likely to include product provenance and ID, instructions for use, quantity, dosage, expiry date and actual photographs of the individual item showing all of its particular (customized) features, including the so-called packaging “fingerprint”. In the case of a warranty application it might include part descriptions, their unique IDs and respective warranty periods. If the memory spot is embedded or attached to the packaging or product by means of a secure seal, then the seal ID will also be included. The factory fitted unique identification Q is retrieved from the memory spot P and combined with the description D and login L to form a single message M = D ||L||Q . This is written to the WORM area of the memory spot. Then, a new message F is formed by appending the previously generated nonce N to

58

H. Balinsky et al. Table 1. A short list of parameters D

is a description of the product. For a medicine it is likely to include product provenance and ID, instructions for use, quantity, dosage, expiry date and actual photographs of the individual item showing all of its particular (customized) features, including the so-called packaging “fingerprint”. In the case of a warranty application it might include part descriptions, their unique IDs and respective warranty periods. If the memory spot is attached to the packaging or product by means of a secure seal, then the seal ID will also be included.

P

is a memory spot.

L

is a login: a unique random integer number that is used as a primary key entry for each unit of packaging in the manufacturer database.

N

is a nonce: a secret random integer number that is recovered from the manufacturer database during a product authentication.

Q

is the factory fitted memory spot unique ID.

M is a message obtained by concatenation of D, L and Q : M = D||L||Q . It is written by the manufacturer to the memory spot P . F

is a message formed by appending the nonce N to the message M : F = M ||N . After the digital signature of F is computed this message is discarded.

N ∗ is the retrieved nonce. M ∗ is the message that is retrieved by the verifier from the memory spot P . M ∗ should be equal to M if it is genuine. F ∗ is a reconstructed message formed by appending the retrieved nonce N ∗ to the message M ∗ recovered from the spot: F ∗ = M ∗ ||N ∗ . R

is the digital signature of the message F that is written by the manufacturer to the memory spot P .

T

is the control spot: a memory spot programmed with a secret that matches the secret H residing within the memory spot P attached to a product.

H

is the manufacturer secret shared by the memory spots P and T .

the message M : F = M ||N . The digital signature R of message F is computed using the manufacturer’s private key and then stored with M . Summarizing, all the relevant product information in the form of the message M , as well as the digital signature R, is stored on the memory spot. However, this does not provide sufficient information for signature verification due to the missing value of nonce N . Next, some secret H (previously generated per batch or lot, i.e., the secret is shared amongst a batch of memory spots and the manufacturer) is written into the restricted access memory and finally, the write functionality is disabled and the memory spot shielded from outside access.

Anti-counterfeiting Using Memory Spots

Fig. 4. The manufacturer procedure (issuing the Signature)

59

60

3.4

H. Balinsky et al.

Verification of the Authentic Package

The flowchart of the end-user’s verification procedure described below is shown in Figure 5. We assume that the verifier has access to a trusted copy of the manufacturer’s public signature verification key and a corresponding “control spot” T from the manufacturer. T is a memory spot programmed with a secret that matches the secret H residing within the memory spot P attached to a product. There should be a clear indication which T should be used for a particular item (package). We also assume that the verifier knows the contact information, such as the IP address or telephone number, to communicate with the manufacturer or other alternative authority. First, the verifier checks that the packaging is intact and breaks it in order to read the contents of the memory spot P . The verifier loads T into a slot in the memory spot reader and instructs it to challenge P by sending the same random string to both T and P . The digests returned from T and P should match, and if they do, it is safe to assume that the secret in both memory spots is the same and hence the memory spot P must and can only have originated from the same place that issued T , i.e. the manufacturer. Message M ∗ , that should be the combination of D ||L||Q that was written by the manufacturer, is now retrieved from P . The login L∗ is extracted from the message and sent to the manufacturer, who checks whether it is valid. For valid L∗ the corresponding flag is subsequently tested, and if it is clear, the manufacturer sends the corresponding nonce to the verifier and then sets the flag. If the flag is not clear, the manufacturer responds to the verifier by either not returning the nonce at all or returning it with warnings - for example “Warning: This drug has already been verified. Is it being resold?” The manufacturer makes a record of every communication. After receiving N ∗ the message F ∗ is formed by adding it to the retrieved message M ∗ . Now the end-user has sufficient information to verify the digital signature using the manufacturer’s public key. The signature R ∗ is retrieved from the memory spot P and verified. If this fails, then the verifier is alerted, otherwise D ∗ and Q ∗ can be trusted. The next step is to compare Q ∗ with the factory fitted memory spot ID to ensure that the data has not been copied from another memory spot. Finally, the verifier checks that the product matches what is described in D ∗ , which may include the packaging fingerprint, expiry date and other relevant information. A failure in any one of these checks alerts the verifier that the product could be counterfeit. 3.5

Remarks

On some occasions the nonce N may not be received due to an accidental network failure or other less innocent reasons. Then, ideally the flag should not be set before there is confirmation that the returned nonce was successfully received by the querying party. To address the issue, the login L can be into two parts, L = L1 , L2 . In the authentication process, the user sends L1 only, the manufacturer returns

Anti-counterfeiting Using Memory Spots

Fig. 5. End-users verification procedure

61

62

H. Balinsky et al.

N  = L2 ⊕ N , the user then computes N = N  ⊕ L2 , and sends N back to the manufacturer. When the manufacturer sees the value N , he can be sure that the right N value has been received. The proposed package authentication scheme allows the authenticated information to be verified only once. This seems a disadvantage, but we would like to argue that this feature is a design feature and it is suitable for pharmaceutical packages, e.g. medicines, which will be sold to and used by the end-user only once in the life time of the product. The authentication verification process can only be run when the end-user is able to access the memory spot tag which implies that the package of the product has already been broken.

4

Security Threats and Analysis

In this section, we will describe in detail existing security threats and show that the proposed solution is resistant to: – – – – – – 4.1

data tampering on a memory spot tag memory spot tag cloning online attacks memory spot tag reuse impersonation attacks stolen memory spots attack Data Tampering on a Memory Spot Tag

Memory spot technology provides a combinational defense on hardware and software levels. After leaving the manufacturer the memory spot tag is a read only memory with circuitry permanently disabled to prevent further writing or data alterations. On a software level, a digital signature with the manufacturer’s private key is generated and stored on the memory spot. If the hardware protection proves inadequate and the data is altered, the signature will fail the verification process. As long as the private key of the manufacturer remains a secret a new signature for the amended data cannot be generated by the attacker. The enduser verifies this signature using the manufacturer’s public key that he receives by a separate trusted channel, for example from the local government, FDA, National Health Service office or directly from the manufacturer. 4.2

Cloning Memory Spot Tag Attacks

This means creating a new memory spot with the same unique ID number as the original one and then copying all the data stored on the authentic memory spot onto the new one. It is a very expensive attack that can only be realized by highly organized criminals with specialist equipment, as the unique ID is provided by hardware with correspondent circuitry permanently disabled after the data has been written (read only memory), However, only one memory spot tag can be

Anti-counterfeiting Using Memory Spots

63

verified for a given login number through the online database, thus the real gain by counterfeiters is limited to one substituted unit per one real. The original real drugs in these circumstances have to be completely distributed through the black market without any possible verification with the manufacturer. 4.3

Online Attacks

As a referential RFID system (as for example described in [8] only returns a simple “Yes” or “No” it is theoretically simple to create a spoof site that returns correct-looking information. The memory spot system requires a correct nonce in response to a login in order to close the loop on the authentication process, which is much more difficult to create. As logins L and nonces N are sparsely distributed large random integer numbers that are hard to guess, a complete database needs to be built and populated with genuine, stolen logins and nonces; anything else will cause the signature verification to fail. Real logins can be retrieved by scanning the drugs while in the distribution chain or by direct attack on the manufacturer database. The first scenario is hard to accomplish as memory spot has an extremely short access range and it is very easy to shield a tag from any malicious access, unless the tamper evident packaging is broken. Alternatively, the memory spot tag can be surrounded by heat sensitive ink that changes color when the tag is read (the reading process causes the tag to get warm). The second scenario is an issue of IT security and not within the scope of this paper. 4.4

Memory Spot Reuse Threat

The packaging should be made from tamper evident materials that cannot be repaired once they are broken without leaving visible marks of repair. So, we will concentrate on reuse of memory spot tags under the assumption that are already taken from their original packaging. This attack can be launched while drugs are still in a distribution chain or after a drug was used and its packaging was carelessly disposed of and subsequently maliciously collected. There are two means in our solution that prevent this attack or at least make it not-cost effective. Every unit is issued a unique login L that cannot be guessed and can be verified only once. The fact that the product is being sold and verified means that the flag in the database entry is turned on and even the whole record may be taken off line, thus rendering the read only memory spot useless. As there is no way to check the authenticity of the product without informing the manufacturer, there is a good incentive for a customer to do so. The second measure is to make the packaging from unique signature materials, for example glass beads, using non-clonable secure seals and adding this unique signature of material to message M whose authenticity is verified by the digital signature [14]. Thus, moving the memory spot into counterfeit packaging will demand an alteration of the data inside message M , which was discussed above in “Data tampering on a memory spot tag”.

64

4.5

H. Balinsky et al.

Impersonation Attacks

While the design of memory spot prevents contents from one memory spot from being copied to another memory spot (cloning attack), it is still conceivable that another device could be manufactured to impersonate the memory spot. It is technically feasible to manufacture another ASIC to clone the unique ID and the contents stored within the ROM area of a genuine memory spot, and also to physically look similar to a genuine memory spot, but such endeavor is unlikely. This is because the manufacture of an ASIC requires a substantial amount of financial investment, furthermore, the ASIC technology required to manufacture something similar to memory spot can only be provided by a few foundries in the world. This is an effective deterrent because perpetrators can easily be traced. The defense against this threat is provided by the on-board challenge response authenticator. Secret keys can be stored in certain locations that are only accessible by the processor. The construction of memory spots does not allow these secret keys to be read by any external process once they are written. The memory spot on-board authenticator will produce a digest based on the augmentation of the challenge string issued by the reader and the said secret keys. It is appreciated that no other information besides the digest is transmitted outside memory spot; hence, no secret is ever revealed. As only the issuer knows the secret, it is virtually impossible for a third party to impersonate a memory spot device. In the case of our pharmaceutical application, the memory spot attached to each unit can be programmed with a secret (perhaps, a unique, non-derivable random number for each lot). Another set of memory spots, so called “control spots”, are also programmed with the same secret. The “control spots” will then be issued to various pharmacies via a different channel (e.g. by post). A pharmacy wishing to validate the authenticity of a medicine will load the appropriate “control spot” into the reader and instruct the reader to validate the memory spot attached to the drug packaging. If the digest, reported by the “control spot”, matches that reported by the memory spot attached to the drug packaging, then both spots must only have originated from the same source. Since the control spots can be trusted, the memory spot attached to the drug packaging can also be trusted. 4.6

Stolen Memory Spots

Memory spot tags can be manufactured in just a few foundries in the world and ideally they should not leave the foundry without a unique ID programmed into them. However, under some scenarios it may be that the foundry ships blank memory spot tags and it is always a possibility that there could be theft from a foundry, taking tags from the production line before their IDs are programmed. Using these blank spots any valid memory spot can be nearly completely cloned: unique ID plus contents of the memory (except the contents of the restricted access memory which is not set anyway). The only way to prevent false acceptance of the fake drugs in this case is to use unique signature materials (non-clonable) for packaging as described in [14]. The non-repeatable packaging ID forms an

Anti-counterfeiting Using Memory Spots

65

integral part of the data signed by the pharmaceutical company private keys. False positive identification (false acceptance) should be minimized and ideally eliminated due to the fact that patients may be put at risk of serious adverse health consequences. If the memory spot tags are stolen after the unique ID has been programmed, this does not present a threat to the proposed solution as explained in “Cloning memory spot tag attacks”. In fact, the technology is expected to be deployed by a variety of different applications and memory spots containing only a unique ID are expected to be publicly available. Stealing them therefore presents no additional threat.

5

Comparison with the Existing Solutions

“FDA’s Report acknowledged the importance of using one or more authentication technologies for drug products, in particular those most likely to be counterfeited”[1]. Authentication technologies for anti-counterfeiting include R measures such as color shifting inks (for example, Microtaggant Security Ink from Microtrace [15]), holograms, fingerprints, or chemical markers embedded in a drug or its label. Generally usability studies show that users cannot accurately remember what the security features are, even for continually used things like money (like for example in [16]). Having trusted local storage of the descriptions of all the features is therefore extremely useful. In this way memory spot technology can be used to enhance existing solutions, but it also provides an authentication solution in its own right. Referential solutions (like RFID or Call-In-Numeric-Token [8]) might benefit the manufacturer, but not so much the end-user who is left to trust a “Yes” or “No” derived in a remote location and delivered over a non-secure channel. In contrast, memory spot technology brings the authentication directly to the end-user at the point of sale, which dramatically improves security and renders IP spoofing and other attacks ineffective. Referential solutions require a verifier to retrieve a generic image of a product over the Internet, which sometimes may not be possible or practical, while memory spot’s large data capacity enables all the unique features of the product to be stored locally. Our solution builds consumer trust and in the long term this will also benefit the manufacturer. Smartcards (like Philips Mifare) have the required memory capacity, but they are physically too big to be fitted into a blister pack for example, and also they are more expensive. For some applications physical size may not be an issue. As mentioned before, the most successful anti-counterfeiting solution in the research community is using RFID to build the supply chain security system [6]. This solution requires the involvement of many entities in the supply chain, such as multiple wholesalers. In some applications, such as pharmaceutical, building such a visible and secure chain is not easy and could be quite costly and difficult. We do not claim that our solution can cover all the security features and usability of the RFID secure supply chain. But we believe that our solution could be an alternative and supplement of the RFID secure supply chain in the pharmaceutical applications.

66

6

H. Balinsky et al.

Conclusions and Future Works

Memory spot has a wide variety of market applications, ranging from vertical to consumer oriented segments. An evaluation kit has been developed and is available for demonstrations and field trials. The full solution that we have described is well suited for high value items; a subset of the features can be used to provide a more basic level of security. For example, to combat warranty fraud an on-line database with nonce and login is not required. Estimates of the component cost of the silicon for the reader are that it should be within the same region as a Bluetooth radio. However as the reader/writer shares a significant proportion of the subsystems of a WLAN chip, this could lead to substantial cost savings and an easier path to deployment in a cell-phone platform.

References 1. US, Food and Drug Administration (FDA): Combating Counterfeit Drugs, A Report of the Food and Drug Administration (February 18, 2004) 2. US, Food and Drug Administration (FDA): Combating Counterfeit Drugs: A Report of the Food and Drug Administration, Annual Update (May 18, 2005) 3. Tuyls, P., Batina, L.: RFID-Tags for Anti-counterfeiting. In: Pointcheval, D. (ed.) CT-RSA 2006. LNCS, vol. 3860, pp. 115–131. Springer, Heidelberg (2006) 4. Staake, T., Thiesse, F., Fleisch, E.: The Potential of RFID in Anti-Counterfeiting. In: The 20th Annual ACM Symposium on Applied Computing, Santa Fe, New Mexico, March 13 -17 (2005) 5. Lehtonen, M., Staake, T., Michahelles, F., Fleisch, E.: From Identification to Authentication - A Review of RFID Product Authentication Techniques. In: Workshop on RFID Security – RFIDSec 2006 (July 2006) 6. Staake, T., Michahelles, F., Fleisch, E., Williams, J.R., Min, H., Cole, P.H., Lee, S.G., McFarlane, D., Murai, J.: Anti-Counterfeiting and Supply Chain Security. In: Cole, P.H., Ranasinghe, D.C. (eds.) Networked RFID Systems and Lightweight Cryptography - Raising Barriers to Product Counterfeiting. Springer, Heidelberg (2007) 7. US, Food and Drug Administration (FDA): Questions and Answers about Counterfeit Drugs (June 2, 2008) 8. Johnston, R.: An Anti-Counterfeiting Strategy Using Numeric Tokens Los Alamos National Laboratory. Int. J. of Pharmaceutical Medicine 19, 163 (2005) 9. White Paper by Philips Semiconductors: Item-level visibility in the pharmaceutical supply chain: a comparison of HF and UHF RFID technologies. TAGSYS, Texas Instruments (2004), http://www.tagsysrfid.com/knowledge-center/upload/ TAGSYS-TI-Philips-White-Paper.pdf (June 2009) 10. Pan-European Summit for Pharmaceutical Manufacturers in the Enlarged EU, Le M´eridien Piccadilly, London (February 2005) 11. Ramos, L., Holmes, B., Overby, C., McAulay, S., McEnroe, W.: Authentication, Not RFID, Will Make Drugs Safer. Forrester (July 2005), http://www.forrester.com/Research/Document/Excerpt/ 0,7211,36832,00.html (June 2009)

Anti-counterfeiting Using Memory Spots

67

12. Hewlett-Packard News Release: HP Unveils Revolutionary Wireless Chip that Links the Digital and Physical Worlds. Palo Alto (July 2006), http://www.hp.com/hpinfo/newsroom/press/2006/060717a.html (June 2009) 13. Eban, K.: Dangerous Doses, How Counterfeiters Are Contaminating America’s Drug Supply. Harcourt, Inc., Orlando (2005) 14. Balinsky, H., McDonnell, E.: Anti-counterfeit packaging. International patent application PCT/EP2007 /057519 (July 2007) R 15. Microtaggant: Paper Solutions, Microtaggant Security Ink, http://www.microtaggant.com/anticounterfeiting-security-ink.htm (June 2009) 16. de Heij, H.A.M.: Feedback from the public for better banknote design. De Nederlandsche Bank (Netherlands). In: IS&T/SPIE 18th Annual Symposium (January 2006) (presentation)

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations Emmanuelle Dottax1 , Christophe Giraud2 , Matthieu Rivain1,3 , and Yannick Sierra1 1

Oberthur Technologies, 71-73, rue des Hautes Pˆ atures, 92 726, Nanterre, France 2 Oberthur Technologies, 4, all´ee du doyen Georges Brus, 33 600, Pessac, France 3 University of Luxembourg, Faculty of Sciences, Technology and Communication 6, rue Richard Coudenhove-Kalergi, L-1359 Luxembourg {e.dottax,c.giraud,m.rivain,y.sierra}@oberthur.com

Abstract. Since their publication in 1996, Fault Attacks have been widely studied from both theoretical and practical points of view and most of cryptographic systems have been shown vulnerable to this kind of attacks. Until recently, most of the theoretical fault attacks and countermeasures used a fault model which assumes that the attacker is able to disturb the execution of a cryptographic algorithm only once. However, this approach seems too restrictive since the publication in 2007 of the successful experiment of an attack based on the injection of two faults, namely a second-order fault attack. Amongst the few papers dealing with second-order fault analysis, three countermeasures were published at WISTP’07 and FDTC’07 to protect the RSA cryptosystem using the CRT mode. In this paper, we analyse the security of these countermeasures with respect to the second-order fault model considered by their authors. We show that these countermeasures are not intrinsically resistant and we propose a new method allowing us to implement a CRT-RSA that resists to this kind of second-order fault attack. Keywords: Fault Attacks, Second Order, CRT-RSA, Countermeasure.

1

Introduction

When attackers have access to physical implementations, cryptographic algorithms need to be secured against threats beyond classical cryptanalysis. Among these, faults attacks (FA) aim at disturbing cryptographic computations, and exploit erroneous results to recover information on secret data. They were introduced in 1996 [5] and they have been further studied since. Techniques have been improved and they have found applications on a wide variety of cryptographic algorithms. A non exhaustive list comprises RSA [1, 5, 16, 17, 19, 25], DSA [22], DES [3, 14], AES [23] and stream ciphers [15]. O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 68–83, 2009. c IFIP International Federation for Information Processing 2009 

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

69

A fault attack description must specify the fault model it assumes [13]. This model clarifies the capabilities of the attacker such as the kind of error (e.g. bit flip in data, program execution modification), the timing precision or the number of errors. The latter characteristic is called the order of the attack: first-order attacks assume an attacker who can induce only one error per execution of the target algorithm. Similarly, second-order attacks assume an attacker who can induce two errors per execution, and so forth. The practicability of the model is of importance to assess the feasibility of an attack. The seminal work [5] introduces several first-order attacks among which one targets an RSA implementation using the Chinese Remainder Theorem (CRT for short). Indeed, most RSA implementations in embedded systems use CRT because of its performance benefits. Let N denote the public modulus composed of two secret prime numbers p and q such that N = p · q. Let e refer to the public exponent and d refer to the private exponent. Whereas a straightforward implementation computes the signature of a message m by performing S = md mod N , a CRT-based implementation is composed of two exponentiations Sp = mdp mod p and Sq = mdq mod q, where dp = d mod (p−1) and dq = d mod (q − 1). As the signature S satisfies S ≡ Sp mod p and S ≡ Sq mod q, it can be computed from Sp and Sq by using the CRT [9]. This additional computation is called the recombination step. The principle of the so-called Bellcore attack [5] is to disturb one of the exponentiations, say Sq , so that the recombination step results in a faulty signature S satisfying S ≡ S mod p and S  ≡ S mod q. The  N ). The fault secret parameter p can then be recovered by computing gcd(S − S, model of this attack is very weak because the attacker only needs to disturb one exponentiation to succeed. The fault can be introduced at any time during the computation, either in code or in data. Due to both the performance advantages of the CRT-RSA and its high vulnerability to fault attacks, securing its implementation is an important and challenging task. Several countermeasures have been introduced of which common goal is to prevent the output of a hazardous result. To do so, a simple solution is to verify the signature before returning it. However, this verification may be costly if the public exponent is not small or/and if it is not provided by the API (e.g. in Javacard). Therefore, more sophisticated methods have been designed which do not rely on additional parameters. We can distinguish two main approaches. The first one is the introduction of internal coherence checks that aim at verifying the validity of the result before returning it [6, 10, 11]. The second one is to make use of so-called infective procedures that render the erroneous signature harmless in case of fault injection [8]. At WISTP’07, Kim and Quisquater [19] introduced a second-order fault model in which they were able to practically break the (first-order) countermeasures of [8] and [10]. Their work also includes improvements of the first-order countermeasures to achieve a secure implementation in their second-order fault model. Later, at FDTC’07, they proposed in [20] an implementation also meant to resist in this model. Unfortunately, we show in this paper that the proposed

70

E. Dottax et al.

countermeasures are actually not intrinsically resistant in this model and that they may be successfully attacked. The rest of this paper is organized as follows. Section 2 recalls the fault model introduced by Kim and Quisquater. Sections 3 and 4 present the countermeasures proposed in [19] and [20] respectively and exhibit their vulnerabilities. Section 5 proposes a generic countermeasure that enables to render any method intrinsically resistant in the Kim and Quisquater’s fault model. Finally, Section 6 concludes the paper.

2

Kim and Quisquater’s Second-Order Fault Model

The literature contains several practical examples of fault attacks. However, to the best of our knowledge, the paper [19] is the first one that reports a successful experiment of a second-order fault attack. In this paper, Kim and Quisquater explain how they practically mounted a second-order attack against a firstorder resistant CRT-RSA implementation. We shall refer to this attack as the KQ-attack. An algorithm is said to be first-order resistant when it contains some countermeasure which ensures that any single error occurring in the execution of the algorithm is not exploitable by an attacker. In the case of the CRT-RSA, some redundant computations are usually added in order to check the coherence of the computation (e.g. [10]) or to infect the faulty signature (e.g. [7]). When a single fault is injected and corrupts the RSA computation, it is systematically detected (or at least with high probability) and the faulty signature is not revealed (or is infected ). However, an attacker may defeat such a countermeasure by using a second-order fault analysis, namely by injecting two faults. In that case, one of these faults must be dedicated to the corruption of the RSA computation in order to produce an exploitable faulty signature. The second fault is then used to render the countermeasure ineffective. For such a purpose, two approaches are possible: – In the first approach, the attacker tries to fool the coherence check. Namely, the second fault aims at covering the effects of the first fault in such a way that the coherence check does not detect it while the result of the RSA computation remains faulty. To do so, the attacker needs to precisely control the two fault injections effects. This implies a very strong and yet not practical adversary model. – The second approach consists in directly skipping the coherence verification (or the infection procedure). Since several experiments have demonstrated the practicability of skipping the execution of one or more operations (see for instance [2,19,21]), this approach corresponds to a weaker model of adversary and is then more natural from a practical point of view. The Kim and Quisquater’s second-order fault model (referred in the sequel as KQ-model ) corresponds to this latter approach. We formalize it hereafter.

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

71

Fault Model (KQ-model). Two faults are injected. The first fault can be of any type (instructions skip, memory modification, . . . ), provided it disturbs the RSA computation and produces an exploitable faulty signature. The second fault allows the attacker to skip any operation or set of contiguous operations in order to circumvent the coherence check (or the infective procedure). In the next section, we show that the countermeasures proposed by Kim and Quisquater in [19] and [20] do not intrinsically resist all fault attacks in their model.

3

Analysis of WITSP’07 Countermeasures

In a paper published at WISTP’07, Kim and Quisquater have reported some practical experiments of second-order fault analysis [19]. They succeeded in breaking two first-order FA-countermeasures published at FDTC’05: the one by Ciet and Joye [8] and the one by Giraud [10]. Finally, they proposed to modify both countermeasures in order to resist to their second-order fault attack. In this section, we present the two countermeasures improved by Kim and Quisquater in [19] which are meant to resist fault analysis in the KQ-model and we show that they are weak with regard to this fault model. 3.1

Analysis of the First WISTP Countermeasure

Description. This first countermeasure of [19] is an improvement of Ciet and Joye’s countermeasure [8] which is a generalization of Shamir’s trick [24]. The basic principle is to multiply the modulus p (resp. q) by a small integer r1 (resp. r2 ). The exponentiation is then carried out modulo r1 · p (resp. r2 · q) which allows to verify the result modulo r1 (resp. r2 ) afterward. If an error is detected, the resulting signature is infected using a random value r3 . Algorithm 1. Modified Ciet and Joye’s scheme [19] Inputs: m, p∗ , q ∗ , dp , dq , Iq∗ , N , r1 , r2 , r3 Output: S = md mod N 1. 2. 3. 4. 5.

Choose a random integer a in Z∗r1 r2 N Initialize γ with a random number Sp∗ ← (a + mdp ) mod p∗ s2 ← (a + mdq mod ϕ(r2 ) ) mod r2 Sq∗ ← (a + mdq ) mod q ∗

6. s1 ← (a + mdp mod ϕ(r1 ) ) mod r1 7. S ∗ ← Sq∗ + q ∗ · Iq∗ · (Sp∗ − Sq∗ ) mod p∗ 8. c1 ← (S ∗ − s1 + 1) mod r1 9. c2 ← (S ∗ − s2 + 1) mod r2 10. γ ← (r3 c1 + (2l − r3 )c2 )/2l  11. return (S ∗ − aγ ) mod N

72

E. Dottax et al.

For two security parameters k and l, let r1 and r2 as two co-prime k-bit integers and r3 as an l-bit integer. And let p∗ , q ∗ and Iq∗ be defined as p∗ = r1 · p, q ∗ = r2 · q and Iq∗ = (q ∗ )−1 mod p∗ . Algorithm 1 describes the modified Ciet and Joye’s scheme. If no fault is injected, the result of Step 7 is S + a mod N and the result of Step 10 is γ = 1 (since s1 = s2 = 1). This way, Step 11 returns the correct signature. On the other hand, if an error is detected, Step 10 returns γ  = 1 and Step 11 infects the returned signature with the random value a (see [19] for further details). Analysis. By noticing that S ∗ ≡ Sp + a mod p and S ∗ ≡ Sq + a mod q, we observe that the Bellcore attack can be successfully applied to the output of Algorithm 1 if a is always subtracted to S ∗ , whatever the fault induced on either Sp∗ or Sq∗ . Indeed, if an attacker disturbs the computation of, say, Sp∗ in ∗ is obtained at the beginning of Step 11 and it Step 3 then a faulty value S ∗  ∗ ≡ Sq + a mod q. Secondly, if he corrupts the satisfies: S ≡ Sp + a mod p and S exponentiation (a, γ)  → aγ in such a way that it outputs a, Algorithm 1 returns S∗ − a mod N . The Bellcore attack can then be successfully applied. The feasibility of this attack depends on implementation details of Step 11 of Algorithm 1. However, we show that a straightforward implementation is vulnerable. We denote by R0 the register containing S ∗ and by R1 the register containing a. A straightforward implementation of Step 11 performs the following operations: 11.1. R1 ← (R1 )γ mod N 11.2. R0 ← R0 − R1 mod N 11.3. return R0

[R1 = aγ mod N ] [R0 = S ∗ − aγ mod N ]

Such an implementation makes Algorithm 1 insecure in the KQ-model. Indeed, the attacker can skip the operation R1 ← (R1 )γ mod N , which results ∗ − a mod N . in the faulty output S = S This example demonstrates that the proposed improvement of the Ciet and Joye countermeasure is not intrinsically secure in the intended KQ-model. Furthermore, this example is particurlarly relevant, as the same one is used by Kim and Quisquater in [19] to break the original countermeasure. 3.2

Analysis of the Second WISTP Countermeasure

Description. The second countermeasure is an improvement of Giraud’s scheme [10,11] that is based on the Montgomery powering ladder. This exponentiation algorithm works on a pair of intermediate results of the form (mδ−1 , mδ ) which allows to check the coherence of the result. In the following, CRT(Sp , Sq ) denotes Garner’s recombination: ((Sp − Sq ) · (q −1 mod p) mod p)·q+Sq . The improvement of Giraud’s scheme uses a modified exponentiation algorithm that is described in Algorithm 2. The whole modified Giraud’s scheme is described in Algorithm 3.

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

73

Algorithm 2. Modified SPA-FA-resistant modular exponentiation [19] Inputs: m, d = (1, dn−2 , · · · , d0 )2 , N , a Output: (a + md−1 mod N, a + md mod N ) 1. a0 ← m 2. a1 ← m2 mod N 3. for i from n − 2 to 1 do adi ← adi · adi mod N

adi ← adi 2 mod N 4. a1 ← (a + a1 · a0 ) mod N 5. a0 ← (a + a0 2 ) mod N 6. if (Loop Counter i not modified) & (Exponent d not modified) then return (a0 , a1 ), else return error.

Algorithm 3. Modified Giraud’s scheme [19] Inputs: m, p, q, dp , dq Output: S = md mod N 1. 2. 3. 4. 5. 6. 7. 8.

Initialize a with a random number in Z∗N (Sp∗ , Sp ) ← Algo. 2(m, dp , p, a) (Sq∗ , Sq ) ← Algo. 2(m, dq , q, a) S ∗ ← CRT(Sp∗ , Sq∗ ) S ← CRT(Sp , Sq ) S ∗ ← m · S ∗ + a mod (p · q) S ← S + a · m mod (p · q) if (S ∗ = S) & (Parameters p and q not modified) then return (S − a − a · m) mod (p · q) else return error.

If a fault is injected, then it breaks the coherence between S and S ∗ , and the test in Step 8 returns an error. Otherwise, the correct signature is returned (see [19] for further details). Analysis. We observe that if the test (S ∗ = S) is skipped then the algorithm execution carries on as if the test had been successfully performed. Therefore, if a first fault induces a faulty signature S and a second one skips the test  an attacker is able to make Algorithm 3 return a faulty signature (S ∗ = S),  (S − a − a · m) mod N which enables the Bellcore Attack. The faulty signature S can be obtained by disturbing either Step 2 or Step 3 of Algorithm 3 without

74

E. Dottax et al.

modifying the values that are checked (e.g. by disturbing the value a1 at Step 4 of Algorithm 2), or by disturbing Step 5 of Algorithm 3. Note that such an attack has been successfully put into practice by Kim and Quisquater in [19]. This shows that the proposed countermeasure is vulnerable in their model and therefore does not reach its goal.

4

Analysis of the FDTC’07 Countermeasures

At FDTC’07, Kim and Quisquater proposed an implementation of CRT-RSA which is meant to resist both side channel analysis and fault analysis [20]. In particular, they claimed the security of their proposal versus the KQ-model. However, we show in this section that their countermeasure is not intrinsically resistant in this model. We analyse two variants of this countermeasure. The first one is the original countermeasure which has been published in FDTC’07 proceedings. The second one is a patched version that has been presented at the workshop. 4.1

Analysis of the Original FDTC Countermeasure

Description. Similarly to Ciet and Joye’s scheme, the implementation proposed by Kim and Quisquater is based on Shamir’s trick. For two co-prime k-bit integers t1 and t2 , let p∗ and q ∗ be defined as p∗ = p · t1 and q ∗ = q · t2 . The following values are then computed and stored in the device: d∗p = d mod ϕ(p∗ ), d∗q = d mod ϕ(q ∗ ), eti = d−1 mod ϕ(ti ), where i = 1, 2. Algorithm 4 describes the exponentiation algorithm which is used to compute the two CRT components Sp∗ and Sq∗ while Algorithm 5 describes the whole protected CRT-RSA. If no fault is injected during the signature computation (i.e. during Steps 3 to 5) then the result of Step 5 is S · r mod N and the results of Steps 6 and 7 are c1 = c2 = 1. This way Step 8 returns the correct signature. If an error is detected, then we have either c1  = 1 or c2  = 1 and Step 8 returns a signature infected by the random value a (see [19] for further details). Algorithm 4. FA-DPA-resistant modular exponentiation [20] Inputs: m, d = (dn−1 , · · · , d0 )2 , N , a, r = a−1 mod N Output: C = md mod N C ← r mod N a0 ← a a1 ← m · a mod N for i from n − 1 to 0 do C ← C 2 mod N C ← C · adi mod N 5. return C

1. 2. 3. 4.

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

75

Algorithm 5. FA-DPA-resistant CRT-RSA [20] Inputs: m, p∗ , q ∗ , d∗p , d∗q , N , et1 , et2 , t1 , t2 Output: S = md mod N 1. 2. 3. 4. 5. 6. 7. 8.

Select a random r in Z∗p∗ q∗ and compute a = r −1 mod p∗ q ∗ Initialize c1 and c2 with random values Sp∗ ← Algo. 4(m, d∗p , p∗ , a, r) Sq∗ ← Algo. 4(m, d∗q , q ∗ , a, r) S ∗ ← CRT(Sp∗ , Sq∗ ) c1 ← (m · r et1 − (S ∗ )et1 + 1) mod t1 c2 ← (m · r et2 − (S ∗ )et2 + 1) mod t2 return S = S ∗ · ac1 ·c2 mod N

Analysis. The principle of the attack described below is similar to the one described in Section 3.1. By noticing that we have S ∗ ≡ Sp · r mod p and S ∗ ≡ Sq · r mod q, we observe that the Bellcore attack can be successfully applied to the output of Algorithm 5 if S ∗ is always multiplied by a in Step 8 whatever the fault induced on either Sp∗ or Sq∗ . Let us examine the feasibility of this attack according to the implementation details of Step 8 of Algorithm 5. We denote by R0 the register containing S ∗ and by R1 the register containing a. A straightforward implementation of Step 8 performs the following operations: 8.1. R1 ← (R1 )c1 ·c2 mod N 8.2. R0 ← R0 · R1 mod N 8.3. return R0

[R1 = ac1 ·c2 mod N ] [R0 = S ∗ · ac1 ·c2 mod N ]

If an attacker corrupts one of the two exponentiations (Step 3 or Step 4) and then skips the operation R1 ← (R1 )c1 ·c2 mod N in Step 8, then Step 8 returns a faulty value of S ∗ multiplied by a which enables the Bellcore attack. Here again, this example demonstrates a weakness of the proposed countermeasure with respect to the KQ-model. The authors had been informed of this attack after the printing of the FDTC’07 proceedings, but before the workshop [12]. Therefore, they have patched their countermeasure and presented the following improved version to the workshop. 4.2

Analysis of the Improved FDTC Countermeasure

Description. Let α be a small random value (less than one byte) and let β be defined as β = α−1 mod ϕ(N ). Algorithm 6 describes the patched version of the Kim and Quisquater countermeasure presented at FDTC’07. Analysis. By noticing that S ∗ ≡ Sp · bβ mod p and S ∗ ≡ Sq · bβ mod q, we observe that the Bellcore attack can be successfully applied to the output of

76

E. Dottax et al.

Algorithm 5 if S ∗ is always multiplied by bα whatever the fault induced on either Sp∗ or Sq∗ . Therefore, by disturbing an exponentiation computing either Sp∗ or Sq∗ and by skipping the multiplication (c1 , c2 , α)  → c1 · c2 · α in such a way that it returns α, the attacker obtains a faulty signature S = S∗ · bα mod N allowing him to recover the secret CRT parameters since S is congruent to Sq modulo q (resp. to Sp modulo p) but not to Sp modulo p (resp. to Sq modulo q). Algorithm 6. Improved FA-DPA-resistant CRT-RSA Inputs: m, p∗ , q ∗ , d∗p , d∗q , N , et1 , et2 , t1 , t2 , α, β Output: S = md mod N 1. 2. 3. 4. 5. 6. 7. 8. 9.

Select a random r in Z∗N and compute a = r −1 mod N ∗ Initialize c1 and c2 with random values b ← aβ mod N Sp∗ ← Algo. 4(m, dp , p∗ , a, r) Sq∗ ← Algo. 4(m, dq , q ∗ , a, r) S ∗ ← CRT(Sp∗ , Sq∗ ) c1 ← (m · r et1 − (S ∗ )et1 + 1) mod t1 c2 ← (m · r et2 − (S ∗ )et2 + 1) mod t2 return S ∗ · bc1 ·c2 ·α mod N

The effectiveness of such an attack depends on the implementation of the multiplication. We can distinguish three different cases depending on the result location: 1. c1 ← c1 · c2 , 2. c2 ← c1 · c2 , 3. temp ← c1 · c2 . For the two first cases, if the attacker skips the multiplication c1 · c2 then the value of c1 (resp. c2 ) remains unchanged. Therefore, if case 1 (resp. case 2) is used to implement the multiplication, the attacker must disturb the computation of Sq (resp. Sp ) and skip the multiplication c1 · c2 . As c1 = 1 (resp. c2 = 1) since no error has been induced on Sp (resp. on Sq ), then the next multiplication with α will result in outputting α. The attack is thus effective. However, if the third method is used, the skipping of the multiplication c1 · c2 will result in outputting the previous value of temp which is unlikely to be equal to 1. In this case, our attack cannot be applied. This analysis shows that in the KQ-model most implementations of the improved FDTC’07 countermeasure are vulnerable, in other words this countermeasure is not intrinsically secure.

5

Countermeasure

In this section, we describe a countermeasure which can be used to counteract the attacks presented in Sections 3 and 4. The proposed countermeasure is indeed

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

77

generic and can make any kind of first-order FA-countermeasure resistant to attacks in the KQ-model, provided it uses a form of redundancy and a checking (or infective) procedure. 5.1

Description

Firstly, we assume that the FA-countermeasure computes some redundant value c which is involved in the checking (or infective) procedure. Thus c is expected to take a given value, denoted c , otherwise the checking (resp. infective) procedure returns an error (resp. infects the returned signature). Our countermeasure is based on a simple mechanism that advantageously replaces the checking (resp. infective) procedure: given c and its expected value c , we perform the check (c = c ) twice while inserting in between a simple but pivotal statement. The whole procedure is described hereafter. Procedure 1. Lock - principle Inputs: Res, S, c and c Process: {Res ← S} if c = c and {Res ← 0; S ← 0} otherwise 1. 2. 3. 4.

if (c = c ) erase S Res ← S if (c = c ) erase Res return Res

Remark 1. Some works have argued that coherence checks using conditional branches must be avoided for FA security [4, 7, 26]. The argument behind this assertion is that such a test can be skipped by corrupting the status register. As we show in Section 5.2, our solution is secure in the KQ-model despite the use of conditional branches. For the sake of completeness, we propose in Appendix A an implementation of the Lock procedure that avoid conditional branches. A solution to strengthen an FA-resistant CRT-RSA based on the Lock procedure follows the series of steps hereafter. First, the result buffer Res is initialized at 0. Then the FA-resistant CRT-RSA is executed: from a message m and some parameters P it outputs a signature S = md mod N and a couple of values (c, c ) which depends on the FA-countermeasure. Afterward, the Lock procedure described in Procedure 1 is executed and Res is eventually returned. If c = c then Lock processes Res ← S and the computed signature is returned. Otherwise, the Lock procedure handles the signature erasure. The overall RSA implementation resistant is described in Algorithm 7. This generic solution can be applied to any FA-countermeasure based on redundant computation and it is resistant to the KQ-attack as shown in the next section.

78

E. Dottax et al.

Algorithm 7. KQ-attack resistant RSA Inputs: m, P Output: md mod N 1. Res ← 0 2. (S, c, c ) ← FA-Res-CRT-RSA(m, P) 3. Lock(Res, S, c, c )

5.2

Security Analysis

In the KQ-model (see Section 2), a first fault is dedicated to the corruption of the RSA computation and a second fault aims to avoid the erasure of the faulty signature by skipping some operations. According to this model, we assume that an attacker can: – inject a fault in Step 2 of Algorithm 7 producing a faulty signature S and a faulty pair of checking values ( c, c ) such that  c = c (this results from the soundness of the first-order countermeasure that is used), – skip a set of contiguous operations of Algorithm 7. We demonstrate hereafter that the skipping of any set of contiguous operations of Algorithm 7 cannot prevent the Lock procedure from erasing the faulty signature S (or returning an unexploitable result) while the faulty checking values  c and c are different. Let us first assume that the adversary skips the entire Step 2 of Procedure 1 One can check that in this case Res holds its initialization value and Algorithm 7 then returns an unexploitable result. On the opposite, if Step 2 of Procedure 1 is not entirely skipped, then either all the previous operations or all the following operations are properly executed since the set of skipped operations is contiguous. As a result, either Step 1 or Step 3 of Procedure 1 is executed which ensures the signature erasure in case of fault detection (i.e. if  c and c are different). To conclude, any KQ-attack implies the return of an unexploitable output and the attacker gains no sensitive information. 5.3

Application

In this section, we show how to apply the generic countermeasure described is Section 5.1 to Ciet and Joye’s scheme [7] and to Giraud’s scheme [11]1 . For this purpose, we have to modify these schemes in such a way that they output a checking value c and its expected value c . They can then be used in replacement of the function FA-Res-CRT-RSA in Algorithm 7. 1

It can also be straightforwardly applied to the implementation described in [19] since the FA-countermeasure is very similar to the one presented in [7].

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

79

Modified Ciet and Joye’s Scheme. We describe hereafter the modified Ciet and Joye’s scheme that includes the countermeasure proposed in Section 5.1. Algorithm 8. New Modified Ciet and Joye’s scheme Inputs: m, p∗ , q ∗ , dp , dq , Iq∗ , N Outputs: S = md mod N , c = (c1 , c2 ), c = (c1 , c2 ), r1 , r2 1. Initialize (c1 , c2 ) and (c1 , c2 ) with different arbitrary values 2. Sp∗ ← mdp mod p∗ 3. c2 ← mdq mod ϕ(r2 ) mod r2 4. Sq∗ ← mdq mod q ∗ 5. c1 ← mdp mod ϕ(r1 ) mod r1 6. S ∗ ← Sq∗ + q ∗ · Iq∗ · (Sp∗ − Sq∗ ) mod p∗ 7. c1 ← S ∗ mod r1 8. c2 ← S ∗ mod r2 9. S ← S ∗ mod N 10. return (S, (c1 , c2 ), (c1 , c2 ))

If a fault injection implies (c1 , c2 )  = (c1 , c2 ) (i.e. if the signature computation is corrupted), then one can check that it is impossible to force (c1 , c2 ) = (c1 , c2 ) by skipping a set of contiguous operations in Algorithm 8. Indeed, (c1 , c2 ) and (c1 , c2 ) are initialized with different values in Step 1 and they remain different until the end of the algorithm whether the different steps are executed or not. The only way one could force (c1 , c2 ) = (c1 , c2 ) would be by skipping Steps 1 to 8 while assuming that the default values (before Step 1) of the buffers storing (c1 , c2 ) and (c1 , c2 ) are the same. This would imply that the RSA computation is not performed which would prevent any attack. Modified Giraud’s Scheme. We describe hereafter the modified Giraud’s scheme that includes the countermeasure proposed in Section 5.1. The Giraud’s scheme [11] is based on the Montgomery powering ladder [18] that from m, p and dp returns the pair (mdp −1 mod p, mdp mod p). The coherence is checked by verifying the relation between the two returned values. Moreover, in order to avoid attacks disturbing the exponent, the modulus or the loop counter some checking information is computed. Let us denote by CI this checking information and by CI  its expected value. Instead of checking CI = CI  at the end of the exponentiation as in [11], (CI, CI  ) is returned as well as (mdp −1 mod p, mdp mod p). We denote by M M E the modified Montgomery powering ladder. Algorithm 9 summarizes the modified Giraud’s scheme. In [11], it is not detailed how to compute the checking information CI on the loop counter, on the exponent and on the modulus. In [10], it is suggested to double the loop index and to compute a checksum for the exponent and the modulus. We do not give further details here since it is not our purpose. However, we mention that for our countermeasure to be valid, it is important that if a

80

E. Dottax et al.

Algorithm 9. New Modified Giraud’s scheme Inputs: m, p, q, dp , dq Outputs: S = md mod N , c = (S, CIp , CIq ), c = (S ∗ , CIp , CIq ) 1. 2. 3. 4. 5. 6. 7.

Initialize (CIp , CIq ) and (CIp , CIq ) with different arbitrary values (Sp∗ , Sp , CIp , CIp ) ← MME(m, dp , p) (Sq∗ , Sq , CIq , CIq ) ← MME(m, dq , q) S ∗ ← CRT(Sp∗ , Sq∗ ) S ← CRT(Sp , Sq ) S ∗ ← S ∗ · m mod N   return S, (S, CIp , CIq ), (S ∗ , CIp , CIq )

fault injection disturbs either the loop index or the exponent or the modulus, the attacker cannot force CI = CI  by skipping some operations. On the other hand, if one injects a fault that does not affect the loop counter nor the exponent nor the modulus, then it breaks the relation between the Sp∗ and Sp (resp. Sq∗ and Sq ) in a way that is unpredictable for the attacker [11]. This makes it impossible for the attacker to recreate this relation – and hence to force c = c – by skipping some operations.

6

Conclusion

In this paper, we have analysed the security of the second-order FA-countermeasures published at WISTP’07 and FDTC’07. We have shown that these countermeasures are not intrinsically resistant with regard to the corresponding second-order fault model. We have also proposed a new method to protect CRTRSA against this particular class of second-order fault attacks which induces a very small overhead compared to the traditional first-order FA-countermeasures. Protecting the CRT-RSA against a wider class of second-order fault attacks is still an open issue. This problem requires all our attention in order to anticipate future evolutions in practical fault induction which could follow the recent publication of the first practical application of a second-order fault attack.

References 1. Aum¨ uller, C., Bier, P., Fischer, W., Hofreiter, P., Seifert, J.-P.: Fault attacks on RSA with CRT: Concrete results and practical countermeasures. In: Kaliski Jr., B.S., Ko¸c, C ¸ .K., Paar, C. (eds.) CHES 2002. LNCS, vol. 2523, pp. 260–275. Springer, Heidelberg (2003) 2. Bar-El, H., Choukri, H., Naccache, D., Tunstall, M., Whelan, C.: The Sorcerer’s Apprentice Guide to Fault Attacks. IEEE 94(2), 370–382 (2006) 3. 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)

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations

81

4. Bl¨ omer, J., Otto, M., Seifert, J.-P.: A New RSA-CRT Algorithm Secure against Bellcore Attacks. In: Jajodia, S., Atluri, V., Jaeger, T. (eds.) ACM Conference on Computer and Communications Security – CCS 2003, pp. 311–320. ACM Press, New York (2003) 5. 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) 6. Boscher, A., Naciri, R., Prouff, E.: CRT RSA Algorithm Protected Against Fault Attacks. In: Sauveron, D., Markantonakis, K., Bilas, A., Quisquater, J.-J. (eds.) WISTP 2007. LNCS, vol. 4462, pp. 229–243. Springer, Heidelberg (2007) 7. Ciet, M., Joye, M.: Elliptic Curve Cryptosystems in the Presence of Permanent and Transient Faults. Designs, Codes and Cryptography 36(1), 33–43 (2005) 8. Ciet, M., Joye, M.: Practical Fault Countermeasures for Chinese Remaindering Based RSA. In: Breveglieri, L., Koren, I. (eds.) Workshop on Fault Diagnosis and Tolerance in Cryptography – FDTC 2005, pp. 124–132 (2005) 9. Garner, H.: The Residue Number System. IRE Transactions on Electronic Computers 8(6), 140–147 (1959) 10. Giraud, C.: Fault Resistant RSA Implementation. In: Breveglieri, L., Koren, I. (eds.) Workshop on Fault Diagnosis and Tolerance in Cryptography – FDTC 2005, pp. 142–151 (2005) 11. Giraud, C.: An RSA Implementation Resistant to Fault Attacks and to Simple Power Analysis. IEEE Transactions on Computers 55(9), 1116–1120 (2006) 12. Giraud, C.: Personnal communication (June 29, 2007) 13. Giraud, C., Thiebeauld, H.: A Survey on Fault Attacks. In: Quisquater, J.-J., Paradinas, P., Deswarte, Y., Kalam, A.E. (eds.) Smart Card Research and Advanced Applications VI – CARDIS 2004, pp. 159–176. Kluwer Academic Publishers, Dordrecht (2004) 14. Hemme, L.: A Differential Fault Attack Against Early Rounds of (Triple-)DES. In: Joye, M., Quisquater, J.-J. (eds.) CHES 2004. LNCS, vol. 3156, pp. 254–267. Springer, Heidelberg (2004) 15. Hoch, J., Shamir, A.: Fault Analysis of Stream Ciphers. In: Joye, M., Quisquater, J.-J. (eds.) CHES 2004. LNCS, vol. 3156, pp. 240–253. Springer, Heidelberg (2004) 16. Joye, M., Lenstra, A., Quisquater, J.-J.: Chinese Remaindering Based Cryptosystems in the Presence of Faults. Journal of Cryptology 12(4), 241–245 (1999) 17. Joye, M., Quisquater, J.-J., Bao, F., Deng, R.: RSA-type Signatures in the Presence of Transient Faults. In: Darnell, M.J. (ed.) Cryptography and Coding 1997. LNCS, vol. 1355, pp. 155–160. Springer, Heidelberg (1997) 18. Joye, M., Yen, S.-M.: The Montgomery Powering Ladder. In: Kaliski Jr., B.S., Ko¸c, C ¸ .K., Paar, C. (eds.) CHES 2002. LNCS, vol. 2523, pp. 291–302. Springer, Heidelberg (2003) 19. Kim, C.H., Quisquater, J.-J.: Fault Attacks for CRT Based RSA: New Attacks, New Results, and New Countermeasures. In: Sauveron, D., Markantonakis, K., Bilas, A., Quisquater, J.-J. (eds.) WISTP 2007. LNCS, vol. 4462, pp. 215–228. Springer, Heidelberg (2007) 20. Kim, C.H., Quisquater, J.-J.: How Can We Overcome Both Side Channel Analysis and Fault Attack on RSA-CRT? In: Breveglieri, L., Gueron, S., Koren, I., Naccache, D., Seifert, J.-P. (eds.) Fault Diagnosis and Tolerance in Cryptography – FDTC 2007, pp. 21–29. IEEE Computer Society Press, Los Alamitos (2007) 21. Kommerling, O., Kuhn, M.: Design Principles for Tamper Resistant Smartcard Processors. In: The USENIX Workshop on Smartcard Technology (Smartcard 1999), pp. 9–20 (1999)

82

E. Dottax et al.

22. Naccache, D., Nguyˆen, P.Q., Tunstall, M., Whelan, C.: Experimenting with Faults, Lattices and the DSA. In: Vaudenay, S. (ed.) PKC 2005. LNCS, vol. 3386, pp. 16–28. Springer, Heidelberg (2005) 23. Piret, G., Quisquater, J.-J.: 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) 24. Shamir, A.: How to check modular exponentiation. In: Eurocrypt 1997 rump session (1997) 25. Yen, S.-M., Kim, D., Moon, S.: Cryptanalysis of Two Protocols for RSA with CRT Based on Fault Infection. In: Breveglieri, L., Koren, I., Naccache, D., Seifert, J.-P. (eds.) FDTC 2006. LNCS, vol. 4236, pp. 53–61. Springer, Heidelberg (2006) 26. Yen, S.-M., Kim, S.-J., Lim, S.-G., Moon, S.-J.: RSA Speedup with Residue Number System Immune against Hardware Fault Cryptanalysis. IEEE Transactions on Computers 52(4), 461–472 (2003)

A

An Implementation of the Lock Procedure without Conditional Branches

Let us introduce few notations. The bit-size of the checking value c is denoted by k and the radix bit-size of the microprocessor is denoted by w. The ith w-bit digit of a buffer X is denoted by X[i] and the size of the RSA modulus in radix 2w is denoted by l. Our solution makes use of a logical function M : Fk2 → Fw 2 that satisfies:  (1, 1, · · · , 1) if X = 0 M:X  → , (1) (0, 0, · · · , 0) if X  =0 For a fast implementation of M, we use a look-up table LU T of 256 w-bit words w storing the F82 → Fw 2 version of M. Namely LU T [0] = 2 − 1 and LU T [i] = 0 for every i ∈ {1, · · · , 255}. The implementation of M is described in Algorithm 10. The implementation of the Lock procedure without conditional branches is described hereafter. Algorithm 10. An implementation of function M Inputs: X ∈ Fk2 Output: M(X) ∈ Fw 2 1. Res ← 2w − 1 2. for i = 0 to k/w − 1 do 3. for j = 0 to w/8 − 1 do 4. Res ← Res ∧ LU T [(X[i]  8j) ∧ 255] 5. return Res

On Second-Order Fault Analysis Resistance for CRT-RSA Implementations Procedure 2. Lock Inputs: Res, S, c and c Process: {Res ← S} if c = c and {Res ← 0; S ← 0} otherwise 1. 2. 3. 4. 5. 6. 7.

mask ← M(c ⊕ c ) for i = 0 to l − 1 S[i] ← S[i] ∧ mask Res ← S mask ← M(c ⊕ c ) for i = 0 to l − 1 Res[i] ← Res[i] ∧ mask

83

Measurement Analysis When Benchmarking Java Card Platforms Pierre Paradinas1, Julien Cordry2 , and Samia Bouzefrane2 1

INRIA Rocquencourt 78150 Le Chesnay France [email protected] 2 CNAM 292 rue Saint-Martin 75003 Paris France [email protected]

Abstract. The advent of the Java Card standard has been a major turning point in smart card technology. With the growing acceptance of this standard, understanding the performance behaviour of these platforms is becoming crucial. To meet this need, we present in this paper, a benchmark framework that enables performance evaluation at the bytecode level. This paper focuses on the validity of our time measurements on smart cards. Keywords: Java Card, Benchmark, Performance.

1

Introduction

With more than 5 billion copies in 2008 [4], smart cards are an important device of todays information society. The development of the Java Card standard [1] made this device even more popular as it provides a secure, vendor-independent, ubiquitous Java platforms for smart cards. It shortens the time-to-market and enables programmers to develop smart card applications for a wide variety of vendors products. In this context, understanding the performance behaviour of Java Card platforms is important to the Java Card community (users, smart card manufacturers, card software providers, card users, card integrators, etc.). Currently, there is no solution on the market which makes it possible to evaluate the performance of a smart card that implements Java Card technology. In fact, the programs which realize this type of evaluations are generally proprietary and not available to the whole of the Java Card community. Hence, the only existing and published benchmarks are used within research laboratories (e.g., SCCB project from CEDRIC laboratory [9] or IBM Research [16]). However, benchmarks are important in the smart card area because they contribute in discriminating companies products, especially when the products are standardised. In this paper, we propose a general benchmarking solution through different steps that are essential for measuring the performance of the Java Card platforms. The emphasis here is towards the validation of the resulting tests in terms of accuracy and precision. O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 84–94, 2009. c IFIP International Federation for Information Processing 2009 

Measurement Analysis When Benchmarking Java Card Platforms

85

The remainder of this paper is organised as follows. In Section 2, we describe briefly some benchmarking attempts in the smart card area. In Section 3, an overview of the benchmarking framework is given. Section 4 analyses the obtained measurements using first a statistical approach, and then a precision reader before concluding the paper in Section 5.

2

Some Attempts at Measuring Java Card Performance

Currently, there is no standard benchmark suite which can be used to demonstrate the use of the JCVM and to provide metrics for comparing Java Card platforms. In fact, even if numerous benchmarks have been developed around the JVM, there are few works that attempt to evaluate the performance of smart cards. The first interesting initiative has been done by Castell` a et al. in [7] where they study the performance of micro-payment for Java Card platforms, i.e., without PKI. Even if they consider Java Card platforms from distinct manufacturers, their tests are not complete as they involve mainly computing some hash functions on a given input, including the I/O operations. A more recent and complete work has been undertaken by Erdmann in [10]. This work mentions different application domains, and makes the distinction between I/O, cryptographic functions, JCRE and energy consumption. Infineon Technologies is the only provider of the tested cards for the different application domains. The software itself is not available. The work of Fischer in [11] compares the performance results given by a Java Card applet with the results of the equivalent native application. Another interesting work has been carried out by the IBM BlueZ secure systems group and it was detailed in a Master thesis [16]. JCOP framework has been used to perform a series of tests to cover the communication overhead, DES performance and reading and writing operations into the card memory (RAM and EEPROM). Markantonakis in [13] presents some performance comparisons between the two most widely used terminal APIs, namely PC/SC and OCF. Chaumette et al. in [5,8] show the performance of a Java Card grid with respect to the scalability of the grid and with different types of cards.

3

General Benchmarking Framework

Our research work falls under the MESURE project [14], a project funded by the French administration (ANR), which aims at developing a set of open source tools to measure the performance of Java Card platforms. These benchmarking tools focus on Java Card 2.2 functionalities even if Java Card 3.0 specifications have been published since March 2008 [3], principally because until now there is no Java Card 3.0 platform in the market except some prototypes such as the one demonstrated by Gemalto during the Java One Conference in June 2008. Moreover, since Java Card 3.0 proposes two editions: connected or web oriented

86

P. Paradinas, J. Cordry, and S. Bouzefrane

edition and classic edition, our measuring tools can be reused to benchmark Java Card 3.0 classic edition platforms. Our benchmarks have been developed under the Eclipse environment based on JDK 1.6, with JSR268 [2]. The underlying ISO 7816 smart card architecture forces us to measure the time a Java Card platform takes to answer to a command APDU, and to use that measure to deduce the execution time of some operations. The set of tests are supplied to benchmark Java Card platforms available for anybody and supported by any card reader. The various tests thus have to return accurate results, even if they are not executed on precision readers. We reach this goal by removing the potential card reader weakness (in terms of delay, variance and predictability) and by controlling the noise generated by measurement equipments (the card reader and the workstation). Removing the noise added to a specific measurement is done with the computation of an average value extracted from multiple samples. As a consequence, each test is performed several times and some basic statistical calculations are used to filter the trustworthy results. The benchmarking development tool covers two parts: the script part and the applet part. The script part, entirely written in Java, defines an abstract class that is used as a template to derive test cases characterized by relevant measuring parameters such as, the operation type to measure, the number of loops, etc. A method run() is executed in each script to interact with the corresponding test case within the applet. Similarly, on the card is defined an abstract class that defines three methods: a method setUp() to perform any memory allocation needed during the lifetime test case, a method run() used to launch the tests corresponding to the test case of interest, and a method cleanUp() used after the test is done to perform any clean-up. The testing applet is capable of recognizing all the test cases and launching a particular test by executing its run method. As detailed in [6] the general benchmark framework follows different steps. The objective of the first step is to find the optimal parameters used to carry out correctly the tests. The tests cover the VM operations and the API methods. The obtained results are filtered by eliminating non-relevant measurements and values are isolated by drawing aside measurement noise. Any measurement that is outside of a confidence interval can be considered as noisy. A profiler module is used to assign a mark to each benchmark type, hence allowing us to establish a performance index for each smart card profile used. The bulk of the benchmark consists in performing time execution measurements while we send APDUs from the computer through the Card Acceptance Device (CAD) to the card. Each test (run) is performed a certain number of times (Y ) to ensure reliability of the collected execution times , and within each run method, we perform on the card a certain number of loops (L). L is coded on the byte P2 of the APDUs which are sent to the on-card applications. The size of the loop performed on the card is L = (P2)2 . As [15] details, there is a way to isolate the time performance of fractions of code as small as a bytecode. As such we can isolate the performance of a simple sadd bytecode. We designed two tests (run). For each iteration of the L

Measurement Analysis When Benchmarking Java Card Platforms

87

loops, each test calls a method. In the first of those tests (the reference test), the method called stacks up two numbers (sspush). In the second test (the operation test or, more precisely here, the sadd operation test), the method stacks up the two same numbers and performs a sadd (short addition). The difference of time performances between those two tests divided by L should give us the isolated time performance of a single sadd. The sadd bytecode is a simple one, but there is primarily a need to validate our measurement method. Indeed, we need to know if our concept of measuring the performance of a smart card from the outside and isolating the performance of a single operation (bytecodes, and APIs entries) is valid.

4 4.1

Validation of the Tests Statistical Correctness of the Measurements

The expected distribution of any measurement is a normal distribution. According to Lilja [12], the arithmetic mean is an acceptable representative value for any given set of normally distributed time measurements (Lilja recommands at least 30 measurements). Nevertheless, Rehioui [16] pointed out that the results obtained via methods similar to ours were not normally distributed on IBM JCOP41 cards. Erdmann [10] cited similar problems with Infineon smart cards. When measuring both the reference test and the operation test on several smart cards by different providers using different CADs (Cherry ST-1044U, FSC Smartcard-Reader USB 2A, GemPC Twin, Omnikey Cardman 2020, Omnikey Cardman 4040, Towitoko Chipdrive Micro, Xiring Teo), different host machines (with CPUs AMD Sempron 3100+, AMD X2 3800+, Intel Core2 Quad CPU Q9400), different OSs (Linux, Windows XP, Windows Vista), none of the time performances had a normal distribution (see figure 1 for a sample reference test performed on a card). The results were similar from one card to another in terms of distribution, even for different time values, and for different loop sizes. Changes in CAD, in host-side JVM, in task priority made no difference on the experimental distribution curve. Testing the cards on Linux and on Windows XP or Windows Vista, on the other side, showed differences. Indeed, the recuring factor when measuring the performances with a terminal running Linux with PC/SC Lite and a CCID driver is the gap between peaks of distribution. The figure 1 shows the time values obtained for a set of performed measurements. The peaks are often separated by 400ms and 100 ms steps which match some parts of the public code of PC/SC Lite and the CCID driver (see figure 2). With other CADs, the distribution shows similar steps with respect to the CAD driver source code. The peaks in the distribution from the measurements obtained on Windows are separated by 0.2 ms steps (see figure 4). Without having access to neither the source code of the PC/SC implementation on Windows nor the driver source codes, we can deduce that there must be some similarities in the source codes between the proprietary versions and the open source versions.

88

P. Paradinas, J. Cordry, and S. Bouzefrane

Fig. 1. Measurements of a reference test as the tests proceed under Linux, and the corresponding distribution curve L = 412

Measurement Analysis When Benchmarking Java Card Platforms

89

pcscd.h:#define PCSCLITE_LOCK_POLL_RATE 100000 pcscd.h:#define PCSCLITE_STATUS_POLL_RATE 400000 winscard.c:SYS_USleep(PCSCLITE_LOCK_POLL_RATE); winscard_clnt.c:SYS_USleep(PCSCLITE_STATUS_POLL_RATE + 10); Fig. 2. Some lines from the PC/SC Lite and CCID driver source codes

Fig. 3. Distribution of the measurement of a reference test : close up look at a peak in distribution L = 412

In order to check the normality of the results, we isolated some of the peaks of the distributions obtained with our measurements (see figure 3). The ShapiroWilk test is a well established statistical test used to verify the null hypothesis that a sample of data comes from a normally distributed population [17]. The result of such a test is a number W ∈ [0, 1], with W close to 1 when the data is normally distributed. No set of value obtained by isolating a peak within a distribution gave us a satisfying W close to 1. For instance, considering the peak in figure 3, W = 0.8442, which is the highest value for W that we

90

P. Paradinas, J. Cordry, and S. Bouzefrane

Fig. 4. Distribution of sadd operation measurements using Windows Vista, and a close up look at the distribution (L = 902 )

Measurement Analysis When Benchmarking Java Card Platforms

91

Fig. 5. Comparison between the sadd operation measurements and the corresponding reference measurements (L = 412 )

observed, with other values ranging as low as W = 0.1384. We conclude that the measurements we obtain, even if we consider a peak of distribution, are not normally distributed. Rehioui [16] proposed an algorithm to locate the highest peak in a distribution to take the value of that peak as the correct measured value. However the algorithm does not literally try to locate the highest peak in the distribution curve, but, with each iteration of the algorithm, it removes the measurements that are to far away from the arithmetic mean of the measurements. The algorithm stops after several such iterations. We should be left with a certain percentage of the initial number of measurements. That particular percentage is determined by the user of the benchmark framework. This algorithm is nevertheless futile when it comes to trying to determine the correct time performance value with a “comb” like distribution (see figure 4), or if the highest peak is relatively far from the mean (which would suggest that we have several other smaller peaks on the other side of the mean).

92

P. Paradinas, J. Cordry, and S. Bouzefrane

But what we are interested in is not exactly the raw measurement of the reference test and the operation test, but the differences between the operation measurements and the reference measurements. Figure 5 shows two curves. The upper curve shows the time values obtained for a sadd operation test, while the lower curve shows the time values for the corresponding reference test. As we can see, each curve is subject to changes due to the non normal distribution of their respective measurements (that is, noises on the test platform). So it is difficult for us to choose the appropriate time value representing each curve. There is nevertheless a time difference between the two curves that is bigger than those variations. That is due to the execution of the supplementary sadd byte code in each iteration of the loop. For a sufficiently large loop size, the difference between those two curves is large enough so that it dwarfs the importance of those variations. Indeed, the supplementary bytecode is then performed a sufficiently large amount of times, so that it can have a large impact on the time performances. So even though we don’t have access to a set of normally distributed time values, for a given large loop size, the measurements could be accurate. 4.2

Validation through a Precision CAD

We used a Micropross MP300 TC1 reader to verify the accuracy of our measurements. This is a smart card test platform, that is designed specifically to give accurate results, most particularly in terms of time analysis. The results here are seemingly unaffected by noises on the host machine. With this test platform, we can precisely monitor the polarity changes on the contact of the smart card, that mark the I/Os. We measured the time needed by a given smart card to reply to the same APDUs that we used with a regular CAD. We then tested the measured time values using the Shapiro-Wilk test, we observed W ≥ 0.96, much closer to what we expected in the first place. So we can assume that the values are normally distributed for both the operation measurement and the reference measurement. We subtracted each reference measurement value from each sadd operation measurement value, divided by the loop size to get a time values set that represents the time performance of an isolated sadd bytecode. Those new time values are normally distributed as well (W = 0.9522). On the resulting time value set, the arithmetic mean is 10611.57 ns and the standard deviation is 16.19524. According to [12], since we are dealing with a normal distribution, this arithmetic mean is an appropriate evaluation of the time needed to perform a sadd bytecode on this smart card. Using a more traditional CAD (here, a Cardmann 4040, but we tried five different CADs) we performed 1000 measurements of the sadd operation test and 1000 measurements of the corresponding reference test. By subtracting each value obtained with the reference test from each of the values of the sadd operation test, and dividing by the loop size, we produced a new set of 1000000 time values. The new set of time values has an arithmetic mean of 10260.65 ns and a standard deviation of 52.46025.

Measurement Analysis When Benchmarking Java Card Platforms

93

The value we found with a regular CAD under Linux and without priority modification is just 3.42% away from the more accurate value found with the precision reader. Although this is a set of measurements that are not normally distributed (W = 0.2432), the arithmetic mean of our experimental noisy measurements seems to be a good approximation of the actual time it takes for this smart card to perform a sadd. The same test under Windows Vista gave us a mean time of 11380.83 ns with a standard deviation of 100.7473, that is 7,24% away from the accurate value. In conclusion, our data are noisy and faulty but despite a potentially very noisy test environment, our time measurements always provide a certain accuracy and a certain precision.

5

Conclusion

With the wide use of Java in smart card technology, there is a need to evaluate the performance and characteristics of these platforms in order to ascertain whether they fit the requirements of the different application domains. For the time being, there is no other open source benchmark solution for Java Card. The objective of our project [14] is to satisfy this need by providing a set of freely available tools, which, in the long term, will be used as a benchmark standard. In this paper, we have focused on the validation of our time isolation technique. Despite the noise, our framework achieves some degree of accuracy and precision. Besides the portability of the benchmarking framework, this means that evaluating appropriately the performance of a smart card does not necessarily require a costly reader. Java Card 3.0 is a new step forward for this community. Our framework should still be relevant to the classic edition of this platform, but we have yet to test it.

References 1. 2. 3. 4. 5.

6.

7.

8.

Java Card 2.2.2 Specification (April 2006) JSR 268: Java Smart Card I/O API (December 2006) Java Card 3.0 Specification (March 2008) Arlot, P.: Le march´e de la carte ` a puce ne connait pas la crise. Technical report, Electronique international (2008) Atallah, E., Darrigade, F., Chaumette, S., Karray, A., Sauveron, D.: A grid of Java Cards to deal with security demanding application domains. In: 6th edn. e-Smart conference & demos (September 2005); Sophia Antipolis, French Riviera Bouzefrane, S., Cordry, J., Meunier, H., Paradinas, P.: Evaluation of java card performance. In: Grimaud, G., Standaert, F.-X. (eds.) CARDIS 2008. LNCS, vol. 5189, pp. 228–240. Springer, Heidelberg (2008) Castell` a-Roca, J., Domingo-Ferrer, J., Herrera-Joancomati, J., Planes, J.: A performance comparison of Java Cards for micropayment implementation. In: CARDIS, pp. 19–38 (2000) Chaumette, S., Sauveron, D.: Some security problems raised by open multiapplication smart cards. In: 10th Nordic Workshop on Secure IT-systems: NordSec 2005 (October 2005)

94

P. Paradinas, J. Cordry, and S. Bouzefrane

9. Douin, J.-M., Paradinas, P., Pradel, C.: Open Benchmark for Java Card Technology. In: e-Smart Conference (September 2004) 10. Erdmannn, M.: Benchmarking von Java Cards. Master’s thesis, Institut f¨ ur Informatik der Ludwig-Maximilians-Universit¨ at M¨ unchen (2004) 11. Fischer, M.: Vergleich von Java und native-chipkarten toolchains, benchmarking, messumgebung. Master’s thesis, Institut f¨ ur Informatik der Ludwig-MaximiliansUniversit¨ at M¨ unchen (2006) 12. Lilja, D.J.: Measuring Computer Performance: A Practitioner’s Guide. Cambridge University Press, Cambridge (2000) 13. Markantonakis, C.: Is the performance of smart card cryptographic functions the real bottleneck? In: 16th international conference on Information security: Trusted information: the new decade challenge, vol. 193, pp. 77–91. Kluwer, Dordrecht (2001) 14. The MESURE project website, http://mesure.gforge.inria.fr 15. Paradinas, P., Bouzefrane, S., Cordry, J.: Performance evaluation of java card bytecodes. In: Sauveron, D., Markantonakis, K., Bilas, A., Quisquater, J.-J. (eds.) WISTP 2007. LNCS, vol. 4462, pp. 127–137. Springer, Heidelberg (2007) 16. Rehioui, K.: Java Card Performance Test Framework, Universit´e de Nice, SophiaAntipolis, IBM Research internship (September 2005) 17. Shapiro, S.S., Wilk, M.B.: An analysis of variance test for normality (complete samples). Biometrika 52(3, 4), 591–611 (1965)

Performance Issues of Selective Disclosure and Blinded Issuing Protocols on Java Card Hendrik Tews and Bart Jacobs Digital Security Group, Radboud Universiteit Nijmegen, The Netherlands http://www.cs.ru.nl/~tews,~bart

Abstract. In this paper we report on the performance of the RSA variants of Brands protocols for zero-knowledge proof and restrictive blinded issuing [1]. The performance is relatively bad: For 4 attributes and an RSA key size of 1280 bits, blinded issuing takes about 10 seconds and the zero-knowledge proof takes about 9 seconds. For 2 attributes the zero-knowledge proof drops to 5 seconds. The poor performance comes from the fact that the cryptographic coprocessor on the Java card can only be employed in very limited ways. With appropriate support of the cryptographic coprocessor both protocols would run much faster. Keywords: Java performance.

1

Card,

selective

disclosure,

blinded

issuing,

Introduction

This paper has a (partly) negative message: it shows that certain desirable things cannot be done, . . . currently. In particular, it shows, via various performance measurements, that the current generation of Java cards is unsuitable for advanced cryptographic protocols, such as privacy-friendly selective disclosure of attributes, via zero-knowledge proofs. The simple reason is that current cards are too slow. The more subtle reason is that the Java-Card API does not permit access to the (fast!) cryptographic primitive operations on the cryptographic coprocessor. The hope that a clear exposition of this problem will contribute to a solution in the near future is an important motivation for writing this paper. The emergence of severe vulnerabilities in the Mifare Classic chip card [4,11,5], which is heavily used in public transport (like London’s Oyster, or the Dutch OV-chipkaart), has led to renewed interest in smart cards for public transport. The current generation of cards is identity-based: – cards have a fixed UID in anti-collision that allows tracing of individuals, also outside the context of public transport, since this UID can be picked up by any reader; 

Sponsored by the NLnet foundation through the OV-chipkaart project.

O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 95–111, 2009. c IFIP International Federation for Information Processing 2009 

96

H. Tews and B. Jacobs

– cards have a fixed (application level) identity that is used in every transaction, enabling detailed travel logging and profiling of individuals (with a personalized card).

There is a desire, at least in certain communities, to move to more privacyfriendly mechanisms, based for instance on attributes instead of identities. After all, in most cases there is no compelling reason why you should tell who you are upon entering a bus; possession of a valid travel attribute should be sufficient. Advanced cryptographic protocols have been developed for such attribute-based access control, such as [1] based on zero-knowledge and blind signatures or [13] based on bilinear pairings on elliptic curves. In this paper we evaluate the approach of Stefan Brands [1] via a prototype implementation on Java Card. We focus on two of the crucial protocols, namely for selective disclosure of attributes and for blinded issuing of a signed attribute expression on currently publicly available Java cards. This is part of a project that is informally called “OV-chip 2.0”. As Brands suggested, we combine the RSA variants of his proof of knowledge protocol with his protocol for blinded issuing. We equip the protocols with the necessary code for initialization and key generation and implement everything in a Java-Card applet and an appropriate host-driver application. The host driver runs on a normal PC and talks to a Java card through a CCID compliant smart-card reader. The host driver can install the applet, download the key material and personalize the applet, run the protocols, and, of course, measure their execution time. We actually implemented two versions of the applet. The first one, the coprocessor-enabled applet, performs the computations as far as possible on the cryptographic coprocessor of the Java card. The second one, the pure Java-Card applet, computes everything on the virtual machine of the Java card. The host driver can talk to both applets. The pure Java-Card applet is, of course, very very slow. It is only discussed here to provide an impression about the speedup of the cryptographic coprocessor. However, also the coprocessor-enabled applet is not as fast as we wished. For 4 attributes and an RSA key size of 1280 bits, blinded issuing takes about 10 seconds and the zero-knowledge proof takes about 9 seconds on the coprocessorenabled applet. When using only 2 attributes the zero-knowledge proof takes about 5 seconds. The main performance limitation is the Java-Card API (together with the provided security of Java cards) that permits no adequate access to the cryptographic coprocessor. We analyze the problems that lead to this unexpectedly bad performance in more detail in Section 2 and Section 3. To achieve better performance for Brands protocols one needs access to the native (assembly) methods for standard and modular multiplication, modular exponentiation and for division that fully exploit the cryptographic coprocessor on the card. For using elliptic curves with the discrete log (DL) variants of Brands protocol one would need access to native methods for point addition and scalar point multiplication. Even the current Java Card 3.0 draft does not specify any of these methods although any card with support for RSA and elliptic curves does

Performance Issues of Selective Disclosure Protocols

97

contain such methods. With adequate access to the cryptographic coprocessor Brands protocols would probably run in about 1 second. Our implementation is based on the Bignat library, a newly developed library for big natural numbers on Java Card. The implementation further exploits the Java-Card protocol layer for the communication between the applet and the host driver. The Java-Card protocol layer is a custom layer for remote method invocation on Java cards that supports methods with an arbitrary number of arguments and results of up to 32 KByte in size. The complete sources are available for download from https://ovchip.cs.ru.nl/OV-chip_2.0 with one exception: Because of Brands patents on his protocols the few methods that implement the protocol for the two applets and the host driver are missing from the distribution.1 The protocol is however fully described in [1] and in Appendix B of this paper so that it should be not too difficult to get the applets running for research purposes. This paper is structured as follows. Section 2 gives insight into the Java-Card API and explains why currently any implementation of Brands protocols on Java cards will have to fight with performance problems. Section 3 presents our Bignat library for operations on big integers on Java Card. Section 4 describes the protocols that we implemented and presents our performance measurements. In Section 5 we shortly discuss elliptic curves and Section 6 concludes. Appendix A shortly introduces Montgomery multiplication, because it is mentioned very often in this paper. The Appendix B contains the technical description of the implemented protocols, similar to the descriptions in [1] but with adoptions for our implementation.

2

Performance Limitation in the Java-Card API

The performance critical part in the RSA variants of Brands protocols are expressions of the form (g1a1 · · · gkak ) mod n, which we call modular multi-powers in the sequel. Such a modular multi-power encodes the attributes a1 , . . . , an of the card as numbers and its blinding in a blinded attribute expression. The length of the bases, exponents and the modulus determine the security level. A modulus n and bases bi of 1280 bits and exponents ai of 160 bits provide reasonable security over the next few years. Apart from the modular multi-powers one also needs multiplication, modular multiplication, addition, division and modulus on big natural numbers. Current Java cards are equipped with a cryptographic coprocessor and a suitable native (assembly) library that can perform these operations in a reasonably fast way. For instance, RSA public key encryption takes only 120 milliseconds for a RSA key and a cipher text of 1280 bits and a public exponent of 200 bits. This leads to speculated 0.3 milliseconds for one modular multiplication of 1280 bit numbers. However, Java-Card applets can only use the public Java-Card API [8,9] and extending this API with new native (assembly) methods is not 1

The current patent owner is Microsoft. Microsoft lawyers are still pondering our request from January 2009 to permit the distribution of the complete sources.

98

H. Tews and B. Jacobs

permitted. The current Java-Card API version 2.2.2 [9] gives very limited access to the cryptographic coprocessor in class BigNumber in the optional package javacardx.framework.math. This class contains multiplication and addition, but no modular multiplication, no division or even modular exponentiation. It appears that almost no cards are available that implement version 2.2.2 of the Java-Card API. Until now we only found two such cards: The Athena IDProtect2 and a recent JCOP31 card from NXP. Both do not support the optional package javacardx.framework.math. The older API version 2.2.1 [8], which is implemented by most of the currently available cards, does neither contain the package javacardx.framework.math nor the BigNumber class. Without direct access to the cryptographic coprocessor the only remaining possibility is to trick one of the high-level cryptographic methods into performing, for instance, a modular multiplication or a modular exponentiation. Current Java cards provide a number of such high-level methods that perform big-integer calculations internally, for instance for RSA (encryption, decryption and key generation), Diffie-Hellman key exchange and DSA. However, internally most of these high-level methods use random padding or randomly generated arguments, which cannot be controlled from the API level. These random ingredients are essential for the security of those methods, but they make it impossible to turn them into a big-integer operation. We only found one exception: The ALG_RSA_NOPAD cipher algorithm contains no random padding and can be used to compute a modular power g a mod n. There are some restrictions on the arguments, but one can easily work around them. Our NXP JCOP cards, for instance, only support moduli between 64 and 244 bytes. The modulus must further have a first non-zero byte and a length (in bytes) that is divisible by 4. As a further peculiarity an exponent of 0 yields 0 as cipher text, that is, x0 = 0 when using the RSA cipher. With an exponent of 1 the RSA_NOPAD cipher can be used to compute a modulus g mod n. This is, however, not very useful, because g cannot be longer than n (in bytes) and for such numbers a simple schoolbook division achieves the same performance. On currently available Java cards it is impossible to directly use the cryptographic coprocessor for multiplication, modular multiplication or division of big integers. 2 2 −b2 It took us a some time to remember that ab = (a+b) −a . For odd mod2 uli this equation can actually be turned into a method for computing modular products. This method will be called squaring multiplication in the following. For one modular product squaring multiplication needs to do 3 modular squares, 2 subtractions, 1 right shift and 1 to 4 additions. The number of additions varies, because, for instance, (a + b)2 mod n might be smaller than a2 mod n and in this case ((a + b)2 − a2 ) mod n = ((a + b)2 mod n) − (a2 mod n) + n. On Java cards squaring multiplication gives a big speedup, because the squares can be computed on the cryptographic coprocessor with the help of the RSA cipher. For instance for numbers of 1280 bits, one square costs only 14 milliseconds, while one addition, which must be done on the Java virtual machine of the card, 2

See http://www.athena-scs.com

Performance Issues of Selective Disclosure Protocols

99

costs 75 milliseconds. Montgomery multiplication, which must also run on the Java virtual machine of the card, requires 320 additions for numbers of 1280 bits and takes about 25 seconds. A squaring multiplication for such numbers costs only between 350 and 580 milliseconds. The RSA cipher on Java Card computes only modular exponents. But if one chooses a modulus n > (a + b)2 then one can use squaring multiplication also to compute a normal (non-modular) product ab. We can conclude here that the Java-Card API does not facilitate the implementation of advanced cryptographic protocols, because the API does not give access to the fast big-integer operations that are available on the card. Without support from the cryptographic coprocessor one is forced to implement the missing operations in Java using bytes and shorts (as there are usually no 32 bit integers on a Java card). With the overhead of the Java Virtual Machine added on top of the limited execution speed of the main processor this will almost certainly yield an unacceptable performance. As things stand, the situation is not likely to improve much, because the current draft of the Java-Card specification for upcoming Java Card 3.0 [10] does not contain any additions to the BigNumber class that is already present in version 2.2.2. So even if some future cards implement the relevant optional package, one still has to implement division and addition in the Java Virtual Machine. With the trick of squaring multiplication, the cryptographic coprocessor can speed up multiplication and modular multiplication but a multiplication directly on the coprocessor would probably still be about 100 times faster than our squaring multiplication method. One aim of this paper is to draw attention to the limitations of the Java Card API for advanced cryptographic protocols and to motivate the Java-Card community in general and the card producers in particular to allow access to basic cryptographic operations on the coprocessor via extensions of the Java-Card API. The paper illustrates the need for such extensions for the next generation of (privacy-friendly) smart card applications.

3

Bignat: A Big-Integer Library for Java Card

The limitations of the Java-Card API force us to perform some computations in a big-integer library on Java Card. We decided to implement such a library from scratch, for the following reasons. Although different big-integer libraries have been developed in the past in different projects [2,3], no such library is currently publicly available. As [2,3] already point out, porting an existing big-integer library does not make much sense because of the limitations of Java Card. The absence of a garbage collector, for instance, enforces a completely different Java programming style, in which all allocations are performed at applet initialization time and temporary objects appear in the interface of those methods that need them. We further believe that a library interface tailored towards the application can improve the performance. For Brands protocols, for instance, the bases gi in a blinded attribute expression (g1a1 · · · gkak ) mod n are constant, which makes special optimizations possible.

100

H. Tews and B. Jacobs Different multiplications for short numbers 1 montgomery normal squaring

time in sec

0.8 0.6 0.4 0.2 0 64

128

192 256 320 number size in bits

384

448

512

Squaring multiplication squaring multiplication

1

time in sec

0.8 0.6 0.4 0.2 0 512

768

1024

1280

1536

1792

2048

number size in bits

Fig. 1. Performance of multiplication. The top chart compares Montgomery, schoolbook, and squaring multiplication for short numbers. Squaring multiplication is fastest from about 92 bits. The bottom chart displays the performance of squaring multiplication for large numbers. One can clearly recognize the different number of additions that were necessary for the randomly chosen parameters. All measurements were done over the contact interface of the card.

Our library implements natural numbers of arbitrary but fixed size that must be specified at object creation time. The numbers are mutable; for many operations the result is stored in the object on which the operation is invoked. If this object is not big enough to hold the result, an exception is thrown. The library implements addition, subtraction, multiplication and division with their schoolbook algorithms. The Bignat library additionally implements Montgomery multiplication (see Appendix A) and squaring multiplication, which are both modular multiplications. Squaring multiplication employs the cryptographic coprocessor of the card via the RSA_NOPAD cipher. Figure 1 shows the performance of these different multiplication methods. Montgomery multiplication has a quadratic complexity, its computation time rises from 4.1 seconds for 512 bit numbers over

Performance Issues of Selective Disclosure Protocols

101

RSA modular power 240 encrypt only modPow exponent

time in sec

0.3

180

0.2

120

0.1

60

exponent size in bit

0.4

0 512

768

1024 1280 1536 1792 2048 base size in bits

Fig. 2. Performance of computing exponents on the cryptographic coprocessor (contact interface only). Cipher and key initialization has a significant overhead over the pure encryption time. The exponent length depends on the base length and is displayed on the right y-axis.

25 seconds for 1280 bit to 64 seconds for 2048 bit numbers. As the bottom chart in Figure 1 shows, squaring multiplication is much faster. However, from the RSA encryption performance we estimate that a 1280 bit multiplication performed directly on the cryptographic coprocessor would only take 0.3 milliseconds. The Bignat library contains a wrapper method for accessing the cryptographic coprocessor via the RSA cipher for computing modular powers. The wrapper works around known problems, for instance, it correctly computes x0 = 1. Figure 2 shows the performance of this method for computing modular powers. For the measurements the size of the exponent was chosen such that it provides similar security for Brands protocols as an RSA modulus of the same size as the bases. The security level of the RSA modulus is thereby estimated following Lenstra [6]. The exponents we use grow from 94 bits for bases of 512 bits to 198 bits for bases of 1952 bits. In Figure 2 the third line displays the exponent length against the right y-axis. For modular multi-powers (g1a1 · · · gkak ) mod n the Bignat library contains two specialized methods: the RSA multi-power method that uses the cryptographic coprocessor as much as possible and the simultaneous squaring multi-power method that computes the result entirely without the cryptographic coprocessor. The RSA multi-power method computes the single modular exponents giai mod n with the RSA cipher of the card and multiplies the results with squaring multiplication. Figure 3 displays the performance of this method for computing a multi power with 4 bases (i.e., k = 4). The subtractions and additions inside squaring multiplication are responsible for a significant part of the computation time. Counting subtractions as additions, the computation of one multi-power consists of 9–18 additions, which costs between 0.6 and 1.3 seconds for 1280 bit numbers.

102

H. Tews and B. Jacobs

280

6

240

5

200

4

160

3

120

2

80 wired wireless exponent

1 0

exponent size in bits

time in seconds

RSA multi-power (4 bases) 7

40 0

512

768 1024 1280 1536 1792 2048 base number size in bits

Fig. 3. Performance of the RSA method to compute modular multi powers. The first computation for any base size takes much longer and is partly outside the chart. For unknown reasons the computation takes longer over the wireless interface. The exponent length is displayed on the right y-axis as before.

simultaneous squaring multi-power 35 wired wireless exponent

120

25 20

80

15 10

40

exponent size in bit

time in minutes

30

5 0

0 128

256 384 512 640 base number size in bits

Fig. 4. Performance of the simultaneous squaring multi-power method. Note that the left y-axis displays minutes. The measurement has been manually stopped after the running time exceeded 30 minutes. The exponent length is displayed on the right yaxis as before.

The simultaneous squaring multi-power method uses the simultaneous squaring method on the basis of Montgomery multiplication. It takes advantage of the fact that for Brands protocols the bases gi are constant and uses a precomputed table of all possible products of the bases gi . Therefore it only needs about 2|a| Montgomery multiplications, where |a| denotes the maximal size of the exponents ai in bits. The simultaneous squaring method requires that all bases and also the precomputed table of factors are provided in Montgomery

Performance Issues of Selective Disclosure Protocols

103

representation. Figure 4 shows the performance of the simultaneous squaring multi-power method. It is clear that on Java Card the simultaneous squaring multi-power method has mostly anecdotic value. We only discuss it here for two reasons. Firstly, it provides an impression of the performance benefits of the cryptographic coprocessor on Java Card. Secondly, an implementation based on the simultaneous squaring multi-power method can easily ported to a platform without cryptographic coprocessor support, such as a smart phone.

4

Implemented Protocols and Their Performance

In this section we describe in somewhat more detail the protocols that we implemented and show their performance on current Java cards. For reasons of space the precise technical description of the protocols has been moved to Appendix B. We actually implemented two applets, the coprocessor-enabled applet and the pure Java-Card applet. The same host driver is used to control both applets. The coprocessor-enabled applet uses internally the RSA multi-power method while the pure Java-Card applet uses the simultaneous squaring multi-power method. The pure Java-Card applet is only shown here for the comparison. Both applets are functionally equivalent. They hold k attributes a1 , . . . , ak that could encode the card type (e.g., whether it is a month card or a reduction card), the expiration date, possibly a balance, and so on. One of the attributes is the private key of the applet, which will never be disclosed to anybody. From the attributes the applet computes its blinded attribute expression A = bv g1a1 · · · gkak mod n, where the bases gi , the RSA modulus n and the public RSA exponent v are public system parameters. The b is a blinding factor that is private to the applet and that ensures that the attribute expression A does not function as a pseudonym. To ensure that the attributes are original the whole attribute expression A is signed. The signature is constructed in such a way that the signing authority does not see the resulting signature and therefore cannot use the signature to recognize the applet later. In our implementation one can configure the number of attributes k and the size of the RSA modulus n and the size of the public RSA exponent v at initialization time. A modulus of 1280 bits and an exponent of 160 bits are sufficient to ensure security over the next few years. Together the host driver and each of the applets implement the following protocols (for a complete technical description of the protocols see Appendix B): Key Setup and Initialization. The host driver generate the keys, the bases g1 , . . . , gk and chooses the first attributes a1 , . . . , ak of the applet. The key material, the bases and the attributes are installed in the applet and the applet computes its first attribute expression A. As last part of the initialization the resign protocol is run to let the applet change its blinding b and to equip it with a valid signature. Resign Protocol. The applet shows its blinded attribute expression A and the signature and the host driver checks the validity of the signature (this check is of course left out if resigning runs as part of the initialization). The

104

H. Tews and B. Jacobs

host driver can then change selected attributes (for instance to change the expiration date) and the applet chooses a new blinding b. Finally the applet obtains a new signature for the changed blinded attribute expression. Gate Protocol. The applet shows its blinded attribute expression A and the signature, which is checked by the host as in the resign protocol. The applet then proves with a zero-knowledge proof that it knows suitable attributes a1 , . . . , ak that give rise to A. Thereby the host learns nothing about the attributes. A feature currently missing is the partial disclosure of some attributes. For instance, at the gate the card would disclose its card type and claim that the expiration date lays in the future. Coprocessor enabled applet resign 4 attr gate 4 attr resign 2 attr gate 2 attr

time in seconds

15

10

5

512

768

1024 1280 1536 RSA key size in bits

1792

2048

Pure Java-Card applet (4 attributes) 75

time in minutes

60

resign gate

45 30 15

64

128

192 256 320 384 RSA key size in bits

448

512

Fig. 5. Performance of the two applets. Note that y-axis of the top chart is in seconds, while for the bottom chart it is in minutes. Timings are complete transaction times over the wired interface, that is, including the computation of the host driver, the communication time, and, of course, the computation of the applet. The coprocessor enabled applet only supports key sizes between 64 and 244 bytes, because the RSA cipher on our cards only supports these key sizes. The measurement for the pure JavaCard applet has been stopped after the key size 512.

Performance Issues of Selective Disclosure Protocols

105

Figure 5 shows the transaction times for the complete system, using either the coprocessor enabled or the pure Java-Card applet. For 4 attributes and a RSA key size of 1280 bits and a public RSA exponent of 160 bits the resign protocol takes between 10 and 11 seconds and the gate protocol between 8 and 9 seconds (the lines in Figure 5 show the average of a number of measurements). For 2 attributes resigning takes between 8 and 9 seconds and the gate protocol between 5.2 and 5.8 seconds. The applet is therefore probably too slow for public transport and most other applications. However, the performance of the coprocessor enabled applet shows that with proper support from a cryptographic coprocessor Brands protocols could already be used today on Java cards. With an appropriate API for the coprocessor we estimate that transaction times of about 1 second are possible for currently available Java cards.

5

Variants Based on Elliptic Curves

Brands protocols for selective disclosure and blinded issuing do also exist in a discrete log (DL) variant. This variant can be implemented on the basis of elliptic curves [12]. The main advantage of elliptic curves is that they permit much smaller key sizes—keys of 150–200 bit would be sufficient. Therefore the numbers that one has to manipulate for the DL variant are much smaller: 150–200 bits instead of 1200–2000 bits as for the RSA variants. The disadvantage is that the base operation on elliptic curves —addition of two points— is much more involved. Although many Java cards implement cryptographic protocols based on elliptic curves, there is no support for adding points of an elliptic curve in the Java-Card API. There are two high-level elliptic curve related methods in the Java-Card API: ECDSA, the digital signature algorithm over elliptic curves and ECDH, Diffie-Hellman key agreement over elliptic curves. ECDSA specifies some random padding, so it cannot be used to perform addition or scalar multiplication of points. It should be possible to trick the Diffie-Hellman algorithm into performing a scalar multiplication of an elliptic-curve point. However, a point of an elliptic curve has two coordinates and the Diffie-Hellman key agreement on Java Card only returns the x-coordinate. This could suffice for those protocols that just do one scalar multiplication at the end, because then the missing ycoordinate can be reconstructed on the host. For Brands protocols, however, one would have to reconstruct the missing y-coordinate on the card. As this involves a square root we are very sceptical about the performance benefits of exploiting the Diffie-Hellman key agreement. We have not done any experiments yet, but we expect that Brands DL variants would actually be slower than our coprocessor enabled applet. We expect that the disadvantage of the missing coprocessor support outweighs the advantage of shorter keys.

6

Conclusion

In this paper we evaluated the performance of Brands selective disclosure and blinded issuing protocols on currently publicly available Java cards. The

106

H. Tews and B. Jacobs

performance is not sufficient for most applications. A zero-knowledge proof for 4 attributes takes about 9 seconds, while blinded issuing takes about 10 seconds for an RSA key size of 1280 bits. For two attributes the zero-knowledge proof takes about 5 seconds for the same RSA key size. Limitations in the Java-Card API for accessing the cryptographic coprocessor are solely responsible for the bad performance. While we found a way to compute modular powers g a mod n on the coprocessor by abusing RSA public key encryption, there is no direct way to execute a modular big-integer multiplication on the coprocessor. Montgomery multiplication executed on the Java Card Virtual machine takes 25 seconds for 1280 bit numbers. The familiar equation (a + b)2 = a2 + 2ab + b2 can be used to dramatically speed up the computation of a modular product because the squares can be computed on the cryptographic coprocessor. With this trick one modular multiplication takes between 0.3 and 0.6 seconds for numbers of 1280 bits. In contrast, we estimate that a modular multiplication directly on the cryptographic coprocessor would only take about 0.3 milliseconds for numbers of this size. We believe that, with appropriate support in the API, running times in the order of 1 second are possible. To facilitate the development and use of new cryptographic protocols the Java-Card API should as soon as possible be enriched with at least two optional classes. One for the basic big-integer operations that are missing from javacards.framework.math.BigNumber: modular multiplication, modular addition, division, modulus, modular powers, and modular inverse. The second class should contain addition and scalar multiplication of points on elliptic curves. Note that all these operations are already implemented on most cards, so it is only a question of exporting them to the Java-Card API. Acknowledgements. We are grateful to Wojciech Mostowski for his help and his insights on Java-Card programming.

References 1. Brands, S.: Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy. MIT Press, Cambridge (2000), www.credentica.com 2. Dowling, T., Duffy, A.: Java card key generation for identity based systems. Technical Report NUIM-CS-TR-2005-01, Department of Computer Science, National University of Ireland, Maynooth (February 2005), http://www.cs.nuim.ie/research/reports/2005 3. Elo, T., Nikander, P.: Decentralized authorization with ECDSA on a Java smart card. In: Proceedings of the fourth working conference on smart card research and advanced applications on Smart card research and advanced applications, Norwell, MA, USA, pp. 345–364. Kluwer Academic Publishers, Dordrecht (2001) 4. Garcia, F., de Koning Gans, G., Muijrers, R., van Rossum, P., Verdult, R., Schreur, R.W., Jacobs, B.: Dismantling MIFARE classic. In: Jajodia, S., Lopez, J. (eds.) ESORICS 2008. LNCS, vol. 5283, pp. 97–114. Springer, Heidelberg (2008)

Performance Issues of Selective Disclosure Protocols

107

5. Garcia, F.D., van Rossum, P., Verdult, R., Schreur, R.W.: Wirelessly pickpocketing a Mifare Classic card. In: IEEE Symposium on Security and Privacy (S&P 2009), pp. 3–15. IEEE, Los Alamitos (2009) 6. Lenstra, A.: Key lengths. In: Bidgoli, H. (ed.) Handbook of Information Security. Information Warfare, Social, Legal, and International Issues and Security Foundations, vol. II, pp. 617–635. Wiley, Chichester (2006) 7. Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC Press, Boca Raton (2001) 8. SUN Microsystems. Java Card v2.2.1 API (2003), http://java.sun.com/javacard/specs.html 9. SUN Microsystems. Java Card v2.2.2 API (2005), http://java.sun.com/javacard/specs.html 10. SUN Microsystems. Java Card Specifications Version 3.0 (2008), http://java.sun.com/javacard/downloads/ 11. Nohl, K., Evans, D., Starbug, S., Pl¨ otz, H.: Reverse-engineering a cryptographic RFID tag. In: 17th USENIX Security Symposium, San Jose, CA, USA, pp. 185–194 (2004) 12. Smart, N.P.: Elliptic curve based protocols. In: Blake, I.F., Seroussi, G., Smart, N.P. (eds.) Advances in Elliptic Curve Cryptography. LMS, vol. 317, pp. 3–19. Cambridge Univ. Press, Cambridge (2005) 13. Verheul, E.R.: Self-blindable credential certificates from the weil pairing. In: Boyd, C. (ed.) ASIACRYPT 2001. LNCS, vol. 2248, pp. 533–550. Springer, Heidelberg (2001)

Appendix A

Montgomery Multiplication

This appendix briefly describes Montgomery multiplication as used in our implementation, see [7, Algorithm 14.36] for a more general description. For clarity we use − · − to denote standard multiplication.   Let n be an odd modulus and l = |n| be the number of bytes it occupies. 8 The Montgomery factor R with respect to n is then defined as R = 28l mod n. Its modular inverse with respect to n is denoted with R−1 , so (R · R−1 ) mod n = 1. The Montgomery representation of a number x is (x · R) mod n, where n is clear from the context. Montgomery multiplication, denoted with − × −, is defined as follows: x × y = (x · y · R−1 ) mod n. If the arguments are in Montgomery representation then so is the result: (x · R) × (y · R) = (x · y) · R mod n. To compute the modular product of a fixed number of factors it is not necessary to convert all factors into Montgomery representation. Instead one adds an additional correction factor Rk , where k is the number of factors. For instance (a1 · a2 · a3 ) mod n = a1 × a2 × a3 × R3 . To convert a number from Montgomery representation back to normal one multiplies with R−1 or exploits x = (x · R) × 1. Montgomery multiplication can be computed with a modified schoolbook multiplication algorithm. To compute x × y one decomposes y into l byte-digits yl yl−1 · · · y1 y0 and performs precisely l multiplication rounds. In multiplication round i one adds x · yi to the accumulator and shifts the accumulator one byte to the right. Before shifting one makes the last digit of the accumulator equal

108

H. Tews and B. Jacobs

to 0 by adding a suitable multiple of n. For an odd modulus n such a suitable multiple does always exist. Which multiple of n to use can be deduced from the last byte of the accumulator. The final accumulator might be bigger than n, so one has to take the modulus with respect to n at the end. The accumulator must be capable of holding l bytes plus 9 bits. In our implementation all numbers that come in contact with Montgomery multiplication are simply allocated with l + 2 bytes.

Appendix B

Description of the Implemented Protocols

This appendix describes the protocols from [1] that we implemented. The technical description is for the coprocessor enabled applet. The changes for the pure Java-Card applet are summarized at the end of each subsection. B.1

Initialization and Personalization

Parameter setup. Before starting the following points must be configured. – The number k of attributes each applet possesses. – The size of the RSA modulus n in bits, denoted with |n| in the sequal. – Optionally the size of the public RSA exponent v, denoted with |v| in the following. If not configured, |v| is derived from |n| using Lenstras estimations on the security level of RSA keys [6]. The following system parameters are computed once. If not further determined the items are randomly chosen to satisfy the relevant conditions. – The RSA modulus n of size |n|, where n = p q with p and q prime. – The public RSA exponent v of size |v|, such that v is prime and coprime to ϕ(n) = (p − 1)(q − 1), where ϕ is Euler’s totient function. – The modular inverse of v with respect to ϕ(n), denoted with v −1 in the following. – The private system key x ∈ Z∗n (i.e., gcd(x, n) = 1) and the public system key h = xv mod n. – k bases g1 , . . . , gk ∈ Z∗n . – For the pure Java-Card applet, the Montgomery factor R with respect to n (see Appendix A). For each applet that gets initialized one generates k random attribute values a1 , . . . , ak ∈ Zv . Applet initialization. After the coprocessor enabled applet or the pure JavaCard applet has been installed on a Java card the following protocol initializes the applet. In the protocol description A denotes the applet and H the host driver.

Performance Issues of Selective Disclosure Protocols

109

H −→ A : |v|, |n|, k the applet allocates all data structures H −→ A : n, h, g1 , . . . gk , b, Πg , a1 , . . . , ak , v, R where b = 1 is the initial blinding of the card, Πg , the precomputed products of the bases gi , and R are only used on the pure Java-Card applet. The card computes its blinded attribute expression A = bv



giai

subsequently the resign protocol is run, whereby the attribute updates are 0 and the signature check is left out on the host For the pure Java-Card applet there are the following changes. In the second step the values of h, g1 , . . . , gk and b are transformed into their Montgomery representation on the host before sending. The precomputed products Πg is an array of 2k − 1 elements containing the Montgomery representation of all possible products of the bases gi , except for the empty product 1. On the coprocessor enabled applet Πg is an array with one arbitrary element, because the Java-Card protocol layer does not support empty arrays. The Montgomery factor R, which equals the Montgomery representation of 1, is needed on the pure Java-Card applet to initialize the accumulator for the simultaneous squaring multi-power method. B.2

Resign Protocol

The resign protocol is taken from [1, Section 4.2.2.]. When the resign protocol runs as part of the applet initialization the signature (Sc , Sr ) is not yet initialized and therefore not checked in the first step. A −→ H : applet id , A, Sc , Sr , where  3 for the pure Java-Card applet applet id = 4 for the coprocessor enabled applet   ? The host checks the signature Sc = H A, Srv (hA)−Sc and aborts the protocol if the equation does not hold. H −→ A : α, u ˆ1 , . . . , u ˆk , where α ∈ Z∗n is the host commitment, and u ˆi are the encoded attribute updates for arbitrary attribute updates u1 , . . . , uk such that  v + ui for ui < 0 − v < ui < v and uˆi = ui otherwise the applet computes its new attributes ai = (ai + u ˆi ) mod v  a  v and the updated attribute expression A = b gi i

110

H. Tews and B. Jacobs

A −→ H : c = (Sc + β3 ) mod v, where   Sc = H A , α β2v (hA )β3 A = β1v A and β1 , β2 ∈ Z∗n , β3 ∈ Zv are random the applet additionally computes q = (Sc + β3 ) ÷ v

(where ÷ denotes integer division)



b = β1 b mod n   (v−1 ) H −→ A : r = α(hAh )c , where Ah = A giui  true if rv = α(hA )c A −→ H : acc, where acc = false if rv  = α(hA )c S

if acc = true the applet computes Sr = rβ2 β1 c (hA )q and atomically switches to use ai , b , A , Sc and Sr instead of ai , b, A, Sc and Sr In the preceding protocol H is a one-way hash function and ÷ denotes integer division with the property b (a ÷ b) + (a mod b) = a for arbitrary a, b ∈ N. Our implementation uses 160 bit SHA-1 for H. The host does not have access to the attribute values and must therefore compute its updated attribute expression Ah in a different way. Both A and Ah must be equal, otherwise the protocol fails. Note that the attribute updates ui might be negative, so it might be necessary to compute modular inverses (with respect to n) in the computation of Ah . The protocol will also fail if one of the attribute updates yields an under or an overflow, that is if ai + ui < 0 or if ai + ui ≥ v. Therefore, the host can only update those attributes where it knows something about the value. In our implementation this problem is solved with an additional status protocol, in which the applet sends all its data, including attributes and blinding, to the host. In a real application such a status protocol must, of course, not exist. For the pure Java-Card applet the protocol is identical, except that A, Sr , α and r are transmitted in their Montgomery representation and the arguments of the hash H are also in Montgomery representation (always with respect to modulus n). B.3 Gate Protocol The gate protocol is taken from [1, Section 2.4.4.]. A −→ H : applet id , A, Sc , Sr , w, where the applet id is as before, and  w = βv giαi is the applet’s witness with β ∈ Z∗n , α1 , . . . , αk ∈ Zv randomly chosen by the applet   ? the host checks the signature Sc = H A, Srv (hA)−Sc and aborts the protocol if the equation does not hold

Performance Issues of Selective Disclosure Protocols

111

H −→ A : γ ∈ Zv , the random challenge the applet checks that indeed γ < v A −→ H : r1 , . . . rk , s, where ri = (γai + αi ) mod v qi = (γai + αi ) ÷ v  q s = βbγ gi i the host accepts the proof if sv



giri = Aγ w

For the pure Java-Card applet the protocol is identical, except that A, Sr , w and s are transmitted in Montgomery representation and the arguments of H are also in Montgomery representation.

Energy-Efficient Implementation of ECDH Key Exchange for Wireless Sensor Networks Christian Lederer1 , Roland Mader2,3 , Manuel Koschuch4, Johann Großsch¨ adl5, 6 6 Alexander Szekely , and Stefan Tillich 1

University of Klagenfurt, Austria [email protected] 2 ITI, Graz University of Technology, Austria [email protected] 3 AVL List GmbH, Austria [email protected] 4 FH Campus Wien – University of Applied Sciences, Austria [email protected] 5 University of Bristol, United Kingdom [email protected] 6 IAIK, Graz University of Technology, Austria {aszekely,stillich}@iaik.tugraz.at

Abstract. Wireless Sensor Networks (WSNs) are playing a vital role in an ever-growing number of applications ranging from environmental surveillance over medical monitoring to home automation. Since WSNs are often deployed in unattended or even hostile environments, they can be subject to various malicious attacks, including the manipulation and capture of nodes. The establishment of a shared secret key between two or more individual nodes is one of the most important security services needed to guarantee the proper functioning of a sensor network. Despite some recent advances in this field, the efficient implementation of cryptographic key establishment for WSNs remains a challenge due to the resource constraints of small sensor nodes such as the MICAz mote. In this paper we present a lightweight implementation of the elliptic curve Diffie-Hellman (ECDH) key exchange for ZigBee-compliant sensor nodes equipped with an ATmega128 processor running the TinyOS operating system. Our implementation uses a 192-bit prime field specified by the NIST as underlying algebraic structure and requires only 5.20 · 106 clock cycles to compute a scalar multiplication if the base point is fixed and known a priori. A scalar multiplication using a random base point takes about 12.33 · 106 cycles. Our results show that a full ECDH key exchange between two MICAz motes consumes an energy of 57.33 mJ (including radio communication), which is significantly better than most previously reported ECDH implementations on comparable platforms.

1

Introduction

A Wireless Sensor Network (WSN) is a network consisting of a (potentially very large) number of autonomous devices, so-called motes, which are deployed in O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 112–127, 2009. c IFIP International Federation for Information Processing 2009 

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

113

the environment to cooperatively monitor physical conditions like temperature [37]. The sensor nodes are equipped with radio transceivers, enabling them to communicate with other nodes and centralized resources (e.g. a base station) or to connect to the Internet. In fact, WSNs are a prime example of what is often referred to by such buzz phrases as “pervasive computing,” “smart dust,” or the “internet of things” [10]. The February 2003 issue of the magazine Technology Review listed WSNs among 10 emerging technologies that will change the world [6]. Today, WSNs play a vital role in a multitude of applications ranging from environmental surveillance over medical monitoring to home automation [37]. A recent study [32] predicts that the WSN market for smart homes will grow from $470 million in 2007 to up to $2.8 billion in 2012, with a potential market size of 6 billion cumulative sensor nodes worldwide. Security and privacy issues pose a big challenge for the widespread adoption of WSN technology in certain application domains such as health care, traffic control, or disaster detection [7,28]. Unfortunately, WSNs are easier to attack (and harder to protect) than other types of network like, for example, corporate intranets. There are basically three reasons why unprotected WSNs are an easy target for malicious attacks. First, the wireless communication between nodes via radio signals makes eavesdropping quite easy and facilitates a slew of active attacks ranging from message injection to denial of service [12]. Second, the deployment of WSNs in unattended areas gives an attacker direct access to the sensor nodes and enables him to conduct all kinds of physical attacks including node capture [3]. Third, the vast majority of sensor nodes on the market today are battery-operated and, hence, severely restricted in terms of computational power, which makes the implementation of cryptographic schemes and security protocols rather difficult. To save energy, WSN designers often refrain from an attempt to secure the network or implement “futile” security measures like the encryption of node-to-node communication using a single network-wide key. 1.1

Key Establishment in WSNs

The establishment of a secret key shared between two (or more) sensor nodes is undoubtedly one of the most important security services needed to ensure the integrity and well functioning of a WSN. Various key establishment techniques taking the special characteristics and adversary models of sensor networks into account have been proposed [27,42]. A simple yet effective approach to obtain shared secret keys in a WSN is random key pre-distribution, first introduced by Eschenauer and Gligor in [16]. The idea is to load a set of keys randomly chosen from a large key pool onto each node prior to deployment such that two nodes will share (at least) one key with a certain probability. While this basic scheme is easy to implement and entails only little overhead since no costly key agreement must be carried out, it has some disadvantages in terms of scalability and resilience to node capture. Several improvements of Eschenauer’s probabilistic key pre-distribution scheme have been published, including a variant where two sensor nodes must share q > 1 common keys instead of just a single one [9]. The benefit of this increased amount of key overlap is better resilience against node

114

C. Lederer et al.

capture. Another variant described in [9] supports node-to-node authentication by assigning a unique secret key to each pair of nodes. Liu and Ning proposed in [26,27] a polynomial pool-based key pre-distribution scheme which combines probabilistic key pre-distribution and polynomial-based key generation to obtain a shared secret. In this scheme, the key pool is replaced by a pool of randomly generated bivariate polynomials over a finite field, and each node is pre-loaded with a set of polynomial shares (i.e. partially evaluated polynomials). Two nodes possessing polynomial shares of the same bivariate polynomial can establish a secret key following the polynomial-based key distribution protocol described in [5]. A very similar key establishment technique was published in [15] along with an in-depth theoretical analysis of its security properties. The polynomial poolbased scheme features low communication overhead and is substantially more resilient against node capture than the basic Eschenauer-Gligor scheme and the q-composite scheme from [9] as long as the number of compromised nodes does not exceed a certain threshold. Zhu et al presented in [44] a scalable protocol for key establishment based on the ideas of probabilistic key sharing and threshold secret sharing. The resilience of this protocol remains intact under a collusion attack by up to a certain number of compromised nodes, similar to the Liu-Ning scheme. Another common feature of the schemes in [26,15] and [44] is that they enable a pair of nodes to set up a unique secret key exclusively known by these two nodes. Therefore, compromised nodes will not leak information about the secret keys shared among non-compromised nodes1 . A completely different approach for key establishment in WSNs is to use a trusted third party (e.g. the base station) that acts as a key distribution center (KDC) and generates, upon request, a unique secret key for two nodes wishing to communicate securely with each other. The KDC sends this key in encrypted form to the two sensor nodes, similar to the Needham-Schroeder protocol [31] or Kerberos [24]. Kerberos was originally designed to authenticate entities on a network; the establishment of a secret key is a “side effect.” Each node of the network shares a long-term secret key with the KDC, which enables the nodes to verify that messages from the KDC are authentic. Similarly, knowledge of the long-term key also serves to prove a node’s identity to the KDC. To set up a link key shared between node A and node B, the KDC generates a secret key and securely sends it to A and B encrypted under the long-term key it shares with A and with B, respectively. Extraction of the link key is only possible for the legitimate node which possesses the corresponding long-term key. Thus, by trusting the KDC, the nodes can authenticate each other (i.e. prove their true identity) and establish a secret key. The long-term key that each sensor node 1

Per definition, a pair-wise key establishment scheme assigns a unique secret key to each pair of nodes. The polynomial pool-based key pre-distribution scheme [26,15] can fulfill this property, provided that no polynomial of degree t is used more than t + 1 times. Zhu et al’s scheme [44] is strictly speaking not pair-wise, but guarantees with an overwhelming probability that a secret key is exclusively known to a pair of nodes. On the other hand, the basic Eschenauer-Gligor scheme is not a pair-wise scheme since one and the same key may be used by several node pairs.

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

115

shares with the KDC is pre-deployed, but, contrary to approaches with a single network-wide key, each node has a unique key. Therefore, compromised nodes do not jeopardize the security of the rest of the WSN, which makes Kerberoslike protocols very robust against node capture. However, they suffer from high communication cost, especially in large networks in which the base station may be located far away from the two nodes wishing to set up a link key. A second drawback of protocols using a central KDC is their non-uniform communication pattern: Nodes located in the vicinity of the KDC have to forward all requests for link keys from the rest of the WSN, which drains the batteries of these nodes at a high rate. The concentration of network traffic near the KDC clearly limits the scalability of Kerberos. To alleviate these disadvantages, Chan and Perrig [8] introduce PIKE, a key establishment protocol that uses “ordinary” nodes as trusted intermediaries for the generation of link keys. √ Both the communication cost and memory overhead of PIKE scale with O( n), where n represents the number of nodes in the network. Perrig et al describe in [33] a Kerberos-like key establishment technique implemented on top of the Secure Network Encryption Protocol (SNEP). Key establishment in WSNs can also be performed with protocols that use public-key cryptography to generate a secret key shared between two nodes. The most important key exchange protocol was proposed by Diffie and Hellman [14] in 1976 and is usually implemented in the multiplicative group of a finite field of prime order. Alternatively, it is also possible to embed the Diffie-Hellman key exchange into an additive group like the group of points on an elliptic curve defined over a finite field. The efficient implementation of elliptic curve cryptography (ECC) for WSN has been an active area of research in recent years, in particular since Gura et al [21] demonstrated that Elliptic Curve Diffie-Hellman (ECDH) key exchange is feasible for resource-restricted sensor nodes. The main advantages of using ECDH key exchange in WSNs are perfect resilience to node capture, excellent scalability, and low memory as well as communication overhead. However, the big drawback of ECDH is the highly computation-intensive nature of its underlying cryptographic operations, causing long execution times and high energy consumption. Energy is the most precious resource of wireless motes, and this will remain so for the next future since dramatic improvements in battery technology are not foreseen. Therefore, approaches for reducing the energy cost of ECDH key exchange are eagerly sought. 1.2

Our Contributions

In this paper we present a highly-optimized software implementation of ECDH key exchange for ZigBee-compliant sensor nodes running the TinyOS operating system, in particular the MICAz motes [11]. Contrary to previous work, where in most cases an elliptic curve over a 160-bit prime field was used as underlying algebraic structure, we base our implementation on a cryptographically much stronger curve over a 192-bit field that is compliant with all major standards for ECC, including the NIST recommendations [30]. We integrated our ECC code into an experimental TinyOS program for key exchange between two MICAz

116

C. Lederer et al.

motes, which allowed us to conduct a detailed performance and energy analysis of both the cryptographic operations and the radio communication. Our work advances the state-of-the-art in efficient ECDH implementation in the following ways: First, we present an improved version of Gura et al’s [21] hybrid method for multi-precision multiplication that requires fewer single-precision additions (i.e. add and adc instructions on an ATmega128L processor [2]). Our variant is similar (but not identical) to the hybrid multiplication methods introduced in [35] and [40]. Second, our implementation uses fast algorithms for elliptic curve scalar multiplication (window method, comb method) to reduce the execution time of ECDH key exchange at the expense of a slight increase in memory requirements. However, we show that despite the additional memory demand, the window and comb methods are perfectly feasible for MICAz motes. Third, we aimed to secure our ECDH implementation against side-channel attacks. Thanks to the window and comb methods, the performance degradation caused by the integration of side-channel countermeasures is relatively small.

2

Elliptic Curve Cryptography

An elliptic curve E over a prime field Fp can be defined as the set of all tuples (x, y) ∈ Fp × Fp satisfying an equation of the form y 2 = x3 + ax + b

with a, b ∈ Fp

(1)

These tuples are called points with x and y referred to as coordinates. The set of points together with a special point O (the so-called point at infinity) allows one to form a commutative group with O being the identity element. The group operation is the addition of points, which can be performed through arithmetic operations (addition, subtraction, multiplication, squaring, and inversion) in the underlying field Fp according to well-defined formulae (see e.g. [22]). Adding a point P = (x, y) to itself is referred to as point doubling and can also be done through a well-defined sequence of operations in Fp . In general, point doubling requires fewer field operations than the addition of two points. The order of an elliptic curve group E(Fp ) is the number of Fp -rational points on the curve E, plus one for the point at infinity. It is well known from Hasse’s theorem that #E(Fp ) has the following bounds: √ √ p + 1 − 2 p ≤ #E(Fp ) ≤ p + 1 + 2 p

(2)

For cryptographic applications, #E(Fp ) should have a large prime factor; in the ideal case it is a prime. Before ECDH key exchange (or any other elliptic curve scheme) can be carried out, the involved parties have to agree upon a common set of so-called domain parameters, which specify the finite field Fp , the elliptic curve E (i.e. the coefficients a, b ∈ Fp defining E according to Equation (1)), a base point P ∈ E(Fp ) generating a cyclic subgroup of large order, the order n of this subgroup, and the co-factor h = #E(Fp )/n. Consequently, elliptic curve domain parameters over Fp are simply a sextuple D = (p, a, b, P, n, h) [22]. In

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

117

elliptic curve cryptography, a private key is an integer k chosen randomly from the interval [1, n − 1]. The corresponding public key is the point Q = k · P on the curve. Given k and P , the point Q = k · P can be obtained by means of an operation called scalar multiplication [22]. Numerous algorithms for scalar multiplication have been proposed; the simplest way to compute k · P is to perform a sequence of point additions and doublings, similar to the square-and-multiply algorithm for modular exponentiation. While a scalar multiplication of the form Q = k · P can be calculated quite efficiently, the inverse operation, i.e. finding k when P and Q are given, is a hard mathematical problem known as the Elliptic Curve Discrete Logarithm Problem (ECDLP). To date, the best algorithm known for solving the ECDLP requires fully exponential time if the domain parameters were chosen with care [22]. In contrast, the best algorithm for solving the Discrete Logarithm Problem (DLP) in Z∗p or the Integer Factorization Problem (IFP) has a sub-exponential running time. As a consequence, elliptic curve cryptosystems can use much shorter keys compared to their “classical” counterparts based on the DLP or IFP. A common rule of thumb states that a properly designed 160-bit ECC scheme is about as secure as 1024-bit RSA. However, the U.S. National Institute of Standards and Technology (NIST) recommends using 1024-bit RSA and 160-bit ECC only until 2010. Therefore, we opted to embed our implementation of the ECDH protocol into a much stronger 192-bit elliptic curve group. 2.1

Elliptic Curve Diffie-Hellman (ECDH) Key Exchange

ECDH key exchange is the elliptic curve analogue of the classical Diffie-Hellman key exchange operating in Z∗p [14]. As its classical counterpart, the ECDH protocol can be used to establish a shared secret key between two entities using an insecure communication channel. In the following, we describe in detail the steps that two communicating parties, usually called Alice and Bob, have to perform in order to obtain a shared secret. We assume that Alice and Bob use the same set of domain parameters D = (p, a, b, P, n, h) for their computations. – Alice generates an ephemeral key pair (kA , QA ), i.e. she generates a random number kA in the interval [1, n− 1] and then performs a scalar multiplication to get the corresponding public key QA = kA · P . She sends QA to Bob. – Bob generates an ephemeral key pair (kB , QB ) with QB = kB ·P in the same way as described above and sends the public key QB to Alice. – After Alice receives Bob’s ephemeral public key QB , she performs a scalar multiplication to obtain the shared secret S = kA · QB . – After Bob receives the ephemeral public key QA from Alice, he obtains the shared secret through computation of S = kB · QA . Now Alice and Bob possess the same secret S since kA · QB = kA · kB · P and kB · QA = kB · kA · P , i.e. both parties arrived at the same value for S because E(Fp ) is a commutative group. Each run of the ECDH protocol requires Alice and Bob to send two messages (to exchange the ephemeral public keys) and to

118

C. Lederer et al.

perform four scalar multiplications altogether. The first two could be computed simultaneously by Alice and Bob; the other two scalar multiplications must be carried out thereafter. It is also possible to precalculate a pair of ephemeral keys when the parties are idling to speed up subsequent protocol runs. An attacker might intercept the public keys QA and QB , but he will not be able to derive the private keys kA and kB from QA , QB , P unless he solves the ECDLP. The security of the ECDH protocol relies on the intractability of the (computational) Elliptic Curve Diffie-Hellman Problem (ECDHP); that is, given an elliptic curve E, a base point P ∈ E(Fp ), and two points QA = kA · P and QB = kB · P , find the point S = kA · kB · P without knowledge of kA , kB . It is clear that an algorithm for solving a generic ECDLP instance would allow one to solve the ECDHP as well. A straightforward implementation of ECDH key exchange is vulnerable to a man-in-the-middle attack [22]. To prevent this attack, the ECDH protocol as described above must be extended in such a way that the communicating parties are authenticated to each other. Nonetheless, the classical ECDH key exchange serves as a good benchmark for the feasibility of public-key cryptography on resource-constrained sensor nodes. Key exchange in WSNs using an advanced protocol incorporating authentication, such as Signed ECDH or ECMQV, has been studied in [13] and [20], respectively. 2.2

Scalar Multiplication

The computationally expensive part of virtually all elliptic curve cryptosystems is scalar multiplication, an operation of the form k · P where k is an integer and P is a point on the curve. A scalar multiplication can be performed by means of repeated point additions and point doublings, both of which, in turn, involve a sequence of arithmetic operations (i.e. addition, multiplication, squaring, and inversion) in the underlying finite field. Inversion is by far the most expensive operation in prime fields [22]. However, it is possible to add points on an elliptic curve without the need to perform costly inversions, e.g. by representing the points in projective coordinates [22]. In Section 2 we described the conventional (i.e. affine) coordinate system in which a point P is associated with an x and a y coordinate, i.e. a tuple (x, y) ∈ Fp × Fp . By contrast, in projective coordinate systems, a point is represented by a triplet (X, Y, Z), which corresponds to the affine coordinates (X/Z u , Y /Z v ) when Z  = 0 (u and v depend on the specific coordinate system chosen). For example, the projective point P = (X, Y, Z) in Jacobian coordinates corresponds to the affine point P = (X/Z 2 , Y /Z 3 ). It is also possible to add two points when one is given in projective coordinates and the other in affine coordinates [22]. In fact, such mixed coordinates often lead to very efficient point addition formulae. For example, adding a point in Jacobian coordinates to an affine point requires eight multiplications and three squarings in Fp (but no inversion). Doubling a point given in Jacobian coordinates takes four multiplications and four squarings. The double-and-add algorithm performs a scalar multiplication via repeated point additions and doublings, analogous to the multiply-and-square algorithm

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

119

for modular exponentiation. It uses the binary expansion of the integer k and computes k · P as follows: For each bit ki of k, the current intermediate result is doubled, and the base point P is added if bit ki = 1 (no addition is performed when ki = 0). Given an l-bit scalar k, the double-and-add algorithm executes exactly l point doublings, whereas the number of point additions depends on the Hamming weight of k. In the average case l/2 additions are carried out; the worst-case number of additions is l. The conventional double-and-add method can be easily improved by using a signed-digit representation of k. One option is the non-adjacent form (NAF), which reduces the number of additions (of either P or −P ) to l/3 in the average case and l/2 in the worst case [22]. However, the number of point doublings remains the same. The average number of point additions can be further reduced if some RAM is available for storing multiples of the base point P . A window method with a window size of w uses a radix-2w representation of the scalar k and requires to pre-compute the points 2P, 3P, . . . , (2w − 1)P . These 2w − 2 points are stored in a look-up table, typically in affine representation to save RAM and to allow one using mixed coordinates for point addition. The window method works in a similar fashion as the double-and-add method, except that in each step w bits of k are considered with the corresponding table-entry being added to the intermediate result. A window size of w reduces the total number of point additions to roughly l/w, but does not change the number of doublings. Results from previous work show that w = 4 represents a good compromise between performance and memory requirements. If the base point is fixed an known a priori, which is the case when generating an ephemeral key pair for ECDH key exchange, the number of both additions and doublings can be reduced by using a so-called comb method [22]. The idea is to pre-compute the points Pi = 2wi · P for 0 ≤ i ≤ l/w − 1 and to perform the scalar multiplication in an interleaved fashion (similar to Shamir’s trick), which yields a total of l/w doublings and roughly the same number of additions. As the base point P is fixed, it is possible to do the pre-computation off-line and store a look-up table holding the 2w − 2 points in Flash memory or ROM. The window method and the comb method have in common that the average-case and the worst-case execution time are almost the same.

3

Prime-Field Arithmetic on the ATmega128

In this section we describe the implementation and optimization of prime-field arithmetic on MICAz motes from Crossbow Technologies [11]. The MICAz is a low-power sensor node equipped with an 8-bit ATmega128L processor clocked at 7.3728 MHz, 4 kB RAM, and 128 kB Flash memory. It also features an IEEE 802.15.4 (“ZigBee”) compliant RF transceiver, which allows for communication with other nodes and the base station. The ATmega128 is a simple 8-bit RISC processor [2] based on the AVR instruction set [1], i.e. the usual arithmetic and logical instructions are supported, including a fast integer-multiply instruction with a 2-cycle latency. A total of 32 general-purpose registers are available.

120

C. Lederer et al.

Our implementation of the ECDH protocol uses a NIST-recommended elliptic curve over a 192-bit prime field as basic building block. The field is defined by the generalized-Mersenne prime p = 2192 − 264 − 1 [30]. All arithmetic operations described in this section are performed on (and optimized for) 192-bit operands (i.e. 192-bit integers). It is common practice in multiple-precision arithmetic to store the operands in arrays of single-precision words, e.g. arrays of unsigned m-bit integers with m denoting the processor’s word size. However, the ANSI C standard specifies the size of the basic integer type to be at least 16 bits, even on 8-bit platforms. Therefore, we decided to use a 16-bit representation, i.e. a 192-bit field element is stored in an array of s = 12 words, each accommodating 16 bits. All software routines were designed and implemented with 16-bit words as the “smallest unit” of data, which means they operate on two bytes of the operand(s) at a time. Another important characteristic of our implementation is that we tolerate incompletely reduced results, provided that their length does not exceed 192 bits. In other words, an operand does not necessarily need to be in the interval [0, p − 1], but it must be smaller than 2192 so that it fits into a 12-word array. 3.1

Addition and Subtraction

The addition of two field elements a, b is implemented via a loop that iterates through the words of the operands, starting with the least significant word. In each iteration, a word (i.e. two bytes) of operand a and a word of b are loaded from memory and added up using the add (resp. adc) instruction. After addition of the most significant word, the prime p must be subtracted if the sum exceeds 192 bits, which can be easily checked via the carry flag. Note that we tolerate an incompletely reduced result; thus it is not necessary to do an exact comparison between the sum and p. The field subtraction is implemented as conventional subtraction, followed by an addition of p if the result was negative. 3.2

Multiplication and Squaring

The overall execution time of a scalar multiplication depends significantly on the efficiency of the multiplication and squaring operations. A field multiplication is composed of a “conventional” multiplication of two 192-bit operands, yielding a 384-bit product, followed by a reduction of the product modulo the prime p. In this subsection we focus on multiplication and squaring; the modular reduction operation is subject of the next subsection. There are two basic algorithms for multi-precision multiplication: one is the operand-scanning method (also called row-wise multiplication) and the other is the product-scanning method (column-wise multiplication) [18,21]. Both require the same number of single-precision multiplications (i.e. mul instructions on an ATmega128), namely 576 in our case of 192-bit operands, but they differ in the number of memory accesses and single-precision additions. We first describe the original operand and product scanning methods, which operate on 8-bit words (i.e. bytes) when implemented on an ATmega processor. Later in this section we

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks Column-Wise Multiplication

Hybrid Multiplication (d = 2)

a0 · b0 a1 · b0 a0 · b1 a2 · b0 a1 · b1 a0 · b2 a3 · b0 a2 · b1 a1 · b2 a0 · b3 a3 · b1 a2 · b2 a1 · b3 a3 · b2 a2 · b3 a3 · b3

a0 · b0 a1 · b0 a0 · b1 a1 · b1 a2 · b0 a3 · b0 a2 · b1 a3 · b1 a0 · b2 a1 · b2 a0 · b3 a1 · b3 a2 · b2 a3 · b2 a2 · b3 a3 · b3

r2 r1 r0 accumulator

r4 r3 r2 r1 r0 accumulator

121

Our Hybrid Multiplication a0 · b0 a1 · b1 a1 · b0 a0 · b1 a2 · b0 a3 · b1 a3 · b0 a2 · b1 a0 · b2 a1 · b3 a1 · b2 a0 · b3 a2 · b2 a3 · b3 a3 · b2 a2 · b3 r4 r3 r2 r1 r0 accumulator

Fig. 1. Comparison between the conventional product-scanning method (left), Gura’s hybrid multiplication (middle), and our variant of hybrid multiplication (right)

introduce our optimized version that uses 16-bit words as smallest unit of data it operates on. The operand-scanning method has a nested-loop structure with a relatively simple inner loop. Each iteration executes an operation of the form a · b + c + d with a, b, c, d denoting 8-bit words (i.e. bytes). On an ATmega this operation requires one mul instruction to produce the partial product a · b, and a total of four add (resp. adc) instructions to add the two bytes c and d to the 16-bit quantity a · b. Furthermore, two load (ld) instructions and a store (st) are executed in each iteration. On the other hand, the product-scanning method performs a multiply-accumulate operation in its inner loop, i.e. two bytes are multiplied and the 16-bit partial product is added to a cumulative sum held in three registers, as illustrated on the left side of Figure 1. The product-scanning method also executes two ld instructions per iteration, but no store [18]. The execution time of the conventional product-scanning method can be significantly improved if the processor features a large number of general-purpose registers, which is the case with the ATmega128 [2]. The hybrid multiplication method, introduced by Gura et al in [21], works similar as the product-scanning technique, but operates on words consisting of d ≥ 2 bytes, which reduces the number of required loop iterations by a factor of d. Figure 1 shows an example for 32-bit operands and d = 2. In each iteration of the inner loop a 16-bit word (i.e. two bytes) of operand a and a 16-bit word of operand b are loaded from memory. These two 16-bit words are multiplied using the mul instruction, and the product is added to a cumulative sum held in five registers. The rectangles in Figure 1 represent 16-bit products as obtained by the multiplication of two bytes. The four mul instructions needed for a multiplication of two 16-bit words are actually executed in row-wise order. Gura et al state in [21] that the hybrid

122

C. Lederer et al.

method employs the product-scanning strategy as the “outer algorithm” and the operand-scanning strategy as the “inner algorithm” (i.e. for the (8 × 8)-bit mul instructions within a (d × d)-byte multiplication). When multiplying two 192-bit operands, the hybrid method with d = 2 executes 576 ld instructions, which represents a 50% improvement over the standard product-scanning technique [21]. The number of mul instructions remains the same. Our implementation of the hybrid multiplication aims at reducing the number of add (resp. adc) instructions compared to Gura et al’s method. To achieve this, we employ the product-scanning strategy as the “inner algorithm,” but schedule the mul instructions in a non-conventional order such that the addition to the cumulative sum (including carry propagation) can be performed in “one pass” for several 16-bit partial products. For example, let us have a look at the multiplication of the 16-bit word (a1 , a0 ) by the 16-bit word (b1 , b0 ), depicted in the top right of Figure 1. We first multiply a0 by b0 and add the 16-bit partial product a0 · b0 to the least significant 16 bits of the cumulative sum held in the register pair r1 , r0 . The second mul instruction produces the partial product a1 · b1 , which is added to the content of registers r4 , r3 , r2 . Hence, the addition of the two partial products a0 · b0 , a1 · b1 to the cumulative sum requires only five add (resp. adc) instructions altogether. Our method can be easily applied for hybrid multiplication with d = 4; in this case 51 add/adc instructions are executed per iteration of the inner loop. Unfortunately, when implemented on the ATmega, our method requires to perform a number of movw instructions to copy the results of the mul instructions to pairs of temporary registers, which is necessary since mul overwrites the carry flag. Scott and Szczechowiak describe in [35] a similar hybrid method using so-called “carry-catcher” registers. The square a2 of a multiple-precision integer a can be computed significantly faster than the product a · b of two distinct integers. Due to a “symmetry” in the squaring operation, most partial products appear twice. However, they need only be computed once and then left-shifted in order to be doubled. Our optimized squaring routine executes just 300 mul instructions for a 192-bit operand. 3.3

Modular Reduction

Each 384-bit product (or square) needs to be reduced modulo p = 2192 − 264 − 1 to get the final result. This modular reduction operation can be implemented very efficiently since p is a generalized-Mersenne prime. In fact, the reduction requires only three 192-bit additions, followed by a few conditional subtractions of p to get a reduced result that is at most 192 bits long (see [22] for a detailed treatment). We implemented the reduction operation as described in [19].

4

Experimental Results and Discussion

We developed a simple TinyOS program for ECDH key exchange and executed it on a MICAz mote, which allowed us to analyze the running time and energy consumption of the protocol. Each key exchange requires the mote to perform

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

123

Table 1. Runtime comparison of different implementations of scalar multiplication Implementation

Finite field

Blaß and Zitterbart [4] Malan et al. [29] Yan and Shi [43] Seo et al. [36] Kargl et al. [23] Wang and Li [41] Szczechowiak et al. [38] Ugus et al. [39] Liu and Ning [25] Gura et al. [21] F¨ urbass et al. [17] Our implementation

GF(2m ), 113 bit GF(2m ), 163 bit GF(2m ), 163 bit GF(2m ), 163 bit GF(2m ), 167 bit GF(p), 160 bit GF(p), 160 bit GF(p), 160 bit GF(p), 192 bit GF(p), 192 bit GF(p), 192 bit GF(p), 192 bit

Fixed P. Rand. P. Notes 6.74 s 34.17 s 13.9 s 1.14 s 0.763 s 1.24 s 1.27 s 0.57 s 2.99 s 1.35 s 0.068 s 0.71 s

17.28 s 34.17 s 13.9 s 1.14 s 0.763 s 1.35 s 1.27 s 1.03 s 2.99 s 1.35 s 0.068 s 1.67 s

comb, dbl-and-add double-and-add affine coordinates Koblitz curve Montgomery ladder sld. window, NAF comb method comb, window sliding window NAF hardware impl. comb, window

two point multiplications, one with a fixed point (to generate an ephemeral key pair), and the second with a random point (to obtain the shared secret). The former uses a fixed-base comb method with 14 pre-computed points and can be carried out in 5.20 · 106 clock cycles (0.71 sec), while the latter is implemented using a window method with a window size of 4 (i.e. 14 pre-computed points) and executes in 12.33 · 106 cycles (1.67 sec). Based on the energy characteristics of the MICAz mote [34,13], these timings translate into an energy consumption of 17.04 mJ and 40.08 mJ, respectively. The energy cost of transmitting one protocol message in 0.205 mJ, which means that the total energy consumption of our ECDH key exchange is approximately 57.33 mJ per node. Taking again the energy model from [34] as reference, we can perform 117,750 key exchanges before the battery voltage drops below the value needed by the ATmega128. Our evaluation shows that the overall energy cost of ECDH key exchange is primarily determined by the computation of the two scalar multiplications on each node; the energy needed for radio communication is almost negligible. We also conducted experiments with point compression [22], a technique that allows to represent a point using the minimum possible number of bits so as to reduce the energy cost of radio communication in ECDH key exchange. However, on the MICAz mote, point compression did not yield any savings in energy. A comparison with related work (see Table 1) shows that our implementation is significantly faster than most previously-reported 192-bit implementations on 8-bit AVR processors and outperforms even some 160-bit implementations. This performance gain is primarily due to the efficient implementation of the field arithmetic (in particular the field multiplication) and the use of the window and comb methods with a window size of 4 for scalar multiplication. The additional memory demand of these methods is small enough to let our TinyOS program for ECDH key exchange fit into the 4 kB RAM of the MICAz mote. Despite all resource constraints, our software implementation of the comb method is only by a factor of 10 slower than the hardware implementation reported in [17].

124

C. Lederer et al.

Protection Against Side-Channel Attacks. Side-channel attacks belong to the genre of implementation attacks and use information leaking from a device while it executes a cryptographic algorithm (e.g. power consumption, execution time) to reveal the secret key [22]. Fortunately, ECDH key exchange is not vulnerable to DPA and timing attacks as the scalar multiplications are performed with new random numbers in each run of the protocol. However, an SPA attack on the scalar multiplication is possible, and if successful, provides the attacker with the random number k that is part of the ephemeral key pair generated in each run of the protocol (see Section 2.1), which enables him to eavesdrop on the communication between the nodes. In order to foil SPA attacks, the scalar multiplication should be implemented in such a way that always the same sequence of operations (i.e. point additions and doublings) is executed, independent of the scalar. Of course, this requires an SPA-resistant implementation of the field arithmetic too. For example, small irregularities in the modular addition or modular reduction (e.g. conditional subtractions of the prime p) typically lead to differences in execution time and power consumption, which can be exploited to mount an SPA attack [22]. It is particularly important to prevent conditional subtractions in the fast reduction operation; we achieved this by following the approach from [19]. As described in Subsection 2.2, we use a window method with a window size of 4 to implement the scalar multiplication by an arbitrary base point P , and a fixed-base comb method if P is known a-priori. Both methods can be made SPA-resistant by converting the scalar k into a radix-24 representation with a digit-set that does not contain 0. Such conversions are easy to implement and have only little impact on performance (about 5% in our implementation).

5

Conclusions

We presented an optimized implementation of ECDH key exchange for MICAz motes. Our implementation utilizes a NIST-recommended elliptic curve over a 192-bit prime field as underlying algebraic structure and executes a full scalar multiplication in 0.71 sec (5.20 · 106 cycles) when the base point is fixed and known a priori. A scalar multiplication by an arbitrary base point takes 1.67 sec (12.33 · 106 cycles). The total amount of energy required to perform an ECDH key exchange is approximately 57 mJ per node, which means that each node can carry out over 117,000 key exchanges before running out of battery. Our ECDH key exchange is significantly faster and more energy-efficient than previously-reported 192-bit implementations on comparable 8-bit platforms. The higher performance is mainly due to the use of the window and comb methods for scalar multiplication instead of the simple double-and-add technique. The additional memory demand when using a window method with a window size of 4 is relatively small (1080 bytes) and fits easily into the motes’ 4 kB RAM. In addition, the window method can be made SPA-resistant without much loss in performance. Putting it all together, our results confirm that high performance and side-channel resistivity can be achieved on resource-constraint motes.

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

125

Acknowledgements. The research described in this paper has been supported by the the EPSRC under grant EP/E001556/1, the Austrian ministry BM:VIT in the FIT-IT program line “Trust in IT Systems” under grant 816151 (project POWER-TRUST), and the European Commission under grant FP6-IST-033563 (project SMEPP) and, in part, through the ICT Programme under contract ICT-2007-216676 ECRYPT II. The information in this document 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.

References R 1. Atmel Corporation. 8-bit ARV Instruction Set. User Guide (July 2008), http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf R 2. Atmel Corporation. 8-bit ARV Microcontroller with 128K Bytes In-System Programmable Flash: ATmega128, ATmega128L. Datasheet (June 2008), http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf 3. Becher, A., Benenson, Z., Dornseif, M.: Tampering with Motes: Real-World Physical Attacks on Wireless Sensor Networks. In: Clark, J.A., Paige, R.F., Polack, F.A.C., Brooke, P.J. (eds.) SPC 2006. LNCS, vol. 3934, pp. 104–118. Springer, Heidelberg (2006) 4. Blaß, E.-O., Zitterbart, M.: Efficient implementation of elliptic curve cryptography for wireless sensor networks. Technical Report TM-2005-1, Institute of Telematics, University of Karlsruhe, Karlsruhe, Germany (March 2005), http://doc.tm.uka.de/2005/tm-2005-1.pdf 5. Blundo, C., De Santis, A., Herzberg, A., Kutten, S., Vaccaro, U., Yung, M.: Perfectly-Secure Key Distribution for Dynamic Conferences. In: Brickell, E.F. (ed.) CRYPTO 1992. LNCS, vol. 740, pp. 471–486. Springer, Heidelberg (1993) 6. Brody, H.: 10 emerging technologies that will change the world. Technology Review 106(1), 33–49 (2003) 7. Chan, H., Perrig, A.: Security and privacy in sensor networks. Computer 36(10), 103–105 (2003) 8. Chan, H., Perrig, A.: PIKE: Peer intermediaries for key establishment in sensor networks. In: Proceedings of the 24th IEEE International Conference on Computer Communications (INFOCOM 2005), vol. 1, pp. 524–535. IEEE, Los Alamitos (2005) 9. Chan, H., Perrig, A., Song, D.: Random key predistribution schemes for sensor networks. In: Proceedings of the 24th IEEE Symposium on Security and Privacy (S&P 2003), pp. 197–213. IEEE Computer Society Press, Los Alamitos (2003) 10. Conti, J.P.: The Internet of things. IET Communications Engineer 4(6), 20–25 (2007) 11. Crossbow Technology, Inc. MICAz Wireless Measurement System. Data sheet (January 2006), http://www.xbow.com/Products/Product pdf files/Wireless pdf/ MICAz Datasheet.pdf 12. Das, S.K., Agah, A., Basu, K.: Security in wireless mobile and sensor networks. In: Guizani, M. (ed.) Wireless Communications Systems and Networks, ch. 18, pp. 531–557. Springer, Heidelberg (2004) 13. de Meulenaer, G., Gosset, F., Standaert, F.-X., Pereira, O.: On the energy cost of communication and cryptography in wireless sensor networks. In: Proceedings of the 4th IEEE International Conference on Wireless and Mobile Computing,

126

14. 15.

16.

17.

18.

19.

20.

21.

22. 23.

24.

25.

26.

27. 28. 29.

C. Lederer et al. Networking and Communications (WIMOB 2008), pp. 580–585. IEEE Computer Society Press, Los Alamitos (2008) Diffie, W., Hellman, M.E.: New directions in cryptography. IEEE Transactions on Information Theory 22(6), 644–654 (1976) Du, W., Deng, J., Han, Y.S., Varshney, P.K.: A pairwise key pre-distribution scheme for wireless sensor networks. In: Jajodia, S., Atluri, V., Jaeger, T. (eds.) Proceedings of the 10th ACM Conference on Computer and Communications Security (CCS 2003), pp. 62–72. ACM Press, New York (2003) Eschenauer, L., Gligor, V.D.: A key-management scheme for distributed sensor networks. In: Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS 2002), pp. 41–47. ACM Press, New York (2002) F¨ urbass, F., Wolkerstorfer, J.: ECC processor with low die size for RFID applications. In: Proceedings of the 40th IEEE International Symposium on Circuits and Systems (ISCAS 2007), pp. 1835–1838. IEEE, Los Alamitos (2007) Großsch¨ adl, J., Avanzi, R.M., Sava¸s, E., Tillich, S.: Energy-Efficient Software Implementation of Long Integer Modular Arithmetic. In: Rao, J.R., Sunar, B. (eds.) CHES 2005. LNCS, vol. 3659, pp. 75–90. Springer, Heidelberg (2005) Großsch¨ adl, J., Sava¸s, E.: Instruction Set Extensions for Fast Arithmetic in Finite Fields GF(p) and GF(2m ). In: Joye, M., Quisquater, J.-J. (eds.) CHES 2004. LNCS, vol. 3156, pp. 133–147. Springer, Heidelberg (2004) Großsch¨ adl, J., Szekely, A., Tillich, S.: The energy cost of cryptographic key establishment in wireless sensor networks. In: Deng, R.H., Samarati, P. (eds.) Proceedings of the 2nd ACM Symposium on Information, Computer and Communications Security (ASIACCS 2007), pp. 380–382. ACM Press, New York (2007) Gura, N., Patel, A., Wander, A.S., Eberle, H., Chang Shantz, S.: Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs. In: Joye, M., Quisquater, J.-J. (eds.) CHES 2004. LNCS, vol. 3156, pp. 119–132. Springer, Heidelberg (2004) Hankerson, D.R., Menezes, A.J., Vanstone, S.A.: Guide to Elliptic Curve Cryptography. Springer, Heidelberg (2004) Kargl, A., Pyka, S., Seuschek, H.: Fast arithmetic on ATmega128 for elliptic curve cryptography. Cryptology ePrint Archive, Report 2008/442 (2008), http://eprint.iacr.org Kohl, J.T., Neuman, B.C.: The Kerberos Network Authentication Service (Version 5). Internet Engineering Task Force, Network Working Group, RFC 1510 (September 1993) Liu, A., Ning, P.: TinyECC: A configurable library for elliptic curve cryptography in wireless sensor networks. In: Proceedings of the 7th International Conference on Information Processing in Sensor Networks (IPSN 2008), pp. 245–256. IEEE Computer Society Press, Los Alamitos (2008) Liu, D., Ning, P.: Establishing pairwise keys in distributed sensor networks. In: Jajodia, S., Atluri, V., Jaeger, T. (eds.) Proceedings of the 10th ACM Conference on Computer and Communications Security (CCS 2003), pp. 52–61. ACM Press, New York (2003) Liu, D., Ning, P.: Security for Wireless Sensor Networks. Advances in Information Security, vol. 28. Springer, Heidelberg (2006) Lopez, J., Zhou, J.: Wireless Sensor Network Security. Cryptology and Information Security Series, vol. 1. IOS Press, Amsterdam (2008) Malan, D.J., Welsh, M., Smith, M.D.: A public-key infrastructure for key distribution in TinyOS based on elliptic curve cryptography. In: Proceedings of the 1st IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks (SECON 2004), pp. 71–80. IEEE, Los Alamitos (2004)

Energy-Efficient ECDH Key Exchange for Wireless Sensor Networks

127

30. National Institute of Standards and Technology (NIST). Recommended Elliptic Curves for Federal Government Use (July 1999), http://csrc.nist.gov/encryption/dss/ecdsa/NISTReCur.pdf 31. Needham, R.M., Schroeder, M.D.: Using encryption for authentication in large networks of computers. Communications of the ACM 21(12), 993–999 (1978) 32. ON World, Inc. WSN for smart homes. Market Dynamics Report (February 2008) 33. Perrig, A., Szewczyk, R., Wen, V., Culler, D.E., Tygar, J.D.: SPINS: Security protocols for sensor networks. In: Proceedings of the 7th Annual International Conference on Mobile Computing and Networking (MOBICOM 2001), pp. 189–199. ACM Press, New York (2001) 34. Piotrowski, K., Langend¨ orfer, P., Peter, S.: How public key cryptography influences wireless sensor node lifetime. In: Zhu, S., Liu, D. (eds.) Proceedings of the 4th ACM Workshop on Security of Ad Hoc and Sensor Networks (SASN 2006), pp. 169–176. ACM Press, New York (2006) 35. Scott, M., Szczechowiak, P.: Optimizing multiprecision multiplication for public key cryptography. Cryptology ePrint Archive, Report 2007/299 (2007), http://eprint.iacr.org 36. Seo, S.C., Han, D.-G., Kim, H.C., Hong, S.: TinyECCK: Efficient elliptic curve cryptography implementation over GF(2m ) on 8-bit Micaz mote. IEICE Transactions on Information and Systems E91-D(5), 1338–1347 (2008) 37. Swami, A., Zhao, Q., Hong, Y.-W., Tong, L.: Wireless Sensor Networks: Signal Processing and Communications Perspectives. John Wiley and Sons Ltd., Chichester (2007) 38. Szczechowiak, P., Oliveira, L.B., Scott, M., Collier, M., Dahab, R.: NanoECC: Testing the Limits of Elliptic Curve Cryptography in Sensor Networks. In: Verdone, R. (ed.) EWSN 2008. LNCS, vol. 4913, pp. 305–320. Springer, Heidelberg (2008) 39. Ugus, O., Westhoff, D., Laue, R., Shoufan, A., Huss, S.A.: Optimized implementation of elliptic curve based additive homomorphic encryption for wireless sensor networks. In: Wolf, T., Parameswaran, S. (eds.) Proceedings of the 2nd Workshop on Embedded Systems Security (WESS 2007), pp. 11–16 (2007), http://arxiv.org/abs/0903.3900 40. Uhsadel, L., Poschmann, A., Paar, C.: Enabling Full-Size Public-Key Algorithms on 8-Bit Sensor Nodes. In: Stajano, F., Meadows, C., Capkun, S., Moore, T. (eds.) ESAS 2007. LNCS, vol. 4572, pp. 73–86. Springer, Heidelberg (2007) 41. Wang, H., Li, Q.: Efficient Implementation of Public Key Cryptosystems on Mote Sensors. In: Ning, P., Qing, S., Li, N. (eds.) ICICS 2006. LNCS, vol. 4307, pp. 519–528. Springer, Heidelberg (2006) 42. Xiao, Y., Rayi, V.K., Sun, B., Du, X., Hu, F., Galloway, M.: A survey of key management schemes in wireless sensor networks. Computer Communications 30(11/12), 2314–2341 (2007) 43. Yan, H., Shi, Z.J.: Studying software implementations of elliptic curve cryptography. In: Proceedings of the 3rd International Conference on Information Technology: New Generations (ITNG 2006), pp. 78–83. IEEE Computer Society Press, Los Alamitos (2006) 44. Zhu, S., Xu, S., Setia, S., Jajodia, S.: Establishing pairwise keys for secure communication in ad hoc networks: A probabilistic approach. In: Proceedings of the 11th IEEE International Conference on Network Protocols (ICNP 2003), pp. 326–335. IEEE Computer Society Press, Los Alamitos (2003)

Key Management Schemes for Peer-to-Peer Multimedia Streaming Overlay Networks J.A.M. Naranjo1 , J.A. L´opez-Ramos2 , and L.G. Casado1 1

Dpto. de Arquitectura de Computadores y Electr´ onica Universidad de Almer´ıa, Spain [email protected], [email protected] 2 ´ Dpto. de Algebra y An´ alisis Matem´ atico Universidad de Almer´ıa, Spain [email protected]

Abstract. Key distribution for multimedia live streaming peer-to-peer overlay networks is a field still in its childhood stage. A scheme designed for networks of this kind must seek security and efficiency while keeping in mind the following restrictions: limited bandwidth, continuous playing, great audience size and clients churn. This paper introduces two novel schemes that allow a trade-off between security and efficiency by allowing to dynamically vary the number of levels used in the key hierarchy. These changes are motivated by great variations in audience size, and initiated by decision of the Key Server. Additionally, a comparative study of both is presented, focusing on security and audience size. Results show that larger key hierarchies can supply bigger audiences, but offer less security against statistical attacks. The opposite happens for shorter key hierarchies. Keywords: Conditional access, peer-to-peer networks, key distribution, secret sharing, digital rights management.

1

Introduction

Key distribution schemes designed for live streaming peer-to-peer (P2P) networks can exploit the fact that for a TV channel every peer can share encryption keys while playing the content. This reduces the Key Server workload dramatically. Still, several problems must be addressed: (a) (b) (c) (d) (e)

Peer tracking. Clients churn (clients joining and leaving frequently) and flash crowds. Large audience sizes. Keeping keys private all the way from the Key Server to the last peer. Avoiding illegal key sharing (traitors).

In relation to (a), possible solutions are Gossip Protocols [6] and Distributed Hash Tables [20]. Centralized tracking is not viable for large audience sizes. Regarding (b), churn directly affects quality of service (QoS) in schemes that are event-driven. This kind of schemes perform a rekeying operation whenever O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 128–142, 2009. c IFIP International Federation for Information Processing 2009 

Key Management Schemes for P2P Streaming Overlays

129

a client joins/leaves the channel, to preserve backward and forward privacy (a client should not be able to decrypt the content before and after its subscription period, respectively). A scheme of this kind is presented in [14]. Churn effects depend also on the topology chosen, which can be mesh-like or multi-tree [15][16]. Flash crowds occur at the beginning of high interest events. The Key Server may be overwhelmed by the large amount of join requests. Dealing with this problem is still a challenge. Making the join process as simple as possible helps to reduce flash crowds effects. Audience size, (c), should not be limited by the key distribution method used. The rekeying process usually sets an upper bound for the number of clients that can be served. The most common solution is to divide the audience into groups of users [7][13]. Regarding (d), some solutions have already been proposed. In [14] key distribution is performed on a tree fashion. In this model, each node shares a secret key (KEK: Key Encryption Key) with its children. This key is used to encrypt communications between node and childs. The arrival of a new peer implies setting new KEKs all the way from the peer to the root node. The same process must be carried out when leaving. This may lead to quality of service (QoS) degradation in high churn situations. In [20] key exchange requires the establishment of trust relationships among peers, which implies mutual authentications under a secure channel. This consumes time and bandwidth. Furthermore, the leave operation is complex and involves several communications among the leaving peer, its neighbors and the Key Server. Finally, traitors (e) are an ever-present problem in the industry. Several traitor-tracing solutions exist, such as watermarking [5][23], but still the heart of the matter is unsolved. Probably the solution will come from Trusted Computing techniques [3][1][2]. This paper introduces two key distribution schemes for multimedia streaming peer-to-peer networks that address problems (c) and (d). The first one, Complete Key Distribution Scheme, is an extension to the traditional solution that suits (and takes advantage of) the features of peer-to-peer networks. The second one, Share Based Distribution Scheme, makes use of Secret Sharing techniques and is simpler in the sense that the key distribution process throughout the peer-to-peer network does not require any encryption/decryption. Both schemes employ a key hierarchy that can vary dynamically from 1 to 3 levels in the case of Complete Key and from 1 to 2, in the case of Share Based. The goal of this dynamic variation is to offer a trade-off between security and audience size. Each key hierarchy length suits better a different scenario, depending on the size of the audience. Both schemes also avoid the necessity of key agreements among peers. Briefly, the Complete Key approach consists of the distribution of messages which contain CW s (the key which encrypts the multimedia stream). These messages are named CW − messages. Each CW-message is encrypted with the key in its upper level and distributed throughout the network. On the other hand, in the Share Based approach different CW-messages are generated and

130

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

distributed for each CW . Each message contains a different piece of information called ”share” which is not encrypted. The CW can be reconstructed with a given number of different shares and a token provided by the Key Server. Peers themselves distribute the shares. Problem (b) and (e) are part of our future work lines. Problem (a) is out of the scope of this work. Sections 2 and 3 introduce some preliminary considerations. Sections 4, 5 and 6 present the two schemes and compare them, respectively. Finally, Section 7 discusses the conclusions and future work lines.

2

Scenario

The proposed schemes have been designed for a scenario that is introduced next. The multimedia stream is delivered to the clients by using a peer-to-peer network. A Contents Server injects the stream into the network by connecting to a small set of clients (preferably those with higher bandwidth and lower latency) that start the distribution chain. A Key Server distributes the keys. Distribution of given key is done via the peer-to-peer network or directly via the TLS protocol, depending on the hierarchy level the key belongs to. Constraints regarding overlay topology are very relaxed: it can be either meshlike or multi-tree. The former is better suited by the Complete Key approach. The Share Based approach fits better multi-tree structures. Keys are not multiplexed into the multimedia stream, and there is only one restriction for the stream format. Every data packet is encrypted with a given key, so the key identifier must be included in the packet. This is done to avoid multiplexing of key change messages into the stream at a given rate. Since there is no guarantee that the whole stream will reach every peer, a peer might miss a key change message and decrypt content packets with the wrong key. An integer data type (32 bits) can be used as key identifier: a negligible portion of bandwidth is consumed and quality of service is not affected. Both key distribution schemes run separately from the content network, so they can be deployed easily and on the top of an already operating multimedia peer-to-peer platform without peer tracking or topology restrictions. Audience size measurement can be performed by several means [11], such as probabilistic polling [10], use of epidemic algorithms [9] and random walks [17]. How measures are taken is out of the scope of this paper.

3

A Dynamic Key Hierarchy

Key hierarchies are not new: they have been extensively used in the Digital Video Broadcast business for near two decades now [8][12][22]. TV conditional access systems usually rely on a static hierarchy. The schemes proposed in this paper introduce the possibility of increasing/decreasing the number of levels employed in the hierarchy, depending on the audience size. The smaller the audience is, the shorter the hierarchy is, and vice versa.

Key Management Schemes for P2P Streaming Overlays

131

Adding a new key on top of the hierarchy at a given moment allows refreshing those below more frequently. This is due to the fact that the highest key must be refreshed against the Key Server, but the others can be renewed via the peerto-peer network, as will be shown next. Thus, for high interest events a new key can be introduced on the top. The frequency of the refreshment decreases as we climb on the hierarchy. In addition to this, enlarging the hierarchy allows to supply bigger audiences, since the number of communications against the Key Server decrease dramatically. The problem with large key hierarchies is that the top-level key stands for long periods of time: an attacker has then more time to guess it. Dynamic changes of the key hierarchy seek avoiding this risk when audience size does not require the use of so many key levels. By shortening the hierarchy the top level key is refreshed at a higher rate. The following sections explain how both schemes work, and how key hierarchies are changed dynamically.

4

The Complete Key Distribution Scheme

As mentioned in section 1, the idea behind this approach is to deliver the key that encrypts the stream (named CW for Control Word) in a CW-message by using the peer-to-peer network itself. This scheme suits mesh-like networks gracefully, introducing very little overhead and achieving a good security level, as will be shown later. The key hierarchy length can vary from one to three levels. Next, the three flavors are presented. How to change among them will be explained hereafter. The One-Level flavor is the simplest of the three, and requires contacting the Key Server at a high frequency (within minutes). The Two-Level scheme increases complexity by adding a second level, allowing avoiding contact with the Key Server for hours. Finally, the Three-Level flavor permits a client to play the content for even days without connecting to the Key Server, by adding a third key over the two others. 4.1

One-Level Flavor

The One Level Complete Key approach employs a centralized client-server architecture for distribution of the key that encrypts the stream. This key, CW , is refreshed periodically within seconds or minutes. The refreshment process requires the client to authenticate against the Key Server. CW is sent under a secure protocol such as TLS. Connections are client-server, thus not exploiting the benefits of the peer-to-peer network. For performance enhancement, several successive CW s can be sent in every communication, thus dividing the number of necessary connections to the Key Server by the number of CW s in each message. The simplicity of the refreshment process has a dramatic impact on the audience size for this flavor: only a very small set of clients can be maintained,

132

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

since every client asks the Key Server directly at a very high frequency. Moreover, secure protocols as TLS impose an overhead on communications (time and number of messages). On the contrary, the security level is very high, since high rate refreshment avoids statistical attacks on CW : the impact of an attacker guessing the key at a given time (by brute force or a weakness of the symmetric encryption) is very low. Furthermore, no sensitive information is stored for a long time in the client side. The main risk is the client distributing CW voluntarily. 4.2

Two-Level Flavor

The multimedia stream is encrypted with CW , which is renewed at a high frequency (similar to the One-Level case). CW is no longer distributed via clientserver connections with the Key Server: it is encrypted with SK (Service Key), the second level key in the hierarchy. The result is encapsulated in a CW-message, which is released into the peer-to-peer network. Peers themselves distribute the CW-message as needed. The message may contain several successive refreshments of CW , if desired. This, as mentioned above, enhances performance of the network, but weakens scheme’s security. SK lifetime is in the order of hours: that means that after this time clients must ask the Key Server for a new SK. The request is done under TLS. Due to the introduction of a second key, clients can receive refreshments of CW and decrypt the stream for hours without communicating with the Key Server (there is a small set of clients that communicate constantly with the Key Server, actually: those are the ones which introduce the CW-messages into the peer-to-peer network). Thus, a larger number of clients can be served. What’s more, communications among peers do not suffer from overhead since they are done under a non-encrypted channel (CW-messages are encrypted themselves). Privacy analysis for CW is similar to that shown for the One Level Complete Key approach. The risk of SK being compromised is low, since it is sent to clients under TLS. As in One Level Share Based, an attacker would have to guess the key a reasonable time before it is renewed. Guessing it later would be useless. 4.3

Three-Level Flavor

The Two Level Complete Key approach encrypts the stream with CW , and CW with SK. The present flavor, as can be guessed, employs a new key level to distribute SK. The new key is called T (authorization Token). The Key Server encrypts SK and includes it into a message named SK-message, which is injected into the peer-to-peer network. T is renewed upon days or even weeks via clientserver TLS communications against the Key Server. T ’s large lifetime allows to dramatically increase the period for which a client can decrypt the content without communicating with the Key Server. Hence, very large audiences can be reached by using this flavor, say, tenths of thousands. Security, on the other hand, decreases because of the same reason: an attacker would have several days or even weeks to decrypt T , which would lead to being

Key Management Schemes for P2P Streaming Overlays

133

able to play the content. T ’s lifetime can be adjusted as necessary to make attackers’ life harder (losing audience size, though). 4.4

Changing among Flavors

The Key Server initiates change from one flavor to another when the audience size surpasses a given threshold (audience size can be measured by any of the methods exposed in Section 2). When exceeding, say, several hundreds of clients, the Key Server may decide to change from One-Level flavor to Two-Level flavor. If the expected audience is very large, then the change may be from One-Level to Three-Level directly. The opposite is also valid: when audience decreases sufficiently the Key Server may decide to shorten the key hierarchy. This section explains how these changes are done. The necessary information for a change is included in the CW-messages. That information consists of three fields: the mode in which the system currently run (field Current Level) how many messages of this kind are left before the next hierarchy change (field Left), and which mode will be used then (field Next Level). Hence, a CW-message contains: – One or more successive CW s (not encrypted for One-Level, encrypted with SK for Two and Three-Level). – ”Current Level” field. – ”Left” field. – ”Next Level” field. Joining peers need the field ”Current Level” so they can know the mode the system is running on. Figure 1 shows an example: the system operates in One-Level mode and plans to change to Two-Level mode. The figure depicts the CW-messages generated by the Key Server. The example starts at moment t = 0. Change is finished at moment t = f . Each CW-message contains three CW s. At moment t = 0 the Key Server generates the first CW-message, and an SK-message which contains a brand new SK. When receiving the CW-message under TLS, a client knows that a mode change is happening soon, because of the values in ”Left” and ”Next Level”. Then, the client obtains the SK-message from the Key Server under TLS before t = f . The CW-message at t = m is the last one served under TLS by the Key Server. At moment t = f the client retrieves the CW-message from the peerto-peer network and decrypts its content by using SK. From that moment on the system runs in Two-Level mode, and fields ”Left” and ”Next Level” indicate 0, until a new mode change is started. Instructions for every possible flavor change are detailed in Figure 2. 4.5

Security and Efficiency Considerations for the Complete Key Approach

It is clear that as key hierarchy length increases, audience size follows: this is due to the fact that the major part of the clients only contact the Key Server to

134

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

Fig. 1. Mode change from One-Level to Two-Level. A valid SK-message must be obtained by the client between t = 0 and t = f .


  
 
 
 


    

    





    

    

    

 



      

 


    

    


  
 

 

Fig. 2. Mode changes for the Complete Key Approach from clients’ view. The process starts at t=0 and ends at t=f.

refresh the highest key (SK in Two-Level and T in Three-Level). The higher the key is, the longer its lifetime, hence less connections are required. Furthermore, to avoid bottlenecks when changing the highest key, requests for it can be made at a random moment before expiration of the current one. If requests from other peers follow a uniform distribution then a homogeneous requests rate will be obtained. This makes workload for the Key Server more bearable. Security is based in symmetric encryption for key distribution within the peerto-peer network and in TLS communications with the Key Server. If keys are generated in a secure way then it will be very difficult for an attacker to break a key in a time short enough to get some benefit out of it. However, having keys with long lifetime has its drawbacks: if the key on top is compromised, then the attacker will gain access to the content for a long time.

Key Management Schemes for P2P Streaming Overlays

135

What’s more, the attacker may share the content and the key with others. That is why it is important (1) to adjust keys’ lifetimes as tight as possible and (2) to keep the system running in a mode as low as possible in the three flavors range. The use of a dynamic key hierarchy provides more security to key distribution if flavor changes are planned smartly on the Key Server side.

5

The Share-Based Key Distribution Scheme

The problem with the Complete Key Distribution approach is that its One-Level flavor can only be used for tiny audience sizes. TLS communications consume time and resources and only a little set of clients can be supplied using the One-Level flavor. This is not useful. The Share-Based is similar to the Complete Key scheme mentioned above but differs in the fact that it makes use of secret sharing techniques to perform key distribution. Due to this, the scheme shows some desirable features: – The dynamic key hierarchy presents two flavors, instead of three, but can reach similar audience sizes than the Complete Key approach. – The key distribution process requires very little computational effort, at the price of very little overhead. This is very convenient for small devices, such as smart phones or PDAs. – It naturally suits multi-tree overlay topologies. Secret sharing can be defined as follows: To distribute a secret S in n shares, needing t ≤ n shares to reconstruct it, and being this impossible with a number of shares below t (threshold). The Shamir Threshold Secret Sharing Scheme is the most popular among the several existing secret sharing methods. A detailed description can be found in [19][21]. The present scheme uses Secret Sharing to refresh CW . Here, one of the shares is given a higher weight than the others, and CW cannot be reconstructed without it. We have named this “important share” M S (Master Secret) and the “regular shares”, SS (Secondary Shares). M S stands for several hours, and CW is refreshed by renewing the different SSs. How M S is refreshed depends on the flavor. More details are given next. 5.1

One-Level Flavor

The One Level Share Based approach employs more information pieces than its Complete Key counterpart, but is still one-level in the sense that only a key is distributed. The stream is encrypted with a key called CW , which is refreshed at a frequency within seconds or minutes. The distribution of CW is accomplished by making use of a secret sharing method as follows. For each refreshment of CW

136

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

the Key Server generates as many shares as desired and includes them (without encryption) in separate messages, which are injected into the peer-to-peer network. The shares are named SSs: Secondary Shares. We call the messages that contain them SS-messages. Peers (clients) ask the network for SS-messages and resend them as needed. By collecting a minimum number of SSs (this number is called threshold) a subkey can be generated by using secret sharing. This subkey receives the name of P S Partial Share. The Key Server may generate and inject as many SSs as desired. Note that SS-messages and hence SSs are not encrypted and can be known publicly. On the other hand, every peer authenticates against the Key Server and receives via TLS a piece of information named M S (Master Share), which must remain secret to outsiders. CW can be computed by means of a one-way function (we name it F ) that takes as input a combination of M S and P S. F is not defined in this paper, and can be designed as desired. It should be complex enough, though, to prevent brute force attacks against M S. Refreshment rate of M S is within hours. This reduces the number of requests the Key Server must attend, hence allowing audience size to rise, say to thousands of clients. Privacy of CW is achieved by keeping secret M S and refreshing it. Security against brute force attacks against CW is achieved by refreshing SS and, therefore P S. The global security of the system depends on the robustness of the F function. If an attacker cannot guess M S a reasonable time before it is refreshed then this scheme can be considered secure enough. M S lifetime can be adjusted as necessary for this purpose. Risk and impact of directly compromising CW is low due to the high refreshment rate. Figure 3 shows the composition and origin of every piece of information involved.










 





 

Fig. 3. Secret sharing for t = 3, channel i

5.2

Two-Level Flavor

This flavor allows the Share Based approach to reach a larger audience. CW encrypts the stream. It is distributed in the same manner as in the One-Level

Key Management Schemes for P2P Streaming Overlays

137


   

  

    




 


    

    

Fig. 4. Mode changes for the Share-Based Approach from clients’ view. The process starts at t=0 and ends at t=f.

flavor. The novelty consists of distributing M S throughout the peer-to-peer network: the Key Server encrypts M S with a new level key, named T (authorization Token), and the result is injected into the network inside a new type of message, namely MS-message. Peers distribute it as necessary. M S’s lifetime is still of several hours. T is renewed under TLS against the Key Server. Its lifetime is in the order of days. T ’s large lifetime allows to increase dramatically the period for which a client can decrypt the content without communicating with the Key Server. Hence, very large audiences can be reached by using this flavor. Security, on the other hand, decreases because of the same reason: an attacker would have several days or even weeks to try to compromise T , which would lead to being able to play the content. T ’s lifetime can be adjusted as necessary to make attackers’ life harder (though losing audience size). Additionally, function F must be carefully chosen. 5.3

Changing among Flavors

Flavor change is performed when audiences exceeds (or goes under) a given threshold. The change is carried out in the same way than in Section 4.4: when informing about next change the necessary information is included in SS-message fields “Left” and “Next Level”. Next we show how changes are done. Figure 4 depicts the details of flavor changing. We assume that the first notification occurs at moment t = 0 and change ends at t = f . 5.4

Security and Efficiency Considerations for the Share-Based Approach

Regarding efficiency, this scheme shows several advantages. First, the refreshment process requires very little computational resources: if Reed-Solomon codes are used then P S can be calculated by means of a Fast Fourier Transform, which

138

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

is computed efficiently at a very low computational cost [4][18]. Furthermore, the fact that SS-messages are not encrypted helps in that sense too. If M S has not expired for a peer, gathering each SS only requires a communication: request and response. This speeds communications up. By appropriately adjusting the threshold (the minimum number of SS-messages needed to compute CW ) and the number of successive updates of CW that can be calculated with t SS-messages (that is, the number of successive shares included in each SSmessage), keys for a long playing time can be obtained without communicating with the Key Server. Updates of M S are far apart in time and peers can ask for it with anticipation for subscription channels, making the requests rate follow a uniform distribution. This allows the Key Server to attend a bigger number of clients, favoring scalability of the net. Additionally, the update does not depend on arrivals or leavings of peers. Another important advantage is the possibility for peers to be members of many peer-to-peer networks, each one for a different multimedia channel. Peers can even serve SS-messages and MS-messages for channels they are not subscribed to: possessing only the SSs for a channel does not allow to regenerate a valid CW , and MS-messages are encrypted with their corresponding T . Regarding security, considerations are similar to those of section 4.5. However, there is one important difference: CW refreshment is carried out by means of a secret sharing technique and function F . Sharing techniques are secure enough to not to be worried about [19][21], but F should be chosen very carefully. If a hash function is involved, then its output should be long enough to withstand bruteforce attacks for a period of time similar at least to SK’s lifetime. Signature of every CW-message and MS-message may be also implemented to avoid denialof-service attacks. We believe that security considerations make inappropriate the addition of a third level key to the Share Based approach. Anyway, if desired, a new key could be added to encrypt and distribute T . Its lifetime could be in the order of a month. The DVB industry has battled with the set-top box key theft problem for years, still a reliable and durable solution has not been found. The more time an attacker has to study a key, the easier will be guessing and sharing it.

6

Comparison of Complete Key Distribution Scheme and Share-Based Key Distribution Scheme

Table 1 sums up both schemes, focusing on audience size and security against fraud. Each flavor is assigned a security level based on the risk of key compromise and its consequences. The best suited scenario is also assigned. Figures 5 and 6 compare ideal reachable audience size and security for both schemes. The main conclusion that can be extracted is that each Share-Based flavor can supply similar audience sizes than the Complete Key approach, employing a shorter key hierarchy. On the other hand, the Complete Key method offers more security. Therefore, Complete Key should be used for small and medium audience

Key Management Schemes for P2P Streaming Overlays

139

Table 1. Comparison of all flavors

Complete Key Keys: CW (secs, mins) Dependence on Key Server: very high Audience size: very low (≈ 0.1 K clients?) One-Level Security: high CW compromise risk: very low CW compromise impact: very low Scenario: small videoconferences Keys: CW (secs, mins); SK (hours) Dependence on Key Server: medium Audience size: medium (≈ 1 K clients?) Security: medium-high CW compromise risk: very low Two-Level CW compromise impact: very low SK compromise risk: medium SK compromise impact: high Scenario: large videoconferences, event broadcasting Keys: CW (secs, mins); SK (hours); T (days, weeks) Dependence on Key Server: very low Audience size: high (≈ 10K clients?) Security: medium CW compromise risk: very low Three-Level CW compromise impact: very low SK compromise risk: medium SK compromise impact: high T compromise risk: medium T compromise impact: very high Scenario: great interest event broadcasting, P2PTV

Share-Based

One-Level

Two-Level

Keys: CW (secs, mins); {M S (hours), SS (secs, mins)} Dependence on Key Server: low Audience size: medium (≈ 1 K clients?) Security: medium-high CW compromise risk: low CW compromise impact: low M S compromise risk: medium M S compromise impact: high Scenario: large videoconferences, event broadcasting Keys: CW (secs, mins); {M S (hours), SS (secs, mins)}; T (days, weeks) Dependence on Key Server: very low Audience size: high (≈ 10 K clients?) Security: medium CW compromise risk: low CW compromise impact: low M S compromise risk: medium M S compromise impact: high T compromise risk: medium T compromise impact: very high Scenario: great interest event broadcasting, P2PTV

140

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

Fig. 5. Comparison of both schemes regarding audience size

Fig. 6. Comparison of both schemes regarding security

scenarios and Share-Based for very large ones. We believe, also, that the ShareBased is more appropriate for set-top boxes, since these devices incorporate less computational capacities.

7

Conclusions and Future Work

This paper introduces two novel key distribution schemes for live multimedia peer-to-peer overlays, which share a common new feature: the possibility of dynamically changing the number of levels in the key hierarchy. This is motivated by the fact that the larger the key hierarchy is, the more audience can be supplied, but the more time the highest level key is exposed. Hence, the key hierarchy

Key Management Schemes for P2P Streaming Overlays

141

employed should be shortened whenever possible. However, it can be enlarged if audience size requires it. The first scheme introduced, the Complete Key Distribution Scheme, is simple and direct. It fits scenarios where a low exposure time is required for keys, preferably on top of mesh-like topologies. The second one, the Share-Based Key Distribution Scheme, is similar to the Complete Key scheme, but employs a Secret Sharing technique to refresh the lowest level key. It suits better multitree topologies and high audience scenarios, while needing little computational power. This last feature makes it more appropriate for set-top boxes. Additionally, the Share-Based approach outperforms Complete Key because it requires less hierarchy levels and computational cost. On both schemes, a smart key hierarchy level adjustement will adjust the higher level key exposure time to the minimum possible, depending on audience size. Our plans for the near future are to implement and test both schemes in a peer-to-peer simulator and to study a more efficient top level key distribution to address the problem of receiving a large number of requests produced by flash crowd situations. Additionally, it is interesting to consider a fusion of both schemes (not covered in this paper): the Complete Key One-Level and TwoLevel flavors might be used for small and medium-size audiences, while the Share-Based Two-Level flavor would be employed for larger audiences.

Acknowledgements This work has been partially funded by grants from the Spanish Ministry of Science and Innovation (TIN2008-01117), Junta de Andaluc´ıa (P06-TIC-1426, P08TIC-3518, FQM 0211 and TEC2006-12211-CO2-02), and the European Regional Development Fund (ERDF).

References 1. Aciicmez, O., Seifert, J.-P., Zhang, X.: A secure DVB set-top box via trusting computing technologies. In: Consumer Communications and Networking Conference (2009) 2. Balfe, S., Gallery, E., Mitchel, C., Paterson, K.: Challenges for trusted computing. In: Security & Privacy. IEEE, Los Alamitos (2008) 3. Balfe, S., Lakhani, A., Paterson, K.: Trusted computing: providing security for peer-to-peer networks. In: Fifth IEEE International Conference on Peer-to-Peer Computing (2005) 4. Blahut, R.E.: A universal Reed-Solomon decoder. IBM Journal of Research and Development 28(2), 150–158 (1984) 5. Eskicioglu, A.M.: Multimedia security in group communications: recent progress in key management, authentication, and watermarking. Multimedia Systems 9(3), 239–248 (2003) 6. Ganesh, A.J., Kermarrec, A.-M., Massouli´e, L.: Peer-to-peer membership management for gossip-based protocols. IEEE Transactions on Computers 52(2) (2003)

142

J.A.M. Naranjo, J.A. L´ opez-Ramos, and L.G. Casado

7. Huang, Y.-L., Shieh, S., Ho, F.-S., Wang, J.-C.: Efficient key distribution schemes for secure media delivery in pay-tv systems. IEEE Transactions on Multimedia 6(5), 760–769 (2004) 8. International Teleommunication Union. ITU-R Rec. BT.810. Conditional-Access broadcasting systems (1992) 9. Jelasity, M., Montresor, A.: Epidemic-style proactive aggregation in large overlay networks. In: ICDCS 2004: Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS 2004), pp. 102–109. IEEE Computer Society, Los Alamitos (2004) 10. Kostoulas, D., Psaltoulis, D., Gupta, I., Birman, K., Demers, A.: Decentralized schemes for size estimation in large and dynamic groups. In: NCA 2005: Proceedings of the Fourth IEEE International Symposium on Network Computing and Applications, pp. 41–48. IEEE Computer Society, Los Alamitos (2005) 11. Le Merrer, E., Kermarrec, A.-M., Massoulie, L.: Peer to peer size estimation in large and dynamic networks: A comparative study, pp. 7–17 (2006) 12. Lee, W.: Key distribution and management for conditional access system on DBS. In: Proc. of international conference on cryptology and information security, pp. 82–86 (1996) 13. Liu, B., Zhang, W., Jiang, T.: A scalable key distribution scheme for conditional access system in digital pay-tv system. IEEE Transactions on Consumer Electronics 50(2) (2004) 14. Liu, X., Yin, H., Lin, C., Deng, Y.: Efficient key management and distribution for peer-to-peer live streaming system, pp. 638–641 (2007) 15. Liu, Y., Guo, Y., Liang, C.: A survey on peer-to-peer video streaming systems. Peer-to-Peer Networking and Applications 1(1) (2008) 16. Magharei, N., Rejaie, R., Guo, Y.: Mesh or multiple-tree: A comparative study of live P2P streaming approaches. In: INFOCOM 2007 (2007) 17. Massouli´e, L., Le Merrer, E., Kermarrec, A.-M., Ganesh, A.: Peer counting and sampling in overlay networks: random walk methods. In: PODC 2006: Proceedings of the twenty-fifth annual ACM symposium on Principles of distributed computing, pp. 123–132. ACM, New York (2006) 18. McEliece, R.J., Sarwate, D.V.: On sharing secrets and Reed-Solomon codes. Communications of the ACM 24(9) (1981) 19. Menezes, A.J., Oorschot, P.C.V., Vanstone, S.A., Rivest, R.L.: Handbook of applied cryptography (1997) 20. Qiu, F., Lin, C., Yin, H.: EKM: An efficient key management scheme for large-scale peer-to-peer media streaming. In: Zhuang, Y.-t., Yang, S.-Q., Rui, Y., He, Q. (eds.) PCM 2006. LNCS, vol. 4261, pp. 395–404. Springer, Heidelberg (2006) 21. Schneier, B.: Practical Cryptography. Wiley & Sons, Chichester (2003) 22. Tu, F., Laih, C.S., Tung, H.H.: On key distribution management for conditional access system on pay-tv system. IEEE Transactions on Consumer Electronics 45, 151–158 (1999) 23. van der Veen, M., Lemma, A.N.: Electronic content delivery and forensic watermarking. Multimedia Systems 11(2), 174–184 (2005)

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks for Monitoring Linear Infrastructure Keith M. Martin and Maura B. Paterson Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX, U.K. {keith.martin,m.b.paterson}@rhul.ac.uk

Abstract. One-dimensional wireless sensor networks are important for such security-critical applications as pipeline monitoring and perimeter surveillance. When considering the distribution of symmetric keys to secure the communication in such networks, the specific topology leads to security and performance requirements that are markedly distinct from those of the more widely-studied case of a planar network. We consider these requirements in detail, proposing a new measure for connectivity in one-dimensional environments. We show that, surprisingly, optimal results may be obtained through the use of extremely lightweight key predistribution schemes. Keywords: wireless sensor networks; key management; one-dimensional networks.

1

Introduction

The classical view of a wireless sensor network (WSN) is one of thousands of sensor nodes with a random physical distribution, such as would result from the nodes being scattered from an aeroplane. In practice, however, the specific sensing requirements of a given application impose a topology on the network that may differ significantly from this standard picture [12]. One example is the case of a one-dimensional network, in which the sensors are arranged in a line or ring. Topologies of this sort arise naturally from applications such as pipeline monitoring or perimeter surveillance, where it is necessary to take measurements at regular intervals along a lengthy piece of infrastructure. Security is important for such applications, hence it is desirable to use cryptographic techniques to secure the wireless communication. Symmetric primitives provide a less computationally intensive solution than public-key techniques, but they require the sensor nodes to share common keys. Key predistribution schemes (KPSs) are a widely-studied means of providing shared keys to the nodes [1,8,15]. However, most widely studied KPSs such as 

This author was supported by EPSRC grant EP/D053285/1.

O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 143–152, 2009. c IFIP International Federation for Information Processing 2009 

144

K.M. Martin and M.B. Paterson

that of Eschenauer and Gligor [2] are designed for planar networks, whose properties are very different to those of a network with a one-dimensional topology. Nodes in a one-dimensional network are likely to have fewer neighbours (that is, nodes that lie within communication range of them) on average and the pattern of communication within the network will be quite different. Also, it is reasonable to suppose that the location of the sensors will be known, at least up to the order in which they occur along the network. In turn, the security requirements of a KPS for such a network are not the same as in the planar case. In particular, maintaining network connectivity is critical in one-dimensional networks, as we will demonstrate. The main contribution of this paper is the identification of the precise requirements a KPS for a one-dimensional WSN, and the observation that it is possible to achieve these properties through the use of schemes with very low storage requirements. In Sect. 2 we discuss applications for one-dimensional WSNs. In Sect. 3 we consider the properties of such networks in detail, and in Sect. 4 we see that this leads to security and performance requirements that are markedly different from those of the classical scenario, particularly with respect to the connectivity of the network. We introduce a new measure, the s-fallibility, that more closely models the desirable connectivity properties of a KPS for a onedimensional network. In Sect. 5 we examine how the s-fallibility of the network is affected by the communication range of the sensors, and in Sect. 6 we propose a key predistribution scheme that gives optimal s-fallibility with very low storage requirements. The advantages of such schemes are summarised in Sect. 7.

2

Applications Requiring the Use of One-Dimensional WSNs

The monitoring of an extended piece of infrastructure, such as a pipe, lends itself to the use of a one-dimensional sensor network. Pipelines carrying oil, gas or water are critical both in terms of their commercial importance and their impact on national security. Reasons for monitoring such pipelines include the detection of leaks, the measurement of seismic activity that has the potential to damage pipes, or the detection of malicious activities such as sabotage or deliberate theft of pipes or their contents. In any context there are advantages to using a wireless (as opposed to wired) network of sensors, such as greater ease of deployment and maintenance of the network. In the one-dimensional scenario, however, even stronger arguments for using a wireless network are provided by consideration of the reliability of the network. An attacker who cuts through the wire can entirely disrupt communication in a conventional network with linear topology. The use of multiple wires complicates the design and deployment of a network, and will not necessarily make it harder for an adversary to disconnect it. An appropriately designed wireless network, on the other hand, can withstand the loss of several sensors

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks

145

without losing connectivity. In the literature there are several proposals for the use of WSNs in such a context [3,4,10,11,13]. Similar considerations also apply to the monitoring of other types of linear infrastructure such as bridges or railway tracks. A related application that leads naturally to the use of one-dimensional WSNs is that of perimeter surveillance (e.g. [14]). For example, sensors may be deployed for monitoring the condition of a fence, or for intrusion detection on the boundary of an unfenced region. The resulting networks differ from those required for pipeline monitoring in that the sensors are arranged in a ring, rather than in a line. In Sect. 6.1 we consider how this affects considerations of connectivity in such networks. Various practical aspects of the performance of one-dimensional ad hoc networks have been studied [6,7,9,16,17]. However, the security of the communications in such networks has received comparatively little attention. In Secs. 3 and 4 we discuss how the properties of these networks lead to quite specific security requirements when considering the performance of key predistribution schemes.

3

Characteristics of One-Dimensional Sensor Networks

The properties of a one-dimensional WSN differ substantially from those of the two-dimensional analogue. Here we examine those properties that are particularly relevant to the design of KPSs. Restricted number of neighbours: If we assume that each node has a particular communication range r, then for a given density of node deployment, the number of nodes within communication range of a sensor in a planar network is proportional to r2 . In a one-dimensional network, however, this number is proportional to r. Location knowledge: It is possible to consider two-dimensional networks in which there are differing degrees of a priori information about the nodes’ locations, ranging from none at all, up to complete knowledge (see [8], for example). In the one-dimensional case it is reasonable to assume that the order in which the nodes occur along the network is known, since they are likely to be deployed sequentially along the object being monitored. In particular, this implies that the neighbours of each particular node are known with high probability prior to deployment. Pattern of communication: In a one-dimensional network, information is constrained to flowing back and forth along the network. This has particular implications for aspects such as the capacity of the network [7], and the design of routing algorithms [17,16]. Density of node deployment: Depending on the quantities that are being measured by the sensors, it is likely that density of node deployment required to ensure adequate sensing coverage will exceed the density required for the wireless network to be connected.

146

4

K.M. Martin and M.B. Paterson

Security Considerations for Key Distribution in One-Dimensional Sensor Networks

When evaluating the performance of a KPS for a WSN, we are generally interested in the trade-off it provides between storage requirements, network connectivity, and resilience in the face of an adversary that can eavesdrop on all network traffic, as well as capture a certain number of nodes and extract any keys they contain. It is common to measure the connectivity in terms of the probability Pr1 that two neighbouring nodes share a key, and the resilience in terms of the proportion of link keys that are compromised when a given number of nodes are captured at random [2,5]. In the case of a one-dimensional WSN, the combination of nodes having a small number of neighbours with the fact that the expected neighbours are known prior to deployment suggests that it may be feasible to employ a KPS that assigns a distinct key to each pair of neighbouring nodes; we refer to this as the local pairwise KPS. This scheme has the advantage of having an optimal value of Pr1 (since any two neighbours share a key with probability 1) and optimal resilience (since any key is shared by just two nodes, and thus the compromise of a node does not expose keys that pairs of uncompromised nodes rely on for communication). Nevertheless, this is not the end of the story for key predistribution in onedimensional WSNs. The quantity Pr1 is useful in that it provides a means of comparing in some sense the relative network connectivity achieved by KPSs in the case of a planar network with no location knowledge, where the formulation of absolute measures of connectivity is problematic. However, in the one-dimensional case, our detailed knowledge of the network topology enables us to quantify more precisely the connectivity behaviour that is desirable from the point of view of network functionality, in terms of a quantity we refer to as the s-fallibility of the network. We will see that while the local pairwise KPS performs well with respect to this measure, there exist schemes that perform equally well, yet require less storage. In what follows, we assume our network consists of n identical nodes arranged in a line at regularly spaced intervals (in Sect. 6.1 we will consider how the situation changes if the nodes lie in a ring.) We suppose each node can communicate with all nodes located within distance r (where the distance between two adjacent nodes is taken to be 1). We restrict our attention to KPSs in which each key is shared by at most two nodes, as this provides optimal resilience. Furthermore, we focus on KPSs that can be used to distribute keys to networks with arbitrarily large values of n: the available location knowledge makes it possible to avoid assigning shared keys to pairs of nodes that are not within communication range, and hence extending a scheme to a large number of nodes does not adversely affect the storage requirements of any given node. Finally, instead of considering only adversaries that capture nodes at random, we analyse resistance against a “worst-case” adversary that chooses which nodes to capture based on the amount of damage it can do to the network.

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks

147

Sensor nodes are small, cheap devices that are deployed with sufficient density that the performance of the network is not affected if a number of them fail. Thus the loss of a small number of sensors through adversarial capture is not in itself critical. However, it becomes a serious problem if the adversary is able to capture nodes in such a way as to prevent large sections of the network from communicating with each other. We formalise this notion in the following definition. Definition 1. Two disjoint sets S1 and S2 of nodes in a one-dimensional WSN are isolated from each other if no node in S1 is in range of and shares an uncompromised key with a node in S2 . Example 1. Consider the network given by the following diagram, in which dots represent nodes and lines connect nodes that share a key:

The capture of the white node and compromise of the corresponding keys isolates the set of black nodes on the left from the set of black nodes on the right, as none of the leftmost three nodes shares a key with any of the rightmost three nodes. Example 2. Consider a one-dimensional network in which the nodes are labeled 0, 1, 2, . . . in turn. If each node with label i shares a key with the nodes labelled i + 2 and i − 2 then the set of nodes with odd labels is isolated from the set of nodes with even labels. 0

2 1

4 3

6 5

8 7

9

In a network where each node stores k keys, then an adversary can always isolate a single node Ψ from the rest of the network by capturing up to k other nodes that between them possess all the keys stored by Ψ . However, it could be argued that the adversary could achieve the same effect more easily by simply capturing Ψ directly. Hence the standard graph-theoretic notion of vertex connectivity does not quite serve to measure how well a KPS for a one-dimensional network stands up to node compromise. The exclusion of a small number of nodes from the rest of the network is not a major source of concern, however the partitioning of a network into two halves that cannot communicate with each other is a serious problem. In order to give a more practical measure of the extent to which an adversary can damage a network in which the KPS is deployed, we define the s-fallibility of a KPS to be the smallest number of nodes an adversary has to capture in order to cause a catastrophic failure in the connectivity of the network. Consider a KPS that can be applied to a one-dimensional network of n of nodes (where n can be made arbitrarily large). If the KPS is s-fallible, then an adversary who captures at most s−1 nodes can only isolate a small (i.e. constant with respect to n) number of nodes from the rest of the network, whereas an

148

K.M. Martin and M.B. Paterson

adversary who captures s nodes can partition the network into two (or more) large sets of nodes that are isolated from each other. We formalise the definition of s-fallibility as follows: Definition 2. A KPS for a one-dimensional network consisting of a set N of n nodes, where n is arbitrary, is s-fallible if the following two conditions hold: 1. After the capture of any s − 1 nodes, there exists a set E ⊂ N of size at most O(1) such that N \ E is connected. 2. It is possible to choose s nodes whose capture partitions the network into two (or more) isolated networks of size Ω(n). For example, the KPS in which each node shares a key with the two immediately adjacent nodes (as illustrated in Example 1) is (trivially) 1-fallible, since if no nodes are captured the network is connected, yet it suffices to capture a single node from the centre of the network to partition the network into two isolated networks of size ≈ n/2. We note that in general a KPS that yields a connected network prior to any node capture is necessarily s-fallible for some s ≥ 1, and hence this quantity is well-defined for any scheme of practical interest. We are interested in KPSs that are s-fallible for as high a value of s as possible. In Sect. 5 we consider factors affecting the fallibility, and provide upper bounds on the s-fallibility that can be achieved for given network parameters.

5

Bounding the s-Fallibility of KPSs for Linear One-Dimensional WSNs

The communication range of the nodes affects the number of neighbours they have. It is unsurprising, therefore, that it should have an effect on the s-fallibility. Theorem 1. If a KPS for a one-dimensional WSN in which the nodes have communication range r yields a connected network, then it is s-fallible for some 1 ≤ s ≤ r. Proof. If a KPS leads to a connected network, then it is s-fallible for some s ≥ 1. Suppose an adversary captures r adjacent nodes from the centre of the network. Then no uncaptured node in the “left-hand half” of the network is within communication range of any node in the “right-hand half,” and hence the network consists of two isolated components each of size ≈ (n − r)/2, as shown in the following diagram. — out of range —

Thus, for a KPS deployed in a specific network to be s-fallible, it is necessary (although not sufficient) for the communication range of the nodes to be at least s. In fact this condition can be strengthened, as shown by the following theorem.

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks

149

Theorem 2. Suppose a KPS that yields a connected network assigns keys to nodes such that the largest distance between two nodes that share a key is b. Then it is s-fallible for some 1 ≤ s ≤ b. Proof. As above, consider an adversary that captures b adjacent nodes from the centre of the network. By construction, no node in the “left-hand half” of the network shares a key with any node in the “right-hand half”, as shown below. — no shared keys —

Thus we see that a KPS can be at most r-fallible, and that for this to be the case the KPS must assign shared keys to pairs of nodes at distance r. There do exist r-fallible schemes: one example is the local pairwise KPS1 . This scheme requires each node to store 2r keys. However, we will show in Sect. 6 that r-fallibility can in fact be achieved using storage that is independent of both r and n.

6

An Ultra-Lightweight KPS Providing Optimal s-Fallibility

By an extension of the proof of Theorem 2, we can see that for a KPS to achieve r-fallibility, it is necessary for each pair of nodes at distance r to share a key (except perhaps for a constant (with respect to n) number of pairs at either end of the network). However, this alone does not provide r-fallibility, since this distribution results in a network consisting of r isolated sets of (n/r) nodes (as was the case in Example 2 for r = 2). In order to achieve r-fallibility, it is necessary to introduce more keys into the network. The following construction leads to the surprising result that it is possible to obtain r-fallibility when each node stores only four keys. Construction 1. Assign keys to the nodes of a one-dimensional network such that each node shares unique pairwise keys with each of the nodes at distance r and 1. Example 3. If Construction 1 is applied to a one-dimensional network with twenty nodes for which r = 3, then the nodes share keys as illustrated by the following diagram.

1

The addition of extra pairwise shared keys to a KPS will evidently not decrease its s-fallibility, and may even increase it. As the local pairwise scheme ensures that every pair of nodes within communication range shares a key, you would thus expect its s-fallibility to be as high, or higher, than that of any other scheme. The fact that it is indeed r-fallible is a direct consequence of our proof of Theorem 3.

150

K.M. Martin and M.B. Paterson

Theorem 3. The KPS of Construction 1 is r-fallible. Proof. Let the nodes of the network be labeled sequentially by the integers 0, 1, . . . , n − 1. Suppose an adversary captures r − 1 nodes from the network and extracts the keys they contain. Let Ψ1 and Ψ2 be two nodes that occur at distance at least r + 1 from any captured node; without loss of generality we suppose the label of Ψ1 is greater than that of Ψ2 . None of their keys are known to the adversary. As the number of captured nodes is r − 1, there must be some integer x with 0 ≤ x ≤ r − 1 such that no node with a label equivalent to x (mod r) has been captured. Then a secure path from Ψ1 to Ψ2 can be found as follows: 1. Take hops of length one from Ψ1 towards Ψ2 until a node whose label is equivalent to x (mod r) is reached. This requires at most r − 1 hops, hence each of these hops is secure by the assumption that no captured node lies within distance r + 1 of Ψ1 . 2. Take hops of length r towards Ψ2 until a node at distance less than r from Ψ2 is reached. As the keys required for these hops all belong to nodes whose label is equivalent to x (mod r), none of them is known to the adversary. 3. Finally, complete the path by hops of length one until Ψ2 is reached. The fact that no captured node lies within distance r + 1 of Ψ2 implies these are also secure. The number of nodes within distance r + 1 of a captured node is at most 2(r + 1)(r − 1); this does not depend on n. Hence we have shown that no matter which r − 1 nodes are compromised, it is possible to exclude a constant (with respect to n) number of nodes such that the remaining nodes form a connected network, and thus the s-fallibility of this scheme is at least r. Together with Theorem 1, this shows that this KPS is in fact r-fallible. 6.1

Lightweight Key Predistribution for Ring Topologies

The scheme of Construction 1 can also be applied directly to one-dimensional networks where the sensors are arranged in a ring. For instance, for a network of twenty nodes with r = 3, the pattern of key sharing can be depicted as follows:

Ultra-Lightweight Key Predistribution in Wireless Sensor Networks

151

The behaviour of a ring network with respect to s-fallibility is slightly different to a linear network. An adversary has to “cut” the network twice in order to disconnect it; the first cut essentially turns it from a ring network to a linear network. It is debatable as to what is the most useful definition of fallibility in this scenario, since for a large ring making even a single “cut” greatly increases the average number of hops required for two nodes to communicate. In any case, the proof of Theorem 3 can be adapted for the case of a ring network, hence we can argue that the security of the KPS of Construction 1 is at least as strong when it is applied to a ring network as when it is used in a linear network. Hence this scheme is also suitable for networks designed for perimeter surveillance and other such application.

7

Conclusion

We have seen that the topology of a one-dimensional network affects its potential connectivity, due to the restricted number of neighbours posessed by each node. This leads to the unexpected result that the KPS given in Construction 1 performs as well as the local pairwise KPS in terms of both connectivity and resilience, despite requiring each node to store only four keys. To summarise, the advantages of this scheme include the following: – optimal resilience; – optimal s-fallibility; – very low storage. In short, this scheme is thus ideal for use in WSNs for monitoring linear infrastructure, no matter how constrained the memories of the nodes.

Acknowledgements We would like to thank the referees for their helpful suggestions for improving the clarity of this paper.

References 1. C ¸ amtepe, S.A., Yener, B.: Key distribution mechanisms for wireless sensor networks: a survey. Rensselaer Polytechnic Institute, Computer Science Department, Technical Report TR-05-07 (March 2005) 2. Eschenauer, L., Gligor, V.D.: A key-management scheme for distributed sensor networks. In: CCS 2002: Proceedings of the 9th ACM conference on Computer and communications security, pp. 41–47. ACM Press, New York (2002) 3. Jawhar, I., Mohamed, N., Shuaib, K.: A framework for pipeline infrastructure monitoring using wireless sensor networks. In: Wireless Telecommunications Symposium, pp. 1–7 (2007)

152

K.M. Martin and M.B. Paterson

4. Jawhar, I., Mohamed, N., Shuaib, K., Kesserwan, N.: Monitoring linear infrastructures using wireless sensor networks. In: The 2008 IFIP Conference on Wireless Sensor and Actor Networks (WSAN 2008), vol. 264, pp. 185–196. Springer, Heidelberg (2008) 5. Lee, J., Stinson, D.R.: On the construction of practical key predistribution schemes for distributed sensor networks using combinatorial designs. ACM Transactions on Information and System Security 11(2), 1–35 (2008) 6. L´evˆeque, O., Preissmann, E.: Scaling Laws for One-Dimensional Ad Hoc Wireless Networks. IEEE Transactions on Information Theory 51(11), 3987–3991 (2005) 7. Liu, B., Thiran, P., Towsley, D.: Capacity of a wireless ad hoc network with infrastructure. In: MobiHoc 2007: Proceedings of the 8th ACM international symposium on Mobile ad hoc networking and computing, pp. 239–246. ACM, New York (2007) 8. Martin, K.M., Paterson, M.B.: An application-oriented framework for wireless sensor network key establishment. Electronic Notes in Theoretical Computer Science 192(2), 31–41 (2008) 9. Miorandi, D., Altman, E.: Connectivity in one-dimensional ad hoc networks: a queueing theoretical approach. Wireless Networks 12(5), 573–587 (2006) 10. Mohamed, N., Jawhar, I.: A fault tolerant wired/wireless sensor network architecture for monitoring pipeline infrastructures. In: International Conference on Sensor Technologies and Applications, pp. 179–184 (2008) 11. Mohamed, N., Jawhar, I., Shuaib, K.: Reliability challenges and enhancement approaches for pipeline sensor and actor networks. In: Arabnia, H.R., Clincy, V.A. (eds.) ICWN, pp. 46–51. CSREA Press (2008) 12. R¨ omer, K., Mattern, F.: The design space of wireless sensor networks. IEEE Wireless Communications Magazine 11(6), 54–61 (2004) 13. Stoianov, I.: Pipenet: A wireless sensor network for pipeline monitoring. In: IPSN 2007, pp. 264–273. ACM, New York (2007) 14. Wittenburg, G., Terfloth, K., Villafuerte, F.L., Naumowicz, T., Ritter, H., Schiller, J.H.: Fence monitoring – experimental evaluation of a use case for wireless sensor networks. In: Langendoen, K.G., Voigt, T. (eds.) EWSN 2007. LNCS, vol. 4373, pp. 163–178. Springer, Heidelberg (2007) 15. Xiao, Y., Rayi, V.K., Sun, B., Du, X., Hu, F., Galloway, M.: A survey of key management schemes in wireless sensor networks. Computer Communications 30(1112), 2314–2341 (2007) 16. Zimmerling, M.: An energy-efficient routing protocol for linear wireless sensor networks. In: Lecture Notes in Informatics, pp. 239–242 (2008) 17. Zimmerling, M., Dargie, W., Reason, J.M.: Localized power-aware routing in linear wireless sensor networks. In: CASEMANS 2008: Proceedings of the 2nd ACM international conference on Context-awareness for self-managing systems, pp. 24–33. ACM, New York (2008)

PKIX Certificate Status in Hybrid MANETs Jose L. Mu˜ noz, Oscar Esparza, Carlos Ga˜ na´n, and Javier Parra-Arnau Universitat Polit`ecnica de Catalunya, Departament Enginyeria Telem` atica 1-3 Jordi Girona, C3 08034 Barcelona, Spain {jose.munoz,oscar.esparza,carlos.ganan,javier.parra}@entel.upc.es

Abstract. Certificate status validation is a hard problem in general but it is particularly complex in Mobile Ad-hoc Networks (MANETs) because we require solutions to manage both the lack of fixed infrastructure inside the MANET and the possible absence of connectivity to trusted authorities when the certification validation has to be performed. In this sense, certificate acquisition is usually assumed as an initialization phase. However, certificate validation is a critical operation since the node needs to check the validity of certificates in real-time, that is, when a particular certificate is going to be used. In such MANET environments, it may happen that the node is placed in a part of the network that is disconnected from the source of status data at the moment the status checking is required. Proposals in the literature suggest the use of caching mechanisms so that the node itself or a neighbour node has some status checking material (typically on-line status responses or lists of revoked certificates). However, to the best of our knowledge the only criterion to evaluate the cached (obsolete) material is the time. In this paper, we analyse how to deploy a certificate status checking PKI service for hybrid MANET and we propose a new criterion based on risk to evaluate cached status data that is much more appropriate and absolute than time because it takes into account the revocation process. Keywords: Certification, Public Key Infrastructure, Revocation, Hybrid MANET, Risk.

1

Introduction

MANETs (Mobile Ad-hoc Networks) are cooperative networks that allow wireless nodes to establish spontaneous communications. As stated in [1], such networks are envisioned to have dynamic, sometimes rapidly-changing, random, multi-hop topologies which are likely composed of relatively bandwidth constrained wireless links. MANETs may operate in isolation (stand-alone), or they may have gateways to fixed networks. In this last case, the MANET is called 

This work is funded by the Spanish Ministry of Science and Education under the projects CONSOLIDER-ARES (CSD2007-00004), SECCONET (TSI2005-07293C02-01), ITACA (TSI2007-65393-C02-02), P2PSEC (TEC2008-06663-C03-01) and, by the Government of Catalonia under grant 2005 SGR 01015 to consolidated research groups.

O. Markowitch et al. (Eds.): WISTP 2009, LNCS 5746, pp. 153–166, 2009. c IFIP International Federation for Information Processing 2009 

154

J.L. Mu˜ noz et al.

“hybrid”. Hybrid MANETs are expected to be deployed as an extension to the traditional infrastructure networks. Also notice that the hybrid behaviour can be temporary due to the situation in which an ad-hoc network may be sometimes stand-alone and sometimes connected to the Internet e.g. a subway network in which a MANET user is connected to the Internet while being at the station and disconnected while traveling. The Hybrid MANET scenario is the one considered in this paper. On the other hand, trust and security are basic requirements to support business applications in this scenario. The public key scheme is the preferred underlying mechanism to provide security services. In a public key scheme, each participant has two keys: a public key (i.e. known by everybody) and a private key (i.e. secret). The announcement of the public key is performed using a signed document called Public Key Certificate (PKC) or simply “certificate“ that binds the participant with her public key. The entity that signs the certificate is called “certificate issuer” or “Certification Authority” (CA). In the literature, there are several ways of managing security and trust in MANETs based on public key cryptography. These approaches basically differ in the degree of decentralization of the mechanisms deployed for issuing, publishing and revoking the certificates (these approaches are reviewed in further detail in the next section). In decentralized architectures such as [2] and [3] the nodes inside the ad-hoc network participate in the certification process. On the other hand, in the centralized architecture the certification process is fully controlled by an external CA that is a Trusted Third Party (TTP). In this case the CA digitally signs certificates, ensuring that a particular public key belongs to a certain user and the overall certification process is performed according to a standard and publicly available policy. Each scheme has its application scenario: decentralized approaches are suitable for autonomous MANETs or hybrid MANETs that do not require a centralized enforced certification mechanism while the centralized approach is suitable for hybrid MANETs in which inter-operability with currently deployed centralized public key infrastructures (PKIs) is required. The problem of using a centralized approach is that current PKIs are designed for wired and well-connected networks, so adopting PKIs for hybrid MANETs is not an easy task. Mobile users are expected to move across different networks. When the user is in a network with connection to the PKI, she can use all the PKI services such as get a certificate, launch a status query, etc. However, users may be disconnected from the PKI when they require a real-time PKI service. In this sense, the certificate status checking is a critical service because applications must decide, at the time of usage, whether a certificate is acceptable or not to perform an action. Proposals in the literature suggest the use of caching mechanisms to let the node itself or a neighbour node to store status checking material (typically on-line status responses or lists of revoked certificates). However, to the best of our knowledge the only criterion to evaluate the cached (obsolete) material is the time. In this paper we propose and formulate a new criterion based on risk to evaluate cached status checking data that is much more appropriate and absolute than time because it takes into account

PKIX Certificate Status in Hybrid MANETs

155

the revocation process. The rest of the paper is organized as follows: Section 2 presents an analysis of the main certification approaches for MANET. Section 3 discusses the main issues that have to be solved in order to adapt current PKI status checking mechanisms to MANET. In Section 4, we present our proposal to evaluate cached status data and, finally, we conclude in Section 5.

2

Certificate Management Schemes for MANET

In general, certificate management schemes can be classified as: – Decentralized. The nodes of the MANET participate either fully or partially in the certification process (see Figure 1.b). – Centralized. Authorities outside the MANET control the certification process according to a global policy (see Figure 1.a). In the fully decentralized PKI schemes for MANET, like Capkun et al. [3,4], the nodes of the MANET themselves issue, publish and revoke the certificates. The certificate management is autonomous and self-organized because there is no need for any trusted authority or fixed server and all the nodes have the same role. In this system, like in PGP (Pretty Good Privacy) [5], each user is her own issuer. Certificates are stored and distributed by the nodes in a fully self-organized manner. Each certificate is issued with a limited validity period and it contains its issuing and expiration times. Before a certificate expires, the owner can issue an updated version of the certificate, which contains an extended expiration time. Authors call this updated version the certificate update. Each node periodically issues certificate updates, as long as the owner considers that the user-key bindings contained in the certificate are correct. Trust is achieved via chains of certificates. The nodes build trust paths certifying from one node to another, as in a friendship circle, forming an authentication ring to achieve the trust relationships with other nodes of the MANET. A decentralized trust management model for pervasive computing environments is presented in [6], where authors overcome the challenges posed by dynamic open environments, making use of the autonomy and cooperative behaviour of the entities.

a)

b)

Cert. Cert. Cert. Cert. Cert. Cert. Cert. Cert.

Cert. Cert.

PKI

Cert.

MANET

Cert. Cert.

Cert. Cert.

Cert.

Cert.

Cert.

MANET

Cert.

Fig. 1. Centralized and decentralized schemes

Cert. Cert.

156

J.L. Mu˜ noz et al.

Another group of public key schemes for MANET is based on threshold cryptography [2]. The idea behind these schemes is to distribute certification duties amongst network nodes. A (k, n) threshold scheme allows the signing private key to be split into n shares such that any k nodes could combine and recover the signing key for a certain threshold k < n, whereas k − 1 or fewer nodes are unable to do so. In this manner, the signing key can be partitioned into n shares and distributed to n nodes using the previous cryptographic technique. For instance, any k of n nodes could then collaborate to sign and issue valid digital certificates or issue status data; whereas a coalition of k − 1 or fewer nodes would not be able to do so. Notice that this scheme is partially decentralized because it requires an initialization phase in which a centralized authority assigns the role to the n nodes that will act as servers for certificate management. Partially decentralized schemes were first proposed by Zhou and Haas in [7]. This work inspired a practical system called COCA [8] in which a threshold cryptography scheme is implemented for infrastructure-based networks. On the other hand, another system called MOCA [9] extends this idea to ad-hoc networks. In this scheme security is improved by selecting powerful nodes as Certificate Authority servers. Finally, an external public key infrastructure can also be used for the hybrid scenario. In this case, centralized trusted authorities issue, publish and distribute the status (valid/revoked) of certificates according to a well-defined standard methodology. In the Internet, the PKIX [10] is the currently working public key infrastructure. However, PKIX is mostly designed for wired and well-connected networks and adapting the PKIX to the hybrid scenario is a challenging task because MANET nodes are expected to move across different networks, sometimes with on-line connection to the PKIX services and sometimes not. When the user is in a network with connection to the PKI, she can use all the PKI services such as getting a certificate, launching a status query, etc. However, users may be disconnected from the PKIX when they require real-time PKIX services. We discuss the problem of adapting PKI to MANET in more detail in the next section.

3

Adapting PKIX to MANET

The local validity of the certificates in the decentralized approaches may restrict their usability in the hybrid scenario. In this sense, the PKIX approach is suitable for hybrid MANETs that require support for mobility maintaining a centralized enforced certification mechanism and also inter-operability with currently deployed PKIs. However, the original design of the PKIX assumes that the user can access at any time to the entities of the infrastructure which is true for wired well-connected networks but not for our scenario. The first problem that we have to face is the certificate acquisition. A permanent connection of the client to the infrastructure cannot be assumed so the solution is to choose relatively long validity periods for the certificates. The idea is that the user has to pass an initial certification process before she can start operating in the MANET. Once the user has its credential, she can operate in

PKIX Certificate Status in Hybrid MANETs

157

the hybrid scenario without further interaction with the PKI (at least interaction is not required for a quite long time). This way of issuing the certificates can be assumed as an initialization phase equivalent to the initialization phase of the partially decentralized scheme in which the shares are delivered. On the other hand, a certificate might be revoked (invalidated) prior to its expiration. Among other causes, a certificate may be revoked because of the loss or compromise of the associated private key, in response to a change in the owner’s access rights, a change in the relationship with the issuer or as a precaution against cryptanalysis. The revocation policies determine how the status of the certificates is distributed to the end users. So the PKI is responsible for the certificates not only at the issuing time but also during all the certificate’s life-time. The problem is that PKIX explicit revocation systems were designed for wired and well-connected networks in which repositories and responders have a wellknown network address and are always available to users. However, MANETs are dynamic environments in which network topology changes randomly and in which mobile users continuously join and leave the network. Therefore, new mechanisms are necessary to distribute explicit status data in MANETs. Proposals in the literature suggest the use of caching mechanisms to address these problems. Caching schemes allow to manage arbitrary disconnections between the users and the sources of the status data service. Disconnections are alleviated by storing copies of status data (lists of revoked certificates or on-line responses) in the nodes of the ad-hoc network. These copies are obtained when connection to the infrastructure is available. In general, an ad-hoc caching scheme for any service has four different kinds of nodes [11]: server-nodes, client-nodes, caching-nodes and intermediate-nodes (see Figure 2). For the status checking service: – Server-nodes. These nodes have ”always updated data“ to offer the status checking service. The server-node has a permanent connection to the certification infrastructure in order to have always fresh status information. Typically, a server-node is an Access Point connected to both to a MANET and to the fixed network. – Client-nodes. These nodes require the status checking service. A service discovery mechanism has to be provided to the client so that she can find a node in the network that provides the service. – Caching-nodes. These nodes have cached data and therefore they may also provide the status checking service. A client-node in the absence of connectivity to a server-node or because of performance issues can connect with a close caching-node to obtain the service with cached status data (perhaps quite obsolete data). – Intermediate-nodes. These nodes forward the packets among client and server nodes. They may also store the path to a service provider (whether a servernode or a caching-node) together with service parameters such as data size, the service expected Time-To-Live (TTL), number of hops to reach the provider etc.

158

J.L. Mu˜ noz et al.

Cert. Cert. Cert. Cert.

Cert. Cert. Cert. Cert. Cert. Cert. Cert. Cert.

Cert. Cert. Cert. Cert.

MANET

Cert. Cert. Cert. Cert.

PKI Server node Caching node Intermediate node Client node

Fig. 2. Four different kinds of nodes in caching schemes

In the literature we can find some proposals that apply the previous ideas to adapt the PKI status checking standards CRL [12,13] and OCSP [14] to the MANET. A CRL is a black list with the identifiers of revoked certificates. The integrity and authenticity of the CRL is provided by an appended digital signature. On the other hand, OCSP is a protocol to make the status of certificates available through a request/response mechanism. The OCSP server is called responder and provides signed responses to clients. Next, we give our point of view about this adaptation and we briefly review some remarkable works about this in the literature. In the case of CRL, server-nodes are nodes that can maintain a stable connection to PKI repositories in order to get the most updated CRL. A caching-node is a node that is willing to collaborate in the certificate status checking service and that has enough cache capacity to store a CRL copy. The caching-node responds to the status requests of client-nodes in the MANET. Notice that a client-node that acquires a valid CRL copy can become a new caching-node. Furthermore, a caching-node that moves to another MANET can collaborate in the new network to provide the service. In this sense, user’s mobility helps the status checking service. In [15], the authors investigate the feasibility of using flooding to distribute CRL information in MANETs by simulation. They conclude that the two major factors for flooding to work smoothly are the number of nodes and the communication range. In [16] a MANET cooperative mechanism for certificate validation is presented in order to overcome both the lack of infrastructure and the limited capabilities of the nodes. This solution is based on an extended-CRL where the repositories can build an efficient structure through an authenticated hash tree. Regarding OCSP, server-nodes are responders. We can consider that there are only responders placed in the PKI (fixed-responders) or we can consider the possibility of having responders implemented in a mobile node that can be part of a MANET (mobile-responders). Despite this possibility, we discourage the use of

PKIX Certificate Status in Hybrid MANETs

159

mobile-responders because they are server-nodes and as such they are supposed to have updated status data. A server-node for certificate status checking must have connectivity with PKI repositories or fixed-responders to get updated status data but this connectivity is not always guaranteed in a MANET. On the other hand, a responder is a trusted authority so it has a private key that has to protect against intruders. In our view, it makes no sense having a server-node that is exposed to attacks and that may not have useful data. Furthermore, in general, increasing the number of trusted authorities in a system is not desirable, the less number of trusted authorities, the less is the probability of having a private key compromised. Besides, if mobile-responders are used, it is necessary to define a mechanism to trust them which is not trivial. With respect caching-nodes, they store OCSP responses issued by server-nodes and distribute them to client-nodes when they detect a request that fulfils freshness requirements. In [17,18], there is a complete proposal called ADOPT (Ad-hoc Distributed OCSP for Trust) that describes a caching scheme for OCSP in MANET.

4

Evaluation of Cached Status Data Based on Risk

As explained in the previous section, caching and discovery mechanisms are necessary to manage the situation in which a user is not able to reach a PKI status data server. When a disconnection happens, the client-node uses service discovery to find a caching node. Then, the node obtains a cached version of available status data and finally, the node decides what to do with the data. In this sense, the CA issues status data bounded by two time-stamps: – thisUpdate. Instant at which status data have been issued. – nextUpdate. Instant at which updated status data are expected to be issued. Let us define Ts as the issuing interval of status data (1). Ts = nextU pdate − thisU pdate

(1)

As data in status responses are time-stamped, users can get an idea about how fresh is the status of a certificate by looking at the thisUpdate parameter of the response and, finally a user can take a decision about whether operate or not with a certain certificate. According to [19] the time is the only criterion to help the user to take this decision and to the best of our knowledge this is the only criterion proposed in the literature. However, this is a poor criterion that can be enhanced. In this section, we propose other parameter rather than time to take this decision. First of all, let us illustrate why time is a poor parameter for our purposes. For instance, consider a status response issued a couple of hours ago. We may wonder: is it fresh or not? The answer is obviously that ”it depends“. Two hours may not be considered a long time if there are a couple of revoked certificates every month but this period can be considered quite long if there are two new revoked certificates per hour. Moreover, a scenario with millions of issued nonexpired certificates is not the same as a scenario that has hundreds of certificates.

160

J.L. Mu˜ noz et al.

In the former, a couple of new revoked certificates is not so relevant while in the latter a couple of new revocations is quite important. As a conclusion, we need a parameter that considers all these aspects. For this purpose, we define a risk function that aids the user to decide whether to trust or not a certificate. We formally define the function risk (r(t)) as the probability of considering a certificate as a valid one when the real status known by the PKI is revoked at time t. To find an analytical expression for the risk function we first need to analyse the certificate issuing process. Certificates are issued with a validity period Tc . Obviously Tc >> Ts , for instance Tc can be a year while the period of status data issuing can be an hour. The number of non-expired certificates (N (t)) -including revoked and non revoked certificates- is a stochastic process whose mean value at instant t depends on the certificate issue and certificate expiration processes. It is assumed that the elapsed time since issuing until expiration (Tc ) is a constant value for all certificates. Therefore, the expiration process is the same as the issuance process elapsed Tc time units. This process is defined by the certificate issue rate λc , which matches with the certificate expiration rate. Hence the mean value of non-expired certificates in steady state is the mean quantity of issued certificates before the expiration process begins. E[N (t)] = N = λC TC , t > TC

(2)

On the other hand, there is a group of revoked non-expired certificates, that is to say, certificates that have a valid validity period but that have been revoked prior to the expiration date and, therefore they are included in the black list. The subset of revoked non-expired certificates is included in the set of non-expired certificates and the cardinality of that set, R(t), is a stochastic process that it is typically modelled [20] as a fraction or percentage (p(t)) of the non-expired certificates (3). R(t) = p(t)N (t) with p(t) ≤ 1

(3)

Assuming that both processes are independent and using expected values: E[R(t)] = E[p(t)]E[N (t)] R = pN

(4) (5)

We further model the expected percentage of revoked certificates as directly proportional to the certification time Tc (6). p = p T c

(6)

This means that larger certification periods will imply more percentage of revoked certificates. On the other hand, smaller certification periods mean less probability of a certificate being revoked during its life-time and therefore low

PKIX Certificate Status in Hybrid MANETs

161

percentage of revoked certificates. Then, the mean value of the revoked nonexpired certificates can be expressed as: R = p λc Tc2

(7)

We have modelled the issuing and revoking processes of the overall system. However, our goal is to model the risk from the point of view of the user, that is to say, we want to find the probability of considering a certificate as a valid one when the real status known by the PKI is revoked. Let us assume, without loss of generality, that at instant t0 = thisU pdate a user gets the current black list of revoked certificates from the PKI. Using this list, the user can split the set of non-expired certificates into revoked certificates and not revoked certificates. Next, we need to define the subset of operative certificates as the group of non-expired certificates for which the last status known by a user is not revoked. Notice that the PKI may know that a certificate considered operative by a user is in fact revoked. However, due to the MANET conditions it is impossible to communicate this situation to the user. Now, let us assume that the user is not able to connect to the infrastructure any more. As time goes by the set of operative certificates will include revoked certificates and the user will need to take decisions about using an operative certificate assuming a certain risk. The risk function r(t) can be evaluated as the ratio between the number of unknown revoked operative certificates (R (t)) and the number of operative certificates (N  (t)) as shown in equation (8). r(t) =

E[R (t)] E[N  (t)]

(8)

N  (t) (number of operative certificates) can be defined as the number of certificates that were not included in the last black list obtained by the user (were not revoked before t0 ) and that they have not expired at t. Included in the set of operative certificates there is the subset of unknown revoked operative certificates. The cardinality of this subset R (t) is the number of operative certificates that are revoked at instant t, that is, they are revoked but this fact is unknown to the user. At t0 = thisU pdate the set of operative certificates is the same that the set of not revoked certificates and, since the user has the same information that the PKI so there is no risk (r(t0 ) = 0). Besides E[N  (t0 )] = (1 − p)N

(9)

E[R (t0 )] = 0

(10)

At the instant t0 +TC all the certificates included in the black list will be expired. This means that all non expired certificates will be operative, and any revoked

162

J.L. Mu˜ noz et al.

certificate will be unknown to the user. The risk at this moment can be expressed as (11). E[R (t0 + TC )] E[R(t0 )] r(t0 + TC ) = = =p (11) E[N  (t0 + TC )] E[N (t0 )] To evaluate the function risk between t0 and t0 + TC we have to observe the processes N  (t) and R (t) in this interval. After t0 the variation of the number of operative certificates (N  (t)) depends on these factors: – Increases because of the new issues. – Decreases because of the expiration of operative certificates issued before instant t0 (the certificates issued later do not expire in the considered interval). The issuance rate is λc that is the same as the expiration rate. But notice that not all expirations concern to operative certificates. A fraction p of the expirations corresponds to revoked non expired certificates, and the other fraction 1 − p corresponds to operative certificates. Then the expiration rate of operative certificates is (1 − p)λc (see Figure 3).

Fig. 3. Evolution of operative certificates

Considering the evolution of the set of operative certificates we can evaluate its expected cardinal (12). E[N  (t)] = E[N  (t0 )] + λC (t − t0 ) − (1 − p)λC (t − t0 )

(12)

Using (9) we obtain. E[N  (t)] = (1 − p)N + pλC (t − t0 )

(13)

Finally, we need an expression for the set of revoked operative certificates. This set is the intersection of the set of operative certificates and the set of revoked certificates as shown in the Figure 4. Hence we can express the cardinality of these sets using the following expression. N (t) = R(t) + N  (t) − R (t)

(14)

PKIX Certificate Status in Hybrid MANETs

163

Fig. 4. Sets of certificates

Therefore, R (t) = R(t) + N  (t) − N (t)

(15)

We obtain the expected value of the number of revoked operative certificates using (15), (2), (5) and (13). E[R (t)] = pλC (t − t0 )

(16)

To obtain the risk function we use the expressions (13), (16) and the expression of its definition (8). r(t) =

p(t − t0 ) (1 − p)Tc + p(t − t0 )

(17)

The previous expression is valid for instants of time t  t0 ≤ t ≤ t0 + Tc and fulfils with the expected results of expressions (10) and (11). Notice that the risk function allows a user to compute the probability of considering a non-expired certificate as non-revoked when the real status known by the PKI is revoked. On the other hand, it is remarkable that unlike time which is a relative parameter, the risk function gives the user an absolute parameter to aid her taking the decision of trusting or not a particular certificate. This decision must be taken when the user is disconnected from the infrastructure and therefore it is taking into consideration cached (obsolete) status data. Finally, the risk function should be used as follows: – In first place, the CA signs the status data with the two standard timestamps (thisUpdate and nextUpdate) but it also adds the current parameter p. The CA can calculate this parameter because it knows the current number of issued non-expired certificates and the current number of non-expired revoked certificates. – When the user has to evaluate status data, she knows Tc as this is the certification period included in her certificate. – Then, the user obtains p from the status data.

164

J.L. Mu˜ noz et al.

– Next, the user can compute the risk at current time t by replacing t0 with thisUpdate in the risk function. – Finally, the user can take a decision about a target certificate with the risk value computed.

5

Conclusions

Decentralized certification architectures for MANET such as self-organized PKIs and PKIs based on threshold cryptography generally provide certificate validation mechanisms inside the MANET. However, local validity of the certificates and inter-operability with currently deployed PKIs may restrict their usability in an hybrid MANET scenario. If a centralized certification infrastructure such as PKIX is used, then certificate validation becomes one of the main problems. This is because users need to ensure at the time of usage that the certificate they are relying upon has not been revoked but at the same time trusted servers of PKIX may be unavailable. Besides, standard status checking mechanisms of the fixed network are not directly usable because they are designed for always connected users. In this sense, caching schemes allow to manage arbitrary disconnections between the users and the sources of the status data service. Disconnections are alleviated by storing copies of status data (lists of revoked certificates or on-line responses) in the nodes of the ad-hoc network. These copies are obtained when connection to the infrastructure is available. On the other hand, a service discovery mechanism is necessary to find the nodes that have cached material. In this paper, we have reviewed and analysed all these issues for adapting the standard PKIX status checking mechanisms to hybrid MANET. Despite the caching scheme allows the users to obtain status data during disconnections, the cached status data is likely to be outdated. When using cached status data a node could operate with a revoked certificate considering it is a valid one. In this paper, we have presented a novel scheme which provides users within the MANET with an absolute criterion to determine whether to use or not a target certificate when updated status data is not available. By taking into account information about the revocation process, users can calculate a risk function in order to estimate whether a certificate has been revoked while there is no connection to a status checking server. Finally, it is also worth to mention that this new criterion can be applied to other networks than hybrid MANETs if these networks are based on an off-line explicit revocation scheme.

Abbreviations ADOPT Ad-hoc Distributed OCSP for Trust. CA Certification Authority. COCA Cornell On-line Certification Authority. CRL Certificate Revocation List. MANET Mobile Ad-hoc Network.

PKIX Certificate Status in Hybrid MANETs

165

MOCA Mobile Certificate Authority. OCSP On-line Certificate Status Protocol. PGP Pretty Good Privacy. PKI Public Key Infrastructure. PKIX Public Key Infrastructure (X.509). TTL Time-To-Live. TTP Trusted Third Party.

References 1. Corson, S., Macker, J.: Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. RFC 2501 (Informational) (January 1999) 2. Desmedt, Y., Frankel, Y.: Threshold cryptosystems. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 307–315. Springer, Heidelberg (1990) 3. Capkun, S., Buttyan, L., Hubaux, J.P.: Self-organized public-key management for mobile ad hoc networks. IEEE Transactions on Mobile Computing (2003) 4. Hubaux, J.-P., Buttyan, L., Capkun, S.: The quest for security in mobile ad hoc networks. In: Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking and Computing, MobiHOC 2001 (2001) 5. Zsako, J.: PGP Authentication for RIPE Database Updates. RFC 2726 (Proposed Standard) (December 1999) 6. Almen´ arez, F., Mar´ın, A., Campo, C., Garc´ıa, C.: Managing ad-hoc trust relationships in pervasive environments. In: Proceedings of the Workshop on Security and Privacy in Pervasive Computing SPPC (2004) 7. Zhou, L., Haas, Z.J.: Securing ad hoc networks. IEEE Networks 13(6), 24–30 (1999) 8. Zhou, L., Schneider, F.B., Renesse, R.V.: Coca: A secure distributed on-line certification authority. ACM Transactions on Computer Systems 20(4), 329–368 (2002) 9. Yi, S., Kravets, R.: Moca: Mobile certificate authority for wireless ad hoc networks. In: Proceedings of the 10th IEEE International Conference on Network Protocols, ICNP 2002 (2002) 10. Pkix chapter of the ietf, http://www.ietf.org/html.charters/pkix-charter.html 11. Yin, L., Cao, G.: Supporting cooperative caching in ad hoc networks. IEEE Transactions on Mobile Computing 5(1), 77–89 (2006) 12. Housley, R., Ford, W., Polk, W., Solo, D.: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459 (Proposed Standard), Obsoleted by RFC 3280 (January 1999) 13. Tuecke, S., Welch, V., Engert, D., Pearlman, L., Thompson, M.: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. RFC 3820 (Proposed Standard) (June 2004) 14. Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 2560 (Proposed Standard) (June 1999) 15. Go, H.W., Chan, P.Y., Dong, Y., Sui, A.F., Yiu, S.M., Hui, L.C.K., Li, V.O.K.: Performance evaluation on crl distribution using flooding in mobile ad hoc networks (manets). In: Proceedings of the 43rd annual southeast regional conference on ACM Southeast Regional Conference archive, Kennesaw, Georgia, vol. 2, pp. 75–80 (2005)

166

J.L. Mu˜ noz et al.

16. Forn´e, J., Mu˜ noz, J.L., Esparza, O., Hinarejos, F.: Certificate status validation in mobile ad hoc networks. IEEE Wireless Communications 16(11), 55–62 (2009) 17. Marias, G.F., Papapanagiotou, K., Tsetsos, V., Sekkas, O., Georgiadis, P.: Integrating a trust framework with a distributed certificate validation scheme for manets. Wireless Communications and Networking 1155(10), 1–18 (2006) 18. Marias, G.F., Papapanagiotou, K., Tsetsos, V., Sekkas, O., Georgiadis, P.: Integrating a trust framework with a distributed certificate validation scheme for manets. EURASIP Journal on Wireless Communications and Networking 2006(2), 1–18 (2006) 19. Deacon, A., Hurst, R.: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. RFC 5019 (Proposed Standard) (September 2007) 20. Arnes, A.: Public key certificate revocation schemes, Queen’s University. Ontario, Canada. Master Thesis (February 2000)

Author Index

Alins-Delgado, Juan J.

12

Balinsky, Helen 52 Bouzefrane, Samia 84

Lederer, Christian L´ opez-Ramos, J.A.

Casado, L.G. 128 Chen, Liqun 52 Cordry, Julien 84 Dottax, Emmanuelle Esparza, Oscar

68

12, 153

Fukushima, Kazuhide

28

Ga˜ na ´n, Carlos 153 Genet, Thomas 1 Giraud, Christophe 68 Großsch¨ adl, Johann 112 Guette, Gilles 1 Harrison, Keith 52 Heen, Olivier 1 Jacobs, Bart Jaimez, Marc

95 12

Kiyomoto, Shinsaku 28 Koschuch, Manuel 112 112 128

Mader, Roland 112 Martin, Keith M. 28, 143 Mata-D´ıaz, Jorge 12 McDonnell, Edward 52 Mu˜ noz, Jose L. 12, 153 Naranjo, J.A.M.

128

Paradinas, Pierre 84 Parra-Arnau, Javier 153 Paterson, Maura B. 143 Radomirovi´c, Saˇsa 38 Rivain, Matthieu 68 Sierra, Yannick 68 Szekely, Alexander 112 Tews, Hendrik Tillich, Stefan

95 112

van Deursen, Ton

38