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 548 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élécom Paristech. In response to the call for participation, 30 contributions from 15 different countries were submitted to the workshop. These contributions were evaluated on the basis of their significance, novelty, and technical quality. This volume contains a revised version of ten full papers, accompanied by three keynote addresses, two short papers, and five 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édéric 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 financial 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élécom (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édéric 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


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é 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é du Quebec en Outaouais, France Università 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à 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


Martin Gagné 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 Verification of Block Cipher Modes of Operation, an Improved Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martin Gagné, 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 Off-Card Matching in Security-by-Contract for Open Multi-application Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nicola Dragoni, Eduardo Lostal, Davide Papini, and Javier Fabra

32

Private Identification of RFID Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Behzad Malek and Ali Miri

49

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

62

Encryption, Cryptanalysis and Automatic Verification 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 Specification and Validation of Security Policies . . . . . . . . . . . . . . . Tony Bourdier, Horatiu Cirstea, Mathieu Jaume, and Hélène 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 Effective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jun Ho Huh and Hyoungshick Kim

194

Ongoing Research A Contextual Privacy-Aware Access Control Model for Network Monitoring Workflows: 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édéric Gervais, Régine Laleau, and Richard St-Denis Specification and Verification of Access Control Policies in EB3 SEC: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pierre Konopacki, Hakim Belhaouari, Marc Frappier, and Régine Laleau

208

218

227

Table of Contents

A Metamodel of the B Modeling of Access-Control Policies: Work in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jérémy Milhau, Marc Frappier, and Régine Laleau 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 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] first coined the term social networks to describe individuals coming together in the specific 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 different 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 specific 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 differences mentioned, based on [2] the core functionality of OSNs are to allow individuals to: 1. construct public or semi-public personal profiles 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 profile 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’ profile information, comments, groups joined, etc. Furthermore, in off-line social communication, users have different 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 flow, 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 profile 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 effectively change the privacy settings offered 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 difficult 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 different 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 profit. 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


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 defined 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 define 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 identified. 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 different 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.


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 profiles 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 configuration) 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 fit.

6


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 identified 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 different 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 different access to his/her shared data. Using fine 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 specific 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


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 define access policy over more than one group in a flexible manner. In the example above, Alice may want to share a note with all close friends in her class by defining a privacy group like “Close-Friend” AND “Classmate”. Moreover, Alice may also want Mallory see the shared note by defining “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


Furthermore, the user may want to terminate all relations with a specific friend by revoking all the friend’s permissions. For instance, if the relation between Alice and Bob finishes, 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 defined groups, or the user may need to define new groups at different times. For instance, Alice may define 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


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 offer any tools for assigning different permissions to different 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 flexibility over friends because each friend is identified by attributes in the user’s domain. Also, all the desired relations between the user and a friend must be specified 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 verification 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


OSN provider acts as the credential authority in the system which is trusted by the users. Each user is the group manager who classifies contacts according to their dynamic roles and grants them the corresponding memberships. Note that each user’s friend can be organized in a different group. That is, no intersection between the defined 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 flexibility in defining 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 define flexible access control over friends or define new groups gradually. 3.9

IBBE-Based Scheme [28]

IBBE-based scheme [28] provides a privacy protection framework for OSN with flexible 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 flexible and dynamic access control without trusting the OSN providers, the efficiency 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,


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 suffer from some drawbacks, such the inefficiency of key management upon a membership modification of user’s friends. Therefore, the design of an efficient 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 different 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 different 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: Definition, History, and Scholarship. Journal of Computer-Mediated Communication 13(1) (2007)

12


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: Pacific 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 defined 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)


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 efficient 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 efficient 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 flexible 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ó, 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 different situations but especially, as discussed below, we will show how it applies and how can be useful for a typical e-voting system, specifically 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 certificates 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 certificates 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 verification operations. We structure the electoral board constitution with the following steps: 1. Election and certification 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 certificate 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 certificate ci . (b) The key pair (pi , si ) and the set of public certificates C = {c1 , . . . , cn } are stored in the corresponding smartcard sci . (c) A validates each certificate ci ∈ C. (d) The electoral board constitution is publicly defined 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 verifies δ 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) Defines 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) Defines 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) Defines 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


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. Verification 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) Verifies 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) Verifies hj , so that g hj corresponds to the public parameter Hj . ˆ = {H1 , . . . , Hn } are correct. (e) Verifies that the public parameters H (f) Stores in scj the share hj , whether all verifications succeed. Otherwise, smartcard scj from member mj addresses a complain to A. 7. To complete and confirm 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 verification. 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 coeffifactor Z1i = Z1(g ) cient, and Z1 = vi ∈V g ri . This factor is used to compute the final tally in a similar way of [3].

18

3


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 certification. The platform can be certified once and the applications can be certified separately. 3.1

JavaCard-Based ElGamal and Threshold Scheme Rationale

Smartcards supporting JavaCard 2.2 [7] and superior versions [8] provide a welldefined 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 offer 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) efficiency 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 defining 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 fields. 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.


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 different 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 efficient. 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 benefits 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, differently 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] defines an algorithm to be any different type of cryptosystem (like RSA or AES) that its API standardizes.

20


