Foundations and Practice of Security: 4th Canada-France MITACS Workshop, FPS 2011, Paris, France, May 12-13, 2011, Revised Selected Papers

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...

Author: Joaquin Garcia-Alfaro | Pascal Lafourcade

11 downloads 591 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

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

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

6888

Joaquin Garcia-Alfaro Pascal Lafourcade (Eds.)

Foundations and Practice of Security 4th Canada-France MITACS Workshop, FPS 2011 Paris, France, May 12-13, 2011 Revised Selected Papers

13

Volume Editors Joaquin Garcia-Alfaro TELECOM-Bretagne Campus de Rennes 2, rue de la Châtaigneraie, 35512 Cesson Sévigné Cedex, France E-mail: [email protected] Pascal Lafourcade Université Joseph Fourier Laboratoire Verimag Centre Equation, 2 avenue de Vignate, 38610 Gires, France E-mail: [email protected]

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

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

Message from the Program Chairs

This volume contains the proceedings of the 4th Canada-France MITACS Workshop on Foundations and Practice of Security (FPS 2011). The FPS workshop was initiated in 2008, following the Canada-France Meeting on Security held at the Simon Fraser University, Vancouver, during December 6–8, 2007. Since then, the FPS workshop has been held annually, alternating between Canadian and French locations, including Montreal, Grenoble and Toronto. This fourth edition of the FPS workshop was held in Paris, France, during May 12–13, and was co-located with the NOTERE 2011 conference hosted by T´el´ecom Paristech. In response to the call for participation, 30 contributions from 15 diﬀerent countries were submitted to the workshop. These contributions were evaluated on the basis of their signiﬁcance, novelty, and technical quality. This volume contains a revised version of ten full papers, accompanied by three keynote addresses, two short papers, and ﬁve ongoing research reports. These papers cover a wide and rich spectrum of research in security and privacy of electronic services. We would like to express our sincere appreciation for all the support we received from the General and Organizing Chairs of FPS 2011, Evangelos Kranakis, Rei Safavi-Naini, Fr´ed´eric Cuppens, and Nora Cuppens-Boulahia. Thanks very much for your contribution to the success of the event. Our special thanks go, also, to our keynote speakers, Abdullatif Shikfa (Alcatel-Lucent Bell Labs), Ali Miri (Ryerson University), Marc Frappier (University of Sherbrooke), Gimer Cervera (Carleton University), Christoph Neumann (Technicolor), and Rei SafaviNaini (Calgary University), for accepting our invitation and for their presence during the event and talks. We acknowledge the ﬁnancial support from MITACS (thank you Rebeccah Marsh and Michael Lynch), INRIA (thank you Claude Kirchner and Helene Kirchner), UOC/IN3 (thank you David Megias), and Institut T´el´ecom (thank you David Sadek). We also acknowledge the support from the following projects: ARES-CONSOLIDER INGENIO 2010 CSD2007-00004 and eAEGIS TSI200765406-C03-03 from the Spanish MICINN; and the DEMONS project FP7-ICT2009-5 from the European Commission. Finally, we express our gratitude to the NOTERE 2011 organization team. Thank you Ahmed Serhrouchni, Isabelle Demeure, Thomas Robert, and Gael Thomas, for all your help with the local arrangements of FPS. Many thanks go, also, to the FPS 2011 Program Committee members and the external referees, for their help, availability and commitment. Last, but by no means least, we thank all the authors who submitted papers and talks, and all the workshop attendees. September 2011

Joaquin Garcia-Alfaro Pascal Lafourcade

FPS 2011 Workshop Organization

General Chairs Evangelos Kranakis Rei Safavi-Naini

Carleton University, Canada Calgary University, Canada

Program Chairs Joaquin Garcia-Alfaro Pascal Lafourcade

TELECOM Bretagne, France Joseph Fourier University, France

Organizing Chairs Fr´ed´eric Cuppens Nora Cuppens-Boulahia Joaquin Garcia-Alfaro

TELECOM Bretagne, France TELECOM Bretagne, France TELECOM Bretagne, France

Publication Chair Joaquin Garcia-Alfaro

TELECOM Bretagne, France

Program Committee Carlos Aguilar Melchor Michel Barbeau Mike Burmester Christophe Bidan Joan Borrell-Viader Ana Cavalli Jordi Castella-Roca Frederic Cuppens Nora Cuppens-Boulahia Ernesto Damiani Josep Domingo-Ferrer David Evans Jose M. Fernandez Sara Foresti

XLIM Research Institute, France Carleton University, Canada Florida State University, USA Supelec, Rennes, France Autonomous University of Barcelona, Spain TELECOM SudParis, France Rovira i Virgili University, Spain TELECOM Bretagne, France TELECOM Bretagne, France University of Milan, Italy Rovira i Virgili University, Spain University of Cambridge, UK Ecole Polytechnique de Montreal, Canada University of Milan, Italy

VIII

FPS 2011 Workshop Organization

Sebastien Gambs Joaquin Garcia-Alfaro Stefanos Gritzalis Jordi Herrera-Joancomarti Thomas Jensen Wei Jiang Bruce Kapron Claude Kirchner Evangelos Kranakis Pascal Lafourcade Yassine Lakhnech Jean Leneutre Georgios Lioudakis Luigi Logrippo Fabio Massacci Ludovic Me Ali Miri Kumar Murty Guillermo Navarro-Arribas Andreas Pashalidis Rei Safavi-Naini Douglas Stinson Nicola Zannone

Universit´e de Rennes 1, France TELECOM Bretagne, France University of the Aegean, Greece Autonomous University of Barcelona, Spain INRIA Rennes, France Missouri University of Science and Technology, USA Victoria University, Canada INRIA, Rocquencourt, France Carleton University, Canada Joseph Fourier University, France Joseph Fourier University, France TELECOM ParisTech, France National Technical University of Athens, Greece Universit´e du Quebec en Outaouais, France Universit`a di Trento, Italy Supelec, Rennes, France Ryerson University, Canada University of Toronto, Canada UAB, Spain K.U. Leuven, Belgium Calgary University, Canada University of Waterloo, Canada Eindhoven University of Technology, The Netherlands

Steering Committee Guillaume Hanrot Bruce Kapron Evangelos Kranakis Pascal Lafourcade Henry Lee

LORIA, France Victoria University, Canada Carleton University, Canada Joseph Fourier University, France Government of BC, Canada

External Referees Theodoros Balopoulos Nataliia Bielova Jannik Dreier Arnau Erola Oriol Farras Laurent Fousse Olga Gadyatskaya

University of the Aegean, Greece Universit`a di Trento, Italy Joseph Fourier University, France Rovira i Virgili University, Spain Rovira i Virgili University, Spain Joseph Fourier University, France Universit` a di Trento, Italy

FPS 2011 Workshop Organization

Martin Gagn´e Iksoon Hwang Behzad Malek Joan Melia-Segui Anderson Morais Kris Narayan Thomas Peyrin Guillaume Piolle Bruno Pontes Soares Rocha Jordi Pujol-Ahullo Alfredo Rial Bharath Samanthula Hoi Ting Poon Elmar Tischhauser Eric Totel Meilof Veeningen

IX

Joseph Fourier University, France TELECOM SudParis, France University of Ottawa, Canada Open University of Catalonia, Spain TELECOM SudParis, France Calgary University, Canada Nanyang Technological University, Singapore Supelec, Rennes, France Eindhoven University of Technology, The Netherlands Rovira i Virgili University, Spain K.U. Leuven, Belgium Missouri University of Science and Technology, USA University of Ottawa, Canada K.U. Leuven, Belgium Supelec, Rennes, France Eindhoven University of Technology, The Netherlands

Table of Contents

Keynote Address Preserving Privacy in Online Social Networks . . . . . . . . . . . . . . . . . . . . . . . . Fatemeh Raji, Ali Miri, and Mohammad Davarpanah Jazi

1

Short Papers TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme for Electronic Elections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jordi Pujol-Ahull´ o, Roger Jard´ı-Ced´ o, Jordi Castell` a-Roca, and Oriol Farr` as Automated Veriﬁcation of Block Cipher Modes of Operation, an Improved Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martin Gagn´e, Pascal Lafourcade, Yassine Lakhnech, and Reihaneh Safavi-Naini

14

23

Pervasive Security and Threshold Cryptography (SC)2 : Secure Communication over Smart Cards: How to Secure Oﬀ-Card Matching in Security-by-Contract for Open Multi-application Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nicola Dragoni, Eduardo Lostal, Davide Papini, and Javier Fabra

32

Private Identiﬁcation of RFID Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Behzad Malek and Ali Miri

49

Threshold Encryption into Multiple Ciphertexts . . . . . . . . . . . . . . . . . . . . . Martin Stanek

62

Encryption, Cryptanalysis and Automatic Veriﬁcation A Novel Commutative Blinding Identity Based Encryption Scheme . . . . . Yu Chen, Song Luo, Jianbin Hu, and Zhong Chen

73

A Related-Key Attack on Block Ciphers with Weak Recurrent Key Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marina Pudovkina

90

A Computational Indistinguishability Logic for the Bounded Storage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gilles Barthe, Mathilde Duclos, and Yassine Lakhnech

102

XII

Table of Contents

Keynote Addresses Preventing the Cluster Formation Attack against the Hierarchical OLSR Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gimer Cervera, Michel Barbeau, Joaquin Garcia-Alfaro, and Evangelos Kranakis Secret Key Establishment over Noisy Channels . . . . . . . . . . . . . . . . . . . . . . Hadi Ahmadi and Reihaneh Safavi-Naini

118

132

Formal Methods and Network Security Formal Speciﬁcation and Validation of Security Policies . . . . . . . . . . . . . . . Tony Bourdier, Horatiu Cirstea, Mathieu Jaume, and H´el`ene Kirchner

148

Vote-Independence: A Powerful Privacy Notion for Voting Protocols . . . . Jannik Dreier, Pascal Lafourcade, and Yassine Lakhnech

164

Black-Box Property of Cryptographic Hash Functions . . . . . . . . . . . . . . . . Michal Rjaˇsko

181

Phishing Detection with Popular Search Engines: Simple and Eﬀective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jun Ho Huh and Hyoungshick Kim

194

Ongoing Research A Contextual Privacy-Aware Access Control Model for Network Monitoring Workﬂows: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eugenia I. Papagiannakopoulou, Maria N. Koukovini, Georgios V. Lioudakis, Joaquin Garcia-Alfaro, Dimitra I. Kaklamani, and Iakovos S. Venieris A Metamodel for the Design of Access-Control Policy Enforcement Managers: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michel Embe Jiague, Marc Frappier, Fr´ed´eric Gervais, R´egine Laleau, and Richard St-Denis Speciﬁcation and Veriﬁcation of Access Control Policies in EB3 SEC: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pierre Konopacki, Hakim Belhaouari, Marc Frappier, and R´egine Laleau

208

218

227

Table of Contents

A Metamodel of the B Modeling of Access-Control Policies: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J´er´emy Milhau, Marc Frappier, and R´egine Laleau Formal Veriﬁcation of a Key Establishment Protocol for EPC Gen2 RFID Systems: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wiem Tounsi, Nora Cuppens-Boulahia, Fr´ed´eric Cuppens, and Joaquin Garcia-Alfaro Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XIII

234

242

253

Preserving Privacy in Online Social Networks Fatemeh Raji1 , Ali Miri2 , and Mohammad Davarpanah Jazi3 1

Department of Electrical and Computer Engineering Isfahan University of Technology, Isfahan, Iran [email protected] 2 Department of Computer Science Ryerson University, Toronto, ON, Canada [email protected] 3 Department of Computer and Information Technology Foulad Institute of Technology, Fouladshahr, Isfahan, Iran [email protected]

Abstract. In recent years, online social networks (OSN) have grown in number and popularity. A large part of this growth is due to the ease of sharing information with other users who have common interests. Protecting the privacy of users against unwanted disclosure of their information in such settings poses challenging privacy problems. In this paper, we highlight OSN privacy requirements emphasizing current risks to users’ privacy in these environments. We summarize some of the privacy laws that regulate how users information may be collected and stored in OSNs. Finally, some of the existing proposed solutions are reviewed and compared in order to provide insight into future research directions. Keywords: Online Social Networks, Privacy, Access Control.

1

Introduction

In 1954, Professor J. A. Barnes [1] ﬁrst coined the term social networks to describe individuals coming together in the speciﬁc groups of around 100 to 150 people that acted like small communities. Online social networks (OSNs) are social networks on the internet, the websites that are online communities of internet users. In recent years, many types of OSNs have been created with diﬀerent emphasis e.g., business, dating, entertainment, blogging, pets, photos, religion, etc. For instance, LinkedIn (http://www.linkedin.com/) aims to connect potential business partners. Moreover, some OSNs let users share a speciﬁc type of content like Flickr (http://www.flickr.com) for sharing images or YouTube (http://www.youtube.com/) for sharing music and video content. There are also some OSNs like Facebook (http://www.facebook.com/) and Myspace (http:// www.myspace.com/) that are intended for general purpose use. J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 1–13, 2012. c Springer-Verlag Berlin Heidelberg 2012

2

F. Raji, A. Miri, and M. Davarpanah Jazi

Despite all the diﬀerences mentioned, based on [2] the core functionality of OSNs are to allow individuals to: 1. construct public or semi-public personal proﬁles within a structured environment; 2. create lists of users with whom they share connections; 3. view their lists of connections and those of others in the system. As a result, users provide some information like proﬁle items that are only available to the OSN providers, while other types of information like photos or notes are also available to a subset of OSN users. However, some information like behavioral information is implicitly supplied to the OSN by actions taken by users within the OSN and made accessible to a large number of people without knowledge of users and their awareness of its implications [3]. That is why they allow a potentially dangerous amount of information about themselves to be available on OSNs. All registered users’ sensitive information and their interactions are stored on OSN servers which are not always honest and transparent. The open nature of OSNs also allows third parties to gather and analyze the private information of their targets easily. Here, the useful and private information is users’ proﬁle information, comments, groups joined, etc. Furthermore, in oﬀ-line social communication, users have diﬀerent types of relationships with each other and only want certain details of their information disclosed to others. Since OSNs give users the ability to simulate real world relationships in an online setting, accommodating relationships at various abstraction levels is required. Providing such a relationship space for social interaction to control access level and information ﬂow, leads to better preservation of information privacy. Consequently, there is an absolute need to use a a privacy-by-design approach in a typical OSN [4], which enable users to have control over how their personal information is acquired, disclosed or used [5]. Contributions: The main contribution of this paper is to present a comprehensive taxonomy of privacy requirements for OSN users based on submitted privacy laws and reported privacy breaches. We also provide a basis for categorizing some of the proposed approaches which tries to preserve users’ privacy. Organization: We describe the notion of privacy in OSNs in Section 2 which includes the privacy settings embedded in Facebook, data privacy laws and the privacy requirements expected for OSN users. In section 3, we discuss some of the recently proposed solutions to providing users’ privacy in OSNs. Conclusions of the paper are given in Section 4.

2

Privacy in OSN

Privacy is the ability of an individual to reveal his/her information selectively. Basically, privacy includes the protection of information (security) as well the appropriate and authorized use of it [6].

Preserving Privacy in Online Social Networks

3

Privacy of information has three facets: the relationship between collection and dissemination of data, the expectation of privacy in the public, public expectation of privacy, and the legal issues [7]. 2.1

Privacy Setting: Facebook Case

For analysis purposes, we look at the privacy problems of the most popular OSN i. e. Facebook, a free, general-purpose platform for socialization. Basically, Facebook is a good target for researchers, governments, marketers and hackers. According to [3], [8], [9] and [10], Facebook has some principal privacy problems: • Users have lots of trust in Facebook and their contacts in it. • Users used to have to use their real information like their real names to create an account proﬁle to the rest of the Facebook users. • The default privacy settings of Facebook are inadequate, so users disclose too much info to a large number of connections. Furthermore, most users do not change the OSN [3] default privacy settings that are provided. As an example of the problem that this poses, the photo and personal details of the incoming head of MI5 were to the public from his wife’s Facebook page [11]. • It is impossible to eﬀectively change the privacy settings oﬀered by Facebook in some cases. For instance, by adding a friend to our friend list, we were able to see her/his entire shared information. • Facebook does not take adequate steps to protect user privacy and even Facebook warns its users that altering default settings may make it more diﬃcult for them to connect with their friends and discourages any alteration. • Third parties are actively seeking out users’ information, and Facebook’s terms of use requires that users release Facebook from responsibility for any damages accrued by installing or using API. Consequently, the embedded privacy settings of Facebook and generally every OSN, should be visible and easily changeable to desired settings. Furthermore, the default privacy settings should be set to the highest level to protect many users who want to protect their information, but are not fully informed on how to change the privacy settings [10]. 2.2

Data Privacy Laws

Given the fact that publishing users’ information has become more common and such information is often stored in diﬀerent databases, the ability of users to exercise control over their own information has been greatly diminished. This lack of control can be potentially harmful to users as the information can be accessed or sold for proﬁt. To overcome this problem, data privacy laws are gradually being approved in many countries to adapt to changes in technology and maintain people’s rights.

4

F. Raji, A. Miri, and M. Davarpanah Jazi

Generally, privacy laws regulate the type of information which may be collected and how this information may be used and stored. Data privacy laws cover the protection of individuals’ information from intentional or unintentional disclosure or misuse [12]. The basic principles of the data privacy laws of most countries including the European Union and Canada are as deﬁned below: • Organizations must clearly state the purpose of collecting personal information, and obtain consent before collecting this information. • Collection of information should be done in reasonable and lawful ways. • Collected information must be deleted or destroyed when it is no longer needed for the stated purpose. Enforcement of privacy protection is also being initiated to deﬁne appropriate privacy roles especially for OSNs. For example, in July 2009, the Canadian Privacy Commissioner found “serious privacy gaps in the way the [Facebook] site operates” [13]. She raised issues with the Facebook handles the third-party application developer to users’ personal information, deletion of content of deactivated accounts, as well as better handling of personal information of non-users and deceased user. Although actions were taken by Facebook were deemed satisfactory by the Canadian Privacy Commissioner in her report in September 2010, further areas of concern were identiﬁed. More recently, the EU justice commissioner announced a package of proposals to be enacted the summer of 2011 requires OSNs such as Facebook to enable a high standard default setting [3] for their users [14]. In the proposed changes, OSNs are required to seek explicit users’ permission before gathering their data, provide users with tools to remove their consent and be assured that any copies of their data on the system has been removed. 2.3

Privacy Requirements in OSN

Generally, in OSN environments, the users are interested in monitoring the following issues: • WHAT information is appropriate to share? What is considered private content depends on users’ characteristics and the its time of release, but often there is commonly accepted information considered to be private. • WHO gets to see the shared information? Users have diﬀerent relationships with their friends on a given OSN, which can vary over time and based on the piece of the information being shared. • HOW the information can be used? Although OSN users may not be able to completely prevent malicious actions by the receivers of their shared information, they may wish to be able to exercise a degree of control over the use of their information. As a result, we can decompose the required privacy for OSN users as below which is also summarized in Fig. 1.

Preserving Privacy in Online Social Networks

5

Fig. 1. Taxonomy of privacy requirements for OSN users

1. No Trusted OSN Provider: Currently, OSN providers have unlimited access to users’ information since users fully trust OSN provider to store and enforce control on users’ data. There are many real world examples of this type of privacy disclosure. For instance, people trust LinkedIn as a professional/business network, so they build proﬁles with educational background and employment history. They assume that their information will stay in the network. Unfortunately, this assumption is not always valid. Information is often easily accessed from outside LinkedIn due to user errors (such as using the wrong conﬁguration) or misunderstanding or from errors beyond the user’s control such malfunctioning code [15]. Moreover, the terms of service of many OSNs grant service providers rights to users’ data. These rights commonly include a license to display and distribute all content posted by users in any way the provider sees ﬁt.

6

F. Raji, A. Miri, and M. Davarpanah Jazi

The survey in [16] states that about 14% of respondents had no idea what a privacy statement was and 48% said that they had never read it. From those who read the privacy statements, 21% reported to have only read part of the statement (since they found reading the whole statement to be too time consuming), and only 5% to have read the statement carefully and always before joining the OSN. Furthermore, only 38% of respondents identiﬁed privacy statement as a deciding factor whether to join the given OSN. 2. No Trusted Third Party: OSN users should be ensured that no entities can access more data than authorized. There are three diﬀerent actors breaching users’ privacy from outside of their contacts: 2.1 Application Developers: Most OSNs provide a framework for third party application developers to create application programming interfaces (API) that access OSN databases and can pose great privacy risk. Third party applications should clearly state which users’ information they need and how they will process it. Under these conditions, the users can then make a decision on whether or not to accept this application. 2.2 Information Seekers: With the development of information retrieval and searching tools, it is very convenient for malicious or curious users that are not part of the OSN to take advantage of these techniques to collect others’ private information. According to a recent survey by Microsoft, 75% of U.S. recruiters and human-resource professionals reported that they are required by their companies to do online research about candidates using a range of OSN sites [17]. 2.3 Auxiliary Embedded Entity: As will be discussed in Section 3, the proposed privacy architectures for OSN try to get help from other trusted entities to avoid trusted OSN providers. However, using these methods often shifts the privacy problems associated with the trust of OSN to the new entities. It is worth mentioning that semi-trusted entities (honest but curious model) are widely used in computer security research. It is assumed that these entities follow protocol properly (honest) and do not break any laws or conduct any illegal activity but these entities are aggressively seek as much information as possible (curious). 3. Access Control: A crucial feature for privacy management in OSNs is to implement access control with the following characteristics. 3.1 Fine-grained Access Control: In OSNs, user’s friends should have diﬀerent access to his/her shared data. Using ﬁne grained access control, a subset of a user’s friends is authorized to view each data item. Under these conditions, the user has the ability to segregate her friends into abstract groups and to make access control decisions at the group level. Then the user allows only some speciﬁc groups to access each item of published data. Suppose a high school student named Alice has an OSN account. Alice may have friends from her school that are in her class. Alice also has some close friends like Bob, Mallory and Zack. Let’s assume that

Preserving Privacy in Online Social Networks

7

Fig. 2. Friends Organization for the user Alice

Bob is her classmate and Mallory is at the other class of her school. Also, there are some friends from her family in Alice’s friend list. It is interesting that Alice organizes her friends in some overlapping groups like “School ”, “Classmate”, “Close-Friend ” and “Family” as depicted in Fig. 2. In this situation, Alice is able to share the photo of the class picnic with only friends in the “Classmate” group. Note that the user can simply categorize her/his friends into disjoint groups i.e. the friends have single membership, but ideally friends should be categorized into non-disjoint groups i.e. friends have multiple memberships, belonging to more than one group. 3.2 Flexible Access Control: It is desirable for the OSN user to deﬁne access policy over more than one group in a ﬂexible manner. In the example above, Alice may want to share a note with all close friends in her class by deﬁning a privacy group like “Close-Friend” AND “Classmate”. Moreover, Alice may also want Mallory see the shared note by deﬁning “Close-Friend” AND “Classmate” AND Mallory. 3.3 Dynamic Access Control: Basically, social relationships are dynamic. That is, the relation between the user and her friends changes over time. In other words, the user should be able to remove friends from groups and add them to other groups. In Figure 2, Alice may become very close with Mallory and wants to add Mallory to her “Close-Friend ” group. Moreover, in the next year of Alice studying, she will have new classmates. Thus, Alice has to remove some friends from the “Classmate” group and add some new ones to this group.

8

F. Raji, A. Miri, and M. Davarpanah Jazi

Furthermore, the user may want to terminate all relations with a speciﬁc friend by revoking all the friend’s permissions. For instance, if the relation between Alice and Bob ﬁnishes, Alice may not only want to remove Bob from “School ”, “Classmate” and “Close-Friend ” but also want to revoke all his credentials from her context. There are many cases where the user adds new friends to her friend list and then puts them in the deﬁned groups, or the user may need to deﬁne new groups at diﬀerent times. For instance, Alice may deﬁne a new relation “Sport-Club” after registering in a sports club and wants to add some friends from this group.

3

Privacy Solutions

Most current OSN architectures use a centralized client-server model. Such a model inherently requires that users trust OSN providers with their information [18]. The centralized client-server model takes advantage of the simplicity and performance of these setups. Recently, various approaches have been proposed to meet privacy requirements in OSNs based on this model. They mostly use cryptographic techniques in order to avoid disclosing information to unauthorized entities. Moreover, these approaches try to remove the assumption of trustworthiness of OSNs providers by employing un-trusted or semi-trusted third parties in their solutions. In the following, each technique is broadly discussed. 3.1

FlyByNight [19]

FlybyNight [19] protects personal information transmitted to Facebook using a Facebook API. FlybyNight supports one-to-many communication that encrypts a single message for a group of friends. To do this, FlybyNight employs a server to execute the proxy cryptography method. For setting up a group, the user generates a group key for the group members and a proxy key for its server which total O(n) friend keys and O(n) proxy keys. Although, the user performs a single encryption for each shared message, the server has to perform O(n) proxy encryptions for each friend who reads the message. A more challenging operation is revocation, since a new group key and new proxy keys for each remaining friend would need to be generated. 3.2

FaceCloak [20]

FaceCloak [20] is an architecture that shields users’ personal information from anyone not explicitly authorized to see it including other users and the OSN providers, while preserving the usability of services provided by OSNs. FaceCloak achieves these goals by providing fake information to OSNs and storing sensitive information in encrypted form on a separate server. In the setup phase, FaceCloak generates several keys and distributes a subset of these keys to the

Preserving Privacy in Online Social Networks

9

user’s friends. In the encryption phase, FaceCloak guides the user to encrypt the posted information and send it to the third party server. Moreover, fake information will be transmitted to the OSN server. In the decryption phase, the user’s friends decrypt the real information retrieved from the third party server and use it to replace the fake information obtained from the OSN. Note that FaceCloak does not provide any access control mechanism giving all the users’ friends the same access rights to private data. 3.3

NOYB [21]

NOYB [21] partitions private information into small clusters called atoms, and then substituting one user’s atom with another chosen pseudo-randomly. In essence, if all the atoms of the same class compose a dictionary, NOYB encrypts the index of the user’s atoms in this dictionary. Afterwards, the user’s friends employ the ciphered index to pick the replacement atom from the dictionary. Similar to FaceCloak, NOYB does not oﬀer any tools for assigning diﬀerent permissions to diﬀerent friends. 3.4

Persona [22]

Persona [22] allows users to manage group membership of their friends and to control access to published data. It combines attribute-based encryption (ABE) and traditional public key cryptography (PKC). In Persona, private users’ data is always encrypted with a symmetric key. The symmetric key is encrypted with an ABE key corresponding to the group that is allowed to read the shared data. Persona uses decentralized storage so that users can choose with whom they store their information. Note that Persona does not satisfy ﬂexibility over friends because each friend is identiﬁed by attributes in the user’s domain. Also, all the desired relations between the user and a friend must be speciﬁed when the friend is added to the user’s friends list. 3.5

Lockr [23,24]

Lockr [23,24] lets users control their own social information. Users can restrict access to their content to friends who have a certain social relationship to them by associating a “social access control list” to their shared information. The users exchanges a digitally sign a description of a social relationship called an “attestation” to let them access the shared content. After attestation veriﬁcation for each data access, two users agree on a session key to protect the exhange of data. Note that Lockr stores users’ private data on OSN server or trusted third parties in plaintext form. 3.6

BE-Based Scheme [25]

A BE-based scheme [25] employs broadcast encryption (BE) to guarantee access control of private data stored on un-trusted storage sites. In this scheme, the

10

F. Raji, A. Miri, and M. Davarpanah Jazi

OSN provider acts as the credential authority in the system which is trusted by the users. Each user is the group manager who classiﬁes contacts according to their dynamic roles and grants them the corresponding memberships. Note that each user’s friend can be organized in a diﬀerent group. That is, no intersection between the deﬁned groups is possible. 3.7

GCC [26]

In GCC [26], each user generates her/his private key and registers a public label on the OSN. To create a community e.g. privacy group, some fully trusted users called “kernel users”, generate a community key (CK) in a cooperative way. For each friend, a user can then generate an access permission key (APK) corresponding to her/his own private key and the friend’s public label. Using the private key and the community’s APK, the user can decrypt the shared information, but not encrypt information for the community. The encryption operation cannot be implemented unless a user is given the community key. In GCC, the OSN users should trust the kernel users and the OSN Platform acts as a middleware for all interactions between end users. Furthermore, there is no ﬂexibility in deﬁning the privacy policies. 3.8

EASiER [27]

EASiER [27] provides revocation using ABE by introducing a proxy that participates in the decryption process and enforces revocation constraints. The basic idea is that the proxy is assigned a secret key with revocation information. A user’s friend who wants to decrypt some data, gets the ciphertext from the proxy. The proxy uses its key to transform the ciphertext into a form that contains enough information for an unrevoked friend to successfully perform the decryption. Upon each key revocation, the user rekeys her/his proxy with the latest revocation information. However, the user does not have the ability to deﬁne ﬂexible access control over friends or deﬁne new groups gradually. 3.9

IBBE-Based Scheme [28]

IBBE-based scheme [28] provides a privacy protection framework for OSN with ﬂexible and dynamic access control without any help from the OSN provider. In the proposed approach, the user generates a symmetric key for each piece of data she would like to share and publishes the key using identity based broadcast encryption (IBBE). Then the user simply broadcasts the encrypted content to their storage servers. Only the intended friends who can compute the decryption key using IBBE would be able to decrypt and access the user’s private data. In spite of the fact that this scheme proposes ﬂexible and dynamic access control without trusting the OSN providers, the eﬃciency of this approach must be improved further to be applicable in real world applications. Table 1 gives an extensive comparison of the illustrated solutions according to the privacy requirements described in Section 2. As can be seen from this table,

Preserving Privacy in Online Social Networks

11

Table 1. Taxonomy of centralized techniques proposed for OSN assuming 1.1: SemiTrusted OSN provider, 1.2: Un-Trusted OSN provider, 2.1: Semi-Trusted Third Party Entity, 2.2: Un-Trusted Third Party Entity, 3.1.1: Simple Membership, 3.1.2: Multiple Membership, 3.2.1: Flexibility Over Relations , 3.2.2: Flexibility Over Friends, 3.3.1.1: Adding a Relation, 3.3.1.2: Adding a Friend, 3.3.2: Removing/Revoking a Friend Methods

1.1 1.2 2.1 2.2 3.1.1 3.1.2 3.2.1 3.2.2 3.3.1.1 3.3.1.2 3.3.2

FlyByNight [19] –

–

–

–

–

–

–

FaceCloak [20]

– –

–

–

–

–

–

–

NOYB [21]

– –

–

–

–

–

–

– –

Persona [22]

– –

–

–

–

Lockr [23,24]

–

–

–

–

–

–

BE-based [25]

–

–

–

–

GCC [26] EASiER [27]

– – – – –

– –

–

– –

–

IBBE-Based [28] – –

–

most of the reviewed proposals suﬀer from some drawbacks, such the ineﬃciency of key management upon a membership modiﬁcation of user’s friends. Therefore, the design of an eﬃcient architecture for private OSN with full access control is still an important issue [29].

4

Conclusions

Preserving privacy of shared data on OSNs presents a challenging problem given the popularity and the growth in use of such networks. Users of these networks should be given tools to enable them to decide who gets to access the information they wish to share and how the information is used. This paper lists characteristics that are common to diﬀerent OSNs and those which can lead to compromise of users’ privacy. After giving an example and discussing some of the legal actions taken to tackle this issue, a detailed taxonomy of required or desired privacy settings under diﬀerent architectures is discussed. A survey of recent work with a comparison of their performances with respect to the privacy settings is also given. Acknowledgments. This research was supported in part by a grant from the Natural Sciences and Engineering Research Council of Canada (NSERC).

References 1. Barnes, J.: Class and Committees in a Norwegian Island Parish. Human Relations 7, 39–58 (1954) 2. Boyd, D., Ellison, N.: Social Network Sites: Deﬁnition, History, and Scholarship. Journal of Computer-Mediated Communication 13(1) (2007)

12

F. Raji, A. Miri, and M. Davarpanah Jazi

3. Gross, R., Acquisti, A.: Information revelation and privacy in online social networks (the Facebook case). In: ACM Workshop on Privacy in the Electronic Society (WPES 2005), pp. 71–80 (2005) 4. Chen, S., Williams, M.A.: Privacy in social networks: A comparative study. In: Paciﬁc Asia Conference on Information Systems, pp. 33–42 (2009) 5. Kang, J.: Information privacy in cyberspace transactions. Stanford Law Review 50, 1193–1294 (1998) 6. http://en.wikipedia.org/wiki/privacy (accessed April 2011) 7. http://en.wikipedia.org/wiki/information/privacy (accessed July 2011) 8. Jones, H., Soltren, J.H.: Facebook: Threats to privacy. Technical report, Massachusetts Institute of Technology (December 2005) 9. Facebook statement of rights and responsibilities, http://www.facebook.com/terms.php (accessed June 2011) 10. Goettke, R., Christiana, J.: Privacy and online social networking websites. Technical report, Harvard University (2007) 11. http://technology.timesonline.co.uk/tol/news/tech and web/ article6644199.ece (accessed July 2009) 12. http://en.wikipedia.org/wiki/information/privacy_law (accessed April 2011) 13. http://www.priv.gc.ca/media/nr-c/2009/nr-c_090716_e.cfm (accessed May 2011) 14. http://www.guardian.co.uk/media/2011/mar/16/eu-social-networksites-privacy(accessed April 2011) 15. Luo, B., Lee, D.: On protecting private information in social networks: A proposal. In: The 25th International Conference on Data Engineering (ICDE 2009), pp. 1603– 1606 (2009) 16. Mohtasebi, A., Borazjani, P.: Privacy concerns in social networks and online communities. In: The VALA 2010 15th Biennial Conference and Exhibition, Melbourne, Australia (2010) 17. http://www.nytimes.com/2010/07/25/magazine/25privacy-t2.html (accessed July 2011) 18. Gao, H., Hu, J., Huang, T., Wang, J., Chen, Y.: Security issues in online social networks. IEEE Internet Computing 15(4), 56–63 (2011) 19. Lucas, M.M., Borisov, N.: FlyByNight: mitigating the privacy risks of social networking. In: The 7th ACM Workshop on Privacy in the Electronic Society (WPES 2009), Alexandria, Virginia, USA, pp. 1–8 (October 2008) 20. Luo, W., Xie, Q., Hengartner, U.: Facecloak: An architecture for user privacy on social networking sites. In: 12th IEEE International Conference on Computational Science and Engineering (CSE 2009), Vancouver, BC, Canada, pp. 26–33 (August 2009) 21. Guha, S., Tang, K., Francis, P.: NOYB: privacy in online social networks. In: The First Workshop on Online Social Networks (WOSN 2008), Seattle, WA, USA, pp. 49–54 (2008) 22. Baden, R., Bender, A., Spring, N., Bhattacharjee, B., Starin, D.: Persona: An online social network with user deﬁned privacy, and scholarship. In: The ACM SIGCOMM 2009 Conference on Data Communication (SIGCOMM 2009), New York, NY, USA, pp. 135–146 (2009) 23. Tootoonchian, A., Gollu, K.K., Saroiu, S., Ganjali, Y., Wolman, A.: Lockr: Social access control for web 2.0. In: The First ACM SIGCOMM Workshop on Online Social Networks (WOSN 2008), Seattle, WA, USA (August 2008)

Preserving Privacy in Online Social Networks

13

24. Tootoonchian, A., Saroiu, S., Ganjali, Y., Wolman, A.: Lockr: Better privacy for social networks. In: The 5th ACM International Conference on Emerging Networking EXperiments and Technologies (CoNEXT), Rome, Italy, pp. 169–180 (2009) 25. Sun, J., Zhu, X., Fang, Y.: A privacy-preserving scheme for online social networks with eﬃcient revocation. In: The 2010 IEEE Conference on Computer Communications (INFOCOM 2010), San Diego, CA, USA, pp. 2516–2524 (July 2010) 26. Zhu, Y., Hu, Z., Wang, H., Hu, H., Ahn, G.J.: A collaborative framework for privacy protection in online social networks. In: The 6th International Conference on Collaborative Computing (CollaborateCom 2010), Chicago, Illinois, USA (October 2010) 27. Jahid, S., Mittal, P., Borisov, N.: EASiER: Encryption-based access control in social networks with eﬃcient revocation. In: 6th ACM Symposium on Information Computer and Communications Security (ASIACCS), Hong Kong (March 2011) 28. Raji, F., Miri, A., Jazi, M.D., Malek, B.: Online social network with ﬂexible and dynamic privacy policies. In: 15th CSI International Symposium on Computer Science and Software Engineering (CSSE 2011), Tehran, Iran (June 2011) 29. Carminati, B., Ferrari, E.: Privacy-aware access control in social networks: Issues and solutions. In: Privacy and Anonymity in Information Management Systems: New Techniques for New Practical Problems. Springer, Heidelberg (2010)

TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme for Electronic Elections Jordi Pujol-Ahull´ o, Roger Jard´ı-Ced´o, Jordi Castell` a-Roca, and Oriol Farr` as Departament d’Enginyeria en Inform` atica i Matem` atiques Av. Pa¨ısos Catalans, 26, ES43007, Tarragona, Spain {jordi.pujol,roger.jardi,jordi.castella,oriol.farras}@urv.cat

Abstract. The private key of electronic elections is a very critical piece of information that, with an incorrect or improper use, may disrupt the elections results. To enforce the privacy and security of the private key, secret sharing schemes (or threshold schemes) are used to generate a distributed key into several entities. In this fashion, a threshold of at least t out of the n entities will be necessary to decrypt votes. We study in this work the feasibility of developing ElGamal cryptosystem and Shamir’s secret sharing scheme into JavaCards, whose API gives no support for it. Keywords: asymmetric cryptography, secret sharing scheme, JavaCards, multi-authority election scheme, e-voting.

1

Introduction

Electronic elections employ typically asymmetric cryptosystems to encrypt votes and, therefore, guarantee their anonymity and secrecy. In this scenario, the private key of the electoral board is a critical piece of information. An incorrect or improper use of the private key could disrupt the election results. Secret sharing is a cryptographic primitive that is used to solve this problem. In a (t,n)-threshold secret sharing scheme, the secret is divided in n shares in such a way that any set of at least t shares can recover the secret. The ElGamal cryptosystem [4] is widely chosen in e-voting schemes, given its homomorphic properties and its possible use in mixnets [2]. In addition, smartcards are being used to enhance the security and usability of the e-voting system given that they are tamper-proof devices [10] and make easier the shares portability. Smartcards have two parts [5]: (i) the hardware components, which might include a cryptographic co-processor to provide hardwareaccelerated cryptographic operations (e.g., RSA, DSA), and (ii) the smartcard operating system, which may allow to develop, deploy and execute user applications in a secure fashion. JavaCards [7,8] are extensively used smartcards, because they can extend their functionality by means of applications (called applets) developed in a subset of the Java programming language. However, even though the smartcard hardware may give support for ElGamal cryptosystem (e.g., [1, pg. 2]), the JavaCard API (Application Programming Interface) does not [7,8]. J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 14–22, 2012. c Springer-Verlag Berlin Heidelberg 2012

TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme

1.1

15

Contributions and Organization

The contributions of our work are the design and development for JavaCards of the following building blocks: (i) ElGamal cryptosystem to generate the ElGamal key pair, (ii) Shamir’s secret sharing scheme to divide the private key in a set of shares, (iii) secure communication channels for the distribution of the shares, and (iv) a decryption function without reconstructing the private key. This solution can be applicable in many diﬀerent situations but especially, as discussed below, we will show how it applies and how can be useful for a typical e-voting system, speciﬁcally in the voting scheme presented by Cramer et al. [3]. In the Section, 2 we detail the protocol implemented and its phases. In the Section, 3 we explain how we implement the protocol. In the following Section 4, we will evaluate the performance of our implementation. Finally, we make conclusions and the analysis of the future work in the Section 5.

2

Smartcard Protocol

In order to explain the protocol behavior and its implementation, we make use of a typical e-voting system [3]. In this section, we describe our proposed smartcard protocol for initializing the ElGamal cryptosystem and the threshold secret sharing scheme that are used in the electronic elections. The protocol has been designed in order to implement all sensitive operations securely into the JavaCard. Firstly. we list the participating actors within the protocol, and afterwards, we describe all the subsequent protocol steps within the elections process. For each electoral district/department there is an electoral board (M), formed by a set of members M = {m1 , . . . , mn }. The electoral board M has the responsibility of initializing ElGamal cryptosystem and providing the private key to all members. The set M is elected from the set of users U = {u1 , . . . , uw }, n ≤ w. Each member mi is provided with a smartcard sci ∈ SC. An electoral authority A has the function of managing and supervising the elections and, in particular, of generating the certiﬁcates ci for each member mi ∈ M. In the following, we highlight the protocol steps in a typical e-voting system. Firstly, (i) the electoral board is constituted, allowing voters to vote; (ii) voters cast their vote encrypted to guarantee anonymity and secrecy; and (iii) votes are decrypted. The votes can be aggregated before obtaining the tally results if the e-voting scheme is homomorphic or hybrid. 2.1

Electoral Board Constitution

The electoral board is constituted by a set of m members. Any member has a smartcard, public certiﬁcates and particular public and private keys. A smartcard sc ∈ SC is used to generate the ElGamal key pair for the current elections, and also all shares for the private key using Shamir’s secret sharing scheme [11]. Only then the private key is securely removed from sc. This smartcard establishes a secure channel to the rest of (n − 1) smartcards and sends them the

16

J. Pujol-Ahull´ o et al.

corresponding shares. Once this protocol step is concluded, all smartcards have their verified share, as well as all the public key and parameters necessary for encryption, decryption and veriﬁcation operations. We structure the electoral board constitution with the following steps: 1. Election and certiﬁcation of the members of the electoral board: (a) The members of M = {m1 , . . . , mn } are drawn from U = {u1 , . . . , uw } according to the current legislation. (b) A stores in all smartcards elections detail E (current elections), list of members M and certiﬁcate cA . (c) All members in M meet. Then, A provides them their smartcards. 2. Creation of the electoral board: (a) For each mi ∈ M, A builds a (e.g., RSA) key pair (pi , si ) and creates its public certiﬁcate ci . (b) The key pair (pi , si ) and the set of public certiﬁcates C = {c1 , . . . , cn } are stored in the corresponding smartcard sci . (c) A validates each certiﬁcate ci ∈ C. (d) The electoral board constitution is publicly deﬁned by δ SHA(M, C, E). 3. Creation of the ElGamal key pair for elections E: (a) δ is stored in each sci ∈ SC. (b) Every sci ∈ SC veriﬁes δ using cA . (c) Every sci ∈ SC stores the ElGamal and threshold scheme public paramA eters in (sci ←− (p, g, t)). (d) One (any) of the sci ∈ SC performs the following operations: i. Generates s ∈ Zp , where s is the ElGamal private key for elections E. ii. Generates y = g s mod p, the ElGamal public key for elections E. 4. Generation of the private key shares for the electoral members according to the Shamir’s (t, n)-threshold scheme. To do so, the above selected sci performs the following operations: (a) Deﬁnes privately B = {b1 , . . . , bt−1 }, where bi ∈ Zp , 0 < i < t. (b) Commits publicly to Bˆ = {B1 , . . . , Bt−1 } : Bi = g bi mod p, 1 ≤ i ≤ t − 1. i (c) Deﬁnes a polynomial f (x) = s+ t−1 i=1 bi x mod p, of degree t− 1, where s is the zero degree term. This polynomial will be used to generate the shares of the (t, n)-threshold scheme. (d) Deﬁnes the public parameters X = {x1 , . . . , xn } : xi ∈ Zp ∧ xi = xj ∧ i = j, 1 ≤ i ≤ n ∧ 1 ≤ j ≤ n. (e) Commits publicly to X = {x1 , . . . , xn }. (f) Calculates the set of shares H = {h1 , . . . , hn } where hi = f (xi ) = s + t−1 j mod p, xi ∈ X . j=1 bj xi (g) Removes securely s. ˆ = {H1 , . . . , Hn } : Hi = g hi mod p, 1 ≤ i ≤ t−1. (h) Commits publicly to H

TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme

17

5. Distribution of shares to all electoral members. To do that, the same smartcard sci prepares all hj ∈ H \ {hi } to be sent privately to other members mj in M \ {mi }. The goal is to securely transmit and store the share hj in the corresponding smartcard scj . We implement a secure communication channel by using symmetric and asymmetric encryption of the data to be sent, and then, send it publicly over any insecure communication channel. In particular, for all j = i, sci realizes the following operations: (a) Gets a symmetric key Kj (e.g., AES key). (b) Encrypts hj using Kj and obtains σj = EKj (hj ). (c) Encrypts Kj using the public key Pcj and obtains αj = Pcj (Kj ). (d) Calculates the digital signature of (σj , αj ) obtaining βj = SHsi (σj , αj ). Recall that si is the mi ’s private key, stored in sci . (e) Sends publicly (y, σj , αj , βj ) to scj . (f) Securely removes all hj from sci . 6. Veriﬁcation and storage of the received shares by all electoral members. To do so, all smartcards scj = sci check the received information. That is, for every j = i, scj performs the following operations: (a) Veriﬁes the digital signature βj . (b) Decrypts αj using its private key sj , and obtains Kj = Ssj (αj ). (c) Decrypts σj using Kj , and obtains hj = DKj (σj ). (d) Veriﬁes hj , so that g hj corresponds to the public parameter Hj . ˆ = {H1 , . . . , Hn } are correct. (e) Veriﬁes that the public parameters H (f) Stores in scj the share hj , whether all veriﬁcations succeed. Otherwise, smartcard scj from member mj addresses a complain to A. 7. To complete and conﬁrm the correct reception of the corresponding shares, all smartcards perform a public commitment to the received shares. Every sci ∈ SC realizes the following operations: (a) Calculates yi = g hi mod p. (b) Calculates de digital signature γi = SHi (yi ). (c) Sends in a public fashion the pair (yi , γi ) to the rest of smartcards. The aforementioned protocol steps guarantee that any sci ∈ SC has its verified private information, as well as all the public key and parameters necessary for encryption, decryption and veriﬁcation. Next, we describe the rest of the logical steps in the elections. 2.2

Vote Encryption and Tallying Votes

Once the electoral board is constituted, the elections starts. In the voting phase, voters cast their vote encrypted in order to guarantee their anonymity and secrecy. Therefore, the vote zi ∈ Zp from voter vi is encrypted using the ElGamal public key y from elections Eand ri , whereZp and 1 < ri < p − 1. When elections have been concluded, a set of at least t members of the electoral board M = {m1 , . . . , mn }, t ≤ n, it is necessary to meet for successfully decrypting votes. These members compute securely in their smartcards the hi λi mod p, where λi is the corresponding Lagrange coeﬃfactor Z1i = Z1(g ) cient, and Z1 = vi ∈V g ri . This factor is used to compute the ﬁnal tally in a similar way of [3].

18

3

J. Pujol-Ahull´ o et al.

Implementation Details

We propose to develop an application to be deployed on JavaCards [7,8]. We chose this technology because it is one of the most pervasive open platforms for secure devices. Nowadays, there are over 3.5 Billion Java Powered smart cards deployed worldwide [9]. The applications developed using Java card technology can be run on several platforms. Another consideration is its Modular security certiﬁcation. The platform can be certiﬁed once and the applications can be certiﬁed separately. 3.1

JavaCard-Based ElGamal and Threshold Scheme Rationale

Smartcards supporting JavaCard 2.2 [7] and superior versions [8] provide a welldeﬁned set of symmetric and asymmetric cryptosystems (e.g., RSA, AES), as well as digital signatures (e.g., DSA). However, there is no support for ElGamal cryptosystem, even though it might be provided by the smartcard hardware. To implement the ElGamal cryptosystem in JavaCards, we need a JavaCard provided with modular arithmetic operations, mainly modular multiplication and exponentiation. Nonetheless, JavaCard 2.2 API provides no modular arithmetics, but only non modular addition, subtraction and multiplication of big numbers [7, see javacardx.framework.math.BigNumber]. Having all this in mind, we identify three building blocks that are necessary in order to oﬀer ElGamal encryption/decryption, as well as the mathematical operations necessary for the construction and use of the Shamir-based threshold scheme: (i) a big number library for JavaCard, (ii) ElGamal API and (iii) threshold scheme API in JavaCard. In particular, the big number library will be used by the ElGamal and threshold scheme API, so that its design and implementation have the (constrained) eﬃciency in very consideration. In addition, we design the whole solution in pure JavaCard language subset to be as much portable as possible. 3.2

Big Number Library

Developing software for smartcards is very restrictive given the functionality and data types they support. This is also the case of the JavaCards. It is easily noticeable that there are several challenges to solve when dealing with big numbers in JavaCards, even though they can be categorized into the following two concerns: (i) big number storage and representation and (ii) modular arithmetics. Big Number Storage and Representation. First of all, we have the challenge of storing big numbers into JavaCards. To do so, JavaCards allow deﬁning array of bytes (8 bits), shorts (16 bits) or ints (32 bits). However, int data type is optionally supported in the standard JavaCard, and not all JavaCards supports array of shorts and ints. This comes to light by the fact that the whole JavaCard API only uses arrays of data type byte. Additionally, the JavaCard language subset restricts that arrays can hold up to 32,767 ﬁelds. This requires that only variables of type byte or short be used as an array index or to specify the size of an array during array creation.

TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme

19

We have designed this library to overcome all these restrictions by following the minimum-common-factor criteria. To do so, we have designed a Java class MutableBigInteger as container of a big number. MutableBigIntegers consist of a byte array as back-end (for true portability) and a minimal set of methods to facilitate their initialization and access. The design of our MutableBigInteger is inspired in the Java 6.0 MutableBigInteger class [6]. Given that all Java objects must be initialized when the applet is registered into the JavaCard, the byte array size has to be initialized to the maximum allowed supported key size in the JavaCard standard [7], which is 2048 bits. However, we permit instantiation of keys of diﬀerent sizes (≤ 2048 bits) according to the current key size used in the system. Modular Arithmetics. MutableBigInteger does not provide any modular arithmetics, but a new Math Java class does. Among other methods, Math implements the modular addition (modAdd), subtraction (modSubtract), multiplication (modMul), exponentiation (modPow) and bitwise right shift (modRightShift). Except modPow and modMul, all modular operations are implemented according to the paper and pencil solution, with cost O(n) in actual number of bytes long of the largest big number. We designed the complex and costly modPow and modMul operations in such a way that they tend to be time and computationally eﬃcient. To do so, we used as much as possible the JavaCard cryptographic coprocessor. In particular, we implement modPow overlaid on the provided JavaCard RSA cryptosystem [12], so that our solution beneﬁts from a hardware-accelerated modular exponentiation (with almost O(1) cost). Following the same path, we use the binomial theorem (1) to transform a modular multiplication into modular exponentiations: (a + b)2 − (a − b)2 = 4ab mod p

(1)

As equation (1) depicts, calculating a modular multiplication requires one modular addition, two modular subtractions, two modular exponentiations and two modular bitwise right shifts, with a total cost of O(n) in current number of bytes long [12]. Therefore, diﬀerently from what could be expected, our implementation provides a O(n) cost in terms of key size. 3.3

ElGamal and Threshold Scheme API in JavaCards

We presented in Section 2 the protocol to initialize the Shamir’s (t,n)-threshold scheme for the ElGamal cryptosystem. However, we have also designed a version of ElGamal cryptosystem to work in a standalone fashion, without a secret sharing scheme. Actually, it is worth noting that our protocol also includes the generation of the ElGamal public and private keys. In this section we present the design of classes which support the standalone ElGamal cryptosystem, and leave the description of the threshold scheme version for later in this section. However, we use the ElGamal private key implementation in both cases to store the standalone private key (s) or the member’s private share (hi ), respectively. ElGamal API in JavaCards. The JavaCard API [7,8] deﬁnes an algorithm to be any diﬀerent type of cryptosystem (like RSA or AES) that its API standardizes.

20

J. Pujol-Ahull´ o et al.

The idea behind that is to allow providing diﬀerent implementations of the set of supported algorithms by the JavaCard API. However, this set of algorithms is not extensible [7, see javacard.crypto.Cipher.ALG * and javacard.security.KeyBuilder.TYPE * constants]. A developer aiming to design a new algorithm has to construct his/her own class structure to support it. However, to reduce the learning curve and to support for a rapid adoption of any new algorithm, we believe that it is preferred to study and inherit as much as possible the class structure and class lifecycle from the JavaCard API. Following these guidelines, we designed the ElGamal cryptosystem and developed all classes. The main example is ElGamalCipher class. ElGamalCipher, which extends from Cipher (provided by the JavaCard API), supports the new kind of algorithm. When it is used to ask for existing algorithms in the JavaCard API, ElGamalCipher forwards the invocation method to its superclass so that the JavaCard library will lastly dispatch it. In particular, ElGamalCipher mainly provides three functions: (i) initialize, which is the mandatory ﬁrst performed task, that includes (1) loading the public parameters g and p, and then (2) generating the ElGamal key pair; (ii) encrypt information, and (iii) decrypt an ElGamal ciphertext to obtain the content in clear format. Threshold Sharing Scheme API in JavaCards. The main diﬀerence between the ElGamal cryptosystem implemented by our ElGamalCipher and our Shamir’s (t,n)-threshold scheme of ElGamal cryptosystem is in the ElGamal ThresholdCipher class. This class is the Cipher in use, instead of the standalone version ElGamalCipher. ElGamalThresholdCipher is implemented to follow strictly the protocol described in Section 2 and provides all the functions necessary to support our protocol of electoral board constitution.

4

Evaluation

In order to evaluate the performance and eﬃciency of our implemented protocol over JavaCards, we carried out a set of tests executing parts of the protocol into JavaCards, with a (3,5)-threshold. Each test has been run for 10 times on a JCOP 21 v2.2 with 72Kb of memory [1], for a 6 diﬀerent key sizes (512, 736, 896, 1024, 1280 and 2048 bits). Concretely, the tests have been focused on basic protocol operations entirely executed on smartcard (not including the operations executed on computer) such as the (i) shares generation (including ElGamal key pair generation), the (i) share veriﬁcation (steps 6d and 6e of electoral board constitution), the (iii) vote encryption and ﬁnally, the (iv) vote decryption without reconstructing the private key. Results appear in Fig. 1, where shares generation and verification costs are the highest and grow linearly together with the key size. Generating 5 shares ranges from 5.56 to 20.10 minutes, whilst verifying a single share ranges from 1.14 to 4.26 minutes. Despite their important costs, they are aﬀordable because these operations are realized only once and before elections start. Encryption cost is reasonable, grows linearly and ranges from 0.42 to 1.25 minutes. This cost does not

TTP SmartCard-Based ElGamal Cryptosystem Using Threshold Scheme

21

depend on the number of shares though. The decryption cost also grows linearly and ranges from 0.27 to 0.70 minutes. This behavior is admissible in a real situation where a homomorphic or hybrid e-voting system is used. However, in e-voting systems purely based on mixnets would not be viable because votes should be decrypted one by one and, therefore, the total cost would depend linearly on the number of votes. Notice that this cost does not depend on the number of shares because each decryption, made in each smartcard of the electoral board, can be parallelized. As introduced in Section 3.2, Fig. 1 depicts a linear growing in time consumption due to (i) the use of the cryptographic co-processor to execute the costly modular exponentiation with an almost constant cost, whilst (ii) the rest of modular operations (such as addition) have the depicted linear cost. 25 Encrypt Decrypt

Shares generation Shares verification

Time (minutes)

20

15

10

5

0 400

600

800

1000

1200 1400 Key size (bits)

1600

1800

2000

2200

Fig. 1. Costs mean (in minutes) of 10 experiments of shares generation, shares veriﬁcation, encryption and decryption with the given key size (in bits)

5

Conclusions and Future Work

We developed a library for Java Cards that allows: (i) a big number storage and representation and (ii) modular arithmetics. Next, we used the library to design and implement the ElGamal cryptosystem for the Java Card platform. Please, note that there is no support for ElGamal cryptosystem in the Java Card API even though it might be provided by the smartcard hardware. We completed the library with the development of the Shamir’s (t,n)-threshold scheme for the ElGamal cryptosystem. Finally, we evaluated the performance and eﬃciency of our implemented library on a JCOP 21 v2.2 with 72Kb of memory using diﬀerent key sizes. The encryption and decryption operations show a reasonable cost although it is not advisable to use these operations massively. The shares generation and veriﬁcation have a signiﬁcant cost. Nonetheless, we think that they are aﬀordable because they can be realized only once and before their use. We should mention that an e-voting company has shown its interest in our library because it could be used in its research prototypes.

22

J. Pujol-Ahull´ o et al.

As a future work, we are working in a non-trusted third party (Non-TTP) solution with a distributed generation of the shares. In addition, we would like to improve the eﬃciency, time and storage of the protocol in smartcard (i.e., using ElGamal on elliptic curves).

References 1. Koninklijke Philips Electronics N.V.: (2003) Jcop 21 v2.2 72kb spreadsheet (2004), http://www.usmartcards.com/images/pdfs/pdf-61.pdf, http://www.usmartcards.com/images/pdfs/pdf-61.pdf 2. Chaum, D.L.: Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM 24(2), 84–90 (1981), http://doi.acm.org/10.1145/358549.358563 3. Cramer, R., Gennaro, R., Schoenmakers, B.: A Secure and Optimally Eﬃcient Multi-Authority Election Scheme. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 103–118. Springer, Heidelberg (1997), http://portal.acm.org/citation.cfm?id=1754542.1754554 4. El Gamal, T.: A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. In: Blakely, G.R., Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 10–18. Springer, Heidelberg (1985) 5. Naccache, D., M’Ra¨ıhi, D.: Cryptographic smart cards. IEEE Micro 16(3), 14–24 (1996), http://portal.acm.org/citation.cfm?id=623269.624010 6. Oracle: Java 6.0 mutablebiginteger api (2010), http://www.java2s.com/OpenSource/Java-Document/6.0-JDK-Core/math/java/math/MutableBigInteger. java.java-doc.htm 7. Oracle: Javacard 2.2.2 api (2010), http://www.oracle.com/technetwork/java/javacard/specs-138637.html 8. Oracle: Javacard 3.0.1 api (2010), http://www.oracle.com/technetwork/java/javacard/specs-jsp-136430.html 9. Oracle: Introduction to java card 3.0 speciﬁcations (2011), http://java.sun.com/javacard/3.0 10. Renaudin, M., Bouesse, F., Proust, P., Tual, J.P., Sourgen, L., Germain, F.: High security smartcards. In: Proceedings of the Conference on Design, Automation and Test in Europe, DATE 2004, vol. 1, p. 10228. IEEE Computer Society, Washington, DC (2004), http://portal.acm.org/citation.cfm?id=968878.969074 11. Shamir, A.: How to share a secret. Commun. ACM 22(11), 612–613 (1979) 12. Sterckx, M., Gierlichs, B., Preneel, B., Verbauwhede, I.: Eﬃcient implementation of anonymous credentials on java card smart cards. In: 1st IEEE International Workshop on Information Forensics and Security (WIFS 2009), pp. 106–110. IEEE, London (2009)

Automated Verification of Block Cipher Modes of Operation, an Improved Method Martin Gagn´e1, Pascal Lafourcade1, Yassine Lakhnech1 , and Reihaneh Safavi-Naini2 1

2

Universit´e Grenoble 1, CNRS, Verimag, France Department of Computer Science, University of Calgary, Canada

Abstract. In this paper, we improve on a previous result by Gagn´e et al. [9] for automatically proving the semantic security of symmetric modes of operation for block ciphers. We present a richer assertion language that uses more ﬂexible invariants, and a more complete set of rules for establishing the invariants. In addition, all our invariants are given a meaningful semantic deﬁnition, whereas some invariants of the previous result relied on more ad hoc deﬁnitions. Our method can be used to verify the semantic security of all the encryption modes that could be proven secure in [9], in addition to other modes, such as Propagating Cipher-Block Chaining (PCBC).

1

Introduction

Block ciphers are among the most basic building blocks in cryptography. They can be used to construct primitives as varied as message authentication codes, hash functions and, their main application, symmetric encryption. Block ciphers are deterministic, and have ﬁxed-size input and output, so protocols, called modes of operation, are required to encrypt messages of arbitrary length. The security of these modes of operation is then proven by reduction from the security of the mode of operation to some security property of the block cipher. Automated veriﬁcation tools can help increase our conﬁdence in the security of these modes of operation by providing an independent argument for their security. Gagn´e et al. [9] ﬁrst initiated the study of automatic veriﬁcation techniques for symmetric modes of operation. They presented an assertion language, invariants and rules for a Hoare logic which can be used to verify the security of most of the traditional modes of operation. However, due to the rather ad hoc nature of the description of certain invariants, and to the restrictiveness of their rule set, the resulting automated veriﬁer was limited and its results could sometimes depend on the order in which the commands of the mode of operation were written. Contributions: We improve on the result of Gagn´e et al. [9] by presenting a Hoare logic with a richer assertion language and invariants, which allow us to verify more modes of operation. For example, our new logic is able to verify the security of Propagating Cipher-Block Chaining (PCBC) – an encryption mode that was introduced for Kerberos version 4 – while [9] could not. J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 23–31, 2012. c Springer-Verlag Berlin Heidelberg 2012

24

M. Gagn´e et al.

The programming language and assertion language are essentially the same as [9], but our invariants are much more precise. We use only three predicates: one that states that the value of a variable is indistinguishable from a random value, one that states that the block cipher has never been computed at the value of a variable, and one that keeps track of the most recent value of a counter. Our predicates are also much more satisfying than those in [9] since they can all be described using a clear semantic deﬁnition, whereas some predicates in [9] were rather ad hoc, particularly when it came to the predicate used to keep track of counters. Using our logic as a set of rules for propagating the invariants though the code of each mode of operation, we can verify the semantic security of all the encryption modes which could be shown secure in [9], together with other modes, such as PCBC. Related Work: Many new modes of operation have been developped in the last decade (IACBC, IAPM [17], XCB [20], TMAC [16,18], HCTR [4], HCH [6], EMU [13], EMU* [10], PEP [5], OMAC [14,15], TET [11], CMC [12], XEX [21], TAE, TCH, TBC [19,22] to name only a few). These new modes of operation often oﬀer new security functionalities that early modes did not possess, but these properties come at the cost of increased complexity of the mode of operation, and increased complexity of the proof of security. We believe that automated veriﬁcation of these modes would greatly increase our conﬁdence in those arguments. An extensive discussion on diﬀerent security notions for symmetric encryption and a proof of the CBC mode of encryption is presented in [3]. They also present a security proof of the CBC mode of operation through a reduction to the security of the block cipher. An automatic method for proving the semantic security for asymmetric encryption schemes in the random oracle model was presented in [7]. A similar method is used in [9] to verify the security of symmetric encryption modes. Our work here is a continuation of these eﬀorts. Other works in automated veriﬁcation of cryptographic protocols include [1], which presents a new logic for reasoning about cryptographic primitives, and uses this logic to formally analyze the security of the signature scheme PSS, and [2], which provides a machine-checked proof of OAEP. We refer the reader to our technical report [8] for the complete details on this result, deﬁnitions, rule set and proofs. We will focus here on the new semantics and our new deﬁnition for the invariants, and explain how they improve our veriﬁer.

2

Definitions

The encryption modes veriﬁed using our method must be written using the language described by the grammar of Figure 1, where:

Automated Veriﬁcation of Block Cipher Modes of Operation

25

$

c ::= x ← − U | x := E (y) | x := E −1 (y) | x := y ⊕ z | x := yz | x := y[n, m] | | x := y + 1 | c1 ; c2 Fig. 1. Language grammar $

– x← − U denotes uniform sampling of a value and assigning it to x. – x := E(y) denotes application of the block cipher E to the value of y and assigning the result to x. – Similarly for x := E −1 (y), where E −1 denotes the inverse function of E. – x := y ⊕ z denotes application of the exclusive-or operator to the values of y and z and assigning the result to x. – x := y||z represents the concatenation of the values of y and z. – x := y[n, m] assigns to x the bits at positions between n and m in the bit-string value of y. I.e., for a bit-string bs = b1 . . . bk , where the bi ’s are bits, bs[n, m] denotes the bits-string bn . . . bm 1 . Then, x := y[n, m] assigns bs[n, m] to x, where bs is the value of y. Here, n and m are polynomials in the security parameter η. – x := y + 1 increments by one the value of y and assigns the result to x. The operation is carried modulo 2η – c1 ; c2 is the sequential composition of c1 and c2 We can now formally deﬁne a mode of encryption as follows: Definition 1 (Generic Encryption Mode). A generic encryption mode M is represented by EM (m1 | . . . |mi , c0 | . . . |ci ) : var xi ; ci , where xi is the set of variables used in ci , all commands of ci are built using the grammar described in Figure 1, each mj is a message blocks, and each cj is a cipher block, both of size n according to the input length of the block cipher E. 2.1

Semantics

A state in our semantics consists of an assignment of value to each variable used in the program (a set denoted by Var) in addition to a list LE which keeps track of all the values on which the block cipher has been computed. We also use a table T which keeps track of all the variables which are used as counters2 . Our new semantics are described in Table 1. 2.2

New Invariants

We introduce a new invariant, lcounter() which is deﬁned using our new table T , and make small modiﬁcations to the other invariants3 . Of particular interest: weaugment the invariant Indis so that it is now possible to indicate that the value 1 2 3

Notice that bs[n, m] = , when m < n and bs[n, m] = bs[n, k], when m > k. We drop the sets F and C, which were an ad hoc attempt at keeping track of fresh variables and counters. We do away with invariants F and RCounter, which were deﬁned using the alsoremoved sets F and C from the semantics.

26

M. Gagn´e et al. Table 1. The semantics of the programming language r

r

[[x ← U]](S, E ) = [u ← U : (S{x → u, T → T ∪ {Tx }, E )] [[x :=⎧E (y)]](S, E ) = ⎨ δ(S{x → v, T , E ) if (S(y), v) ∈ LE δ(S{x → v, T → T ∪ {Tx }, LE → S(LE ) · (S(y), v)}, E ) ⎩ if (S(y), v) ∈ LE and v = E (S(y)) [[x := y ⊕ z]](S, E ) = δ(S{x → S(y) ⊕ S(z), T , E ) [[x := y||z]](S, E ) = δ(S{x → S(y)||S(z), T , E ) [[x := y[n, m]]](S, E ) = δ(S{x → S(y)[n, m], T , E ) [[x :=y + 1]](S, E ) = δ(S{x → S(y) + 1, T → T ∪ {Tz → Tz [i + 1] = x}, E ) if y = Tz [i] ∧ Tz [i + 1] = ⊥ δ(S{x → S(y) + 1, T , E ) otherwise [[c1 ; c2 ]] = [[c2 ]] ◦ [[c1 ]]

of a variable is indistinguishable from a random value when given all the values in LE . This small modiﬁcation is crucial to the Lemma below, and is one of the main reasons for the improved capacity of our automated prover. lcounter(x; V ): means that x is the most recent value of a counter that started at a random value, and that the set V contains all the variables with previous values of the counter. E(E; x; V ): means the probability that the value of x is neither in LE nor in V is negligible. Indis(νx; V ): means that no adversary has non-negligible probability to distinguish the value of x from a random value, when he is given the values of the variables in V . In addition to variables in Var, the set V can contain a special variable LE , in which case the invariant means that no adversary has non-negligible probability to distinguish whether he is given results of computations performed using the value of x or a random value, when he is given the values of the variables in V and LE . More formally, for each invariant ψ, we deﬁne that a distribution X satisﬁes ψ, denoted X |= ψ as follows: r

r

– When LE ∈ V , X |= Indis(νx; V ) iﬀ [(S, E) ← X : (S(x, V ), E)] ∼ [(S, E) ← r X; u ← U; S = S{x → u} : (S (x, V ), E)] r – When LE ∈ V , X |= Indis(νx; V ) iﬀ [(S, E) ← X : (S(x, V ∪ LE .dom), E)] ∼ r r [(S, E) ← X; u ← U; S = S{x → u} : (S (x, V ∪ LE .dom), E)] r – X |= E(E; x; V ) iﬀ Pr[(S, E) ← X : S(x) ∈ S(LE ).dom ∪ S(V )] is negligible. – X |= lcounter(x; V ) iﬀ Indis(x; Var \ V ) and V = T (x). where LE .dom = {v1 | (v1 , v2 ) ∈ LE } and T (x) = {x ∈ Var | ∃i, j ∈ N and y ∈ Var such that Ty [i] = x and Ty [j] = y}. Notation: For a set V and a variable, we write V, x as a shorthand for V ∪ {x} and V − x as a shorthand for V \ {x}. We denote by Var∗ the set Var ∪ LE and use Indis(νx) as a shorthand for Indis(νx; Var∗ ).

Automated Veriﬁcation of Block Cipher Modes of Operation

27

The relation between these invariants are described in the following Lemma. Lemma 1. For any set V ⊂ Var and variables x, y with x = y, we have 1. Indis(νx; V ∪ LE ) ⇒ E(E; x; V \ {x}) 2. lcounter(x; V ) ⇒ Indis(x; Var \ V ) 3. E(E; x; V ) ∧ Indis(νx; {y}) ⇒ E(E; x; V, y) The ﬁrst line of this Lemma is particularly important, because it links the Indis invariant to the E invariant. This is of interest because the invariant Indis is quite a bit easier to deal with than the invariant E alone, so this enables us to infer that quite a few more variables have never been queried to the block cipher than in our previous paper (however, we have to be careful to handle correctly rules for commands that add elements to LE , but this is also done relatively easily). As a result of this, it is possible, for example, to ‘pass along’ the invariant E to multiple values in a chain of Xor operations – whereas it was only possible to pass it once in our previous paper – which is what makes it now possible to prove the security of the PCBC mode of operation. 2.3

Encryption Security

We prove the modes of encryption secure in the ideal cipher model. That is, we assume that the block cipher is a pseudo-random function.4 This is a standard assumption for proving the security of any block-cipher-based scheme. The semantic security for a mode of encryption is deﬁned as follows. Definition 2. Let EM (m1 | . . . |mi , c0 | . . . |ci ) : var xi ; ci be a generic encryption mode. A = (A1 , A2 ) be an adversary and X ∈ Dist(Γ, E). For η ∈ , let

A Advind−CP (η, X) A,M r = 2 ∗ Pr[(S, E) ← X; r r 1 (x0 , x1 , p, s) ← AO 1 (η); b ← {0, 1}; r S ← [[cp ]](S{m1 | . . . |mp → xb }, E) : 2 AO 2 (x0 , x1 , s, S (c0 | . . . |cp )) = b] − 1

where O1 = O2 are oracles that take a pair (m, j) as input, where m is a string and j is the block length of m, and answers using the j t h algorithm in EM . A1 outputs x0 , x1 such that |x0 | = |x1 | and are composed of p blocks. The mode of A operation M is semantically (IND-CPA) secure if Advind−CP (η, X) is negligible A,M for any constructible distribution ensemble X and polynomial-time adversary A. Our method veriﬁes the security of an encryption scheme by proving that the ciphertext is indistinguishable from random bits. It is a classical result that this implies semantic security. More precisely: 4

While block ciphers are really families of permutations, it is well known that pseudorandom permutations are indistinguishable from pseudo-random functions if the block size is large enough.

28

M. Gagn´e et al.

Proposition 1. Let EM (m1 | . . . |mi , c0 | . . . |ci ) : var xi ; ci be a generic encrypi tion mode. If, after execution of ci the invariant j=0 Indis(νcj , IO) holds, where IO = {m1 , . . . , mi , c0 . . . , ci }, then the encryption mode is semantically secure.

3

Hoare Logic Rules

In the following, the notation {ϕ}c{ϕ } means that execution of command c in any distribution that satisﬁes ϕ leads to a distribution that satisﬁes ϕ . Using Hoare logic terminology, this means that the triple {ϕ}c{ϕ } is valid. We group rules together according to their corresponding commands. We do not provide rules for the commands x := E −1 (y) or x := y[n, m] since those commands are only used during decryption. In all the rules below, unless indicated otherwise, we assume that t ∈ {x, y, z} and x ∈ {y, z}. In addition, for all rules involving the invariant Indis, LE can be one of the elements in the set V . Random Assignment $

– (R1) {true} x ← − U {Indis(νx) ∧ lcounter(x; {x})} $

− U {Indis(νt; V, x)} – (R2) {Indis(νt; V )} x ← $

– (R3) {E(E; t; V )} x ← − U {E(E; t; V, x)} Xor Operator – (X1) {Indis(νy; V, y, z)} x := y ⊕ z {Indis(νx; V, x, z)} if y = z and y ∈ V – (X2) {Indis(νt; V )} x := y ⊕ z {Indis(νt; V )} if x ∈ V , even if t = y or t = z – (X3) {Indis(νt; V, y, z)} x := y ⊕ z {Indis(νt; V, x, y, z)} Due to the commutativity of the Xor operation, the role of y and z can be reversed in all the rules above. Concatenation – (C1) {Indis(νy; V, y, z) ∧ Indis(νz; V, y, z)} x := yz {Indis(νx; V, x)} if y, z ∈ V – (C2) {Indis(νt; V, y, z)} x := yz {Indis(νt; V, x, y, z)} – (C3) {Indis(νt; V )} x := yz {Indis(νt; V )} if x ∈ V , even if t = y or t = z Increment – (I1) {lcounter(y; V )} x := y + 1 {lcounter(x; V, x) ∧ E(E; x; Var − x)} – (I2) {Indis(νy; V )} x := y + 1 {Indis(νx; V )} if y ∈ V – (I3) {Indis(νt; V )} x := y + 1 {Indis(νt; V )} if x ∈ V even if t = y – (I4) {Indis(νt; V, y)} x := y + 1 {Indis(νt; V, x, y)} if x ∈ V – (I5) {lcounter(y; V1 ) ∧ E(E; t; V2 )} x := y + 1 {E(E; t; V2 , x)} even if t = y Block Cipher – (B1) {E(E; y; ∅)} x := E(y) {Indis(νx) ∧ lcounter(x; {x})} – (B2) {Indis(νt; V ) ∧ E(E; y; ∅)} x := E(y) {Indis(νt; V, x)} provided LE ∈ V even if t = y

Automated Veriﬁcation of Block Cipher Modes of Operation

29

– (B3) {Indis(νt; V, LE , y) ∧ E(E; y; ∅)} x := E(y) {Indis(νt; V, LE , x, y)} – (B4) {lcounter(t; V ) ∧ E(E; y; ∅)} x := E(y) {lcounter(t; V )} even if t = y – (B5) {E(E; t; V, y)} x := E(y) {E(E; t; V, y)} Finally, we add a few rules whose purpose is to preserve invariants that are unaﬀected by the command. Generic Preservation Rules $ Assume that t = x, y, z and c is either x ← − U, x := yz, x := y ⊕z, or x := w +1: – (G1) {lcounter(t; V )} c {lcounter(t;V)} if y, z ∈ V – (G2) {E(E; t; V )} c {E(E; t; V )} if x ∈ V , even if t = y or t = z

4

Example

We show in Figure 2 how our new rules can be used to prove the security of the PCBC encryption mode. We only consider messages consisting of 3 blocks, as it would be clear that the propagaion of invariants would continue for any ﬁnite number of blocks. To simplify the exposition, we only show the invariants that are necessary for the proof of security. An automated veriﬁer would obtain the proof of security by applying every applicable rule at each execution step. In all the examples, we denote by, say, (L3) the use of the third part of Lemma 1. EP CBC (m1 |m2 |m3 , IV |c1 |c2 |c3 ) var IV, z1 , z2 , z3 , y2 , y3 ; $

− U; {Indis(νIV )} IV ← z1 := IV ⊕ m1 ; {Indis(νIV ; Var∗ − z1 ) ∧ Indis(νz1 ; Var∗ − IV ) ∧ E(E ; z1 ; Var − IV − z1 )} {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 )} c1 := E (z1 ); y2 := c1 ⊕ m1 ; {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var∗ − y2 ) ∧ Indis(νy2 ; Var∗ − c1 )} z2 := y2 ⊕ m2 ; {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var∗ − y2 − z2 ) ∧ Indis(νz2 ; Var∗ − c1 − y2 ) ∧ E(E ; z2 ; Var − c1 − y2 − z2 )} {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var − y2 − z2 ) c2 := E (z2 ); ∧ Indis(νc2 )} y3 := c2 ⊕ m2 ; {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var − y2 − z2 ) ∧ Indis(νc2 ; Var∗ − y3 ) ∧ Indis(νy3 ; Var∗ − c2 )} z3 := y3 ⊕ m3 ; {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var − y2 − z2 ) ∧ Indis(νc2 ; Var∗ − y3 − z3 ) ∧ Indis(νz3 ; Var∗ − c2 − y3 ) ∧ E(E ; z3 ; Var − c2 − y3 − z3 ) {Indis(νIV ; Var − z1 ) ∧ Indis(νc1 ; Var − y2 − z2 ) c3 := E (z3 ); ∧ Indis(νc2 ; Var∗ − y3 − z3 ) ∧ Indis(νc3 )} Fig. 2. Analysis of PCBC encryption mode

(R1) (X1)(X2) (L1) (B1)(B2) (X2)(X3) (X1) (X2)(X3) (X1)(L1) (B2) (B1) (X3) (X1)(X2) (X3) (X1)(X2) (L1) (B2) (B1)(B2)

30

5

M. Gagn´e et al.

Conclusion

We improved on the result of Gagn´e et al. [9] by proposing a new Hoare logic with more precise invariants and more complete rule set. This logic can be used to construct an automated veriﬁcation tool that can successfully verify the security of all the symmetric encryption modes that could be veriﬁed by [9], in addition to many more that it could not. Future directions to this work include the addition of loops to our grammar to remove the necessity of having a diﬀerent program for each message length. We would also like to use a similar system to model other security properties, such as unforgeability (for message authentication codes) and collision-resistance (for hash functions). We believe that the study of message authentication codes would be of particular interest since, combined with semantically secure encryption, it would allow us to prove the chosen-ciphertext (CCA) security of certain symmetric authenticated encryption modes.

References 1. Barthe, G., Daubignard, M., Kapron, B., Lakhnech, Y.: Computational indistinguishability logic. In: Proceedings of the 17th ACM Conference on Computer and Communications Security, CCS 2010, pp. 375–386. ACM (2010) 2. Barthe, G., Gr´egoire, B., Lakhnech, Y., B´eguelin, S.Z.: Beyond Provable Security Veriﬁable IND-CCA Security of OAEP. In: Kiayias, A. (ed.) CT-RSA 2011. LNCS, vol. 6558, pp. 180–196. Springer, Heidelberg (2011) 3. Bellare, M., Desai, A., Jokipii, E., Rogaway, P.: A concrete security treatment of symmetric encryption. In: Annual IEEE Symposium on Foundations of Computer Science, p. 394 (1997) 4. Chakraborty, D., Nandi, M.: An improved security bound for HCTR, pp. 289–302 (2008) 5. Chakraborty, D., Sarkar, P.: A New Mode of Encryption Providing a Tweakable Strong Pseudo-Random Permutation. In: Robshaw, M.J.B. (ed.) FSE 2006. LNCS, vol. 4047, pp. 293–309. Springer, Heidelberg (2006) 6. Chakraborty, D., Sarkar, P.: HCH: A new tweakable enciphering scheme using the hash-counter-hash approach. IEEE Transactions on Information Theory 54(4), 1683–1699 (2008) 7. Courant, J., Daubignard, M., Ene, C., Lafourcade, P., Lahknech, Y.: Towards automated proofs for asymmetric encryption schemes in the random oracle model. In: Proceedings of the 15th ACM Conference on Computer and Communications Security (CCS 2008), Alexandria, USA (October 2008) 8. Gagn´e, M., Lafourcade, P., Lakhnech, Y., Safavi-Naini, R.: Automated veriﬁcation of block cipher modes of operation, an improved method. Technical Report TR2011-9, Laboratoire Verimag, Universit´e Joseph Fourier, France, 21 pages (April 2011), http://www-verimag.imag.fr/~ gagne/TechRep2011_09.pdf 9. Gagn´e, M., Lafourcade, P., Lakhnech, Y., Safavi-Naini, R.: Automated Security Proof for Symmetric Encryption Modes. In: Datta, A. (ed.) ASIAN 2009. LNCS, vol. 5913, pp. 39–53. Springer, Heidelberg (2009) 10. Halevi, S.: EME*: Extending EME to Handle Arbitrary-Length Messages with Associated Data. In: Canteaut, A., Viswanathan, K. (eds.) INDOCRYPT 2004. LNCS, vol. 3348, pp. 315–327. Springer, Heidelberg (2004)

Automated Veriﬁcation of Block Cipher Modes of Operation

31

11. Halevi, S.: Invertible Universal Hashing and the Tet Encryption Mode. In: Menezes, A. (ed.) CRYPTO 2007. LNCS, vol. 4622, pp. 412–429. Springer, Heidelberg (2007) 12. Halevi, S., Rogaway, P.: A Tweakable Enciphering Mode. In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol. 2729, pp. 482–499. Springer, Heidelberg (2003) 13. Halevi, S., Rogaway, P.: A Parallelizable Enciphering Mode. In: Okamoto, T. (ed.) CT-RSA 2004. LNCS, vol. 2964, pp. 292–304. Springer, Heidelberg (2004) 14. Iwata, T., Kurosawa, K.: OMAC: One-Key CBC MAC. In: Johansson, T. (ed.) FSE 2003. LNCS, vol. 2887, pp. 129–153. Springer, Heidelberg (2003) 15. Iwata, T., Kurosawa, K.: On the Security of a New Variant of OMAC. In: Lim, J.I., Lee, D.-H. (eds.) ICISC 2003. LNCS, vol. 2971, pp. 67–78. Springer, Heidelberg (2004) 16. Iwata, T., Kurosawa, K.: Stronger Security Bounds for OMAC, TMAC, and XCBC. In: Johansson, T., Maitra, S. (eds.) INDOCRYPT 2003. LNCS, vol. 2904, pp. 402– 415. Springer, Heidelberg (2003) 17. Jutla, C.S.: Encryption Modes with Almost Free Message Integrity. In: Pﬁtzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol. 2045, pp. 529–544. Springer, Heidelberg (2001) 18. Kurosawa, K., Iwata, T.: TMAC: Two-key CBC MAC. In: Joye, M. (ed.) CT-RSA 2003. LNCS, vol. 2612, pp. 33–49. Springer, Heidelberg (2003) 19. Liskov, M., Rivest, R.L., Wagner, D.: Tweakable Block Ciphers. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 31–46. Springer, Heidelberg (2002) 20. McGrew, D.A., Fluhrer, S.R.: The security of the extended codebook (XCB) mode of operation (2007) 21. Rogaway, P.: Eﬃcient Instantiations of Tweakable Blockciphers and Reﬁnements to Modes OCB and PMAC. In: Lee, P.J. (ed.) ASIACRYPT 2004. LNCS, vol. 3329, pp. 16–31. Springer, Heidelberg (2004) 22. Wang, P., Feng, D., Wu, W.: On the Security of Tweakable Modes of Operation: TBC and TAE. In: Zhou, J., L´ opez, J., Deng, R.H., Bao, F. (eds.) ISC 2005. LNCS, vol. 3650, pp. 274–287. Springer, Heidelberg (2005)

(SC)2 : Secure Communication over Smart Cards How to Secure Oﬀ-Card Matching in Security-by-Contract for Open Multi-application Smart Cards Nicola Dragoni1, Eduardo Lostal1 , Davide Papini1 , and Javier Fabra2 1

DTU Informatics, Technical University of Denmark, Denmark [email protected] 2 DIIS, University of Zaragoza, Spain [email protected]

Abstract. The Security-by-Contract (S×C) framework has recently been proposed to support software evolution in open multi-application smart cards. The key idea lies in the notion of contract, a speciﬁcation of the security behavior of an application that must be compliant with the security policy of the card hosting the application. In this paper we address a key issue to realize the S×C idea, namely the outsourcing of the contractpolicy matching service to a Trusted Third Party (TTP). In particular, we present the design and implementation of (SC)2 (Secure Communication over Smart Cards), a system securing the communication between a smart card and the TTP which provides the S×C matching service. Keywords: Security-by-Contract, Smart Cards, Secure Communication.

1

Introduction

The Security-by-Contract (S×C) approach [8,9] has recently been proposed as security framework for open multi-application smart cards. As its name suggests, a multi-application smart card is a smart card that can host several software applications, in contrast with the most widespread single application smart cards where each cards host only one application. The challenge is to make these cards “open” so that third-party applications can be dynamically loaded into and removed from the card at runtime (i.e., during the card’s active life). This openness requirement has a direct consequence in the security of such cards and this explains why concrete deployment of open multi-application cards has remained extremely rare. Indeed, although several standards for open multiapplication smart cards have emerged (including Java Card [21], MULTOS [5] and GlobalPlatform (GP) [15]), openness introduces the still open problem of controlling applications’ evolution, that is to control the interactions among possible applications after the card has been ﬁelded. To date, security models for smart cards (namely, permissions and ﬁrewall) do not support any type of applications’ evolution. As a result, smart card developers have to prove that all changes suitable to be applied to the card are J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 32–48, 2012. c Springer-Verlag Berlin Heidelberg 2012

(SC)2 : Secure Communication over Smart Cards

33

“security-invariant”. More formally, they have to prove that proof of compliance with Common Criteria is still valid and a new certiﬁcate is not required. The Security-by-Contract (S×C) approach has been proposed to address this applications’ evolution challenge and, indirectly, to support the openness requirement, thus making possible to deploy new applications (owned and asynchronously controlled by diﬀerent stakeholders) on a card once it is in the ﬁeld. S×C builds upon the notion of Model Carrying Code (MCC) [26] and has successfully been developed for securing mobile code ([10,7] to mention only a few papers). The overall idea is based on the notion of contract, a speciﬁcation of the security behavior of an application that must be compliant with the security policy of the hosting platform (i.e., the smart card). This compliance can be checked at load time, this way avoiding the need for costly run-time monitoring. 1.1

Contribution of This Paper

The eﬀectiveness of S×C has been discussed in [8,9], where the authors show how the approach could be used to prevent an illegal information exchange among several applications on a single smart card, and how to deal with dynamic changes in both contracts and platform policy. However, in these papers the authors assume that the key S×C phase, namely contract-policy matching, is directly done on the card, which is a resource limited device. What remains open to bring the S×C idea to its full potential is the possibility of outsourcing the contract-matching phase to a Trusted Third Party. This need comes from the hierarchy of contract and policy models of the S×C framework [9], proposed to address the computational limitations of smart cards. The rationale is that each level of the hierarchy is used to specify contracts and policies at a certain degree of expressivity and, consequently, of computational cost. As a result, “light” contract and policy speciﬁcations allow the execution of the matching algorithm directly on the card, while richer speciﬁcations require an external (i.e., oﬀ-card) matching service. Thus, the communication between the card and the trusted service provider must be secured. In this paper, we address this issue by means of the design and implementation of (SC)2 , a system speciﬁcally developed to secure the communication between a smart card and a Trusted Third Party responsible for the matching phase. In particular, the contributions of the paper can be listed as follows: – extension of the S×C framework to deals with rich contract and policy speciﬁcations (i.e., belonging to a detailed level of the S×C hierarchy of contract/policy models) – design of the (SC)2 system to secure the communication between a smart card and the TTP providing the matching service – a running Java Card based prototype implementing the proposed solution Outline of this Paper. The remainder of this paper is organized as follows. Section 2 gives a concise introduction to the S×C framework and the speciﬁc problem we tackle within that framework. The design of the (SC)2 system is sketched in

34

N. Dragoni et al.

Section 3, whereas the details about its implementation as well as its optimization are presented in Section 4. A security analysis and a discussion regarding another implementation of (SC)2 follow in Sections 5 and 6, respectively. Finally, Section 7 concludes the paper.

2

S×C for Open Multi-applications Smart Cards

The S×C framework [10,7] was originally developed for securing mobile code [10], building on top of the notion of Model Carrying Code (MCC) [26]. The key idea behind the S×C approach lies in the notions of contract and policy: a mobile application carries with a claim on its security behavior (an application’s contract ) that has to be matched against a platform’s policy before downloading the application. The main diﬀerence between these two concepts is that a contract is bounded to an application while a policy relates to a platform, such as a smart card, for instance. Thus, a contract can be seen as a security policy bounded to a piece of mobile code. This highlights one of the key features of the S×C foundational idea: by signing the code of an application, a developer binds it with the claims on its security-relevant behavior, i.e. its contract, providing a semantic to the digital signature (the digital signature does not certify only who did the application but also the behavior of the application in terms of security-relevant actions [10]). 2.1

S×C Framework... in a Nutshell

In its simplest form, the S×C approach follows a workﬂow similar to the one depicted in Fig. 1 [9]. The ﬁrst step concerns the trustworthiness of the mobile application that one wants to load on the smart card. To do this one needs some evidence to be checked on the platform. Such evidence can be a trusted signature as in standard mobile applications [30] or a proof that the code satisﬁes the contract (by means of PCC techniques [23] or using speciﬁc techniques for smartcards [12]). Once there is evidence that the contract is trustworthy, the platform checks whether the contract is compliant with the policy that the platform wants to enforce. This is a key phase called contract-policy matching in the S×C jargon. If they do match, then the application can be run without further ado, because the application is compliant with both a trusted contract and the platform’s security policy. On the contrary, if this match results in a failure, then we might reject the application or enforce the smart card’s security policy. This can be done, for instance, through inlining techniques or monitoring the application at run-time. In both cases the application will run with some overhead. In case an application comes without any evidence of its trustworthiness (trusted signature and/or proof of contract-code compliance), then the only S×C solution to run the application is to enforce the smart card’s security policy. 2.2

Problem: Securing Oﬀ-Card S×C Contract-Policy Matching

A key issue in the S×C framework concerns where the contract-policy matching takes place and who is responsible for that key phase of the S×C workﬂow.

(SC)2 : Secure Communication over Smart Cards

35

Fig. 1. S×C Workﬂow [taken from [9]]

Indeed, due to the computational limitations of a resource limited environment such as a smart card, running a full matching process on the card might be too expensive. In the S×C setting, the choice between “on-card” and “oﬀ-card” matching relies on the level of contract/policy abstraction [8,9]. As a matter of fact, the framework is based on a hierarchy of contracts/policies models for smart cards, so that each model in the hierarchy can be used to specify contracts and policies at a certain level of expressivity. We do not recall such hierarchy here, because this would be out of the scope of the paper. What instead is important to stress is that more expressivity (that is, moving from one level to the other in the hierarchy) results in rich policies and contracts, but also in a complex matching algorithm requiring more computational eﬀorts. In this paper we do not consider how contract and policies are speciﬁed, that is, in which policy speciﬁcation language. Without loss of generality, we assume that they are speciﬁed at a level of abstractions that require the outsourcing of the contract-policy matching phase, because too expensive to be performed on the card. This represents a key problem to support the S×C hierarchy of models, and more in general to bring the S×C approach to its full potential. Fig. 2 depicts the main idea, where a Trusted Third Party (TTP), for instance the card issuer, provides its computational capabilities to perform the contract-policy compliance check. This TTP could supply a proof of contractpolicy compliance to be checked on the smart card (SC). The SC’s policy is then updated according to the results received by TTP: if the compliance check was successful, then the SC’s policy is updated with the new contract and the application can be executed. Otherwise, the application is rejected or the policy enforced. Since both SC and TTP act in an untrusted environment, the key challenge to develop the above scenario is to secure the communication between SC and TTP. In particular, both contract and policy must be encrypted and signed by

36

N. Dragoni et al.

Fig. 2. Supporting Oﬀ-Card S×C Contract-Policy Matching

SC before they are sent to the TTP to ensure authentication, integrity and conﬁdentiality. Similarly, the results of the matching algorithm must be encrypted and signed by the TTP before they are sent back to the SC. In the remainder of this paper, our solution to support oﬀ-card S×C contract-policy matching by securing the communication between SC and TTP will be discussed. Before that, it is important to stress that our solution has been adapted to work on one of the most widespread technology for multi-application smart cards, namely Java Card. Java Card is based on the Application Protocol Data Unit (APDU) command-response paradigm, so well-known protocols such as Kerberos [24] or Online Certiﬁcate Status Protocol (OCSP) [22] cannot be used (or easily extended) for this purpose. This motivates the need for a new speciﬁc protocol.

3

(SC)2 : Secure Communication over Smart Cards

A Public Key Infrastructure (PKI) is used to secure the system, where keys and identities are handled through certiﬁcates exchanged between the communicating parties. For this reason, SC must engage an initialization phase, where its certiﬁcate is created and then stored in the SC along with the initial security policy and the Certiﬁcation Authority (CA) certiﬁcate. The security of the system relies on the assumption that the environment in this phase is completely trusted and secure. If this is not true, certiﬁcates stored at this time are not trustworthy. All messages exchanged between SC and TTP will be encrypted and signed in order to accomplish the aforementioned requirements for mutual authentication, integrity and conﬁdentiality. In this Section we describe the design of the (SC)2 system, distinguishing between an initialization phase and a contract-policy matching phase. The system is based on Java Card: the SC acts as a server which responds only to Application Protocol Data Unit (APDU) commands by means of APDU-response messages.

(SC)2 : Secure Communication over Smart Cards

3.1

37

Initialization Phase

This phase is divided into three diﬀerent steps: Certiﬁcate Signing Request (CSR) building [25], certiﬁcates issuing, and ﬁnally certiﬁcates and policy storage. Before this phase, the system has to be deployed on the card. SC’s key pair is generated on the card during deployment, the private key never leaves the card: this is one of the security highlights of the system which makes more diﬃcult to break the PKI. As shown in Fig. 3, the ﬁrst Trusted Reader (TR) Smart Card (SC) step consists in building the CSR SC’s public key order for the certiﬁcate to be sent to the PuKSC SC’s CSR: CA. In message #1 the Trusted SCCSR SCCSR Reader (TR) queries the SC for CSR’s signature: SPrKSC (SCCSR) SPrKSC(SCCSR) its public key which is sent in Store message #2. TR then builds the signed CSR CSR and in message #3 sends it to SC who signs it and send it Fig. 3. (SC)2 : CSRs Building back to TR in message #4. Finally, the TR stores the signed certiﬁcate. Message #4: SPrKSC(SCCSR) means that the CSR from SC (SCCSR) is signed (S) with the private key (PrK) of SC. In the second step, depicted on Fig. 4(a), TR - Certiﬁcates Manager (TRCM) sends to CA the CSR. CA issues the certiﬁcate and sends it back to TRCM. The last step, shown in Fig. 4(b), completes the initialization phase by storing in the SC its certiﬁcate, the initial security policy and the CA certiﬁcate, which is needed by the SC to verify certiﬁcates of TTPs. Once the SC has been initialized, it is ready to securely engage in any activity that involves the contract-policy matching. Speciﬁcally, the card will be able to verify the identity of the TTP, to authenticate and to authorize its requests.

Trusted Reader (TR)

Smart Card (SC) CACert

Acknowledgment

Certification Authority (CA)

TR - Certificates Manager

SPrKSC (SCCSR) SCCert

Store CA’s certificate

SCCert Acknowledgment

Store certificate

Policy Certificate issuance: SCCert

(a) Certiﬁcate Issue

Acknowledgment

Store policy

(b) Storage of Certiﬁcates and Policy on Card

Fig. 4. (SC)2 : Certiﬁcate Issue and Storage of Certiﬁcates and Policy

38

3.2

N. Dragoni et al.

Contract-Policy Matching Phase

During this phase the contract and the security policy stored in the card are sent from SC to some TTP which runs the matching algorithm and then sends the result back to SC. The goal is to make the communication between SC and TTP secure. The proposed solution is shown in Fig. 5. It is divided into three parts: certiﬁcates exchange, contract and policy sending and matching result sending.

Trusted Third Party (TTP)

Smart Card (SC)

TTPCert

Certificates exchange

SCCert SC’s certificate verification

TTP’s certificate verification

Contract and Policy order Generation: K_sess, N_sc Asymmetric encryption: EPuKTTP(K_sess), EPuKTTP(N_sc)

Contract and policy sending

[EPuKTTP(K_sess), EPuKTTP(N_sc), EK_sess(M, SPrKSC(M | N_sc))]

Digital Signature: SPrKSC(M | N_sc) Symmetric encryption: EK_sess(M, SPrKSC(M | N_sc))

Decryption and verification Run algorithm

Matching result sending

Digital Signature: SPrKTTP(R | N_sc+1) Encryption: EK_sess(R, SPrKTTP(R | N_sc+1))

[EK_sess(R, SPrKTTP(R | N_sc+1))]

Acknowledgement

Decrypt, verify and get the result

Fig. 5. Oﬀ-Card Contract-Policy Matching

In the ﬁrst part, both parties TTP and SC exchange their own certiﬁcates and then respectively check their validity. In particular, SC checks the certiﬁcate received against CA certiﬁcate which was stored during the initialization phase. If some certiﬁcate is not valid, the communication terminates. Otherwise TTP asks SC for the contract and policy. At this point, the SC engages in a sequence of actions aiming to secure the message M containing the requested information. Firstly, a session key and a NONCE (Number used Once) that will be used for this communication are randomly generated. NONCE (Nsc ) is used to avoid replay attacks. The encryption of the message M is done by means of symmetric cryptography, mainly because it provides higher speed than the asymmetric one (based on PKI). Security is also improved by the lack of linearity since the session key changes for each session. After that, SC encrypts the session key and Nsc

(SC)2 : Secure Communication over Smart Cards

39

with TTP’s public key ensuring that only TTP will be able to get them. Once that is done, the message M concatenated with the Nsc is hashed and then signed. This way, the system provides to the signature with freshness. As Nsc changes, signature does as well for the same contract and policy. Finally, conﬁdentiality is ensured through the encryption of message M and signature by means of the session key. The message to be sent to TTP contains the session key and the Nsc encrypted by TTP’s public key, and the message and signature encrypted by the session key, this is, Message #4: EP uKT T P (Ksess ), EP uKT T P (Nsc ), EKsess (M , SP rKSC (M |Nsc )). The message is then sent to TTP, which veriﬁes it and extracts the needed information. In the last step, the TTP runs the matching algorithm using the information received in the previous message. When the algorithm ﬁnishes, it builds a secure message containing the result R to be sent to SC. The session key, which has been previously generated on SC and sent encrypted to TTP, is used again to encrypt the result R along with the signature, which is done over the result R concatenated with Nsc + 1. The change in the value of Nsc introduces variability in the hash, making it more unlikely to forge. Thus, the message to be sent is Message #5: EKsess (R, SP rKT T P (R|Nsc + 1)). Finally, SC decrypts and veriﬁes the message getting the result of the matching algorithm. Due to the fact that every APDU communication is made up of a command and a response, the protocol ﬁnishes with the sending of an acknowledgement to the TTP.

4

(SC)2 Implementation

The implementation of the (SC)2 system is depicted in this Section. Due to the constrained nature of smart cards, we will particularly focus on (SC)2 optimization in terms of memory usage and also performance. 4.1

Implementation

Diﬀerent programming languages have been used according to whether the entity was an oﬀ-card one or not. Java version 1.6 has been used to implement the TTP and the TR, while SC has been implemented with Java Card 2.2.2. On one hand, Java was chosen because of its multi-platform feature since TTP should be run over diﬀerent devices. On the other hand, Java Card 2.2.2 has been chosen due to the lack of maturity of Java Card 3 (actually, there are no cards supporting its implementation). It is worth mentioning that an APDU extended length capability has been implemented in order to send up to 32 KB data messages instead of the by-default maximum 255 bytes size. Moreover, the garbage collection is done on-demand. Concerning the execution over a SC simulator, two diﬀerent environments have been used: at the earliest stages we adopted Java Card Platform Workstation Development Environment (Java Card WDE) tool and then we moved to C-language Java Card Runtime Environment (CREF) as soon as development needed to save the status of the card.

40

N. Dragoni et al.

Certiﬁcates. Authentication is ensured by means of X.509 certiﬁcates [17]. Certiﬁcates used in (SC)2 are generated by means of OpenSSL 0.9.8n. In order to test the system, certiﬁcates for CA and TTP have to be created. CA root certiﬁcate is generated as a self-signed certiﬁcate. During the initialization phase, the CSR’s signature is done through SHA as hash algorithm whose digest is encrypted using RSA with a padding according to the PKCS#1 (v1.5) scheme [19]. Once the CSR is ready, it is sent to the CA. OpenSSL veriﬁes it and, by means of the CA root certiﬁcate, issues a new certiﬁcate corresponding to the CSR received. The certiﬁcates are stored on-card as byte arrays and DER-encoded [16]. Parser. An on-card parser has been developed to verify the validity of certiﬁcates received by the SC. Speciﬁcally, what is checked is the compliance with DER and ASN.1 encoding, the signature, the key algorithm and length and the corresponding issuer. The oﬀsets of a couple of parts of CA’s certiﬁcate are stored on SC in order to ease its access during TTP certiﬁcate’s veriﬁcation [14]. In contrast, SC only needs to temporary store the oﬀset of the TBSCertiﬁcate part [17] from TTP’s certiﬁcate. TTP’s certiﬁcates are stored temporary because each certiﬁcate is analyzed only once when it is parsed. Certiﬁcates are parsed from the beginning following the DER encoding which guides the parser through their TLV-structure (Tag-Length-Value). The encoding is checked and every part is reached, extracting it if needed (i.e., public key). At the end, the signature is veriﬁed against the CA’s public key. Cryptography. Both the aforementioned simulation environments suﬀer from a problem that sets limitations on the prototype: not every algorithm from the API is implemented for these environments [29]. Namely, the main problems are related to the length in RSA keys and the secure random algorithm. In the following, they will be detailed more thoroughly. Concerning asymmetric cryptography, RSA is used with a padding according to the PKCS#1 (v1.5) schema. The length of RSA keys used in the prototype is 512 bits because it was the only one provided by the environment as it has been previously pointed out. However, without this limitation a 2048-bit key size would be used. The other limitation is related to the random number generator. In the prototype a Pseudo-Random Generator has been used. Nevertheless, it is recommended to use a Secure Random Number Generator to avoid the predictability of the linear congruential algorithms [28]. The chosen symmetric block cipher is AES with 128 bits key length and block size in Cipher Block Chaining (CBC) mode. This mode makes necessary the use of an Initialization Vector (IV), known by both sides of the communication in order to properly ﬁnish the encryption/decryption process. Nsc ﬁts perfectly, since it is random and fresh in every new session. Therefore, IV takes the ﬁrst 128 bits from Nsc .

(SC)2 : Secure Communication over Smart Cards

4.2

41

Optimization

Smart cards are limited in terms of resources, mainly in memory aspects. Some issues must be considered by developers and also by card suppliers, especially that the card applet will not provoke a memory overﬂow due to dynamic class instantiations and also that memory limits are not reached. The smart card industry has provided developers with some speciﬁc programming guidelines and methodologies in order to keep memory usage under control. Optimization of Java Card applications normally concerns adapting and formalizing traditional methods of optimization to Java Card programs as well as developing new techniques, with the main aim of minimizing execution time and memory consumption. There are some approaches which have faced the problem of memory overﬂow at Java Card. In [13], for example, a constraint-based algorithm able to determine potential loops and mutually recursive methods is proposed. This algorithm processes the applet bytecodes by means of a set of processing rules, designed in such a way that a certiﬁed analyzer could be extracted from their proof of correctness. A similar approach was previously depicted in [3], where a constraint-based algorithm was built and then formally extracted from the proof of correctness of the algorithm in the proof assistant Coq [1]. However, the approach presented in [13] improved the one presented in [3] with respect to memory usage and also with respect to its scope (the ﬁrst one also covered subroutines and exceptions, which were not addressed in the second one). Both the problem of instantiating classes inside loops and the incorrect usage of recursive functions in Java-based smart cards are still open challenges. An interesting approach is [20], where the author describes an on-card bytecode veriﬁer, but it does not address properties related to memory usage. Previous work [3] presented a certiﬁed analyzer to determine loops and mutually recursive methods but its memory footprint prevents it from being deployed on-card. Other works have faced the problem of Java Card optimization from an analytical point of view. In [6], authors propose to optimize Java Card applications by adding several new instructions to the Java Card Virtual Machine (JCVM). These instructions allow to transmit a result inside the bytecodes, thus improving the resolution of the virtual machine, reducing the quantity of the code and shortening the runtime overall performance. Other approaches propose to optimize only the bytecodes generated by a subset of operations of the virtual machine, such as in [18,11]. However, the application of these solutions to a common development cycle is quite complex, since it requires modifying the JCVM. Finally, a very interesting review to two basic techniques to optimize the Java Card bytecode set is provided in the IBM WOK 1 . These techniques can be used in the conversion step executed before downloading applets to the card, namely i) instruction set optimization, and ii) overall data layout optimization. In this work, some of the main guidelines introduced in [4] have been followed. Mainly, neither persistent nor transient objects have been created unless strictly 1

http://www.zurich.ibm.com/pdf/javacard.pdf

42

N. Dragoni et al.

required. Also, nesting method invocations has been avoided, since this practice usually leads to stack overﬂows. The code has been reviewed to ensure that objects are instantiated only once, especially when creating new instances inside loops and functions. Other well known best practices have been followed: i) merging methods to get a lighter code, avoiding the duplication of code and the addition of new signatures (which requires extra bytes); ii) a survey of useless variables has been carried out and then removed. Also, the use of declared ﬁnal static variables has been studied in order to ﬁnd the useless ones; iii) certain variables have been moved to the method where are used instead of being an attribute; iv) native functions for the management of arrays have been used to improve the execution time and also the memory usage of the resulting code, instead of generating a diﬀerent, more sophisticated code which does not get beneﬁt from the native execution; v) ﬁnally, complex code constructions have been avoided, replacing them by more simple ones. All these code programming optimizations have allowed reducing the applet memory usage before it is deployed in the card up to a 32% in code size with respect to the ﬁrst implementation of the prototype. Also, it is still possible to apply some of the optimization techniques presented previously, although this last step is out of the scope of this work. 4.3

Memory Usage Analysis

The memory usage of the resulting implementation has been evaluated. The importance of this analysis lies in showing that the theoretical idea is suitable to be implemented and ﬁts in the constrained and limited smart card resources. Several measures have been taken through the output of the CREF commands. Although the execution of the CREF commands gives us the chance to retrieve statistics and information related to the EEPROM, the transaction buﬀer, the stack usage, the clear-on-reset RAM, the clear-on-deselect RAM and also the ROM, only the EEPROM data are shown and analyzed. This is due to the fact that, on the one hand, ROM is the memory which stores binary codes of the OS and the JCVM, among others. This memory is created and initialized by the smart card manufacturer and it is not able to be modiﬁed later. That is why it lacks of interest for a developer who cannot alter it. On the other hand, RAM is the memory which stores the whole application which is running at every moment and its data. This is very important due to the fact that if an applet needs for more memory to be executed than RAM provided, this would end in an error because RAM memory resources are exhausted. However, albeit this is a problem which every developer has to keep in mind when working on smart cards, in this work it is not representative since the RAM amount remains the same and the developer should know its working size. Also, RAM is cleared at every shutdown and might be cleaned over demand; hence, it changes every card-tearing. In the case of EEPROM, this memory stores the applications and data which are dynamically loaded to the card; load which is tried to be properly managed by the S×C framework. The key point of checking the memory statics

(SC)2 : Secure Communication over Smart Cards

43

Table 1. Memory Usage in Bytes Stage Deployment Installation Initialization Running

Consumed before 6994 11476 12572 15118

Consumed after 11476 12572 15279 14572

Available before 58510 54028 52932 50386

Available after 54028 52932 50225 50932

is to know whether it is worth adding the system developed to the card or if it takes too many memory resources otherwise, thus excessively reducing the space on-card and making the multi-application framework non suitable. Table 1 depicts the memory usage in bytes for the prototype implementation. The CREF simulator provides a 64KB EEPROM memory (this is, 65536 bytes). The common size for Java Card 2.2.2 real implementations ranges between 32KB (old and constrained) and 128KB, although it is starting to use greater values. The stages shown in the left column represent the applet lifecycle, which causes the main changes over the EEPROM. First of all, the deployment stage consists of downloading the applet to the card and then storing the bytecode there. The installation stage is done by means of the static install method, which installs the applet on the card invoking a registration method. The initialization stage corresponds to the initialization phase detailed in Section 3. Finally, the running stage is the contract-policy matching phase. Rows in Table 1 depict the memory usage before and after the corresponding stage was executed. As shown, the card requires almost 7 KB which are normally reserved for some OS initialization. Downloading the applet to the card takes almost 5 KB, whilst its installation more than 1 KB. It is worth mentioning that the initialization stage is the most memory consuming, since all instances are created and most of the space is reserved in the card at that moment (keys and algorithms, for instance). However, the optimizations carried out in the code have allowed to decreases the available memory in less than 3 KB at initialization. After this stage has been performed, both SC and CA certiﬁcates as well as Policy have been stored. As an example of initial Policy for the card, a ﬁle of 518 bytes was used. Obviously, this value will change according to security needs of the card and installed applications. Finally, the EEPROM consumption of the matching algorithm only makes memory vary a few hundred bytes. To sum up, the developed system needs a rough memory space in the EEPROM of 7.5 KB. Let us now focus on several points related to the obtained values. If the stats are looked through, downloading the applet is the most consuming stage because of the extensive source code. That is because the applet has to deal with several cryptographic problems, even including an on-card parser. Usually, common applets are not as large, what means that is still possible to store a high number of them. On the other hand, the heaviest issue is bytecode downloading, as it was expected. It must be kept in mind than the smart card and also the rest of current hardware is continuously evolving, so available memory will be greater

44

N. Dragoni et al.

in a short time whilst the necessary space for the system developed will remain. As shown, the application takes more space than a usual applet because of its higher complexity, but it does not reduce the available memory considerably, thus allowing to store a large number of applications in a secure way.

5

Security Analysis

In the S×C framework the goal is to secure a smart card against installation of malicious software, therefore our focus is to guarantee the security of data and applications stored on the card. Ultimately this means that origin of the result of contract-policy matching (i.e. the TTP) must be authenticated. To make it simpler, if an attacker would manage to forge the last message of oﬀ-card contract-policy matching phase, the security of the system would be invalidated. In order to prove the system secure we have to analyze it from two diﬀerent perspectives: the designed protocols and the cryptographic primitives involved. The latter is usually assumed secure as long as proper key-sizes and cryptoalgorithms are used. On the other hand the ﬁrst is the most critical: the simplest ﬂaw in the protocol design can render a secure algorithm with the longest key practically useless. This Section is divided into two parts: the ﬁrst one focuses on protocol security and the second on cryptographic algorithms and key-sizes. 5.1

Protocol Analysis

In Section 3 we have described the protocols involved in the system, namely initialization phase (from hereon called protocol #1, see Fig. 3, 4(a) and 4(b)) and Oﬀ-card Contract-Policy Matching (protocol #2, see Fig. 2). Protocol #1 is performed in a secure environment, this is because in this phase certiﬁcates and keys are generated, subsequently SC does not have means to establish any secure communication. Hence protocol #1 is not secure, anyhow this does not invalidate the security of the system. The key of the security of the system is then protocol #2. To analyze it we used the LySa tool [2]. The LySa tool is an automated tool for verifying security properties of protocols that use cryptography to protect network communication from tampering by malicious parties. Protocols modeled in the process calculus LySa are input to the tool. The LySa tool makes a fully automated program analysis that can guarantee conﬁdentiality and authentication properties. Freshness and integrity are implicitly guaranteed whenever the Nonce is either conﬁdential or can not be predicted and whenever the probability of two diﬀerent messages colliding into the same hash is negligible. The protocol has been checked against single session (i.e., one initiator and one responder at a time). This is suﬃcient to prove that the system is secure, since Java Card technology does not allow multiple sessions (one APDU-response for one APDU-command at a time). The analysis shows that the values known to the attacker are: contract and policy order message, certiﬁcates of parties

(SC)2 : Secure Communication over Smart Cards

45

involved, and all the encrypted messages (see Fig. 2). These messages does not reveal any conﬁdential information as long as cryptography is not broken. The protocol is therefore secure. 5.2

Cryptographic Algorithms and Key-Sizes

In security, standard cryptographic algorithms are considered secure as long as the key is large enough to guarantee that the system cannot be broken for the time data or information needs to be conﬁdential. [27] extensively discuss recommended algorithms and related weaknesses, if any, along with recommended key lengths both for symmetric and asymmetric cryptography. In our implementation we chose AES-128 for symmetric and RSA-512 for the asymmetric (both values are limitations imposed by the simulator). According to [27], to break a 128 bit symmetric key you need 1016 years while for RSA-512 (whose security corresponds to 50 bit symmetric key [27]) time to break is signiﬁcantly smaller, from 10 min to 1 hour. This is unacceptable since RSA is used for certiﬁcates, which are supposed to be valid for years. Considering that this size was imposed by the simulator (Section 4), for a real implementation we recommend to use RSA-2048 (whose security corresponds to 103 bit symmetric key, time to break > 108 years). Finally, to generate the NONCE, a Secure Random Number Generator has to be used instead of a Pseudo-Random one because the latter produces predictable numbers [28].

6

Discussion

Despite the previous design (and relative prototype), another version has been developed. In the latter, every entity uses two key pairs, and consequently two certiﬁcates, one for encryption and one for signature. This way, the signature (performed with the private key for signature of the sender) is encrypted by means of the public key for encryption of the receiver. Therefore, conﬁdentiality in the signature is achieved thanks to the public key for encryption instead of the session key. The diagram of this design is depicted in Fig. 6. Since a new certiﬁcate has to be managed, some changes have been added: it is necessary to create two CSRs and store two certiﬁcates during the initialization, and also to exchange another one during the matching phase. This approach is more secure, since it increases the number of keys an attacker needs to break in order to fully attack the system (i.e., the attacker has to ﬁnd not only the session key but also to break RSA for both the certiﬁcates). On the other hand, the space needed by the prototype using two RSA key pairs is more than 1.5 KB bigger than the one needed by the proposed prototype (taking in account the prototype built uses 512-bit RSA keys, this amount is expected to increase with a 2048-bit key). Thus, since smart cards are constrained resource devices and the security level provided by symmetric encryption is more than suﬃcient (Section 5). Hence the approach requiring less space was chosen as more suitable.

46

N. Dragoni et al.

Trusted Third Party (TTP)

Smart Card (SC)

TTPCertEncr

SCCertEncr

Certificates exchange

SC’s certificate verification

TTPCertSign SCCertSign

SC’s certificate verification

TTP’s certificate verification

TTP’s certificate verification

Contract and Policy order Generation: K_sess, N_sc [EPuKTTPEnc(K_sess), EPuKTTPEnc(N_sc), EK_sess(M), EPuKTTPEnc( SPrKSCSig(M | N_sc))]

Contract and policy sending Decryption and verification

Encryption: EK_sess(M), EPuKTTPEnc(K_sess), EPuKTTPEnc(N_sc) Digital Signature: EPuKTTPEnc( SPrKSCSig(M | N_sc))

Run algorithm

Matching result sending

Encryption: EK_sess(R) Digital Signature: EPuKSCEnc( SPrKTTPSig(R | N_sc+1))

[EK_sess(R), EPukSCEnc( SPrKTTPSig(R | N_sc+1))]

Acknowledgement

Decrypt, verify and get the result

Fig. 6. Contract-Policy Matching Phase with Two Certiﬁcates

7

Conclusion

In this paper we have addressed a key open issue in the S×C framework for open multi-application smart cards, namely supporting the outsourcing of the contract-policy matching service to a TTP by securing the communication between the card and the TTP. The design of the (SC)2 system as well as its optimized implementation have been presented. The solution provides conﬁdentiality, integrity and mutual authentication altogether. Since smart cards are resource constrained devices, a memory analysis has also been presented to demonstrate the suitability of the framework for these devices. Finally, a security analysis and an alternative version of (SC)2 have been discussed.

References 1. Bertot, Y., Cast´eran, P.: Interactive Theorem Proving and Program Development. Coq’Art: The Calculus of Inductive Constructions. Texts in Theoretical Computer Science. Springer, Heidelberg (2004) 2. Bodeia, C., Buchholtzb, M., Deganoa, P., Nielsonb, F., Nielsonb, H.R.: Static validation of security protocols. Computer Security 13(3), 347–390 (2005) 3. Cachera, D., Jensen, T., Pichardie, D., Schneider, G.: Certiﬁed Memory Usage Analysis. In: Fitzgerald, J.S., Hayes, I.J., Tarlecki, A. (eds.) FM 2005. LNCS, vol. 3582, pp. 91–106. Springer, Heidelberg (2005)

(SC)2 : Secure Communication over Smart Cards

47

4. Chen, Z.: Java Card Technology for Smart Cards: Architecture and Programmer’s Guide. Addison-Wesley, Boston (2000) 5. Multos Consortium. Multos developer’s reference manual. mao-doc-tec-006 v1.45. Speciﬁcation 1.45 (2009) 6. Dawei, Z., Wenrui, D.: Optimization of resolution on Java card. Journal of Beijing University of Aeronautics and Astronautics (2009) 7. Desmet, L., Joosen, W., Massacci, F., Philippaerts, P., Piessens, F., Siahaan, I., Vanoverberghe, D.: Security-by-Contract on the .NET platform. Information Security Tech. Rep. 13(1), 25–32 (2008) 8. Dragoni, N., Gadyatskaya, O., Massacci, F.: Supporting Applications’ Evolution in Multi-Application Smart Cards by Security-by-Contract [Short Paper]. In: Samarati, P., Tunstall, M., Posegga, J., Markantonakis, K., Sauveron, D. (eds.) WISTP 2010. LNCS, vol. 6033, pp. 221–228. Springer, Heidelberg (2010) 9. Dragoni, N., Gadyatskaya, O., Massacci, F.: Security-by-contract for applicationsevolution in multi-application smart cards. In: Proc. of NODES, DTU Technical Report (2010) 10. Dragoni, N., Massacci, F., Naliuka, K., Siahaan, I.: Security-by-Contract: Toward a Semantics for Digital Signatures on Mobile Code. In: L´ opez, J., Samarati, P., Ferrer, J.L. (eds.) EuroPKI 2007. LNCS, vol. 4582, pp. 297–312. Springer, Heidelberg (2007) 11. Fournerie, L.: An in-card bytecode optimization for objects management in javabased smart cards. In: Proc. of the 4th Gemplus Developer Conference (2002) 12. Ghindici, D., Simplot-Ryl, I.: On Practical Information Flow Policies for JavaEnabled Multiapplication Smart Cards. In: Grimaud, G., Standaert, F.-X. (eds.) CARDIS 2008. LNCS, vol. 5189, pp. 32–47. Springer, Heidelberg (2008) 13. Giambiagi, P., Schneider, G.: Memory consumption analysis of java smart cards. In: Proc. of CLEI 2005, Cali, Colombia (October 2005) 14. Henninger, O., Lafou, K., Scheuermann, D., Struif, B.: Verifying X.509 Certiﬁcates on Smart Cards. World Academy of Science, Engineering and Technology 22, 25–28 (2006) 15. GlobalPlatform Inc. GlobalPlatform Card Speciﬁcation, Version 2.2. Speciﬁcation 2.2, GlobalPlatform Inc. (2006) 16. ITU-T. ITU-T Rec. X.690 Information technology – ASN.1 encoding rules: Speciﬁcation of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Technical report, ITU (2002) 17. ITU-T. ITU-T Rec. X.509 Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certiﬁcate frameworks. Technical report, ITU (2005) 18. Kim, D.-W., Jung, M.-S.: A Study on the Optimization of Class File for Java Card Platform. In: Chong, I. (ed.) ICOIN 2002. LNCS, vol. 2343, pp. 563–570. Springer, Heidelberg (2002) 19. RSA Laboratories PKCS #1 v2.1: RSA Cryptography Standard. RSA Security Inc. Public-Key Cryptography Standards (PKCS) (June 2002) 20. Leroy, X.: Bytecode veriﬁcation on java smart cards. Softw. Pract. Exper. 32, 319– 340 (2002) 21. Sun Microsystems. Runtime environment speciﬁcation. Java CardTM platform, version 3.0, connected edition. Speciﬁcation 3.0, Sun Microsystems (2008) 22. Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: X.509 Internet Public Key Infrastructure Online Certiﬁcate Status Protocol - OCSP. RFC 2560 (June 1999)

48

N. Dragoni et al.

23. Necula, G.C.: Proof-carrying code. In: Proc. of the 24th ACM SIGPLAN-SIGACT Symp. on Princ. of Prog. Lang., pp. 106–119. ACM Press (1997) 24. Neuman, B.C., Ts’o, T.: Kerberos: an authentication service for computer networks. IEEE Communications Magazine 32(9), 33–38 (1994) 25. Nystrom, M., Kaliski, B.: PKCS #10: Certiﬁcation Request Syntax Speciﬁcation version 1.7. Technical report, RSA Security, Internet RFC 2986 (November 2000) 26. Sekar, R., Venkatakrishnan, V.N., Basu, S., Bhatkar, S., DuVarney, D.C.: Modelcarrying code: a practical approach for safe execution of untrusted applications. In: Proc. of SOSP 2003, pp. 15–28. ACM (2003) 27. Smart, N.: ECRYPT II Yearly Report on Algorithms and Keysizes (2009-2010) (March 2010) 28. Stallings, W.: Cryptography and Network Security: Principles and Practice. Pearson Education (2002) 29. Sun Microsystems, Inc. Development Kit User’s Guide, Java Card Platform, Version 2.2.2 (March 2006) 30. Yee, B.S.: A Sanctuary for Mobile Agents. In: Vitek, J., Jensen, C.D. (eds.) Secure Internet Programming. LNCS, vol. 1603, pp. 261–273. Springer, Heidelberg (1999)

Private Identification of RFID Tags Behzad Malek1 and Ali Miri2 1

School of Electrical Engineering and Computer Science University of Ottawa, Ottawa, ON, Canada [email protected] 2 Department of Computer Science Ryerson University, Toronto, ON, Canada [email protected]

Abstract. A lightweight identiﬁcation mechanism is proposed for RFID systems in which the privacy of tags is protected against unknown readers. Private identiﬁcation of RFID tags allows authorized readers to easily identify the tags. The identity of the tag is secure across multiple readers, and unknown readers will not be able to trace the tag throughout the system. Our proposed scheme is based on McEliece public-key cryptosystem rearranged in a novel way to meet the practical requirements of RFID tags. Complex computational operations in the McEliece cryptosystem are removed from the RFID tags, as they only perform simple binary operations on short vectors.The public-key cryptosystem simpliﬁes the key sharing in the system, and it can readily scale to large RFID systems. Keywords: RFID, Privacy, Identiﬁcation, Public-key, Error-correcting Code, McEliece.

1

Introduction

Advancement in technology has enabled mass production of cheap, miniaturized Radio Frequency IDentiﬁcation (RFID) tags that can wirelessly transmit an electronic identiﬁer to a reader. RFID tags are usually very small in size and transparent to their bearer. They can be wirelessly activated and scanned without notice. Every time, an RFID tag is scanned, it immediately responds (almost always) with the same identiﬁcation number. Therefore, it is possible to covertly trace RFID tags over a long distance. RFID tags have become rampant in every application ranging from animal/cargo tracking to items labeling and payment systems. In some applications, RFID tags can contain sensitive data, such as a user’s location, previous purchases, shopping preferences, dates of birth, credit card numbers or other personal information. Emphasis has always been to protect the sensitive data carried on the RFID tags by encryption. However, some sensitive data, such as the location or frequency of a visit to a speciﬁc store, even if they are protected via encryption, can be uncovered simply by tracing a tag. In other words, security by encryption does not suﬃce to protect the privacy of RFID tags, and we need to design privacy mechanisms to protect identiﬁcation J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 49–61, 2012. c Springer-Verlag Berlin Heidelberg 2012

50

B. Malek and A. Miri

of RFID tags. Our approach to protect the privacy of RFID tags is to limit the identiﬁcation of a tag to authorized readers only and to not reveal the identity of the tag to unauthorized readers. The drive for low-cost mass-production demands for a minimalist approach that can are suitable for low-cost RFID tags, in particular EPC Gen 2 tags [3]. Low-cost RFID tags do not usually have the computational or memory resources to perform complex cryptographic operations. Nevertheless, most of existing identiﬁcation protocols for RFID tags are secured based on complex cryptographic operations that are computationally infeasible for low-cost RFID tags. In this work, we focus on protecting the privacy of low-cost (EPC Gen 2) RFID tags. In our design of a private identiﬁcation scheme for low-cost RFID tags, we consider the following requirements: – Private Identiﬁcation: Only (pre)authorized readers can correctly identify an RFID tag and receive its identity. Unauthorized readers could not reveal the identity of a tag. – Lightweight: The private identiﬁcation protocol must be suitable for lowcost RFID tags, especially EPC Gen 2 tags that have little memory. – Proven Security: Security of the private identiﬁcation protocol must be based on a reliable cryptosystem that can be conﬁdently trusted in sensitive applications. In other words, there the security of protocol should be provided by a known security problem in cryptography. – Key Management: Asymmetric (public-key) key-sharing algorithms greatly simplify the management of secret keys and are recommended in the design. In any Public Key Infrastructure (PKI), there are two sets of keys: a public-key, which is publicly known to everyone in the system and a corresponding private key, which is kept privately by one owner. Every two entities holding a public and private key pair are able to securely share any secret selected on their own. – Probabilistic: The private identiﬁcation protocol must be probabilistic; that is protocol is randomized and the same tag sends diﬀerent (indistinguishable) messages in every new session. This is very vital in a security system, as it safeguards the system against replay attacks. – Correctness: Another desirable property is that the intended reader must be able to correctly identify an RFID tag and reveal its identity with certainty. Given these requirements, we design a lightweight, private identiﬁcation protocol for RFID tags, which is derived from a well-known cryptosystem, i.e. McEliece cryptosystem [14]. McEliece cryptosystem is an eﬃcient public-key cryptosystem, which is based on error-correcting binary codes. Therefore, McEliece is suitable for implementation in small devices, such as RFID tags, that have limited resources. However, McEliece cryptosystem cannot be directly applied to EPC Gen 2 tags. The public-key matrix in McEliece cryptosystem is very large and it will require a lot of memory1 . Small RFID tags, such as EPC Gen 2 tags, have little memory, which is usually less than 1K bits. 1

It is stated that the public-key matrix in McEliece cryptosystem alone requires about 6.5M bits of memory [14].

Private Identiﬁcation of RFID Tags

51

With further improvements on McEliece cryptosystem and a new arrangement of the system, we are able to design a lightweight identiﬁcation protocol that preserves the privacy of RFID tags. Contributions: Our contributions in this work are as follows: We propose a private identiﬁcation scheme that can be easily implemented in low-cost RFID tags, such as EPC Gen 2 tags [3]. Our scheme is based on an eﬃcient public-key cryptosystem, i.e. McEliece, making the key management easier in large RFID systems. The size of the public-key matrix in McEliece is so big that it cannot be directly used in small RFID tags. We have made modiﬁcations to the original McEliece cryptosystem, so that it can be ﬁt into small RFID tags without reducing the size of the parameters suggested for a high security level. Outline: This work is organized as follows: we ﬁrst give an overview of the related work in Section 2. The required background to understand the main scheme is provided in Section 3. The detailed description of our scheme with its security analysis is given in Section 4. The resource requirements are provided in Section 5 followed by the conclusions and future work in Section 6.

2

Related Work

In RFID systems, the price of the tag usually determines its capabilities for complex cryptographic functions. For very sensitive applications, expensive RFID tags equipped with standard cryptography functions might be available. In many applications, expensive RFID tags are not available, and lightweight authentication schemes based on unconventional cryptographic protocols have been proposed. One of the most known lightweight authentication schemes for RFIDs is HB+ by Juels and Weis [11]. HB+ is a modiﬁcation of another authentication protocol by Hopper and Blum (HB) that was originally designed to detect human users. HB+ is applicable to low-cost RFID tags, as it only requires simplistic binary operations, such as XOR (⊕) and dot-product (·). The security of HB+ is based on the problem of decoding a random linear code [11], which is also the basis of our proposed private identiﬁcation scheme. Later in Section 3, we formally deﬁne the problem of decoding a random linear code. Although HB+ is implementable in small, low-cost RFID tags, it has a high false rejection rate; that is for 80 bits of security, the false rejection rate is estimated at 44% [6]. Moreover, HB+ is proved to be insecure against the man-inthe-middle attack [7]. Gilbert et al. [6] improve HB+ protocol and propose HB# by increasing the communication and computation overheads of the RFID tag. In HB family protocols, the communication overheads increase linearly with the security parameter. Therefore, it is not possible to reduce the communication overheads without lowering the security of the scheme. Uncertainties in HB family protocols should also be avoided in practice, especially since RFID tags communicate over noisy channels with high interference from adjacent tags. Moreover, HB+ and its variants are based on a key-symmetric algorithm that does not scale eﬃciently as the number of tags and readers increases in the system. This is

52

B. Malek and A. Miri

because the RFID tags and readers have to share the same secret key, in order to succeed in the authentication process. The number of shared secret keys increases linearly with the number of tags and also with number of readers. The situation quickly becomes unmanageable when each tag has to securely identify itself to many readers, or one reader has to handle many tags. As mentioned before, asymmetric-key (public-key) cryptosystems are superior to symmetric-key cryptosystems, and they are highly recommended in large-scale, distributed systems. It has been shown that it is feasible to implement a few of asymmetric-key (public-key) cryptosystems [5,8,9,10,13] in RFID tags. Nevertheless, key-asymmetric systems often require complex mathematical operations with large numbers. Gaborit and Girault [5] proposed an adaptation of Stern’s authentication scheme [16] as a public-key cryptosystem based on error-correcting codes that can be used in RFID systems. Code-based cryptosystems generally require simple binary operations, and it is suitable for hardware implementations. In McEliece cryptosystem [14], the main encryption operations are comprised of mostly matrix and vector operations over binary ﬁelds. However, the main problem in using code-based cryptosystems in RFID tags is that large binary matrices have to be stored in the tag’s memory. Berger et al. [1] have shown how to reduce the size of public-keys in the McEliece cryptosystem from 6.5M bits in its original format [14] to 6.8K bits. However, the size of matrices to be used in low-cost RFID tags is still too large and its implementation is not feasible for EPC Gen 2 tags, which have only about 1K bits of memory. In the next section, we provide a brief introduction on McEliece cryptosystem, only suﬃcient to understand the proposed private identiﬁcation protocol in Section 4. For a detailed review, we refer the reader to [1] and [14].

3

Background

McEliece cryptosystem is a code-based cryptosystem and its security is based on a well known complexity assumption in the coding theory. Therefore, it is necessary to provide some basics of coding theory here. 3.1

Coding Theory

An algebraic expansion of length N over a binary ﬁeld F2 of 2k codewords is a code C, denoted by [N, k, d], where d is the minimum of pairwise Hamming distances between every two codewords. C is a linear code if and only if there are 2k codewords that form a k-dimensional subspace of the vector space of all the N -tuples over F2 . When working with binary codes deﬁned over F2 , the Hamming weight, denoted by w(·), of a codeword is the number of non-zero positions in the codeword. The k × N matrix G is called a generator matrix of the code if k linearly independent codewords form the rows of G. A vector a of length k is mapped (encoded) into a codeword c of length N using the generator matrix via c = aG. The parity-check matrix is a (N − k) × N matrix, denoted by H, that satisﬁes HGT = 0, where GT is the transpose of matrix G. We can check whether a codeword belongs to a code

Private Identiﬁcation of RFID Tags

53

C by applying the parity-check matrix on the codeword. Since for every codeword c ∈ C, we have: HcT = HGT aT = 0. In the coding theory, the Hamming distance between two binary codewords of equal length, denoted by d in this work, is deﬁned as the number of positions the codewords are diﬀerent. It is known that a code with the minimum Hamming distance d can detect up to d − 1 errors in a codeword and correct up to (d − 1)/2 errors [12]. 3.2

Complexity Assumption

Linear codes to be used in McEliece cryptosystem have to possess certain complexity properties. The security of our schemes is based on the complexity of the Syndrome Decoding (SD) problem, which is stated as follows: Deﬁnition 1 (Syndrome Decoding Problem). Let H be a parity-check matrix of a binary code [N, k, d]. Suppose i is the syndrome of a vector e and p is an integer. The question is if one can find a vector e of length N , such that HeT = i and w(e) < p, where w(e) returns the Hamming weight of e. There is also a decision problem variant of the SD problem, which is deﬁned as follows: Deﬁnition 2 (Syndrome Decoding Decision Problem). Let G be a generator matrix of a binary code [N, k, d], y a binary vector of length N and p an integer. The challenge is to find a vector e of length N and Hamming weight p, such that y ⊕ e ∈ C. In other words, the SD decision problem is to know if there exists a pair (m, e), such that y = mG ⊕ e, where w(e) = p. The SD problem is NP-complete, and one can go from the parity-check matrix in the SD to the generator matrix in the SD decision problem (and vice-versa) in polynomial time [14]. 3.3

McEliece Cryptosystem

The McEliece cryptosystem [14] is a public-key cryptosystem based on the SD decision problem. Let [N, k, d] be a linear code with length N , dimension k and a minimum distance d. Let G be the generator matrix of an eﬃcient code for which an eﬃcient decoding algorithm exists. G is a k-by-N matrix. Take a random invertible k × k-matrix S and a random permutation N × N -matrix P . Compute the public-key as the matrix as F = SGP and [N, k, d]. To encrypt a message denoted by a binary vector m ∈ F2k , pick a random error vector e ∈ F2N , such that its weight is equal to d−1 2 . Then compute y = mF ⊕ e and output y ∈ F2N . With the knowledge of the decoding algorithm of G and the matrices S and P , the ciphertext y is decrypted as follows: First calculate yP −1 = mSG ⊕ eP −1 and then decode the result. It should be noted that since P −1 is a permutation matrix, eP −1 has the same weight as e. Therefore, the weight of eP −1 and e are the same.

54

B. Malek and A. Miri

In other words, the number of errors in mSG⊕eP −1 is equal to d−1 2 and mSG can be recovered. After correcting yP −1 , decode the result to obtain mS and remove S by applying S −1 . A randomized version of McEliece is proposed recently by Nojima et al. [15]. Randomized McEliece [15] is a probabilistic cryptosystem in which the encryption algorithm encrypts [r|m] instead of m itself. Let’s suppose that k1 is the length of the random string r, and k2 is the length of the message m. k1 and k2 are chosen, such that k = k1 + k2 and k1 = bk, where b < 1 is a positive rational num9 . The decryption algorithm is almost the same as in the original ber, e.g. b = 10 McEliece except that it outputs only the last k2 bits of the decrypted string. For more details, we refer the reader to the original paper [15]. Using the randomized McEliece cryptosystem, we design an identiﬁcation protocol, where a tag can present its identity to an authorized reader while unauthorized readers would not be able to ﬁnd any information about the tag’s identity.

4

Private Identification

Almost in every RFID system, RFID tags respond to any reader in the system, and they can be queried with no restriction. Automatic querying of the tag’s identity by unknown readers should be prohibited, as it poses a great privacy threat. As mentioned before, in some applications, even encryption of the tag’s content is not enough to protect the sensitive data on the tag. Some information such as the number of visits to a store or location of the tag can be revealed simply by just tracking a tag using its unique identity. On one hand, tags should present their unique identities to authorized readers to receive tag-speciﬁc services. On the other hand, the identities should not be traceable throughout the system. Our goal is to design a realistic scheme that identiﬁes the RFID tags only to their authorized readers, while tags’ unique identity is hidden from unknown readers. This serves as a great protection mechanism of privacy of their RFID tags and their security in an open environment. 4.1

Main Protocol

Our private identiﬁcation scheme is given as follows: Let’s denote the tag by T and the reader by R. Each reader R has a public-key F in the randomized McEliece cryptosystem with a given linear code [N, k, d]. The tag’s identity is uniquely mapped to an element aid ∈ F2k2 , where k2 is the size of the message block in the randomized McEliece cryptosystem. Note that in the original randomized McEliece [15], authors proposed k2 < k1 , in order to maximize the probabilistic eﬀect and to provide pseudo-randomness. Tag’s identity is then concatenated with a random binary vector r ∈ F2k1 . Recall that in the randomized McEliece cryptosystem [15], F can be denoted as F T = [F1T |F2T ], where F1 and F2 are k1 × N and k2 × N sub-matrices of F , respectively. Thus, we can divide the encrypted message (ciphertext) y = [r|aid ]F ⊕ e in two parts as shown in Eq. (1). y = c ⊕ e = [r|aid ]F ⊕ e = (rF1 ⊕ e) ⊕ aid F2

(1)

Private Identiﬁcation of RFID Tags

55

The ﬁrst part, i.e. aid F2 , is ﬁxed and carries the tag’s identity. The second part, i.e. (rF1 ⊕ e), is randomized and changes every time to provide the probabilistic security in McEliece cryptosystem. At the setup stage, when the tag is initialized, a trusted center – that can be the system administrator – calculates rF1 and aid F2 for the RFID tag and stores them in its memory. The trusted center also stores r in the tag’s memory. The tag’s identity aid is a ﬁxed element. The public-key matrix F is known for every authorized reader. The trusted center can pre-compute the set {rF1 , aid F2 , r} and would store it in the tag’s memory at the setup. It should be noted that the tag does not need to store a large matrix F . Instead, it would only store three small vectors in the set {rF1 , aid F2 , r}. Let h(·) be a (hash) function that returns k1 bits of its inputs. Note that h(·) can have a very simple design and does not need to be a cryptographic hash function. The identity of the tag is then securely transmitted to an authorized reader R via the private identiﬁcation protocol that is displayed in Algorithm 1. When the tag T is queried, the reader is ﬁrst identiﬁed to the tag. The tag then searches its memory to ﬁnd the pre-computed values rF1 , aid F2 and r corresponding to the reader R. If T does not recognize R or does not ﬁnd the corresponding values in its memory, it quits the protocol. If T does not quit in the previous step and recognizes R, it proceeds by picking a random error vector e ∈ F2N , such that its weight is equal to d−1 2 . It then computes y = rF1 ⊕ aid F2 ⊕ e and sends it to R. Computing y is very simple, as T only needs to retrieve the values of rF1 and aid F2 from the memory and to add them together with e. Note that y is a valid McEliece ciphertext, which can be decrypted if R is an intended recipient and has the corresponding McEliece private key. The reader R, on the other side, decrypts y to retrieve r, aid and e. The reader picks new random vectors r ∈ F2k1 and t ∈ F2N . Then, R generates a circular matrix from t, which we denote by At . It then prepares the response set S = {d0 , d1 , d2 , d3 }, where d0 = (r ⊕ h(e)), d1 = (r F1 ⊕ eAt ), d2 = (rF1 ⊕ t) and d3 = (r ⊕ h(e)). The tag receives S from the reader and expands it to S = {d0 , d1 , d2 , d3 }. Then, T proceeds as follows: if its stored value of r from memory is not equal to (d3 ⊕h(e)), it quits the protocol noticing that the reader R has failed to decrypt y correctly. Otherwise, it generates a circular matrix At from d2 ⊕ rF1 and calculates eAt . Calculating eAt can be done very eﬃciently, since At is a circulant matrix and e has only a few non-zero digits in it. Finally, T replaces rF1 and r in the memory by d1 ⊕ eAt and d0 ⊕ h(e), respectively. The next identiﬁcation round is executed similarly with new values of r F1 and r . Correctness: It is easy to check the correctness of the proposed protocol. The ﬁrst condition that T checks is to verify (d3 ⊕ h(e)) = r, where d3 = r ⊕ h(e). It proves to T that the reader has successfully decrypted the ciphertext y, and it can be trusted. The tag will then ﬁnd the random vector t by computing d2 ⊕ rF1 = (rF1 ⊕ t) ⊕ rF1 = t. If a correct t is recovered, the tag can correctly calculate At and therefore eAt . Then, the tag calculates d1 ⊕ eAt = (r F1 ⊕ eAt ) ⊕ eAt = r F1 and replaces it with rF1 in the memory. The corresponding random vector r for r F1 is retrieved from (d0 ⊕ h(e)) = (r ⊕ h(e)) ⊕ h(e) = r .

56

B. Malek and A. Miri

Algorithm 1. Private identiﬁcation of RFID tags 1. T : ﬁnd {rF1 , aid F2 , r} for R, o.w. quit T : pick e randomly s.t. w(e) =

d−1 2

T : compute y = rF1 ⊕ aid F2 ⊕ e T : y −→ R 5. R : decrypt y and get rF1 , e, aid R : pick a random r ∈ F2k1 & t ∈ F2N R : return {(r ⊕ h(e)), (r F1 ⊕ eAt ), (rF1 ⊕ t), (r ⊕ h(e))} R : S = {d0 , d1 , d2 , d3 } −→ T 10. T : check if (d3 ⊕ h(e)) = r, o.w. quit T : compute d2 ⊕ rF1 and calculate eAt T : calculate d1 ⊕ eAt T : replace rF1 by d1 ⊕ eAt T : replace r by d0 ⊕ h(e) and quit

The proposed identiﬁcation scheme achieves several goals that are listed below: Privacy: The proposed method protects privacy of the tags, since the tag uses a diﬀerent F , so diﬀerent rF1 and aid F2 values, to communicate with various (known) readers. Furthermore, each rF1 is updated with a new r F1 every time the tag is queried by the same reader. In other words, when the tag is communicating with the same reader multiple times, the messages exchanged between the tag and the reader are randomized every time and new parameters (except for encrypted identity, i.e. aid F2 ) are generated that are not distinguishable to unauthorized readers. For an adversary who is eavesdropping on readers, identifying a speciﬁc tag has two challenges: (1) associating two diﬀerent messages S and S sent to the same reader R to one tag T ∗ and (2) matching the messages Si and Sj (i = j) sent to two different readers Ri and Rj , respectively to the same tag T ∗ . Later in the rest of this section, we show that both of these tasks are computationally impossible. Protected Identities: Encrypting the identity of an RFID tag protects it from being queried by unauthorized readers. In other words, the tag always responds with an encrypted identity to the queries, and the requester has to have the decryption key (corresponding to F used in Algorithm 1) to be able to uncover the identity. Without a proper decrypting algorithm, the requester cannot retrieve the tag’s identity. This scheme can be readily extended to encrypt tag’s content as well as its identity; one would simply encrypt the entire data on the tag with a secret key before storing the data on to the tag. The secret key can be a variation of aid that is obtained if the reader can retrieve aid in the proposed identiﬁcation method. Eﬃciency: In the original McEliece cryptosystem, the size of public-keys has to be very large to guarantee a minimum level of security (80 bits of security) [14].

Private Identiﬁcation of RFID Tags

57

The proposed private identiﬁcation method stores only pre-computed values of aid F not the entire public-key F in the tag. Even if we did not use the compressed version of McEliece [1], storing each {rF1 , aid F2 , r} in their original size requires 2.96K bits [2,14]. Computing y = rF1 ⊕ aid F2 ⊕ e can be done very fast by XORing rF1 and aid F2 values from the memory with e, which mostly contains 0 except at 27 random positions (for d = 56). The most complex operation at the tag is the computation of eAt . Note that At is a circulant matrix derived from vector t. Therefore, computing eAt can be easily done by shifting t and XORing it to itself 27 times (for d = 56). The rest of the private identiﬁcation protocol is performed with simple XOR operations. Scalability: Using a PKI allows the system to expand eﬃciently to accommodate any number of tags and readers. In any RFID system, usually a reader is in interaction with a large number, probably around thousands, of tags, whereas each tag is only communicating with a few, maybe less than ﬁve, readers. Moreover, the parameters that reader has to store in our protocol does not increase linearly with the number of tags. The only parameters the reader needs to store are the decryption key for the given McEliece system and they are ﬁxed regardless of the number of tags in the system. On the other hand, the number of parameters for the RFID tag increases linearly with the number of readers. We have shown that the RFID tags will only require little memory along with the some capabilities for simple binary operations, such as XOR and binary shift, to perform the proposed identiﬁcation scheme. This provides a security and privacy enhancement for inexpensive RFID tags that are used in most applications. We investigate the security of the proposed scheme in the rest of this section. 4.2

Security Analysis

As mentioned earlier, the privacy protection of the proposed identiﬁcation scheme comes from two assumptions: (1) it is diﬃcult to distinguish a particular tag among many tags communicating with a single reader R, and (2) it is infeasible to track a speciﬁc RFID tag by messages it sends to various readers. It can be shown that if any of the above assumptions is not valid, one could build a protocol to solve the SD problem or break the information theoretic security assumption. Assumption 1: Let’s suppose that a tag, T , has communicated with the reader R and the tag’s identity aid is known. The adversary is given aid , F1 , F2 , aid F2 , where F1 and F2 are sub-matrices of a randomized McEliece public-key F . The adversary’s challenge is to ﬁnd out from messages exchanged in the protocol, i.e. y = rF1 ⊕ aid F2 ⊕ e and S = {(r ⊕ h(e)), (r F1 ⊕ eAt ), (rF1 ⊕ t), (r ⊕ h(e))}, that the same T is present. Informally, the adversary would need knowledge of t, in order to ﬁnd eAt and to recover r F1 . Without knowing r F1 , it is shown in [15] that the randomized McEliece cryptosystem is probabilistic and therefore aid cannot be distinguished from a random identity.

58

B. Malek and A. Miri

It is easy to see that t and eAt completely hide rF1 and r F1 , respectively. Since t is an arbitrary binary vector, and therefore it is not disjoint from eAt . The adversary can even ﬁnd t ⊕ e from aid F2 , y and (rF1 ⊕ t). However, this does not yield a disjoint circular matrix At that can be used to estimate the weight of y for aid . Tracking a tag from (rF1 ⊕ t) and (r F1 ⊕ eAt ) values is also computationally impossible. The adversary might try to distinguish the tag T by extracting some useful information from (r ⊕ h(e)) and (r ⊕ h(e)) values. However, the adversary is faced with three unknowns, r, r and e, and only two equations. Therefore, it is information theoretically impossible to extract any of the unknowns without additional information. It should also be noted that in every round of identiﬁcation, new random vectors, i.e. r and e, are selected, making it impossible to extract any of the unknowns from a collection of identiﬁcation sessions. Assumption 2: The adversary might try to distinguish a speciﬁc tag T by the messages communicated to various readers. When communicating with two authorized readers Ri and Rj (i = j), the adversary’s challenge is to ﬁnd out if the same tag T is present. We show that if the adversary cannot successfully perform a cryptanalysis of McEliece ciphertexts, he cannot single out the tag T from other tags. The messages sent from T to Ri and Rj are calculated using public-key Fi and Fj , respectively. Let’s make the assumption that a compromised reader Rj only reveals the identity aid of the tag T and the random number rj that is stored on the tag’s memory. The adversary can successfully track the tag T over Ri only if he can either compromise Ri or match messages communicated with Ri to T . Without compromising Ri , the adversary cannot identify T , as it still needs to obtain ri (or ri Fi ) associated with Ri to distinguish T . Note that without having ri , the adversary can only recover ri Fi ⊕ ei , where the subscript i is placed to indicate communication with Ri . As proved in [15], knowledge of ri is essential in distinguishability of the randomized McEliece cryptosystem. We can therefore conclude that the adversary is only able to compromise the proposed private identiﬁcation scheme if it can solve the SD problem that forms the basis of the randomized McEliece cryptosystem.

5

Resource Requirements

Code-based cryptosystems, despite their many advantages for small devices, cannot be directly applied to low-cost RFID tags. The size of the public-key matrix to yield a sensible security level is too large to ﬁt in EPC Gen 2 tags that have little storage memory. The recommended parameters for a secure McEliece cryptosystem size was originally [N, k, d] = [1024, 524, 50], as suggested in [2,14]. Later the size of parameters was increased to [N, k, d] = [2960, 2288, 56], around 6.7M bits, due to new attacks found in [2]. By using quasi-cyclic alterant codes, the parameters can be compressed in McEliece cryptosystem down to [N, k, d] = [450, 225, 56] while resisting new attacks [1]. This will require around 101K bits of memory, which is more manageable yet not practical for EPC Gen 2 tags with 1K bits of memory.

Private Identiﬁcation of RFID Tags

59

Table 1. Performance of the proposed private identiﬁcation scheme in comparison with HB+, HB# Scheme

HB+

HB#

Side Memory Message XORs (bits)

(bits)

Reader

800

8,000

8,000

Tag

800

8,040

16,000

Reader

1,472

80

194,481

Tag

1,472

953

194,481

This Work Reader 101,250 Tag

1,015

Key Sharing Symmetric

Symmetric

1,130

202,500 Asymmetric

450

13,395

In the proposed private identiﬁcation scheme, we have overcome this problem by moving the complex matrix operations from the RFID tags to the readers, which usually have more computational and memory capacities. This will eliminate the need to store large matrices in small RFID tags. In order to allow for great improvements in reducing the size of McEliece parameters, we further use parameters proposed by Berger et al. [1]. We have seen that in the randomized McEliece cryptosystem, a random vector r ∈ F2k1 must be concatenated with the identity vector aid ∈ F2k2 . According to the EPC standards [4], the identity vectors aid are usually around 96 bits. In McEliece [N, k, d] = [450, 225, 56], we suggest to set k2 = 110 leaving enough bits to represent aid and therefore k1 = 115 complying with the condition k2 < k1 . We will have aid ∈ F2110 and r ∈ F2115 . Our scheme can then be directly realized in the EPC Gen 2 tags; we only have to store two small binary vectors for rF1 and aid F2 of 450 bits each, and 115 bits for r. Table 1 summarizes the resource requirements of the proposed scheme in the RFID tag and reader. In Table 1, we have estimated that the nonvolatile memory needed for the tag should contain three parameters: rF1 , aid F2 each in 450 bits and r in 115 bits, a total of 1, 015 bits. The scheme has only one round and the communication messages are limited to one vector y ∈ F2450 from the tag to the reader and S containing four vectors {d0 , d1 , d2 , d3 } from the reader to the tag. The size of S is therefore 1, 130 bits, as it is comprised of binary vectors d1 , d2 ∈ F2450 and d0 , d3 F2115 . The computations by the tag are only to check r = d3 ⊕ h(e) by 230 XORs, to compute t = d2 ⊕ rF1 by 450 XORs, to calculate eAt by around 12, 150 XORs (c. O(N log N )) and ﬁnally to evaluate d1 ⊕eAt and d0 ⊕h(e) with 450 and 115 XORs, respectively. The number of XOR operations in the tag is estimated at 13, 395 XORs. The computation complexity for the reader, on the other hand, is larger than the tag, and it is in the order of 202, 500 XOR operations. We have also compared in Table 1 the performance of our scheme with HB+ and HB# that are speciﬁcally designed for RFID tags. It is clear that even though our

60

B. Malek and A. Miri

scheme is based on an asymmetric cryptosystem, it outperforms the symmetrickey schemes of HB family and has no false detections. The comparison in Table 1 is based on the suggested practical parameters for HB+ [11] and HB# based on using Toeplitz matrices [6]. The main advantages of applying a public-key cryptosystem become evident when scaling the system to many tags and readers. In the symmetric system, the number of parameters increases linearly with the number of readers and tags combinations. However, in the proposed identiﬁcation scheme, the number of parameters are ﬁxed for the readers regardless of the number of tags in the system. This is very useful in practice, where one reader is usually managing thousands of tags.

6

Conclusions and Future Work

In this work, we have presented an identiﬁcation scheme for RFID tags that keeps them undetectable to unknown readers. Readers can remotely activate RFID tags and can inquire the tag’s identity only if they have been authorized in advance. Our scheme allows authorized readers to query and update the tags’ memory, while tracking the tag across multiple readers is (computationally) impossible both for authorized and unauthorized readers. Using a public-key cryptosystem enables the RFID system to scale without an expansion in the number of parameters in the system, as the number of tags and readers increases. In particular, the size of parameters remain constant for readers, as the number of RFID tags increases in the system. The security of the proposed scheme is based on the diﬃculty of crypt-analyzing McEliece cryptosystem, which is based on the intractability of SD problem. The proposed scheme provides a private identiﬁcation in the presence of an static adversary who only eavesdrops on the messages communicated between tags and readers. It is still an open problem to design a private scheme that preserves tag’s privacy against an adaptive adversary who can also alter the communication messages. In our scheme, true identities of the tags are revealed to authorized readers. Therefore, dishonest (authorized) readers can collude together to track the RFID tags. A continuation of this work would be to design eﬃcient schemes that keep RFID tags anonymous even before authorized readers. Moreover, the proposed scheme provides an identiﬁcation mechanisms only. It is also interesting to extend this work beyond identiﬁcation to achieve a private authentication mechanism. A full implementation of this work and measuring its performance in a real application has yet to be analyzed.

References 1. Berger, T.P., Cayrel, P.-L., Gaborit, P., Otmani, A.: Reducing Key Length of the McEliece Cryptosystem. In: Preneel, B. (ed.) AFRICACRYPT 2009. LNCS, vol. 5580, pp. 77–97. Springer, Heidelberg (2009)

Private Identiﬁcation of RFID Tags

61

2. Bernstein, D.J., Lange, T., Peters, C.: Attacking and Defending the McEliece Cryptosystem. In: Buchmann, J., Ding, J. (eds.) PQCrypto 2008. LNCS, vol. 5299, pp. 31–46. Springer, Heidelberg (2008) 3. EPCGlobal. Class-1 Generation-2 UHF air interface protocol standard (July 2010), http://www.epcglobalinc.org/standards/ 4. International Organization for Standardization. ISO/IEC 14443: Identiﬁcation cards – Contactless integrated circuit cards – Proximity cards (2008) 5. Gaborit, P., Girault, M.: Lightweight code-based authentication and signature. In: IEEE International Symposium on Information Theory (ISIT 2007), pp. 191–195 (2007) 6. Gilbert, H., Robshaw, M.J.B., Seurin, Y.: HB#: Increasing the Security and Efﬁciency of HB+. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 361–378. Springer, Heidelberg (2008) 7. Gilbert, H., Robshaw, M.J.B., Sibert, H.: An Active Attack Against HB+: A Provably Secure Lightweight Authentication Protocol. IEE Electronics Letters 41(21), 1169–1170 (2005) 8. Hoﬀstein, J., Howgrave-Graham, N., Pipher, J., Silverman, J.H., Whyte, W.: NTRUSIGN: Digital Signatures Using the NTRU Lattice. In: Joye, M. (ed.) CT-RSA 2003. LNCS, vol. 2612, pp. 122–140. Springer, Heidelberg (2003) 9. Hoﬀstein, J., Pipher, J., Silverman, J.H.: NTRU: A Ring-Based Public Key Cryptosystem. In: Buhler, J.P. (ed.) ANTS 1998. LNCS, vol. 1423, pp. 267–288. Springer, Heidelberg (1998) 10. Hoﬀstein, J., Silverman, J.H., Whyte, W.: NTRU report 012. Estimated breaking times for NTRU lattices. Technical Report 12, NTRU Cryptosystems, Inc. (June 2003) 11. Juels, A., Weis, S.A.: Authenticating Pervasive Devices with Human Protocols. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 293–308. Springer, Heidelberg (2005) 12. Kabatiansky, G., Krouk, E., Semenov, S.: Error Correcting Coding and Security for Data Networks. John Wiley and Sons (2005) ¨ Public key cryptography based pri13. Kayaa, S.V., Sava¸s, E., Levi, A., Er¸cetin, O.: vacy preserving multi-context RFID infrastructure. Ad Hoc Networks 7(1), 136–152 (2009) 14. McEliece, R.J.: A public-key cryptosystem based on algebraic coding theory: DNS Progress Report. Technical report, Jet Propulsion Laboratory (1978) 15. Nojima, R., Imai, H., Kobara, K., Morozov, K.: Semantic security for the McEliece cryptosystem without random oracles. Designs, Codes and Cryptography 49(1), 289–305 (2008) 16. Stern, J.: A New Identiﬁcation Scheme Based on Syndrome Decoding. In: Stinson, D.R. (ed.) CRYPTO 1993. LNCS, vol. 773, pp. 13–21. Springer, Heidelberg (1994)

Threshold Encryption into Multiple Ciphertexts Martin Stanek Department of Computer Science Comenius University Mlynsk´ a dolina, 842 48 Bratislava, Slovak Republic [email protected]

Abstract. We propose (T, N ) multi-ciphertext scheme for symmetric encryption. The scheme encrypts a message into N distinct ciphertexts. The knowledge of the symmetric key allows decryption of the original message from any ciphertext. Moreover, knowing T + 1 ciphertexts allows eﬃcient recovery of the original message without the key, and without revealing the key as well. We deﬁne the security property of the scheme, and prove the security of the proposed scheme. We discuss several variants of the basic scheme that provides additional authenticity and eﬃciency.

1

Introduction

Imagine a situation where a secure backup of data has to be stored on multiple locations. It is easy to achieve this using an encryption – we encrypt the data and store them on as many locations as we want. In order to recover the data again, we need a decryption key and a backup from at least one location. We can reduce the need for “full” key-management by distributing the key via secret sharing scheme and storing particular shares on speciﬁed locations. Then one can recover the data from a single backup, provided (s)he knows the key, or recover the data having backups from multiple locations, provided the key can be reconstructed from the shares. However this approach has a drawback – the key is revealed/compromised by this reconstruction, so it cannot be used for other data/purposes. Imagine another situation where data are written to multiple systems (disks) for redundancy reasons. Because of conﬁdentiality requirements, each copy of the data must be encrypted. In order to allow fast read operation, we want a recovery algorithm that computes data from encrypted copies much faster than regular decryption. The recovery should be possible as long as we have access to at least some pre-deﬁned number of copies. Our Contribution. We propose (T, N ) multi-ciphertext scheme for symmetric encryption (where 1 ≤ T ≤ N ). The scheme encrypts a message into N distinct ciphertexts. The knowledge of the symmetric key allows decryption of the original message from any ciphertext. Moreover, knowing T + 1 ciphertexts allows eﬃcient recovery the original message without the key, and without revealing the J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 62–72, 2012. c Springer-Verlag Berlin Heidelberg 2012

Threshold Encryption into Multiple Ciphertexts

63

key as well. A (1, 2) multi-ciphertext scheme called “double ciphertext mode” was proposed in [3]. Our work solves an open problem formulated there and can be viewed as a generalization of their scheme. We deﬁne the security property of the scheme that diﬀers from the deﬁnition provided in [3], which is based on indistinguishability of ciphertexts and random binary strings. We follow an approach of distinguishing encryptions of real-orrandom plaintexts, introduced by Bellare et al. [1]. We prove the security of a concrete implementation of multi-ciphertext scheme, called multiple ciphertext mode, using a proof techniques similar to [1]. We discuss several variants of the basic scheme that provides additional eﬃciency and authenticity. The paper is organized as follows. Section 2 introduces basic notions. A multiciphertext scheme and its security are deﬁned in Sect. 3. Multiple ciphertext mode is proposed in Sect. 4, together with proofs of its security. Section 5 contains variants of multiple ciphertext mode that address some eﬃciency issues and authenticity requirements.

2

Preliminaries

We denote [l] = {1, 2, . . . , l} for a positive integer l. Let k and n be positive integers. A block cipher is a function E : {0, 1}k × {0, 1}n → {0, 1}n, where for each key K ∈ {0, 1}k , the function EK (·) = E(K, ·) is a permutation on {0, 1}n. Let Bloc(k, n) be the set of all block ciphers with k-bit keys and n-bit blocks. The inverse of block cipher E is denoted by E −1 . The construction will use the arithmetic in ﬁnite ﬁeld GF(2n ), i.e. n-bit blocks are sometimes treated as elements in GF(2n ). For this purpose we assume some representation of GF(2n ) is ﬁxed and known. We denote the addition in GF(2n ), i.e. the bitwise XOR operation of two binary vectors as ⊕. Let bin(a) be an element of GF(2n ) corresponding to the n-bit binary representation of integer a ∈ {0, . . . , 2n − 1}, e.g. bin(3) = x + 1, bin(6) = x2 + x etc. A scalar product of vectors α = (a1 , . . . , al ), β = (b1 , . . . , bl ), where all ai , bi ∈ GF(2n ), is denoted as α, β, i.e. α, β = a1 b1 ⊕ . . . ⊕ al bl . The experiment of choosing a random element x from the ﬁnite set S will be $ denoted by x ← − S. Let Func(n, n ) be the set of all functions from {0, 1}n to {0, 1}n . An adversary (or sometimes a distinguisher) is a probabilistic algorithm that interacts with one or more oracles, written as superscripts, and outputs 0 or 1. Let F : {0, 1}k × {0, 1}n → {0, 1}n be a function with key space {0, 1}k , domain {0, 1}n and range {0, 1}n . A distinguisher D tries to distinguish F from a random function, having oracle access to one of them. We deﬁne its advantage as follows: − {0, 1}k : DFK (·) ⇒ 1] − Pr[f ← − Func(n, n ) : Df (·) ⇒ 1]. Advprf F (D) = Pr[K ← $

$

A function F is called (t, q, ε)-secure pseudo-random function if for any probabilistic distinguisher D that runs in time t and makes q queries Advprf F (D) ≤ ε.

64

M. Stanek

Similarly, we can deﬁne (t, q, ε)-secure pseudo-random permutation; the only distinctions are requirements for n = n , FK being a permutation on {0, 1}n for all K ∈ {0, 1}k , and the distinguisher tries to distinguish F from a random permutation. Secure pseudo-random permutation is suﬃciently secure pseudorandom function, see [1,4], the diﬀerence is negligible and related to the birthday bound of ﬁnding a collision. Therefore, similarly to [1], we use pseudo-random function instead of pseudo-random permutation to model a block cipher in the analysis of our scheme.

3

A Multi-ciphertext Scheme

Let T, N, m, l be positive integers. Let M = {0, 1}nm be the message space, and C = {0, 1}nm be the ciphertext space. A (T, N ) multi-ciphertext scheme is a quadruple of algorithms (K, E, D, Recover): – K – the key generation algorithm (we also denote the key space as K) – E : K × M → C N × {0, 1}l – the encryption algorithm. It takes a key and a message to produce N ciphertexts and an l-bit tag τ . For an M ∈ M, K ∈ K we denote E(K, M ) = EK (M ) = (C1 , . . . , CN , τ ). The tag τ is used to randomize the encryption and will be generated as a random bit-string in our construction. Moreover, in order to allow a distributed computation of individual ciphertexts, we require that knowing the key and τ allows computation of any Ci . We denote the partial encryption functions as E 1 , . . . , E N , i i.e. Ci = EK (M, τ ) for all i = 1, . . . , N . – D : K × C × [N ] × {0, 1}l → M – the decryption algorithm. It takes a key, a ciphertext, its index and a tag to produce the original message. We require the correctness of the scheme, i.e. ∀K ∈ K ∀M ∈ M ∀τ ∈ {0, 1}l ∀i ∈ [N ] :

i DK (EK (M, τ ), i, τ ) = M.

– Recover – the algorithm for message recovery without using the key. It takes at least T +1 ciphertexts and the tag τ ; the set of indices of these ciphertexts is denoted by I. The algorithm outputs the original message. More formally: ∀K ∈ K ∀M ∈ M ∀τ ∈ {0, 1}l ∀I ⊆ [N ] (|I| > T ) : i Recover({(i, EK (M, τ )) | i ∈ I}, τ ) = M.

Remark 1. Whether the tag is generated randomly by the scheme or randomly generated and supplied by application is an unimportant technical detail. In practice we can choose both approaches (however, for our deﬁnition we prefer the tag to be generated internally). For other modiﬁcations, the tag can be generated by suitable pseudorandom function and serve for authentication purposes (see Sect. 5.3 or [3]).

Threshold Encryption into Multiple Ciphertexts

65

Security. The security deﬁnition of a multi-ciphertext scheme is modeled according real-or-random property proposed by Bellare et al. [1]. An adversary is any probabilistic polynomial time machine with access to an oracle. In the ﬁrst (“real”) scenario the oracle returns encryption of given plaintext. In the second (“random”) scenario the oracle returns encryption of randomly chosen string of equal length. The adversary tries to distinguish between these two scenarios. The multi-ciphertext scheme allows recovery of the original message from T +1 or more ciphertexts. Therefore, we have to restrict the number of ciphertexts the adversary can obtain from the encryption oracle to at most T . The tag is also available to the adversary. On the other hand, we allow the adversary to choose which T ciphertexts it receives for each query. We denote the selection EK (·) (I), where I = {i1 , . . . , iT } ⊆ [N ] and |I| = T , i.e. EK (·) (I) = (Ci1 , . . . , CiT , τ ). More formally, let A be an adversary, and we denote the (privacy) advantage of A for a multi-ciphertext scheme Γ : |·| $ $ − K : AEK (·)(.) ⇒ 1 − Pr K ← − K : AEK ($ )(.) ⇒ 1 , Advpriv Γ (A) = Pr K ← $

− {0, 1}|M| . where $|·| on input M generates M ← A multi-ciphertext scheme is (t, q, ε)-secure if Advpriv Γ (A) ≤ ε, for any probabilistic adversary A that runs in time t and asks at most q queries.

4

Multiple Ciphertext Mode (MCM)

We propose a Multiple Ciphertext Mode (MCM) as a concrete instantiation of multi-ciphertext scheme. First, we describe so called basic MCM, with simple structure suitable for explanation and analysis of its properties. Then we discuss a more practical modiﬁcation of the basic MCM. All constructions are based on counter mode (CTR) of block cipher and use ideas of secret sharing schemes. 4.1

Basic MCM

The key generation algorithm is trivial, we simply choose a random k-bit key K (it will be used for underlying block cipher). For basic MCM encryption we set l = nT . The tag is generated randomly and divided into n-bit vectors τ1 , . . . , τT . These vectors are used as starting points for T independent streams of CTR blocks. Finally, we combine the CTR streams and message blocks to produce N ciphertexts. Let M = (P1 , . . . , Pm ) be the input message consisting of m blocks. We denote by MCM(E) the basic MCM with an underlying transformation E. Let us deﬁne N vectors α1 , . . . , αN ∈ GF(2n )T +1 in the following way: αi = (bin(1), bin(i), bin(i)2 , . . . , bin(i)T ), where all computations are performed in GF(2n ).

66

M. Stanek

Function EK (P1 , . . . , Pm ): $

τ = (τ1 , . . . , τT ) ← − ({0, 1}n )T for i = 1, . . . , m: (Ri,1 , . . . , Ri,T ) ← (EK (τ1 ⊕ bin(i)), . . . , EK (τT ⊕ bin(i))) β = (Pi , Ri,1 , . . . , Ri,T ) (C1,i , . . . , CN,i ) ← (α1 , β, . . . , αN , β) return ((C1,1 , . . . , C1,m ), . . . , (CN,1 , . . . , CN,m ), τ ) C1

CN

Let us denote by αi the vector obtained from αi by deleting the ﬁrst element, i.e. αi = (bin(i), bin(i)2 , . . . , bin(i)T ). Decryption algorithm is straightforward: Function DK (Cj , j, τ ): (τ1 , . . . , τT ) ← τ for i = 1, . . . , m: (Ri,1 , . . . , Ri,T ) ← (EK (τ1 ⊕ bin(i)), . . . , EK (τT ⊕ bin(i))) β = (Ri,1 , . . . , Ri,T ) Pi = Cj,i ⊕ αj , β return (P1 , . . . , Pm ) M

Knowing at least T + 1 ciphertexts (say Cj1 , Cj2 , . . . , CjT +1 ) allows recovery of the original message M without knowing the key. We show that each plaintext block Pi (for i = 1, . . . , m) can be recovered from corresponding blocks of ciphertexts: Cj1 ,i , . . . , CjT +1 ,i . From encryption equations we have (as always, the computations are in GF(2n )): Cj1 ,i = Pi ⊕ bin(j1 )Ri,1 ⊕ bin(j1 )2 Ri,2 ⊕ . . . ⊕ bin(j1 )T Ri,T Cj2 ,i = Pi ⊕ bin(j2 )Ri,1 ⊕ bin(j2 )2 Ri,2 ⊕ . . . ⊕ bin(j2 )T Ri,T ... CjT +1 ,i = Pi ⊕ bin(jT +1 )Ri,1 ⊕ bin(jT +1 )2 Ri,2 ⊕ . . . ⊕ bin(jT +1 )T Ri,T Thus, we have a system of T +1 linear equations with T +1 variables Pi , Ri,1 . . . , Ri,T . The matrix of the system (let us denote it AJ where J = {j1 , . . . , jT +1 }) is Vandermonde matrix with distinct bin(j1 ), . . . , bin(jT +1 ), and therefore the system has a unique solution. The algorithm Recover solves the system for each message block and computes the values of P1 , . . . , Pm . The eﬃciency of Recover algorithm depends on how fast we can ﬁnd an unknown Pi for particular system. The system of linear equations with Vandermonde matrix can be solved in time O(T 2 ) (e.g. see [2]), so the overall complexity of recovery is O(mT 2 ). However, we can do even better. We compute the inverse matrix A−1 J . Then ⎞ ⎞ ⎛ ⎛ Pi Cj1 ,i ⎜ Ri,1 ⎟ ⎜ Cj2 ,i ⎟ ⎟ ⎟ ⎜ ⎜ A−1 · AJ · ⎜ . ⎟ = A−1 . ⎟ J ·⎜ ⎝ .. ⎠ J ⎝ .. ⎠ IT +1

Ri,T

CjT +1 ,i

Threshold Encryption into Multiple Ciphertexts

67

and Pi can be easily computed in O(T ) time: Pi = γ, (Cj1 ,i , . . . , CjT +1 ,i ), where −1 γ is the ﬁrst row of A−1 J . We can compute AJ in advance or at the beginning of the algorithm Recover (it does not depend on ciphertexts) in O(T 2 ) time [7]. Therefore the overall complexity of recovery is O(T 2 + mT ). In practice, we can usually expect m T , so the term T 2 is not an issue. Remark 2. The lower bound for time complexity of Recover in general is Ω(mT ) (use every block of every ciphertext). Otherwise the security properties of the scheme are violated. 4.2

Security of Basic MCM

We start with analyzing the security of basic MCM in an ideal world, where the $ underlying block cipher EK (·) is modeled as a random function f ← − Func(n, n). Certainly, a random permutation (instead of function) would be more precise for ideal model of EK (·). However, the diﬀerence between random permutation and random function on {0, 1}n is negligible (a hypothetical distinguisher has to ﬁnd a collision). Therefore, for our ideal world analysis it suﬃces to take random f . Theorem 1. Let MCM(f ) be a basic MCM where the underlying block cipher $

− Func(n, n). Let A be an adversary which asks at most EK is instantiated as f ← 2 2 n q queries. Then Advpriv MCM(f ) (A) ≤ (q T m)/2 . Proof. Let (M (1) , I (1) ), . . . , (M (q) , I (q) ) be the queries that A asks its oracle. We will add a superscript “(s)” to variables in MCM to denote their value for particular query (M (s) , I (s) ). Recall, A gets a subset I (s) of ciphertexts corresponding to the encryption of M (s) in the ﬁrst scenario, and the same subset of ciphertexts corresponding to a randomly chosen plaintext in the second scenario. We deﬁne an event Over as follows: Over occurs if there exists an arbitrary overlap of any CTR streams generated by MCM when computing the answers to A’s queries. More precisely, Over happens if and only if there exist s, s ∈ {1, . . . , q}, j, j ∈ {1, . . . , T }, i, i ∈ {1, . . . , m} such that (s, j, i) = (s , j , i ) and (s) (s ) τj ⊕ bin(i) = τj ⊕ bin(i ). Since τ (s) values are generated randomly, the probability of Over is the same in both scenarios. Let us estimate the upper bound of the probability Pr[Over]. We can think of all q · T CTR streams as independent streams (τ (s) are random). The probability of overlap when generating i-th stream is upper bounded (when previous streams do not overlap) as follows: (i − 1)(m − 1) + (i − 1)m 2m(i − 1) ≤ n 2 2n qT Then the upper bound of Pr[Over] ≤ i=1 pi can be computed: pi ≤

Pr[Over] ≤

qT 2m(i − 1) i=1

2n

≤

q2 T 2m 2n

(1)

68

M. Stanek

Let Win1 (Win2 ) be the event that A outputs 1 in the ﬁrst (second) scenario. We need to estimate (upper bound) Advpriv MCM(f ) (A): Advpriv MCM(f ) (A) = Pr[Win1 ] − Pr[Win2 ] = (Pr[Win1 | Over] · Pr[Over] + Pr[Win1 | ¬Over] · Pr[¬Over]) − (Pr[Win2 | Over] · Pr[Over] + Pr[Win2 | ¬Over] · Pr[¬Over]) (s)

If there is no overlap in the CTR streams, for each ciphertext block Cj,i (for j ∈ I (s) , i ∈ {0, . . . , m}) which A receives as an oracle’s answer the following holds: (s) each value Ri,· used for encryption is random and independent of other values. Since A gets T ciphertexts, this yields the system of T linear equations with T +1 (s) (s) (s) unknowns Pi , Ri,1 , . . . , Ri,T (T × (T + 1) Vandermonde coeﬃcient matrix) – (s)

thus the corresponding plaintext block Pi can be arbitrary. Therefore, A cannot distinguish the scenarios when there is no overlap, i.e. Pr[Win1 | ¬Over] = Pr[Win2 | ¬Over] . Let us continue with estimation of Advpriv MCM(f ) (A): Advpriv MCM(f ) (A) = Pr[Win1 | Over] · Pr[Over] − Pr[Win2 | Over] · Pr[Over] = (Pr[Win1 | Over] − Pr[Win2 | Over]) · Pr[Over] ≤ Pr[Over] The proof is ﬁnished by combining this bound with (1).

Remark 3. We use ﬁxed-length messages (having m blocks) in the proofs of Theorem 1 and Theorem 2. This simpliﬁes the presentation of the proofs. However, the proofs can be easily generalized for messages with variable number of blocks. We move from the ideal world to more concrete security. We prove that the MCM(E) scheme is secure, assuming the block cipher is secure pseudo-random function. Theorem 2. Let F be a (t , q , ε )-secure pseudo-random function. Then the MCM(F ) is (t, q, ε)-secure multi-ciphertext scheme, where t = t − cq (1 + N/T ), q = q /(mT ) and ε = 2ε + q 2 T 2 m/2n for some constant c > 0. Proof. Let A be an adversary that breaks MCM(F ) scheme, i.e. Advpriv MCM(F ) (A) > ε. We build a distinguisher D that attacks the pseudo-randomness of F : Distinguisher DO(·) : $

b← − {0, 1} run A and answer its oracle queries (M, I): simulate the encryption of M using O(·) to simulate the EK calls return T ciphertexts according I if (b = b ) return 1 else return 0

Threshold Encryption into Multiple Ciphertexts

69

Distinguisher D has access to oracle O(·), instantiated as FK (·) (for random $

− Func(n, n). If A makes q queries then D key K) or a random function f ← asks q = qmT queries. Moreover, if A runs in time t then D runs in time t = t + cqm(T + N ) = t + cq (1 + N/T ) for some constant c > 0, were the additional term is due to encryptions that D performs. Let us estimate Advprf F (D). To shorten the length of probabilistic expressions we omit the random selections of K or f (they are known from the context). We have FK (·) ⇒ 1] − Pr[Df (·) ⇒ 1] Advprf F (D) = Pr[D We evaluate the ﬁrst probability. Let us deﬁne the following shortcuts: A(FK ) = FK FK |·| AEK (·)(.) , A(FK $) = AEK ($ )(.) ). Then Pr[DFK (·) ⇒ 1] = Pr[A(FK ) ⇒ 1 ∧ b = 1] − Pr[A(FK $) ⇒ 0 ∧ b = 0] 1 1 = · Pr[A(FK ) ⇒ 1 | b = 1] − · Pr[A(FK $) ⇒ 0 | b = 0] 2 2 1 = · (Pr[A(FK ) ⇒ 1] − Pr[A(FK $) ⇒ 0]) 2 1 1 = + · Advpriv MCM(F ) (A) 2 2 Similarly Pr[Df (·) ⇒ 1] =

1 1 + · Advpriv MCM(f ) (A) . 2 2

Putting this together we have Advprf F (D) =

1 1 priv · Advpriv MCM(F ) (A) − 2 · AdvMCM(f ) (A) . 2

Using the fact that Advpriv MCM(F ) (A) > ε and Theorem 1 we get Advprf F (D) >

ε q2 T 2m − n+1 = ε , 2 2

a contradiction with assumption that F is (t , q , ε )-secure pseudo-random function.

5

MCM Variants

There are several directions how the basic MCM can be improved. We discuss some possibilities in this section. 5.1

Eﬃciency of Encryption and Recovery

The encryption algorithm requires computation of T CTR streams that are combined with the message blocks to obtain N ciphertexts. Notice that knowing the key and tag τ allows a distributed computation of particular ciphertexts. This

70

M. Stanek

can be useful for an application, where a distant backup location computes just i “its own” ciphertext Ci = EK (M ) (and forgets the key afterwards, for example). The need to compute T CTR streams makes the encryption approximately T times slower than simple symmetric encryption with the same block cipher. Here we assume that the linear combinations of CTR streams can be computed much faster than performing the block cipher transformation. Otherwise, the slowdown would be even worse. In situations where a more eﬃcient computation of particular ciphertext is required, we can choose a diﬀerent set linear combinations. More importantly, diﬀerent set of linear combinations can increase the performance of Recover algorithm. To be more precise, let A be an N × (T + 1) matrix over GF(2n ) that deﬁnes the linear combinations for producing ciphertexts. For the basic MCM scheme we have (i ∈ {1, . . . , m}): ⎞ ⎛ ⎞ ⎛ ⎞ ⎛ ⎞ ⎛ α1 Pi Pi C1,i ⎜ Ri,1 ⎟ ⎜ α2 ⎟ ⎜ Ri,1 ⎟ ⎟ ⎜ ⎟ ⎜ ⎟ ⎜ ⎜ .. ⎟ ⎝ . ⎠ = A · ⎜ .. ⎟ = ⎜ .. ⎟ · ⎜ .. ⎟ . ⎝ . ⎠ ⎝ . ⎠ ⎝ . ⎠ CN,i Ri,T αN Ri,T However, we can choose a diﬀerent matrix as long as it guarantees the properties of the scheme. An zero element in j-th row of a matrix means that particular CTR stream is not needed to compute Cj . Example 1. Let us illustrate this with T = 2 and N = 3 (one can expect that N will not be very large in practical scenarios). Then, for example, the following matrix A deﬁnes an alternative computation of ciphertexts: ⎧ ⎛ ⎞ ⎪ 110 ⎨ C1,i = Pi ⊕ Ri,1 C2,i = Pi ⊕ Ri,2 A = ⎝1 0 1⎠ ⇒ ⎪ ⎩ 111 C3,i = Pi ⊕ Ri,1 ⊕ Ri,2 It is easy to verify that knowing any pair of ciphertexts does not help in computing the plaintext. On the other hand, three ciphertexts allow very fast recovery of plaintext without knowing the key: Pi = C1,i ⊕ C2,i ⊕ Ci,3 . Moreover, the ciphertext C1 and C2 can be computed as fast as standard encryption in CTR mode. 5.2

Shorter Tags

The basic MCM scheme generates the tag τ randomly as nT -bit string. We can shorten the tag to n bits by employing a pseudo-random function. Let F : {0, 1}k × {0, 1}n → {0, 1}n be a pseudo-random function (in practice we can use the underlying block cipher E). We modify the basic MCM scheme as follows: – The key generation algorithm chooses two independent random k-bit keys K, K . The key K is used in computation of CTR stream as before, and K will be used for expansion of shortened tag τ .

Threshold Encryption into Multiple Ciphertexts

71

– The encryption algorithm starts with the following code to produce τ and τ1 , . . . , τT : τ← − {0, 1}n (τ1 , . . . , τT ) ← (FK (τ ⊕ bin(1)), . . . , FK (τ ⊕ bin(T ))) $

The rest of the algorithm (computation of ciphertexts) remains intact. – The decryption algorithm must be adjusted accordingly, i.e. τ1 , . . . , τT are computed from τ as shown above. This modiﬁcation has no impact on Recover algorithm. It can be easily veriﬁed that Theorem 1 holds for this modiﬁcation, and mN Theorem 2 holds with insigniﬁcant adjustments: t = t − cq 1 + (m+1)T and q q = (m+1)T . 5.3

Authentication

In many practical situation some form of authenticity is often required in addition to conﬁdentiality provided by encryption. The multiple ciphertext mode can be extended to provide authentication. We can use a two-pass construction similar to those used for computation of authentication tag in double ciphertext mode [3] or synthetic initialization vector mode [5]. The construction uses a pseudo-random functions G : {0, 1}k × {0, 1}nm → {0, 1}n and F : {0, 1}k × {0, 1}nm → {0, 1}n. We extend the key generation algorithm to produce three k-bit random keys KG , KF and K. The ﬁrst key KG is used for computing authentication tag τG used in place of the original tag τ . The second key KF is used for producing tags for CTR streams (taking a construction from Sect. 5.2). The key K is used as in basic MCM. Therefore the encryption algorithm is modiﬁed as follows: Function EKG ,KF ,K (P1 , . . . , Pm ): τG = GKG (P1 . . . Pm ) (τ1 , . . . , τT ) ← (FKF (τG ⊕ bin(1)), . . . , FKF (τG ⊕ bin(T ))) for i = 1, . . . , m: (Ri,1 , . . . , Ri,T ) ← (EK (τ1 ⊕ bin(i)), . . . , EK (τT ⊕ bin(i))) β = (Pi , Ri,1 , . . . , Ri,T ) (C1,i , . . . , CN,i ) ← (α1 , β, . . . , αN , β) return (C1 , . . . , CN , τG ) The decryption algorithm checks for validity of authentication tag τG (beside decrypting the message). In case the authenticity cannot be veriﬁed the decryption returns nothing, except the information that the ciphertext is not authentic. We denote this by the symbol ⊥. Analogous veriﬁcation of the authentication tag τG must be added into Recover algorithm.

72

M. Stanek

Function DKG ,KF ,K (Cj , j, τG ): (τ1 , . . . , τT ) ← (FKF (τG ⊕ bin(1)), . . . , FKF (τG ⊕ bin(T ))) for i = 1, . . . , m: (Ri,1 , . . . , Ri,T ) ← (EK (τ1 ⊕ bin(i)), . . . , EK (τT ⊕ bin(i))) β = (Ri,1 , . . . , Ri,T ) Pi = Cj,i ⊕ αj , β M ← (P1 , . . . , Pm ) if (GkG (M ) = τG ) return M return ⊥

6

Conclusion

We presented and proved the properties of basic multiple ciphertext mode. We discussed some extensions of the basic construction. Interesting open problems for further research are: generalization of variant described in Sect. 5.1; design of one-pass mode that is (T, N ) multi-ciphertext scheme and simultaneously guarantees the authenticity of the ciphertexts; and exploring possible eﬃciency gains by using BRW polynomials [6] in multiple-ciphertext scheme with authentication, similar to the ideas employed in [3]. Acknowledgement. This work was supported by VEGA 1/0266/09.

References 1. Bellare, M., Desai, A., Jokipi, E., Rogaway, P.: A Concrete Security Treatment of Symmetric Encryption. In: Proceedings of the 38th Symposium on Foundations of Computer Science, pp. 394–403. IEEE (1997) 2. Bj¨ orck, ˚ A., Pereyra, V.: Solution of Vandermonde Systems of Equations. Mathematics of Computation 24(112), 893–903 (1970) 3. Chakraborty, D., Mancillas-L´ opez, C.: Double Ciphertext Mode: A Proposal for Secure Backup, Cryptology ePrint Archive, Report No. 2010/369 (2010) 4. Katz, J., Lindell, Y.: Introduction to Modern Cryptography. Chapman & Hall/CRC (2008) 5. Rogaway, P., Shrimpton, T.: A Provable-Security Treatment of the Key-Wrap Problem. In: Vaudenay, S. (ed.) EUROCRYPT 2006. LNCS, vol. 4004, pp. 373–390. Springer, Heidelberg (2006) 6. Sakar, P.: Eﬃcient Tweakable Enciphering Schemes from (Block-Wise) Universal Hash Functions. IEEE Transactions on Information Theory 55(10), 4749–4760 (2009) 7. Traub, J.: Associated Polynomials and Uniform Methods for the Solution of Linear Problems. SIAM Review 8(3), 277–301 (1966)

A Novel Commutative Blinding Identity Based Encryption Scheme Yu Chen , Song Luo, Jianbin Hu, and Zhong Chen Institute of Software, School of Electronics Engineering and Computer Science, Peking University, Beijing, China Key Laboratory of High Conﬁdence Software Technologies (Peking University), Ministry of Education {chenyu,luosong,hujb,chen}@infosec.pku.edu.cn

Abstract. In EUROCRYPT 2004, Boneh and Boyen presented two eﬃcient Identity Based Encryption (IBE) schemes that are selectiveidentity secure in the standard model. Particularly, the ﬁrst one known as BB1 -IBE, which is characterized by commutative blinding technique (BB1 -style), distinguishes itself as the most fertile ground for many applications. They also proved that BB1 -IBE is fully secure in the random oracle model but with a looser reduction. In this paper, we propose a novel IBE scheme of BB1 -style, which is fully secure in the random oracle model with a tighter reduction. Additionally, we give a chosen ciphertext secure construction of our scheme from twin technique. Keywords: identity based encryption, provable security, bilinear DiﬃeHellman problem, twin technique.

1

Introduction

Shamir [25] proposed the concept of Identity Based Encryption in 1984. IBE provides a public key encryption mechanism where a public key can be an arbitrary string such as an email address or a telephone number, while the corresponding private key can only be generated by a Private Key Generator (PKG) who has the knowledge of the master secret. The ﬁrst secure and eﬃcient IBE scheme was proposed by Boneh and Franklin in CRYPTO 2001 [8]. Their scheme, known as BF-IBE, is based on the bilinear maps between groups. Particularly, Boneh and Franklin [8] also deﬁned the formal security notions for IBE setting and proved BF-IBE was chosen ciphertext secure in the random oracle model. Since that time, many other IBE schemes have been proposed. One important research direction is achieving provable security in the standard model, because random oracle model only provides heuristic security [2]. Canetti, Halevi, and Katz [11] suggested a weaker security notion for IBE, known as selective-ID

Supported by National Natural Science Foundation of China (No.61073156). Supported by National Key Technology R&D Program in the 11th ﬁve-year Period (No.2008BAH33B01) and National Natural Science Foundation of China (No.60773163).

J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 73–89, 2012. c Springer-Verlag Berlin Heidelberg 2012

74

Y. Chen et al.

model. Shortly afterwards, Boneh and Boyen [5] proposed two eﬃcient schemes (BB1 -IBE and BB2 -IBE) with selective-ID security without random oracles. Waters then proposed a simple extension to BB1 -IBE, which we refer to as WatersIBE. In EUROCRYPT 2006, Gentry [15] presented an IBE scheme with short public parameters which was provably secure with a tight reduction based on a non-static assumption. In CRYPTO 2009, Waters [28] proposed dual system encryption which resulted in fully secure IBE and HIBE systems under simple assumption and with compact public parameters. 1.1

Related Work

We restrict our attention back to BB1 -IBE. Brieﬂy, the idea of BB1 -IBE is based on the structure that two secret coeﬃcients and two blinding factors that commute with each other under the pairing, which is referred to as commutative blinding [9]. Hereafter, we shorthand it as BB1 -style. Boneh and Boyen proved that BB1 -IBE was selective-ID secure with a tight reduction to the decisional BDH (DBDH) problem. They also presented two general methods about how to achieve full security from selective-ID security, which indicated that BB1 IBE was also fully secure in both the standard model and the random oracle model. However, the security reduction lost a factor of N ≈ 2160 and a factor of Qh ≈ 260 , respectively. Boneh and Boyen then proposed a coding-theoretic extension to BB1 -IBE that allowed them to prove full security without random oracles. However, the extension is mostly viewed as an existence proof of fully secure IBE in the standard model because it is somewhat impractical. Waters [27] further proposed Waters-IBE based on BB1 -IBE, which was proved fully secure with a polynomial reduction to the DBDH problem in the standard model, but with relative larger public parameters. Two independent papers [22] and [13] further showed how to make a trade-oﬀ between the size of public parameters and the tightness of security reduction for Waters-IBE. 1.2

Motivation

It is somewhat surprising to realize that BB1 -IBE and Waters-IBE share the same framework but have quite diﬀerent security results. The only diﬀerent part is the identity hash function. This give us a hint that the construction of identity hash function is crucial to provable security. On the other hand, it is well known that a tight security reduction is crucial to cryptographic schemes, not only from theoretic aspects, but also from practical aspects [15]. An ineﬃcient security reduction would imply either the lower security level or the requirement of larger key size to obtain the same security level. However, the security reductions of both BB1 -IBE (proven fully secure in the random oracle model) and WatersIBE are far from tight. It is also worth to remark that the BB1 -style framework naturally supports many valuable extensions: such as forward secure hierarchical IBE [6], fuzzy IBE [23], attribute-based IBE [4], wildcard IBE [1], and direct

A Novel Commutative Blinding Identity Based Encryption Scheme

75

CCA-secure1 encryption [10]. So our motivation is to construct a novel IBE scheme of BB1 -style with a tighter security reduction by employing some new identity hash function. Be aware of that many cryptographic schemes [1, 4, 6, 20] built from BB1 -IBE or Waters-IBE in a more-or-less black-box manner, and their speciﬁc schemes are not involved with the construction identity hash function. That is to say, if we can construct a more eﬃcient BB1 -style scheme by employing some new identity hash function, then the resulting BB1 -style scheme would be a better underlying primitive for the aforementioned extensions compared to BB1 -IBE and Waters-IBE. 1.3

Our Contributions

We stress that all the following results can be extended to hierarchical IBE [19] in an analogous method used in [5]. 1. In Section 3, we propose a novel IBE scheme of BB1 -style. Compared to BB1 IBE, the only modiﬁcation lies at the identity hash function. We show that this minor modiﬁcation enables us to achieve fully security with a tighter security reduction in the random oracle model. Our scheme compares favorably with other existing BB1 -style schemes in terms of the tightness of security reduction and the ciphertext size. The main drawback is that it is only provably secure in the random oracle model. But from practical aspect, inheriting the ﬂexibility of BB1 -style framework, our scheme can be used as an eﬃcient primitive in the applications where a proof in the random oracle model is acceptable. For example, Abdalla et al. [1] introduced a new system called IBE with wildcards (WIBE for short). In the same paper they also presented a concrete construction (BB-WIBE) from BB1 -HIBE which was proven secure the random oracle model. Since BB-WIBE construction is not involved with the concrete identity hash function, its security reduction could be immediately tighten if using our scheme instead of BB1 -HIBE. 2. In Section 4, we ﬁrst identify and correct an error in previous literature [13] about the CCA construction of BB1 -IBE. We then present an eﬃcient CCA construction of our scheme, i.e., encapsulating a fresh symmetric key from a BDH tuple and then employing a chosen ciphertext secure symmetric cipher to perform the encryption. Security of such construction always need to rely on a stronger assumption, e.g., [13, 21]. We avoid resorting on a stronger assumption by applying the twin technique proposed in [12]. With the help of trapdoor test, the security of our construction can be reduced to the usual computational BDH (CBDH) problem. Our CCA construction compares favorably to the scheme obtained from the generic Fujisaki-Okamoto transformation [14] in terms of ciphertext size and the tightness of security reduction. We provide in Table 1 a comparison among BB1 -IBE [5], Waters-IBE [27], and our scheme. 1

We use “CCA-secure” to denote “secure against adaptive chosen ciphertext attacks” throughout this paper.

76

Y. Chen et al. Table 1. Comparison among BB1 -style schemes Scheme BB1 -IBE Waters-IBE Our scheme BB1 -IBE+FO-transformation Our scheme+Twin Technique

Assumption Reduction factor ROM |mpk| DBDH Qh yes 4|G| DBDH 32(n + 1)Qe no (n + 4)|G| DBDH eQe yes 3|G| CBDH CBDH

eQe Qh eQe

yes yes

3|G| 4|G|

For security concern, n is suggested to be at least 128 [27]. Qe ≈ 230 , Qh ≈ 260 refer to the maximum number of private key queries and the maximum number of random oracle queries, respectively. e ≈ 2.71 is the base of the natural logarithm. The eﬃciency, ciphertext size of BB1 -IBE, Waters-IBE, and our scheme are the same.

2

Preliminary

Notation. We use Zp to denote the group {0, . . . , p − 1} under addition modulo p. For a group G of prime order we use G∗ to denote the set G∗ = G\{1G} where 1G is the identity element in the group G. We use Z+ to denote the set of positive integers. 2.1

Bilinear Maps

We brieﬂy review the facts about groups with bilinear map. Let G and GT be two groups of large prime order p, and e : G × G → GT be a map between these two groups. We say e is an admissible bilinear map if it satisﬁes the following three properties. 1. Bilinearity. The map e : G × G → GT is bilinear if e(ua , v b ) = e(u, v)ab for all u, v ∈ G and arbitrary a, b ∈ Zp . 2. Non-degeneracy. The map does not send all pairs in G × G to the identity in GT . 3. Computability. There is an eﬃcient algorithm to compute e(u, v) for any u, v ∈ G. Bilinear Map Parameter Generator. We say that a randomized algorithm GroupGen is a bilinear map parameter generator, which takes 1κ as input and output a κ bits prime number p, two groups G, GT of order p, and an admissible bilinear map e : G × G → GT . We write GroupGen(1κ ) → (p, G, GT , e). 2.2

Bilinear Diﬃe-Hellman Problem

Let G be a group of prime order p with bilinear map e : G × G → GT . The computational Bilinear Diﬃe-Hellman (CBDH) problem [5, 8] in G is as follows:

A Novel Commutative Blinding Identity Based Encryption Scheme

77

given a tuple g, g x , g y , g z ∈ G as input, output e(g, g)xyz ∈ GT . An algorithm A has advantage in solving the CBDH problem if Pr[A(g, g x , g y , g z ) = e(g, g)xyz ] ≥ where the probability is over the random choice of g in G∗ , the random choice of x, y, z ∈ Zp , and the random bits used by A. Similarly, we say an algorithm B that has advantage in solving the DBDH problem if |Pr[B(g, g x, g y , g z , e(g, g)xyz ) = 0] − Pr[B(g, g x, g y , g z , T ) = 0]| ≥ where the probability is over the randomly choice of g in G∗ , the random choice of x, y, z in Zp , the random choice of T ∈ GT , and the random bits consumed by B. We refer to the distribution on the left as PBDH and the distribution on the right as RBDH . Deﬁnition 2.1. The (decision) (t, ) BDH assumption holds if no t-time adversary has at least advantage in solving the (decision) BDH problem in G. Due to space constraints, we move the formal deﬁnitions and security notions of IBE and symmetric cipher to Appendix A and Appendix B, respectively.

3

Our Scheme

In this section, we present our BB1 -style scheme which is provably secure in the random oracle model. Setup. Run GroupGen(1κ ) to generate (p, G, GT , e), randomly select x ∈ Zp , g, Y ∈ G and compute X = g x . Next, pick a cryptographic hash function H : {0, 1}∗ → G. The public parameters are mpk = (g, X, Y, H). The master secret is msk = Y x . KeyGen. To generate the private key dID for an identity ID ∈ {0, 1}∗, pick a random r ∈ Zp and output dID = (d1 , d2 ) = (Y x Qr , g r ) ∈ G × G where Q = H(ID) is the public key of the identity ID. Encrypt. To encrypt a message M ∈ GT under the identity ID, pick a random z ∈ Zp , compute Q = H(ID). Then the ciphertext is constructed as C = (g z , Qz , e(X, Y )z M ) ∈ G × G × GT Decrypt. To decrypt a given ciphertext C = (C1 , C2 , C3 ) under ID using the private key dID = (d1 , d2 ), output C3

e(d2 , C2 ) e(g r , Qz ) = e(X, Y )z M e(d1 , C1 ) e(Y x Qr , g z ) e(g, Qrz ) =M = e(X, Y )z M e(X, Y )z e(Qrz , g)

78

Y. Chen et al.

3.1

Security Analysis

Theorem 3.1. Our scheme is IND-ID-CPA secure provided that H is a random oracle and the DBDH assumption holds in groups generated by GroupGen. Concretely, suppose there is an IND-ID-CPA adversary A that has advantage against the scheme. If A makes at most Qe > 0 private key extraction queries. Then there is an algorithm B that solves the DBDH problem with advantage at least: 1 AdvB ≥ eQe Proof. Suppose A has advantage in attacking our scheme. We build an algorithm B that solves the DBDH problem. B is given as input a random 5-tuple (g, g x , g y , g z , T ) that is either sampled from PBDH (where T = e(g, g)xyz ) or from RBDH (where T is uniform and independent in G). B’s goal is to output 1 if T = e(g, g)xyz and 0 otherwise. B works by interacting with A in an IND-ID-CPA game as follows. Setup. B sets X = g x , Y = g y , Z = g z . The public parameters are mpk = (g, X, Y, H). Note that the corresponding master secret msk, which is unknown to B, is Y x = g xy ∈ G. From the perspective of the adversary A the distribution of the public parameters are identical to the real construction. H-queries. At any time A can query the random oracle H. To respond to these queries B maintains a list of tuples ID, v, w as explained below. We refer to this list as the L list, which is initially empty. When A queries the oracle H at a point ID algorithm B responds as follows: 1. If ID already appears on the L in a tuple ID, v, w then algorithm B responds with H(ID) = g v Y w ∈ G. 2. Otherwise, B picks random v ∈ Zp , w ∈ Zm and adds the tuple ID, v, w to the L list. B responds to A with H(ID) = g v Y w ∈ G. Phase 1 - Private key queries. Upon receiving the private key query for an identity ID, B run the above algorithm to obtain H(ID). Let ID, v, w be the corresponding tuple on the L list. If w = 0, B aborts and randomly outputs its answer to the DBDH problem. Otherwise, B picks a random r ∈ Zp and constructs the private key d = (d1 , d2 ) as follows: Let rˆ = r −

x w.

Then we have v

d1 = X − w g rv Y rw x

= Y x (g v Y w )r− w = Y x (H(ID))r = Y x Qr 1

x

d2 = g r X − w = g r− w = g rˆ B can always answer the private key extraction iﬀ w = 0. Challenge. The adversary A submits two messages M0 , M1 ∈ GT and an identity ID∗ where it wishes to be challenged. Suppose (ID∗ , v ∗ , w∗ ) is the corresponding entry on the L list. If w∗ = 0, B aborts and outputs a random guess for the

A Novel Commutative Blinding Identity Based Encryption Scheme

79

DBDH challenge. Otherwise, B ﬂips a fair coin β ∈ {0, 1}, and creates the cipher∗ text as C = (Z, Z v , T Mβ ). It is easy to see that if T = e(g, g)xyz = e(X, Y )z , the challenge ∗

C = (Z, Z v , e(g, g)xyz Mβ ) = (g z , (Q∗ )z , e(X, Y )z Mβ ) is a valid encryption of Mβ under ID∗ , where Q∗ = H(ID∗ ). On the other hand, when T is uniform and independent in GT then C is independent of β in A’s view. Phase 2 - Private Key Queries. Except rejecting the query to ID∗ , B responds to the private key extraction queries the same way as it did in Phase 1. Guess. Finally, the adversary A outputs a guess β for β. If β = β, then B outputs 1 meaning Z = e(g, g)xyz . Otherwise, it outputs 0 meaning T = e(g, g)xyz . Claim. The responses to the H-queries are as in the real attack since each response is uniformly and independently distributed in G. All responses to private key extraction queries are valid. When the input 5-tuple is sampled from PBDH (where T = e(g, g)xyz ) then A’s view is identical to its view in a real attack and therefore A must satisfy |Pr [β = β ] − 1/2| ≥ . On the other hand, when the input 5-tuple is sampled from RBDH (where T is uniform in GT ) then Pr [β = β ] = 1/2. Therefore, with g uniform in G∗ , x, y, z uniform in Zp , and T uniform in GT we have that |Pr [B(g, g x, g y , g z , e(g, g)xyz ) = 1] −

1 ± − Pr [B(g, g x, g y , g z , T ) = 1] | ≥ 2

1 = 2

To complete the proof of Theorem 3.1 it remains to calculate the probability that B aborts during the simulation. Let abort denote the event that B does not abort during the simulation. B may aborts simulation for the two following events. 1. Event E1 : w = 0 when answering the private key queries either in Phase 1 or Phase 2. 2. Event E2 : w∗ = 0 during the challenge phase. Note that w is picked randomly from Zm and hidden from the adversary, we conclude that the w(s) of the private key extraction querying identities and the w∗ of the challenge identity are mutual independent. Therefore for each identity Pr[w = 0] = 1/m, and for the challenge identity Pr[w∗ = 0] = 1/m. Suppose the maximum number of private key extraction queries is Qe , we have Qe 1 1 , Pr[¬E2 |¬E1 ] = Pr[¬E1 ] = 1 − m m Therefore 1 Pr[abort] = Pr[¬E2 |¬E1 ]Pr[¬E1 ] = m

Qe 1 1− m

80

Y. Chen et al.

We can optimize the probability by setting mopt = 1+Qe (a common estimate for Qe is 230 , suggested by Bellare and Rogaway [3]). Using mopt , we have Qe 1 Qe 1 1 ≈ Pr[abort] = 1− Qe m m eQe If the adversary makes less queries Pr[abort] can only be greater. This shows B’s advantage is at least /eQe as required.

4

Chosen Ciphertext Security

Chatterjee and Sarkar [13] proposed a CCA construction of BB1 -IBE based on the oracle decisional bilinear Diﬃe-Hellman (OBDH) assumption [24], which is stronger than the DBDH assumption. Their CCA construction is as follows: compared to Waters-IBE, the Setup and KeyGen remain unaltered. To encrypt a message M , ﬁrst encapsulate a symmetric key k := K(g z , e(X, Y )z ), then set the ciphertext C := (Enc(k, M ), g z , Qz ). To decrypt, extract e(X, Y )z = e(d1 , g z )/e(d2 , Qz ) using the corresponding private key (d1 , d2 ), then decapsulate the symmetric key k using K. They claimed the proof of the CCA construction would be provided in the full version of their paper. However, their proof does not hold in the standard model as claimed. Consider the following attack of an adversary A: suppose the challenge identity is ID∗ , in Phase 2 A randomly zˆ picks zˆ ∈ Zp , M ∈ M, and sets the ciphertext Cˆ = (Enc(k, M ), g zˆ, (Q∗ ) ), ∗ zˆ zˆ ∗ where k = K(g , e(X, Y ) ) and Q = H(ID ). A issues the decryption query ˆ to the simulator B. Recall that for one identity, B can either embed the ID∗ , C underlying intractable problem into it or extract the private key of it, therefore B has to abort since it is unable to recover e(X, Y )zˆ without the corresponding private key and then answer the decryption query. Note that after the challenge identity is ﬁxed in the challenge stage, A can always carry on the above attack in Phase 2. So their CCA construction is not provably secure in the standard model as claimed. Interestingly, we point out that Chatterjee and Sarkar’s CCA construction can be proven secure in the random oracle model. By modeling K as a random oracle, the simulator can answer the decryption queries when it cannot extract the corresponding private keys. More precisely, the simulator set the associated symmetric key k := K(g zˆ, ∗) then return Dec(k, Cˆ1 ), where ∗ denotes the value e(X, Y )zˆ unknown to the simulator for the moment. The simulator uses the patching technique [21] with the help of a decision oracle to ensure the simulation for K is coherent throughout the game. The proof is elegant but has to rely on the OBDH assumption, which is stronger than the DBDH assumption, and much more stronger than the CBDH assumption. Next we show how to adapt the twin technique [12] to achieve the CCA security based on the CBDH assumption. 4.1

Twin Technique and Trapdoor Test

Cash, Kiltz and Shoup proposed a new computational problem called the twin (bilinear) Diﬃe-Hellman problem in [12]. They also designed a clever

A Novel Commutative Blinding Identity Based Encryption Scheme

81

“trapdoor test” which allows a DH/BDH adversary to answer decision oracle queries of the twin DH/BDH problem (without knowing any of the corresponding discrete logarithms) correctly with high probability. Theorem 4.1 (Trapdoor Test for BDH Problem). Let G and GT be two cyclic groups of prime order p, g is the generator of G, e : G × G → GT is a bilinear map. Suppose X1 , t, s are mutually independent random variables, where X1 takes value in G, and each of t, s is uniformly distributed over Zp . Deﬁne the random variable X2 := g s /X1t and suppose that Y , Z are random variables taking values in G, Tˆ1 and Tˆ2 are two elements in GT . Then we have: 1. X2 is uniformly distributed over G; 2. If X1 = g x1 and X2 = g x2 , then the probability that the truth value of t Tˆ1 Tˆ2 = e(Y, Z)s

(1)

does not agree with the truth value of Tˆ1 = e(Y, Z)x1 ∧ Tˆ2 = e(Y, Z)x2

(2)

is at most 1/p; moreover, if (2) holds, then (1) certainly holds. Proof. Observe that s = tx1 + x2 . It is easy to verify that X2 is uniformly distributed over G. To prove the item 2, condition on ﬁxed values of X1 and X2 . In the resulting conditional probability space, while X1 , X2 , Y , Z, Tˆ1 and Tˆ2 are ﬁxed, t is uniformly distributed over Zp . If (2) holds, then by substituting the two equations in (2) into (1), we see that (1) certainly holds. Conversely, if (2) does not hold, we show that (1) holds with probability at most 1/q. Observe that (2) is equivalent to (Tˆ1 /e(Y, Z)x1 )t = e(Y, Z)x2 /Tˆ2

(3)

If Tˆ1 = e(Y, Z)x1 and Tˆ2 = e(Y, Z)x2 , then (3) certainly does not hold. This leaves us with the case Tˆ1 = e(Y, Z)x1 . In this case, the left hand side of the equation is a random element of GT (since t is uniformly distributed over Zp ), but the right hand side is a ﬁxed element of GT . Thus, (3) holds with probability 1/p this case.

4.2

CCA Construction from the Twin Technique

To suit the twin technique and the trapdoor test, we present our CCA construction of our scheme as follows: Setup. Select random x1 , x2 ∈ Zp , g, Y ∈ G and compute X1 = g x1 , X2 = g x2 . Pick two cryptographic hash functions H : {0, 1}∗ → G and K : {0, 1}∗ × G × GT ×GT → {0, 1}λ . The master public parameters are mpk = (g, X1 , X2 , Y, H, K). The master secret is msk = (Y x1 , Y x2 ). Choose a CCA secure symmetric-key cipher SE, of which the length of message is n, the length of key is λ.

82

Y. Chen et al.

KeyGen. To generate the private key dID for an identity ID ∈ {0, 1}∗, pick random r1 , r2 ∈ Zp and output dID = (d11 , d12 , d21 , d22 ) = (Y x1 Qr1 , g r1 , Y x2 Qr2 , g r2 ) ∈ G4 where Q = H(ID) can be viewed as the public key of the identity ID. Encrypt. To encrypt a message M ∈ {0, 1}n under the identity ID, randomly pick z ∈ Zp , and set k := K(ID, g z , e(X1 , Y )z , e(X2 , Y )z ), the ciphertext is C = (g z , Qz , Enc(k, M )) ∈ G × G × {0, 1}n For a well-formed ciphertext, e(C1 , Q) is equal to e(C2 , g). Decrypt. To decrypt a given ciphertext C = (C1 , C2 , C3 ) under ID, the algorithm ﬁrst check if e(C1 , Q) = e(C2 , g) holds. If not, reject the ciphertext. Otherwise, use the private key dID = (d1 , d2 , d3 , d4 ) to compute e(Y x1 Qr1 , g z ) e(d11 , C1 ) = = e(X1 , Y )z ; e(d12 , C2 ) e(g r1 , Qz ) e(d21 , C1 ) e(Y x2 Qr2 , g z ) = = e(X2 , Y )z . e(d22 , C2 ) e(g r2 , Qz ) then derive k := K(ID, g z , e(X1 , Y )z , e(X2 , Y )z ) and returns Dec(k, C3 ). Remark 1. Our CCA scheme is essentially a KEM-DEM (Key Encapsulation Mechanism - Data Encapsulation Mechanism) construction. Compared to the CCA scheme obtained from applying Fujisaki-Okamoto transformation [14], our CCA construction has shorter ciphertext at the cost of increasing one element in public parameters. Remark 2. The session key of BB1 -IBE is only related to the randomness z used by the encryption algorithm, which means an adversary learning one session key associated to the randomness z is able to decrypt any ciphertext with the same randomness (the same ﬁrst component C1 of the ciphertext). Our CCA construction eliminates such issue by including the identity to the input of the K hash function. 4.3

Security Analysis

Theorem 4.2. Our CCA construction is IND-ID-CCA secure assuming H and K are random oracles, the CBDH assumption holds in the groups generated by GroupGen, and the underlying symmetric cipher SE is unbreakable under chosen ciphertext attack. Concretely, suppose there is an IND-ID-CCA adversary A that has advantage against the scheme. If A makes at most Qk K-queries, Qe > 0 private key extraction queries. Then there is an algorithm B that solves the CBDH problem with advantage at least: Qk 1 AdvB ≥ 2 1 − p eQe

A Novel Commutative Blinding Identity Based Encryption Scheme

83

Proof. Suppose A has advantage in attacking the scheme. We build an algorithm B that solves the CBDH problem by interacting with A in an IND-ID-CCA game as follows. Setup. Given the CBDH challenge (g, g x , g y , g z ), B set X1 = g x , Y = g y , Z = g z , randomly picks s, t ∈ Zp , and set X2 = g s /X1t (x2 = s − tx1 ). The mpk is (g, X1 , X2 , Y ). The corresponding msk, which is unknown to B, is (Y x1 , Y x2 ) ∈ G. From the perspective of the adversary A the distribution of the public parameters are identical to the real construction. H-Queries. The same as the proof in Section 3. K-Queries. To respond to these queries B maintains a list of tuples ID, C1 , T1 , T2 , k as explained below. We refer to this list as the R list, which is initially empty. When A queries K on point (ID, C1 , T1 , T2 ), B proceeds as follows: 1. If there is already an entry indexed by (ID, C1 , T1 , T2 ), then returns the corresponding k. 2. Otherwise, generates a random k ∈ {0, 1}λ and insert ID, C1 , T1 , T2 , k into the R list, then responds with k. For each new tuple, B marks it as “good” or “bad” according to its trapdoor test. If T1t T2 = e(Y, C1 )s holds marks “good”. Otherwise marks “bad”. Phase 1 - Private Key Queries. Upon receiving the private key query for an identity ID, B runs the above algorithm to obtain H(ID) = Q. Let ID, v, w be the corresponding tuple on L. If w = 0, B aborts. Otherwise, B picks random r1 , r2 ∈ Zp and constructs the private key d = (d11 , d12 , d21 , d22 ) as: v −w

d11 = X1

x1

g r1 v Y r1 w = Y x1 (g v Y w )r1 − w = Y x1 (H(ID))rˆ1 = Y x1 Qrˆ1 1 −w

d12 = g r1 X1 v −w

d21 = X2

x

= g r1 − w = g rˆ1 x2

g r2 v Y r2 w = Y x2 (g v Y w )r2 − w = Y x2 (H(ID))rˆ2 = Y x2 Qrˆ2 1 −w

d22 = g r2 X2

x

= g r2 − w = g rˆ2

Let rˆ1 = r1 − xw1 , rˆ2 = r2 − xw2 . It is easy to see that B can always answer the private key queries iﬀ w = 0. Phase 1 - Decryption Queries. Let ID, C be a decryption query issued by algorithm A, where C = (C1 , C2 , C3 ) = (g z , Qz , Enc(k, M )). 1. If B can extract the private key of ID, then responds the decryption query normally using the private key. 2. Otherwise, B ﬁrst checks if e(C1 , Q) = e(C2 , g) holds. If not, B rejects the ciphertext. Else, B proceeds by checking if there is a “good” tuple in the R list indexed by (ID, C1 ), if so, B gets the associated k; if not, B generates a random k ∈ {0, 1}λ, and it will stay on the lookout for a good tuple indexed by (ID, C1 ) in future K-queries, associating this key with that tuple to keep things consistent. Challenge. The adversary A submits two messages M0 , M1 ∈ {0, 1}n and an identity ID∗ where it wishes to be challenged. Suppose ID∗ , v ∗ , w∗ is the corresponding entry on the L list. If w∗ = 0, B aborts. Otherwise, B checks whether

84

Y. Chen et al.

the entry indexed by (ID∗ , Z) on the R list is marked as good. If so, B gets the associated k. If not, B generates a random symmetric key, and watches for a good tuple to come up as a K-hash query, when it sees one, it “patches” that query by returning the symmetric key generated earlier. B returns the challenge ∗ ciphertext as C = (Z, Z v , Enc(k, Mβ )). C is a valid encryption of Mβ under ID∗ ∗ ∗ ∗ ∗ ∗ since Z v = (g v )z = (Q∗ )z , where Q∗ = g v Y w = g v . Phase 2. B responds to the private key extraction queries and the decryption queries the same way it did in Phase 1. Guess. Finally, the adversary A outputs a guess β for β. B examines K and looks for a good entry of the form ID∗ , Z, T1 , T2 , k. If it ﬁnds one, it outputs T1 as its answer to the CBDH challenge. It is straightforward to check the good entry of the form ID∗ , Z, T1 , T2 , k appears on the ﬁnal R list with probability 2 whenever A breaks the IND-ID-CCA security of our CCA construction with advantage . The probability analysis of B aborts during the simulation is the same as that of the above CPA scheme in Section 3: Qe 1 1 (4) Pr[abort] = Pr[¬E2 |¬E1 ]Pr[¬E1 ] = 1− m m Pr[abort] can be maximized to be 1/eQe by setting mopt = 1 + Qe . To complete the proof of Theorem 4.2 it remains to calculate the probability that K can be perfectly simulated. Lemma 1. The K oracle can be simulated perfectly with probability at least 1 − Qk /p. Proof. Note that the probability of the BDH trapdoor test described in 4.1 returning a wrong decision result for a distinguish query is at most 1/p, and this happens at most Qk times. Therefore B can use the trapdoor test to mark all the entries on the R list correctly with probability at least 1 − Qk /p. Lemma 1 follows immediately. Combining Equation (4) and Lemma 1, B’s advantage is at least 2(1−Qk /p)/eQe as required.

5

Further Discussion

The proving technique we use is essentially the “partitioning strategy” summarized by Waters in [28]. In the security reduction, the simulation algorithm partitions the identities space I into two subspaces: (1) I1 - identities of which simulator can create private keys; and (2) I2 - identities in which simulator can embed the underlying intractable problem. In order to have a successful simulation, the simulator expects that the private key querying identities in Phase 1 or Phase 2 come from I1 and the challenge identity comes from I2 . We remark that the two subspaces are orthogonal, i.e. I = I1 ∪ I2 , I1 ∩ I2 = Ø.

A Novel Commutative Blinding Identity Based Encryption Scheme

85

The H(ID) is programmed to be the binomial combination based on 2-generators (g, Y ): g v Y w , thereby the public key space corresponding to I is g v Y w (v ∈ Zp , w ∈ Zm ), while the public key space corresponding to I1 is g v Y w (v ∈ Zp , w ∈ Z∗m ) and the public key space corresponding to I2 is g v Y w (v ∈ Zp , w = 0). It is easy to see that |I2 |/|I1 | = 1/(m − 1). Recall the proofs in Section 3 and Section 4, m is a crucial factor that dominates the tightness of reduction. Our scheme and Waters-IBE are quite similar to BB1 -IBE. Other than the notational diﬀerences, the distinguishing features are diﬀerent constructions of the identity hash function (IHF). We use the uniform notation to review the identity hash functions of BB1 -IBE, Waters-IBE, and our scheme as follows: – In BB1 -IBE [5], IHF(ID) = U Y F (ID) , where U , Y are elements from G, F : ID → Zp is a hash function. n – In Waters-IBE [27], IHF(ID) = U i=1 vi Ui (U and Ui are elements from G, vi is the i-th bit of the bitstring ID), which is known as Waters hash. Recently, Hofheinz and Kiltz [18] pointed out that Waters hash is essentially a (1, poly)programmable hash function. – In our scheme, IHF(ID) = H(ID), where H : {0, 1}∗ → G is modeled as a random oracle, which is an ideally programmable hash function.

6

Conclusion

In this paper we proposed a novel IBE scheme of BB1 -style, which can be viewed as an eﬃcient variant of BB1 -IBE in the random oracle model. Our scheme can beneﬁt the schemes that used to construct on BB1 -IBE (proven fully secure in the random oracle model). We also propose a CCA construction for our scheme from the twin technique. Our analysis indicates the concrete construction of the identity hash function is an important factor that determines if we can achieve an eﬃcient or a loose security reduction with or without random oracles. Acknowledgements. We would like to thank the anonymous reviewers for their valuable suggestions.

References 1. Abdalla, M., Catalano, D., Dent, A.W., Malone-Lee, J., Neven, G., Smart, N.P.: Identity-Based Encryption Gone Wild. In: Bugliesi, M., Preneel, B., Sassone, V., Wegener, I. (eds.) ICALP 2006. LNCS, vol. 4052, pp. 300–311. Springer, Heidelberg (2006) 2. Bellare, M., Rogaway, P.: Random Oracles are Practical: A Paradigm for Designing Eﬃcient Protocols. In: ACM Conference on Computers and Communication Security, pp. 62–73 (1995) 3. Bellare, M., Rogaway, P.: The Exact Security of Digital Signatures - How to Sign with RSA and Rabin. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 399–416. Springer, Heidelberg (1996)

86

Y. Chen et al.

4. Bethencourt, J., Sahai, A., Waters, B.: Ciphertext-Policy Attribute-Based Encryption. In: IEEE Symposium on Security and Privacy 2007 (SP 2007), pp. 321–334 (2007) 5. Boneh, D., Boyen, X.: Eﬃcient Selective-ID Secure Identity-Based Encryption Without Random Oracles. In: Cachin, C., Camenisch, J.L. (eds.) EUROCRYPT 2004. LNCS, vol. 3027, pp. 223–238. Springer, Heidelberg (2004) 6. Boneh, D., Boyen, X., Goh, E.-J.: Hierarchical Identity Based Encryption with Constant Size Ciphertext. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 440–456. Springer, Heidelberg (2005) 7. Boneh, D., Franklin, M.: Identity-Based Encryption from the Weil Pairing. In: Kilian, J. (ed.) CRYPTO 2001. LNCS, vol. 2139, pp. 213–229. Springer, Heidelberg (2001) 8. Boneh, D., Franklin, M.K.: Identity-Based Encryption from the Weil Pairing. SIAM Journal on Computation 32, 586–615 (2003) 9. Boyen, X.: General Ad Hoc Encryption from Exponent Inversion IBE. In: Naor, M. (ed.) EUROCRYPT 2007. LNCS, vol. 4515, pp. 394–411. Springer, Heidelberg (2007) 10. Boyen, X., Mei, Q., Waters, B.: Direct chosen ciphertext security from identitybased techniques. In: ACM CCS 2005, pp. 320–329 (2005) 11. Canetti, R., Halevi, S., Katz, J.: A Forward-Secure Public-Key Encryption Scheme. In: Biham, E. (ed.) EUROCRYPT 2003. LNCS, vol. 2656, pp. 255–271. Springer, Heidelberg (2003) 12. Cash, D., Kiltz, E., Shoup, V.: The Twin Diﬃe-Hellman Problem and Applications. In: Smart, N. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 127–145. Springer, Heidelberg (2008) 13. Chatterjee, S., Sarkar, P.: Trading Time for Space: Towards an Eﬃcient IBE Scheme with Short(er) Public Parameters in the Standard Model. In: Won, D.H., Kim, S. (eds.) ICISC 2005. LNCS, vol. 3935, pp. 424–440. Springer, Heidelberg (2006) 14. Fujisaki, E., Okamoto, T.: Secure Integration of Asymmetric and Symmetric Encryption Schemes. In: Wiener, M. (ed.) CRYPTO 1999. LNCS, vol. 1666, pp. 537– 554. Springer, Heidelberg (1999) 15. Gentry, C.: Practical Identity-Based Encryption Without Random Oracles. In: Vaudenay, S. (ed.) EUROCRYPT 2006. LNCS, vol. 4004, pp. 445–464. Springer, Heidelberg (2006) 16. Halevi, S., Rogaway, P.: A Tweakable Enciphering Mode. In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol. 2729, pp. 482–499. Springer, Heidelberg (2003) 17. Halevi, S., Rogaway, P.: A Parallelizable Enciphering Mode. In: Okamoto, T. (ed.) CT-RSA 2004. LNCS, vol. 2964, pp. 292–304. Springer, Heidelberg (2004) 18. Hofheinz, D., Kiltz, E.: Programmable Hash Functions and Their Applications. In: Wagner, D. (ed.) CRYPTO 2008. LNCS, vol. 5157, pp. 21–38. Springer, Heidelberg (2008) 19. Horwitz, J., Lynn, B.: Toward Hierarchical Identity-Based Encryption. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 466–481. Springer, Heidelberg (2002) 20. Huang, X., Mu, Y., Susilo, W., Wu, W., Xiang, Y.: Further Observations on Optimistic Fair Exchange Protocols in the Multi-User Setting. In: Nguyen, P.Q., Pointcheval, D. (eds.) PKC 2010. LNCS, vol. 6056, pp. 124–141. Springer, Heidelberg (2010)

A Novel Commutative Blinding Identity Based Encryption Scheme

87

21. Libert, B., Quisquater, J.J.: Identity Based Encryption Without Redundancy. In: Ioannidis, J., Keromytis, A.D., Yung, M. (eds.) ACNS 2005. LNCS, vol. 3531, pp. 285–300. Springer, Heidelberg (2005) 22. Naccache, D.: Secure and Practical Identity-Based Encryption. Cryptology ePrint Archive, Report 2005/369 (2005), http://eprint.iacr.org/ 23. Sahai, A., Waters, B.: Fuzzy Identity-Based Encryption. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 457–473. Springer, Heidelberg (2005) 24. Sarkar, P.: HEAD: Hybrid Encryption with Delegated Decryption Capability. In: Canteaut, A., Viswanathan, K. (eds.) INDOCRYPT 2004. LNCS, vol. 3348, pp. 230–244. Springer, Heidelberg (2004) 25. Shamir, A.: Identity-Based Cryptosystems and Signature Schemes. In: Blakely, G.R., Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 47–53. Springer, Heidelberg (1985) 26. U.S. Department of Commerce/National Bureau of Standards, National Technical Information Service, Springﬁeld, Virginia. FIPS 197: Advanced Encryption Standard. Federal Information Processing Standards Publication 197 (2001) 27. Waters, B.: Eﬃcient Identity-Based Encryption Without Random Oracles. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 114–127. Springer, Heidelberg (2005) 28. Waters, B.: Dual System Encryption: Realizing Fully Secure IBE and HIBE under Simple Assumptions. In: Halevi, S. (ed.) CRYPTO 2009. LNCS, vol. 5677, pp. 619–636. Springer, Heidelberg (2009)

A

Identity Based Encryption

Recall that an IBE scheme consists of four algorithms [8, 25], Setup, Extract, Encrypt and Decrypt, as follows: – Setup: takes as security parameter 1κ , and returns system public parameters mpk and master secret msk. The description of message space M and the description of ciphertext space C are included in the system parameters. – Extract: takes as input mpk, msk and an arbitrary ID ∈ {0, 1}∗, and returns a associated private key dID . – Encrypt: takes as input mpk, ID, and M ∈ M, and returns a ciphertext C ∈ C. – Decrypt: takes as input mpk, C ∈ C, and a private key dID , and returns M ∈ M. A.1

Security of Chosen Ciphertext Attack for IBE

Boneh and Franklin formalized the chosen ciphertext security for IBE in [7, 8]. Concretely, an IBE scheme E is said to be secure against adaptively chosen ciphertext attack (IND-ID-CCA) if no probabilistic polynomial time (PPT) algorithm A has a non-negligible advantage against the challenger in the following game: Setup. The challenger takes the security parameter 1κ and runs the Setup algorithm. It gives the adversary the resulting system parameters and keeps the master secret to itself.

88

Y. Chen et al.

Phase 1. The adversary issues queries q1 , . . . , qm where query qi is one of: – Extraction query IDi . The challenger responds by running algorithm Extract to generate the private key di corresponding to IDi . It sends di to the adversary A. – Decryption query IDi , Ci . The challenger responds by running algorithm Extract to generate the private key di corresponding to IDi . It then runs algorithm Decrypt to decrypt the ciphertext Ci using the private key di . It sends the resulting plaintext to the adversary A. These queries may be asked adaptively, that is, each query qi may depend on the replies to q1 , . . . , qi−1 . Challenge. Once the adversary decides that Phase 1 is over it outputs two equal length plaintexts M0 , M1 ∈ M and an identity ID on which it wishes to be challenged. The only constraint is that ID did not appear in any private key extraction query in Phase 1. The challenger picks a random bit β ∈ {0, 1} and sets C ∗ = Encrypt(mpk, ID∗ , Mβ ). It sends C ∗ as the challenge to the adversary. Phase 2. The adversary issues more queries qm+1 , . . . , qr where qi is one of: – Extraction query IDi with the constraint that IDi = ID∗ . The challenger responds as in Phase 1. – Decryption query IDi , Ci = ID∗ , C ∗ . The challenger responds as in Phase 1. These queries may be asked adaptively as in Phase 1. Guess. Finally, the adversary outputs a guess β ∈ {0, 1} and wins the game if β = β. We refer to such an adversary A as an IND-ID-CCA adversary, whose advan1 Pr[β = β (κ) = ] − tage over the scheme E is deﬁned by AdvCCA E,A 2 , where κ is the security parameter. The probability is over the random bits used by the challenger and the adversary. Deﬁnition 1.1. We say that an IBE scheme E is IND-ID-CCA secure if for any probabilistic polynomial time IND-ID-CCA adversary A the advantage AdvCCA E,A (κ) is negligible.

B

Symmetric-Key Encryption Scheme (SE)

A symmetric-key encryption scheme consists of two algorithms (Enc, Dec). For a symmetric key sk, the encryption algorithm Enc encrypts a plaintext M as C = Enc(sk, M ); the decryption algorithm Dec decrypts a ciphertext C as M = Dec(sk, C). Moreover, we say that SE is length preserving if |Enc(sk, M )| = |M |. Deﬁnition 2.1. A symmetric-key encryption scheme is IND-CCA secure if no probabilistic polynomial time (PPT) adversary A has a non negligible advantage in the following game. 1. In the setup stage, the challenger randomly chooses a symmetric key sk. 2. In Phase 1, A starts probing the scheme by querying the encryption oracle Enc(sk, ·) and the decryption oracle Dec(sk, ·).

A Novel Commutative Blinding Identity Based Encryption Scheme

89

3. In the challenge stage, A outputs two equal length messages (M0 , M1 ) that were not submitted to Enc(sk, ·) or obtained from Dec(sk, ·) and gets C ∗ = Enc(sk, Mβ ) for a random bit β ∈ {0, 1}. 4. In Phase 2, A issues new queries as in Phase 1 but is disallowed to ask for the decryption of C ∗ and the encryptions of M0 and M1 . 5. In the guess stage, A eventually outputs a guess β for β. A’s advantage is deﬁned by AdvA (κ) = |Pr[β = β] − 1/2|. We will use a length preserving IND-CCA secure symmetric-key encryption scheme in our construction. Such a scheme can be built by applying CMC [16] or EME [17] mode of operation to a block cipher, if the underlying block cipher is modeled as strong pseudorandom permutation (for example, AES [26] can be used).

A Related-Key Attack on Block Ciphers with Weak Recurrent Key Schedules Marina Pudovkina National Nuclear Research University (Moscow Engineering-Physics Institute) Moscow, Kashirskoe shosse 31, Russian Federation [email protected]

Abstract. An important component of an iterated block cipher is the key schedule. In this paper, we consider iterated block ciphers with a key schedule algorithm described by a recurrence relation. We present an eﬃcient related-key attack on those ciphers. With regard to similar techniques, such as the slide attack, our proposal considerably reduces the number of necessary plaintexts from O(2n/4 ) plaintexts to 2r, where r is the number of recovered round keys. The complexity of our attack is, moreover, almost equal to the complexity of guessing just one round key.

1

Introduction

In most existing block ciphers, a secret key of speciﬁed length is manipulated to create the round keys of the cipher. This manipulation is known as the key schedule, which is considered to be the most important component of an iterated block cipher. Indeed, a block cipher with a strong key schedule is expected to be more resistant to attacks such as diﬀerential, linear, boomerang and rectangle attacks [1]. These attacks assume independence between the round keys used by the block cipher. However, very often the round keys are computed in the key schedule from a short key in a nonrandom fashion, and therefore, they can be attacked using related-key attacks [1]. In [2], it is empirically shown that ciphers having this dependency and based on straightforward key schedules are easier to be attacked. Indeed, properties of the key schedules are very important for the success of related-key attacks. Weaknesses of the key schedules of well known block ciphers, such as LOKI [3], [4], AES [5], KASUMI [6], SQUARE [7], SHACAL-1 [8], and SHACAL-2 [9], can decrease the security of these ciphers. Authors in [10–13] describe several related-key attacks based on this assumption. In this paper, we consider iterated block ciphers whose round functions depend on round keys only, and whose key schedules algorithms are described by a recurrence key relation. Some block ciphers belonging to this family are LOKI89, LOKI91[4], KeeLoq [14], TREYFER [16], MMB[15] and the 25-round GOST 28147-89. We ﬁrst describe a general related-key attack on block ciphers of this family. Compared to related contributions, such as the slide attack [16], our proposed attack reduces the number of necessary plaintexts from O(2n/4 ) to J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 90–101, 2012. c Springer-Verlag Berlin Heidelberg 2012

A Related-Key Attack on Block Ciphers

91

2r, where r is the number of recovered round keys. Since we can get these recovered round keys from any two arbitrary diﬀerent plaintexts, the complexity of our proposal is, moreover, almost equal to the complexity of guessing just one round key. Then, we show modiﬁcations of our ﬁrst attack to Feistel schemes belonging to the considered family of block ciphers. We discuss the application of our attack technique on the 25-round Feistel schemes having the same key schedule as the 25-round GOST 28147-89 cipher. In papers [17–23], other approaches to analyze the GOST 28147-89 cipher have been described. All these approaches depend on properties of the round function of the GOST 28147-89 cipher. However, our attack assumes only its key schedule and considers only an arbitrary round function. Moreover, and compared to the aforementioned approaches, our attack presents the lowest number of necessary plaintexts (ﬁve) which, moreover, can be obtained from only one arbitrary plaintext. The complexity of the attack in this speciﬁc case is estimated as O(232 ). Therefore, the resulting attack can be considered as a practical attack. The paper is organized as follows. Section 2 summarizes the notation used in the remainder sections. Section 3 describes the family of ciphers considered for our attack. Section 4 describes some related work. Section 5 gives the general description of our two ﬁrst attacks and estimates their complexity. Section 6 adapts our proposal to be applicable to Feistel schemes, and describes the third attack against some sample 25-round Feistel schemes which have the same key schedule as the 25-round GOST 28147-89 cipher. Section 7 concludes the paper.

2

Notation

N is the set of all natural numbers; N0 corresponds to N ∪ {0}; Vn is a n– dimensional vector space over GF (2); n, m, r, d, l are all natural numbers; ⊕ is the addition operator in Vn ; l is the number of rounds (such that 2 ≤ r < l); gk : Vn → Vn is a round function depending on a round key k; K = Vd is the key space (such that n < d); n0 is the number of plaintexts; ki is the round key of the i-th round. Finally, let f(k0 ,...,ki−1 ) = gki−1 . . . gk1 gk0 , α(i) = f(k0 ,...,ki−1 ) (α) = gki−1 . . . gk0 (α), where i ∈ {1, . . . , l}, f(k0 ,...,ki−1 ) is an encryption function and α(i) is a ciphertext of a plaintext α, then (k0 , . . . , ki−1 ) is an extended key.

3

Considered Block Cipher Family

We consider iterated block ciphers such that for their encryption functions and key schedules φ∗ = (δ, φ) there exist r ∈ N, r < l, and mappings λ : Vnr → Vn , δ : K → Vnr , φ : Vnr → Vnl satisfying the following conditions: 1. n < d; 2. δ(k) = (k0 , . . . , kr−1 );

92

M. Pudovkina

3. for an arbitrary i ∈ N0 , the following holds (ki , . . . , ki+l−1 ) = φ(ki , . . . , ki+r−1 ), where ki+l+j = λ(ki+j , . . . , ki+r−1+j ), j = 0, . . . , l − r; 4. round functions gk0 , . . . , gkl−1 are only depending on round keys k0 , . . . , k−1 and are the same for all the rounds; 5. gk is a permutation on Vn for all k ∈ Vn , such that gk = gk for all k, k ∈ Vn , k = k ; 6. there exists ψ : Vn × Vn → Vn such that k = ψ(α, β) holds for all k ∈ Vn , α ∈ Vn , where β = gk (α). Condition (1) shows that the length of a secret key is larger than the length of a block of a plaintext, so the complexity of our attack is smaller than the complexity of the brute force attack. Conditions (2) and (3) mean that for any i ∈ {0, . . . , l − r} and an arbitrary sequence of round keys ki , . . . , ki+r−1 we can ﬁnd the secret key k ∈ K. In particular, condition (3) indicates that a key schedule algorithm can be described by a recurrence relation λ. Note that the secret key k can be represented as (k0 , . . . , kr−1 ) and δ is often the identical mapping. In fact, φ represents a key schedule and can be considered as a mapping of a shift register (linear or nonlinear). Condition (5) means that the round function does not have equivalent keys. Thus, condition (5) is very natural and many block ciphers fulﬁll it. Condition (6) means that if we have an input α and an output β of the round function gk , then we can easily ﬁnd a round key k using the function ψ. Naturally, there are ciphers which do not satisfy condition (6). For this reason, we ﬁrst discuss our attack on block ciphers that satisfy condition (6); and then we do the necessary modiﬁcations for applying our technique when condition (6) does not hold. Note that the recurrence relation λ can be arbitrary. For example, for r = 10 it can be described as ki+10 = λ(ki , . . . , ki+9 ) = ki ⊕ ki+5 ⊕ (ki+9 <<< 6) ⊕ ki+3 or ki+10 = λ(ki , . . . , ki+9 ) = ki ⊕ ki+1 ∗ ki+2 ∗ ki+7 ⊕ (ki+9 <<< 5)⊕ (ki+3 +2n ki+8 ), where ∗ is a multiplication operator in the Galois ﬁeld GF (2n ), <<< t is a left circular rotation of t bits, +2n is an addition operator modulo 2n . We consider (k0 , . . . , kr−1 ) as the secret key and φ as the key schedule.

4

Related Work

Related-key cryptanalysis assumes that the attacker learns the encryption of certain plaintexts not only under the original (unknown) key k , but also under some derived keys. In a chosen-related-key attack, the attacker speciﬁes how the key is to be changed; known-related-key attacks are those where the key diﬀerence is known, but cannot be chosen by the attacker.

A Related-Key Attack on Block Ciphers

93

The attacker knows or chooses the relationship between keys, not the actual key values. Firstly, these techniques have been developed in [3], [4] to attack the LOKI block cipher. The key schedule of the LOKI block cipher satisﬁes the following property. For an arbitrary secret key k ∈ K there exists such k (1) ∈ K that if φ(k) = (k0 , . . . , kl−1 ) then φ(k (1) ) = (k1 , . . . , kl−1 , k0 ). These relations mean that for any k (0) ∈ K can be found such k (1) , . . . , k (l−1) ∈ K that φ(k (0) ) = (k0 , . . . , kl−1 ), φ(k (i) ) = (ki , . . . , kl−1 , k0 , . . . , ki−1 ), i = 1, . . . , l − 1. Note that φ∗ also satisﬁes conditions (2) and (3). For example, we can suppose r = l − 2, δ(k) = (k0 , . . . , kl−2 ), λ(k0 , . . . , kl−2 ) = kl−1 , λ(ki−1 , . . . , kl−1 , k0 , . . . , ki−3 ) = ki−2 , i = 2, . . . , l − 1. Moreover, if the encryption function also satisﬁes conditions (4)–(6), then the slide attack can be applied. In [12], such attacks are presented and their complexity and number of plaintexts are estimated as follows: – Known plaintext attacks require O(2n/2+1 ) plaintexts, and their time complexity is bounded by O(2n ). – Known plaintext attacks on Feistel schemes require O(2n/2+1 ) plaintexts, and their time complexity is bounded by O(2n/2 ). – Chosen plaintext attacks on Feistel schemes require O(2n/4+1 ) plaintexts, and their time complexity is bounded by O(2n/2 ). Note that condition (6) is very important for the application of the attack. Indeed, if it does not hold, then the attack complexity increases considerably. In [12], the key schedule satisfying the following property is also analyzed. For an arbitrary secret key k ∈ K there exists k (1) ∈ K such that if φ(k) = (k0 , . . . , kl−1 ) then φ(k (1) ) = (k1 , . . . , kl−1 , kl ), where kl is an element from Vn . This means that for any k (0) ∈ K, a sequence of related keys k (1) , . . . , k (l−1) ∈ K can be found by applying the following two equations: φ(k (0) ) = (k0 , . . . , kl−1 ), φ(k (i) ) = (ki , . . . , kl−1 , kl , . . . , kl−1+i ), i = 1, . . . , l − 1, where kl , . . . , k2l−1 are some elements from Vn . Moreover, φ∗ fulﬁlls conditions (2) and (3) if we take r = l − 2, δ(k) = (k0 , . . . , kl−2 ), λ(k0 , . . . , kl−2 ) = kl−1 , λ(ki , . . . , ki−1+l ) = ki+l , i = 0, . . . , l − 1. Also in [12], some attacks for Feistel schemes based on both slide and relatedkey approaches are presented. The complexity of the attacks and the number of plaintexts are estimated as follows:

94

M. Pudovkina

n/2+1 – Known plaintext attacksrequire O(2 ) plaintexts, and their time com n/2−1 . plexity is bounded by O n · 2 – Chosen plaintext attacks require O(2n/2+1 ) plaintexts (their time complexity is not provided in [12]).

The attack technique that we present in the sequel satisﬁes conditions (1)–(5). Moreover, it improves the complexities of the attacks given in [12].

5

The Attack Technique

First, we describe the main idea of our two ﬁrst attacks for iterated block ciphers satisfying conditions (1)–(6) deﬁned in Section 3. We start by describing how to ﬁnd the round key ki , i ∈ {1, . . . , l}. Let α(0,1) , . . . , α(0,n0 ) be arbitrary diﬀerent plaintexts from Vn and k = (k0 , . . . , kr−1 , kr , . . . , kl−1 ) = φ(k0 , . . . , kr−1 ) is the extended key of the secret key k = (k0 , . . . , kr−1 ) (where l is the number of rounds). Consider two related keys k (i) = (ki , . . . , ki+r−1 ), k (i+1) = (ki+1 , . . . , ki+r ) and their corresponding extended keys: k(i) = (ki , . . . , ki+l−1 ) = φ(k (i) ), k(i+1) = (ki+1 , . . . , ki+l ) = φ(k (i+1) ) To ﬁnd the round key ki for all κ ∈ Vn , we can proceed as follows: 1. Encrypt plaintexts α(0,1) . . . ,α(0,n0 ) under the extended key k(i) to get ci ,(0,j) (l,j) , j = 1, . . . , n0 ; = fk(i) α phertexts α 2. Compute related plaintexts α(0,j) = gκ α(0,j) , j = 1, . . . , n0 ; 3. Compute related ciphertexts α(l,j) = fk(i+1) α(0,j) under the related extended key k(i+1) , j = 1, . . . , n0 ; 4. Find the round key ki+l,j , i.e., ki+l,j = ψ(α(l,j) , α(l,j) ), j = 1, . . . , n0 . Step (4) means that encrypting n0 plaintexts under the same extended key k(i+1) we should get the same round key ki+l,j , i.e., ki+l = ki+l,j . To ﬁnd ki+l,j we use the equality α(l,j) = gki+l,j α(l,j) and applying the function ψ get ki+l,j = ψ(α(l,j) , α(l,j) ), j = 1, . . . , n0 . Therefore, if κ is a correct round key, and thus ki = κ, then ki+l = ki+l,1 = ki+l,2 = . . . = ki+l,n0 , ψ(α(l,1) , α(l,1) ) = . . . . = ψ(α(l,n0 ) , α(l,n0 ) ),

(1)

i.e., Equality (1), holds with probability one. If ki = κ, being κ a wrong round key, then ψ(α(l,j) , α(l,j) ) can be regarded as a random variable uniformly distributed on Vn . Under the assumption that random

A Related-Key Attack on Block Ciphers

95

Attack 1 1. Choose n0 arbitrary plaintexts α(0,j) ∈ Vn , where j = 1, . . . , n0 . 2. For i = 0, . . . , r − 1, do: (a) Let k(0) = (k0 , . . . , kr−1 , kr , . . . , kl−1 ) = φ(k0 , . . . , kr−1 ). Consider two (unknown) related keys k(i) = (ki , ki+1 , . . . , ki+r−1 ), k(i+1) = (ki+1 , ki+2 , . . . , ki+r ) and their corresponding extended keys k(i) = (ki , . . . , ki+l−1 ) = φ(k(i) ), k(i+1) = (ki+1 , . . . , ki+l ) = φ(k(i+1) ). (b) Guess the round key ki . For all κ ∈ Vn do: i. Find ciphertexts α(l,j) = fk(i) α(0,j) for j = 1, . . . , n0 . ii. Compute related plaintexts α(0,j) = gκ α(0,j) for j = 1, . . . , n0 . iii. Find related ciphertexts α(l,j) = fk(i+1) α(0,j) for j = 1, . . . , n0 . iv. Check the equality ψ(α(l,1) , α(l,1) ) . . . = ψ(α(l,j) , α(l,j) ) = . . . = ψ(α(l,n0 ) , α(l,n0 ) ), if it holds, then κ is a correct round key and we can suppose that ki = κ.

variables ψ(α(l,1) , α(l,1) ), . . . , ψ(α(l,n0 ) , α(l,n0 ) ) are independent, the probability of relation (1) is 2−n(n0 −1) . This way, we can independently recover the round keys and get the secret key. Attack 1 summarizes the steps of the ﬁrst attack holding these aforementioned ideas. To estimate the time complexity of Attack 1, we will assume that one simple operation (s.o.) means computing either gκ (α) or ψ(α(l,j) , α(l,j) ). Thus, the time complexity of Attack 1 can be estimated as 2n+1 n0 · r(1 + l) simple operations. Let i ∈ {0, . . . , r −1}, we can now discuss how to ﬁnd the number of plaintexts n0 . Note that, if the guessed round key ki is correct, then Equality (1) holds with probability one. If the guessed round key ki is wrong, then Equality (1) holds with probability 2−n(n0 −1) . Consider simple hypotheses H0,i , H1,i and H0 , H1 deﬁned as: – – – –

H0,i : the guessed round key ki is correct; H1,i : the guessed round key ki is wrong; ) is correct; H0 : the guessed key (k0 , . . . , kr−1 ) is wrong. H1 : the guessed key (k0 , . . . , kr−1

Then, the probability of type 1 errors is p1,i = P {H1,i |H0,i } = 0, and the probability of type 2 errors is p2,i = P {H0,i |H1,i } = 2−n(n0 −1) . Therefore, p1 = r P {H1 |H0 } = 0 and p2 = P {H0 |H1 } = 1 − 1 − 2−n(n0 −1) .

96

M. Pudovkina

Table 1 summarizes the complexity of Attack 1 when the number of plaintexts is either two or four. Note that we can apply Attack 1 for any number of rounds and any round functions. Moreover, it is often enough two plaintexts. The number of related keys is r + 1. Note that if (n, r, n0 ) = (64, 32, 2) then P {H0 |H1 } = 2 · 10−18 . If (n, r, n0 ) = (128, 128, 2), then P {H0 |H1 } = 4 · 10−37 . That means that probabilities of type 2 errors are very small. Table 1. Complexity of Attack 1 in the general case n0 number of s.o. P {H1 |H0 } P {H0 |H1 } number of rel.keys 2 2n+2 · r(1 + l) 0 1 − (1 − 2−n )r r+1 4 2n+2 · r(1 + 2l) 0 1 − (1 − 2−3n )r r+1

If it is diﬃcult to ﬁnd a function ψ satisfying condition (6) or if its computation cost is too high, then on the precomputation step we can use memory and build a table in which k ∈ Vn addresses α + β2n , where gk (α) = β . In this case, the memory requirement of this attack is 22n n -bits values. If we do not want to use memory, then Step 2 of Attack 1 can be slightly changed as presented in Attack 2.

Attack 2 1. For i = 0, . . . , r − 1 do: (a) Guess the round key ki as follows: i. For all κ ∈ Vn do: A. Find ciphertexts α(l,j) = fk(i) α(0,j) for j = 1, . . . , n0 . B. Compute related plaintexts α(0,j) = gκ α(0,j) for j = 1, . . . , n0 . C. Compute related ciphertexts α(l,j) = fk(i+1) α(0,j) under the extended key k(i+1) for j = 1, . . . , n0 . D. For all x ∈ Vn , if equalities gx α(l,1) = α(l,1) , gx α(l,2) = α(l,2) , . . . , gx α(l,n0 ) = α(l,n0 ) , hold, then κ is correct and, therefore, ki = κ.

Notice that steps A–C of Attack 2 are the same as in Attack 1. In Step D, if κ is a correct round key, i.e., ki = κ, then gki+l α(l,1) = α(l,1) , gki+l α(l,2) = α(l,2) , . . . , gki+l α(l,n0 ) = α(l,n0 ) . As a result, if x = ki+l , then gx α(l,1) = α(l,1) , gx α(l,2) = α(l,2) , . . . , gx α(l,n0 ) = α(l,n0 ) ,

(2)

A Related-Key Attack on Block Ciphers

97

i.e., there exists x ∈ Vn for which Equality (2) holds. If κ is a wrong round key, ki = κ, then for any x ∈ Vn Equality (2) holds with probability 2−n·(n0 −1) . To estimate the time complexity of Attack 2, we assume that one simple operation means computing gκ (α). Thus, the time complexity of Attack 2 is 22n n0 · r(1 + 2l) simple operations. The probabilities of type 1 and type 2 errors, and the number of related keys are the same as in Attack 1. For block ciphers based on Feistel schemes and satisfying conditions (1)–(6) deﬁned in Section 3, Attack 1 can be slightly changed. Let n be equal to 2m. The main diﬀerence consists of guessing a round key from Vm instead of Vn . The resulting complexity is summarized in Table 2. If it is diﬃcult to ﬁnd a valid function ψ satisfying condition (6), or if its computation cost is too high, then we can use an adapted version of Attack 2 for these Feistel schemes, by guessing the round key from Vm instead of Vn . In such cases, the complexity of Attack 2 would still be equal to the complexity of Attack 1. Table 2. Complexity of Attack 1 for Feistel schemes n0 the number of s.o. P {H1 |H0 } P {H0 |H1 } the number of rel.keys 2 2n/2+2 · r(1 + l) 0 1 − (1 − 2−n )r r+1 4 2n/2+2 · r(1 + 2l) 0 1 − (1 − 2−3n )r r+1

6

Attack on 25-Round Feistel Schemes with the GOST Cipher Key Schedule

In the previous section, we have discussed a general attack technique on Feistel schemes. In this section, we apply such a technique to attack Feistel schemes with the key schedule of the GOST block cipher. Let n be equal to 2m. We consider the key schedule φ : Vm8 → Vm32 used in the GOST cipher, and deﬁned as φ : (k0 , . . . , k7 ) → (k0 , . . . , k7 , k0 , . . . , k7 , k0 , . . . , k7 , k7 , . . . , k0 ). Let k = (k0 , . . . , k7 ) ∈ Vm8 be a secret key, k (i) = (ki , . . . , k7 , k0 , . . . , ki−1 ) from Vm8 be the i-th related key, where i = 1, . . . , 4, l ∈ {1, . . . , 32}. Then, the l-round extended key kl of k is (k0 , . . . , k7 , k0 , . . . , k7 , k0 , . . . , k7 ), l = 24, kl = (κ0 , . . . , κ31 ) = (k0 , . . . , k7 , k0 , . . . , k7 , k0 , . . . , k7 , k7 ), l = 25, (i)

The structure of the l-round extended key kl is equal to (i)

kl

=

of k (i) follows from Attack 1 and

(ki , . . . , k7 , k0 , . . . , ki−1 , ki , . . . , k7 , k0 , . . . , ki−1 , ki , . . . , k7 , k0 , . . . , ki−1 ), l = 24, (ki , . . . , k7 , k0 , . . . , ki−1 , ki , . . . , k7 , k0 , . . . , ki−1 , ki , . . . , k7 , k0 , . . . , ki−1 , ki−1 ), l = 25,

where i = 1, . . . , 4.

98

M. Pudovkina

We consider now the general round function g deﬁned as g (α1 , α0 ) = (α1 , α0 ⊕ g˜κ (α1 )) , where g˜k = hsk , sk : α → α ∗ k , ∗ ∈ {⊕, +(mod2m )} , h is an arbitrary permutation on Vm , k ∈ {0, . . . , 2m − 1} . Let fkl be the encryption function under the l-round extended key kl , (l) (l) (0) (0) α0 , α1 = fkl α0 , α1 , where

(l,i,j)

α0

(l,i,j) (l,i,j) , α1 α0

(l,i,j)

, α1

(0,i,j) (0,i,j) , α1 = fk(i) α0 , l

(0,i,j) (0,i,j) is the ciphertext of the j-th plaintext α0 , α1 (i)

after encrypting it under the extended key kl , j = 1, . . . , n0 , l ∈ {1, . . . , 25} , i = 1, . . . , 4. If the number of plaintext j is unimportant, then we can omit it. We discuss now the idea of our attack by showing how to ﬁnd round keys k0 , k7 . First, we guess k0 ∈ Vm . This means that for all κ ∈ Vm and j = 1, . . . , n0 , we (1) take plaintexts to encrypt under the related key k25 : (0,1,j) (0,1,j) (0,j) (0,j) α0 , α1 = gk α0 , α1 . By using the following relation (23,1,j) (23,1,j) (24,j) (24,j) (0,j) (0,j) α0 = α0 = fκ24 α0 , α1 , , α1 , α1 we can obtain

(24,1,j)

α0

(24,1,j)

, α1

(24,j) (24,j) (24,j) = α1 . , α0 ⊕ g˜κ α1

Therefore, we have: (25,j) (25,j) (24,j) (24,j) (24,j) α0 = α1 ⊕ α0 , α1 , g˜k7 α1 (25,1,j) (25,1,j) (24,j) (24,j) (25,1,j) (24,j) α0 , α1 ⊕ g˜κ α1 = α0 , g˜κ α0 ⊕ α1

(3)

(4)

From Equations (3) and (4), and if the guessed round key κ is correct, i.e., k0 = κ, then Equality (5) holds with probability one. (25,1,j) (25,1,j) (25,j) = α0 ⊕ α0 (5) g˜k0 α0 Otherwise, if the guessed round key κ is wrong, i.e., k = k0 , then Equality (5) holds with probability 2−m and the following equalities simultaneously hold with probability 2−m·n0 . (25,1,1) (25,1,1) (25,1) (25,1,j) (25,1,n0 ) (25,n ) = α0 = α0 g˜k0 α0 ⊕ α0 , . . . ., g˜k0 α0 ⊕ α0 0 ,

A Related-Key Attack on Block Ciphers

99

Moreover, if the guessed key κ is correct, then from (24,j) (25,j) (24,j) = α1 g˜k7 α1 ⊕ α0 we can ﬁnd k7 . It is straightforward that related keys k(i) and k(i+1) satisfy the following relations (25,i+1,j) (25,i+1,j) (25,i,j) g˜ki α0 = α0 ⊕ α0 , (24,i,j) (25,i,j) (24,i,j) = α1 g˜k7−i α1 ⊕ α0 , for i ∈ {1, 2, 3}.

Attack 3 2 , j = 1, . . . , n0 ; 1. Choose arbitrarily n0 diﬀerent plaintexts α(0,j) ∈ V32 2. For i = 0, . . . , 3, do: (a) Find round keys k7−i , ki as follows: i. For κ ∈ Vm do: A. Find ciphertexts α(25,i,j) = fk(i) α(0,j) for j = 1, . . . , n0 ; B. Compute related plaintexts α(0,i+1,j) = gκ α(0,i,j) for j = 1, . . . , n0 ; C. Find ciphertexts α(25,i+1,j) = fk(i+1) α(0,i+1,j) for j = 1, . . . , n0 ; D. If the following equalities (25,i+1,1) (25,i+1,1) (25,i,1) (25,i+1,n0 ) = α0 = ⊕ α0 , . . . ., g˜ki α0 g˜ki α0 (25,i+1,n0 )

α0

(25,i+1,n0 )

⊕ α0

.

hold, then κ is correct, and we can assume that ki = κ. E. If κ is correct, then using relations (3), (4) compute k7−i from (25,i,1) (24,i,1) (24,i,1) ∗−1 α1 ⊕ α0 , k7−i = h−1 α1 where ∗−1 =

⊕, if∗ = ⊕, −(mod2m ), if∗ = +(mod2m ).

Attack 3 summarizes the whole process. To estimate its time complexity, we assume that one simple operation means computing either gκ (α) or (25,i,1) (24,i,1) (24,i,1) ∗−1 α1 h−1 α1 ⊕ α0 ,

100

M. Pudovkina Table 3. Complexity of Attack 3 on 25-round Feistel schemes for m = 32 n0 the number of s.o. P {H1 |H0 } P {H0 |H1 } the number of rel.keys 1 239.68 + 4 0 2−30 5 39.70 2 2 +4 0 2−62 5

where j = 1, . . . , n0 , i = 1, . . . , 4. The time complexity of Attack 3 relies on the execution of 2m+2 · (50 + n0 ) + 4 simple operations, i.e., p1 = P {H1 |H0 } = 0 4 and p2 = P {H0 |H1 } = 1 − (1 − 2−mn0 ) . Table 3 summarizes the complexity of Attack 3 on 25-round Feistel schemes for m = 32. The complexity of Attack 3 on the GOST 28147-89 block cipher is equivalent.

7

Conclusion

We have presented a new related-key attack that can target a large family of iterated block ciphers based on recurrent key schedule algorithms. The main feature of our attack technique is that it requires a considerably low number of plaintexts to succeed. With regard to similar strategies, such as the slide attack, which requires from O(2n/2 ) to O(2n/4 ) plaintexts, ours requires from two to only one plaintext. The considered family of ciphers could resist our attacks if they adapt, for instance, the round key ki depends on the round number i; or if they apply this dependence in their round functions. We have also presented how our proposal can aﬀect Feistel schemes. An example, based on arbitrary Feistel schemes having the same key schedule as the 25-round GOST 28147-89 cipher, has been described. Similar ideas are used in [24] to attack the full GOST block cipher with two or four related keys.

References 1. Swenson, C.: Modern Cryptanalysis. Techniques for Advanced Code Breaking. Wiley Publishing (2008) 2. Knudsen, L.R., Mathiassen, J.E.: On the Role of Key Schedules in Attacks on Iterated Ciphers. In: Samarati, P., Ryan, P.Y.A., Gollmann, D., Molva, R. (eds.) ESORICS 2004. LNCS, vol. 3193, pp. 322–334. Springer, Heidelberg (2004) 3. Biham, E.: New Types of Cryptanalytic Attacks Using Related Keys. In: Helleseth, T. (ed.) EUROCRYPT 1993. LNCS, vol. 765, pp. 398–409. Springer, Heidelberg (1994) 4. Knudsen, L.R.: Cryptanalysis of LOKI91. In: Zheng, Y., Seberry, J. (eds.) AUSCRYPT 1992. LNCS, vol. 718, pp. 196–208. Springer, Heidelberg (1993) 5. Biryukov, A., Dunkelman, O., Keller, N., Khovratovich, D., Shamir, A.: Key Recovery Attacks of Practical Complexity on AES-256 Variants with up to 10 Rounds. In: Gilbert, H. (ed.) EUROCRYPT 2010. LNCS, vol. 6110, pp. 299–319. Springer, Heidelberg (2010) 6. Dunkelman, O., Keller, N., Shamir, A.: A Practical-Time Related-Key Attack on the KASUMI Cryptosystem Used in GSM and 3G Telephony. In: Rabin, T. (ed.) CRYPTO 2010. LNCS, vol. 6223, pp. 393–410. Springer, Heidelberg (2010)

A Related-Key Attack on Block Ciphers

101

7. Koo, B., Yeom, Y., Song, J.: Related-Key Boomerang Attack on Block Cipher SQUARE. IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences 94(1), 3–9 (2011) 8. Wang, G., Keller, N., Dunkelman, O.: The Delicate Issues of Addition with Respect to XOR Diﬀerences. In: Adams, C., Miri, A., Wiener, M. (eds.) SAC 2007. LNCS, vol. 4876, pp. 212–231. Springer, Heidelberg (2007) 9. Fleischmann, E., Gorski, M., Lucks, S.: Memoryless Related-Key Boomerang Attack on 39-Round SHACAL-2. In: Bao, F., Li, H., Wang, G. (eds.) ISPEC 2009. LNCS, vol. 5451, pp. 310–323. Springer, Heidelberg (2009) 10. Kelsey, J., Schneier, B., Wagner, D.: Key-Schedule Cryptanalysis of IDEA, G-DES, GOST, SAFER, and Triple-DES. In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 237–251. Springer, Heidelberg (1996) 11. Kelsey, J., Schneier, B., Wagner, D.: Related-Key Cryptanalysis of 3-WAY, BihamDES, CAST, DES-X, NewDES, RC2, and TEA. In: Han, Y., Quing, S. (eds.) ICICS 1997. LNCS, vol. 1334, pp. 233–246. Springer, Heidelberg (1997) 12. Ciet, M., Piret, G., Quisquater, J.-J.: Related-Key and Slide Attacks: Analysis, Connections, and Improvements (1999), http://www.dice.ucl.ac.be/crypto 13. Ciet, M., Piret, G., Quisquater, J.-J.: A Survey of Key Schedule Cryptanalysis. Technical Report CG-2002/1, Universite catholique de Louvain, Crypto Group (2002), http://www.dice.ucl.ac.be/crypto/techreports.html 14. Courtois, N.T., Bard, G.V.: Algebraic and Slide Attacks on KeeLoq. Cryptology ePrint Archive, Report 2007/062 (2007) 15. Schneier, B.: Applied Cryptography, Protocols, Algorithms, and Source Code in C, 2nd edn. John WileySons, Inc., New York (1995) 16. Biryukov, A., Wagner, D.: Slide Attacks. In: Knudsen, L.R. (ed.) FSE 1999. LNCS, vol. 1636, pp. 245–259. Springer, Heidelberg (1999) 17. Seki, H., Kaneko, T.: Diﬀerential Cryptanalysis of Reduced Rounds of GOST. In: Stinson, D.R., Tavares, S. (eds.) SAC 2000. LNCS, vol. 2012, pp. 315–323. Springer, Heidelberg (2001) 18. Biham, E., Dunkelman, O., Keller, N.: Improved Slide Attacks. In: Biryukov, A. (ed.) FSE 2007. LNCS, vol. 4593, pp. 153–166. Springer, Heidelberg (2007) 19. Kara, O.: Reﬂection Cryptanalysis of Some Ciphers. In: Chowdhury, D.R., Rijmen, V., Das, A. (eds.) INDOCRYPT 2008. LNCS, vol. 5365, pp. 294–307. Springer, Heidelberg (2008) 20. Ko, Y., Hong, S., Lee, W., Lee, S., Kang, J.-S.: Related Key Diﬀerential Attacks on 27 Rounds of Xtea and Full-Round Gost. In: Roy, B., Meier, W. (eds.) FSE 2004. LNCS, vol. 3017, pp. 299–316. Springer, Heidelberg (2004) 21. Rudskoy, V.: On Zero Practical Signiﬁcance of ”Key Recovery Attack on Full GOST Block Cipher with Zero Time and Memory” (2010), http://eprint.iacr.org/2010 22. Isobe, T.: A Single-Key Attack on the Full GOST Block Cipher. In: Joux, A. (ed.) FSE 2011. LNCS, vol. 6733, pp. 290–305. Springer, Heidelberg (2011) 23. Courtois, N.: Security Evaluation of GOST 28147-89 in view of international standardisation (2011), http://eprint.iacr.org/2011/211 24. Pudovkina, M., Khoruzhenko, G.: Related-key attacks on the full GOST block cipher with 2 or 4 related keys. In: Western European Workshop on Research in Cryptology (2011), http://2011.weworc.org

A Computational Indistinguishability Logic for the Bounded Storage Model Gilles Barthe1 , Mathilde Duclos2 , and Yassine Lakhnech2 1

2

IMDEA Software, Madrid, Spain Université de Grenoble, CNRS – Verimag, Grenoble, France

Abstract. Side-channel attacks are a major threat for cryptographic mechanisms; yet, they are not considered in the computational model that is used by cryptographers for proving the security of their schemes. As a result, there are several eﬃcient attacks against standardized implementations of provably secure schemes. Leakage resilient cryptography aims to extend provable security so that it can account for side-channels. There are several models of leakage resilient cryptography, from very general models such as physically observable cryptography, to more specialized models that aim to account for a speciﬁc form of covert channel. The Bounded Storage model (BSM) is a such a specialized model, which focuses on situations where a virus or a malware program forwards to the attacker some information stolen from the infected computer’s memory, for instance some share of a long-term key. We adapt the Computational Indistinguishability Logic to account the BSM, and show how the resulting formalism can be used to verify an existing key exchange protocol in the BSM. Our work provides the ﬁrst formalism to reason about leakage resilient cryptography. Keywords: Provable cryptography, formal veriﬁcation, computational model, bounded storage model.

1

Introduction

Context and motivation: Designing secure cryptographic primitives and protocols is notoriously diﬃcult; indeed, the early history of cryptography is fraught with schemes that were deemed secure, sometimes over long periods of time, but were subsequently broken. These early failures have contributed to draw the cryptographic community towards the paradigm of provable security [GM84], which has by now become a de facto standard for proposing a new cryptographic scheme. Provable security provides a mathematical approach for justifying the security of cryptographic systems, using ideas from complexity theory. In a nutshell, provable security advocates providing a rigorous deﬁnition of security, and a rigorous proof of security. The prominent model for deﬁning security is the computational model, in which the adversary is given black-box access to oracles that execute the primitives of the construction or the steps of the protocol. Unfortunately, the model does not make any provision for covert channels: in particular, the adversary cannot observe the execution time or the memory J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 102–117, 2012. c Springer-Verlag Berlin Heidelberg 2012

A Computational Indistinguishability Logic for the Bounded Storage Model

103

consumption of oracles. Consequently, many systems that are deemed secure in the computational model are vulnerable in the real world, because there exist covert channels that allow the adversary to gain decisive information eﬃciently: for instance, RSA has been broken by a timing attack [Koc96]. Leakage-resilient cryptography is an emerging approach to strenghthen the guarantees brought by provable security, by making its underlying model more accurate through the integration of covert channels. Physically observable cryptography [MR04b] is one example of a recent approach that aims at providing a realistic model in which to reason about security. However, there have been a number of earlier, more speciﬁc models, tailored to some speciﬁc forms of covert channels. For instance, the Bounded Storage Model (BSM) [Mau92] considers the possibility of an attacker gaining partial knowledge about secret information that resides on a physical device through a virus, or a malware. Formally, the BSM models corruption by modifying oracles so that they take as additional input from the adversary a virus, modelled as a circuit and so that they return as additional output the result of executing the circuit on the internal memory of the oracles. The BSM does not mandate that the circuit is bounded in its size, since it is assumed that the virus has total control over the machine until it is removed, but requires that the virus returns an answer of bounded size to the adversary, since too long messages to an adversary are likely to be noticed, or to be even impossible. Thus, the BSM model can take into account passive intrusion in proofs. While leakage-resilient cryptography is a thriving subject, the rapid progress in its development has not been matched by the formal methods community. To date, there is no formal veriﬁcation method to reason about leakage resilient cryptography. The purpose of this article is to initiate the development of such methods, with the aim to bring to leakage-resilient cryptography the high level of guarantees that can be achieved using formal methods to reason about the computational model. Our starting point is the Computational Indistinguishability Logic (CIL) [BDKL10], a general logic that supports reasoning about the correctness of cryptographic constructions in standard and idealized models. CIL features a small set of rules that deeply connect to standard notions in programming languages and process calculi, for instance bisimulations, contexts, observational equivalence, and can serve as the basis for a mechanical proof veriﬁer and hence help increase conﬁdence in cryptographic proofs. To date, CIL has been used eﬀectively to prove the security of encryption schemes such as OAEP [RB95] and signature schemes such as FDH [BR96b] and PSS [BR96a]. However, its underlying semantics mimicks the computational model and gives the adversary a black-box access to the oracle; in particular, CIL cannot be used directly to model leakage resilient cryptography, and more speciﬁcally the BSM. The contributions of this work are two-fold: ﬁrst, we extend CIL to handle the BSM, and with an explicit treatment of time; second, we prove that the intrusion resilent key exchange protocol from [Dzi06] is correct using the extended formalism. Thus, our work constitutes the ﬁrst application of CIL to a protocol, and the ﬁrst formal proof of security in a model of leakage-resilient cryptography.

104

G. Barthe, M. Duclos, and Y. Lakhnech

Related Work: Leakage resilient cryptography is a ﬂourishing subject, and it is out of the scope of this article to provide an extensive account of its recent developments. We just mention some natural extensions to the BSM model, and refer to [ADW09] for a survey. Models for both intrusion-resilience and leakageresilience were proposed in [MR04a] by Maurer et al., followed by work on leakage resilience by Dziembowski et al. in [DP08] which results on a leakage resilient cipher stream. Very recently, Kiltz and Pietrzak developed a leakage resilient variant of ElGamal encryption in [KP10]. There are primarily two means to reason formally about the security of a cryptographic protocol in the computational model: one can device a sound abstraction of the model, and prove the security of a protocol in the abstract model; or, one can reason directly in the computational model. The ﬁrst line of work has been followed in the so-called symbolic approach to cryptography, in where symbolic models that are supported by decision procedures or other practical methods are used to reason about a protocol, and computational soundness results are used to derive the guarantees in the computational model from the proof of correctness in the symbolic model. We refer the interested reader to [CKW10] for a recent survey on symbolic methods and computational soundness results. The second line of work encompasses works on indistinguishability logics, initiated by Impaglazzio and Kapron [IK06] and further developed by Zhang [Zha08] and Datta et al [DDMW06], and the work on tools like CryptoVerif [Bla06] (which is an automated veriﬁer in the computational model), and CertiCrypt [BGZ09] (a framework to construct machine-checked proofs). Outline: In section 2 we present the BSM and the intrusion-resilient protocol from [Dzi06], which enables two parties to generate a session key. In section 3, we describe CIL, and the extensions for integrating intrusion resilience in our model and proofs. We present an application of these extentions in Sect. 4.

2

Intrusion Resilience and Bounded Storage Model

A cryptographic scheme is said to be intrusion resilient secure if it ensures some security property (as secrecy, for example), even if its adversaries can send a virus to the honest parties. We verify this property in the Bounded Storage Model, deeply explained by Dziembowski [Dzi06]: in this model, the virus has complete view on honest parties hardware, but can only send back short information on it to the adversary. For compatibility, we adopt the notations from [Dzi06], in particular: – – – – –

k is the security parameter, σ(k) is the size of the output of the virus, s is the size of the adversary (Eve) memory, K is a (huge) common random input to the honest participant, α(k) is the size of K.

A Computational Indistinguishability Logic for the Bounded Storage Model

2.1

105

Bounded Storage Model

Dziembowski [Dzi06] deﬁnes in detail the underlying model for key exchange protocols in the BSM. As we largely follow his presentation, we only informally introduce his model and scheme here, and refer to [Dzi06] for more details. For simplicity, we assume that there are two honest parties Alice and Bob, whose goal is to set up a common session key. Alice and Bob share a long random def α(k)-bit string K, from a randomizer space R = {0, 1}τ (k), either temporarily accessible by anyone, or broadcasted by Alice or Bob (for all sessions). Moreover, they have fresh (independent) random inputs at the beginning of each session. At the end of the session, they both obtain a session key κA and κB respectively. Additionally, we assume the presence of an adversary Eve. As usual, Eve has complete control over the network: she can delay, change or even stop messages between the parties, and send her own messages. Moreover, Eve can corrupt Alice and Bob’s machines: at the beginning of each session she can install a virus, i.e. a circuit which returns a result, that will be run on each Alice’s and Bob’s. She retrieves the result of this circuit at the end of the session. The circuit can do the following: i. read all the internal data of the machine on which it is installed, ii. compute an arbitrary function Γ on this data; this function is modeled as a boolean circuit, and its only restriction is that the size of its output is bounded, iii. send the result back to the adversary at the end of the session. The BSM mandates that the result is of bounded size, but allows the size of the circuit to be unbounded. Moreover, the BSM does not take into account active viruses which could alter the memory or change the behavior of the honest participant. The goal of Eve is to compromise a session key, i.e.: – to make Alice and Bob agree on diﬀerent session keys, – to make Alice or Bob agree on a (partially) known key1 , – to learn the key on which Alice and Bob agreed for some uncorrupted session, i.e. session where no circuit was sent to the machine. The protocol studied in this paper uses an intrusion resilient key expansion function. Such a function is able to expend a key Y into V using a huge random string R such that even if Eve has had a temporary access to R and that she knows Y , Eve is not able to get signiﬁcant information on V (once she has lost her access to R). We assume that Eve has a memory of size σ(k) considerably smaller than def τ (k) = |R|. Then she can only store partial information of size σ(k) on R, via any storage function h : R → {0, 1}σ(k) she wants to use. Once she retrieves this information, she looses her access to R. As R is truly random, Eve cannot recompute R from h(R). It follows that knowing (h(R), Y ), Eve has no meaningful information about f (R, Y ). Such a function is called a (σ, τ, ν, μ)-secure intrusion resilient expansion key function. Such a function has been designed and proved intrusion-resilient in [DM04]. 1

By partially known key we mean that Eve has signiﬁcant information about this key.

106

2.2

G. Barthe, M. Duclos, and Y. Lakhnech

Intrusion Resilient Session Key Generation Protocol

The original protocol described in [Dzi06] works in two phases: ﬁrst, both parties compute a common authentication intermediate key S from their long shared key. Then, using this key with a MAC function, they exchange the session key, using an asymmetric encryption scheme. For some ﬁxed security parameter k, let R = {0, 1}τ (k), Y = {0, 1}μ(k) , K = def (RA , RB ) ∈ R2 , α(k) = 2τ (k), f : R × Y → {0, 1}ν(k) is a (σ, τ, ν, μ)-secure intrusion resilient expansion key function, and H : {0, 1}ν(k) → {0, 1}λ(k) is a hash function (modeled as a random oracle function), MAC uses a key of length λ(k) and the encryption scheme is an asymmetric encryption scheme semantically secure. The protocol takes place in seven steps: 1. A picks up randomly YA from Y and sends it to Bob. 2. B picks up randomly YB from Y and sends it to Alice. def 3. A and B compute SA = SB = S = f (RA , YA ) ⊕ f (RB , YB ) and SA = SB = def

4. 5.

6. 7.

S = H(S). This terminates the ﬁrst part of the protocol. A generates a public and private key pair2 , and sends the public key along with a MAC using S of it (labelled with her identity) to B. B checks the MAC, if it is correct then it generates randomly a session key κi ∈ {0, 1}δ(k) , encrypts it, sends it along with its MAC (labelled once again with B identity) to A and outputs κi . A checks the MAC, decrypts the message and outputs κi . At the end of the session, A and B erase all their internal data, except K.

If one of the checks fails, the party aborts the session. This protocol has been proved secure by hand in [Dzi06]. The proof idea of this scheme is that it can be attacked at two points: ﬁrst and second part. If the adversary can break S (in the ﬁrst part), then it can impersonate Alice and/or Bob in the second part. The best that Eve can do is to link SA and SB together, and SB are independent if SA = SB . Thus either SA = SB but as H is used, SA or SA and SB are independent. This equality leaves Eve with two options: to corrupt the encryption scheme, which is impossible, or to corrupt MAC. If SA and SB are independent, then Eve can’t forge a mac without SA or SB . As we can see, the proof reduces to the security of f as a BSM-secure function, the MAC and the encryption schemes.

3

Computational Indistinguishability Logic

CIL (Computational Indistinguishability Logic) [BDKL10] is a general logic for proving cryptographic protocols secure within computational models. The ultimate goal of this logic is to build a computer-aided veriﬁcation tool for cryptographic primitives and protocols. 2

Note that this particular key pair is only valid in this session.

A Computational Indistinguishability Logic for the Bounded Storage Model

107

CIL is based upon the notion of oracle system. Informally, an oracle system is a set of stateful oracles that share a memory. Oracles can be invoked by an adversary; when an oracle is called with a query, it runs its implementation on the memory, updates the memory and returns its answer. The security is represented by a function of the number of calls to the oracles, which measures the probability of an adversary to either provoke some bad event, or to distinguish between two schemes, within a given running time; formally, the probability is deﬁned as a function from time, which is modelled abstractly, to probabilities, i.e. values in the unit interval. The original notion of oracle system is suﬃcient for reasoning in the computational black box model, but cannot account immediately for the BSM. Extending CIL to model the BSM involves non-trivial original extensions and adaptations. The ﬁrst step to accomodate the BSM is to modify the signature of the function so that it also depends on the size of the viruses sent to the oracle. Below we brieﬂy review in Section 3.1 the main deﬁnitions and properties of CIL—we refer to [BDKL10] for a more complete account of CIL—and its extension to handle time and the BSM. Then we present in Sect. 3.2 a selection of the rules that we use in Sect. 4. 3.1

Basic Notions of CIL

CIL is designed to reason about the interactions between an oracle system (the primitive or protocol for which we want to prove a security property) and an adversary. As we reason about probabilistics algorithms (for both oracles and adversaries), we use a notation for distribution: D(U ) denotes a distribution over U . The following deﬁnition for an oracle system can be described more intuitively as a set of oracles running on a shared memory. Definition 1 (Oracle System). An oracle system O is given by: – sets Mo of oracle memories and No of oracles; – for each o ∈ No , a query domain In(o), an answer domain Out(o) and an implementation: Oo : In(o) × Mo → D(Out(o) × Mo ) – a distinguished initial memory m ¯ o ∈ Mo , and distinguished oracles oI for initialization and oF for finalization, such that In(oI ) = Out(oF ) = 1. We let Res = In(oF ). Adversaries are stateful systems that communicate to each other and interact with oracle systems. They can be deﬁned by two functions: one which computes the query to be asked an oracle of the system, and another to interpret the answer and update its memory. An exchange ((o, q, a) of the set Xch) consists then in a query (o, q) and an answer (a), a query being an oracle name and the question itself. The set of queries is denoted Que, and the set of answers is denoted Ans. In the following deﬁnition, we use to denote a partial function.

108

G. Barthe, M. Duclos, and Y. Lakhnech

Definition 2 (Adversary). An adversary A (for an oracle system O) is given by a set Ma of adversary memories, an initial memory m ¯ a ∈ Ma and functions for querying, and updating: A : Ma D(Que × Ma ) A↓ : Xch × Ma → D(Ma ) We define the running time τA (resp. τA↓ ) of an adversary as the number of elementary operations computed by A (resp. A↓ ). To model intrusion resilience, we need to take into account circuits sent by the adversary to the oracle: Γ of type Mo → {0, 1}γ . Informally, Γ is a circuit describing a function, and γ denotes the size of Γ ’s output. Then, we require that implementations of oracles return the result of the function computed by Γ on the current memory of the oracle system in addition to its proper answer. As the behaviour of an oracle system is deterministic once the random draws are set, we can assume that the adversary sends its circuit to the initialization oracle only, which runs it on the common memory. The interaction between the adversary and the oracle system extends immediately to this new setting, and yields a distribution A|O on traces. First, the oracle system has an initial memory. Then, the adversary submits its ﬁrst query to the oracle system, which computes the ﬁrst answer accordingly, updating its memory. The adversary receives its answer, updates its internal state, and another round can take place. The interaction halts when the adversary outputs its reply. A sequence of queries and answers is called an execution. An essential aspect in all cryptographic proofs is the running time of an adversary; we now deﬁne formally a bounded adversary, and its running time. Definition 3 (Bounded Adversary). Let O be an oracle system composed of oracles O1 , · · · , On . We define fo the function mapping Oi to the number of calls from A to Oi . An adversary A is called (t, q1 , · · · , qn , b)-bounded if for any execution of A | O, – fo (Oi ) ≤ qi , ∀i = 1, · · · , n – τA + τA↓ ≤ t – |γ| ≤ b To deﬁne security properties, we often use execution traces to check if some event has occurred or not during an interaction of an adversary with an oracle system. A trace consists of a succession of exchanges and memory updates of the oracle system from the initial memory and querying the oI , and ﬁnish by a ﬁnal exchange with oF , and each step has a non-zero probability to happen. By denoting T (η) the trace (obtained by removing the adversarial memory) associated with the execution η, and T −1 (τ ) the set of executions producing τ , we are able to deﬁne the probability of any event E over O-traces: Pr [A|O : E] =Pr A|O : T −1 (E) = Pr [A|O : η] η∈Exec(A|O)|E(T (η))=true

A Computational Indistinguishability Logic for the Bounded Storage Model

109

CIL considers two judgments: – probability statements of the form O : E, with E an event. This statement is valid (|= O : E) if and only if for every adversary A, Pr [A|O : E] ≤ – indistinguishability statements of the form O ∼ O , with O and O compatible oracle systems3 . Such a statement is said to be valid (|= O ∼ O ) if and only if |Pr [A|O : r = true] − Pr [A|O : r = true] | ≤ where r = true means that the adversary was able to compute a property on an uncompromised ﬁnished session with O and O . Intuitively, it says that whatever property r A can compute on O, he will retrieve r with the same probability on O if O is indistinguishable from O. The function essentially stands for the expression of the probability that an adversary can produce a given event, or distinguish between two oracle systems. This function depends on the number of calls that the adversary makes to the oracles (intuitively, for a clever adversary, the more it makes queries to the oracles, the higher the probability will be to force an event or to distinguish between oracle systems). We adapt it to take into account the running time of the adversary and the size of the result of the virus. Then we have: : ((No → N) × T × N) → [0, 1] where No → N is a function which maps for each oracle name the maximal number of calls that the adversary makes to this oracle. N denotes the maximal size of the information retrieved by the adversary and T denotes the running time of the adversary. We also add a new operator to the original CIL logic that allows us to deal with sequential execution. We deﬁne O1 ; O2 to denotes a sequential execution (where O1 and O2 are oracle systems). The idea is that an adversary is allowed to ask a ﬁxed number of queries to O1 before querying O2 . When it starts querying O2 , it cannot query O1 again. Definition 4 (Sequential Composition). Let O1 , O2 be oracle systems. The sequential composition O1 ; O2 denotes a new oracle system such that the memory is: Mo = Mo 1 Mo 2 {f lag}, and the oracle names are: No = No 1 No 2 (where denotes the disjointe union), the initial memory is m ¯ o1 , and f lag = 0. The f lag bit marks if the adversary started to query the second oracle system, in which case it cannot ask again the first oracle system. We introduce a new constant 3

Two oracle systems are said to be compatible if and only if an adversary can act in the very same way with it: be able to ask the same questions, with the same kind of answer. Formally, they must have the same set of oracle names, and the sets Que and Ans must have the same domains in both oracle systems.

110

G. Barthe, M. Duclos, and Y. Lakhnech

null which can be of any type and has no information. The implementation is changed in this way: for Que = (o, q), if o ∈ No 2 then let m.f lag ← 1 in return Oo (q, m) else if m.f lag = 0 then return Oo (q, m) else return (null , m) Note that the sets of oracle names must be disjoint, or there will be conﬂicts between diﬀerent implementations of oracles. Proposition 1. Let O1 , O2 and O1 , O2 be oracle systems. If |= Oj ∼ j Oj for j = 1, 2 then |= O1 ; O2 ∼ O1 ; O2 with (f, t, b) = 1 (f1 , t1 , b1 )+ 2 (f2 , t2 , b2 ) and b = b1 + b2 , t = t1 + t2 and f (o) = f1 (o) if o ∈ No1 and f (o) = f2 (o) if o ∈ No2 . Proof idea: The main idea is to use a reduction argument: we suppose that |= Oj ∼ j Oj for j = 1, 2, and that we have an adversary A that can distinguish between with O1 ; O2 and O1 ; O2 with better probability than . We then prove that we can construct two adversaries from A: A1 against O1 ∼ 1 O1 : it uses A in the sense that it forwards queries to O1 and simulates O2 , and a second adversary which simulates O1 and forwards queries to O2 . One of the two adversaries has a probability of success higher than 1 or 2 . Context. A context is an intermediate between the adversary and the oracle system. A context can be applied to an adversary to form a new adversary, or to an oracle system to form a new oracle system. This captures many reduction proofs: to translate a query to a basic oracle system from an adversary against another oracle system is the very nature of a reduction proof. In the setting of our extended model, contexts need to partially evaluate circuits on their own memory, prior to forwarding it to the oracle. More precisely the circuit has then this type: Γ : Mc → Mo → {0, 1}γ ≡ Γ : Mc × Mo → {0, 1}γ The context (or rather the initialization procedure of the context) evaluates Γ on its memory. It then gets a new circuit Γ : Mo → {0, 1}γ which it can forward to the initialization oracle function. We also need to take into account the running time of the context, as it changes the running time of the adversary with which it can be composed and the number of calls to the oracles. The epsilon function is then changed in this way: c (fc , t, b) = o (fo , t + Tc , b) where c is associated with the oracle system composed to the context, o is associated with the oracle system alone, Tc denotes def m the running time of the context, namely Tc = j=1 fc (cj )(TC→ (cj ) + TC← (cj ) ) m and fo (oi ) = j=1 α(oi , cj )fc (cj ) the number of calls to the oracles, fc the number of calls to the context, TC→ (cj ) the running time of the context C→ (cj ), def

and with α(oi , cj ) = 1 if oi is called by cj , 0 otherwise.

A Computational Indistinguishability Logic for the Bounded Storage Model

111

Bisimulation. An important tool to handle cryptographic proofs is to be able to transform an oracle system into an equivalent one, which is much easier to reason with. The two systems are in general similar up to some bad event: an idealized signature scheme cannot be fooled, whereas a secure signature scheme could be forged with negligeable probability. Then there is a notion of bisimulation up to some event: two oracle systems are bisimilar (i.e. have the same behavior), with regard toward a relationship R binding the memories of the two oracle systems together, as long as some condition ϕ holds. We denote by O ≡R,ϕ O the fact that the two oracle systems O and O are bisimilar with regard toward R up to ϕ. Classical bisimulation is captured by bisimulation up to true. The rule OR below captures bisimilarity up to. 3.2

Rules

This paragraph summarizes the rules used for the case study. First, there are rules to capture that indistinguishability is an indexed equivalence relation. The rules for reﬂexivity and symmetry are obvious; the rule for transitivity and sequential composition are of the forms: O ∼ 1 O O ∼ 2 O (trans) O ∼ 1 + 2 O

O1 ∼ 1 O1 O2 ∼ 2 O2 (SEQ) O1 ; O2 ∼ O1 ; O2

where is deﬁned in prop. 1. CIL features a rule for contexts and a rule for bisimilarity: O ∼ o O (SUB) C[O] ∼ c C[O ]

O : F¬ϕ O ≡R,ϕ O (OR) O ∼ O

where c is explicited in the previous paragraph. The last rule states that unless some ﬂag is set to false, there are no means to distinguish between the two oracle systems. The proof system is sound.

4

Intrusion Resilient Session Key Generation Protocol Proved Correct in CIL

Following the work of [Dzi06], we try here to prove their scheme in a formal logic: Computational Indistinguishability Logic (cil). The idea of this proof is to prove the equivalence of the original protocol (which we will name π in the rest of the paper) presented in Sect. 2.2 to an idealized protocol described in Fig. 1 (denoted π id ). The idealized protocol does not leak any information about the secret data as none of the exchanged messages contains any information about it. To be more explicit, there are two parts in the protocol: the ﬁrst to get an intermediate key which is later used to authenticate the two parties. The second part is the generation and exchange of the session key. These two parts are quite independent, and it is easier to handle the protocol it sequential. Thus we consider the protocol as two sequential subprotocols, π0 and π1 .

112

G. Barthe, M. Duclos, and Y. Lakhnech

The idealized protocol is presented in Fig. 1. In the ﬁrst part of the protocol, if the exchange of the nounces happens without any interference, then Bob draw a random S which magically appears at Alice’s. In the second part of the protocol, if the macs (used with S ) are correct, and the encryption valid, then, again, Bob draw a session key κi which is instantly retrieved by Alice. Thus this idealized protocol oﬀers the same message distribution as the original, but no information travel over the network. Hence, this protocol cannot leak any information about S or κi . Alice R

Bob R

YA ← − Y, YA sent to Bob YB ← − Y, YB sent to Alice R S − {0, 1}k S ← R (pkA , skA ) ← − K, (pkA , MACS (A : pkA )) sent to Bob R check MAC, κi ← − {0, 1}k , enc ← εpkA (0), (enc, MACS (B|enc)) sent to Alice κi κi erase all but K erase all but K Fig. 1. Idealized intrusion resilient key generation protocol from [Dzi06]

We need to deﬁne clearly the oracle system in which we prove the protocol correct. The oracle system (which we will call Oπ ) is composed of a series of basic oracle systems: – Of ⊕f , which uses the intrusion resilient function, which takes 2 parameters as an entry and outputs a single value, – a OMAC oracle system (OMAC for generation, OVer for veriﬁcation), – an asymmetric encryption system (Oi−encr for key generation, Oε(·) for encryption, OD(·) for decryption). We also use several contexts, to modelize the fact that the protocol uses several cryptographic primitives: – CH which encapsulates Of ⊕f into Oπ0 (i.e. CH [Of ⊕f ] = Oπ0 ), – CMAC which encapsulates Oε(·) to π1 , – Cε(·)id which encapsulates OMAC towards Oπ1id . Equality between oracle systems is given as equality of (Que, Ans) distributions of both oracle systems. The proof tree is presented in Fig. 4. Using the sequential property of the scheme, we can clearly divide the proof in two independent parts.

A Computational Indistinguishability Logic for the Bounded Storage Model

113

Of ⊕f ∼1 OU (SUB) CH (f ) = Oπ0 ∼1 CH (U ) = Oπid 0

Fig. 2. Subtree for Fig. 4, ﬁrst part of the protocol OM AC id ≡R,¬f orged OM AC

OM AC :2 Ff orged

OM AC id ∼2 OM AC Oπid ∼ Cεpk (0) (OM AC ) 1

OR

Oεpk (·) ∼3 Oεpk (0)

SUB

Oπ1 ∼ CM AC (Oεpk (0) )

2

3

Oπ1 ∼ + Oπid 2

3

SUB trans

1

Fig. 3. Subtree for Fig. 4, second part of the protocol

Oπ0 ∼1 Oπid 0

(Fig. 2)

Oπ1 ∼2 +3 Oπid

Oπ ∼1 +(2 +3 ) Oπid

1

(Fig. 3) (SEQ)

Fig. 4. Proof tree of Dziembowski Protocol

For the sake of brevity, some details of the proof, and most oracle and context deﬁnitions have been left out, but are described in the full version of this article [BDL11]. 4.1

First Part of the Protocol

First, we prove the ﬁrst part of the protocol (Fig. 2): π0 . We start from what we want to prove, i.e. Oπ0 ∼ Oπ0id for some . The goal is to go up to known assumptions of cryptographic primitives: here we want to exploit the fact that f is indistinguishable from a uniform distribution. From the protocol, we are able to deﬁne an oracle system implementing Oπ0 . The ﬁrst part of the protocol is implemented in Fig. 5. Oinit is a session initializer: the adversary is forced to call it to start a new session. It sends it its Γ , and get back Γ (Mo ). The diﬀerent actions of the participants are implemented step by step as OA1 , OA2 , OB1 , OB2 . def Using f ⊕ f (YA , YB ) = f (YA ) ⊕ f (YB ) as a oracle system, we are able to deﬁne a context system which when associated with the former oracle system has the same message distribution and S distribution as π0 . H is a random oracle which keeps a list of the requested hash values and the random values assigned to each one of them. The initial memory of the context is the empty list. Then, when it is called (with two inputs YA , YB ), it def

calls f (YA ) ⊕ f (YB ) and computes S = H(f (YA ) ⊕ f (YB )). S stays secret, and it outputs a bit (1 for example), meaning that the computation was successful. The justiﬁcation for equal distributions is then straightforward: the output of H is the uniform distribution.

114

G. Barthe, M. Duclos, and Y. Lakhnech

Oinit (Γ, m) : if m.start = 1 then abort else let (m1 .RA , m1 .RB , m1 .f lagsA , m1 .f lagsB ) ← (RA , RB , [1, 0, 0], [1, 0, 0]) in return (Γ (m1 ), m1 ) OA1 (m) :

if m.f lagsA [0] = 1 ∨ m.f lagsA [1] = 0 then abort else let m.YAA ← {0, 1}μ(k) in let m.f lagsA ← [1, 1, 0] in return (m.YAA , m)

OA2 (YB , m) : if m.f lagsA [1] = 1 ∨ m.f lagsA [2] = 0 then abort else let m.YBA ← YB in let m.S A ← f (m.RA , m.YAA ) ⊕ f (m.RB , m.YBA ) in let m.S A ← OH (m.S A , m) in let m.f lagsA ← [1, 1, 1] in return (1, m) OB1 (YA , m) : if m.f lagsB [0] = 1 then ∨ m.f lagsB [1] = 0abort else let m.YBB ← {0, 1}μ(k) in let m.f lagsB ← [1, 1, 0] in return (m.YBB , m) OB2 (m) :

if m.f lagsB [1] = 1 ∨ m.f lagsB [2] = 0 then abort else let m.S B ← f (m.RA , m.YAB ) ⊕ f (m.RB , m.YBB ) in let m.S B ← OH (m.S B , m) in let m.f lagsB ← [1, 1, 1] in return (1, m)

Fig. 5. Implementation of the Oracle system Oπ0

A Computational Indistinguishability Logic for the Bounded Storage Model

115

Then we get to f ∼ 1 U (where U denotes a function with uniform distribution over its range, which is the range of f ). This is true if f is an intrusion resilient function: not knowing either RA or RB , an adversary can’t distinguish the output of f from a random number (in the same range). Then we get the proof tree of Fig. 2. 4.2

Second Part of the Protocol

We now focus on the second part of the protocol (Fig. 3): π1 . Here again, the idea is to go bottom up to some known assumptions of the cryptographic primitives. A little subtlety is however used: we prove that both Oπ1 and Oπ1id are indistinguishable to a third protocol. By transitivity, they are then indistinguishable. OInit (Γ, m) :

if m.start = 1 then abort else Oi−encr , Oi−mac let (m.f lagsA , m.f lagsB ) ← ([1, 0, 0], [1, 0]) in return (Γ (m), m)

OA3 (S , m) :

if m.f lagsA [0] = 1 ∨ m.f lagsA [1] = 0 then abort else let (m.pk, m.sk) ← K in let mac ← MACS (A : pk) in let m.f lagsA ← ([1, 1, 0]) in return (m.pk, mac, m)

OA4 (S , msg, m) : if m.f lagsA [1] = 1 ∨ m.f lagsA [2] = 0 then abort else parse msg as (cipher, mac) in let m.κA ← Dm.sk (cipher) if ¬ VerS (mac, εpk B|m.κA ) then abort else return (1, m) OB3 (S , msg, m) : if m.f lagsB [0] = 1 ∨ m.f lagsB [1] = 0 then abort else parse msg as (pk, mac) if ¬ VerS (mac, A|pk) then abort else let m.κB ← {0, 1}δ(k) in let m.encB ← εpk (0) in let m.msg2 ← m.encB , B|m.encB in let (m.f lagsB ) ← ([1, 1]) in return (m.msg2 , m) Fig. 6. Implementation of the Oracle System Oπ1

The implementation of π1 is shown in Fig. 6. To get to it from the oracle systems implementing the primitives, we deﬁne two context systems: the ﬁrst one links the cryptographic primitive MAC to π1id . The second context links the encryption scheme to π1 . In the special optic of intrusion, it is secure (up to the security of the mac and encryption schemes), since we use fresh random inputs for each session.

116

4.3

G. Barthe, M. Duclos, and Y. Lakhnech

Unifying the Two Parts

From there, we apply the contexts and get to Oπ1id ∼ 2 Cenc (OMAC ) and Oπ1 ∼ 3 CMAC (Oenc ). Then it remains to prove that Cenc (OMAC ) and CMAC (Oenc ) are equal in terms of messages and κ distributions, as the contexts simulate perfectly the behavior of the encryption and of the mac.

5

Conclusion

Computational Indistinguishability Logic (CIL) is a logic to reason about cryptographic constructions in the computational model. This paper extends CIL to reason about the bounded storage model, in which the adversary can have limited access to the internal state of the parties running the protocol, by injecting viruses. In order to capture the BSM, we extended the notion of oracle so that it takes as additional argument a circuit, that is used to compute the leaked information. Moreover, we have shown that the resulting framework is suﬃciently expressive to formalize the security proof of Dziembowski’s protocol [Dzi06]. Our work provides preliminary evidence that CIL, and more generally logics of indistinguishability, are applicable to leakage-resilient cryptography. However, signiﬁcant work is required to account in a single formal model for the developments in these new models. Our next objective is to extend this work to active viruses, i.e. viruses that are able to change the memories of honest participants.

References [ADW09]

[BDKL10]

[BDL11]

[BGZ09]

[Bla06]

[BR96a]

[BR96b]

Alwen, J., Dodis, Y., Wichs, D.: Survey: Leakage Resilience and the Bounded Retrieval Model. In: Kurosawa, K. (ed.) Information Theoretic Security. LNCS, vol. 5973, pp. 1–18. Springer, Heidelberg (2010) Barthe, G., Daubignard, M., Kapron, B., Lakhnech, Y.: Computational indistinguishability logic. In: Proceedings of the 17th ACM Conference on Computer and Communications Security. ACM (2010) Barthes, G., Duclos, M., Lakhnech, Y.: A computational indistinguishability logic for the bounded storage model. Technical report, Verimag, IMDEA Software (2011) Barthe, G., Grégoire, B., Béguelin, S.Z.: Formal certiﬁcation of codebased cryptographic proofs. In: Proceedings of POPL 2009, pp. 90–101 (2009) Blanchet, B.: A computationally sound mechanized prover for security protocols. In: IEEE Symposium on Security and Privacy, pp. 140–154 (2006) Bellare, M., Rogaway, P.: The Exact Security of Digital Signatures - How to Sign with RSA and Rabin. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 399–416. Springer, Heidelberg (1996) Bellare, M., Rogaway, P.: The Exact Security of Digital Signatures - How to Sign with RSA and Rabin. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 399–416. Springer, Heidelberg (1996)

A Computational Indistinguishability Logic for the Bounded Storage Model [CKW10]

117

Cortier, V., Kremer, S., Warinschi, B.: A survey of symbolic methods in computational analysis of cryptographic systems. J. Autom. Reasoning, 1–35 (2010) [DDMW06] Datta, A., Derek, A., Mitchell, J.C., Warinschi, B.: Computationally sound compositional logic for key exchange protocols. In: Proceedings of CSFW 2006, pp. 321–334 (2006) [DM04] Dziembowski, S., Maurer, U.: Optimal randomizer eﬃciency in the bounded-storage model. Journal of Cryptology 17(1), 5–26 (2004) [DP08] Dziembowski, S., Pietrzak, K.: Leakage-resilient cryptography. In: IEEE 49th Annual IEEE Symposium on Foundations of Computer Science, FOCS 2008, pp. 293–302 (2008) [Dzi06] Dziembowski, S.: Intrusion-Resilience Via the Bounded-Storage Model. In: Halevi, S., Rabin, T. (eds.) TCC 2006. LNCS, vol. 3876, pp. 207–224. Springer, Heidelberg (2006) [GM84] Goldwasser, S., Micali, S.: Probabilistic encryption* 1. Journal of Computer and System Sciences 28(2), 270–299 (1984) [IK06] Impagliazzo, R., Kapron, B.M.: Logics for reasoning about cryptographic constructions. Journal of Computer and Systems Sciences 72(2), 286–320 (2006) [Koc96] Kocher, P.C.: Timing Attacks on Implementations of Diﬃe-Hellman, RSA, DSS, and Other Systems. In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 104–113. Springer, Heidelberg (1996) [KP10] Kiltz, E., Pietrzak, K.: Leakage Resilient ElGamal Encryption. In: Abe, M. (ed.) ASIACRYPT 2010. LNCS, vol. 6477, pp. 595–612. Springer, Heidelberg (2010) [Mau92] Maurer, U.M.: Conditionally-perfect secrecy and a provably-secure randomized cipher. Journal of Cryptology 5(1), 53–66 (1992) [MR04a] Micali, S., Reyzin, L.: Physically Observable Cryptography. In: Naor, M. (ed.) TCC 2004. LNCS, vol. 2951, pp. 278–296. Springer, Heidelberg (2004) [MR04b] Micali, S., Reyzin, L.: Physically Observable Cryptography (Extended Abstract). In: Naor, M. (ed.) TCC 2004. LNCS, vol. 2951, pp. 278–296. Springer, Heidelberg (2004) [RB95] Rogaway, P., Bellare, M.: Optimal asymmetric encryption how to encrypt with rsa (1995) [Zha08] Zhang, Y.: The computational SLR: a logic for reasoning about computational indistinguishability. IACR ePrint Archive 2008/434 (2008); Also in Proc. of Typed Lambda Calculi and Applications 2009

Preventing the Cluster Formation Attack against the Hierarchical OLSR Protocol Gimer Cervera1 , Michel Barbeau1 , Joaquin Garcia-Alfaro2, and Evangelos Kranakis1 1

School of Computer Science, Carleton University, K1S 5B6, Ottawa, Ontario, Canada {gcevia,barbeau,kranakis}@scs.carleton.ca 2 Institut Telecom, Telecom Bretagne, LUSSI Dept., Cesson-Sevigne, 35576, France [email protected]

Abstract. The Hierarchical Optimized Link State Routing (HOLSR) protocol enhances the scalability and heterogeneity of traditional OLSR-based Mobile AdHoc Networks (MANETs). It organizes the network in logical levels and nodes in clusters. In every cluster, it implements the mechanisms and algorithms of the original OLSR to generate and to distribute control traffic information. However, the HOLSR protocol was designed with no security in mind. Indeed, it both inherits, from OLSR, and adds new security threats. For instance, the existence of misbehaving nodes can highly affect important HOLSR operations, such as the cluster formation. Cluster IDentification (CID) messages are implemented to organize a HOLSR network in clusters. In every message, the hop count field indicates to the receiver the distance in hops to the originator. An attacker may maliciously alter the hop count field. As a consequence, a receiver node may join a cluster head farther away than it appears. Then, the scalability properties in a HOLSR network is affected by an unbalanced distribution of nodes per cluster. We present a solution based on the use of hash chains to protect mutable fields in CID messages. As a consequence, when a misbehaving node alters the hop count field in a CID message, the receiver nodes are able of detecting and discarding the invalid message. Keywords: MANETs, Routing, HOLSR, Security, Hash Chains.

1 Introduction The Hierarchical Optimized Link State Routing (HOLSR) [14] is a proactive routing protocol designed to improve scalability of heterogeneous Mobile Ad-Hoc Networks (MANETs). HOLSR has two phases: i) cluster formation and ii) topology map acquisition. In the first phase, HOLSR organizes the network in logical levels and nodes in clusters. In the second phase, HOLSR implements the mechanisms and algorithms of the original OLSR [4] to generate and to distribute control traffic messages. Information contained in Hello and Topology Control (TC) messages are used to calculate optimal routes from any given node to any destination within each cluster. Additionally, Hierarchical Topology Control (HTC) messages are implemented to advertise membership information from a cluster to other nodes in higher levels. Nevertheless, HOLSR was J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 118–131, 2012. c Springer-Verlag Berlin Heidelberg 2012

Preventing the Cluster Formation Attack against the HOLSR Protocol

119

designed without security measures. Therefore, both phases are vulnerable to malicious attacks. In HOLSR networks, a malicious attack can be perpetrated by a node that interrupts the flooding of control traffic information or does not obey the rules of the protocol to maintain the hierarchical architecture. In this paper, we describe a cluster formation attack against the HOLSR protocol during the cluster formation phase. During the first stage, every cluster head advertises itself through the periodical generation of CID messages that invite other nodes to join. Every CID message has a hop count field that indicates the distance to the originator. The cluster head field of a CID messages points to the originator. When the receiver node joins a cluster head, it generates a new message increasing by one the hop count field. When a node receives messages from different cluster heads, it joins the closest cluster head, in terms of hops. When a node receives CID messages from multiple cluster heads, but with the same hop count, it attaches itself to the cluster head from which it received the first message and remains with that cluster head until the topology changes. As a consequence, a node at the border of different clusters only accepts control traffic information from its cluster. An attacker might unsettle this process by generating CID messages with and invalid hop count field. This attack, has a higher impact when the hop count field value is drastically reduced. The receiver nodes may join a cluster head which is farther away than it appears. As a result, the affected cluster head may be overloaded due to an unbalanced node distribution. Additionally, the nodes in some clusters have to include more elements in their routing tables adding unnecessary overhead to the cluster. We handle this risk by implementing a mechanism that implements hash chains to protect the hop count field in every CID message. Our solution is based on the work of Hong et al. in [6]. They present a wormhole detective mechanism and an authentication protocol to strengthen the neighbor relationship establishment in standard OLSR. We address a different kind of attack in HOLSR networks. Our mechanism protects the integrity of CID messages and enforces the uniform distribution of nodes in every cluster. Organization of the paper. Section 2 reviews the OLSR protocol. Section 3 presents the HOLSR protocol. Section 4 describes the cluster formation attack. Section 5 presents a new security extension to the protocol leveraging hash chains that mitigates the cluster formation attack. Section 6, shows our results and simulations setup. Section 7 presents the related work. Finally, Section 8 closes the paper with our conclusions.

2 Optimized Link State Routing Protocol This section presents a brief overview of the OLSR protocol. OLSR is a proactive routing protocol designed for MANETs. The core of the protocol is the selection, by every node, of Multipoint Relays (MPRs) among their one-hop symmetric neighbors. OLSR nodes flood the network with link-state information messages. The link-state information is constructed by every node and involves periodically sending Hello and TC messages. This information is used to determine the best path to every destination in the network. Due to the proactive nature, the routes are immediately available when needed. The OLSR protocol is based on hop by hop routing, i.e., each routing table lists, for each reachable destination, the address of the next node along the path to that

120

G. Cervera et al.

destination. To construct a topology map, every node implements a topology discovery mechanism leveraging the periodic exchange of control traffic messages. Topology discovery includes: link sensing, neighbor detection and topology sensing. During this first stage (link sensing), every node populates its local link information base (link set). This phase is exclusively concerned with the OLSR interface addresses and ability to exchange packets between such OLSR interfaces. Then, during the neighbor detection stage, every node populates its neighborhood information base (i.e., onehop and two-hop neighbor set). The link sensing and neighbor detection phases are based on the periodic exchange of Hello messages. Hello messages are solely transmitted to one-hop neighbors. Information contained in Hello messages allows every node to construct and maintain neighbor tables, as well as to select its MPR set. The MPR set is selected such that all two-hop neighbors are reachable through, at least, one MPR. In the neighbor table, each node records the information about the one-hop neighbor link status (i.e., unidirectional, bidirectional or MPR), with this information every node builds its MPR selector set, i.e., the number of neighbors who selected that node as their MPR. Topology sensing is achieved through the exchange of TC messages. TC messages are generated and retransmitted exclusively by the MPRs. These messages allow each node to construct its topology table and to declare its MPR Selector set. The MPR Selector Set is the collection of nodes that have selected a given node as an MPR. A TC contains the MPR Selector Set of its originator. A node that has an empty MPR Selector Set does not send or retransmit any TC message. An MPR forwards a message if it comes from a node in its MPR Selector Set. This forwarding algorithm is defined in [4]. Using the information from TC messages, each node maintains a topology table where each entry consists of: (i) an identifier of a possible destination, i.e., an MPR selector in a TC message, (ii) an identifier of a last-hop node to that destination, i.e., the originator of the TC message, and (iii) an MPR Selector Set sequence number [8]. It implies that a possible destination (i.e. an MPR selector) can be reached through the originator of the TC message. If there is an entry in the topology table whose last-hop address corresponds to the originator of a new TC message and the MPR Selector Set sequence number is greater than the sequence number in the received message, then the new message is discarded. Routing tables are constructed using the information from the neighbor and topology table. OLSR implements two optional messages: Multiple Interface Declaration (MID) and Host and Network Association (HNA) messages. MID messages are used to declare the presence of multiple interfaces on a node. HNA messages are employed to inject external routing information into an OLSR network and provide connectivity to nodes with non-OLSR interfaces. HNA and MID are exclusively retransmitted by the MPRs and following the default forwarding algorithm defined in [4]. MID messages are implemented in a network with multiple interface nodes. Additional information is necessary in order to map interface addresses to main addresses. In OLSR, the main address is defined as the OLSR interface address. A node with multiple interfaces must generate periodically MID messages announcing all its interfaces to other nodes in the network. Thus, every node in an OLSR network will associate multiple interfaces to a node’s main address. Nodes with just one interface do not generate MID messages and the main

Preventing the Cluster Formation Attack against the HOLSR Protocol

121

address is the OLSR interface address. A node with several interfaces, where only one of them is participating in an OLSR network must not generate MID messages. MID messages are retransmitted exclusively by the MPRs following the default forwarding algorithm . Upon receiving a MID message, the information is stored in an Interface Association table. This information is used to construct the routing tables. Then, if a node misbehaves and does not retransmit MID messages, the proper construction of the routing tables is compromised. In an OLSR network, a node with multiple interfaces might be connected to an external network (e.g., an Ethernet) not running OLSR. In this case, the node acts as a gateway and may inject external routing information in the OLSR network. Thus, a node connected to an external network should periodically generate HNA messages announcing its external network address and netmask. HNA messages flood the network following the default MPR forwarding mechanism. The flooded information is used by the OLSR nodes to construct their routing tables. HNA messages can be considered as a generalized version of the TC messages. Like TC messages, the originator of the HNA messages announces reachability to the others.

3 The Hierarchical OLSR Protocol OLSR is a flat routing protocol designed exclusively for MANETs. However, the performance of the protocol tends to degrade when the number of nodes increases due to a higher number of topology control messages propagated through the network. Scalability can be defined as the capacity of the network to adjust and to maintain its performance even when the number of nodes in the network increases [14]. The MPR mechanism is local and therefore very scalable. However, the diffusion by all the nodes in the network of all the link-state information is less scalable. For instance, in [11] Palma et. al. show that OLSR has good results in terms of scalability in networks with up to 70 nodes, preferably with a moderate node speed (e.g., pedestrian speed) and where the number of traffic flows is also moderate. However, OLSR’s performance decreases in large heterogeneous ad hoc networks. Additionally, OLSR does not differentiate the capabilities of its member nodes and, in consequence, does not exploit nodes with higher capabilities. Thus, HOLSR is an approach designed to improve the scalability of OLSR protocol in large-scale heterogeneous networks. The main improvements are a reduction in the amount of topology control traffic and efficient use of high capacity nodes. HOLSR organizes the network in hierarchical clusters. This architecture allows to reduce the routing computational cost, i.e., in case a link is broken only nodes inside the same cluster have to recalculate their routing table while nodes in different clusters are not affected. In HOLSR, nodes are organized in clusters according to their capacities. The network hierarchical architecture is illustrated in Fig. 1. At level 1, we have low-capability nodes with one interface represented by circles. Nodes at the topology level 2 are equipped with up to two wireless interfaces, designated by squares. Nodes at level 2 employ one interface to communicate with nodes at level 2 and one interface to communicate with nodes at level 1 or 3. Nodes at level 3, designated by triangles, represent high-capacity nodes with up to three wireless interfaces to communicate with nodes at lower levels.

122

G. Cervera et al.

Nodes with more than one interface are selected as cluster heads. In Fig. 1, the notation used to name the clusters reflects the level of the cluster and the cluster head, e.g., C1.A means that the cluster is at level 1 and the cluster head is node A. A node with multiple interfaces is identified at every level with a different interface. For instance, in Fig. 1 node F has two interfaces and can communicate with nodes at levels 2 and 3. Then, F2 and F3 represent node F’s interfaces at level 2 and 3 respectively. Node B has three interfaces and establishes communication with nodes at levels 1, 2 and 3 through interfaces B1, B2 and B3 respectively. HOLSR allows formation of multiple clusters and, unlike OLSR, HOLSR nodes can exchange Hello and TC messages exclusively within each cluster. This constraint reduces the amount of traffic information broadcast to the entire ad hoc network.

Level 3 B3

F3

Cluster C3.B

Cluster C2.F

Level 2

F2

Cluster C2.B

D2 B2

G2 E2

A2

C2

Cluster C1.B B1

Cluster C1.D

6

11

A1 1 Cluster C1.A

2

C1

G1

10 9

5

3

Level 1

Cluster C1.G

D1

4

7

Cluster C1.C

8

E1 12 13 Cluster C1.D

Fig. 1. Example of a hierarchical architecture with heterogeneous nodes

3.1 Cluster Formation The topology control information is exchanged between clusters via specialized HOLSR nodes designed as cluster heads. The selection of cluster heads and classification of nodes according to their capabilities are defined at the startup of the HOLSR process. A cluster is formed by a group of mobile nodes -at the same hierarchical level- that have selected a common cluster head. Nodes can move from one cluster to another and associate to a new cluster head. Any node participating in multiple topology levels automatically becomes the cluster head of the lower-level cluster. In HOLSR, a cluster head declares its status and invites other nodes to join it by periodically sending out CID announcement messages. These messages are transmitted in the same packets together with Hello messages using a message grouping technique. This technique is implemented to reduce the number of packet transmissions. A CID message contains two fields:

Preventing the Cluster Formation Attack against the HOLSR Protocol

123

– cluster head: interface address of the originator of the message. – hop count: distance in hops to the cluster head generating the message. Once a node has joined a cluster head, it generates a new CID message inviting other nodes farther away to join the cluster. Any given node may receive two or more CID messages, indicating that it is located in the overlapping regions of multiple clusters. In such a case, the node joins whichever cluster is closer in terms of hop count. When a node receives messages from different cluster heads with the same hop count value, it joins the cluster head from which it received the first CID message. Fig. 2 shows the cluster formation process. Nodes A and B are cluster heads and generate CID messages (CIDA and CIDB respectively). The one-hop neighbor nodes join the originator of the message and generate a new message increasing by one the hop count field. Notice that node 2 receives CID messages from CHA and CHB with the same hop count value. In this case, node 2 chooses the cluster from which it has received the first message. In the same figure, node 9 joins cluster head A and generates a new CID message with hop count equal to four. Node 11 rejects that message because cluster head B is only three hops away. We refer to neighbor nodes in different clusters, such as nodes 9 and 11, as border nodes. Robustness is ensured thanks to a built-in diagnostic feature. Every node registers a timeout value for each CID message received. When a cluster head becomes inactive or moves away, then each neighbor node stops receiving CID messages. Eventually the CID message timeout expires and the CID information becomes invalid. Thus, each node starts to process new CID messages from other clusters and selects a new cluster head. For instance, in Fig. 2, assuming cluster head CHA went down, then all nodes attached to it will join cluster head CHB after receiving new CID messages from that cluster head. If no CID messages are received, then it means that the network is not partitioned in clusters anymore and behaves as the original OLSR protocol.

5

4

CIDB: 1 CIDA: 1

CIDB: 2 CIDA: 2

CIDA: 1

CIDA: 1

2

13

CIDB: 2

10

CIDA: 2

8 12

6

CID - Cluster ID advertisement

CIDB: 1

3

1

A

- CID Message

B

CIDA: 2

CIDB: 4 CIDA: 3

CIDB: 3 11

9

7

CIDA: 4

- Cluster Head

Fig. 2. CID messages

3.2 Cluster Head Message Exchange The hierarchical architecture must support the exchange of topology control information between clusters without introducing additional overhead. Thus, Hierarchical TC

124

G. Cervera et al.

(HTC) messages are generated by the cluster head and used to transmit the membership information of a cluster to higher level nodes. There are three basic types of HTC messages: – full membership: these messages are periodically transmitted by a cluster head to provide information about its cluster members, including any node in lower levels beneath it. – update: to provide information about cluster membership changes. The update HTC is used when a node leaves or joins a cluster. – request: request HTC messages are used when a packet loss has occurred. HTC message carries a sequence number field, which allows a node to request the retransmission of a full membership HTC message. HTC forwarding is enabled by the MPRs and restricted within a cluster. Nodes at the highest topology level have full knowledge of all nodes in the network and their routing tables are as large as they would be in an OLSR network. However, in lower levels, the size of the routing table of every node is restricted to the size of the cluster and it is smaller than in OLSR. For instance, in Fig. 1 the cluster head A generates an HTC message for the interface A2 (level 2) announcing that nodes 1, 2 and A1 are members of its cluster at level 1. The message is relayed to all nodes at the same level. Then, node B generates an HTC message for the interface B3 (level 3) advertising that nodes 1, 2, 3, 4, 5, 7, 8, A1, B1, C1 (at level 1) and A2, B2, C2, D2 (at level 2) are members of its cluster. Fig. 3 presents a summary of the messages implemented in HOLSR networks. Messages Hello TC CID HTC

Generated by Every node MPRs Cluster heads Cluster heads

Retransmitted by N/A MPRs N/A MPRs

Information reported One-hop neighbors MPR selectors A Cluster head Nodes within a cluster

Fig. 3. Summary of control traffic messages in HOLSR networks

3.3 Topology Control Propagation Nodes in each cluster select their MPRs to flood control traffic information. Control messages are generated and propagated exclusively within each cluster, unless a node is located in the overlapping zone of several clusters. For example, in Fig. 1 node 2 is within the border of cluster C1.A and may accept a TC or HTC message from node 3 located in cluster C1.B. However, node 2 retains the information without retransmitting it to its cluster. Thus, except for the border nodes, knowledge of nodes about the clusters is restricted to their own cluster. Data transfer between nodes in the same cluster is achieved directly via the information in the routing tables. However, when transmitting data to destinations outside the local scope of a cluster, the cluster heads is used as a gateway. When transmitting data between border nodes in different clusters at the same level, a different strategy might be used. In this situation, the cluster head is not used as

Preventing the Cluster Formation Attack against the HOLSR Protocol

125

a gateway to relay the information. Nearby nodes in different clusters at the same level can communicate directly without following the strict clustering hierarchy. This means that, data transfer between nodes is achieved following three different strategies: – communication between nodes in the same cluster is achieved via the routing information in their routing tables, – data transfer between nodes in different clusters is achieved through the cluster heads, but – if the nodes are neighboring nodes in different clusters at the same topology level, the cluster heads are not used and data packets are directly relayed. Therefore, HOLSR offers two main advantages (a) messages reflecting local movement are restricted to each cluster (thus, reducing the routing table computation overhead) and (b) an efficient use of high-capacity nodes without overloading them.

4 Cluster Formation Attack against the HOLSR Protocol 4.1 Adversary Model The flow of CID messages is an important vulnerability target. The hop count has to be updated every time a new message is retransmitted. Thus, a malicious node might alter this field to unsettle the cluster formation process. The attack, has a bigger impact when the malicious node drastically reduces the hop count field. This is because the receiver nodes accept the CID message with the lowest hop count value. Thus, when an attacker increases drastically the value, the receiver nodes automatically discard the altered message and accept the valid message from other nodes, as this is described in Section 3.1. If a node that generates a CID message reinitializes the value of the field hop count, the receiver nodes may join a farther cluster head and discard valid CID messages from closer cluster heads. Then, we only need to address the case when the hop count field is maliciously reduced. In general, if an attacker is at distance d (in hops) from a cluster head CHi , and generates a new CID message with hop count value j, the nodes with hop count greater or equal to j + d2 from the CHi are potentially affected. For instance, Fig. 4 (a) shows the correct propagation of CID messages. Fig. 4 (b) shows an example of the attack. In Fig. 4 (b), M1 is a malicious node at distance six hops from cluster head CHB . M1 receives CID messages from CHB and CHA , and generates a new CID message assigning an incorrect value to the field hop count, i.e., hop count is set to two. Thus, all nodes at distance greater or equal to four hops (nodes 2 and 3) process the message and incorrectly join CHA . Notice that the lowest value that can be used to reinitialize the field hop count is two because CID messages with field hop count equal to one are generated exclusively by the cluster heads. Additionally, we consider that the attacker only has one interface, it can not impersonate a cluster head and it only modifies the hop count value. In the following section, we present our proposed solution to handle this problem.

126

G. Cervera et al.

5 Handling the Attack with the Use of Hash Chains We describe in this section a security improvement over HOLSR based on the use of hash chains [13]. Authentication and integrity is achieved by using hash key chains. For instance, in [10], Lamport proposes a method of user password authentication based on a secure one-way hash function. We do not attempt to address authentication, but the integrity of the messages. A one-way hash chain is based on a one-way hash function h that is applied n times to a unique value x. Hash functions are relatively easy to compute and can be applied to a block of data of any size. A hash function can be applied to a block of data of any size and produce a fixedlength output. According to [13], a strong one-way hash function h must have the following properties: 1. The one-way property implies that for any given value h(x), it is infeasible to find the value of x. 2. The weak collision resistance property implies that for any given block x, it is computationally infeasible to find y = x such that h(x) = h(y). 3. The strong collision resistance property implies that it is computationally infeasible to find a pair (x, y) such that h(x) = h(y). These properties are explained in detail in [13]. Our scheme prevents the attack presented in Section 4 while avoiding the use of computationally expensive cryptographic operations. We use the following notation: – sj : is a random value (i.e., a nonce) generated and known exclusively by the cluster head CHj . – h(x): is a strong one-way hash function applied to x. – hn (x): is a hash chain constructed by applying n times the hash function h to x, hn (x) = h(...h(h(x))). – t: is the maximum number of times that a hash function is applied to x. – M axj : is the value obtained by applying t times the hash function to a nonce sj , M axj = ht (sj ). – i: is the distance in hops between the receiver and a cluster head. CIDA: 1

CIDA: 2

CIDA: 6

CHA

1

CHB

3

2 CIDB: 6

CIDB: 5

CIDB: 4

CIDB: 3

CIDB: 2

CIDB: 1

CIDB: 3

CIDB: 2

CIDB: 1

a) Correct CID message propagation.

CIDA: 1

CHA

CIDA: 2

CIDA: 6

CIDA: 2

M1

CIDA: 3

2

CIDA: 4

CHB

3 CIDB: 4

b) Incorrect CID message propagation, decreasing the hop count value. - Cluster Head - Incorrect CID Message

Fig. 4. CID messages

Preventing the Cluster Formation Attack against the HOLSR Protocol

127

Consider that the hash function h(x) and the value of t are known by all nodes in the network. For our purposes, we suppose that the malicious attacker is not able of generating a valid nonce sj . Algorithm H ASH -C HAINED _CID_D ISSEMINATION (henceforth HCCD for brevity) formalizes our proposal.

A LGORITHM : HCCD A cluster head (CHj ) generates a random number sj , i.e., a nonce. CHj sets the field i = 1. CHj calculates the value M axj = ht (sj ). CHj generates the CID message:< M axj , hi (sj ), i >. The receiver node verifies that the sender node is i-hops away by applying the following criteria: – If M axj = ht−i (hi (sj )), then the CID message is valid. – Else, the receiver node discards the CID message. 6. If the CID message is valid, then the receiver node generates a new CID message with the hop count increased by one and applying the hash function to hi (sj ): < M axj , h(hi (sj )), i + 1 >. 1. 2. 3. 4. 5.

Algorithm HCCD works as follows: firstly, a valid cluster head (CHj ) generates a random number sj , i.e., a nonce that is only known by the originator of the message. Then, it initializes the hop count field i equal to one and computes the M axj value by applying t times the hash function h(x) to the nonce sj , such as M axj is equal to ht (sj ). We assume that M axj and the value of t are known by all the nodes in the network during the execution of the protocol. Additionally, CHj applies i times the hash function to sj , to obtain hi (sj ). Then, CHj generates a CID message with the fields: < M axj , hi (sj ), i >. The receiver node verifies that the CID message is valid by applying t−i times the hash function to hi (sj ) and comparing the result with M axj . Therefore, if M axj is equal to ht−i (hi (sj )), then the hop count value i has not been altered and the received CID message is valid. Finally, the receiver node joins CHj until it receives a CID message from a different cluster head with a lower hop count value. In the mean time, the receiver node generates periodically CID messages announcing its cluster head and the hop count distance to reach it, i.e., < M axj , h(hi (sj )), i + 1 >. Theorem 1. Given a HOLSR network applying the algorithm HCCD for the dissemination of CID messages, such that malicious nodes in the network are not able of generating a valid nonce s, h is a strong one-way hash function, i is the distance in hops to reach a cluster head j and M axj is a value obtained by applying t times h to the nonce sj . Then algorithm HCCD guarantees that a malicious node cannot generate a valid CID message with a hop count value k = i, such that M axj = ht−k (hi (sj )). Proof. According to algorithm HCCD , M axj = ht (sj ) and a CID message is valid if M axj = ht−i (hi (sj )). Then, let us assume that there exists a value k = i such that M axj = ht−k (hi (sj )). Thus, ht (sj ) = ht−k (hi (sj )). Then, function h does not

128

G. Cervera et al.

(a) σ ≤ 5

(b) 5 < σ ≤ 7

(c) 7 < σ ≤ 10

(d) 10 < σ

Fig. 5. Standard deviation of the average number of nodes per cluster testing different HOLSR networks with up to five malicious nodes and applying algorithm HCCD

meet the weak collision resistance property of strong one-way hash functions due to ht−k (hi (sj )) and ht−i (hi (sj )) are both equal to M axj . Therefore, ht (sj ) is equal to ht−k (hi (sj )) only if k is equal to i.

6 Results and Simulations Setup In this section, we describe the experiments and results after assessing the effectiveness of our proposed countermeasure to the cluster formation attack presented in Section 4. We conducted our experiments using the NS-3 simulator [5], version 3.9. We modified the original OLSR code developed by Ros and Carneiro to implement the hierarchical approach (i.e., HOLSR), attack, and countermeasure described in Section 5. We tested our algorithm in an HOLSR network with two levels, 200 nodes in the first level with only one interface and four nodes with up to two interfaces (i.e., cluster heads). The transmission range for nodes in the first level and second level is 120 m and 500 m respectively. Nodes at the first level are placed following a uniform distribution in an area of 1000 m by 1000 m. We assume that the administrator of the network can decide the best criteria to distribute the cluster heads. Thus, we divide our scenario in four quadrants and place a cluster head in the center of each of them. We also assume that the malicious node knows the position of the cluster heads and sets itself in the border

Preventing the Cluster Formation Attack against the HOLSR Protocol

129

of two different clusters to maximize the impact of an attack. We also assume that the malicious nodes do not collude to perform an attack, no data traffic is generated and all the scenarios are static. In an ideal scenario, the number of nodes per cluster must be equally balanced. However, due to the position of the nodes in the network this is not always possible. Additionally, the presence of misbehaving nodes may disproportionately increase the imbalance of the number of nodes per cluster. We compute the average of the standard deviation of the number of nodes per cluster with up to five malicious nodes launching the cluster formation attack. Then, we compare the average of the standard deviation of the number of nodes per cluster on a series of simulated HOLSR networks without protection and the average of the standard deviation of the number of nodes per cluster but applying algorithm HCCD . We use the standard deviation (σ) as a measure of

¯ 2 (x −X)

j dispersion. The standard deviation is computed with the formula: σ = NCH and expressed in the same units as the data, where xj is equal to the number of nodes in ¯ is the average of nodes per cluster, i.e., total number of nodes (n) over the cluster j, X In our experiments, the standard deviation formula can the number of clusters (NCH ).

2

(xi −50) be simplified as follows: σ = . Fig. 5 shows how the CID attack affects 4 the average of the standard deviation of 100 experiments with different topologies and 90% confidence interval. To present our results, we consider two factors that affect the distribution of nodes per cluster: the network topology and the presence of malicious nodes. Thus, Fig. 5(a) shows the experiments where σ ≤ 5, this means that the distribution of nodes per cluster in the network is relatively balanced when there is no malicious nodes. Fig. 5(b) shows the experiments where the distribution of nodes per cluster is less balanced due to the network topology, i.e., 5 < σ ≤ 7, Fig. 5(c) shows the experiments where 7 < σ ≤ 10, and Fig. 5(d) shows the experiments where 10 < σ. In each case, the first column shows the average of the standard deviation with malicious nodes and implementing algorithm HCCD . Therefore, the distribution of the nodes per cluster is affected only by the network topology. The second column represents the average of the standard deviation with malicious nodes but without applying our algorithm. Notice that the average of the standard deviation and size of the confidence interval increase because the number of nodes per cluster is less balanced due to the network topology plus the effect of the attack.

7 Related Work In this paper, we reviewed the cluster formation phase in HOLSR networks, however other hierarchical approaches based on the OLSR protocol are also vulnerable during the cluster formation stage, for instance: cluster OLSR (C-OLSR) [12] proposed by Ros et al. assumes that a cluster formation mechanism has been executed, nevertheless any security measures during this stage are proposed. The Multi-level OLSR Routing using the Host and Network Association (HNA) messages Extension (MORHE) [15] presented by Voorhean et al. does not specify any secure cluster formation mechanism therefore like C-OLSR, the cluster formation stage is vulnerable to malicious attacks.

130

G. Cervera et al.

A tree-based logical topology [3,2] to provide hierarchical routing is presented by Baccelli, this approach implements Branch messages to form and maintain a tree-based structure. With a Branch message a node specifies information such as its identity (the NodeID field), the tree where it belongs to (the TreeID field) and its parent in the tree (the ParentID field). Additionally, the Depth field indicates the distance of the node to the root. This approach does not propose any security measure to protect the integrity of Branch messages, so an attacker can easily alter the value of the Depth field in Branch messages. A hierarchical approach similar to HOLSR which uses HNA messages instead of HTC messages for inter-cluster communication is proposed by Arce et al. in [1]. Like HOLSR, cluster heads are predefined then is not necessary a cluster head selection algorithm, however a cluster formation mechanism is needed. Therefore, any strategy that uses the distance in hops as the main parameter to invite other nodes to join a particular cluster head will be affected by the attack presented in this paper. In [6], Hong et al., present a solution to secure OLSR (SOLSR). Authors present a wormhole detective mechanism and authentication to strengthen the neighbor relationship establishment. Thus, they use digital signature to ensure the non-mutable fields and hash chains to secure Hop Count and TTL fields. Their solution is similar to our proposed algorithm, however it is implemented in flat OLSR to protect only standard control traffic messages. Kush and Hwang, present in [9] a mechanism based in hash chains to secure AODV. Then Hashing is done for route request and reply messages to achieve complete security in terms of availability, integrity and authentication, minimal overhead, network performance in terms of throughput and node mobility. Similarly, Hu et al., [7] propose a hashing mechanism to secure distance vector routing protocols.

8 Conclusion HOLSR has been designed to improve scalability in MANETs. However, the protocol has been designed without security countermeasures. In this paper, we propose a method to protect the cluster formation stage in HOLSR networks. Our mechanism prevents an attacker from maliciously altering the hop count field in CID messages. Thus, we present an algorithm based on hash chains that allows to detect and discard invalid CID messages. Our experiments show that the distribution of nodes is less balanced when the hop count in CID messages is maliciously altered. We also show that we can prevent this kind of attacks by applying our proposed algorithm. Notice that our mechanism, can be also applied in other hierarchical routing protocols for MANETs that utilize mutable information such as the hop count or TTL fields to organize the network in clusters. Acknowledgments. The authors graciously acknowledge the financial support received from the following organizations: Natural Sciences and Engineering Research Council of Canada (NSERC), Mathematics of Information Technology and Complex Systems (MITACS), Institut Telecom, Spanish Ministry of Science and Innovation (grants TSI2007-65406-C03-03 E-AEGIS and CONSOLIDER-INGENIO CSD200700004 ARES), National Council of Science and Technology (CONACYT), and Ministry of Education of Mexico (SEP, Program for Academic Improvement).

Preventing the Cluster Formation Attack against the HOLSR Protocol

131

References 1. Arce, P., Guerri, J.C., Pajares, A., Lázaro, O.: Performance evaluation of video streaming over ad hoc networks using flat and hierarchical routing protocols. Mobile Networks and Applications 13(3-4), 324–336 (2008) 2. Baccelli, E.: OLSR scaling with hierarchical routing and dynamic tree clustering. In: IASTED International Conference on Networks and Communication Systems (NCS), Chiang Mai, Thailand (March 2006) 3. Baccelli, E.: OLSR Trees: A Simple Clustering Mechanism for OLSR. In: Al Agha, K., Guérin Lassous, I., Pujolle, G. (eds.) Challenges in Ad Hoc Networking. IFIP, vol. 197, pp. 265–274. Springer, Boston (2006) 4. Clausen, T., Jacquet, P.: Optimized link state routing protocol (OLSR), RFC3626. IETF Internet Draft (October 2003), http://www.ietf.org/rfc/rfc3626.txt 5. Henderson, T., et al.: The NS-3 network simulator (2011) Software package retrieved from, http://www.nsnam.org/ 6. Hong, F., Hong, L., Fu, C.: Secure OLSR. In: International Conference on Advanced Information Networking and Applications, vol. 1, pp. 713–718 (2005) 7. Hu, Y.-C., Johnson, D.B., Perrig, A.: Sead: secure efficient distance vector routing for mobile wireless ad hoc networks. Ad Hoc Networks 1(1), 175–192 (2003) 8. Jacquet, P., Muhlethaler, P., Clausen, T., Laouiti, A., Qayyum, A., Viennot, L.: Optimized link state routing protocol for ad hoc networks. In: Proceedings of IEEE International Multi Topic Conference, IEEE INMIC 2001. Technology for the 21st Century, pp. 62–68. Lahore University of Management Sciences, Pakistan (2001) 9. Kush, A., Hwang, C.: Proposed protocol for hash-secured routing in ad hoc networks. Masaum Journal of Computing (MJC) 1, 221–226 (2009) ISSN 2076-0833 10. Lamport, L.: Password authentication with insecure communication. Commun. ACM 24, 770–772 (1981) 11. Palma, D., Curado, M.: Inside-Out OLSR Scalability Analysis. In: Ruiz, P.M., GarciaLuna-Aceves, J.J. (eds.) ADHOC-NOW 2009. LNCS, vol. 5793, pp. 354–359. Springer, Heidelberg (2009) 12. Ros, F.J., Ruiz, P.M.: Cluster-based OLSR extensions to reduce control overhead in mobile ad hoc networks. In: Proceedings of the 2007 International Conference on Wireless Communications and Mobile Computing, pp. 202–207. ACM (2007) 13. Stallings, W.: Cryptography and Network Security, Principles and Practices. Pearson Prentice Hall (2006) 14. Villasenor-Gonzalez, L., Ge, Y., Lamont, L.: HOLSR: A hierarchical proactive routing mechanism for mobile ad hoc networks. IEEE Communications Magazine 43(7), 118–125 (2005) 15. Voorhaen, M., Van de Velde, E., Blondia, C.: MORHE: A Transparent Multi-Level Routing Scheme for Ad Hoc Networks. In: Al Agha, K., Guérin Lassous, I., Pujolle, G. (eds.) Challenges in Ad Hoc Networking. IFIP, vol. 197, pp. 139–148. Springer, Boston (2006)

Secret Key Establishment over Noisy Channels Hadi Ahmadi and Reihaneh Safavi-Naini Department of Computer Science, University of Calgary, Canada {hahmadi,rei}@ucalgary.ca

Abstract. This paper provides a reﬂective overview of the research published in [3, 4], which introduces a new realistic scenario for information theoretically secure key establishment. The scenario is when two parties are communicating over “noisy” channels that are eavesdropped by other parties in the environment. We deﬁne the secret key capacity as the highest achievable secret key rate, i.e., the highest number of secret key bits that the two parties can share on average per use of the channel. We study the above problem in two settings when the two parties have, or do not have, access to sources of local randomness. In each case, we derive lower and upper bounds on the SK capacity and derive the capacity for special cases. We also compare the bounds in the two settings and discuss the role of local randomness in increasing key rate.

1

Introduction

In cryptography it is traditionally assumed that communication channels are error-free. A basic security requirement is protection of communicated messages from a sender, Alice, to a receiver, Bob, over error free channels that are public and can be eavesdropped by an adversary, Eve; we refer to this problem as secure message transmission (SMT). In SMT, a plaintext message is converted into a ciphertext via an encryption algorithm that uses a cryptographic key. The security of the ciphertext requires that it does not reveal information about the message. The strictest notion of security is information theoretic security, where no limits on the computation power of the adversary are assumed. In his seminal paper [11], Shannon proposed the ﬁrst formal treatment of information theoretic SMT over error-free public channels. He proved that to provide perfect secrecy in this model, Alice and Bob must share a secret key with entropy at least equal to the message entropy and so for a full entropy message source, the key length must be at least equal to the message length. This result is particularly disappointing because, in the information theoretic setting and without making extra assumptions (such as prior correlated information), it is impossible to establish secure shared keys by communication over public channels [9]. In a second seminal paper [12], Wyner proposed wiretap channel as an alternative model for SMT in information-theoretic setting. This approach takes advantage of channel noise and does not require Alice and Bob to have prior shared keys. The model was generalized by Csisz´ar and K¨ orner [5] to discrete memoryless broadcast channel (DMBC) in which a message sent by Alice is received in noisy forms by Bob and Eve. Their results showed that SMT is possible J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 132–147, 2012. c Springer-Verlag Berlin Heidelberg 2012

Secret Key Establishment over Noisy Channels

133

if and only if Bob can receive a less noisy version [8] than what Eve receives. Performance of a SMT protocol is measured by its secrecy rate which is the average number of message bits it transmits securely per channel use. The secrecy capacity of a DMBC is the highest secrecy rate achievable over all protocols. In real life, all communication channels are inherently noisy and reliable communication is made possible by using layers of channel coding to remove noise from the communication. One can look at the above two approaches to SMT with perfect secrecy as implementing security at two diﬀerent layers of a multilayer network architecture. Reliable communication is always implemented at the physical layer (lower layer) of the network stack, making it possible to assume error-free channels for higher layers. Traditional cryptography considers security in the upper layers of the network; hence, it assumes existence of errorfree channels. The noisy channel paradigm, on the other hand, considers message reliability and security as two properties that can be achieved simultaneously at the physical layer. Surprisingly with this new paradigm, keyless (informationtheoretic) SMT becomes possible in interesting scenarios [5, 12]. Maurer [9] and independently Ahlswede and Csisz´ar [1] considered the problem of secret key establishment (SKE) in which the goal is to establish a shared key that is completely unknown Eve. Alice and Bob have access to a DMBC and a public channel. This latter channel is noise-free, authentic, but insecure. Similar to SMT protocols, performance of a SKE protocol is measured in terms of secret key (SK) rate which is the average number of secure key bits established by the protocol per single transmission over the DMBC. The secret key (SK) capacity is the highest secure key rate over all SKE protocols. An immediate solution to this problem, assuming Alice can generate random bits locally, is for Alice to generate a random key and send it securely to Bob. The lower and upper bounds on the SK capacity, proved in [1, 9], however, show that by allowing Alice and Bob to use the public channel, the achievable SK rates can substantially increase; more interestingly, Alice and Bob are able establish keys in some cases even when the secrecy capacity of the DMBC is zero. SKE in information theoretic setting has been widely studied in recent years and scenarios where Alice and Bob have access to other resources such as correlated randomness [7, 10] or secure feedback [2] are considered. In this paper, we focus on SKE in a very basic setting where Alice and Bob can send messages to each other over noisy channels that are eavesdropped. Alice and Bob may or may not have local sources of randomness. This is the scenario that models for instance two devices that are communicating in a wireless environment and their communication is intercepted by other devices in the neighborhood. 1.1

SKE with Local Randomness

We ﬁrst consider SKE using a pair of discrete memoryless broadcast channels (2DMBC) when the parties have access to local sources of independent randomness. We deﬁne the SK rate of an SKE protocol as the number of random key bits generated at the end of the protocol, divided by the total number of times that the channels are used. Compared to the public channel setting in [1,9], this

134

H. Ahmadi and R. Safavi-Naini

is a more realistic measure of SK rate in wireless scenarios where transmission of a symbol consumes battery power. Note that the SK rate in the public channel setting does not consider the cost of transmission over public discussion channel, whereas in practice the SK rates will be lower. The ability of interactive communication in the 2DMBC setup is crucial in the sense that it allows Alice and Bob to try multi-round SKE protocols to improve their key rate. While this advantage is also oﬀered in the “public channel” setting, an important diﬀerence of the two models is that, in 2DMBC, parties can beneﬁt from channel noise in both directions using the two DMBCs. SKE over a 2DMBC can be approached by taking advantage of existing solutions to a number of related problems. Here, we study two widely known problems, namely (i) SMT over one-way DMBC and (ii) SKE over one-way DMBC with a public channel. Each of these approaches result in a lower bound on the SK capacity of the 2DMBC setup. We also provide a third lower bound by proposing a new two-round SKE protocol that uses a two-level coding method. We compare the three lower bounds and show that our lower bound is tighter than the other two, and this is because the two-round SKE construction is the only approach that allows to use channel noise in both DMBCs for the purpose of SKE. (In the ﬁrst arXiv version of [3] we also discussed a fourth lower bound considering the setup in [7, 10] that assumes communicants have access to prior correlated variable. The bound using the new two round protocol, matches this forth lower bound. In this paper, we only consider setups that use (noisy or public) channels as resource.) We also obtain an upper bound on the SK capacity by bounding the highest key rate that any multi-round SKE protocol can possibly achieve. The upper bound is shown not to be tight in general; however, it matches all three lower bounds (above) when each DMBC is physically degraded, i.e., when Eve receives is degraded version of what the legitimate users receive.

1.2

SKE without Local Randomness

In all above studies on the SKE protocols and the SK capacity, it is assumed that Alice and Bob have access to a local source of perfect randomness and this access is free, i.e., the amount of randomness which is be used is not counted. A natural question is whether SKE in 2DMBC setup is possible if there is no such local sources. This setting is particularly meaningful noting that generation of perfect randomness in general is costly and requires special hardware and/or software processes that may not be aﬀorded in many cases, including when Alice and Bob are using small battery powered devices. We start our investigation by showing simple cases of 2DMBC where SKE without local randomness is impossible. This includes the case where the two DMBCs are noise-free (even if the adversary is computationally bounded). We furthermore show that the two above approaches to SKE (one DMBC with/without a public channel) which were discussed in the previous section do not give any positive rate for secret key. We however prove that, SKE is

Secret Key Establishment over Noisy Channels

135

possible when Alice and Bob start with constant strings (for example pre-stored IDs) by “distilling” randomness from channel noise through communication. In the ﬁnal part of this paper, we study the role of local randomness in secret key establishment by comparing the lower and upper bounds on the SK capacity obtained in the two settings, namely with and without local randomness, assuming the DMBCs consist of two independent binary symmetric channels. The results show a drastic decrease in the lower bound when local randomness is removed. We however did not observe a big gap between the two upper bounds. This implies more uncertainty about the SK capacity (gap between the two bounds) when local randomness does not exists. 1.3

Notation

We use calligraphic letters (X ), uppercase letters (X), and lowercase letters (x) to denote ﬁnite alphabets, random variables, and their realizations over sets, respectively. X n is the set of all sequences of length n (so called n-sequences) with elements from X . X n = (X1 , X2 , . . . , Xn ) ∈ X n denotes a random nsequence in X n . For the random variables X, Y , and Z, we use X ↔ Y ↔ Z to denote a Markov chain between them in the given order which implies PY Z|X = PY |X PZ|Y . For a value x, we let [x]+ = max{0, x} and for 0 ≤ (x, y) ≤ 1, we deﬁne x y = x+ y − 2xy. Eventually, h(x) = −x log x− (1 − x) log(1 − x) denotes the binary entropy function. 1.4

Paper Structure

Section 2 describes the problem of SKE, the 2DMBC setup, and the SK capacity. In section 3, we discuss our results on SKE using local randomness, and in Section 4, we study the problem when local randomness does not exist. We compare the ﬁnal results in the two settings by applying them to binary symmetric channels in Section 5 and conclude the paper in Section 6.

2

Description of SKE in the 2DMBC Setup

A Discrete Memoryless Broadcast Channel (DMBC) (X , Y, Z, PY Z|X ) is a channel that, for an input symbol X ∈ X , returns two output symbols Y ∈ Y and Z ∈ Z according to the distribution PY Z|X and independently of other symbols. In the 2DMBC setup, there exists a forward DMBC from Alice to Bob and Eve, denoted by (Xf , Yf , Zf , PYf ,Zf |Xf ), and a backward DMBC from Bob to Alice and Eve, denoted by (Xb , Yb , Zb , PYb Zb |Xb ). See Fig. 1(a). To establish a secret key, Alice and Bob follow a (possibly multi-round) SKE protocol that is public. A SKE protocol works in general as follows. In each communication round, either Alice or Bob sends a sequence of symbols over their DMBC, and the other party and Eve receive noisy versions of it. This sequence is calculated as a function of the previously communicated (sent and/or received) sequences. Note that the above function can be randomized provided

136

H. Ahmadi and R. Safavi-Naini

Xf

Alice Yb

Yf

Forward DMBC

PYf Z f |X f Zb

Eve

Zf

Backward DMBC

PYbZb| Xb

(a) General 2DMBC

Bob

Xf

Alice Xb

Yf

BSC p1 BSC p2

Zb Eve Zf

Yb

BSC p2 BSC p1

Bob Xb

(b) 2DMBC with independent BSCs

Fig. 1. The 2DMBC setup (a) in general and (b) with independent BSCs

that Alice and Bob have access to sources of randomness; otherwise, it must be deterministic. At the end of the last communication round, Alice, Bob, and Eve each will have collected a set of communicated sequences which form their “view”s of the protocol. Using their views, Alice and Bob calculate SA ∈ S and SB ∈ S as their shared secret key, respectively. A secure SKE protocol is formally deﬁned as follows. Definition 1. For Rsk ≥ 0 and δ ≥ 0, the SKE protocol Π is (Rsk , δ)-secure if there exists a random variable S ∈ S such that the following conditions hold: Randomness:

H(S) ≥ Rsk − δ, n

(1a)

Reliability:

Pr(SA = SB = S) ≥ 1 − δ,

(1b)

Secrecy:

H(S|V iewE ) ≥ 1 − δ, H(S)

(1c)

where n is the number of channel uses and V iewE is Eve’s view of the protocol. We say that a SK rate Rsk is “achievable” if for any arbitrarily small δ > 0, there exists an (Rsk , δ)-secure SKE protocol. This lets us deﬁne the SK capacity of a 2DMBC as the highest achievable SK rate. Definition 2. The Secret Key (SK) capacity is the largest Rsk ≥ 0 such that, for any arbitrarily small δ > 0, there exists an (Rsk , δ)-secure SKE protocol.

3

SKE over 2DMBC with Local Randomness

In this section, we study SKE using a 2DMBC in a setting that local randomness is unlimitedly available to all the parties, so Alice and Bob can apply any randomized function during SKE with no limit on the amount of randomness and without counting this as part of calculating the SK rate. We denote by 2DMBC+r the SK capacity in the 2DMBC setup with local randomness. We Csk prove lower and upper bounds on this capacity.

Secret Key Establishment over Noisy Channels

3.1

137

SK Capacity: Lower Bound

Although the 2DMBC setup for SKE is a new setting, SKE results in previous setups can be used to obtain a SKE protocol over 2DMBC. Here, we focus on two well-studied settings. Using One-Way DMBC: One approach to establish a shared key over 2DMBC is that either Alice or Bob chooses a random secret key and sends it in a secure and reliable way over their corresponding DMBC. This approach uses only one of the DMBCs for the purpose of SKE, and of course it chooses the DMBC using which the sender can send higher number of key bits on average per channel use, i.e., the DMBC with the higher secrecy capacity. Csisz´ar and K¨ orner [5] proved that the secrecy capacity of the DMBC (X , Y, Z, PY Z|X ) is at least max{[I(X; Y ) − I(X; Z)]} PX

(2)

The highest achievable key rate by the ﬁrst approach is equal to the maximum of the secrecy capacities of the forward and the backward DMBCs. This proves

2DM BC+r BC+r BC+r BC+r Csk ≥ LDM = max{LDM , LDM }, where sk sk,A sk,B BC+r LDM sk,A BC+r LDM sk,B

(3)

= maxPXf [I(Xf ; Yf ) − I(Xf ; Zf )] ,

(4)

= maxPXb [I(Xb ; Yb ) − I(Xb ; Zb )] .

(5)

Using One-Way DMBC and Public Channel: A second approach is to realize the setting of one-way DMBC and public channel, independently studied by Maurer [9], and Ahlswede and Csisz´ar [1]. Here, realizing the public channel is attained by using channel coding techniques for reliable transmission over noisy channels. The results in [1,9] show the following lower bound on the SK capacity when the DMBC is denoted by (X , Y, Z, PY Z|X ): max{[I(X; Y ) − I(X; Z)], [I(X; Y ) − I(Y ; Z)]}. PX

(6)

The ﬁrst term above is achieved by only using the DMBC and so it follows from (2). The second term results from a two-round protocol that uses the DMBC in the ﬁrst round and the public channel in the backward (Bob-to-Alice) direction in the second round. The calculation of the above lower bound [1, 9] does not count the public channel usage as part of the communication cost. In the 2MDBC setup however, which is closer to the real-life scenario, sending over the public channel incurs cost that needs to taken into account. Since the ﬁrst term above is obtained without using the public channel, we only consider the second term. Let’s assume that each time the public channel is used it can transmit R bits reliably. In Maurer’s proof [9] of (6), for each symbol Y received by Bob from the DMBC, one symbol from the same set should be sent over the public channel; hence, the number of times that the public channel is used per DMBC use is at least ζ ≥ log |Y|/R. This lets us replace the above lower bound by, max{[I(X; Y ) − I(X; Z)], ζ,PX

[I(X; Y ) − I(Y ; Z)] s.t. log |Y| ≤ ζR}. 1+ζ

(7)

138

H. Ahmadi and R. Safavi-Naini

For this second term, Ahlswede and Csisz´ ar’s proof [1] gives a better bound. It argues that Alice’s uncertainty about the DMBC output Y in the ﬁrst round is resolved by Bob sending backward H(Y |X) bits of “helping” information over the public channel in the second round. The number of public channel uses, per DMBC use, is at least ζ ≥ H(Y |X)R. This implies a tighter bound: max{[I(X; Y ) − I(X; Z)], ζ,PX

[I(X; Y ) − I(Y ; Z)] s.t. H(Y |X) ≤ ζR}. 1+ζ

(8)

Given the 2DMBC (Xf , Yf , Zf , PYf Zf |Xf ) and (Xb , Yb , Zb , PYb Zb |Xb ), one DMBC can be used as is, while the other can be used to realize a public channel in the opposite direction. The rate limit for a DMBC (used as a public channel) equals its capacity for reliable transmission, i.e., R = maxpx I(X; Y ). We have the following lower bound on the SK capacity:

2DMBC+r C+r C+r C+r ≥ LDMBC+P = max{LDMBC+P , LDMBC+P }, Csk sk sk,A sk,B

(9)

where C+r LDMBC+P = sk,A

C+r = LDMBC+P sk,B

max

ζ,PXf ,PXb

max

ζ,PXf ,PXb

{[I(Xf ; Yf ) − I(Xf ; Zf )],

[I(Xf ; Yf ) − I(Yf ; Zf )] 1+ζ

s.t. H(Xf |Yf ) ≤ ζ.I(Xb ; Yb )}, (10) [I(Xb ; Yb ) − I(Yb ; Zb )] {[I(Xb ; Yb ) − I(Xb ; Zb )], 1+ζ s.t. H(Xb |Yb ) ≤ ζ.I(Xf ; Yf )}.

(11)

Intuitively, the second approach to SKE can lead to higher key rates. While the former approach suggests using only one DMBC, the latter may beneﬁt from both channels at the same time. Comparing(3) with (9) also approves this: C+r LDMBC+P ≥ LDMBC+r . sk sk

(12)

Using Both DMBCs: Although using a public channel together with a DMBC can oﬀer higher SK rates, it is not always the best approach. Once channel noise is viewed as a resource for cryptography, removing it via error-correcting codes may decrease the capability in the setup for SKE. Relying on this observation, in [3], we derived a tighter lower bound on the SK capacity. The lower bound is achieved by a protocol that takes advantage of noise in both DMBCs, if applicable. Theorem 1. The SK capacity of 2DMBC is lower bounded as [3, Appendix A]

2DM BC+r BC+r BC+r BC+r Csk ≥ L2DM = max{L2DM , L2DM }, where sk sk,A sk,B BC+r L2DM = sk,A

max

ζ,PX ,PX f

[

b

[I(Xf ; Yf ) − I(Yf ; Zf )] + ζ[I(Xb ; Yb ) − I(Xb ; Zb )]+ 1+ζ s. t. H(Yf |Xf ) ≤ ζI(Xb ; Yb )}],

BC+r = L2DM sk,B

max

ζ,PX ,PX f b

[

(13)

(14)

[I(Xb ; Yb ) − I(Yb ; Zb )] + ζ[I(Xf ; Yf ) − I(Xf ; Zf )]+ 1+ζ s. t. H(Yb |Xb ) ≤ ζI(Xf ; Yf )}].

(15)

Secret Key Establishment over Noisy Channels

139

The lower bound (13) is obtained by a two-round protocol, initiated by either Alice or Bob: The SK rate (14) is achieved when Alice starts the protocol and (15) is obtained by Bob initiating it. We explain (14) while (15)can be exis the weighted average over plained in a similar way. The key rate L2DMBC+r sk,A two terms (each in square bracket). The second term simply shows the secrecy capacity of the backward channel, derived in second round of communication. The ﬁrst term, however, is the potential in the forward channel that can be extracted through interaction, assuming Alice is the initiator. This term also appears in (10) where Alice and Bob can interact over public channel. Here, the backward channel serves two purposes: helping with the potential in the forward channel and contributing to the key through its secrecy capacity. The parameter ζ controls the ratio of channel uses in the second round to that of the ﬁrst round. The condition on the average is analogous to the condition in (10) for the public channel setting. Comparing the Lower Bounds: We show that the lower bound (13) is always greater or equal to (9). For this, we need to argue that it is greater or equal to both (10) and (11). We do this for the former and the latter follows. By choosing ζ suﬃciently large in (15), we obtain that ≥ max [I(Xf ; Yf ) − I(Yf ; Zf )]. L2DMBC+r sk,B PXf ,PXb

Furthermore, since [I(Xf ; Yf ) − I(Yf ; Zf )]+ ≥ 0, we have from (14) that ≥ L2DMBC+r sk,A

max

ζ,PXf ,PXb

{

[I(Xf ; Yf ) − I(Yf ; Zf )] s.t. H(Xf |Yf ) ≤ ζ.I(Xb ; Yb )}. 1+ζ

Combing these two gives 2DMBC+r C+r = max{Lsk,A , L2DMBC+r } ≥ LDMBC+P . L2DMBC+r sk sk,B sk,A

and similarly, we have 2DMBC+r C+r ≥ LDMBC+P , Lsk sk,B

which shows the claim. To better see the diﬀerence between the three lower bounds above, we apply them to the special case of 2DMBC with binary symmetric broadcast channels (BSBCs), i.e, when it consists of four independent binary symmetric channels as illustrated in Fig. 1(b). We assume the main channels from Alice to Bob and vice versa have bit error probability p1 , and Eve’s both channels have bit error probability p2 . We refer to this special case as 2BSBC. For this case, we ﬁrst simplify the three obtained lower bound expressions. = [h(p2 ) − h(p1 )]+ , LBSBC+r sk

C+r = max{[h(p2 ) − h(p1 )]+ , (1 − h(p1 ))(h(p1 LBSBC+P sk 2BSBC+r Lsk = h(p1 )[h(p2 ) − h(p1 )]+ + (1 − h(p1 ))(h(p1

(16) p2 ) − h(p1 ))},(17) p2 ) − h(p1 )). (18)

140

H. Ahmadi and R. Safavi-Naini

sk

Lower bounds on C2BSBC

1 0.9

LDMBC+r

0.8

L

0.7

L

DMBC+PC+r 2DMBC+r

0.6 0.5 0.4 0.3 0.2 0.1 0 0

0.1

0.2

0.3

0.4

Eve’s channel bit error probability (p2)

0.5

Fig. 2. The comparison of the lower bounds with respect to p2 when p1 = 0.1

Fig. 2 graphs the three lower bounds with respect to Eve’s channel error probability 0 ≤ p2 ≤ 0.5, when p1 = 0.1. This graph shows that our lower bound is always superior than the other two based on results over previous setups. When the main channel is noisier that Eve’s channel (p2 ≤ p1 ), using only one DMBC cannot result in any shared key; however, the public channel approach gives positive SK rates. This is the interesting outcome of Maurer’s and Ahlswede and Csisz´ar’s work. Furthermore, the lower bound from this approach matches our lower bound and this is because, under the above condition, our SKE protocol also chooses to realize a public channel from one DMBC. The diﬀerence between our lower bound and that of the public channel approach appears when p2 > p1 : this shows that in this case, converting a DMBC (with positive secrecy capacity) to a public channel is not the optimal choice. When p2 is “suﬃciently” larger than p1 , the public channel approach cannot do better than using one DMBC (the ﬁrst approach). Moreover, the three bounds converge when p2 = 0.5; i.e., when there is no leakage to the adversary all approaches choose to use only one round of communication over a single DMBC. 3.2

SK Capacity: Upper Bound

While the lower bound in Theorem 1 is achieved by a two round protocol, a general key establishment protocol may consist of many rounds. Each communication round can contribute to the shared key between the two parties at the cost of channel uses of that round. Theorem 2 gives an upper bound on the key rate achievable by any protocol with any number of communication rounds. Theorem 2. The SK capacity of 2DMBC is upper bounded as [3, Appendix B]

2DMBC+r 2DMBC+r ≤ Usk = max {I(Xf ; Yf |Zf ), I(Xb ; Yb |Zb )} Csk PXf ,PXb

(19)

Unlike the lower bounds, the upper bounds derived for other SKE setups cannot be used to derive upper bounds on the SK capacity of 2DMBC setup and the expression (19) is the only known upper bound in this setting.

Secret Key Establishment over Noisy Channels

141

This upper bound however is not a tight. To see this, consider the case where the forward DMBC has zero secrecy capacity and the backward channel from Bob to Alice is fully noisy, i.e., it cannot transmit even a single bit of information reliably to Alice. In this case, the SK capacity clearly equals to that of the one-way forward DMBC [5], which equals zero. However, the upper bound (19) results in maxPXf [I(Xf ; Yf |Zf )] (since I(Xb ; Yb |Zb ) = 0 for all PXb ) which can remain positive in many cases. This shows that the upper bound in not tight and improving the bound remains an interesting open question. While the two bounds do not appear to be tight in general, in certain cases they coincide and hence the SK capacity is derived. In what follows, we give our results on physically degraded channels which is as special case where the lower and upper bound coincide and the SK capacity is known. 3.3

Physically Degraded 2DMBC

A physically degraded DMBC is a special case of a DMBC where the adversary always receives a degraded version of what the receiver observes through the channel. Wyner’s “wiretap channel” [12] which has founded this line of research is a physically degraded DMBC. Physically degraded channels can be formally shown by a Markov chain relation between the input/ouput variables of the channel. Definition 3. The DMBC (X , Y, Z, PY,Z|X ) is called physically degraded if, for any distribution PX , X ↔ Y ↔ Z forms a Markov chain.

Xf

Alice

PY f | X f

Yf

PZ f |Y f Zb

Eve

PZb |Yb

Yb

Bob

Zf

PYb | X b

Xb

Fig. 3. 2DMBC with physically degraded channels (pd-2DMBC)

The following theorem proves the SK capacity in the case of pd-2DMBC. A 2DMBC is called physically degraded (pd-2DMBC) if both its DMBCs are physically degraded. See Fig. 3. Theorem 3. For the pd-2DMBC, the SK capacity equals [3, Appendix C] pd−2DMBC+r = max {I(Xf ; Yf |Zf ), I(Xb ; Yb |Zb )}, Csk PXf ,Xb

and this capacity can be achieved by a one-rotund SKE protocol which uses the DMBC with higher secrecy capacity.

142

4

H. Ahmadi and R. Safavi-Naini

SKE over 2DMBC without Local Randomness

In Section 3, we investigated the problem of SKE in the 2DMBC setup when parties can have unlimited free access to independent randomness. The two-round SKE protocol (cf. [3, Appendix A]) that achieves the lower bound (13) requires the two parties to have access to free randomenss. In many SKE scenarios however, this assumption is not realistic: Communicating devices may have limited or even no access to randomness source. In the following, we revisit the results of Section 3, assuming that no source of local randomness is available. We assume Alice and Bob each has a ﬁxed publicly known string and can only participate in a (possibly multi-round) deterministic protocol. The question is whether the parties can beneﬁt from interaction together with the channel noise (as their only resource) to achieve positive rates 2DMBC−r . of secret key. We denote the SK capacity in this setting by Csk 4.1

Impossibility Results for Special Cases

It is clear that a SKE protocol is expected to result in a key that is random; therefore, with no local randomness and only using public channels, the task is impossible. This observation is true even in the computational setting, e.g., the Diﬃe-Hellman key exchange protocol [6] where Eve has limited (polynomially bounded) computational power. This is true because all parameters in the system are deterministic, and Eve can execute the same algorithms as Alice and Bob to derive the ﬁnal key. This shows once more that using error correcting codes to remove noise can limit cryptographers in designing secure systems. Although the existence of noise in the communicating channels is a necessary condition for SKE without local randomness, it is not suﬃcient. We show this by discussing the two well-studied SKE scenarios of (i) one-way DMBC [5] and (ii) one-way DMBC and public channel [1, 9], where SKE is impossible despite the existence of noise in the system. The above two setups can be viewed as special cases of 2DMBC. Recall that in the previous section, we studied approaches to SKE by realizing setups (i) and (ii) from a 2DMBC and running known SKE protocols on them. There, we observed that both approaches result in positive rates of secret key; however, it was assumed that local randomness exists as a resource. In the following we revisit them assuming no local randomness. One-Way DMBC: Consider a case that one of the DMBCs, say the backward DMBC, always returns constant values at its outputs. This is the same as assuming a one-way communication over the forward channel. Irrespective of the protocol, Alice will never have a single bit of randomness in her view and, without randomness, she cannot have a secret key. This gives that without local randomness the SK capacity of a one-way DMBC equals DMBC−r = 0. Csk

Secret Key Establishment over Noisy Channels

143

One-Way DMBC and Public Channel: Without loss of generality, assume that the backward DMBC is noiseless and public. In any SKE protocol, Alice’s view of the protocol only comes from what she receives from the public channel which leaks all its data to Eve. This implies that Eve’s view of the protocol includes Alice’s view and thus she can simply follow Alice’s deterministic steps of calculating the key, i.e., the key cannot be secure from Eve, implying DMBC+P C−r Csk = 0.

4.2

Bounds on the SK Capacity

Removing access to local randomness causes impossibility of SKE in a number of well-known setups. For the 2DMBC setup nevertheless, positive rates of secret key may be achieved by taking advantage of noise in both the forward and the backward channels [4]. Theorem 4. Without local randomness, the SK capacity is lower bounded as [4, Section 5] 2DMBC−r Csk

≥

L2DMBC−r = max sk ζ≥0,PXf ,PXb

2DMBC−r 2DMBC−r Lsk,A +sk,B

2

,

(20)

where (ζ[I(Yb ; Xb ) − I(Yb ; Zb )] + γ1 [I(Xf ; Yf ) − I(Xf ; Zf )]+ ) , 1+ζ (ζ[I(Yf ; Xf ) − I(Yf ; Zf )] + γ2 [I(Xb ; Yb ) − I(Xb ; Zb )]+ ) = , 1+ζ

BC−r L2DM = sk,A

(21)

BC−r L2DM sk,B

(22)

for H(Yb |Xb , Zb ) + ζ(H(Yb |Xb ) − H(Xf )) }, I(Xf ; Yf ) H(Yf |Xf , Zf ) + ζ(H(Yf |Xf ) − H(Xb )) γ2 = min{1, }, I(Xb ; Yb ) γ1 = min{1,

(23) (24)

such that H(Yb |Xb , Zb ) > ζH(Xf ),

I(Xf ; Yf ) > ζH(Yb |Xb ),

(25)

H(Yf |Xf , Zf ) > ζH(Xb ),

I(Xb ; Yb ) > ζH(Yf |Xf ).

(26)

We remark that in [4], we assumed the full-duplex communication model, where in each channel use both DMBCs can be used. Hence, we proposed a multi-round SKE protocol that, in each round, uses both DMBCs the same number of times. As we described SKE in Section 2, here we assume the half-duplex model where in each channel use only one of the DMBCs is used. As a consequence, each round of the SKE protocol in [3] should be replaced by two consecutive rounds with the same number of channel uses. The total number of channel uses is thus doubled and the lower bound becomes half. This explains the reason why in (20) we divided by two the lower bound given in [4].

144

H. Ahmadi and R. Safavi-Naini

The lower bound (20) is achieved by a multi-round protocol, called the main protocol. This protocol consists of an initialization step followed by repeated use of a sub-protocol protocol, called the basic protocol. Each iteration of the basic protocol uses some randomness and generates new randomness for the next iteration, together with a new part of secret key. The initialization step provides the initial randomness for the ﬁrst iteration of the basic protocol. As the number of iterations increases, the SK rate of the main protocol approaches (20), which is, in fact, the SK rate of the basic protocol. The basic protocol is constructed similarly to the SKE protocol using local randomness; however, it also provides independent randomness for the parties. 2DMBC−r The SK rates L2DMBC−r and Lsk,B are similar to those in (14) and (15), sk,A with more conditions applied. The real numbers γ1 and γ2 are to relate the amount of achievable key rate as a function of the randomness obtained from channel noise. Theorem 5 gives an upper bound on the SK capacity of 2DMBC without using local randomness. Theorem 5. Without local randomness, the SK capacity is upper bounded as [4, Appendix B]

2DMBC−r 2DMBC−r ≤ Usk = Csk

max

ζ,PXf ,PXb

2DMBC−r 2DMBC−r UA,sk + UB,sk

1+ζ

,

(27)

where 2DMBC−r UA,sk = min{ζH(Yb |Xb , Zb ), I(Xf ; Yf |Zf )}, 2DMBC−r = min{H(Yf |Xf , Zf ), ζI(Xb ; Yb |Zb )}. UB,sk

and

(28) (29)

The upper bound (27) can be speciﬁcally used to prove the impossibility results for the special cases discussed in Section 4.1. In the case of one way communication, e.g., when the backward channel returns constant values at its outputs, both terms I(Xb ; Yb |Zb ) and H(Yb |Xb , Zb ) equal zero, implying a zero upper bound on SK rates. The same argument can be used to prove impossibility when the backward channel is noiseless and public. The two bounds do not match in general. In a special case where DMBCs do not leak information to Eve, Theorem 6 shows that the bounds coincide and the multi-round protocol is capacity-achieving. Theorem 6. When the DMBCs do not leak information to Eve and without randomness, the SK capacity equals [4, Appendix C] 2DM BC−r Csk =

5

max

ζ,PX ,PX f

[min{ζH(Yb |Xb ), I(Xf ; Yf )} + min{H(Yf |Xf ), ζI(Xb ; Yb )}].(30)

b

The Role of Local Randomness over BSCs

Consider the 2BSBC setup described in Section 3.1 (Fig. 1(b)). Recall that this setup has four independent BSCs: the main channels between Alice and Bob

Secret Key Establishment over Noisy Channels

145

have bit error probability p1 and Eve’s channels have bit error probability p2 . We study the role of local randomness in achieving higher rates of secret key. We ﬁrst simplify the lower and upper bound expressions derived in Sections 3 and 4 for the two settings. When randomness is available, we have [3]: = h(p1 )[h(p2 ) − h(p1 )]+ + (1 − h(p1 ))(h(p1 p2 ) − h(p1 )), (31) L2BSBC+r sk and 2BSBC+r Usk = h(p1 p2 ) − h(p1 ).

(32)

When local randomness does not exist, we have [4]: 2BSBC−r Lsk = maxμ∈{0,M1 ,M2 } {Lbound}, such that

Lbound =

1 1+μ

(33)

(μ[h(p1 p2 ) − h(p1 )] + γ[h(p2 ) − h(p1 )]+ ) , h(p1 ) − μ}, γ = min{1, 1−h(p 1)

M1 =

h(p1 ) 1−h(p1 )

−1

1) M2 = min{h(p1 ), 1−h(p h(p1 ) },

and

and 2BSBC−r Usk = min{h(p1 ), h(p1 p2 ) − h(p1 )}.

1

1

L2DMBC+r 2DMBC+r

0.8

U

0.7

L

0.6

U

Bounds of the SK capacity

Bounds of the SK capacity

0.9

2DMBC−r 2DMBC−r

0.5 0.4 0.3 0.2

0.9

L2DMBC+r

0.8

U2DMBC+r

0.7

L2DMBC−r

0.6

U2DMBC−r

0.5 0.4 0.3 0.2 0.1

0.1 0 0

(34)

0.1

0.2

0.3

0.4

Eve’s channel error probability (p ) 2

0.5

0 0

0.1

0.2

0.3

0.4

Main channel error probability (p )

0.5

1

(a) The bounds w.r.t p2 for p1 = 0.1 (b) The bounds w.r.t. p1 for p2 = 0.1 Fig. 4. Comparison of lower and upper bounds with respect to p1 and p2

In Fig. 4, we graph the behavior of the above bounds for diﬀerent values of p1 and p2 . We observe that with or without randomness, there is a gap between the best known lower and upper bounds and where the bounds coincide, correspond to the impossibility of SKE or the SK capacity for the special cases discussed in this paper. Fig. 4(a) compares the bounds as functions of p2 when p1 equals 0.1. Since p1 is ﬁxed, the main channels provide a ﬁxed level of noise as resource

146

H. Ahmadi and R. Safavi-Naini

for randomness, and the behaviors of the bounds in both settings (with/without randomness) look similar. However, in Fig. 4(b) where the comparison is with respect to p1 , we observe that for small values of p1 the SK capacity is vanishingly small. This is however not the case when generating local randomness is not a concern. 2BSBC−r ≥ Lsk Comparing the lower bounds, both graphs reveal that L2BSBC+r sk where equality only holds in the extreme cases. This implies that removing local randomness has signiﬁcant impact on the lower bound. We further note that the lower bound (31) is achieved by only two rounds of communication, whereas (33) requires a multi-round protocol; restricting the number of communication rounds will increase such a diﬀerence between the two lower bounds. This diﬀerence cannot be seen however for the upper bounds. In both graphs, the derived upper bounds in the two settings remain the same except when p1 is much less than p2 . This suggests that the two bounds for SKE without local randomness are farther apart compared to the case of SKE with local randomness. An interesting future work is to derive tighter bounds on the SK capacity, specially in the setting of SKE without local randomness.

6

Concluding Remarks

We considered the 2DMBC setup for SKE and gave an overview of the known results in comparison with other related SKE setups, in particular a one-way DMBC, and DMBC together with a public channel. 2DMBC setup is a natural model for communication of terminals in wireless environments and minimizes assumptions such as the existence of a public channel, or a correlated random variable and gives a realistic estimate of the key rate by taking into account all the uses of the communication channels. More importantly, by allowing interaction over noisy channels, SKE becomes possible in cases where it is impossible for the other two SKE setups mentioned above, to have positive SK rate. In particular, when there is no local source of randomness, 2DMBC is the only setup that gives positive SK rate. We gave concrete comparison of the three bounds and the three setups by assuming the 2DMBC is a 2BSBC and suggested direction for future research. Acknowledgement. This work is supported by Natural Sciences and Engineering Research Council of Canada.

References 1. Ahlswede, R., Csisz´ ar, I.: Common randomness in information theory and cryptography. Part I: secret sharing. IEEE Transaction Information Theory 39, 1121–1132 (1993) 2. Ahlswede, R., Cai, N.: Transmission, identiﬁcation and common randomness capacities for wire-tape channels with secure feedback from the decoder. In: Ahlswede, R., B¨ aumer, L., Cai, N., Aydinian, H., Blinovsky, V., Deppe, C., Mashurian, H. (eds.) General Theory of Information Transfer and Combinatorics. LNCS, vol. 4123, pp. 258–275. Springer, Heidelberg (2006)

Secret Key Establishment over Noisy Channels

147

3. Ahmadi, H., Safavi-Naini, R.: Secret key establishment over a pair of independent broadcast channels. In: International Symposium Information Theory and its Application, pp. 185–190 (2010) Full version on the arXiv preprint server, arXiv:1001.3908 4. Ahmadi, H., Safavi-Naini, R.: Secret keys from channel noise. In: Paterson, K.G. (ed.) EUROCRYPT 2011. LNCS, vol. 6632, pp. 266–283. Springer, Heidelberg (2011); Full version on the Cryptology ePrint Archive: Report 2011/063 5. Csisz´ ar, I., K¨ orner, J.: Broadcast channels with conﬁdential messages. IEEE Transaction Information Theory 24, 339–348 (1978) 6. Diﬃe, W., Hellman, M.E.: New directions in cryptography. IEEE Transaction Information Theory 22, 644–654 (1976) 7. Khisti, A., Diggavi, S., Wornell, G.: Secret key generation with correlated sources and noisy channels. In: IEEE International Symposium Information Theory, pp. 1005–1009 (2008) 8. K¨ orner, J., Marton, K.: Comparison of two noisy channels. Transactions of the Hungarian Colloquium on Information Theory, 411–423 (1977) 9. Maurer, U.: Secret key agreement by public discussion from common information. IEEE Transaction Information Theory 39, 733–742 (1993) 10. Prabhakaran, V., Eswaran, K., Ramchandran, K.: Secrecy via sources and channels - a secret key - secret message rate trade-oﬀ region. In: IEEE International Symposium Information Theory, pp. 1010–1014 (2008) 11. Shannon, C.E.: Communication theory of secrecy systems. Bell System Technical Journal 28, 656–715 (1948) 12. Wyner, A.D.: The wire-tap channel. Bell System Technical Journal 54, 1355–1367 (1975)

Formal Specification and Validation of Security Policies Tony Bourdier1 , Horatiu Cirstea1 , Mathieu Jaume2 , and H´el`ene Kirchner3 1

INRIA Nancy - Grand-Est Research Center & Nancy-Universit´e & LORIA 2 SPI LIP6, Universit´e Paris 6 3 INRIA Bordeaux - Sud-Ouest Research Center

Abstract. We propose a formal framework for the specification and validation of security policies. To model a secured system, the evolution of security information in the system is described by transitions triggered by authorization requests and the policy is given by a set of rules describing the way the corresponding decisions are taken. Policy rules are constrained rewrite rules whose constraints are first-order formulas on finite domains, which provides enhanced expressive power compared to classical security policy specification approaches like the ones using Datalog, for example. Our specifications have an operational semantics based on transition and rewriting systems and are thus executable. This framework also provides a common formalism to define, compare and compose security systems and policies. We define transformations over secured systems in order to perform validation of classical security properties.

1 Introduction When addressing the field of security policies in computer science, we are faced to multiple definitions of this concept, most often based on their purpose rather than on their behavior. We adopt here a generic definition by saying that the purpose of a security policy is to define what it means to be secure for a system, an organization or another entity. With this point of view, security policies can be seen as special procedures that deliver authorizations to perform specific actions: for instance, they decide whether or not an access is granted, whether or not a transaction may be approved, possibly taking into account the history of transactions (e.g., on a bank account, the total amount of cash withdrawal during the month should not exceed a fixed amount), or priority considerations (e.g., an emergency call is always given priority). The additional specificity of security policies is their reactive behaviour with respect to their execution environment: on one hand, a target system may query the policy for an authorization before performing specific accesses or transactions; on the other hand, the answers of the policy not only determine the way the corresponding action is handled in the system but can also modify the (security) information of the system and consequently subsequent executions. For example, a negative authorization from an ATM machine security policy due to an incorrect PIN not only prevents immediate money withdrawal but can also induce a (bad PIN) counter incrementation and lead to a permanent blocking of the corresponding account after a certain number of unsuccessful attempts. So, the security information could be seen as part of the target system but it is also intrinsic to the corresponding policy whose decisions strongly depend on it. When J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 148–163, 2012. c Springer-Verlag Berlin Heidelberg 2012

Formal Specification and Analysis of Security Policies

149

designing policies that deliver authorizations to perform specific actions based on some security information, two questions arise. How to formalize the information needed by the policy? How to formalize the effect of the policy decision on this information? To address these questions, our first contribution is to provide a framework which can be used to formalize separately the security system that manipulates all the security information used for producing the authorization decisions and the policy rules that compute the decisions. This separation is relevant not only for a conceptually clear specification and design, but also for the verification, comparison and composition of policies. In particular, this approach allows one to analyse separately properties related to the management of the security information (expressed as invariants of the security system) and properties related to the policy rules (consistency or completeness for example). A security system is formalized as a transition system whose states are generated by syntactic environments, and whose transitions are described by transition rules on environments. Each transition is triggered by an event which corresponds to an authorization given by the security policy. The policy is specified as a set of rules describing the way the decisions are taken. Policy rules are constrained rewrite rules, whose constraints are first-order formulas solved in the current state of the transition system. According to the authorization, the transition rule may or may not apply. So, conceptually, the security policy restricts the possible transitions of the security system. Such specifications of security systems and policies have a well-understood operational semantics based on transition and rewriting systems and are thus executable. The goal of security policies is to achieve security properties. On the other hand, the relation between these properties and the mechanisms implementing the policy is not always obvious and a question naturally emerges: how to bridge the gap in such a case? Our second contribution is a transformation based approach which can be used to check generic security properties for security systems which have been independently designed. A security policy is often expected to fulfill a certain security property expressed on some entities, while it is dealing with a different set of entities. A typical example is given by access control policies designed for ensuring flow properties: such policies do not deal with information flow but only with objects containing information to be traced. Indeed, access control policies allow to grant or to revoke the rights for active entities (the subjects) to access some passive entities (the objects), but cannot always control how the information is used once it has been accessed (there is no control on its propagation). Intuitively, a link is needed between “what you do” (the policy) and “what you want” (the goal for which the policy is designed). We formalize this link through a transformation of environments, whose aim is to translate an environment into another one dealing with the entities we are interested in. We can use such a link to define a flow-based interpretation of access control policies. This kind of transformations allows thus the validation of a property over a system even if the property is expressed in a different specification. In practice, this approach provides a way to reuse the same specification of a security property in order to analyse or to verify several policies and systems, thus showing the benefits of a library of generic security properties, dedicated to particular domains (like information flows) and that can be considered in several contexts. For example, it becomes possible to check the same information flow property expressed by a specification for several access control policies.

150

T. Bourdier et al.

We first introduce some useful notions and notations in Section 2. Section 3 presents the different components of our specification framework: security signatures, environments, transition rules as well as security systems, policy rules, and secured systems. Section 4 addresses the validation point of view by defining environment transformations and illustrating the verification of security properties. In Section 5, we compare our approach with other works. Conclusions and future works are presented in Section 6. We give, in the appendix, some implementation hints.

2 Preliminaries We assume the reader familiar with the standard notions of term rewriting, first order logic and Datalog. This section briefly recalls basic notions used in this paper; more details can be found in [19] for logic considerations, in [2] for rewriting considerations and in [27] for Datalog related notions. A many-sorted signature Σ = (S, F , P) is given by a set of sorts S, a set of function symbols F and a set of predicate symbols P. A function symbol f with arity s1 , . . . , sn ∈ S and co-arity s is written f :s1 , . . . , sn → s. A predicate symbol p with arity s1 , . . . , sn ∈ S is written p:s1 , . . . , sn . Variables are also sorted and the notation x:s specifies that the variable x has sort s. We assume in this paper that all variables are ranging over finite sets. This condition can be relaxed under some conditions [27], especially for allowing built-in sorts such as integers. Given a set ζ extending a set of variables X (possibly empty) with constants sorted by S, the set of Σ-terms over s is the smallest set containing elements of ζ of sort s and all the ζ denoted by TΣ,ζ si for i ∈ [1..n]. We write f (t1 , . . . , tn ) such that f :s1 , . . . , sn → s ∈ Σ and ti ∈ TΣ,ζ s TΣs instead of TΣ,∅ and the sort is omitted when not important in the context. We also consider a partial ordering < on the set S of sorts of a signature Σ and we write s1 < s2 s1 s2 if TΣ,ζ ⊆ TΣ,ζ . Pos(t) denotes the set of positions of a term t, t|ω denotes the subterm of t at position ω, and t [u]ω the term t with the subterm at position ω replaced by u. The set of variables occurring in a term t is denoted by Var(t). If Var(t) is empty, t is called a ground term. All the following definitions are given w.r.t. to a set ζ whose subset of variables is denoted by X . A substitution is a mapping from X to TΣ,ζ which is the identity except over a finite set of variables called domain of σ and denoted by Dom(σ). σ naturally extends to an endomorphism of TΣ,ζ . If any variable in the domain is mapped to a ground term then, the corresponding substitution is called ground. A Σ-atom is of the form p(t1 , . . . , tn ) or t1 = t2 with p ∈ P and t1 , . . . , tn ∈ TΣ,ζ . A Σ-literal is either a Σ-atom or a negated (with ¬) Σ-atom and the set of Σ-formulas built out of Σ-literals is denoted by F orΣ,ζ . The set of free variables of a formula φ (i.e. variables not in the scope of a quantifier) is denoted by F Var(φ). A logical rule over Σ, denoted by a ← l1 ∧ . . . ∧ ln , consists of a conjunction of Σ-literals li called the body and a Σ-atom a called the goal. A constrained rewrite rule over a signature Σ is a 3-tuple (l, ϕ, r) ∈ TΣ,X ×F orΣ,X × ϕ TΣ,X , denoted by l − → r, such that Var(r) ⊆ Var(l) ∪ F Var(ϕ). A constrained term rewrite system (CTRS) R is a set of constrained rewrite rules. We say that t ∈ TΣ rewrites into a term t ∈ TΣ with respect to R and a Σ-theory ϑ, which is denoted by

Formal Specification and Analysis of Security Policies

151

ϕ

t →ϑR t iff there exist a position p ∈ Pos(t), a rewrite rule l − → r ∈ R, and a ground substitution σ with Dom(σ) = Var(l) ∪ F Var(ϕ) such that ϑ |= {t|p = σ(l) ; t = t [σ(r)]p ; σ(ϕ)}.

3 Secured Systems A security policy responds to the authorization requests of a system according to a certain number of rules and to the configuration of the system at the moment of the request. We consider thus that a system constrained by a security policy consists of two parts: on one hand, the set of rules describing the way the decisions are taken and on the other hand, the information used by the rules and the way these evolve in the system. We call the former the policy rules and the latter the security system. In our framework all objects manipulated by the security system and the policy rules are described as first order terms over a common signature called the security signature. We define the security system using transition rules and the policy rules as a constrained rewrite system. 3.1 Security Signature A transition of the security system is triggered when an authorization request occurs and the result of the respective transition depends on the corresponding decision. We thus call events the pairs consisting of an authorization request and the associated decision, and the security signature always defines the sorts Query and Decision corresponding to the sorts of the first and respectively second element of such a pair. Definition 1. A security signature is a signature ΣSys ∪ ΣEv such that ΣEv contains two sorts Query and Decision with Decision < Query and a set of function symbols whose co-arity belongs to SEv . Example 1. Along the lines of this paper, we consider an access control system on which we define a confidentiality policy (which can be viewed as a variant of the mandatory part of the Bell and LaPadula policy [7]). This policy constrains accesses done by subjects (S) over objects (O) according to access modes (A) by considering levels of security belonging to a finite lattice (L, ) associated with subjects and objects. Hence, we introduce the security signature ΣSys ∪ ΣEv as follows. First, ΣSys = (SSys , FSys , PSys ) consists of SSys = {S, O, A, L} and ⎧ ⎫ ⎧ ⎫ :L, L read: → A , fs : S →L ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ ⎬ ⎨ ⎬ m:S, O, A write: → A , fo : O →L FSys = PSys = sudo:S erase: → A , root: →S ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎩ ⎭ ⎩ ⎭ redlist, blacklist:S topSecret: → L The functions fs and fo describe security levels associated with subjects and objects; root (resp. topSecret) is a particular subject (resp. security level). The predicate m describes current accesses over objects by subjects: m(s, o, a) means that the subject s performs an access of type a over an object o. The predicate sudo describes “sudoers”, i.e. users with root privileges. redlist and blacklist respectively indicate if a subject

152

T. Bourdier et al.

has requested one or more successive denied accesses. The signature ΣEv is based on the following function symbols:

ask:S, O, A → Query, release:S, O, A → Query, FEv = deny: → Decision, permit: → Decision ask(s, o, a) (resp. release(s, o, a)) means that the subject s asks to get (resp. to release) an access over an object o according to the access mode a. 3.2 Environments and Transition Rules A security system is a transition system that describes the way security information evolves. The states of the system are defined intensionally by a set of kernel information (that can be modified by the transition rules of the system) and an immutable set of closure rules used to compute the complete security information. The result of such a computation represents the extensional description of the corresponding state. Definition 2. An environment η over a signature Σ = S, F , P consists of: (i) a domain: a finite set | η | of sorted constants that contains all the constants of Σ; (ii) a base of facts: a finite set Bη of atoms of the form p(t1 , . . . , tn ) with p ∈ P, n > 0 and t1 , . . . , tn ∈ | η |. (iii) a base of equalities: a finite set Eη of equalities of the form f (t1 , . . . , tn ) = t with f ∈ F, n > 0 and t1 , . . . , tn , t ∈ | η | which does not contain two equalities with the same left-hand side; (iv) closure rules: a set Rη of safe and stratified logical rules over Σ. Safety and stratification of logical rules are well-known notions [27] imposing that (i) any variable occurring in a rule has a bounded domain and (ii) negations wrapped inside recursion are forbidden. The base of equalities gives the interpretation into the domain of the environment for any term of the signature. We denote by t↓η the interpretation of the term t in | η |, i.e. f (t1 , . . . , tn )↓η = u iff f (u1 , . . . , un ) = u ∈ Eη and ui = ti ↓η for all i ∈ [1, n]. If t = t↓η we say that t is η-normalized. Example 2. If we consider the security signature Σ introduced in Example 1, we can define the environment η as follows. The domain | η | contains the constants Alice and Charlie of sort S, the constant P wdF ile of sort O, and the constants Secret, L1 , L2 , P ublic, of sort L. The base of facts Bη (partially) defines the partial order and states that Charlie is a sudoer:

L1 Secret, L2 Secret, P ublic L1 , P ublic L2 , Bη = Secret topSecret, sudo(Charlie) The base of equalities Eη provides a definition for the security levels associated with the subjects defined in the domain:

fs (root) = topSecret, fs (Alice) = L2 , fs (Charlie) = P ublic, Eη = fo (P wdF ile) = Secret, The set of closure rules completes the definition of : Rη = x x ← ; x z ← x y ∧ y z Due to the restrictions imposed on the domain and on the formulas, we have:

Formal Specification and Analysis of Security Policies

153

Proposition 1. For any environment η over Σ, there exists a unique and computable least fixpoint of the logic program consisting of Bη , Eη and Rη . This fixpoint is denoted by η and is called the semantics of η. Since | η | is finite, the validity of any first-order formula in η is decidable. The transition rules of a security system describe the evolution of environments. Several approaches like, for example, action languages [16] or updating rules [1], have been already used for the specification of logical models change. We follow in this paper the main ideas of the latter approach. Definition 3. An update u over Σ = (S, F , P) is a logical rule (goal ← body) of one of the following forms: (i) p(x1 , . . . , xn ) ← ϕ or (ii) ¬p(x1 , . . . , xn ) ← ϕ or (iii) f (x1 , . . . , xn ) = y ← ϕ ∧ y = t where xi and y are variables, p ∈ P, f ∈ F and ϕ is a formula. u is applicable iff (in the case (iii)) Var(t) ⊆ {x1 , . . . , xn }. In this case, the application of u over the environment η is the environment η = η ⊕ u such that:

case (i) Bη = Bη ∪ p(μ(x ), . . . , μ(x )) 1 n

η|=μ(ϕ) case (ii) Bη = Bη \ η|=μ(ϕ) p(μ(x1 ), . . . , μ(xn )) case (iii) Eη = Eη \ {f (μ(x1 ), . . . , μ(xn )) = t ∈ η | η |= μ(ϕ ∧ y = t)} ∪ {f (μ(x1 ), . . . , μ(xn )) = μ(y) | η |= μ(ϕ ∧ y = t)}

where μ are maps from {x1 , . . . , xn , y} to | η |. The result of applying a sequence of updates U = (u1 , . . . , un ) over η is the environment η ⊕ U = (. . . (e ⊕ u1 ) ⊕ u2 ) . . .) ⊕ un ). Applying an (applicable) update over an environment consists thus in adding (or removing) the fact or changing the equality corresponding to its goal for any substitution making its body true in the environment. The transitions of the security system describing the evolution of the states are sequences of updates labelled by the events that trigger them: Query Decision × TΣ,X Definition 4. A Σ-transition rule is a pair of terms event ∈ TΣ,X whose subterms are constants or variables of ΣSys together with a sequence of updates U over Σ such that σ(U )1 is applicable for any ground substitution σ of domain Var(event). A transition rule is usually written (event) : U . For any transition rule evt r = (event) : U , η −→r η iff evt = σ(event) and η = η ⊕ σ(U ). Moreover, for any evt evt set of rules δ, η −−→δ η iff there is a rule r ∈ δ such that η −−→r η .

Example 3. If we consider the security signature Σ introduced in Example 1, we can define the following set δ of transition rules: 1

For any substitution σ, σ(U ) is the update sequence obtained by replacing in the goal and body of all its updates any x ∈ Dom(σ) by σ(x).

154

T. Bourdier et al.

⎧ ⎨

m(s, o, a) ← ¬redlist(s) ← ⎩ ¬blacklist(s) ← ⎧ ⎨ blacklist(s) ← redlist(s) ¬m(s, o , a ) ← blacklist(s) ∧ m(s, o , a ) (ii) (ask(s, o, a), deny) : ⎩ redlist(s) ← (iii) (release(s, o, a), permit) : ¬m(s, o, a) ← (i)

(ask(s, o, a), permit) :

The rules (i) and (iii) indicate that when an access request is permitted, the corresponding fact is added and when the respective access is released, the fact is removed. The rule (ii) expresses that a subject is registered on a red-list when it attempts a denied access and that it is black-listed when it attempts twice in a row. When it is black-listed, all its current accesses are removed. The expressive power of the formalism goes well beyond the updates of Example 3. For instance, if we consider a predicate delegate, the following rule indicates how user s can give his rights to user s ; if s is root then s becomes a sudoer unless it had been red- or black-listed: fs (s ) = l ←l = fs (s) (delegate(s, s), permit) : sudo(s ) ←s = root ∧ ¬redlist(s ) ∧ ¬blacklist(s ) Provided the rule events are not unifiable, we get: Proposition 2. For any set δ of disjoint transition rules (i.e. such that rule events do not overlap), the relation →δ is deterministic. 3.3 Security Systems, Policy Rules and Secured Systems A security system is defined by a set of transition rules and an initial environment. Definition 5. Given a security signature Σ = ΣSys ∪ ΣEv , a security system, is the labelled transition system S whose states are environments over ΣSys , with an initial evt Query Decision state ηinit and whose transitions are η −→δ η for some evt ∈ TΣ,| . η | × TΣ,| η | Example 4. The security system S over the security signature Σ defined in Example 1 consists of the initial environment η defined in Example 2 and the set δ of transition rules defined in Example 3. Definition 6. A set of policy rules over a security signature Σ = ΣSys ∪ ΣEv is an ϕ ordered constrained term rewrite system over Σ with all the rules of the form l− →r with l, r terms sorted by sorts in SEv and ϕ a ΣSys -formula. We write q →η d when q is rewritten in one step w.r.t. the policy rules and the ∗ environment η into d and we write q −→ η d for multiple-step rewriting.

Formal Specification and Analysis of Security Policies

155

Example 5. The following ordered CTRS ⎧ ⎫ blacklist(s) ⎪ ⎪ ask(s, o, a) − − − − − − − → deny ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ sudo(s) ∧ s=root ⎪ ⎪ ⎪ ⎪ ask(s, o, a) − − − − − − − − − − − → ask(root, o, a) ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ f (o)f (s) ∧ (∀o .m(s,o ,write)⇒f (o)f (o )) o s o o ⎪ ⎪ ⎨ ask(s, o, read) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ permit ⎬ ⎪ ask(s, o, write) ⎪ ⎪ ⎪ ⎪ ask(s, o, erase) ⎪ ⎪ ⎪ ⎪ ⎪ ask(s, o, a) ⎪ ⎩ release(s, o, a)

∀o .m(s,o ,read)⇒fo (o )fo (o)

−−−−−−−−−−−−−−−−−−−−→

permit

−−−−−−−→ → − → −

permit deny permit

fo (o)fs (s)

⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎭

defines a policy specifying that: • a black-listed subject is denied any access; • a sudoer has the same access rights as root; • a subject can read an object whose level of security is smaller than its level of • • • •

security if it is not writing an object of a lower security level; a subject can write an object if it is not reading an object of a higher level; a subject can erase an object whose security level is smaller than its level; in all other cases, the access is denied ; a subject can always release any of its accesses.

Notice that since the rules are ordered, the constraints do not need to impose explicitly the negation of the constraints of previous overlapping rules and, in particular, no constraint is needed for the “default” rules. Definition 7. A set of policy rules over a security signature Σ = ΣSys ∪ ΣEv is η-consistent (resp. η-complete) for an environment η over ΣSys iff for any query q ∈ Query Decision TΣ,| such that η | , there exists at most (resp. at least) one decision d ∈ TΣ,| η | ∗

q −→η d.

These properties can be proved for a large class of policy rules. Proposition 3. A set of policy rules is η-consistent if (1) for each rule, its left-hand side contains only one occurrence of each variable and its constraint does not involve ϕ

ϕ

→ r and l −→ r there exists no position terms of sort Query; (2) for any two rules l − ω and no substitution σ such that η |= {σ(l|ω ) = σ(l ) ∧ σ(ϕ) ∧ σ(ϕ )}. Proof. The proof is obtained by adapting the proof for orthogonal TRS [2]. Proposition 4. A set of policy rules over a security signature Σ = ΣSys ∪ ΣEv is ∗ η-complete if (1) the reduction −→ η terminates, (2) for any symbol f :s1 , . . . , sn → s ∈ FEv with s > Decision there exists a default rule for f , i.e. a rule containing no constraint and whose left-hand side is a term f (x1 , . . . , xn ) with xi ∈ X , (3) each rule of is sort-preserving or sort-decreasing (i.e. the sort of its left-hand side is equal or greater than the sort of its right-hand side).

156

T. Bourdier et al.

Query Proof. We prove that q ∈ TΣ,| η | has a normal form of sort Decision by induction on the well-founded rewrite relation induced by . If q is of sort Decision then its normal form is necessarily of the same sort by (3). If not, then q is reducible by (because of the default rule) into a ground term q which, by induction hypothesis, has a normal form of sort Decision.

The classical methods for proving termination of TRS can be adapted for CTRS. For example, the policy rules introduced in Example 5 can be shown terminating using an obvious polynomial interpretation [2] connected to the corresponding constraints. There is also a default rule for each symbol of sort Query and the rules are sort-preserving or sort-decreasing. Consequently, the corresponding normal forms are clearly in this case permit or deny. The policy rules obviously satisfy condition (1) of Proposition 3 and, because of the order, condition (2) as well. The policy rules of Example 5 are thus η-complete and η-consistent for any environment η. Definition 8. Given a security signature Σ = ΣSys ∪ ΣEv , a security system S over Σ and a set of policy rules over Σ η-complete and η-consistent for any environment η over ΣSys , a secured system is the labelled transition system ℘ whose states are environments over ΣSys , whose initial state is the initial state of S and whose transi q,d

q,d

Query Decision tions are η −−−→℘ η for some q, d ∈ TΣ,| such that η −→ δ η and η | × TΣ,| η | ∗

q −→η d.

Since the set of security rules of a secured system is η-complete and η-consistent for any environment η, the corresponding relation is computable. Moreover, the underlying relation of the security system is computable by construction and thus, so is the underlying relation of the corresponding secured system. Proposition 5. The relation − →℘ is computable for any secured system ℘.

4 Checking Security Properties In this section, we propose a methodology based on environment transformations for the validation of security properties enforced by a policy over a system. This is particularly relevant when the policy and the security property are expressed on different entities. This is the case, for instance, when security is specified in terms of information flow properties, while the policy is an access control policy that can only manipulate objects containing the information to be traced. To solve this problem, we introduce a transformation whose aim is to translate an environment into another one dealing with the entities we are interested in. Such a transformation is defined below by a signature morphism, that allows the translation of the domain and of the base of equalities, together with a set of transformation rules on the base of facts. Definition 9. A signature morphism θ from (S1 , F1 , P1 ) to (S2 , F2 , P2 ) is a pair (θS , θF ) such that θS :S1 → S2 and θF :F1 → F2 are (partial or total) functions such that ∀f :s1 , . . . , sn → s ∈ Dom(θF ) where s1 , . . . , sn , s ∈ Dom(θS ), θF (f ): θS (s1 ), . . . , θS (sn ) → θS (s) ∈ F2 . We extend θ to a morphism θˆ (which is simply denoted by θ) over terms as follows:

Formal Specification and Analysis of Security Policies

157

ˆ • ∀x:s ∈ X , θ(x:s) = x:θS (s) ˆ (t1 , . . . , tn ):s) = θF (f )(θ(t ˆ 1 ), . . . , θ(t ˆ n )) • ∀f ∈ Dom(θF ), θ(f Definition 10. Given two signatures Σ1 = (S1 , F1 , P1 ) and Σ2 = (S2 , F2 , P2 ), an environment transformation Θ is a tuple (θ, δ, R) where: • θ is a signature morphism from Σ1 to Σ2 ; • δ is a set of pairs condition, conclusion with condition a Σ1 -formula and conclusion a conjunction of Σ2 -atoms such that x:s ∈ F Var(condition) iff θ(x:s) ∈ F Var(conclusion); • R is a set of safe and stratified logical rules over Σ2 . Applying Θ on an environment η over Σ1 produces an environment Θ(η) over Σ2 defined as follows: • | Θ(η) | = {c:θ(s) | c:s ∈ | η | ∧ s ∈ Dom(θ)}; • EΘ(η) contains an equality θ(f (t1 , · · · , tn )) = θ(t) for each f (t1 , · · · , tn ) = t in Eη whose image by θ is defined; • BΘ(η) contains all Σ2 -atoms p(μ(t1 ), . . . , μ(tm ))↓Θ(η) for which there exists a pair condition, conclusion ∈ δ where p(t1 , · · · , tn ) occurs in conclusion, and a mapping μ from Var(condition) to | η | such that η |= μ(condition); • RΘ(η) = R. We say that η is transformed by Θ into Θ(η). Any environment transformation Θ = (θ, δ, R) from Σ1 to Σ2 induces a total mapping η → Θ(η) from Σ1 -environments into Σ2 -environments; this operational view justifies to call Θ a transformation operator. We can use this notion of environment transformation to check a security property expressed as a Σ2 -formula ψ over reachable environments of a secured system ℘ over Σ1 . Indeed, this amounts to check that for every reachable environment η of ℘, we have Θ(η) |= ψ, which is decidable for any ψ, as a consequence of Proposition 1 and the computability of Θ(η) for any η. Example 6. We consider now environment transformations that can be used to deal with information flow properties of access control policies. We introduce the “generic” signature ΣFLOW = ({Actor, Inf ormation}, FFLOW , PFLOW ) where PFLOW is: ⎫ ⎧ MoveTo : Inf ormation, Inf ormation; ⎬ ⎨ Get : Actor, Inf ormation; Put : Actor, Inf ormation; Trustworthy : Actor, Inf ormation; ⎭ ⎩ Eligible : Actor, Inf ormation; Gflow : Inf ormation, Inf ormation and where FFLOW is an arbitrary set of function symbols. Get (a, i) means that the actor a knows the information i, Put (a, i) means that the actor a modifies the information i (by using the information it knows), MoveTo(i1 , i2 ) means that the information i2 is enriched with information i1 , Eligible (a, i) means that the actor a is granted to know the information i, Trustworthy(a, i) means that the actor a is granted to modify the information i and Gflow (i1 , i2 ) means that the information i1 is authorized to flow into i2 . The predicates Get , Put and MoveTo are useful for describing existing flows while the predicates Eligible , Trustworthy, and Gflow are used to specify flow policies (respectively a confidentiality policy, an integrity policy and a confinment policy). Now, it is possible to define, in a generic way, confidentiality, integrity and confinment security properties as follows:

158

T. Bourdier et al.

Confidentiality Integrity Confinment

ψ conf ψ int ψ info

∀a, i. Get(a, i) ⇒ Eligible (a, i) ∀a, i. Put(a, i) ⇒ Trustworthy(a, i) ∀i, i . MoveTo(i, i ) ⇒ Gflow (i, i )

Let us consider the environment transformation defined from the signature ΣSys of Example 1 and the signature ΣFLOW and consisting of the partial function θS : SSys → SFLOW such that Dom(θS ) = {S, O} with θS (S) = Actor, θS (O) = Inf ormation together with the identity function θF , the following logical rules over ΣFLOW : ⎧ MoveTo(i, i) ← ⎪ ⎪ ⎪ ⎪ ⎨ MoveTo(i, i ) ← Get (a, i) ∧ Put(a, i ) RFLOW = Get (a, i) ← MoveTo(i, i ) ∧ Get (a, i ) ⎪ ⎪ Put (a, i ) ← MoveTo(i, i ) ∧ Put(a, i) ⎪ ⎪ ⎩ MoveTo(i, i ) ← MoveTo(i, i ) ∧ MoveTo(i , i ) and δ defined by: m(x, y, read) ∧ ∀x .¬m(x , y, erase) Get (x, y)

fo (y) fs (x) Eligible (x, y)

m(x, y, write) ∧ ∀x .¬m(x , y, erase) Put (x, y)

fo (y) fo (y ) Gflow (y, y )

The rules introducing Get and Put allow the translation of the accesses expressed in the source environment using the predicate m into accesses expressed in the target environment using the predicates Get and Put. The rules introducing Eligible and Gflow can be viewed as the definition of the flow interpretation of a (security level-based) access control policy. Note that this transformation allows to handle transitive information flows generated by accesses performed simultaneously in a given environment but does not take into account the past (accesses) of the system. Indirect flows can be nevertheless dealt with by adding a new predicate which keeps track, in the source environments, of the origins of the information contained into each object of the system (for example, see [17,22] for an intrusion detection based approach dealing with indirect information flows). The above environment transformation provides the means for checking that our policy ensures confinment. This can be done by checking that each reachable environment η of the secured system ℘ is such that Θ(η) |= ψ info . However, the existence of sudoers may generate reachable environments that do not satisfy the confidentiality property w.r.t. Θ, i.e. it is possible to obtain a reachable environment in ℘ which is transformed into an environment which does not satisfy ψ conf . This is for example the case for the environment obtained by considering the initial environment introduced in Example 2 and a transition labelled by the event ask(Charlie, P wdF ile, read). Indeed, since Charlie is a sudoer, the policy defined in Example 5 allows Charlie to have a read access over P wdF ile even if its security level is not greater than Secret and hence, we have Get (Charlie, P wdF ile). However, the meaning of Eligible specified by δ does not take into account sudoers and we have thus ¬Eligible (Charlie, P wdF ile). sudo(s) to δ and give thus a different semantics Of course, when adding the rule Eligible (s, o) to the confidentiality property, one can check that any reachable environment η of the system ℘ is such that Θ(η) |= ψ info ∧ ψ conf . Note also that if we add the possibility

Formal Specification and Analysis of Security Policies

159

for a user to assign its security level to another user (as illustrated on page 154) then the security level of a user can decrease and thus, only the property ψ info is preserved. By constraining the delegation mechanism with the following policy rules: fs (s )fs (s) delegate(s, s) −−−−−−−−→ permit ¬(fs (s )fs (s))

delegate(s, s) −−−−−−−−−−→ deny to ensure that security levels of subjects can only increase, the property ψ conf can be preserved. The transformation approach can be also useful when one wants to enforce policies by directly using the desired security properties to constrain the transitions of a security system. Indeed, suppose we want to constrain a security system S = (ηinit , δ) over a signature Σ1 in order to ensure a security property expressed as a formula ϕ over a different signature Σ2 . The corresponding secured system can be obtained by using an environment transformation Θ = (θ, δΘ , R2 ) from Σ1 to Σ2 and by considering the evt evt transition relation →δϕ such that η −→δϕ η iff η −→δ η ∧ Θ(η ) |= ϕ. Of course, such an approach leads to a system whose reachable states satisfy ϕ iff Θ(ηinit ) |= ϕ. The notion of environment transformation makes thus possible the application of a security policy expressed as a (required) property to several systems.

5 Related Work Among a rich literature on security policies (see for instance [14] for policy specification languages, and [21] for the rule-based and property-based approaches to define policies), our approach is in the line of logic-based languages providing a wellunderstood formalism, which is amenable to analysis and verification. Our formalism borrows inspiration from various sources. Horn clause logic has been used extensively for RBAC models [25]. Since negation and recursion are often needed, the concept of stratified theories is present for instance in the authorization specification language ASL [20] for access control. Integrity rules specify application dependent conditions that limit the range of acceptable policies. Stratified logic for RBAC policies is also developed in [4]. In our work, we use similar concepts but do not restrict to RBAC models. Constraint logic programming for designing RBAC and temporal RBAC policies is considered in [5]. Their constraints are conjunctions of equational constraints over sets of constants, and arithmetic constraints over non-negative integers. While keeping a declarative approach, CLP adds the expressive power and efficiency of constraint solving and database querying. A security administrator has then analysis capability thanks to the computation of sets of constraints as answers. Formalisation of security analysis in an abstract setting is done in [24] and exemplified for RBAC. In comparison, we allow a different class of constraints that we keep decidable by restricting to safe theories, and we use constraints in a rewriting context. Note that it is also possible to apply constraint narrowing to get analysis power as in [23] or in [9]. Whereas most existing works on reasoning about security policies model the environment only lightly, if at all, there are some exceptions. One of the closest works is [15]

160

T. Bourdier et al.

who represents the behavior of access control policies in a dynamic environment. Policies are written in Datalog and can refer to facts in the authorization state. Events, such as access requests, can change the authorization state, and the changes are specified as a state machine whose transition labels are guarded by the policy. Security properties can then be analyzed by model checking formulas in first-order temporal logic. In [6], the authors introduce a logic for specifying policies where access requests can have effects on the authorization state. The effects are explicitly specified in the language, an extension of Datalog backed on transaction logic. They also propose a proof system for reasoning about sequences of user actions. In comparison, thanks to constraint rewriting, we provide a more expressive formalism, while keeping it operational and decidable. The full expressive power of constraint rewriting is explored in [10]. Comparing the expressive power of access control models is a fundamental problem in computer security, already addressed in several works. In [8], different access control models are represented in C-Datalog (an object-oriented extension of Datalog) and compared using results from logic programming. In [26], the authors express access control systems as state transitions systems as we do and introduce security-preserving mappings, called reductions, to compare security analysis based on accessibility relations in two different models. In [11,18], the comparison mechanism is based on a notion of simulation. Thanks to the notion of environment transformation, we address this problem with an operational transition rules based approach. Contrary to the majority of papers previously cited, we have chosen to make a clear separation between systems and policies. This allows us to limit the class of expressible systems in order to increase the class of policies. More precisely, the environments that we consider must be characterized by a finite number of facts and of saturation rules and this may appear quite restrictive. In practice, however, standard security models are finite and use simple relations such as (total or partial) orders that can be easily modeled in our framework. These realistic limitations on the system specification offer us the possibility to significantly increase the class of security policies we can express because we benefit, in particular, from the expressive power of the first order formulas used to constrain the policy rules. Indeed, it is well known that the resolution of any first order formula in a finite model is equivalent to the resolution of a query in a database [13] and thus is effectively computable. As a matter of fact, we applied in this paper the principle of separation of concerns by defining for every concept (systems states, systems transitions, security policy, environment transformation) a specific language, with an appropriate, i.e. reality compliant, expressive power. The global expressive power is, in our opinion, more important and well-suited to real security requirements.

6 Conclusion and Future Work We proposed a framework which provides a common formalism for defining security signatures, environments, systems, and policy rules. We have shown that secured systems specified in this formalism have an operational semantics based on transition and rewriting systems and are thus executable. Such a formalism can be viewed as the definition of a mechanism allowing to constrain the executions of a transition system by applying a policy. As shown by our examples, this can be useful in the context of security, but such a mechanism can also be

Formal Specification and Analysis of Security Policies

161

considered when supervising a system for other purposes. Our framework also allows the definition of transformations of security signatures and environments and consequently, of secured systems. We defined a transformation operator and showed how it can be used to check security properties over the reachable environments of a secured system. This approach based on a transformation operator allows us to check some properties over a system even if these properties are expressed on a different signature (and/or specification). Our framework facilitates thus the reusability since the same specification of a security property can be used to check several policies and systems. It encourages also the specification of generic security properties dedicated to particular domains like, for example, information flows, and that can be used in different contexts. The operational nature of our formalism should lead to relatively direct implementations using rewrite based tools like Maude [12] or TOM [3] for example. The rule engine of Maude can then be used to simulate secured systems and their transformations and the integrated model-checker could be used to verify the corresponding properties. As future work, we aim to focus on the extension of the proposed transformation in order to define policies and systems on different signatures and to provide thus an enhanced modularity in formal developments. We also want to study how the transformation operators could be used for comparing and composing security policies and systems. Indeed, the comparison between two policies expressed as policy rules 1 and 2 , respectively based on the signatures Σ1 and Σ2 , is often based on an embedding of Σ1 -formulas into Σ2 -formulas. Such an approach can also be considered for systems, using transformations between environments to define a comparison mechanism. Similarly, for composition, transformation operators could be used to translate policies and systems into policies and systems sharing the same security signature and specification, thus easing the definition of a composition relation.

References 1. Alferes, J.J., Pereira, L.M., Przymusinska, H., Przymusinski, T.C.: LUPS - A Language for Updating Logic Programs. In: Gelfond, M., Leone, N., Pfeifer, G. (eds.) LPNMR 1999. LNCS (LNAI), vol. 1730, pp. 162–176. Springer, Heidelberg (1999) 2. Baader, F., Nipkow, T.: Term Rewriting and All That. Cambridge University Press (1998) 3. Balland, E., Brauner, P., Kopetz, R., Moreau, P.E., Reilles, A.: Tom: Piggybacking Rewriting on Java. In: Baader, F. (ed.) RTA 2007. LNCS, vol. 4533, pp. 36–47. Springer, Heidelberg (2007) 4. Barker, S.: Access Control for Deductive Databases by Logic Programming. In: Stuckey, P.J. (ed.) ICLP 2002. LNCS, vol. 2401, pp. 54–69. Springer, Heidelberg (2002) 5. Barker, S., Stuckey, P.J.: Flexible access control policy specification with constraint logic programming. ACM Transactions on Information and System Security 6(4), 501–546 (2003) 6. Becker, M.Y., Nanz, S.: A Logic for State-Modifying Authorization Policies. In: Biskup, J., L´opez, J. (eds.) ESORICS 2007. LNCS, vol. 4734, pp. 203–218. Springer, Heidelberg (2007) 7. Bell, D., LaPadula, L.: Secure Computer Systems: a Mathematical Model. Tech. Rep. MTR2547 (Vol. II), MITRE Corp., Bedford, MA (May 1973) 8. Bertino, E., et al.: A logical framework for reasoning about access control model. ACM Transactions on Information and System Security 6, 71–127 (2003) 9. Bourdier, T.: Specification, analysis and transformation of security policies via rewriting techniques. Journal of Information Assurance and Security 6(5), 357–368 (2011)

162

T. Bourdier et al.

10. Bourdier, T., Cirstea, H.: Constrained rewriting in recognizable theories. Tech. rep., INRIA (2010), http://hal.archives-ouvertes.fr/inria-00456848/en/ 11. Chander, A., Mitchell, J., Dean, D.: A state-transition model of trust management and access control. In: Proceedings of the 14th IEEE Computer Security Foundation Workshop CSFW, pp. 27–43. IEEE Comp. Society Press (2001) 12. Clavel, M., Dur´an, F., Eker, S., Lincoln, P., Mart´ı-Oliet, N., Meseguer, J., Talcott, C.: All About Maude - A High-Performance Logical Framework. LNCS, vol. 4350. Springer, Heidelberg (2007) 13. Codd, E.F.: Relational completeness of data base sublanguages. In: Rustin, R. (ed.) Database Systems, pp. 65–98. Prentice Hall (1972) 14. Damianou, N., et al.: A survey of policy specification approaches. Tech. rep., Department of Computing, Imperial College of Science Technology and Medicine, London, UK (2002), http://www.doc.ic.ac.uk/˜mss/Papers/PolicySurvey.pdf 15. Dougherty, D.J., Fisler, K., Krishnamurthi, S.: Specifying and Reasoning About Dynamic Access-Control Policies. In: Furbach, U., Shankar, N. (eds.) IJCAR 2006. LNCS (LNAI), vol. 4130, pp. 632–646. Springer, Heidelberg (2006) 16. Gelfond, M., Lifschitz, V.: Action languages. Electron. Trans. Artif. Intell. 2, 193–210 (1998) 17. George, L., Tˇong, V.V.T., M´e, L.: Blare Tools: A Policy-Based Intrusion Detection System Automatically Set by the Security Policy. In: Balzarotti, D. (ed.) RAID 2009. LNCS, vol. 5758, pp. 355–356. Springer, Heidelberg (2009) 18. Habib, L., Jaume, M., Morisset, C.: Formal definition and comparison of access control models. Journal of Information Assurance and Security 4(4), 372–381 (2009) 19. Hinman, P.: Fundamentals of mathematical logic. A.K. Peters, Ltd. (2005) 20. Jajodia, S., et al.: A unified framework for enforcing multiple access control policies. In: ACM SIGMOD International Conference on Management of Data, pp. 474–485. ACM (1997) 21. Jaume, M.: Security Rules Versus Security Properties. In: Jha, S., Mathuria, A. (eds.) ICISS 2010. LNCS, vol. 6503, pp. 231–245. Springer, Heidelberg (2010) 22. Jaume, M., Tˆong, V.V.T, M´e, L.: Contrˆole d’acc`es versus contrˆole de flots. In: Approches Formelles dans l’Assistance au D´eveloppement de Logiciels, pp. 27–41 (2010) 23. Kirchner, C., Kirchner, H., Santana de Oliveira, A.: Analysis of rewrite-based access control policies. In: Proceedings of the Third International Workshop on Security and Rewriting Techniques (SecReT 2008). ENTCS, vol. 234, pp. 55–75. Elsevier (2009) 24. Li, N., Tripunitara, M.V.: Security analysis in role-based access control. ACM Transactions on Information and System Security (TISSEC) 9(4), 391–420 (2006) 25. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role-based access control models. Computer 29, 38–47 (1996) 26. Tripunitara, M.V., Li, N.: A theory for comparing the expressive power of access control models. Journal of Computer Security 15(2), 231–272 (2007) 27. Ullman, J.: Database and Knowledge - Base Systems. Classical Database Systems, vol. 1. Computer Science Press (1988)

A Towards a Concrete Implementation The operational nature of our formalism leads to relatively direct implementations using rewrite based tools like Maude [12] or TOM [3] for example. We show in this section how the various notions introduced in the paper can be specified using a Maude-like syntax. First of all, the security signatures and environments used in Examples 1 and 2

Formal Specification and Analysis of Security Policies

163

are almost directly translated into an algebraic specification where the different sets are specified using subsorting and associative-commutative-idempotent operators: sorts S, O, A, L, Access,... subsort Access < AccessSet op root,... : -> S op PwdFile,... : -> O op secret,... : -> L op m : S O A -> Access op _<_ : L L -> Ord op _._ : AccessSet AccessSet -> AccessSet [assoc comm idem] op env : SLSet OLSet OrdSet AccessSet SSet SSet SSet -> Env ...

An environment specifies the levels of subjects and objects and the relationship between these levels as well as the set of current accesses and the sets of subjects which are sudo, redlisted and blacklisted. Policy rules like, for example, the fourth rule in Example 5 can be specified using a conditional rewrite rule whose left-hand side consists of a query and an evaluation environment and whose right-hand side is the corresponding decision. The constraint becomes a condition which is evaluated in the corresponding environment: ask(s,o,write) ; env

=> permit

if allReadInf(s,o,read,env)

with allReadInf specified by a set of rather obvious rules which use non-linear (anti-) patterns. We just show here the rule which specifies that a current access by a subject different from the one asking the access does not influence the final result: allInf(s,o,a,env(sl,ol,ord, ca1.m(!s,o’,a).ca2, ss,rl,bl)) => allInf(s,o,a,env(sl,ol,ord, ca1.ca2, ss,rl,bl))

The rules of the transition system in Example 2 can be also specified with conditional rewrite rules and, for example, the second rule of this system is encoded by the following rules: ask(s,o,a)/deny |env(sl,ol,ord,ca,ss,rl1.s.rl2,bl) => ask(s,o,a)/deny |env(sl,ol,ord,ca,ss,rl1.s.rl2,s.bl) ask(s,o,a)/deny |env(sl,ol,ord,ca1.m(s,o’,a’).ca2,sl,rl,s.bl) => ask(s,o,a)/deny |env(sl,ol,ord,ca1.ca2,sl,rl,s.bl) ask(s,o,a)/deny |env(sl,ol,ord,ca,sl,rl,bl) => ask(s,o,a)/deny |env(sl,ol,ord,ca,sl,s.rl,bl)

The system secured by the policy in Example 5 is obtained by adding the condition if ask(s,o,a) ; env(...) => deny to each of the above rules. The Maude strategy language should be used to guarantee that each of the rules is applied until a fix-point is reached. The transformations discussed in Section 4 are encoded in a similar way. Once we have implemented the various rules we can use, for example, the Maude command search for performing the reachability analysis described previously. The Maude tools (CRC, MTT) can be used to check the confluence and the termination of the rules encoding the policy and the LTL Maude module can be used to perform LTL model-checking.

Vote-Independence: A Powerful Privacy Notion for Voting Protocols Jannik Dreier, Pascal Lafourcade, and Yassine Lakhnech Universit´e Grenoble 1, CNRS, Verimag, France [email protected]

Abstract. Recently an attack on ballot privacy in Helios has been discovered [20], which is essentially based on copying other voter’s votes. To capture this and similar attacks, we extend the classical threat model and introduce a new security notion for voting protocols: Vote-Independence. We give a formal deﬁnition and analyze its relationship to established privacy properties such as Vote-Privacy, Receipt-Freeness and CoercionResistance. In particular we show that even Coercion-Resistant protocols do not necessarily ensure Vote-Independence. Keywords: Electronic Voting, Privacy, Anonymity, Security, Formal Veriﬁcation, Coercion-Resistance, Receipt-Freeness.

1

Introduction

Electronic voting schemes are systems that allow casting and tallying votes using machines. This promises to improve eﬃciency by providing results faster, using less personnel or adding comfort (e.g. the possibility to vote from home). However the recent use of commercial electronic voting systems for presidential or general elections in many countries has spread controversy on security issues [5,6,17,22]. Primary concerns are veriﬁability (the possibility to verify the elections’s outcome, i.e. to check if all votes have been counted correctly) and privacy (i.e. anonymity of the voter, secrecy of the vote). To address this issues, many diﬀerent protocols have been developed to fulﬁll security requirements such as – Eligibility: Only the registered voters can vote, and nobody can vote more than once. – Fairness: No preliminary results are available which could inﬂuence other voters’ decisions. – Individual Verifiability: Each voter can check whether his vote was counted correctly. – Universal Verifiability: Anybody can verify that the announced result corresponds to the sum of all votes. – Vote-Privacy: The votes are kept private.

This work was partially supported by the ANR project AVOTE. An extended version containing the detailed proofs is available as a technical report [9].

J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 164–180, 2012. c Springer-Verlag Berlin Heidelberg 2012

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

165

– Receipt-Freeness: A voter cannot construct a receipt which allows him to prove to a third party that he voted for a certain candidate. This is to prevent vote-buying. – Coercion-Resistance: Even when a voter interacts with a coercer during the entire voting process, the coercer cannot be sure whether the voter followed his instructions or actually voted for another candidate. – Robustness: The protocol should be able to tolerate a certain number of misbehaving voters. A common aim is to verify these properties using formal models and deﬁnitions. This concerns privacy properties (privacy, receipt-freeness and coercionresistance) [7,8,16], election veriﬁability [14,21], or both [11,12,13]. We concentrate on privacy-type properties of voting protocols (i.e. Vote-Privacy, ReceiptFreeness and Coercion-Resistance). While analyzing privacy in Helios [2], a web based voting system, B. Smyth and V. Cortier [19,20] recently discovered an attack based on the possibility for an attacker to copy another voter’s vote and to submit it as his own. If the number of participating voters is small or if a noticeable fraction of voters can be corrupted, this can break privacy as the contents of the vote can be inferred from the published election outcome. For example in the case of three voters (two honest ones and one under the control of the attacker), the attacker can try to copy the vote of the ﬁrst honest voter. The candidate chosen by the targeted voter will then have at least two votes, and can thus be recognized in the oﬃcial outcome. This reveals the content of the targeted vote. Our Contributions. Based on this attack, we extend the established threat model and give a formal deﬁnition for the notion of “Vote-Independence (VI)” in the applied pi calculus. We show that our deﬁnition of “Vote-Independence” implies Vote-Privacy as deﬁned in the literature [7] and that the concept can be generalized to improve Receipt-Freeness and Coercion Resistance as well. We deﬁne “Vote-Independence with passive Collaboration (VI-PC)” (which corresponds to Vote-Independence in same setting as Receipt-Freeness, i.e. with passive collaboration of the voter) and “Vote-Independence with active Collaboration (VI-AC)” (which corresponds to Coercion Resistance). We prove the hierarchy of the deﬁnitions and illustrate each level with a real world example: the protocol by Fujioka et al. [10] provides Vote-Independence (VI), the protocol due to Okamoto [18] ensures VI-PC, and the protocol by Bohli et al. [4] guarantees VI-AC. We also show that even Coercion-Resistant protocols may not ensure Vote-Independence (i.e. that our deﬁnitions are strictly stronger than the usual privacy notions) by analyzing the protocol by Lee at al. [15]. Outline of the Paper. The remainder of the paper is structured as follows. In Section 2, we recall the applied pi calculus and the standard privacy deﬁnitions. In Section 3 we elaborate our deﬁnitions of Vote-Independence. Then we analyze the hierarchy of our deﬁnitions, the relation to standard privacy properties and discuss several examples in Section 4. Finally, we conclude and discuss future work.

166

2

J. Dreier, P. Lafourcade, and Y. Lakhnech

Preliminaries

In this section we introduce the applied pi calculus, deﬁne our model of voting processes and recall existing privacy deﬁnitions. 2.1

The Applied Pi Calculus

We use the applied pi calculus [1] to model our security properties and the protocols to analyze. The calculus is an abstract language to describe concurrent processes and interactions, and is supported by the tool “ProVerif” [3]. The calculus consists of names (which typically correspond to data or channels), variables, and a signature Σ of function symbols which can be used to build terms. Functions typically include encryption and decryption (for example enc(message, key), dec(message, key)), hashing, signing etc. Terms are correct (i.e. respecting arity and sorts) combinations of names and functions. We distinguish the type “channel” from other base types. To model equalities we use an equational theory E which deﬁnes a relation =E . A classical example for symmetric encryption is dec(enc(message, key), key) =E message. Processes are constructed using the following grammar: P , Q, R :=

plain processes 0 null process P |Q parallel composition !P replication νn.P name restriction (“new”) if M = N then P else Q conditional in(u, x) message input out(u, x) message output

Active or extended processes are plain processes or active substitutions: A, B, C :=

active processes P plain process A|B parallel composition νn.A name restriction νx.A variable restriction {M/x} active substitution

The substitution {M/x} replaces the variable x with term M . We denote f v(A), bv(A), f n(A), bn(A) the free variables, bound variables, free names or bound names respectively. A process is closed if all variables are bound or deﬁned by an active substitution. The frame Φ(A) of an extended process A is obtained when replacing all plain processes in A by 0. This frame can be seen as a representation of what is statically know to the exterior about a process. The domain dom(Φ) of a frame Φ is the set of variables for which Φ deﬁnes a substitution. An evaluation context C[ ] denotes an extended process with a hole for an extended process.

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

167

The semantics of the calculus are given by Structural equivalence (≡), which is deﬁned as the smallest equivalence relation on extended processes that is closed under application of evaluation contexts, α-conversion on names and variables such that: PAR-0 A|0 ≡ A REPL !P ≡ P |!P PAR-A A|(B|C) ≡ (A|B)|C REWRITE {M/x} ≡ {N/x} PAR-C A|B ≡ B|A if M =E N NEW-0 νn.0 ≡ 0 ALIAS νx. {M/x} ≡ 0 NEW-C νu.νv.A ≡ νv.νu.A SUBST {M/x} |A ≡ {M/x} |A {M/x} NEW-PAR A|νu.B ≡ νu.(A|B) if u ∈ / f n(A) ∪ f n(b) and extended by Internal reduction (→), the smallest relation on extended processes closed under structural equivalence and application of evaluation contexts such that: COMM out(a, x).P | in(a, x).Q → P | Q THEN if M = M then P else Q → P ELSE if M = N then P else Q → Q for any ground terms such that M =E N To describe the interaction of processes with the exterior, we use labelled operaα tional semantics (− →) where α can be an input or the output of a channel name or a variable of base type: in(a,M)

in(a, x).P −−−−−→ P {M/x}

IN

out(a,u)

out(a, u).P −−−−−→ P

OUT-ATOM

out(a,u)

A −−−−−→ A

OPEN-ATOM

νu.A −−−−−−−→ A α → A u does not occur in α A−

SCOPE

α

α

PAR STRUCT

u = a

νu.out(a,u)

→A A−

νu.A − → νu.A bv(α) ∩ f v(B) = bn(α) ∩ f n(B) = ∅ α

A|B− → A | B α A≡B B− → B B ≡ A α

A− → A

Labelled transitions are not closed under the evaluation contexts. Note that a term M cannot be output directly, but only a variable as “reference” to it. This is to model that e.g. the output of enc(m, k) does not give the context access to m. In our deﬁnitions we use the following equivalence and bisimilarity properties: Definition 1 (Equivalence in a Frame). Two terms M and N are equal in the frame φ, written (M = N )φ, if and only if φ ≡ ν n ˜ .σ, M σ = N σ, and {˜ n} ∩ (f n(M ) ∪ f n(N )) = ∅ for some names n ˜ and some substitution σ.

168

J. Dreier, P. Lafourcade, and Y. Lakhnech

Definition 2 (Static Equivalence (≈s )). Two closed frames φ and ψ are statically equivalent, written φ ≈s ψ, when dom(φ) =dom(ψ) and when for all terms M and N (M = N )φ if and only if (M = N )ψ. Two extended processes A and B are statically equivalent (A ≈s B) if their frames are statically equivalent. The intuition behind this deﬁnition is simple: Two processes are statically equivalent if the messages exchanged with the environment cannot be distinguished by an attacker (i.e. all operations on both sides give the same results). This idea can be extended to labelled bisimilarity. Definition 3 (Labelled Bisimilarity (≈l )). Labelled bisimilarity is the largest symmetric relation R on closed extended processes, such that A R B implies 1. A ≈s B, 2. if A → A , then B → B and A R B for some B , α α → A and f v(α) ⊆ dom(A) and bn(α)∩f n(B) = ∅, then B →∗ − →→∗ B 3. if A − and A R B for some B . In this case each interaction on one side can be simulated by the other side, and the processes are statically equivalent at each step during the execution, thus an attacker cannot distinguish both sides. Labelled bisimilarity implies “classic” bisimilarity [1], but is often easier to prove and can be used to express many classical security properties, in particular anonymity properties. 2.2

Voting Process

We use the deﬁnition by Delaune et al. [7] to model voting protocols in the applied pi calculus. The basic idea is simple: A voting process is the parallel composition of all voters and the trusted authorities, whereas untrusted authorities are left to the context (i.e. the attacker). Messages are exchanged over public or private channels. We limit ourselves to protocols where each voter votes only once. Definition 4 (Voting Process [7]). A voting process is a closed plain process V P ≡ νn ˜ .(V σ1 | . . . |V σn |A1 | . . . |Am ). The V σi are the voter processes, the Aj s the honest election authorities, and the n ˜ are channel names. We also suppose that v ∈ dom(σi ) is a variable which refers to the value of the vote. We define an evaluation context S which is like V P , but has a hole instead of three V σi , and an evaluation context S which is like V P , but has a hole instead of two V σi . Note that S and S contain – by construction – only honest voters, i.e. voters that follow the protocol and do not collude with the attacker. 2.3

Privacy

Before discussing Vote-Independence, we recall the deﬁnition of the three basic privacy properties as given by Delaune et al. [7].

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

169

Vote-Privacy. The intuition for Vote-Privacy is the following: An attacker cannot distinguish two runs of the voting protocols where two voters swap their votes. This does not change the outcome and if the votes are private, the attacker should not know which vote belongs to which voter: Definition 5 (Vote-Privacy [7]). A voting process respects Vote-Privacy (P) if for all votes a and b S [VA {a/v } |VB {b/v}] ≈l S [VA {b/v} |VB {a/v}] Receipt-Freeness. To deﬁne Receipt-Freeness, we use the transformation P ch which can be applied to a process P . The transformed process outputs all its inputs and its private data (in particular new names, for example random values) on a special channel ch to the attacker. In the case of a voting process V , this corresponds to trying to create a receipt of the vote. If a protocol is receipt-free, a voter should be able to fake all these outputs to the coercer, i.e. to output fake values without the attacker noticing. This means that there should exist some process V so that the attacker is not able to distinguish between a successfully coerced voter V ch that votes c and outputs the correct values, and a voter V that fakes the values and votes a instead. To ensure that the coercer cannot tell both cases apart from the result, Delaune et al. introduce another voter that counterbalances the vote, and require that V actually votes for a using Deﬁnition 7. Definition 6 (Process P ch [7]). Let P be a plain process and ch be a channel name. We define P ch as follows: – – – – – – – – –

0ch = ˆ 0, (P |Q)ch = ˆ P ch |Qch , ˆ νn.out(ch, n).P ch when n is a name of base type, (νn.P )ch = (νn.P )ch = ˆ νn.P ch otherwise, (in(u, x).P )ch = ˆ in(u, x).out(ch, x).P ch when x is a variable of base type, ch (in(u, x).P ) = ˆ in(u, x).P ch otherwise, ch (out(u, M ).P ) = ˆ out(u, M ).P ch , ch ch (!P ) = ˆ !P , (if M = N then P else Q)ch = ˆ if M = N then P ch else Qch .

In the remainder we assume ch ∈ / f n(P ) ∪ bn(P ) before applying the transformation. Definition 7 (Process A\out(ch,·) [7]). Let A be an extended process. We define the process A\out(ch,·) as νch.(A|!in(ch, x)). Definition 8 (Receipt-Freeness [7]). A voting process respects Receipt-Freeness (RF) if there exists a closed plain process V such that for all votes a and c we have V \out(chc,·) ≈l VA {a/v} and

chc S VA {c/v } |VB {a/v} ≈l S [V |VB {c/v}]

170

J. Dreier, P. Lafourcade, and Y. Lakhnech

Coercion-Resistance. Similarly to Receipt-Freeness, Delaune et al. deﬁne a process that outputs all its inputs and secret values to the attacker. To express interactive coercion, it additionally waits for input from the context that tells it what to do before outputting values or branching (Deﬁnition 9). Definition 9 (Process P c1 ,c2 [7]). Let P be a plain process and c1 , c2 be channel names. We define P c1 ,c2 as follows: – – – – – – – – –

0c1 ,c2 = ˆ 0, (P |Q)c1 ,c2 = ˆ P c1 ,c2 |Qc1 ,c2 , c1 ,c2 (νn.P ) = ˆ νn.out(c1 , n).P c1 ,c2 when n is a name of base type, c1 ,c2 = ˆ νn.P c1 ,c2 otherwise, (νn.P ) (in(u, x).P )c1 ,c2 = ˆ in(u, x).out(c1 , x).P c1 ,c2 when x is a variable of base type and x is a fresh variable, (in(u, x).P )c1 ,c2 = ˆ in(u, x).P c1 ,c2 otherwise, c1 ,c2 (out(u, M ).P ) = ˆ in(c2 , x).out(u, x).P c1 ,c2 , c1 ,c2 c1 ,c2 = ˆ !P , (!P ) (if M = N then P else Q)c1 ,c2 = ˆ in(c2 , x).if x = true then P c1 ,c2 c1 ,c2 else Q where and x is a fresh variable and true is a constant.

The deﬁnition then follows the same basic idea as for Receipt-Freeness: there exists a process V that can interact with the attacker and fake all necessary messages without the attacker noticing. Yet one has to add some condition to ensure that the attacker cannot distinguish both sides of the bisimilarity simply based on the result by forcing the coerced voter to vote d, which would change the outcome. Tho enforce this, Delaune et al. use a context C that models the part of the attacker which interacts with VA . The conditions on C ensure that the attacker actually forces the voter to vote c, and not d and thus make sure the vote is counterbalanced by VB . Definition 10 (Coercion-Resistance [7]). A voting process respects CoercionResistance (CR) if there exists a closed plain process V such that for any C = c ,c νc1 .νc2 .( |P ) satisfying n ˜ ∩ f n(C) = ∅ and S [C [VA {?/v} 1 2 ] |VB {a/v}] ≈l S VA {c/v}chc |VB {a/v} we have for all votes a and c C [V ] and

c1 ,c2

S [C [VA {?/v }

\out(chc,·)

≈l VA {a/v }

] |VB {a/v}] ≈l S [C [V ] |VB {c/v }]

Note that we write {?/v} to represent the fact that the coerced voters vote does not depend on the substitution, but on the interaction with the context C.

3

Vote-Independence

In the previous privacy deﬁnitions the attacker has the role of an outside observer that tries to infer something about someone’s vote. In the case of CoercionResistance or Receipt-Freeness he might communicate with the targeted voter,

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

171

but he cannot necessarily vote himself or collude with other voters - unlike what would generally happen in real-world elections. To address this shortcoming and obtain a more realistic model of the attacker’s abilities, we introduce the notion of Vote-Independence for diﬀerent levels of collaboration. The idea is to extend the existing deﬁnitions to the case where the attacker can vote himself and might try to relate his vote to the vote of a targeted voter to compromise privacy (for example copy it as in the attack by B. Smyth and V. Cortier [20]). 3.1

Vote-Independence (without Collaboration)

Definition 11 (Vote-Independence). A voting process respects Vote - Independence (VI) if for all votes a and b S [VA {a/v} |VB {b/v} |VCc1 ,c2 ] ≈l S [VA {b/v } |VB {a/v} |VCc1 ,c2 ] The intuition behind our deﬁnition is the following: We start from the deﬁnition of privacy, but add a voter under the control of the attacker in both cases. If an attacker can relate his vote to the vote of one of the voters (for example copy VA ’s vote, i.e. vote for the same candidate), he will be able to distinguish both sides as the result of the vote will be diﬀerent. This is the most basic deﬁnition, as the attacker has only access to publicly available data. Subsequently we add the possibility of collaborating voters. Smyth and Cortier [20] used a similar idea in a recent extension to their original paper. Contrary to our deﬁnition, they implicitly include corrupted voters in the context S (or S resp.). We chose to make the corrupted voter explicit to be able to easily compare both notions. 3.2

Vote-Independence with Passive Collaboration

Definition 12 (Vote-Independence with Passive Collaboration). A voting process respects Vote-Independence with Passive Collaboration (VI-PC) if there exists a closed plain process V such that for all votes a and c V \out(chc,·) ≈l VA {a/v} and

chc S VA {c/v} |VB {a/v } |VCc1 ,c2 ≈l S [V |VB {c/v } |VCc1 ,c2 ]

Vote-Independence with Passive Collaboration can be seen analogously to ReceiptFreeness. The attacker should not be able to link his vote to another voter’s vote, even if this voter collaborates with him and gives him access to his secret values after voting (secret keys, random values, nonces, etc.). This is ensured in the deﬁnition as the attacker cannot decide if he is in a case where the attacked voter actually collaborates with him, or if the voter only pretends to collaborate and in reality votes diﬀerently. If he could use the information provided by the attacked voter to e.g. copy his vote, he would be able to distinguish these cases.

172

3.3

J. Dreier, P. Lafourcade, and Y. Lakhnech

Vote-Independence with Active Collaboration

Definition 13 (Vote-Independence with Active Collaboration). A voting process respects Vote-Independence with Active Collaboration (VI-AC) if there exists a closed plain process V such that for all votes a and c and for any C = νc1 .νc2 .( |P ) satisfying n ˜ ∩ f n(C) = ∅ and c ,c chc S [C [VA {?/v} 1 2 ] |VB {a/v} |VCc3 ,c4 ] ≈l S VA {c/v} |VB {a/v} |VCc3 ,c4 we have

C [V ]

\out(chc,·)

≈l VA {a/v }

and c1 ,c2

S [C [VA {?/v}

] |VB {a/v} |VCc3 ,c4 ] ≈l S [C [V ] |VB {c/v} |VCc3 ,c4 ]

In this deﬁnition, the attacker is even more powerful. Similarly to CoercionResistance, he can interact with the attacked voter during the entire voting process.

4 4.1

Hierarchy and Relation to Privacy Hierarchy

Intuitively, V I − AC is a stronger property than V I − P C, which is a stronger property than V I. The following proposition conﬁrms this intuition: Proposition 1. We have: – If a protocol respects Vote-Independence with Active Collaboration, it also respects Vote-Independence with Passive Collaboration. – If a protocol respects Vote-Independence with Passive Collaboration, it also respects Vote-Independence (without collaboration). The detailed proofs can be found in our technical report [9]. 4.2

Relation to Privacy

The only diﬀerence between P and V I (or V I − P C and RF , or V I − AC and CR) is the process VCc1 ,c2 , i.e. the existence of a legitimate voter that is under control of the attacker. Intuitively this gives the attacker more power and thus V I (or V I − P C or V I − AC) should be the stronger property. Indeed: Proposition 2. We have: – If a protocol respects Vote-Independence, it also respects Vote-Privacy. – If a protocol respects Vote-Independence with Passive Collaboration, it also respects Receipt-Freeness. – If a protocol respects Vote-Independence with Active Collaboration, it also respects Coercion-Resistance.

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

173

Informally we can argue that any attack on Vote-Privacy can be used to break Vote-Independence. In this case the voter under control of the attacker simply behaves as a normal voter and the intruder can employ the same attack. The formal proof is given in our technical report [9]. CR ⇒ RF ⇒ P has been shown in the literature [7]. 4.3

The Global Picture

Taking these properties together, we obtain the following hierarchy of notions. A ⇒ B means that any protocol ensuring property A also ensures property B.

CR [15]

⇐ ⇒

⇓⇑

RF

⇓⇑ ⇐ ⇒

⇓⇑

P

VI-AC [4] VI-PC [18] ⇓⇑

⇐ ⇒

VI [10]

The cited protocols [4,10,15,18] illustrate the hierarchy and show that the inverse implications are not true, as discussed below. 4.4

Example: FOO

The protocol by Fujioka et al. [10] is based on commitments and blind signatures. It was proven to respect Vote-Privacy (P ) [7], but is not Receipt-Free (RF ) as the randomness of the commitment can be used as a receipt. We show that it ensures Vote-Independence (V I). Informal Description. The protocol is split in three phases. In the ﬁrst phase, the voter obtains the administrator’s signature on a commitment to his vote: – Voter Vi chooses his vote vi and computes a commitment xi = ξ(vi , ki ) for a random key ki . – He blinds the commitment using a blinding function χ, a random value ri and obtains ei = χ(xi , ri ). – He signs ei and sends the signature si = σVi (ei ) together with ei and his identity to the administrator. – The administrator checks if Vi has the right to vote, has not yet voted, and if the signature si is correct. If all tests succeed, he signs di = σA (ei ) and sends it back to Vi . – Vi unblinds the signature and obtains yi = δ(di , ri ). He checks the signature.

174

J. Dreier, P. Lafourcade, and Y. Lakhnech

In the second phase, the actual voting takes place: – Voter Vi sends (xi , yi ) to the collector C through an anonymous channel. – The collector checks the administrator’s signature and enters (xi , yi ) into a list. When all ballots are cast or when the deadline is over, the counting phase begins: – The collector publishes the list of correct ballots. – Vi veriﬁes that his commitment appears on the list and sends ri together with the commitment’s index l on the list to C using an anonymous channel. – The collector C opens the l-th ballot using ri and publishes the vote. Model in Applied Pi Calculus. Our model is based on the one developed in [7], but we add a third voter. We use the following equational theory: open(commit(m, r), r) = m checksign(sign(m, sk), pk(sk)) = m unblind(blind(m, r), r) = m unblind(sign(blind(m, r), sk), r) = sign(m, sk) The complete model can be found in our technical report [9]. Analysis Proposition 3. FOO respects Vote-Independence (V I). Proof. Similarly to the proof of Vote-Privacy by [7], we do not need to trust any authority except for the key distribution process. Thus the voter VCc1 ,c2 under control of the attacker only interacts with the attacker (as untrusted authorities are left to the context, i.e. the attacker), except during the key distribution process at the beginning. In this process he obtains his key (which we do not require to be secret) and the administrator’s public key, which is available to the attacker anyway. Thus the attacker is essentially in the same situation as in the proof of Vote-Privacy. The full proof can be found in our technical report [9]. Note that this protocol cannot respect Vote-Independence with Passive or Active Collaboration (V I − P C or V I − AC), as this would imply Receipt-Freeness (see the hierarchy). This shows that V I ⇒ V I − P C. 4.5

Example: Okamoto

The protocol by Okamoto [18] uses trap-door commitments to achieve receiptfreeness [7]. However it is not Coercion-Resistant (CR) [7]. Informal Description. The protocol is very similar to the one by Fujioka et al. [10] discussed above. The only diﬀerence is the use of a trap-door commitment

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

175

and a timeliness member to open the commitments. The ﬁrst phase - during which the voter obtains a signature on his commitment - follows the same protocol, except for the fact that this time ξ is a trapdoor-commitment. In the second phase the actual voting takes place: – Voter Vi sends the signed trap-door commitment to the collector C through an anonymous channel. – The collector checks the administrator’s signature and enters (xi , yi ) into a list. – The voter sends (vi , ri , xi ) to the timeliness member through an untappable anonymous channel When all ballots are cast or when the deadline is over, the counting phase begins: – The collector publishes the list of correct ballots. – Vi veriﬁes that his commitment appears on the list. – The timeliness member publishes a randomly shuﬄed list of votes vi and a zero-knowledge proof that he knows a permutation π for which xπ(i) = ξ(vi , ri ). Model in Applied Pi Calculus. Our model is based on the model used in [7], but we add a third voter. It is based on the following equational theory: open(tdcommit(m, r, td), r) = m tdcommit(m1 , r, td) = tdcommit(m2 , f (m1 , r, td, m2 ), td) checksign(sign(m, sk), pk(sk)) = m unblind(blind(m, r), r) = m unblind(sign(blind(m, r), sk), r) = sign(m, sk) The ﬁrst equation models the creation of a trap-door commitment to m using a random value r and a trap-door td, whereas the second equation allows the construction of another random value to open a commitment diﬀerently. This requires knowledge of the trap-door td and the initial random value r. Analysis Proposition 4. The protocol by Okamoto respects V I − P C. Proof. To prove this, we need to ﬁnd a process V that successfully fakes all secrets to a coercer. In addition to normal receipt-freeness, we also have to ensure that the attacker cannot use the secrets to e.g. copy the vote of the targeted voter. In this protocol the trap-door commitment allows the voter to return a faked random number to the attacker which opens the commitment to any value the voter wants. This means that - although the attacker has access to the commitment and the necessary values to open it - he will always open it in a way

176

J. Dreier, P. Lafourcade, and Y. Lakhnech

that yields a vote for c due to the fake randomness, even if the voter actually committed to a. The same reasoning applies for copying votes: Although it is technically possible to copy the vote of the targeted voter, the voter will provide a faked random value, which will make the timeliness member open the vote as a vote for c. This makes it impossible for the attacker to know if the voter complied with his instructions or only pretended to do so, even if he tries to relate his vote to the targeted voter’s vote. The detailed model and complete proof can be found in our technical report [9]. Thus the protocol also respects simple Vote-Independence (V I). Note that this protocol cannot respect Vote-Independence with Active Collaboration (V I − AC), as this would imply Coercion-Resistance. This shows that V I − P C ⇒ V I − AC. 4.6

Example: Bingo Voting

Bingo Voting was developed by Bohli et al. [4] to achieve coercion-resistance as well as individual and universal veriﬁability by using a trusted random number generator (RNG). We use Bingo Voting to illustrate the existence of protocols that respect Vote-Independence with active Collaboration (V I − AC). Informal Description. We consider an election with k voters and l candidates. The protocol is split into three phases: The pre-voting phase, the voting phase and the post-voting phase. In the pre-voting phase, the voting machine generates k random values ni,j for every candidate pj (the dummy votes). It commits to the k · l pairs (ni,j , pj ) and publishes the shuﬄed commitments. In the voting phase, the voter enters the voting booth and selects the candidate he wants to vote for on the voting machine. The RNG generates a random number r, which is transmitted to the voting machine and displayed to the voter. The voting machine chooses for each candidate a dummy vote, except for the voter’s choice. For this candidate, the random value from the RNG is used and the receipt (a list of all candidates and the corresponding random numbers) is created. Finally, the voter checks that the number displayed on the RNG corresponds to the entry of his candidate on the receipt. In the post-voting phase, the voting machine announces the result, publishes all receipts and opens the commitments of all unused dummy votes. The machine also generates non-interactive zero-knowledge proofs that each unopened commitment was actually used as a dummy vote in one of the receipts. Model in Applied Pi Calculus. As we are only interested in privacy, we ignore the zero-knowledge proofs which are necessary to achieve veriﬁability. This yields a very simple equational theory: open(commit(m, r), r) = m We assume the voting machine to be honest, otherwise no privacy can be guaranteed as the vote is submitted in clear by the voter. The detailed model can be found in the technical report [9].

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

177

Analysis Proposition 5. Bingo Voting respects V I − AC. Proof. The receipts contain only random values which makes it impossible for the attacker to know if a certain number corresponds to the random value by the RNG or a dummy vote. Thus the voter V does not even have to fake a receipt, he can simply forward his receipt and claim he voted for the coercer’s choice. Constructing a related vote based on the receipt is not possible either since - while voting - the attacker has to transmit his choice in clear to the voting machine. Being able to e.g. copy VA ’s vote would imply the break of simple privacy on the voter’s vote using the receipt. The complete proof can be found in our technical report [9]. This implies that Bingo Voting is coercion resistant and provides Vote-Independence. 4.7

Example: Lee et al.

The protocol by Lee et al. [15] was proven to be Coercion-Resistant (CR) in [7], but does not respect Vote-Independence (V I) – and thus neither V I − P C nor V I − AC – as we show. It is based on trusted devices that re-encrypt ballots and use designated veriﬁer proofs (DVPs) to prove their correct behavior to the voter. Informal Description. We simpliﬁed the protocol to focus on the important parts with respect to privacy and vote-independence. For example, we do not consider distributed authorities. – The administrator sets up the election, distributes keys and registers legitimate voters. Each voter is equipped with his personal trusted device. At the end, he publishes a list of legitimate voters and corresponding trusted devices. – The voter encrypts his vote with the tallier’s public key (using the El Gamal scheme), signs it and sends it to his trusted device over a private channel. The trusted device veriﬁes the signature, re-encrypts and signs the vote, and returns it, together with a DVP that the re-encryption is correct, to the voter. The voter veriﬁes the signature and the proof, double signs the ballot and publishes it on the bulletin board. – The administrator veriﬁes for all ballots if the voter has the right to vote and if the vote is correctly signed. He publishes the list of correct ballots, which is then shuﬄed by the mixer. – The tallier decrypts the mixed votes and publishes the result. Model in Applied Pi Calculus. Our model is based on the one developed in [7], but we add a third (corrupted) voter and an explicit mixing stage. This stage

178

J. Dreier, P. Lafourcade, and Y. Lakhnech

was left out in their model, but is essential to highlight the diﬀerence between Vote-Privacy and Vote-Independence. We use the following equational theory: decrypt(penc(m, pk(sk), r), sk) = m checksign(sign(m, sk), pk(sk)) = m rencrypt(penc(m, pk(sk), r1), r2) = penc(m, pk(sk), f (r1, r2)) checkdvp(dvp(x, rencrypt(x, r), r, pk(sk)), x, rencrypt(x, r), pk(sk)) = ok checkdvp(dvp(x, y, z, skv), x, y, pk(skv)) = ok Analysis. In the extended model, the protocol by Lee et al. still ensures (CR), but it is not (V I). Proposition 6. The protocol by Lee et al. does not respect Vote-Independence (V I). Proof. As acknowledged by the authors in their original paper [15], it is possible to copy votes. More precisely, an attacker can access the ballots on the bulletin board before the mixing takes place. He can easily verify which ballot belongs to which voter as they are signed by the voters themselves. He can remove the signature and use the ciphertext as an input to his trusted device. The trusted device will re-encrypt and sign it. This allows the attacker to construct a correct ballot which contains the same vote as the targeted honest voter. This obviously contradicts vote-independence. Our technical report [9] shows how this can be seen in the formal model. This example shows that vote-independence properties are strictly stronger than the corresponding privacy properties (CR ⇒ V I − AC, RF ⇒ V I − P C, P ⇒ V I), as even a coercion-resistant protocol fails to respect simple voteindependence.

5

Conclusion

Inspired by an attack based on copying votes, we extended the classical threat model and developed the notion of “Vote-Independence”. We gave a formal deﬁnition and showed that it is stronger than standard vote-privacy. We generalized the deﬁnition to passive and active collaboration, and obtained reﬁned properties on the same attack level as receipt-freeness and coercion-resistance. Subsequently we analyzed practical examples which illustrate that our property is strictly stronger, i.e. that even coercion resistant protocols can fail with respect to Vote-Independence, and thus of practical interest. Future Work. We plan to translate our symbolic deﬁnition to the computational model and extend our analysis e.g. to accommodate protocols permitting multiple votes. Additionally, it would be desirable to develop tools that at least partly automate and/or verify the necessary proofs.

Vote-Independence: A Powerful Privacy Notion for Voting Protocols

179

References 1. Abadi, M., Fournet, C.: Mobile values, new names, and secure communication. In: Proceedings of the 28th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL 2001, pp. 104–115. ACM, New York (2001) 2. Adida, B., De Marneﬀe, O., Pereira, O., Quisquater, J.-J.: Electing a university president using open-audit voting: analysis of real-world use of helios. In: Proceedings of the 2009 Conference on Electronic Voting Technology/Workshop on Trustworthy Elections, EVT/WOTE 2009, p. 10. USENIX Association, Berkeley (2009) 3. Blanchet, B., Abadi, M., Fournet, C.: Automated veriﬁcation of selected equivalences for security protocols. Journal of Logic and Algebraic Programming 75(1), 3–51 (2008) 4. Bohli, J.-M., M¨ uller-Quade, J., R¨ ohrich, S.: Bingo Voting: Secure and CoercionFree Voting Using a Trusted Random Number Generator. In: Alkassar, A., Volkamer, M. (eds.) VOTE-ID 2007. LNCS, vol. 4896, pp. 111–124. Springer, Heidelberg (2007) 5. UK Electoral Commission. Key issues and conclusions: May 2007 electoral pilot schemes, http://www.electoralcommission.org.uk/elections/pilots/May2007 6. Bundesverfassungsgericht (Germanys Federal Constitutional Court). Use of voting computers in 2005 bundestag election unconstitutional (March 2009), press release 19/2009, http://www.bundesverfassungsgericht.de/en/press/bvg09019en.html 7. Delaune, S., Kremer, S., Ryan, M.: Verifying privacy-type properties of electronic voting protocols. Journal of Computer Security 17, 435–487 (2009) 8. Delaune, S., Kremer, S., Ryan, M.D.: Verifying Privacy-Type Properties of Electronic Voting Protocols: A Taster. In: Chaum, D., Jakobsson, M., Rivest, R.L., Ryan, P.Y.A., Benaloh, J., Kutylowski, M., Adida, B. (eds.) Towards Trustworthy Elections. LNCS, vol. 6000, pp. 289–309. Springer, Heidelberg (2010) 9. Dreier, J., Lafourcade, P., Lakhnech, Y.: Vote-independence: A powerful privacy notion for voting protocols. Technical Report TR-2011-8, Verimag Research Report (April 2011), http://www-verimag.imag.fr/TR/TR-2011-8.pdf 10. Fujioka, A., Okamoto, T., Ohta, K.: A Practical Secret Voting Scheme for Large Scale Elections. In: Zheng, Y., Seberry, J. (eds.) AUSCRYPT 1992. LNCS, vol. 718, pp. 244–251. Springer, Heidelberg (1992) 11. Juels, A., Catalano, D., Jakobsson, M.: Coercion-resistant electronic elections, Cryptology ePrint Archive, Report 2002/165 (2002), http://eprint.iacr.org/ 12. Juels, A., Catalano, D., Jakobsson, M.: Coercion-resistant electronic elections. In: Proceedings of the 2005 ACM Workshop on Privacy in the Electronic Society, WPES 2005, pp. 61–70. ACM, New York (2005) 13. Kremer, S., Ryan, M.: Analysis of an Electronic Voting Protocol in the Applied Pi Calculus. In: Sagiv, M. (ed.) ESOP 2005. LNCS, vol. 3444, pp. 186–200. Springer, Heidelberg (2005) 14. Kremer, S., Ryan, M., Smyth, B.: Election Veriﬁability in Electronic Voting Protocols. In: Gritzalis, D., Preneel, B., Theoharidou, M. (eds.) ESORICS 2010. LNCS, vol. 6345, pp. 389–404. Springer, Heidelberg (2010) 15. Lee, B., Boyd, C., Dawson, E., Kim, K., Yang, J., Yoo, S.: Providing ReceiptFreeness in Mixnet-Based Voting Protocols. In: Lim, J.-I., Lee, D.-H. (eds.) ICISC 2003. LNCS, vol. 2971, pp. 245–258. Springer, Heidelberg (2004)

180

J. Dreier, P. Lafourcade, and Y. Lakhnech

16. Moran, T., Naor, M.: Receipt-Free Universally-Veriﬁable Voting with Everlasting Privacy. In: Dwork, C. (ed.) CRYPTO 2006. LNCS, vol. 4117, pp. 373–392. Springer, Heidelberg (2006) 17. Participants of the Dagstuhl Conference on Frontiers of E-Voting. Dagstuhl accord (2007), http://www.dagstuhlaccord.org/ 18. Okamoto, T.: An electronic voting scheme. In: Proceedings of the IFIP World Conference on IT Tools, pp. 21–30 (1996) 19. Smyth, B., Cortier, V.: Attacking and ﬁxing helios: An analysis of ballot secrecy. In: Accepted at CSF 2011 (2011) 20. Smyth, B., Cortier, V.: Attacking and ﬁxing helios: An analysis of ballot secrecy. Cryptology ePrint Archive, Report 2010/625 (2010), http://eprint.iacr.org/ 21. Smyth, B., Ryan, M.D., Kremer, S., Kourjieh, M.: Towards Automatic Analysis of Election Veriﬁability Properties. In: Armando, A., Lowe, G. (eds.) ARSPA-WITS 2010. LNCS, vol. 6186, pp. 146–163. Springer, Heidelberg (2010) 22. Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (Netherland’s Ministry of the Interior and Kingdom Relations). Stemmen met potlood en papier (voting with pencil and paper) (May 2008), press release, http://www.minbzk.nl/ onderwerpen/grondwet-en/verkiezingen/nieuws--en/112441/stemmen-metpotlood

Black-Box Property of Cryptographic Hash Functions Michal Rjaˇsko Department of Computer Science Faculty of Mathematics, Physics and Informatics Comenius University Mlynsk´ a dolina, 842 48 Bratislava, Slovak Republic [email protected]

Abstract. We deﬁne a new black-box property of cryptographic hash function families H : {0, 1}K × {0, 1}∗ → {0, 1}y which guarantees that for a randomly chosen hash function HK from the family, everything “non-trivial” we are able to compute having access to the key K, we can compute only with oracle access to HK . If a hash function family is pseudo-random and has the black-box property then a randomly chosen hash function HK from the family is resistant to all non-trivial types of attack. We also show that the HMAC domain extension transform is PrfBB preserving, i.e. if a compression function f is pseudo-random and has the black-box property (Prf-BB for short) then HMACf is Prf-BB. On the other hand we show that the Merkle-Damg˚ ard construction is not Prf-BB preserving. Finally we show that every pseudo-random oracle preserving domain extension transform is Prf-BB preserving and viceversa. Hence, Prf-BB seems to be an all-in-one property for cryptographic hash function families, which guarantees their “total” security. Keywords: cryptographic hash function, pseudo-randomness, collision resistance, domain extension transform.

1

Introduction

The primary security property of cryptographic hash functions has historically been collision resistance. For a collision resistant hash function F : {0, 1}∗ → {0, 1}y it is hard to ﬁnd a pair of messages (M, M ) such that F (M ) = F (M ). Currently used hash functions, such as the SHA family or MD5, are designed using the Merkle-Damg˚ ard (MD) construction [7,10]. The MD construction is a domain extension transform, i.e. it extends a domain of a ﬁxed-input-length (FIL) compression function f : {0, 1}(y+d) → {0, 1}y to a variable-input-length (VIL) hash function F . The key security feature of the MD construction is that it preserves collision resistance. If the compression function f is collision resistant, then so is the resulting hash function F .

Research supported by VEGA grant No. 1/0266/09 and Comenius University grant No. UK/429/2010.

J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 181–193, 2012. c Springer-Verlag Berlin Heidelberg 2012

182

M. Rjaˇsko

However, collision resistance is not enough to prove the security of many important applications which involve hash functions. A cryptographic hash function should have “random” behavior, which collision resistance alone cannot ensure. Moreover, for several of the applications (e.g. RSA-FDH) no standard model security property suﬃcient for proving their security has been found. On the other hand, no realistic attacks against these applications have been found. Hence, Bellare and Rogaway [4] introduced a so called random oracle model, which models a hash function as a publicly available random function (random oracle). Using this framework, one can prove the security of many important schemes. A proof in the random oracle model does not guarantee security when we replace the random oracle with a real hash function [5]. However, such a proof is believed to ensure that there are no structural ﬂaws in the scheme and thus one can heuristically hope that the scheme remains ﬂawless when the random oracle is replaced with a “well designed” hash function. Real hash functions are often built using some smaller components such as compression function in the case of the MD construction. On the other hand, in the random oracle model, hash functions are modeled as a monolithic oracle without any subcomponents. In order to avoid such a contrast between theory and practice, Maurer, Renner and Holenstein introduced the indiﬀerentiability framework [9] and consequently Coron et. al deﬁned a property for hash functions called pseudo-random oracle [6]. If a hash function F is pseudo-random oracle then it is indiﬀerentiable from the random oracle. Hence, F can be used in any cryptosystem instead of the random oracle without loosing the security. The pseudo-random oracle property assumes that a hash function is built from a publicly available FIL random function f (compression function). Thus, the pseudo-random oracle property still requires the random oracle model. It is hard to deﬁne collision resistance for hash functions in the standard model. Due to the pigeonhole principle, each hash function with domain greater than its range has a pair of messages which map to the same image. A potential adversary attacking a hash function can have such a pair hardwired into its code, so that its description is simple and it runs very fast. Hence, formal deﬁnitions of security properties for cryptographic hash function are often made in the dedicated-key settings [2,12]. A hash function with a dedicated-key input is called a hash function family (i.e. H : {0, 1}k × {0, 1}∗ → {0, 1}y ), a particular hash function from the family is selected by a key K (K ∈ {0, 1}k ). In the dedicatedkey settings, a potential adversary has to ﬁnd a collision for a hash function HK randomly chosen from the family. Our contributions. In this paper we introduce a black-box (BB) property for hash function families. If a hash function family H : {0, 1}k ×{0, 1}∗ → {0, 1}y has the BB property, then everything “non-trivial” we are able to compute having access to the randomly chosen key K, we are able to compute only with oracle access to the hash function HK . A “non-trivial” thing we deﬁne as an information which is hard to compute for a random oracle. Clearly, the BB property is not suﬃcient for “good” cryptographic hash functions. Moreover, the BB property can be

Black-Box Property of Cryptographic Hash Functions

183

easily achieved by a hash function family, which “reveals” its key (e.g. a family for which HK (0) = K). On the other hand, we show that a pseudo-random hash function family with the BB property (a Prf-BB hash function family for short) is resistant to all “non-trivial” attacks. For a Prf-BB hash function family, the pseudo-randomness ensures that without access to a randomly chosen key K, one cannot distinguish HK from a random oracle. Additionally, the blackbox property ensures that access to the key K does not reveal any “useful” information about the structure of HK . We show that the MD construction does not preserve the Prf-BB property. On the other hand, we show that the HMAC construction [1,6] is Prf-BB preserving. Moreover we show that every pseudo-random oracle preserving domain extension transform is Prf-BB preserving and vice-versa. Hence Prf-BB property can be seen as a replacement of the pseudo-random oracle property, which is deﬁned only in the random oracle model (since pseudo-random oracle assumes that a hash function is build from an ideal compression function). Since Prf-BB is deﬁned in the standard model, it is a good candidate to become a new primary security goal for hash function families. Organization. In Section 2 we introduce some useful notations and deﬁnitions. In Section 3 we deﬁne the black-box property and show that a randomly chosen hash function from a Prf-BB hash function family is resistant to all “non-trivial” types of attack. Next, in Section 4 we show that the MD construction is not PrfBB preserving. The proof that the HMAC construction is Prf-BB preserving is in Section 5. In Section 6 we show the equivalence between pseudo-random oracle preserving domain extension transforms and Prf-BB preserving domain extension transforms.

2

Preliminaries $

We write M ←S for the uniform random selection of M from the ﬁnite set S. Concatenation of ﬁnite strings M1 and M2 is denoted by M1 ||M2 or simply M1 M2 , M denotes bitwise complement of the string M . The i-th bit of a string d M is M [i], thus M = M [1]|| · · · ||M [|M |]. By M1 , . . . , Ml ← M , where M is a string, is denoted the following semantics: 1. Pad M with the suﬃx pad := 1||0d−((|M|+1) mod d) 2. Parse the string M ||pad into M1 , M2 , . . . Ml , where |Mi | = d for 1 ≤ i ≤ l. It must hold that M1 ||M2 || . . . ||Ml = M ||pad. Let Func(D, R) represent the set of all functions ρ : D → R and let RFD,R be $

a function chosen randomly from the set Func(D, R) (i.e. RFD,R ←Func(D, R)). We sometimes write RFd,r or Func(d, r) when D = {0, 1}d and R = {0, 1}r . Similarly, we write RF∗,r or Func(∗, r) when D = {0, 1}∗ and R = {0, 1}r . If i is an integer, then ir is r-bit string representation of i. If r is omitted, then i is the shortest string representation of i (e.g. if i = 3, then i = 11).

184

M. Rjaˇsko

Hash function family. Let n ∈ N be a security parameter. A variable input length hash function family is a function H : {0, 1}k × {0, 1}∗ → {0, 1}y computable in a polynomial time, where k, y ∈ N. In the rest of this paper we assume that k, y are polynomially related to the security parameter n (i.e. k = p1 (n) and y = p2 (n) for some polynomials p1 , p2 ). We will often write the ﬁrst argument to H as a subscript, i.e. HK (M ) := H(K, M ). A ﬁxed input length hash function family is a function H : {0, 1}k × {0, 1}m → {0, 1}y , where k, m, y ∈ N are polynomially related to the security parameter n. Negligible function. A function f is negligible if for every polynomial p(·) there 1 . Negligible functions exists N such that for every n > N it holds that f (n) < p(n) are denoted as negl(·). Interactive Turing machines. An interactive Turing machine (ITM) T accepts inputs via input tape, performs some local computations and outputs via output tape. An ITM T can have “oracle” access to several other ITMs T1 , . . . , Tl . The communication between T and T1 , . . . , Tl is performed via “oracle” input tapes t1 , . . . , tl and output tapes t1 , . . . , tl . Whenever T writes some input on the tape ti , the ITM Ti is invoked on that input and its output is written on the oracle output tape ti . We call such an operation a query to the oracle Ti . All queries are performed in unit time (i.e. computation of Ti is not counted into T ’s running time). By T T1 ,...,Tl we denote that the ITM T has oracle access to T1 , . . . , Tl . Each ITM can implement various interfaces (f1 , f2 , . . . ). An interface speciﬁes what needs to be written on the input type to invoke particular functionality of the ITM. We write T = (f1 , f2 , . . . ) meaning that T implements interfaces f1 , f2 , . . . . We sometimes distinguish between private and public interfaces of an ITM T . In this case we write T = ((f1 , f2 , . . . ), (f1 , f2 , . . . )), where f1 , f2 , . . . are private interfaces and f1 , f2 , . . . are public. We write P Tpub to denote that an ITM P has oracle access only to public interfaces of an ITM T . Adversary. An adversary is a probabilistic polynomial-time ITM. Running time of an adversary A is the expected running time of A plus the description size of A (hence one cannot precompute some large amount of information and store it into A’s description). Running time of an adversary is polynomial in length of its inputs and the security parameter n. Without loss of generality we assume that an adversary always stop and returns some output. Games. A game GO,A is a probabilistic polynomial ITM which output is always a bit b ∈ {0, 1}. If b = 1 we say that the adversary A won the game G for the oracle O. If b = 0 we say that A lost the game G for O. In this paper we focus on the games with the ﬁrst oracle being a hash function or a hash function family. Example 1. Let H : {0, 1}k × {0, 1}∗ → {0, 1}y be a hash function family, and let GCR be the following algorithm:

Black-Box Property of Cryptographic Hash Functions

185

Game GCR GCR has access to H(·, ·) and adversary A(·) 1. 2. 3. 4.

$

choose K ←{0, 1}k query A(K) → (M, M ) if M = M and H(K, M ) = H(K, M ) return 1 otherwise return 0.

The game GCR represents the well known collision resistance experiment for the hash function family H. If no polynomial adversary A can win the game GCR for H with non-negligible probability we say H is collision resistant. Note that we can deﬁne games also for all other standard properties of hash function families like preimage resistance, second-preimage resistance, their everywhere and always versions [12], unforgeability, etc. Example 2. The following game GCRF for a hash function F : {0, 1}∗ → {0, 1}y is an “unkeyed” adaptation of the game GCR from the Example 1. Game GCRF GCRF has access to F (·) and adversary A 1. query A → (M, M ) 2. if M = M and F (M ) = F (M ) return 1 3. otherwise return 0. Note that for all hash functions F there exists an eﬃcient adversary A which returns a collision for F . Since there exists collisions in F , A just needs to have one of the collisions hardwired into its description. Hence, we cannot deﬁne collision resistance for hash functions. A hash function F : {0, 1}∗ → {0, 1}y and a hash function family H : {0, 1}k × {0, 1}∗ → {0, 1}y can represent the same function ρ(K, M ) = F (K||M ) = H(K, M ). Hence, when considering an arbitrary game G, we cannot tell whether it treats it’s oracle as a hash function (e.g. GCRF ) or hash function family (e.g. GCR ). This is undesirable in some cases, where we want to utilize advantages of hash function families (e.g. ability to deﬁne collision resistance). Because of this, in the following deﬁnitions of a non-trivial game and the black-box property, we make a random choice of a key before the game starts. Then the game G is given access to the hash function HK chosen randomly from the family H : {0, 1}k × {0, 1}∗ → {0, 1}y (but K is not given to G). Thus, we can utilize the advantages of hash function families and we don’t restrict how games should treat their oracle. Non-trivial games. There are games, which are easy to win (e.g. a game which always returns 1) and games which cannot be won (a game always returning 0). Informally, a trivial game G is a game, which utilizes adversary’s knowledge of the key so that it can be won for a keyed random function. Our formal deﬁnition follows.

186

M. Rjaˇsko

Definition 1 (Non-trivial game). Let F : {0, 1}k × {0, 1}∗ → {0, 1}y be a publicly available random function. Game G is non-trivial if for all adversaries A there exists a simulator S and a negligible function negl such that K $ negl(n) ≥ Pr F ← RFk×∗,y ; K ←{0, 1}k ; GFK ,A → 1 FK $ → 1 . − Pr F ← RFk×∗,y ; K ←{0, 1}k ; GFK ,S Where the probabilities are taken over random choice of F , random selection of the key K and random coins of G and A (S in the second experiment). If F is a fixed input length (FIL) keyed random function (F : {0, 1}k × {0, 1}m → {0, 1}y ) then we say that G is non-trivial for FIL hash functions. Note that the game GCRF deﬁned in the Example 2 is non-trivial. The game GCR expects its oracle H to be a hash function family, i.e. a function with two inputs K and M . If we modify the game GCR so that it expects H to be a function only with one input K||M then GCR is also non-trivial. Example 3. The following game GkeyGuess is an example of a trivial game (i.e. a game which is not non-trivial). The game is parametrized by a hash function family H : {0, 1}k × {0, 1}∗ → {0, 1}y , from which a hash function HK is chosen uniformly randomly. Game GkeyGuess (H) GkeyGuess has access to HK (·) and adversary AK for randomly chosen $

key K ←{0, 1}k . 1. query AK → K $ 2. choose M ←{0, 1}m for some integer m. 3. if HK (M ) = HK (M ) return 1. 4. otherwise return 0. There exists an adversary AK which ﬁnds the correct key for all functions HK . The adversary AK asks its oracle for the key K and outputs the same. Hence, AK wins GkeyGuess (F ) for a random function F and thus violates the Deﬁnition 1. Remark 1. Trivial games represent those kinds of attack, which are not important for us. For a trivial game G, there is an attacker which is able to win the game against keyed random oracle given access to a key. Since random oracle is “unbreakable” hash function, it must be the case that there is something “trivial” in the game G.

3

The Black-Box Property

Let H : {0, 1}k × {0, 1}∗ → {0, 1}y be a hash function family, G be a game, A an adversary and S a simulator. We deﬁne the following experiment:

Black-Box Property of Cryptographic Hash Functions

187

Experiment HashBB(H, G, A, S) 1. 2. 3. 4. 5.

$

choose K ←{0, 1}k K run GHK ,A → b HK run GHK ,S → b if b = b return 1 otherwise return 0

Definition 2 (Black-box property). We say that the hash function family H : {0, 1}k × {0, 1}∗ → {0, 1}y has the black-box property if for all non-trivial games G, all adversaries A there exist a polynomial simulator S and a negligible function negl, such that Pr HashBB(H, G, A, S) = 1 ≤ negl(n). Remark 2. Informally, if a hash function family H has the black-box property, everything “non-trivial” we are able to compute having access to the randomly chosen key K, we are able to compute only with oracle access to the hash function HK . There exist hash function families, which have the black-box property “trivially”. Let H : {0, 1}k ×{0, 1}∗ → {0, 1}y be a hash function family and let H be deﬁned as: K if M = 0 HK (M ) = HK (M ) otherwise Hence, a simulator S HK can query HK (0) and it receives the key K. If S knows the key K, it can simulate an adversary A and thus it can compute the same as AK can. Therefore the black-box property alone is not enough for “strong” cryptographic hash function family. Pseudo-randomness. A hash function family is pseudo-random, if a randomly chosen hash function from the family is indistinguishable from the random function. More formally, let H : {0, 1}k × {0, 1}∗ → {0, 1}y be a hash function family and let $ $ k HK F (A) := ←{0, 1} ; A → 1 − Pr F ←RF ; A → 1 AdvPrf Pr K ∗,y H We say that the hash function family H is a pseudo-random function (Prf), if for all adversaries A there exists a negligible function negl, such that AdvPrf H (A) ≤ negl(n). Definition 3. We say that a hash function family H is Prf-BB if it is a pseudorandom function and has the black-box property. Remark 3. It remains an open problem, whether Prf-BB hash function family exists. However, for the existence of a Prf-BB hash function family it is crucial that games like the key guessing game GkeyGuess deﬁned in the Example 3 are not non-trivial. If games, which can be won only by “simple utilization” of knowledge

188

M. Rjaˇsko

of the key K (e.g. GkeyGuess ), would be non-trivial, then no hash function family with the black-box property could be pseudo-random. Let H be a hash function family with the black-box property and assume that GkeyGuess is non-trivial. Since H has the black-box property for all adversaries A there exists a simulator S such that for a randomly chosen key K with a non-negligible probability holds K

HK

HK ,S K ,A GH keyGuess = GkeyGuess . K

K ,A However, there exists an adversary AK which wins the game GH keyGuess for all keys K (it just outputs the key it has as an oracle). Hence there exists a simulator H K ,S K S HK which wins the game GH keyGuess with non-negligible probability. But then, HK

K ,S the algorithm D := GH keyGuess can distinguish HK from a random function. What means that H cannot be pseudo-random. The fact that we consider only non-trivial games seems to be crucial for satisﬁability of the Prf-BB property. It is possible that in order to prove the existence of Prf-BB hash function families one has to come up with a stronger notion of the non-trivial game.

In the following theorem we show, that a randomly chosen hash function HK from the Prf-BB hash function family is as resistant as the random oracle to all types of attacks which can be represented by a non-trivial game GHK . Theorem 1. Let H : {0, 1}k × {0, 1}∗ → {0, 1}y be a Prf-BB hash function family and G be a non-trivial game. Then for all adversaries A there exists a polynomial simulator S and a negligible function negl such that F $ $ k H ,AK → 1 − Pr F ←RF∗,y ; GF ,S → 1 ≤ negl(n). Pr K ←{0, 1} ; G K

Proof. See the full version of this paper [11].

4

Merkle-Damg˚ ard and the Black-Box Property

In this section we show that the well known Merkle-Damg˚ ard domain extension transform does not preserve the black-box property. Merkle-Damg˚ ard construction. The strengthened Merkle-Damg˚ ard domain extension transform (SMD) operates in the following way (see ﬁg. 1). Algorithm SMDf (K, M ) the algorithm has oracle access to f : {0, 1}k ×{0, 1}y ×{0, 1}d → {0, 1}y . d 1. (M1 , . . . , Ml ) ← M 2. Ml+1 ← |M |d 3. Y0 ← IV 4. for i = 1 to l + 1 do 5. Yi ← fK (Yi−1 , mi ) 6. return Yl

Black-Box Property of Cryptographic Hash Functions

189

By SMDf we denote the hash function family created by the SMD domain extension transform from the compression function f : {0, 1}k × {0, 1}d × {0, 1}y → {0, 1}y . We often write SMDfK (·) instead of SMDf (K, ·). If g : {0, 1}d ×{0, 1}y → {0, 1}y is an unkeyed compression function, then SMDg denotes a hash function created by the unkeyed SMD construction. Note that SMDf as deﬁned above can process messages only of length up to d 2 bits. We can modify the algorithm SMDf so that it can process messages of arbitrary length. In the rest of this section we will assume that SMDf can process messages of arbitrary length, but to simplify the presentation we consider that processed messages are of length at most 2d bits. M0 IV

f

K

M1 Y1

f

Y2

...

Yl-1

K

Ml

|M|

f

f

K

K

Y

Fig. 1. Merkle-Damg˚ ard domain extension transform

Theorem 2. Let f : {0, 1}k × {0, 1}(y+d) → {0, 1}y be a compression function which is Prf-BB. Then the hash function family SMDf : {0, 1}k × {0, 1}∗ → {0, 1}y does not have the black-box property. Proof. See the full version of this paper [11].

5

HMAC Is Prf-BB Preserving Domain Extension Transform

In this section we show that the HMAC domain extension transform (ﬁg. 2) is Prf-BB preserving. Algorithm HMACf (K, M ) the algorithm has oracle access to f : {0, 1}k ×{0, 1}y ×{0, 1}d → {0, 1}y . d 1. (M1 , . . . , Ml ) ← M 2. Y0 ← IV0 3. for i = 1 to l do 4. Yi ← fK (Yi−1 , mi ) 5. if y < d then Y := Yl ||0d−y 6. else Y := Yl [0]|| . . . ||Yl [d] 7. Y → fK (IV1 , Y ) 8. return Y

190

M. Rjaˇsko

By HMACf we denote the hash function family created by the HMAC domain extension transform from the compression function f . We often write HMACfK (·) instead of HMACf (K, ·). If g : {0, 1}d × {0, 1}y → {0, 1}y is an unkeyed compression function, then HMACg denotes a hash function created by the unkeyed HMAC construction. M0

IV0

f

K

M1 Y1

f

Ml Y2

...

Yl-1

K

f

K

IV1

f

Y

K Fig. 2. HMAC domain extension transform

In the Lemma 1 we show that for a Prf compression function f , all games G and all simulators S there exists a simulator S such that G cannot distinguish f whether it is interacting with HMACfK and S fK or HMACfK and S HMACK . In other words, if f is pseudo-random then S is able to simulate fK using HMACfK for randomly chosen key K ∈ {0, 1}k . Lemma 1. Let f : {0, 1}k × {0, 1}(y+d) → {0, 1}y be a compression function which is Prf. Then for all games G and all simulators S there exists a simulator S and a negligible function negl(n) such that f fK $ negl(n) ≥ Pr[K ←{0, 1}k ; GHMACK ,S → 1] f f HMAC $ K − Pr[K ←{0, 1}k ; GHMACK ,S → 1] Proof. See the full version of this paper [11]. Theorem 3. Let f : {0, 1}k × {0, 1}(y+d) → {0, 1}y be a compression function which is Prf-BB. Then HM AC f : {0, 1}k × {0, 1}∗ → {0, 1}y is Prf-BB. Proof. See the full version of this paper [11].

6

Prf-BB and Pseudo-random Oracle

Pseudo-random oracle. Pseudo-random oracle (Pro) [2,3,6] is a property of cryptographic hash functions based on the indiﬀerentiability framework introduced

Black-Box Property of Cryptographic Hash Functions

191

by Maurer, Renner and Holenstein [9]. A hash function F g : {0, 1}∗ → {0, 1}y based on an ideal compression function g is pseudo-random oracle if it is indifferentiable from a random oracle. More formally, let F g ,g AdvPro (A) := ; A → 1 Pr g ← RF y+d,y F,S F − Pr F ← RF∗,y ; AF ,§ → 1 We say that a hash function F g : {0, 1}∗ → {0, 1}y based on an ideal compression function g is pseudo-random oracle if for all adversaries A there exists a polynomial simulator S and a negligible function negl such that AdvPro F,S (A) ≤ negl(n). The property Pro is meaningful only in the random-oracle model. Since F is based on an “uncertain” random compression function g, the Pro is rather a property of domain extension transforms. We say that F is Pro preserving domain extension transform if F g is Pro. Thus F securely extends the domain of the ﬁxed-input length random oracle g to the variable-input length pseudo-random oracle. This is also the reason why we do not deﬁne the pseudorandom oracle property for hash function families. Given a domain extension transform F g : {0, 1}∗ → {0, 1}y we can construct a hash function family H : {0, 1}k × {0, 1}∗ → {0, 1}y by replacing g with a keyed compression function fK . However, if fK is not random, the security of the resulting hash function family is uncertain [3]. In this section we show that every Pro preserving domain extension transform is also Prf-BB preserving and vice-versa. Hence Prf-BB can be seen as a “standard-model” equivalent to the Pro property, which is deﬁned only in the random-oracle model. We prove this equivalence in the following two theorems. Theorem 4. Let F be a domain extension transform, which is Prf-BB preserving. Then F is Pro preserving. Proof. See the full version of this paper [11]. Theorem 5. Let F be a domain extension transform, which is Pro preserving. Then F is Prf-BB preserving. The proof of this theorem is similar to the proof of the Theorem 3. See the full version of this paper [11] for the complete proof. Remark 4. It is possible to modify the pseudo-random oracle property so that the modiﬁed property is deﬁned in the standard model. Let F be a domain extension transform and f : {0, 1}k × {0, 1}y+d → {0, 1}y be a compression function. Let H be a hash function family, such that HK (M ) := F fK (M ). Let $ k HK ,fK Pr K (A) := ←{0, 1} ; A → 1 AdvPro2 H,f,S F − Pr F ← RF∗,y ; AF ,§ → 1

192

M. Rjaˇsko

We say that a hash function family H is Pro2 if for all adversaries A there exists a polynomial simulator S and a negligible function negl such that AdvPro2 H,f,S (A) ≤ negl(n). However, such modiﬁed Pro2 property does not guarantee security against all non-trivial games as the Prf-BB does. Since the adversary A does not have access to the key, the Pro2 property does not guarantee security against games, which give to an adversary an access to the key (e.g. collision resistance – the game GCR deﬁned in the Section 2). If we modify the Pro2 property so that A has access to the key, then no hash function will satisfy this property.

7

Conclusion

In this paper we introduced the black-box property for hash function families, which guarantees that for a hash function family H : {0, 1}k × {0, 1}∗ → {0, 1}y everything “non-trivial” we are able to compute with access to a randomly chosen key K is possible to compute only with oracle access to the hash function HK . We showed that a pseudo-random hash function family with black-box property (Prf-BB) is resistant to all “non-trivial” types of attack. We proved that the Merkle-Damg˚ ard construction is not Prf-BB preserving and conversely that the HMAC construction is Prf-BB preserving. Moreover we proved that every pseudo-random oracle preserving domain extension transform is Prf-BB preserving and vice-versa. We believe that a Prf-BB property is all-in-one property – it guarantees “total” security of a hash function family and should be a primary security goal for designers of hash functions. A natural and interesting question is whether a Prf-BB hash function family exists. A combination of pseudo-random and collision resistant hash function families H(K1 , K2 , M ) := H1 (K1 , H2 (K2 , M )), where H1 is pseudo-random and H2 is collision resistant seems to be a good candidate. The collision resistant hash function family H2 ensures that a potential adversary A is unable to arbitrarily select inputs to the pseudo-random hash function family H1 . Hence H2 minimizes adversary’s ability to utilize the key K1 . The pseudo-randomness of H1 guarantees that the output of H1 has random behavior and hides possible “non-random” behavior of H2 .

References 1. Bellare, M., Canetti, R., Krawczyk, H.: Keying Hash Functions for Message Authentication. In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 1–15. Springer, Heidelberg (1996) 2. Bellare, M., Ristenpart, T.: Hash Functions in the Dedicated-Key Setting: Design Choices and MPP Transforms. In: Arge, L., Cachin, C., Jurdzi´ nski, T., Tarlecki, A. (eds.) ICALP 2007. LNCS, vol. 4596, pp. 399–410. Springer, Heidelberg (2007)

Black-Box Property of Cryptographic Hash Functions

193

3. Bellare, M., Ristenpart, T.: Multi-Property-Preserving Hash Domain Extension and the EMD Transform. In: Lai, X., Chen, K. (eds.) ASIACRYPT 2006. LNCS, vol. 4284, pp. 299–314. Springer, Heidelberg (2006) 4. Bellare, M., Rogaway, P.: Random oracles are practical: a paradigm for designing eﬃcient protocols. In: 1st ACM Conference on Computer and Communications Security, pp. 62–73. ACM (1993) 5. Canetti, R., Goldreich, O., Halevi, S.: The random oracle methodology, revisited. Journal of the ACM 51(4), 557–594 (2004) 6. Coron, J.-S., Dodis, Y., Malinaud, C., Puniya, P.: Merkle-Damg˚ ard Revisited: How to Construct a Hash Function. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 430–448. Springer, Heidelberg (2005) 7. Damg˚ ard, I.B.: A Design Principle for Hash Functions. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 416–427. Springer, Heidelberg (1990) 8. Dodis, Y., Ristenpart, T., Shrimpton, T.: Salvaging Merkle-Damg˚ ard for Practical Applications. In: Joux, A. (ed.) EUROCRYPT 2009. LNCS, vol. 5479, pp. 371–388. Springer, Heidelberg (2009) 9. Maurer, U., Renner, R., Holenstein, C.: Indiﬀerentiability, Impossibility Results on Reductions, and Applications to the Random Oracle Methodology. In: Naor, M. (ed.) TCC 2004. LNCS, vol. 2951, pp. 21–39. Springer, Heidelberg (2004) 10. Merkle, R.C.: One Way Hash Functions and DES. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 428–446. Springer, Heidelberg (1990) 11. Rjaˇsko, M.: Black-Box Property of Cryptographic Hash Functions. Cryptology ePrint Archive, Report 2010/631 12. Rogaway, P., Shrimpton, T.: Cryptographic Hash-Function Basics: Deﬁnitions, Implications, and Separations for Preimage Resistance, Second-Preimage Resistance, and Collision Resistance. In: Roy, B., Meier, W. (eds.) FSE 2004. LNCS, vol. 3017, pp. 371–388. Springer, Heidelberg (2004)

Phishing Detection with Popular Search Engines: Simple and Eﬀective Jun Ho Huh1 and Hyoungshick Kim2 1

Information Trust Institute, University of Illinois at Urbana-Champaign, US [email protected] 2 Computer Laboratory, University of Cambridge, UK [email protected]

Abstract. We propose a new phishing detection heuristic based on the search results returned from popular web search engines such as Google, Bing and Yahoo. The full URL of a website a user intends to access is used as the search string, and the number of results returned and ranking of the website are used for classiﬁcation. Most of the time, legitimate websites get back large number of results and are ranked ﬁrst, whereas phishing websites get back no result and/or are not ranked at all. To demonstrate the eﬀectiveness of our approach, we experimented with four well-known classiﬁcation algorithms – Linear Discriminant Analysis, Na¨ıve Bayesian, K-Nearest Neighbour, and Support Vector Machine – and observed their performance. The K-Nearest Neighbour algorithm performed best, achieving true positive rate of 98% and false positive and false negative rates of 2%. We used new legitimate websites and phishing websites as our dataset to show that our approach works well even on newly launched websites/webpages – such websites are often misclassiﬁed in existing blacklisting and whitelisting approaches. Keywords: Phishing detection, URL Reputation, Classiﬁcation.

1

Introduction

Phishing attacks are pre-dominant in today’s web. The Anti-Phishing Working Group (APWG) reported that there were at least 126,697 phishing attacks in the second half of 2009, almost doubling the number of attacks counted in the ﬁrst half [1]. A lot of these attacks entice people into visiting fraudulent websites that impersonate trusted entities, and persuade them to disclose their private information such as passwords and bank account details. Figure 1 shows an example of a phishing website posing as Facebook; notice how the URL in the red box (http://h1.ripway.com/riki123/index.html) is completely diﬀerent to the original URL. Some of the widely available and used phishing detection techniques include whitelisting [2], blacklisting [19], and heuristics [3,16,7,24,22]. Although blacklisting is eﬀective in detecting known-bad phishing websites, it can be weak against detecting new ones. It is also diﬃcult to eﬃciently update and verify the website entries of central databases. J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 194–207, 2012. c Springer-Verlag Berlin Heidelberg 2012

Phishing Detection with Popular Search Engines: Simple and Eﬀective

195

Fig. 1. Example of a phishing website

Whitelisting, on the other hand, is eﬀective against new phishing websites since only those considered ‘trusted’ are accessed by users. However, it is somewhat difﬁcult to know exactly which new legitimate websites a user will visit next and have these entries added to the whitelist prior to their visit. If the coverage of the whitelist is insuﬃcient, it can incur a signiﬁcant usability penalty. It is this usability concern that currently discourages many users from using the whitelists. Heuristic-based techniques look for common characteristics of phishing websites. Since these techniques do not rely on central databases being up-to-date, they can be more eﬀective against detecting new phishing websites. Nevertheless, heuristics will inherently incur false positives and false negatives, and there is always a room for phishers to design their websites to bypass the heuristics that are being checked. This paper proposes a novel phishing detection method that uses the reputation of a website for classiﬁcation. Our intuition is based on the observation that (1) the reputation of a legitimate website will grow over time unlike a phishing website, and (2) a webpage’s reputation can be measured approximately by querying popular search engines with its full URL and analysing the returned results. In particular, the number of results returned and ranking of the website give good indication as to what the nature of the website is. Our approach has two key advantages: (1) it can be very eﬀective against new websites since the web search engines crawl and cache hundreds and thousands of new and old webpages per second; (2) it is simple to implement and deploy. To demonstrate feasibility, we evaluated performance of four well-known classiﬁcation algorithms, Linear Discriminant Analysis, Na¨ıve Bayesian, K-Nearest Neighbour, and Support Vector Machine, on three diﬀerent search engines, Google1 , Bing2 and Yahoo3 . 1 2 3

http://www.google.co.uk/ http://www.bing.com/ http://uk.yahoo.com/

196

J.H. Huh and H. Kim

The next section gives an overview of how our approach works. In Section 3, we introduce the four classiﬁcation algorithms. Then, in Section 4, we discuss the feasibility of our approach based on the experiment results, and recommend how it should be used in practice. Some related work is discussed in Section 5. Finally, we conclude in Section 6.

2

Phishing Detection with Popular Search Engines

The key idea is simple: a user’s trusted application queries a popular web search engine using the full URL of a website she intends to access (e.g. “http://www. example.com” would be your search string), and analyses the ‘number of results’ returned and ‘ranking’ of the website to make a decision. As with any other heuristic-based methods, a system designed to use our approach can be fully automated. When the user tries to visit a website, her trusted application – this could be a web browser plug-in or a built-in feature – will ﬁrst submit a search query to a web search engine using the full URL string without parameters; for example, if the user wishes to access “http://www.facebook. com/profile.php?id=12345”, then the concatenated string “http://www. facebook.com/profile.php” will be submitted. From the returned search results, the application will fetch two attributes: the ‘number of results’ and ‘ranking’ of the queried URL; and use this information to determine whether the website is legitimate. The ranking is measured by looking at where the queried URL appears on the returned results: ranking n implies that the URL appears as the nth result. Most of the time, legitimate websites that are safe for users to browse and match are ranked ﬁrst; phishing websites, on the other hand, have lower ranking or are not ranked at all. Legitimate websites also have larger number of search results compared to phishing websites. This can be explained by the long-lived nature of legitimate websites and the growing number of in-links as oppose to the short-lived nature of phishing websites and the small number of in-links (usually none) they have. Figure 2 shows the diﬀerences between the search results returned from Google when queried with (a) the original URL of Facebook and (b) URL of its phishing website. When a search engine is queried with a URL, it ranks a cached/indexed website very high, often ﬁrst, if this website’s URL exactly matches the queried URL. Our approach fully exploits this aspect of search engines to accurately identify even the recently published legitimate websites that do not have many in-links, or long-lived legitimate websites that are unpopular and have small number of in-links. Moreover, new legitimate websites tend to build their reputation more quickly. Table 1 compares how the reputation of new legitimate websites and phishing websites change on Google over a period of 5 days – day 1 being the ﬁrst day that a website/webpage was created. New webpages published through well-known websites like BBC and Amazon were used to observe the trends for the legitimate websites. As for the phishing websites, 5 most recently listed on an online

Phishing Detection with Popular Search Engines: Simple and Eﬀective

(a) Facebook

197

(b) A phishing website

Fig. 2. Diﬀerences in the search results returned from Google when queried with the original URL of Facebook and the URL of its phishing website. With the original URL, the ‘number of results’ returned is 2,340,000,000 and the website is ranked ﬁrst, while it is only 3 for the phishing website which is not ranked at all. Table 1. How the reputation of new Legitimate Websites (LWs) and Phishing Websites (PWs) change on Google over 5 days

LW1 LW2 LW3 LW4 LW5

No. of results Ranking No. of results Ranking No. of results Ranking No. of results Ranking No. of results Ranking

D-1 7 1 2 2 3 1 6 1 1 1

D-2 41 1 8 1 35 1 268 1 4 1

D-3 D-4 48 79 1 1 9 9 1 1 39 90 1 1 158 289 1 1 1 1 1 1

D-5 105 1 9 1 83 1 308 1 2 1

P W1 P W2 P W3 P W4 P W5

D-1 1 0 2 0 3 0 2 0 2 0

D-2 1 0 5 0 3 0 4 0 4 0

D-3 0 0 3 0 2 0 3 0 3 0

D-4 D-5 0 0 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0

phishing URL database called ‘PhishTank’4 were used. Even during this short period of time, we observed that the number of results for legitimate websites increased more quickly and they were all ranked ﬁrst from the second day onward. In contrast, the phishing websites had fairly static, small number of results and were never ranked on Google. Our approach uses such distinct characteristics between the two groups to measure their reputation and classify them. After collecting the two information, the user’s trusted application processes them using the pre-generated classiﬁer to determine the nature of the website. If the website is likely to be a phishing website, the user is given a warning message to deal with; otherwise, the user is free to access the website. In the next two sections, we describe four diﬀerent classiﬁcation methods that may be used to train a classiﬁer, and demonstrate how each method performs on the search results returned from three popular search engines, Google, Bing and Yahoo. 4

http://www.phishtank.com

198

3

J.H. Huh and H. Kim

Applying Classiﬁcation Methods

Given a set of search results for the website URLs, our problem can be reduced to a classification problem: the input will be a set of training samples in the form of nu , ru , cu for a URL, u, where nu , ru , and cu are the ‘number of results’ returned, ‘ranking’ of the website, and ‘indicator’ that shows whether u belongs to a phishing website, respectively. cu will be TRUE if u belongs to a phishing website; otherwise, it will be FALSE. A classiﬁcation method should be carefully selected based on constraints such as the desired level of accuracy, time available for development and training, and nature of classiﬁcation problems. We carried out a number of experiments to evaluate four diﬀerent classiﬁcation methods and to ﬁnd the best performing (most suitable) one. This section introduces these classiﬁcation methods and the experiment results are discussed in Section 4. 3.1

Linear Discriminant Analysis

Linear Discriminant Analysis (LDA) is a powerful tool for dimensionality reduction and classiﬁcation [8]. Given a set of search results, LDA ﬁnds a linear transformation of the training samples with nu and ru that best discriminates between legitimate and phishing websites. LDA performs well if the features of the dataset are linearly independent. So we expect LDA to be suﬃcient for detecting phishing websites since nu and ru between legitimate and phishing websites are likely to be discriminated linearly. 3.2

Na¨ıve Bayesian Classification

Na¨ıve Bayesian (NB) classiﬁcation algorithm [6,21] is one of the most successful learning algorithms for text categorisation. Based on the Bayes rule, which assumes conditional independence between classes, this algorithm attempts to estimate the conditional probabilities of classes given an observation. The joint probabilities of sample observations and classes are simpliﬁed because of the conditional independence assumption. While this Bayes rule assumption is often violated in practice, NB is known to perform well in many existing applications [17]. 3.3

K-Nearest Neighbour Classification

K-Nearest Neighbour (KNN) classiﬁcation is a non-parametric classiﬁcation algorithm. KNN has been applied successfully to various information retrieval problems. KNN uses an integer parameter K. Given a search result for a URL, u, the algorithm ﬁnds K, the closest training data that points to this result, and uses the majority vote to determine whether the website with u is a phishing website. Without any prior knowledge, the KNN classiﬁer usually applies Euclidean distances as the distance metric. This simple method can often yield competitive results even compared to other sophisticated machine learning methods. The

Phishing Detection with Popular Search Engines: Simple and Eﬀective

199

performance of KNN is primarily determined by the choice of K as well as the distance metric applied [13]. However, choosing a suitable K value is not easy when the points are not uniformly distributed [5]. 3.4

Support Vector Machines

Support Vector Machine (SVM) [20,4] is known as one of the best supervised learning techniques for solving classiﬁcation problems with high dimensional feature space and small training set size. The idea is to ﬁnd the optimal separating hyperplanes that classify data by maximising the geometric margin space between the classes’ closest points. SVM is receiving great attention due to some excellent performance it has achieved on real-world applications [9].

4

Experiment Results

The aim of our experiment was to demonstrate feasibility and eﬀectiveness of our approach, and determine the best performing classiﬁcation method. We tested with real legitimate websites and phishing websites, querying three popular search engines, Google, Bing and Yahoo. The dataset (search results) collected was then trained and classiﬁed using the four classiﬁcation algorithms described above (LDA, NB, KNN, and SVM). 4.1

Description of the Dataset

We quickly noticed that the search results returned for highly targeted websites (e.g. banks, online payment services, and social networks) were strongly distinct from those returned for phishing websites. So rather than investigating the well-established ones (which are relatively easy to classify), we focused more on analysing the performance of classifying new websites/webpages: the legitimate websites we used were only a few days or weeks old, and the phishing websites were a few hours old. Note, based on our original intuition about the growing reputation of legitimate websites (see Section 1), this relatively new dataset represents the worst case scenarios in the experiment; we expect more established websites such as banks to have more distinct characteristics from the phishing websites. We tested our approach under several conditions by changing the search engines and query string formats. The dataset is summarised as follows: – legitimate websites – 100 URLs of recently launched websites were collected from ‘New Websites’5 , which is a showcase for the latest websites; – phishing websites – 100 URLs of the latest phishing websites were collected from two well-known online phishing URL databases (50 from each), ‘Artists Against 419’6 which contains phishing URLs as well as other forms of scams, and ‘PhishTank’7 which only contains phishing URLs. 5 6 7

http://www.newlywebsite.com http://www.aa419.org http://www.phishtank.com

J.H. Huh and H. Kim

Ranking

8 6 4

10 8 6 4

2

2

0 0

0 0

1000 2000 3000 4000 5000

Number of Results

(a) Google L P

Ranking

8 6 4

Number of Results

4

1000 2000 3000 4000 5000

L P

4

0 0

1000 2000 3000 4000 5000

Number of Results

(c) Yahoo

6

2

(d) Google(h)

6

0 0

1000 2000 3000 4000 5000

8

0 0

L P

8

2

10

2

Number of Results

10

(b) Bing

Ranking

10

L P

Ranking

L P

10

L P

8

Ranking

10

Ranking

200

6 4 2

1000 2000 3000 4000 5000

Number of Results

(e) Bing(h)

0 0

1000 2000 3000 4000 5000

Number of Results

(f) Yahoo(h)

Fig. 3. Scatter plot graphs showing the collected search results. X-axis and Y -axis represent the ‘number of results’ returned and ‘ranking’ of the website, respectively.

We tested the three search engines individually (Google, Bing, Yahoo) and also observed the performance of combining all of the results together (All). With All, a total of six attributes, two from each search engine, were used for classiﬁcation. Having realised that the query string format, whether it includes the string ‘http://’ in front or not, could aﬀect the returned results, we used two string formats: the ﬁrst is ‘URL only’, e.g. “www.facebook.com”; and the second is ‘URL with protocol’, e.g. “http://www.facebook.com”. Classiﬁers generated by querying ‘URL with protocol’ to a search engine S are denoted as ‘S(h)’, while classiﬁers generated by querying ‘URL only’ is denoted as ‘S’ alone. Google, for instance, represents search results collected from Google through querying ‘URL only’, and Google(h) represents results collected through querying ‘URL with protocol’. To visually observe the diﬀerences between the search results collected for legitimate websites and phishing websites, we use scatter plot graphs with the ‘number of results’ on the X-axis and the ‘ranking’ of the website on the Y -axis. These graphs are shown in Figure 3; for better visualisation of the dataset, the X-axis only shows up to 5,000 and the Y -axis up to 10. A number of distinct characteristics can be observed from these graphs. First, all of the phishing websites, plotted with a red X, have a very small number of returned results (quite a few have none), and most of them are not ranked or ranked below 10 – this explains why many phishing websites are missing from the graphs. Second, the majority of the legitimate websites are ranked ﬁrst and have large number of returned results; quite a number of legitimate websites that have more than 5,000 results are not shown in the graphs. Interestingly,

Phishing Detection with Popular Search Engines: Simple and Eﬀective 1

0.5 0

Accuracy Sensitivity Specificity G

B

Y

A

Rate

Rate

1

0.5 0

G(h) B(h) Y(h) A(h)

Accuracy Sensitivity Specificity G

B

Y

(a) LDA

G(h) B(h) Y(h) A(h)

1

0.5

G

B

Y

A

Accuracy Sensitivity Specificity G(h) B(h) Y(h) A(h)

(c) KNN (K = 3)

Rate

Rate

A

(b) NB

1

0

201

0.5 0

G

B

Y

A

Accuracy Sensitivity Specificity G(h) B(h) Y(h) A(h)

(d) SVM

Fig. 4. Performance of the four classiﬁers with respect to Accuracy, Specif icity, and Sensitivity

Yahoo(h) shows no phishing websites, indicating that most of them are either ranked below 10 or not ranked at all; also, there are many legitimate websites that are not ranked ﬁrst. 4.2

Classification Results

For classiﬁcation, we used the ﬁrst half of the collected search results for training and the rest for testing. The classiﬁers, as discussed in Section 3, were generated with the ﬁrst half of the data. We then assigned the legitimate websites with ‘Positive’ answers (P ) and the phishing websites with ‘Negative’ answers (N ). True Positive (T P ), False Positive (F P ), True Negative (T N ), and False Negative (F N ) can be summarised as below: – – – –

T P – legitimate websites correctly classiﬁed as legitimate websites; F P – legitimate websites incorrectly classiﬁed as phishing websites; T N – phishing websites correctly classiﬁed as phishing websites; F N – phishing websites incorrectly classiﬁed as legitimate websites.

The graphs in Figure 4 show the performance of the four classiﬁers using the following three measurements: N – Accuracy – the rate of the websites correctly classiﬁed ( T PP +T +N ); TN – Specif icity – the rate of true negative ( T N +F P ); P – Sensitivity – the rate of true positive ( T PT+F N ).

We also measured the running time of the classiﬁers to show the relative eﬃciency of the classiﬁcation algorithms; the results are shown in Table 2. These classiﬁers were implemented using the built-in MATLAB library functions. The PC we used for the experiment was equipped with an Intel quad-core 2.4GHz CPU and 64-bit Windows operating system. The results show that all of the algorithms except

202

J.H. Huh and H. Kim Table 2. Average running time of the classiﬁers measured in seconds

– (h) – Bing (h) – Yahoo (h) – All (h) Average – Google

LDA Train Test 0.000s 0.009s 0.000s 0.001s 0.000s 0.005s 0.000s 0.001s 0.000s 0.001s 0.000s 0.001s 0.000s 0.002s 0.000s 0.001s 0.000s 0.003s

NB Train Test 0.110s 0.027s 0.020s 0.007s 0.021s 0.007s 0.021s 0.008s 0.021s 0.008s 0.021s 0.007s 0.058s 0.019s 0.057s 0.019s 0.041s 0.013s

KNN Train Test 0.000s 0.019s 0.000s 0.009s 0.000s 0.014s 0.000s 0.009s 0.000s 0.009s 0.000s 0.009s 0.000s 0.009s 0.000s 0.010s 0.000s 0.011s

SVM Train Test 0.392s 0.005s 0.040s 0.004s 0.057s 0.005s 0.007s 0.004s 0.089s 0.005s 0.057s 0.004s 0.207s 0.001s 0.091s 0.004s 0.118s 0.004s

SVM incur computational overhead that is less than 0.05 seconds for training and less than 0.02 seconds for classifying. We argue that this is a reasonable overhead. Overall, the KNN (K = 3) classiﬁcation algorithm produced the best results – when ‘URL with protocol’ was queried on Yahoo (Yahoo(h)), KNN achieved 98% in all accuracy, speciﬁcity and sensitivity. Such a high performance implies that each data point, legitimate or phishing, can ﬁnd two or three neighbours in the same class and that are very closely related. The False Negative rate can also be calculated using 1 − Sensitivity, which gives a False Negative rate of 2% for Yahoo(h). The results were somewhat inconsistent for other three classiﬁcation algorithms. For example, both SVM and LDA performed bad with Yahoo(h) – unlike our expectations, SVM did not outperform other algorithms. Since SVM is one of the most generalised form of linear classiﬁers, it is likely that Yahoo(h) has a nonlinear property. Although SVM performed well with Bing, when we consider how expensive the tuning phase of SVM is (see Table 2), we would not recommend using SVM. In contrast, NB performed bad with Bing: we speculate that this is because NB relies on each attribute being independent, but the two attributes were not truly independent in Bing. Hence, we would not recommend using Bing or Bing(h) with NB; more obvious recommendations would be to use Google or Yahoo. If one wishes to use these as the classiﬁcation algorithms, the search engine and/or the query string format should be selected carefully. In addition, we observed that Yahoo queried with ‘URL only’ and All search engines combined together can both achieve reasonable and stable performance with any classiﬁcation algorithm. The linear property of Yahoo allows all of the classiﬁcation algorithms to perform reasonably well. If one wishes to use All, the response time of querying all three search engines should be carefully evaluated ﬁrst. In our experiment, the average response time for querying Google with both the phishing and legitimate websites was 0.161 seconds. If we assume that the response time for querying the other two search engines is the same, then the total response time for using All would be 0.483 seconds. On average, it would take about 0.483 seconds (plus the running time for classiﬁcation as shown above)

Phishing Detection with Popular Search Engines: Simple and Eﬀective

203

more to access a webpage. Hence, for any given classiﬁcation algorithm, the use of All should be considered only if it outperforms the best performing single search engine.

5

Related Work

Over the years, a wide range of phishing detection techniques have been proposed and deployed. One of the most used techniques seems to be blacklisting. Most of the anti-phishing applications available, including those built into mainstream web browsers, use blacklists for detecting phishing sites. Typically, a URL database of known-bad websites is managed and used for detecting phishing websites. These blacklisting approaches [19], however, only provide a partial solution with partial list of global phishing websites, and are not completely eﬀective against new phishing websites. To make the matters worse, the majority of the phishing websites are short-lived (e.g. lasting hours) and hundreds of new ones appear everyday [15], making it diﬃcult to update and check against the central databases. In contrast, whitelists manage a list of known-good websites. Whitelists are generally divided into global lists updated by central servers and personalised lists managed by the end users as needed. Due to its inherent usability issues, whitelists are currently used only in the preprocessing step, i.e. before the heuristics are checked, to reduce false positives. Kirda and Krugel [12] have developed a browser extension called AntiPhish to maintain trusted websites’ domain names and credentials. Cao et al. [2] have proposed a method for constructing the user’s personalised whitelists using the Na¨ıve Bayesian classiﬁcation algorithm. One of the main limitations with using blacklists and whitelists is that they can only classify previously-known phishing or legitimate websites. Inevitably, these lists are not very eﬀective when it comes to identifying a newly formed website. To overcome this limitation, many heuristics-based techniques have been proposed that analyse the HTML structure, URL, domain name, and webpage contents [3,16,7,24,22]. These methods are capable of achieving true positive rates between 85% and 95%, and false positive rates between 0.43% and 12%. Here, the most challenging task is to extract the right features that correctly identify phishing websites. When this task is not managed properly, they will incur false positives and false negatives. To minimise false positives and false negatives, Ronda et al. [18] have proposed a user-assisted system that uses visual previews of the original web form and the form the user intends to access — the user is expected to visually compare the two previews and make a decision. Considering that many phishing websites are now highly eﬀective in replicating the original websites and forms, how much this type of approach will add to the overall usability is questionable. The majority of researchers have used the webpage contents to measure the likelihood of phishing. For example, CANTINA [24] determines whether a webpage is dangerous by scrutinising webpage features like ‘consistency of wellknown logos’ and ‘use of HTML form tags’. Again, this type of approach has

204

J.H. Huh and H. Kim

limitations: if the heuristic looks for common properties of phishing websites, the phishers can simply avoid these properties when designing new ones. In practice, most of these ideas are implemented as toolbars (built-in web browsers), showing diﬀerent types of security messages to help users mitigate phishing attacks [3,14]. Some of the browser anti-phishing mechanisms were compared and evaluated in [23]. More recently, Kim and Huh [11] have proposed a method for identifying phishing websites using the network performance characteristics such as the round-trip time. This method is capable of achieving true positive rate of 99.4% and false positive rate of 0.7%. Bain et al. [10] have evaluated a number of online resources in assisting phishing detection. In particular, they have demonstrated that Google PageRank and Yahoo! Inlink, which rank websites according to the number of in-links, can be eﬀective in identifying phishing websites. The domains of legitimate websites usually have in-links from credible websites whereas the phishing websites do not. However, one concern is that such ranking systems only use the in-link information to rank a website. Many newly formed legitimate websites, which are not so much exposed to the public, may not have any (or very small number of) in-links from credible websites. This will introduce high false positives – that is, legitimate websites appearing as phishing websites. Our approach, by submitting the website URL as the search string, also checks whether there is a cached website/webpage with the exact same URL. Most of the time, the search engines we tested with, Google, Yahoo, and Bing, ranked a website first in their search results if the queried URL exactly matched this website’s URL, regardless of the number of in-links it may have. Hence, even the new legitimate websites that have small number of in-links are likely to be ranked very high using our approach. We have demonstrated this in Table 1: even from day 1, most of the legitimate websites are ranked ﬁrst; the phishing websites are not ranked at all. Moreover, Google PageRank is updated approximately every 3 months. This means a website may have to wait 3 months for its ranking to change: a legitimate website that is currently ranked low (or not ranked) and is misclassiﬁed as a phishing website, would continuously be misclassiﬁed until its ranking goes up after 3 months. Our approach, on the other hand, uses the latest information returned straight from the search engine, which is updated daily or even hourly. Table 1 shows how quickly such information can change, and the need to capture the latest information possible to make an accurate decision.

6

Conclusion and Future Work

Existing phishing detection techniques based on blacklists, whitelists, and various heuristics tend to achieve low performance when it comes to classifying new, recently launched websites. To address this weakness, we proposed a heuristicbased technique that uses the reputation of the URL of a website, a property that can be measured easily and quickly through any popular web search engine. Our experiment results show that, when a search engine is queried with the website’s full URL as the search string, the legitimate websites tend to get back large number of results and are ranked ﬁrst most of the time. The phishing

Phishing Detection with Popular Search Engines: Simple and Eﬀective

205

websites, on the other hand, tend to get back very small number of results (one or two) and are often ranked below 10 or not ranked at all. For performance evaluation, we used three most popular search engines, Google, Bing and Yahoo, to measure the reputation of 100 new legitimate websites and 100 new phishing websites. These recorded values were experimented with several classiﬁcation methods, Linear Discriminant Analysis, Na¨ıve Bayesian, K-Nearest Neighbour, and Support Vector Machine algorithms, demonstrating high accuracy in classifying the new websites. Although we relied on a relatively small sample pool, our best performing classiﬁcation method outperformed existing heuristics (these achieve true positive rates between 85% and 95% and false positive rates between 0.43% and 12%); and unlike previous experiments, our experiment focused more on analysing the performance of classifying relatively new websites. Hence, we expect the performance of classifying more established websites such as banks and social networks to be signiﬁcantly higher. There are a few things that a phisher might try to bypass our system: the phisher could provide a legitimate website for a while (to build a good reputation) and then abuse this reputation, or compromise a legitimate website (that already has a good reputation) and replace it with a phishing website. But these attacks would be expensive, and perhaps forcing the phishers to perform such costly attacks is a good thing. The phisher may also try ‘gaming’ the search engines to manipulate their ranking/reputation algorithms, and such attacks may turn out to be cheaper to perform than working around existing phishing ﬁlters. However, as the phishing attacks become more sophisticated, we imagine that a combination of anti-phishing mechanisms would be used in the future, rather than just relying on one particular solution. Some combination of our method and other existing heuristics may be used to provide a highly eﬀective solution. As part of the future work, we plan to increase the size of the dataset and investigate any change in performance. Moreover, we would like to try these classiﬁcation methods on a more fresh set of phishing websites which are yet to be registered on online databases. It would also be interesting to analyse how diﬀerent combinations of URL formats (e.g. leaving some parameters in the URL) aﬀect performance. Acknowledgements. The authors would like to thank Richard Clayton and Dongting Yu for their constructive comments and suggestions. The authors would also like to thank the anonymous reviewers for their careful attention and insightful comments.

References 1. Aaron, G., Rasmussen, R.: Global phishing survey: Trends and domain name use in 2h2009 (May 2010), http://www.antiphishing.org/reports/APWG GlobalPhishingSurvey 2H2009.pdf 2. Cao, Y., Han, W., Le, Y.: Anti-phishing based on automated individual whitelist. In: DIM 2008: Proceedings of the 4th ACM Workshop on Digital Identity Management, pp. 51–60. ACM, New York (2008)

206

J.H. Huh and H. Kim

3. Chou, N., Ledesma, R., Teraguchi, Y., Mitchell, J.C.: Client-Side Defense Against Web-Based Identity Theft. In: NDSS 2004: Proceedings of the Network and Distributed System Security Symposium (2004) 4. Cristianini, N., Shawe-Taylor, J.: An introduction to support vector machines: and other kernel-based learning methods, 1st edn. Cambridge University Press (March 2000) 5. Domeniconi, C., Peng, J., Gunopulos, D.: Locally adaptive metric nearest-neighbor classiﬁcation. IEEE Transactions on Pattern Analysis and Machine Intelligence 24, 1281–1285 (2002) 6. Domingos, P., Pazzani, M.: On the Optimality of the Simple Bayesian Classiﬁer under Zero-One Loss. Machine Learning 29(2-3), 103–130 (1997) 7. Fu, A.Y., Wenyin, L., Deng, X.: Detecting Phishing Web Pages with Visual Similarity Assessment Based on Earth Mover’s Distance (EMD). IEEE Transactions on Dependable and Secure Computing 3(4), 301–311 (2006) 8. Fukunaga, K.: Introduction to statistical pattern recognition, 2nd edn. Academic Press Professional, Inc., San Diego (1990) 9. Hearst, M.A., Dumais, S.T., Osman, E., Platt, J., Scholkopf, B.: Support vector machines. IEEE Intelligent Systems and their Applications 13(4), 18–28 (1998) 10. Bian, K., Park, J.-M., Hsiao, M.S., Belanger, F., Hiller, J.: Evaluation of Online Resources in Assisting Phishing Detection. In: Ninth Annual International Symposium on Applications and the Internet, SAINT 2009, pp. 30–36. IEEE Computer Society, Bellevue (2009) 11. Kim, H., Huh, J.H.: Detecting DNS-poisoning-based phishing attacks from their network performance characteristic. Electronics Letters 47(11), 656–658 (2011) 12. Kirda, E., Kruegel, C.: Protecting Users Against Phishing Attacks with AntiPhish. In: COMPSAC 2005: Proceedings of the 29th Annual International Computer Software and Applications Conference, pp. 517–524. IEEE Computer Society, Washington, DC, USA (2005) 13. Latourrette, M.: Toward an Explanatory Similarity Measure for Nearest-Neighbor Classiﬁcation. In: Lopez de Mantaras, R., Plaza, E. (eds.) ECML 2000. LNCS (LNAI), vol. 1810, pp. 238–245. Springer, Heidelberg (2000) 14. Liu, W., Deng, X., Huang, G., Fu, A.Y.: An Antiphishing Strategy Based on Visual Similarity Assessment. IEEE Internet Computing 10(2), 58–65 (2006) 15. Moore, T., Clayton, R.: Examining the impact of website take-down on phishing. In: eCrime 2007: Proceedings of the Anti-Phishing Working Groups 2nd Annual eCrime Researchers Summit, pp. 1–13. ACM, New York (2007) 16. Pan, Y., Ding, X.: Anomaly Based Web Phishing Page Detection. In: ACSAC 2006: Proceedings of the 22nd Annual Computer Security Applications Conference, pp. 381–392. IEEE Computer Society, Washington, DC, USA (2006) 17. Rish, I.: An empirical study of the naive Bayes classiﬁer. In: Proceedings of IJCAI2001 Workshop on Empirical Methods in Artiﬁcial Intelligence (2001) 18. Ronda, T., Saroiu, S., Wolman, A.: Itrustpage: a user-assisted anti-phishing tool. ACM SIGOPS Operating Systems Review 42(4), 261–272 (2008) 19. Sheng, S., Wardman, B., Warner, G., Cranor, L.F., Hong, J., Zhang, C.: An empirical analysis of phishing blacklists. In: CEAS 2009: Proceedings of the 6th Conference on Email and Anti-Spam (2009) 20. Vapnik, V.N.: Statistical Learning Theory. Wiley-Interscience (September 1998) 21. Wu, X., Kumar, V., Quinlan, J.R., Ghosh, J., Yang, Q., Motoda, H., McLachlan, G.J., Ng, A., Liu, B., Yu, P.S., Zhou, Z.-H., Steinbach, M., Hand, D.J., Steinberg, D.: Top 10 algorithms in data mining. Knowledge and Information Systems 14(1), 1–37 (2007)

Phishing Detection with Popular Search Engines: Simple and Eﬀective

207

22. Xiang, G., Hong, J.I.: A hybrid phish detection approach by identity discovery and keywords retrieval. In: WWW 2009: Proceedings of the 18th international conference on World wide web, pp. 571–580. ACM, New York (2009) 23. Zhang, Y., Egelman, S., Cranor, L., Hong, J.: Phinding Phish: Evaluating AntiPhishing Tools. In: NDSS 2007: Proceedings of the 14th Annual Network and Distributed System Security Symposium (2007) 24. Zhang, Y., Hong, J.I., Cranor, L.F.: Cantina: a content-based approach to detecting phishing web sites. In: WWW 2007: Proceedings of the 16th International Conference on World Wide Web, pp. 639–648. ACM, New York (2007)

A Contextual Privacy-Aware Access Control Model for Network Monitoring Workflows: Work in Progress Eugenia I. Papagiannakopoulou1, Maria N. Koukovini1 , Georgios V. Lioudakis1 , Joaquin Garcia-Alfaro2, Dimitra I. Kaklamani1 , and Iakovos S. Venieris1 1 School of Electrical and Computer Engineering National Technical University of Athens, Athens, Greece 2 Institut TELECOM, TELECOM Bretagne, CS 17607, 35576 Cesson-S´evign´e, Rennes, France

Abstract. Network monitoring activities are surrounded by serious privacy implications. The inherent leakage-proneness is harshened due to the increasing complexity of the monitoring procedures and infrastructures, that may include multiple traﬃc observation points, distributed mitigation mechanisms and even inter-operator cooperation. In this paper, we report a work in progress policy model that aims at addressing these concernes, by verifying access requests from network monitoring workﬂows, with privacy features already contained since their speciﬁcation phase. We survey related work, outline some of their limitations, and describe an early version of our proposal. Keywords: Network monitoring, access control, privacy, context, workﬂows.

1

Introduction

Network monitoring is characterised by certain features that stress the need for special mechanisms controlling access to the data that are collected and being processed, as well as the underlying computational resources. To name a few, ﬁrst of all the protection of privacy is a fundamental issue, since the concerns are not limited to the payload of the packets; sensitive information can be derived by protocol headers, even by not obvious ﬁelds [7] and even if there has been prior anonymisation of the data [8][26]. Second, the domain of network monitoring has become a legislated area, with several regulations governing the collection and consequent processing of the associated data (e.g., [11][12][13]); the regulations should be taken into account when designing access control systems and specifying the policies [19][29]. Third, something that cannot be neglected is the fact that network monitoring deals with very high data rates, exceeding the order of Gbps; in this context, access control has to face the stringent requirement of ultra fast responsiveness. Fourth, there is an emerging trend of collaborative J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 208–217, 2012. c Springer-Verlag Berlin Heidelberg 2012

A Contextual Privacy-Aware Access Control Model

209

monitoring, reﬂecting the cooperation between diﬀerent stakeholders, in order to eﬀectively cope with current attacks threatening networks, such as botnets and large scale DDoS. Last but not least, access control within network monitoring can be interpreted in a variety of ways, notably access to monitored data, monitoring devices and processing operations, as well as access policies that reﬂect operational aspects, mostly related to security, such as the behaviour of a ﬁrewall or the routing table of a router redirecting malicious traﬃc to a honeypot. In this paper, we sketch the deﬁnition of a new access control model that aims at dealing with all those aforementioned aspects. It is conceived on the basis of network monitoring, capturing all the underlying concepts, e.g., devices and functions, and providing rich expressiveness. Moreover, in order to deal with performance needs and in line with the “privacy by design” principle, the proposed approach puts in place mechanisms for inherent privacy-awareness of network monitoring workflows, by incorporating associated access control provisions already at design-time, thus minimising run-time reasoning overheads. In that respect, a procedure is being developed for the veriﬁcation of workﬂows and their enhancement with privacy-preserving features; a challenge here is to capture at design-time the contextual constraints, typically dealt with at run-time. In the following, we ﬁrst survey related work and outline the reference framework in Sections 2 and 3. Section 4 describes the access control model, while the paper concludes in Section 5 with some insights on current and future work.

2

Related Work

Privacy protection in network monitoring is typically thought of as the anonymisation of traﬃc traces, an area where several works have been proposed [14][15] [17][18][24]. Nevertheless, albeit useful as anonymisation libraries, such approaches base on “static” anonymisation patterns, while being vulnerable to attacks able to infer sensitive information [8][26]. Privacy-aware access control has recently evolved to a prominent research area [4]. However, approaches such as [1][5][9][21][22][25] have not been designed for meeting the particular requirements of network monitoring and conceptualising the corresponding functionalities and infrastructures; additionally, they either do not support context-awareness or they only support some straightforward contexts. Furthermore, they are not suitable for highly dynamic and distributed environments and –especially– for automating privacy-awareness. On the other hand, work in the area of access control enforcement in workﬂow management [6][28] and Model-Driven Security [3][23], though important, suﬀer from enforcing security policies only at run-time and not during the workﬂow formation. Finally, the proposed model draws inspiration from previous works of the authors, notably OrBAC [10][27][2] and PRISM [16][20][19]. OrBAC provides a mature framework for managing contextual policies, and several extensions, e.g., for dynamically deploying security policies; PRISM is an access control approach speciﬁcally devised for network monitoring, although limited to singleprobe environments. Their enhancement towards fulﬁlling all the requirements implied here, has been the motivation for the model presented in the following.

210

3

E.I. Papagiannakopoulou et al.

Reference Framework for Network Monitoring

The network monitoring framework under consideration relies on a modular and service-oriented architecture; it is centred around the concept of the workflow, that is, a series of tasks, along with their interaction patterns (both data- and control-ﬂow), that are executed in order for a high-level purpose to be fulﬁlled. As shown in Fig. 1, a workﬂow’s lifecycle can be seen as consisting of two phases, notably Planning and Execution. The former refers to the speciﬁcation of the workﬂow by its designer, including all steps for its graphical deﬁnition, decomposition to elementary tasks, compliance checking and necessary transformations. On the other hand, the Execution Phase relies on the Planning Phase’s outcome and refers to the deployment of the workﬂow to the system and its execution. The execution environment consists of Agents providing the service abstractions of the underlying actual components (e.g., detection or mitigation ones); the Inter-domain Exchange Point (IXP) constitutes a special Agent, being the functional gateway towards external domains, for the realisation of cooperative monitoring. The execution is coordinated by dedicated Orchestrators, while the means for context and capabilities management are also provided. Of great importance is the procedure for verifying and appropriately adjusting the workﬂow at design-time, so that it becomes inherently privacy-compliant before its execution. The procedure is conducted by the Model Checker, whereas a Reasoner provides the necessary intelligence, being the entity that incorporates and infers knowledge from the Policy Model; it consists in three steps: – Purpose verification: Checks regarding purpose compliance are performed; speciﬁcally, in order for a workﬂow to be privacy-aware, its design must be relevant and consistent with a purpose, while the purpose itself should not contradict with the access rights of the person initiating the workﬂow. – Skin task verification 1 : Each skin task is evaluated both individually and in relation to the rest of the skin tasks. During these checks, the system may introduce modiﬁcations, such as task additions, removals or substitutions. – Decomposition: Each composite skin task is decomposed in more elementary subtasks, until it is ﬁnally analysed in a combination of atomic tasks that will eventually be included in the ﬁnal executable form of the workﬂow. Fig. 2 illustrates a network monitoring workﬂow example; Fig. 2(a) depicts the initial workﬂow, as speciﬁed by its designer, and Fig. 2(b) the workﬂow after some transformations following the veriﬁcation and transformation procedure. In practice and especially within workﬂows, rules remain inactive until a set of conditions are fulﬁlled. We denote as contextual the authorisation policies containing dynamic authorisation provisions. In this regard, authorisation rules 1

We call skin tasks the ones deﬁned by the workﬂow designer, as opposed to the tasks that their inclusion in the workﬂow is a result of workﬂow check and modiﬁcation; all tasks in Fig. 2(a) are considered to be skin tasks. Their separate examination without considering their decomposition targets the early identiﬁcation of conﬂicts.

A Contextual Privacy-Aware Access Control Model

211

Fig. 1. Overall Architecture

(a) Initial Workﬂow (as speciﬁed by its designer)

(b) (Partially) Processed Workﬂow Fig. 2. Workﬂow Example

may depend on temporal contexts (e.g., authorisations granted only during working hours), geographical contexts (e.g., permission inside the physical boundaries of a company), a priori contexts (in which a permission to execute a set of actions can only be carried out as a result of the completion of previous actions). Therefore, it is essential that not only the contextual conditions are captured by the model, but also that they are taken into consideration during the veriﬁcation and transformation procedure, providing for the speciﬁcation of context-based diﬀerentiated workﬂow behaviours, already during workﬂow formation.

4

Policy Model

The Policy Model regulates the system’s operation and drives the workﬂow veriﬁcation and transformation process. It consists of a semantically rich information model, providing abstractions of the underlying concepts, and access control rules. Similar to the subject–verb–object linguistic pattern, everything that takes place in the context of the system’s operation can be seen as an operation of an actor on a resource. This metaphor is the basis on which actions and tasks are deﬁned, being the core elements of access control rules and workﬂows and the “seed” for knowledge extraction. The following outline the basic concepts.

212

4.1

E.I. Papagiannakopoulou et al.

Information Model

In a typical case and at a concrete level, a set of Users (U ), participating (e.g., working) in Organisations (Org), are –directly or indirectly– using Operation Containers (OpC ), deployed over Machines (M ) and oﬀering Operation Instances (OpI )2 , in order to act upon Objects (Obj ), with the latter referring to everything that is aﬀected by or required for the execution of an action, such as Data (D ) being collected and/or processed. At an abstract level, the users are assigned with Roles (R), their actions instantiate some Operations (Op) and are performed for fulﬁlling some Purposes (Pu). Moreover, data, organisations, machines and operation containers are characterised by types, reﬂecting the semantic class they fall under; thus, sets of Data Types (DT ), Organisation Types (OrgT ), Machine Types (MT ) and Operation Container Types (OpCT ) are deﬁned, respectively. Additional elements of the model include Context (Con), that enables the deﬁnition of contextual parameters, Attributes (Att ), that are leveraged for describing properties and characteristics of other elements, as well as Alerts (Al ), i.e., notices regarding events, along with the corresponding AlertTypes (AlT ). While most of these notions are either typically present in state-of-the-art models or intuitively self-explained, a few remarks are deemed necessary for some of the concepts. Speciﬁcally, the OpC and OpCT are introduced in order to model components or other functional structures that typically oﬀer a set of operations together. For instance, an IntrusionDetectionSystem clusters several operations related with intrusion detection. Apart from the convenience it introduces regarding several modelling aspects (such as the inheritance of attributes), these structures are also helpful for describing a variety of concepts related with “horizontal” dependencies and transfer of characteristics. Moreover, the machines (and their types) play a fundamental role in network monitoring and, therefore, our model cannot be limited to a level of abstraction exclusively centred around functionalities; in any case, functionalities are provided by machines which, on the one hand, are characterised by attributes (e.g., topological ones) that may be inherited to the hosted functionalities and, on the other hand, create inherent dependencies between the hosted functionalities. All these concepts comprise graphs of elements that are characterised by relations; the latter are implemented by predicates deﬁning AND- and ORhierarchies and enabling the inheritance of attributes and rules, as well as the speciﬁcation of dependencies. For instance and with respect to the DT graph, three partial order relations are deﬁned: isA(dti , dtj ), lessDetailedThan(dti , dtj ) and contains(dti , dt k ), where dti , dtj ∈ DT, and dt k ⊆ P(DT ), reﬂecting, respectively the particularisation of a concept, the detail level and the inclusion of some data types to another. Moreover, the model speciﬁes the necessary predicates in order to link concepts from diﬀerent graphs; for example, the predicate mayActForPurposes(r, puk ), where r ∈ R, puk ⊆ P(Pu), appoints the legitimate purposes puk for which the users assigned with the role r may act. 2

In Web Services’ terms, Operation Containers correspond to a service portType, whereas Operation Instances represent the associated operations.

A Contextual Privacy-Aware Access Control Model

4.2

213

Actions, Tasks and Workflows

We use the term Action in order to refer to a structure similar to the subject– verb–object metaphor, and describe situations where an operation opi is performed by an actor ai on a resource resi , i.e., acti = ai , opi , resi . Following the hierarchical relations of operations Op, an action can be either atomic or composite, depending on whether the associated operation can be decomposed to more elementary operations or not. In addition, the deﬁnition of an action can be complemented by a fourth parameter, notably the organisation within which it is deﬁned; in such a case, it is expressed as acti = ai , opi , resi , org. Several of the aforedesribed types of entities may constitute actors and resources; they can be either concrete, e.g., Users and Data, or abstract, e.g., Roles and Data Types. Depending on whether actors and resources are deﬁned at abstract, concrete or mixed level, several variations of Actions are identiﬁed, such as Abstract Actions, Concrete Actions and Semi-Abstract Actions, the formal description of which is beyond the scope of this work-in-progress overview. Actions are used for describing Tasks and Workflows, the deﬁnition of which is interrelated. A task ti is an action acti when being part of a workﬂow w, written as a tuple ti = ai , opi , resi w , or ti = ai , opi , resi , orgw . On the other hand, a workﬂow consists in a ﬁnite number of tasks, i.e., w = t1 , t2 , ..., tn , along with the control- and data-ﬂow relationships among them. 4.3

Access Control Rules

Access control rules are used for deﬁning permissions, prohibitions and obligations over Actions, that is, they specify authorisations between actors, operations and resources within organisations. The following predicates are used: – Permission(pu, act, preAct, cont, postAct ) – Prohibition(pu, act, preAct, cont, postAct ) – Obligation(pu, act, preAct, cont, postAct ) In these expressions, apart from the action act that the rule applies to, additional provisions are deﬁned. These include contextual conditions cont ∈ P(Con), the purpose pu ∈ Pu under which the rule is applicable, as well as structures of actions, preAct and postAct, that should respectively precede and follow the rule’s enforcement. It should be noted here that preAct and postAct may comprise complex logical structures of actions, including negation. This enables the speciﬁcation of expressive Dynamic Separation of Duty constraints, whereby conﬂicts between tasks can be deﬁned based on any of the elements. Based on these formalisms, the model provides the system with the necessary knowledge regarding access rights and their applicability, hierarchical relations and inheritance of attributes and access primitives across the information graphs, as well as associations between the model’s diﬀerent components. As an additional remark here, in some cases rules can be a priori evaluated; this puts in place a separation of the real-time and non-real-time aspects of access control procedures, resulting in performance advances. A few examples of knowledge extraction are provided in the next section.

214

4.4

E.I. Papagiannakopoulou et al.

Knowledge Extraction

Let’s assume the rather typical case where a user holding a role rinit ∈ R initiates a workﬂow w = t1 , t2 , ..., tn , where ti = ai , opi , resi , orgw , declaring a purpose puw ∈ Pu. Sample knowledge that will be requested in the context of workﬂow veriﬁcation and transformation and will consequently be inferred after reasoning over the model includes: —Whether rinit justiﬁes triggering the execution of w, in order for pu to be served. For instance, a NetworkAdministrator should be able to execute a workﬂow for the purpose of NetworkSecurity, while an Accountant should not. —Whether the operations opi contained in w ’s tasks are in line with puw . For example, all functions in Fig. 2(a) are relevant to the purpose of NetworkSecurity, while a task InterceptCommunications is not and would have been rejected. —Whether a task ai , opi , resi w is in principle valid, i.e., the actor ai has the right to perform operation opi on resource resi , regardless other constraints. —The tasks that should complement the execution of a task, i.e., precede, follow or be executed in parallel. For instance, there may be the case that whenever a DDoSAttack is identiﬁed and reported by an alarm, the prompt notiﬁcation of the SecurityOfficer should take place, along with the associated mitigation actions (represented by the high-level task MitigateDDoS); as Fig. 2(b) depicts, the InformSecurityOfficer task has been added to be executed in parallel, while the AggregateResults task is added for being executed before ReportToGUI. —The possible ai , resi combinations allowed for the execution of an operation opi , given w, rinit and puw . For instance, depending on the actor ai in charge of executing the ReportToGUI task, the resource resi to be delivered to the task may be plain or aggregated detection data. Such provisions may result in the incorporation of conditional branches within the workﬂow, such as diﬀerent execution paths for diﬀerent actors. —The possible decompositions of a task ti , for given rinit and puw . For instance, Fig. 2(b) illustrates a simpliﬁed decomposition of the DetectSYNFlood task to the subtasks tuple parser, tuple demux and syn flood calc; nevertheless, there are alternative decompositions that could be leveraged, so it is assumed here that the speciﬁc decomposition has been selected based on the parameters applying (e.g., rinit may permit only this decomposition). —Whether a task within the workﬂow requires another task (or a series of tasks), along with its exact or relative position in the workﬂow; such requirements might also depend on context. For instance, the Anonymise task has been added in Fig. 2(b), assuming to be a prerequisite for tuple parser’s execution under the control of the actor in charge and for given rinit , puw , etc. —Identiﬁcation of possible incompatibilities and conﬂicts that may exist among some tasks within the workﬂow and, possibly, their resolution. For instance, the addition of the Anonymise task in Fig. 2(b) could be the resolution of an incompatibility between the CaptureTraffic and ParseTuple tasks, taking into account the actors and resources of the tasks, as well as the rinit , puw , etc.

A Contextual Privacy-Aware Access Control Model

215

—Identiﬁcation of the possible workﬂow diﬀerentiations, based on contextual parameters and alarms/events. For example, Fig. 2 illustrates a conditional branch, that depends on whether an alarm is raised or not; while here it is supposed that the workﬂow designer has deﬁned the conditional branch, there can be cases where such diﬀerentiations are inferred by the Policy Model. —What are the possible workﬂow instantiations, taking into account the access rights, as well as the available capabilities. As an example, let’s assume that Ingrid, the engineer on duty at the time of a DDoSAttack alert, holds the JuniorNetworkAdministrator role and, therefore, in order to implement the InformSecurityOfficer task, she is authorised to only use the MakeVoIPCall operation oﬀered by VoIPSoftwareClient operation containers. In addition, Ingrid is authorised to use only a small number of PersonalComputer machines with VoIPSoftwareClient software deployed. Thus, for the instantiation of the workﬂow during Ingrid’s duty hours, the model should enable the identiﬁcation of a VoIPSoftwareClient-enabled PersonalComputer machine that Ingrid is authorised to use, in order to include the concrete task in the workﬂow.

5

Conclusions and Current Work

Motivated by the necessity of enhancing network monitoring architectures in terms of privacy-awareness, we are working towards the speciﬁcation of a new policy model for controlling access to associated resources, such as data, operations and infrastructures. Our model aims at allowing the deﬁnition of network monitoring workﬂows, with privacy features already contained since their speciﬁcation phase. In this paper, we have surveyed existing solutions, outlined some of their drawbacks, and presented an early version of our proposal. Our model takes full advantage of the integration of contextual properties; this allows us to cover the deﬁnition of both simple and complex business processes, as well as describing rich contextual categorisation of network resources. As a result, our model allows to potentially reduce the deﬁnition of the concrete policies which will need to be deployed in the end, over legacy network monitoring systems. As future perspectives, we aim at implementing and empirically verifying the powerfulness of our model, by the application of a proof-of-concept version of our approach carried out through a representative real-world case study. Acknowledgements. This research was partially supported by the European Commission, in the framework of the FP7 DEMONS project (Grant agreement no. FP7-257315). The research of M. N. Koukovini is co-ﬁnanced by the European Union (European Social Fund - ESF) and Greek national funds through the Operational Program “Education and Lifelong Learning” of the National Strategic Reference Framework (NSRF) — Research Funding Program: Heracleitus II. Investing in knowledge society through the European Social Fund. The research of Joaquin Garcia-Alfaro is also supported by the Spanish Ministry of Science and Innovation (grants TSI2007-65406-C03-03 E-AEGIS and CONSOLIDERINGENIO CSD2007-00004 ARES).

216

E.I. Papagiannakopoulou et al.

References 1. Agrawal, R., Kiernan, J., Srikant, R., Xu, Y.: Hippocratic databases. In: VLDB 2002: Proceedings of the 28th International Conference on Very Large Data Bases, pp. 143–154. VLDB Endowment (2002) 2. Ajam, N., Cuppens-Boulahia, N., Cuppens, F.: Contextual Privacy Management in Extended Role Based Access Control Model. In: Garcia-Alfaro, J., NavarroArribas, G., Cuppens-Boulahia, N., Roudier, Y. (eds.) DPM 2009. LNCS, vol. 5939, pp. 121–135. Springer, Heidelberg (2010) 3. Alam, M., Hafner, M., Breu, R.: Constraint based role based access control in the sectet-framework a model-driven approach. Journal of Computer Security 16(2), 223–260 (2008) 4. Antonakopoulou, A., Lioudakis, G.V., Gogoulos, F., Kaklamani, D.I., Venieris, I.S.: Leveraging access control for privacy protection: A survey. In: Yee, G. (ed.) Privacy Protection Measures and Technologies in Business Organizations: Aspects and Standards. IGI Global (2011) 5. Ardagna, C.A., Camenisch, J., Kohlweiss, M., Leenes, R., Neven, G., Priem, B., Samarati, P., Sommer, D., Verdicchio, M.: Exploiting cryptography for privacyenhanced access control: A result of the prime project. Journal of Computer Security 18(1), 123–160 (2010) 6. Ayed, S., Cuppens-Boulahia, N., Cuppens, F.: Deploying security policy in intra and inter workﬂow management systems. In: International Conference on Availability, Reliability and Security, pp. 58–65 (2009) 7. Bellovin, S.M.: A technique for counting NATted hosts. In: IMW 2002: Proceedings of the 2nd ACM SIGCOMM Workshop on Internet Measurment, pp. 267–272. ACM, New York (2002) 8. Burkhart, M., Schatzmann, D., Trammell, B., Boschi, E., Plattner, B.: The role of network trace anonymization under attack. SIGCOMM Computer Communications Review 40(1), 5–11 (2010) 9. Byun, J.W., Li, N.: Purpose based access control for privacy protection in relational database systems. The VLDB Journal 17(4), 603–619 (2008) 10. Cuppens, F., Cuppens-Boulahia, N.: Modeling Contextual Security Policies. International Journal of Information Security 7(4), 285–305 (2008) 11. European Parliament and Council: Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. Oﬃcial Journal of the European Communities L 281, 31–50 (November 1995) 12. European Parliament and Council: Directive 2002/58/EC of the European Parliament and of the Council concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications). Oﬃcial Journal of the European Communities L 201, 37–47 (July 2002) 13. European Parliament and Council: Directive 2006/24/EC of the European Parliament and of the Council of 15, March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC. Oﬃcial Journal of the European Communities L 105, 54–63 (April 2006) 14. Fan, J., Xu, J., Ammar, M.H., Moon, S.B.: Preﬁx-preserving IP address anonymization. Computer Networks 46(2), 253–272 (2004)

A Contextual Privacy-Aware Access Control Model

217

15. Foukarakis, M., Antoniades, D., Antonatos, S., Markatos, E.: Flexible and highperformance anonymization of NetFlow records using anontool. In: SECURECOMM Conference (2007) 16. Gogoulos, F., Antonakopoulou, A., Lioudakis, G.V., Mousas, A.S., Kaklamani, D.I., Venieris, I.S.: Privacy-aware access control and authorization in passive network monitoring infrastructures. In: CIT 2010: Proceedings of the 10th IEEE International Conference on Computer and Information Technology (2010) 17. Koukis, D., Antonatos, S., Antoniades, D., Markatos, E., Trimintzios, P.: A generic anonymization framework for network traﬃc. In: IEEE International Conference on Communications, ICC 2006, vol. 5, pp. 2302–2309 (2006) 18. Li, Y., Slagell, A., Luo, K., Yurcik, W.: Canine: A combined conversion and anonymization tool for processing netﬂows for security. In: International Conference on Telecommunication Systems Modeling and Analysis (2005) 19. Lioudakis, G.V., Gaudino, F., Boschi, E., Bianchi, G., Kaklamani, D.I., Venieris, I.S.: Legislation-aware privacy protection in passive network monitoring. In: Portela, I.M., Cruz-Cunha, M.M. (eds.) Information Communication Technology Law, Protection and Access Rights: Global Approaches and Issues, ch. 22, pp. 363–383. IGI Global (2010) 20. Lioudakis, G.V., Gogoulos, F., Antonakopoulou, A., Mousas, A.S., Venieris, I.S., Kaklamani, D.I.: An access control approach for privacy-preserving passive network monitoring. In: ICITST 2009: Proceedings of the 4th International Conference for Internet Technology and Secured Transactions (November 2009) 21. Masoumzadeh, A., Joshi, J.: Purbac: Purpose-Aware Role-Based Access Control. In: Meersman, R., Tari, Z. (eds.) OTM 2008. LNCS, vol. 5332, pp. 1104–1121. Springer, Heidelberg (2008) 22. Massacci, F., Mylopoulos, J., Zannone, N.: Hierarchical hippocratic databases with minimal disclosure for virtual organizations. The VLDB Journal 15, 370–387 (2006) 23. Menzel, M., Meinel, C.: SecureSOA. In: IEEE International Conference on Services Computing, pp. 146–153 (2010) 24. Minshall, G.: Tcpdpriv, http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html 25. Ni, Q., Bertino, E., Lobo, J., Brodie, C., Karat, C.M., Karat, J., Trombetta, A.: Privacy-aware role-based access control. ACM Transactions on Information and System Security 13(3), 1–31 (2010) 26. Pang, R., Allman, M., Paxson, V., Lee, J.: The devil and packet trace anonymization. Computer Communication Review (CCR) 36(1), 29–38 (2006) 27. Preda, S., Cuppens, F., Cuppens-Boulahia, N., Garcia-Alfaro, J., Toutain, L.: Dynamic deployment of context-aware access control policies for constrained security devices. J. Syst. Softw. 84, 1144–1159 (2011) 28. Russello, G., Dong, C., Dulay, N.: A workﬂow-based access control framework for e-health applications. In: WAINA 2008: Proceedings of the 22nd International Conference on Advanced Information Networking and Applications Workshops, pp. 111–120. IEEE Computer Society, Washington, DC (2008), http://portal.acm.org/citation.cfm?id=1395080.1395523 29. Sicker, D.C., Ohm, P., Grunwald, D.: Legal issues surrounding monitoring during network research. In: IMC 2007: Proceedings of the 7th ACM SIGCOMM Conference on Internet Measurement, pp. 141–148. ACM, New York (2007)

A Metamodel for the Design of Access-Control Policy Enforcement Managers: Work in Progress Michel Embe Jiague1,2 , Marc Frappier1 , Fr´ed´eric Gervais2 , R´egine Laleau2 , and Richard St-Denis1 1

GRIL, D´epartement d’informatique Universit´e de Sherbrooke Sherbrooke (Qu´ebec), J1K 2R1, Canada {Michel.Embe.Jiague,Marc.Frappier,Richard.St-Denis}@USherbrooke.ca 2 LACL, Universit´e Paris-Est IUT Fontainebleau, 77300 Fontainebleau, France {Frederic.Gervais,Laleau}@U-PEC.fr Abstract. This paper presents a metamodel of a policy enforcement manager responsible for applying the rules defined in security policies with the aim to constraint the access to the functionalities and data of information systems. The metamodel is useful to derive platform-specific security models that provide the basis for the design and implementation of such managers for Web services as well as legacy information systems in various business sectors.

1

Introduction

Using a policy enforcement manager (PEM) to control access to software system components appears as the most prevailing solution in the domain of informationsystem security. Designing and implementing a PEM, however, entails challenges, given the rapid evolution of information technologies, in particular, those related to the Web. Describing an abstract architecture of a PEM in UML can contribute, in part, to this issue. Such a description can be seen as a metamodel that can be specialized for a given implementation context (e.g., legacy information systems, Web services). The metamodel described in this paper was inspired from the XACML standard [6]. It includes three main components. A policy enforcement point (PEP) performs access control by making decision requests and enforcing authorization decisions. To carry out this task, the PEP calls a policy decision point (PDP), which considers security policies prescribed by a regulatory agency or an audit department. The PDP relies on several ﬁlters to evaluate policy rules and on a decision engine to combine their results. The proposed architecture supports hierarchically deﬁned policies. It also distinguishes between static and dynamic

The research described in this paper was supported, in part, by the Natural Sciences and Engineering Research Council of Canada (NSERC) and the French National Research Agency (ANR).

J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 218–226, 2012. c Springer-Verlag Berlin Heidelberg 2012

A Metamodel for the Design of Access-Control PEM

219

policies. Assessing dynamic policy rules requires a policy information point (PIP) to obtain information about the environment with which the PEM must interact to make a decision. There are several diﬀerences between the XACML standard and the metamodel presented in this paper. The XACML standard is an XML-based language that describes RBAC-like access-control policies. It encompasses a simple description of a possible architecture of the PEM as well as a description of its components. Our metamodel is based on the same components, but provides several extensions to account for dynamic policies. In addition, it describes interactions between the active components of a PEM. Finally, it establishes useful distinctions between the various concepts used to make an access-control decision. For instance, it distinguishes between business parameters and accesscontrol parameters, static and dynamic rules, and master and slave PDPs. XACML primarily focuses on basic notions (e.g., rule, policy) while paying no attention to a method for developing a PEM. In our research projects, the metamodel is a part of such a method, which reuses some XACML notions. It relies, however, on formal, abstract languages that allow for ﬂexible and powerful descriptions of policies and transformations for the computation of access-control decisions. XACML does not provide explicit support for these tasks. Another key diﬀerence is the type-based description of messages exchanged inside the PEM. Our metamodel includes the notion of access-control parameter, which can be specialized to obtain concrete classes on which access control can be enforced.

2

The PEM Metamodel

The PEM metamodel is devoted to the construction of platform-speciﬁc security models that conform to an acceptable view of a framework for the domain of access control to information-system components. Implementations derived from instances of the metamodel can then be compared with respect to a unique common basis. Comparisons can be made not only in terms of their speciﬁc features, but also in terms of eﬃciency from data gathered during system operation or experiments conducted with software prototypes. Such a metamodel describes a set of passive and active objects peculiar to a PEM and speciﬁes how information is exchanged between active objects independently of any implementation details (e.g., authentication, encryption, intrusion detection). Class diagrams and sequence diagrams—two UML graphic notation techniques—are respectively used for that purpose. 2.1

Sequence Diagrams

In describing sequence diagrams, it is assumed that an anonymous object has the name of its class; it is written in lowercase in the sans serif font. Names in bold face designate classes. Three typical scenarios are presented. Figure 1 focuses on message exchanges between an authenticated user and the whole platform, particularly when he attempts to access service E with

220

M. Embe Jiague et al.

:AuthenticatedUser E(bp)

:Interceptor

:PEP

E(acp, bp)

root:PDP

:Service

AR(E, acp, bp) access E(bp) response

alt access = granted response access denied

Fig. 1. Sequence diagram: PEP at the root

the business parameters bp. It also shows the main sequence of messages that pass through the instances interceptor, pep, and root as a result of the request initiated by the user. As indicated by its name, an instance of Interceptor intercepts each user request to add access-control parameters acp, such as user role and organization. The interceptor sends the augmented message to the PEP with the intention of enforcing the access-control policies deployed for the target service. Then, the PEP asks the top-level PDP in a hierarchy of PDPs for an authorization decision about the incoming request deﬁned by E, acp, and bp. The latter returns an access decision to the former. If the access is granted, then the original request is forwarded to the intended service. Otherwise, the user receives a notiﬁcation that the service request has been denied. The response provided by the service is not sent directly to the user. It passes through the PEP, which reroutes the response to the user as explained in the next section. The decision process can become complex when various policies are imposed by diﬀerent internal or external regulation agencies. In this case, several instances of the class PDP may be deployed and organized hierarchically based on the priority level of each policy. For example, in the hospital sector, ﬁve PDP instances may form a three-level hierarchy when considering the following access-control policies: i) a policy prescribed by government legislation about health institutions; ii) a policy based on internal procedures; and iii) a policy that supersedes the ﬁrst two in emergency cases. Between two adjacent levels of the hierarchy, there is a master-slave relationship from which a decision-making process is deﬁned. As depicted in Fig. 2, an internal PDP in the hierarchy that receives an authorization request is considered a master PDP. It forwards the same request to its immediate successors, which are the slaves. A slave then becomes a master if it is not a leaf of the hierarchy. All slaves return their access decisions to the corresponding master, which keeps all the decisions until it receives the last one or a delay has expired. Then, the master calls an instance of DecisionEngine that combines all the access decisions. The object root must send the ﬁnal access decision to the PEP (see Fig. 1).

A Metamodel for the Design of Access-Control PEM

master:PDP

221

:DecisionEngine

slaves:PDP

*[all]AR(E, acp, bp) access Combine(accesses) access

Fig. 2. Sequence diagram: PDP at an intermediate level

As shown in Fig. 3, a slave PDP at the bottom of the hierarchy uses a collection of ﬁlters to infer an access decision. When it receives an authorization request message from its master PDP, it calls its ﬁlters sequentially by forwarding the same message, but with an additional parameter (pr), resulting from the previous ﬁlter (this parameter is ignored by the ﬁrst ﬁlter), since a given ﬁlter may require the result of the previous ﬁlter in order to determine its own result. Similarly to the case described in Fig. 2, a ﬁlter sends its result back to the slave, which keeps all the results until it receives the last one or a delay has expired. Then, the slave calls an instance of DecisionEngine that transforms all the results into an access decision. The ﬁlters can also run in parallel, in which case, they ignore the parameter pr. 2.2

Class Diagrams

Classes of objects are grouped together in class diagrams to exhibit relationships between them. In a metamodel, however, classes are, in fact, metaclasses. A deliberate abuse of language is necessary to simplify their description, since classes are generally presented in two diﬀerent perspectives at the same time: the pr: result of the previous ﬁlter master:PDP

slave:PDP

:DecisionEngine

:Filter

AR(E, acp, bp) *[all]AR(pr, E, acp, bp) result Combine(results) access

access

Fig. 3. Sequence diagram: PDP at the bottom level

222

M. Embe Jiague et al.

AbstractMessage

Message

AccessControlMessage

AuthorizationMessage

1..*

1..*

1..*

1..*

Interceptor

1..*

PEP

1..* PDP

Fig. 4. Class diagram: PEM components

perspective of the metamodel and that of models derived from the metamodel. The names written in the typewriter font represent metaclasses. Italic is used for the names of abstract metaclasses or abstract classes. All messages are represented by an abstract class and specialized according to their speciﬁc usage in the sequence diagram in Fig. 1. As shown in Fig. 4, the metaclasses Message, AccessControlMessage, and AuthorizationMessage represent the messages E(bp), E(acp, bp), and AR(E, acp, bp), respectively, as well as the corresponding responses. The class diagram in Fig. 4 also speciﬁes which objects send or receive them. Instances of metaclasses Interceptor, PEP, and PDP vary from one implementation to another. As an example, instances of Interceptor in an SOA application represent SOAP handler classes, whose instances act as proxies between the user application and Web services. Their role is to inject access-control parameters into the SOAP message E(bp). The class diagram in Fig. 5 presents another view of message hierarchy. In general, a message includes optional parameters, which are categorized according to message type. A parameter holds an input value or an output value depending on the service request/response or method call. This characteristic (i.e., input/output)

AbstractParameter BusinessParameter 0..* Bparameters AbstractMessage

AccessControlParameter 0..* 0..*

ACParameters

ACParameters

AccessControlMessage

AuthorizationMessage Fig. 5. Class diagram: message hierarchy

A Metamodel for the Design of Access-Control PEM

223

AccessControlParameter « instance » Organization

Role

User

Fig. 6. Class diagram: access-control parameters

is an attribute of AbstractParameter . Based on this attribute, there are oneway messages with only input parameters and for which senders do not expect a response or two-way messages. The metaclass AccessControlParameter, which appears in the class diagrams in Fig. 5 and 6, is instantiated when deﬁning a security model with its own classes of access-control parameters (e.g., classes Organization, Role, and User). Any model derived from the metamodel may consider other classes of access-control parameters such as the present time of a user request or its geographic origin. An access-control policy is deﬁned as a set of rules represented by the abstract metaclass Rule in Fig. 7 and 8. The metamodel makes a distinction between static and dynamic rules. Static rules express constraints a` la RBAC [3] while dynamic rules also consider the history of operations executed by the services. Examples of static rules are permission, which authorizes an operation to be executed, and prohibition, which forbids an operation to be executed. The abstract metaclass staAC::Rule (resp. dynAC::Rule ), that appears in the package staAC in Fig. 7 (resp. the package dynAC in Fig. 8), represents static (resp. dynamic) rules, which are used to deﬁne a static (resp. dynamic) policy. Examples of dynamic rules are separation of duty (SoD), which states that a set of related operations must be invoked by diﬀerent users or roles, and obligation, which forces a user to eventually trigger an operation after the execution of a speciﬁc operation for himself. Therefore, the metamodel forbids policies with both types AccessControlParameter 1..* staAC

Rule 1..* rules Policy

Permission

Prohibition

1 policy Filter

AbstractFilter

AbstractPolicy

Fig. 7. Class diagram: static access control

224

M. Embe Jiague et al.

AccessControlParameter 1..* dynAC

Rule 1..* rules

Obligation

Policy

SoD

1 policy Filter 1 PIP

AbstractFilter

AbstractPolicy

Fig. 8. Class diagram: dynamic access control

of rules. Nevertheless, such policies can be split into two parts and associated with two ﬁlters instead of only one. Contrary to the classes Organization, Role, and User in Fig. 6, Permission and Prohibition are really sub-metaclasses of staAC::Rule because the metamodel allows for instantiation of the former to model various classes of permission or prohibition rules for speciﬁc security models (e.g., those only based on roles, those only based on users, and those based both on users and roles). Instances of staAC::Filter (resp. dynAC::Filter), a specialization of AbstractFilter in the upper package, are classes whose instances use a static (resp. dynamic) policy to infer a result after considering the whole or a part of its rules. For a static rule, a ﬁlter tries to match the parameters E, acp, and bp of an authorization request message with the values of the rule’s corresponding terms. Besides matching parameters and values, a ﬁlter associated with a dynamic policy must acquire information about the history of operations executed by the services and related to the policy rules. The PIP, an auxiliary component of the PEM, supplies this information (see Fig. 8). Several implementations are possible. A PIP can memorize and update the subset of the system state necessary to determine the authorization decision with respect to the contents of all dynamic rules. Another possibility is a PIP that queries the information-system databases or considers environment attributes (e.g., system load, system time) to provide the required information. Finally, Fig. 9 shows the relationships between AbstractFilter , PDP, and DecisionEngine. It is clear from this diagram that the PDPs are organized hierarchically and there is only one decision engine associated with a PDP. The synthesis of an access decision is symbolized by the metaclass DecisionEngine. In its simple form, a decision engine merges local decisions conjunctively, but more sophisticated inference-based multi-decision algorithms may be considered. For example, a decision engine can give priority to a policy over another in case of emergency.

A Metamodel for the Design of Access-Control PEM

225

AuthorizationMessage 0..* AbstractFilter 0..* ﬁlters PDP 0..* subPDPs decisionEngine

1 DecisionEngine

Fig. 9. Class diagram: PDP hierarchy

3

Discussion and Conclusion

The metamodel described in this paper was instantiated into diﬀerent PEM models. Prototypes were produced from most of them to evaluate speciﬁc characteristics (e.g., performance, feasibility with respect to current technologies, suitability for application domains). In [1], the authors present two PEM models based on the metamodel. They are part of real applications in the health sector. The ﬁrst application is a PHP program in which not only access to its functions is controlled but also access to its Web pages. In this case, the PDP is a PHP module that communicates with a ﬁlter through plain/signed/encrypted HTTP requests. The second application was developed in Java using aspect-oriented programming to seamlessly integrate the PEP into parts of the program, where their access is to be controlled. In both applications, all the active components were implemented in the same manner, except for communication between the PDP and the unique ﬁlter. The policies were written in OrBAC [5], which were translated into XACML policies to be interpreted by an XACML engine. In [2], the authors detail a complete implementation of a PEM model for SOA applications. Policies were speciﬁed by using ASTDs [4], which were transformed into BPEL processes. The latter implement ﬁlters executed inside a BPEL engine. The interceptor and PEP are SOAP handlers. The PDP and decision engine were integrated into one Java singleton. All messages are SOAP messages, except for those between the PEP and PDP, which were implemented by Java method calls.

References 1. Coatrieux, G., Embe Jiague, M., Morucci, S.: Implementation of Web services for security enforcement. Internal Technical Report, LACL, Universit´e Paris-Est (2011) 2. Embe Jiague, M., Frappier, M., Gervais, F., Laleau, R., St-Denis, R.: Enforcing ASTD access-control policies with WS-BPEL processes in SOA environments. International Journal of Systems and Service-Oriented Engineering 2, 37–59 (2011)

226

M. Embe Jiague et al.

3. Ferraiolo, D.F., Kuhn, D.R., Chandramouli, R.: Role-Based Access Control, 2nd edn. Artech House, Norwood (2007) 4. Frappier, M., Gervais, F., Laleau, R., Fraikin, B., St-Denis, R.: Extending statecharts with process algebra operators. Innovations in System and Software Engineering 4, 285–292 (2008) 5. Kalam, A.A.E., Baida, R.E., Balbiani, P., Benferhat, S., Cuppens, F., Deswarte, Y., Mi`ege, A., Saurel, C., Trouessin, G.: Organization based access control. In: IEEE 4th International Workshop on Policies for Distributed Systems and Networks, pp. 120–131 (2003) 6. OASIS: eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS (2005)

Specification and Verification of Access Control Policies in EB3SEC: Work in Progress Pierre Konopacki1,2 , Hakim Belhaouari2, Marc Frappier1 , and R´egine Laleau2 1

2

GRIL, D´epartement d’informatique, Universit´e de Sherbrooke, Canada Universit´e Paris-Est, LACL, IUT S´enart Fontainebleau, Fontainebleau, France {pierre.konopacki,marc.frappier}@usherbrooke.ca, {hakim.belhaouari,laleau}@u-pec.fr

Abstract. Information systems are widely used and help in the management of huge quantities of data. Generally, these data are valuable or sensitive, their access must be restricted to granted users. Security is a mandatory requirement for information systems. Several methods already exist to express access control policies, but few of them, like EB3 SEC, support all kinds of constraints that can be defined in access control policies. In this paper, we present how to use EB3 SEC to express two kinds of access control constraints : permissions and prohibitions. Once, constraints are expressed, we provide algorithms to verify that the model of the policy do not lead to deadlock. Keywords: formal method, access control, verification.

1 Introduction Access Control (AC) constraints are generally classified into four categories: i) permissions allowing the execution of an action, ii) prohibitions forbidding the execution of an action, iii) obligations linking two actions: both actions must be executed by the same user [1] , iv) separation of duty (SoD) linking two actions: each action must be done by a different user. We can also distinguish them according to their static or dynamic feature. Static constraints can be considered as invariants on the state of the system. They are always true whatever the state of the system. Permissions, prohibitions and static SoD are static constraints. A static SoD constraint means that if a user is assigned to one role, the user is prohibited from being a member of a second role [2]. Dynamic constraints require to take into account the history of the system, that is the set of actions already performed on a system. Obligations and dynamic SoD are dynamic constraints. With dynamic SoD, users may be authorized for roles that may conflict, but limitations are imposed while the user is actively logged onto the system. As shown in [3], EB3 SEC is a formal language which aims at modeling AC policies. The main objectives of the language are: i) to enable the definition of the four categories of AC constraints, ii) to easily support new security models, iii) to be supported by tools such as formal verifiers or interpreters. In this paper, we show how the EB3 SEC language can be used to model AC policies and we focus on static AC constraints. Section 2 introduces the EB3 SEC language, an J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 227–233, 2012. c Springer-Verlag Berlin Heidelberg 2012

228

P. Konopacki et al.

example of AC policy and its modeling in EB3 SEC. Section 3 shows how the correctness of an EB3 SEC model can be verified.

2

EB3 SEC

EB3 SEC is based on EB3 [4], a process algebra. This kind of languages is more suitable to express events ordering constraints, compared to state-based languages like B or Z [5]. In EB3 SEC, events are secure events. A secure event is an action of the system enhanced with security parameters representing persons, roles, organizations, etc. The originality of EB3 SEC versus other AC languages is that the number and the type of security parameters can be adapted to the IS. Thus EB3 SEC allows the designer to define his own AC model. It can be existing models such as RBAC [6], OrBAC [7] or extensions of them in order to capture specific AC requirements of the IS. An EB3 SEC specification contains two parts: a security class diagram and a set of process expressions. Process expressions depict the dynamic behaviour of the AC policy. They are used to express dynamic SoD and obligations at a workflow level. For further details, readers can refer to [3]. A security class diagram contains classes and associations necessary to define the different concepts used to specify static AC constraints. Classes define the type of the security parameters ; the choice of classes can be adapted to the AC policy of the IS, according to the relevant concepts of the AC policy of a given IS. We provide in this paper an example of a class diagram derived from the OrBAC method [7] and depicted in figure 1.

Action 0..n

0..n 0..n

Role 0..n Play 0..n Person

0..n

0..n

Prohibition Permission

0..n Branch

0..n

Fig. 1. Example of security class diagram

Four classes are involved in this class diagram: class person is used to model all users of the IS, class role depicts all roles that can be played in the IS, class branch describes all the branches where the IS is used and class action encompasses all actions existing in the AC policy. Association play describes the role that a user can play in a branch, as in OrBAC. Both associations permission and prohibition link classes role, branch and action. Association permission (respectively prohibition) describes which role can (respectively, is not allowed) to execute an action in which branch. We use an example of the bank domain. This example deals with check deposit procedure. The deposit of a check can be done by clerks and bankers but their validation

Specification and Verification of Access Control Policies in EB3 SEC

229

must be done by bankers only. We suppose that there are several branches and we focus on one of them which is called Montreal. In this branch two roles can be played: clerk and banker. play () == & & & ; Fig. 2. Instance of the association play

Figure 2 shows an instance of association play. This clause depicts the fact that Alphonse is a clerk in the branch of Montreal, Boris is a banker in the branch of Montreal, etc.. The next clause, in figure 3, describes permissions that hold in the IS. It depicts an instance of the association Permission. permission () == & & ; Fig. 3. Instance of the association Permission

The instance shown in figure 3 depicts the AC policy of the example. We can also use an instance of the association Prohibition to express the fact that clerks are not allowed to validate a check, as shown in figure 4. prohibition () == ; Fig. 4. Instance of the association Prohibition

Now, we suppose that we have the user Catherine who plays the role clerk in Montreal but has the authorization to deposit any check. To model this AC constraint, we introduce a new clause called genPermission, shown in figure 5. Each line of the clause genPermission contains a tuple. Each tuple contains four parts. The last part is an action of the IS. The first three parts correspond to the security environment which contains security parameters. The first security parameter is the user who executes the action, the second part is the role that must be played to execute the action and the third part is the organization where the action can be executed. Each of the security parameters can be replaced by ’ ’. Symbol ’ ’ means that the security

230

P. Konopacki et al.

genPermission () == <_,clerk,Montreal,deposit()> & <_,banker,Montreal,deposit()> & <_,banker,Montreal,validate()> & ; Fig. 5. Example of clause genPermission

parameter can take any value. This clause is used instead of the clause permission: each element of the clause permission is extended with a value equal to ’ ’ for the security parameter corresponding to user. The semantics of these tuples is given by: u, r, o, a∈genPermission⇔ (u, r, o) ∈ play ∧ (r, o, a) ∈ Permission On the opposite, we consider that the user called Denis is a banker who is not allowed to validate any check. To model this AC constraint, we introduce a new clause called genProhibition, shown in figure 6. genProhibition () == <_,clerk,Montreal,validate()> & ; Fig. 6. Example of clause genProhibition

The semantics of tuples used in genProhibition is given by: u, r, o, a∈genProhibition⇔ (u, r, o) ∈ play ∧ (r, o, a) ∈ Prohibition genPermission and genProhibition statements can be used to described AC policies that are not complying with standards such as RBAC [2] or OrBAC [7].

3 Verification The set of permissions and prohibitions can contain contradictions and even deadlocks (i.e., an action can never be executed because of too many prohibitions). We provide algorithms to avoid such deadlocks. The main idea of the algorithm is to compute, for each action, the set of security environments allowed to execute this action and the set of security environments which are not allowed to perform this action.

Specification and Verification of Access Control Policies in EB3 SEC

231

Then we remove, for each action, the set of forbidden security environment from the set of allowed security environment. Finally, if an action obtains an empty set of security environment, it cannot be executed. − −→ We define two security environments called − p−→ sec = (u, r, o) and psec = (u , r , o ), a relation called isParamComp and a relation isComp. isParamComp(x, x ) 1. if (x = ∨ x = ) return T RUE 2. else if (x = x ) return T RUE 3. else return FALSE −→ →, − isComp(− p− sec psec ) return 1. isParamComp(u, u ) 2. ∧ isParamComp(r, r ) 3. ∧ isParamComp(o, o ) Relation isParamComp checks whether two security parameters are compatible: if the value of at least one of them is , they are compatible otherwise they must have the same value. Relation isComp verifies that two security environments are compatible: that is to say that all of their security parameters are compatible. The first step is to unfold clauses play and permission, this means obtaining, for each action the set of security environments that authorize the action to be performed. The algorithm PerE f f shown in the following is used to execute this step. It is presented in a functional way, a` la CAML. PerE f f (play, genPermission) match permission with →, a( ) :: queue → return un f oldPlay(play, − 1. − p− p−→ sec sec , a) ∪ PerE f f (play, queue) 2. null → return 0/ un f oldPlay(play, − p−→ sec , a) match play with −−→ − → →, − 1. psec :: queue → if (isComp(− p− sec psec ) −− → return psec , a( ) ∪ un f oldPlay(queue, − p−→ 2. sec, a) − − → 3. else return un f oldPlay(queue, psec, a) 4. null → return 0/ Figure 7 shows the result of this algorithm with the example. The next step is to obtain, for each action, the security environments that are forbidden by the clause genProhibition. The following algorithm performs this task, it is presented in a functional way, a` la CAML. ProhE f f (play, genProhibition) match interdiction with →, a( ) :: queue → return un f oldPlay(play, − 1. − p− p−→ sec sec , a) ∪ ProhE f f (play, reste) 2. null → return 0/ The figure 8 shows the result of this algorithm with the example.

232

P. Konopacki et al.

PerE f f (play, genPermission) = [ Al phonse, clerk, Montreal, deposit , Catherine, clerk, Montreal, deposit , Boris, Banker, Montreal, deposit , Denis, Banker, Montreal, deposit , Boris, Banker, Montreal, validate , Denis, Banker, Montreal, validate , Catherine, clerk, Montrealvalidate] Fig. 7. Result of PerE f f

ProhE f f (play, genProhibition) = [ Al phonse, clerk, Montreal, validate , Catherine, clerk, Montrealvalidate , Denis, Banker, Montreal, validate] Fig. 8. Result of ProhE f f

PermReal(PerE f f (play, genPermission), ProhE f f (play, genProhibition)) = [ Al phonse, clerk, Montreal, deposit , Catherine, clerk, Montreal, deposit , Boris, Banker, Montreal, deposit , Denis, Banker, Montreal, deposit , Boris, Banker, Montreal, validate] Fig. 9. Result of PermReal

The last step consists in removing, for each action, all security environments that are forbidden from the set of security environments that are allowed. This step is enforced by the algorithm PermReal. PermReal(pE, iE) match iE with →, a( ) :: queue → return removeI(pE, − 1. − p− p−→ sec sec , a) ∪ PermReal(pE, queue) 2. null → return 0/ removeI(pE, − p−→ sec , a) match pE with −−→ −→ → = − 1. psec , a’ :: queue → if (− p−sec p sec ∧ a = a’) −−→ →, a) return p sec , a( ) ∪ removeI(queue, − p− 2. sec − − → else return removeI(queue, psec , a) 3. 4. null → return 0/ The figure 9 shows the result of this algorithm with the example. In this example, each action has at least one security environment allowing its execution. Thus no deadlock is detected.

Specification and Verification of Access Control Policies in EB3 SEC

233

4 Conclusion and Future Works In this paper, we provide a language which allows to express EB3 SEC models. As it is a work on progress, by now, the language allows to describe an AC policy which contains only permissions and prohibitions. The sets of permissions and prohibitions made in the model can sometimes leads to a deadlock: because of too much prohibitions an action cannot be executed. To prevent this situation, we provide algorithms that help to check the correctness of a model. In the future, we want to incorporate new operators and new clauses which allow the modeler to define SoD and obligation constraints in the model. We are aware that these new patterns can introduce new situations that can lead to deadlocks. We have to provide new tools which allowed the verification of the patterns. As described in [8], model checking over EB3 specifications, is a difficult task but with the TAMAGO [9] framework we would be able to provide tools which could be helpful to simulate the models and at least to detect such errors. This framework also help us to have an implementation that could be compared to the APIS platform 1 . Furthermore, we can also compare these implementations to the results given by an XACML [10] profile.

References 1. Ni, Q., Bertino, E., Lobo, J.: An obligation model bridging access control policies and privacy policies. In: Proceedings of the 13th ACM Symposium on Access Control Models and Technologies, SACMAT 2008, pp. 133–142. ACM, New York (2008) 2. Ferraiolo, D.F., Kuhn, D.R., Chandramouli, R.: Role-Based Access Control. Artech House, Inc., Norwood (2003) 3. Konopacki, P., Frappier, M., Laleau, R.: Expressing access control policies with an eventbased approach. In: WISSE (2011) 4. Frappier, M., St-Denis, R.: EB3 : an entity-based black-box specification method for information systems. Software and System Modeling 2(2), 134–149 (2003) 5. Fraikin, B., Frappier, M., Laleau, R.: State-based versus event-based specifications for information systems: a comparison of B and EB3 . Software and Systems Modeling 4(3), 236–257 (2005) 6. Anderson, A.: XACML Profile for Role Based Access Control (RBAC). OASIS Standard (2004) 7. Kalam, A.A.E., Benferhat, S., Mi`ege, A., Baida, R.E., Cuppens, F., Saurel, C., Balbiani, P., Deswarte, Y., Trouessin, G.: Organization based access control. In: Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY 2003, pp. 120–130. IEEE Computer Society, Washington, DC (2003) 8. Frappier, M., Fraikin, B., Chossart, R., Chane-Yack-Fa, R., Ouenzar, M.: Comparison of Model Checking Tools for Information Systems. In: Dong, J.S., Zhu, H. (eds.) ICFEM 2010. LNCS, vol. 6447, pp. 581–596. Springer, Heidelberg (2010) 9. Belhaouari, H., Peschanski, F.: A Lightweight Container Architecture for Runtime Verification. In: Leucker, M. (ed.) RV 2008. LNCS, vol. 5289, pp. 173–187. Springer, Heidelberg (2008) 10. Moses, T.: eXtensible Access Control Markup Langage (XACML) Version 2.0. OASIS Standard (2005) 1

http://www.dmi.usherb.ca/˜ frappier/

A Metamodel of the B Modeling of Access-Control Policies: Work in Progress J´er´emy Milhau1,2 , Marc Frappier1 , and R´egine Laleau2 1

2

GRIL, D´epartement Informatique, Universit´e de Sherbrooke, 2500 boulevard universit´e, Sherbrooke J1K 2R1, Qu´ebec, Canada {Jeremy.Milhau,Marc.Frappier}@USherbrooke.ca Universit´e Paris-Est, LACL, IUT S´enart Fontainebleau, D´epartement Informatique, Route Hurtault, 77300 Fontainebleau, France [email protected]

Abstract. Veriﬁcation and validation of access-control policies for information systems is a diﬃcult yet necessary task. In order to take advantage of the formal properties and tools of the B method, we introduce in this paper a metamodel of the B modeling of access control policies. This metamodel lead to the development of a formal prototype of an access control ﬁlter combined to the system. It allows veriﬁcation and validation of policies before implementation. Keywords. Metamodel, access-control, IS, formal method, MDA, B.

1

Introduction

In the context of information systems (IS), we advocate the use of formal methods in order to prevent unexpected behavior and produce a software correct by design. Following this approach, we have proposed a way to specify the functional part of an IS and to systematically implement it using the APIS platform [4]. We now focus on the speciﬁcation of access-control (AC) policies, i.e. the expression of rules describing if an action can be executed in the system given a context. We think that separating AC policies from the functional core of a system fosters maintainability and reduces the complexity of future modiﬁcations. However, expressing AC rules is not a trivial task. Several languages and notations have been proposed, each one with its strengths and weaknesses. Our approach encompasses two steps to specify AC rules. The ﬁrst one consists in expressing AC rules with UML-like graphical notations, thus they can be understood and validated by stakeholders. Then these graphical notations are translated into formal notations in order to be veriﬁed and animated [10]. 1.1

Combining Static and Dynamic Rules

AC rules can be characterized by several criteria. For instance, they can be either static or dynamic. According to Neumann and Strembeck in [11], dynamic rules

This research is funded by ANR (France) as part of the SELKIS project (ANR-08SEGI-018) and by NSERC (Canada).

J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 234–241, 2012. c Springer-Verlag Berlin Heidelberg 2012

A Metamodel of the B Modeling of Access-Control Policies

235

are deﬁned as rules that can only be evaluated at execution time according to the context of execution. Static rules are deﬁned as invariants on the state of a system. For example a static rule would grant the execution of action a by user u at any time, whereas a dynamic rule would grant the execution of action a by user u only if action b was not executed by u before. In order to be evaluated, such dynamic rules require an history of previously executed actions, which can be represented in either the IS state or the policy enforcement manager state. They deﬁne allowed or forbidden workﬂows of actions in a system. We have chosen two notations: Secure-UML and astd in order to model AC policies [10]. 1.2

A Formal Notation for AC Rules

The B notation, developed by Abrial [1], is an abstract machine notation based on set theory and ﬁrst order logic. It involves a development approach based on reﬁnements of models called machines. The initial machine is the most abstract model of the system. Each subsequent reﬁnement step introduces more concrete elements into the model until a ﬁnal reﬁnement produces an implementation, i.e. a machine that can be implemented using a programing language such as C. Each machine is composed of static and dynamic parts. The static part refers to constants and invariants, i.e. properties of the machine. The dynamic part refers to variables and operations that modify variables of the machine. We would like to take advantage of veriﬁcation and validation tools associated with the B method such as ProB [7], an animator and model checker for B speciﬁcations. For that reason, we have chosen to use B to express AC policies. In order to express dynamic rules in a platform-independent model (PIM), we used the astd notation [5], an extension of Harel’s Statecharts using process algebra operators. This notation oﬀers an automata-like representation of workﬂows which can be combined using sequence, guard, choice, Kleene closure, interleave, synchronization and quantiﬁcations over choice and interleave. It also provides a graphical representation of dynamic rules. For static rules, we use a SecureUML-based notation [8]. We then translate both astd speciﬁcations [9] and SecureUML diagrams into B machines (named Dynamic Filter and Static Filter respectively in the following sections). The ﬁnal step of our work is to build an AC ﬁlter implemented using the BPEL notation [3]. We want to use the reﬁnement approach of B to obtain the implemented ﬁlter. In order to do so, we have to identify the concepts required in the implementation and to extend the B metamodel with these new types for AC modeling. We then provide reﬁnement rules between the new types and their implementation.

2

A Proposal for AC Modeling Using B

Our proposed metamodel is an extension of the B metamodel [6] with AC aspects. It describes an AC engine that is able to grant or deny the execution of an action of the IS according to an AC policy. If certain conditions are met then

236

J. Milhau, M. Frappier, and R. Laleau

the action is executed. If one of the conditions does not hold, then it denies the execution. Conditions, i.e. AC rules, can refer to security parameters (such as user, role, organization, . . . ) or functional (business) parameters. Our goal is the reﬁnement to several platform-speciﬁc models (PSMs). In order to do so, we have to specify concepts such as rules or policies that are not explicitly speciﬁed in the original B metamodel. In our PIM metamodel, we specialize classes from the B Metamodel into new ones that correspond to concepts used for deﬁning AC policies. This helps the reﬁnement process by linking a concept of the abstract level to a concept of a more concrete level. The metamodel also combines the static and dynamic parts of the speciﬁcation of an AC policy. Since the metamodel is composed of many classes and is quite large, we will describe it here in a fragmented way. 2.1

Combinaison of B Machines

Fig. 1 presents the part of the metamodel that describes machines and operations used to model a complete AC engine. We will detail in the following sections this part of the metamodel from top to bottom. The ﬁrst line is composed of B machines as denoted by the generalization link between classes. The AC engine is composed of at least four machines. Each one plays a role in the process of granting or denying the execution. The four kinds of machines composing an engine are the following: 1. The functional machine is the core of the IS. It describes how the system evolves over time and how attributes and classes of the system are modiﬁed by the execution of an action. The functional model of the system can also introduce ordering constraints on the actions to be executed. 2. Several static filters can be included in the engine. Each one of them describes a static policy, i.e. a set of static AC rules. Such rules are expressed in an RBAC-like (Role based access-control) notation. For example, there may be one static ﬁlter for authorization and one for prohibition. 3. Several dynamic filters can be included in the engine. Each one of them describes a dynamic policy, i.e. a set of dynamic AC rules that can grant or deny an execution according to the state of the IS, or the state of the dynamic policy itself. All dynamic ﬁlters may not be needed at all time. One of the dynamic ﬁlters can be activated, for example, in emergency situations only. 4. The AC ﬁlter is the main part (controller) of the engine. It is in charge of asking each machine if the action can be executed according to several parameters. It includes all the other machines so it can call their operations. Then it combines the answers it received in order to decide if the action is granted or not. According to the context, it can decide to ignore the decisions made by the static ﬁlters and the dynamic ﬁlters, for instance in the case of emergencies in an hospital. Our metamodel also takes into account operations of these B machines. To illustrate them, we use a case study of an hospital. We consider an action of

%2S3DUDPHWHU

%2SHUDWLRQ

%0DFKLQH

% 0HWDPRGHO

$&B$FWLRQ

Fig. 1. Main part of the metamodel for AC modeling in B UHWXUQV!!

LVBJUDQWHG

6HFXULW\B3DUDPHWHU

FDOOV!!

6HFXUHGB2SHUDWLRQ

$&BUROOEDFN

LQFOXGHV!!

$&B)LOWHU

UHWXUQV!!

6WDWLFB$FWLRQ

6WDWLFB)LOWHU

UROH

XVHU

%IRU$FFHV&RQWURO 0HWDPRGHO

UHWXUQV!!

'\QDPLFB$FWLRQ

'\QDPLFB)LOWHU

LVBH[HFXWHG

)XQFWLRQDOB3DUDPHWHU

)XQFWLRQDOB$FWLRQ

)XQFWLRQDOB0RGHO

A Metamodel of the B Modeling of Access-Control Policies 237

238

J. Milhau, M. Frappier, and R. Laleau

the functional part of the system, called Admission( P atient ), that denotes the admission of a patient in one of the units of the hospital. Such an action is generally performed by a user of the IS who is a doctor. 1. The functional operation Admission( P atient ) is in the functional machine. It is an example of a Functional Action. It speciﬁes all the modiﬁcations that the execution of the action performs on all the entities of the IS and their attributes. It can also describe conditions in order for the action to be executed, for example the patient must have paid his medical bills before being admitted. 2. The static operation Static Admission( P atient, U ser ) is in the static machine. It is an example of a Static Action. It will return granted or denied according to the static policy. Note that in our example a security parameter User was added, compared to Admission( P atient ). This addition can be used to check that the user is a doctor and not a nurse for instance. 3. The dynamic operation Dynamic Admission( P atient, U ser ) is in the dynamic machine. It is an example of a Dynamic Action. It will return granted or denied according to the dynamic policy. The security parameter User can be useful if we want to check that the user of the IS (that should be a doctor, according to the static policy) is a doctor in the same hospital as the patient. 4. Finally, the operation AC Admission( P atient, U ser ) is in the AC ﬁlter machine. It is an example of an AC Action. It calls all static and dynamic operations described above and computes wether or not to execute the action Admission( P atient ) of the functional machine. In our example, the algorithm can take into account emergency situations and the ﬁlter will bypass the static policy if, for instance, an emergency is declared. We also need another operation called rollback( ) that is part of the AC ﬁlter machine. This operation may be required in speciﬁc cases. For instance, if an action was granted to be executed by all static and dynamic machines but the execution fails in the functional machine, the rollback operation must be called. Indeed, the dynamic policy state is modiﬁed when the answer granted is given. In the event of the failure of the execution in the functional machine, the previous state of the dynamic policy must be restored. This is the role of operation rollback. Operation parameters are either security parameters or functional parameters. Security parameters refers to user, their role and any other non-functional related information, whereas functional parameters are parameters of the actions of the IS. All operations from static and dynamic machines return granted or denied as represented by the is granted class and functional operations return success or failure. 2.2

The Static Filter

The static ﬁlter machine deﬁnes a static AC policy that will be enforced on the system. In our example, we have chosen an RBAC-like policy. Each rule

A Metamodel of the B Modeling of Access-Control Policies

% 0HWDPRGHO

239

%IRU$FFHV&RQWURO 0HWDPRGHO LQFOXGHV!!

%0DFKLQH

6WDWLFB)LOWHU

%2SHUDWLRQ

6WDWLFB$FWLRQ

8VHU$VVLJQHPHQWV

6WDWLFB3ROLF\

%3UHFRQGLWLRQ

%6XEVWLWXWLRQ

6WDWLFB5XOH 5XOHB'HILQLWLRQ

3HUPLVVLRQ 3URKLELWLRQ

5XOHB$VVLJQHPHQW

Fig. 2. Details of the static machine of the metamodel for AC modeling in B

of such policy can be expressed as a permission or a prohibition. A rule is a combination of instances of role and action classes. For instance, in an hospital, we can give the permission to any user connected as a doctor to perform action Admission( P atient ). In Fig. 2 the class Rule Definition deﬁnes either a permission to perform an action or a prohibition. Such a deﬁnition is then linked to a role by the class Rule Assignement. The combinination of both is called Static Rule and can be used in one or more B operations (Static Action). The set of all Static Action deﬁne the Static Policy of the Static Filter machine. The Static Filter includes the machine UserAssignements that deﬁnes a role hierarchy and the the roles that a user can play. 2.3

The Dynamic Filter

The dynamic ﬁlter machine deﬁnes a dynamic AC policy that will be enforced on the system. Such policies can be deﬁned using the astd notation. When describing an astd, there are several parts to take into account. An astd is composed of a topology and a state. The topology refers to the structure of the astd. It is unaﬀected by the execution of actions. On the contrary, the state of the astd evolves each time an action is executed. In order to model a workﬂow using the B formalism, we must encode the topology and the state. We do so in our metamodel as depicted by Fig. 3. The state of the workﬂow (Dynamic State) is stored into several variables called State Variable. The Dynamic Policy is composed of several Dynamic Actions

240

J. Milhau, M. Frappier, and R. Laleau

% 0HWDPRGHO

%IRU$FFHV&RQWURO 0HWDPRGHO

%9DULDEOH

6WDWHB9DULDEOH

%2SHUDWLRQ

'\QDPLFB$FWLRQ

%0DFKLQH

'\QDPLFB3ROLF\

LQFOXGHV!!

'\QDPLFB&RQWH[W

%6XEVWLWXWLRQ

'\QDPLFB6WDWH

'\QDPLFB)LOWHU

%3UHFRQGLWLRQ

'\QDPLFB5XOH

Fig. 3. Details of the dynamic machine of the metamodel for AC modeling in B

encoding the topology of the workﬂow into Dynamic Rules. Each rule is composed of B preconditions that can test the value of several State Variables and B substitutions that will modify them, hence the evolving Dynamic State.

3

Conclusion

We have deﬁned a metamodel allowing to use the B notation to model accesscontrol policies to be enforced upon an information system. Such B model can be used in order to validate the policy and perform veriﬁcation and proof of properties, improving the trustworthiness and security of such information systems. In order to validate our approach we have implemented our metamodel using a medical IS case study [10]. The ORKA project [2] proposed a framework to compare the features of AC methodologies. Each method is based on at least one notation that is very good at expressing one type of rule (i.e. static rules for *RBAC, dynamic rules for astd, etc.). But expressing other types of rules may be diﬃcult (as for static rules with astd) or requires the coding of a context introducing state variables. Our approach solves this problem by providing adapted languages for each rules. The combining of all parts of the policy into one single formal model also helps to validate the entire speciﬁcation. The ORKA project evaluates methods according to criteria such as formalism of the notation, availability of veriﬁcation and validation tools, availability of a graphical notation for the policy and the possibility to express constraints. Our approach was developed in order to have all these features available. We are currently working on the next step, i.e. translating a model using the reﬁnement mechanisms of B. This will ensure that a correct implementation of AC policies is provided and improve reliability on such a critical part of the system. We are also working on tools for the translation steps of our approach.

A Metamodel of the B Modeling of Access-Control Policies

241

References 1. Abrial, J.R.: The B-Book: Assigning Programs to Meanings. Cambridge University Press (1996) 2. Consortium, T.O.: ORKA — Organizational Control Architecture (2010), http://www.organisatorische-kontrolle.de/index-en.htm 3. Embe-Jiague, M., St-Denis, R., Laleau, R., Gervais, F.: A bpel implementation of a security ﬁlter. In: PhD Symposium of 8th European Conference on Web Services (2010) 4. Fraikin, B., Gervais, F., Frappier, M., Laleau, R., Richard, M.: Synthesizing information systems: the apis project. In: First International Conference on Research Challenges in Information Science (RCIS), Ouarzazate, Morocco, p. 12 (April 2007) 5. Frappier, M., Gervais, F., Laleau, R., Fraikin, B., St-Denis, R.: Extending statecharts with process algebra operators. Innovations in Systems and Software Engineering 4(3), 285–292 (2008) 6. Idani, A.: B/UML: Mise en relation de sp´eciﬁcations B et de descriptions UML pour l’aide a ` la validation externe de d´eveloppements formels en B (2006) 7. Leuschel, M., Butler, M.J.: Prob: A Model Checker for B. In: Araki, K., Gnesi, S., Mandrioli, D. (eds.) FME 2003. LNCS, vol. 2805, pp. 855–874. Springer, Heidelberg (2003) 8. Lodderstedt, T., Basin, D., Doser, J.: SecureUML: A UML-Based Modeling Language for Model-Driven Security. In: J´ez´equel, J.-M., Hussmann, H., Cook, S. (eds.) UML 2002. LNCS, vol. 2460, pp. 426–441. Springer, Heidelberg (2002) 9. Milhau, J., Frappier, M., Gervais, F., Laleau, R.: Systematic Translation Rules from astd to Event-B. In: M´ery, D., Merz, S. (eds.) IFM 2010. LNCS, vol. 6396, pp. 245–259. Springer, Heidelberg (2010) 10. Milhau, J., Idani, A., Laleau, R., Labiadh, M.A., Ledru, Y., Frappier, M.: Combining UML, ASTD and B for the formal speciﬁcation of an access control ﬁlter. Innovations in Systems and Software Engineering 7(4), 303–313 (2011) 11. Neumann, G., Strembeck, M.: An approach to engineer and enforce context constraints in an rbac environment. In: Proceedings of the 8th ACM Symposium on Access Control Models and Technologies, SACMAT 2003, pp. 65–79 (2003)

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems: Work in Progress Wiem Tounsi, Nora Cuppens-Boulahia, Frédéric Cuppens, and Joaquin Garcia-Alfaro Institut Télécom, Télécom Bretagne, CS 17607, 35576 Cesson-Sévigné, France [email protected], [email protected]

Abstract. The EPC Class-1 Generation-2 (Gen2 for short) is a standard Radio Frequency Identification (RFID) technology that has gained a prominent place on the retail industry. The Gen2 standard lacks, however, of verifiable security functionalities. Eavesdropping attacks can, for instance, affect the security of monitoring applications based on the Gen2 technology. We are working on a key establishment protocol that aims at addressing this problem. The protocol is applied at both the initial identification phase and those remainder operations that may require security, such as password protected operations. We specify the protocol using the High Level Protocol Specification Language (HLPSL). Then, we verify the secrecy property of the protocol using the AVISPA model checker tool. The results that we report show that the current version of the protocol guarantees sensitive data secrecy under the presence of a passive adversary.

1 Introduction The RFID technology is one of the most promising advances in current pervasive infrastructures. It allows contactless identification of tagged objects and people. The EPC Gen2 standard, short-hand for the Electronic Product Code (EPC) Class-1 Generation2 [8], is a proper example of this technology. Most promising Gen2 scenarios relay on passive tags designed with very basic capabilities. Gen2 tags derive their transmission and computational power from the signal of an interrogating device. Albeit they can perform some basic arithmetic operations, they are characterized with a very minimalist design, specially with regard to the implementation of security functionalities. For this reason, the security of the EPC Gen2 technology is gaining great attention in both industry and academia [9]. One important focus of research is the inclusion of verifiable secure key establishment protocols, to prevent eavesdropping attacks [10]. In this regard, we present in this paper a work-in-progress protocol that aims at addressing the aforementioned objective. We present the protocol and describe its translation into High Level Protocol Specification Language (HLPSL), a specification language for formalizing protocols and security goals based on Lamport’s Temporal Logic of Actions (TLA) [11]). Finally, we evaluate the translated description with the AVISPA model checker tool, a well known EU funded software verification framework for the automatic validation of security protocols [1]. The initial results that we report show that the protocol guarantees secrecy in the presence of a passive adversary. J. Garcia-Alfaro and P. Lafourcade (Eds.): FPS 2011, LNCS 6888, pp. 242–251, 2012. c Springer-Verlag Berlin Heidelberg 2012

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems

243

Paper Organization. Section 2 motivates our work. Section 3 describes the protocol. Section 4 presents some necessary assumptions. Section 5 overviews the AVISPA tool and the HLPSL format. Section 6 models the protocol in HLPSL and summarizes the results of the automatic verification process. Section 7 concludes the paper.

2 Motivation Flawed Gen2 Security Model. The Gen2 specification considers some special operations that require reader authentication, such as tag memory writing, decommission of tags, and tag self-destruction. They require the communication of a password prior the tag execution. Such a password must be sent via the insecure reader-to-tag channel. Since this channel is more likely to suffer from eavesdropping attacks than the tag-toreader channel, the specification proposes to protect the exchange as follows: 1. READER −→ TAG : Key-request 2. TAG −→ READER : Key 3. READER −→ TAG : Password ⊕ Key The reader informs in Step 1 that it is waiting for a key necessary to obscure the following exchange (cf. Step 3) that will eventually contain the required password to grant the execution of the operation. The key can also be used in order to obscure the contents of the remainder parts of the operation (e.g., to protect the data associated to a memory writing operation). The key is generated by the tag as a random bit string, and transmitted in Step 2 in plaintext to the reader. This is done via the tag-to-reader channel which, in principle, is expected to have an eavesdropping range much lower that the reader-totag channel. This exchange supposes that an adversary eavesdropping the reader-to-tag channel cannot capture the sensitive data (either the password or the contents of the password-protected operation). However, it is straightforward that an adversary capable of eavesdropping the tag-to-reader channel using special hardware devices (e.g., readers with high sensitive receivers and multiple antennas), or predicting the output of the random bit generator of the tag (e.g., based on a flawed EPC Gen2 pseudorandom generator), can simply obtain such a sensitive data by applying the obtained key and an Exclusive-OR operation. Lack of Formally Verified Security Enhancements. There have recently been many approaches focusing on enhancing the security of the EPC Gen2 technology [9]. Some of these approaches propose physical solutions, including new cryptographic primitives on-board of the tags; others propose straighforward protocols, that remain to be adapted to the Gen2 contsraints. However, a great number of solutions have been reported as insecure. For instance, recent cases of authentication techniques for EPC Gen2 were reported vulnerable by Li and Wang in [13]; by Li and Deng in [12]; and by Cao, Bertino, and Lei in [6]. These cases show the lack of formal verification of new security techniques for EPC Gen2, which we consider deemed necessary.

3 Proposed Key Establishment Protocol The protocol aims at establishing a secure communication between a reader and a tag without any advance exchange of a secret key. This assumes the existence of a shared

244

W. Tounsi et al.

generation function denoted by KeyGen. The KeyGen function generates for each exchanged message a secret key named derived key (e.g., KDer-i ) relying on some initialization values (e.g., a master key KMaster , a timestamp t). The validity of the derived keys depends on the validity of the master key. This validity is decided by a third entity (not described in this work) through a computational approach after a fixed number of use. In the sequel, we present the three main stages of the protocol. 1. Reader Authentication. The reader must first prove its identity to the tag. We assume that preserving on-board tag generated data is the aim of our protocol. Thus, we consider that readers are likely to be dishonest rather than tags. Moreover, the constrained capacity of the tag (mainly, the lack of energy) to follow all the communication process or to disturb it, weaken the possibility for a tag to play the role of an adversary. The reader authentication steps are described below. 1. 2. 3. 4.

READER TAG READER TAG

−→ −→ −→ −→

TAG READER TAG READER

: : : :

ReadID TagID TagID ⊕ KDer0 KDer1

The reader requests the identification of the tag (denoted by the ReadID command) in Step 1. As a result, the reader receives in Step 2 the tag identification (denoted as TagID). The reader verifies the existence of this identification in its related database and extracts the last state of the identified tag (e.g., master key, timestamps, internal vectors). This state allows to derive a new derived key named KDer0 , based on the master key KMaster . The result of this generation is XORed with the received TagID and sent to the tag in Step 3. Upon receiving the message TagID ⊕ KDer0 , the tag generates a new key from the shared KeyGen function and checks the equality of this new generated key and the received value. If they are equal, the tag generates a new derived key with the same function and sends it as an acknowledgement to the reader in Step 4. 2. Master Key Assignment. The reader distributes now a new master key to refresh the protocol state on the two sides. 5. READER −→ TAG : (Knew-Master,t) ⊕ KDer2 6. TAG −→ READER : Knew-Der0 The reader sends in Step 5 a new calculated master key concatenated with a timestamp t, XORed together with KDer2 which is generated using the initialized master key. The tag, in turn, calculates a new K’Der2 and checks the correctness of the sent KDer2 by applying an XOR operation as follow: (Knew-Master ,t) ⊕ KDer2 ⊕ K’Der2 . If KDer2 = K’Der2 , the tag obtains (Knew-Master,t) using the nilpotency property (cf., Section 4), and recognizes the shared timestamp t to eventually deduce the Knew-Master . Finally, the tag updates its variables and acknowledges in Step 6 a new derived key using the KeyGen function initialized by the new received master key. 3. Remainder Gen2 Operations. The system can now continue with other Gen2 operations, such as reading or writing data from/to the tag. For instance, the following steps exemplify the protocol part associated to a Write operation:

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems

7. READER 8. TAG 9. READER 10. TAG

−→ −→ −→ −→

TAG READER TAG READER

: : : :

245

oprequest ⊕ Knew-Der1 Knew-Der2 (data,t) ⊕ Knew-Der3 Knew-Der4 ⊕ opreply

The reader sends in Step 7 a request command named oprequest XORed with a new derived key. oprequest is a command to have the permission for writing. The tag checks the authentication of the reader by verifying Knew-Der1 and acknowledges the request by sending in Step 8 a new derived key generated using the KeyGen function. The reader sends in Step 9 the data to be written. Upon accepting the data, the tag replies in Step 10 with a new derived key XORed with a predefined command opreply to acknowledge the operation.

4 Assumptions Prior the Verification Process We want to decide whether the protocol ensures the secrecy of some sensitive terms (e.g, the master key that can reveal the sequence of the derived keys) under a number of assumptions, namely the encryption model and the adversary capabilities. By ensuring secrecy, we expect that the adversary cannot deduce from his initial knowledge of the protocol and the environment of its execution and from the set of messages sent in a given execution more than what he is permitted to know. Encryption Model. The hypothesis of perfect encryption inspired by the Dolev-Yao model [7], has been long assumed in the modeling of cryptographic protocols. This hypothesis idealizes the cryptography used in the functions. It allows to overcome the complexity of these functions by embedding the algebraic properties of the cryptographic primitives into black boxes (i.e., the only way to decrypt a message is to know the encryption key). This assumption has allowed to find numerous logical flaws in protocols (e.g., in the Shamir 3-pass protocol [14]). We relax the perfect encryption hypothesis by exposing the cryptographic primitives used in our protocol and analyzing them according to their algebraic properties. We explicitly define an encryption method based on a one time pad using the XOR operator (e.g., a message m encrypted with a key k is denoted as m ⊕ k). The XOR operator is known to have four properties that constructs a deduction rules for the adversary: 1. 2. 3. 4.

x x x x

⊕ ⊕ ⊕ ⊕

y = y ⊕ x (Commutativity) (y ⊕ z) = (x ⊕ y) ⊕ z (Associativity) 0 = x (Neutral element) x = 0 (Nilpotency)

Adversary Capabilities. We consider a passive adversary. The introduction of the properties of the XOR operator that weaken the assumption of a perfect encryption extends the capabilities of the adversary and strengthen his deduction possibilities. The adversary has an entire control of the communication channels. It can harvest his knowledge by using, at first, the information he initially knows about the participants, the network characteristics and the algebraic properties of the protocol (e.g., the standards used in the communication or the key generation algorithm) and, at second, by eavesdropping the different messages sent in the network to use them as input of his deduction process.

246

W. Tounsi et al.

5 The AVISPA Model Checking Tool 5.1 A Brief Presentation AVISPA [1] is a suite of applications commonly used for automated validation and verification of cryptographic protocols. It maintains a library of security protocol specifications written in the HLPSL language (e.g., 54 IETF protocols are tested). For each protocol, the expected security properties and the possible attacks found are described. The AVISPA framework is composed of several modules. A translator called HLPSL2IF for transforming HLPSL specifications to a low level specification with IF language (Intermediate Format) and four different verification backends to analyze the IF specifications. These backends are named: On the Fly Model Checker(OFMC) [3], ConstraintLogic based Attack Searcher (CL-AtSe) [17], SAT based Model-Checker (SAT-MC) [2] and Tree Automata based Protocol Analyser (TA4SP) [4]. Each backend has its own options and parameters to define before the verification. After the verification process, the output describes the result, and under what conditions it has been obtained. The output format is common to all backends of the AVISPA tool. In the SUMMARY section; it indicates if the protocol is safe, unsafe, or if the analysis is inconclusive. In a second section titled DETAILS, the tool explains under what conditions/reasons the protocol is declared safe/unsafe/inconclusive. The next sections, PROTOCOL, GOAL and BACKEND recall the name of the protocol, the goal of the analysis and the name of the back-end used, respectively. Finally, some possible comments and statistics of the execution are described and the trace of the attack (if any) is printed in an Alice&Bob notation which means that a given goal has been violated. 5.2 The HLPSL Format The protocol and the verification assumptions are specified in the High Level Protocol Specification Language (HLPSL) [5]. HLPSL is a specification language for formalizing protocols and security goals based on Lamport’s Temporal Logic of Actions (TLA) [11]). The language, developed in the context of the AVISPA framework [1], is a role-based language focusing on roles rather than on messages exchange. Roles can be basic (cf., agent roles) describing the action of an agent during the execution of the protocol or composed (cf., session and environment roles) describing scenarios of basic roles to model an entire protocol run including the adversary model. Basic Roles. Figure 1(a) shows how the basic role is generally structured. Each basic role declares its name (designed by A), its initial information or parameters (denoted by param) and the agent playing the role (denoted by ag). The basic role can declare a set of local variables (denoted by L). The init section assigns the initial values to the local variables, if required. The transition section describes changes of the agent state. It consists of a trigger (e.g., evt.2) and an action (e.g., act.2) to be performed when the trigger event occurs. The = | > symbol separates the two phases. Composed Roles. Composed roles combine basic roles, either in parallel or in sequence. HLPSL defines two composed roles: the session role and the environment role.

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems

(a)

(d)

role A(param) played by ag def= local L init Init transition evt.0 ^ evt.1 = | > act.1 evt.2 = | > act.2 ... evt.n = | > act.n end role

goal secrecy_of sec_kn end goal

247

role S (param) def= const C composition R1 (param-1) ^ . . . ^ Rn (param-n) end role

(b)

role environment (param) def= const C intruder_knowledge = IN composition S1 (param-1) ^ . . . ^ Sn (param-n) end role

(c)

Fig. 1. HLPSL main elements. (a) Basic role structure. (b) Session role structure. (c) Environment role structure. (d) Secrecy in the goal section.

Actions, in composed roles, are not defined in a transition section like in basic roles. Rather, a composition section is defined to instantiate other roles Ri or Si (with sets of parameters param-i) that run in parallel (cf., Figures 1(b) and 1(c)). The session role (named S), instantiates in its composition section the basic roles and the different channels relating them while the environment role instantiates in its composition section all the sessions to be run (referred by Si). The environment role is called the main role, as it declares the global constants (denoted by C) and defines the intruder knowledge (i.e., the information that the adversary knows and eavesdrops, denoted by IN). Security Properties. HLPSL provides an independent section to declare the security properties required, named goal. The goal declaration can be done either by using predefined macros of the security properties (secrecy, weak authentication, strong authentication) or by using Linear Temporal Logic formulas [11]. We are interested in the secrecy property (cf. reference [5] for its complete definition). The property is added to the honest basic role and identified by protocol_id type. It is declared later in the goal section. For example, assuming that sec_kn is the name of the secret term, the secret(Knew’,sec_kn,A,B) expression is added in the honest player of the role claiming that Knew’ must be a secret term and that it is known only by the two agents A and B. The constant sec_kn is declared later in the goal section as seen in the Figure 1(d).

6 Automatic Verification of the Protocol Modeling the Protocol and the Assumptions in HLPSL. The specification of both the protocol (cf., Section 3) and the verification assumptions (cf., Section 4) is described into five HLPSL sections: two sections for the basic roles (the tag and the reader) and two sections for the composed roles (the session and the environment roles). A special

248

W. Tounsi et al.

RFID role role tag (B,A : agent, Keygen : hash_func, Tagid,Opreq,Tmp : text, Snd,Rcv : channel (dy)) played_by B def= local State : nat, L,L1,L2,L3,L4,L5,L6,L7 : message, Instate: text, Opwr : text, Kold : text, Knew : text init State:=0 transition 1. State=0 ^Rcv(xor(Tagid,L')) =|> State':=1 ^Instate' :=new() ^L1':= Keygen(L',Instate') ^Snd(L1') 2. State=1 ^Rcv(xor((Knew'.Tmp),L2')) =|> ^State':=2 ^Instate' :=new() ^L3':= Keygen(Knew,Instate') ^Snd(L3')

3. State=2 ^Rcv(xor((Opreq.Tmp),L4')) =|> State' :=3 ^Instate' :=new() ^L5':= Keygen(L4',Instate') ^Snd(L5') 4. State=3 ^Rcv(xor((Opwr'.Tmp),L6')) =|> State' :=4 ^Instate' :=new() ^L7':= Keygen(L6',Instate') ^Snd(L7') Environment role role environment() def= local Snd, Rcv: channel(dy) const sec_kn: protocol_id, a, b: agent, keygen: hash_func, tagid,opreq,tmp : text, l,l1,l2,l3,l4,l5,l6,l7: message intruder_knowledge = {a,b,tagid, opreq,tmp,keygen,l,l1,l2,l3,l4, l5,l6,l7} composition session(a,b,keygen,tagid,opreq,tmp) goal secrecy_of sec_kn, sec_opwr end goal

Fig. 2. Specification sketch of the protocol in HLPSL

(a)

% OFMC SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS PROTOCOL FPS2011Protocol.if GOAL as_specified BACKEND OFMC COMMENTS STATISTICS parseTime: 0.00s searchTime: 2.18s visitedNodes: 1715 nodes depth: 8 plies

%CL-AtSe SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS TYPED_MODEL PROTOCOL FPS2011Protocol.if GOAL As Specified BACKEND CL-AtSe STATISTICS Analysed : 3 states Reachable : 3 states Translation: 0.01 seconds Computation: 0.00 seconds

Fig. 3. Evaluation results. (a) OFMC results. (b) CL-AtSe results.

(b)

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems

249

section is dedicated to the secrecy goal. Due to space restrictions, we only show in Figure 2 one basic role (the RFID role) beginning by Step 3, one composed role (the environment role) and the goal section1 . We assume that the reader and the tag execute some key generation function, initialized by the master key (K or Knew) and an internal state (Instate), to generate the derived keys. The output value of this function is used as an input of the next execution, defining a succession of internal states and of derived keys. For that aim, we use an HLPSL function of type hash_fun to specify the generation function called Keygen. This function is supposed to be known to the intruder. Thus, the intruder is able to calculate the successors of Keygen(Li,Instate), called also the derived keys, and can invert the outputs of the Keygen function only if he knows/deduces all the entries of Keygen (e.g., the updated internal state (Instate)). In the environment role, as channels in AVISPA are until now of only type (dy) relying on the Dolev-Yao intruder model [7], we define a passive adversary by adding to his knowledge all the data transmitted in the network in addition to the knowledge of the key generation function and the standards used in the communication, without attributing him an active role to play in the composition section. Finally, in the goal section, the Master key and the data written on the tag are specified as (sec_kn) and (sec_opwr) respectively, to be checked for secrecy requirements. Obtained Results. We have used the OFMC and CL-AtSe backends of the AVISPA framework. Both the OFMC and CL-AtSe backends support analyzing protocols with Exclusive-OR properties. They do it for a bounded number of sessions. The backends are called with the default options. Results have reported the protocol as safe (cf. Figure 3), meaning that the stated security goals (cf. Section 6) are successfully checked by the OFMC and CL-AtSe backends for a bounded number of sessions. Therefore, we can affirm that our protocol satisfies the secrecy of the sensitive data, named the master key and the data written in the tag, with respect to a passive intruder, as specified in the environment role.

7 Conclusion Motivated by the security flaws of the EPC Gen2 RFID specification, and the lack of formally verified security enhancements for this technology, we are working towards the specification and deployment of a key establishment protocol for Gen2 systems. In this paper, we have described the specification and formal verification of an early version of the protocol using the AVISPA model checking tool. We have presented how we described the protocol using the HLPSL format, and verified the secrecy property of the protocol under the presence of a passive adversary. We have then showed how we used two of the verification algorithms implemented in the AVISPA tool to analyze the security of the main cryptographic primitive used in the proposed protocol. As future perspectives, we aim at continuing the evaluation of the protocol under the presence of an active adversary. In this regard, more security goals must be considered, particularly for guaranteeing the authenticity of the reader. We also plan to define the 1

Full HLPSL code available at: http://j.mp/FPS2011

250

W. Tounsi et al.

appropriate key generation functions, and their introduction to the constrained environment of a Gen2 tag. This contribution shall allow us to decide about the refresh period of the established keys. Acknowledgments. The authors graciously acknowledge the financial support received from Institut TELECOM through its Future et Rupture program; and from the Spanish Ministry of Science and Innovation (grants TSI2007-65406-C03-03 E-AEGIS and CONSOLIDER-INGENIO CSD2007-00004 ARES).

References 1. Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Compagna, L., Cuellar, J., Drielsma, P.H., Heám, P.C., Kouchnarenko, O., Mantovani, J., Mödersheim, S., von Oheimb, D., Rusinowitch, M., Santiago, J., Turuani, M., Viganò, 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) 2. Armando, A., Compagna, L.: SATMC: A SAT-Based Model Checker for Security Protocols. In: Alferes, J.J., Leite, J. (eds.) JELIA 2004. LNCS (LNAI), vol. 3229, pp. 730–733. Springer, Heidelberg (2004) 3. Basin, D.A., Sebastian, M., Vigano, L.: OFMC: A symbolic model checker for security protocols. International Journal of Information Security 4(3), 181–208 (2005) 4. Boichut, Y., Heam, P.C., Kouchnarenko, O., Oehl, F.: Improvements on the genet and klay technique to automatically verify security protocols. In: Automated Verification of InfiniteState Systems (AVIS 2004), Joint to ETAPS 2004, pp. 1–11 (2004) 5. Chevalier, Y., Compagna, L., Cuellar, J., Hankes Drieslma, P., Mantovani, J., Modersheim, S., Vigneron, L.: A High Level Protocol Specification Language for Industrial SecuritySensitive Protocols. In: Workshop on Specification and Automated Processing of Security Requirements (SAPS 2004), pp. 193–205 (2004) 6. Cao, T., Bertino, E., Lei, H.: Security Analysis of the SASI Protocol. IEEE Transactions on Dependable and Secure Computing 6(1), 73–77 (2008) 7. Dolev, D., Yao, A.: On the Security of Public-Key Protocols. IEEE Transactions on Information Theory 2(29), 198–207 (1983) 8. EPCglobal. EPC Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID Protocol for Communications at 860-960 MHz, http://www.epcglobalinc.org/ standards/ 9. Garcia-Alfaro, J., Barbeau, M., Kranakis, E.: Security Threat Mitigation Trends in Low-cost RFID Systems. In: 2nd SETOP International Workshop on Autonomous and Spontaneous Security SETOP 2009, pp. 193–207 (2009) 10. Juels, A.: RFID Security and Privacy: A Research Survey. IEEE Journal On Selected Aeas In Communications 24(2), 381–394 (2006) 11. Lamport, L.: The temporal logic of actions. ACM Transactions on Programming Languages and Systems 16(3), 872–923 (1994) 12. Li, T., Deng, R.H.: Vulnerability Analysis of EMAP-An Efficient RFID Mutual Authentication Protocol. In: 2nd International Conference on Availability, Reliability and Security, pp. 238–245 (2007) 13. Li, T., Wang, G.: Security Analysis of Two Ultra-Lightweight RFID Authentication Protocols. In: IFIP International Federation for Information Security, pp. 108–120 (2007)

Formal Verification of a Key Establishment Protocol for EPC Gen2 RFID Systems

251

14. Schneier, B.: Applied Cryptography, protocols, algorithms, and source code in C. J. Wiley & Sons, Inc. (1996) 15. Staake, T., Thiesse, F., Fleisch, E.: Extending the EPC Network — The Potential of RFID in Anti-Counterfeiting. In: ACM Symposium on Applied Computing, pp. 1607–1612 (2005) 16. Tounsi, W., Garcia-Alfaro, J., Cuppens-Boulahia, N., Cuppens, F.: Securing the Communications of Home Health Care Systems based on RFID Sensor Networks. In: 8th Annual Communication Networks and Services Research (CNSR) Conference, pp. 284–291 (2010) 17. Turuani, M.: The CL-Atse Protocol Analyser. In: Pfenning, F. (ed.) RTA 2006. LNCS, vol. 4098, pp. 277–286. Springer, Heidelberg (2006)

Author Index

Ahmadi, Hadi

132

Kaklamani, Dimitra I. 208 Kim, Hyoungshick 194 Kirchner, H´el`ene 148 Konopacki, Pierre 227 Koukovini, Maria N. 208 Kranakis, Evangelos 118

Barbeau, Michel 118 Barthe, Gilles 102 Belhaouari, Hakim 227 Bourdier, Tony 148 Castell` a-Roca, Jordi 14 Cervera, Gimer 118 Chen, Yu 73 Chen, Zhong 73 Cirstea, Horatiu 148 Cuppens, Fr´ed´eric 242 Cuppens-Boulahia, Nora 242 Davarpanah Jazi, Mohammad Dragoni, Nicola 32 Dreier, Jannik 164 Duclos, Mathilde 102 Embe Jiague, Michel

Lafourcade, Pascal 23, 164 Lakhnech, Yassine 23, 102, 164 Laleau, R´egine 218, 227, 234 Lioudakis, Georgios V. 208 Lostal, Eduardo 32 Luo, Song 73 1

218

Fabra, Javier 32 Farr` as, Oriol 14 Frappier, Marc 218, 227, 234 Gagn´e, Martin 23 Garcia-Alfaro, Joaquin Gervais, Fr´ed´eric 218 Hu, Jianbin 73 Huh, Jun Ho 194 Jard´ı-Ced´ o, Roger 14 Jaume, Mathieu 148

118, 208, 242

Malek, Behzad 49 Milhau, J´er´emy 234 Miri, Ali 1, 49 Papagiannakopoulou, Eugenia I. Papini, Davide 32 Pudovkina, Marina 90 Pujol-Ahull´ o, Jordi 14 Raji, Fatemeh Rjaˇsko, Michal

1 181

Safavi-Naini, Reihaneh 23, 132 Stanek, Martin 62 St-Denis, Richard 218 Tounsi, Wiem

242

Venieris, Iakovos S.

208

208