Security and Privacy in the Age of Ubiquitous Computing: IFIP TC11 20th International Information Security Conference, May 30 - June 1, 2005, Chiba, Japan ... Federation for Information Processing)
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!
SECURITY AND PRIVACY IN THE AGE OF UBIQUITOUS COMPUTING
IFIP - The International Federation for Information Processing IFIP was founded in 1960 under the auspices of UNESCO, following the First World Computer Congress held in Paris the previous year. An umbrella organization for societies working in information processing, IFIP's aim is two-fold: to support information processing within its member countries and to encourage technology transfer to developing nations. As its mission statement clearly states, IFIP1s mission is to be the leading, truly international, apolitical organization which encourages and assists in the development, exploitation and application of information technology for the benefit of all people.
IFIP is a non-profitmaking organization, run almost solely by 2500 volunteers. It operates through a number of technical committees, which organize events and publications. IFIP's events range from an international congress to local seminars, but the most important are: The IFIP World Computer Congress, held every second year; Open conferences; Working conferences. The flagship event is the IFIP World Computer Congress, at which both invited and contributed papers are presented. Contributed papers are rigorously refereed and the rejection rate is high. As with the Congress, participation in the open conferences is open to all and papers may be invited or submitted. Again, submitted papers are stringently refereed. The working conferences are structured differently. They are usually run by a working group and attendance is small and by invitation only. Their purpose is to create an atmosphere conducive to innovation and development. Refereeing is less rigorous and papers are subjected to extensive group discussion. Publications arising from IFIP events vary. The papers presented at the IFIP World Computer Congress and at open conferences are published as conference proceedings, while the results of the working conferences are often published as collections of selected and edited papers. Any national society whose primary activity is in information may apply to become a full member of IFIP, although full membership is restricted to one society per country. Full members are entitled to vote at the annual General Assembly, National societies preferring a less comm~tted involvement may apply for associate or corresponding membership. Associate members enjoy the same benefits as full members, but without voting rights. Corresponding members are not represented in IFIP bodies. Affiliated membership is open to non-national societies, and individual and honorary membership schemes are also offered.
SECURITY AND PRIVACY IN THE AGE OF UBIQUITOUS COMPUTING IFIP TC11 2othInternational Information Security Conference May 3 0 - June 1, 2005, Chiba, Japan
Edited by
Ryoichi Sasaki Tokyo Denki University lapan
Sihan Qing Chinese Academy of Sciences China
Eiji Okamoto University of Tsukuba lapan
Hiroshi Yoshiura University of Electro-Communications lapan
4 - Springer
Library of Congress Cataloging-in-Publication Data A C.I.P. Catalogue record for this book is available from the Library of Congress. Security and Privacy in the Age of Ubiquitous Con~p~tiizg, Edited by Ryoichi Sasaki, Sihan Qing, Eiji Okamoto and Hiroshi Yosh~ura
p.cm. (The International Federation for Information Processing)
Copyright O 2005 by International Federation for Information Processing. All rights reserved. This work may not be translated or copied in whole or In part without the written permission of the publisher [Springer Science+Business Media, Inc., 233 Spring Street, New York, NY 10013, USA), except for brief excetpts in connection with reviews or scholarly analysis. Use in connection with any form of inforniation storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now know or hereafter developed is forbidden. The use in t h ~ spublication of trade names, trademarks, service marks and similar terms, even if the are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Prmted in the United States of America. 9 8 7 6 5 4 3 2 1 springeronline.con1
SPIN I1418313 (HC) 1 114191 12 (eBook)
Contents
Preface IFIP/SEC2005 Conference Committees
xi xiii
PART I REGULAR PAPERS
1
Accountable Anonymous E-Mail VINCENT NAESSENS, BARTDE DECKER,LIESJEDEMUYNCK
3
Protecting Consumer Data in Composite Web Services CRAIGPEARCE,PETERBERTOK,RONVANSCHYNDEL A Decision Matrix Approach ALBINZUCCATO Assignment of Security Clearances in an Organization LECHJ. JANCZEWSKI, VICTORPORTOUGAL Tool Supported Management of Information Security Culture THOMASSCHLIENGER AND STEPHANIE TEUFEL ERPSEC - A Reference Framework to Enhance Security in ERP Systems PROF.S.H. VON SOLMS.M.P. HERTENBERGER
Security and Privacy in the Age of Ubiquitous Computing
A New Architecture for User Authentication and Key Exchange Using Password for Federated Enterprises YANJIANG YANG,FENGBAOAND ROBERTH. DENG A Secure Quantum Communication Protocol Using Insecure Public Channels I-MINGTsAI, CHIA-MU.YU, WEI-TINGTU, AND SY-YENKUO Trusted Component Sharing by Runtime Test and Immunization for Survivable Distributed Systems JOONS. PARK,PRATHEEPCHANDRAMOHAN, GANESH AND JOSEPHGIORDANO DEVARAJAN, Design and Implementation of TPM SUP320 WANG,XUEMIZHAOAND JIANGCHUN REN,KUI DAI,ZHIYING YUANMAN TONG Mathematical Models of IP Traceback Methods and Their Verification KEISUKEOHMORI,AYAKOSUZUKI, MANABU OHMURO TOSHIFUMI KAI,MARIKOKAWABATA , RYUMATUSHIMA AND SHIGERU NISHIYAMA Transferable E-CASH Revisit JOSEPHK. LIU,SANDYH. WONG', DUNCAN S. WONG A License Transfer System for Supporting Content Portability in Digital Rights Management AND NICHOLAS PAUL QIONGLIU, REIHANEHSAFAVI-NAINI SHEPPARD Secure Human Communications Based on Biornetrics Signals YONGDONG WU, FENGBAOAND ROBERTH. DENG Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks LAURENT BUSSARD AND WALIDBAGGA An Adaptive Polling Scheme for IEEE 802.11 Wireless LAN KYUNG-JUN KIM,HYUN-SOOK KIM,SANG-DON LEE,
Security and Privacy in the Age of Ubiquitous Computing
The Pairing Problem with User Interaction THOMAS PEYRINAND SERGE VAUDENAY Network Smart Card ASADALI, KARENLU, AND MICHAELMONTGOMERY Protection Against Spam Using Pre-Challenges RODRIGO ROMAN, LOPEZ JIANYING ZHOU,AND JAVIER Automatically Hardening Web Applications Using Precise Tainting ANHNGUYEN-TUONG, SALVATORE GUARNIERI, DOUGGREENE, JEFFSHIRLEY,DAVIDEVANS Traffic Redirection Attack Protection System (TRAPS) VRIZLYNN L. L. THING, HENRYC. J. LEEAND MORRISSLOMAN Statistical Signatures for Early Detection of Flooding Denial-of-service Attacks JOHNHAGGERTY, QI SHIAND MADJIDMERABTI Design, Implementation, and Evaluation of FRiTrace WAYNEHUANG,J.L. CONG,CHIEN-LONG WU,FANZHAO, S. FELIXWU Design and Implementation of a High-Performance Network Intrusion Prevention System KONSTANTINOS XINIDIS, KOSTASG. ANAGNOSTAKIS, EVANGELOS P. MARKATOS STRIDE: Polymorphic Sled Detection through Instruction Sequence Analysis AND K. P. AKRITIDIS, E. P. MARKATOS, M. POLYCHRONAKIS, ANAGNOSTAKIS PIRANHA: Fast and Memory-Efficient Pattern Matching for Intrusion Detection S. ANTONATOS, M. POLYCHRONAKIS, P. AKRITIDIS, K.G. AND E.P. MARKATOS ANAGNOSTAKIS Designated-Verifier Proxy Signature Schemes GUILINWANG
vii
Security and Privacy in the Age of Ubiquitous Computing
Tripartite Concurrent Signatures WILLY SUSILO AND YI MU Signcryption in Hierarchical Identity Based Cryptosystem SHERMAN S.M. CHOW,TSZHONYUEN,LUCASC.K. HUI, AND S.M. YIU
443
Protecting Group Dynamic Information in Large Scale Multicast Groups YONGDONG WU, TIEYANLI, AND ROBERTH. DENG Secure Group Communication with Distributed Generation 477 of Private Keys for Ad-hoc Networks SHRIKANT SUNDARAM, PETERBERTOKAND BENJAMIN BURTON Ensuring Media Integrity on Third-party Infrastructures JANADITTMANN, STEFANKATZENBEISSER, CHRISTIAN SCHALLHART, HELMUTVEITH
493
A New Fragile Mesh Watermarking Algorithm for Authentication HAO-TIANWU AND YIU-MINGCHEUNG
509
New Paradigm in Graph-based Visual Secret Sharing Scheme by Accepting Reversal in Black-White Images YUJISUGA
525
PART I1
537
WORKSHOP PAPERS
Overcoming Channel Bandwidth Constraints in Secure SIM Applications 539 JOHNA. MACDONALD, WILLIAMSIRETTAND CHRISJ. MITCHELL On the Performance of Certificate Revocation Protocols Based on a Java Card Certificate Client Implementation K. PAPAPANAGIOTOU, K. MARKANTONAKIS, Q. ZHANG, W.G. SIRETTAND K. MAYES On-the-Fly Formal Testing of a Smart Card Applet LARSFRANTZEN, ARJENVAN WEELDEN,MARTIJNOOSTDIJK, PIETERKOOPMAN, JANTRETMANS
55 1
565
Security and Privacy in the Age of Ubiquitous Computing
A Computationally Feasible SPA Attack on AES via Optimized Search JOELVANLAVEN, MARKBREHOB,AND KEVINJ. COMPTON
577
The Proof by 2m-1: A Low-cost Method to Check Arithmetic Computations SYLVAINGUILLEYAND PHILIPPEHOOGVORST
589
Streamto: Streaming Content Using a Tamper-Resistant Token JIEYINCHENG,CHEUNNGENCHONG,JEROENM. DOUMEN, SANDROETALLE. PIETERH. HARTELAND STEFANNIKOLAUS
60 1
Preface
This book contains the proceedings of the 2oth IFIP International Information Security Conference (IFIPISEC2005) held from 3othMay to IS' June, 2005 in Chiba, Japan. It was the 2oth SEC conference in the history of IFIP TC-11. The first one was held in Stockholm, Sweden in May 1983. After that, IFIPISEC conferences have been in various countries all over the world. The last IFIPISEC conference held in Asia was IFIPlSEC2000 in Beijing, China. In IFIPISEC2005, we emphasize on "Security and Privacy in the Age of Ubiquitous Computing". Even in the age of ubiquitous computing, the importance of the Internet will not change and we still need to solve conventional security issues. Moreover, we need to deal with the new issues such as security in P2P environment, privacy issues in the use of smart cards and W I D systems. Therefore, in IFIPISEC2005, we have included a workshop "Small Systems Security and Smart Cards" and a panel session "Security in Ubiquitous Computing". This book includes the papers selected for presentation at IFIPISEC2005 as well as the associated workshop. In response to the call for papers, 124 papers were submitted to the main conference track. These papers were evaluated by members of the Program Committee in terms of their relevance, originality, significance, technical quality and presentation. From the submitted papers, 34 were selected for presentation at the conference (an acceptance rate of 27%). We also include 6 short papers selected by the Workshop committee. We would like to thank Mr. Leon Strous, chair of IFIP TC-I 1, Professor Norihisa Doi, Professor Hideki Imai, Professor Tsuneo Kurokawa and Professor Shigeo Tsujii,
xii
Security and Privacy in the Age of Ubiquitous Computing
members of the SEC2005 Advisory Committee for their continuous advice. We are grateful to the members of the Program Committee for their voluntary efforts to review manuscripts. We are also grateful to the members of the Local Organizing Committee for their efforts in preparing this conference, especially Professor Yuko Murayama, chair of this committee.
Ryoichi Sasaki, Tokyo Denki University (General Chair) Sihan Qing, Chinese Academy of Science Eiji Okamoto, University of Tsukuba (Program Chairs)
IFIPlSEC2005 Conference Committees
Conference General Chair Ryoichi Sasaki, Tokyo Denki University, Japan Advisory Committee Norihisa Doi, Chuo University, Japan Hideki Imai, University of Tokyo, Japan Tsuneo Kurokawa, Kokugakuin University, Japan Shigeo Tsujii, Chuo University, Japan Programme Committee co-Chairs Sihan Qing, Chinese Academy of Sciences, China Eiji Okamoto, University of Tsukuba, Japan Programme Committee H. Armstrong, Curtin University of Technology, Australia W. Caelli, Queensland University of Technology, Australia E. Chaparro, Fundacion Via Libre, Argentina B. de Decker, K. U. Leuven, Belgium Y. Deswarte, LAAS-CNRS, France M. Dupuy, SGDNIDCSSIICERTA, France M. El-Hadidi, Cairo University, Egypt J. Eloff, University of Pretoria, South Africa S. Fischer-Huebner, Karlstad University, Sweden
xiv
Security and Privacy in the Age of Ubiquitous Computing
D. Gollmann, Technische Universitat Hamburg-Harburg, Germany D. Gritzalis, Athens University of Economics and Business, Greece H. Inaba, Kyoto Institute of Technology, Japan K. Iwamura, Canon Inc., Japan S. Jajodia, George Mason University, USA S. Katsikas, University of the Aegean, Greece H. Kikuchi, Tokai University, Japan K.-Y. Lam, PrivyLink, Singapore C. Landwehr, CISEICNS, USA W. List, Partner, Independent, UK J. Lopez, University of Malaga, Spain K. Matsuura, University of Tokyo, Japan Y. Murayama, Iwate Prefectural University, Japan T. Nakanishi, Okayama University, Japan M. Nishigaki, Shizuoka University, Japan G. Papp, Vodafone Hungary, Hungary M. Park, Mitsubishi Electronic Corporation, Japan H. Pohl, ISIS - Institute for Information Security, Germany R. Posch, Graz Univ. of Technology, Austria K. Rannenberg, Goethe University Frankfurt, Germany K. Sakurai, Kyushu University, Japan P. Samarati, University of Milan, Italy I. Schaumuller-Bichl, Johann Wilhelm Kleinstrase 1 1, Austria L. Strous, De Nederlandsche Bank, NL K. Tanaka, Shinshu University, Japan S. Teufel, Universite de Fribourg, Switzerland D. Tygar, University of California, Berkeley, USA V. Varadharajan, Macquire Univ., Australia I. Verschuren, TNO ITSEF, NL J. Vyskoc, VaF, Slovakia M. Warren, Deakin University, Australia T. Welzer, University of Maribor, Slovenia H. Yoshiura, University of Electro-Communications, Japan S. Furnell, University of Plymouth, UK J. Knudsen, Copenhagen Hospital Corporation, Denmark I. Ray, Colorado State University, USA T. Virtanen, Helsinki University of Technology, Finland R. Solms, Port Elizabeth Technikon, South Africa Local Organizing Committee Chair Yuko Murayama, Iwate Prefectural University, Japan
Security and Privacy in the Age of Ubiquitous Computing
Local Organizing Committee Steering Chairs Yuko Murayama, Iwate Prefectural University, Japan Yoshito Tobe, Tokyo Denki University, Japan Program Chairs Eiji Okamoto, Tsukuba University, Japan Hiroshi Yoshiura, University of Electro-Communication, Japan Mi Rang Park, Mitsubishi Electronic Corporation, Japan Finance Chair Masatoshi Terada, Hitachi Limited, Japan Publicity Chairs Masakatsu Nishigaki, Shizuoka University, Japan Ryuya Uda, Tokyo University of Technology, Japan Local Arrangement Chairs Hiroaki Kikuchi, Tokai University, Japan Moriaki Itazu, Tokyo Denlu University, Japan Publication Chair Kanta Matsuura, University of Tokyo, Japan Liaison Chairs Seiichiro Hayashi, Japan Internet Payment Promotion Association, Japan Kouji Nakao, KDDI Corporation, Japan Satoru Torii, Fujitsu Limited, Japan
xvi
Security and Privacy in the Age of Ubiquitous Computing
Workshop on Small Systems Security and Smart Cards Working Conference Programme Committee Jean-Jacques Quisquater, UCL, Belgium Jan Verschuren, TNO ITSEF-BV, The Netherlands, Joan Daemen, STMicroelectronics, Belgium Jan Eloff, University of Pretoria, South Africa Pieter Hartel, Twente University, The Netherlands Jaap-Henk Hoepman, University of Nijmegen, The Netherlands Les Labuschagne, RAU Standard Bank Academy for Information Technology, South Africa Piet Maclaine Pont, Mullpon vof, The Netherlands Michael Montgomery, Axalto Schlumberger, USA Pierre Paradinas, CNAM, Paris, France Erik Poll, University of Nijmegen, The Netherlands Ingrid Verbauwhede, KU Leuven, Belgium Erik de Vink, Eindhoven University of Technology, The Netherlands Bert den Boer , Independent Cryptographer, The Netherlands Jeroen Doumen ,Twente University,The Netherlands
PART I REGULAR PAPERS
ACCOUNTABLE ANONYMOUS E-MAIL
Vincent Naessens*, Bart De Decker, Liesje Demuynck' K.U.Leuven, Department of Computer Science, Celestijnenlaan 200A, 3001 Leuven, Belgium, *K.U.Leuven, Campus Kortrijk (KULAK), E. Sabbelaan 53, 8500, Kortrijk, Belgium
Abstract:
Current anonymous e-mail systems offer unconditional anonymity to their users which can provoke abusive behaviour. Dissatisfied users will drop out and liability issues may even force the system to suspend or cease its services. Therefore, controlling abuse is as important as protecting the anonymity of legitimate users when designing anonymous applications. This paper describes the design and implementation AAEM, an accountable anonymous e-mail system. An existing anonymous e-mail system is enhanced with a control mechanism that allows for accountability. The system creates a trusted environment for senders, recipients and system operators. It provides a reasonable trade-off between anonymity, accountability, usability and flexibility.
Key words:
privacy, anonymity, accountability, control
INTRODUCTION Anonymous e-mail systems serve many purposes ranging from making public political statements under oppressive governments to discussing topics that might otherwise lead to embarrassment, harassment or even loss of jobs in more tolerant political environments [I]. However, unconditional anonymous e-mail systems (such as remailers) can also be used for sending offensive mail, sparn, black mail, copyrighted material, child pornography ...
' Research assistant of the Research Foundation
- Flanders
(FWO - Vlaanderen)
4
Vincent Naessens *, Bart De Decker, Liesje Demtlynck
Legal actions against this service may even force it to shut down. Therefor, controlling abuse is as important as protecting the anonymity of legitimate users. Both considerations play a central role in the design of the accountable anonymous e-mail system (AAEM). Anonymity should always be guaranteed to legitimate users but extra controls are necessary to prevent or at least discourage abuse. The paper is organized as follows: section 2 describes a general anonymous credential system; these credentials will be used in the e-mail system that is designed in section 3. Section 4 describes and evaluates a prototype of the system. An overview of related work is given in section 5. We conclude in section 6 with a summary of the major achievements.
2.
ANONYMOUS CREDENTIALS
This section describes Idemix [I 1,121, a general anonymous credential system. Idemix helps to realize anonymous yet accountable transactions between users and service providers. The credential system is used to introduce anonymity control in the AAEM system. A simplified version of the Idemix protocols is presented here. Not all inputs of the protocols are described. The outputs of interactive protocols are not always visible to all parties involved in the protocol. Nym registration. A nym is the pseudonym by which the user wants to be known by an organization. Idemix has two kinds of nyms: ordinary nyms and rootnyms. The user establishes a nym with an organization based on his master secret2. Nym registration (for registering ordinary nyms). NymUo=RegNym(). Note that the rootNym (see below) is hidden in every nym of the user. RootNym registration (for registering rootnyms). RootNymUR = RegRootNym(SigUR,Certuc). The user signs the established nym with his signature key, which is certified by an external certificate (which links the user's public key with his identity). Hence, the organization holds a provable link between the rootnym and the identity certified by the certificate. Credential issuing. Credu1 = IssueCred(NymuI, CredInfouJ. After establishing a nym with an organization, the user may request a credential on
Note that all the user's nyms and credentials are linked to the user's master secret. Hence, sharing one credential means sharing all other credentials as well.
Accountable Anonymous E-Mail
5
that nym. Credentials can contain additional information: show options (e.g. one/limitedlmulti-show) and attributes (e.g. age, citizenship, expiration date, ...).
Credential showing. (TranscriptuEMsgUv) = CredShow(NymuK Credur, CredShowFeaturesUv.S. The user proves to the verifying organization V that he owns a credential issued by organization I. A credential show can have several features:
- The credential is shown relative to another nym. The (anonymous) user proves that the nym on which the credential is issued and a nym by which he is known by the verifier, belong to the same user (they are based on the same user secret). - Local andlor global deanonymization is allowed (cfr. below). In addition, a user may choose to prove any attribute (or a property of these attributes). Showing a credential results in a transcript for V which can be used later in double spending checking and deanonymization protocols. During a credential show, a message can be signed, which provably links the message to the transcript of the credential show. The following anonymity properties are valid:
- Two or more credential shows of the same credential can not be linked together (unless the credential is a one-show credential).
- A credential show does not reveal the nym on which it was issued. Deanonymization. Transcripts of anonymous credential shows can be deanonymized by including a verifiable encryption of the user's nym (local deanonymization) or rootNym (global deanonymization). Thus, only parties that have the deanonymization keys can deanonymize credential shows Local deanonymization. (Nyrn~~, DeAnonTran~cript~.~~) = DoLocalDeanon(Transcriptw). If a credential show is locally deanonymizable, the nym for which the credential was issued can be revealed by a deanonymizer D. A deanonymization transcript contains a provable linking between the transcript and the nym. Global deanonymization. (RootNym~~,DeAnonTranscriptDDUV) =DoGlobalDeanon(TranscriptUV~. If the credential show was globally deanonymizable, the user's rootnym can be revealed.
Vincent Naessens *, Bart De Decker, Liesje Demuynck
6
Credential Revocation. RevokeCred(NymLr[,CredUJ.The issuer can also revoke credentials issued on a nyrn.
ACCOUNTABLE ANONYMOUS E-MAIL First, the requirements of the players in the system are described. The requirements analysis results in the design of an anonymous mail system enhanced with a control mechanism that allows for accountability. The roles in the system are described in the second paragraph. Third, we describe the protocols used in the different phases. Finally, we evaluate the trust properties in the system.
3.1
Requirements
User requirements. These requirements depend on the role the users play in the the mail system. Senders want their privacy to be protected whereas recipients mainly have control requirements. Whereas current remailer systems mainly focus on the former, our design considers the concerns of both parties. The control requirements of recipients are twofold: Spam control measures. Recipients don't want spam in their mailbox. The mail system should take measures to discourage this kind of abuse. Accountability for criminal mail. It should be possible to prosecute the sender of a criminal mail. The mail system should guarantee that the identity of the sender can be revealed (i.e. the user is accountable). The anonymity requirements of mail senders will only be met as long as the sender abides by the rules (no spam or criminal mail). Unlinkability of a mail to the initiator. Unlinkability of different mails from the same initiator.
System requirements. The system requirements are twofold: Offering good service to users. The mail system wants to offer a good service in order to attract users. Therefor, the mail system contracts its users to meet the requirements of their users. Limited use of resources. To be able to meet the accountability requirements, evidence will be stored in the system. The amount of evidence stored by the AAEM-system itself should be minimal.
Accountable Anonymous E-Mail
7
Law Enforcement requirements. The government may require accountability of misbehaving users. Such users have sent illegal mails (such as illegal music files, child porn, ...) or criminal mails (such as death threats, bribery, blackmail ...).
3.2
Roles
Registrar (for registration). The registrar knows a provable link between a user's true identity and his rootNym. To increase trust in the system, the registrar is independent of the AAEM-system. Its cooperation is required to identify the sender of an anonymous e-mail. AAEM system infrastructure (core of the mail system).
- Activation Manager (for activation). The Activation Manager handles the (anonymous) user registrations, and if the AAEMsystem is not for free, also deals with payments. Payment can be anonymous; however, it is not a pre-requisite to fulfil the requirements. - Mail guard (for mailing). The Mail Guard imposes strict access control to the AAEM-system (only registered users are authorized to use the services of the system) and adds verifiable proofs to the message guaranteeing that the sender of the message can be identified under certain conditions. - Complaint handler. The Complaint Handler handles suspected (unacceptable/criminal) mail that is sent through the mail system. Complaints are sent by recipients of such mail. The Mail Guard can also pass suspected mail to the Complaint Handler. Deanonymization grantinglhandling infrastructure.
- Law Enforcement entity (or Justice). The role of the Law Enforcement Entity (LE) is to verify whether the identity of a user behind a nym may be revealed. - Arbiter. The arbiter's role is to verify whether an e-mail fulfills the local or global de-anonymization condition. - Deanonymizer. This authority can retrieve the pseudonym of the sender of an anonymous e-mail message. Communication infrastructure.
Vincent Naessens*, Bart De Decker, Liesje Demuynck
- Anonymous connection system (AC). The connection between the sender and some of the other participants need to be anonymous. - Re mailers (REM). The remailers constitute the existing anonymous e-mail system. The AAEM system forwards mail towards the recipient through a remailer system. Users of the AAEM system.
- (Anonymous) Sender.
The sender is entitled to send e-mail anonymously (when he is registered to the system). As long as he abides by the rules, his anonymity will be respected. - Recipient. The owner of a mailbox and e-mail address. The recipient may refuse to accept anonymous e-mails unless they are "stamped" by a trusted Mail Guard. If the email is spam or contains illegitimate or criminal content, the recipient may file a complaint with the AAEM-system. --
----
AAEM-system arbiter
uard
deanon.
I
Figure 1. Overview of the AAEM system.
3.3
Protocols
This section describes the protocols used in different phases.
Registration. In this phase, the user contacts the registrar to obtain a root credential. The user first establishes a rootNyrn and signs that rootNym with an external certificate (issued by a trusted CA). The registrar stores the identity proof and issues a root credential on the rootNym. The root credential can be shown multiple times to the Activation Manager.
U: Certucfrom C (an external Certzfication Authorityl
Accountable Anonymous E-Mail
uf3R: R00tNymUR= RootNym (SigUR,Certuc) R: stoves [SigUR,CertK, RootNym LIR] U 6+ R: CredUR= IssueCved(RootNym UR,['A CT]) Activation of Anon-Email Service. Each user has to activate the anonymous mail service with the Activation Manager before he can send mail. The Activation Manager issues a send credential, required to send mail. Before the user receives a send credential, he must prove that he has previously registered (possesses a valid root credential) and solve an activation puzzle. To achieve these goals, the user first establishes an anonymous communication channel and registers a nym with the Activation Manager. The user then shows his root credential relative to that nym. This prevents unregistered users to activate the mail service. The credential show is undeanonymizable. The Activation Manager verifies the credential show. The user then solves the activation puzzle. The puzzle discourages users to activate the service several times3.
U t,M NymuM = RegNymO U h\M. ( T r a n ~ c r i p t ~MsgUl,& ~ , ~ ~ - ~=, CredShow(NymUMCredUR,CredShowFeature~~~Q) with CredShowFeaturesuM-R=[LDeDanon=null,GDeAnon=null] and MsgUw = contract between U and AAEM, may contain explanation of acceptable use policy. U ~j M: activation procedure (solving puzzle) U t,M: CredUM= IssueCred(NymUM['SENDY) M: stores [TranscriptUMR,Nymm Credud Sending anonymous mail. Sending mail is conditionally anonymous. A user is anonymous as long as he abides by the rules. If the system is used to send spam mail, the user's send credential will be revoked; if criminal mail is sent through the system, the sender can be identified and prosecuted. The sender is responsible for removing identifying headers before contacting the mail guard, who will verify the sender's send credential. During the credential show, the mail is signed, which provably links the mail to the transcript of the credential show. The transcript is locally and globally
The activation puzzle can be omitted if the user has to go through a prior payment phase, in which he receives a one-show payment credential. In that case, the user must pay in order to activate the mail service.
10
Vincent Naessens *, Bart De Decker, Liesje Demuynck
deanonymizable. The Mail Guard verifies the credential show and attaches the transcript to the mail. The Mail Guard then forwards the mail to the recipient mailbox over a remailer network.
U # G: (TranscriptEM MsgU)= CredShow(nul1, CredUM,CredShowFeaturesuG.,$ with CredShowFeaturesUG.,~ = [LDeAnon=[DCond= UnacceptablelCriminal, Arbiter=A],
GDeAnon=[DCond=Criminal,Arbiter=A]] and Msgu = message to be sent anonymously to the recipient G:forwards [Msg, SigG(TranscriptuG.,n)]to recipient r through REM Receiving anonymous mail. The recipient checks the validity of the TranscriptuG with respect to the message MsgU.If the verification fails, the message is discarded. If the verification is successful, the user reads the message. If the message is abusive (unacceptable or criminal), the recipient forwards the mail to the complaint handler.
...).
Unacceptable behavior (Spam, If a user has sent spam, the send credential of that user should be revoked. Revoking the send credential consists of three steps: Decision of Arbiter. The recipient sends the suspected mail (mail contents and transcript) to AAEM system. The Complaint Handler signs the mail and forwards the request to the Arbiter. The Arbiter first verifies the validity of the mail w.r.t. the transcript. It then verifies whether the mail is really unacceptable. The Arbiter returns his signed decision. If the mail is unacceptable, the Complaint Handler informs the Deanonymizer. Disclosing Nym. The Deanonymizer receives a signed message from the Complaint Handler. The message contains the Arbiter's decision (i.e. "Unacceptable"), the mail and the transcript. The Deanonymizer verifies the advice, and if positive, locally deanonymizes the transcript. He then returns the nym and a deanonyrnization transcript to the Complaint Handler. The Deanonymizer also stores the Arbiter's signed decision. Credential revocation. When the Complaint Handler receives the nym from the Deanonymizer, the mail system actually revokes the credential issued on the nym. The victim is also kept informed.
Accountable Anonymous E-Mail r
J
C: [ComplaintSpam, iMailu] with Mailu = [M~gc,T r a n ~ c r i p t ~ ~ - ~ J and Transcript,, contains LDeAnon=(Unacceptablej Criminal, A]
C J A: Sigc(Mailu Unacceptable?) C tA: SigA(Mailc, Unacceptable) C
-+D: SigA(Mailu Unacceptable)
D: (NymUMD e A n o n T r ~ n s c r i p t ~ . ~DoDeAnonLocal(TranscriptuG.~ ~)= D: stores SigA(Mailu Unacceptable)
C: RevokeCred(NymUMCredu,d C stores: [SigA(MailU,Unacceptable), NymCilW DeAnonTran~cript~.~~]
r t C: Sigc(Sender=BANNED, SigA(MailU,Unacceptable)) Criminal behavior. Criminal behavior can be detected by the recipient (e.g. blackmail, stalking, ...) or by a mail system component (e.g. illegal content...). In both cases, the identity of the mail sender should be revealed. In addition, the user's send credential can be revoked. Revocation of a send credential is described above. Revealing the identity of the sender requires the following steps: Decision of Arbitertsee above). Disclosing RootNym. If the mail is criminal, the Arbiter convinces the deanonymizer to reveal the rootNym behind the transcript. The deanonymizer globally deanonymizes the transcript and returns the rootNym and the deanonymization transcript to the Complaint Handler. Revealing identity. The Complaint Handler forwards the evidence to LE. LE then orders the Root Authority to reveal the identity of the user behind the rootNym. LE stores the evidence that proves the link between the sender and the criminal mail.
r
+ C: [ComplaintCriminal, Mailu] with Mailu = [MsgU,TranscriptuG+J and Transcript,-, contains GDeAnon=[Criminal, A]
C +A: Sigc(MailU, Criminal?)
Vincent Naessens *, Bart De Decker, Liesje Demuynck
-+LE: [SigA(MailU,Criminal), RootfimuR, DeA nonTrans~ript~."~]
LE stores [RootNymUR,Siguh CertUc,MsgUR]
3.4
Properties
This section focuses on the trust properties in the system. The mail system creates a trusted environment for senders, recipients and administrators of an AAEM system. Sender. First, the sender may trust that different mails cannot be linked by the AAEM system. Although send credentials are issued by the AAEM system, credential shows are unlinkable. Therefore, different mails from the same user can not be linked by AAEM. Note that an anonymous communication infrastructure is required. Second, the sender may trust that his send credential will not be revoked as long as he does not send abusive mail. Three parties are involved in revoking send credentials: AAEM, A and D. D will only locally deanonymize the transcript after permission of A. AAEM can only revoke the send credential related to the transcript after local deanonymization. Moreover, AAEM needs A's permission to revoke the credential. Nevertheless, trust is required in a righteous Arbiter. AAEM and user can possibly negotiate which Arbiter to involve before a credential show. Third, revealing the user's identity is only possible with cooperation of external entities: A, LE, D and R. D only globally deanonymizes a transcript after A's approval. R only reveals the link between the rootNyrn and the identity of the user after approval of LE. Recipient. A valid transcript guarantees that a mail is locally and globally deanonymizable. Recipients also know the verifier of valid
Accountable Anonymous E-Mail
13
transcripts (i.e. AAEM) and the deanonymization conditions. Moreover, the recipient can block mail containing no or invalid transcripts.
AAEM, D and R. AAEM can not be liable as long as it observes the rules (i.e. respects the decision of the Arbiter). AAEM stores evidence about unacceptablelcriminal mail and the judgement of A about the mail. D also stores such evidence. In case of criminal mail, R stores LE's judgement.
4.
PROTOTYPE
4.1
Description
Client side infrastructure. The application layer consist of three components. The registrationlactivation module receives registration1 activation requests from the user and passes them to the credential layer. The mail client is configured to forward mail to a local SMTP server (running at the sender's machine). The mail server filters any identifying headers and passes the message to the credential layer.
I
SMTP server
Activation Interface
II
I RulesDB
ldemix Architecture
I
+
+
+
Onion routing Client Proxy
+
CredsDB
I
Figure 2. Client side infrastructure
The credential layer implements Idemix credential protocols (credential showing, credential issuing, ...). The credential layer requires two databases in order to execute a credential protocol. First, the CredsDB stores credentials (root credential, activation credentials, mail credentials). This database is updated as (new) user credentials are retrievedlrevoked. Second, the RulesDB specifies the rules for credential showinglcredential issuing during each phase (registration, activation, sending mail). The RulesDB is configured at set up time. Idemix requests are passed to the communication layer.
Vincent Naessens *, Bart De Decker, Liesje Demuynck
14
The communication layer deals with anonymous connections to the AAEM system. An onion routing proxy[2,3] is inserted at communication level. In the current implementation, the client composes an anonymous path to the AAEM system. In an alternative implementation, the communication layer can contact an external communication proxy that sets up anonymous connections. However, the latter implementation has different anonymity properties. Access configurations to anonymous connection systems are discussed in [2,3]. The client side also consists of a module that verifies transcripts and sends complaints to the AAEM system.
Core of AAEM system. The activation manager and the mail guard are implemented as two different Idemix organizations. The Mail Guard verifies mail, stores the transcripts as attachment and passes them to a Mixmaster remailer proxy (running at the same machine). The remailer proxy chooses a chain of remailers, recursively encrypts the message and forwards the message through the remailer system. The Complaint Handler receives complaints from recipients. The Complaint Handler forwards them to an arbiter andlor a law enforcement entity. This depends on the type of complaint.
4.2
Evaluation
Anonymity. Anonymity at application level is achieved by using anonymous credentials as building block. However, anonymity at application level is useless without support at the communication level. A global passive adversary is the most commonly assumed threat when analyzing anonymity at this level. No current practical low-latency, bidirectional system (i.e. anonymous connection system) does protect against such a strong adversary. The prototype implements anonymous connections between the sender and the AAEM system. The credential protocols require a real-time, bidirectional communication channel. However, sender and recipient are the real endpoints of communication. The AAEM system forwards mails to recipients over a remailer system that resists global attacks. Thus, global attackers cannot link the endpoints of communication. UsabilityIDeployability. To be deployed and used in the real world, the system is not expensive to run: The design does not place a heavy liability burden on AAEM operators (as discussed in section 3.4).
Accountable Anonymous E-Mail
-
-
15
Decentralized storage of mail transcripts reduces the number of disk space required by AAEM. The number of stored activation transcripts is linear to the number of activations. The amount of evidence stored by AAEM is linear to the number of accepted complaints. However, the system discourages multiple activations and abusive behaviour. The system extends an existing infrastructure. AAEM uses a preexisting network of anonymous remailers and anonymous connections. Once a user has installed the client software, he only has to change the location of the outgoing SMTP server in his mail client.
Flexibilityltransparency. The components are loosely coupled by a layered design. Transparency is achieved between the mail component and the communication component. The communication component can easily be replaced by another implementation. Second, the system foresees a loose coupling between different entities: the Arbiter and the Law Enforcement entity do not require any knowledge about Idemix and the structure of the mail system to judge complaints. Even the deanonymizer doesn't require knowledge about the structure of the mail system. To simplify the complaint handling procedure, the deanonymizer itself can be the Arbiter. This requires additional trust in the deanonymizer.
5.
RELATED WORK
Our work on AAEM was largely motivated by the problems of current anonymous mail systems and tries to be a reliable extension of current remailer systems. The Mail Guard functions as front end to a remailer system. Our implementation uses Mixmaster[S, 101 remailers. However, only the communication proxy at the Mail Guard has to be re-implemented to work well with other types of remailers. If replies should be supported, the SMTP server at the client side also has to be re-implemented. This server must know the available remailers in order to build a reply structure. The current implementation does not support replies: the SMTP server just removes the "return-path" header. The first anonymous mail system open to the public was anon.penet.fi [9]. Unfortunately, penet did not use encryption. Moreover, only one machine needs to be compromised in order to break the anonymity. Type-1 remailers, also called Cypherpunk remailers, were developed to address many shortcomings of the penet system. Type-1 remailers have public keys with which incoming messages are encrypted. A message can be sent through a
16
Vincent Naessens *, Bart De Decker, Liesje Demzlynck
chain of type-1 remailers, having been successively encrypted for each of them. Each remailer in a chain knows only the identity of the previous remailer and the next remailer in the chain. The system also supports reply functionality. Type-2 remailers[5,10] offer several improvements in security over type1 remailers. These improvements make hop-by-hop analysis considerably harder. They include fixed size messages, replay detection and better reordering of messages at remailers. Type-2 remailers do not support replies to unknown destinations. Type-3 remailers[8], also called Mixminion remailers, support secure single-use reply blocks. Mix nodes cannot distinguish Mixminion forward messages from reply messages. Directory servers allow users to learn public keys and performance statistics of participating remailers. Mixminion provides a mechanism for each node to specify an exit policy (open exit nodes versus middleman exit nodes) and describes a protocol which allows recipients to opt-out of receiving mail from remailers. However, this requires recipients to send an opt-out request to each open exit node. This is very difficult to realize in practice as new remailers become available. Moreover, if receiving mail is opt-out, non-abusive mail is also retained. Our approach is to discard only anonymous messages without a valid transcript. Senders of abusive mail can be held accountable. Nymsew[l] is an e-mail pseudonym server: the server keeps a public key and a reply block for every nym. Nymserv also functions as front end and back end to a remailer system. Mail sent from the server to a user leaves through a chain of Cypherpunk remailers; requests to create nyms and to send mail from them arrives through a chain of Cypherpunk remailers. Nyms of abusive users can be revoked. Nymserve also uses a high-latency anonymous communication system. However, different mails from the same user can be linked. Moreover, only a limited amount of control is possible: users can not be accountable for sending abusive mail.
6.
CONCLUSION
The presented mail system considers both anonymity requirements of senders and accountability requirements of recipients. A reasonable tradeoff between these interests is achieved. An acceptable level of anonymity at communication level is achieved by reusing existing solutions: anonymous connections and remailers. An anonymous credential system is used as building block for accountability of application specific data/actions. Moreover, the credential system is loosely coupled to the application.
Accountable Anonymous E-Mail
17
Trust is achieved by splitting responsibilities over different entities and accurate complaint handling procedures. However, a trusted external party is still required in applications where conditional anonymity is a design issue.
REFERENCES [I] David Mazieres and M. Frans Kaashoek. The design, Implementation and Operation of an Email Pseudonym Server. In Proceedings of the 5th ACM conference on Computer and communications security, p.27-36, November 02-05, 1998, San Francisco, California, United States. [2] P. Syverson, M.Reed and D. Goldschlag. Onion routing access configurations. In DARPA Information Survivability and Exposition (DISCEX 200), volume 1, p.34-40. IEEE CS Press, 2000. [3] P. Syverson, G. Tsudik, M. Reed and C. Landwehr. Towards an Analysis of Onion Routing Security. In H. Federrath, editor, Designing Privacy Enhancing Technologies: Workshop on Design Issue in Anonymity and Unobservability, p.96-114. Springer-Verlag, LNCS 2009, July 2000. [4] M. Reed, P. Syverson and D. Goldschlag. Anonymous connections and onion routing. IEEE Journal on Selected Areas in Communications, 16(4): 482-494, May 1998. [5] U. Moller, L. Cottrel, P. Palfiader and L. Sassaman. Mixmaster Protocol - Version 2. Draft, July 2003, http://ww. abditum. com/mixmaster-spec. txt. [6] B. Levine, M. Reiter, C. Wang and M. Wright. Timing analysis in lowlatency mix-based systems. In A. Juels, editor, Financial Cryptography. Springer-Verlag, LNCS, 2004. [7] C. Gulcu and G. Tsudik. Mixing E-mail with Babel. In Network and Distributed Security Symposium(NDSS 96), P.2-16. IEEE, February 1996. [8] G.Danezis, R.Dingledine and N. Mathewson. Mixminion: Design of a type-3 anonymous remailer protocol. In 2003 IEEE Symposium on Security and Privacy, p.2-15. IEEE CS, May 2003. [9] J. Helsingius. anon.penet.fi press release. http://www.penet.Ji/pressenglish.htm.l
18
Vincent Naessens*, Bart De Decker, Liesje Demuynck
[lo] Cottrel. Mixmaster and remailer attacks. http://www.obscura.com/-loki/remailer/remailer-essay.html. [I 11 Jan Camenisch, Els Van Herreweghen: Design and Implementation of the Idemix Anonymous Credential System. Research Report RZ 3419, IBM Research Division, June 2002. Also appeared in ACM Computer and Communication Security 2002 [12] Els van Herreweghen, Unidentifiability and Accountability in Electronic Transactions. PhD Thesis, KULeuven, 2004.
PROTECTING CONSUMER DATA IN COMPOSITE WEB SERVICES
Craig Pearce, Peter Bertok, Ron Van Schyndel R M T University. Melbourne, Australia {crpearce,pbertok,ronvs)@cs.rmit. edzr.au
Abstract: The increasing number of linkable vendor-operated databases present unique threats to customer privacy and security intrusions, as personal information communicated in online transactions can be misused by the vendor. Existing privacy enhancing technologies fail in the event of a vendor operating against their stated privacy policy, leading to loss of customer privacy and security. Anonymity may not be applicable when transactions require identification of participants. We propose a serviceoriented technically enforceable system that preserves privacy and security for customers transacting with untrusted online vendors. The system extends to support protection of customer privacy when multiple vendors interact in composite web services. A semi-tuustedpvocessor is introduced for safe execution of sensitive customer information in a protected environment and provides accountability in the case of disputed transactions.
Key words: Electronic commerce; privacy; security; web services.
Craig Pearce, Petev Bertok, Ron Van Schyndel
1.
INTRODUCTION
Many vendors have shown poor security of customer databases, leading to intrusions, loss of customer privacy and even identity theft [internetnews.com, 20031. When back-end customer databases are copied, sold or linked with databases of other vendors, the wealth of available customer information rapidly increases. In some cases, customers trust a vendor with personal information, however the information is collected for processing by other (untrusted) parties along the chain, as seen in outsourcing and supply chain management [Medjahed et al., 20031. Currently, private information that customers choose to release to vendors, such as medical information or credit card details, cannot be fully controlled by the customer once released. In addressing this issue, we have designed a generalised application-layer privacy platform, named: TEPS, the Technically Enforceable Privacy and Security system. TEPS protects from customer privacy violations at the vendor-side by preventing an untrusted vendor from ever holding customer personally identifiable information (PII) in plain view. The customer decides which of their personal attributes to protect and we introduce a semi-trusted processor (STP) that is trusted not to disclose customer PI1 within local execution of vendor-provided business logic. Full trust of the STP is not required as accountability and code watermarking [Collberg and Thomborson, 20021 can detect other forms of STP abuse. Mobile code is utilised as a method of communicating messages of varying protection levels amongst the entities of the service-oriented electronic commerce architecture. TEPS is a generalised model, and is suitable within the Web Services architecture, where multiple vendors can interact to fulfill customer requests, typically seen with a front-end web service broker that outsources back-end activities to other web services. Our results from a fully scaled implementation withm wired and wireless networks, and the possibility of mobile clients, show that TEPS is suitable within service-oriented transactions, enforcing consumer privacy as a valueadded service.
2.
BACKGROUND AND RELATED WORK
Traditionally, once a vendor has access to plain-text (non-encrypted) customer information, there are no technical methods available to restrict its use of that information.
Protecting Consumev Data in Composite Web Services
21
Anonymising layers, such as [Chaum, 1981, Jakobsson and Juels, 2001, Dingledine et al., 20041, help protect the customer source identity, and sometimes vendor destination, but once personally identifiable information has been captured by the vendor it can no longer be controlled. Identity Management systems, such as [Waldman et al., 2000, Campbell et al., 2002, Jendricke et al., 20041, act as an intermediary between customer and vendor and provide a pseudonym of the customer instead of the customer's real identity. This establishes privacy as long as pseudonyms cannot be linked to the customer's real identity. However, pseudonyms cannot be used when a vendor is required to authenticate a customer in environments that provide services both in electronic and traditional environments, such as banking, voting and payment. Credential-carrying pseudonyms [EU FP6 PRIME Project, 20051 could be considered an alternative to strong authentication, but require globally present identity management mechanisms. Non-traceable anonymous payment systems, such as [Chaum, 1982, Chaum et al., 19901 for transactions requiring authentication remain to be problems, such as medical subscriptions and large order requests. The Secure Electronic Transactions (SET) protocol used hashing techniques to preserve privacy of payment and order information, although overheads of client-side certificates, implementation difficulties and lack of extensibility for multiple vendors within integrated transactions made it unsuitable for complex environments, such as Web Services [Medjahed et al., 20031. The Secure Sockets Layer (SSLITLS) [Dierks and Rescorla, 20041 provides communication channel authentication, message confidentiality and integrity but protects only the communication channel between customer and vendor. Customer privacy from untrusted vendors is not protected once data has reached the vendor. Protection of a customer's personally identifiable information (PII) has been proposed [Kenny and Korba, 20021 but does not offer assurance of enforceability in global e-commerce. Furthermore, the proposed PIIprotecting model [Kenny and Korba, 20021 requires full trust in the data controller, which is also responsible for accountability. Personnel are required to manually check data processing activity and the security of data controllers is simplified to a question of reputation. Extensible support for multiple vendors interacting within a transaction has not been addressed. Encrypting digital identifiers and enforcing associated privacy policies through trusted computing technologies [Casassa et al, 20031 has been suggested, however all participants are required to operate within the confines of a globally unified trusted computing platform. Recent developments in XML-based privacy between customer and vendor has seen the emergence of Platform for Privacy Preferences (P3P)
22
Craig Pearce, Peter Bertok, Ron Van Schyndel
[W3C, 2002, Berthold and Kohntopp, 20011 for the Internet and Enterprise Privacy Authorization Language (EPAL) [Ashley et al., 20031 for organisations. P3P and EPAL provide a standardised way for the vendor to represent their privacy policy and allow the customer to specify their privacy needs but cannot provide technical assurance that the vendor will not digress from their stated privacy policy. EPAL provides logging and reporting capabilities and enforces privacy access within an organization [Goldberg, 20021 using network privacy monitors, however, is not appropriate for complex transactions as customers are required to unconditionally trust resources governed by vendor organisations. Furthermore, P3P and EPAL were designed for web-based applications, using the traditional client-server model, and are not suitable for Web Services [Medjahed et al., 20031. Issues of vendors digressing from their stated privacy policy, lack of identification and non-repudiation in anonymous payment systems, overheads of client identity certificates and legal factors due to globalisation have encumbered electronic commerce with privacy concerns. In many jurisdictions, revelation of customer databases to third parties is legally punishable if detected, but is still prevalent due to limitations in tracking down the perpetrator. Globalisation increases this problem as privacy laws in some jurisdictions are weak or non-existent. The "Technically Enforceable Privacy and Security" (TEPS) system helps solve these core issues by operating as a generalised service at the application-level protocol layer, and is suitable in a service-oriented architecture to prevent vendors from ever gaining access to customer privacy information.
3.
SCENARIOS: HOW ONLINE TRANSACTIONS AFFECT CUSTOMER PRIVACY
In this section we describe two realistic scenarios currently threatening customer privacy that TEPS aims to alleviate.
3.1 Scenario 1: Online brokers A customer uses on online bookseller web service as the vendor to locate a textbook. After finding a suitable match, the customer decides to purchase the package from the vendor. Current practices require customers to log into the vendor's website with a previously established account that probes for customer identity information. SSLITLS is used for encrypting credit card information, which is generally handled by a payment gateway, not the
23
Protecting Consumer Data in Composite Web Services
vendor. The vendor redirects customers to a payment gateway, and once payment is complete, the payment gateway returns an outcome to the vendor. Despite what may be stated within the vendor's privacy policy, SSLITLS does not prevent the vendor from disclosing consumer spending habits to other parties.
3.2 Scenario 2: Composite web services REQUEST (
REQUEST (
name, address, med~calh~story, complaint,
name,addrcss, lnedlcal history, complarnt,
RESPONSE (
RESPONSE (
transactlon outcome)
REQUEST (
name,address, medmne,
billing details)
' specialist +----
(service)
transaction outcome)
2
RESPONSE ( transaction
outcome)
Figure I. Composite web services
A customer seeks medication by lodging a request to an online health clinic and must log in for identification. As with Scenario 1, the previously established account may require a number of personally identifiable customer attributes deemed private in nature. The health clinic is a front-end only, outsourcing medical knowledge to a specialist back-end service, as shown in Figure 1. Furthermore, if medicine is required, the specialist outsources prescription services to a pharmacy. The customer may not be aware of multiple vendors operating to fulfil their transaction. Each of these back-end services will request customer details from the front-end service to perform their business activity, possibly without customer knowledge. Privacy policies of back-end services may be independent to the health clinic privacy policy agreed to by the customer.
4.
SYSTEM DESIGN
TEPS is composed of the following entities: Customer (CUS): Operates a client (CL) machine through a web browser; Client (CL): Computer used by customer in transacting with a vendor; Vendor (V): Service-oriented online store (for example, travel agent, weather service); Semi-Trusted Processor (STP): Partially trusted intermediary between client and vendor in processing vendor business logic on
Craig Pearce, Peter Bertok, Ron Van Schyndel customer PI1 data. Example STPs include payment gateways, identity verifiers and marketing bureaus to name a few; Certificate Authority (CA): Trusted certificate server used for distribution and revocation of digital certificates to the entities communicating in an online transaction. The CA can be used throughout online transactions for verification of certificates with public key encryption and signing; Accountability Authority (AA): Used in disputed transactions to provide accountability of participants in case of abuse. The AA stores hashes of information used within a transaction, saving space and providing confidentiality to the other parties. A transaction is disputed when enough threshold certificates are gathered from disputing parties or if requested by an external certified entity. The AA and CA are essential services for a technically-enforceable system that guarantees privacy and accountability. The current approach to online transactions (Section 3, Scenario 1) uses SSLITLS encryption and X.509 Certificates signed by certificate authorities (CAs) to communicate vendor certificates to clients. An accountability service is not provided, limiting the types of transactions performed online due to lack of defined dispute resolution mechanisms.
4.1 Assumptions In formulating our system, we considered the following assumptions: STPs will not knowingly reveal PI1 data to another entity (with the exception of an accountability authority in pre-defined legal circumstances); STP, AA and Certificate Authority (CA) services are who they claim to be; host security has not been breached; Vendors comply with the privacy system by programming their business logic in a way that is executable by the STP; These assumptions show the proposed solution to be useful in providing customer privacy protection in scenarios where vendors are willing to program and communicate their business logic to STPs. This is not a major overhead, as vendor business logic should be a direct implementation of the action stated publicly in their privacy policy. In cases of rigid intellectual property agreements, non-disclosure agreements (NDAs) or outsourcing could be negotiated between vendor and semi-trusted processor. Additional privacy requirements, such as data minimisation and purpose binding can be met by the customer proactively reading the vendor's privacy
25
Pvotecting Consumer Data in Composite Web Services
policy and discontinuing the transaction if the collection purpose or amount of requested information is not appropriate. We plan for TEPS to utilise existing privacy and security services where possible. While TEPS is a generalised model, this paper explores TEPS in a service-oriented environment, with Figure 2 showing the communication stack layering TEPS on top of web services, as web services alone do not protect customers from misbehaving vendors. SSLITLS can be used for underlying channel communication security. : Technically Enforceable Privacy & Security (TEPS) * protection a g a m t misbehaving partlclpants * accountabllitv and d i s ~ u t eresolut~on
Web Services: WS-Security * blndlngs for XML encryption, signature, security assertions * authenhcatlon, confidentiality, lntegrlty of SOAP messages (XML-Encryption, XML-Signature)
H* authentication. confidentialitv. . intezritv of erson and replay attacks
1
I
Figure 2. TEPS communication stack: privacy and security for Web Services
4.2 Processing of an online transaction Figure 3 shows the functional steps taken in a transaction using TEPS. Each phase within Figure 3 is described here: 1. Whenever a vendor's form requests an input that has been marked PII, the client privacy reference monitor will transparently request a list of STPs from vendor. The vendor will compile a list of STPs (consulting a business registry (BR) if needed) and return this to the client with vendor's privacy policy (VP). The client hashes the VP and stores it safely in case of a disputed transaction; 2. From a given a list of STPs, the client will choose one, and then contact it to download the PI1 protector mobile code, providing a name certificate a shared for transfer of a temporal public key. The STP generates KSTP-CL, secret key, encrypting it with the client's public key for confidentiality. The PII-protecting mobile code is signed by the STP;
26
Craig Pearce, Peter Bertok, Ron Van Schyndel
3. The customer fills out the vendor's HTML form. The client executes STP's mobile code which protects the customer's PI1 by encrypting it with K,yTp-cL; 4. Upon receiving the PII-Protecting mobile code, the vendor executes the mobile code which prompts for a business process activity (BPA); 5. Once the mobile code cycles back to the STP, the BPA is processed with customer's PI1 data in a safe environment; 6. Threshold certificates are provided by CA after providing the name certificates of participants in the transaction 7.STP communicates h(VP), h(BPA), h({PII)KsTp-cL) hashes to AA. STP then responds to the vendor and client with the transaction outcome and threshold certificates in case a dispute arises; Legend
Cy,CSTP= identity certificates ~p = vendor privacy policy B p ~= vendor business process activity
Protocol 1. Initial communication 2. client downloads mobile code 3. customer fills out form 4. vendor provides BPA to STP 5. STP performs BPA on PI1 6. STP requests and receives threshold cens from CA 7(a) STF gives evidence of transaction to accountability authority 7(b) STP reveals outcome and gives threshold cert to client 7(c) STP reveals outcome and gives threshold cert to vendor
"'JJ
4%)
Figure 3. Privacy in transactions
The transaction will be aborted if the client is not satisfied with the list of STPs provided by the vendor in Figure 3 Step 1. If a party stops responding during the processing of a transaction, the transaction will time out and be aborted.
Protecting Consumer Data in Composite Web Services
4.3 Composite web services
Figure 4. Technically enforced privacy and security in composite web services
Scenario 2 of Section 3 described a transaction involving a customer and multiple vendors. Web Services privacy is an open question when each vendor performs a separate business process activity, integrated to form a composite web service [Medjahed et al., 20031. We address this issue by forcing the front-end web service to clearly state the need of back-end vendors in their privacy policy, and the client agreeing to transitivity of semi-trusted processing of personal information. The TEPS protocol is then performed recursively for each back-end vendor. For instance, the example composite web service in Figure 1 involves a separate invocation of TEPS for the Health Specialist and Pharmacy services, as shown here in Figure 4. Each subsequent vendor has an associated, possibly different, semi-trusted processor to perform its business process activity, preserving privacy for the previous vendor. A tree-based structure is formed and includes two chains of information flow: (1) untrusted vendor chain which has no access to client personally identifiable information or adjacent vendor privacy information and (2) trusted chain for semi-trusted processors to communicate customer personally identifiable information (PII) from top STP to bottom STP. While trust management of the STP chain is not addressed here, we assume clients to explicitly agree to adjacent STPs in a chain exchanging privacy information between themselves (transitivity).
4.4 Accountability and disputed transactions Transactions may be disputed when two or more parties out of three submit a dispute request with their allocated threshold certificate. Alternatively, external certified entities (ECEs) can initialise a disputed transaction by submitting a signed request with appropriate certification. An
Craig Pearce, Peter Bertok, Ron Van Schyndel
28
example scenario for ECE involvement would be law enforcement officers with reason to believe one of the parties committed fraud. Possible disputed transactions include: 1. (CL AND STP) AGAINST V 2. (V AND STP) AGAINST CL 3. (CL AND V) AGAINST STP 4. ECE AGAINST (STP OR CL OR 7')
Each party gives their evidence to AA who contains enough information to judge whether the defendant, first claimant andlor second claimant are cheating. If the defending party is not contactable for any reason, the transaction is logged as 'in dispute' by AA and claimants. The dispute resolution mechanism is a two-step protocol , with the AA firstly attempting to reach an outcome without knowledge of the PIIprotecting key, KSTP-CL. If an outcome cannot be determined at this point, as evidence; both client only then will the AA request submission of KSTP.CL and STP are asked to provide the shared secret key as either party may be a suspect.
5.
SECURITY CONSIDERATIONS
We have relaxed tmst on the STP to not reveal customer PI1 and properly execute PI1 within the vendor business process activity. This opens up hostile STP possibilities, such as: *STP falsifying the transaction outcome: client and vendor could request a dispute, resulting in the AA detecting an anomaly in the transaction; STP leaking vendor's business process activity: vendor can mitigate risk by code watermarking [Collberg and Thomborson, 20021 the business process activity for detection of misuse, such as disclosure or reverse-engineering; .External denial of service (DoS) attacks: it is expected that the STP provides a list of replicated services to alleviate bottleneck and single point of failure concerns. Collusion between two parties (for example, vendor and STP) prevents the remaining party from issuing a disputed transaction request. The remaining party could still contact an external certified entity (ECE) for further investigation. We have assumed the STP will not knowingly disclose customer PII, however, in the case of compromise, a noticeable amount of information
Protecting Consumer Data in Composite Web Services
29
may accumulate over time. Customers can mitigate potential risk by choosing an STP that operates within the same data privacy laws and we expect that finding a reputable STP is easier than finding a reputable vendor. Although privacy principles of 'data minimisation' and 'purpose binding' are not technically enforced by TEPS, compliance has been placed in the customer's domain. Customers can check vendor PI1 requests against their stated privacy policy before opting to continue with the transaction. Customers and STPs can check vendor purpose binding and is considered a legal issue if not followed, pre-empting a transaction dispute.
6.
FORMAL ANALYSIS OF THE PROTOCOL
TEPS has been formally verified with the Casper protocol compiler and FDR2 model checker [Donovan et al., 19991 to prove confidentiality on customer PI1 data, vendor business process activities hold against all currently known communication channel attacks. Due to combinatorial explosion of the search space, privacy assertions for composite web services could not be fonnally verified by FDR2. However, as simple web services privacy is formally verified, and composite web services are iterated simple web services, induction suggests TEPS provides technically-assured privacy of composite web services.
7.
IMPLEMENTATION AND RESULTS
TEPS was implemented in Java with Web Services support for SOAP messaging and WSDL documents. Our system offers flexibility of public key certificate representations, supporting X.509 and SPKIISDSI formats. X.509 is the industry standard, providing identity certificates but it requires hierarchies of fully-trusted certificate authorities and cannot handle threshold certificates. SPKIISDSI is a simplified and flexible certificate system allowing identity and authorisation certificates, fine-grained access control and, most importantly, supports threshold certificates. We implemented a secured SPKIJSDSI framework, that was reported in [Pearce et al., 2004a, Pearce et al., 2004b1, which allows for naming, access control and thresholding. TEPS services use thread-based concurrency to support multiple transactions simultaneously. Business process activities (BPAs) are compiled Java bytecodes packaged as '.jar7archives. Vendors could possibly
Craig Pearce, Peter Bertok, Ron Van Schyndel
30
provide BPAs to semi-trusted processors in an encrypted form for confidentiality. Experiments were conducted on Intel(R) PI11 lGHz machines, with separate machines for each service, communicating over a wired lOOMbps switched network. We measured client connectivity on both the lOOMbps switched network and a wireless 802.1 1g network at speeds of lMbps and 11Mbps. The wireless access point used media access control (MAC) filtering and Wired Equivalency Privacy (WEP) based encryption for additional security. Table I . Total client-wait times using TEPS with and without TLS ~ I M (sec) E CONFIGURATION TEPS, Wired I OOMbps b.67 TEPS, Wired IOOMbps, SSLITLS 8.35 TEPS, Wireless lMbps 8.01 TEPS, Wireless 1 lMbps 1.67
Table 1 shows protocol performance in the client perspective by measuring total client-wait time over the entire length of a transaction. Vendor privacy policies and business process activities were fixed at one kilobyte each. Timing of business process execution by STPs were not performed as they gave a constant time among each experiment and, pragmatically spealung, are highly dependent on the business purpose of the vendor. Results from Table 1 indicate that TEPS is efficient at servicing simple web services transactions for both wired and wireless clients, with overheads of around seven to eight seconds per web services transaction. In fact, transaction times did not significantly differ for either wireless or wired network speeds, never exceeding 5% of total transaction times. This suggests that transaction performance will remain satisfactory as network speeds scale down further. Tunnelling TEPS over SSLITLS incurred a penalty of nearly one second for total client wait-times. Service start-up times took an Table 2. Processing and communications costs for participant
CL
Send 4
Recv 4
-92
Processing + Communication Times (sec) Send Recv Total 6.65 3.01 3.64
V STP CA AA
3 5 1 0
4 3 1 1
-56 -136 -60 -0.8
0.01 0.05 3.09 -
Party
Number of Messages
Total Message Sizes (kb)
6.58 3.53 0.04 0.1 1
6.59 3.58 3.13 0.1 1
Cryptographic Operations Encrypts 1 (symm)
Decrypts 1 (asymm) 1 (s~mm)
3 (asymm sig)
Protecting Consumer Data in Composite Web Services
31
additional three to five seconds for SSLITLS enabled sockets due to key randomisation and secure socket establishment. For a deeper understanding of practicalities within TEPS-enabled web services transactions, we measured processing and communication costs incurred by each party for each communicated message. This was collated to give an overview on how much work is performed by each participant, as shown in Table 2. Client and vendor have the highest costs in terms of time, due to encryption, communication and awaiting responses from other parties respectively. The STP, as is evident with the vendor, spends almost all of its time waiting to receive messages, whereas the certificate authority incurs most of its costs in generating and communicating threshold certificates. Our results suggest a linear extension of composite web services yields linear growth in time complexity. For example, the Health Clinic service detailed in Scenario 2 of Section 3 would involve three iterations of TEPS, each iteration being interleaved within its adjacent iteration with a total client wait-time approximately three times longer than a single iteration.
8.
DISCUSSION AND FURTHER WORK
Through the use of a semi-trusted processor, TEPS guarantees protection of customer personally identifiable information (PII) against untrusted vendors in the application layer. This also prevents vendors from linking up databases and identifying customers on seemingly unlinkable attributes (triangulation). Introducing an accountability authority allows for externally certified entities to follow up unlawful activities. TEPS supports execution of business process activities for (1) once-off transactions (for example, customer using an online broker) and (2) transactions requiring multi-vendor integration, that being composite web services. In the first scenario, described in Section 3, the business process activity may require access to the vendor database (for example, an inventory table). It is the responsibility of vendor and semi-trusted processor to agree on appropriate mobile code and dependent parameters to satisfy business logic for execution of business process activities. One solution can involve the vendor attaching required data from its own database to the business process. Alternatively, both vendor and STP can agree on a common link for respective scrambled PI1 and plain-text PI1 database entries. The second scenario is addressed by iterating the TEPS protocol for each additional back-end vendor web service, creating a trusted chain for semi-trusted
Craig Peavce, Peter Bevtok, Ron Van Schyndel
32
processors and an untrusted vendor chain. Complexity is linear which suggests that the system is extensible for transactions of growing numbers of interacting services. However, for large business processes or a large number of co-operating vendors, long running transactions (LRTs) may be required to provide acceptable client wait-time. We expect to alleviate vendor reluctance of outsourcing full business processes to STPs by the use of code watermarking: detecting STP misuse, such as disclosure or reverse-engineering. More comprehensive solutions may be more applicable, such as source code escrow agreements. TEPS prevents vendors from profiling clients, which is another privacy issue. However, if customers choose to allow profiling of their activities, the STP can profile customers based on gathered information, anonyrnise (by removing identifiable elements) and pass it back to the vendor. We have not investigated programming challenges of aggregation and separation of business processes into activities that can be processed by separate parties. Furthermore, aggregation and separation of privacy policies among co-operating vendors is an area of future work. Investigation into the benefits and trade-offs of caching vendor business policies with identity and authentication details will help decide whether additional performance gains are worth the risk against obsolescence. Vendor policies negotiated on a client-by-client basis presents an open problem in this approach.
9.
CONCLUSION
In this paper we proposed the Technically-Enforceable Privacy and Security (TEPS) system that prevents vendors from ever obtaining customer personally identifiable information. Major components of the system were the following: semi-trusted processor to (I) protect customer personally identifiable information (PII) and (2) execute vendor-provided business processes with customer PI1 data in a protected environment; accountability service to provide recourse when one or more parties abuse the protocol; resolution mechanism for transaction disputes; Furthermore, we showed how TEPS is extensible in supporting composite web services by iterating the protocol for multiple back-end vendors. TEPS has been verified to ensure customer privacy is maintained against untrusted vendors or external attackers and that vendor business process activities are not accessible to parties other than the semi-trusted processor.
Protecting Consumer Data in Composite Web Services
33
Our results indicated that the solution was suitable for web services as client wait-times for transactions were within an acceptable range. TEPS also performed well in slower wireless networks and transaction times grew in a linear fashion as complexity of interactions rose in composite web services scenarios. TEPS gives privacy and security guarantees to prevent untrusted vendors from obtaining private customer information within traditional transactions and composite multi-vendor web services. In helping alleviate consumer concerns and address open issues of privacy within composite web services, service-oriented transactions can become a safer practice.
ACKNOWLEDGEMENTS We would like to thank Formal Systems for providing a license to freely use FDR2. We would also like to thank the anonymous reviewers for their useful suggestions.
REFERENCES [Ashley et al., 20031 Ashley, P., Hada, S., Karjoth, G., Powers, C., and Schunter, M. (2003). Enterprise Privacy Authorization Language (EPAL). Research Report 3485, IBM Research. [Berthold and Kohntopp, 20011 Berthold, 0 . and Kohntopp, M. (2001). Identity management based on P3P. In Lecture Notes in Computer Science, volume 2009, pages 141-160. [Campbell et a1.,2002] Campbell, R., Al-Muhtadi, J., Naldurg, P., Sampemane, G., and Mickunas, M. Dennis (2002). Towards security and privacy for pervasive computing. In Proceedings of the International Symposium on Software Security, Keio University, Keio University, Tokyo, Japan. [Casassa et al, 20031 M. Casassa Mont, S. Pearson, P. Brarnhall. Towards Accountable Management of Privacy and Identity Information. ESORICS 2003: 146-161 [Chanet a1.,2002] Chan, H., Lee, R., Dillon, T., and Chang, E. (2002). E-Commerce: Fundamentals and Applications. pages 287-298. ISBN: 0-471-49303-1, [Chaum, 19811 Chaum, D. (1981). Untraceable Electronic Mail, Return Addresses and Digital Pseudonyums. Communications ofthe ACM, 24(2):84-90. [Chaum, 19821 Chaum, D. (1982). Blind Signatures for Untraceable Payments. Crypto, pages 199-203. [Chaum et al., 19901 Chaum, D., Fiat, A,, and Naor, M. (1990). Untraceable electronic cash. Proceedings on Advances in cryptology. California, United States, pages 3 19-327. [Collberg and Thomborson, 20021 Collberg, C. and Thomborson, C. (2002). Watermarking, Tamper-Proofing, and Obfuscation - Tools for Software Protection. In ZEEE Transactions on Software Engineering, volume 28, pages 735-746. [Dierks and Rescorla, 20041 Dierks, T. and Rescorla, E. (2004). The TLS Protocol Version 1.1. I n t e m e t D r a f t h t t p : //www.potaroo.net/ietf/ids-wg-tls .html.
34
Craig Pearce, Peter Bertok, Ron Van Schyndel
[Dingledine et al., 20041 Dingledine, R., Mathewson, N., and Syverson, P. (2004). Tor: The Second-Generation Onion Router. In In Proceedings of the 13th USENIX Securip Symposium. [Donovan et al., 1999]Donovan, B., Norris, P., and Lowe, G. (1999). Analyzing a library of security protocols using Casper and FDR. In Workshop on Formal Methods and Security Protocols. [Goldberg, 20021 Ian Goldberg. Privacy-enhancing Technologies for the Internet, 11: Five Years Later. Workshop on Privacy Enhancing Technologies. April 2002 [intemetnews.com, 20031 intemetnews.com, Staff: (2003). Acxiom Hacked, Customer Information Exposed. Website: www.internetnews.com/storage/article.php/2246461. [Jakobsson and Juels, 20011 Jakobsson, M. and Juels, A. (2001). An Optimally Robust Hybrid Mix Network. In Proceedings of the twentieth annual ACM symposium on Principles of distributed computing, pages 284-292. ACM Press. [Jendricke et al., 20041 Jendricke, U., Kreutzer, M., and Zugenmaier, A. (2004). Pervasive Privacy with Identity Management. In Proceedings of ACM Symposium on Applied Computing, pages 1593-1599. ACM Press. [EU FP6 PRIME Project, 20051 PRIME: Privacy and Identity Management for Europe. Last accessed: 15-1 1-2004. Website: htt~:!lwww.~rime-~roject.eu.org/ [Kenny andKorba,2002] Kenny, S. and Korba, L. (2002). Applying digital rights management systems to privacy rights management. Computers & Security, 21(7):648664. [Medjahed et al., 20031 Medjahed, B., Benatallah, B., Bouguettaya, A,, Ngu, A. H. H., and Elmagarmid, A. K. (2003). Business-to-business interactions: issues and enabling technologies. The International Journal on Very Large Data Bases, 12(1):59-85. [Pearce et al., 2004al Pearce, C., Bertok, P., and Thevathayan, C. (2004a). A Protocol for Secrecy and Authentication within Proxy-Based SPKIISDSI Mobile Networks. AusCERT Asia Pacific Information Technology Security Conference ISBN: 1864997745. [Pearce et al., 2004bl Pearce, C., Ma, Y., and Bertok, P. (2004b). A Secure Communication Protocol for Ad-Hoc Wireless Sensor Networks. IEEE International Conference on Intelligent Sensors, Sensor Networks & Information Processions, Melbourne, Australia. [W3C, 2002lW3C (2002). Platform for Privacy Preferences (P3P). W3C Recommendation www.w3c. org/TR/2002/REC-P3P-20020416/. [Waldman et al., 20001 Waldman, M., Rubin, A., and Cranor, L. (2000). Publius: A robust, tamper-evident, censorship-resistant, web publishing system . In Proc. 9th USENIX Security Symposium, pages 59-72.
A DECISION MATRIX APPROACH to prioritize holistic security requirements in e-commerce Albin Zuccato Karlstad University, Department of Computer Science, Universitetsgafan 2, 651 88 Karlstad, Sweden
Abstract:
In security management, the concept of security requirements has replaced risk analysis when assessing appropriate measurements. However, it is not clear how elicited requirements can be prioritized? State of the art methods to prioritize the holistic nature of security requirements are applicable only after major revisions. This dilemma is the starting-point for proposing a qualitative decision matrix approach which is quick and where the results are reproducible and sufficiently accurate. This article describes how the parameters for a prioritization are derived and how the prioritization is carried through.
Keywords:
decision matrix, prioritization
holistic
security
requirement,
security
requirement
INTRODUCTION In recent years the term security requirement has become more and more popular in the security management community. The purpose of a security requirement is to guide the implementation and ongoing administration in security management [IS0 13335-1, 19961. In earlier years, a security requirement was mainly interpreted as a factor that had to be derived from a risk analysis process - see [IS0 13335-1, 19961, [IS0 17799, ~ O O O ] . The risk value then clearly indicated the importance of the requirement. The more severe the risk was, the higher was the incitement to realize the requirement. In that manner a priority order, dependent on the risk value, can be established and the resources can be dedicated to the most important requirements. This is
Albin Zuccato necessary as we assume that only limited resources are available which are insufficient for realizing all security requirements. However, for to e-commerce applications [Zuccato, 20041 suggests that also the stakeholder and the environment can in addition to impacts of risks on assets also provide valuable inputs to the holistic security requirements. This broadening of a security requirement implies that the conventional mechanism for prioritization is no longer suitable. Therefore we propose the decision matrix approach, which relies on a strategic management method in order to prioritize business activities, called the Boston Consulting Group (BCG) Matrix, and adapt it to the security area. The proposed approach is described later in the article, where also an application example is provided. Apart from the functional demands we proposed in [Zuccato, 2002a] that an approach that works in an e-commerce environment should also fulfill additional demands. One demand for each decision method should be that the results can be reproduced later4. Another demand that is specifically important in e-commerce is short time-to-market cycles - therefore a ranking method must be fast. To justify the proposal of a new approach we will start by discussing related work on requirement prioritization approaches from the security field as well as the software engineering community. Shortcomings that make those approaches unsuitable for the discussed problem will be pointed out.
2.
REQUIREMENT PRIORITIZATION TODAY
The concept of requirements is a recent trend and currently heavily influenced by the previous approach of risk analysis. [IS0 17799, 20001 mentions for example security requirements, but has risk analysis as the only source. This implies that risk management concepts can be applied for prioritization. [IS0 17799,20001 and, based on that, [CCTA CRAMM, 19961, argue that the asset value and the savings indicate the risks that should be mitigated. The problem with this assumption is that risks are taken as the only source for security requirements. [Zuccato, 20041 states that security in e-commerce cannot solely rely on risk analysis. Additional input from business and stakeholder have to be included in order to cover a broader picture. Such requirements are then no longer expressed in terms of risks for an asset. Therefore the old prioritization (higher risks first) is inappropriate.
4 0 n e argument in favor of that is liability claim to 2 court. With a reproducible process it is easier to prove an honest and negligent behavior.
A Decision Matrix Approach
37
As an alternative to risk concept, sometimes business metric systems are used - see [Gordon et ai., 20041.Prominent examples used in the security field are Return of Security Invest (RoSI) [Wei et al., 20011 or Net Present Value (NPV). RoSI conducts a cost-benefit analysis almost in the same way that we are going to propose it. However, the fundamental difference is that that RoSI was designed to evaluate the effectiveness of security safeguards. The approach chooses a risk and then evaluates in how far a given safeguard prevents it. RoSI implicitly assumes that all risks (or mainly the most prominent risks) are considered. A similar approach is presented in [Pfleeger and Ptleeger, 20031, where risks are processed in order of their magnitude. In [Zuccato, 2002bI we argue that security (requirements) can "earn" money as a business enabler (i.e. generate a positive cash flow) and it would be wise to consider that in the cost-benefit analysis. The NPV approach in security anticipates the occurrence of future cash flows when a risk is mitigated by a safeguard. Such cash flows would represent the annual spending and the annual savings for the anticipated risks - it would be possible to replace a risk with a requirement. However, apart from the risk related problem mentioned above, we have another problem with NPV which is that future cash flows and future interest-rates (for discounting) must be known in advance. In a highly volatile area that information security constitutes such a long term prognoses seems to be almost impossible5 . A third alternative is to rely on the requirement prioritization schemes from the software engineering community. Three of these approaches should be discussed as representatives. We start with the extreme Programming (XP) [Beck, 20001 as a representative for the agile methods. With XP the customer is requested to define a priority for each requirement (called story). When it comes to security this implies a specific problem, namely that many customers do not realize the importance of security [Hitchings, 19951 and therefore rank it very low - as current experiences with security problems indicate. A second problem is that such decisions are hardly reproducible. The second approach is to ask the stakeholder how (a) satisfied with the availability of a security feature or (b) unhappy with its absence they would be [Robertson and Robertson, 19991. This approach is better than just simply asking the customer, as it probably mitigates the "dislike -factorn when
is also a quantitative method and as [Moses, 19921 argued, quantitative methods imply problems of data generation in the security field.
5~~~
38
Albin Zuccato
distributed to various stakeholders. Regarding the reproducibility, however, it is only slightly better. Finally, we look at the requirement prioritization carried through in the Unified Process (UP) [Jacobson etal., 19991 as a representative for the monumental processes. [Leffingwell and Widrog, 19921 indicates that two different prioritizations are required in the UP. The first one lies on the customer's side, where helshe has to define the features required. The assumption is, in conformity with approaches presented earlier, that the decision maker possesses some kind of oracle that supports the decision making. However, it can be questioned whether this is true for security, as we assume that the decision maker seldom has enough knowledge to conduct such decisions. The second prioritization in the UP is carried through by the software architect, who decides, based on the first prioritization, which requirements should be implemented first and which ones will be postponed to later iterations or versions. It is therefore necessary to assume that they are initially ranked highly enough when considering security requirements, so that they will be implemented also after the second prioritization. It is obvious that this assumption is doubtful as the same decision restrictions as above can be applied. These problems with each of the above mentioned methods indicate that they are not entirely suitable and could only be applied after major adoptions. We therefore propose a different approach used in strategic management when deciding which products (features) are required on the market which also is suitable for the security field and security requirements.
3.
PORTFOLIO ANALYSIS
In strategic management, one of several important tasks in order to survive in the competitive market and to maximize the profits is to find the optimal product portfolio. As a result of that, the portfolio analysis was proposed in the 1970ies to find out the actual product's position on the market. Based on that information the further steps were planned. The first approach came from the [[Boston-Consulting-Group, 19721 (BCG) and today, thanks to its simplicity, it is still the most frequently used one, and it will be investigated further on in this article.
3.1 Boston Consulting Matrix The BCG Matrix is based on two criteria: the reference market's growth rate (acting as an indicator for the attractiveness) and the market share in relation to the firm's largest competitor (measuring competitiveness). A
A Decision Matrix Approach
39
large market growth means that the product is mostly at the begin of its life cycle and has the potential to get large parts of the market although not having it yet. In the matrix - Fig. 1 - these two criteria form the axes. Additionally the matrix is divided into 4 zones, where each of them intuitively represents the products position on the market.
Figure 1. Product portfolio matrix after BCG
After defining the duple for each product, the value pair is going to be drawn in the matrix. Based on the position, different strategies are proposed (see for example [Lambin, 19971). Cash cow (a well situated, profitable product) The priority strategy is to earn money. (an old product for divestment) The priority strategy is to divest. Dog Star (a young product with market potential) Investment is recommended to make the product a cash cow. Problem child (product in start-up phase, which needs placement) Depending on the relative position in the quadrant, two strategies are possible: an investment strategy to make the product a cash cow, or a divestment strategy to make the product a dog.) [Lambin, 19971 argues that although the initial assumptions may be restrictive - but assumably correct - an accurate and valuable recommendation can be generated. An advantage worth to emphasize is that the matrix is straight forward and intuitive and therefore easy to understand and apply.
4.
DECISION MATRIX FOR SECURITY REQUIREMENTS
In the previous section, the BCG matrix was introduced as a tool when deciding how a portfolio should be developed further. The problem is
40
Albin Zz~ccato
similar when it comes to security requirements: how do we decide which ones should be developed first and which ones can wait? To conduct this decision we first need to position the requirements in the matrix. Then we can derive a priority list. Additionally, the position in the matrix can suggest a course of action for the treatment. The positioning mentioned is the difficult part of the approach as it is the non-mechanistic (creative) one. Corresponding parameters to attractiveness and competitiveness must be derived for each requirement. When the requirements are parameterized, the mechanistic part of the priority generation must be conducted. Before going into more detail for each step we will provide an overview for our approach.
4.1 Approach To begin with, it is necessary to assess a requirement according to its potential, i.e. to generate something similar to the tuple of attractiveness and competitiveness used in the BCG Matrix. Each requirement should be represented as a tuple containing the perceived security benefit and costcomplexity of the realization. To reflect competitiveness of a requirement we Security benefit propose to use the perceived security benefit. Security benefit should mean either (a) that the requirement provides high protection of own resources andlor (b) that the requirement will increase the security benefit as it enables business. This is based on the underlying assumption for holistic security requirements, where they not only insure company resources but also enable the selling of the product because of a competitive advantage gained from the satisfaction of security needs from customers - for a more elaborate discussion of these security drivers see [Zuccato, 20021~1.Then we can say that the higher the security benefit of a requirement is, the more competitive it is in respect to other requirements. CostIComplexity We think that attractiveness of the requirement is represented best by its costs of realization and the associated complexity. These factors represent in how far the requirement is likely to fulfill its perceived function. The more it costs and the harder it is to realize, the higher the stake is. However, the cost-complexity measure makes only sense in relation to the intended security level. It is important to mention that a requirement that is easier and cheaper to enforce than a second one with he same benefit should be prioritized, and it most definitely does not mean that the cheap and easy way is always the best solution.
A Decision Matrix Approach Cost-Lonxpl. v x v
Figure 2. Requirement prioritization matrix
Before applying the matrix concept, the meaning of the quadrants needs to be set into relation to the input values. This is necessary as the complexity and costs are indirect proportional to the benefit. More benefits and limited costs are preferable. Additionally the quadrants must be redefined to reflect the scope of security requirements. means that not only the complexity and the costs are low, but Dog also are the benefits. The requirement has an indifferent potential. Problem child means that the complexity and the costs are high and the expected benefit is low. The potential of the requirement is low. means that the complexity and the costs are low but the Cash Cow expected benefit is high. Such a requirement is very promising to realize as it has high potential. Star means that both the cost-complexity and the benefits are high. Although such a requirement is interesting its realization is also highly risky. Therefore, as for the dog, the potential is indifferent.
4.2 Input data elicitation The approach for every security requirement is to elicit the perceived security benefit and the cost-complexity level. Due to several reasons of impracticability of quantitative methods we will use a qualitative approach. Firstly we think that the required empirical data for a quantitative estimation is hard to provide due to the high dynamics in the security field - see [Moses, 19921. Secondly, we think that most quantitative estimates require an "oracle" - most likely statistical prediction or a simulation - which would not necessarily provide more accuracy than a qualitative estimate (i.e. an expert guess). And thirdly, we think that an empirical method is more prone to violate our quickness requirement for a prioritization method.
42
Albin Zzrccato
However, as the goal is to achieve reproducibility and acceptable accuracy, we propose the conduction of a structured elicitation. We suggest the use of the Delphi method [Dalkey and Helmer, 19631 in order to predict the security benefits and the cost-complexity parameters. Delphi is a method that is used to support judgmental or heuristic decision-making - i.e. creative or informed decision making. According to [Adler and Z ~ I I O , 19951, Delphi is a suitable method when "(a) the problem does not lend itself to precise analytical techniques; (b) the problem at hand has no monitored history nor adequate information on its present and future development [and]; (c) addressing the problem requires the exploration and assessment of numerous issues". We think that all these factors are accurate in concern of our elicitation problem. Alternative approaches to Delphi could be brainstorming or questionnaires. However, both alternatives can create problems in the reliability and are eventually subjects to the "dislike" problem mentioned above. "The Delphi method is based on a structured process for collecting and distilling knowledge from a group of experts by means of a series of questionnaires interspersed with controlled opinion feedback [Adler and Z ~ I I O , 19951. In the beginning a questionnaire is sent to selected experts. The filledin questionnaires are collected and aggregated as a second step. Different ways to derive the aggregates are possible, but here a mean value approach has been used. The mean-value should then be rounded to the next integer to avoid positioning problems in the evaluation. The aggregates constitute feedback to the experts, and in case of to big variation - decided by the method performer - the experts are requested to further state or revise their opinions. This process is conducted until the intended accuracy is achieved. Note that the higher the accuracy demand is, the higher the cost will be which holds true for all decision methods. The design of the questionnaire mentioned above is important in order to achieve satisfactory inputs for the result generation - i.e. the requirement prioritization. To perform the subsequent prioritization process efficiently we need to have sufficient parameter information without adding much complexity to the prediction - which would require additional time. We therefore propose the use of an ordinal scale for the parameter. To derive the scale, according to [Fowler, 19951, one must design the granularity to (a) achieve validity, and (b) make the elements of the distribution distinguishable. This would indicate that the higher the granularity is, the better. However, [Fowler, 19951 says that 5 to 7 categories are probably as many categories as most respondents can use meaningfully. This means that we will aim for a six value scale as our scale must be a multiple of two to correspond with the quadrant structure of the matrix. The quadrants should be made explicit to the respondents by introducing a neutral point in betwecn,
A Decision Matrix Approach
43
as [Fowler, 19951 says that neutral points help to reduce ambiguity. Therefore we introduce a neutral point between 3 and 4 where I - 3 represent low and 4 - 6 represent high. [Fowler, 19951 suggests to use numbers for reliability reasons, but to provide adjectives for clarification of the categories' meaning. Based on that we propose the following scale for each parameter:
Figure 3. Ordinal scale for the survey
To derive the categories for each requirement, two questions should be asked for each requirement. How much security benefit do you associate with the requirement? How much complexity and cost do you associate with the realization of the requirement? The result is then represented as a tuple:
Requirement(Bene$t, Cost-Complexity)
4.3 The prioritization activity The aim of the decision matrix is to derive, which requirements should be implemented at first. The position in the matrix suggests the priority of the requirements. To derive the priority, we suggest two different methods which should be used dependent on the accuracy demand, the quality of the inputs and the application place. For the first method we suggest the use of the quadrants. Based on the result a priority can be derived. The second method will rely on a more formal prioritization that eventually could be automatized.
4.3.1 Informal prioritization For the start, we assume that the requirements are placed in the matrix. The quadrants can then be used to derive a requirement priority list. This list suggests which requirements should be considered first. In general we can say that the closer a requirement is to the right lower corner, the more preferable it is. Given the quadrants we therefore suggest the following prioritization:
Requirement list = (Cash Cows, lower Stars, lower Dogs, higher Stars, higher Dogs, Problem child)
Albin Zuccato
These requirements are likely to be problematic in the Problem child implementation. The expected benefit will not justify that and they will end up low in the priority list. Cash Cow These requirements are of great priority as much benefit is expected for the associated costs and complexity. They will all end up high in the priority list. Star We have already mentioned that this quadrant suggests indifference. However, we can derive a priority in the way that we imagine a diagonal from the source to the upper right comer. All requirements that are below will have higher priority than the requirements above it. Therefore the "lower Stars" will follow directly after the Cash cows and the "higher Stars", and end up in the middle of the priority list. Dog The "Dog requirements" are similar to the stars when it comes to indifference. The same diagonal as mentioned above can be used to derive priorities. "lower Dogs" will come after the "lower Stars" and "higher Dogs" after the "higher Stars" just before the "problem child" requirements.
Figure 4. Informal prioritization matrix
Although the informal method can be less accurate we propose it because: 1. it is a good way to visualize the requirement prioritization for the decision maker; 2. in cases where the input variables do not provide high accuracy - because the Delphi method was abandon in favor of a faster or more suitable method in specific situations - the informal method do not introduce a fictive accuracy and; 3. in some situations - e.g. a requirement engineering workshop with stakeholders [Zuccato, 20041 - a visual and less technology dependent method is preferable
A Decision Matrix Approach
4.3.2 Formal prioritization The formal approach starts by deriving a value for each requirement, which defines the position in the matrix. This value is calculated by dividing the Benefit with the Cost-Complexity - Equ. 1. To position that in the matrix (aij)we assume that i=BeneJit and j=CostComplexity.
a. . = J
Benefit CostComplexity
For a 6x6 matrix we can construct generic values as shown in table 1. Table 1.Priorities for a 6x6 Matrix Benefit 2 1 Cost 0.16 0.33 6 0.4 5 0.2 0.25 0.5 4 0.33 0.66 3 1 2 0.5 1 1 2
3 0.5 0.6 0.75 1 1.5 3
4
0.66 0.8 1 1.33 2 4
5 0.83 1
1.25 1.66 2.5 5
6 1 1.2 I .5 2 3 6
For prioritization we construct - as in the informal approach - a preference set. We compare two requirements with each other until we have processed all requirements6 . This comparison leads to a preference set where a+b means that a is preferred to b, and a-b means that they are indifferent. When the prioritization value of one requirement (aij)is different to the other requirement ( a k J ,we construct a preference order by following the Equ. 2.
The prioritization value can be equal under two circumstances. In these cases a preference order should be achieved dependent on the requirement
6 ~ o t that e this is a classical sorting problem. Therefore sort algorithms should be used to process all requirements.
Albin Zuccato
46
parameter. If the parameters are equal, the requirements are indifferent and receive the same priority7 - see Equ. 3.
If the parameters are different from each other, we define that more security benefit (i>k) is preferable, as our overall goal is to improve the system security - see Equ. 4. However, when having a limited budget this interpretation must not correspond with the truth and could be reconsidered
O'q. a .J. = a k , , ~ i > k = a i , +a,,, / 1,
5.
(4)
E-COMMERCE SCENARIO
We start by looking at some security requirements proposed in [Zuccato, Those requirements have an Internet-banking scenario as a background, where the customers access their accounts and make money transfers. 1. Sensitive user data (passwords, keys ...) in a database needs to be stored bi-directionally (not hashed) encrypted due to requirements of the voice recognition system. 2. A demand of internal audit means that audit logs for the intrusion detection system must be stored for three months. 3. An activity log for each transaction should be kept for six months. 4. When saving personal information for statistical purposes, user pseudonyms should be used whenever possible to comply with the data protection legislation. 5. User authentication for accessing bank accounts and services via the internet is necessary. 6. The privacy policy must define customer profiling as one purpose for the activity logs. We start by preparing the questionnaire for the Delphi method. Then we select some experts representing different areas to cover all aspects of the 20041.
7 ~ o t that e this is an intended behavior as those requirements then form a priority group, where the requirements are of the same importance and the selection can be conducted based on project planning considerations.
A Decision Matrix Approach
47
holistic requirements. A few examples could be: a security officer, a product owner, a bank manager, a security implementer ... In this example we assume that we will receive the following parameter values after a number of Delphi iterations. equ. 1
1
Benefit 14
I ~ o s t c o m ~ . Requ. 4 12
1
Benefit 12
lcostcornp
I6
Informal method When we conduct the informal approach we must transfer the requirements to the matrix - see Fig. 5.
From there we can follow our algorithm and derive a priority list. We get the following priority set: ({5,1),3, {6,2),4). Note that according to this priority list there is no priority between 5 and 1 and 6 and 2. Formal method To conduct the formal approach we need to calculate the values for each requirement.
When applying the algorithm we will end up with a priority set as follows: (5,1,6,3,2,4). The difference to the informal method is that due to the higher granularity we achieved a greater accuracy in the result. Requirement 6 would have gained less attention in the informal approach than in the formal one as it is in the wrong quadrant.
Albin Zuccato
6.
CONCLUSIONS
It is a difficult task to make requirement prioritization easily understandable and reconstructible. In a market environment, where timeto-market cycles are measured in weeks instead of months, the speed of such a method is of considerable importance. The method presented in this article is supposed to solve these problems by enabling a prioritization based on a matrix approach common in strategic management. By choosing this matrix approach, large parts of the prioritization work become mechanistic and therefore easy to reproduce. The non-mechanistic part uses an established prediction method to derive parameter values and can therefore be more easily reproduced. Concerning the speed, a final judgment can only be made after extensive testing. However, from a theoretical perspective, properties as simplicity and the mechanistic prioritization imply acceptable speed behavior. In future research it would be interesting to transform this qualitative method into a quantitative one by providing means to derive the input parameters by calculatory means - as we hope that the progress in security management will provide a sufficient database for statistical prediction. It would be of great interest to learn whether this could enhance accuracy further by not decreasing speed and simplicity significantly. A predecessor of this method was, as described above, applied once in an Internet banking environment. However, as this approach has changed partially, we plan further application in order to verify the presented ideas in this article.
REFERENCES [Adler and Ziglio, 19951 Adler, M. and Ziglio, E. (1995). Gazing into the oracle: the Delphi method and its application to social policy and public health. London - Jessica Kingsley. [Beck, 20001 Beck, K. (2000). extreme programming explained. Addison Wesley. [Boston-Consulting-Group, 19721 Boston-Consulting-Group (1972). Perspectives and Experience. Boston, Mass. [CCTA CRAMM, 19961 CCTA CRAMM (1996). CCTA Risk Analysis and Management Method. Central Computer and Telecommunication Agency, United Kingdom, user manual edition. [Dalkey andHelmer, 19631 Dalkey, N. and Helmer, 0. (1963). An experimental application of the delphi method to the use of experts. Management Science, (9): 458467. [Fowler, 19951 Fowler, F. (1995). Improving Survey Questions, volume 38 of Applied Social Research Methods Series. Sage Publications. [Gordon et al., 20041 Gordon, L. A., Loeb, M. P., Lucyshyn, W., and Richardson, R. (2004). 2004 csilfbi computer crime and security survey. Technical report, CSIFBI.
A Decision Matrix Appvoach
49
[Hitchings, 19951 Hitchings, J. (1995). Achieving an integrated design: the way forward for information security. In Eloff and von Solms, editors, Information security - the next decade, pages 369 - 383. IFIP, Chapman & Hall. [IS0 13335-1, 19961 I S 0 13335-1 (1996). ISOIIEC TR 13335- 1: 1996 Information technology - Guidelines for the management of IT Security - Part 1: Concepts and models for IT Security. International Standard Organization. [IS0 17799,20001 I S 0 17799 (2000). ISOIIEC 17799: 2000, Information technology Code of practice for information security management. International Standard Organization. [Jacobson et al., 19991 Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process. Object technology series. Addison Wesley Longman. [Lambin, 19971 Lambin, J.-J. (1997). Strategic marketing management. McGraw-Hill. [Leffingwell and Widrog, 1992lLeffingwel1, D. and Widrog, D. (2000). Managing software requirements: a unified approach. Addison Wesley. [Moses, 19921 Moses, R. H. (1992). Risk Analysis and Management. In K.M.Jackson and J.Hruska, editors, Computer Security Reference Book, pages 227 - 263. Buttenvorth Heinemann. [Pfleeger and Pfleeger, 20031 Pfleeger, C. and Pfleeger, S. L. (2003). Security in Computing. Addison & Wesley, 3ed edition. [Robertson andRobertson, 19991 Robertson, S. and Robertson, J. (1999). Mastering the requirements process. Addison-Weseley. [Wei et al., 20011 Wei, H., Frinke, D., Carter, O., and Ritter, C. (2001). Cost-benefit analysis for network intrusion detection systems. In 28th Annual Computer Security Conference. [Zuccato, 2002al Zuccato, A. (2002a). A modified mean value approach to assess security risks. In Labuschagne, L. and Eloff, M., editors, 2nd annual conference of Information Security for South Africa - ISSA-2 Proceedings. South African Computer society. [Zuccato, 2002bl Zuccato, A. (2002b). Towards a systemic-holistic security management. Licenciate thesis, Karlstad Unviersity Studies. [Zuccato, 20041 Zuccato, A. (2004). Holistic security requirement engineering for electronic commerce. Computers & Security, 2311: 63 - 76.
ASSIGNMENT OF SECURITY CLEARANCES IN AN ORGANIZATION
Lech J. Janczewski, Victor Portougal Department of Management Science and Information Systems, The University of Auckland, Private Bag 92019, Auckland, New Zealand
Abstract:
The paper discusses the assignment of security clearances to employees in a security conscious organization. New approaches are suggested for solving two major problems. First, full implementation of the 'need-to-know' principle is provided by the introduction of Data Access Statements (DAS) as part of employee's job description. Second, for the problem of setting up border points between different security clearances, the paper introduces a fuzzy set model. This model helps to solve this problem, effectively connecting it with the cost of security. Finally, a method is presented for calculating security values of objects security clearances for employees when the information objects are connected to each other in a network structure.
Key words:
Information security, data security, security models, security clearances, fuzzy sets, Data Access Statement.
INTRODUCTION Managing Information Security depends on business environment, people, information technology, management styles, and time - to list the most important. An analysis of the chain of security arrangements shows a significant weak point. It is the issue of assigning security clearances to an individual. This paper presents an attempt to solve this problem by the optimisation of an information security system subject to cost constraints. As a result, an optimisation procedure that assigns formally the security clearances to all employees of an organisation has been developed. In a typical business environment this procedure is based on the position of a
52
Lech J. Jnnczewski, Victor Portozrgal
given person within the hierarchy of an organisation. The general principle is that "the higher you are within the company hierarchy the highest security clearance you must have". Such an approach clearly incurs significant problems. In the one extreme a person might have a security clearance that is too high for hislher job, which increases the total cost of the security system. The higher the security clearance, the higher the cost (for instance, of security training). On the opposite side a person with a security clearance too low for hislher job must obtain temporary authority for accessing specific documents. Such a procedure could be costly, time consuming and decrease the efficiency of operations. Portougal & Janczewski (1998) demonstrated the consequences of the described approach in complex hierarchical structures. A competing and more logical idea is to apply the "need to know" principle. Unfortunately, this principle does not give adequate guidance to the management as to how to set-up security clearances for each member of the staff. Amoroso, (1994) describes the "principle of least privilege". The recommended application is based on subdividing the information system into certain data domains. Data domains in the main contain secret or confidential information. Users have privileges (or rights to access) to perform operations for which they have a legitimate need. "Legitimate need" for a privilege is generally based on a job function (or a role). If a privilege includes access to a domain with confidential data, then the user is assigned a corresponding security clearance. It is easy to see the main flaw of this approach is that a user has access to the whole domain even if helshe might not need a major part of it. Thus the assigned security clearance may be excessive. A similar problem arises regarding the security category of an object. A particular document (domain) could be labelled "confidential" or "top secret" even if it contains a single element of confidential (top secret) information. In this paper we suggest another realisation of the "need to know" principle. Our method is based on the Data Access Statements (DAS), defined for every employee as part of their job description. DAS lists all data elements needed by an employee to perform herlhis duties effectively. Thus we shift the assignment of security clearance from the domain level to the element level. Our approach allows not only the solving of the difficult problem of defining individual security clearances. It also connects this problem to more general problems of the security of the organisation as a whole, to the problem of security cost and cost optimisation.
Assignment of Security Clearances in an Organization
DATA ACCESS STATEMENT There is a lot of attention in literature to employee specifications and job analysis. It is strange though, that the one of the most important aspects of the job analysis, which is information use, is completely out of specification. We suggest that in addition to the main content of a job description a Data Access Statement (DAS) for every employee is added. Schuler (1992) defined the following components of a job description: Job or Payroll title, Job number and job group to which the job belongs, Department andlor division where the job is located, Name of incumbent and name of job analyst, Primary function or summary of the job, Description of the major duties and responsibilities of the job, Description of the skills, knowledge and abilities, Relationship to other jobs. The job description is the best place to define the security clearance of employee through DAS. It could be, for instance, an additional "bullet point' in the above list. DAS was introduced earlier by (Portougal & Janczewski, 1998), and was defined as follows: 1. Data Access Statements (DAS) of a staff member is a vector, containing Data Access Statements Elements (DASE) as its components. 2. Each DASE defines what type of access to informationldata is allowed (read, write, delete, etc) 3. Each DASE is defined as a result of the analysis of the job description document related to the given position 4. Each DASE has a confidentiality parameter CP assigned (being an element of the organization's database it should have the same value CP, e.g. 1, if we think they are all of equal value). An example of DAS statements is presented in Table 1. At the bottom of the column the total value of information accessible is shown. We shall call it SCV - Security Clearance Value, thus tying the assignment of a security clearance to the volume of accessible information.
54
Lech J. Janczewski, Victov Povtot~gal
Any production facility has an information system. Table 1 lists all the data elements used within an organization. Every data element has an assigned confidentiality parameter (CP), which characterizes its importance from the point of view of security. For more about assigning CP's refer (Portougal & Janczewski, 1998). Table 1. Database elements listing and DAS for all en~ployeesof the production facility
(by products) costs (by materials) TOTAL (SCV) Positions Codes: A: General Manager B: Operations C: Accountant General D: Purchasing E: Sales and Marketing
1 d d d . i 1 1 9 1 1 3
d d 5
6
6
F: Production Unit N G: Account N Manager H: Raw material Store Manager I: Finished Goods Store
In this example we assume that each data element is independent, so knowledge of a particular element does not allow one to find the value of the other. In order not to overcomplicate the example we assume all CP equal to 1.
Assignment of Secuvity Clearances in an Ovganization
MODELLING SECURITY CLEARANCES The security clearance allows a person to access a certain part of a database. We can assume that the optimum security clearance is assigned strictly in accordance with the "need to know" principle. Unfortunately, the "need to know" principle assigns to every employee a specific area of the database, and generally there will be as many different areas as the number of employees. At the same time, there are always a limited (2-4) number of security clearances. Thus the assigned clearance will practically always be different from optimum, below or above that optimal point. Clearly, the probability of an information leak goes up, when the difference between the actually assigned clearance and the optimum clearance is increasing. At the same time assigning extra security clearance involves extra cost. Let us analyse the cost of assigning security clearances to particular persons in a more detailed way. There is a correlation between security of the system, numbers of security measures, and their costs, i.e. more security measures
2 more
secure system
2
more costs
Many sources, e.g.: (Frank, 1992) indicate the above correlation is not linear but has a tendency to grow exponentially. Similar situations exist in the case of assigning security clearances. The higher security clearance of an employee means a higher expenditure to the employer. The structure of costs would be somehow different from the security measures listed above. The costs like those listed below would be of significance: Examination of candidate credentials, Security training, Security equipment (especially for accessing protected zones, either physical or system), Management of the system controlling the security clearances. Again one might expect that there is a correlation of security clearances with costs: higher security clearance granted
2 higher
costs for the organization
The security clearances should be directly related to the jobs and should follow the "need to know" principle. The security clearances are designed to subdivide the employees of the organization into classes according to data access privileges, e.g. secret, confidential and general. Following the usual approach, borderlines should be drawn, defining the minimum amounts and
Lech J Janczewski, Victor Portoz~gnl
56
importance of data in use for each category. It was analyzed in the Introduction that, before our development of quantitative measures of confidentiality (CP), this subdivision was performed either by employees' position or by assigning security categories to data domains, and then using these categories for defining clearances. With the CP and SCV defined the problem becomes much easier and more logical to solve.
In our example (Figure I), let us have three security categories: general, confidential and secret. We shall define the borderline SCV between general and confidential as 4, and the borderline SCV between confidential and secret as 8. If the total SCV of information in use by an employee is less or equal to four, then this person is not required to follow special security procedures at all, and helshe would be assigned a general clearance. If the total SCV is between five and eight, then the confidential clearance should be applied, meaning that this employee is under an obligation to use and follow all the security procedures defined for this clearance. Similarly, if the SCV of data in use is more than eight, then this employee should be assigned the secret clearance. Though this procedure is simple and easy to understand, nevertheless it has two weak points: 1. This procedure implies that the security experts will be able to define the borderlines. In reality it is not so easy, and sometimes the decision about the borderlines is provided by reasons well outside the model, for example by position. 2. Under this procedure it is hard to explain why employees with SCV close to the borderline from different sides have different clearances. What is the crucial reason for an employee with SCV equal to 0.79 has a clearance confidential, but his colleague with SCV = 0.81 has secret clearance?
Assignment of Security Clearances in an Organization
57
Both points indicate an inadequacy in our security clearance modeling. Basically, the inadequacy comes from using a classical crisp set for modeling, like this used by (Pfleeger, 1997). The crisp set is defined in such a way as to dichotomise the individuals into two groups: members (those that certainly belong to the set) and not members (those that certainly do not). A sharp distinction should exist between members and non-members of the class. This is definitely not so in our case. The classes of security clearances do not exhibit this characteristic. Instead, the transition from member to non-member of one class appears gradually rather than abruptly. This is the basic concept of fuzzy sets. In the first fuzzy model we shall assume only two security clearance classes: general (set G) with no security cost and secret (set S) with a security cost A for each member of the class. The membership functions of class S are given in Figure 2. The vertical lines on Figure 2 represent the employees of the example company and the value of their membership function in the set S. General Manager and Accountant General have the value equal to 11 (A,B), Operations Manager has it equal to 911 1 (C), Purchasing Manager has it equal to 311 1 (I), etc.
Membership Function
I
G,H
F
D,E
C
A, B
SCV +
Figure 2. Membership function for the fuzzy set "secret"
If we assign to every manager the security clearance secret, then the cost of the security system will be equal to 9A (As there are 9 managerial
58
Lech J. Janczewski, Victor Portozgal
positions in the company). If this is not affordable, then some of the managers will be put into G class. This involves a risk of information leak. Let us assume that this risk is proportional to SCV (the more a person knows the higher is the risk). We shall introduce the risk factor (RF) for an employee i as:
A good estimate for the company risk factor (CRF) would be either:
CRF,, = maxi RFi, or CRF,, = Xi RFi 1 N, where N is the total number of employees.
CRF,, characterises the risk of information leak from the most informed employee. It is better for evaluation than CRF,,, when the SCV, of the employees are diverse. Sometimes both are useful. The risk factor can not be used directly for the evaluation of real security threats. It is only a coefficient in a more complex equation with unknown chances of a breach of security and losses from it. But the assumption of its proportional value to the security risk gives it a good comparative meaning. Let in our example postulate that the company has a security budget of 3A, or that it can afford to assign the secret clearance only to three employees: GM, AG and OP. The security risk factors will be:
CRF,, = (3+3+4+5+6+6+0+0+0)/11/9 = 27/99. CRF,, = 6111 If we increase the security spend to 4A (33% increase, one more person classified as S), then the CRF,, will drop to 21/99 (22% decrease), but CRF,, would not change. It is worth to think whether to increase the security spend or not in this situation. Thus, the main benefit of the CRF is the possibility to use it for comparing different assignments of security clearances. Though the two class model is too simplistic, nevertheless it shows the main problem of a security system design. The problem is that practically no organisation can afford a security system with a zero risk factor, and it is forced to look for a suitable trade-off between the cost and the risk factor We shall show that introduction of intermediate classes helps in security improvement without cost increases.
59
Assignment of Security Clearances in an Organization
Let we introduce an intermediate clearance confidential (set C). We shall assume that the security procedures designed for this clearance eliminate the risk of data leakage for all employees with SCV, no more than 4. Let the cost of these procedures be B = A/3, and the security budget as before is 3A. The possible variant of assigning clearances to employees is shown in Figure 3.
Membership Function
scv __*
Figure 3. Risk function and its cover by 3 classes G, C and S
In this variant we sacrifice the clearance S for the Operations Manager (OP), changing it to C, which incurs a security risk factor of (9 - 4)/11. It allows the provision, within the limits of our budget, two more employees with higher risk factors, PUN and ANM, with the same clearance C. This will decrease their risk factors by 411 1 each. The security risk factors will be:
This shows a significant improvement in security estimates. The next step will be to sacrifice the S clearance of either GM or AG and to provide C clearances for himher and additional two employees with higher risk factors. This will leave only 2 persons in the G class; 6 persons will be in the C class, 2 of them having a non-zero risk factor. The security risk factors for this distribution show the following improvement:
Lech J. Janczewski, Victor Portougul
CRF,, = (3+3+0+1+2+2+5+6+0)/11/9 = 22/99. CRF,, = 6/11. The first criterion has decreased, but the second shows an increase. We can choose either the previous variant of clearances distribution if we prefer the second criterion, or to go further on if we prefer the first one. Then the final logical step is to use the budget for assigning all employees a uniform clearance C. In our case this does not show further improvement. Generally, an analysis of both company risk factor functions CRF,, and CRF,,, show the best way for their optimisation, but this analysis is outside the scope of this paper.
4.
SECURITY MODELLING FOR DATABASES WITH NETWORK DATA STRUCTURES
In any of these cases some important problems were not addressed, which is commonly referred to as the 'tjigsaw puzzle" intelligence. A watchful analysis of the officially collected materials allows to obtain sometimes highly classified information. For example, close monitoring and analysis of the registration plates of military vehicles at barrack gates could detect movement of military units. The same principle may be applied to business facilities. It is estimated that 80% to 90% of the data collected by intelligence gathering organisations (both civilian and military) originate from entirely legal sources and are obtained without any security breakage. Reconstruction of classified information (without adequate security clearance) through an analysis of accessible data is based on the fact that the most of data used in business, production, services and military are logically connected. Knowledge of that connection algorithm allows one to reconstruct a relatively accurate model of the reality with the use of only few components. The main argument presented in this paper is that individual clearances should not be based on the position of an individual within the organizational hierarchy. Rather the individual clearances should be defined by the confidentiality of the documents the employees use in their everyday managerial activity. The methods for defining security clearances depend on the information structure in the organization. For a hierarchical model Portougal & Janczewski, (1998), suggested an algorithm that assigns crisp security categories. Later on they expanded (Portougal & Janczewski, 2000)
Assignment of Securiv Clearances in an Organization
61
the algorithm for the case when the security categories are treated as fuzzy intervals. The models with hierarchical data structures showed some unexpected results. Naturally, the security clearances depended on the form of the data tree. A perfect data tree, having at least two branches on each organizational level and no overlapping of data (i.e. any data unit is known to only one person on a given organizational level) would produce security clearances directly adequate to the position of the person with respect to this level. Otherwise, with real-life trees, the differences were dramatic. The specific features of the models are as follows. The set of key indicators (which need to be protected). Data structures of all key indicators. Basically, all performance indicators have a hierarchical structure and thus every key indicator can be modelled as a tree. However, because all indicators are formed from elementary data feedback, the general structure of the data flow in the company will be a network. An algorithm that assigns Confidentiality Parameter (CP) to every element works for every DAS sequentially, matching it against data network also sequentially. An experimental implementation in a company showed the following results. Before implementation of the model described above, the company had three security categories: "Secret", "Confidential" and "Internal use" defined in Table 2. Key indicators showing total production volume, sales and costs were considered "secret". The security clearances were related to the position of given employee within the organizational framework. Table 2. Structure of the security clearances
After the introduction of the algorithm calculating the real security clearance values, and the proper definition of security clearances, the structure of security clearances changed (Table 3, last column). Analysis of the information flow in the company shows that in a number of cases the
Lech J. Janczewski, Victor Portougal
62
security clearances are not matching the amount and confidentiality of information the employees are having an access to. "Finished good store" manager is perhaps the best example. By the virtue of that person's activities helshe could have a total knowledge of production and sales volumes, while this person security clearance was set-up only on the "internal use" level.
Table 3. List of individual security clearances
5.
CONCLUSION The main results of this paper may be summarized as follows: For the full and complete implementation of the 'need-to-know7principle we introduced data access statements (DAS) as part of employee's work description. Thus the access to the information is granted to every employee on the data element level as opposed to the existing practice of granting access on a domain level. We suggest changing the existing practice of assigning security categories to data base domains, and to assign instead a confidentiality parameter (CP) to every element of the data base. The data base will be characterized from the confidentiality point of view in more detail.
Assignment of Security Clearances in an Organization
63
3. We showed that current crisp models of assigning security clearances do not include cost and efficiency optimization. Instead we developed optimization models, based on h z z y sets theory. 4. As a measure of efficiency of the security system we introduced the company risk factor (CRF), which makes possible to compare different ways of security organization under a limited budget. 5 . Most of information processed and stored in a database is related to each other. These relationships may allow calculation or estimation of, sometimes quite confidential, information. Knowledge of these relationships therefore might influence significantly content of security labels attached to objects and subjects. We addressed this problem under assumption that the database has a network structure. Further research in this direction might include the development of optimization models, based on analysis of both company risk factor functions CRF,, and CRF,, and the structure of the set of feasible solutions. Another direction of research includes the development of models optimizing costs of the security system under risk constraints.
REFERENCES Amoroso, E., (1994), Fundamentals of Computer Security Technology, Prentice Hall, USA. Frank, L., (1992), EDP-Security, Elsevier Science Publishers, The Netherlands. Pfleeger, C., (1997), Security in Computing, Prentice Hall, USA. Portougal, V., Janczewski, L., (1998), Industrial Information-weight Security Models, Information Management & Computer Security, Vol. 6. No 5, Great Britain. Portougal, V. & Janczewski, L., (2000), "Need-to-know" principle and fuzzy security clearances modeling, Information Management & Computer Security, Vol. 8. No 5, Great Britain Schuler R. et all, (1992), Human Resource Management in Australia, Harper Educational, Australia.
TOOL SUPPORTED MANAGEMENT OF INFORMATION SECURITY CULTURE Application in a Private Bank Thomas Schlienger and Stephanie Teufel international institute of management in telecommtrnications (iimt), University of Fribourg, Switzerland
Abstract:
In this paper, we present a management process we have developed for an Information Security Culture. It is based theoretically on action research and practically on expert interviews and group discussions. A Decision Support System, which supports the process, allows quick survey of the existing Information Security Culture in an organization and analysis of the results, thus discovering strong and weak points. This tool recommends, based on stored measures and rules, actions to improve the weak points. It helps security officers to do their work and to improve the Information Security Culture in their organizations. The application of the process and the Decision Support System in a Private Bank is presented here and major findings are discussed.
Key words:
Information Security; Information Security Culture; Awareness; Assessment; Decision Support System.
1.
INTRODUCTION
The intensified dependence on information processing in recent years has increased the organizational risk of becoming a victim of computer abuse. T h s risk will continue to rise within the coming years. Existing technical and procedural countermeasures can be enhanced by socio-cultural measures to increase the security awareness and the security knowledge of staff within an organisation, thus improving the security level of the whole organization (Martins, Eloff 2002; Schlienger, Teufel 2002). Potential losses by cyber attacks, computer abuse and industrial espionage can be prevented. Security culture should support all activities in such a way that information security becomes a natural aspect of the daily activities of every employee. It can
66
Thomas Schlienger and Stephanie Tezfel
help to build the necessary trust between the different actors and should become part of the organizational culture, which defines how an employee sees the organization (Ulich 2001: 503). It is a collective phenomenon that grows and changes over time and can, to some extent, be influenced or even designed by the management. This paper discusses first our management process for analyzing, maintaining and changing Information Security Culture. We then present a Decision Support System that supports this management process. This tool is designed to quickly analyze the existing culture and to automatically propose measures to improve weaknesses. It also allows comparison of the Information Security Cultures between different organizations (benchmarking) or that of a Culture within the same organization over different points in time. In this instance, the management process and tool were applied in a project at a Private Bank. We discuss the settings and findings of this project and the lessons learned.
2.
MANAGEMENT OF INFORMATION SECURITY CULTURE
Information Security Culture, like organizational culture, cannot be created once and then used indefinitely without hrther action or modification. To ensure that it corresponds with the targets of an organization, culture must be maintained or modified continuously. It is a never ending process, a cycle of analysis and change. The first step is to analyze the actual Information Security Culture (diagnosis). If the culture does not fit with the organization's targets, the culture must be changed. If it fits, it should be reinforced. The necessary actions must be chosen (planning) and realized (implementation). The success of the actions taken must then be checked and learning specified (evaluation). The process is illustrated in Figure 1.
2.1
Process Description
In the following section, we give a short overview of these four management steps.
Tool Supported Management of Information Security Culture
Figure I. Information Security Culture management process
2.1.1
Diagnosis
In order for security culture to make a substantial contribution to the field of information security, it is necessary to have a set of methods for its study. Bearing in mind the difficulties in comprehending culture at all, the use of a combination of measurement tools and methods as proposed among others by (Riihli 1991; Schreyijgg 1999) seems evident. This allows verification of the results with other methods and the use of different viewpoints in interpreting them. The researcher is thus able to pick the appropriate methods, which help himher assess the security culture in hislher organization. In our research we use: Analysis of security specific documents, e.g. security policy Questionnaires with employees Interviews or questionnaires with security officers Observation, e.g. clean desk policy verification A more detailed discussion of the evaluation items and methods can be found in (Schlienger, Teufel 2003). In this paper, we concentrate only on questionnaires, as they are the instruments best suited for a tool supported assessment. We have developed a standardized questionnaire on the basis of the organizational behavior model of (Robbins 2001), see also (Martins, Eloff 2002). This divides organizational behavior into three layers: organization, group and individual, with in all twenty areas (e.g. work and technology design, communication, attitude etc.). The questionnaire has 42 questions, which are answered on a five point Likert scale from 1 (I strongly agree) to 5 (I strongly disagree).
Thomas Schlienger and Stephanie Teujel 2.1.2
Planning
The diagnosis step reveals the actual culture and its weaknesses. Depending on the target culture, specific actions must be taken to maintain or even change the culture. It is important to bear in mind that changing an existing, inappropriate culture needs more radical measures than maintaining an appropriate culture. Whereas an appropriate security culture can be maintained by an effective awareness programme, changing a culture involves the reengineering of all existing cultural measures. Clear objectives for the development of an appropriate security culture must be set. We propose using the security policy as a definition of the target security culture. It is an overarching document for all measures concerning information security and defines the basics for security behaviour, see also (von Solms, von Solms 2004). To be able to define the right cultural measures, it is also essential to know which people one wishes to influence. A widely used approach is to define three groups: IT-staff, managers and lower-level employeeslsupport staff, and to implement special measures for each group. In our research, segmentation by function (IT vs. business) or hierarchical position (managers vs. lower-level employees/support staff) revealed statistically significant differences that suggest the need to define special cultural measures for specific departments or management levels. Comparing the actual with the target security culture, one can choose the right instruments to implement the target culture. Culture cannot be decreed by regulations; more subtle actions are possible and necessary. A number of possible instruments exist to influence Information Security Culture, the most important ones are: responsibilities, internal communication (awareness campaigns), training, education and exemplary action of managers.
2.1.3
Implementation
The planned actions must now be implemented. This phase can be organized as for every other project: it is essential to define detailed activities, responsibilities and resources, the schedule and the budget. We will not go into details concerning this phase.
2.1.4
Evaluation
Evaluation is the last step in our Information Security Management process. It provides valuable information about the efficiency and effectiveness of the actions implemented. It helps to improve the actions taken, to define necessary follow-up and also to legitimate investment in
Tool Supported Management of Information Security Cultzrre
69
Information Security Culture. This is especially important in applying for the following year's budget. To highlight the changes achieved in a culture, the same instruments, in our case the same questionnaire, should be used. This questionnaire can be complemented by specific questions on the actions taken to reveal its effectiveness. Evaluation also reinforces organizational learning (Argyris, Schon 1978): 1. single loop learning ("adaptation"): the actions taken are evaluated to be improved in the future, e.g. the educational programme can be improved, knowing the strengths and weaknesses. 2. double loop learning ("change"): the evaluation also has an impact on the Information Security Culture itself. Undertaking an evaluation affirms the importance of information security. Employees pay attention to this topic once again. 3. deutero learning ("learn how to learn"): evaluation also helps to improve the evaluation process itself. Experiences from carrying out an evaluation will change and improve further evaluations of Information Security Culture.
2.2
Scientific and Practical Foundation
The proposed management cycle has its roots in a scientific research method and in practical exchange of ideas and experience. The scientific root lies in action research. It is an established research method, used in social sciences since the mid-twentieth century, and it gained much interest in information systems research toward the end of the 1990s (Baskerville 1999; Bjorck 200 1; O'Brien 2001). Action researchers assume that complex social systems, like an organization and its information systems, cannot be reduced to components for meaningful study. They can be best studied by introducing changes in social processes and then observing the effects of these changes. This involves five steps: diagnosis, action planning, action taking, evaluating and specifying learning. In our management process we use the same steps, but have integrated the steps evaluation and learning, since learning normally accompanies all steps but is most important in the evaluation. The process has also been checked concerning practicability during discussions within the Working Group "Information Security Culture" of the FGSec (information security society Switzerland). The group consists of nine researchers, security officers and security consultants with experience in socio-cultural measures in information security. The process has been proved practical in this expert round and is now the recommended procedure of managing Information Security Culture.
Thomas Schlienger and Stephanie Tezfel
A DECISION SUPPORT SYSTEM FOR THE MANAGEMENT OF INFORMATION SECURITY CULTURE The complexity and the interdependence of information systems and of information security management are steadily growing. Providing tool support to security officers helps them to cope with complex decision making under time pressure. Computer based tools impart knowledge, which can provide the necessary foundation for decisions. Information systems that help to analyze the existing culture and to propose possible actions for improving weaknesses can be a major asset for the information security officer. The problem field of Information Security Culture management is either not structured, or, at the least, badly structured, and therefore not suited to automated decision taking. It is therefore not possible to build complete decision trees with all actions and consequences. Although a tool for Information Security Culture management is therefore not a Decision Silpport System in its narrow sense, it is one in a broad sense. Decision Support Systems are not decision automatons, but they can help the user to prepare for decision making by surveying, filtering, completing and aggregating information. Decision Support Systems help to (Hattenschwiler, Gachet 2003): make decisions faster, improve the quality of decisions, reach the goals with fewer resources and make more rationale, robust and replicable decisions. The tool supports in its first stage, see also (Kneger 2004), the management of Information Security Culture in the steps of diagnosis, planning and evaluation. The architecture is illustrated in Figure 2. It surveys the Information Security Culture with two questionnaires, one for all staff (survey component A) and one for the security officer (survey component B). It automatically analyzes statistically the survey results, discovers weaknesses in the culture and proposes actions to improve weak points (reporting component). Thus the security officer quickly obtains status information and knowledge about the Information Security Culture of hislher organization. He/she can then choose actions from the proposition list and implement them. The survey component can also be used to carry out the evaluation. An administration component allows administrators and researchers to manage surveys, questionnaires, best practices and users. In a second stage further functions are planned. It is planned to support benchmarking survey results relating to one company with those of other companies and to improve the planning stage.
Tool Supported Management of Information Security Culture
R
Survev comoonent A questionnlng the level of lnformation Secunty Culture
deimng surveys, questlonnalres, best practlces and users
1
-
I
I
Data
analyslng the level of miormation security culture and recommending socio-cultural measures based on the results of the two questionnaires and the stored
ev cornDonent quesiionning the Implemented lnformation Security Culture measures
e n 2 Dlagnosss 8 Planning
Infomlat~onSecunty Officer
Figure 2. Architecture of the Information Security Culture Decision Support System
The tool has been developed on the web technology html and ASP.NET; results are stored in the free runtime version of Microsoft SQL server, and the analysis and reporting is undertaken with Crystal Reports. The web based clientlserver technology allows easy distribution of the application.
4.
DEMONSTRATION AND CASE STUDY: APPLICATION TO A PRIVATE BANK
The tool was applied in a Private Bank in November 2004. Whereas the bank has employees worldwide, most of the staff works in Switzerland. The company has already carried out an information security awareness programme this year and is now starting to analyze its Information Security Culture in a systematic way. The project was supported by the top-level management and was signed by the CEO, CFO, COO, Head of Enterprise Risk and Head of Information Security. The project was thus backed by the highest hierarchical levels.
Thomas Schlienger and Stephanie Tezfel
4.1
Diagnosis
We first discuss the survey setting with the online questionnaires. Then we present the reporting function of our Decision Support System, which displays the results of the survey but also findings and propositions to improve weak points in the Information Security Culture. The reporting component therefore covers the diagnosis and planning steps.
4.1.1
Survey
A questionnaire to survey the culture, in English and German, was prepared on the server of our Institute. Internet connection was secured with SSL. We used the standardized questionnaire, but dropped two questions that are not relevant for the organization and added six new questions. Although we always recommend and propose using the standardized questionnaire, it is frequently necessary to adapt it to the specific needs of an organization. Comparability between organizations is still given on the area level, where several questions concerning a specific area are aggregated. The employees were invited by an email from the Head of Information Security to fill out the questionnaire. They also received the URL to the questionnaire with an anonymous company login and password. On the questionnaire, and prior to answering the questions, each employee first has to authenticate him-/herself and also to indicate hislher position (3 levels), hislher function (7 functions) and hisher region (4 regions). The questionnaire then consists of 46 mandatory questions and a section for optional comments. Cookies are set to anticipate multiple answers from the same account. The Head of Information Security answered the security officer's questionnaire, which surveys the measures already taken to create and support an appropriate Information Security Culture. The database currently stores 87 answers from other security officers of Swiss organizations. Comparing an organisation's results with those of other Swiss organizations gives valuable information about the maturity of the Information Security Culture from the security officer's viewpoint. Approximately 19% of all staff in Switzerland and Liechtenstein responded to the survey. The confidence interval of 7.36 at a confidence level of 95% provides enough accuracy for a statistical analysis of this group. However the feedback of only 0% to 5.5% from the other three regions gives us not enough data for a statistical analysis of these branches. One main problem of the two branches in Asia was the poor Internet access. In spite of that, the general problem of all three branches apparently is the lack of interest in information security.
Tool Supported Management of Information Security Culture 4.1.2
Reporting
The reporting section is designed for the security officer and the senior management. It shows the answers on different aggregation layers: Overview: all questions aggregated, to give an overall picture (see Figure 3). Level: the questions concerning Organization, Group and Individual are aggregated to give level information. Area: the questions concerning an area are aggregated to give a more detailed picture of the areas. This analysis is called the Information Security Culture Radar and gives a wide range of information at a glance. It is the favourite aggregation level for benchmarking (see Figure 4). Single question: the results of a single question give the most detailed information. The results can be filtered according to position, department and region to receive more details and to be able to define specific actions for target group. The report can be exported to different formats (PDF, Word and Html). Figure 3 shows the navigation of the reporting component and the entry screen with the overview. On the left side is a navigation tree, where the user can jump directly to the different levels, areas or questions. On the top are the filters and also the export function. The second top line offers
-
. ;Hman Rersoincer Nanagemert 3
O r g m h o n a l C~hlrc O r g m a b o n d Ctrachre
r @OW +
I 1
umt INFORMATIONSECURITY CULTURE TOOLBOX
Tndndwm
all Postlons
all Oepaitements
allRegions
Number ofsuweyed persons 1 4 4
Overall
Figtrre 3. Overall results and Navigation
Thomas Schlienger and Stephanie Tezfel
74
possibilities for searching and navigating through the pages. The overall result (Figure 3) of 73% agreement is good. In discussion with the working group, we set the threshold for a satisfactory Information Security Culture at 60% agreement for each question. This number can be adjusted by the organisation for each question if wanted. In our survey the CSO agreed to the recommended threshold. Although the overall result is good, the analysis of areas and individual questions reveals improvement points. The Information Security Culture Radar (Figure 4) shows the results on the area aggregation layer. It shows at once where the strengths and weaknesses are. Weaknesses are on the areas Human Resources Management, Organisational Culture and Problem Management. Actions should focus on improving the worst areas and maintaining the good areas at the same level. Information Security Culture Radar
-\
MoOuat~on
Human R e a u u m e s Management
Perception
Figure 4. Area results: the Information Security Culture Radar
4.2
Planning
The reporting function also covers some of the planning phase. Its function is to automatically discover weaknesses and to propose improvement actions, based on rules and actions stored in the database. These actions are based on the results of the expert group. If a single question receives less than the agreement threshold, improvement actions are proposed. Filtering on position, department and region allows checlung on whether the actions have to be implemented for everybody or for specific target groups. The Decision Support System helps the security officer to quickly spot weaknesses and to retrieve possible measures. Depending on the specific
Tool Supported Management of Information Security Culture
75
situation and specific needs, he or she can then choose preferred actions and implement them in his or her organization. Figure 5 shows the result of the question "I receive training (courses, presentations, self-study etc.) in security applications and procedures I need for my work." The threshold is not reached, so the system reveals a problem and proposes improvement actions. In this case, employees do not receive the necessary information security training. The proposed measures focus on general information security education and specialised training in security procedures and tools.
Future steps: Implementation and Evaluation
4.3
The bank is going to implement the most promising improvement measures during 2005. It is also planned to evaluate the actions taken in an evaluation survey at the end of 2005 or beginning of 2006. The evaluation step is necessary to a systematic management of Information Security Culture. It gives valuable information about the effectiveness and efficiency of the implemented measures and supports organizational learning. We expect valuable improvement of information security in this bank and hope that systematically managing Information Security Culture will become a part of its organizational culture.
I
Ich w r d e ,n den S~cherhe~tsanwndungen und - prozedurengeschuit (Kurs, Veranstaflung, Selbst- Training ... I receive framing (courses, presentations, sell- stu* etc . In securlly appiications andprocedures I need for my..
07
nmn&
ape
nevtd
disagree
agree
nmngly disagree
n= 138
Employees must understand, why information security 1s important for the organlzatlon and how they can operate securely They must know, how to use the securitffunctlons wllhln the appltcatlons and i n their own work process Train~ngIS one ofthe foundation elements to create securlty awareness. Flnd[nEE
Agreenient to th:s question :s 33.09 Th!s ?o:!?t skouid be IUPROS'ED
Pronosltion(s1
.
TRAINING, EDUCATION Glve education about lnformatlon securltyln general and why ~t1s Important for your organlzatlon Courses workshops presentatlons, seittralnlng, computer based tralnlng, movles etc are sulted G~vetraining to the employees how to use the speclal security sotflare and procedures Courses, presentatlons, self-tralnlng, computer based tramng etc are sulted
.
Figure 5. Question results with problem description and improvement propositions
76
Thomas Schlienger and Stephanie Tezfel
CONCLUSIONS In our survey on Information Security Culture in Swiss Organizations (Schlienger, Rues Rizza 2004) we discovered that most of the organizations rate the socio-cultural dimension of information security as very important. However, they encounter problems in proving its value in terms of improvement in information security and return on investment. The proposed method and tool helps to bridge this gap by allowing organizations to systematically analyze their information security culture, to quickly identify weaknesses and improvement actions and to prove progress in Information Security Culture. The application in a real world project shows its usefulness and the experience shows that we have reached our goals. In future development we will extend the functions of the Decision Support System to provide benchmarking and better support in the planning phase.
ACKNOWLEDGMENTS We thank all members of the Working Group "Informationssicherheitskultur" (Information Security Culture) of the FGSec (information security society Switzerland) for their valuable discussions and cooperation. We especially thank Stefan Burau for giving us the opportunity to apply the management process and the Decision Support System in practice and to gain valuable experience with it. The successful implementation of the first prototype of our Decision Support System is thanks to Manuel Krieger.
REPERENCES Argyris, C. and D. A. Schon (1978). Organizational learning. Reading, Mass., AddisonWesley Pub. Co. Baskerville, R. L. (1999). Investigating Information Systems with Action research, Communications of the Association for Information Systems. Volume 2, Article 19. httu:i!www.cis.esu.edui-rbaskerv!CATS 2 19, 11.3.2004. Bjorck, F. (2001). Security Scandinavian Style: Interpreting the Practice of Managing Information Security in Organisations. Licentiate Thesis. Department of Comuuter and Systems Sciences. Stockholm, Stockholm University & Royal Institute of Technology. Hattenschwiler, P. and A. Gachet (2003). Skriptum in Decision Support Systems Theory I. University of Fribourg. Krieger, M. (2004). Ein Decision Support System fur das Management der Informationssicherheitskultur. Masterarbeit. Lehrstuhl fur Manaeement der Informations- und Kommunikationstechnoloaie, Universitat Freiburg i.Ue.
Martins, A. and J. H. P. Eloff (2002). Information Security Culture. In: M. A. Ghonaimy, M. T. El-Hadidi and H. K. Aslan, Eds. Security in the information society: visions and perspectives. IFIP TC11 International Conference on Information Security (Sec2002), Cairo, Egypt, Kluwer Academic Publishers: 203-2 14. O'Brien, R. (2001). Um exame da abordagem metodologica da pesquisa aq8o [An Overview of the Methodological Approach of Action Research]. In: R. Richardson, Ed. Teoria e Pratica da Pesquisa Aclo rTheorv and Practice of Action Researchl. Jo8o Pessoa, Brazil, Universidade Federal da Paraiba. English version: http://www.web.cal-robrien/uauers/arfinal.html (1 1.3.2004). Robbins, S. P. (2001). Organizational Behavior. New Jersey, Prentice Hall. Ruhli, E. (1991). Unternehmungskultur - Konzepte und Methoden. In: E. Riihli and A. Keller, Eds. Kulturmanagement in schweizerischen Industrieuntemehmunnen. Bern und Stuttgart, Paul Haupt Verlag: 11-49. Schlienger, T. and R. Rues Rizza (2004). Befragung zur Informationssicherheitskultur in CH Organisationen, Arbeitsgruppe "Informationssicherheitskultur" der FGSec (information security society switzerland). www.fnsec.ch/adisklMarktbefrarz~n~2u~~df, 9.1 1.2004 Schlienger, T. and S. Teufel (2002). Information Security Culture - The Socio-Cultural Dimension in Information Security Management. In: M. A. Ghonaimy, M. T. ElHadidi and H. K. Aslan, Eds. Security in the inforn~ationsociety: visions and perspectives. IFIP TC11 International Conference on Information Security (Sec2002), Cairo, Egypt, Kluwer Academic Publishers: 191-201. Schlienger, T. and S. Teufel (2003). Analyzing Information Security Culture: Increasing Trust by an Appropriate Information Security Culture. Proceedings of the International Workshop on Trust and Privacy in Digital Business (TrustBust03) in conjunction with 14th International Conference on Database and Expert Systems Applications (DEXA 2003), September 1-5 2003, Prague, Czech Republic, IEEE Computer Society. Schreyogg, G. (1 999). Organisation: Grundlagen moderner Organisationsgestaltung. Wiesbaden, Gabler Verlag. Ulich, E. (2001). Arbeitspsychologie. Zurich, vdf, Hochschulverlag an der ETH Zurich. s Security von Solms, R. and B. von Solms (2004). "From policies to culture." C o m ~ u t e r & 23(2004): 275-279.
ERPSEC - A REFERENCE FRAMEWORK TO ENHANCE SECURITY IN ERP SYSTEMS
Prof. S.H. von Solms, M.P. Hertenberger Rand Afrikaans University
Abstract:
This paper proposes a method of integrating the concept of information ownership in an Enterprise Resource Planning (ERP) system for enhanced security. In addition to providing enhanced security, the reference framework ERPSEC developed for this study provides better manageability and eases implementation of security within ERP software packages. The results of this study indicate that central administration, control and management of security within the ERP systems under investigation for this study weaken security. It was concluded that central administration of security should be replaced by a model that distributes the responsibility for security to so-called information owners. Such individuals hold the responsibility for processes and profitability within an organization. Thus, they are best suited to decide who has access to their data and how their data may be used. Information ownership, coupled with tight controls can significantly enhance information security within an ERP system.
Keywords:
Database security, information flow
1.
security
policy,
misuse
detection,
authentication,
INTRODUCTION
The concept of information ownership has been around for some time. However, its full benefit has never been harnessed in the ERP software space5. In ERP software systems, security is critically important. ERP systems are fairly complex and integrate functions and data across an entire enterprise. The fact that human resources data and finmcial information is
80
Pro$ S.H. von Solrns, M P . Hertenbergev
integrated with production planning and sales data should illustrate the requirement for stringent security subsystems. Additionally, ERP systems in use by an organization contain critical business data. Hence, it is essential that such information be protected from unauthorized access. Unauthorized access to the data within the ERP system's database must be prevented, especially since a large percentage of fraud takes place within the organization4. In the study completed by the authors', various ERP software products where evaluated to determine how security is implemented. In all cases, the security subsystem forces centralized control by one or more central security administrators. It is the view of the authors that this approach, though practical and widely used, weakens security. In the study, a framework for implementing the information ownership approach to strengthen and enhance security within ERP software packages is proposed. This paper briefly summarizes some of the findings.
2.
THE TRADITIONAL APPROACH AND ITS PROBLEMS
To provide the reader with sufficient information on the traditional way of implementing security within an ERP environment, the following brief discussion is provided.
ERP implementation projects require many skilled resources from various disciplines. To ensure adequate knowledge transfer, staff members from the organization for which the ERP system is being configured are included in the project team. The technical skills required to implement and configure the software are quite different to the business and process knowledge that is required to change the workings of the software components to support the business processes and add value to the organization. Technical skills are generally required to assist in the implementation and realization of a security policy. Briefly stated, the reason for this is due the fact that: - security is generally considered an administrative, and therefore a technical role - the implementation of an adequate security infrastructure requires specific knowledge relating to the ERP system's technical architecture. In all the ERP systems reviewed, detailed knowledge of system objects and their use and function is a prerequisite.
ERPSEC - A Reference Framework to Enhance Security in ERP ... -
the ERP systems available provide only a centralized way of implementing and maintaining security objects and settings
2.1
Specialization by discipline and resources
Hence, the traditional approach to the implementation of security within ERP systems is based on a centralized approach. There is nothing physically wrong with this approach. However, the centralized approach provided by ERP software packages does not allow the organization to expand its security infrastructure to comply with information ownership principles. To illustrate this in a different way, consider that ERP software systems contain a huge variety of hnctions and configuration possibilities. To understand all facets of a single system in detail is virtually impossible. Hence, specialization of skills takes place almost naturally. Business-oriented users are more concerned with the real-world application of the ERP software and how the configuration can be changed to mirror the processes within the organization. In contrast, technical experts and administrators delve deeply into the architecture and structure of the system; they are more concerned with how the system has been built. The knowledge divide becomes apparent when a business process owner requests the configuration of a security object from a technical security administrator. As the focus of both parties is different, understanding from both sides may be lacking.
2.2
Translation of business requirements into technical terms
The requirements of the business process owner for increased security in order to protect the organization from fraud, for example, must be translated into a technical specification by the security administrator. Though this process may be fairly simple in some cases, more complex requirements may not be easy to implement technically. An example of a simple security requirement may be the restriction of permitting only certain users print to a certain printer in the organization. The requirement can be fairly easily understood and translated into the technical format required by the system. Similarly, testing such an access restriction is fairly simple and does not provide too many possibilities for failing. A far more complex requirement may include access restrictions to data for certain material types, cost centers and locations. In a large organization many material types and locations may be present. Ensuring that all users have been allocated the correct security objects becomes far less trivial to implement and configure than the preceding example involving only a single printer.
Pro$ S.H. von Sol~ns,M P . Hertenberger
82
Possible introduction of errors and hence weakened security
2.3
To restate the above concept, the assumption that a central system or security administrator has the ability to understand all nuances and specifics of each functional area is often incorrect. Instead, the security administrator must gather information from each area of the business. Once all these details have been gathered, the security administrator is able to translate the requirements of each business area into the appropriate roles and profiles within the ERP system. In many cases, the security administrator has to select objects manually to create the appropriate access authorization for the user. It should be clear that such a process is often completed with a number of errors and omissions.
The security administrators as a bottleneck
2.4
The security administrator in an ERP environment must contend with numerous business areas and functional areas. These include sales, finance, human resources and so on. Adding the various organizational layers on top of ths, together with various stakeholders the business may have to support, creates an environment in which the centralized security administrator becomes a central bottleneck. Figure 1 illustrates this more vividly:
(
Business
,
)a ,
Business
administrator Business
Figure 1. Centralized security within an ERP environment
Figure 1 indicates one of the main problems with the implementation of security within an ERP environment, namely that of creating a bottleneck by
ERPSEC - A Reference Framework to Enhance Security in ERP ...
83
having to route all requests for change through one or more administrators who possess the technical knowledge on how to deal with the request.
3.
THE APPROACH USING INFORMATION OWNERSHIP
The authors are of the opinion that the support of information ownership can assist in enhancing the configuration of security objects in ERP software environments8. In addition, the approach using information ownership provides various additional benefits that are useful to organizations implementing ERP software packages to support their business processes. To this end, the ERPSEC framework has been developed and will be briefly discussed during the remainder of this paper. Prior to the discussion relating to the ERPSEC framework, it should be clear why the authors consider the approach using information ownership to be beneficial.
3.1
Reduction of complexity
Within traditional ERP environments, the centralized approach to implementing access control and access restrictions enables one or more security administrators to create and maintain profiles, roles and user master records. As has been mentioned above, this approach suffers from a number of problems, most notably that the security administrator cannot and usually does not understand the complexities of the actual business processes within the organization and how these have been mapped to the functionality of the selected ERP software package. To combat this problem and to promote more rigid and adequate security within an ERP environment, it is necessary to deal with complexity within the system as a whole. The provision of an integration layer to reduce complexity is a definite requirement. Such an integration and simplification layer is not available in any of the currently available ERP software packages. The ERPSEC framework proposes an integration layer to simplify the creation of ERP security objects. Figure 2 illustrates the integration layer and should be compared to Figure 1 above.
Pro$ S.H. von Solms, M.P. Hertenberger
Figure 2. Providing an integration layer to support information ownership
As an aside, the addition of a suitable integration layer that has the ability to translate and present technical security objects to non-technical users makes the decentralization of security configuration a distinct possibility. This may not always be recommended, but goes a long way in supporting segregation of duties issues and need-to-know principles in certain organizations. Further comment regarding this will be made once the ERPSEC framework has been discussed in more detail.
3.2
Simplification
The sudden popularity of ERP software packages stemmed primarily from their ability to integrate all data within the organization, to deliver realtime results and reporting and to make specific functionality available to the user at the desktop level. In stark contrast to the adaptability and flexibility of being able to configure the ERP software package to the needs of the business, the configuration of security related objects is completed by technical staff. Mention has already been made of the complexity of ERP software packages. This complexity is necessary for the software package to be adaptable to different industries and legal requirements. The ERP software packages investigated during the course of this study provide full support for the configuration of the software to adapt it to support various business processes. Similar functionality for the configuration of security objects is missing. In fact, all security-related objezts are generally grouped
ERPSEC - A Reference Framework to Enhance Security in ERP.. .
85
together and are not easily distinguished from one another. The ability to document the necessary access restrictions and security objects is hampered by very technical naming conventions. In ERP systems targeted at organizations with a smaller user population, the configuration of the security subsystem is often fairly trivial, offering the security administrator very little flexibility. The ERPSEC framework attempts to simplify the creation and maintenance of security related objects within an ERP environment.
WHY INFORMATION OWNERSHIP? To enhance the concept of information ownership, the concept of an information owner must first be explained. The concept of permitting individuals within the business to manage and maintain their own information security is termed information ownership. Information owners are individuals in charge of a certain business area within the organization. Generally, these individuals are already in charge of a division, such as finance or sales, for example. In other words, these individuals are stakeholders within the business and carry some form of responsibility. It is the goal of the information ownership approach within the ERPSEC framework to provide the tools to individuals who are held liable or responsible for certain actions taking place within the business. If these individuals are not provided with the tools to support their decision-making process and the ability to ensure that their data is safe, they cannot be held responsible for anything that occurs within their sphere of responsibility. This concept aligns closely with that of segregation of duties. One definition2 states that segregation of duties is a method of working whereby tasks are apportioned between different members of staff in order to reduce the scope for error and fraud. Prior to the ERPSEC framework being discussed, some advantages of the information ownership approach are listed here: - Technical security administrators are experts at maintaining technical security objects, but often lack the necessary knowledge relating to the impact these objects have when allocated to the wrong user. Information owners are aware of their business area and know the impact of incorrect allocation of one or more security objects - Technical security administrators are generally not aware of the staff members in various organizational units. Therefore, the creation of roles and allocation of security objects is done based purely on feedback and information received from the relevant organizational unit or division. In
Prof S.H. von Solwn, M P . Hertenbergev contrast, information owners are focused on their business area, know their staff and can make informed decisions based on their capabilities and possible weaknesses The ability to compartmentalize security objects based on their applicability to various sections of the business can radically reduce the time and effort required to implement and configure the ERP security subsystem. As each information owner can take care of his own section of the business, this permits the security administrators to take on a role that examines security in more detail across the enterprise. The integration layer provided by the ERPSEC framework supports this compartmentalization. Information ownership goes a long way to promote and control segregation of duties issues and improve corporate governance. Due to a large number of legislative requirements, this is a very important topic for organizations at present. At present, very little support is provided by existing ERP software products to assist organizations in dealing with these complexities.
THE ERPSEC REFERENCE FRAMEWORK The ERPSEC reference framework has one primary aim, namely to enhance and increased the security and access control within an ERP system. Existing ERP system already contain a centralized security subsystem. Hence, retrofitting the ERPSEC framework to an existing product may not be an easy task. The definition of ERPSEC in the study provides an objectoriented definition that should ease a possible physical implementation sometime in the future. In addition to enhancing security within an ERP system, ERPSEC will attempt to cater for the following: - a reduction in complexity of the security configuration; - the ability to increase responsibility and accountability within the organization; - a faster implementation time by providing decentralized access to security objects; - to improve the quality of the security configuration as a whole; These goals can be realized by considering the current state of security subsystems in existing ERP software packages. A brief review is provided below.
ERPSEC - A Reference Framework to Enhance Security in ERP ...
5.1
Traditional ERP security subsystems
The discussion presented in this paper provides the most basic details 1 regarding the ERPSEC framework. The complete study by contains a detailed description including object and table definitions for the creation of the framework in "real-life".
A mention of the centralized nature of the security subsystems of existing ERP software products has already been made. In the model employed by these products, a single administrator modifies and maintains the security objects for all users, regardless of their place within the organization. This is depicted in Figure 3. User 1
User 2
User 3
[A,B,Cl
[BE1 A
[A,C,Dl
Allocation and
Allocation and revocation
w Security administrator
t
I
I
Profile. role, user master management
Security objects in ERP system
I
Figure 3. Centralized security within an ERP environment
A simple solution to include the concept of information ownership for purposes of the ERPSEC framework is to define individual information owners. From the preceding discussion of information ownership it should be clear that information ownership implies a form of decentralization. The decentralization is such that individual stakeholders become responsible for groups of users within the organization.
5.2
Information owners
The information owner is an important part in the ERPSEC framework. Not only does the information owner know what access is required in order i'or the department or organizational unit to function, but also has an in-depth
88
Prof: S.H. von Solms, M P . Hertenbevger
knowledge of the jobs and tasks performed within that department. Hence, the translation of a particular task to its security and access restriction requirements within the ERP system is far simpler to determine. A further advantage is that the requirements do not have to be communicated to a third party, such as the central security administrator. The information owner thus plays the role of a decentralized security administrator, albeit only for the area of the business the information owner belongs to. For this to be possible, the ERPSEC framework must cater for some additional requirements. From the preceding discussion, it was made clear that the translation of access restrictions and security requirements was a major factor that inhibited and decreased security within a traditional ERP system. The requirement of an information owner within the ERPSEC framework cancels this complication, but does not fully solve all problems. To be useful, the ERPSEC framework must provide some way of allowing security objects to be configured without the need for the detailed technical understanding of the system that security administrators generally have.
Dealing with technical complexity The previous section has dealt briefly with the requirement the ERPSEC framework has for dedicated information owners in the organization. In order to permit these information owners to be able to create and maintain their own security objects, a high level of abstraction is required. Abstraction of the technical details regarding the configuration and maintenance of security is an absolute necessity when placing such responsibilities with the information owners. Abstraction can be achieved in the proposed ERPSEC framework. Instead of relying on a central security administrator who must know all technical details to create and maintain security objects, ERPSEC introduces an additional layer in the security subsystem that allows security objects to be configured and maintained in a very simple yet powerful fashion. It should be clear that retrofitting existing ERP software packages with such an additional software layer may not be practical. However, future versions of current ERP software packages could easily incorporate such an abstraction layer to promote and support the concept of information ownership. Figure 4 below depicts the additional abstraction layer. The abstraction layer can also be considered a simple interface layer. The layer has the responsibility of translating the input of the non-technical information owner into technical object names and function codes. In effect, the interface translates technically detailed security objects and presents them to i he information
ERPSEC - A Reference Framework to Enhance Security in ERP ...
89
owner in a very simplistic fashion. Ideally, the interface for the information owner should be a point-and-click environment in which allocation of security objects and settings can be made quickly and easily. A technical implementation of such an interface is beyond the scope of this paper. A description may be found in the full study relating to ERPSEC.
User 2 -
User 1 [A,B,Cl
User 3 [A,C,Dl
fl ,/' ,/'
,/.
.'
:'F~II access to all objects
Information owner l
,
lnformation owner 2
administrator Protile and role management Profile, role, user master management
I
Security objects in ERP system
I I
Figure 4. Decentralized security within an ERP environment
Though the inclusion of an interface in the ERF'SEC framework allows the concept of information ownership to be supported more fully, additional requirements still exist. Most importantly, ERPSEC must validate and handle information owners in a slightly different way to ordinary users of the system. In addition, the interface for the information owner should be restrictive enough to ensure that only appropriate security objects for that information area can be configured and maintained.
5.4
Validating information owners
As mentioned in the section above, validation of information owners is important to ensure that access restrictions can be defined. The ERPSEC framework does not require too many special mechanisms to validate information owners. An information owner within the ERPSEC framework is simply another user of the system. The crucial difference is that an information owner has some additional access rights that an ordinary user would not have.
Pro$ S.H. von Solms, M P . Hertenberger
90
ERPSEC requires information owners to have special security settings added to their user master record that identifies them as information owners. In addition, the information they are responsible for is also identified, as well as the users they should be permitted to administer. This solves two problems, namely the ability of information owners to be able to configure and maintain security objects within the system, and the restriction of the information owner to being able to operate only within a set information area of the organization. Technically, ERPSEC requires information areas to be defined. In the simplest sense, an information area is a portion of the ERP system that corresponds to an area of the real-world organization. Examples of information areas are manufacturing, shipping and financials. Depending on the size of the organization, more information areas may exist; as an example, an organization with a global presence may have manufacturing capacity in various countries. It is unlikely that a single individual would be able to perform the task of information owner for the all manufacturing divisions worldwide. Hence, information areas may be created for each manufacturing location. Regardless what the information areas are deemed to be, ERPSEC associates the information areas with relevant users in that location or information area. The assigned information owner is the only individual other than the security administrator who is able to maintain and configure access restrictions for those users. The assignment of users to information areas and the creation of information areas themselves are tasks that can be completed by the security administrator. This task is not technically complex and does not involve detailed knowledge of business Information Access to B and C only
,yV ,/'
/'
k"
./'
administrator Full access to objects
-
Yr
Allocation of users and objects +,,-,. -..-'F Access to D and E only Interface layer
V
Security objects in ERP system
Figure 5. ERPSEC compartm-ntalizes users and information areas
ERPSEC - A Reference Framework to Enhance Secuvit?/ in ERP ...
91
processes. This information can be gleaned from the organization's structure. Figure 5 attempts to represent the restricted access of the information owners. Note that the interface layer is responsible for ensure that the access to all security objects takes place in a compartmentalized fashion. In technical terms, the security subsystem may contain a number of tables that list all information owners with their associated information areas. A second table contains the information owner and allocated system users. The ERPSEC framework performs numerous checks whenever access to a security object is required by any user. In the case of an information user, ERPSEC verifies that the user in question is identified as an information owner. Once this check has successfully been completed, ERPSEC queries the table containing the information areas for that information owner. Access is not permitted to any object that is not within the list permitted for that user At a higher level, ERPSEC ensures that no information area is accessible by more than one information owner. This ensures concurrency control and integrity.
5.5
Maintaining integrity
The concept of integrity has been briefly mentioned above. Integrity is a very important concept that has to be adhered to. As has been discussed, ERPSEC changes the traditional centralized security model to a decentralized one. In this decentralized approach, more than one user is able to modify security settings for ordinary system users. In effect, ERPSEC proposes multiple security administrators with one significant difference: each information owner is restricted to a very narrow set of users and security objects that may be configured and maintained. Integrity is maintained within the ERPSEC framework by controlling the allocation of information areas to information owners. As discussed previously, it is very important that each information area be allocated to a single information owner. The structure of ERPSEC ensures this by providing a list of available information areas that have been configured, and by permitting the allocation of each one to only a single information area. If required, a single physical user could be the information owner for more than one information area. This is a matter of preference and does not compromise the operation of ERPSEC. However, the combination of information areas for a single information owner reverts back to the traditional centralized approach with most of its inherent problems. For this reason, a single information owner for each information area is recommended.
92
Pro$ S.H. von Solms, M P. Hertenberger
The allocation of information areas to individual information areas is performed by a security administrator. Once this has been completed, security objects within the ERP system that belong to that information area have to be allocated to that information area. This is not a trivial exercise and must be performed by the information owners.
5.6
Extending information areas to include security objects
Figure 3 briefly introduced the notion of allocating security objects to individual information owners. To facilitate the transfer of functionality to ordinary users within the system, the information owner must be able to allocate physical security objects to users. The concept of allocating such security objects is similar to the allocation of information areas to information owners. In the case of security objects, the organization determines which functional blocks within the ERP system belong to which information area. As has been determined in the study of existing ERP systems, a large number of function or menu codes are present in an ERP system. The ERPSEC framework assumes that all functions within an ERP system can be represented by function codes. In technical terms, a function code can be a mellu item, shortcut or text entry that is linked to a particular program or functionality within the software system. Once the user selects a menu item or enters the function code, that program or functionality is executed. In this way, the user is able to perform tasks such as the entry of an order or the creation of an invoice. To provide information owners with the ability to distribute the required functionality to the users within their information area, the information owner must be able to allocate function codes to relevant users in the system. It is logical to assume that function codes can be grouped to form segments of basic functionality within an ERP system. This fact is supported by the study of existing ERP systems: groups of function codes represent functionality within a particular module of the ERP system. In this way, all material management functions are associated with a particular group of function codes, for example. Hence, the allocation of function codes to individual information areas and hence to information owners is not an impossible task. In the ERPSEC framework, the information owners determine which function codes belong to their information area. There may be cases where the ownership of a particular function code cannot be determined precisely. In this case, the organization should allocate that function code to the most
ERPSEC - A Reference Framework to Enhance Security in ERP ...
93
likely information area. The result of this exercise within the ERPSEC framework is an additional data structure within the security subsystem that contains all function codes that have been allocated to a particular information owner. By employing the integrity and concurrency rules discussed earlier, only one information owner is able to allocate any particular function code. This has important consequences for the tightening and enhancing of security within the ERP system.
5.7
Enhancing security through ERPSEC
The operation of the ERPSEC framework has been briefly discussed in the above sections. The allocation of information areas to information owners, and the allocation of particular function codes to these information areas enhances security automatically. The reason for this is the fact that only the stakeholders or owners of the information are permitted to allocate access to it. This has important consequences for the overall security of the ERP system: as the information owner is responsible for the performance of his business unit, restricting access to only those users in the organization that require access is sensible. In contrast to the traditional centralized approach, the approach of allocating access at the information area level adds an extra layer of trust and security. As the information owner is aware of the users to whom certain function codes are being allocated, the allocation of the function codes takes place in a more secure environment. In contrast, a centralized security administrator is not always fully aware of all users within the organization and cannot determine why a certain function code may have to be allocated.
5.8
Support for segregation of duties
The fact that the information ownership approach increases support for segregation of duties has been mentioned briefly. Segregation of duties is seen to be one of the most important aspects to prevent fraud and heighten security7.1t is important to note that this requirement is becoming a legislative requirement for many organizations to adhere to. Legislation at present mandates accountability. The ERPSEC framework assists by providing a non-technical platform for stakeholders to configure and define what security is required within their area. This in turn requires the stakeholder or information owner to accept the responsibility for the configuration and content of the resulting security object. Though it has to be stated that the ERPSEC framework
Pro$ S.H. von Solms, A4 P. Hertenberger
94
cannot guarantee increased security, the adherence to the information ownership principles provides a platform from which stricter security measures can be put in place.
CONCLUSION The paper has briefly introduced the reader to the problems traditionally faced when implementing security within an ERP software environment. The most pressing problems were identified and discussed. To provide a solution to these problems, the paper introduced the concept of information ownership as a means to increasing and enhancing the security subsystem of an ERP software package. The proposed ERPSEC framework was introduced. The requirements of the ERPSEC framework to support the concept of information ownership were highlighted. It was briefly shown how ERPSEC assists in supporting the following: - a reduction in complexity of the security configuration; - the ability to increase responsibility and accountability within the organization; - a faster implementation time by providing decentralized access to security objects; - to improve the quality of the security configuration as a whole;
REFERENCES 1. M. Hertenberger, Prof. S.H. von Solms, A framework for ERP security, PhD study in progress, 2005 2. The Information Security Glossary, http://www. yourwindow.to/information-security 3. Internal controls, Committee of Sponsoring Organizations of the Treadway Commission (COSO), http://audit.ucr.edu~internal~controls.htm 4. Joseph R. Dervaes, Internal Fraud and Controls, Washington Finance Officer's Association, 48th Annual Conference, 19 September 2004 5. K. Vuppula. B W security approaches, httv:liwww.intelligenterp.com/feat~~re/2002~12/02 12feat1 1.shtml, 2002 6. P. Manchester, Financial Times, 12 November 2003 7. Elizabeth M. Ready, Emerging Fraud Trends, State of Vermont, 2003 8. M. Hertenberger, Prof. S.H. von Solms, A casefor information ownership in ERP systems, Kluwer Publishing, 2004
A NEW ARCHITECTURE FOR USER AUTHENTICATION AND KEY EXCHANGE USING PASSWORD FOR FEDERATED ENTERPRISES Yanjiang yangl,I, Feng ~ a oand ' Robert H.
en^^
'~nstituteforZnfocomm Research, 21 Heng Mui Keng Terrace, Singapore 119613; * ~ c h o ooj l information Systems, Singapore Management University, Singapore 259756
Abstract:
The rapid rise of federated enterprises entails a new way of trust management by the fact that an enterprise can account for partial trust of its affiliating organizations. On the other hand, password has historically been used as a main means for user authentication because of operational simplicity. We are thus motivated to explore the use of short password for user authentication and key exchange in the context of federated enterprises. Exploiting the special structure of a federated enterprise, our proposed new architecture comprises an external server managed by each affiliating organization and a central server managed by the enterprise headquarter. We are concerned with the development of an efficient authentication and key exchange protocol using password, built over the new architecture. The architecture together with the protocol well addresses off-line dictionary attacks initiated at the server side, a problem rarely considered in prior effort.
Driven by the promise of cost saving, expansion of market share and quality improvement of service provision through consolidation and cooperation, industry has seen a rapid rise of federated enterprises. Specifically, a federated enterprise consolidates under one corporate umbrella multiple divisions, branches and affiliations serving different aspects of business continuum and senice coverage. For example, in the
96
Yanjiang Yang, Feng Bao and Robert H. Deng
banlung sector, a central bank has numerous branches distributed across a city, a region. Another example is in the healthcare area, where a federated hospital integrates many inside and outside units, e.g., clinical laboratories, departments, outpatient clinics, managed care organizations, pharmacies and so on. In a federated enterprise, each affiliating organization has its own business interest, providing service to a distinct group of users. Following conventional ways, each affiliating organization has to work independently on trust management, maintaining by itself account information of its users. However, this may not be optimal in practice. First, affiliating organizations may lack sufficient expertise and funds for a secure maintenance of user account. This situation deteriorates with the trend that organizations are becoming increasingly fond of outsourcing IT management to some specialized service providers. In such circumstances, system administrators may present themselves as a big threat to system security [I]. Second, from the users' perspective, a user apparently prefers assuming the higher credit of the entire enterprise rather than that of an individual affiliating organization. For these reasons, new paradigm of trust management that well takes advantage of the special structure of federated enterprises is of interest and urgency. On the other hand, human memorable password has historically been used as a main means for user authentication, due to operational simplicity. In particular, no dedicated device is required for storing password, which is deemed of particular importance as users are becoming increasingly roaming nowadays. We are thus interested in exploring the use of short passwords for user authentication and key exchange in the context of federated enterprises. Towards this, we are faced to first address the weaknesses inherent in password-enabled systems: because of a limited dictionary space, password is susceptible to brute-force dictionary attack, and more precisely off-line dictionary attach? [2]. Specifically, in off-line dictionary attack, an attacker records the transcript of a successful login between a user and the server, and then enumerates and checks every possible password against the transcript, until eventually determine a correct password. Tremendous effort has been dedicated to resisting off-line dictionary attack in password-enabled protocols (e.g., [3, 4, 5, 6, 7, 8, 9, 101). An assumption common to these methods is that the server is completely reliable, so users share with the server clear passwords or some easily-derived values of passwords for subsequent user authentication. As such, while these protocols are sufficiently robust to off-line dictionary attacks by the outside attackers, they
In contrast to off-line attack is on-line dictionary attack, which turns out to be easily thwarted by restricting the number of unsuccessful login attempts made by a user.
A New Architectzrrefor User Authentication and Key Exchange ...
97
are not intended to defend against the server, e.g., in the event of penetration by outside attackers. However, for the reasons discussed earlier (limited expertise and funds, outsourcing, etc.), threats posed by the server become clearer in the setting of federated enterprises. As a consequence, servers maintained by the affiliating organizations of an enterprise are no longer deemed fully trusted. Adapting password-enabled systems to federated enterprises has to additionally mitigate the concern of unreliable servers, in addition to outside attackers. To this end, we propose a new architecture for user authentication and key exchange using password, geared to the needs of federated enterprises. In its simplest configuration, the architecture consists of an external sewer managed by each affiliating organization and a central sewer administrated by the enterprise; each server only keeps partial information on a user password, such that no single server can recover the password by means of off-line dictionary attacks user authentication is accomplished together by the two servers. Our attention is given to the development of an efficient authentication protocol for the new architecture, rather than formal provable security. The proposed architecture together with the protocol enjoys several attractive features The rest of the paper is organized as follows. In Section 2, we review related work. We then present our new architecture and discuss extension in Section 3. In Section 4, we propose an efficient user authentication and key exchange protocol well attuned to the new architecture, and security of the protocol is examined. Finally, Section sec5 concludes the paper.
RELATED WORK Resistance to off-line dictionary attack has long been in the core of research on password-enable systems. It is a proven fact that public key techniques are absolutely necessary so as to resist off-line dictionary attacks, whereas the involvement of public key cryptosystems is not essential [7]. Accordingly, two separate lines of research have been seen in the literature: combined use of password and public key cryptosystem, and password only approach. For the former, asymmetry of capacity between the users and the server is considered, so that a user only uses a password while the server has a publiclprivate key pair at its disposal. Examples of such public keyassisted password authentication include [7, 8, 1 I]. With no surprise, the use of public keys entails the deployment of PKI for certification, adding to the users the burden of checlung key validity. To eliminate this drawback, password-only authenticated key exchange (PAKE) protocols have been
98
Yanjiang Yang, Feng Bao and Robert H. Deng
extensively explored (e.g., [3, 4, 5, 6, 9, 101). The PAKE protocols do not involve any public key cryptosystem whatsoever. What common to the above methods is the assumption that the server is totally trustful, so a user shares a password or some password-derivative value with the server. In other words, these methods are by no means resilient to the off-line dictionary attack initiated by the server, e.g., in the event of break-ins by outside attackers. To address this problem, [I21 first proposed the so-called password hardening technique by transforming a weak password into a strong one through several servers, thereby eliminating a single point of vulnerability. Afterwards, [13] improved this multi-server model. Further and more rigorous extensions were due to [I41 and [15], where the former built a t-out-of-n threshold PAKE protocol and gave formal security proof under the Random Oracle Model [16], and the latter presented another two provably secure threshold PAKE protocols under the standard model. A limitation of the protocols in [I41 and 1151 is their low efficiency, so they may not be practical to resource-constrained users, e.g., mobile phones. Moreover, notice that in the above multi-server setting, password is still susceptible to a weaker form of a single point of vulnerability, in the sense that passwords are eventually reconstructed by a dealer at the time of user authentication. By contrast, in our architecture no trust exists between the central server and the external server, thus a single point of vulnerability is completely eliminated. This however adds substantial challenges to the design of the underlying authentication protocol. Our basic architecture (one central server is involved) is similar to a recent novel two-server model in [17], which was to overcome the deficiency of complex and computation extensive protocols in [14, 151. The protocol in [I71 assumes that servers use SSL to establish secure communication channel with users. Distinctions between our work and [I71 include: (a) we achieve mutual (bilateral) authentication as well as key exchange, whereas [17] considered merely unilateral authentication of the user to the servers, and no key exchange; (b) we develop a different protocol for testing the equality of two numbers under our presumed adversary model. Without a similar explicitly specified adversary model, the protocol in [I71 may cause trouble in case that one of the two servers deliberately disrupts the protocol, attempting to gain advantages over the other; (c) our architecture is tailored to federated enterprises, whereas the model in [17] was suggested for an organization outsoucing a part of its trust management to a security service provider; (d) we also suggest extending the basic architecture to an architecture including a group of central servers, solving the possible bottleneck caused by one single central server.
A New Architecture for User Authentication and Key Exchange ..
3.
A NEW AUTHENTICATION ARCHITECTURE FOR FEDERATED ENTERPRISES
Our basic architecture is shown in Figure 1: at the server side, an external sewer and a central sewer coexist; the external server is the actual one providing service to the users, thereby standing front-end; the central server is to assist the external server for user authentication, staying transparent to the users. A main objective of this architecture is to "harden" a user's short password into two long secrets and each is hosted by a server, so that neither of the two servers can launch off-line dictionary attacks. As discussed earlier, a uniqueness of this architecture is represented by the fact that no trust exists between the two servers. This on the one hand totally eliminates a single point of vulnerability, while on the other hand makes the design of the underlying password-enabled protocol particularly challenging. In particular, the two servers together validate user passwords, whereas no extra information should be leaked to each other in facilitating off-line dictionary attack.
User
Figure I. Basic two-server architecture for federated enterprises
Figure 2 shows the scenario when applying this basic structure to a federated enterprise: the headquarter of the enterprise manages the central server, and each affiliating organization operates an external server, providing service to a group of users of its own. This architecture offers several benefits: First of all, of particular advantage is that neither the central server nor the external servers can compromise user passwords by means of off-line dictionary attack. Affiliating organizations are relieved from strict trust management to some extent, so they can dedicate their limited expertise and resources to enhancing service provision to the users.
Yanjiang Yang, Feng Bao and Robert H. Deng
100
Users are afforded to assume the higher credit of the enterprise, wlde engaging business with individual affiliating organizations. The enterprise is provided a way to monitor the affiliating organizations, deterring them from cheating. As the central sever is hidden from the public, the chance for it under attacks is substantially minimized, thereby increasing the overall security of the architecture.
-----------
Enterprise Headquarter Affiliating Org.
II I
I
I I I 1 I
r
I
--J
-I -Sewer - - - - - -I User
Figure 2. Typical application scenarios
3.1
Extension
In the basic architecture, a single central server is to collaborate with numerous external servers in a federated enterprise. It is thus possible that the central server becomes a system bottleneck. To mitigate this concern, we suggest extending to include several central servers as a group as shown in Figure 3. The group of central servers work under a 2-out-of-n threshold secret sharing scheme (e.g., ['8]), so that each holds a share of the secret that would be otherwise kept by a single central server (n is the total number of the central servers). When an external server requests for user authentication, one of the servers volunteers to manage the reconstruction of the secret among the group. This voluntary central server is the only one interacting with the requesting external server, thus the external server feels nothing different as with a single central server. This extension not only solves the potential bottleneck problem, but also addresses the issue of failures or break downs of a single central server.
A New Architecture for User Authentication and Key Exchange ...
101
Figure 3. Extended architecture including a group of central servers
4.
AN AUTHENTICATION AND KEY EXCHANGE PROTOCOL USING PASSWORD
In this section, we shall detail the authentication and key exchange protocol using password, which is geared to the setting of federated enterprises. The protocol is built over the basic architecture in Figure 1. Extension to the extended architecture in Figure 3 is also discussed. A central building block of our protocol is a sub-protocol for testing the equality of two numbers. For ease of reference, we start with listing the notations that are used in the sequel. Table I . Notations two large primes such that p = 2q+ 1. a generator of a subgroup of 2,' of order q. g n a user's password. cryptographic hash functions which are modelled as random oracle [16]. h . )H . ) U, ES, CS identity of a user, the external sever and the central server, respectively. encryption and decryption functions (of a semantic secure public key E d . ) , Dd.) cryptosystem) by entity 2 s public key and private key, respectively.
P,4
4.1
The setting
Three types of entities are involved in our system, i.e., the users, the external servers and the central server. For the purpose of authentication, each user U has a short password K , and z is transformed into two long secrets, each of which is held by the external server ES that U belongs to and
102
Yanjiang Yang, Feng Bao and Robert H. Deng
the central server CS, respectively. CS stays transparent to the public, and ES acts as the relaying party between U and CS. In such a scenario, it is reasonable to assume authentic communications between ES and CS. Definitely, this assumption can be readily accomplished by the two parties sharing a secret, which is used to key a MAC. Considering the close tie between the two parties, it is also convenient for them to periodically (e.g., once a week) update this secret, e.g., the headquarter (CS) sends a new secret to the affiliating organization (ES) by normal mail weekly. CS has an authentic key pair that corresponds to a semantically secure public key cryptosystem, with the encryption function (resp. decryption function) Ecs(.) (resp. Dcs(.)). As discussed earlier, in a federated enterprise CS clearly assumes more trust than ES because of sufficient expertise, funds, and the fact that CS is not directly exposed to the public. Considering such asymmetry in terms of trust upon CS and ES, adversary model in our protocol is that CS is semi-honest and ES is malicious, with respect to their desire for off-line dictionary attack, and they do not collude. More specifically, CS is honest-but-curious ['9], i.e., it follows the protocol, with the exception that it may try to derive extra information by analyzing the protocol transcript; on the contrary, ES may act arbitrarily for uncovering user passwords.
4.2
High level description
Central to our protocol is to fight against off-line dictionary attack by the servers (Note that outside attackers are clearly no more powerful than the external server in this regard). The intuition behind our authentication and key exchange protocol is as follows: in an out-of-band registration phase, a user U "hardens" his password n into two random long secrets s and n + s, and registers them to the external server ES and the central server CS, respectively, where s is a random number. In authentication phase, U picks another long random number r and sends r and n + r to the two servers, respectively. Upon receiving the messages, ES computes a = r - s, and CS computes b = (n+ r) - (n + s) = r - s. Afterwards, the two servers engage into an interactive protocol to test a ?= b. Note that a = b holds if and only if user U knows n. Upon the servers validating the user, ES and U negotiate a common session key for subsequent data exchanges. Clearly, from s and r (resp. n + s and n + r), ES (resp. CS) is unable to gain anything useful on n. It is thus of crucial importance to ensure the protocol for testing a ?= b could not facilitate the servers for off-line dictionary attack. In what follows, we first propose a protocol allowing two parties to test a ?= b, which will be invoked by our final authentication and key exchange protocol that follows.
A New Architecture for User Authentication and Key Exchange ...
4.3
103
A protocol testing a ?=b
A protocol for simply testing a ?= b by two parties A (possessing a) and B (possessing b), while without disclosing a and b may be quite straightforward. See a simple example: A sends h(a) to B and B sends h(b) to A, where h(.) is a hash function as defined in Table 1; each party checks h(a) ?= h(b). A variant is that A sends G, = gomodp to B and B sends Gb = gb mod p to A, where p and g are defined as in Table 1; each party then checks G, ?= Gb. Both methods however cannot avert off-line dictionary attack by the two parties in our case. Take the first example and A for instance, A chooses a random number r and computes a = r - s for himself, and simply sends r to B. B will return h(r - s - x) to A. It is easy to see that A can enumerate every possible password until find n: such that h(a - x') = h(r - s - x). In a same way, the attack applies to the variant example, although in normal cases, it is hard to get a (resp. b) given Go (resp. Gb) according to discrete logarithm assumption. These examples convey to some extent the subtleties in designing a protocol in our case of withstanding off-line dictionary attack. Let QR, denote the group of quadratic residues modulo p , and a hash function be defined as h: {O, l}'Pi+ QR,, where p, q, h(.) are public parameters and as defined in Table 1. Note that in practice h can be achieved by squaring a one-way hash function, e.g., SHAI. We outline our proposed protocol for testing a ?= b in Figure 4 (all arithmetic operations are calculated modulo p).
Figure 4. A protocol testing a ?=b
Specifically, A picks kA E R Z, on the fly and computes y , = h ( ~ ) ~ " mod p. A initiates the protocol by sending yA to B. Upon receiving the message, B chooses kB E Zq, in turn compctes yB = h(blk" mod p and
104
Yanjiang Yang, Feng Bao and Robert H. Deng
k, modp, respectively. B then sends y, to A. After receiving y,, A w, = y, computes w, = y, k , modp and sends w, to B. With WA,B tests wA ?= WE. B then sends WB to A if w, = WB, and a special label otherwise. A then tests wg ? = w, if wBis received.
4.3.1
Security analysis
In line with the adversary model defined in our final protocol, we assume A a malicious adversary while B an honest-but-curious adversary. In addition, for the moment we assume A does not replay messages, and the communication between A and B is authentic. These assumptions will be clear when we come to our final protocol. We start by by claiming that upon completion of theprotocol, either (1) A and B learn that a = b or ( 2 ) A and B learn a b but nothing more on the opposite side's secret. Clearly in the first case, if w~ = wB holds, A and B learn that a = b. We next show if a # b (this may be due to that A cheats by intentionally using a, which is different from his original input), both parties learn nothing more. Consider A first: intuitively, A gets y , = h ( b ) k n mod p at the end of the protocol. It is easy to see that without knowing kB, A is unable to obtain anything on b in an information theoretic sense. Next, consider the case of B: when the protocol terminates, of relevance to B is ( y, =,h(a)k~ mod p, W~ = Y E k~ mod p). Notice intuitively that (w,, yB = wAk'-mod p, yA, h ( a ) = v , k ~ - ' mod p) is indistinguishable from (wA, y,, y ~ Z, ) under the decisional Diffie-Hellman assumption [20], where z is random and kAkA-'= 1 mod q. Therefore B cannot learn anything more on a from executing the protocol. Our next claim is that f A aborts the protocol before completion, he is unable to gain more advantages over B. To see this, the only place A is likely to abort is after receiving yBfrom B. But as we have discussed, y, does not leak anything on b. Our claim thus holds. We stress that as an honestbut-curious adversary, B is not interested in deviating from the protocol, e.g., deliberately aborting the protocol or sending in the case of w~ = wg. In this sense, our protocol achieves "fairness".
*
4.4
Authentication and key exchange using password
We now present an efficient authentication and key exchange protocol using password, built over the basic architecture in Figure 1. The earlier protocol for testing a ?= b is invoked in this protocol as a building block, where ES plays the role of A and CS takes the role of B. In the sequel, we
A New Architecture for User Authentication and Key Exchange ...
105
occasionally omit "modulo p" in stating arithmetic operations as long as the context is clear. System parameters are defined as follows: p and q are as defined in Table 1, and QR, is the group of quadratic residues modulop. A hash function H(.) (e.g., SHAI) is employed. Moreover, g is picked from QR, as g E QRp\ (1 ). Clearly, g is of order of q. H(.),p , q and g are public parameters. To enrol as a legitimate user in a service, it is natural that at the beginning, a user must authenticate to the service provider and in turn establish a password with the organization for subsequent service access. In our case, U needs to register to not only the actual service provider E S but also the enterprise CS that ES is affiliated to.
4.4.1
Registration
Suppose U has already successfully authenticated to ES, e.g., by showing his identity card, U picks his password 7c and selects a random number SE QR,. U then registers in a secure way s and 7c + s mod p to ES and CS, respectively. Here for purely simplicity reasons, we assume (n + s m o d p ) ~ QR;. Consequently, ES stores the account information (U, s) to its secret database, and CS stores (U, + s mod p ) to its secret database. Someone may wonder how Uregisters n + s to CS, as CS is supposed hidden from the public. This is in fact not a problem in practice: U can contact CS by normal mail, etc. Indeed, imagine that a user enrols in a branching bank, it is not strange at all that the user still needs to submit a secret to a higher authority of the bank so as to activate his account. Upon completion of the registration, U can request service from ES, by exploiting the protocol in Figure 5 for authentication and establishment of a common session key. 4.4.2
The protocol
Let us follow the protocol (in Figure 5 ) step by step. To initiate the protocol, U picks x as x E Z, and computes e, = gr mod p, which will be used for (Diffie-Hellman) key exchange. U also selects r as r E Z,, and encrypts ex, 7c + r modp and Tusing CS's authentic public key as eo = Ecs(e,, n + r, T), where T is the current timestamp. U then sends in MI the message of (U, ex, r, eo, T ) to ES. Upon receipt of the message, E S first checks whether T is within a pre-defined time window: if T expires, ES simply
In our protocol, we require (n + s mod p ) E QR, Indeed, if (rr must hold that (p - n -s mod p) E QR,,.
+s
mod p ) P QR,, then it
106
Yanjiang Yang, Feng Bao and Robert H. Deng
returns reject to U and aborts the protocol; otherwise, ES proceeds ahead. ES searches his secret database for Us account. If no such an account is found, ES returns reject to U and stops the protocol; otherwise, ES fetches the secret s and computes a = r - s mod p ; ES also keeps e, in his live buffer. Afterwards, ES relays (U, eo, T ) to CS in M2.
Figure 5. An authentication and key exchange protocol using password
In a similar way, CS checks the freshness of T and the account of U in his secret database. If both are correct, CS decrypts eo to get (eo', b', T) = Dcs(eo). CS then checks whether T = T: if not, CS rejects; otherwise, CS continues. CS takes out n + s and computes b = b' - (n + S) modp. Next, in M3, CS and ES engage in the protocol of Figure 4 to test a ?= b. If a t b, CS rejects and ES in turn replies reject to U. Otherwise, CS chooses z E Z, and computes e, = gzmodp, which is in turn used to "encrypt" n + s as e2 = e,'"n + s) mod p. CS then sends in M4 the message of (e,,', ez, e2) to ES. Upon receiving the message, ES checks whether e,' = e, (e, is being kept alive in the buffer) to ensure that ex received in MI has not been replaced by outside attackers. Interestingly, here e., and e.,' are serving an extra purpose of "freshness nonce". If e,y';t e,, ES notifies CS and sends reject to U. Otherwise, ES picks
A New Architecture for User Authentication and Key Exchange ...
107
y~ Zy and computes e, = g" mod p. e, is then used to "encrypt" s as el = e,Y.s modp. Afterwards, ES sends (e,y,e,, el, eZ,e2) in M5 to U. Here, e,yacts as a freshness nonce. ES also computes a common session key K as K = H((e,y, U, ES). Upon receiving the message, U does the following calculations: computes e,y, = (e,)" mod p and obtains nl = ellev mod p; computes e,yz= (eJX mod p and gets n2 = e2/en mod p ; tests n ?= n2 - nl mod p: if the equality holds, U is assured of the authenticity of ES and computes the common session K as K = H(e,,, U, ES).
4.4.3
Security analysis
Our architecture is different from either the standard client-server model (e.g., [7, 101) or the multiple-server model (e.g., [14, 15]), so formal provable security may be quite involved. We thus give an informal security analysis for the moment, yet we believe our analysis still suffices to guarantee the security of the protocol. Recall that the primary goal of this protocol is to resist off-line dictionary attacks by the two servers, where ES is a malicious adversary and CS is an honest-but-curious adversary under the adversary model that represents different levels of trust upon ES and CS. It is easy to see that outside attackers are no more powerful than ES in terms of the capability to uncover Us password. Admittedly, outside attackers can act as man-in-the-middle between U and ES, resulting in a legitimate user being deemed illegitimate by the servers. Note that such attacks are inevitable in any protocol, and discussion of them is beyond the scope of this work as they are not relevant to the password attacks. Resistance to CS: In the protocol, what relevant to CS for off-line dictionary attack is (n + r mod p , n. + s mod p), as well as the interactive protocol for testing a ?= b. Clearly, from n. + r mod p and n + s mod p , CS is unable to learn anything on n.; as discussed earlier, the protocol for testing a ?= b leaks nothing more on n. Consequently, as a passive semi-trusted adversary, CS cannot launch effective off-line dictionary attacks. Resistance to ES: Intuitively, if following the protocol, of help to ES regarding off-line dictionary attack are (r, eo) and (s, e2). However, Ecs(.) is a semantic secure encryption, so the first pair does not help in dictionary attack; notice then that (e,, e2) is a standard ElGamal encryption. As widely known, it is also semantic secure when g~ QR, and (n + s mod p) E QR, as in our protocol. Therefore, ES is not effective in off-line dictionary attack as long as he follows the protocol (behaving as a passive adversary).
Yanjiang Yang, Feng Bao and Robert H. Deng
108
As an active adversary, ES can modify or forge protocol transcript. To see this, ES may pick x of its choice and computes e,, and in turn makes a dubious eo, in an attempt to deceive CS into replying with e2 under his e,. This cheating however cannot succeed, due to the fact that without knowing x, ES is not able to convince CS of a = b. We do notice that in such a way, ES can launch on-line dictionary attack by repeatedly guessing passwords, and engaging in the protocol for testing a ?= b: each time CS returns (reject), ES is assured to exclude a password from the dictionary. However, it is clear that such attacks are unavoidable in any password-enabled system, but can be readily thwarted by limiting the number of unsuccessful authentication attempts (regarding a same user) made by ES. Security to outside adversaries: While no more effective than ES in terms of dictionary attack, an outside adversary could attempt to acquire the common key K established between U and ES. This is another common attack to authentication and key exchange protocols. In our protocol, as the adversary does not know x, he has no way to negotiate a dubious common session key with ES in the name of U. What remains to consider is the scenario that the adversary derives the session key K by watching the protocol transcript between U and ES. This in our case is clearly equivalent to breaking the Diffie-Hellman assumption: by given ,6' modp and gvmodp, to compute gr"mod y without knowing x and y. 4.4.4
Extension
We introduce briefly how to adapt the protocol to the extended architecture in Figure 3 that includes a group of central servers. The extension turns out to be straightforward. The central servers work under a tout-of-n threshold secret sharing scheme [la], each keeping a share of n + s that would be otherwise preserved by a single central server. At the time an external server requests for user authentication, one of the servers volunteers to be the dealer, managing the reconstruction of n + s. The voluntary dealer is the only one interacting with the requesting external server. While the dealer could become a single point of vulnerability, compromise of it actually affects solely those x + s that had ever been reconstructed on it. Furthermore, as already discussed, the chance of compromising a central server is practically minor. After all, this extension at the central server side is actually aimed at solving possible bottleneck problems and break-downs due to a single central server.
A New Architecture for User Authentication and Key Exchange ...
4.5
109
Discussions
The proposed protocol enjoys several advantages. Among others, first, the protocol is particularly efficient to the users in terms of both communication and computation. As to computation, a user only needs to compute 2 one-line exponentiations, and 1 off-line exponentiation and 1 offline public key encryption. This is important when consider to support resource-constrained users, e.g., mobile phones. The communication to the users is optimal: only one round of interaction is involved. Second, a user can use the same password to register to different enterprises or to different affiliating organizations in a same enterprise (by varying s). This avoids a big inconvenience in traditional password-enabled systems (e.g., those reviewed in Section 2), where a user has to memorize different passwords for different applications. We next clarify a possible argument why we do not simply rely on the central server(s) for full trust management of the affiliating organizations, a paradigm similar to Kerberos ['I]. The reasons are as follows: first, each affiliating organization has its own business interest, so it has a stake to involve into the trust management of its own; second and more important, a main objective of our architecture is to avoid a single point of vulnerability. Finally, while the assumption of CS being an honest-but-curious adversary well represents the different levels of trust upon an enterprise and its affiliating organization, it is a strong one. Design of an authentication and key exchange protocol in the case of CS being also a malicious adversary (e.g., allowed to wiretap the communication between U and ES) is an open problem.
CONCLUSIONS We explored applying authentication and key exchange using password to federated enterprises. Taking advantage of the special structure of a federated enterprise, a new architecture comprising an external server and a central server was proposed. A user authentication and key exchange protocol using password that is geared to the architecture was presented. Attention was focused on resisting off-line dictionary attacks by the servers, a topic rarely considered in previous effort. Our proposed architecture and protocol enjoyed several attractive features.
Yanjiang Yung, Feng Bao and Robert H. Deng
ACKNOWLEDGEMENTS The authors would like to thank the anonymous reviewers for their valuable comments.
REFERENCES L. Bouganim, P. Pucheral, Chip-Secured Data Access: Confidential Data on Untrusted Servers, in: Very Large Data Bases (VLDB), pp. 13 1-142,2002. D. V. Klein, Foiling the Cracker - A Survey of, and Improvements to, Password Security, in: 2nd USENIXSecurity, pp. 5-14, 1990 E. Bresson, 0. Chevassut, and D. Pointcheval, Security Proofs for an Efficient PasswordBased Key Exchange, in: ACM. Computer and Commzrnicafion Security, pp. 241-250, 2003. S. Bellovin, and M. Merritt, Encrypted Key Exchange: Password- Based Protocols Secure Against Dictionary Attacks, in: IEEE Symposium on Research in Security and Privacy, pp. 72-84, 1992. S. Bellovin and M. Merritt, Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, in: ACM. Computer and Communication Seczrrity, pp. 244-250, 1993. J. Katz, R. Ostrovsky, and M. Yung, Efficient Password-Authenticated Key Exchange Using Human-Memorable Passwords, in: Advances in Cpptolog)., Euvoclypt'Ol, LNCS 2045, pp. 475-494,2001, S. Halevi, and H. Krawczyk, Public-key Cryptography and Password Protocols, in: ACM Computer and Communication Security, pp. 122- 13 1, 1998. M. K. Boyarsky, Public-key Cryptography and Password Protocols: The Multi-User Case, in: ACM Conference on Computer and Communication Security, pp. 63-72, 1999. J. Katz, R. Ostrovsky, and M. Yung, Forward Secrecy in Password-Only Key Exchange Protocols, in: Security in Communication Networks, 2002 l o M. Bellare, D. Pointcheval, and P. Rogaway, Authenticated Key Exchange Secure against Dictionary Attacks, in: Advance in cryptology, EurocryptlOO,pp. 139-155,2000. L. Gong, M. Lomas, R. Needham, and J. Saltzer, Protecting Poorly Chosen Secrets from Guessing Attacks, IEEE Journal on Seclected Areas in Communications, 11(5), pp. 648656,1993. l 2 W. Ford, and B. S. Kaliski Jr, Sever-assisted Generation of a Strong Secret from a Password, in: IEEE. 9th International Workshop on Enabling Technologies, 2000. l 3 D. P. Jablon, Password Authentication Using Multiple Servers, in: RSA Security Conference, LNCS 2020, pp. 344-360,2001. l 4 P. Mackenzie, T. Shrimpton, and M. Jakobsson, Threshold Password-Authenticated Key Exchange}, in: Advances in Cryptology, Cryptor02,LNCS 2442, pp. 385-400,2002. l5 M. D. Raimondo, and R. Gennaro, Provably Secure Threshold Password-Authenticated Key Exchange, in: Advances in Cryptology, Ezrrocrypt103,LNCS 2656, pp. 507-523,2003. l 6 M. Bellare, P. Rogaway, Random Oracles are Practical: A Paradigm for Designing Efficient Protocols, in: ACM. Computer and Communication Sectrvity, pp. 62-73, 1993. l 7 J. Brainard, A. Juels, and B. Kaliski, M. Szydlo, A New Two-Server Approach for Authentication with Short Secret, in: USENIX Security, 2003.
A New Architecture for User Authentication and Key Exchange ...
111
A. Shamir, How To Share A Secret, Commt~nicationsof the ACM, Volume 22, pp. 612-613, 1979. l 9 0. Goldreich, Secure Multi-party Computatlon, Working Draft, Version 1.3, June 2001. D. Boneh, The Decision Diffie-Hellman Problem, in: 3rd International Algorithmic Number Theory Symposium, LNCS 1423, pp. 48-63, 1998. 2' J. Kohl, and C. Neuman, RFC 15 10: The Kerberos Network Authentication Service, 1993. l8
*'
A SECURE QUANTUM COMMUNICATION PROTOCOL USING INSECURE PUBLIC CHANNELS
I-Ming Tsail, Chia-Mu YU*,Wei-Ting TU', and Sy-Yen KUO' ' ~ e ~ a r t m e noft Electrical Engineering; ' ~ r a d u a t e Institute of Computer Science and Information Engineering; National Taiwan University, No.1, Sec. 4, Roosevelt Road, Taipei, 106, Taiwan
Abstract:
Due to the discovery of Shor's algorithm1, many classical crypto-systems based on the hardness of solving discrete log and factoring problem are theoretically broken in the presence of quantum computers. T h ~ smeans that some of the classical secret communication protocols are no longer secure and hence motivate us to find other secure crypto-systems. In this paper, we present a new quantum communication protocol which allows two parties, Alice and Bob, to exchange classical messages securely. Eavesdroppers are not able to decrypt the secret messages and will be detected if they do exist. Unlike classical crypto-systems, the security of this protocol is not based on the hardness of any unproven mathematic or algorithmic problem. Instead, ~tis based on the laws of nature.
Quantum information science is a highly interdisciplinary field of research and hence has applications in nearly every field of computer science and electrical engineering. Cryptography, most notably key distribution, is one example. Classical cryptography enables two parties, Alice and Bob, to exchange confidential messages such that the messages are illegible to any unauthorized third party. The problem is that it is difficult to distribute the
114
I-Ming Tsai, Chia-Mu Yzl, Wei-Ting Tu, and Sy- Yen Kuo
secret key securely through a classical channel. This is known as the key distribution problem. Classical key distribution protocols based on the hardness of mathematical or algorithmic problems2*%re conditionally secure i. e. theoretically insecure. However, quantum cryptography allows a number of applications that are not possible classically. An example is the Quantum Key Distribution (QKD) protocol -- a protocol dealing with secure key distribution using quantum mechanics. Theoretical study and physical implementations of QKD have been developed rapidly after Bennett and Brassard proposed the standard BB84 protocol4. Basically, QKD schemes can be categorized into two classes -non-deterministic QKD and deterministic QKD. For non-deterministic QKD, the sender and the receiver have no control over what bit string is used as the 1 ~~ 9 2 key. Typical non-deterministic QKD schemes include BB84, ~ 9 and protocols. In contrast, in a deterministic scheme, the sender and receiver have a total control of what bit string is used. This is actually, in classical cryptography terms, a secure communication, or an encryptionldecryption process7-'0. A secure communication protocol allows the sender (Alice) and the receiver (Bob) to exchange messages securely without running the risk of being decrypted by an eavesdropper (Eve). As a secure communication protocol, two requirements must be satisfied. First, upon a successfill transmission process, the secret messages shall be able to be read out as its original form by the legitimate receiver. Second, in the presence of an eavesdropper, the encrypted message shall give her absolutely no information even if she may have total control of the channel. In the following sections, we present a protocol which not only fulfills these two requirements, but also can detect the eavesdroppers, if they do exist.
2.
BACKGROUND
The state of a single quantum bit can be written as a linear combination of two states in a two-dimensional complex vector space as
r)
2
2
where a and /? are com lex numbers and la1 +l,8l = 1 . The two orthonormal states 10) and forms a computational basis of the system and the contribution of each basis state to the overall state ( aa n d p in this case) is called the probability amplitude. According to quantum mechanics, when the system is measured, the state c,dlap,~esto one of the basis states
~
A Secure Quantum Communication Protocol Using Insecure ...
115
(1
0) or 11) ). The probability of collapsing to a particular basis state is directly proportional to the square of the probability amplitude associated with it. More specifically, when a measurement is erformed on a quantum state, the P probability of getting a result of 10) is nl and the probability of getting a resylt of, 11) is 1,812 . Obviously, due to the rule of probability, Jal +l,8l = 1 . The symbol for a quantum measurement is shown in Fig. 1(a). input
++
output
input
+ ,
output
control input
output target
Figure 1. The symbols for quantum measurement and various quantum gates
The state described above exhibits a unique phenomenon called quantum superposition. When a particle is in such a state, it has a part corresponding to 10) and a part corresponding toll), at the same time. However, when a measurement is performed, it collapses to one of the states in the basis (eigenstates). To distinguish the above system from a classical binary digit, such a unit is called a quantum binary digit, or qubit. An easy way to describe a qubit is to use column matrices. For example, Eq. ( I ) is equivalent to the notation
Similar to classical bits manipulated by classical logic gates, a qubit can be manipulated using quantum gates. Like a qubit, a quantum gate can also be written in matrix form. In its matrix form, a quantum gate G must be unitary, i.e. satisfyng GG' = GcG = I , where G+ stands for the
116
I-Ming Tsai, Chia-Mzi Yzi, Wei-Ting Tzi, and Sy- Yen Kzro
transpose conjugate of G . This is because any such gates can be pictorially described as a rotation on the Bloch sphere. When a qubit goes through some quantum gates, the state vector is rotated to another direction. An example of quantum gate is the quantum NOT gate, which has the matrix representation of
Using the matrix form, the new state after a quantum NOT gate can be calculated using matrix multiplication. For example, when a qubit 2 2 la1 + 1,8I = 1 goes through a quantum NOT gate, the state changes to
The symbol for a quantum NOT gate is shown in Fig.l(b). Another important quantum gate is the HADAMARD (H) gate. The matrix form of a HADAMARD gate is
and is able to make the following state changes:
The symbol for a HADAMARD gate is shown in Fig. 1 (c). The space of a multi-qubit system can be modeled by the tensor product of each individual space. For example, a two-qubit state is a linear combination of four basis states:
A Secure Quantum Communication Protocol Using Insecure ...
117
+ 1 ~ 1 ' + Id2+
P
with a , , y , 6 complex numbers and In12 1612= 1 . Similar to the single qubit case, a two-qubit system can be represented using a 4 x 1 column matrix and a two-qubit gate can be represented using a 4 x 4 matrix. An example of two-qubit gate is the CONTROL-NOT (CN) gate, as shown in Fig. l(d). A CN gate consists of one control bit x and one target bit y . The target qubit will be inverted only when the control qubit is 1). Assuming x is the control bit, the gate can be written as CN x, y ) ) = x, x 63 y ) , where @ denotes exclusive-or. This actual1 performs a permutation on the basis as follows: 00) i 00) , 1 0lf 1101) , 110) i 11) , and 111) i 110) . In column matrix, this is equivalent to
/
I
[
/
1
/
An interesting phenomenon in quantum mechanics is entanglement. Imagine that Alice and Bob share a two-qubit system in the state
where a and b denote Alice and Bob respectively. According to quantum mechanics, if Alice takes a measurement on qubit a , the state of the qubit with a probability of // . Moreover, Alice immediately will collapse to knows that the state of the other qubit (qubit b ) must be 10) . In other words, once the measurement result of one qubit is decided, the state of the other one is perfectly correlated and can be instantaneously decided, no matter how far away Alice and Bob are separated. A similar result happens if the result of Alice's measurement is 11) . This non-classical correlation among multiple quantum systems is called quantum entanglement, because they can not be written as separable states and are considered to be entangled. Studies of different types of entanglement and their applications are an important issue in quantum information science.
10)
3.
ENCRYPTED COMMUNICATION PROTOCOL
The proposed protocol uses one entangled qubit pair to transmit one encrypted classical bit, then an n -bit classical message can be transmitted
118
I-Ming Tsai, Chia-Mu Yu, Wei-Ting Tzr, and Sy-Yen Kuo
bit-by-bit via this protocol. At the end of the transmission, an error checking process is employed to check the integrity of the whole message.
3.1
Resource requirement
In this paper we assume Eve has unlimited technological and computational power. She can perform any operation on the transmitting qubit as long as it is allowed by the laws of nature. Under these circumstances, the propose protocol can protect both the privacy and integrity of the message using a classical public channel and a quantum channel. The natures of these channels are described in the following paragraphs. A classical channel is a communication path that can be used to transmit classical information from a sender to a receiver. For example, an optical fiber which allows Alice to send her voice to Bob is a typical classical channel. Depending on whether the channel is readable or writable by an unauthorized third party, classical channels can be further categorized into classical private channels and classical public channels. A classical private channel is a channel, together with some appropriate mechanisms, which are capable of maintaining the privacy and integrity of the messages transmitted via that channel. The term privacy refers to the fact that the data carried in the channel cannot be read or revealed by anyone without authorization. It involves mainly data encryption algorithms and secret keys. An encryption mechanism, together with a secret key, can be used to translate the message into a form that is unreadable without the secret key. The term integrity means the message from the source can not be either accidentally or maliciously modified, altered, or destroyed. In other words, the messages exchanged between Alice and Bob are identically maintained during the transmission process. As a contrast, a classical public channel is a classical channel that maintains only the data integrity, regardless of the privacy. In other words, a classical public channel can be used to transmit classical information from Alice to Bob without being modified by eavesdroppers. However, anyone, including eavesdroppers, can read the original message. Radio broadcasting in a non-jamming environment is an example of a classical public channel. In general, a classical public channel is a weaker assumption compared to a classical private channel. A quantum channel is a communication channel which can be used to transmit quantum information from a sender to a receiver, as opposed to a classical channel transmitting only classical information. In other words, a quantum channel can be used to transmit a quantum state as described in Eq. (I), from the sender to the receiver. An example of quantum channels is an
A Secure Quantum CornrnzlnicationProtocol Using Insecure ...
119
optical fiber that can be used to transmit and maintain the polarization of photons.
Bit encryption protocol
3.2
In the following paragraphs, we give the specific steps and associated examples of the encrypted quantum communication protocol. All the steps are illustrated in Fig. 27 jh
I"
Alice
lvii ;
;
i la) = 10) i i.............................................&................................... Quantum channel
Figure 2. The encrypted quantum communication protocol with each step indicated
1. Assuming Alice has a classical secret bit b E {0,1) which she wants to send to Bob. To do this, Alice encodes her classical secret bit b into a quantum state 0) in case b = 0 , or 1) in case b = I . 2. Then Alice applies a HADAMARD gate on lb) to get a quantum state . Depending on the classical secret bit, the state will be
/
Iv)
in case b = 1 .
/
120
I-Ming Tsai, Chia-Mu Yzi, Wei-Ting Tu, and Sy-Yen Kz~o
10)
3. Alice then prepares an ancillar qubit la)= and a lies a CONTROL-NOT gate CN Y), a The notation CN Y), stands for a CONTROL-NOT gate with y) as the control bit and la) as the target bit. This creates an entanglement between y ) and a) , since
I
f.
i
1
[
1 3
1
in case b = 1. The subscript iy and a denote the order of the qubits. 4. Alice sends ubit la) to Bob through the quantum channel. After Bob gets qubit la7, he tells Alice through the classical public channel that he has received the qubit. 5 . Both Alice and Bob apply HADAMARD gates to their own qubits. If b = 0, this gives
However, in case b = 1, it gives
A Secure Quantum Communication Protocol Using Insecure ...
12 1
6. Alice takes a measurement of her qubit with respect to ( 0 ) and 11) . Eq.(15) and Eq.(16), she will get a result of either 11) with a probability of . Alice then translates the corresponding classical bit: p = 0 if = or
i p ) 10)
7. Alice sends the result p to Bob through the classical public channel. 8. Similarly, Bob takes a measurement of his qubit with respect to 0) and 1) . According to Eq.(15) and Eq.(16), he will get a result of either y) = or ') = 1 ) with a probability of . Bob then translates the result y into the corresponding classical bit: q = 0 if y ) = 10) or 4 = 1 if ')=11). 9. Unlike Alice, who sends her result through the classical public channel, Bob keeps the result secret and performs
1
1"
1
1
,
/
to recover the classical message b .
3.3
Protocol description
In the protocol described above, the information of the secret bit b is encoded as the phase of the entanglement state after Alice applies the CONTROL-NOT gate. This can be seen ffom the phase (plus vs. minus sign) in Eq.(13) and Eq.(14). If Alice sends only one qubit to Bob, the information is shared between them and can not de retrieved via any local operation. In other words, the only qubit sent by Alice via the quantum channel does not contain enough information to recover the secret bit b . To recover the original secret bit, either a joint operation (for example, a CONTROL-NOT gate) or classical message exchange between the two parties is necessary. In this protocol, Alice does not send both qubits to Bob, she keeps one qubit in her hand to avoid a joint operation performed by the eavesdropper. Instead, two HADAMARD gates are performed by Alice and Bob separately. Since after these operations, the measurement results of these qubits become perfectly correlated (as in Eq.(15) and Eq.(16)) and the secret bit can be deduced by a simple calculation over the two classical bits according to Eq.(17). However, one of the two classical bits is now in Bob's hand. All Alice has to do is to reveal her classical bit p to Bob. To do this, Alice can send her classical bit p to Bob via the classical public channel. Note that the result announced by Alice is completely random, so it does not contain enough information for Eve to deduce the secret bit. At the end of the protocol, Bob can count the number of '1's and decrypt the secret bit
I-Ming Tsai, Chia-Mu Yu, Wei-Ting Tzr, and Sy- Yen Kuo
122
according to Eq.(17). If the number of '1's is even, the message b is 0 . On the other hand, if the number of '1's is odd, the message b is 1.
4.
ANALYSIS OF THE PROTOCOL
In this section, we assume the existence of an eavesdropper and show that the protocol is secure as long as the qubit sent by Alice reaches Bob.
4.1
Analysis on eavesdropping
As described previously, step (1)-(3) are performed by Alice locally. Basically these steps prepare an entanglement state depending on the secret bit b . The only chance Eve can get information from the channel is step (4) and (7). A typical attack is shown in Fig. 3.
Figure 3. The encrypted quantum communication protocol with eavesdroppers
Since step (4) is the only chance for Eve to attack the quantum channel, we discuss this first. As Eve has the capability of performing quantum gates to that qubit, without lose of generality, we assume that Eve prepares an and performs a C N (a,/?) to get some information ancillary qubit?!, = from the flying qubit. The state is now
10)
A Secure Quantum Communication Protocol Using Insecuve ...
123
for b = 0 , and
in case b = 1 . The notation CNap stands for a CN gate with a as the control and p as the target. In the following steps, if Eve performs a HADAMARD gate as Alice and Bob do in step (S), the state will evolve as follows. 1. If b = O , i t g i v e s
2. if b = 1 , it becomes
From Eq.(20) and Eq.(21), we see this still makes the total number of '1's even in case b = 0 and odd in case b = 1 . After Alice announces her measurement result in step (7), if Bob knew the result of all three qubits he could still count the total number of '1's to deduce the secret bit.
I-Ming Tsai, Chia-Mzl Yu, Wei-Ting Tu, and Sy-Yen Kuo
124
Assuming the secret bit b = 0 , the total number of '1's is even ( 000) 0 1 1) ,I10 1) , 1 10) ). However, there is a probability of ( 0 1 1) and 11 0 1) ) that Eve has a '1' in her hand. The silent eavesdropper has no way to get rid of this bit and push this information back to Alice or Bob. This makes the total number of '1's belonging to Alice and Bob odd and will hence flip the secret bit. As for Eve's qubit, it carries no information because it can be either 10) or 11) , each with a probability of . In summary, the intrusion introduces an error but gives Eve no information. Similar analysis holds for other unitary operations performed by Eve. Since the existence of eavesdropping will inevitably introduce errors, Alice and Bob can detect the intrusion by appending an error checking code in the message. A simple error checking algorithm that allows two parties to perform message encryption is shown in the following section.
1
4.2
,I
/
1
Message encryption protocol
The bit encryption protocol allows two parties to transmit one classical bit each time. The result is either a successful transmission or a bit-flip induced by eavesdropping. With the bit encryption protocol described above, an n-bit message can be sent using the following procedure to protect its integrity. 1. Alice sends the message bit-by-bit using the bit encryption protocol. 2. They negotiate publicly to decide a hash function. 3. Alice sends the hash result, bit-by-bit, using the bit encryption protocol. 4. Bob gets both the message and hash result. He can check the integrity of the message using the hash. If they don't match, the message is corrupted. Otherwise, the message is valid.
4.3
Channel analysis
In this protocol, two communication channels are used. One is a classical public channel; the other is a quantum channel. As described previously, the classical channel is a public channel, so the data is public readable. However, we did not discuss whether the channel can be publicly writable. Actually, if the classical public channel is contaminated, the result decrypted by Bob will be flipped and hence cause an error. From this point of view, the classical public channel is publicly writable, but any incorrect value inevitably causes an error. This is because an attack in the classical channel is protected by the quantum channel and will be detected. Moreover, this implies that the protocol still works even if a man-in-the-middle exists only in the classical channel. Similarly, the quantum channel is publicly writable as long as the classical channel is not contaminated. This is because even the flying qubit is
A Secuve Quantum Communication Protocol Using Insecure ...
125
replaced by an uncorrelated new qubit, the eavesdropping will still be detected by the integrity checking process. However, if both classical and quantum channels are controlled by Eve, then she will be able to do whatever she likes as a man-in-the-middle. This becomes an authentication problem, which is outside the scope of this paper.
5.
CONCLUSION
In this article, we propose a new cryptographic protocol based on a phase-encoding scheme. Local operation and classical communication can be used to achieve private communications between the sender and the receiver. In case eavesdroppers exist and have total control of the channel, the protocol not only gives absolutely no information but also can detect the existence of eavesdroppers. Unlike its classical counterpart, the security of the protocol does not depend on any unproven hard problems. It is based on the laws of physics.
REFERENCE 1. P. Shor, Algorithms for quantum computation: discrete logarithms and factoring, Proceeding of the 35th Annual IEEE Symposium on the Foundations of Computer Science, 124-134(1994). 2. R. &vest, A. Shamir, and L. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, vol. (2) 21, pp. 120-126(1978). 3. W. Diffie, and M. E. Hellman, Multiuser Cryptogrphic Techniques, Proceeding of AFIPS National Computer Conference, 644-654(1976). 4. C . Bennett, and G. Brassard, Quantum Cryptography: Public Key Distribution and Coin Tossing, Proceedings of IEEE International Conference on Computers Systems and Signal Processing, 175-179 (1984). 5. A. K. Ekert., Quantum Cryptography based on Bell's theorem, Phys. Rev. Lett 67(6), 661-663(1991). 6. C. Bennett, Quantum Cryptography: Uncertainty in the Service of Privacy, Science 257,752-3 (1992). 7. K. Bostrom, and T. Felbinger, Deterministic Secure Direct Communication using Entanglement, Phys Rev Lett. 2002 Oct 28;89(18):187902.
126
I-Ming Tsai, Chia-Mu Yu, Wei-Ting Tu, and Sy- Yen Kuo
8. Qing-Yu Cai, Deterministic Secure Direct Communication using PingPong Protocol without Public Channel, http://xxx.lanl.gov/abs/quantphl0301048. 9. Qing-Yu Cai, Deterministic secure communication protocol without using entanglement, Chin. Phys. Lett, 2 1(4),6Ol (2004). 10. Z. Zhao, T. Yang, Z.-B. Chen, J.-F. Du, and J.-W. Pan, Deterministic and highly efficient quantum cryptography with entangled photon pairs, Phys. Rev. Lett., http://xxx.lanl.gov/abs/quant-ph/0211098.
TRUSTED COMPONENT SHARING BY RUNTIME TEST AND IMMUNIZATION FOR SURVIVABLE DISTRIBUTED SYSTEMS
Joon S. park', Pratheep chandramohan2, Ganesh ~ e v a r a j a nand ~ , Joseph ~iordano~ ',2,3~aboratory for Applied Information Security Technology (LAIST), School of Information Studies, Syracuse University; 4~nformationDirectorate, Air Force Research Laboratory
Abstract:
As information systems became ever more complex and the interdependence of these systems increase, the survivability picture became more and more conlplicated. The need for survivabiiity is most pressing for mission-critical systems, especially when they are integrated with other COTS products or services. When components are exported from a remote system to a local system under different administration and deployed in different environments, we cannot guarantee the proper execution of those remote components in the currently working environment. Therefore, in the runtime, we should consider the component failures (in particular, remote components) that may either occur genuinely due to poor implementation or the failures that occurred during the integration with other components in the system. In this paper, we introduce a generic architecture and mechanisms for dynamic componentfailure detection and immunization for survivable distributed systems. We have also developed a prototype system based on our approaches as a proof of our ideas.
Keywords:
Component Immunization; Recovery; Survivability.
1.
INTRODUCTION
Although advanced technologies and system architectures improve the capability of today's systems, we cannot completely avoid threats to them. This becomes more serious when the systems are integrated with
128
Joon S. Park, Pratheep Chandramohan, Ganesh Devarajan,
Commercial Off-the-shelf (COTS) products and services, which usually have both known and unknown flaws that may cause unexpected problems and that can be exploited by attackers to disrupt mission-critical services. Usually, organizations including the Department of Defense (DoD) use COTS systems and services to provide office productivity, Internet services, and database services, and they tailor these systems and services to satisfy their specific requirements. Using COTS systems and services as much as possible is a cost-effective strategy, but such systems-even when tailored to the specific needs of the implementing organization-also inherit the flaws and weaknesses from the specific COTS products and services used. Traditional approaches for ensuring survivability do not meet the challenges of providing assured survivability in systems that must rely on commercial services and products in a distributed computing environment3"29930. The damage caused by cyber attacks, system failures, or accidents, and whether a system can recover from this damage, will determine the survivability characteristics of a system. A survivability strategy can be set up in three steps: protection, detection and response, and recover$" 16. I*. TO make a system survivable, it is the mission of the system, rather than the components of the system, to survive. This implies that the designer or assessor should define a set of critical services of the system to fulfill the mission. In other words, they must understand what services should be survivable for the mission and what functions of which components in the system should continue to support the system's mission25.
2.
DEFINITION OF SURVIVABILITY The definitions of survivability have been introduced by previous
researcher^^^'^^. In this paper, we define survivability as the capability of an entity to continue its mission even in the presence of damage to the entity. An entity ranges from a single component (object), with its mission in a distributed computing environment, to an information system that consists of many components to support the overall mission. An entity may support multiple missions. Damage can be caused by internal or external factors such as attacks, failures, or accidents. If the damage suspends the entity's mission, we call it critical damage (CD), and if it affects overall capability, but the mission can still continue, we call it partial damage (PD). Since we believe survivability is a mission-oriented capability, there are basically three abstract states of the system: normal, degraded, and suspended. A system is in the normal state (So) when it is running with full capability. It is in the degraded state (S1)when it is running with limited capability because of PD, which does not suspend the overall mission. Finally, the system is in the
Trusted Component Sharing by Runtime Test und Irnmunizationfor ...
129
suspended state (S2) when it cannot continue its mission because of CD. When partial recovery (PR) occurs to an infected component, only the mission-related service is recovered, so the service is still in a degraded mode with limited capacity. When there is a total recovery (TR) such as that resulting from component substitution, service is provided at full capacity. As understood intuitively, PR and TR on So, PD and PR on S1, and PD and CD on S2 do not change their current states. From the survivability point of view, we may put up with partial damages (PD) on the system as long as the mission carries on. We may simply insulate the damaged components from others instead of recovering them, although the performance of the overall system may degrade. However, if the damage is so critical that the system cannot continue its mission, we must recover the damaged components as soon as possible in order to continue the mission. We describe the concept of survivability using a finite state machine. Abstractly, we can consider the damages and recovery actions as inputs to a survivable entity. Furthermore, we can classify the outputs of the entity into two abstract cases, one for the outputs when the mission performed (M) successfully, and one for the outputs when the mission failed (F). This generates Table 1, which shows the transitions and outputs for each pair consisting of a state and an input. Based on this table, we generate a finite state machine in Figure 1. Table I . State Table for Survivable Systems Transition Function ( f )
State (s)
Next State Input (I)
Output Function (g) Output ( 0 ) Input (I)
The finite-state machine M = (S, I., 0, f. g, so) consists of a finite set S of states (where So is an initial state), a finite input alphabet I, a finite output alphabet 0, a transition function f that assigns each state and input pair to a new state, and an output function g that assigns each state and input pair to an output. In this state diagram, we have three states (normal state (So), degraded state (S,), and suspended state (Sz)), four types of inputs (partial damage (PD), critical damage (CD), partial recovery (PR), and total recovery (TR)), and two outputs (when mission performed (M), and when mission failed (F)). To continue the mission, the system must stay in either So or S1. Some strict missions do not allow the critical components to stay even one moment
Joon S. Park, Pratheep Chandramohan, Ganesh Devarajan,
130
in the suspended state (S2) until the mission is completed. However, in reality, we believe most missions may allow critical components to stay in the suspended state (S2) for a moment until they are recovered and the state is changed to the degraded state (S,) or normal state (So). TR, M
Start
<States> So Normal State
S1 Degradedstate S2 Suspended State
PD Partla1 Damage CD Critical Damage P R Partial Recovery TR Total Recovery
M Successful Results F Failed Results
Figzrre I . Abstract State Diagram for Survivable Systems
We could decompose S1 and S2 into sub-states to represent detailed transitions based on the actual missions and applications described in2'. In this paper, however, we introduce a generic approach to describe the concept of survivability with the abstract inputs, states, and outputs. We believe the three states (So, S,, and S2), the four kinds of inputs (PD, CD, PR, TR), and the two kinds of outputs (M, F) can represent the state transitions of a survivable entity based on our mission-oriented survivability definition.
3.
RELATED WORK
3.1
Black-box and white-box testing
Currently, existing technologies for identifymg faulty components are more or less static in nature. One of those approaches employs black box testing for the components. In this technique, the behavioral specification2 is provided for the component to be tested in the target system. The main disadvantage of this technique is the specifications should cover all the detailed visible behavior of the components, which is impractical in many
Trusted Component Sharing by Runtime Test and Immunization for ...
131
situations. Another approach employs a source-code analysis, which depends on the availability of source code of the components. Software testability analysis35 employs a white-box testing technique, which determines the locations in the component where a failure is likely to occur. Unlike black box testing, white box testing allows the tester to see the inner details of the component and later help him to create appropriate test data. Yet another approach is software component dependability a ~ s e s s m e n ta~ ~ modification , to testability analysis where each component is tested thoroughly. These techniques are possible only when the source code of the components is available.
3.2
Fault injection
In the past'9 we have employed a simple behavioral specification utilizing execution-based evaluation. Their approach combines software fault injection'' 24' 33' 34 at component interfaces and machine learning techniques to: (1) identify problematic COTS components; and (2) understand these components' anomalous behavior. In their approach of isolating problematic COTS components, they created wrappers and introduced them into the system under different analysis stages to uniquely identify the failed components and to gather information on the circumstances that surround the anomalous component behavior. Finally, they preprocess the collected data and apply selective machine learning algorithms to generate a finite state machine for better understanding and increasing the robustness of the faulty components. In other research7 the authors have developed a dynamic problem determination framework for a large J2EE platform, employing a fault detection approach based on data clustering mechanisms to identify faulty components. This research also employed a fault injection technique to analyze how the system behaves under injected faults.
3.3
Bytecode instrumentation
Performing fault injection analysis and providing immunization to the components either by rewriting the existing code or by creating additional wrappers is a non-trivial task when the source code for the component is not readily available. Source code may not be available at all when we are dealing with COTS components and externally administered components downloaded dynamically in runtime at local machme. This is an issue that needs to be addressed before proceeding further. Providing immunization and performing fault injection at the component interfaces require modification of the component code; however, we assume that the source
132
Joon S. Park, Pratheep Chandramohan, Ganesh Devarajun,
code is not available in a large disturbed application. Instead, we provide the immunization to the runtime code (e.g., JAVA Bytecode) by extending the code instrumentation technique5.6, 8' lo, 15' ". Instrumentation techniques have previously been used for debugging purposes; to evaluate and compare the performance of different software or hardware implementations such as branch prediction, cache replacement, and instruction scheduling; and in support of profile-driven optimizations3'93 ' I ' 22.
4. 4.1
RUNTIME COMPONENT TEST AND IMMUNIZATION Generic system architecture
Figure 2 shows the generic architecture of our component failure detection and immunization system. It consists of a Monitoring Agent, an Immunization Agent, and a Knowledge Base. The monitoring agent is further divided into two subsystems: the fault injection subsystem and fault detection subsystem. Before a component is run on a host (especially a mobile component downloaded from another machine under different administration), the fault injection subsystem injects faults into the component, while the fault detection system analyzes component behavior in response to the injected faults. The component's internal structure information, such as method interface, arguments, local variables, etc., is accessible in runtime; thus, this information can be used in the dynamic component analysis. If there is no abnormal behavior, the monitoring agent allows the component to run in the local machine. For the performance reason, we can finish this analysis with the local components and fix the failures in the source codes before the operation starts (if the source codes are available). However, this is not possible for the remote components because their source codes are usually not available to the local machines. When the monitoring agent detects abnormal behaviors in the mobile component through the fault injection analysis, the fault detection subsystem identifies the reason for failure and informs the immunization agent to immunize the faulty component accordingly. The immunization agent builds and deploys immunized components to the target system. The immunization agent possesses a knowledge base that consists of a list of procedures for how to provide immunization for component failures. The immunization agent provides immunization and increases the survivability of the faulty components. Basically, there are two options to increase the survivability of the vulnerable components and to
Trusted Component Sharing by Runtime Test and Immunization for ...
133
make it more robust12: (1) inform the vendor of the software problems and wait for a patch; or (2) immunize the components with wrappers or instrument the faulty methods with updated and modified methods for more robust behavior4,26. The first technique is not feasible for dynamic runtime recovery from errors; consequently, we have adopted the second approach to provide immunization and increase the survivability of vulnerable components. rebu,lds t h e faulty component b y p i o n d ~ n ggenerlc or spec,nc l m m u n l z a f l o n fa the components %.
immun,zation
---
knobwd:2e
CO"'","S solutlorl t o , m m u n i z e t h e components for paiflculai attack s c e n r r , o s
Host Machine
.
M o n l t o r l n y Agent
M o n l f o r l n y agent incorporates t h e Fault l n p c t l o n module t o inject faults and Fault Detectsun module t" help analyze a n * d e t e c t the faults
Figure 2. Component Failure Detection and Immunization
4.2
The strategy
Figure 3 summarizes the steps involved in the entire process of detecting and immunizing faulty components. When we download a component from the remote location we perform the first test to determine if there are any dependent components. If so, we also download the dependent component. The component that is downloaded is an executable file for which we don't have the source code. By using an additional tool in runtime (e.g. Jikes B T ' ~ for JAVA bytecode), however, we can determine most of the intricate structure details of the component that we have downloaded. The test as well determines the structure of the code (including the data flow and the interdependencies of the functions inside the component) that is required to do a runtime test in the local environment. Then, we go into the next phase of monitoring the component performance. In the next phase we inject the faults and observe the performance of the component. The fault injection module injects test inputs (faults) and analyses the behavior of the component. Different machines (or applications) may have different fault injection modules based on their test criteria. For
Joon S. Pavk, Pvatheep Chandramohan, Ganesh Devavajan,
134
instance, one module may test internal failures, while another may test the robustness against cyber attacks. After the test inputs are injected we collect evidences and reasons for the failures, specific methods, classes that are affected. If there are any failures detected we check if we can provide some immunization to that failure from the knowledge base that we have built and updated regularly. If we have a specific solution for the failure we provide it from the knowledgebase, otherwise we provide it a generic i m m ~ n i z a t i o n ~ ~ ' 28. After the immunization is done we send the immunized component to the monitoring phase again. Now if the component is not having any problem we go to the next phase where we see if all the fault injections are performed and the component is functioning without any problem then our goal is achieved. However, if there is any problem in the monitoring stage after the immunization we may simply drop the component off.
Download
Component Download
dependant component
NO
Monltoi
components
1 pelrorm Fault ln,ecton
I
],::.::-_ *-
Faults 1
Fully Tested?
Figure 3. Strategy for Identifying Component Failures and Immunization
We can provide component immunization in runtime by either class-level modifications or method-level modifications. By class-level modification the references to the original class definitions are replaced by another subclass
Trusted Component Sharing by Runtime Test and Immunization for ...
135
of the original class. By method-level modification, we modify some of the runtime (executable) code in the original method by adding new runtime code (i.e. Java bytecode in our implementation) or deleting some runtime code or both at the same time. The latter provides more flexibility to build more powerful immunized class. At the same time method level modification is more difficult to implement than class level modifications because it involves direct modification of already existing Java bytecode whereas the class-level modification just involves rearranging references in the class file. The main advantage of using method level instrumentation techniques is that all the modifications are transparent to other components, which make calls to the modified components because the semantics and syntax are still maintained after modifications.
PROTOTYPE DEVELOPMENT Although the detailed techniques for component-failure detection and immunization are slightly different based on the programming languages, applications, and local policies, we believe our approach is applicable to most of distributed systems, which require survivability. We focus on the component failure scenarios here, but we believe our approach can be extended with cyber attacks. In our experiment, we detect component failures such as naming collisions, infinite loops, multi-threading problems, and array out-of-bound problems, and successfully immunized them in runtime so that the component's service can continue in a reliable manner. In the following description, we mainly concentrate on the problems of naming collisions because they cannot be rectified in the programming time and this particular paper has a space constraint. The other problems might be avoided when the programmer takes extra care during programming. However, we still need to check those problems in a remote component during runtime under a strict component-sharing policy.
5.1
Detection and immunization of naming collisions
When we perform tests for a local component, naming collision across other spaces cannot be detected. However, when we perform the test after the component is downloaded from a remote machine and integrated with local components there can be naming collisions occurring. There are possibilities that two or more components, which are being integrated together, might have the same variable name or even within the same component the same variable name can be used in different contexts. When the client program tries to access these variables there are possibilities that it might get the wrong value.
Joon S. Park, Pratheep Chandrarnohan, Ganesh Devarajan,
136
Integration After downloading Remote Organization1
Remote Organization2 I
par:,oge
:iar-ior:ii.is;i?r
pubilc class ComponentA { publ~cComponentAO {
r
return I
public statlc void maln(String0 args) { ComponentA componentA1 = new ComponentA() publlc statlc vold maln(Str1ngO args) { Component8 component61 = new ComponentBO.
1
L o c a l integrating Organization
package namecoillsion. publlc class NameColllslon { publlc static vold main(StrlngO args) { -'ComponentA compa = new remotea ComponentAi). System out prlntln("value of I from component A " + coinpa newname()). Component6 compb = new remoteb CornponsntB(). S p t e m out pnntln("value of I from component 8 " + compb newnameB0).
Figure 4. Detection and Immunization of Naming Collision
The downloaded component's internal structure information such as method interface, arguments, local variables, etc. is collected in runtime after analyzing the Java bytecode. Using the sti-ucture information and fault injection module, the local machine performs a fault injection test to determine all the return values in the component. This enables the local machine to figure out the architecture of the component and then to decide, which are all the function values required. Once the functions are selected the component is passed into the naming collision test stub where we test if there is any other component with the same variable name returning the value. If the testing says there are no variables with the same variable name then integration is taken to the next level. Now if there are variables with the same variable name from different component then our immunization code for t h s scenario will be creating an instance for the remote class. Using this instance we access the method name
Trusted Component Sharing by Runtime Test and Immztnization for ...
137
and through that we access the variable value(e.g. compa.newnameA()). The renaming process to avoid naming collision is to be performed mainly when we convert the private function to public function. The original source code writer's intension would have been that the function was a private function its scope is well defined and hence he can reuse the variable name. If there is a private function then this will not affect our processing as that variable it limited to the scope of that class. However, if there are two variables from the same component with the same name then we can go about changing the name as per the naming convention so that it becomes easier for the programmer who is working with the source code generated from the bytecode to differentiate from the other common variable named item. The main advantage of this system is that we can get access to the variables which where initially not possible to access and then by renaming them we are able to distinguish between the two similarly name variable. This as well helps in the optimal code re-usage. In reality, performing instrumentation is a non-trivial task because it involves precision handling of instructions. In most of the cases the instrumentation requires dealing with intermediate-level code (e.g., Java bytecode) or low-level code (e.g., Assembly), which requires ultra care when modifying these kinds of code. Basically our principle can be applied to more complex problems but the complexity of the immunization code increases quite considerably when dealing with complex problems. An important point should be noted here that it is not always possible to apply immunization by changing the code (Java bytecode in this case). In some cases the reason for the failure is not known even after performing thorough fault injection analysis. In other cases code segments can be inherently complex to be discerned for further modifications (immunization). In such scenarios specific immunization is not possible, so we need to provide generic immunization by rebuilding the faulty component or deploying it in a new conducive environment. As depicted in Figure 4, we download two components from remote location A and remote location B. After the download we first modify the package name so that the downloaded component can also become a part of the new component being developed. Supposing the programmer is interested in the method newnameB() after loolung into the component's architecture. He simply modifies the private method to a public method and then finds out that there exists a naming collision within the same component. In order to access the variable value the method has to be made public. Now that the fault injector has made the method public with a return value, he can access that variable value by simply creating an instance of the remote object in the local component and hence being able to access that newly converted public methods' return variable value.
138
Joon S. Park, Pratheep Chund~arnohun,Ganesh Devarujan,
Evaluation results We implemented the prototype for the component evaluation phase of our fault detection and runtime immunization approach to determine the existence of naming collisions. After we generate the source codes we perform three stages of tests to: (1) identify the variables in use; (2) ascertain the scope of each variable; and (3) determine if naming collisions will occur when their respective intermediate values are accessed. There are two scenarios of accessing the variables in other components. Suppose component A tries to access a variable "i" in component B, and they both are in the same package, where class1 is in component A and class2 is in component B. The procedure followed to access that variable is by classname.methodname.variablename-in our example, class2.func2.i. Through this method component A will be able to access the variable "i" in component B. Still, there is a possibility that the variable "i" may not be accessible as it could be in the private member function of the component B. For this reason, we need to extend the scope of that method to public. When we extend the variable's scope there is a chance that there is another variable i>) in the same component, which is globally defined or within the same method with another initialization to the same variable. Consequently, the accessing component might be getting the last assigned value to that variable. In order to access the initial value, we will have to assign different names to those variables that cause naming collisions. The second scenario occurs when a component is trying to access the variables from different components. Suppose component A is accessing the variable "i" from component B, as well as variable "in from component C. The first step for the component to access the variables from different components will be to put them all into the same package. After this, we have to check the scope of the variable to determine if it is possible for another component to access this variable; if not, then we will have to extend the scope of the variable and then verify it doesn't cause any naming collisions, and then provide access to the component attempting to access that variable. Suppose class 2 is in component B and class 3 is in component C, and methods func2 is in class2 and h n c 3 is in class3, to access the value of the "i" in component B, the code will be class2.func2.i. Similarly, the variable "i" in component C can be accessed using the code class3.func3.i. To avoid further confusion, we can assign these variables to different names after abstracting them in component A so that naming collisions do not occur in the root component. (6
'
Trusted Component Shaving by Runtime Test and Immunization for ...
139
Table 2. Namine Collision Results
Number Number Total of of Number Components Components of Tested with variables Naming reused Collision
Naming collisions without Scope Extension
Naming Collisions with Scope Extension
Detected and Immunized
Table 2 shows the test results for the components that were tested in our experiment. Most of the components that where tested were downloaded from IBM's Alpha works website, while the rest were from various other sources. Each component has a minimum of 100 lines of code or more. The total number of components tested was 81. Out of the 81 components, 37 components experienced naming collision problems, both before and after their respective scopes were extended. A total of 104 variable names were reused in different scopes in the various components. Out of these 104 variables, 30 variables had scopes that were not well defined, causing naming collisions even without an extension in scope. There were a total of 36 variables that caused naming collisions after their scope was extended. We were able to detect all 66 instances where variables caused naming collisions.
6.
CONCLUSION AND FUTURE WORK
Although many current systems are being developed using Java, there are also many other distributed software components developed using other technologies such as Windows C O M ' ~(e.g., DLLs), Unix Shared Libraries (e.g., SO files), and even .Net libraries. The .Net platform is relatively new and is a major competitor for Sun's Java. The .Net uses Intermediate Language (IL), which is very similar to the Java Intermediate Bytecode and uses a Common Language Runtime (CLR) also very similar to Java Virtual Machine (JVM) to load the code in to memory. Since .Net and Java share common object oriented model, memory models, semantics and architecture. Our instrumentation and immunization techniques can be directly applied with little modifications. In contrast, DLLs and Shared Libraries are quite different from the bytecode (intermediate code) because these are libraries in assembly code (low level). In the past there has been some research conducted in this area, and in13 they have formulated a technique to intercept
140
Joon S. Park, Pratheep Chandramohan, Ganesh Devarajan,
and instrument COM applications. We can apply our methodologies theoretically to these platforms but in reality we may face some technical challenges. Instrumenting Windows COM applications is more difficult than instrumenting Java bytecode because of the inherent complexity of the COM technology. Our future goal is to apply our current immunization techniques to other platforms by overcoming these complexities. Furthermore, we consider that cyber attacks may involve tampering of existing source code to include undesired functionality, replacing or modifying a genuine component with a malicious one. Software components can be subject to two major kinds of attacks, (1) An attack involving the modification of existing source code to introduce additional malicious functionality, and, (2) An attack involving the introduction of a malicious piece of code independent of the original program that can be started when the original component is used and run independent of it (e.g. a Trojan Horse). Our goal is to detect this unauthorized integrity change in code by extending our previous work3* and extract the malicious parts out of the component while retaining its originally expected functionality.
ACKNOWLEDGMENTS This work was supported by the US Air Force Research Lab's extended research program, based on the SFFP (Summer Faculty Fellowship Program) award in 2004, sponsored by the Nation Research Council (NRC) and the Air Force Office of Scientific Research (AFOSR).
REFERENCE 1. Dimiter R. Avresky, Jean Arlat, Jean-Claude Laprie, Yves Crouzet. Fault Injection for the Formal Testing ofFault Tolerance. The Twenty-Second Annual International Symposium on Fault-Tolerant Computing, July 8-1 0, 1992: 345-354. 2. Abadi and L. Lamport. Composing Specications. ACM Transactions on Programming Languages, l5(l): 73-1 32, January 1993. 3. Anant Agarwal, Richard Sites and Mark Horwitz. ATUM: A New Techniquefor Capturing Address Traces Using Microcode. In Proceedings of the 1 3 ' ~ Inteinational Symposium on Computer Architecture, 119-127, June 1986. 4. Amitabh Srivastava and Alan Eustace. "ATOMA System for Building Customized Program Analysis Tools." In Proceedings of the SIGPLAN '94 Conference on Programming Language Design and Implem~ntation(PLDI), pages 196-205, June 1994. 5. BCEL - Bytecode Engineering Library httu:~:bcel.sourcefor~e.net/
Trusted Component Sharing by Runtime Test and Immunization for ...
141
6. BIT: Bytecode Instrumenting Tool httn:l/www.cs.colorado.edu/--1~a~~lee~BITii11dex.l1tml 7. M. Chen, E. Kiciman, E. Brewer, and A. Fox. Pinpoint: Problem Determination in Large, Dynamic Internet Services. In Proceedings of the IEEE International Conference on Dependable Systems and Networks, DSN, 2002. 8. Ajay Chander, John C. Mitchell, Insik Shin. Mobile Code Security by Java Bytecode Instrumentation. In Proceedings of the 2001 DARPA Information Survivability Conference & Exposition (DISCEX 11), pages 1027-1040, Anaheim, CA, June 2001. 9. Brian Bershad et al. Etch Overview. httn:/letch.cs.washington.edu/ 10.James R. Larus and Eric Schnarr. "EEL: Machine-Independent Executable Editing." In proceedings of the SIGPLAN '95 Conference on Programming Language Design and Implen~entation(PLDI), pages 29 1-300, June 1995. 11.Susan J. Eggers, David R. Keppel, Eric J. Koldinger, and Henry M. Levy. Techigzresfor efficient Inline Tracing on a Shared-Memory Multiprocessor. In Pro-ceedings of the 1990 ACM Sigmetrics Conference on Measurement and Modelings of Con~puterSystems, 8(1), May 1990. 12. A. Ghosh, J. Voas. Inoculating Software for Survivability. Communications of the ACM, July 1999. 13.Galen Hunt and Doug Brubacher. Detours: Binary Interception of Win32 Functions. Proceedings of the 3rd USENIX Windows NT Symposium, pp. 135- 143. Seattle, WA, July 1999.USENM. 14.Galen Hunt and Michael Scott. Intercepting and Instrumenting COMApplications. Proceedings of the Fifth Conference on Object-Oriented Technologies and Systems (COOTS199),pp. 45-56. San Diego, CA, May 1999. USENIX. 15.Jikes Bytecode Toolkit - IBM Alpha Works httu://www.alphaworks.ibm.com/tech/iikesbt. 16. S. Jajodia, C. McCollum, and P. Ammann. Trusted Recovery. Communications of the ACM, 42(7), pp. 71-75, July 1999. 17.JOIE - The Java Object Instrumentation Environment httu:/!www.cs.duke.edu/ari:ioie/ 18.5. Knight, M. Elder, and X. Du. Error Recovery in Critical Infrastructure Systems. Proceedings of the 1998 Computer Security, Dependability, and Assurance (CSDA'98) Workshop, Williamsburg, VA, November 1998. 19.G. Kapfhammer, C. Michael, J. Haddox, R. Coyler. An Approach to Identlhing and Understanding Problematic COTS Components. The Software Risk Management Conference, ISACC 2000. 20.5. Knight and K. Sullivan. Towards a Definition ofSzrrvivability. Proceedings of the 31d Information Survivability Workshop (ISW), Boston, MA, October 2000. 2 I .P. Liu, P. Ammann, and S. Jajodia. Rewring Histories: Recoveringfrom Malicious Transactions. Distributed and Parallel Databases, 8(1), pp. 7-40, January 2000. 22. James R. Larus and Thomas Ball. Rewriting Exect~tableFiles to Measzrre Program Behavior. Software, Practice and Experience, 24(2): February 1994. 23. H. Lipson and D. Fisher, Survivability -- A New Technical and Business Perspective on Security. Proceedings of the New Security Paradigms Workshop (NSPW'99), Caledon Hills, Ontario, Canada, September 2 1-24, 1999. 24.Henrique Madeira, Diamantino Costa, Marco Vieira. On the Emzrlation of Software Faults by Sofhare Fault Injection. International Conference on Dependable Systems and Networks (DSN 2000). New York, New York, June 25 - 28,2000. 25.N. Mead, R. Ellison, R. Linger, et al. Survivability Network Analysis Method, SET Technical Report: CMU/SEI-00-TR-013, September 2000. 26.Amitabh Srivastava and David Wall. " A Practical Systemfor Intermodule Code Optimization at Link-Time."Journal of Programming Languages, vol 1, no 1, pages 1-18, March 1993. 27. Joon S. Park. Component Survivabilityfor Mission Critical Distributed Systems Technical P.eport, NRCiAir Force SFFP (Summer Faculty Fellowship Program), 2004.
142
Joon S. Pavk, Pvatheep Chandvarnohan, Ganesh Devavujan,
28.Joon S. Park and Pratheep Chandramohan. Component Recovery Approaches for Survivable Distributed Systems. 37th Hawaii International Conference on Systems Sciences (HICSS-37), Big Island, Hawaii, January 5-8,2004. 29.Joon S. Park, Pratheep Chandramohan, and Joseph Giordano. Survivability Models and Implementations in Large Distributed Environments. 16th IASTED (International Association of Science and Technology for Developn~ent)Conference on Parallel and Distributed Computing and Systems (PDCS), MIT, Cambridge, MA, November 8-10, 2004. 30. Joon S. Park, Pratheep Chandramohan, and Joseph Giordano. Component-Abnormality Detection and Immunization for Survivable Systems in Large Distributed Environments. 8th IASTED (International Association of Science and Technology for Development) Conference on Software Engineering and Application (SEA), MIT, Cambridge, MA, November 8-10,2004. 3 1. Joon S. Park and Judith N. Froscher. A Strategyfor Information Survivability. 4th Information Survivability Workshop (ISW), Vancouver, Canada, March 18-20,2002. 32.Joon S. Park and Ravi Sandhu. Binding Identities and Attributes Using Digitally Signed Certificates. 16th IEEE Annual Computer Security Applications Conference (ACSAC), New Orleans, Louisiana, December 11-15, 2000. 33.Ted Romer, Geoff Voelker, Dennis Lee, Alec Wol-man, Wayne Wong, Hank Levy, Brian Bershad, and Brad Chen. Instrumentation and Optimization of Win32Lntel Executables Using Etch. In Proceedings ofthe 1997USENIX Windows NT Workshop. August 1-7, 1997. 34. Jeffrey Voas. Sofiware Fault Injection. IEEE Spectrum, appeared in 2000. 35. Jeffrey Voas, Keith W. Miller, and Jeffrey E. Payne. Pisces: A tool forpredicting sojware testability. In the Proceedings of the Symposium on Assessment of Quality Software Development Tools, pages 297-309, New Orleans, LA, May 1992. 36. Jeffrey Voas and Jeffrey Payne. Dependability certlficarion ofsoftware components. Journal of Systems and Software, 2000.
DESIGN AND IMPLEMENTATION OF TPM SUP320
Jiangchun Ren, Kui Dai, Zhiying Wang, Xuemi Zhao and Yuanman Tong School of Computer, National University of Defense Technology, Changsha, Htman, P.R.China, 41 0073
Abstract:
Security of computer in network is becoming more and more challengeable. The traditional way of applying a common smart card to application can not meet the requirement of high degree of security in critical systems. Trust Computing Group (TCG) drafts out specifications on trust computing platform, which have been acknowledged by specialists in this field. Following these specifications, we designed and implemented a chip named SUP320 with SOC technology. This paper gives the chip's hardware architecture, firmware modules and method for low power. Performance of SUP320 is tested in the end. We find that SUP320 is better than traditional smart cards in both security and efficiency.
Computer systems in network are often attacked by viruses and trojan horses, the basal platform can not build up a trust and secure environment for applications on it. Most systems resist hacker's attack by technologies such as digital certificates and public key infrastructure to authenticate participants and provide cryptographic keys. But the arithmetic of cryptography reduces system's efficiency heavily. A smart card then is used to accelerate the arithmetic by hardware component. The smart card surely increases the system security to some extent, but it can not meet the requirement of high degree of security. For it has some okvious disadvantages: firstly, the comrnimication protocol between the card
144
Jiangchzm Ren, Kui Dai, Zhiy ing Wang, Xuemi Zhao and . ..
and the host is too easy that users' privacy may be hijacked in the middle; Secondly, the card's processor and memory are isolated and just connected by wires, the data in memory is possibly decrypted by hacker who can steal the card; and thirdly, the mode of smart card is single, administrator can not apply different security policies to different applications. Just for these reasons, Compaq, IBM, Intel, HP and Microsoft launched and formed Trust Computing Platform Alliance (TCPA, renamed TCG later), TCG drafts out a specification on the subsystem for security in universal The specification suggests a Trust Computer Base (TCB) should be used in the platform and the whole system's security infrastructure should be built up on it. The TCB combines a highly secure chip with its outside circuit. The secure chip is often named Trust Platform Module ( T P M ) [ ' ~ [ ~ ~ [ ~ ' . In this year, we designed and implemented a TPM chip named SUP320, and designed an architecture of subsystem which can be embedded in the common computers. Platforms with this subsystem can get assistance for security in all kinds of levels: hardware, OS kernel and application[51.
User Space
Kernel Space
4 I
Hardware
f
I
Figzrre I. Framework of Secure Subsystem
The subsystem is composed of physical chip SUP320 including outside circuitry, device driver, Trust Platform Service (TPS) and libraries assisting for applications. Among those four levers, SUP320, a system on chip is the core of the subsystem. SUP320 has two kinds of important functions: accelerating security arithmetic and intercommunicating with host according to a robust protocol (explained in the broken line)["[71.This paper firstly presents the hardware architecture of SUP320; then describes the firmware
Design and Implementation ofTPMSUP320
145
modules in detail; following that, introduces the method for low power; Finally, tests the chip's performance.
2.
HARDWARE ARCHITECTURE
The SUP320 was implemented by O.18um 1P6M CMOS technology, Its die size is 4 . 9 ~ 4 . 9mm2, The cost of power is about 0.6W. Its hardware architecture is presented in figure 2.
Figure 2. Hardware Architecture of SUP320
The core of SUP320 is a 32 bit RISC processor named "TengYue-I", which is designed by ourselves. The processor works well under frequency of 200 MHz, with a five-lever pipeline, an independent data cache and an instruction cache. Cache sizes are both 2K bytes. MMultp, AES, DES and SHA are co-processors, which accelerate arithmetic of RSAIECC, AES, DES and SHA. Because the operations of modular multiplication and modular power are frequently used in public-key arithmetic of RSA and ECC, we design a co-processor "MMultp" to speedup operation of modular multiplication, then speedup operation of modular power based on that. It is easy to realize the arithmetic of RSA (the length of key can be 512bit, 1024bit and 2048bit) and ECC (the length of key can be 160 bit and 192 bit) by different procctdures[81'911'01.
146
Jiangchun Ren, Kui Dai, Zhiying Wang, Xuemi Zhao and ...
TRNG is a true random numbers generator which produces numbers through noises in physical matter. These true random numbers are used in the module of communication protocol and public-key arithmetic to get big modular number pairs. There are three kinds of memories on the chip: FLASH, EEPROM and S U M . The size of flash is 128K bytes, in which the whole firmware is stored. The size of EEPROM is 128K bytes too, in which all kinds of keys and privacy data are stored. The SRAM's size is 16K bytes. It acts as a work room for the system on chip. These memories are all managed by a memory controller. Peripheral interfaces include UART, GPIO, USB and LPC (Low Pin Count). LPC is designed according to TCPA specification, which can be connected with Intel CPU'~'.Other interfaces are designed to improve the flexibility of this chip so that SUP320 can also be used in other devices such as USB-KEY, secure disk and etc.
FIRMWARE The firmware of SUP320 plays a critical role in the SOC. It is composed of many modules such as initialization, self test, interfaces abstract, arithmetic accelerating, community protocol, keys management, session management and method for low power. The ability of real-time and high efficiency always affects the system on chip to great extent. There are two approaches to this problem: one is to clip real-time OS such as RtLinux; another is to code sub-procedure for each module and set them up. The first method has an advantage that programmer can use all kinds of functions supported by OS and ignore the work of task scheduling, but the code size of OS is often too big. The second method has advantage inversely. Our chip would be used in a complex platform, efficiency is very important to the host. And the size of memory on chip is limited. For these reasons, we adopt the second method to organize the firmware. The firmware's architecture is presented in figure 3. The main job of SUP320 is to wait for commands and do them, so the module of communication protocol is the schedule center of firmware. Command issued by outer entity enters the chip through the module of interfaces abstract, which is aroused by interrupts from peripheral interfaces. The module of communication protocol checks the integrity of command and explains it according to TCPA specification. After that, it arouses other modules to run. The result of operation is also sealed and sent out by it. In the following section, we give more details of some critical modules.
Design and Implementation of TPMSUP320
@-+&I
Initalize v
Self-Test
LPC Int
Interfaces Abstract Keys Manage
Manage
Low Power
Mmultp
AES
Figure 3. Firmware Modules
3.1
Interfaces Abstract
In operating system, all kmds of interfaces to peripheral devices are described abstractly as file interface. Sending and receiving data from device by applications are just like writing and reading data from a special file. The module of interfaces abstract uses a kind of data structure to describe communicating data in peripheral interfaces. The data structure is presented in figure 4.
I - p
Block Length
I
,
I
Valid Data Defined Max Length
Reserved
I
-9
Figure 4. Data Structure Described In Interface Abstract Module
SUP320 has lots of peripheral interfaces, so it can be used in devices such as USB-KEY and secure disk. The module of interfaces abstract lets system on chip pay more attention to data processing but not data receiving
148
Jiangchun Ren, Kui Dai,Zhiying Wang, Xuemi Zhao and ...
or sending. Of course, the chip will use only one interface in a practical device, other interfaces is disabled. However, our method of abstracting interfaces could let the firmware reliable in a same copy for different cases.
3.2
Keys Management
The module of keys management is the securest module in SOC. Keys can been classified into two groups by their functions: stored keys and signing keys. They can also been classified by their capability in migration into two groups: migratable keys and non-migratable keys. Keys have the following attributes: 1. Some key is bound to a chip or a platform; 2. Each key has a multi-lever access control, one key may not be open to all processors in the platform; 3. All keys are managed in hiberarchy. Each key has a blob and naturally leads to a tree. The root of tree is the "Storage Root KeyM(SRK)which is generated inside the TPM and is non-migratable. Table I. Data Structure of Key Blob ID ClassID Content
Authorize
Parent ID
Next ID
To describe key blob in the key tree, a data structure presented in table 1 is adopted. All keys are managed in a thread tree (figure 5 ) .
Figure 5. Key Tree
Design and Implementation of TPMSUP320
149
The key tree has a sub-tree marked "root". It managed all the migratable keys in the chip. The "root" key is assigned by user's command, for he always wants to set a "password" to protect his privacy. The module of keys management is composed of three parts: keys generator, keys storage management and keys import and export. In asymmetrical arithmetic, the true random number generated by TRNG is used to produce big modular number pairs, and the user's public key and private key are produced by procedure according to them. In symmetrical arithmetic, the true random number is directly used for key. Key is managed by sub-module of keys storage management as soon as it is produced. Only public key and key of symmetrical arithmetic which are wrapped by parent key can be exported from chip. SOC provides two basic functions: Export-key and Load-key. In theory, SUP320 can produce unlimited keys through its capability of key generating. But the size of memory on chip is limited, we just design the chip as a portal for keys management. The host must use the two functions to maintain consistency of key view inside and outside the chip.
3.3
Session Management
The module of session management maintains the session information of processes in platform. Any process that wants to intercommunicate with SUP320 must start a session at the very start. A session is discarded when the conversation ends. But we must notice that the number of sessions is changing momentarily. There are lots of processes using the chip in the host, the capability of real-time must be considered. In this project, a list is adopted to manage the session handles. A new session is put ahead of the list when it is created, and a time-out session or an unused session is deleted from the list soon. When looking for a session which belongs to a special process, system searches the list from the head to the end. Other information belonging to a session is saved with the session handle.
3.4
Communication Protocol
The module of communication protocol does two kinds of things. One is to restrict SUP320 to explain input command in specific format. Another is to perform access control on the command according to current session, function and target key. Different commands have different parameters. We don't intend to describe the format of each command. But each command includes fields such as TAG, Command ID, session information, key information, authorization data, nonce and etc. Table 2 shows most fields of a command.
150
Jiangchun Ren, Kui Dai, Zkying Wang, Xuemi Zhao and ...
Table 2. Fields o f Command TCG TAG Paramsize
CMD ID
KeyHandle
JnArg
Nonce
.. .
SUP320 provides two protocols for authorizing the use of entities without revealing the authorization data on the network or the connection to the SUP320. The first protocol is the "Object-Independent Authorization Protocol" (01-AP), which allows the exchange of nonces with a specific SUP320. Once an 01-AP session is established, its nonces can be used to authorize any entity managed by the SUP320. The session can live indefinitely until either party request the session termination. The TPM-OIAP function starts an 01-AP session. The second protocol is the "Object Specific Authorization Protocol" (0s-AP)". The 0 s - A P allows establishment of an authentication session for a single entity. The session creates nonces that can authorize multiple commands without additional session establishment overhead, but is bound to a specific entity. The TPM-OSAP command starts the 0 s - A P session. To depict problem easily, we suggest: inParamDigest is the result of the following calculation: SHAl (ordinal, inArg); outParamDigest is the result of ordinal, outArg); the following calculation: SHA 1(returncode, inAuthSetupParams refers to the following parameters, in this order: auth authLastNonceEven,nonceOdd, continueAuthSession; Handle, refers to the following parameters, in this order: auth OutA~~thSetupParams Handle, nonceEven, nonceodd, continueAuthSession. Then steps of 01-AP list below: 1. The caller sends command TPM-OIAP to start a conversation with SUP320; 2. SUP320 creates a new session, gets a new authHandle, associates session with authHandle. Gets a true random number to use for authLastNonceEven, saves authLastNonceEven with authHandle. Returns both authLastNonceEven and authHanle to the caller. 3. The caller receives anthHandle and authLastNonceEven and saves them. Gets a true random number to use for nonceodd, computes inAuth = HMAC(Key.usageAuth, inPararnDigest, inAuthSetupParams). Saves nonceodd with authHandle, sends a command TPM-example, whose message include nonceodd, authHandle and inAuth. 4. SUP320 receives command TPM-example, verifies authHandle is valid, retrieves authLastNonceEven from internal session storage, computes HM = HMAC (key.usageAuth, inParamDigest, inAuthSetupParams). Compares HM to inAuth, if anything is ok, executes TPM-Example and creates returncode. Generates nonceEven to replace authLastNonceEven in session. Sets resAuth = HMAC ( key.usageAuth,outParamDigest, outAuthSetupParams). Returns autput parameters, message returned
Design and Implementation of TPMSUP320
151
nonceEven, resAuth and continueAuthSession. If includes continueAuthSession is FALSE, then destroys the session. 5. The caller saves nonceEven, HM = HMAC (key.usageAuth, outParamDigest, outAuthSetupParams). compares HM to resAuth. This verifies returncode and output parameters. 6. The caller can use key authHandle to a new key, just follows step 3 to step 5 until the command of Terminate-Session is executed. The difference of 0s-AP and OA-IP is that: OS-AP names the entity to which the authorization session should be bound. More detail information can be found in [I].
3.5
Self Test
The task of self test module is to test the state of hardware components according to the configure parameters when the chip initializes. System on chip reports error information and exits once it finds any component is bad. To test a component effectually, we choose typical test programs for different components. Get test results after execution completed, then we can judge the state of component by the results.
METHOD FOR LOW POWER The method for low power is paid more attention to the embedded system than any other problem. Although SUP320 has four co-processors, it nearly do not use two of them at the same time. So we can disable some coprocessor to reduce the cost of chip power when it is not been used. The module of Low Power just does this kind of things, it manages all the states of co-processors and enables or disables the co-processors on behalf of other modules. To simplify the problem, we do not put the true number generator into consideration, for the true number is frequently used in module of communication protocol. In the following, a sub-routine of key-pair generating in RSA arithmetic is used as an example: 1. After SUP320 having done self test, all co-processors are disabled; 2. SUP320 receives the command of Key-Pair generating, procedure of RSA initialization calls module for low power, who enables the coprocessor of MMultp; 3. When the operation finished, module for low power disables the coprocessor of MMultp in the end of procedure of RSA; 4. SUP320 stores the keys and returns result to the caller. The method is simple, but test result indicates that the cost of power is almost reduced by 50%.
152
Jiangchun Ren, Kui Dai, Zhiying Wang, Xuemi Zhao and ...
PERFORMANCE In a Pentium 2.4GHZ, Windows XP installed machine, SUP320 is tested by USB interface. We did some typical operations and compare efficiency of it with that of a common smart card, Compare results list in table 3. Table 3. Performance Test KeySize Function Smartcard Arithmetic N.A. 160 HASH SHA 3DES 3 *64 EncryptiDecrypt 1 OOMbps AES 128 EncryptiDecrypt N.A. 1024bit Sign 61s RSA 1024bit(e=216+1) Authentication 241s lhObitGF@) Sign N.A. ECC Authentication N.A. 16ObitGF(p) * The symbol "N.A." denotes the device has not this kind of function.
It is obvious that chip of SUP320 is better than a common smart card in both security and efficiency. It is a good choice to build up trust computing platform.
CONCLUSION Building up a secure subsystem based on a physic chip, the whole platform gets security assistance in all levers of hardware, OS kernel and application. We can build a secure system out of insecure environment. Chip of SUP320 is designed by SOC technology, which can bind data and programs together in one chip. It can be used in many fields such as TPM, PKI and etc. The hardware architecture, software modules and method for low power is recommendable to design the system on chip. In the following days, we plan to consider the problems on cooperation of chip and platforms such as PC, PDA etc.
ACKNOWLEDGMENTS The authors are extremely grateful to the members in trust computing group for their effort on the specifications. This research has been supported in part by The Chinese National Science Foundation(NSF 90104025).
Design and Implementation of TPMSUP320
REFERENCES 1. Trusted Computing Platform Alliance (TCPA), Main specification, February 2002. Version 1.lb. 2. Trusted Computing Platform Alliance (TCPA), PC Specific Implementation Specification version 1.O. 3. Trusted Computing Platform Alliance (TCPA), Trusted platform module protection profile, July 2002. Version 1.9.7. 4. Intel Low Pin Count (LPC) interface Specification Revision 1. l . 5. J.E.Dobson and B.Randell, Building Reliable Secure Computing Systems Out of Unreliable UnSecure Compinents, IEEE July 2003. 6. Ross Anderson, TCPApalladium frequently asked questions, http://www.cl.cam.ac.uk/ users/ja14/tcpafaq,html accessed 13 March 2003. 7. W. A Arbaugh, D J Farber, and J. M Smith. A secure and reliable bootstrap architecture, In Proceedings 1997 IEEE Symposium on Security and Privacy, pages 65-7 1, May 1997. 8. Jean-Francois, Design of an Efficent Public-key Cryptographic Library for RISC-based smart cards. Ph.D. Thesis, University Catholique de Louvain,May 1998. 9. Koc,C.K,Acar,T., Burton S.kaliski Jr, Analyzing and Comparing Montgomery Multiplication Algorithms, IEEE Micro 16(3):26-33, june 1996. 10. Tung, C., "Signed-Digit Division Using Combinational Arithmetic," IEEE Trans. On Comp., vol. C-19, no. 8, pp. 746-748, Aug, 1970.
MATHEMATICAL MODELS OF IP TRACEBACK METHODS AND THEIR VERIFICATION
Keisuke Ohmoril, Ayako ~ u z u k i ' , Manabu ~ h m u r o ' , Toshifumi ~ a i ~ , Mariko ~ a w a b a t a ,' Ryu at us hi ma' and Shigeru ~ i s h i ~ a m a ' ' N ~ Advanced T Technology Corp. Systems Development Unit,l-19-3, Nakacho, Musashino-shi, Tokyo, 180-0006, Japan; 2~atsushitaElectric Works, Ltd. Systems Technology Reserch Laboratory, 4-8-2, Shiba, Minato-ku, Tokyo 108-0014, Japan
Abstract:
IP traceback is a technology for finding distributed-denial-of-service (DDoS) attackers. Various IP traceback methods have been proposed. When a new method is proposed, a performance comparison with the conventional methods is required. In this paper, mathematical models of ICMP, probabilistic packet marking, hash-based, and Kai's improved ICMP method are proposed. The mathematical models proposed can be applied to arbitrary network topologies, and are applicable for evaluating the performance of a new traceback. The mathematical models are verified by comparing the theoretical values with actual measurements of a network of about 600 nodes.
Key words: ICMP traceback,; Probabilistic packet marking traceback; Hash-based IP traceback; Mathematical model
1.
INTRODUCTION
Distributed-denial-of-service attacks (DDoS attack) cause serious damage to the Internet community; programs for implementing such attacks are typically propagated using worms or viruses. Research and development to prevent such attacks is necessary. P traceback can look for the attack routes, even if the IP address of the attacker is forged. It is one technology that may be employed to defend a computer system from DDOS attacks. ICMP traceback', probabilistic
156
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro,..
packet marking traceback2, and hash-based traceback3 are typical IP traceback methods; new traceback methods are also being proposed. When a new traceback method is proposed, we need to compare the performance with the conventional IP traceback methods. Ideally, one would install the conventional IP traceback systems and evaluate the performance; however, the systems are difficult to install. Therefore, performance estimation by mathematical modeling becomes desirable. The conventional mathematical models4 apply to simple network topologies such as linear and binary trees. They are not applicable to arbitrary network topologies. In this paper, we propose mathematical models of typical traceback methods: ICMP traceback (iTrace), probabilistic packet marking traceback (PPM), and hash-based traceback. We also propose a mathematical model for improved ICMP traceback method, which does not use probabilistic packet sampling. These models can be applied to arbitrary network topologies and we show the validity of the mathematical models by comparing them with actual measurements of a large-scale verification network. This paper is organized as follows. We propose mathematical models of the IP traceback methods in Section 2. We present the verification method and a verification network in Section 3. We compare the theoretical values with actual measurements in Section 4. Finally we summarize our results and present areas for future research in Section 5.
2.
THE MATHEMATICAL MODELS
2.1
Summary of IP traceback methods
First, we present an overview of IP traceback. An IP traceback looks for DDoS attackers by examining the flow of attack packets. An agent of the IP traceback is sent to each router. It generates traceback information, which includes the packets that pass through the router. This traceback information is sent to a collector and is used for the traceback. An example of a traceback is shown in Fig. 1. V is a victim, and A l , A2, A3, A4 are attackers.The attackers A l , A2, A3, A4 attack the victim V through routers. For example, attack packets from the attacker A1 reach the victim through the edge e6, e3, and e l . Therefore, a trace back to the attacker A1 becomes possible when traceback information about e l , e3, and e6 is generated.
Mathematical Models of IP Traceback Methods and Their Verification
157
Figure I. Example of IP traceback
IP traceback methods may be divided into those that use probabilistic packet sampling, such as ICMP and probabilistic packet marking, and those that do not, such as hash-based traceback and improved ICMP traceback. In ICMP and probabilistic packet marking, traceback information is generated probabilistically for packets, both normal and attack packets. Therefore, the discovery probability of the attackers can be calculated from the generation probability of the traceback information about each edge of the attack routes. For example, the discovery probability Pr (A1 n A2 n A3 n A4) of the four attackers A l , A2, A3, A4 can be calculated with the Eq. (I), using the probability that traceback information is generated for the edge ei.
The hash-based traceback and improved ICMP traceback methods are not probabilistic packet sampling methods. They have no collector; a manager controls the agents on the routers. In hash-based traceback, an agent of each router calculates the hash value of every packet and registers it in a hash table. The manager asks agents whether they routed an attack packet using the hash value of the attack packet. The attackers can be found using the answers from the agents. In improved ICMP traceback, the manager sends a request packet asking the router to inform it if it routes an attack packet. The agent informs the
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro,. .
158
manager when the attack packet is routed. The manager decides where to send the next request packets using the link information of the routers.
2.2
ICMP traceback
2.2.1
Outline
An agent which generates traceback information is installed in each router. A traceback information collector is placed just before the victim. The agent generates an iTrace packet with a probability p (usually, one in 20000) for packets destined for the victim. The iTrace packet includes the original packet, and the collector looks for the attackers.
2.2.2
Implementation
Implementation is based on the ~nternet- raft'. In a normal ICMP traceback, a single iTrace packet including an attack packet means that the attack packet was routed down the edge. To reduce false positives, it was decided that two iTrace packets must include an attack packet before attributing the attack to the edge.
2.2.3
Mathematical model
We find the probability that the agent of a router generates two iTrace packets including the attack packet on an edge. Let p be the probability of generating an iTrace packet and N be the number of attack packets arriving on edge ei; then the probability of generating two or more iTrace packets becomes
Here (1-p) is the probability that no iTrace packets are generated and Np (1-p) N'l is the probability that only one iTrace packet is generated. We can Aj) of all the attackers by using the calculate the discovery probability Pr iTrace packet generation probability on each edge ei of the attack routes.
(n
~ r ( f i Aj) =
fi
Pr(ei)
Mathematical Models of ZP Traceback Methods and Their Verification
159
Changing the number of packets N in Eq. (2) and Eq. (3) allows us to calculate the discovery probability for different attack scenarios. Traceback time is calculated from the number of packets found with the formula Eq. (3). For example, we may apply Eq. (2) and Eq. (3) to the scenario illustrated in Fig. 1. In Fig. 1, the attackers A l , A2, A3, A4 carry out a DDoS attack; each sends a attack packets per second. We may calculate the probability that the attackers are discovered after t seconds as shown in Table 1. Here the number of packets on edges e l , e2, e5 is twice that of the other edges because two edges join into one. For example, suppose that each attacker sends 1000 attack packets per second. In this case, the traceback takes 96 seconds for the discovery probability to reach 95% for A l , A2, A3, and A4. Table I. Example for how to calculate the discovery probability of the attackers in ICMP traceback Edge Number of attack packets Probability that two or more after t seconds iTrace packets are generated at each edge F(2at) e l , e2, e5 2at e3, e4, e6, e7, e8 at Fat) the discovery probability of attackers A l , A2, A3, A4 ~(2at)~*~(at)~
2.3
Probabilistic packet marking traceback
2.3.1
Outline
The agent, which marks routed packets, is installed in each router. The collector, which collects marked packets, is arranged just before the victim. A hash value for a packet is stored at each router with probability p (usually, 1/20). The collector can look for the attackers using marked packets sent to the victim.
2.3.2
Implementation
Implementation is based on Song and Perrig's AMS-II(Advanced and Authenticated Marking Scheme-11). The probabilistic packet marking traceback evaluated here divides the 64-bit hash value into 8 individual fragments; one of these is chosen at random and marked. The collector considers an attack packet to have been routed when the 64-bit hash value (16 marked packets) arrives twice.
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro,..
160
2.3.3
Mathematical model
We assume that the d individual routers are found in a direct route between the attacker and the victim. First, a router Ri marks a packet, and the probability that the other routers do not rewrite the marked packet is calculated.
Attacker Figure 2. For mathematical model computation of PPM
For example, in Fig. 2, if router R1 marks one packet, the probability that it is not marked by other routers is p (l-p)d-'. The hash value is divided into 8 individual fragments and one of those is sent at random. Therefore, the generation probability of a marked packet is p18. One mark is generated, and the probability Fd, that the mark is not rewritten by other routers, becomes
The probability Pr(ei), that two or more marked packets arrive on edge ei as set of eight individual fragments is
Here N is the number of packets, N*Fd (1-Fd)N-' is the arrival probability of one marked packet, and (1-Fd) is the probability that no marked packet reaches the collector. By deducting the two values from 1, the probability that two or more marked packets arrive at the collector can be calculated. It is raised to the eighth power because eight fragments are necessary for the traceback. The discovery probability of the attackers and traceback time can be found with Eq. (3) in the same way as for ICMP traceback. We may apply Eq. (3) and Eq. (5) to the scenario illustrated in Fig. 1. In an IP marking system, there are routers which may rewrite marked packets between a router to mark and the victim, unlike the ICMP system. Let a be the number of attack packets per second from A l , A2, A3, and A4. The discovery probabilities of the attackers after t seconds are shown in the Table 2. For example, suppose that each attacker sends 25 packets 1 sec; then the traceback time takes 65 seconds for the discovery probability to reach 95% for A l , A2, A3, and A4.
Mathematical Models of IP Traceback Methods and Their Verification
161
Table 2. Example for how to calculate the discovery probability of the attackers in probabilistic packet marking traceback Edge d Number of routed Probability of generating two or more packets after t seconds marked packets on each edge el,e2 1 2at G(1,2at) 2 2at G(2,2at) e5 2 at e3,e4 G(2,at) e6,e7,e9 3 at G(3,at) at G(4,at) e8 4 Discovery probability of ~(1,2at)'*~(2,2at)*~(2,at)'*~(3,at)~*~(4,at)
2.4
Hash-based traceback
2.4.1
Outline
The agent of each router registers the hash value of every packet. The manager asks the agents whether attack packets with the same hash value were routed through each router. An example of hash-based traceback is shown in Fig.3. In this example, the manager is tracing A3. The agent of each router returns the answer to manager's inquiry by yes or no.
Figure 3. Example of Hash-based traceback
2.4.2
Implementation
W e use the system of BBN technologies. Because of hash collisions, we let the hash table size be 14 bits in the evaluated system.
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro, . .
162 2.4.3
Mathematical model
The traceback time depends on the total number of inquiries from the manager. The number of inquiries increases very much as the attackers increase. It is difficult to derive the mathematical model because the traceback is done by the parallel processing. Therefore, the regression analysis was done based on the measurement data this time. The measurement data and regression analysis are shown in Fig.4. The measurement data was obtained by the verification item shown in paragraph 4.2 . The number of attackers is changed from 1 to 100.
total number of inquires 500
1000
1500
Figure 4. Regression analysis of hash-based traceback time
2.5
Improved ICMP traceback
2.5.1
Outline
Improved ICMP traceback places an agent on each router and has a manager. We show the flow of improved ICMP traceback in Fig. 5. First, the manager sends a traceback request to an agent on the router just before the victim. The traceback request has information about the attack packet. When the agent detects the requested attack packet, it generates a uTrace packet, which includes link information, and sends the uTrace packet to the manager. The manager receives the uTrace packet and sends a traceback request to the routers which link to the previous router. The manager then repeats these transactions.
Mathematical Models of IP Traceback Methods and Their Verification
163
Victim
\
/Atraceback
request
Figure 5. The flow of improved ICMP traceback
2.5.2
Implementation
An agent usually generates an uTrace packet when one attack packet comes on an edge. An exception is the edge just before an attacker. In this case, the agent generates an uTrace packet when two attack packets come on the edge to prevent false positives.
2.5.3
Mathematical model
The traceback time T of an attack route is the following.
Here T,,it(i) is the waiting time that an agent waits for an attack packet on an edge ei. The traceback time is the sum of the waiting times of each router on the attack route. When there are many attack routes, the traceback time is the one route with the longest traceback time. In Fig.1, when A l , A2, A3, A4 attack with 50 packets per second, the traceback of the attack route from A3 takes the most time. The average waiting time of an attack packet on edges e2, e5, e7 and e8 are looms, looms, 200ms, 200ms x 2, respectively. The average traceback time is 800ms.
In order to verify our mathematical model against actual measured values, we constructed a verification network. The network had 600 nodes. The network has the following parameters: The number of the hops between the victim and the attacker The number of attackers, arranged at random. In the measurement of the verification network, the traceback time was measured when the false negative rate and the false positive rate were within 5% of each other.
3.2
Verification network
The specification of the verification network is shown in the Table 3. Table 3. The specification of verification network Item Specification Network scale 300 servers, 600 nodes 0s Linux Network speed 1OOMbps The number of DoSlDDoS attackers at most 100 Attack packet amount per a machine at most 25000 packetlsec Network topology a mesh at the core, trees at the edges
When a large-scale network is constructed, we must consider the cost, the setting, securing a power supply, and the problem of heat in the room. In this research, these problems are solved by virtual OS technology. We selected UML (User Mode ~ i n u x ) ' because the specified OS is Linux. We assigned 32 MB to each virtual 0s. The maximum number of virtual servers is six. We chose not to use the virtual OS for the router because of the limitation of the input and output interface speed of the PC. The structure of the verification network is shown in Fig. 6. We had 380 servers and clients and 110 routers. Each router was a PC router using zebra6. The number in parenthesis is the actual number of PCs.
Mathematical Models of IP Traceback Methods and Their Verification
165
server attacker
client }
1OO(20)
380(70) I
'
management terminal
vlctlm
Figure 6. The structure of the verification network
4.
EVALUATION
4.1
The number of the hops
We measured the traceback time of a linear topology by changing the number of hops; we used the values 1, 3, 5, 10, 15, and 20. The measurement conditions are shown in Table 4. The number of trials was decided from both the standard deviation in measurement values and the test efficiency. Table 4. The measurement condition Traceback method Number of hops
ICMP PPM Hash Improved ICMP
1,3,5,10,15,20
Number of attack packets per second 125Opps 5 0 ~ ~ s 5 0 ~ ~ s 5 0 ~ ~ s
Number of trials 10 100 5 60
We evaluate the relationship between the number of the hops and traceback time. Actual measurement values and the theoretical values from the mathematical model are shown in the Fig. 7. Character M and T in parentheses mean the measurement values and the theoretical values respectively. The theoretical value is about the same as the actual measurement value. The hash-based and improved ICMP traceback are different from tracebacks where traceback information is generated probabilistically, such as ICMP and PPM traceback. They are very fast, because they can trace back with the arrival of a single attack packet.
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro,. .
166
Traceback time for these is under 2 seconds and increases with the number of the hops.
I
traceback time(sec)
1°00
7
7
Figure 7. The relation between the number of hops and the traceback time
4.2
The number of attackers
We also measured the change in traceback times in relation to the number of attackers. The numbers of attackers were 1, 10, 20, 50, and 100. We fixed the total number of attack packets sent to the victim. The measurement conditions are shown in Table 5; the topology of the verification network is shown in Fig. 8.
Figure 8. Topology of the verification network
Mathematical Models of l P Traceback Methods and Their Verification Table 5. The measurement condition Traceback method Number off attackers
ICMP PPM Hash Improved ICMP
1,10,20,50,100 1,10,25,50,100 10,20,50,100
Total number of attack packets per second 25OOOpps 1OOOpps 5 0 ~ ~ s 1OOpps
167
Number of trials 10 60 5 60
The actual measurement values and the theoretical values from the mathematical model are shown in Fig. 9. Character M and T in parentheses mean the measurement values and the theoretical values respectively. The theoretical values are about the same as the actual measurement values. The traceback time for ICMP traceback with 100 attackers is not shown because it took longer than the measurement time limit of 10 minutes. In the Hash-based and improved ICMP traceback, traceback times were almost the same even when the number of attackers changed, because the maximum number of hops is about the same even if the number of attackers is different.
traceback time(sec) 1000 I -
1
0 . J
the number of attackers
Figure 9. The relation between the number of attackers and the traceback time
5.
SUMMARY AND FUTURE RESEARCH
Mathematical models of IP traceback We proposed mathematical models of ICMP, probabilistic packet marking, hash-based and improved ICMP traceback methods. In improved ICMP traceback, the manager sends a request packet to inform it if an attack
168
Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro, . ..
packet is routed through each router. The agent informs the manager when the attack packet gets routed. We constructed a verification network to verify the mathematical models. We evaluated the relationship between the number of hops and traceback time and the relationship between the number of attackers and traceback time. We confirmed that the theoretical values of the mathematical models are almost same as the values actually measured, and the improved ICMP performance is about the same as hash-based traceback. The models can be applied to any network topology; therefore, the models can be used for the performance comparison of a new traceback model. The models can also be used to predict the performance of a typical traceback. The large-scale verification network The verification network had 600 nodes made by 152 PCs. We used a virtual OS to increase the number of "machines." In order to prevent performance decline, we chose to use PC routers rather than virtualize. Future research This time, we verified the mathematical models on a verification network with one autonomous system (AS). We plan to evaluate them on a verification network which has multiple ASS.
ACKNOWLEDGEMENTS National institute of information and Communications Technology (NICT) funded this research (2002 - 2005).
REFERENCES 1. Steven M. Bellovin, "ICMP Traceback Message", Internet Draft, Oct. 2001,
http://mark.doll,name/i-d/itrace/obsolete 2. Dawn Xiaodon Song, Adrian Perrig, "Advanced and Authenticated Marking Schemes for IP Traceback", IEEE INFOCOM 2001, http://vip.poly,edu/kulesh/forensics/docs/advancedmarkingpdf 3. Alex C. Snoeren et al., "Hash-Based IP Traceback", Proc. of the ACM SIGCOMM conference 2001, San Diego, CA, Computer Communication Review Vol. 31, No 4, October 2001. http://nms.lcs.mit.edu/-snoere~papers/spie-sigcomm.pdf
Mathematical Models of IP Traceback Methods and Their Verification
169
4. Vadim Kuznetsov, Andrei Simkin, Helena Sandstrom, "An evaluation of different IP traceback approaches", ICICS, 2002, 37-48 5. The User-mode Linux Kernel Home Page. http://user-mode-linux.sourceforge.net 6. Zebra Home Page, http://www.zebra.org
TRANSFERABLE E-CASH REVISIT Joseph K. ~ i u ' Sandy , H. wong' *, Duncan S. wong3 'Department of Information Engineering The Chinese University of Hong Kong Shatin, Hong Kong [email protected] 'wireless Technology Hong Kong Applied Science and Technology Research Institute Company Limited, Hong Kong [email protected] 3~epartment of Computer Science City University of Hong Kong Kowloon, Hong Kong [email protected]
* The work described in this paper was clone when this author was at the Department of Information Engineering, The Chinese Universiry of Hong Kong
Abstract:
Key words:
Incorporating the property of transferability into an offline electronic cash (ecash) system has turned out to be no easy matter. Most of the e-cash systems proposed so far do not provide transferability. Those who support transferability are either inefficient or requiring to be online with the help of a trustee. In this paper we present an efficient offline transferable e-cash system. The computational complexity of our system is as light as a single term e-cash system [13]. Besides, no trustee is involved in the transfer protocol. In addition to it, we propose two e-check systems constructed using similar techniques to our e-cash system. One is as efficient as a single term ecash system and supports partial unlinkability. The other one provides complete unlinkability with a more complex setting. electronic payment systems, secure electronic commerce, transferable e-cash, e-check
172
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong
INTRODUCTION An electronic cash (e-cash) system provides a digital way to mint and transfer money, or so-called e-cash/e-coins. According to 1171, an ideal ecash system consists of six properties: independence, security, untraceability, offline payment, divisibility and transferability. Independence implies that the security of the e-cash system does not depend on any physical location, medium, time or users. Security means that an e-cash cannot be forged or double spent without being detected. Untraceability refers to the maintenance of the anonymity of any honest user. Offline payment does not need the bank to be involved during the payment process conducted by a customer and a merchant. Divisibility refers to the ability to divide an e-coin into smaller pieces provided that the total amount of those pieces equals the value of the original e-coin. Transferability allows a user to spend an e-coin received in a payment to another user immediately without having contact the bank. Most of the e-cash systems [12,13,4,16,7,20] focus only on the first five properties but not on the last one: transferability. The first transferable ecash system was proposed by Okamoto, et al. [17]. It is based on the costly cut-and-choose methodology. Chaum, et al. [ I I ] outlined a method to extend [22] for transferability. Their idea is similar to ours. In this paper, we actually build a transferable one based on an entirely different and efficient scheme. In addition, we also illustrate how it can further be extended to construct e-check systems. Other transferable e-cash systems include the one proposed by Pagnia, et al. [18] and another one proposed by Anand, et al. [I]. However, this first one requires a trusted third party in the system to maintain users' anonymity while the second one requires the payment process to be online. Jeong, et al. also proposed a transferable cash system in [15] using group signatures [6,5,2]. However, the system needs an additional third party - the group manager. It can recover the identity of any group member and therefore it has to be trusted by all the users. In addition to e-cash, a more convenient means of payment is the electronic check (e-check). An e-check can be used for only once but can be used for any amount up to a maximum value and then be returned to the bank for a refund of the unused part. Therefore an extra protocol, the refund protocol is needed. It is convenient because a customer can 'withdraw' some token with the bank and decides how much it wants to use later on. The leftover can be redeemed afterwards. E-check was first proposed by Chaum, et al. in 1988 [8,10]. In [8], an online e-check system was proposed. Although [10,14] proposed offline echeck systems, they use the cut-and-choose methodology which appears to be quite inefficient in practice. The systems proposed in [3,21] avoid using
Transferable E-CASH Revisit
173
the cut-and-choose technique. However, [21] requires a trustee which knows the owner of each e-coin in the system even without double-spending. In this paper, we propose two e-check schemes by direct extension from a e-cash scheme [13]. The second scheme which provides complete linkability is as efficient as that in [3] in terms of computational complexity. In this paper, we propose an efficient offline transferable e-cash system. It extends directly from Ferguson's single term e-cash scheme [13] which is described in Section 2. In our proposed system, only users and a bank is present. A shop is eliminated because a payment to a shop can be regarded as a transfer of an e-coin from a user to anther user. The scheme is untraceable but secure. Moreover, we also propose two offline e-check systems which are as efficient as the one in [3]. One is highly efficient and supports partial unlinkability. The other one is completely unlinkable with a more complex setting. The rest of the paper is organized as follows. In Sec. 2, the Single Term offline e-cash scheme proposed by Ferguson [13] is reviewed. In Sec. 3, we describe our proposed transferable e-cash scheme. This is followed by the proposed two e-check schemes in Sec. 4 and conclude the paper in Sec. 5.
2. FERGUSON'S SINGLE TERM OFF-LINE COINS [13] It is an offline untraceable e-cash system without providing transferability. The scheme is efficient and does not use the cut-and-choose methodology. Here we give a brief review of the scheme.
Preliminaries. Let {0,1}*denote the set of finite binary strings. To denote that an element a is chosen uniformly at random from a finite set A , we write a E, A . Let n be the public RSA modulus [19] of the bank and v be its public exponent. It is required that v is a reasonably large prime (say 128 bits). Let g:, g,, g,, h,, h, be publicly known numbers such that ga,g,,g, E Z,, have large order and h,,h, are of order n in G F ( p ) , where p-1 is a multiple of n . Let U be an identity which is the concatenation of the user's identity and a unique coin number so that U is distinct for each e-coin. Let f, : (0,I } * + Z , and f, : ( 0 ,I } * -+ Z,* be cryptographic hash functions.
2.1. Withdrawal Protocol The withdrawal protocol consists of three parallel runs of the randomized blinded RSA signature scheme [9,13]. It is proceeded as follows.
Joseph K. Liu, Sandy H. Wong, Duncan S.Wong 1. The user picks c , , a , , b , ~Z,", , o , r , @ ~Z,, , y , a , P ~ ,Z , , and computes 0
Gc = yVc1gc mod n, G, = avalgo 'mod n, G, = Pvblg, 'mod n. 2. It sends M I = (U, G,, G,, GI))to the bank. For simplicity, we omit the notation of modular reduction in the rest of the paper when it gets clear from its context. 3. The bank picks c,, a,, b, E, Z," and sends
"
M , = (h," mod p, a,, h, mod p) to the user. 4. The user picks tl E , Z: and computes
ec = f , (h,"'"')- o m o d v,
5. It then sends M , = (e,, e,, e,) to the bank"
6. The user also signs ( M I M,, , M , ) and sends the signature to the bank' ' . 7. The bank computes -
C = Gcc2gc
''Note
ec,
that the exponents e, , eb and e, are computed modulo
v . Certain
corrections in the final signature ( S o ,S,) are needed to make the blinding perfect. This is done by multiplying the final signature by a suitable powers of g,, g, and
g, [13]. Corrections are not shown in this paper. "This corresponds to a signature of the user for all the data in the first three transmissions. It is used to protect the user against framing by the bank. We refer readers to 1131 for detail.
Transferable E-CASH Revisit
175
-uliv and selects t, c R2:. It sends (c, , b,, t, , ( ~ ' 2 ~ ) " " , (C B ) to the user. 8. The user computes C = C1C2,
b = b,b,, t = tlt2mod v,
and checks whether S, " = CtA and S,' = C" B . If these two equalities hold, it accepts. The user stores (a,b,c,t,S,,S,) as an e-coin. ( a ,b,c) are the base numbers of the coin.
2.2. Payment Protocol To spend an e-coin ( a ,b, c, t , S,, S,) , the user executes the following protocol with the shop. 9. The user sends ( a ,b, c ) to the shop. 10. The shop randomly chooses a challenge x and sends it to the user. 11. The user computes and sends r = tx + U and S = (S,)'(S,) to the shop. 12. The
shop
computes
C = cg, f , ( h C C ) ,
A=aga
fi (0)
,
B = bghf,'hbb' and checks if S v = CrA'B . If the equality holds, the shop accepts the coin and stores ( a ,b, c, x, r, S ) . Otherwise, it rejects.
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong
176
( x , r , S ) is a proof of the user's ownership to the e-coin with base number ( a ,b, c ) . Obviously, the user can only provide one proof in order to prevent from revealing its identity.
2.3. Deposit Protocol To deposit an e-coin, it sends (a,b,c, x, r, S ) to the bank. The bank verifies the coin by following the steps below. 13. Compute C = cgc
A = agohi'' and B = bg, f , ( h h b )
14. Check if S" = CrA"B . If it is false, the bank rejects the deposit. 15. Otherwise, it checks if (a,b,c) are already existed in its database. If yes, the bank rejects the deposit. Otherwise it accepts and stores ( a ,b, c ) in its database and it credits the shop. Double-spending is detected if the bank finds the same triple ( a ,b, c ) are already in its database. If the corresponding ( x , r , S ) are the same as the ones stored in the database, the bank concludes that the shop is cheating. Otherwise, it concludes that the user double spends the coin. The identity of the user, U can be obtained easily by solving the two linear equations.
3. OUR PROPOSED TRANSFERABLE E-CASH Let the bank issue e-coins with N different denominations. For the i -th denomination, the bank has a distinct and reasonably large prime vi be the corresponding public exponent. Define a zero-value coin with the corresponding public exponent v, as a distinct large prime. A zero-value coin is an e-coin which is worth nothing. It preserves all the properties of a non-transferable e-coin. Essentially, if the zero-value coin is double spent, the identity of the user would be revealed. For distinction, we call other nonzero-value coins as positive-value coins. Note that coins with various denominations are sharing the same public RSA modulus n .
Transferable E-CASH Revisit
How It Works. Each user obtains a number of zero-value coins from the bank using the withdrawal protocol described below during the system setup. When an owner, Alice, of a positive-value coin transfers the coin to a user, Bob, she carries out the payment protocol described below which is similar to the original payment protocol reviewed in Sec. 2.2. That is, Bob obtains the coin's base numbers and a proof of Alice's ownership. When Bob wants to transfer this coin to another user, Carol, Bob has to send, through a transfer protocol, the coin's base numbers and the proof of Alice's ownership appended with the base numbers of one of his zero-value coins and a proof of his ownership to Carol. Now when Carol wants to transfer the coin to another user, Daniel, Carol sends, through the transfer protocol, the coin's base numbers, the proof of Alice's ownership, the base numbers of Bob's zero-value coin, the proof of Bob's ownership, appended with the base numbers of one of her zero-value coins and a proof of his ownership to Daniel. The procedure repeats until the final receiver of the coin decides to deposit it. We refer to this transfer mechanism as a 'transfer-chain'. We will see shortly that this 'chain' is linked by a special relation between the proof of the sender's ownership of the coin and the base numbers of a receiver's zerovalue coin. As long as a user provides only one proof of its ownership to a zero-value coin, the user's identity would not be compromised. This implies that each zero-value coin can only be appeared in at most one transfer-chain. Using twice or more will result in identity revocation. When a user receives a transfer-chain, it can only transfer the chain to one user. Transferring to more than one user is equivalent to doublespending. On the other side, multiple transfer-chains can be combined into one transfer chain when they are transferring to one single user. That is, multiple coins can be transferred to a receiver in one run of the transfer protocol. This is accomplished by building up many-to-one relation of the proofs of multiple senders' ownerships of several coins and the base numbers of a receiver's zero-value coin. In the system, a payment process is considered as a transfer of some ecoins from a user to a shop. It has no difference from a transfer process and a shop has no difference from a conventional user. Hence there are only users and a bank in the system and the payment protocol is replaced by a transfer protocol. In the following, we describe the three protocols of our scheme, namely the withdrawal protocol, the transfer protocol and the deposit protocol.
178
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong
3.1. Withdrawal Protocol This protocol is executed when a user withdraws a coin from the bank, no matter the coin is a zero-valued or a positive-valued. The corresponding public exponent is used for each denomination of the coins. The protocol is similar to Ferguson's described in Sec. 2.1. For a user i , a zero-value coin and a positive-value coin are denoted as Zi and q , respectively.
3.2. Transfer Protocol As explained before, a transfer-chain is formed when a coin is transferred. Without loss of generality, let the transfer start from user 1, then to user 2, and so on. That is, user 1 withdraws a positive-value coin 4 = (al,bI,c,,t,,S,, ,S,, ) from the bank with corresponding identity U,. It is later transferred to user 2 and then to user 3, and so on. Let the zero-value coin of user k , for k > 1 , be' 2, = (a,,b,,~,,t,,S,~ , S b k ) with corresponding identities U, . In this section, we will see that a transferred coin is derived directly from the concept of transfer-chain. Below is the structure of a transferred coin Coin, when it is transferred from user 1 all the way to user k , for k > 1.
Structure of a Transferred Coin. Suppose the value of 4 is d -th denomination which corresponds to the public exponent v, , where 15 d 5 N . After the coin has been transferred for k -1 times for k > 1 , user k has the coin and the following components constitute the transferred coin Coin,. S, = s, I1 $2 I I I I s,-1 %=q11a211' Bk=b111b211'
"Ilak-lllak
"Ilbk-lllbk
C,=c,llc2lI . .Ilc,-,lk, Rk=~llr211'
"/lrk-l
where
si = ( S )"ISh, ' 1l i lk - 1 , xi = H(a,+,,b,+,,ci+,) and H is some
appropriate cryptographic hash functions. Hence (a,,b,,c,, S,, ,Sb ) are from 4 and ( a j ,b j , c j ,S, ,S, ) are from J
Z j for j > 1 .
I
Transferable E-CASH Revisit
179
For the boundary case (when k=l ) we define Coinl = ( S 14, , B,, C l ,R l ) , for Al = q , B, = bl , C, = c1 and S, = R, = /Z , where
A
represents empty content.
Validation of a Transferred Coin. We describe the validation of a transferred coin Coin, as a function, valid(Coin,) which outputs accept if the coin is valid, otherwise, it outputs reject:
valid = "On input Coin, = ( S ,,A,, B, ,C, ,R, ) , for any k 2 1 , 1. Compute
4. = a, ga& ( a , ) , B, = b, g,
fi(hb4)
,
c, = Cigc
f,(hCc1)
and xi = H (a,+l, b,+,,c,,,) , for 1 5 i 5 k - 1 . 2. Check whether s1'* = C, Al *I B, ,
'
siv"
C , " ~ x ' B i , f o rk2- 1~ i ~
3. Output accept if all the equalities hold, otherwise output reject."
The Protocol. When user k (for any k 2 1 ) transfers Coin, to user k + 1 , they execute the following transfer protocol. Here we assume that user k + 1 has an unused (fresh) zero-value coin Z,,, with base numbers ('k+l,
bk+l
9
',+I)
'
1. User k sends Coin, = ( S , ,A,, B, ,C, ,R, ) to user k + 1 . 2. User k + l executes valid(Coin,) to validate the coin. It continues if the function output accept. Otherwise, it halts with failure. 3. User k + 1 computes and sends x, = H (a,,, ,b,,, ,c,+,) to user
k. 4. User k computes
r, = tkxk+ Uk s, =(So,PShk
and sends r,, s, to user
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong S, V d
= C, ' A ,4Bl,ifk = 1
skVo = CkrkAkXkBk,ifk >1. 6. It continues if the equality holds. Otherwise, it halts with failure. 7. User k 1 constructs
+
Ak+l
11 ak+l
=
Bk+l=Bk
IIbk+l
ck+l=ckllck+l
Rk+l=Rkllrk
s,,,=s,Ils, and stores them as the new transferred coin Coin,,, .
3.3. Deposit Protocol The Deposit Protocol is straightforward. When user k deposits Coin, to the bank, the bank executes valid(Coin,) to validate the coin. Then it checks if (a,,b,,c,) are already in its database. If not, the bank stores Coin, and credits user k . Otherwise, it means someone has double spent the coin.
Detection of Double-Spending. We use the following example to illustrate the detection mechanism of double-spending. Suppose user 1 withdraws a coin ( U ,) from the bank and transfers to user 2 ( U , ) and so on, until it reaches user 6 ( U , ). User 6 deposits the coin. Also suppose that user 3 ( U , ) and user 5 ( U s) double spend the coin. Their double-spent coins are finally transferred to user 6' and user 7", respectively, and then deposited to the bank. Hence the bank has three copies of the coin with the same initial base numbers (q,b,,c,) . Let the transferred coin deposited by user 6, user 6' and user 7" be Coin,, Coin,, and Coin,,,, respectively. The bank finds I(a,,b,,c,,q), , (a,,b,,c,,r,), ( ~ s , b s , c s , r s...I ) , from . . a ,
Coin, ; {(a,,b, ,c, ,5 ) , . . . , (a,,b, ,c,, 9 ), . .) from Coin,, ; and {(a,,b,,c,,r,),..., (a,,bs,cs,r,.), from Coin,#. From Coin, and Coin,, , the bank finds the double spender to be user 3 and from Coin, and Coin,. , the bank finds the double spender to be user 5. Their identities are easily obtained by solving the corresponding linear equations. For example, U , is obtained by computing x, = H(a,,b4,c4) and x,, = H (a,,, b4,,c,,) and solving the following equations:
Transferable E-CASH Revisit
Also, it is important to see that the identity of other honest users would not be revealed by the bank.
4. OUR PROPOSED E-CHECKS In this section, we present two e-check systems. The first one is highly efficient and supports partial unlinkability. The second one support complete unlinkability with a more complex setting.
W e base on Ferguson's e-cash system again and therefore use the same notations as before. In this e-check system, there is a list of reasonable large as public exponents of the bank with vi prime numbers (vl,...,vk) corresponding the value of $2'-' . Define that multiplying any set of vi , 1l i l k , represents to the sum of their corresponding values, v, denotes the public exponent of the bank representing $d such that i=l
where d > , denotes the value of the i -th least significant bit of d . For example, <6>, = 0, <6>, = 1,<6>, = 1 . In this way, we can represent any amount up to $2k- 1 .
4.1.1. Withdrawal Protocol Without loss of generality, suppose a user wants to withdraw an e-check of $2k -1 as its maximum value. The withdrawal protocol is the same as Ferguson's one (Sec. 2.1) by setting the public exponent to v = v, . v, .v,. Note that the maximum value of the e-check must be in the form of $2' - 1, for any i > 1 . That is, all the bits of the maximum value of the e-check should be 1 in its binary representation. This ensures that the devaluation of v, (first step of the Payment Protocol below) is always computable. Let the e-check be denoted as K = (a,b,c,t, S,,S,) where (a,b,c) are the base numbers of the check.
Joseph K. Liu,Sandy H. Wong, Duncan S. Wong
4.1.2. Payment Protocol Suppose the user wants to spend $d to the shop, where 1 I d I 2k -1. The corresponding public exponent of the bank is v, which can be publicly computed using equation (1). In the first step of the protocol, the user 'devalues' the check from $2k - 1 to $d . The protocol proceeds as follow. -
1.The user computes v, = v,
vkdivv, , and
stu=
-
-
sSlb= ( S b ) v d .
2. Note: div is normal division without taking modulo. 3. The user then sends the base numbers of the check ( a ,b,c) to the shop. 4. The shop randomly picks a challenge x and sends it to the user. 5. The user computes r = tx + U , S = and sends r, S to the shop.
(s',)"(s',)
6. The shop computes C = cgc"'",
A z a g , f,( u ) , B = bg, f i ( h h h )
and checks whether Svd= C r A x B . If the equality holds, the shop accepts and stores ( a ,b, c, x, r , S , d ) . Otherwise, it rejects.
4.1.3. Deposit and Refund Protocols The deposit protocol of our e-check system is the same as Ferguson's deposit protocol reviewed in Sec. 2.3, with the public exponent v = v, . The user can refund the remaining $2k -1-d from the bank by executing a refund protocol. The protocol is almost the same as the deposit protocol, except the checking of double spending. In the refund protocol, the user sends the used check-tuple (a,b,c,x,r , S , d ) to the bank. The bank verifies user's ownership of the e-check by first carries out the steps similar to the payment protocol, namely it sends a challenge x' and obtains a response pair (r',S') . Then it checks if the base numbers (a,b,c) are already in its database. If it exists and the amount is d , the bank refunds the remaining $2k - 1 - d to the user and updates its database to record that the e-check has already been refunded. Note that this part is not anonymous. The bank knows the identity of the user who asks for refund. The bank can also link the e-check which has already spent by the user in earlier time.
Transferable E-CASH Revisit
The e-check system proposed in last section is linkable at the refund stage. In this section, we propose another scheme which is completely unlinkable. In this scheme, the bank has only one public exponent v . Instead, we use different elements g, E Z,*,l l i lk of large order to represent different values of the e-check. Like the representation system in E-Check I, we use go, to represent $2'-I. In this way, with k consecutive elements, the e-check has a maximum value of $2k - 1. We further use g, to prevent a user from using the e-check twice or more. Thus goo is included in the payment of an e-check regardless of the payment amount. E-Check I1 is similar to Ferguson's e-cash system. However, there are k+l signatures in each e-check if its maximum value is $2k -1, one is for embedding the identity of the user to prevent double-spending while the others are for composing the value of the e-check.
4.2.1.Withdrawal Protocol Without loss of generality, we assume a user wants to withdraw an echeck of $2k -1 . We follow the notations of Sec. 2.1. Let ~ , o ~ ~ o l be ~ public ~ ~ where ~ ~ g~ o o, gal , k,. . .~,g O ~ kg,~h ,gc ~ are ~ of C large order in 2:. The Withdrawal Protocol proceeds as follows. 1.The user picks b 1 , c l , q ~ , y , , . . . , E4 R~ Z : ,
G,, =ai "qtgo,4 ,fori=O,.. .,k 2. and sends M, = (U, G,, G,, Goo
, a .
3. The
bank
picks
a ,
Gak) to the bank.
b,, c,, a 4 , aq ,. . .,
E,
M, = (h,", h, ", a20, a 2,..., 4k) to the user
.
4. The user picks tl0,tl, ,...,tlkE , Z: computes
2,'
and
sends
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong
eb = f,(hb' l b 2 ) - 4 mod v e, = f,(hc"") - o mod v
and sends M , = (e,, e,,
coo, e,,
, . a
a ,
eUk) to the bank.
5. The user also signs ( M , ,M 2 , M 3 )and sends the signature to the bank. (Note: refer to Sec. 2.1 for discussions). 6. The bank computes C = Gcc2g, ec 'h
B=Gbb2 g, q = G , y, f2(i,ec,e,)g,, ",fori=O,...,k 7.The
bank
selects
t 2 0 , t 2 1 , . . . , t 2 k ~ , Z ~and
Ci2!
S; = (
sends
q)l'v
r'"ct;.
)'" ,fori = 0,. ..,k
and checks whether S, " = C" B and Si " = C"q.,for i = 0;. . ,k . If all the equalities hold, he accepts. The user stores (a,, payment of the e-check.
. .,a,, b , c , to,. . ,t, ,Sb,So,S 1 , . .,S , )
for the
Transferable E-CASHRevisit
4.2.2. Payment Protocol Without loss of generality, suppose the user wants to spend $2' -1, for some 1 I j < k , to the shop. The payment protocol proceeds as follows. 1.The user sends b, c, a,,.. a j to the shop. a ,
2. The shop selects a challenge number x and sends it to the user. 3. The user computes 5 = tix + U and Sti = (S,)(Si)", and sends
(q ,S t i ) ,0 I i I j , to the shop. 4. The shop computes
C = cg, f , ( h C C ) B=bg, f,(h,,h)
q=qg , "'",oG<j, f i V= C';4."B for 0 5 i lj .
and checks whether equalities hold, the
If all the shop accepts and stores (a,,...,aj,b,c,x,ro,...,rj,S',,...,S'j) . Otherwise, it rejects.
4.2.3. Deposit Protocol The deposit protocol is constructed in its natural way. When the shop deposits the e-check, it sends the check-tuple
( ao,...,aj,b,c,x,ro,...,rj ,St~,...,Stj) to the bank. The bank verifies of the tuple as follows. 1.Compute C = cg, f ( h C C ) , B = b g , f ( h h h ) ,
4. = ai gu,
f(ul)
, for
i = o , ... , j .
sfi"
2. Check whether = CC'; 4."B , 0 I i I j . If not all equal, the bank rejects the deposit. 3. Check whether the same values of (a,,b,c) already exist in its database. If yes, the bank rejects the deposit and the double-spender can easily be found. Otherwise, it accepts and credits the shop.
4.2.4. Refund Protocol If the user wants to refund the remaining amount of the e-check, that is,
$2k - 1- (2' - 1) = $2k - 2' , he has to inform the bank his account number and his identity U for the refund purpose and execute the following steps.
Joseph K. Liu, Sandy H. Wong, Duncan S. Wong and tj+,,...,t, to the bank. -2. The bank retrieves B, C from the withdrawal record. 3. The bank checks if any of aj+,,. . - ,a, are already in the database. If yes, it rejects. Otherwise, the bank selects a challenge number x and sends it to the user. The bank also computes q = tix+ U , for j+lIiSk. 1.The user sends
U ,aj+l, -,a,
4. The user computes q = tix + U and Sai= (S,)(Si)xr); p , and
sends Sai , j
+ 1 5 i I k , to the bank.
5 . The bank
computes
4 = ai g,,
(
)
and
checks
whether
-
saiV = CqA,' B for j + 1I i S k . If not all of them are equal, the bank rejects. Otherwise, the bank records that the e-check has been refunded in its database and refunds $2, - 2' to the user. Unlike E-Check I, in this e-check system, the bank is unable to link the refunded e-check with the e-check that the user has already spent to the shop.
5. CONCLUSION We have proposed an off-line transferable e-cash system. Unlike [15], we do not require any group manager or trustee. Our scheme does not use cutand-choose technique, thus more efficient than those using cut-and-choose such as [17]. In addition, we have also proposed two e-check systems. One is almost as efficient as a single term e-cash such as [13] with partial unlinkability only. The other one provides complete unlinkability with a more complex setting. We do not address divisibility in our transferable e-cash system. We may consider divisibility to be less important in practice as this can be easily be solved as in the world of physical cash. That is, using various denominations and conducting changes in transactions as the coins are transferable. Hence we consider that with transferability, divisibility becomes a less important property of e-cash.
Transferable E-CASH Revisit
REFERENCE [I] R. Sai Anand and C.E. Veni Madhavan. An Online, Transferable E-Cash Payment System. INDOCRYPT2000, LNCS 1977, pp. 93-103. Springer-Verlag, 2000. [2] G. Ateniese, J. Camenisch, M. Joye and G. Tsudik. A Practical and Provably Secure Coalition-Resistant Group Signature Scheme. CRYPTO 2000, LNCS 1880, pp. 255-270. Springer-Verlag, 2000. [3] S. Brands. An Efficient Off-line Electronic Cash System based on the Representation Problem. Technical Report CS-R9323, CWI, April, 1993. [4] S. Brands. Untraceable off-line cash in wallets with observers. Proc. CRYPTO 93, LNCS 0773, pp. 302-3 18. Springer-Verlag, 1993. [5] J. Carnenisch and M. Michels. A group signature schemes with improved efficiency. Proc. ASIACRYPT 98, LNCS 1514, pp. 160-174. Springer-Verlag, 1998. [6] J. Camenisch and M. Stadler. Efficient group signature scheme for large groups. Proc. CRYPTO 97, LNCS 1296, pp. 410-424. Springer-Verlag, 1997. [7] A. Chan, Y. Frankel and Y. Tsiounis. Easy Come - Easy Go Divisible Cash EUROCRYPT 98, LNCS 1403, pp. 561-575. Springer-Verlag, 1998. [8] D. Chaum. Online Cash Checks. Proc. EUROCRYPT 89, LNCS 0403, pp. 288-293. Springer-Verlag, 1990. [9] D. Chaum. Randomized Blind Signature. manuscript., 1992. [lo] D. Chaum, B. den Boer, E, van Heyst, S. Mjolsnes and A. Steenbeek. Efficient offline electronic checks. Proc. EUROCRYPT 89, LNCS 0403, pp. 294-301. Springer-Verlag, 1990. [ l l ] D. Chaum, T.P. Pedersen. Transferred Cash Grows in Size Proc. EUROCRYPT 92, LNCS 0658, pp. 390-407. Springer-Verlag, 1992. [12] D. Chaum, A. Fiat and M. Naor. Untraceable electronic cash. Proc. CRYPTO 88, LNCS 0403, pp. 319-327. Springer-Verlag, 1990. [13] N. Ferguson. Single Term Off-line Coins. Proc. EUROCRYPT 93, LNCS 0765, pp. 318328. Springer-Verlag, 1993. [14] R. Hirschfeld. Making Electronic Refunds Safer. Proc. EUROCRYPT 92, LNCS 740, pp. 106-1 12. Springer-Verlag, 1993. [15] I.R. Jeong, D.H. Lee and J.I. Lim. Efficient Transferable Cash with Group Signatures. ISC 2001, LNCS 2200, pp. 462-474. Springer-Verlag, 2001. [16] T. Okamoto. An efficient divisible electronic cash scheme. Proc. CRYPTO 95, LNCS 0963, pp. 438-451. Springer-Verlag, 1995. [17] T. Okamoto and K. Ohta. Universal electronic cash. Proc. EUROCRYPT 91, LNCS 0547, pp. 324-337. Springer-Verlag, 1991. [18] H. Pagnia and R. Jansen. Towards Multiple-payment Schemes for Digital Money. Financial Cryptography 1997, LNCS 1318, pp. 203-216. Springer-Verlag, 1997. [19] R. Rivest, A. Shamir and L Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21: 120-126, Feb 1978.
188
Joseph K. Liu,Sandy H. Wong, Duncan S. Wong
[20] T. Sander and A. Ta-Shma. Auditable, Anonymous Electronic Cash. Proc. CRYPT0 1999, LNCS 1666, pp. 555-572. Springer-Verlag, 1999. [21] A. de Solages and J. Traore. An Efficient Fair Offline Electronic Cash System with Extensions to Checks and Wallets with Observers. Financial Cryptography 1998, LNCS 1465, pp. 275-295. Springer-Verlag, 1998. [22] Hans van Antwerpen. Electronic Cash. Master's Thesis, CWI, 1990.
A LICENSE TRANSFER SYSTEM FOR SUPPORTING CONTENT PORTABILITY IN DIGITAL RIGHTS MANAGEMENT* Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard Center for Znformation Security, School of Znformation Technology and Compzrter Science, University of Wollongong, NSW 2522, Azrstralia
Abstract:
Current digital rights management systems typically bind the right to use content to a particular device whose location cannot be changed easily. Users may find it difficult to acquire a new license for each device. We propose a license transfer system that allows the user to share a license between devices and uses transaction track files to ensure that only one device can use the license at a time. We analyze the security properties of the proposed system.
Key words:
digital rights management; content portabil~ty;license transfer.
1.
INTRODUCTION
Digital rights management (DRM) systems are used to prevent unauthorized access to digital content and to manage content usage rights. Rather than trading the content as in traditional physical methods of distribution, the subject of trade is a license that grants certain rights over the content. Typically, the content, which is sold by the content provider, is encrypted with cryptographic algorithms to protect it from illegal copying and consumption. Protected content can be obtained by the user through various delivery channels. However, without possession of a valid license, the content cannot be decrypted.' To access protected content, the user's
*
This work was funded by the Smart :
190
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard
device needs to contact the license server, which is used by the license issuer to issue licenses, to acquire a valid license. We define content portability as the ability to access the same digital content on multiple suitable devices. Traditional content distribution models bind the right to use the content to the physical object that carries the content, such as a CD, which can be easily moved to wherever the owner wishes to go. One of the problems in current DRM implementations is that most solutions offer licenses that are bound to a playback device, which is often a desktop computer whose physical location cannot be changed easily. Usually digital content is locked to the device that it was downloaded to. Having purchased the right to use the content for one device, the user still needs to acquire a new license to access the same content on a different d e ~ i c e , ~ " which discourages the use of DRM. It would be welcomed by the users if the usage rights can be shared among multiple devices, so that the users do not need to re-acquire the rights when they have a new device, or when they want to use the content at different physical places. In this paper we propose a license transfer system that allows the user to share a license among multiple devices while ensuring that only one device can use the license at a time. We present surveys of existing DRM models that support content portability in Section 2. Section 3 describes our proposed license transfer system. We analyze the security properties of the proposed system in Section 4. Section 5 describes our demonstration system that supports content portability using the proposed license transfer protocol. Finally, we give conclusions in Section 6.
2.
RELATED WORKS
Several existing DRM systems or proposed schemes provide a limited degree of content portability. We identified three DRM models as follows.
2.1
Rights Locker Model
A rights locker4 is a storage system that contains the digital rights purchased by a user. It is implemented as a central server to facilitate consumers' access to their rights anywhere anytime. In a DRM rights locker model, permissions to use content are no longer bound to a particular device, but to the consumer himself. Each consumer has an account with the locker service that allows him to redeem his content usage rights from multiple locations using any DRM enabled device. Every time the user wants to access the content on his device, he needs to log on to his locker account via a web browser by typing in his username and
A License Transfer System for Supporting Content Portability in ...
191
password. After the central server has verified the authenticity of the request, it grants the access rights for the content to the user. Digital World services5 o msuch ~ a model. and ~ ~ 3 . c use The rights locker model requires Internet connections between users' devices and the central server. Users, especially those who do not have permanent Internet access, may find it difficult to access their rights using this model. Another drawback of this approach is that the central server can easily become a bottleneck. There may be a single point of failure: if the server were crashed or compromised by an attacker, e.g. under denial of service attacks, all the consumers would not be able to access their rights. Moreover, cracking a DRM rights locker would violate user's privacy4.
2.2
Rights-Sharing Model
In the rights-sharing model, content can be shared among a collection of devices, which is called an authorized domain. Usually, a domain represents a set of devices belonging to a consumer. The content can only be accessed in the domain for which it has been authorized. Several schemes have been proposed to address the need for content protection in the authorized domain, l ~ OMA such as the Family Domain concept7, the xCP Cluster ~ r o t o c o and DRM domain sharing9. The disadvantage of such model is that it introduces the overhead of setting up the domain prior to using it. Only when the domain is formed and the devices are enrolled in the domain, can content be sharing among devices in the domain. If user wants to access the content using devices that are not part of the domain, he is required to register each of these devices as a member of the domain.
2.3
Rights Transfer Model
The rights transfer model allows the consumer to transfer the rights to use the content to machines on the condition that the original copy of the content cannot be used. A few content protection schemes use this model. ~ l e x i ~ o k e nproposed " by NTT Laboratories is a generic copy prevention scheme for trading digital rights. In this scheme, a digital right is represented using two types of information: the rights description object and the token object. The token object represents the "genuineness" of the rights object and is stored and circulated using tamper-proof devices such as smart cards. The rights object can be held in any storage medium, but to redeem the rights, the user must present the token of the rights to the service provider. The rights transfer protocol proposed in this scheme takes place between two svart cards of the user, using public key cryptography. The token object must be deleted from the original card after the rights transfer procedure.
192
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppavd
FlexiToken assumes that neither participant flees from the other, i.e. the sender will delete the token object after it receives the receipt from the receiver. However, this assumption may be violated if the operation of the rights transfer protocol is interrupted either intentionally or accidentally. For example, a dishonest user may cut power from the sender before it deletes the token object. Aura and ~ o l l m a n n "proposed a simple license transfer procedure for transferring software licenses between smart cards. Since this protocol is based on the assumption that there is no communication interruption between two the cards, it shares the same problem as FlexiToken. The license transfer model has several advantages over the rights locker model and the license-sharing model: First, in the license transfer model, the digital rights portability among various devices does not depend on the availability of the central server. And it does not require Internet connection if licenses are transferred using local area network (LAN) or between PC and PDA. Second, the license transfer model is a low cost solution because it does not require domain set-up and management process, as the licensesharing model does. We consider using the license transfer model to support content portability in DRM.
3.
ROPOSED SOLUTION
We assume that encrypted content can be obtained by the user in any way the user wishes. Access to the content will be provided if the device has a valid license and can extract the content key from the license. Suppose that the user has purchased a license for a content file using one of his devices. Encrypted content is allowed to be copied to any device. To access the content on a particular device, the user needs to transfer the license from the original device to this machine. We require that at any one time, a license should only be used by one device to consume the digital content. Rogue users may try to make copies of one purchased license, then exchange or resell the license copies, thus allowing many devices to consume the digital content at the same time with the cost of a single license. In our system, the management of a single copy is done by the player software by using a transaction flag to record the state of the license: there are four different transaction flags, only when the license has an 'Active' flag, can the content be played. When the transaction flag changes to one other than 'Active', playing stops. Each device keeps a transaction track file that records the current state of each license stored on the device. Only the player can read and update transaction flags. In our proposed license transfer protocol, suppose that license L is for user U to use content C on device Dl, L's usage
A License Transfer System for Supporting Content Portability in ...
193
rules allow a new license to be created for the same user U to use the same content C on another device D2, subject to the condition that after transfer of the new license from DLto D2, L becomes invalid.
3.1
System Overview
Figure 1 shows the components of our system: The license database is a conceptual database, such as a file directory, on the user's device, which stores all the licenses that the user has purchased. The transaction track file is a digital data file that records the current state of these licenses. The digital library is a digital content repository on the user's device that stores protected content files obtained by the user. To decrypt and use the protected content, there must be a valid license in the license database and the transaction flag for that license must be 'Active' in the transaction track file. The player is a content viewer responsible for content decryption and playback, and for providing an interface with which the user can requestltransfer a license fromlto another device through a network.
licersc
0
. . . . . . . .
J
T m a c h ,,' Track Fik "'
Figure 1. Components of license transfer system
Following is a use scenario of our system: The user has acquired a license from the license server and stored the license on his home PC. If he wants to consume the content on multiple devices, he must transfer the license to the appropriate device. Transfer can be through mobile phones or other handheld devices with wireless connections. The user carries the mobile phone wherever he goes. Using the mobile phone to transfer licenses to a DRM-enabled device is a convenient solution to the above scenario.
194
3.2
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard
Assumptions
In DRM, end users cannot be assumed to be trusted. Player software executes in a hostile environment, taking control of how the content is used, by whom and under which conditions. Rogue users may try to modify the player software to circumvent the enforcement of usage rules. We assume the player is trusted. The trusted player is responsible for rendering digital content while enforcing the permissions and constraints associated with the content. By "trusted", we mean trusted by the content provider. The integrity of the trusted player can be protected by using a trusted computing platform'2, for example, Microsoft's Next-Generation If a trusted computing platform is not '~ Secure Computing ~ a s e (NGSCB). exist available, there are techniques such as encryption or code obf~scation'~ to make it hard for rogue users to tamper with the player. We assume each device has a certified publiclprivate key pair. The corresponding private key and the transaction track file stored on the device are only accessible to the trusted player. We assume that license transfers take place between two trusted players and that there exists a mechanism for players to authenticate each other before engaging in communications and transactions.
3.3
Requirements
Our license transfer system has the following requirements: R1: The content key in the license must be hidden from the user. R2: Players must be able to verify the authenticity and the integrity of the license, and extract the content key from the license. R3: The license transfer protocol must ensure that only the authorized user can access the license. R4: At one time, a user should only be able to use a license on one device. Using copies of the license on other devices does not give access to the protected content. R5: The license transfer protocol must satisfy the atomicity property, which is to ensure that exactly one device (Dl or D2) has a valid copy of the license at the end of the transfer procedure regardless of any communication failure between two devices.
3.4
License Transfer Protocol
In our system, the license transfer protocol is run between two trusted player programs. Consider the scenario there are two devices Dl and D2 with trusted players PI and P2respectively. Suppose the user uses device D2 to request the license L stored on device Dl. The user should first authenticate himself to P2. PI and P2 will perform a mutual authentication protocol to
A License Transfer System for Supporting Content Portability in ...
195
authenticate their mutual identities. PI only allows transfer of the license if the identity of the user matches the identity of the licensee stored in the license on Dl. We use a flag mechanism to define license status. Each license is associated with a transaction flag that describes the status of the license. There are four different transaction flags: Active, Deactivated, Request and Recover. The meaning of these flags is as follows: Active: the player can use the license to decrypt the content. Deactivated: the license is deactivated, so the player cannot use it to decrypt the content. Request: the license is not physically stored on the device. The player can request it to be transferred from another device. Recover: the license is physically stored on the device. The player can request its status to be changed from 'Deactivated' to 'Active'. We assume PI and P2 share an authenticated session key K, which can be obtained by executing an authenticated key establishment protocol.15In the following license transfer protocol, Req(P1,P2, L) denotes the license request that P2 sends to PI for license L. IDL is L's identifier. Flg denotes the message type, which is to show that the message is for license request or license recovery. PKI/SKI and PK2/SK2 are publidprivate key pairs of device Dl and D2 respectively. Let ENCK(X)denote encryption of a message X using a symmetric key K. T is the timeout value of the protocol. The license transfer protocol is described as follows: Stepl: P2 sends to PI: ENCK(Req(PI, P2, L)), P2 writes (IDL, 'FlagzRequest') where Req(P1,P2, L) = PI, P2, IDL,Flg. Step2: If Flg = 'Request' and the transaction flag for L on Dl is 'Active' or 'Deactivated by P2', PI sends to P2: ENCK(L), P1 writes (IDL, 'Flag=Deactivated by P2'); else PI quits. Step3: If L is valid, P2 stores L and writes (IDL, 'Flag=Active7); If L is invalid or P2 does not receive L within time T, P2 quits. In step 1, P2 sends a license request Req(P1, P2, L) to PI, which is encrypted using the shared session key K. This encryption provides privacy for the user against eavesdropping and also possible theft and misuse of the license. The message type Flg in Req(P1, P2, L) is 'Request'. At the same time, P2 writes (IDL, 'Flag=Request7) as the entry for L in the transaction track file on D2, which indicates that L is being requested by P2. In step 2, PI uses the session key K to decrypt the license request Req(P1, P2, L) and checks the message type Flg in Req(P1,P2, L). If Flg is 'Request', PI checks transaction flag for L on Dl. If L has the 'Active' flag, PI sends license L to P2 and updates L's transaction flag on Dl from 'Active' to 'Deactivated by P2'. If PI finds that L was deactivated by P2, which indicates
196
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard
that P2 failed to receive the license in the previous license transfer procedure, PI will send L to P2 again. Once L is deactivated, it cannot be used by PI anymore, although L is still physically kept on device Dl, i.e. PI will refuse to use L to decrypt the content if PI finds that L is marked as deactivated in the transaction track file. If PI finds that L does not have the 'Active' flag or was deactivated by other players, PI quits. In step 3, P2 receives L from PI and verifies L's integrity and authenticity using the public key of the license issuer. If this succeeds, P2 stores L and sets the transaction flag for L as 'Active', i.e. L's entry in the D2's transaction track file is changed from (IDL, 'Flag=Request') to (IDL, 'Flag=Active'). If the license verification fails or P2 does not receive L from P1 within time T after sending the license request, P2 quits. To get the license L, P2 needs to request the license again, starting from step 1. The license recovery protocol is similar to the above approach. A license recovery scenario is that both Dl and D2 have a copy of the license L. The transaction flag for L is 'Active' on device D2, but is 'Deactivated by P2' on device Dl. PI requests L's transaction flag on Dl to be set to 'Active'. In this procedure, P I sends the license recovery request to P2 in which the message type Flg is 'Recover'. At the same time, PI writes (IDL, 'Flag=Recover7) as the entry for L in the transaction track file on Dl. The transaction flag 'Recover' indicates that L is physically stored on Dl but cannot be used and PI requests reactivation of L. After P2 receives and verifies the license recovery request, it sets the transaction flag for L on D2 from 'Active' to 'Deactivated by PI', so P2 will not be able to use the license L. On receipt of the respond message from P2, PI updates L's transaction flag on Dl, changing it to 'Active', so L can only be used by PI to decrypt the content. If PI does not receive the response from P2 within time T, P I quits. To activate L on Dl, P I needs to send the license recovery request to P2 again. Using transaction flags rather than deletion of licenses guarantees atomicity property, i.e. at any one time, exactly one device can use the license to get access to the content. In comparison with the FlexiToken scheme, our license transfer protocol is robust against communication interruption between two devices.
3.5
Content Key Management in License Transfers
In current DRM implementations, a license includes the content identifier, the identity of the licensee, usage rules, and the encrypted content key. The content key is usually encrypted with the public key of the user's device. Only the device that possesses the correct private key is able to decrypt the encrypted content key and gain access to the content. The license is usually digitally signed by the license issuer to enable its integrity and authenticity
A License Transfer System for Supporting Content Portability in ...
197
to be verified. A problem with this in the license transfer system is that the content key, which is encrypted with the original device's public key, in the transferred license cannot be accessed by the receiving device. We need to design a mechanism that protects the license in such a way that enables the content key to be successfully extracted by the target device in license transfer while ensuring that the license integrity can be verified. We consider using broadcast encryption and point-to-point encryption for content key encryption. Let Kc denote the content key and PENCpK(X) denote encryption of a message X using a public key PK. Let PK1lSK1,PK2/SK2,. . . PKnlSK, be publiclprivate key pairs of devices Dl, DZ,. . .Dnrespectively.
3.5.1
Broadcast Encryption
In broadcast encryption, the user needs to register all the devices he intends to use with the content provider. During license transfer, the sender does not need to modify the original license. Only legitimate devices can access the content key after receiving the license. We consider two types of broadcast encryption: Public key broadcast encryption16: The content provider generates a public key (PKG)for the group of devices that the user will be using. Each legitimate device has a different private key (SKI, SK2, . . . SK,) stored in a secure storage on the device. The license contains the encrypted content key PENCpK,(Kc).Player PI (i = 1, 2, ... n) on device Dl uses D,'s private key SKi to decrypt the content key Kc and then uses Kc to decrypt the content. The content key in the license is Using a public key infia~tructwe'~: encrypted with each device's public key: PENCpK,(Kc)PENCpK2(Kc)... PENCpK,,(Kc).When player PI (i = 1, 2, ... n) on device D, receives the license, it uses Di's private key SK, to decrypt PENCpK,(Kc)and then uses Kc to decrypt the content. The disadvantage of using broadcast encryption is that new devices must be registered to the content provider. When the user replaces old devices with new ones, he wants to continue to use the content he has purchased. The new devices must receive a private key. If a device is compromised, the content provider must change the public key and update the private keys of all devices. Thus, the content provider will have to save and periodically update a record of the user and the device set. Moreover, if the user wants to subscribe content from different content providers, the user has to register his devices with each content provider, which is inconvenient for the user.
198 3.5.2
Qiong Liz,, Reihaneh Sufuvi-Naini and Nicholas Paul Sheppuvd Point-to-Point Encryption
Suppose that the license issuer's public key and private key pair is PKLI/SKLI.When the license is distributed to device D l , the license issuer encrypts the content key Kc with Dl's public key, i.e. PENCpK, (Kc). In the license transfer procedure from Dl to D2, player PI on device Dl needs to use Dl's private key SKI to decrypt the encrypted content key first and then reencrypt the content key using D2's public key, i.e. PENCpKz(Kc), so that player P2 on device D2 can decrypt the content key using D2's private key SK2. A problem with this scenario is that the license integrity cannot be verified, because the encrypted content key in the license has changed from PENCpK,(Kc)to PENCpK,(Kc).When player P2 on device D2 checks the integrity of the license using the license issuer's public key, the verification will fail.
License Identifier Licensee's Public Key Content Identifier Hash(&)
-
-Part 1
Usage Rules Metadata
-Part 2
Figure 2. License format on device Dl
To solve the above problem, we propose a license format as shown in Figure 2. A license is split into two parts: the first part of the license includes the license identifier, licensee's identity, the content identifier, the hash value of the content key, usage rules and other related licensing information. The license identifier is used to link the license with its entry in the transaction track file. The licensee's identity shows the identity of the user to whom the rights are granted, using the user's public key. The content identifier, which may be in the form of a Uniform Resource 1dentifierI8 (URI) or a Uniform Resource ~ o c a t o r (URL), '~ is used to uniquely identify the protected content file associated with this license. The first part is digitally signed by the license issuer to enable its integrity and authenticity
A License Transfer System for Supporting Content Portability in ...
199
to be verified. We use SIG(SKLI, Part 1) to denote the license issuers signature on the first part of the license. The second part includes the content key encrypted with the public key of the device. The reason for constructing the license in this way is to prevent usage rules from unauthorized modification and to ensure that the license issuer's signature can be verified when the content key is encrypted with another device's public key during license transfer. One may ask: what happens in the case of a dispute when the user claims that the license issuer put the wrong content key in the license? To avoid such dispute, the hash function has to be one-way and collision-free, so it would be infeasible for the license issuer to generate two content keys with the same hash value. When the player receives the license, it checks the signature of the first part of the license. If the verification succeeds, the player checks the transaction flag for the license in the transaction track file according to the license identifier specified in the license. If the transaction flag for the license is 'Active', the player verifies the user's identity, checks the content identifier, decrypts the encrypted content key using the device's private key and passes the resulting content key to the hash function. If the computed result is the same as the hash value contained in the license, the player will accept the license. Otherwise, the license will be rejected and the player will contact the license server for license reissue. If the license is accepted but the key cannot be used to decrypt the content, the license issuer needs to reissue a license that contains the correct content key.
3.6
Transaction Track File
Each device has a transaction track file that records the current state of each license stored on the device. There are two fields in a track entry: the license identifier and the transaction flag. If the license identifier in the track entry matches that in a license, the track entry is for the corresponding license. Each time the user wants to use the license to access the content, the player checks the transaction flag of the license. Access to the content can be granted only when the transaction flag for the license is 'Active'. There is only one entry in the track file for a specific license. When a license is delivered to the user's device for the first time, the player adds an entry for the license to the track file after the license integrity is verified. The transaction flag for the license is set to 'Active'. When a license transfer happens, the player reads the license identifier specified in the transferred license and checks the track entry for the license according to the identifier. The player will update the transaction flag for the license after the license has been transferred to another device.
200
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard
To prevent track entries from unauthorized manipulation, the transaction track file is only accessible to the trusted player. Rogue users may take a snapshot of the hard disk drive, perform one or more license transfers to another device and then restore the transaction track file to the state before license transfers happen. To prevent this attack, software tamper resistant techniques need to be deployed. We do not discuss this topic here, because it is out of the scope of this paper.
4.
SECURITY ANALYSIS
This section analyzes the security properties of our system according to the requirements listed in 3.3. Requirement R1 is satisfied, because the content key in the license is encrypted using the device's public key (or the group key of authorized devices). The corresponding private key of the device is only accessible to the trusted player, so the user cannot decrypt the content key. Requirement R2 is satisfied. The license is digitally signed by the license issuer, so the integrity and authenticity of the license can be verified by the trusted player using the license issuer's public key. As discussed in 3.5, the proposed license format ensures that the license issuer's digital signature will work properly when a license transfer happens using point-to-point encryption. The content key in the license is encrypted using the device's public key (or the group public key of authorized devices), which can be decrypted by the trusted player using the device's private key. Requirement R3 is satisfied. The license is transferred through a secure communication channel between two devices. The shared session key of the two trusted players is unknown to any third party, so rogue users cannot intercept and get access to the license during license transfers. Moreover, license transfers can only be allowed if the license requestor is the licensee. Requirement R4 is satisfied. Unauthorized devices will not be able to use copied licenses to consume the protected content, because the content key in the license is encrypted using the authorized device's public key (or the group public key of authorized devices). Only the authorized device has the knowledge of its own private key and hence can decrypt the encrypted content key, which then can be used to decrypt the content. Requirement R5 is satisfied. After a license transfer procedure takes place, exactly one device has the license with 'Active' flag. This property is analyzed on a case-by-case basis, as follows: Case 1: There is no communication problem between PI and P2. Exchanged messages are not disrupted by an attacker. The protocol runs
A License Transfer System for Supporting Content Portability in ...
20 1
successfully. At the end of the license transfer, only P2gets the license with 'Active' flag. Case 2: PI fails to receive a valid license request from P2 in step 2. L is still kept on device Dl. PZdoes not get the license. The transaction flag for L on Dl is kept unchanged, which is still 'Active'. Case 3: P2 fails to receive the license from P I in step 3. The protocol aborts after timeout. The transaction flag for L in the transaction track file on Dl is marked as 'Deactivated by Pz7.However, P2 can get the license from PI through a negotiation procedure, i.e. P2 re-starts the license transfer protocol by sending the license request Req(Pl, P2, L) to PI again. The message flag in the license request shows that the current transaction flag for L on D2's transaction track file (i.e. 'Request'). From the message flag and L's transaction flag on Dl, PI gets to know that P2 did not receive the license previously. Since L is still physically stored on Dl, PI sends L to P2 again. Finally, P2 gets the license L and changes the transaction flag for L on D2 from to 'Request' to 'Active'. Case 4: The trusted player P3 on the third device D3 initiates the license transfer protocol, requesting L stored on Dl. Upon on the receipt of the license request, PI checks L's transaction flag on Dl that indicates that L was deactivated by P2 due to the previous license transfer procedure that transfers L from Dl to D2. The deactivating device is D2 rather than D3, which tells PI that this is not a negotiation procedure due to the previous communication failure between PI and P3. Therefore, PI refuses the license request from P3 by terminating the license transfer protocol. In conclusion, our license transfer system satisfies all the requirements listed in 3.3. Our license transfer protocol is robust against intentional or unintentional communication failures of the protocol. The license is not bound to a particular device so it can be easily transferred within a household if required. Finally, our scheme is an offline solution, so the user does not need to be connected on the Internet when he wants to share a license between devices.
5.
IMPLEMENTATION
We have developed a functional DRM demonstration system that supports content portability among different devices using the license transfer mechanism defined in this paper. The player is implemented in Java, which allows the user to access protected content using the licenses stored on the device and supports transfers of licenses from one device to another using the license transfer protocol. In our system, licenses are generated based on the MPEG-21 REL data model. We use the Java cryptography
202
Qiong Liz!, Reiharzeh Safavi-Naini and Nicholas Paul Sheppard
extension library provided by Cryptix Foundation Limited to implement cryptographic operations, such as encryption, hashing and digital signature. Our implementation of license transfer includes a client program and a server program. The client requests licenses to be transferred from the server. We use the following software modules, as shown in Figure 3.
Figure 3. Software modules of license transfer
The license request module connects to the server and creates a secure communication channel between the client and the server using secure socket layer. The user authentication module uses a "challenge-response" mechanism to authenticate the user's identity. It includes signature generation and verification modules. The signature generation module takes the challenge and the user's private key as input and generates a digital signature using the user's private key. The signature verification module verifies the user's signature on the challenge using the user's public key. We implemented these modules using RSA digital signature scheme. The license lookup module is called by the server. It takes each license stored on the server machine and the user's public key as input and checks if the identity of the user matches the identity of the licensee (i.e. the public key of the key holder) in the license. It also consults the status maintenance module to check the status of the license. The license processing module is called by the server. It processes the requested license to make the content key inside the license accessible to the client machine. It uses the private key of the server machine to decrypt the content key in the requested license, and reencrypts the content key using the public key of the client machine. The license transfer module accepts the output of the license processing module and transfers the license to the client through the secure communication channel created by the license request module. The license verification
A License Transfer System for Supporting Content Portability in ...
203
module is called by the client. It verifies the integrity and authenticity of the license by checking the digital signature on the license using the license issuer's public key. The status maintenance module maintains status of all the licenses stored on the device. It updates transaction flags for the transferred licenses in the transaction track file.
CONCLUDING REMARKS This paper describes the requirements for a digital rights management system that supports content portability. We propose a license transfer system that allows the user to share a license between multiple devices, which satisfies these requirements. We describe the license transfer protocol and analyze content key management problem in license transfers. We propose a new license format by which the integrity of the license can be verified. We use a transaction track file to ensure that at one time, exactly one device can use the license to decrypt content. We evaluate the security properties of our solution. The development of our DRM test bed shows a working implementation of possible DRM services that could be offered to the customers. Through implementation, we get better understanding about how DRM components work together to provide a secure DRM solution. We believe that DRM systems can be widely used only if customers find it easy to use. Currently, our system only supports transfers of licenses that grant stateless rights to the user. Stateless rights are usage rights for which the device does not have to maintain state information. Permissions that require maintenance of state by the device, for example a limited number of plays or a maximum period of metered usage time, are considered stateful rights. To make our license transfer system correctly enforce stateful rights expressed in the license, we need to design a mechanism that keeps track of the uses of the associated content. In the future, we will work on the loan application to make our system support the loan right. The loan right represents the right to lend the content to another user for a specific period of time. While the content is on loan, the original copy of the content cannot be used. At the end of the loan period, the loaner copy deactivates and the original copy reactivates. Currently, our system supports license transfers for a single user between different devices. To support the loan application, the license transfer protocol needs to handle license transfers between different users and take the loan period into account, which provides a challenge for us to conduct future work on this field.
204
Qiong Liu, Reihaneh Safavi-Naini and Nicholas Paul Sheppard
REFEREYCES 1. Q. Liu, R. Safavi-Naini, and N. P. Sheppard, "Digital rights management for content distribution," In Proceedings of the Australasian information security workshop conference on ACSW frontiers 2003, pp. 49-58, Australian. 2. D. K. Mulligan, J. Han, and A. J. Burstein, "How DRM-based content delivery systems disrupt expectations of 'personal use'," In Proceedings of the 2003 ACM workshop on Digital rights management, pp. 77-89, ACM Press, 2003. 3. W. Eric, "Protecting digital music using DRM: example of a mobile service over WLAN (version 1.0)," 2002. 4. J. Feigenbaum, M. J. Freedman, T. Sander, and A. Shostack, "Privacy engineering for digital rights management systems," In Digital Rights Management Workshop, pp. 76-105, 2001. 5 . Digital World Services, "Digital world services launches rights locker and content manager," http:l/www.dwsco.comi, 200 1. 6. Cyber Patrol, "Free MP3.com technology takes cue from open-source movement,"http:llnews.com.com/2100-1023-25 1014.html?legacy=cnet, 2001. 7. T. S. Messerges and E. A. Dabbish, "Digital rights management in a 3G mobile phone and beyond," In Proceedings of the 2003 ACM workshop on Digital rights management, pp. 27-38, ACM Press, 2003. 8. F. Pestoni, J. B. Lotspiech, and S. Nusser, "xCP: Peer-to-Peer Content Protection," IEEE Signal Processing Magazine, 2004. 9. Open Mobile Alliance, "OMA DRM specification v2.0. draft version," http://member.openmobilealliance.org/ftp/PublicdocunentslBAClDLDRM/, Jan. 2004. 10. IvI. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy prevention scheme for rights trading infrastructure". 11. T. Aura and D. Gollmann, "Software license management with smart cards," USENIX Workshop on Smartcard Technology, May 1999. 12. P. England, B. Lampson, J. Manferdelli, M. Peinado, and B. Willman, "A Trusted Open Platform," IEEE Computer Security, 2003. 13. Microsoft Corporation, "Next-generation secure computing base: the road to security," http:llwww.microsoft.com/ngscb, 2003. 14. M. Sosonkin, G. Naumovich and Nasir Memon, "Obfuscation of design intent in objectoriented applications," In Proceedings of the 2003 ACM workshop on Digital rights management, pp. 142 - 153, ACM Press, 2003. 15. W. Stallings, "Cryptography and network security: principles and practice," Prentice-Hall, Inc., Upper Saddle River, NJ 07458, USA, third edition, 2002. 16. D. Boneh and IM. K. Franklin, "An efficient public key traitor tracing scheme," In Proceedings of the 19th Annual International Cryptology Conference on Advances in Cryptology, pp. 338-353, Springer-Verlag, 1999. 17. R. Safavi-Naini and H. Wang, "Broadcast authentication for group communication," Theoretical Computer Science, 269(1-2): 1-2 1, October 2001. 18. The Internet Society, "Uniform Resource Identifiers (URI): Generic Syntax. http:llwww.ietf.orgirfc/rfc2396.txt, 1998. 19. The Internet Society, "Registration Procedures for URL Scheme Names", http:llwww.ietf.org/rfc/rfc2717.txt, 1999.
SECURE HUMAN COMMUNICATIONS BASED ON BIOMETRICS SIGNALS
Yongdong WU', Feng ~ a oand ' Robert H.
en^*
'lnstititue for Infocomm Research (I'R), Singapore, {wydong,baofeng)@i2r.a-star.edu.sg; 2~chool of information Systems, Singapore Management Univeristy, [email protected]
Abstract:
1.
User authentication is the first and probably the most challenging step in achieving secure person-to-person communications. Most of the existing authentication schemes require communicating parties either share a secret/password or know each other's public key. In this paper we suggest a novel user authentication scheme that is easy to use and overcomes the requirements of sharing password or public keys. Our scheme allows two human users to perform mutual authentication and have secure communications over an open channel by exchanging biometrics signals (e. g., voice or video signals). In addition to user authentication, our scheme establishes a secret session key between two users by cryptographically binding biometrics signals with users's Diffie-Hellman public values. Under the assumption that the two communicating persons are familiar with each other's biometrics signals, we show that the scheme is secure against various attacks, including the man-in-the-middle attack. The proposed scheme is highly suitable for applications such as Voice-over-IP.
INTRODUCTION
The explosive growth of computer systems and their applications has considerably increased the dependence of both organizations and individuals on the information communicated using the Internet. However, the Internet is an interconnection of open public networks. Without security measures, communications over the Internet, such as Voice-over-IP (VOIP) and video conferences, can be eavesdropped without much difficulty. This in turn has led to a heightened effort to protect data from disclosure and to guarantee the
206
Yongdong Wu, Feng Bao, Robert H. Deng
integrity of data and messages communicated over open networks. User authentication is the first and probably the most challenging step in achieving secure communications in the Internet. To date, the most pervasive user authentication schemes are based on cryptographic techniques which require that the parties either share a secret key (e.g., a password)1 or know each other's public key2. Although password based authentication protocols are widely used, there are many potential difficulties for a human user to share passwords with a large number of remote users. First of all, establishing a shared password between two users requires a secure secret distribution mechanism to be in place. This is very challenging. Second and more importantly, human users are not good at remember passwords of good quality, not to mention remembering multiple passwords shared with many remote users. Public key based authentication protocols require users to know each other's public key in authenticated manners in the form of public key certificates. This turn requires the existence of a public key infrastructure in the Internet, an impossible task at least in the near to medium terms3. In this paper our focus is on human user authentication in person-toperson communications in an open environment such as the Internet. In this case, it is much more convenient and natural for human users to authenticate each other using biometrics techniques. Most of the existing research on biometrics based user authentication techniques allows a human user to authenticate himself or herself to a local machine. Little effort has been spent to study biornetrics based methods which perform authentication between two remote human users. To our knowledge, the only work related to our effort is the Pretty Good Privacy n e ~ . implements an authentication protocol based Phone or ~ ~ ~ f o PGPfone on the exchange of voice signals. However, PGPfone is vulnerable to replay attack. If an attacker is able to collect sound samples of all the 256 octets by, for example, eavesdropping on someone's phone calls, the attacker is able to impersonate the victim at will. As in PGPfone, our scheme requires that communicating users be able to identify each other based on the other party's biornetrics signals (such as acoustic waves or face expression). Based on the exchange of biometrics signals, the proposed scheme not only authenticates remote human users but also enables them to have secure communications over open channels. Specifically, to achieve authentication and agreement of a secret session key, the Diffie-Hellman public key values are cryptographically committed or bound with biometrics signals such that the trust on the biometric information is extended to the Diffie-Hellman public values. The trusted Diffie-Hellman public values are then used to perform the Diffie-Hellman Key Exchange Protocol so as to defeat the man-in-the-middle attack. Since
Secure Human Communications Based on Biometrics Signals
207
our scheme does not require users to share any password or know each other's public key in advance, it is attractive for applications such as secure VOIP or secure video conferences. The reminder of the paper is organized as follows. Section 2 addresses the primaries for clarity. Section 3 elaborates the proposed scheme and its variant. Section 4 discusses the availability and security. Section 5 contains our concluding remarks.
2.
PRILIMINARIES
2.1
Notations
A: shorthand notation for Alice (or her communication device) who initiates the communication unless stated otherwise. Preminatary B: shorthand notation for Bob (or his communication device) who responses to Alice's communication request. C: shorthand notation for Clark who tries to attack the communications between Alice and Bob. Cx: a challenge biornetrics signal. Without loss of generality, we will use voice signals as the representative biornetrics signals throughout the paper. Thus, Cx is the acoustic wave or digital representation of a challenge statement spoken by user X (either A or B); whether it is the acoustic wave or the digital representation should be clear from the context of discussion. Ry: an acoustic wave or digital representation of a response statement spoken by user Y in reply to CX. Ry-Cx: The response Ry matches challenge Cx. For instance, the content of Ry is the same/similar to that of Cx, or Ry is a correct answer to CX. I Cx 1: the time duration of Cx. I Ry I: the time duration of Ry. e(K, m): encryption of message m with a symmetric key cryptosystem (e. g., AES) using a secret key K. d(K, c): decryption of a ciphertext c with a symmetric key cryptosystem using a secret key K. h(.):a one-way hash function (e.g., SHA-1). T: the required minimum time duration (e. g., 10 seconds) of any statement spoken by a user. 6: a threshold value which is much less than T, (e.g. 6=0,1T). The value of 6 (or equivalently that of T ) plays an important role in deciding the security strength of the protocol (refer to Eq.(l)).
Yongdong Wu, Feng Bao, Robert H. Deng
208
To keep our notation compact, only residue modulo is shown in the following. That is, we will write gx mod p, gY mod p and gq mod p simply as gx, gY and gq respectively, where p is a predefined large prime.
2.2
System Architecture
The system architect for person-to-person communications between two remote users, Alice and Bob, is depicted in Figure 1. We assume that Alice and Bob are aware that they will have an authenticated and confidential communication session and Alice will start the present secure protocol. This awareness assumption can be satisfied easily via any non-secure channel. The transmission channel includes but is not limited to any communication systems or media such as computer networks, public telephone switching networks and radio links. Device A Alice
I Fl-f=-py Attacker
Device B
Clock 2
Transmission Channel
I
Coder
Figure I. The communication system architecture.
Alice and Bob communicate with each other by interfacing with Device A and Device B, respectively. Device A (or Device B) accepts audio input from Alice (Bob) and outputs Bob's (Alice's) audio signal to Alice (Bob). The signals are sent and received via the Network Interface (NI). Each device has a clock for timing purpose, a coder performing audio encodingldecoding operations, and a crypto-engine executing the DiffieHellman and symmetric key cryptosystem operations. We assume that the Diffie-Hellman parameters, g and p, are negotiated on-line or hard coded in the software. Without loss of generality, Alice is assumed to be the initiator and Bob is the responder of a communication session.
Secure Human Communications Based on Biornetrics Signals
2.3
Assumptions
The attacker Clark sits in the middle of the channel between Alice and Bob. He is able to perform both passive (eavesdropping) and active (message tampering, delay, replay). He may know biometrics data of Alice and Bob recorded from their past conversations. Clark may have much more powerful resources (e.g. super-computers and large storage devices) than Alice and Bob. The only restriction is that Clark is not able to mimic the natural speech of Alice or Bob in real time. Alice and Bob neither share any secret data (e.g., password) nor have each other's public key. In order to achieve user authentication, we make the following assumptions: S I : Alice and Bob are familiar with each other's voice (biometrics characteristics in general) and able to recognize each other by listening each other's speech. This assumption is reasonable and practical since there are generally no confidential topics between two strangers unless there is the involvement of a trusted third party. S2: It is difficult for a human being to mimic the dynamic biometrics features of others in real time without being detected. S3 It is difficult for a machine to mimic the dynamic biometrics features of a human being without being detected. Text-To-Speech (TTS) technology targets for creation of audible speech from computer readable text. A high quality TTS has to select text units from large speech databases in an optimum way5. To make use of TTS, an attacker needs to organize a database of large samples. On the other hand, although speech syntheses technology has made significant advancement in minimizing audible signal discontinuities between two successive concatenated units, and prosodic variation, it is still not satisfactory to mimic natural speech6.For example, in the TTS demo7 of Microsoft Research, the speech is not nature although each word or short phrase is pronounced accurately, such that it is easy to distinguish the voice of a machine from that of a natural human. Similarly, the concatenation artifacts of TTS from AT&T' can be detected easily. In other words, presently, synthesized speech is still distinguishable from human speech after many years of research and development. S4: Each participant can speak fresh sentences whose durations are sufficient long (e.g, at least 7). S5: The RTT (round-trip-time) of the communication channel can be estimated (e.g., command ping www.y a h o o . corn). It is required that RTT << T. This requirement must be met in order for the conversations between the communicating parties to be audible.
Yongdong Wu, Feng Bao, Robert H. Deng
210
3.
AUTHENTICATION PROTOCOLS BASED ON BIOMETRICS SIGNALS
In this section, we present authentication protocols based on the exchange of users' biometrics signals. The protocols are designed to perform mutual authentication between two parties called Alice and Bob and at the same time allow them to share a secret session key for securing their subsequent communications.
3.1
Basic Idea
To start a secure communication session with our proposed scheme, Alice initiates the session by speaking a challenge statement, such as "This is Alice! The time is 21 minutes passed 9am. How was your midterm examination, Bob? " Bob receives and listens to Alice's challenge, and makes sure that the message is indeed spoken by Alice. He then speakes a response statement, such as "Hi, Alice! Bob's here. My mid-term exam was not very good. But thank God, it was over! ". Upon hearing Bob's response, Alice decides whether the response is spoken by Bob and whether it is related to her challenge. If the answer is positive, Alice authenticates Bob. Bob can authenticate Alice in the same way. In order to establish a secret session key during the above authentication process, we incorporate the Diffie-Hellman key exchange into our scheme. By cryptographically binding biometric signals with Diffie-Hellman public values, the proposed scheme is protected against the man-in-the-middle attack. The above conceptual description seems very simple, the scheme is more complicated. To demonstrate the above concept, we present two protocols, a sequential protocol and a parallel protocol in the following.
3.2
A Sequential Protocol
The authentication protocol consists of three phases: Authentication of Bob, Authentication of Alice. Additionally, a Key Confirmation will be executed so as to guarantee that both share the same session key.
3.2.1
Authentication of Bob
This phase, shown in Figure 2, allows Alice to authenticate Bob and
Secure Human Communications Based on Biometries Signals
2.Generate x,
2.Speak CB
Figure 2. Authentication of Bob. An underlined step is performed by Alice or Bob, while other steps are executed by devices. RE - CA means that the reply RB matches the challenge CA. For instance, the content of RB is the same/similar to that of CA, or RB is a correct answer to CA
212
Yongdong Wu, Feng Bao, Robert H. Deng
obtain Bob's Diffie-Hellman public value gy in an authenticated manner. Alice's Challenge. Here Alice sends a challenge statement to Bob. This biometrics signal is cryptographically bound to Alice's Diffle-Hellman public value. (1) Alice speaks a challenge statement CA which is input to Device A. It is highly preferred that CA contains some "freshness" elements such as the date and time, news headlines of the day. (2) Device A generates a random number x, computes gx and a key KA=h(gx).Next, Device A encrypts CA using KA with a symmetric key cryptosystem (e.g. AES) and sends the ciphertext A1=e(KA,CA) to Bob over the transmission channel. Bob's Commitment. In the next 2 steps, Bob sends commitment to Alice so that Alice discloses her challenge. Bob's commitment contains the encryption of his challenge statement which will be opened by Alice at a later stage. (3) Device B receives message Al and prompts Bob to speak a challenge statement CB. (4) Device B generates a random number y, computes g" and a key KB=h(g"), encrypts CB using Kg with a symmetric key cryptosystem and transmits the ciphertext BI=e(KB,CB)to Alice. Bob's Response. The next 4 steps allow Bob to send his response statement to Alice. ( 5 ) Device A receives B1, sends A2 = gx to Device B and starts a clock. (6) Device B computes KA=h(gx),recovers CA=d(KA,A1), and computes a key KBA= h(gX)'). (7) Device B plays back CA to Bob who listens to it and verifies if the voice belongs to Alice. If the verification fails, Bob terminates the session; otherwise, Bob speaks a response statement RB in reply to CA. Device B encrypts RB with KBAto obtain B2 =e(KBA,RB ), and sends 8 and B2 to Device A. (8) Upon receipt of message B2, Device A stops the clock and obtains tA the elapsed time of the clock. Alice's Verification. In the next 3 steps, Alice verifies the originality of the response and checks the elapsed time used in obtaining the response. (9) Device A computes KAB=h(f) and KB=h(gY),and then she recovers CB=d(KB,B1) and RB=d(KAB,B2), and computes ICA((the duration of CA)and ]RBI(the duration of RB). (10) Note that within the time tA, Bob has to listen to CA and speaks a response RB. Hence, tA2 (ICA I + I RB I+ AB), where AB is the delay due to transmitting messages A2 and B2, and processing time introduced by Device B in steps (6) and (7). AB can be estimated by device A. Then, Device A calculates
Secure Human Communications Based on Biornetrics Signals
213
6~ = t~ - (ICA I + I RB I + AB) (1) If 6A > 6, Device A terminates the session; otherwise, Alice listens and verifies RB. If Alice recognizes that either RB is not in Bob's voice or RB is not a reply to CAIshe stops the session. (1 1)Alice concludes that gY comes from Bob and authenticates Bob.
3.2.2
Authentication of Alice
To provide mutual authentication and key agreement, Bob will proceed to authenticate Alice and obtain Alice's Diffie-Hellman public value gx in an authenticated manner. The process is similar to that given above with the exception that Bob is the initiator and Alice is the responder. Note that Bob's challenge statement CB was sent to Alice in step (4). This is done intentionally so as to prevent the man-in-the-middle attack during the process of authenticating Alice. After both Alice and Bob have obtained the each other's authenticated Diffie-Hellman public key values, they are confident that the agreed DiffieHellman key KABis shared only among them. After mutual authentication, Alice and Bob can confirm their shared key easily.
3.3
A Parallel Protocol
A careful reader might have noticed that certain steps in Figure 2 can be executed in parallel so as to speed up the protocol. Figure 3 depicts the flow chart of the parallel protocol which has the same phases as those of the sequential protocol. Challenges (1) Alice starts the session by speaking a challenge statement CA. (2) Device A generates a random x, computes a key KA=h(gX),encrypts CAas A1=e(KA,CA)and sends the ciphertext Al to Bob. (3) After receiving message A], Bob speaks a challenge statement CB. (4) Device B generates a random number y, computes a key KB=h(gY), encrypts Ce as BI=e(KB,CB)and sends the ciphertext B1 to Alice. (5) After receiving B1,Device A sends A2=gx to Bob and starts clock 1. (6) Upon receipt of message A2, Device B starts its clock 2 and sends message B2=gY to Alice. Responses (7) After receiving message B2, Device A computes KB=h(8), recovers Bob's challenge message CB=d(KB,Bl). On the other hand, Device B computes KA=h(gX),recovers Alice's challenge as CA=d(KA,A]). (8) Alice listens CBand stops the protocol if she believes that CB is not in Bob's voice; Bob listens to CAand terminates the protocol if he
214
Yongdong Wu, Feng Bao, Robert H. Deng 1. Speak CA
2.Generate x,
A ] = e(KA,CA)
KA = h(gX)
3. Receive A ] . Speak CB I
5. Start clock 1
A2 = gX
Start clock 2
Bob
Alice 1
7. KB = h(gY)
7. KA = h(gX)
CB = ~ K BB , )
CA= ~ ( K AA,I )
stop
9. Speak RA
9. Speak RB
KAB= htsQ)
KBA= h(gq)
10. Stop clock 1, RB = d(KAB,B3), calculate tA
d(KBA,A3), calculate tB
Stop
Authenticated Figure 3. Parallel protocol.
Authenticated
Secure Human Communications Based on Biometries Signals
215
doubts on the originality of CA. ( 9 ) Alice speaks a response RA to the challenge CB.Device A computes KAB=h(gY"),encrypts RA and sends the ciphertext A3=e(KAB,RA) to Bob. Meanwhile, Bob speaks RB in reply to CA.Device B computes a key KBA=h(gV),and sends the ciphertext B3=e(KBA, R B )to Alice. (10) After receiving message B3, Device A stops clock 1 , recovers Bob's response RB=d(KAB,B3) and calculates the elapsed time tA. After receiving message A3, Device B stops clock 2, recovers Alice's response RA =d(KBA,A3),and calculates the elapsed time tB. Verifications (1 1 ) Device A calculates 6A as 6A= tA - (ICAI + I RBI+ AB) where AB is the delay due to transmitting messages A2 and B3, and processing interval introduced by Device B in steps (7)-(9).Device A terminates the session if >6. Simultaneously, Device B calculates 6~ as t~ - (ICBI+ I RAl+ AA), where AA is the delay due to transmitting messages B2 and A3, and processing interval introduced by Device A in steps (7)-(9).Device B terminates the session if 6B > 6. Alice listens and verifies RB. She stops the session if she is not convinced that RB is Bob's response to CA. Bob listens and verifies RA. He stops the session if he is not convinced that RA is Alice's response to CB. ~
3.4
B
I
Variant
An alternative approach in the protocol is that the symmetric key cryptosystem for messages CA and CB can be replaced by a cryptographic commitment function. For example, the commitment function is using a cryptographic one-way function h(.). To commit to an item m , the committing party computes the commitment h(k 11 m), where k is a secret key and 11 is the concatenation. To verify the commitment, the verifying party must have k and m, compute h(k I( m) and compare it with the commitment. In other word, A, can be replaced with h(KA 11 CA) , then CA will be transmitted along with A2. Similarly, the parallel protocol can be implemented with the commitment variant too.
Yongdong Wu, Feng Bao, Robert H. Deng
4.
DISCUSSION
4.1
Availability
In the present protocols, time restriction plays an important role for the availability. The scheme requires the responsor produce a related response in real time, otherwise, the authentication fails. To relieve this burden, the responsor may merely repeat the challenge in hidher own voice. Here, the challenge can be prepared in advance and has no impact on the availability. Another factor related to the availability is the variability of the network delay T. An inappropriate parameter T may disable to set up an authenticated channel. Thus, the proposed scheme is applicable such as in VOIP where the quality of the service itself is required to be high. Despite the proposed protocols may reject some genuine communication, no forgery is possible. In other words, although false rejection ratio FRR+O due to network traffic, FAR (false acceptance ratio) is negligible. From the viewpoint of security, FAR is much more important than FRR.
4.2
Impersonating Bob
In the proposed protocols, an important condition for Alice (Bob) to authenticate Bob (Alice) is that Bob's (Alice's) response to her (his) challenge must arrive within a defined time interval. Therefore, if Clark can obtain the correct answer in the voice of Bob (or Alice) in the predefined time interval, he can impersonate Alice (Bob) successfully. To this end, Clark may adopt one of the following three methods to provide the response in the voice of the impersonated party. Clark replays recorded speeches of the impersonated party. Clark or his device responses to the challenge by emulating the speech of the impersonated party. Clark lures the impersonated party to answer the challenge. The first two methods are not possible based on security assumptions S1S3. To defend against Clark's attack using the third method, it is crucial to check the lengths of the elapsed time of the clocks. Assume that an attacker would like to impersonate Bob, Figure 4 illustrates a possible way to lure Bob to respond with RB. To this end, Clark performs a man-in-the-middle attack shown in Figure 4 so as to obtain CA and RB. In this simulated attack, Alice proceeds in the same way as that shown in Figure 2. For the sake of simplicity, we will only show the main steps which are related to the attack.
Secure Human Communications Based on Biometrics Signals Alice
Clark
Bob
Obtain CA generate y,
Obtain CA,
Figure 4. Impersonate Bob. Clark shares a channel with Alice and Bob simultaneously so that he can eavesdrop messages between them.
4.2.1
Obtaining Alice's challenge C A
In Figure 4, Alice starts a session and sends the ciphertext AI=e(KA,CA ) to Bob. After intercepting the ciphertext A,, Clark generates a number z, computes a key Kc=h(gz)).Based on Assumption S2, Clark can not mimic Bob to speak a challenge, but he may reuse Bob's recorded speech. Clark encrypts an old statement CrBspoken by Bob, and sends to Alice the ciphertext e(Kc, CtB). Alice receives the ciphertext, replies with g.' and starts a clock. Clark derives a key KA =h(gX)and recovers CA= d(KA,CA).
4.2.2
Obtaining Bob's response RB
Because Clark can not mimic Bob's voice to produce an appropriate response RB,he has to lure Bob to respond to Alice's challenge CA. To this end, he impersonates Alice and starts a new session with Bob by sending Bob e(Kc, CA). Next, upon receipt of e(Kc, CA ), Bob generates a random y,
Yongdong Wu, Feng Bao, Robert H. Deng
218
computes a key KB =h(gy),speaks a challenge statement CB, and sends the ciphertext e(KB,C B )to Alice. Clark intercepts the ciphertext. To continue to impersonate Alice, Clark sends gz to Bob. Bob computes Kc =h(gZ),decrypts e(Kc, CA), listens to CA which was indeed spoken by Alice. Bob speaks a response statement RB, computes a key KBC=h(gZY), and transmits gY and the ciphertext e(KBc,RB)to Alice. Clark again intercepts the ciphertext, computes KBC= h ( f ) to decrypt e(KBc,RB ). Now he gets RB !
4.2.3
Calculating the elapsed time
Clark computes KAc=h(gxZ),encrypts RB with KAC, and sends the ciphertext e(KAc, RB) to Alice. Alice stops the clock and calculates the elapsed time tA,decrypts the ciphertext e(Kc, C f B )and e(KAc,RB)to recover C r Band RB, respectively. Alice makes sure that CtB and RB are in Bob's voice. Since RB is indeed a response to CA from Bob, Alice will be fooled into believing Clark as Bob! Luckily, our protocol prevents this from happening by checking the clock's elapsed time tA in the following.
4.2.4
Checking the elapsed time
Consider the man-in-the middle attack shown in Figure 4. Within the time interval tA,Bob has to speak his challenge statement CB, listens to CA, and speaks the response RB;therefore, tA 2 1 CBJ+ [CAI+ [RBI+ Ah, where Ab is the time used in computation and transmission. With reference to Eq.(l), Alice checks 6~= tA - (ICAI + I RBI+AB)2 1 C B2~ T > 6. Therefore, by checking the value of tA, Alice detects the man-in-themiddle attack and stops the session.
4.3
Impersonating Alice
The other kind of possible attack is to impersonate the initiator Alice. To this end, Clark has to obtain the original challenge CB and then Alice's respond RA to Bob's challenge CB.Figure 5 shows the second scenario of the man-in-the-middle attack, where Clark impersonates Alice to Bob. Therefore, Clark must start the communication with Bob at first.
4.3.1
Obtaining Bob's challenge CB
Clark generates z, computes a key Kc= h(gZ),and encrypts C'A - an old statement from Alice. Clark starts the impersonation by sending the ciphertext e(Kc, CIA) to Bob.
Secure Human Communications Based on Biometries Signals
219
Upon receipt of Clark' message, Bob generates y, and a key KB =h(gY).He then speaks a reply Cg, and transmits the ciphertext e(KB, C g ) to Alice. Clark sends gZto Bob. Bob derives Kc =h(gZ),decrypts e(Kc, CIA)with Kc to recover CIA. Bob listens to CIA and believes that CtAwas indeed spoken by and Alice. He then speaks a response statement Rg, derives a key KBC=h(gZY), transmits gY and the ciphertext e(KBc,R g ) to Alice. Bob then starts a clock. Next, upon interception of e(KBc,R g ) and 8,Clark derives KB=h(gY)and KBC=h(gZY), decrypts e(KB,C g ) to recover CB! Alice
Clark
Bob
generate y,
Figure 5. Impersonate Alice.
4.3.2
Obtaining Alice's response RA
Since Clark is not able to reply Cg in Alice's voice, he starts a session with Alice by sending e(Kc, C B )to Alice. Upon receipt of e(Kc, CB),Alice generates x, and computes a key KA=h(gx). She speaks a challenge CA, and sends the ciphertext e(&, CA)to Bob. Clark intercepts the ciphertext and sends gz to Alice. Alice derives a key Kc =h(gz),decrypts e(Kc, Cg) to recover Cg. She listens to Cg and believes that it is in Bob's voice. Alice speaks a response statement RA, computes KAC=h(gXZ),sends gx and the ciphertext e(KAc, RA) to Bob. Clark intercepts the message from Alice and decrypts the ciphertext to obtain RA!
220 4.3.3
Yongdong Wu, Feng Bao, Robert H. Deng
Checking the elapsed time
After obtaining RA, Clark sends the ciphertext e(KBc,RA) to Bob. Bob receives e(KBc, RA), stops the clock and calculates the elapsed time tB. Without checking the elapsed time tg, Bob would have been fooled into believing that he is talking to Alice since RA is Alice's reply to CB.However, within interval tg,Alice has to speak CA,listen to CBand speak RA, thus, 6 g = t B - ( I C ~ I + I R ~ I + A1~C)~2l > T > 6 . Therefore, by checking the elapsed time tg, Bob detects the man-in-themiddle attack and hence stops the session.
CONCLUSIONS The present paper describes a scheme for mutual authentication and key establishment between two remote human users. Unlike most of the existing authenticated key establishment protocols where remote authentication is based on sharing a secretJpassword or knowing remote party's public key, our scheme is based on exchanging of signals representing remote user's biometrics information. Although clock timing plays an important role in our protocols, only relative time is used so that synchronization between two parties is not required. Our technique is especially useful for securing telephony or videoconference communications over open networks. We illustrated our scheme with protocols using audio signals to represent users' biometrics information. It should be noted that security of the protocols can be improved with additional biometrics information such as facial image and mouth movement. Such additional information adds few burdens to the human users, but greatly increases the difficulty of attacking the protocols.
REFERENCE 1. 2. 3. 4.
5.
D. Otway and 0 . Rees, "Efficient and timely authentication", Operating Systems Review, Vol. 21, No. 1, pp. 8-10, 1987. C. Kaufman, R. Perlman, and M. Speciner, Network Security - Private Communication in A Public World, PTR Prentice Hall, Englewoor Cliffs, NJ, 1995. R. H. Deng, J. Zhou and F. Bao, "Defending against redirect attacks in mobile IP," ACM Conference on Computer and Communications Security, pp. 59-67, 2002. P. Zimmermann, PGPfone Owner's Manual, Version 1.0 beta 5 , 5 January 1996, http://web.mit.edu/network/pgpfone/manual. Hunt and A. Black, "Unit selection in a concatenative speech synthesis system using large speech database," IEEE International Conf. on Acoustics, Speech, and Signal Processing (ICASSP), pp.373-376, 1996.
Secure Human Communications Based on Biometries Signals 6.
7. 8.
22 1
Matthias Jilka, Ann K. Syrdal, Alistair D. Conkie and David A. Kapilow, "Effects on 'ITS Quality of Methods of Realizing Natural Prosodic Variations," 151h International Congress of Phonics Science (ICPhS) 2003. TTS,https://research.microsoft.com/speech/t;ts/TTS.dll?TTS AT&T, TTS: Synthesis of Audible Speech from Text, http://www.research.att.com/projects/tts/
DISTANCE-BOUNDING PROOF OF KNOWLEDGE TO AVOID REAL-TIME ATTACKS" Laurent Bussard and Walid Bagga Instittct EurCcom, Corporate Cornmtmications, 2229 Rotrte des Crgtes, BP 193, 06904 Sophia Antipolis (France) {bussard,bagga}@eurecom.fr
Abstract:
Traditional authentication is based on proving the knowledge of a private key corresponding to a given public key. In some situations, especially in the context of pervasive computing, it is additionally required to verify the physical proximity of the authenticated party in order to avoid a set of realtime attacks. Brands and Chaum proposed distance-bounding protocols as a way to conlpute a practical upper bound on the distance between a prover and a verifier during an authentication process. Their protocol prevents frauds where an intruder sits between a legitimate prover and a verifier and succeeds to perform the distance-bounding process. However, frauds where a malicious prover and an intruder collaborate to cheat a verifier have been left as an open issue. In this paper, we provide a solution preventing both types of attacks.
Keywords:
Real-time attack, distance-bounding, authentication, proof of knowledge
INTRODUCTION The impressive development in the areas of web technologies, wireless networks, mobile computing, and embedded systems in the past decade has lead to an increasing interest in the topics of pervasive computing and open environments computing. In these contexts, authentication of communicating parties is considered as a major security requirement. As described in [8], a careful authentication may require the verification of the physical proximity of the authenticated party in order to prevent some real-time attacks. A 12 The work reported ir, this paper is suppolted by tine IST PRIME project and by Institut EurCcom; however, it represents the view of the authors only.
Laurent Bussard and Walid Bagga
224
typical example is applications where digital authentication is required to access a building. In the scenario depicted in Figure 1-a, a researcher carries around a mobile device (a mobile phone with extended functionalities or a PDA enhanced with communication capabilities) that takes care of computing, storage and communication on his behalf within the laboratory environment. Whenever the researcher approaches the door of a confidential research area, a communication is established between his mobile device and a lock device installed at the door. If the researcher is authorized to access the research area, the door is unlocked. Whenever the combination of the physical proximity and the cryptographic identification is not carefully addressed, some frauds could be performed such as the one depicted in Figure I-b. In this fraud, a distant researcher (prover) that is allowed to access the confidential research area helps a friend (intruder) that is close by to access the area. For instance, a radio link could be used to establish the communication between the prover and the intruder.
Prover
Verifier hover
( a ) Legitlinatr Access
(b) F~oudulentA x e s \
Figure I .
Access to a Confidential Research Area
The scenario described above falls under a quite recurring family of security protocols where a prover tries to convince a verifier of some assertion related to his private key. In order to address this problem, Brands and Chaum introduced the concept of distance-bounding protocols in [4]. Such protocols allow determining a practical upper bound on the distance between two communicating entities. This is performed by timing the delay between sending out a challenge bit and receiving back the corresponding response bit where the number of challenge-response interactions is determined by a system-specific security parameter. This approach is feasible if, on one hand, the protocol uses very short messages (one bit) on a dedicated communication channel (e.g. wire, IR) and if, on the other hand, no computation is required during each exchange of challenge-response bits
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
225
(logical operations on the challenge bit). These conditions allow having round-trip times of few-nanoseconds. The protocols given in [4] allow preventing ma$a frauds where an intruder sits between a legitimate prover and a verifier and succeeds to perform the distance-bounding process. In this paper, we provide an extension of such protocols. Our solution allows preventing terrorist frauds [S] that have not been addressed so far. In these frauds the prover and the intruder collaborate to cheat the verifier. Note that even if the prover is willing to help the intruder to cheat the verifier, we assume that he never discloses his valuable private key. The key idea in our solution consists of linking the private key of the prover to the bits used during the distancebounding process. This relies on an adequate combination of the distancebounding protocol with a bit commitment scheme and a zero-knowledge proof of knowledge protocol [12]. The remainder of this paper is organized as follows. In Section 1, we define the frauds being addressed and give some related work. In Section 2, we draw a general scheme for distance-bounding proof of knowledge protocols, while we give a description of our protocol in Section 3. In Section 4, we analyze the security properties of the proposed protocol. At the end, we conclude and describe further work.
1.
PROBLEM STATEMENT
In this section, we provide the definitions of the three attacks we tackle in this paper, namely distance fraud, majiafiaud, and terrorist fraud. Next, we present related work and we show why the existing approaches are not satisfactory.
1.1
Definitions
Distance-bounding protocols have to take into account the three real-time frauds that are depicted in Figure 2. These frauds can be applied in zeroknowledge or minimal disclosure identification schemes. The first fraud is called the distance fraud and is defined in the following (Figure 1-a).
DEFINITION1 (DISTANCEFRAUD)In the distance fraud two parties are involved, one of them (v the veriJier) is not aware of the fraud is going on, the other one (P the fraudulent prover) performs the fiaud. The Ji-aud enables P to convince V of a wrong statement related to its physical distance to prover V. The distance fraud has been addressed in [4]. This fraud consists of the following: if there's no relationship between the challenge bits and the
Laurent Bussard and Walid Bagga
226
response bits during the distance-bounding protocol and if the prover P is able to know at what times the challenge bits are sent by the verifier V, he can make V compute a wrong upper bound on his physical distance to V by sending out the response bits at the correct time before receiving the challenge bit, regardless of his physical distance to V.
// I/
: Honest patTy Fraudulent party
-
-
. Close Remote
/
( c )Terrorist Fraud
Figure 2.
Three Real-Time Frauds
The second fraud is called the mafia fruud and is defined in the following (Figure 1-b).
DEFINITION2 (MAFIAFRAUD)In the mafia fraud three parties are involved, two of them (P the honest prover and V the verifier) are not aware of the fraud is going on, the third party (I the intruder) pet$orms the fraud The fraud enables I to convince V of an assertion related to the private key of P. The mafia fraud has been first described - - in [8]. In this fraud, the intruder I is usually modeled as a couple ( P , V ) where P is a dishonest prover interacting with the honest verifier V and where V is a dishonest verifier interacting with the honest prover P. Thanks to the collaboration of y , the fraud enables P to convince V of an assertion related to the private key of P. The assertion is that the prover is within a certain physical distance. This fraud was also called Mig-in-the-middle attack in [2]. The third fraud is called the terroristfraud and is defined in the following (Figure 1-c).
DEFINITION 3 (TERRORISTFRAUD) In the terrorist fratrd three parties are involved, one of them (V the verifier) is not aware of the fraud is going on, the two others (P the dishonest prover and I the intruder or terrorist) collaborate to perform thepaud. Thanks to the help of P, the fraud enables I to convince V of an assertion related to the private key of P. The terrorist fraud has been first described in [8]. In this fraud, the prover and the intruder collaborate to perform the fraud whereas in the mafia fraud the intruder is the only entity that performs the fraud. Note that the prevention of terrorist frauds implies :he prevention of mafia frauds.
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
1.2
227
Related Work
In this section we review different techniques that have been proposed and show why they are not sufficient when it is necessary to verify that some entity knowing a private key is indeed physically present. Constrained Channel [13] aims at exchanging some secret between two physical entities and thus ensures the proximity of two devices. An obvious implementation is to have a physical contact [16] between the two artifacts. This scheme works only when the attacker is not physically present. It can protect a system only against distance frauds. Context Sharing is a straightforward extension of constrained channels where some contextual data is used to initiate the key exchange. For instance, in [lo], the pairing mechanism is done by shaking artifacts together in order to create a common movement pattern that is subsequently used to bootstrap the security of communications. This approach prevents distance frauds and can partially avoid mafia frauds when the context is difficult to reproduce. Isolation [3] is a widely deployed solution to check whether a physical entity holds a secret. The device is isolated in a Faraday cage during a challenge-response protocol. This solution prevents distance frauds, mafia frauds as well as terrorist frauds. However, it is difficult to deploy, it is not user-friendly, and does not allow mutual authentication. Unforgeable Channel aims at using communication channels that are difficult to record and reconstruct without knowing some secret. For instance, channel hopping [I] or radio frequency watermarking [ l l ] makes it difficult to transfer data necessary to create the signal in another place. This scheme protects against distance frauds and the solution proposed in [I] can prevent mafia frauds as well when it is not possible to identify communication sources. Quantum cryptography can also be envisioned as an unforgeable channel. Time of Flight relies on the speed of sound andlor light. Sound and especially ultra-sound [15] is interesting to measure distance since it is slow enough to authorize computation without reducing the accuracy of the measure. Sound-based approaches cannot protect against physically present attackers and thus can only prevent distance frauds. Some works also rely on the speed of light when measuring the round trip time of a message to evaluate the distance to the prover. However, one meter accuracy implies responding within few nanoseconds and thus it cannot be done through standard communication channels and cannot use cryptography 1171. Such schemes prevent distance frauds and the solution proposed in [4] prevents mafia frauds as well. As shown above, only isolation allows preventing distance, mafia and terrorist frauds all together. In this paper, we focus on distance-bounding
Lazrrent Bussavd and Walid Bagga
228
protocols and propose a solution that prevents the three real-time attacks. In contrast with isolation, our approach is easy to deploy and allows mutual authentication.
THE GENERAL SCHEME In this section, we present a general scheme (denoted DBPK) containing the basic building blocks of distance-boundingpvoof of knowledge protocols.
2.1
Description
The DBPK scheme is depicted in Table 1. It relies on a set of global settings that have to be performed before the execution of any interaction between the prover and the verifier. Besides the cryptosystem's public parameters, these global settings allow the prover to have a valuable private key and a certificate on the corresponding public key. That is, before any interaction with the verifier, the prover holds a private key x which importance, by assumption, is so high that the prover should not reveal it to any other party. In addition, the prover holds a certificate (generated by a globally trusted authority) on its public key y = T(x). The first stage of the DBPK protocol is called the Bit Commitment stage. During this stage the prover first picks a random one-time key k E K and uses it to encrypt its private key x according to a publicly known symmetric key encryption algorithm E. This leads to the ciphertext e = ER(x).Once the encryption performed, the prover commits to each bit of both k and e according to a secure bit commitment scheme commit. For each bit Hi] (resp. e[i]), a string v, (resp.vJ,) is randomly chosen by the prover to construct the (resp. q,,)). commitment blob qk,,) Once the Bit Commitments stage is completed, the actual distancebounding interactions are executed during the Distance-Bounding stage. Basically, N interactions are performed between the prover and the verifier. In the ith interaction, the prover releases either kfi] or e[i] depending on whether the challenge bit is equal to 0 or to 1. Note that Hi] (resp. e[i]) denotes the ithbit in the binary representation of k (resp. e) where kfO](resp. e[O]) is the least significant bit of k (resp. e). During each bit exchange, the round trip time (few nanoseconds) is measured in order to verify the distance to the prover.
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
229
v
P Prover (private keys) (public key y = T(s))
Verifier (P's public key y)
Bit Commitments secret key k E R ?!( N=/log2(lKI)1 , M = { O , . . . . N - 1 ) e = !&(.Y) t (0.1)" for all I E !?d v,,vi ER {O,1 j* for all 1 E M cc(,,,) = c o m m ~ t ( k [v,) ~]. for all r E !M cc(,,I = corntmf(e[l], v:) for all i E M
c j i ,)
.
,I C
Distance-Bounding (for all i E 34)
EK (0%1)
Commitment Opening for all i E 94 (if 6 ( n , ) = 1) vi (if 6(ai)= 0) 11:
Proof of knowledge
Figure 3. A general scheme for DBPK[c( : y = r(a)]
After the execution of the N successful challenge-response bit exchanges, the prover opens the commitments on the released bits of k and e. The Commitment Opening stage consists of sending the string v, if q i ] has been released and v', otherwise. Only half of the bits of k and e are released to the verifier. This must not allow the verifier to get any significant information
Laurent Bzlssard and Walid Bagga
230
about the valuable private key x. In the case where the verification of c(k,i) (resp. q,,)) fails, the verifier sends back an error notification of the form errork(i)(resp. error,(i)). The last step in the DBPK protocol is the Proof of Knowledge stage. During this stage, the prover convinces the verifier in a zero-knowledge interaction that he is the party who performed the three previously described stages. That is, the prover proves that he has generated the different commitments, that the generated commitments correspond to a unique private key, and that this private key corresponds to the public key y that is used by the verifier to authenticate the prover. Before the proof of knowledge process can be performed, the verifier must compute a one way function on the private key x: z = Q(x,y)where v and x are known only by the prover. As z depends on and only on the commitments on the bits of k and e, it may even be computed just after the Bit Commitments stage. The proof of where the knowledge we use is denoted PK[(a,P): z = Q(a,P)A y = r(a)] Greek small letters denote the quantity the knowledge of which is being proved, while all other parameters are known to the verifier. The functions R, r, 6, E, and commit are adequately chosen to meet our security requirements, namely the prevention of the distance, mafia, and terrorist frauds. The distance-bounding proof of knowledge of a secret x such that y=T(x) is denoted DBPK[a : y = r(a)].
3.
OUR PROTOCOL
This section presents a concrete distance-bounding proof of knowledge protocol that consists of exactly the same building blocks of the DBPK protocol. The protocol will be denoted DBPK-Log = D B P a a : y =gal.
3.1
Global Settings
We first describe the global settings on which relies the DBPK-Log protocol. These settings consist of two main phases: Initialization and Registration. In the Initialization stage, a trust authority (TA) provides the public parameters of the system.
Initialization: TA sets up the system's global parameters TA chooses a large enough strong prime p, i.e. there exists a large enough prime q such that p = 2qt 1 TA chooses a generator g of z,* 9 TA chooses an element h E z,*
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
23 1
The randomly chosen element h will be used by the commitment scheme. The only requirement is that neither of the prover and the verifier knows log,(h). This can be achieved either by letting the trusted authority generate this element, or by malung the prover and the verifier jointly generate h. The two alternatives rely on the intractability of the discrete logarithm problem D41. In the Registration stage, a user chooses a private key and registers at the trust authority so to get a certificate on the corresponding public key.
Registration: The following steps are taken by P to get a certified public key corresponding to a valuable private key P selects an odd secret x E R z,., I Jq], then computes y =,d'. The public key of P is y and his private key is x P registers his public key with TA so TA publishes a certificate on this public key Note that the two phases described above are executed only once. They allow generating the prover's public and private keys that will be used in the different subsequent distance-bounding proofs of knowledge.
3.2
Interactions
Our distance-bounding proof of knowledge protocol starts with the Bit Commitments stage where the prover P generates a random key k, and uses this key to encrypt the private key x. Then, P performs a secure commitment on each bit of the key k and encryption e.
Bit Commitments: The following steps are performed Given a security parameter m', P picks at random k E R (0, ..., y-I}, where N = m'tm and m = rlog2(p)1. P computes e E (0,. .., 2 N - ~such } that e x-k modp-1. For all i E JO, ..., N-I], P chooses vk,, Vsi E R Zp-,,computes c ~= gqj , ~ .hvk,'modp and c ,=~ge['l.hYe,'modp , then sends ck,,as well as c j to V
-
Once the verifier V receives all the commitment blobs corresponding to the bits of k and e, the Distance-Bounding stage can start. Thus, a set of fast single bit challenge-response interactions is performed. A challenge corresponds to a bit chosen randomly by V while a response corresponds either to a bit of k or to a bit of e.
Laurent Bzrssard and Walid Bagga
Distance-Bounding: For all i E 10, ..., N-I}, V sends a challenge bit ai€, J0,I) to P P immediately sends the response bit b, = Zik[i] ale[i]to V
+
At the end of the Distance-Bounding stage, the verifier V is able to compute an upper bound on the distance to P. In order to be sure that P holds the secrets k and e, the prover P opens, during the Commitment Opening stage, the commitments on the bits of k and e that have been released during the Distance-Bounding stage.
Commitment Opening: The commitments of the released bits are opened. If all the checks hold, all the bit commitments on k and e are accepted, otherwise they are rejected and an error message is sent back For all i E JO, ...,N-I}, P sends 3vk,;+ a,v,,, to V For all i E JO, ...,N-I}, V performs the following verification:
a,ck , ~+ a,cr,i = g C k [ ' l + w [ i l . h z v ? ,
I
,
k.t+or~e,!
I
mod p
The proof of knowledge allows the verifier V to be sure that e is indeed the encryption of the private key x corresponding to the public key y of the prover. From the bit commitments, V can compute:
Note that V is able to compute z as soon as all the commitments on the bits of k and e are received.
Proof of Knowledge: Given z = gT.hv, the following proof of knowledge is performed by P and V: PK[(a,P) : z = $hP A y = gal.
4.
SECURITY ANALYSIS
In this section, we discuss the relevant security properties of the DBPKLog protocol. First, we show that our protocol prevents distance, mafia, and terrorist frauds. Next, the security properties of the encryption scheme that is used to hide the prover's private key are studied.
Distance-Bounding Proof ofKnowledge to Avoid Real-Time Attacks
4.1
233
Preventing Distance, Mafia and Terrorist Frauds
The first security requirement for our distance-bounding proof of knowledge protocol is a correct computation of an upper bound on the distance between the prover and the verifier. This requirement is being already achieved in the DBPK general scheme according to the following.
Proposition 4.1 Ifthe DBPKprotocol is performed correctly, then the distance fraud has a negligible probability of success. Pro08 Assume that the prover P knows at what times the verifier V will send out bit challenges. In this case, he can convince V of being close by sending out the bit response bi at the correct time before he receives the bit ai. The probability that P sends correct responses to V before receiving the challenges is equal to
In Proposition 4.1, the correct execution of the protocol means that each party performs exactly and correctly the actions specified in the different steps of the protocol. The DBPK-Log protocol is an implementation of the DBPK protocol where the function 6 corresponds to the identity function, i.e. b'i 6(a,)=a,. This leads to the following proposition.
Proposition 4.2 Ifthe DBPKprotocol is performed correctly, then the distance fraud has a negligible probability of success. Respecting the notations of Section 2, we introduce the three following properties.
Property 4.1 Let T : {0, I)*-+ (0, I)* be the filnction such that y = T(x),then thefollowing holds: Given y, it is hard tofind x such that y = T(x). It is hard tofind x # x 'such that T(x)= T(x3. Property 4.2 Let R : (0, I)* x JO,I)*-+ {0, I)* be the filnction such that z = R(x,v),then the following holds Knowing z and R , it is hard toJind (x,v). Itishardtofind(x,v)#(x~v')suchthatR(x,v)=R(x',v'). Property 4.3 Let E be thefunction such that e = E,(x), then thefollowing holds (a) E is an encryption scheme: knowing e and E, it is hard to find x without knowing k; and given e and k, x = D,(e) is eficiently computable.
234
Laurent Bussard and Walid Bagga
(b) Given either k[il or e[i]for all i E {O, ..., N-l), it is hard to find x. (c) It is eSficient to compute z = Q(x,v)Ji.om the commitments on the bits of k and e. The second security requirement for distance-bounding proof of knowledge protocols consists in preventing terrorist frauds. This requirement can already be achieved in the DBPK general scheme according to the following proposition.
Proposition 4.3 If Property 4.1, Property 4.2, and Property 4.3 are respected and if the DBPKprotocol is performed correctly, then the terrorist fraud has a negligible probability of success. Prooj A successful execution of the Proof of Knowledge stage proves that the entity knowing the private key corresponding to the public key y have performed the Bit Commitments stage. Assume that the latter has been performed using k and e. Then, the probability for an intruder to perform the Distance-Bounding stage successfully using (k', e') #(k,e) is equal to
This shows that without knowing (k,e), i.e. without knowing x = Dk(e),the probability of success of a terrorist fraud is negligible. The DBPK-Log consists of the same building blocks than those of the DBPK protocol. Moreover, the three following statements hold (1) The function I- : x 4 gx respects Property 4.1 thanks to the intractability of the discrete logarithm problem. (2) The function R : (x,v) + gx . hv respects Property 4.2 thanks to the intractability of the representation problem. (3) The one-time pad Ek(x)= x-k mod p-1 respects Property 4.3 (see Section 4.2). The properties listed above lead to the following.
Proposition 4.4 If the DBPK-Log protocol is performed correctly, then the terroristfraud has a negligible probability of success. Recall that the prevention of terrorist frauds makes the prevention of mafia frauds straightforward.
4.2
Encryption of the Private Key
Since some bits of the key k are revealed, it is straightforward that a onetime key is necessary. To be compliant with Property 4.3, we propose a
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
235
dedicated one-time pad: e = Ek(x)= x-k mod p- 1 where k E (0, ..., 2"-l} is randomly chosen before each encryption. The parameter N is such that N = mtm', where m is the number of bits of the private key x and m' is a systernspecific security parameter. The prime number p is a strong prime, i.e. p = 2qtl where q is an enough large prime. This scheme is compliant with the following: Property 4.3.a: with this encryption scheme, revealing e still ensures perfect secrecy of x: P,,,,(X = xl E = e) = P, (X = x) = 2-Nfor all x,e Property 4.3.b: in the following, we show that the knowledge of either Hi] or e[i]for all i E {O, ...,N-l), allows to retrieve information on x with probability less than 2-2m'.We basically study the impact of the security parameter m' on the probability of revealing information on x. Knowing b such that b = x-b', information on x can be statistically obtained when a large enough number n of close to the samples can be collected to have a sample mean
7,
mean p i.e. I -pi < p - I . The Central Limit Theorem states that the sum of a large number of independent random variables has a distribution that is approximately normal. Let Y,,Y,,..., Y, be a sequence of independent and identically distributed random variables with mean p and variance $ and
= (1 /
n ) z n ): 1=1
then,
That is
Since the following holds
then, the probability of having a sample mean - close to the mean is
The mean is ,LL=x+~~-' and the variance is d,where o= (2N)2/12. Hence, ( 2
"-'&)10 = (6&)
/ 2 "+'"'
>> 1 . In other words,
We study the number of s a q l e s necessary to get information on x:
Lawent Bussard and Walid Bagga
Here no is the number of sample necessary when m' = 0, i.e. when the parameters x, k, and e are of equal length. In the worst case, nois equal to 1 and the number of samples necessary to get information on x is 24'n'. Note that the security parameter mo ensures a probability of successful attack less than 2-4m'at the expense of m' additional challenge-response bit exchanges. For instance, for m = 1024 bits and m' = 50 bits, the probability of retrieving information about x is less than 2-200at the expense of around 5% of additional challengeresponse bit exchanges. Property 4.3.c: it is possible to deduce a representation of z depending on x from commitments on bits of k and e (Section 3): =
n:;
(ck,l
. ce,;I*' = gr. hv mod p
CONCLUSION AND FURTHER WORK In this paper, we addressed the problem of terrorist frauds in application scenarios where cryptographic authentication requires the physical proximity of the prover. Our solution consists in distance-bounding proof of knowledge protocols that extend Brands and Chaum's distance-bounding protocols [4]. We first presented a general scheme that shows the main building blocks of such protocols. We then presented a possible implementation of such protocols and analyzed its security properties. Even though we have not reached perfect secrecy, our solution remains secure in the statistical zeroknowledge security model. The general scheme presented in this paper (DBPK) could be used with any public key scheme T i f adequate commitment scheme commit, encryption method E, and representation function Q exist. We proposed a solution relying on a public key scheme based on the discrete logarithm problem, bit commitment based on discrete logarithm, group addition onetime pad, and representation problem: DBPK-Log = DBPK[a : y = gal. This scheme could directly be used with ElGamal's and Schnorr's identification schemes that both rely on the discrete logarithm problem. The integration of distance-bounding with Fiat-Shamir identification scheme [9] is not straightforward. The public key x is chosen in Z n where n = pq and the public key is m mod n. It is necessary to define D B P a a : y = a2]. Using the commitment scheme presented in this paper, the following proof
Distance-Bounding Proof of Knowledge to Avoid Real-Time Attacks
237
of knowledge is required: PK[a,P : z = ga.hp A y = a2].In other words, the parameter g has to be a generator of a cyclic group of order n. We are also studying whether such a scheme can be used in a privacy preserving way. DBPK could be integrated in a group signature scheme2 e.g. '1 ; the initial one proposed in [7] would be: DBPK[a : ? = PK[P : = g"(P ) ] .This way, the verifier can verify that he is in front of a member of some group. However the verifier does not get any information on the identity of this group member. In this case, the encryption has to be done modulo n. A further step would be the integration of distance-bounding protocols in unlinkable and/or pseudonymous credentials schemes such as Idemix [6]. An alternative way to address terrorist frauds would be by combining trusted hardware with any protocol preventing mafia frauds [ 5 ] . In other words, a tamper-resistant hardware trusted by the verifier has to be used by the prover to execute the protocol. However, our approach is more general and easier to deploy since it neither relies on tamper-resistant hardware nor requires device certification process.
g'"
?g
-
REFERENCES A. Alkassar and C. Stuble. Towards secure iff preventing mafia fraud attacks. In Proceedings ofMLCOM 2002, volume 2, pages 1139-1 144, October 2002. Ross Anderson. Security Engineering; A Guide to Building Dependable distributed Systems. John Wiley and Sons, 2001. S. Bengio, G. Brassard, Y. Desmedt, C. Goutier, and J.J. Quisquater. Secure implementation of identification systems. Journal of Cryptology, 4(3):175-183, 1991. S. Brands and D. Chaum. Distance-bounding protocols (extended abstract). In Proceedings of EUROCRYPT 93, volume 765 of LNCS, pages 23-27. Springer-Verlag, May 1993. L. Bussard and Y. Roudier. Embedding distance-bounding protocols within intuitive interactions. In Proceedings of Conference on Security in Pervasive Computing (SPC12003),LNCS. Springer, 2003. J. Camenisch and A. Lysyanskaya. An efficient system for non-transferable anonymous credentials with optional anonymity revocation. Lecture Notes in Computer Science, 2045,2001. J. L. Camenisch and M. A. Stadler. Efficient group signature schemes for large groups. In Advances in Cryptology - CRYPT0 '97 Proceedings, volume 1294 of LNCS, pages 41 W 2 4 . Springer-Verlag, 1997.
238
Lazwent Bussard and Walid Bagga
Yvo Desmedt. Major security problems with the 'unforgeable' (Feige)-FiatShamir proofs of identity and how to overcome them. In Proceedings of SecuriCom '88, 1988. [9] A. Fiat and A. Shamir. How to prove yourself: Practical solutions to identification and signature problems. In Advances in Cryptolom-Crypto '86, pages 186-194, New York, 1987. Springer-Verlag. [lo] L.E. Holmquist, F. Mattern, B. Schiele, P. Alahuhta, M. Beigl, and H-W. Gellersen. Smart-its friends: A technique for users to easily establish connections between smart artefacts. In Proceedings of UbiComp 2001, 2001. [l 11 Yih-Chun Hu, A. Perrig, and D.B. Johnson. Packet leashes: a defense against wormhole attacks in wireless networks. In Proceedings of ZNFOCOM2003. Twenty-Second Annual Joint Conference of the IEEE Computer and Communications Societies, volume 3, pages 1976-1 986, March 2003. [I21 J.Pieprzyk, T.Hardjono, and J.Seberry. Fundamentals ofComputer Security. Springer, 2003. [13] T. Kindberg, K. Zhang, and N. Shankar. Context authentication using constrained channels. In Proceedings of the IEEE Worhhop on Mobile Computing Systems and Applications (WMCSA), pages 14-2 1, June 2002. [14] Alfred J. Menezes, Scott A. Vanstone, and Paul C. Van Oorschot. Handbook of Applied Cryptography. CRC Press, Inc., 1996. [15] N. Sastry, U. Shankar, and D. Wagner. Secure verification of location claims. In Proceedings of the 2003 ACM workshop on Wireless security, 2003. [I61 Frank Stajano and Ross J. Anderson. The resurrecting duckling: Security issues for adhoc wireless networks. In Security Protocols Workshop, pages 172-1 94,1999. [I71 B. Waters and E. Felten. Proving the location of tamper-resistant devices. Technical report. [8]
AN ADAPTIVE POLLING SCHEME FOR IEEE 802.11 WIRELESS LAN
Kyung-jun Kim, Hyun-sook Kim, Sang-don Lee, Ki-jun Han Department of Computer Engineering, Kyungpook National University, Sun-hyuk Dong, Pukgu, Daegu 702-701, Korea
Abstract:
The point coordination function of IEEE 802.1 1 is defined to support time bounded traffic in wireless LANs. However, current WLAN standard does not consider the traffic characteristics such as time bound traffic, null poll, and priority. In the case of time bounded traffic, PCF must evolve to support degrees of priority. In this paper, we proposed an adaptive polling scheme to increase the performance of wireless LANs. Moreover, we focused to a polling schedule to serve voice traffic. The simulation results show that the proposed scheme is more efficient than using only standards.
Key words:
WLAN, IEEE 802.1 1, Polling, PCF, Real-time
1.
INTRODUCTION
The dramatic increasing of wireless devices has recently generated a lot of interest in wireless networks that support multimedia services, such as streaming video and audio that has critical quality of service requirements such latency, jitter and bandwidth [6]. IEEE802.11 WLAN standard protocol supports two kinds of access methods: distributed coordination function and PCF [I]. The DCF is designed for asynchronous data transmission by using CSMAICA (carrier sense multiple access with collision avoidance) and must be implemented in all stations. On the other hand, the PCF is a polling-based scheme which is mainly intended for transmission of real-time traffic. This access method is optional and is based on polling controlled by a PC (point coordinator). Currently, the polling mechanism for IEEE 802.: 1 PCF mode is based on
240
Kyung-jun Kim, Hyun-sook Kim, Sung-don Lee, Ki-jzin Hun
the round robin principle which polls every station in sequence regardless of whether it has packets to transmit or not. Real-time applications are characterized by QoS parameters such as delay, jitter, etc [a]. These applications generally have higher priority than non-real time traffic and hence they are allocated a significant portion of the bandwidth. In our knowledge, since the round robin polling scheme does not consider traffic characteristics in each station, the PCF suffers from performance degradation such as delay since empty poll which a happen when the AP polls to stations in silence state [2, 31. However, current WLAN standard does not consider the traffic characteristics such as time bound traffic, null poll, and priority. In the case of time bounded traffic, PCF must evolve into support priority and to reduce packet drop due to buffer overflow, traffic to the bottleneck node must be controlled. This can be achieved by decrease of the number of polling. In this paper, we proposed dynamically adaptive polling scheme that reducing the unnecessary polling overhead for service real-time data in IEEE 802.1 1 WLAN efficiently. Thus, our scheme is to increase the bandwidth effectively without losing fairness at the MAC layer in wireless local area networks. The remainder of this paper is organized as follows. In Section 2, we briefly describe the related works. In section 3 presents an adaptive polling scheme. In section 4, we evaluate the performance of the proposed scheme deriving the packet discard ratio and maxitnum number of real-time stations handled by PCF. Finally, section 5 concluded in this paper.
RELATED WORKS This section briefly summarizes the some of the features of the 802.11 WLAN sub-layer with the emphasis on the PCF mode of operation. CFPR hterval
b
Contenbon Free Penod
. . . . ......
NAV
--. .--
--n
DX = Fmmes sent by Point Coordinator
Ux = F m r w sent by Polkd Stations
Figure 2. Example of PCF frame transfer
An Adaptive Polling Scheme for IEEE 802.1I Wireless LAN
24 1
A typical medium access sequence during PCF is shown in Fig. 1. A station being polled is allowed to transmit a data frame. In case of an unsuccessfid transmission, the station retransmits the frame after defer or during the next contention period. A PC [I] polls the stations in a roundrobin fashion. A polled station always responds to the received a poll. If there is no pending transmission, the intended station responds to a null frame without payload. This frame is called empty poll. In the PCF mechanism, prior to all stations polling, if the CFP-Max Duration terminates, next polling sequence resumed at a station not called station. If transmission failed, the station retransmits the frame after delay or during the next contention period. If contention traffic from the previous repetition interval carries over into the current interval, the CFP-Max Duration may be shortened. Also, if a station lasts longer than the remaining contention periods, the PC has to defer the start of its real time traffic transmission until the medium becomes free for a PIFS. This is because of bandwidth of shared medium. Therefore, recently. bandwidth has been a major design goal for wireless LAN. In the last few years, many researchers actively explored advanced bandwidth reuse approaches for wireless LAN. A set of related research issues needs to be addressed before our approach called as adaptive polling scheme which is technically feasible and economically practical. In 12, 3, 41 scheme, in the case of real time traffic, the existence of transmission delay and packet discard by empty poll is not assumed in order to decrease transmission delay. However, our adaptive polling scheme predicts an adaptive (optimal) priority for the current transmission, based on queue sizes in each station. Most of the known wireless MAC protocols are not specifically designed to support multimedia traffic QoS such as transmission delay, which severely impairs the system performance, can be averaged out. Eustathia et al. [2] proposed a scheme called cyclic shift and station removal polling process (CSSR) in which the AP's polling list temporarily removes stations that enter silence state. However, when it leaves silence state, its voice packet may be discarded in the next round because it does not receive a poll in the maximum allowable delay. 0.Sharon et al. [4] proposed an Efficient Polling MAC Scheme in which stations are separated into two groups, active group and idle group, according to whether there are any pending data ready to be sent. a station in active group and a station in the idle group can simultaneously respond to the polling from the PC by using signals of different strengths. In contrast, our polling scheme, each station has a priority and AP multipolls in each station, which is dynamically assigned by the PC based on the queue size of each station.
242
Kyung-jun Kim, Hyun-sook Kim, Sang-don Lee, Ki-jun Hun
3.
AN ADAPTIVE POLLING SCHEME
3.1
Overview
IEEE 802.11 PCF mode has been addressed many issues, very important one of these issues which is empty poll problem, this is happens during polling to stations under the silence state. For example, if any station leaves silence state, voice packet of the idle station may be discarded in the ongoing next round, since excess maximum delay for receiving a poll.
Figure 2. The polling list used for the re-setup
Therefore, an adaptive polling scheme for avoidance null-poll without transmitting delay is an important challenge to serve real-time traffic. When large frames are transmitted in a noisy channel, they accumulate bit errors that triggers retransmissions. These retransmissions consume valuable bandwidth and degrade the efficiency of the entire system. Thus, an adaptive polling scheme achieves two benefits: 1) the priority of a frame is guaranteed; and 2) avoid to waste bandwidth, which increases the throughput of the system. Fig. 2 shows basic operation of adaptive multicast polling list re-setup.
3.2
Management of Polling List
In this section, we propose an adaptive polling scheme in the IEEE 802.11 PCF to reduce polling overhead. It is occur because of managing the polling list based on the amount of packets at each station. A station with many data is expected to having a higher priority. For each intended station, its priority is given depending on an amount of payload, which is dynamically assigned by the PC based on the queue size of each station. The PC received a packet which includes the information of queue size and an
An Adaptive Polling Scheme for IEEE 802.11 Wireless LAN
243
amount of payload of each station. At this time, idle stations without data are assigned the lowest priority level. and then at one time they will be received a multicast poll instead of separated poll. For that reasons, a number of empty poll can be reduced as many as the number of idle stations, since using a multicast poll.
Figure 3. Multi-polling illustration
When an idle station receives the poll frame, it can transmit its packet after a designated constant time. We use silence detection mechanism to avoid empty-poll of the silence terminals. Fig. 3 shows the illustration of the multi-polling. Frequently, any station within silence period will to be less polled. The use of silence detection can increase the number of voice stations supported by the network. The PC transmits sequentially a poll frame to each station based-on polling priority of polling list, and then the PC receives queue length information by a pollfeedback. Using poll-feedback, the PC allows priority to stations based on the queue length. In the Fig.4, we will describe how node determines that its priority given own.
3.3
An Adaptive Multicast Polling Scheme
We now describe an adaptive multicast polling scheme for idle station to avoid empty polling. As discussed above, the main objective of this scheme is to reduce delay depending on an empty poll and packet loss due to buffer overflow, as well as maintain the network bandwidth. Our scheme can be expressed in an example of the management for polling list shown in Fig, 4. The arrow mark with small circle indicates multicast poll and general poll without circle, respectively. In Fig. 4, SA, Sb, S,, and Sd represents its station A, B, C, and D. The rectangular indicate pending packet. The multi column boxes represent polling list. The PHY show the sequence of packet transmission in physical layer.
Kyung-jun Kim, Hyun-sook Kim, Sang-don Lee, Ki-jun Hun
Figure 4. An example of the management for polling list
First, in the nth PCF round, SB and Sc enter silence state following- -packet generation interval and have no more data to send (that is, because of the poll interval is longer than the packet generation interval), then SB and S, are added to the idle station group in the next (n+l)th round which will receive the multi-poll. If the idle station group has no data to send, it still leaves the idle station group. PROCEDURE ii','~>Li.\t!&
(iJ {
for each s t a t m i m currenf round for ( 8 = 0. r < n, ,++)
poU_kt[n+l] station,., elis queue-length s e n p t y poD_mtcnal >packet generatm u~tsn.al
idle k t gmup
polbble STA
Figure 5. Basic operation of multicast polling scheme
An Adaptive Polling Schemefov IEEE 802.11 Wireless LAN
245
In the (n+l)th PCF round, SBleaves the idle station group because it has a packet to be sent when receiving the multi-poll at the same time. Assuming Sdtransmits its packet in the (n+l)th PCF round, the PC gives the highest priority to Sd in the next PCF round since its queue is the longest of all stations. At time (n+2)th, Sb can transmit its packet. In other hand, S, is remained idle station status. In the Fig. 5 shows an algorithm of basic operation of multicast polling scheme.
4.
ANALYSIS AND SIMULATION RESULTS
The system parameters for the simulation environment are listed in TABLE 1 as specified in the IEEE 802.11b standard. To simplify the simulation, the radio link propagation delay is assumed zero with no transmission errors. Fig. 6 shows the simulation model.
Figure 6. Simulation model
We consider onloff model of voice traffic. In the simulation, we assume that a voice packet is generated by exponential distribution [7]. While the previous packet has been transmitted, the older packet is discarded since a new packet is generated. In this model, the talk spurt period over silence period is 1.0 sec and 1.35 sec, respectively. The frame length of real-time traffic is set to 200 bytes considering the overheads of upper layer protocols. Assuming the ratio of PCF duration within a super-frames, r, throughput of an adaptive polling scheme is approximately as follows,
r *Fp(n)+(l-r)*Fd(n)
(1)
Actually r can be dynamically modified by changing priority re-setup, CFPDuration. For any given n, we want to set appropriate CFPDuration to maximize the total throughput, as shown below [3].
Kyung-jtm Kim, Hyun-sook Kim, Sang-don Lee, Ki-jun Hun
, where Fd is generally throughput, this parameter is function of n, denoted as Fd (n) and F, is a fbnction of the total number of associated stations T, the number of current active stations n, and r shown re-try limit. Table 1 System parameters for simulation
Mtanings
Symbol R
I
Value
I
Channel rate
CW,,,,,,
Minimtwi contention
CW,,,,,
Maximtnn contention window
1 T H ~ ~I
TPI~
M
IlMbps 31
indow
1023
1 I
PIFS time CFP repletion interval
30us 30ms
The parameters for the real-time traffic are summarized in TABLE 2. The maximum delay between a station and the point coordinator, Dm, is set by 35ms [6, 71.Namely, real-time packets are discarded if their waiting time exceeds 35ms. The CFP-Max-Duration is set to 28ms considering the maximum size of MPDU.
-.. ..*....-
-6 ' w
n
5
a,
h 2- I
0
I0
20
30
40
50
60
70
SO
Number of stations
Figure 7. Average delay according to number of stations
In Fig. 7, the simulation shows the effects of changing the number of stations versus the average delay. If the number of node increases, the entire average delay increases. The average delay of proposed scheme is shorter
An Adaptive Polling Scheme for IEEE 802.11 Wireless LAN
247
than the original IEEE 802.1 1 scheme because the proposed scheme can reduce the amount of the empty polls.
-
..-n-..EEE 802.11 PCF
Mumcast Pdiing
X
0
I0
20
30
50
40
hO
70
80
Number of sbtions
Figure 8. Discard ratio according to number of stations
In Fig. 8, we see that the performance of the proposed scheme for the packet discard ratio. Reflecting the end-to-end delay bound of real-time traffic, remaining time to service deadline between a station and the point coordinator is considered which is instead of end-to-end delay between two communicating stations. The discard ratio for real-time traffic using the proposed scheme stayed low. The maximum delay between a station and the point coordinator is set by 35ms [6].
10
15
20
25
30
CFPR Inte~al(ms)
Figure 9. Maximum number of station according to CFPR interval
In Fig. 9, we see that the maximum number of supported stations, while the CFPR interval is increased. This is due to the reduction of delay and
248
Kyzing-jun Kim, Hyun-sook Kim, Sang-don Lee, Ki-jun Hun
packet discard ratio with our scheme. Fig. 10 shows an increase of throughput of the proposed scheme in the same simulation setting.
. - . X - - . E E E 802.11 PCF
-Multicast
Polling
Number of stations
Figure 10. Throughput according to number of stations
5.
CONCLUSION
To reduce the number of empty poll in IEEE 802.11 PCF mode, this paper proposed a multicast poll scheme. Multicast poll scheme spreads a poll to the silence station group at the same time. Simulation studies revealed that our scheme could improve the average delay and packet discard ratio by preventing serious empty poll.
REFERENCE 1 IEEE: Draft and standard for wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification, IEEE 802.1 1, (May 1999). 2 Eustathia Ziouva and Theodore Antonakopoulos, A dynamically adaptable polling scheme for voice support in IEEE 802.1 1 networks, IEEE Computer Communications, vol. 26, no.2, 129-142, (Feb. 2003). 3 Shou-Shin Lo, Guanling Lee and Wen-Tseun, An Efficient Multipolling Mechanism for IEEE 802.1 1 Wireless LANs, IEEE Trans. on Computers, vol, 52, no. 6, 764-768, ( h e . 2003). 4 Oran Sharon and Eitan Altman, An Efficient Polling MAC for Wireless LANs, IEEE/ACiM Trans. on Networking, vol, 9, no. 4,439-451, (Aug. 2001). 5 Moustafa A. Youssef and Arunchandar Vasan, Specification and Analysis of the DCF and PCF Protocols in the 802.1 1 Standard Using Systems of Communicating Machines, Proc. of the 10th IEEE IIVCP, (Nov. 2002).
An Adaptive Polling Scheme fov IEEE 802.11 Wiveless LAN 6 R. S. Ranasinghe, L.L. H. Andrew and D. Everitt, Impact of polling strategy on capacity of 802.11 based wireless multimedia LANs, IEEE Inter. Con$ on Network (ICON ' 9 9 ) , 96103, (Oct. 1999). 7 Sven Wietholter and Christan Hoene, Design and Verification of an IEEE 802.1 1 EDCF Simulation Model in ns-26, (Nov. 2003). 8 S. Agarwal and S.V.Krishnamurthy, Distributed Power Control in Ad Hoc Wireless Networks, in Proceedings ofIEEE PIMRC '01, vol. 2,59-66, (Oct. 2001).
THE PAIRING PROBLEM WITH USER INTERACTION Thomas Pcyrin EPFL Lousanne, Smtzerlar~d thomas.peynn@grnailcorn
Bluetooth-like applications face the paring problem two devices want to establtsh a relationship between them without any prior private infomlation. Hoepman studied the ephemeral pairing problem by regarding the human operator of the devices as a messenger in an authenticated andlor private low-bandwidth channel between the nodes. Here we study the painng problem with user interaction In which the operator can parttcipate by doing extra (smple) computations.
Keywords:
Authentication, pairing, key exchange
1.
Introduction
A typical problem in wireless networks is that we do not know if two communicating devices are actually talking to each other, The pairing problem consists of securely establishing a private key between two or more specific physical nodes in the network. We assume that no secret information is shared between the nodes before the pairing. Furthermore, we want a high level of security and a minimal human interaction. Pairing between Bluetooth devices is a typical setting. In HoeM. Hoepman studied the ephemeral pairing problem (denoted (pKE): given a low bandwidth authentic and/or private communication channel between two nodes (callecl Alice and Bob), and a high bandwidth broadcast channel, can we establish a high-entropy shared secret session key without relying on any a priori shared secret information? The low bandwidth channel can be a (passive) human user who can read a PIN code on one de-
252
Thomas Peyrin and Serge Vaudenay
vice and write it on the other in a secure way. However there are many cases where this model is not sufficient: first, the standard Bluetooth pairing in which the user generates the PIN code; second, cases where the devices have no input keyboard or no output screen; third, when confidentiality (for instance) is guaranteed from the user to one device but not the other; etc. In this paper, we extend the model by introducing the user as a real participant who can further do simple con~putations.We call it the user-aided key exchange (UAKE) problem. Gehrmann and Nyberg gave in GNOl two schemes. They also created a new scheme in GN04 using a MAC function and Jakobsson provided a variant of this scheme in JakOl. Those schemes are adapted to cases where one device has no input keyboard or no output screen. The pairing problem is highly related LO the authenticated key exchange problem (AKE): two users want to establish an authenticated high-entropy private key from scratch. Bellovin and Merritt BM92 gave a class of protocols called EKE (Encrypted Key Exchange) that solves the AKE problem using the assumption that the two peers already share a low-entropy password. EKE is basically an encrypted Diffie-Hellman DH76 key exchange. Jaspan Jas96 analyzed the Diffie-Hellman parameters in order to avoid partition attacks against EKE (in the case where the password is not ephemeral). Then Boyko et al. BMPOO specified a slightly different version of Diffie-Hellman based EKE called PAK (Password Authenticated Key exchange). MacKenzie Mac02 provided proofs in the Bellare-Rogaway model BR94. (A survey on authenticated key establishment protocols is available in BM03.) Note that in this paper, "EKE protocol" denotes independently the EKE or PAK protocol.
2. 2.1
The pairing problem models The pairing problems
In the pairing problem, two nodes in a (wireless ad-hoc) network, that do not yet share any secret, want to establish a secure association. They may be able to exchange small amounts of information reliably andlor in a private way by being attended by a human operator. The ephemeral key exchange ((pKE) problem considers the human operator as a simple messenger between the nodes. In this paper we consider the user-aided key exchange (UAKE) problem in which the operator really participates. The nodes can communicate through the insecure channel and the user can securely exchange small amounts of information with the nodes and perform simple operations. Protocols must be such that:
1 both nodes and the user are ensured that the secret is shared with the correct physical node 2 no other node learns any part of the shared secret
The Pairing Problem with User Interaction 3 a user needs lo perform only simple and inhlitive steps For the third requirement, we allow the following operations: pick a random string, compare two strings, copy a string. XOR two strings. Avoiding the (quite complicated) XOR will be addressed in Section 4.1. We further limit user channels to a small bandwidth. The second requirement will be made clear by formaIizing the security model. Once achieved, the first requirement is satisfied by standard key confirmation techniques. Note that we do not consider denial of services attacks. By directly introducing the user in the problem, we can consider many different situations that can be encountered in practice, For example, we can easily describe the Bluetooth pairing in many different scenarios such as devices with no output screen or no input keyboard, pairing in a hostile environment when anyone can look over the user's shoulder, etc.
2.2
The communicatiori model
Two nodes Alice and Bob are connected through a high bandwidth channel network. The adversary Eve has full control over this channel. Both nodes however share with the user two communication channels (one in each direction) which can have specific security properties: 1 confidentiality: the sender is guaranteed that the messages she sends can not be read by anyone but the right receiver (Eve can not read it).
2 integrity: the receiver is guaranteed that the message he receives was actually sent as is (Eve can not modify it). 3 authentication: the receiver is guaranteed that the message he receives was actually sent by the right sender (Eve can not modify or insert a message in the channel but can delay or replay a message). (Note that our definition of authentication implicitly assumes integrity.) These properties may hold in both directions, or only in one direction. In this paper, we will not consider the integrity property except in our final discussion in Section 4.1 to simplify the protocols. Note that lack of integrity protection in confidential channels means that it could be possible for Eve to replace a confidential z message by a message z&, 6 with a 6 of her choice. (This is typically the case when the confidentid channel is implemented by a stream cipher, e.g. in Bluetooth.) We further assume independence between the channels in the sense that it is impossible for an adversary e.g. to take a message from a secure channel and to insert it into another. We thus have 4 unidirectional channels that can have one of four attributes: AC (authenticated and confidential channel), A (authenticated channel), C (confidential channel) and 0 (no security property). Those channels represent all
Thomas Peyrin and Serge Vaudenay
254
the interactions with the user. For example, a screen on a device represents a channel of type A from the device to the user who is watching the screen, a device holder typing a code on the device's keyboard in a private way represents a channel of type AC from the user to the device. Moreover, we can consider channels with an extremely low bandwidth (typically one bit) if we use a single light, or a single Boolean button for low cost devices.
2.3
The security model
We use the adversary model of Bellare et al. BPROO. Each participant p may engage in the protocol many times in a concurrent way. For each new protocol run where p is asked to play a role, a unique instance xb is created. Eve has the entire control of the network and about who is running a new step of a protocol run, In a UAKE protocol with participants p, q, and r playing the role of Alice, Bob, and User respectively, we create new instances x',, xi, and x5 with input (p, q, r). x; and should terminate with a key. (The (pKE protocol is similar: r is simply hidden.) The attack is formalized by giving access to oracles for the instances of the network to the adversary: H
H
~xecute(n',,ni,n:): execute a complete protocol run with x i , $.This query models passive attacks.
xi, and
Cormpt(p,x): get all internal information about p and force its secret data (if any) to become x. Reveal(7cb): reveal the key generated by $,to the adversary. Send($ m): send a message m to the instance .nb and run a new step of the protocol. ~est($): this query can be called only once. A bit b is flipped at random a random key (if b = 0) or the key from K> (if b = 1) is output.
Eve makes a Test query and tries to correctly guess the bit b. The attack is successful if p,q, r are not corrupted and if ~ e s t ( z b )or ~ e s t ( x i )led to the right guess for b. Thus we define the advantage of Eve attacking the protocol by AdvE = 2Pr[correct] - 1. Note that we can not send a ~est(x;) query if a ~ e v e a l ( x i )or ~ e v e a l ( z i query ) has already been sent, otherwise finding the value of the bit b would be trivial. We do not consider long term passwords as in regular EKE schemes but rather ephemeral ones. So oracles Reveal($,) and Cormpt(p,x) are not relevant in our context.
The Pairing Problem with User Interaction
3. 3.1
Key exchange with user interaction The ephemeral pairing problem
In the original (pKE problem, we have 24 = 16 different possibIe configurations (2 channels and 4 possiblc security propertics for each channel). We can represent each of those configurations by a 2 x 2 Boolean matrix: each row corresponds to a security property (A and C), and each column corresponds to a channel. For more readability, we represent the matrix by M = [A & B] h
where a,b E {O,A,C,AC) are the columns of M. We denote (pKE(M)the ( ~ K E problem with the configuration represented by the matrix M. If a secure protocol can be found for the (pKE(M)problem, we say that (pKE(M)is possible. Otherwise, we say that it is impossible. First of all, we can see that the (pKE problem is symmetric: (pKE(M)is equivalent to cpKE(sym(M)) where sym(M) is the M matrix with the columns inverted. Furthermore, if a (pKE(M1)problem represented by the configuration matrix MI is possible, we can solve the problem with additional security properties by using the same protocol. We denote M1 5 M2 for corresponding configuration matrices M2.
FACT 1 Let MI and M2 be two (pKEproblemconfiguration matrices. IfMl M2, any protocol which solves qKE(Mlf solves cpKE(M2)as well.
<
FACT2 Let M be a cpKE probiem conJiguration matrix. (pKE(M)i~ possible if and only if (pKE(sym(M))is possible. C + B) is impossible.
THEOREM 3 (H0~0.5)(pKE(A
A
Hoepman provided protocols for all minimal possible configurations. We can see that two types of protocols are used: we can try to make Alice and Bob share a low-entropy password and compute the EKE protocol with that password (see Figure 1 and Figure 2). The two devices can also try to run a DiffieHellman key exchange with commitment and authenticate with the low bandwidth channel (see Figure 3).
THEOREM 4 ( H 0 ~ 0 4 )(pKE(A5 B) and (pKE(A
+ B) are possible by usC
C
ing the protocol from Figures I and 2 respectively. The advantage of an adversary which is limited to q orac1e.s queries is at most the best advantage of an adversary to the EKE protocol with the same parameter q.
THEOREM 5 ( H o ~ 0 4 )We consider a group G of order at least 22s in which the decisional Difie-Hellman problem is hard. We consider$ve hash functions hl : G + G, h2 : G -t (0, I)', h3,h4,hs : G + {0,1)0 such that h l ( X ) and h2(X) are independent .for X EU G, h2 is balanced, and h3, h4, and h5 are
Thomas Peyrin and Serge Vaudenay
256
1
(independent)painvise independent random hash function qKE(A B) is A possible by using the protocol from Figure 3. The advantage of an adversary which i s limited to q oracle queries is O(1 - e-q.2-') 0 ( 2 - S ) .
+
Alice p ~ c kp E {O, 1)' send p on AC run E K E ( p )
mn i K E i p )
Alice
3.2
~
Bob
The user-aided key exchange problem
In the UAKE problem we have 44 = 256 different possible configurations (4 channels and 4 different states for each channel). We can represent each of those configurations by a 2 x 4 matrix as in the (PKE problem. For more readability, we represent the matrix by M
=
[A
+ U fd B] where a,b.c,d E u
b
c
{O,A,C,AC) correspond to the columns. We denote UAKE(M) the UAKE problem with the configuration represented by the matrix M. The UAKE problem is symmetric: UAKE(M) is the same problem as UAKE(sym(M)) where sym(M) is the M matrix with some columns inverted so that the role of Alice and Bob is exchanged.
FACT 6 Let M I and M2 be two UAKE problem configuration matrices. If M I 5 Ma any pmtocol solving UAKE(M1)solves UAKE(M2)as well.
FACT 7 Lef M be a UAKEproblem configuration matrix. UAKE(M)is possible if and only i f UAKE (sym(M)) is possible.
We consider two participants Alice and Bob of UAKE(A & U BB) protocol. b c By simulating the interaction between Alice and User by a participant C. We obtain a protocol for pKE(C $ B). We deduce:
FACT8 Let a, b,c, d E (0,A, C,AC). I f UAKE(A (pKE(A $ BB) and pKE(A b
> U + B ) is possible then d
b
c
+ B) are also possible. d
Considering a messenger U who forwards messages, we obtain:
FACT9 Let a , b E {O,A,C,AC). I f pKE(A
U
$ B ) is alro po,ssible.
2b B) is possible then UAKE(A &b
Thomas Peyrin and Serge Vaudenay
258
UAKE(A
2b U $ B) is possible if
d &h B) and (pKE(A + B) are possible. c
Channels with securily
THEOREM 10 Let a, b, c,d and only ifqKE(A
E {O,A,C,AC).
AC
AC
property 0 can be removed, except for (A + U -- B) which is impossible. B) is impossible. In that conP r o o ~Let us prove that UAKE(A 5 U figuration, Alice and Bob can not receive anything from any secure channel.
By removing any interaction with U , we obtain a qKE(A
4B) protocol which 0
contradicts Theorem 3 and Fact 1. Other impossible cases follow from Fact 8. d 2b U + B) is possible for all con~binationsof A C (pKE limit cases: (pKE(A + B), (pKE(A + B), (pKE(A 5 B) and * ( A A C
Let us now show that UAKE(A
c
B). By using synlmetries, we restrict to the following limit cases:
.
w
C
C
A
~ ( A A~C U A~ C D )1, c( A +: U ~ B ) A, ( A A$ ~ I ~ B ) .
~
Type2: (A 'C U 5 3 ) .(A
c + U Z B ) , (A $ U C
C
B).
Fact 9 addresses limit cases of type 1, Theorem 11 and 12 below provide a solution for limit cases of type 2 and 3 respectively. User
Ahce P
Bob P
p ~ c kp E {O,l)'
EWP)
THEOREM 11 UAKE(A 'C U 5 B), UAKE(A
E K W
C
U
5 B) and UAKE(A + C C
AC
U t B) are possible by using the protoco1.s from Figures 4, 5 and 6 respectively. The advantage of an adve~saiywhich is limited to q oracles queries is at most the best advantage of an adversary to the EKE protocol with the same parameter q plus 2-'.
Proofi The Figure 4 case is trivial: we assume we can set up a password in a secure way prior to EKE. For the cases of Figures 5 and 6, we note that if the
259
The Pairing ProbIem with User Interaction Al~ce
-.
--
User
-
Bob
paiE {o, I)' compute y EKE@)
Fzgure 5.
UAKE(A
+U 5 B) C
C
User
Ahce
Bob
pick r E {0,1}'
~ k ( b i l...-~.+
Fagure 7.
Authentication step in Figure 3 for UAKE(A
receive ;B,PB and if thenabort
;# ia
+A U +B ) 4
IC
C
adversary impersonates User to Alice, since she has no clue about (Bob's) p, Alice will receive an incorrect p with probability 1 - 2-' and EKE will fail. 0
THEOREM 12 Wth the same hypotheses as in Theorem 5, UAKE(A B), UAKE(A
4A U 5 B), UAKE(A 1'U A
B), and UAKE(A
0
+U A
A
U
IC, T-
C
*?4 8)
are possible by using the sub-protocolsfrom Figures 7,8, 9, and I 0 respectively in the protocol of Figure 3. The advantage of an adversary which is limited to q oracle queries is O(q.2') f O ( T S ) .Thejrst part ofthe protocol on Figure 7firnher assumes integrity in the U -+ B channel.
is provided in Section 4.5. Proof (sketch): In Figure 8 (resp. Figure 9), if the adversary impersonates Bob to Alice (resp. Alice to Bob), the random z will never be released, so the protocol cannot succeed but with a probability of 2-'. Figure 10 is similar. In Figure 7 second part, the adversary has no clue about h2(gY) and z until User discloses z. So, if she impersonates Bob to Alicc, she can not predict which h2(@)Alice will obtain. Consistency check with the commitment phase in Hoepman's protocol will thus reject with a probability of 1 - 2-'(Note that this works because h2(gY) is unknown prior to the protocol).O
4. 4.1
Discussions Removing the XORs
We can see that the user has to compute the XOR of two values in protocols from Figures 5 and 6. Those cases have a common particularity: we have a
confidential non-authenticated channel between the user and Alice or Bob. In pairing situations those cases may not be relevant: such a channel would e.g. mean for example that the user types some digits on one device in a private way but the device is not sure that the typed digits actually come from the user! Nevertheless, those XORs can be removed by assuming integrity in addition to confidentiality. (Virtual confidential channels achieving this can typically be implemented by using encryption with strong security properties, e.g. INDCCA2. Using less secure encryption, e.g. CBC encryption requires extra care.) In that case we replace the XORs by the concatenation.
4.2
User operations and bandwidth
One of the crucial points of our protocols are the ease of use for the user, we can thus analy~ethe number of operations computed by the user on the devices. In Figure 11 is shown the user operations according to h e different protocols. According to the previous section, we can remove the XORs; in our table that would mean adding two copied values for each XOR.
4.3
Applications
A typical application of the UAKE problem would be the Bluetooth authentication scheme. The standard Bluetooth pairing assumes the same configuration as the protocol shown on Figure 4: the user types a password on both devices in a private and authenticate way. But according to our analysis of the UAKE
Thomas Peyrin and Serge Vaudenay
262
Fzgure 11.
User operahons in UAKE protocols (in blts)
problem, we can consider many other cases. For exanlple, the user can read a password on device Alice and copy it on the device Bob. Moreover, we can imagme as explained on Figure 9, that the device Bob has only a private and aulhenticate screen but no keyboard and that the user can read and type data on device Alice in an authenticated way but not in a private way. Another application could be the establishment of a secure SSL or SSH A
session without certificates. In the A f U A
+ B case, the user could indeed be A
A
two human operators talking (in an authenticated way) over the telephone, i.e.
+ A
A
A
aA UA UB B scenario. A Note that problems arise if we do not consider mutual belief in the key as shown by Lowe in Low96. The UAKE protocols should similarly be followed by an acknowledgment protocol.
4.4
Manufacturer aided key exchange
We can consider that a password p~ has been written in the non-volatile memory of one device by the manufacturer, for example for a low-cost device without any keyboard. That would mean a fourth node M in our pairing scheme representing the manufacturer. AC channels from M to Bob and to User can be considered. Note that those channels can only be used once in the first setup. That new assumption would change protocols shown on Figures 4,5 and 6: we
263
The Pai~ingProblem with User Interaction C
AC
AC
use now p~ for the EKE protocol. This works in a A c 71 c- M --+ B setting. Note that obviously this scheme leads to weaker versions of our protocols since the passworcl used for each instance remains always the same. We can also easily adapt the qKE(A pairing problem in a A
U
=+ U A A
A +B
A + B ) protocol in Figure 3 to solve the A
A
or A f. U
A +-
A
B configuration with a prior A
'AC M % B setup. We can even restrict one of the two A $ U channels to A
a single bit.
We now consider the protocol on Figure 12 as a replacement for the authentication phase in the protocol of Figure 3 using GF(2') arithnletics. In the first part of the protocol, we consider an optimal adversary who tries to make Bob accept a P of his choice for X - ha(g'). (This follows a commitment phase in Hoepman's protocol, so an attack which makes Bob accept a random value is thwarted by the consistency check when opening the commitment.) Note that the right value of X is unknown to thc adversary prior to the protocol. Without loss of generality, the adversary replaces ( u ,v ) by (u', v') = f ( u ,v),the returned (u' ,6)by (14'' ,v") = g (u' ,d ),X by 0, and w = d v'p by wJ hx (w) for some chosen functions f,g, and hx. Let Sw be the set of all ( u ,v) such that g(ur,v') = ( u ,v ) for (u', v') = J ( u , v), and z i t + v'p = w. Note that #Sw 1 2'. The attack is successful if and only if (X, u ,v ) is such that there exists w such that u vX = hx (to) and ( u ,V ) E S,,. Hence the probability of success p is
+
-
+
+
Given w, let now ni be the number of X's such that ( ( u ,v ) E S,;N VX = h x ( w ) ) has cardinality i. We can view the ( u ,v) pairs as straight lines. Given a set of i straight lines such that u -t vX = hx (w) for one fixed X and w, we have i(i - 1)/2 pairs of straight lines intersecting on the same point. If we sum all pairs over all X's, we obtain an overall number of intersecting pairs of at most #Sw x ( # S , - 1)/2. Hence
We have
-*i
C # { ( u , v ) E S,;u X
+vX = hx (w)}= C i.ni i= 1
264
Thomas Peyvin and Serge Vaudenay
with the constraint &n, 5 2'. By linear programming results we obtain that E S,;U+VX
L#{(U,V) X
= hx(iv)} 5
o(2~12)
<
hence p 0 (2-f/2). This big 0 is thus a new term to add in Theorem 12 for our protocol &tho& the integrity assumption. Alice
We have extended Hoepman's ephemeral pairing problem by introducing the User Aided Key Exchange problem. We studied the minimal assumptions and provided pairing protocols in all cases.
Acknowledgment. This work was supported in part by the National Competence Center in Research on Mobile Information and Communication Systems (NCCR-MICS), a center supported by the Swiss National Science Foundation under grant number 5005-67322.
The Pairing Problem with User Interaction References
Steven M. Bellovin and Michael Menitt, Encrypted key exchange :Password-based protocols secure againsr dictionnary attacks, E E E symposium on Research In Secur~tyand Pnvacy, IEEE Computer Society Press, 1992, pp. 72-84. Colin Boyd and Anish Mathuria, Protocols for authentication and key establishment, Infomation Security and Cryptography, Springer-Verlag, 2003. Victor Boyko, Phillip MacKenzie, and Sarvar Patel, Provably secure password-authenticated key exchange using Difjie-HeUman,Advances In Cryptology (Eurocrypt'OO), Lecture notes in computer science, vol. 1807, Springer-Verlag, 2000, pp. 156-171. Mihir Bellare, David Pointcheval, and Phillip Rogaway, Authenticated key exchange secure against dictionary attacks, Advances in Cryptology (Eurocrypt'OO), Lecture notes in computer science, vol. 1807, Springer-Verlag, 2000, pp. 139-155. Mihir Bellare and Phillip Rogaway, Entity authentrcation and key dirtribution, Advdnce? in Cryptology (Crypto'93), Lecture notes in computer science, vol. 773, Springer-Verlag, 1994, p. 232. Whitfield Diffie and Martin E. Hellman, New directions in cryptography, IEEE Transactions on Infonnation Theory IT-22(@(1976), 644-654, Christian G e h a n n and Kaisa Nyberg, Enhancements to Bluetooth baseband secunr)., Proceedings of Nordsec 2001,2001, Copenhagen, Denmark. , Security in personal area networks, Security for Mobillty ('OM), 191-230, IEE, London. Jaap-Henk Hoepman, The ephenieralparring problem, Elghth International Conference on FInancial Cryptography, Lecture notes in computer science, vol. 3 110, Springer-Verlag,2004, Key West, FL,USA, pp. 212-226. , Ephemeral pairing on anonymous networks, To appear in the Proceedings of Second IEEE International Workshop on Pervasive Computing and Communication Security, Lecture notes in computer science, Springer-Verlag, 2005. Markus Jakobsson, Method and apparatus for immunizing againsr ofline dictionary attacks, U.S. Patent Appljcation 601283,996. Filed on 16th April 2001,1001. Barry Jaspan, Dual-workfuctor encrypted key exchange :Efjicrentlypreventingpassword charning and dictionnary attacks, 6th USENIX Security Symposium, San Jose, California, 1996, pp. 4S50. Gavin Lowe, Some nav attacks upon security protocols, 9th JEEE Computer Security Fondations Workshop, IEEE Computer Society Press, 1996, pp. 162-169. Philip MacKenzie, The PAK suite :Protocols forpassword-authenticated key exchange, Tech. Report 2002-46, DIMACS, 2002.
NETWORK SMART CARD A New Paradigm of Secure Online Transactions Asad Ali, Karen Lu, and Michael Montgomery Axalto, Smart Cards Research, 8311 North FM 620 Road, Austin, TX 78726, USA
Abstract:
This paper describes the functionality and practical uses of a network smart card: a smart card that can connect to the Internet as a secure and autonomous peer. The network smart card does not require any special middleware on the host device. It uses standard networking protocols PPP and TCPIIP to achieve network connectivity. Network security is accomplished by an optimized SSLITLS stack on the smart card. The combination of TCPIIP and SSLITLS stacks on the smart card enables the smart card to establish a secure end-to-end network connection with any standard (unmodified) client or server on the Internet. This opens the door to seamless, secure and novel applications of smart cards in the most ubiquitous network: the Internet. Some of these applications that use the network smart card in confidential online transactions are explained.
INTRODUCTION Smart cards have been in use for more than two decades. However, their use has so far been on the fringes of mainstream computing. Smart card advantages such as security, portability, wallet-compatible form factor, and tamper resistance make them increasingly useful in many applications. Smart cards are used as agents in off-line transactions, as tokens for controlling access to physical resources, as SIM units in GSM phones, and as secure tokens for storing confidential and personal information. Current applications of smart cards, though useful in their own right, are hindered by the mismatch between smart card communication standards and the communication standards for mainstream computing and networking. When
Asad Ali, Karen Lu, and Michael Montgomery
268
smart cards are connected to computers, host applications cannot communicate with them using standard mainstream network interfaces. Specific hardware and software in the form of smart card reader device drivers and middleware applications are needed to access the smart card services. The network smart card solves this mismatch of communication standards by implementing standard mainstream networking protocols on the smart card. It supports PPP [I] and TCPIIP [2,3,4,5] as the underlying communication layer. It also supports the SSLITLS [6,7,8] protocol that adds application level network security. Using this combination of TCPIIP and SSLITLS protocols, which are ubiquitous in the Internet, a variety of mainstream application frameworks can be supported by the smart card. Currently, a working prototype of the network smart card supports a Telnet server and a secure web server using HTTPS. To the host device or a remote application, the smart card appears as another PC on the network. This seamless integration of network smart card with existing PC applications could pave the way for an unprecedented growth in the use of smart cards by enhancing the security of online web transactions.
MOTIVATION Smart cards are extremely secure hardware tokens with a programmable microprocessor chip. Although they are useful in a variety of security critical applications, there are two main impediments to widespread acceptance of smart cards for use in online web transactions. The first is the necessity to install middleware on the host PC where the smart card is physically connected. Without this middleware, smart card services cannot be accessed. The second is the lack of end-to-end security between the smart card and any remote application: for example, an online merchant's web server. A key motivation for developing the network smart card was to address both these drawbacks, and thereby achieve the vision of widespread smart card acceptance. The root cause of both these drawbacks is the communication protocol mismatch between smart card and the host PC. Current smart cards use APDUs and smart card-specific IS0 78 16 standards for communication. Host PCs, on the other hand use standard mainstream network standards like PPP and TCPIIP. Middleware software is installed on the host PC to act as a bridge between these two sets of diverse protocols. This software is not only cumbersome to develop, install and maintain across multiple host platforms,
Network Smart Card
269
it also breaks the end-to-end security model when smart cards are accessed from remote applications. Figure 1 illustrates this break in security as a conventional smart card is accessed from a remote PC.
>/!?-3
TCP / IP + secur~ty Remote PC
IS0 7816
Host PC I deuce
Smart card
Figure I . Network connectivity of conventional smart cards.
The remote PC cannot directly communicate with the smart card. It first connects to the host PC using standard mainstream network and security protocols. The host decrypts the information and then passes it to the smart card using IS0 7816 protocols. Due to this protocol conversion, the host PC needs to be trusted. However, PCs are known for their vulnerability to hardware as well as software attacks. As such, even if the I S 0 7816 communication is encrypted, the host PC becomes a weak link in the end-toend security between the remote PC and the smart card.
Remote PC
Host PC I device
Network smart card
Figure 2. Network connectivity of the Network Smart Card.
Figure 2 describes the same scenario of accessing a smart card from a remote PC using the network smart card. Since the network smart card supports the same mainstream communication protocols as the remote PC, there is no need for any protocol conversion at the Host PC. There is a direct secure connection using the SSLITLS protocol from the remote PC to the network smart card. The host PC merely acts as a pass-through router and need not be trusted. The OS on the host PC provides services that allow it to be configured as a pass-through router. This eliminates the need for installing any smart card specific middleware. The use of network smart card
270
Asad Ali, Kaven Lu, and Michael Montgomery
in an end-to-end secure connection with a remote client creates a much more secure model of conducting online transactions than is possible with current approaches that either do not use smart cards, or use them as auxiliary tokens connected to the host PC.
3.
RELATED WORK
For years, efforts have been underway to connect smart cards to the Internet. Early pioneers [9,10,11,12] have made major contributions to enhancing the connectivity paradigm of smart cards. However, they did not make the smart card a truly independent node on the Internet. These developments relied on some form of host middleware or software service to be installed on the host machine. In addition, they did not support any mainstream network security protocol on the smart card. The network smart card addresses these shortcomings in the earlier efforts by implementing a standard network protocol stack on the smart card. With this approach the smart card can establish an end-to-end secure connection with standard unmodified remote applications. In addition, the use of smart card does not require any smart card specific middleware to be installed on the host PC. The freedom to use the smart card on any PC without requiring smart card specific software on the PC is one of the major contributions of the network smart card.
ARCHITECTURE & DEPLOYMENT The architecture of the network smart card is based on two key principles: the use of standard TCPIIP and SSLITLS protocol stacks inside the smart card; and utilizing standard interfaces and drivers built into most operating systems, thereby eliminating the need to install smart card specific software. This allows the network smart card to seamlessly integrate in the existing mainstream computing infrastructure. The deployment of smart cards is no longer encumbered by the middleware. Figure 3 shows some of the ways a network smart card can be connected to the network where unmodified clients can seamlessly access it. The card can be used in the standard credit card size form factor when connected to a host computer or a smart card hub. It can also be used in the SIM form factor when placed in GSM phones and wireless PDAs. Figure 4 shows details of the network smart card protocol stack. The network smart card is connected via the "direct connection to a host
Network Smart Card
27 1
computer" deployment option. It contains a complete network stack consisting of PPP, TCPIIP, and SSLITLS, and various network applications.
Host computer
Remote computers
Figure 3. Deployment options for network smart card in various form factors.
The host computer can be any platform that is configured to permit network access from a serial or USB port. This includes most workstation, desktop, and laptop platforms including Windows, Mac, Linux, and Unix platforms, as well as some mobile devices. In the case of Windows platforms, configuration is a simple task requiring a few simple steps via the New Connection Wizard (a standard utility that comes with all Windows operating systems). This establishes a direct connection to another computer. The host is unaware that the computer being connected is a smart card: it treats the smart card as any other computer requesting a connection. Specific details of the network smart card architecture and various
I
Unmodified remote computer with standard network applications
Secure Network Applications
Reader Connector Unmodified host computer
Network smart card
Figure 4. Network protocol stack and connection through a host computer.
I
Asad Ali, Karen Lu, and Michael Montgomery connectivity models are described in a separate paper [13]. The host computer functions simply as a router to connect the smart card to the network, where other remote computers may access it. Since the smart card has its own IP address, any remote client or server anywhere on the network can securely communicate directly with this card using standard network applications. As far as the remote computer can tell, the smart card is just another standard computer on the Internet. This kind of seamless network interaction with unmodified remote applications is not possible with conventional smart cards. In figure 4, the solid line boxes (e.g. TCPIIP, SSLITLS) represent components and services that have already been implemented in the network smart card, whereas the dotted line boxes (e.g. SOAP) are application frameworks that can easily be added using the underlyng communication layers.
5.
APPLICATION FRAMEWORKS
A variety of standard application frameworks can be supported on top of the underlying implementation of TCPIIP in the network smart card. Applications running on the smart card do not communicate directly with the TCPIIP layer. Instead they go through a socket interface layer. Since this is how mainstream applications on a PC connect to the network, applications on the smart card can seamlessly integrate with other remote applications on the network. Standard unmodified client applications can connect to the smart card services as if they were connecting to another computer on the network. The utility of this seamless integration is further augmented by the SSLITLS layer, which adds application level network security to all remote connections to the smart card. SSL and TLS are the de-facto standards for securing communication between web servers and web clients (the browsers). These protocols have been in use for several years and no critical flaws have been discovered in them. Adding these protocols to the smart card substantially increases the security of network access to smart cards. The SSLITLS library developed for the network smart card provides a simple API that can be used by on-card applications to establish secure end-to-end network connections with any remote unmodified client on the Internet. This provides authentication, confidentiality, and data integrity for all network communication. Figure 5 shows some of the application frameworks that can be supported on top of socket layer and the SSLITLS layer. Solid boxes represent components that have already been implemented and demonstrated. Other boxes with dotted outlines can easily be added.
Network Smart Card
Web Sewer
r E q m Socket Interface Layer TCP 1 IP Figure 5. Application frameworks that can be supported in network smart card.
The current version of the network smart card supports a Telnet server and a secure web server that can serve static as well as dynamic HTML content. The static HTML content is served by reading the requested file from the smart card file system and returning its contents. The Dynamic content is supported by a more elaborate mechanism. The web server invokes the requested application, or library through a CGI interface and then redirects the resulting output to the browser. This allows the web sever to generate web pages on the fly, and implement various forms of access control for data stored on the smart card. No smart card specific application is needed to access the network smart card services. The user can simply open a standard Internet browser (IE, Netscape, Mozilla Firefox, etc.) and connect to the smart card in a secure manner over an HTTPS connection. From an administrator's point of view, programming the card can be as simple as creating a new HTML file and uploading it to the smart card using the same browser. The network smart card also supports a Linux-like shell interface that can be accessed either through Telnet or through a secure HTTPS connection. This provides a very powerful way of interacting with the card, both as a user and as an administrator. New application frameworks such as .NET, SOAP, and Web Services can be easily added.
6.
SECURE ONLINE TRANSACTIONS
Because the network smart card supports mainstream networking protocols, it can be seamlessly integrated into any network application. One example of such applications is the web-based online transaction. PC users have become accustomed to conducting online transactions as part of their
274
Asad Ali, Karen Lu, and Michael Montgomery
normal daily activity. However, a closer look at these transactions reveals that they are not as secure as people believe them to be. There are three players in any online transaction: the client application, e.g. a standard Internet browser running on local PC; the remote web server representing the merchant we do business with; and finally, the Internet infrastructure over which our data is carried back and forth between the client application and the remote web server. Let us analyze these three players. The Internet infrastructure is considered open and any data traversing it can be viewed by anyone who cares to examine the packets. However, security protocols such as SSLITLS that are used in online transactions encrypt the data in a way that data integrity and confidentiality are not compromised while the data traverses the Internet. The remote web server is under the control of the trusted merchant with which we are conducting our online transactions. We trust the merchant, otherwise, why would we conduct business with them? This leaves us with our local PC on which we run the client application, the Internet browser. PCs are extremely vulnerable to both hardware and software attacks, and therefore form the weak link in any online transaction. Any information that is entered through them can be compromised even before the SSLITLS layer encrypts it. Similarly, an attacker can capture any data that may have originated on a different device but simply flows through the PC in the clear.
Trusted merchant Remote web sewer
Figure 6. Online transactions: a) without a smart card, b) with a conventional smart card.
Figure 6-a shows this typical scenario of conducting online transactions without any smart card support. Using an Internet browser, B2, the user establishes a secure SSL connection with a trusted merchant. Any confidential data entered by the user is secure while in transit, but is open to attack while it resides on the Local PC. This is because information can be
Network Smart Card
275
captured before the SSL layer can encrypt it. Current use of smart cards to augment the security of PCs is described in Figure 6-b. It is a step in the right direction but does not completely solve the security problem. The confidential data now resides on the smart card where it is secure. However, in the process of being SSL-encrypted for transmission to the trusted merchant, the data has to flow through the PC in the clear. Since PCs are open to attack, so is any information that flows through them in the clear. Due to their vulnerabilities, PCs are the weak links in any online transaction. The use of the network smart card in an online transaction solves the problem introduced by the vulnerable nature of PCs. Instead of passing information through the PC, the network smart card establishes a secure connection directly with the remote server of the merchant. All confidential information is passed from smart card directly to the merchant. The PC is used only as an initial means of connecting the smart card to the Internet. Once that connection is established, the PC merely acts as a router that physically passes encrypted information back and forth between the network smart card and the remote merchant. Logically, the smart card has a direct connection with the remote merchant that completely bypasses the PC. Figure 7 shows this use of network smart card in conducting a truly secure online transaction. The local PC, the trusted merchant, and the network smart card are three independent nodes on the Internet that are capable of establishing secure connections using SSLITLS. Any two nodes can communicate with each other without disclosing the contents of the communication to the third node, or any other party that happens to be listening. The fact that network smart card is one of these nodes, is a critical distinction that elevates the security of online transactions to a level not
card: ! Internet node
Figure 7. Network smart card in a secure on-line transaction.
276
Asad Ali, Karen Lu, and Michael Montgomevy
possible with conventional smart cards. Various interactions outlined in Figure 7 are described below. All the bidirectional arrows in this figure represent secure HTTPS connections using the SSLITLS protocol. The steps listed here represent a simplified set of interactions when using network smart card in an online transaction. More details are covered in a separate paper 1141 that talks about the use of network smart card in preventing online identity theft. The sequence of steps in chronological order is as follows:
1. The user opens a web browser on the local PC. This instance of the web browser is referred to as B1. From B1 the user connects to the secure web server running on the network smart card and authenticates himself through some form of card holder verification: a PIN, biornetrics, etc. This connection is established over a secure HTTPS link. Once authenticated, he is presented with a list of trusted merchants. The user picks a trusted merchant and asks the network smart card to establish a secure connection with this service provider. 2. The user clicks on a link in B1 to start a new browser. This instance of the web browser is referred to as B2. 3. When browser B2 is launched, it automatically connects to the remote web server of the trusted merchant that was selected by user in step 1. Since the browser was launched from B 1, the network smart card address can be passed to the trusted merchant. Alternatively, the smart card can initiate a connection to the trusted merchant and pass its address, as well as other login credentials to it.
4. Regardless of the method used for mutual discovery, the trusted merchant web server and the network smart card can now communicate directly without involving any third party - including the local PC. This direct SSL connection is represented by link 4 shown in figure 7. Once the mutual discovery and authentication of the network smart card and the trusted merchant is complete, the user can use browser B2 to interact with the web server of the trusted merchant. During this interaction, all confidential data interchange can be deferred to the direct connection between the trusted merchant and the network smart card. Such confidential data can be sent from the network smart card directly to the trusted merchant. The data is as safe during transit as it was when stored on the smart card. Some scenarios of secure online transactions that have been prototyped with the network smart card are listed in the following sections. These
Network Smart Card
277
applications have been demonstrated at various smart card conferences [15,16,17]. See Figure 8 for a sample screen-shot from these demonstrations.
Figure 8. Screen-shot of secure web server running on network smart card.
Figure 8 shows the list of secure services (trusted merchants) that is presented to the user once he has logged on to the network smart card. All information displayed in this browser window is coming directly from the web server running on the network smart card using an HTTPS connection. As evident from the URL, the network smart card has been assigned its own IP address: in this case 172.27.97.130. Standard unmodified Internet client applications can communicate with the smart card using this IP address. The
Asad Ali, Karen Lu, and Michael Monfgomery
278
Mozilla Firefox browser shown in Figure 8 corresponds to the browser B1 in the scenario outlined in Figure 7.
6.1
Online Stock Trade
In this scenario, the trusted merchant is a stock brokerage house where the user wants to sell some stock from his portfolio. As shown in figure 7, the user uses browser B2 from the local PC and selects the stock that need to be sold. As the final submit button is pressed, the brokerage house will not automatically complete the transaction. Instead it would use link 4 to contact the network smart card directly. This is done for two reasons: Firstly, the remote merchant wants to make sure that the network smart card, which represents the user in this online transaction, is still connected to the network. Secondly, it allows the user to manually approve any information that is disclosed by the network smart card. This secure close-back loop is a critical step that is missing in all current on-line transaction scenarios that use conventional smart cards, or are conducted without any smart card support.
6.2
Online Shopping
In the online shopping scenario the network smart card provides a secure way of transferring one's credit card information without having to type it manually. Such confidential details like credit card number and expiration date are stored on the network smart card. Storing this information on a smart card provides a greater level of security than storing it either on the remote merchant server, or on the local PC. Once the user is ready to pay for online shopping, the user instructs the network smart card to send the credit card details to the selected merchant. This secure transfer of credit card information between the smart card and the merchant using an end-to-end SSL connection solves one of the most critical issues with online shopping today. The path of confidential data transfer is shown as link 4 in figure 7.
6.3
Online Auction
The online auction scenario is quite similar to the online stock trade scenario. Instead of trading stocks, the user participates in an online auction by placing bids. However, before the merchant accepts any bids, the user's identity is confirmed by a secure direct connection between the merchant web server and the network smart card. In conventional online auctions, attackers can impersonate the user by compromising the user's username and password. The use of network smart card eliminates such fraudulent bids.
Network Smart Card
CONCLUSION The network smart card presented in this paper enables smart cards to participate as autonomous nodes on the Internet with no host or remote application changes required. Smart cards may, finally, be accommodated within the existing mainstream computing infrastructure. This innovative technology combines the best aspects of two worlds of computing: the world of PCs, and the world of smart cards. In the world of PCs we have ubiquitous infrastructure access and very strong network security protocols for remote access. However, a PC is a very weak hardware device that is vulnerable to security attacks. Smart cards on the other hand are very secure hardware tokens, but suffer from lack of seamless access to the mainstream communication networks. The network smart card combines the hardware security of smart cards with the ubiquitous access and network security of PC. The result is a new paradigm of portability, enhanced security, and tamper resistance. We foresee this new paradigm triggering an unprecedented growth in the deployment of smart card applications for the Intemet and other network environments. The network smart card can bring a level of security to online transactions that has so far not been possible.
REFERENCES 1. 2. 3. 4. 5. 6. 7.
8. 9. 10. 11. 12. 13.
Simpson, W. "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994. Postel, J. "Internet Protocol," RFC 791, September 198 1. Postel, J. "Transmission Control Protocol," RFC 793, September 198 1. Socolofsky, T. "A TCPIIP Tutorial," RFC 1180, January 1991. Almquist, P. "Type of Service in the Internet Protocol Suite," RFC 1349, July 1992. Freier, Alan O., et al. "The SSL Protocol, Version 3.0," Intemet Draft, November 18, 1996. Also see the following Netscape URL: http:llwp.netscape.com~engIssl31. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0," IETF Network Working Group. RFC 2246. See http:llwww.ietf.orglrfc/rfc2246.txt. Elgamal, et al. August 12, 1997, "Secure socket layer application program apparatus and method." United States Patent 5,657,390. Rees, J., and Honeyman, P. "Webcard: a Java Card web server," Proc. IFIP CARDIS 2000, Bristol, UK, September 2000. Urien, P. "Internet Card, a smart card as a true Internet node," Computer Communication, volume 23, issue 17, October 2000. Guthery, S., Kehr, R., and Posegga, J. "How to turn a GSM SIM into a web server," Proc. IFIP CARDIS 2000, Bristol, UK, September 2000. Muller, C. and Deschamps, E. "Smart cards as first-class network citizens," 4th Gemplus Developer Conference, Singapore, November 2002. Montgomery, M., Ali, A,, and Lu, K. "Implementation of a Standard Network Stack in a Smart Card", CARDIS 2004, Toulouse, France, August 2004.
280
Asad Ali, Karen Lu, and Michael Montgomevy 14. Lu, K., and Ali, A. "Prevent Online Identity Theft - Using Network Smart Cards for Secure Online Transactions," 7th Information Security Conference, Palo Alto, CA, September 2004. 15. Montgomery, M., et al., "Web Identity Card", Axalto booth, CARTES & IT Security 2003, Paris, France, November 2003. 16. Ah, A,, et a]., "Web Identity Card", Axalto booth, CTST 2004, 14th Annual Conference and Exhibition, Washington D.C., April 2004. 17. Montgomery, M., et a]., "Web Identity C a r d , Axalto booth, CARTES & IT Security 2004, Paris, France, November 2004.
PROTECTION AGAINST SPAM USING PRECHALLENGES Rodrigo
oma an', Jianying zhoul, and Javier ~
o ~ e z ~
'institutefor 2
Infocomm Research, 21 Heng Mui Keng Terrace, Singapore 119613; ~T.S. . Ingenieria Informatics, University of Malaga, 29071, Malaga, Spain.
Abstract:
Spam turns out to be an increasingly serious problem to email users. A number of anti-spam schemes have been proposed and deployed, but the problem has yet been well addressed. One of those schemes is challenge-response, in which a challenge is imposed on an email sender. However, such a scheme introduces new problems for the users, e.g., delay of service and denial of service attacks. In this paper, we introduce apre-challenge scheme that avoids those problems. It assumes each user has a challenge that is defined by the user himselflherself and associated with hislher email address, in such a way that an email sender can simultaneously retrieve a new receiver's email address and challenge before sending an email in the first contact. Some new mechanisms are employed to reach a good balance between security against spam and convenience to email users.
Keywords:
electronic mail; anti-spam; internet security.
INTRODUCTION Email is one of the most valuable tools for Internet users, with which people at anywhere can communicate instantaneously regardless of the distance. However, this tool can be used for bad purposes too, and there is no doubt that the worst use of email is spam. Spam, or unsolicited commercial email, can be defined as advertising messages (mostly for fraudulent products) neither expected nor desired by the intended receivers. Since it is very easy to flood users' mailboxes with little investment, spam is a big threat to email systems, resulting in the loss of time and money to email users.
282
Rodrigo Roman, Jianying Zhou, and Javier Lopez
A lot of research in the area of anti-spamming has been done in the past years, trying to seek effective solutions to the spam problem. One of those solutions is challenge-response. When a sender sends an email, helshe is first given a challenge from the receiver that must be solved before the email reaches the receiver's mailbox. However, such a scheme introduces new problems, for example, delay of sewice (when a sender waits for arrival of a challenge from a receiver), and denial of sewice (when challenges are redirected to a victim's address that is spoofed by spammers as the sender). Our Contribution. In this paper, we propose a pre-challenge scheme, which is based on challenge-response mechanism, preserving its benefits while avoiding its drawbacks. It assumes that each user has a particular challenge associated with hw'her email address, in such a way that an email sender can simultaneously retrieve a new receiver's email address and challenge before sending an email in the first contact. Our scheme enables management of mailing list and error messages. O w scheme is easy to be integrated into existing email systems as it is a standalone solution, without changing the other party's software and configuration. The rest of the paper is organized as follows. In section 2, we summarize the existing solutions against spam and analyze their limitations and/or problems. After that, we present a new solution in section 3, and further discuss it in section 4. Finally, we conclude the paper in section 5.
PREVIOUS WORK The original SMTP protocol ['I was introduced in 1982, with only minor modifications 12' in the past 20 years. The main problem in SMTP is the lack of authentication. When an email is received, it is not possible to know whether the source of the email is who claims to be. This is precisely the flaw that spammers make use of. However, as the SMTP protocol has been standardized and widely deployed, most of the research focuses on avoiding spam while maintaining the actual SMTP protocol and email infrastructure in order to ensure compatibility. This implies that anti-spamming solutions must be based on the operation with email headers and contents or on specific implementations at the application level. One of the headers that can provide information regarding an eventual spam of the incoming email is the "Received" headers, which give information about the client MTA. There are some projects [31 that try to identify misconfigured email MTAs or major sources of spam. However, it does not work effectively against individual spammers, and innocent client MTAs might be blocked.
Protection Against Spam Using Pre-Challenges
283
Another header that can be used against spamming is the receiver's address, with policy or password-like extensions. In policy-based systems [41, policies are encoded inside the address and an email is discarded at its destination if the policy is not fulfilled. In password-based systems [5-71,the receiver's address is extended with a sequence of characters that act like a password, which can be obtained with a proof of computational task [lo]. These solutions work well in some scenarios (e.g., using mail addresses in computer-based systems like web forums). However, as the email addresses created in such schemes are very hard to remember, they may cause problems when used by humans. There are several works dealing with email content analysis based on artificial intelligence (AI) and statistical techniques [8991. They try to distinguish whether an email comes from a legitimate user or from a spammer by assigning a "spam score" to any incoming message. This approach may lead to false positives, and spammers may try to bypass the classifier algorithms. Other implementation approaches against spam include micropayment, challenge-response, and obfuscation schemes. Micropayment schemes [lo-131 are applied to email systems in order to prevent spammers sending millions of emails. They require the user or client MTA to compute a moderately hard function in order to gain access to the server MTA. As a result, a spammer will not be able to send a large number of emails to a certain server MTA. Such an approach is difficult to be applied to those client devices with very weak computing capability (e.g., mobile phones). In challenge-response schemes "42'51,whenever an email from an unknown user is received, a challenge is sent back to that user. The solution to that challenge can be simple (e.g., just reply), complicated (e.g., solve a CAPTCHA [''I), or time consuming. Only when the correct response is received, the emails from that user are allowed to enter into the receiver's mailbox. These schemes do not work when a human user is not involved in sending emails (e.g., in the case of mailing lists). Moreover, these schemes may introduce new problems such as delay of service and denial of service. In the obfuscation scheme, email addresses are displayed in an obfuscated format (e.g., John HIPHEN Smith AT yahoo DOT com), from which senders can reconstruct the real email addresses. It does not require any software from the user side or from the server side. However, the problem with this scheme is the constraints that the human users face when constructing the obfuscated addresses. As the combinations are limited, it allows AI-based harvest programs to easily retrieve real addresses. Moreover, once the email is captured by the spammer, there is no protection against spam (unless other solutions are utilized).
Rodrigo Roman, Jianying Zhou, and Javiev Lopez
284
3.
A PRE-CHALLENGE SCHEME
3.1
Overview
As stated, our pre-challenge scheme is based on challenge-response mechanism in the sense that both of them impose a challenge that must be solved by a potential sender. However, in the pre-challenge scheme, the sender retrieves the receiver's email address together with hislher challenge simultaneously (see Fig. 1). Once the challenge is solved, the answer will be included inside the email. Challenge = 3 + 4 Tel: 999-12345
Figure I . Basics of the pre-challenge scheme
When a mail from an unknown sender arrives, the receiver's system tests whether that mail contains an answer to the challenge. If the test turns out positive, the sender is white-listed. That means future mails from this sender will get into the receiver's mailbox without being checked again. The goal of our scheme is to check whether there is really a human behind a sender's computer. The reason is that spammers use automatic programs to send their propaganda, and they feed these systems with email addresses obtained by searching web sites and mail servers. However, it is a bit hard for these programs to retrieve a challenge that matches an email address and even harder to answer each of these challenges. Therefore, whenever a spam arrives to destination, it will be automatically discarded if no correct answer to the challenge is attached. In comparison with a challenge-response scheme, our pre-challenge scheme preserves its benefits while avoiding its drawbacks, as we explain in the following: In a challenge-response scheme, there is a delay in obtaining the receiver's challenge. On the contrary, in our pre-challenge scheme,
Protection Against Spurn Using Pre-Challenges
285
because the receiver's challenge is available in advance, the sender can directly solve the challenge and send the email to the receiver 13. With a challenge-response scheme, if spammers forge a sender's address in their mails, the challenges will be sent to that address, launching a possible DDoS attack [I6'. This attack will not take place in the prechallenge scheme because a receiver need not reply an unknown sender's request for a challenge. A challenge-response scheme can work with mailing lists only if some rules are manually introduced, and it cannot handle mail error messages properly. As we will show in section 4.1 and section 4.4, the prechallenge scheme manages mailing list systems and processes mail error messages without any problem. Another benefit of the pre-challenge scheme is the continuous protection against email harvesting. When a correct email address is retrieved by a spammer, helshe needs to get the solution of the current pre-challenge at the same time to make the address usable, but the user can change the prechallenge at any time (see section 3.2), making the combination <email,solution> useless.
3.2
Challenge Retrieval and Update
A challenge is defined by an individual human user. Each user has one challenge at a time to be used by all incoming emails, and the challenge can be updated at any time at hislher own discretion. The challenge can range from a simple question or mathematical operation to a hard-A1 problem that only a human can solve [I7'. Normally a user's challenge is published next to this user's email address. Since any potential sender must retrieve the email address of the receiver before contacting hirniher, challenge and email address can be accessed at the same time. However, in certain cases, a challenge may not be accessed directly. Instead, a URL may be provided to retrieve the challenge. Since the challenge is not restrained to obfbscate a valid email address, which has a fixed structure (name, domain), the user has more freedom to produce it. When stored inside a website, the challenge can take advantage of its form and content - personal information, the theme, or visual appearance of the website, etc. Challenges may also be retrieved using a majordomo style service '221. TOprevent spammers from using this service as
13
The frequency of challenge update is a security parameter decided by the receiver. based on hislher own experience, to control the risk of replay attacks from spammers.
286
Rodrigo Roman, Jianying Zhou, and Javier Lopez
a collector of valid email addresses, the service must return a false challenge for every non-existent user.
3.3
Data Structures
The pre-challenge scheme requires certain data structures to accomplish its tasks. The two most important structures are the actual challenge (or a URL), and the solution to the challenge. By using these structures, it is possible to advertise the actual challenge and to check whether an incoming mail has solved the challenge. Additionally, the solutions to old challenges must be stored, as discussed later. Other data structures needed by the scheme are the white-list and the reply-list (both used by some challenge-response schemes), and the warninglist, that is a structure specifically created for our new scheme. Each of those structures contains a list of email addresses and, optionally, a timestamp which indicates the time an email can be in the list.
White-List. The white-list contains email addresses in such a way that emails coming from those addresses are accepted without being checked. Some email senders may even be white-listed by a receiver at the set-up phase if they are already known. Those senders are marked in order to send a confirmation when receiving their first message (see section 3.5). This list could be manually modified by a human user. Reply-List. The reply-list contains email addresses of those users to which the local user has sent email to, and has not replied yet. The use of this list is justified because the local user is the one who initiated the communication with those users; hence, there is no need to check any challenge when replies are received. This list will be managed automatically by the local user's system. Warning-List. The warning-list contains email addresses of users that have sent an email containing the answer of an old challenge. The existence of this list is justified because an email message with an old response will cause a reply from the receiver indicating the new challenge. With this list, the local user does not need not send that reply more than once. This list will be reset every time when the challenge is updated, and will be managed automatically by the local user's system.
Protection Against Spam Using Pre-Challenges
3.4
Security Levels
The pre-challenge scheme can be configured to work at two security levels, high security and low security. The main difference between these two levels is how the reply-list is queried. The scheme starts working at the high security level of protection. High security means that all queries in the reply-list are done by looking for a <user, domain> match, and the matched entry will be erased from the replylist, On the other hand, low security means that all queries in the reply-list are done by looking for a <*, domain> match. The reason why the pre-challenge scheme needs these two levels of security is that some email accounts have different addresses for receiving and for sending email. This usually happens with mailing lists, and this issue will be discussed in section 4.1.
3.5
Architecture
Now we explain the design of our pre-challenge scheme. Suppose user B wants to send an email to user A. To simplify the explanation, we assume that user A is using the pre-challenge scheme while user B is not. 1. A's system checks if B's address is listed in the white-list. If this is the case, the email reaches A's mailbox. Additionally, if that mail is the first message A received from B, A sends a confirmation email to B. 2. Otherwise, if B is listed in the reply-list, the email reaches A's mailbox and B is added to the white-list. We should point out that the query to the reply-list is different according to the level of security being applied, as seen in section 3.4. In case of using a high security level, B is erased from the reply-list because A received the reply expected from B. 3. Otherwise, A's system checks whether the challenge of the email has been solved. If it is solved, the mail reaches A's mailbox and B is added to the white-list. Additionally, B receives a confirmation email. 4. Otherwise, if the email has a solution to an old challenge, A's system checks if B is listed in the warning-list 1 4 . If that is the case, the mail is discarded. If it is not listed, B's address is added to the warning-list and B gets a reply containing information about the new challenge.
l4
Note, the warning-listwill be reset whenever the challenge is updated.
288
Rodvigo Roman, Jianying Zhozt, and Javiev Lopez
5. Otherwise, the email is discarded without any reply to B indicating this fact. The problem of accidental discard of a legitimate email will be addressed in section 4.3. It should be noted, however, that discarding the email does not mean the user cannot read it. The scheme can be configured for labeling the message with a "spam score" and placing it in a special fold of the mailbox if the owner of that mailbox desires so.
3.6
Spam Scenarios
When a spammer wants to send hislher advertisements to a final user that operates the pre-challenge scheme, helshe basically faces two scenarios.
Scenario 1. The spammer only retrieves the email address of a target, but not hislher challenge. When the spam is sent to the target, it will be silently discarded because no solution to a (current or old) challenge is included. Scenario 2. The spammer only retrieves the email address of a target, and impersonates as a sender that happens to be in the receiver's white-list, due to the lack of authentication in the email infrastructure. All schemes that use a white-list share this problem, but this is not a serious issue because spammers must find the white-listed senders for all the addresses helshe want to spam. And for millions of addresses to spam, this is unprofitable. It could seem that a spamrner, using little investment (solving one challenge), can send many pieces of spam to a given email address (a replay attack). It could also seem that a group of spammers interchange their solved challenges of the corresponding users in order to lessen each spammer's effort on accessing the victims' mailboxes. However, what spammers want is to send millions of messages. And since the challenges are different for every user and a challenge can be solved only by a human, the task of repeatedly solving or sniffing a new challenge per user, or hiring cheap labor in order to send spam, becomes unprofitable.
4.
FURTHER DISCUSSION
Here we further discuss how our scheme works for users in a mailing list, and whether our scheme can make a challenge easily available to users and make users to be sure on the delivery status of an email. We also discuss how to manage mail error messages.
Protection Against Spurn Using Pre-Challenges
4.1
Mailing Lists
Mailing lists "8~'91 share a common behaviour: upon registration, they send a challenge to the user in order to prove that the user is a real person. As a result, it seems not possible to use challenge-response schemes with mailing lists. Fortunately, there is a solution to this problem in the pre-challenge scheme. Since all mails from the same mailing list come from the same domain, a user can switch to the low security level (see section 3.4) whenever helshe wants to subscribe to a mailing list. At the low security level, all the incoming mails from the mailing list domain (including all the challenges and all the messages from the mailing list) that have a match in the reply-list are accepted into the user's mailbox and their senders are whitelisted. When the user finally receives the first mail of the mailing list, helshe switches to the high security level (see Fig. 2).
Figure 2. Process of subscription to a mailing list
The risk of inserting a spammer inside the user's white-list while the user is at the low security level is very low, because the spammer's email address must have the same domain as the people in the user's reply-list, and because a user normally only subscribes to a few mailing lists in a year. Also, the user can set up the system not for adding the incoming mails to the white-list when running at the low security level, but for adding to a temporary white-list instead. HeIShe will decide later whether to add (manually) them into the final white-list.
4.2
Availability
It is clear that some availability problems exist when the challenge is not published along with the email address. If a sender cannot obtain the
Rodvigo Roman, Jianying Zhou, and Javiev Lopez
290
challenge of a new receiver and solve it, hislher email may not be able to reach the receiver's mailbox. It might be good to provide both the challenge and a URL that points to the challenge for better availability. In case the URL does not work, the challenge (even if outdated) can still be used by an email sender to get in touch with a new receiver. (The receiver will reply with the latest challenge on receiving the answer of an old challenge.) Finally, there is an availability problem that is common for both prechallenge and challenge-response schemes: A challenge easy for a normal user might be impossible to solve for a disabled user. For example, a blind user will find impossible to solve a challenge based on images without help.
4.3
Accessibility
One of the main issues in the pre-challenge scheme is that an incoming email from a new sender without the answer of the receiver's challenge is automatically discarded, and the sender is not notified. This approach avoids the increment of Internet traffic due to the responses to spammers' mails, but also introduces a problem: a normal sender is not sure whether the receiver really got the email. A possible solution is to define a standard prefix in each email address that is enabled with the pre-challenge scheme. In such a way, the sender knows clearly that a challenge should be answered in hislher first email to such a receiver and a notification is expected should the email reach the receiver's mailbox. There is an alternative solution if the pre-challenge scheme is implemented at the MTA level. In this solution, the sender is warned of the invalid answer of challenge using the error reporting mechanism of the SMTP delivery negotiation protocol. This protocol works as follows: 1. The client MTA sends the contents of the email to the server MTA. After that, the server MTA checks if the email must be accepted or rejected by searching the answer to the pre-challenge. 2. If the negotiation fails, the client MTA creates an email that includes the cause of the error and the undelivered email. That email is sent to the original sender, if the client MTA does not manage hisher emails. By using this solution, the final user will receive an error message if helshe sends an email with an invalid answer of a challenge, without increasing the Internet bandwidth in most cases. We have more discussions on managing error messages in section 4.4.
Protection Against Spam Using Pre-Challenges
4.4
Managing Mail Error Messages
During the SMTP delivery negotiation between two MTAs, if an email cannot be delivered to its recipient, the client MTA has to send the original sender an email containing an error message. Errors can range from an invalid recipient to over-quota mailboxes, or (as seen in the previous section) pre-challenge errors. A problem arises when the error message is not created by the MTA of the client that implements the pre-challenge scheme. An example is shown in Fig. 3. In the example, the error happens at MTA lvl 2, thus MTA lvl 1 creates and sends an error message back to the original sender. But MTA is a computer and will not include any answer of a challenge inside the error message. Therefore, it will not reach the client's protected mailbox - a problem of availability.
I
Error in 4) due to "No answer to pre-challenge"
v
-
I
I
Error In 2) due to "Mailbox full"
I
I
2) Send email, ERROR
3) MTA Ivl 1 creates
4) Send error ernail.
MTA lvl 1 hotrnail.com
-
MTA Ivl2 hotmail.com
Figure 3. Problems while dealing with error messages
This problem can be solved based on two premises. First, error messages can be identified with the "messageldelivery-status" header, and have attached the email that caused the problem. Second, all emails have a unique ID issued by the original client MTA, stored in the "Message-ID" header. When an error message arrives, the pre-challenge scheme accepts the email if both address of the recipient and ID of the original message are inside the reply-list. Thus, it is necessary to add the ID of outgoing emails to the reply-list. A spammer may try to bypass this scheme by forging both the unique ID and the recipient of the original message. This requires the spammer to wiretap the communication channel, which is unprofitable for massive spamming.
Rodrigo Roman, Jianying Zhou, and Javier Lopez
292
SUMMARY In this paper, we presented a pre-challenge scheme for spam controlling, based on challenge-response mechanism but avoiding its drawbacks. Our scheme is a standalone solution, since there is no need to install software or change the configuration in the sender's side. Our scheme allows einail senders to have no delay in reaching the receiver's mailbox, and prevents the denial of service attack if the origin of the email is forged. It also manages mailing list messages and error messages properly. Finally, our scheme offers protection against email harvesting. This scheme can be used jointly with other major anti-spam solutions, because the type of protection that the pre-challenge scheme provides is centered in the protection of email against harvesting, thus leaving the door open to other solutions such as content analysis. Moreover, the scheme could also be integrated with authentication solutions like DomainKeys [201 or Identity-Based Encryption [211, hence thwarting attacks like using forged senders to bypass the white-list checlung.
REFERENCES 1. 2. 3. 4.
J. Postel. Simple Mail Transfer Protocol. RFC 821, IETF, August 1982. J. Klensin. Simple Mail Transfer Protocol. RFC 2821, IETF, April 2001. SBL. http://spamhaus.org/. J. Ioannidis. Fighting Spam by Encapsulating Policy in Email Addresses. NDSS'03, February 2003. 5. E. Gabber, M. Jakobsson, Y. Matias, and A. Mayer. Curbing Junk E-Mail via Secure Classification. 1998 Financial Cryptography, pages 198-2 13, February 1998. 6. R. J. Hall. How to Avoid Unwanted Email. Communications of the ACM, 41(3):88-95, March 1998. 7. L. F. Cranor and B. A. LaMacchia. Spam! Communications of the ACM, 41(8):74--83, August 1998. 8. M. Sahami, S. Dumais, D. Heckennan, and E. Horvitz. A Bayesian Approach to Filtering Junk Email. AAAI'98 Workshop on Learning for Text Categorization, July 1998. 9. P. Cunningham, N. Nowlan, S. J. Delany, and M. Haahr. A Case-Based Approach to Spam Filtering that Can Track Concept Drift. ICCBR'03 Workshop on Long-Lived CBR Systems, June 2003. 10.C. Dwork and M. Naor. Pricing via Processing or Combatting Junk Mail. Crypto'92, pages 139-147, August 1992. 11.C. Dwork, A. Goldberg, and M. Naor. On Memory-Bound Functions for Fighting Spam. Crypto103,pages 426-444, August 2003. 12.M. Abadi, A. Birrell, M. Burrows, F. Dabek, and T. Wobber. Bankable Postage for Network Services. 8th Asian Computing Science Conference, December 2003. 13.Microsoft Penny Black Project. http:l/research.microsoft.com/research/sv/PennyBlac~, 14.SparnArrest. http:l/spamarrest.comi. 15.SpamCap. http://www.toyz.orglcgi-bin/wiki.cgi?SpamCap.
Protection Against Spurn Using Pre-Challenges
293
16.5. Mirkovic, J. Martin, and P. Reiher. A Taxonomy of DDoS Attackr and DDoS Defense Mechanisms. Technical Report #020018, Dept. of Computer Science. Univ. of California. 17.L. von Ahn, M. Blum, N. J . Hopper, and J. Langford. CAPTCHA: Using Hard AI Problemsfor Security. Eurocryptt03, pages 294-3 1 1, May 2003. 18.Ezmlm Mailing List. http://www.ezmlm.orgi. 19.Mailman Mailing List. http://www.list.orgl. 20.Yahoo DomainKeys. http:l/antispam.yahoo.comidomainkeys/. 2 1.D. Boneh and M. Franklin. Identip Based Enclyption from the Weil Pairing. Crypto'Ol , pages 213-229, August 2001. 22,Majordomo Mailing List. http://www.greatcircle.comimajordomo/.
AUTOMATICALLY HARDENING WEB APPLICATIONS USING PRECISE TAINTING
Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Greene, Jeff Shirley, David Evans Department of Computer Science, Charlottesville, VA 22904-4740, USAi
University of
Virginia, I5 I
Engineer's
Way,
Abstract:
Most web applications contain security vulnerabilities. The simple and natural ways of creating a web application are prone to SQL injection attacks and cross-site scripting attacks as well as other less common vulnerabilities. In response, many tools have been developed for detecting or mitigating common web application vulnerabilities. Existing techniques either require effort from the site developer or are prone to false positives. This paper presents a fully automated approach to securely hardening web applications. It is based on precisely tracking taintedness of data and checking specifically for dangerous content only in parts of commands and output that came from untrustworthy sources. Unlike previous work in which everything that is derived from tainted input is tainted, our approach precisely tracks taintedness within data values.
Key words:
web security; web vulnerabilities; SQL injection; PHP; cross-site scripting attacks; precise tainting; information flow
1.
INTRODUCTION
Nearly all web applications are security critical, but only a small fraction of deployed web applications can afford a detailed security review. Even when such a review is possible, it is tedious and can overlook subtle security
This work was funded in part by DARPA (SRS FA8750-04-2-0246) and the National Science Foundation (NSF CAREER CCR-0092945, SCI-0426972).
296
Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Greene, ..
vulnerabilities. Serious security vulnerabilities are regularly found in the most prominent commercial web applications including mail', e ~ a g , yahoo3, ~ o t m a i and l ~ Microsoft passport4. Section 2 provides background on common web application vulnerabilities. Several tools have been developed to partially automate aspects of a security review, including static analysis tools that scan code for possible vulnerabilities5 and automated testing tools that test web sites with inputs designed to expose vulnerabilities5". Taint analysis identifies inputs that come from untrustworthy sources (including user input) and tracks all data that is affected by those input values. An error is reported if tainted data is passed as a security-critical parameter, such as the command passed to an exec command. Taint analysis can be done statically or dynamically. Section 3 describes previous work on securing web applications, including taint analysis. For an approach to be effective for the vast majority of web applications, it needs to be fully automated. Many people build websites that accept user input without any understanding of security issues. For example, PHP & MySQL for ~ u v n r n i e s provides ~ inexperienced programmers with the knowledge they need to set up a database-backed web application. Although the book does include some warnings about security (for example, p. 213 warns readers about malicious input and advises them to check correct format, and p. 261 warns about <script> tags in user input), many of the examples in the book that accept user input contain security vulnerabilities (e.g., Listings 11-3 and 12-2 allow SQL injection, and Listing 12-4 allows cross-site scripting). This is typical of most introductory books on web site development. In Section 4 we propose a completely automated mechanism for preventing two important classes of web application security vulnerabilities: command injection (including script and SQL injection) and cross-site scripting (XSS). Our solution involves replacing the standard PHP interpreter with a modified interpreter that precisely tracks taintedness and checks for dangerous content in uses of tainted data. All that is required to benefit from our approach is that the hosting server uses our modified version of PHP. The main contribution of our work is the development of precise tainting in which taint information is maintained at a fine level of granularity and checked in a context-sensitive way. This enables us to design and implement fully-automated defense mechanisms against both command injection attacks, including SQL injection, and cross-site scripting attacks. Next, we describe common web application vulnerabilities. Section 3 reviews prior work on securing web applications. Section 4 describes our design and
Automatically Hardening Web Applications Using Precise Tainting
297
implementation, and explains how we prevent exploits of web application vulnerabilities.
2.
WEB APPLICATION VULNERABILITIES
Figure 1 depicts a typical web application. For clarity, we focus on web applications implemented using PHP, which is currently one of the most popular language for implementing web applications (PHP is used at approximately 1.3M IP addresses, 18M domains, and is installed on 50% of Apache servers9). Most issues and architectural properties are similar for other web application languages. A client sends input to the web server in the form of an HTTP request (step 1 in Figure 1). GET and POST are the most common requests. The request encodes data created by the user in HTTP header fields including file names and parameters included in the requested URI. If the URI is a PHP file, the HTTP server will load the requested file from the file system (step 2) and execute the requested file in the PHP interpreter (step 3). The parameters are visible to the PHP code through predefined global variable arrays (including $-GET and $-POST). The PHP code may use these values to construct commands that are sent to PHP functions such as a SQL query that is sent to the database (steps 4 and 3, or to make calls to PHP-API functions that call system APIS to manipulate system state (steps 6 and 7). The PHP code produces an output web page based on the returned results and returns it to the client (step 8). We assume a client can interact with the web server only by sending HTTP requests to the HTTP server. In particular, the only way an attacker can interact with system resources, including the database and file system, is by constructing appropriate web requests. We divide attacks into two general classes of attacks: injection attacks attempt to construct requests to the web server that corrupt its state or reveal confidential information; output attacks ( e g , cross-site scripting) attempt to send requests to the web server that cause it to generate responses that produce malicious behavior on clients.
F ~ l eSystem
--
0
PHP Interpreter HTTP Sewer
1 1
0
+ Database
Figure 3. Typical web application architecture
298
2.1
Anh Ngzlyen-Tuong, Salvatore Gzlarnieri, Doug Greene, ...
Command injection attacks
In a command injection attack an attacker attempts to access confidential information or corrupt the application state by constructing an input that allows the attacker to inject malicious control logic into the web application. With the system architecture shown in Figure 1, an attack could attempt to inject PHP code that will be executed by the PHP interpreter, SQL commands that will be executed by the database, or native machine code that will be executed by the web server host directly. We consider only the first two cases. Web application vulnerabilities are far more common than vulnerabilities in the underlying server or operating system since there are far more different web applications than there are servers and operating systems, and developers of web applications tend to be far less sophisticated from a security perspective than developers of operating systems and web servers. PHP injection. In a PHP injection attack, the attacker attempts to inject PHP code that will be interpreter by the server. If an attacker can inject arbitrary code, the attacker can do everything PHP can and has effectively complete control over the server. Here is a simple example of a PHP injection in phpGedView, an online viewing system for genealogy informationlo. The attack URL is of the form: http://[target]/[...I /editconfig~gedcom.php?gedcom~config=../. ./../../../../etc/passwd The vulnerable PHP code uses the gedcom-config value as a filename: require($gedcom-config);. The semantics of require is to load the file and either interpret it as PHP code (if the PHP tags are found) or display the content. Thus this code leaks the content of the password file. Abuse of require and its related functions is a commonly reported ~ccurrence""~,despite the fact that, properly configured, PHP is impervious to this basic attack. However, additional defenses are needed for more sophisticated injection attacks such as the recently released Santy worm13 and the phpMyAdmin attacki4. SQL injection. Attacking web applications by injecting SQL commands is a common method of attacking web applications'5"6. We illustrate a simple SQL injection that is representative of actual vulnerabilities. Suppose the following is used to construct an SQL query to authenticate users against a database: $cmd="SELECT user FROM users WHERE user = ' " . $user . "' AND password = ' " . $pwd . " ' "; The value of $user comes from $-POST['user'], a value provided by the client using the login form. A malicious client can enter the value: ' OR 1 = 1 ; --' (-- begins a comment in SQL which continues to the end of the line). The resulting SQL query will be: SELECT user FROM users WHERE user = ' I
Automatically Hardening Web Applications Using Precise Tninting
299
OR 1 = 1 ; -- ' AND password = 'x'. The injected command closes the quote and comments out the AND part of the query. Hence, it will always succeed regardless of the entered password. The main problem here is that the single quote provided by the attacker closes the open quote, and the remainder of the user-provided string is passed to the database as part of the SQL command. This attack would be thwarted by PHP installations that use the default magic quotes option. When enabled, magic quotes automatically sanitize input data by adding a backslash to all strings submitted via web forms or cookies. However, magic quotes do not suffice for attacks that do not use quotes17. One solution to prevent SQL injections is to use prepared statements''. A prepared statement is a query string with placeholders for variables that are subsequently bound to the statement and type-checked. However, this depends on programmers changing development practices and replacing legacy code. Dynamic generation of queries using regular queries will continue to be prevalent for the foreseeable future.
2.2
Output attacks
Output attacks send a request to a web application that causes it to produce an output page designed by the attacker to achieve some malicious goal. The most dangerous lund of output attack is a cross-site scripting attack, in which the web server produces an output page containing script code generated by the attacker. The script code can steal the victim's cookies or capture data the victim unsuspectingly enters into the web site. This is especially effective in phishing attacks in which the attacker sends potential victims emails convincing them victim to visit a URL. The URL may be a trusted domain, but because of a cross-site scripting vulnerability the attacker can construct parameters to the URL that cause the trusted site to create a page containing a form that sends data back to the attacker. For example, the attacker constructs a link like this:
300
Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Gueene, .. .
web depends on scripting languages, so most users are unwilling to disable them. Even security-conscious web developers frequently produce websites that are vulnerable to cross-site scripting attack^'^^^^^^^^. As with SQL injection, ad hoc fixes often fail to solve discovered problems correctly-the initial filters develop to fix the Hotmail vulnerability could be circumvented by using alternate character encodings4. Hence, we focus on fully automated solutions.
RELATED WORK Several approaches have been developed for securing web applications including filtering input and output that appears dangerous, automated testing and diversity defenses. The approaches most similar to our proposed approach involve analyzing information flow. Input and Output Filtering. Scott and Sharp developed a system for providing an application-level firewall to prevent malicious input from reaching vulnerable web serversz3.Their approach required a specification of constraints on different inputs, and compiled those constraints into a checkmg program. This requires a programmer to provide a correct security policy specific to their application, so is ill-suited to protecting typical web developers. Several commercial web application firewalls provide input and output filtering to detect possible attack^^^'^^. However, these tools are prone to both false positives and negatives26. Automated Testing. There are several web application security testing tools designed specifically to find v ~ l n e r a b i l i t i e s ~The ~~~ problem ~ ~ ~ . with these tools is that they have to guess the exploit data in order to expose the vulnerability. For well-known generic classes of vulnerabilities, such as SQL injection, this may be possible. But for novel or complex vulnerabilities, it is unlikely the scanner will guess the right inputs to expose the vulnerability. Diversity Defenses. Instruction-Set Randomization is a form of diversity in which defenders modify the instruction set used to run applications29. Thus, code-injection attacks that rely on knowledge of the original language are detected and thwarted easily. This approach has been advocated for general scripting languages29 and for protection against SQL injection^^^. There are two main problems with ISR: (1) it is effective only against code injection attacks and incomplete by itself (it does not handle cross-site scripting attacks), and (2), the deployment of ISR is not transparent to developers and requires the transformation of application code. Information Flow. All of the web vulnerabilities described in Section 2 stem from insecure information flow: data from untrusted sources is used in a trusted way. The security community has studied information flow
Automatically Hardening Web Applications Using Precise Tainting
301
extensively3'. The earliest work focused on confidentiality, in particular in preventing flows from trusted to untrusted source^'^. In our case, we are primarily concerned with integrity. Biba showed that information flow can also be used to provide integrity by considering flows from untrusted to trusted sources33. Information flow policies can be enforced statically, dynamically or by a combination of static and dynamic techniques. Static taint analysis has been used to detect security vulnerabilities in C programs34,35.Static approaches have the advantage of increased precision, no run-time overhead and the ability to detect and correct errors before deployment. However, they require substantial effort from the programmer. Since we are focused on solutions that will be practically deployed in typical web development scenarios, we focus on dynamic techniques. Huang et. a1 developed WebSSARI, a hybrid approach to securing web applications36.The WebSSARI tool uses a static analysis based on typebased information flow to identify possible vulnerabilities in PHP web applications. Their type-based approach operates at a coarse-grain: any data derived from tainted input is considered fully tainted. WebSSARI can insert calls to sanitization routines that filter potentially dangerous content from tainted values before they are passed to security-critical functions. Because we propose techniques for tracking taintedness at a much finer granularity, our system can be more automated than WebSSARI: all we require is that the server uses our modified interpreter PHP to protect all web applications running on the server.
4.
AUTOMATIC WEB HARDENING
Our design is based on maintaining precise information about what data is tainted through the processing of a request, and checking that user input sent to an external command or output to a web page contains only safe content. Our automated solution prevents a large class of common security vulnerabilities without any direct effort required from web developers. The only change from the standard web architecture in Figure 1 is that we replace the standard PHP interpreter with a modified interpreter that identifies which data comes from untrusted sources and precisely tracks how that data propagates through PHP code interpretation (Section 4.1), checks that parameters to commands do not contain dangerous content derived from user input (Section 4.2), and ensures that generated web pages do not contain scripting code created from untrusted input (Section 4.3).
302
4.1
Anh Ngzyen-Tuong, Salvatore Guamieri, Doug Greene, . ..
Keeping track of precise taint information
We mark an input from untrusted sources including data provided by client requests as tainted. We modified the PHP interpreter's implementation of the string datatype to include tainting information for string values at the granularity of individual characters. We then propagate taint information across function calls, assignments and composition at the granularity of a single character, hence precise tainting. The application of precise tainting enables the prevention of injection attacks and the ability to easily filter output for XSS attacks. If a function uses a tainted variable in a dangerous way, we can reject the call to the function (as is done with SQL queries or PHP system functions) or sanitize the variable values (as is done for preventing cross-site scripting attacks). Web application developers often remember to sanitize inputs from GET and POSTS, but will omit to check other variables that can be manipulated by clients. Our approach ensures that all such external variables, e.g. hidden form variables, coolues and HTTP header information, are marked as tainted. We also keep track of taint information for session variables and database results. 4.1.1
Taint strings
For each PHP string, we track tainting information for individual characters. Consider the following code fragment where part of the string $x comes from a web form and the other from a cookie: $x = "Hello " . $-GET['namel'] . ". I am " . $-COOKIE['name2']; The values of $-GET['namel'] and $-COOKIE['name2'] are fully tainted (we assume they are Alice and Bob). After the concatenation, the values of $x and its taint markings (underlined) are: H e l l o A1 ice. I am Bob. 4.1.2
Functions
We keep track of taint information across function calls, in particular functions that manipulate and return strings. The general algorithm is to mark strings returned from function as tainted if any of the input arguments are tainted. Whenever feasible, we exploit the semantics of functions and keep track of taintedness precisely. For example, consider the substring function in which taint marlungs for the result of the substr call depend on the part of the string they select: substr("precise taint me", 2, 10); /I ecise
a
Automatically Hardening Web Applications Using Precise Tainting 4.1.3
303
Database values and session variables
Databases provide another potential venue for attackers to insert malicious values. We treat strings that are returned from database queries as untrusted and mark them as tainted. While this approach may appear overly restrictive, in the sense that legitimate uses may be prevented, we show in Section 4.3 how precise tainting and our approach to checking for cross-site scripting mitigates this potential problem. Further, if the database is compromised by some other means, the attacker is still unable to use the compromised database to construct a cross-site scripting attack. The stateless nature of HTTP requires developers to keep track of application state across client requests. However, exposing session variables to clients would allow attackers to manipulate applications. Well-designed web applications keep session variables on the server only and use a session id to communicate with clients. We modified PHP to store taint information with session variables.
4.2
Preventing command injection
The tainting information is used to determine whether or not calls to security-critical functions are safe. To prevent command injection attacks, we check that the tainted information passed to a command is safe. The actual checking depends on the command, and is designed to be precise enough to prevent all command injection attacks from succeeding while allowing typical web applications to function normally when they are not under attack.
4.2.1
PHP injection
To prevent PHP injection attacks we disallow calls to potentially dangerous functions if any one of their arguments is tainted. The list of functions checked is similar to those disallowed by Per1 and Ruby's taint mode37~38 and consists of functions that treat input strings as PHP code or manipulate the system state such as system calls, WO functions, and calls that are directly evaluated.
4.2.2
SQL injection
Preventing SQL injections requires taking advantage of precise taint information. Before sending commands to the database, e.g. mysql-query, we run the following algorithm to check for injections:
Anh Nguyen- Tuong, Salvatove Gztavnievi, Doug Greene, . ..
TOKENIZE THE QUERY STRING; PRESERVE TAINT MARKINGS WITH TOKENS. SCAN EACH TOKEN FOR IDENTIFIERS AND OPERATOR SYMBOLS (IGNORE LITERALS, I.E., STRINGS, NUMBERS, BOOLEAN VALUES). DETECT AN INJECTION IF AN OPERATOR SYMBOL IS MARKED AS TAINTED. OPERATOR SYMBOLS ARE ,()[I.;:+ */\%A<>=-!?
@#&I'
DETECT AN INJECTION IF AN IDENTIFIER IS TAINTED AND A KEYWORD. EXAMPLE KEYWORDS INCLUDE UNION, DROP, WHERE, OR, AND. Using the example from Section 2.1 : $cmd="SELECT user FROM users WHERE user = ' " . $user . "' AND password = ' " . $password . " ' "; The resulting query string (with $user set to ' OR 1 = 1 ; -- ') is tainted as follows: SELECT user FROM users WHERE user = ' ' OR 1 = 1 ; -- ' AND password = 'xi. - We detect an injection since OR is both tainted and a keyword.
4.3
Preventing cross-site scripting
Our approach to preventing cross-site scripting relies on checking generated output. Any potentially dangerous content in generated HTML pages must contain only untainted data. We modify the PHP output functions (print, echo, printf and other printing functions) with functions that check for tainted output containing dangerous content. The replacement functions output untainted text normally, but keep track of the state of the output stream as necessary for checking. For a contrived example, consider an application that opens a script and then prints tainted output: print "<script>document.write ($user)"; An attacker can inject JavaScript code by setting the value of $user to a value that closes the parenthesis and executes arbitrary code: " me");alert("yoM. Note that the opening script tag could be divided across multiple print commands. Hence, our modified output functions need to keep track of open and partially open tags in the output. We do not need to parse the output HTML completely (and it would be unadvisable to do so, since many web applications generate ungrammatical HTML).
Checking output instead of input avoids many of the common problems with ad hoc filtering approaches. Since we are looking at the generated output any tricks involving separating attacks into multiple input variables or using character encodings can be handled systematically. Our checking
Automatically Hardening Web Applications Using Precise Tainting
305
involves whitelisting safe content whereas blacklisting attempts to prevent cross-site scripting attacks by identifying known dangerous tags, such as <script> and