The idea behind that is to allow providing different 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 first 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 difference 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 efficiency 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 different 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 verification (steps 6d and 6e of electoral board constitution), the (iii) vote encryption and finally, 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 affordable 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


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 verification, 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 efficiency of our implemented library on a JCOP 21 v2.2 with 72Kb of memory using different 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 verification have a significant cost. Nonetheless, we think that they are affordable 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


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 efficiency, 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 Efficient 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 specifications (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.: Efficient 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é1, Pascal Lafourcade1, Yassine Lakhnech1 , and Reihaneh Safavi-Naini2 1

2

Université 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é 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 flexible invariants, and a more complete set of rules for establishing the invariants. In addition, all our invariants are given a meaningful semantic definition, whereas some invariants of the previous result relied on more ad hoc definitions. 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 fixed-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 verification tools can help increase our confidence in the security of these modes of operation by providing an independent argument for their security. Gagné et al. [9] first initiated the study of automatic verification 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 verifier 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é 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é 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 definition, 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 offer 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 verification of these modes would greatly increase our confidence in those arguments. An extensive discussion on different 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 efforts. Other works in automated verification 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, definitions, rule set and proofs. We will focus here on the new semantics and our new definition for the invariants, and explain how they improve our verifier.

2

Definitions

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

Automated Verification 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 define 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 defined using our new table T , and make small modifications 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 defined using the alsoremoved sets F and C from the semantics.

26

M. Gagné 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 modification 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 define that a distribution X satisfies ψ, denoted X |= ψ as follows: r

r

– When LE ∈ V , X |= Indis(νx; V ) iff [(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 ) iff [(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 ) iff Pr[(S, E) ← X : S(x) ∈ S(LE ).dom ∪ S(V )] is negligible. – X |= lcounter(x; V ) iff 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∗ ).


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 first 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 defined 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 verifies 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é 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 satisfies ϕ leads to a distribution that satisfies ϕ . 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


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 unaffected 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 finite number of blocks. To simplify the exposition, we only show the invariants that are necessary for the proof of security. An automated verifier 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é et al.

Conclusion

We improved on the result of Gagné 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 verification tool that can successfully verify the security of all the symmetric encryption modes that could be verified 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 different 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égoire, B., Lakhnech, Y., Béguelin, S.Z.: Beyond Provable Security Verifiable 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é, M., Lafourcade, P., Lakhnech, Y., Safavi-Naini, R.: Automated verification of block cipher modes of operation, an improved method. Technical Report TR2011-9, Laboratoire Verimag, Université Joseph Fourier, France, 21 pages (April 2011), http://www-verimag.imag.fr/~ gagne/TechRep2011_09.pdf 9. Gagné, 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)


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: Pfitzmann, 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.: Efficient Instantiations of Tweakable Blockciphers and Refinements 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 Off-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 specification 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 fielded. To date, security models for smart cards (namely, permissions and firewall) 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 certificate 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 different stakeholders) on a card once it is in the field. 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 specification 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 effectiveness 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 specifications allow the execution of the matching algorithm directly on the card, while richer specifications require an external (i.e., off-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 specifically 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 specifications (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 specific 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 difference 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 workflow similar to the one depicted in Fig. 1 [9]. The first 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 satisfies the contract (by means of PCC techniques [23] or using specific 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 Off-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 workflow.


35

Fig. 1. S×C Workflow [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 “off-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 efforts. In this paper we do not consider how contract and policies are specified, that is, in which policy specification language. Without loss of generality, we assume that they are specified 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 Off-Card S×C Contract-Policy Matching

SC before they are sent to the TTP to ensure authentication, integrity and confidentiality. 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 off-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 Certificate Status Protocol (OCSP) [22] cannot be used (or easily extended) for this purpose. This motivates the need for a new specific protocol.

3


A Public Key Infrastructure (PKI) is used to secure the system, where keys and identities are handled through certificates exchanged between the communicating parties. For this reason, SC must engage an initialization phase, where its certificate is created and then stored in the SC along with the initial security policy and the Certification Authority (CA) certificate. 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, certificates 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 confidentiality. 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.


3.1

37

Initialization Phase

This phase is divided into three different steps: Certificate Signing Request (CSR) building [25], certificates issuing, and finally certificates 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 difficult to break the PKI. As shown in Fig. 3, the first Trusted Reader (TR) Smart Card (SC) step consists in building the CSR SC’s public key order for the certificate 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 certificate. 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 - Certificates Manager (TRCM) sends to CA the CSR. CA issues the certificate and sends it back to TRCM. The last step, shown in Fig. 4(b), completes the initialization phase by storing in the SC its certificate, the initial security policy and the CA certificate, which is needed by the SC to verify certificates of TTPs. Once the SC has been initialized, it is ready to securely engage in any activity that involves the contract-policy matching. Specifically, 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) Certificate Issue

Acknowledgment

Store policy

(b) Storage of Certificates and Policy on Card

Fig. 4. (SC)2 : Certificate Issue and Storage of Certificates 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: certificates 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. Off-Card Contract-Policy Matching

In the first part, both parties TTP and SC exchange their own certificates and then respectively check their validity. In particular, SC checks the certificate received against CA certificate which was stored during the initialization phase. If some certificate 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


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, confidentiality 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 verifies 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 finishes, 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 verifies 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 finishes 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

Different programming languages have been used according to whether the entity was an off-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 different 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 different 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.

Certificates. Authentication is ensured by means of X.509 certificates [17]. Certificates used in (SC)2 are generated by means of OpenSSL 0.9.8n. In order to test the system, certificates for CA and TTP have to be created. CA root certificate is generated as a self-signed certificate. 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 verifies it and, by means of the CA root certificate, issues a new certificate corresponding to the CSR received. The certificates are stored on-card as byte arrays and DER-encoded [16]. Parser. An on-card parser has been developed to verify the validity of certificates received by the SC. Specifically, what is checked is the compliance with DER and ASN.1 encoding, the signature, the key algorithm and length and the corresponding issuer. The offsets of a couple of parts of CA’s certificate are stored on SC in order to ease its access during TTP certificate’s verification [14]. In contrast, SC only needs to temporary store the offset of the TBSCertificate part [17] from TTP’s certificate. TTP’s certificates are stored temporary because each certificate is analyzed only once when it is parsed. Certificates 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 verified against the CA’s public key. Cryptography. Both the aforementioned simulation environments suffer 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 finish the encryption/decryption process. Nsc fits perfectly, since it is random and fresh in every new session. Therefore, IV takes the first 128 bits from Nsc .


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 overflow due to dynamic class instantiations and also that memory limits are not reached. The smart card industry has provided developers with some specific 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 overflow 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 certified 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 first 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 verifier, but it does not address properties related to memory usage. Previous work [3] presented a certified 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 overflows. 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 final static variables has been studied in order to find 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 different, more sophisticated code which does not get benefit from the native execution; v) finally, 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 first 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 fits 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 buffer, 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 modified 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


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 certificates as well as Policy have been stored. As an example of initial Policy for the card, a file 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 off-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 different 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 first is the most critical: the simplest flaw in the protocol design can render a secure algorithm with the longest key practically useless. This Section is divided into two parts: the first 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 Off-card Contract-Policy Matching (protocol #2, see Fig. 2). Protocol #1 is performed in a secure environment, this is because in this phase certificates 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 confidentiality and authentication properties. Freshness and integrity are implicitly guaranteed whenever the Nonce is either confidential or can not be predicted and whenever the probability of two different 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 sufficient 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, certificates of parties


45

involved, and all the encrypted messages (see Fig. 2). These messages does not reveal any confidential 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 confidential. [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 significantly smaller, from 10 min to 1 hour. This is unacceptable since RSA is used for certificates, 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 certificates, 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, confidentiality 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 certificate has to be managed, some changes have been added: it is necessary to create two CSRs and store two certificates 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 find not only the session key but also to break RSA for both the certificates). 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 sufficient (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



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 Certificates

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 confidentiality, 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éran, 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.: Certified Memory Usage Analysis. In: Fitzgerald, J.S., Hayes, I.J., Tarlecki, A. (eds.) FM 2005. LNCS, vol. 3582, pp. 91–106. Springer, Heidelberg (2005)


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. Specification 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 Certificates on Smart Cards. World Academy of Science, Engineering and Technology 22, 25–28 (2006) 15. GlobalPlatform Inc. GlobalPlatform Card Specification, Version 2.2. Specification 2.2, GlobalPlatform Inc. (2006) 16. ITU-T. ITU-T Rec. X.690 Information technology – ASN.1 encoding rules: Specification 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 certificate 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 verification on java smart cards. Softw. Pract. Exper. 32, 319– 340 (2002) 21. Sun Microsystems. Runtime environment specification. Java CardTM platform, version 3.0, connected edition. Specification 3.0, Sun Microsystems (2008) 22. Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: X.509 Internet Public Key Infrastructure Online Certificate 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: Certification Request Syntax Specification 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 identification mechanism is proposed for RFID systems in which the privacy of tags is protected against unknown readers. Private identification 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 simplifies the key sharing in the system, and it can readily scale to large RFID systems. Keywords: RFID, Privacy, Identification, Public-key, Error-correcting Code, McEliece.

1

Introduction

Advancement in technology has enabled mass production of cheap, miniaturized Radio Frequency IDentification (RFID) tags that can wirelessly transmit an electronic identifier 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 identification 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 specific store, even if they are protected via encryption, can be uncovered simply by tracing a tag. In other words, security by encryption does not suffice to protect the privacy of RFID tags, and we need to design privacy mechanisms to protect identification 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 identification 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 identification 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 identification scheme for low-cost RFID tags, we consider the following requirements: – Private Identification: 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 identification protocol must be suitable for lowcost RFID tags, especially EPC Gen 2 tags that have little memory. – Proven Security: Security of the private identification protocol must be based on a reliable cryptosystem that can be confidently 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 identification protocol must be probabilistic; that is protocol is randomized and the same tag sends different (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 identification protocol for RFID tags, which is derived from a well-known cryptosystem, i.e. McEliece cryptosystem [14]. McEliece cryptosystem is an efficient 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 Identification of RFID Tags

51

With further improvements on McEliece cryptosystem and a new arrangement of the system, we are able to design a lightweight identification protocol that preserves the privacy of RFID tags. Contributions: Our contributions in this work are as follows: We propose a private identification scheme that can be easily implemented in low-cost RFID tags, such as EPC Gen 2 tags [3]. Our scheme is based on an efficient 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 modifications to the original McEliece cryptosystem, so that it can be fit 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 first 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 modification 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 identification scheme. Later in Section 3, we formally define 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 efficiently as the number of tags and readers increases in the system. This is

52


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 fields. 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 sufficient to understand the proposed private identification 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 field 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 defined 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 satisfies HGT = 0, where GT is the transpose of matrix G. We can check whether a codeword belongs to a code


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 defined as the number of positions the codewords are different. 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: Definition 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 defined as follows: Definition 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 efficient code for which an efficient 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


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 identification protocol, where a tag can present its identity to an authorized reader while unauthorized readers would not be able to find 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-specific services. On the other hand, the identities should not be traceable throughout the system. Our goal is to design a realistic scheme that identifies 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 identification 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 effect 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)


55

The first part, i.e. aid F2 , is fixed 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 fixed 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 identification protocol that is displayed in Algorithm 1. When the tag T is queried, the reader is first identified to the tag. The tag then searches its memory to find the pre-computed values rF1 , aid F2 and r corresponding to the reader R. If T does not recognize R or does not find 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 efficiently, 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 identification 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 first 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 find 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


Algorithm 1. Private identification of RFID tags 1. T : find {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 identification scheme achieves several goals that are listed below: Privacy: The proposed method protects privacy of the tags, since the tag uses a different F , so different 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 specific tag has two challenges: (1) associating two different 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 identification method. Efficiency: 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].


57

The proposed private identification 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 identification protocol is performed with simple XOR operations. Scalability: Using a PKI allows the system to expand efficiently 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 five, 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 fixed 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 identification 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 identification scheme comes from two assumptions: (1) it is difficult to distinguish a particular tag among many tags communicating with a single reader R, and (2) it is infeasible to track a specific 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 find 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 find 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


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 find 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 identification, new random vectors, i.e. r and e, are selected, making it impossible to extract any of the unknowns from a collection of identification sessions. Assumption 2: The adversary might try to distinguish a specific 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 find 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 identification 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 fit 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.


59

Table 1. Performance of the proposed private identification 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 identification 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 finally 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 specifically designed for RFID tags. It is clear that even though our

60


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 identification scheme, the number of parameters are fixed 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 identification 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 difficulty of crypt-analyzing McEliece cryptosystem, which is based on the intractability of SD problem. The proposed scheme provides a private identification 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 efficient schemes that keep RFID tags anonymous even before authorized readers. Moreover, the proposed scheme provides an identification mechanisms only. It is also interesting to extend this work beyond identification 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)


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: Identification 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 Efficiency 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. Hoffstein, 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. Hoffstein, 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. Hoffstein, 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 Identification 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 efficient recovery of the original message without the key, and without revealing the key as well. We define 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 efficiency.

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 specified 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 confidentiality 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-defined 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 efficient 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 define the security property of the scheme that differs from the definition 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 efficiency and authenticity. The paper is organized as follows. Section 2 introduces basic notions. A multiciphertext scheme and its security are defined 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 efficiency 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 finite field 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 fixed 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 finite 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 define 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 define (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 sufficiently secure pseudorandom function, see [1,4], the difference is negligible and related to the birthday bound of finding 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 definition we prefer the tag to be generated internally). For other modifications, the tag can be generated by suitable pseudorandom function and serve for authentication purposes (see Sect. 5.3 or [3]).


65

Security. The security definition 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 first (“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 modification 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 define 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 first 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 efficiency of Recover algorithm depends on how fast we can find 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


67

and Pi can be easily computed in O(T ) time: Pi = γ, (Cj1 ,i , . . . , CjT +1 ,i ), where −1 γ is the first 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 difference between random permutation and random function on {0, 1}n is negligible (a hypothetical distinguisher has to find a collision). Therefore, for our ideal world analysis it suffices 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 first scenario, and the same subset of ciphertexts corresponding to a randomly chosen plaintext in the second scenario. We define 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 first (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 coefficient 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 finished by combining this bound with (1).

Remark 3. We use fixed-length messages (having m blocks) in the proofs of Theorem 1 and Theorem 2. This simplifies 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


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 first probability. Let us define 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

Efficiency 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 efficient computation of particular ciphertext is required, we can choose a different set linear combinations. More importantly, different 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 defines 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 different 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 defines 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 τ .


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 modification has no impact on Recover algorithm. It can be easily verified that Theorem 1 holds for this modification, and mN Theorem 2 holds with insignificant 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 confidentiality 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 first 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 modified 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 verified the decryption returns nothing, except the information that the ciphertext is not authentic. We denote this by the symbol ⊥. Analogous verification 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 efficiency 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.: Efficient 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 Confidence Software Technologies (Peking University), Ministry of Education {chenyu,luosong,hujb,chen}@infosec.pku.edu.cn

Abstract. In EUROCRYPT 2004, Boneh and Boyen presented two efficient Identity Based Encryption (IBE) schemes that are selectiveidentity secure in the standard model. Particularly, the first 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 DiffieHellman 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 first secure and efficient 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 defined 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 five-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 efficient 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. Briefly, the idea of BB1 -IBE is based on the structure that two secret coefficients 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-off 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 different security results. The only different 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 inefficient 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 specific schemes are not involved with the construction identity hash function. That is to say, if we can construct a more efficient 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 modification lies at the identity hash function. We show that this minor modification 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 flexibility of BB1 -style framework, our scheme can be used as an efficient 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 first identify and correct an error in previous literature [13] about the CCA construction of BB1 -IBE. We then present an efficient 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 efficiency, 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 briefly 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 satisfies 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 efficient 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 Diffie-Hellman Problem

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


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 . Definition 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 definitions 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 iff 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


79

DBDH challenge. Otherwise, B flips 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 Diffie-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 , first 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 fixed 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) Diffie-Hellman problem in [12]. They also designed a clever


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 . Define 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 fixed values of X1 and X2 . In the resulting conditional probability space, while X1 , X2 , Y , Z, Tˆ1 and Tˆ2 are fixed, 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 fixed 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 first 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 first 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


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 iff 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 first 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 finds 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 final 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 = Ø.


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 differences, the distinguishing features are different 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 efficient variant of BB1 -IBE in the random oracle model. Our scheme can benefit 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 efficient 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 Efficient 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.: Efficient 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 Diffie-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 Efficient 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)


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, Springfield, Virginia. FIPS 197: Advanced Encryption Standard. Federal Information Processing Standards Publication 197 (2001) 27. Waters, B.: Efficient 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 defined by AdvCCA E,A 2 , where κ is the security parameter. The probability is over the random bits used by the challenger and the adversary. Definition 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 |. Definition 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, ·).


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 defined 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 efficient 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 specified 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 differential, 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 first 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 different plaintexts, the complexity of our proposal is, moreover, almost equal to the complexity of guessing just one round key. Then, we show modifications of our first 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 (five) which, moreover, can be obtained from only one arbitrary plaintext. The complexity of the attack in this specific 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 first 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 find 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 fulfill it. Condition (6) means that if we have an input α and an output β of the round function gk , then we can easily find a round key k using the function ψ. Naturally, there are ciphers which do not satisfy condition (6). For this reason, we first discuss our attack on block ciphers that satisfy condition (6); and then we do the necessary modifications 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 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ár 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 first 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ár [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 first 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 first 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 first 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 first 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 benefit 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 offer 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)


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 first 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 first 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 ζ sufficiently 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 difference 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 first 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


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ár’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 difference 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 “sufficiently” larger than p1 , the public channel approach cannot do better than using one DMBC (the first 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.


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


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 fixed publicly known string and can only participate in a (possibly multi-round) deterministic protocol. The question is whether the parties can benefit 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 Diffie-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 final 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 sufficient. 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


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


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 first 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 specifically 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


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 first 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 different 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 fixed, the main channels provide a fixed level of noise as resource

146


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 significant 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 difference between the two lower bounds. This difference 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, identification 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)


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 confidential messages. IEEE Transaction Information Theory 24, 339–348 (1978) 6. Diffie, 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-off 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élène Kirchner3 1

INRIA Nancy - Grand-Est Research Center & Nancy-Université & LORIA 2 SPI LIP6, Université 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


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:


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.


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:


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


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


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ópez, 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án, 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é, 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ông, V.V.T, Mé, L.: Contrôle d’accès versus contrôle de flots. In: Approches Formelles dans l’Assistance au Développement 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


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 _ 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é 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 definition 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 Verification, Coercion-Resistance, Receipt-Freeness.

1

Introduction

Electronic voting schemes are systems that allow casting and tallying votes using machines. This promises to improve efficiency 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 verifiability (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 different protocols have been developed to fulfill 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 influence 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].


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 definitions. This concerns privacy properties (privacy, receipt-freeness and coercionresistance) [7,8,16], election verifiability [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 first honest voter. The candidate chosen by the targeted voter will then have at least two votes, and can thus be recognized in the official 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 definition for the notion of “Vote-Independence (VI)” in the applied pi calculus. We show that our definition of “Vote-Independence” implies Vote-Privacy as defined in the literature [7] and that the concept can be generalized to improve Receipt-Freeness and Coercion Resistance as well. We define “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 definitions 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 definitions 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 definitions. In Section 3 we elaborate our definitions of Vote-Independence. Then we analyze the hierarchy of our definitions, 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, define our model of voting processes and recall existing privacy definitions. 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 defines 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 defined 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 Φ defines a substitution. An evaluation context C[ ] denotes an extended process with a hole for an extended process.


167

The semantics of the calculus are given by Structural equivalence (≡), which is defined 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 definitions 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


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 definition 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 definition 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 definition of the three basic privacy properties as given by Delaune et al. [7].


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 define 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 Definition 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


Coercion-Resistance. Similarly to Receipt-Freeness, Delaune et al. define 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 (Definition 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 definition 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 definitions 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,


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 different levels of collaboration. The idea is to extend the existing definitions 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 definition is the following: We start from the definition 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 different. This is the most basic definition, 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 definition, 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 definition 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 differently. 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


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 definition, 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 confirms 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 difference 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.


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 first 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


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 verifies 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 difference is the use of a trap-door commitment


175

and a timeliness member to open the commitments. The first 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 verifies that his commitment appears on the list. – The timeliness member publishes a randomly shuffled 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 first 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 differently. 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 find 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


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 verifiability 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 shuffled 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 verifiability. 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].


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 verifier proofs (DVPs) to prove their correct behavior to the voter. Informal Description. We simplified 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 verifies 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 verifies the signature and the proof, double signs the ballot and publishes it on the bulletin board. – The administrator verifies 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 shuffled 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


was left out in their model, but is essential to highlight the difference 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 definition and showed that it is stronger than standard vote-privacy. We generalized the definition to passive and active collaboration, and obtained refined 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 definition 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.


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 Marneffe, 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 verification 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 Verifiability 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


16. Moran, T., Naor, M.: Receipt-Free Universally-Verifiable 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 fixing helios: An analysis of ballot secrecy. In: Accepted at CSF 2011 (2011) 20. Smyth, B., Cortier, V.: Attacking and fixing 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 Verifiability 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 define 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 find 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 fixed-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.


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 sufficient 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 flaws in the scheme and thus one can heuristically hope that the scheme remains flawless 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 indifferentiability framework [9] and consequently Coron et. al defined a property for hash functions called pseudo-random oracle [6]. If a hash function F is pseudo-random oracle then it is indifferentiable 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 define 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 definitions 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 find 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 define as an information which is hard to compute for a random oracle. Clearly, the BB property is not sufficient 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 defined 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 defined 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 definitions. In Section 3 we define 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 finite set S. Concatenation of finite 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 suffix 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 first argument to H as a subscript, i.e. HK (M ) := H(K, M ). A fixed 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 specifies 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 first 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:


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 define 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 efficient 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 define 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 define collision resistance). Because of this, in the following definitions 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 definition 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 defined 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 finds 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 Definition 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 define the following experiment:


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 defined 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 defined 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 satisfiability 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 fig. 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


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 defined 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 (fig. 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 indifferentiability framework introduced


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 fixed-input length random oracle g to the variable-input length pseudo-random oracle. This is also the reason why we do not define 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 defined 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 modified property is defined 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 modified 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 defined 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)


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 efficient 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.: Indifferentiability, 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: Definitions, 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 Effective 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 classification. Most of the time, legitimate websites get back large number of results and are ranked first, whereas phishing websites get back no result and/or are not ranked at all. To demonstrate the effectiveness of our approach, we experimented with four well-known classification 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 misclassified in existing blacklisting and whitelisting approaches. Keywords: Phishing detection, URL Reputation, Classification.

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 first 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 different 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 effective in detecting known-bad phishing websites, it can be weak against detecting new ones. It is also difficult to efficiently 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 Effective

195

Fig. 1. Example of a phishing website

Whitelisting, on the other hand, is effective against new phishing websites since only those considered ‘trusted’ are accessed by users. However, it is somewhat difficult 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 insufficient, it can incur a significant 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 effective 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 classification. 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 effective 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 classification algorithms, Linear Discriminant Analysis, Na¨ıve Bayesian, K-Nearest Neighbour, and Support Vector Machine, on three different 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 classification 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 first 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 first; 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 differences 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 first, 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 first 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


(a) Facebook

197

(b) A phishing website

Fig. 2. Differences 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 first, 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 first 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 classifier 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 different classification methods that may be used to train a classifier, 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 Classification 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 classification method should be carefully selected based on constraints such as the desired level of accuracy, time available for development and training, and nature of classification problems. We carried out a number of experiments to evaluate four different classification methods and to find the best performing (most suitable) one. This section introduces these classification 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 classification [8]. Given a set of search results, LDA finds 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 sufficient 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) classification 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 simplified 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) classification is a non-parametric classification 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 finds 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 classifier 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


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 classification problems with high dimensional feature space and small training set size. The idea is to find 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 effectiveness of our approach, and determine the best performing classification 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 classified using the four classification 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 classification. Having realised that the query string format, whether it includes the string ‘http://’ in front or not, could affect the returned results, we used two string formats: the first is ‘URL only’, e.g. “www.facebook.com”; and the second is ‘URL with protocol’, e.g. “http://www.facebook.com”. Classifiers generated by querying ‘URL with protocol’ to a search engine S are denoted as ‘S(h)’, while classifiers 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 differences 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 first 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 Effective 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 classifiers 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 first. 4.2

Classification Results

For classification, we used the first half of the collected search results for training and the rest for testing. The classifiers, as discussed in Section 3, were generated with the first 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 classified as legitimate websites; F P – legitimate websites incorrectly classified as phishing websites; T N – phishing websites correctly classified as phishing websites; F N – phishing websites incorrectly classified as legitimate websites.

The graphs in Figure 4 show the performance of the four classifiers using the following three measurements: N – Accuracy – the rate of the websites correctly classified ( 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 classifiers to show the relative efficiency of the classification algorithms; the results are shown in Table 2. These classifiers 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 classifiers 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) classification algorithm produced the best results – when ‘URL with protocol’ was queried on Yahoo (Yahoo(h)), KNN achieved 98% in all accuracy, specificity and sensitivity. Such a high performance implies that each data point, legitimate or phishing, can find 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 classification 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 classifiers, 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 classification 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 classification algorithm. The linear property of Yahoo allows all of the classification algorithms to perform reasonably well. If one wishes to use All, the response time of querying all three search engines should be carefully evaluated first. 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 classification as shown above)


203

more to access a webpage. Hence, for any given classification 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 effective 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 difficult 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 classification 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 effective 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 effective 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 different 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 effective 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 first; 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 misclassified as a phishing website, would continuously be misclassified 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 first most of the time. The phishing


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 classification 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 classification 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 significantly 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 filters. 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 effective 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 classification 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 different combinations of URL formats (e.g. leaving some parameters in the URL) affect 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 classification. IEEE Transactions on Pattern Analysis and Machine Intelligence 24, 1281–1285 (2002) 6. Domingos, P., Pazzani, M.: On the Optimality of the Simple Bayesian Classifier 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 Classification. 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 classifier. In: Proceedings of IJCAI2001 Workshop on Empirical Methods in Artificial 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)


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évigné, 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 traffic 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 workflows, with privacy features already contained since their specification 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, workflows.

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, first 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 fields [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, reflecting the cooperation between different stakeholders, in order to effectively 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 reflect operational aspects, mostly related to security, such as the behaviour of a firewall or the routing table of a router redirecting malicious traffic to a honeypot. In this paper, we sketch the definition 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 verification of workflows 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 first 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 traffic 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 workflow management [6][28] and Model-Driven Security [3][23], though important, suffer from enforcing security policies only at run-time and not during the workflow 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 specifically devised for network monitoring, although limited to singleprobe environments. Their enhancement towards fulfilling 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-flow), that are executed in order for a high-level purpose to be fulfilled. As shown in Fig. 1, a workflow’s lifecycle can be seen as consisting of two phases, notably Planning and Execution. The former refers to the specification of the workflow by its designer, including all steps for its graphical definition, 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 workflow 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 workflow 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; specifically, in order for a workflow 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 workflow. – 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 modifications, such as task additions, removals or substitutions. – Decomposition: Each composite skin task is decomposed in more elementary subtasks, until it is finally analysed in a combination of atomic tasks that will eventually be included in the final executable form of the workflow. Fig. 2 illustrates a network monitoring workflow example; Fig. 2(a) depicts the initial workflow, as specified by its designer, and Fig. 2(b) the workflow after some transformations following the verification and transformation procedure. In practice and especially within workflows, rules remain inactive until a set of conditions are fulfilled. We denote as contextual the authorisation policies containing dynamic authorisation provisions. In this regard, authorisation rules 1

We call skin tasks the ones defined by the workflow designer, as opposed to the tasks that their inclusion in the workflow is a result of workflow check and modification; all tasks in Fig. 2(a) are considered to be skin tasks. Their separate examination without considering their decomposition targets the early identification of conflicts.


211

Fig. 1. Overall Architecture

(a) Initial Workflow (as specified by its designer)

(b) (Partially) Processed Workflow Fig. 2. Workflow 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 verification and transformation procedure, providing for the specification of context-based differentiated workflow behaviours, already during workflow formation.

4

Policy Model

The Policy Model regulates the system’s operation and drives the workflow verification 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 defined, being the core elements of access control rules and workflows and the “seed” for knowledge extraction. The following outline the basic concepts.

212

4.1


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 offering Operation Instances (OpI )2 , in order to act upon Objects (Obj ), with the latter referring to everything that is affected 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 fulfilling some Purposes (Pu). Moreover, data, organisations, machines and operation containers are characterised by types, reflecting the semantic class they fall under; thus, sets of Data Types (DT ), Organisation Types (OrgT ), Machine Types (MT ) and Operation Container Types (OpCT ) are defined, respectively. Additional elements of the model include Context (Con), that enables the definition 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. Specifically, the OpC and OpCT are introduced in order to model components or other functional structures that typically offer 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 defining AND- and ORhierarchies and enabling the inheritance of attributes and rules, as well as the specification of dependencies. For instance and with respect to the DT graph, three partial order relations are defined: isA(dti , dtj ), lessDetailedThan(dti , dtj ) and contains(dti , dt k ), where dti , dtj ∈ DT, and dt k ⊆ P(DT ), reflecting, respectively the particularisation of a concept, the detail level and the inclusion of some data types to another. Moreover, the model specifies the necessary predicates in order to link concepts from different 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.


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 definition of an action can be complemented by a fourth parameter, notably the organisation within which it is defined; 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 defined at abstract, concrete or mixed level, several variations of Actions are identified, 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 definition of which is interrelated. A task ti is an action acti when being part of a workflow w, written as a tuple ti = ai , opi , resi w , or ti = ai , opi , resi , orgw . On the other hand, a workflow consists in a finite number of tasks, i.e., w = t1 , t2 , ..., tn , along with the control- and data-flow relationships among them. 4.3

Access Control Rules

Access control rules are used for defining 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 defined. 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 specification of expressive Dynamic Separation of Duty constraints, whereby conflicts between tasks can be defined 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 different 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


Knowledge Extraction

Let’s assume the rather typical case where a user holding a role rinit ∈ R initiates a workflow 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 workflow verification and transformation and will consequently be inferred after reasoning over the model includes: —Whether rinit justifies triggering the execution of w, in order for pu to be served. For instance, a NetworkAdministrator should be able to execute a workflow 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 identified and reported by an alarm, the prompt notification 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 workflow, such as different execution paths for different actors. —The possible decompositions of a task ti , for given rinit and puw . For instance, Fig. 2(b) illustrates a simplified 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 specific decomposition has been selected based on the parameters applying (e.g., rinit may permit only this decomposition). —Whether a task within the workflow requires another task (or a series of tasks), along with its exact or relative position in the workflow; 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. —Identification of possible incompatibilities and conflicts that may exist among some tasks within the workflow 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.


215

—Identification of the possible workflow differentiations, 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 workflow designer has defined the conditional branch, there can be cases where such differentiations are inferred by the Policy Model. —What are the possible workflow 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 offered 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 workflow during Ingrid’s duty hours, the model should enable the identification of a VoIPSoftwareClient-enabled PersonalComputer machine that Ingrid is authorised to use, in order to include the concrete task in the workflow.

5

Conclusions and Current Work

Motivated by the necessity of enhancing network monitoring architectures in terms of privacy-awareness, we are working towards the specification of a new policy model for controlling access to associated resources, such as data, operations and infrastructures. Our model aims at allowing the definition of network monitoring workflows, with privacy features already contained since their specification 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 definition 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 definition 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-financed 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


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 workflow 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. Official 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). Official 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. Official Journal of the European Communities L 105, 54–63 (April 2006) 14. Fan, J., Xu, J., Ammar, M.H., Moon, S.B.: Prefix-preserving IP address anonymization. Computer Networks 46(2), 253–272 (2004)


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 traffic. 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 netflows 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 workflow-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édéric Gervais2 , Régine Laleau2 , and Richard St-Denis1 1

GRIL, Département d’informatique Université de Sherbrooke Sherbrooke (Québec), J1K 2R1, Canada {Michel.Embe.Jiague,Marc.Frappier,Richard.St-Denis}@USherbrooke.ca 2 LACL, Université 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 filters to evaluate policy rules and on a decision engine to combine their results. The proposed architecture supports hierarchically defined 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).


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 differences 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 flexible 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 difference 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-specific 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 specific features, but also in terms of efficiency 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 specifies 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 defined 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 notification 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 different 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, five 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 first two in emergency cases. Between two adjacent levels of the hierarchy, there is a master-slave relationship from which a decision-making process is defined. 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 final access decision to the PEP (see Fig. 1).


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 filters to infer an access decision. When it receives an authorization request message from its master PDP, it calls its filters sequentially by forwarding the same message, but with an additional parameter (pr), resulting from the previous filter (this parameter is ignored by the first filter), since a given filter may require the result of the previous filter in order to determine its own result. Similarly to the case described in Fig. 2, a filter 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 filters 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 different perspectives at the same time: the pr: result of the previous filter 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


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 specific 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 specifies 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


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 defining 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 defined 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 define 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 different users or roles, and obligation, which forces a user to eventually trigger an operation after the execution of a specific 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


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 filters 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 specific 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 filter 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 filter 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.


225

AuthorizationMessage 0..* AbstractFilter 0..* filters 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 different PEM models. Prototypes were produced from most of them to evaluate specific 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 first 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 filter 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 filter. 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 specified by using ASTDs [4], which were transformed into BPEL processes. The latter implement filters 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é 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


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ège, 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égine Laleau2 1

2

GRIL, Département d’informatique, Université de Sherbrooke, Canada Université Paris-Est, LACL, IUT Sénart 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 () == & & & ; 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 () == & ; 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.


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.


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ège, 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érémy Milhau1,2 , Marc Frappier1 , and Régine Laleau2 1

2

GRIL, Département Informatique, Université de Sherbrooke, 2500 boulevard université, Sherbrooke J1K 2R1, Québec, Canada {Jeremy.Milhau,Marc.Frappier}@USherbrooke.ca Université Paris-Est, LACL, IUT Sénart Fontainebleau, Département Informatique, Route Hurtault, 77300 Fontainebleau, France [email protected]

Abstract. Verification and validation of access-control policies for information systems is a difficult 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 filter combined to the system. It allows verification 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 specification 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 modifications. 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 first 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 verified 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).


A Metamodel of the B Modeling of Access-Control Policies

235

are defined as rules that can only be evaluated at execution time according to the context of execution. Static rules are defined 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 define allowed or forbidden workflows 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 first order logic. It involves a development approach based on refinements of models called machines. The initial machine is the most abstract model of the system. Each subsequent refinement step introduces more concrete elements into the model until a final refinement 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 verification and validation tools associated with the B method such as ProB [7], an animator and model checker for B specifications. 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 offers an automata-like representation of workflows which can be combined using sequence, guard, choice, Kleene closure, interleave, synchronization and quantifications 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 specifications [9] and SecureUML diagrams into B machines (named Dynamic Filter and Static Filter respectively in the following sections). The final step of our work is to build an AC filter implemented using the BPEL notation [3]. We want to use the refinement approach of B to obtain the implemented filter. 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 refinement 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 refinement to several platform-specific models (PSMs). In order to do so, we have to specify concepts such as rules or policies that are not explicitly specified 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 defining AC policies. This helps the refinement 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 specification 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 first 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 modified 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 filter 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 filters may not be needed at all time. One of the dynamic filters can be activated, for example, in emergency situations only. 4. The AC filter 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 filters and the dynamic filters, 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


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 specifies all the modifications 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 filter 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 filter 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 filter machine. This operation may be required in specific 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 modified 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 filter machine defines a static AC policy that will be enforced on the system. In our example, we have chosen an RBAC-like policy. Each rule


% 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 defines either a permission to perform an action or a prohibition. Such a definition 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 define the Static Policy of the Static Filter machine. The Static Filter includes the machine UserAssignements that defines a role hierarchy and the the roles that a user can play. 2.3

The Dynamic Filter

The dynamic filter machine defines a dynamic AC policy that will be enforced on the system. Such policies can be defined 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 unaffected 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 workflow 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 workflow (Dynamic State) is stored into several variables called State Variable. The Dynamic Policy is composed of several Dynamic Actions

240


% 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 workflow 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 defined 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 verification 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 difficult (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 specification. The ORKA project evaluates methods according to criteria such as formalism of the notation, availability of verification 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 refinement 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.


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 filter. 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écifications B et de descriptions UML pour l’aide a ` la validation externe de développements 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ézéquel, 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éry, 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 specification of an access control filter. 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:


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.


(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 Înstate' :=new() ^L1':= Keygen(L',Instate') ^Snd(L1') 2. State=1 ^Rcv(xor((Knew'.Tmp),L2')) =|> ^State':=2 Înstate' :=new() ^L3':= Keygen(Knew,Instate') ^Snd(L3')

3. State=2 ^Rcv(xor((Opreq.Tmp),L4')) =|> State' :=3 Înstate' :=new() ^L5':= Keygen(L4',Instate') ^Snd(L5') 4. State=3 ^Rcv(xor((Opwr'.Tmp),L6')) =|> State' :=4 Înstate' :=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)


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)


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élène 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édéric 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égine 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é, Martin 23 Garcia-Alfaro, Joaquin Gervais, Frédéric 218 Hu, Jianbin 73 Huh, Jun Ho 194 Jard´ı-Ced´ o, Roger 14 Jaume, Mathieu 148

118, 208, 242

Malek, Behzad 49 Milhau, Jérémy 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

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

Elektor May 2011

Pollution Engineering May 2011

Flexible Packaging May 2011

PC World May 2011

Dairy Foods May 2011

Quantum Interaction: 5th International Symposium, Qi 2011, Aberdeen, Uk, June 26-29, 2011, Revised Selected Papers

Home Power Magazine, April 2011 May 2011

Yachting Monthly - May 2011

Saveur - May 2011

Scientific American May 2011

Economist - 21 May 2011

HAPPI May 2011

GUT MAY 2011

Appliance Design May 2011

Computerworld - 23 May 2011

Food Engineering May 2011

Discover Magazine May 2011

Process Heating May 2011

Nutraceuticals World May 2011

Ceramic Industry May 2011

Webuser - 05 May 2011

Industrial Heating May 2011

Quality May 2011

Society Life - May 2011

Candy Industry May 2011

Coatings World May 2011

Prepared Foods May 2011

Security Technology - SecTech 2011

Tile Magazine May-June 2011

Environmental Design + Construction May 2011

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

Elektor May 2011

Pollution Engineering May 2011

Flexible Packaging May 2011

PC World May 2011

Dairy Foods May 2011

Quantum Interaction: 5th International Symposium, Qi 2011, Aberdeen, Uk, June 26-29, 2011, Revised Selected Papers

Home Power Magazine, April 2011 May 2011

Yachting Monthly - May 2011

Saveur - May 2011

Scientific American May 2011

Economist - 21 May 2011

HAPPI May 2011

GUT MAY 2011

Appliance Design May 2011

Computerworld - 23 May 2011

Food Engineering May 2011

Discover Magazine May 2011

Process Heating May 2011

Nutraceuticals World May 2011

Ceramic Industry May 2011

Webuser - 05 May 2011

Industrial Heating May 2011

Quality May 2011

Society Life - May 2011

Candy Industry May 2011

Coatings World May 2011

Prepared Foods May 2011

Security Technology - SecTech 2011

Tile Magazine May-June 2011

Environmental Design + Construction May 2011

Recommend Documents