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)

SECURITY AND PRIVACY IN THE AGE OF UBIQUITOUS COMPUTING IFIP - The International Federation for Information Processin...

Author: Ryoichi Sasaki | Sihan Qing | Eiji Okamoto | Hiroshi Yoshiura

91 downloads 1105 Views 9MB Size Report

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

DOWNLOAD PDF

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)

ISBN-10: (HB) 0-387-25658-X ISBN-13: (HB) 978-0387-25658-0 ISBN-10: (eBook) 0-387-25660-1 ISBN-13: (eBook) 978-0387-25660-3 Printed on acid-free paper.

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,


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


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


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


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


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


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


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.


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


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


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?)


D: (RootNymUh [email protected]/cl= DoDeAnonGlobal(T~anscr@t~~.~ D: stoves SigA(Mailu Crimiutal)

C

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


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.


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).


-

-

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.


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


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.


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


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


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


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)


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.


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


[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


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,


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


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.


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.

Figure 5. Qualitative security requirement decision matrix

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.

1

t

Membership

General

Confidential

Secret

-b Min

4

8

11

Security category value (SCV)

Figure 1. Security categories (crisp representations)

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?


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


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

Security level Secret Confidential Internal use

Associated security clearance General manager Level 2 management Level 3 management

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.


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.


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.


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.


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


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


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


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.

Tool Suppovted Management oflnformation Security Culture

77

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.


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


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


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


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


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.

Key words:

federated enterprise; password authentication; dictionary attack; key exchange; public key cryptosystem.

1.

INTRODUCTION

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


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.


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


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.


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


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


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


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


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).


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.


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.


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.

Key words:

Quantum Cryptography; Encrypted Conlmunication; Quantum Entanglement

1.

INTRODUCTION

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:


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

\\

:.

'..

-

Classical channel

; I.......................................;: ...................................................

. !.

5

Bob

:

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


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.

................................................................

'

jb

Alice

i

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


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


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


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


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/


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.

Key words:

TCPA(TCG); TPM; SUP320; SOC; low power; smart card; keys management.

1.

INTRODUCTION

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


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


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.

SUP320 500M bps 2 10Mbps 500M bps 3001s 280001s 1200is 6001s

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).


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.


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.


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.

164

Keisuke Ohmori, Ayako Suzuki, Manabu Ohmuro, . . .

3.

VERIFICATION METHOD AND NETWORK

3.1

Verification method

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.


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


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.


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.


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 .


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


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


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:


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, , = 0, , = 1,, = 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.


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


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.


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


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


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


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


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


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


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


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


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


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


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 > 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, ,++)

dpoll was sent by AP

return STA-POLLFEEDBACKO

PROCEDURE 'VUATF PRIORiT';'(,,poil~list~){ dqueue_length, >queus_length poll_lst[n]

,-,

stallon,

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

Serge Vaudenay EPFL Lausanne. Swztzerland serge vaudenay@epflch

Abstract

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.

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 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).

2) negotiate with [email protected] ) M From *@user.com

[email protected]

list.com

Other subscribed users

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: 0 and x, > x,.~> . . . > x2 > XI. 2) Let g, (consumption growth in percentage) correspond to each x, whereby an alarm has to be triggered and traffic redirection activated. Detection sensitivity has to be increased as the resource utilization gets larger. Therefore, allowable consumption growth rate should be set smaller for increasing monitoring stages. 3) Let t, be the sampling rate of each stage (in seconds, n = 0 for sampling rate before first alerting point and n > 0 for sampling rate during alerting stages). Similar to the consumption growth, the detection sensitivity should be increased as the alerting point is advanced. This could be set through the sampling rate by allowing more frequent sampling at later/crucial monitoring stages. 4) Let y be the final alert point or the alarm point, whereby an alarm is immediately generated as soon as the resource utilization reaches or exceeds this point.

3.6

Rate Limiting at Gateways and Victim's AR

After TRAPS is activated, resource consumption at the victim is constantly monitored to adjust the rate-limiting parameters at the gateways and victim's AR in the protected network. An allowable stable resource consumption level, R,, is configured at the victim. We define the probability of rate-limiting, p, as the probability of dropping the incoming traffic. The initial value of p, po, is derived from R, when alarm is triggered for TRAPS activation. For example, if R, is 85% of bandwidth and aggregate incoming traffic at the victim is utilizing 95% of it's bandwidth, po will be (95-85)/95, which is approximately 0.105. This value will be sent to the gateways to perform rate limiting for this particular victim (i.e, destination of packets = victim). Resource consumption, which is constantly monitored at the sampling rate, t,, as in Section 3.4, will be used for adjusting the probability setting. To provide a last line of defense (e.g. in case of internal attackers), victim's AR will be asked to perform further rate-limiting to maintain victim's resource consumption within a "safe" level (e.g. limit victim's aggregate incoming traffic bandwidth at 100kbps).

3.7

Flooding subsidence

To prevent frequent toggling between activation and deactivation of TRAPS resulting in high overhead, three parameters would be used to determine if the DDoS attack has subsided. Therefore, TRAPS will only be deactivated if possible resource consumption without TRAPS is maintained

318

Vrizlynn L.L. Thing, Henry C.J. Lee and Morris Sloman

within an acceptable level (R, < XI,where xl is defined in Section 3.4), for at least T, seconds with a low probability (Pa) of rate limiting at the gateways. Possible resource consumption without TRAPS is measured by totaling resource consumption at the victim, resource conservation due to filtering and rate limiting at the gateways and victim's AR. The choice of the three parameters (R,, Pa, and T,) would affect the frequency of toggling as in the following equation. Frequency of toggling a (R, x PJT,

4.

(2)

PROOF OF CONCEPT (INCORPORATION WITH MIP)

We used MIP for performing the signaling as it is well-suited for carrying out the required virtual traffic redirection. It is virtual in the sense that traffic is not really redirected to another route but rather to the victim's new address, and the same default or optimal route might still be used. Another reason is that since MIPv4 and MIPv6 are IETF standards, widespread implementations of the protocols are in place (e.g, versions in Windows, Linux, BSD are available). No change will be required in the rest of the Internet infrastructure and the correspondents. In MIP, Home Agents (HAS) are responsible for proxying and intercepting the packets on behalf of Mobile Nodes (MNs, i.e. the victims here), therefore the tasks of filtering and forwarding of the packets destined to MNs can be performed by HAS instead of the gateways. In this case, the gateways are relieved from having to handle all the hosts, which might be activating TRAPS, in the network. In this way, more effective workload distribution and thus higher scalability is achieved. We developed the TRAPS prototype by implementing the necessary modifications on the MIPL MIPv6 code [22] and additional supporting modules for deployment in a testbed. The systems were running Linux kernel 2.4.22. The supporting modules implemented on the Gateway are the Rate Limiting daemon, which listens for signals from MN and provides rate limiting based on the received parameters, and the Router Bandwidth Monitoring application, which monitors all incoming traffic and records bandwidth utilization for previous interval. The Filtering daemon on the HA listens for signals from MN and filters packets with old correspondentvictim address pair. MN runs the Host Bandwidth Monitoring and TRAPS activation application, which monitors all incoming traffic, computes the bandwidth utilization, monitors the alert stages, sends TRAPS activation signal to the MIP code to trigger TRAPS, notifies gateway regarding rate limiting activation and parameter updates, and notifies HA of filtering

Traffic Redirection Attack Protection System (TRAPS)

319

updates, and the Test Server, which listens for data transfer from CN before, during and after TRAPS activation to test that there's no cutting off of messages. The Attack module on the Attacker system is an UDP packet generator with adjustable attack rate and configurable spoofed address. The Test Client on CN sends continuous data to MN before, during and after TRAPS activation to test that there's no cutting off of messages Experiments were performed by setting 3 stages of resource monitoring (2 alert stages at 50 and 60kbps respectively, and the alarm stage at 80kbps) at MN. Test Server module at MN and Test Client module at CN were started to continuously carry out data transfer. The Attacker's spoofed address was set to be CN's IP address. When the attack traffic was gradually increased through each stage corresponding to those set at MN, the alert events and finally the alarm event were triggered. MN then sent rate limiting signal to the gateway and BU to the CN regarding its new IP address. The gateway started rate limiting traffic destined to MN. When CN received MN's BU, it sent a BAck to MN. After that, MN sent the filtering signal to HA to activate filtering on the CN's address, MN's HoA pair. After which, the attack traffic from the Attacker was intercepted by HA and filtered off. On the other hand, the data transfer between the Test Server and Test Client was able to continue.

5.

DISCUSSIONS

Security Considerations o f Protocol Traffic redirections as used in TRAPS can pose a major security problem in the Internet if the protocol messages are not properly authenticated. Therefore, we will now consider the MIP related security issues, which are of concern to TRAPS. In MIPv4, it is specified that each MN, FA, and HA must be able to support a mobility security association for mobile entities, indexed by their security parameter index (SPI) and IP address. Registration messages between MN and its HA must also be authenticated with an authorizationenabling extension. This prevents a malicious node from impersonating MN to redirect away its traffic or HA to intercept MNs' packets. The MIPv4 Route Optimization Authentication extension [23] is used to authenticate the protocol messages with an SPI corresponding to the source IP address of the message and it must be used in any binding update message sent by the HA or MN to the CNs. The calculation of the authentication data is specified to be the same as in the base MIPv4. This is HMAC-MD5 [24]. A security association must be present between CN, which could be any node in the Internet, and MN/HA. It is suggested in [20] that the mobility security association at a CN could be used for all MNs served by a particular

320


HA. The effort of establishing such an association with a relevant HA is more easily justified than the effort of doing so with each MN. In MIPv6, binding updates are protected by the use of IPSec extension headers [25] or the Binding Authorization Data option, which employs a binding management key established through the return routability procedure [21]. It is specified that MN and HA must use an IPSec security association to protect the integrity and authenticity of the binding management messages. The protection of binding updates to CNs does not require the configuration of security associations or the existence of an authentication infrastructure between the MN and CNs. The return routability procedure is used to prove the authenticity of the MN by testing whether packets addressed to the two claimed addresses (i.e. HoA and CoA) are routed to the MN. MN can only pass the test if it is able to supply proof that it received the keygen tokens which CN sends to those addresses. The return routability procedure also protects CN against memory exhaustion DoS attacks as CN does not need to retain any state about individual MNs until an authentic binding update arrives. If the gateways are not implemented with the HA functionalities to perform filtering, security associations must be set up between the MN and the gateways, which are responsible for rate-limiting. Finally, it is important to note that TRAPS presents no additional security vulnerability to the MIP protocols.

Random Hit We mentioned that Class B attacks are singled out by TRAPS for notification of the latest reconfiguration information. As they could not be "reached, they could be easily identified as attack traffic flows and would then be filtered off. However, what if there happens to be a random hit (e.g. randomly generated spoofed addresses by attackers within an address range resulting in an address belonging to one of the attackers)? In this case, that particular attacker would be notified of the latest information and continue attack on the victim using randomly spoofed addresses. However, in this second round of attack, the traffic volume will be lower and distributed across the spoofed address range (and will be rate-limited instead), since the other attackers were "stopped" in the first round. A solution to strengthen the scheme and lower the chances of this happening (recommended in Section 3), is by performing regular dynamic reconfigurations and updates. Spvina bv Class A attackers It was mentioned in Section 2 that there's a possibility that Class A attackers might be used as spies to obtain protected hosthetwork's latest configuration information to support attacks in the other 3 classes. However,

Trafic Redirection Attack Protection System (TRAPS)

321

even with this information, the other forms of attacks would not be successful as prevention from filtering not only acts on knowledge of this information but also matching correspondent's address. In any case, a solution could be in place to catch the spy. The victim could have multiple sets of configuration information (e.g. multiple addresses in the Virtual Relocation Approach) and provide each set of correspondents with different configuration information. If exploitation of a particular set of configuration information is detected, we would know that a spy is within this set of correspondents. We could narrow down to the exact correspondent by performing iterations of this procedure.

6.

COMPARISONS WITH RELATED WORK

Traceback mechanisms [4-121 have been proposed to trace the true source of the DDoS attackers, as attack packets are often sent with spoofed IP addresses. In traceback, the attack path or graph is constructed to provide information on the routels the attack packets have taken to arrive at the victim. It is an attacker identification tool which requires further deployment of a detection and mitigation tool to counter DDoS attacks. Pushback [15] is a rate limiting mechanism which imposes a rate limit on data streams characterized as "malicious". It involves a local mechanism for detecting and controlling high bandwidth aggregate traffic at a single router by rate limiting the incoming traffic, and a co-operative pushback mechanism in which the router can ask upstream routers to control the aggregate. However, all high bandwidth traffic, whether good or bad, will be subjected to this rate 1imiting.Filtering mechanisms [16,17] on the other hand, filter out attack stream completely. This is used when the data stream is reliably detected as malicious; else, it may run the risk of accidentally denying service to legitimate traffic. Mechanisms such as traceback, rate limiting, and filtering need to be triggered by a third-party detection tool. The way the detection tools detect an attack is therefore very important to determine how reliable it is and which of the above-mentioned mechanisms is to be used. Detections are classified in two main categories, which are "Anomaly Detection" and "Misuse Detection" [26]. Anomaly detection techniques assume that a "normal activity profile" could be established for a system. Activities not matching the profile would be considered as intrusions. However, an action which is not intrusive but not recorded formerly in the profile would then be treated as an attack, resulting in false positive. Filtering would then result in DoS by the defense system itself. In situations whereby intrusive activities, which are not anomalous, occur, it would result in attacks not detected and

322


therefore false negatives. Such scenarios are possible if DDoS attacks are launched by flooding the victim with legitimate service requests. In misuse detection schemes, the attacks are represented in the form of a pattern or signature so that even variations of the same attack can be detected. However, they can only detect known attacks. For new attacks whereby the characteristics of the attack packets and pattern are unknown, they would of little use. They are also unable to detect attacks that are launched by flooding of legitimate packets. The advantage of TRAPS over these mechanisms is that it does not require prior traffic characterizations. A preventive measure to DDoS attacks is to ensure the authenticity of packets by eliminating source address spoofing. Ingress filtering [13] filters packets with spoofed source addresses at the first router encountered on entering the Internet. This router typically has information about valid source addresses that are allowed to pass through it. However, enforcement on supporting ingress filtering on all outbound routers to the Internet is difficult. Source Address Validity Enforcement (SAVE) [14] messages propagate valid source address information from the source to all destinations, for enroute routers to build an incoming table that associates each incoming interface of the router with a set of valid source address blocks. Packets with invalid source addresses are identified as attack packets. Widespread deployment is required for this scheme to be effective. Reconfiguration mechanisms change the topology of the victim or the intermediate network to add resources or isolate attack machines. The Secure Overlay Services (SOS) [I81 architecture is constructed using a combination of secure overlay tunneling, routing via consistent hashing, and filtering. The overlay network's entry points perform authentication verification and allow only legitimate traffic. The route taken by the traffic is computed to be designated beacons and then servlets, both of which are kept secret from the correspondents. Potential targets are protected by filtering which only allow traffic forwarded by the chosen secret servlets. Randomness and anonymity is in this way introduced into the architecture, making it difficult for an attacker to target nodes along the path to a specific SOS-protected destination. The XenoService [I91 is a distributed network of web hosts that respond to an attack on a web site by replicating it rapidly and widely. It can then quickly acquire more network connectivity to absorb a packet flood and continue providing services. TRAPS belongs to the category of reconfiguration mechanisms by changing the routes to the victim under attack. However, unlike SOS, an overlay network and complex algorithms (e.g. Chord routing algorithm, consistent hashing) need not be implemented. In SOS, only certain destinations are chosen for protection. These destinations are protected by filtering to only allow traffic forwarded by selected servlets. However,

Traffic Redirection Attack Protection System (TRAPS)

323

beacons and servlets could be subjected to attacks instead. It is recommended in [I81 to have a large number of beacons and servlets to provide redundancy. Nodes overwhelmed by the attacks would then be "removed" and their jobs will be handled by the remaining active ones. In TRAPS, any node running the MN module would be able to bring itself under protection in the event of attacks. Redundancy by providing additional resources is also not required in TRAPS, unlike XenoService.

7.

CONCLUSIONS

This paper proposes TRAPS, an adaptive real-time DDoS mitigation scheme. In TRAPS, the victim under attack verifies the authenticity of the source by performing adaptive reconfigurations, either host or network based, and requesting senders of high-bandwidth traffic streams to send subsequent data based on the victim's latest configuration. If the source is illegitimate, it would not be updated with this information. This traffic can be easily identified as attacks, with absolute confidence and be dropped. Suspicious traffic for the victim will be rate limited as most good traffic will have been redirected, leaving mainly attack packets with randomly generated IP addresses. The basic mechanisms of TRAPS, and various approaches (i.e. En-route Routers Nomination, Passcode and Virtual Relocation) of achieving the TRAPS reconfiguration for redirection were explained in detail. We discussed and evaluated the various approaches, and concluded that the endhost based approach, Virtual Relocation, is comparatively more efficient (e.g. requires least processing at gateways/routers/victim and overhead), and requires the least deployment effort among the proposed approaches. We suggested incorporating this approach with the MIP protocol to avoid proposing new protocols for Internet-wide deployment. Implementation of TRAPS was carried out and deployed in a testbed environment. It was observed that the operations of each module were functioning correctly and TRAPS was able to successfully mitigate an attack launched with spoofed source IP address. The security considerations with regards to MIP are discussed and we showed that TRAPS does not introduce any additional security vulnerability. Other possible scenarios of random hit and spying were also discussed with possible solutions proposed. Related work on the existing DDoS detection, tracking and mitigation techniques is presented. Comparison of some of their important features with TRAPS is carried out. Advantages of TRAPS over existing DDoS mechanisms are: it does not require prior traffic flow characterizations and allows for a quick real-time response even in the event whereby DDoS attacks constitute brute-force flooding of victim with legitimate service

324

Vrizlynn L. L. Thing, Henry C.J. Lee and Morris Sloman

requests; no need for additional resource allocation for providing redundancy; QoS is maintained for good high bandwidth traffic; very suitable for both high-end powerful systems and embedded systems as it is simple to implement and does not require sophisticated algorithms.

ACKNOWLEDGEMENTS We gratefully acknowledge the support from the Institute for Infocomm Research and the EU funded Diadem Distributed Firewall FP6 IST-2002002154. We would also like to thank Dr. Robert Deng for the valuable suggestions on the paper.

REFERENCES 1. K. J. Houle, G. M. Weaver, "Trends in Denial of Service Attack Technology", CERT Coordination Center, Oct. 2001 2. L. Garber, "Denial-of-Service attacks rip the Internet", IEEE Computer, Vol. 33, No. 4, pp. 12- 17, Apr. 2000 3. David Moore, Geoffrey M. Voelker, Stefan Savage, "Inferring Internet Denial-of-Service Activity", Usenix Security Symposium, Aug. 2001 4. Alex C. Snoeren et al, "Hash-Based IP Traceback", ACM Sigcomm 2001, Aug. 2001 5. Stefan Savage et al, "Practical network support for IP traceback", ACM Sigcomm 2000 6. Dawn Song, Adrian Perrig, "Advanced and authenticated marking scheme for IP traceback", IEEE Infocom 2001 7. K. Park, H. Lee, "On the Effectiveness of Probabilistic Packet Marking for IP Traceback under Denial of Service Attack", IEEE Infocom 2001 8. Steve Bellovin et al, "ICMP Traceback Messages", IETF Internet Draft, Version 4, Feb. 2003 (Work in progress) 9. Allison Mankin et al, "On Design and Evaluation of "Intention-Driven" ICMP Traceback", IEEE International Conference on Computer Communication and Networks, Oct. 2001 10.Henry C. J. Lee, Vrizlynn L. L. Thing, Yi Xu, Miao Ma, "ICMP Traceback with Cumulative Path, An Efficient Solution for IP Traceback, International Conference on Information and Communications Security, Oct. 2003 1l.Abraham Yaar, Adrian Perrig, Dawn Song, "Pi: A Path Identification Mechanism to Defend against DDoS Attacks", IEEE Symposium on Security and Privacy, May 2003 12.D. Dean, M. Franklin, A. Stubblefield, "An algebraic approach to IP Traceback", Network and Distributed System Security Symposium, Feb. 2001 13.P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000 14.Jun Li et al, "SAVE: Source address validity enforcement protocol", IEEE Infocom 2002 15.Ratul Mahajan et al, "Controlling High Bandwidth Aggregates in the Network", ACM Sigcomm 2002 16.T. Darmohray, R. Oliver, "Hot spares for DDoS attacks", http://www.usenix.org/pub1ications/login/2000-7/apropos.html 17.Mazu Enforcer, http:Nwww,mazunetworks.com

Traffic Redirection Attack Protection System (TRAPS) 18.A. D. Keromytis, V. Misra, D. Rubenstein, "SOS: Secure Overlay Services", ACM Sigcomm 2002 19.J. Yan, S. Early, R. Anderson, "The XenoService - A Distributed Defeat for Distributed Denial of Service", Information Survivability Workshop 2000, Oct. 2000 , RFC 3344, Aug. 2002 20.C. Perkins, "IP Mobility Support for I P v ~ "IETF , RFC 3775, June 2004 21.D. Johnson, C. Perkins, J. Arkko, "Mobility Support in I P v ~ "IETF 22. MIPL Mobile IPv6 for Linux, http://www.mipl.mediapoli.com 23.C. Perkins, D. B. Johnson, "Route Optimization in Mobile IP", IETF Internet Draft, Version 9, Feb. 2000 (Work in progress) 24.H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, Feb. 1997 25,s. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, Nov. 1998 26.Aurobindo Sundaram, "An Introduction to Intrusion Detection", ACM Crossroads, Vol. 2, Issue 4, pp. 3-7, Apr. 1996

STATISTICAL SIGNATURES FOR EARLY DETECTION OF FLOODING DENIAL-OFSERVICE ATTACKS

John ~ a ~ ~ e Qi r t hi' ~ ' and , Madjid ~ e r a b t i ' ' ~ i v e r ~ o John o l Moores University, School of Computing & Mathematical Sciences, Byrorn Street, Liverpool, L3 3AF. E-mail: {J.Haggerty, Q.Shi, M. Merabti} @livjm.ac.uk

Abstract:

A major threat to the information economy is denial-of-service attacks. Despite the widespread deployment of perimeter model countermeasures these attacks are highly prevalent. Therefore a new approach is posited; early detection. This paper posits an approach that utilises statistical signatures at the router to provide early detection of flooding denial-of-service attacks. The advantages of the approach presented in this paper are threefold: analysing fewer packets reduces computational load on the defence mechanism; no state information is required about the systems under protection; and alerts may span many attack packets. Thus, the defence mechanism may be placed within the routing infrastructure to prevent malicious packets from reaching their intended victim in the first place. This paper presents an overview of the early detection-enabled router algorithm and case study results.

Keywords:

network attacks; denial of service; statistical signatures; early detection.

1.

INTRODUCTION

The flow of information is the most valuable commodity for organisations and users alike. Information is traded within the networked world and we are becoming ever more reliant on access to data and resources as technologies develop to facilitate this flow. Our reliance on such network technologies has ensured that financially unquantifiable assets, such as

328

John Haggerty, Qi Shi and Madjid Merabti

people, reputation, and business relations, are amongst the most important to business [I]. A major threat posed to this information economy paradigm is that of denial-of-service attacks. These attacks present a very real threat as they disrupt or interrupt the flow of data that organisations rely on. Such attacks can be launched in a number of ways, from malicious use of common applications such as e-mail, to subverting Internet protocols. The subversion of Internet protocols leads to flooding attacks, whereby large volumes of data are sent to the victim. Denial-of-service attacks may also be a sideeffect of other types of attack, such as Internet worms. Irrespective of the modus operandi, denial-of-service attacks are prevalent because the tools required are freely available on the Internet, simple to launch, effective, and difficult to prevent. Thus, large numbers of attacks are continuously being launched [2]. In addition, businesses that rely on their connectivity, such as on-line services, can be blackmailed with the threat of a denial-of-service attack if they were not to pay [3]. Yet, despite the prevalence of these attacks, a cost-effective and efficient countermeasure has yet to be proposed. Current defences rely on the perimeter model of network security, where a boundary is established around the nodes under protection. Inside the perimeter is trusted space, whilst outside is viewed as untrustworthy. Denial-of-service attacks remain a significant problem due to the unsuitability of perimeter devices for two reasons. First, perimeter devices are located on the victim system and are therefore under attack at the point of detection. Second, these devices inspect each and every packet in an attack, which in the case of denial of service places a large computational load on the defence mechanism in addition to the large network load caused by the attack. This paper demonstrates that the use of statistical signatures for early detection of denial-of-service attacks can greatly reduce the volume of packets that are inspected to determine malicious packets from legitimate. The approach employed by this paper has three novel contributions. First, the computational load is reduced on the defence mechanism as fewer packets are analysed. Second, no state information about the networks under protection needs to be held, again reducing computational load. Third, reports of attacks may relate to several packets rather than 'one packet, one alert' techniques employed by traditional countermeasures utilising nonstatistical signatures. The reduction of volume enables detection devices to be placed beyond the perimeter and within the routing infrastructure thus enabling attacks to be thwarted prior to their reaching their intended target. As demonstrated in section 4, the approach posited in this paper remains highly efficient despite a significantly reduced number of packets inspected. This paper is organised as follows. Section 2 discusses related work. Section 3 presents an overview of statistical signatures and the effects that a

Statistical Signatures for Early Detection of Flooding Denial-of-. . .

329

denial-of-service attack has on a network that is used for early detection. Section 4 presents a case study and results. Finally, section 5 presents conclusions and further work.

RELATED WORK Flooding denial-of-service attacks are distinct from other attacks, for example, those that execute malicious code on their victim, in that they require a large volume of traffic, and it is this continuing stream of data that prevents the victim from providing services to legitimate users. It is the mass of all packets directed at the victim that poses the threat, rather than the contents of the packets themselves. Flooding denial-of-service attacks are problematic due to their subversion of normal network protocols. As such, it is these attacks that pose the greatest problem in today's network infrastructures. Subverting the use of protocols, such as the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), enables the attacker to disrupt on line services by generating a traffic overload to block links or cause routers near the victim to crash [4]. Because they subvert existing protocols the packets involved in these attacks are high-volume without being conspicuous or easily traceable. For example, TCP SYN flooding specifically targets weaknesses in the TCP protocol to achieve its aim. This attack method, which accounts for 94 per cent of denial-of-service attacks [2], is based on exploiting the three-way handshake in TCP. A number of approaches have been posited to counter the denial-ofservice problem. For example, [5] proposes stronger authentication between communicating parties across a network. Alternatively, [6] suggests that network resources should be divided into classes of service, where higher prices would attract less traffic and ensure that an attacker could not afford to launch an attack. Alternatively, [7] suggests that the routing infrastructure should be more robust by securing servers in the first place. These approaches are not without their problems. For example, authentication, whilst attempting to prevent denial of service, paradoxically leaves itself open to such an attack due to the computational load required for the defence. Payment approaches assume that the consumer is willing to pay for different levels of service, which they are usually not. Finally, it is often poor software development practices due to the pressure of getting a product to market that lead to the release of server applications that are subvertable. These problems have led to the rise of traffic monitoring approaches and fall into two categories; statistical monitoring and adaptation of congestion algorithms. Statistical monitoring of networks, such as [8, 91, observes a network and detect upsurges in traffic of a particular type or for system

330


compromise. An advantage of this approach is that one alert may cover a number of attack packets, thus reducing network load caused by the reporting of events. In addition, a large upsurge of traffic is indicative of a flooding attack, irrespective of the protocol used by the attacker. Alternatively, congestion algorithms are adapted for detection of denial-ofservice attacks. Approaches such as [lo, 111, use existing congestion techniques, where routers deal with upsurges in traffic to ensure quality of service, to detect denial of service. These approaches have the benefit of being able to detect the attack in the routing infrastructure, thus being able to halt the attack before it reaches its intended victim. However, even these more sophisticated approaches are not without their problems. Statistical approaches require human intervention to monitor the networks for upsurges, so is both labour intensive and inefficient. The congestion adaptation approaches may only apply simplistic signatures so as to not impede on the throughput of traffic. In addition, approaches such as [lo, 111 require that state information is held on the router. This information is computationally too exhaustive to be effective within the routing infrastructure. Therefore, a new approach is required that provides early detection of denial-of-service attacks; one that can combine and make use of the advantages of both the statistical and adaptation of congestion algorithm approaches. In this way, the benefits as above are achieved.

STATISTICAL SIGNATURES Traditional stateful signature analysis applies statistical methods to collected data within the system over a period of time. This data is then analysed to generate some system-specific values: for example, traffic thresholds or user profiles to define normal or abnormal behaviour [12]. By allowing a system to keep state information of the system, detection signatures can be designed to match a complex series of events which fall outside that normal behaviour. A number of techniques are employed in this area and include: Collection of events. In any system, a number of events may be observed in conjunction to indicate that an attack is under way. l Threshold enforcement. A certain threshold of acceptable events is determined for the system based on prior experience or threats. Once events in the system surpass this threshold, an alert is generated to indicate that an attack is under way. l Frequency threshold. This is a variation on threshold enforcement and is widely used in authentication. If one or more events are

Statistical Signatures for Early Detection of Flooding Denial-of-. ..

33 1

observed, then an alert is raised or services halted until a time limit is reached. Other approaches that fall into this category include analysis of mean and standard deviation information, the multivariate model, Markov process model, and clustering analysis [12]. These approaches are widely used in anomaly intrusion detection where misuse against known but ill-defined variables is being matched. Despite the requirement for state information to be held by these approaches, statistical monitoring is effective in detecting large volumes of traffic being directed at a victim host. The way in which this is achieved statelessly is presented in section 4. These approaches require state information to be held about the systems under protection but this is too computationally exhaustive to be used in the routing infrastructure. The effects on network dynamics of a denial-of-service attack and the applicability of a statistical-based approach can be clearly demonstrated through the use of a probability plot. A probability plot assesses whether a particular distribution fits the given data. The plot points are calculated using a non-parametric method. The fitted line provides a graphical representation of the percentiles. The fitted line is created by calculating the percentiles for the various percents based on the chosen distribution. The associated probabilities are transformed and used as the y variables. The percentiles may be transformed and then used as the x variables. A goodness of fit measure, such as the Anderson-Darling statistic [13], is then applied to the data. This is a measure of how far the plot points fall from the fitted line in the probability plot. The statistic is a weighted squared distance from the plot points to the fitted line with larger weights in the tails of the distribution. A smaller Anderson-Darling "Goodness of Fit" indicates that the distribution fits the data better. To demonstrate the effect of a denial-of-service attack on the data, attacks are calculated and plotted according to this technique. Figures 1 to 4 compare the results for control traffic, nuke which utilises only a small number of packets during an attack, a SYN flood attack, and a UDP flood.

John Haggerty, Qi Shi and Madjid Merabti Normal Probability Plot for ctr1512 ML EItlmales- 95% CI

ML Estrmates 99

F

96 so 80

-

-

Mean

42.775

S1Dev

16.9966

Goodness of Flt

-

nD'

;;-

3 644

# g :.

8

3020 10 5

-

1

-

50

0

100

Data

Figure I. Probability plot for control traffic.

ML Estimates Mean

49.W17

SDev

16 1061

Goodness of Fft AD'

50

Data

Figure 2. Probability plot for nuke attack traffic.

2.089

Statistical Signatures for Early Detection of Flooding Denial-of-. .. Normal Probability Plot for syn2

-

ML Estimates 95% CI

ML Estimates Mean

47.9583

StDev

112.454

Goodness of Fit AD'

-300

-200

-100

0

100

200

300

400

34.8

500

Data Figure 3. Probability plot for TCP SYN flood attack traffic.

Normal Probability Plot for udp

-

ML Estimates 95% CI

ML Estimates Mean

224.017

StDev

578.258

Goodness of FL AD'

-1000

0

1000

36.01

2000

Data Figure 4. Probability plot for UDP flood attack traffic.

The Anderson-Darling Goodness-of-Fit statistics provides the maximum likelihood and least squares estimation. The control traffic in figure 1 has a low Anderson-Darling Goodness of Fit of 3.64, suggesting that the distribution fits the data well, i.e. an attack is not underway. In

334


vulnerability attacks, such as nuke in figure 2, again the distribution fits the data well with a Goodness of Fit of 2.09. This is due to the few additional packets placed on the network for this attack to achieve its objective. In total, only nine packets are sent to the victim to exploit the kernel vulnerability on the target machine. A further six packets are sent to ensure that the attack has caused the desired effect. Therefore, during an attack, only 15 malicious packets are required. This accounts for the low Goodness of Fit. Figures 3 and 4 demonstrate that high-volume attacks have a severe effect on the network. In figure 3, the TCP SYN flood attack generates a much higher than control mean and standard deviation, 47.95 and 112.45 respectively. The Anderson-Darling Goodness of Fit is therefore high, 34.8, suggesting that the distribution fits the data significantly poorer than control. This pattern is repeated in figure 4 with the UDP flood attack on the network. The mean and standard deviation remain high, 224.02 and 578.26 respectively. The Anderson-Darling Goodness of Fit is also high at 36. As we can see, the Anderson-Darling Goodness of Fit statistics are ineffective for the detection of attacks that utilise only a small number of packets, such as nuke, but are effective for flooding denial-of-service attacks such TCP SYN flood or UDP flood.

4.

CASE STUDY AND RESULTS

The challenge remains as to how to implement statistical signatures within the routing infrastructure in an environment that is unable to support state information. This is achieved by enhancing the existing congestion algorithms present on routers. Congestion occurs within networks, and so routers employ congestion algorithms, such as RED [14] or CHOKe [15], to ensure that they do not fail when faced with high levels of traffic. These algorithms may be as simple as employing afirst in, first out (FIFO) queue. Once the queue maximum limit is reached, packets are dropped in accordance with the congestion algorithm to ensure queue space for further incoming packets. In this way, an acceptable level of traffic throughput is maintained. This paper presents the Distributed Denial-of-Service Defence Mechanism (DiDDeM) architecture [16] for early detection of denial-ofservice attacks. DiDDeM is a domain-based system that adapts congestion algorithms within the routing infrastructure. The DiDDeM system comprises a server liaising with a number of DiDDeM-enhanced routers that pre-filter attack traffic outside the traditional perimeter. Congestion algorithms are adapted for statistical signature matching by detecting large traffic volumes associated with a flooding denial-of-

Statistical Signatures for Early Detection of Flooding Denial-of-. ..

335

service attack. Rather than purely dropping packets when the router threshold is met, packets to be dropped from the queue are inspected. This enables inference of stateful information about traffic flows and whether these unusual flows are intended for a particular destination thereby suggesting an attack. It is the random inspection that allows the state inference. If two (or more) sampled dropped packets are heading to one destination, they are checked against other (stateless) signatures to confirm an attack. To demonstrate the way in which this is achieved in the DiDDeM architecture, afirst-in, first-out (FIFO) queue is used within a ns2 prototype. The available space within the DiDDeM-enhanced FIFO queue is divided into two sub-queues to allow comparison of packets. If due to bandwidth restrictions the packet cannot be immediately forwarded to the next router, an incoming packet to the router is placed in a queue. These packets are placed in either the first or second sub-queue at the router based on a firstcome, first-served basis. Packets placed in the queue, and its sub-queues, are dequeued and forwarded to their destination. If the threshold of the total queue limit is exceeded the router begins to drop packets to ensure that packets already in the queue are forwarded and that new incoming packets can be placed in the queue. In this way, no stateful information is held about the queue apart from whether the queue limit has been exceeded, thereby reducing the computational overhead placed on the router. At periods where congestion occurs, packets are dropped. By meeting the threshold of the particular router which invokes packet dropping, an upsurge in traffic can be inferred. However, this may or may not be due to large amounts of traffic, such as would occur during a flooding denial-ofservice attack. Therefore, prior to packets being dropped, the IP header is accessed and the destination address obtained. This IP destination address is compared to the previous packet's IP destination address. If they are the same, then the IP destination address is stored for comparison with the next packet and the packet is passed for stateless signature analysis. Stateless signature analysis verifies attacks by applying techniques used in misuse detection whereby fixed byte sequences within the packet are inspected. If the destination addresses are not the same, the destination IP address is still stored for comparison with the next packet, but the packet is dropped. The algorithm is illustrated in figure 5.


Arriving packet

I

dmit new packet

C_'

i2

Analysepacket

to be dropped

I

Enqueue

/

u l ~ l p r e v i ypacket

address

L-i analysis

i] Drop packet

Figure 5. Routing algorithm using a FIFO queue

A simulation was conducted in which approximately 19,500 attack packets were directed at the victim node by two attacking nodes. This represented an attack consisting of approximately 1,000 packets per second. Once the congestion algorithm was invoked by the router, 798 attack and legitimate packets were to be dropped. Of this number, 742 packets were actual attack packets whilst the remainder were legitimate traffic. Therefore, out of a total of 19,500 attack packets, only 4 per cent of this volume was inspected. DiDDeM detected 697 packets using the algorithm in figure 5. The 697 packets detected out of the 742 inspected by the DiDDeM-enhanced router ensure a 94 per cent detection rate. This system is therefore extremely efficient.

Statistical Signatures for Early Detection of Flooding Denial-of-. . .

337

The prototype is tested on two systems to measure the impact of DiDDeM detection on the router. The methodology used is to measure the impact of the simulation on the processor by using the top program. This program measures the load by applications on the processor in the UNWLinux operating system. To provide a comparison with current network standards, the memory and processor usage were tested for DiDDeM and two routing algorithms; DropTail, and RED. This comparison allows us to see the impact on router efficiency in implementing DiDDeM and is presented in table 1. Table I. Impact on memory and processor of DiDDeM versus RED and DropTail algorithms.

Algorithm

PI1 400 MHz 128 M b RAM

AMD 2 GHz 256 Mb RAM

Memory usage

Processor load

Memory usage

Processor load

DiDDeM

4.70%

95.50%

2.30%

41.10%

RED

4.70%

96.70%

2.30%

60.00%

Drop Tail

4.60%

96.20%

2.20%

51.80%

As demonstrated by table 1, the impact of the simulation routing algorithm affected the memory usage of both computers. The DropTail routing algorithm required less memory usage, an improvement of 2.13% (PI1 processor) and 4.34% (AMD Athlon) compared to both DiDDeM and RED. However, DiDDeM was actively detecting denial-of-service attacks whilst the RED algorithm merely detected congestion at the router. In terms of processor load, DiDDeM proved to be more efficient. One key measure for DiDDeM is its performance within the network environment. In particular, the DiDDeM algorithm should not have an adverse affect on the network, which would require a trade off between usability and effectiveness. In order to measure the performance of the DiDDeM in the network it is compared to the routing algorithms above; RED and DropTail. Unlike RED, DiDDeM and DropTail do not require any information about the state of the queue. However, to test the impact of DiDDeM on the queue and the network, the number of datagrams and packets passed from a router within the attack domain to the second router is measured. This impact is illustrated in figures 6 to 8 showing DiDDeM, DropTail and RED.

338


Figure 6. Packets sent by the DiDDeM-enabled router.

Figure 7. Packets sent by the DropTail-enabled router.

Statistical Signatures for Early Detection of Flooding Denial-of-. .

Figure 8. Packets sent by the RED-enabled router

Figures 6 to 8 show the number of packets sent by router 1 at 0.1 second intervals. The attack is launched just before 5 seconds, as indicated by the sharp increase of traffic. Prior to the attack, all three approaches steadily send the packets comparably, although one slight dip in the number of packets sent is seen in RED at just after 4 seconds. Although all three approaches maintain a queue, they are also able to comparably send packets. In fact, there is very little difference in the number of packets sent between the two routers used in the case study. However, whilst in DropTail and RED, those packets not sent are dropped, DiDDeM is comparing these packets for early detection of denial-of-service attacks. As these figures demonstrate, DiDDeM has little effect on the number of packets sent, and therefore network performance.

5.

CONCLUSIONS AND FURTHER WORK

The flow of information is the most valuable commodity for organisations and users alike, and denial-of-service attacks pose a great threat to this flow. These attacks are highly prevalent despite the widespread deployment of network security countermeasures such as firewalls and intrusion detection systems. These countermeasures find denial of service extremely problematic, therefore a number of other approaches have previously been proposed to counter the problem. However, these

340


approaches are not without their own problems, thus a new approach of early detection of denial-of-service attacks is required. The paper demonstrates that statistical measures may be used to provide signatures of denial-of-service attacks. However, traditional uses of these techniques are labour intensive and require state information, which is computationally exhaustive within the routing infrastructure. Therefore, this paper has demonstrated the way in which a routing congestion algorithm may be adapted to provide statistical signatures statelessly. The results from our case study in ns2 demonstrate the applicability of this approach in that it is highly effective in the detection of attacks without impeding on network traffic. This approach provides three benefits: computational load is reduced on the defence mechanism, even during an attack; no state information is required, again reducing computational load; and alerts to attacks may span several packets, thus reducing network load during an attack. In this way countermeasures can be placed beyond the perimeter and within the routing infrastructure to prevent attacks from reaching their intended victim. Future work concentrates on the application of the system to other attacks that require or generate a high volume of traffic such as worms and malicious mobile code.

REFERENCES Department of Trade and Industry / Price Waterhouse Coopers, "Information Security Breaches Survey 2004," Technical Report, http://www.dti.gov/industries/information-security (2003). Moore, D., Voelker, G.M. & Savage, S., "Inferring Internet Denial-ofService Activity," in Proceedings of 10th Usenix Security Symposium, Washington, DC (2001). Anonymous, "Russian blackmailers arrested: Peace at last for online bookmakers," Computer Fraud and Security, vol. 2004, no. 8, p.1 (2003). Gil, T.M. & Poletto, M., "MULTOPS: a data-structure for bandwidth attack detection," in Proceedings of USENIX Security Symposium, Washington, DC, USA (2001). Meadows, C., "A cost-based framework for analysis of denial of service in networks," Journal of Computer Security, vol. 9, pp. 143-164 (2001). Brustoloni, J.C., "Protecting Electronic Commerce from Distributed Denialof-Service Attacks," in Proceedings of WWW2002, Honolulu, Hawaii, USA (2001). Papadimitratos, P. & Haas, Z.J., "Securing the Internet Routing Infrastructure," IEEE Communications Magazine, vol. 40, pp. 76-82 (2002). Shan, Z., Chen, P., Xu, Y. & Xu, K., "A Network State Based Intrusion Detection Model," in Proceedings of Computer Networks and Mobile Computing 2001 (ICCNMC), Beijing, China (2001).

Statistical Signatures for Early Detection of Flooding Denial-of-. .. 9.

10.

11.

12. 13.

14.

15.

16.

34 1

Sterne, D., Djahandari, K., Balupari, R., La Choker, W., Babson, B., Wilson, B., Narasimhan, P. & Purtell, A,, "Active Network Based DDoS Defense," in Proceedings of DARPA Active Networks Conference and Exposition (DANCE '02), San Fransisco, CA, USA (2002). Ioannidis, J. & Bellovin, S.M., "Implementing Pushback: Router-based Defense Against DDoS Attacks," in Proceedings of Network and Distributed Systems Security Symposium, San Diego, CA, USA (2002). Kuzmanovic, A. & Knightly, E.W., "Low-Rate TCP-Targeted Denial of Service Attacks," in Proceedings of Symposium on Communications Architecture and Protocols (SIGCOMM),Karlesruhe, Germany (2003). Verwoerd, T. & Hunt, R., "Intrusion detection techniques and approaches," Computer Communications, vol. 25, pp. 1356-1365 (2002). Stephens, M.A., "EDF Statistics for Goodness of Fit and Some Comparisons" in the Journal of American Statistical Association, vol. 69, pp. 730-737 (1974). Floyd, S. & Jacobson, V., "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, vol. 3, pp. 365-386 (1993). Pan, R., Prabhakar, B. & Psounis, K., "CHOKe: A stateless active queue management scheme for approximating fair bandwidth allocation," in Proceedings of IEEE INFOCOMM 2000, Tel Aviv, Israel (2000). Haggerty, J., Shi, Q. & Merabti, M., "DiDDeM: A System for Early Detection of TCP SYN Flood Attacks", in Proceedings of Globecom 04, Dallas, TX, USA (2004).

DESIGN, IMPLEMENTATION, AND EVALUATION OF FRITRACE

Wayne Huang, J.L. Cong, Chien-Long Wu, Fan Zhao, S. Felix Wu University of California, Davis, California 95616

Abstract:

Denial-of-Service attacks are more prevalent than ever, despite the loss of media attention after the infamous attacks that shut down major Internet portals such as Yahoo, eBay and E*Trade in February 2000. In these flood-style denial-of-service attacks, attackers send specially formatted IP packets with forged or true IP source addresses at potentially high packet rates in order to overload/waste the resources of the routers or servers they are attacking. Determining the true sources of an attack stream, depending on the DDoS attack types, is a difficult problem given the nature of the IP protocol however it is often beneficial for the victims to acquire this information in a timely manner in order to stop the attack from further denying service to legitimate users. FRiTrace (Free ICMP Traceback) is an IP traceback implementation that can provide victims of flood-style denial-of-service attacks with sufficient information to determine the true sources of an attack, despite forged IP headers and varying attack architectures. In this paper, we present our design, implementation, and evaluation about FRiTrace.

Key words:

Attack source tracing; DDoS.

INTRODUCTION Despite being out of the media spotlight, denial-of-service attacks are more prevalent than ever. One study, aimed at analyzing the byproduct of

Wayne Huang, J.L. Cong, Chien-Long Wu, Fun Zhao, S. Felix

Wzl

denial-of-service attacks, inferred using their backscatter analysis technique that 12,805 attacks occurred against over 5,000 hosts in just a three-week period (Moore et al., 2001). Due to the lack of spoofed denial-of-service counter measures, the problem of identifymg the true source of an attack in the presence of IP spoofing has become even more relevant. If the victims of an attack can discover the true sources in a timely manner, this will allow administrators to coordinate their efforts in stopping the attack by filtering it directly upstream of the source and may provide sufficient information during the investigative phase to prosecute the perpetrators. This provides two benefits. First, the sooner the sources can be identified, the sooner they can be filtered or shutdown to prevent further loss of or degraded service to legitimate users. Second, accountability provides a psychological deterrent to launching further denial-of-service attacks. In this paper, we present FriTrace, an IP traceback system using the ICMP Traceback (Bellovin, 2000) and Intention ICMP Traceback (Wu et al., 2001) mechanisms as described in their respective IETF drafts. FriTrace, through the use of specially formatted out-of-band messages, can provide the victims of an attack with sufficient information to construct an attack graph consisting of all administrative domains supporting iTrace or Intention iTrace through which attack packets traversed thus allowing the discovery of the true victims or administrative domains containing the victims. In addition, this paper will discuss various design issues with respect to FriTrace and present the results of our deployment of FriTrace in a test-bed environment.

FLOODING ATTACKS Besides all the existing DDoS attacks, we are considering a new type of statistical attack aimed at IP traceback mechanisms that probabilistically select packets for marking or the generation of an out-of-band message, such as iTrace. With probabilistic schemes, all packets seen at a given router or host are considered equally for marlung or generating an iTrace message. Therefore the probability of selecting a packet that is part of an attack stream is based on the percentage of the total packet flow through the router or host that comprises attack packets. Therefore, if it is possible to artificially inflate the background "legitimate" traffic at the router or host, then its possible to decrease the probability of selecting an attack packet, thus reducing the overall effect of the IP traceback mechanism. With a slight modification to the distributed denial-of-service architecture, a statistical attack can be launched. The slaves are split into two logical groups where each slave still attacks the same victim or victims. However, in addition to the attack traffic, each slave in each group sends cover traffic to each slave in the other group.

Design, Implementation, and Evaluation of FRiTrace

345

If there are sufficient slaves, the cover traffic packet rate can be relatively small and thus less detectable. In doing this, depending on the number of slaves, the attackers can generate artificial background traffic thereby reducing the likelihood of attack packets being selected by routers closest to the slaves. In addition, this attack architecture has all of the benefits of the distributed attack including greater anonymity and the ability to generate packet rates of extremely large magnitude.

3.

IP SOURCE ACCOUNTABILITY MECHANISMS

The stateless nature of the IP protocol and lack of appropriate filtering by routers makes it an extremely difficult problem to provide source accountability during spoofed denial-of-service attacks. However, there are currently a number of different techniques that provide varying degrees of source accountability. First, source accountability can be achieved through the use of link testing or other flood-based approaches whereby the victim will flood its upstream links to determine which link is passing the bulk of the attack traffic by measuring the drop in the attack traffic rate when the link is flooded. The second class of mechanisms is logging-based, such as Hash-Based IP Traceback (Snoeren, 2001). These mechanisms require routers to store, in some compact format, information about all the packets it has forwarded for a given interval of time. The last class of source accountability mechanisms select packets probabilistically in which to mark the packet or to generate an out-of-band message describing the links from which the packet arrived at the router and which link the packet was forwarded through. These mechanisms rely on the fact that flooding denialof-service attacks often generate large packet streams for long durations and thus cannot be used to identify the source of a single packet as with the previously mentioned logging mechanisms. Some examples of these mechanisms include the advanced and authenticated marking scheme (Song et al., 2001) based on the original probabilistic packet marlung scheme (Savage et al., 2000). Two other probabilistic schemes, and the schemes implemented in FriTrace are ICMP Traceback (Bellovin, 2000) and Intention-Driven ICMP Traceback (Wu et al., 2001).

4.

INTENTION-DRIVEN ICMP TRACEBACK

ICMP Traceback (iTrace) is a mechanism where packets are selected randomly according to a probabilityp for generating iTrace messages. Once a packet is selected, a specially formatted out-of-band ICMP message is sent

346

Wayne Huang, J.L. Cong, Chien-Long Wu, Fan Zhao, S. F e l h Wu

towards the destination of the selected packet. This message contains usefill information such as the IP address and MAC address pair of both the upstream and downstream links of the router that selected the packet. In addition, a timestamp and a portion of the selected packet's payload are included for use by the receiver to correlate messages to received packets. Lastly, the iTrace message contains optional message authentication information to prevent a malicious user from forging iTrace messages. In the IP packet containing the iTrace message, the TTL field is always initialized to 64. When the victim of a denial-of-service attack receives iTrace messages, they can be ordered to generate a graph from the victim to the attacker's domain including all intermediary routers that support iTrace and generated iTrace messages towards the victim. This ordering can be achieved in two ways. First, two adjacent routers will share a link, where one router's downstream link is the other router's upstream link or vice versa. By analyzing the link information in the iTrace packets, it can be inferred that two routers are adjacent if they share a common link. However, this assumes that all routers in the path support iTrace. To allow for incremental deployment of iTrace, ordering can also be deduced based on the value of TTL field in the IP header containing the iTrace message. All routers correctly following the IP protocol, regardless of whether they support iTrace, will decrement the TTL field before forwarding a packet to the next hop. After generating a graph showing all intermediary routers up to or near the attacking domain, the job of locating the actual source, usually done manually, can be expedited by eliminating the need to contact all intermediary administrative domains to determine the next upstream administrative domain passing the attack traffic. The original ICMP traceback scheme provided sufficient information for the victims of flooding denial-of-service attacks to determine the nearest administrative domain supporting iTrace to the actual attackers, regardless of potentially spoofed IP addresses in the attack packets. In addition, authentication codes can be used to prevent malicious users from forging iTrace messages to obstruct or mislead the construction of the attack graph. However, the original iTrace scheme is susceptible to the statistical denial-of-service attack described earlier. Specifically, iTrace will select packets randomly with probability p at any given router supporting iTrace. Therefore, the probability of selecting attack packets is simply p(R,J, where R , is the ratio of attack traffic to total traffic. By artificially increasing the total traffic without affecting the attack traffic, a malicious user can reduce R,, and thus reduce the overall probability of iTrace selecting attack packets. Intention-Driven ICMP Traceback (Intention iTrace) is an enhancement to iTrace where packet seiection factors in an administrative domain's desire


347

to receive iTrace messages. For each administrative domain, this desire is propagated through the use of an intention bit associated with each network prefix the administrative domain, or autonomous system (AS) advertises through BGP. Using a network intrusion detection system or even manually with an administrator, the intention bit can be dynamically set if the AS detects it is under a denial-of-service attack. BGP will automatically propagate this information to all BGP-speaking routers on the Internet for use with Intention iTrace. The Intention iTrace consists of two different packet selection algorithms, however both algorithms achieve an average packet selection probability of p while allowing the administrator to specify the percentage pi of selected packets to subject to the Intention iTrace criteria that an iTrace message only be generated for destinations wishing to receive iTrace messages. For all other I - pi selected packets not subject to the Intention iTrace criteria, normal iTrace messages are generated as the normal iTrace. The first algorithm separates traffic into two classes by analyzing all of the intention bits that are known to a particular router's routing information base (RLB). Packets with destination prefixes having an intention bit of 1 in the RIB will be considered intention traffic and all other packets will be considered normal trafJic with R,, representing the ratio of intention traffic to total traffic. Both traffic classes will consider packets equally for normal iTrace, or a probability of p(I - p J , however the intention traffic must also be considered for Intention iTrace. Intuitively, this probability should be p @ , however this probability would be static. In the ideal case, if Rin, is extremely small then the probability for generating an Intention iTrace message should be greater than p@J, otherwise it is likely that packets from the intention traffic will not be considered. Similarly, as R,, approaches 1, the probability for selecting a packet to consider with Intention iTrace should be as close to p(pJ as possible or packets will no longer be considered for normal iTrace. To strike a balance between packets being considered for normal iTrace and Intention iTrace, the probability for considering a packet for Intention iTrace from the intention traffic is p(pJRi,t). (~Traced) (Intention ~Traced)

Figure I. Intention iTrace Scheme 1 (IIS#l) Decision Process

348

Wayne Huang, J.L. Cong, Chien-Long Wu, Fan Zhao, S. Felix Wu

Therefore, the total probability for an intention traffic packet to be considered for iTrace message generation is P, = p(1 - pJ + p(pi/Ri,,J and P,, = p(1 - pJ for packets in the normal traffic class. The total overall probability for generating an iTrace message can then be expressed as P,,, = Rint * P i + (I-Rind * P , = p . The second algorithm does not segregate traffic into traffic classes and instead, first selects a packet for either iTrace or Intention iTrace consideration with probability p as in the normal iTrace scheme. The selected packet is then sent to the appropriate decision module based on the probability pi, where with probability p(pJ the packet will be considered by the Intention iTrace decision module and with probability p(1 - pJ the packet will be considered by the normal iTrace decision module. However, within the normal iTrace decision module, the packet's destination prefix is looked up in the router's RIB and if the intention bit is set, the packet will still be considered under the Intention iTrace criteria. If the destination prefix in the RIB does not have its intention bit set, then the packet generates a normal iTrace message. Based on the ratio R;,, of intention traffic to normal traffic, it is given that approximately Rin, of packets sent to the normal iTrace decision module will be considered for Intention iTrace and 1 - Rin,of packets will generate normal iTrace messages. lotenlion tTrace (intention [Traced)

Normal [Trace

[Intention !Traced) (~Traced)

Figure 2. Intention iTrace Scheme 2 (IIS#2), Decision Process

The total probability that a selected packet will be considered using the Intention iTrace criteria is Pi = p(pJ + p(1 - p J * R,,, and the probability that a selected packet will generate a normal iTrace message is P, = p(l - p J * (I - Ri,J. The average probability of selected packet being considered for iTrace is thus P,, = Pi + P,, = p. Thus for both Intention iTrace algorithms, the average probability for a packet to be considered for generation of an iTrace message is p, but both algorithms allow administrators to determine the amount of resources to be dedicated to Intention iTrace and provide a method for randomly mixing both normal iTrace and Intention iTrace schemes. Using Intention iTrace will still allow the victim of a statistical denial-of-service attack to receive usehl iTrace messages despite the artificial increase in background traffic.

Design, Implementation, and Evalzmtion of FRiTrace

349

In addition, Intention iTrace will still generate normal iTrace messages to destinations whom may be under a denial-of-service attack but that have not detected the attack and thus have not specified their desire to receive iTrace messages.

5.

FRITRACE DESIGN AND IMPLEMENTATION

FriTrace is our open-source implementation of an IP traceback suite that supports both iTrace and Intention iTrace as well as authentication to prevent spoofed iTrace messages, source IP address spoof detection and source iTrace. The iTrace and Intention iTrace mechanisms were originally designed to work in router platforms where knowledge of upstream and downstream links would be used in the generation of an iTrace message. As such, we developed FRiTrace as a Linux 2.4 Loadable Kernel Module (LKM) to be run on Linux-based routers to provide iTrace and Intention iTrace support. However, most administrative domains use appliance-based routers such as those made by Cisco and Juniper Networks, and therefore the FriTrace LKM would not be as useful in those domains without replacing the appliance-based routers with Linux-based routers. In order to allow such domains to support iTrace and Intention iTrace, a passive implementation of FriTrace was developed that would listen on a network in order to select packets to be iTraced instead of selecting packets while forwarding them, such as in the LKM implementation. In this paper, only the passive approach is discussed.

5.1

FriTrace Probabilistic Packet Selection

Regardless of whether normal iTrace or Intention iTrace is activated in FriTrace, both modes require the ability to probabilistically select packets given a probabilityp. The naive approach to the selection method would be to maintain a counter and to select a packet every time the counter modulo I / p was equal to 14 - I . While this maintains an average probability o f p to select a packet, it is not secure to specially timed attacks. By selecting packets statically using this method, a crafty attacker can setup a flooding denial-of-service attack where the attack packets are sent periodically with the same frequency. If timed correctly, this attack can exploit the static packet selection technique to avoid selection of packets from the attack stream. To counter this timed attack, packet selection must occur randomly with probabilityp. This can be implemented by computing a random number for each packet and selecting the packet if the generated random number is less

350

Wayne Huang, J. L. Cong, Chien-Long

Wzl, Fan

Zhao, S. Felix WZI

than p . Assuming a uniformly distributed pseudo random number generator (PRNG), attack packets will be selected at random with a probability p. However this approach suffers in that a random number must be generated for each packet, thus causing per-packet overhead, which should be avoided in order not to affect packet-processing rates. In FriTrace, random packet selection is achieved by pre-computing a series of n random numbers using a uniformly distributed PRNG for integer values between 0 and n(l/pl - 1, inclusive. The window of n random numbers is then sorted. For each packet that is read, a counter is incremented. When the counter value equals a value from the random number window, a packet is selected. When the counter value reaches n(l/pl it is reset to zero and a new window of random numbers is computed. This approach allows packets to be selected at random with a probabilityp, without incurring the overhead of computing a random number for each packet.

5.2

Source iTrace

IP traceback mechanisms have primarily focused on allowing the victims of denial-of-service attacks to discover the true sources of their attackers. However, depending on the specific attack used, there may be other administrative domains adversely affected. Specifically, the use of most spoofed denial-of-service attacks causes the victim to generate responses towards the IP addresses that were spoofed. Therefore, if iTrace messages are also generated with an independent probability p towards the source of a packet, this would allow administrative domains to discover that their address space is being used by a malicious user in a spoofed denial-ofservice attack. Another distributed denial-of-service attack architecture involves the use of reflectors, or innocent hosts on the Internet used to reflect attack packets towards a victim. Instead of the slaves generating the attack traffic directly towards the victim, they instead reflect their attacks off of random hosts on the Internet by using the functionality of the TCP and UDP transport layer protocols. For example, if an attacker sends a SYN packet to a reflector with a forged source address of the victim, any response generated by the reflector will be sent to the victim. With the use of iTrace or Intention iTrace the victim would simply trace back to the reflectors used in the attack, which is not especially useful to the victim. However, with the use of Source iTrace, the packet stream from the slaves to the reflectors will be iTraced with the iTrace messages being sent towards the victim. This information can then be used to discover the slaves in a reflector-based denial-of-service attack.

Design, Implementation, and Evaluation of FRiTvace

351

FriTrace supports the Source iTrace feature and maintains an independent probability to generate Source iTrace messages.

5.3

The Passive Approach and its Implementation

The passive implementation of FriTrace is run entirely in user space as a single process. There are three main components within the passive FriTrace implementation. Kernel

Network

+. 4

.

..

User

...m

trace Daemon

.D ...

Figure 3. FriTrace, Passive Architecture The first is the network stack interface using libpcap that allows FriTrace passive access to all packets on a network segment using the BSD Packet Filter (BPF) (McCanne et al., 1993) or packet socket functionality. The libpcap interface then calls the iTrace decision module for each packet that is observed on the network, similar to the functionality of Netfilter in the active implementation. The iTrace decision module then applies the appropriate packet selection algorithm and if a packet is selected to be iTraced, it will be sent to the iTrace generation component prior to returning control to the libpcap interface. The second component, or iTrace generation component, performs the logging of packet information to syslog and generates iTrace messages. Lastly, the third component validates and responds to authentication requests. It is important to note that because packets are read from the network passively, there is no accompanying information that passive FriTrace can use to truly identify either an upstream or downstream IP link. However, packets intercepted through libpcap retain their link layer information, which provides passive FriTrace with information that can be used to generate a MAC address upstream link. Since passive FriTrace will be operating on a network segment, the receiver of an iTrace message can determine the administrative domain from which the message was sent based on the IP address of the host running passive FriTrace. Once the offending administrative domain is located, the MAC address pair can be used to locate individual machines from within that domain.

352

6.

Wayne Huang, J.L. Cong, Chien-Long Wu, Fan Zhao, S. Felix Wu

FRITRACE EVALUATION

The experimental setup consisted of four hosts, a 100 Mbps hub and a router. The Attacker, Background and FRiTrace hosts were Pentium I11 700 MHz servers with 5 12 MB of memory and a 100 Mbps network interface card, running Red Hat Linux release 7.0 with the Linux 2.2.16 kernel. All three hosts are connected to a 100 Mbps hub, which is in turn connected to a router. The Victim host is a dual Pentium 111 1000 MHz with 512 MB of memory and a 100 Mbps network interface card, running Red Hat Linux release 7.2 with the Linux 2.4.7 kernel.

As shown above, separate experiments with different parameters were conducted using FRiTrace on this experimental topology. In the first experiment, the background traffic was fixed at 16,000 pps with the attack rate doubling with each run from 1,000 pps to 16,000 pps. In the second experiment, the attack rate was fixed at 2,000 pps with the background traffic rate doubling with each run from 2,000 pps to 16,000 pps. These experiments were conducted with normal iTrace and both Intention iTrace schemes with p = 1120,000. For the Intention iTrace schemes, pi was set to 1/10, 114 and 112. Each experiment was conducted a total of ten times. Using a modified FRiTrace daemon, information about each iTrace message generated was stored to a log file. This information contained the iTrace packet size and the destination IP address. Once all of the experiments were conducted, the log files, one generated for each run, were post-processed to obtain the total number of iTrace messages generated, the

353


total number of useful iTrace messages, the total packet overhead of FRiTrace and the total data overhead of FRiTrace. One method of determining the effectiveness of FRiTrace as an IP traceback suite is to measure how many useful iTrace messages were generated with the different schemes, where a useful iTrace message is defined as one generated from a packet belonging to a denial of service attack stream. The higher the number of useful iTrace messages received by the victim of an attack, the more confidence the victim can place on the path generated by post-processing the iTrace messages. Once the data was compiled, all three schemes were compared to each other to show the relative effectiveness of one scheme versus another and to also show how the pi parameters relates to the overall effectiveness of the Intention iTrace schemes. Useful Messages (16,000 pps Background Traffic)

0

20W

4000

6000

8000

lWO0

12000

14000

16000

18000

Attack Rate (pps)

Figure 4. Number of Useful Messages for Normal vs IIS#I

The first comparison was between normal iTrace and Intention iTrace scheme 1 with a fixed background rate and shows how the number of useful messages is affected by changes in the attack rate. As can be seen from this comparison (Figure 4), overall the Intention iTrace scheme 1 showed a higher number of useful iTrace messages. Based on the functionality of Intention iTrace this behavior was expected. In addition, asp, was increased from 1/10 to 112, the number of useful messages also increased. In scheme 1, the Intention iTrace decision module classifies packets into two groups based on the packets' destination addresses. As a result, when the ratio of Intention traffic to total traffic, R,, is small, the reiative increase in the

354

Wayne Huang, J.L. Cong, Chien-Long Wzl, Fan Zhao, S. Felix Wu

number of useful messages is also small when comparing normal iTrace to Intention iTrace and also between the Intention iTrace runs with varying p,. However, as Riincreases, the increase in the number of useful messages becomes more realized. Lastly, with Intention iTrace scheme 1, there is roughly a linear relationship between the number of useful messages and pi at high attack rates. For example, the number of useful messages roughly doubled whenp, was increased from 114 to 112. We have also compared the normal iTrace scheme and IIS#2. This scheme does not classify packets into traffic groups, but instead generates a trigger with probability p , after which pi decides whether the packet should be treated as an Intention packet or a normal packet. Because of this, the change in the number of useful messages as the attack rate increases is not affected by the ratio of Intention trafficto total traffic, Ri. Useful Messages (2,000 pps Attack Rate)

Background Traffic Rate (pps)

Figure 5. Normal vs. IIS#l, with Variable Background Traffic

Figure 5 shows how the number of useful messages is affected by an increase in the background traffic rate in all the schemes. This experiment is important for determining how effective a statistical denial of service attack is on hiding the true attack packets. In general, as the background traffic rate increases, there is a decrease in the number of useful messages in all runs. However, the rate of decrease as the background traffic rate increases varies for each run. For example, using normal iTrace, as the background traffic

355

Design, Implementation, and Evalzmtion of FRiTrace

rate doubles, the number of useful messages decreases by half. But for Intention iTrace, the rate of decrease decreases as p, is increased despite increasing the background traffic rate. This can be seen from the scheme 1 run withp, = 112. An initial doubling of the background traffic rate drops the number of useful messages from about 90 to 60, a decrease of about 112. The next doubling of the background traffic rate yields a decrease of only 113, and so on. In general, as pi is increased towards 1.O, the rate of decrease approaches 0. This is consistent with the functionality of Intention iTrace, which only generates iTrace messages for prefixes with an intention bit of 1. We have also performed the same experiments with IIS#2, and the results are similar. Useful Messages (16,000 pps Background Traffic)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Attack Rate (pps)

Figure 6. Number of Useful Messages for IIS#l versus IIS#2

From these comparisons, the most important result is that both Intention iTrace schemes are resilient to statistical denial of service attacks because as the background traffic rate increases, the rate of decrease of the number of useful messages also decreases. In addition, as pi is increased, the amount of decrease increases until pi = 1 where a decrease in the number of useful messages no longer occurs.

Wayne Huang, J.L. Cong, Chien-Long Wzr, Fan Zhao, S. Felix Wu

Useful Messages (2,000 pps Attack Rate)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Background Traffic Rate (pps)

Figure 7. Scheme 1 vs Scheme 2, with Variable Background Traffic

The next comparisons show how the two different Intention iTrace schemes compare in terms of useful messages when there is a fixed background traffic rate of 16,000 pps and a variable attack rate and when there is a fixed attack rate of 2,000 pps and a variable background traffic rate.The solid lines in Figure 6 represent scheme 1 results and the dashed lines represent scheme 2 results with varying pi. As can be seen, scheme 2, in general generated more useful messages than scheme 1 under identical testing conditions. From this comparison, the effect of classifying traffic into groups and selecting packets independently is apparent by the significantly lower number of useful messages produced by scheme 1 compared to scheme 2 when the ratio of Intention traffic to total traffic Riis low. For higher values of pi, it appears that scheme 1 achieves its maximum usefulness around Ri= 0.5 when compared to scheme 2. Up to and following Ri = 0.5, the number of useful messages decreases compared to scheme 2. With variable background traffic, as in Figure 8, scheme 2 achieves a higher number of useful messages at all levels of pi and for all values of Ri. However, more important to note is the fact that scheme 2 is much more resilient to statistical denial of service attacks, which artificially inflate the background traffic rates. Not only do the scheme 2 results generate more useful iTrace messages, but the rate of decrease of the number of useful


357

messages as the background traffic rate increases is much smaller in scheme 2 than in scheme 1. The quicker stabilization of scheme 2 even for small R, indicates that much more of the background traffic is ignored by scheme 2 and that further increases of the background traffic rate past 16,000 pps would yield only slight decreases in the number of useful messages.

SUMMARY To show the overall effectiveness of FRiTrace, several experiments were conducted to measure the number of useful iTrace messages and the total traffic overhead generated by the various FRiTrace modes. For the Intention iTrace schemes, p, was also varied to observe its effects on the number of useful messages and total traffic overhead. Our experiments showed that even when the attack traffic represents a small percentage of the overall background traffic that FRiTrace is still able to generate a substantial amount of useful iTrace messages. While it only takes a single message from any of the routers along the path from the victim to the true attacker, the more messages received fi-om the routers along the path the greater confidence the victim can place in the final traced path to the attacker or attackers. By increasing p, throughout the first set of experiments, it was shown that not only does the Intention iTrace scheme generate more useful messages, but there is also a near-linear relationship between p, and the relative amount of useful messages, regardless of the attack rate or background traffic rate. Lastly, the first set of experiments showed the true benefits of the Intention iTrace schemes. With a fixed attack rate, as the background rate was increased, the number of useful messages did not drop linearly as in the normal iTrace scheme. Instead, the decrease in the number of useful messages decreased as either pi or R, increased and eventually reached a stable value where additional increases in the background traffic would still generate approximately the same number of useful messages. This behavior was not expected or observed in normal iTrace, where there was a linear relationship between the decrease in useful iTrace messages and the increase in the background traffic rate. Our experiments also showed that even in the worse case, FRiTrace only generated approximately 0.0064% total network traffic overhead. This equates to an increase of approximately 6.5 kbps for every 100 Mbps of traffic analyzed by FRiTrace, a very small amount of overhead. In addition, the amount of overhead is a function of the probability to generate an iTrace message p. A decrease in p would result in a decrease of the network traffic overhead. This parameter is intended to be set by the network administrators of the domain being analyzed based on traffic patterns observed on the

358

Wayne Huang, J.L. Cong, Chien-Long Wu, Fan Zhao, S. Felix

Wzl

network. Aside from the overall low overhead introduced by FRiTrace, several logical trends were observed. As p, increased for both Intention iTrace schemes, the amount of total traffic overhead also dropped. As R, increased, total traffic overhead stabilized regardless the increase in either the background traffic rate or attack rate. Lastly, it was observed that scheme 2 produced slightly higher overhead than scheme 1.However, this is a result of the higher efficiency of scheme 2 and is also shown in the first set of experiments where scheme 2 generated more useful iTrace messages than scheme 1 regardless of the parameters to the experiments. These initial results show that FRtTrace can be an effective tool for allowing victims of denial of service attacks to discover the true attackers despite IP spoofing. While these experiments were conducted on a simple test network representing only a single FRiTrace host, the results would simply scale up to the number of hosts or routers along the attack path that supported iTrace because the probability p to generate an iTrace message is independent of all other hosts or routers along the path. Further, since iTrace messages are sent out of band, there is no interference from downstream routers on previously generated iTrace messages as in the probabilistic packet marking schemes described in an earlier chapter. Because of this, as more routers along the attack path support iTrace, more iTrace messages will be sent to the victim allowing faster path reconstruction and correlation.

REFERENCES Bellovin, S. M., ICMP Traceback Messages, ZETF Internet Draft: draft-ietf-itrace-Ol.txt, October 2000. McCanne, S, and Jacobson, V., The BSD packet filter: a new architecture for user-level packet capture, in Proceedings of the Winter 1993 USENLX Conference, January 1993. Moore, D, Voelker, G. M., and Savage, S. Inferring Internet Denial-of-Service Activity, in Proceedings of the 1 0 ' ~USENLXSectrrity Symposium, August 2001. Savage, S., Wetherall, D., Karlin, A., and Anderson, T., Practical Network Support for IP Traceback, in Proceedings ofACMSZGCOMM, August 2000. Snoeren, A.C., Partridge, C., Sanchez, L.A., Jones, C.E., Tchakountio, F., Kent, S.T., and Strayer, W.T., Hash-Based IP Traceback, in Proceedings of SIGCOMM, August 2001. Song, D.X., and Perrig, A,, Advanced and Authenticated Marking Schemes for IP Traceback, in Proceedings ofIEEE Znjocom, April 2001. Wu, S. F., Zhang, L., Massey, D., and Mankin, A., Intention-Driven ICMP Traceback, ZETF Internet Draft: draft-ietf-itrace-intention-OO.txt, November 2001.

DESIGN AND IMPLEMENTATION OF A HIGHPERFORMANCE NETWORK INTRUSION PREVENTION SYSTEM Konstantinos ini id is', Kostas G. ~ n a ~ n o s t a k i s Evangelos ', P. ~ a r k a t o s '

'institute of

Computer Science, Foundation for Research and Technology Hellas, P . 0 Box 1385 Heraklio, CR-711-10 Greece (xinidis, [email protected] ; '~istributedSystems Laboratory, CIS Department, Univ. of Pennsylvania, 200 S. 33"' Street, Philadelphia, PA 19104 anannost @dsl.cis.upenrz.edu

Abstract:

Network intrusion prevention systems provide proactive defense against security threats by detecting and blocking attack-related traffic. This task can be highly complex, and therefore, software-based network intrusion prevention systems have difficulty in handling high speed links. This paper describes the design and implementation of a high-performance network intrusion prevention system that combines the use of software-based network intrusion prevention sensors and a network processor board. The network processor acts as a customized load balancing splitter that cooperates with a set of modified content-based network intrusion detection sensors in processing network traffic. We show that the components of such a system, if co-designed, can achieve high performance, while minimizing redundant processing and communication. We have implemented the system using low-cost, off-theshelf technology: an IXP1200 network processor evaluation board and commodity PCs. Our evaluation shows that our enhancements can reduce the processing load of the sensors by at least 45% resulting in a system that can handle a fully-loaded Gigabit Ethernet link using at most four commodity PCs.

Key words:

Network Intrusion Detection Systems, Network Intrusion Prevention Systems, network processors, load balancing

1.

INTRODUCTION

The increasing importance of network infrastructure and services along with the high cost and difficulty of designing and enforcing end-system security policies has resulted in growing interest in complementary,

360

Konstantinos Xinidis, Kostas G. Anagnostakis.. .

network-level security mechanisms, as provided by firewalls and network intrusian detection and prevention systems. High-performance firewalls are rather easy to scale up to current edgenetwork speeds because their operation involves relatively simple operations such as matching a set of Access Control List-type policy rules against fixed-size packet headers. Unlike firewalls, network intrusion prevention systems (NIPSes) are significantly more complex and, as a result, are lagging behind routers and firewalls in the technology curve. The complexity stems mainly from the need to analyze not just headers but also packet content and higher-level protocols. Moreover, the function of NIPSes needs to be updated with new detection components and heuristics, due to the continuously evolving nature of network attacks. Both complexity and the need for flexibility make it hard to design highperformance NIPSes. Application-Specific Integrated Circuits (ASICs) lack the needed flexibility while software-based systems are inherently limited in terms of performance. One design that offers both flexibility and performance is the use of multiple software-based systems behind a hardware-based load balancer. Although such a design can scale up to edgenetwork speeds, it still requires significant resources, in terms of the number of sensors, required rack-space, etc. It is therefore important to consider ways of improving the performance of such systems. This paper explores the role that high-speed network processors (NPs) can play in scaling up network intrusion prevention systems. We focus on ways for exploiting the performance and programmability of NPs for boosting in-line network intrusion detection. We describe the architecture of a NIPS using commodity Personal Computers (PCs) as network intrusion detection sensors, fed by an 1 ~ ~ 1 2 0network 0~ processor. We present the allocation of operations to components and the trade-offs we faced during designing and prototyping the system. For further details please refer to 20. The rest of this paper is organized as follows. In Section 2 we describe the architecture and implementation of our system, called Digenis''. In Section 3 we examine the performance benefits of using NP-based load balancing and acceleration. We discuss work that is related to highperformance intrusion prevention in Section 4. Finally, we summarize and comment on future research directions in Section 5.

l5

Digenis Akritas, the ideal medieval Greek hero, is a bold warrior of the Euphrates frontier. He was a proficient warrior by the age of three and spent the rest of his life defending the Byzantine Empire from frontier invaders.

Design and Implementation of a High-Performance Network.. .

2.

DESIGN AND IMPLEMENTATION

We faced a number of design challenges in constructing Digenis with respect to performance, flexibility and scalability: Performance: The primary metric of interest in the design of a NIPS is throughput. That is, to be able to operate at network speeds of at least 1 Gbitls without packet losses, so as to detect any attempted attack. Therefore, the system must be capable of analyzing all the incoming traffic under the most stringent conditions. Network intrusion detection systems (NIDSes) based on commodity PCs are able to monitor at speeds much lower than l ~ b i t / s This ~ ~ ~ necessitates . the use of a distributed design with several intrusion detection sensors operating in parallel and supported by a load balancing traffic litter^'"''^. At the same time, we want to minimize cost and use as few resources as possible. The use of an NP implementing the splitter appears reasonable, since it is likely to be cheaper than a custom ASIC, while load balancing operations seem to be well within the processing capacity of modern NPs. We also want to minimize the number of sensors needed. A key focus of our work is therefore on how to exploit the processing capacity on the NP to reduce the load of the sensors. A second important performance goal is minimizing the latency induced by the NIPS. There is a direct relationship between latency introduced by a networking device and the maximum throughput of TCP flows16. If the NIPS will be used at the boundary between an enterprise network and the Internet, latencies in the order of a few milliseconds may be tolerable. If the NIPS is deployed internally, and the network needs to support high-bandwidth local services (such as file sharing, etc.) the latency requirements are even more stringent. Particularly, there is a critical value for the round trip time (RTT) of a packet in each network. If the latency is below this critical value, TCP throughput is unaffected -- it is the line speed of the underlying network which becomes the bottleneck -- above this critical value, however, TCP throughput is negatively impacted. The critical value for RTT in a network supporting Gigabit speeds is 0.5 milliseconds. Thus, if we want the throughput of TCP to be unaffected, we must ensure that the latency imposed by our NIPS is less than 0.5 milliseconds. However, Gigabit Ethernet links will rarely carry only a single TCP connection. Rather, a Gigabit Ethernet link supports hundreds, if not thousands of TCP connections, and this multiplexing mitigates the impact of latency on the overall throughput of the linkg. In other words, it is possible

Ih

Recall that TCP Throughput=Window/R?T where Window is the maximum TCP window size (default value is 64 Kbytes) and R7T is the round trip time in the network.

Konstantinos Xinidis, Kostas G. Anagnostakis..

Figure I. Architecture of Digenis.

to impose latency greater than 0.5 milliseconds without affecting the throughput of a link due to the high number of TCP connections.

Flexibility and Scalability: A NIPS needs to be flexible and scalable, both for scaling up to higher link speeds and more expensive detection functions, as well as for updating the detection heuristics. If the protection of a faster link or a more fine-grained detection is required, it would be desirable to reuse as much as possible of the existing hardware. Clearly, this property does not hold for ASIC-based NIPSes. However, it is remarkable that almost all NIPS providers ignore this Furthermore, a prerequisite of flexibility is simplicity as extending a complex system may be hard and error-prone. It is therefore desirable for the hard-to-program elements of our system to be as generic as possible.

2.1

Architecture

Digenis is composed of a customized load balancing splitter and a number of content-based network intrusion detection sensors connected with the splitter (Figure 1). The splitter is the entry and exit point of the traffic that runs through the system. The basic task of the splitter is to evenly distribute the traffic across the sensors and to transmit the non-attack packets back to their destination. The sensors are responsible for the heavy task of inspecting the traffic for intrusion attempts. They maintain the required information for recognizing all the malicious traffic and deciding whether to forward or drop the packet. For every input packet, the splitter computes which sensor will be responsible to analyze this packet. Then, it forwards the packet to this sensor for inspection. The sensor searches for known attack patterns contained in the packet. If a pattern is found, then the packet is blocked, otherwise the packet is forwarded back to the splitter. The splitter receives the analyzed packet and transmits it to its destination.


363

Additionally, Digenis supports plug-ins that implement operations necessary to improve the performance of the system. A plug-in has two parts, one running on the splitter and one running on the sensors. These two parts cooperate in order to accomplish their task. In the context of this work we have designed a plug-in for Digenis that attempts to minimize the cost of sending a packet from a sensor to the splitter.

Splitter: The functionality of the splitter can be divided into the basic operations and the plug-ins that provide adequate operations to boost performance. The basic part of the splitter integrates the functionality of a load balancer -- it is responsible for distributing the incoming traffic across the output interfaces (ports). However, it differs from a common load balancer in that it must be flow-preserving, that is, all the packets belonging to the same flow1' must be forwarded to the same output interface. Regarding load balancing, there are two possible approaches that we could use: stateful load balancing that requires from the system to hold state ~ , ' ~experiences ~'~ greater load imbalances. and hash-based load b a ~ a n c i n ~ that For the purposes of this paper, we assume that load imbalances are tolerable and use the simpler hash-based method. The input of the hash function is composed of the source and destination IP addresses of the packet. Sensor: A sensor is a commodity PC that runs a modified popular NIDS and is connected with the splitter (through an Ethernet connection). A sensor receives traffic from the splitter and analyzes it for possible known attacks. In case that an attack is found, it notifies the splitter to block the offending packet(s), otherwise it informs the splitter that the packet(s) should be forwarded. A sensor maintains state about the traffic it analyzes in order to operate correctly. The maintained state includes the active TCP connections it has captured in the near past, TCP connections tagged as offending, fragmented packets and statistics about the connections per second to TCPLJDP destination ports. 2.1.1

Reducing Redundant Packet Transmission

We have designed a plug-in for Digenis that is responsible for reducing redundant packet transmission on the system. The idea behind this plug-in is the following: Suppose that the splitter stores temporarily (for a few

l7

In case of T C P N D P traffic, we define a flow to consist of all the traffic of a TCP or UDP connection. Otherwise, a flow consists of all the traffic originating from a particular IP address and destined to a particular IP address.

364

Konstantinos Xinidis, Kostas G. Anagnostakis.. ,

milliseconds) the packets that it forwards to the sensors for analysis. Then there is no need for the sensors to send back to the splitter the analyzed packet, but only a unique identifier of that packet (PID). Because the splitter has previously stored the packet with this PID, it can infer the referenced packet and forward it to the appropriate destination. The only extra work for the splitter is to tag each packet with a PID, which is a trivial task. Although the additional processing cost to the splitter from this plug-in is minimal, the reduction to the load of the sensors is remarkable. However, this technique requires from the splitter to be equipped with additional memory for the buffering of the packets. As we will present in Section 3, the memory requirements are easily satisfied by modern NPs. Subsequently, we discuss how a sensor communicates the packet information back to the splitter.

Communication between Splitter-Sensor: The splitter communicates with the sensors in order to decide the action that should be performed, that is, forward or drop the packet. This is done with acknowledgments (ACKs) from the sensors to the splitter. An ACK is an ordinary Ethernet packet. It consists of an Ethernet header, followed by two bytes denoting the number of packets acknowledged (ACK factor) and followed by a set of four-byte integers representing the PIDs. There are other possible formats requiring less bytes and supporting higher ACK factors for this configuration. However, this approach is more scalable. There are several options regarding the information that these packets should contain. The sensors may send back to the splitter the following responses: 1 . Positive ACKs: an ACK for every packet not related to any intrusion attempt. 2. Positive cumulative ACKs: an ACK for a set of packets not related to any intrusion attempt. 3. Negative ACKs: an ACK for every packet that belongs to an offending session. 4. Negative cumulative ACKs: an ACK for a set of packets that belong to an attack session. 5. The packet received.

Each of these solutions has its pros and cons. The packet received (PR) scheme, although it has the advantage that it does not require the splitter to temporary hold the packet in memory, it suffers from low performance. In Section 3, we evaluate some of these approaches, with regard to performance. Among positive and negative cumulative ACKs (CACKs) we have chosen the former ones. Negative CACKs have two major drawbacks: First, in order to be able to distinguish when a packet must be forwarded, we


365

have to wse a timeout value. Recall that, our NIPS must not drop any packet or an attack might be missed. As a result, we would be forced to choose a timeout for the worst case scenario. The side-effect is that packets will experience a high latency. Second, it is impossible for the splitter to differentiate the case where the analyzed packet contained no intrusion from the case where the packet was dropped due to an error condition. We have chosen positive CACKs (P-CACKs) because they supersede positive ACKs.

2.2

Implementation

We have implemented Digenis using low-cost, off-the-shelf technology: an Intel IXP1200 Ethernet evaluation board and commodity PCs.

Splitter: We have implemented the splitter using an IXP1200 network processor. The IXP1200 chip contains six micro-engines with four hardware threads (contexts) each. Also, this chip has a general-purpose StrongARM processor core, a FIFO Bus Interface (FBI) unit and buses for off-chip memories (SRAM and SDRAM). The maximum addressable SRAM and SDRAM memory are 8 Mbytes and 256 Mbytes respectively. The FBI unit interfaces the IXP1200 chip with the media access control (MAC) units through the IX bus. The FBI also contains a hash unit that can take 48-bit or 64-bit data and produce a 48- or 64-bit hash index. In our evaluation board, an IXF440 MAC unit (with eight Fast Ethernet interfaces) and an IXF1002 MAC unit (with two Gigabit Ethernet interfaces) are connected to the IX bus. We have developed the application using micro-engine assembly language. The assignment of threads to tasks is done as follows: we assign eight threads for the receive part of the Gigabit Ethernet interface, one thread for the receive part of each of the eight Fast Ethernet interfaces, four threads for the transmit part of the eight Fast Ethernet interfaces, and four threads for the transmit part of the Gigabit Ethernet interface. For the implementation of hash-based load balancing, we use the hash unit of the IXP1200. Also, for the temporary storage of the incoming packets until they are acknowledged we use a circular buffer which resides in SDRAM memory. This circular buffer must be large enough to prevent overwriting packets before their matching ACK is received. Sensor: The functionality of the sensor has been implemented by modifying the popular NIDS Snort version 2.0.2'~.The functionality of the sensor can be divided into three different phases: (1) the protocol decoding phase, (2) the detection phase, and (3) the prevention phase. In the first phase, the raw packet stream is separated into connections representing end-


366

to-end activity of hosts. A connection, in case of IP traffic, can be identified by the source and destination IP addresses, transport protocol and UDPlTCP ports. Then, a number of protocol-based operations are applied to these connections. The protocol handling ranges from network layer to application layer protocols. Some of the operations applied by the protocol-based handling are IP defragmentation, TCP stream reconstruction and identification of the URI in HTTP requests. The second phase consists of the actual detection. Here, the packet (or an equivalent higher-level protocol data unit) is checked against a database of detection heuristics representing attack patterns. Then follows the prevention phase. The action of this phase depends on the result of the previous one. If no attack is found, the sensor informs the splitter to forward the packets. If malicious activity is observed, then the prevention engine blocks the suspicious traffic by informing the splitter to not forward the packets belonging to the offending connection(s).

Extra Implementations: In addition to our splitter, for comparison purposes, we have implemented the following three configurations on the IXPI 200: A forwarder (FWD) that transmits the traffic arriving at an input Gigabit Ethernet interface to an output Gigabit Ethernet interface. A load balancer (LB) that implements a flow-preserving load balancer with the same load-balancing characteristics as our splitter. The IXP1200 receives traffic from a Gigabit Ethernet interface and transmits the traffic to eight Fast Ethernet interfaces. The last configuration (LB + FWD) implements the basic functionality of our splitter (without optimizations).

3.

EVALUATION

In this Section we examine the performance of our architecture. We focus on the impact of our enhancements to sensor-splitter communication. In particular, we compare the performance of P-CACK vs, the PR scheme. We also show that such techniques can be efficiently supported by current network processors and that they do not significantly impair forwarding latency.

3.1

Experimental Environment

Splitter: The performance of the configurations running on the IXPI200 is measured using the IXP1200 Developer Workbench (version 2.0la)'. Specifically, we use the transactor provided by Intel. The transactor is a


367

cycle-accurate architectural model of the IXP1200 hardware. We simulate the configurations as they would run on a real IXP1200 chip. We assume a clock frequency of 232 MHz and a 64-bit IX bus with a clock frequency of 104 MHz.

Sensor: We use a 2.66 GHz Pentium IV Xeon processor with hyperthreading disabled. The PC has 512 Mbytes of DDR DRAM memory at 266 MHz. The PC1 bus is 64-bit wide clocked at 66 MHz. The host operating system is Linux (kernel version 2.4.20, Red-Hat 9.0). The Gigabit Ethernet r~. network interface is an Intel PRO11000 MT Dual Port Server ~ d a ~ t eThe sensor software is a modified Snort version 2.0.2, compiled with gcc version 3.2.2. We turn off all preprocessing in Snort. Unless noted otherwise, Snort is configured with the default rule-set. Packet Traces: For the evaluation of Digenis we use three packet traces. The FORTH-WEB trace was captured at ICS-FORTH and only contains HTTP traffic. The FORTH.LAN trace was also captured at ICS-FORTH and contains traffic from an internal Local Area Network (LAN). Both traces contain the real payload of the packets. The IDEVAL traces are taken from MIT Lincoln Laboratory and were used in the 1999 DARPA Intrusion Detection valuation'^.

3.2

Results

3.2.1

Performance of the Splitter

All the IXPI200 configurations described in Section 2 (LB, FWD, our splitter, and LB+FWD) handle at most the IP and UDPITCP header of the incoming packets. Thus, we argue that the most demanding traffic for these configurations is the traffic consisting of a high percentage of small packets, namely 64-byte packets''. We simulate the above configurations and the results show that all the configurations are capable of sustaining line speed even with traffic consisting of only 64-byte packets'? This is expected as the theoretical forwarding capacity of the IXPI200 chip is greater than 1600 ~bit/s~. While all the configurations sustain line speeds, we use as a metric for comparison the utilization of the micro-engines and the utilization of SRAM

l8

This is the smallest possible packet in an Ethernet link including the 4-byte Ethernet CRC. The splitter uses P-CACK scheme with a factor of eight.


368

and SDRAM memoriesz0.These are some of the resources that may become the bottleneck, considering that the IXP1200 specification states that the maximum IX bus throughput is 6 Gbit/s. In Figure 2 we present the average utilization of the micro-engines and the utilization of the SRAM and SDRAM memories for the described configurations. We observe that our approach is efficient and does not consume all the resources of the IXP1200, leaving headroom for even more offloading of the sensors. Particularly, the results suggest that the extra cost of the splitter compared to the load balancer is affordablez1. 35

3 30

3

25

B 20

$

15

g

10

-

5

Packet Size (bytes)

Packet Sire (bytes)

Packet Size (hyies)

Figure 2. Utilization of the IXP1200 micro-engines, SDRAM and SRAM memories for different packet sizes. It is obvious that the splitter configuration does not consume all the resources of the IXP1200.

3.2.2

Performance of the Sensor

We first measure the processing cost of a sensor for different coordination schemes using the default rule-set. In this experiment Snort simply reads traffic from a packet tracez2,performs all the necessary NIPS functionality, and then transmits the coordination messages to a hypothetical splitter through a Gigabit Ethernet interface. Figure 3, shows the time that Snort spends to process all the packets for the FORTH.WEB trace including user and system time breakdown. The results show that the higher the PCACK factor, the less the total running time for Snort. The running time is practically the same with the unmodified Snort for P-CACK with factor equal to 128. Also, Snort finished 45% faster for P-CACK with factor equal

More accurately, we measure the utilization of the buses of SRAM and SDRAM memories. We have to mention that the increased utilization of the micro-engines in the case of the splitter configuration is caused by the instrumentation code we add to measure the performance of the splitter. While in the other configurations we do not add code for evaluation purposes, we are obliged to do so in the case of the splitter. 22 We confirm that the hard disk is not the bottleneck by measuring the throughput of the hard disk and the transmit rate of Snort. As expected, the transmit rate of Snort is smaller than the throughput of the disk.

20

2'


369

to 128 compared to the PR scheme. Moreover, we observe that the system time is lower than the user time. This confirms the fact that Snort spends most of its processing time in header and content matching which is counted in user time. We also observe (Figures 3 and 4) that the improvement of the P-CACK scheme compared to the PR scheme depends very much on the trace used: the P-CACK scheme is from 45% to 3.8 times more efficient than the PR scheme. The reason is that the improvement depends on the detection load of the sensor. The smaller the detection load, the bigger the relative improvement. This becomes clearer if we determine where the improvement is coming from. The improvement stems from the fact that the P-CACK scheme reduces the overhead required for sending a packet to the network (system time in Figures 3 and 4). If the detection engine of a sensor is overloaded, then this overhead is a small fraction of the total workload of the sensor and reducing it does not lead to much improvement. In contrast, if the detection engine of a sensor is lightly loaded, this overhead consumes a significant fraction of the total workload of the sensor and reducing it results in a more notable improvement. For example, if the traffic is rulesetintensive, then the detection load of the sensor increases and the relative improvement is small. On the other hand, for traffic that requires fewer rules to be checked for every packet, the detection load of the sensor will be minimal and the improvement will be greater. 50

4ol n n

User Tlme System Tlme

Coordination Scheme

Figure 3. Processing cost of a sensor (time to process all packets in a trace), with user and system time breakdown (FORTH.WEB trace). We observe that the P-CACK scheme with factor 256 is 45% more efficient than the PR scheme.

User Time System Time

Coordination Scheme

Figure 4. Processing cost of a sensor (time to process all packets in a trace), with user and system time breakdown (IDEVAL trace). We observe that the P-CACK scheme with factor 256 is 3.8 times more efficient than the PR scheme.

Konstantinos Xinidis, Kostas G. Anagnostakis.. .

370

We also repeat the experiment on a PC with a slower Pentium I11 processor at 1.13 GHz and the same PC1 bus characteristics and Ethernet network interfaces. The results (Figure 5) show that the improvement is smaller compared to the faster machine. When we examine more carefully the results, we observe that while user time doubles, the system time increases only by 30%. This happens because user time is mainly the time spent for content search and header matching, which are processor intensive tasks. On the contrary, system time is dominated by the time spent for copying the packet from main memory, over the PC1 bus, to the output network interface, handling interrupts and control registers of the Ethernet device. As the speed of processors increases faster than the speed of PC1 buses and DRAM memories, we can argue that, as technology evolves, the effect of our enhancements will be even more pronounced - common processors are already running at 3.8 GHz, so the previously reported improvement is in fact a conservative result. User Time System Time

:

300 -

.

User Tme System Tme

" ,,

u

1003

o

Coordination Scheme

Figure 5. Processing cost of a slower sensor (FORTH.WEB trace). We can see that the improvement is smaller compared to the faster sensor.

i Number of Rules

Figure 6. Performance of a sensor using incremental number of synthetic rules. We notice that as the number of rules increases the improvement of P-CACK scheme versus PR scheme decreases.

Table 1. Synthetic rule example.

alert tcp any any -+any any (ack: 1; flags: S; content: "RPC overflow"; )

All the above experiments are performed using the default rule-set of Snort. To further understand the correlation between the detection load of a sensor and the P-CACK scheme improvement we also experiment with variable, synthetic rule-sets. An example rule is shown in Table 1. Similarly

Design and Implementation of a High-Performance Network. ..

37 1

to the previous experiment, Snort reads traffic from a packet trace and sends packets over a Gigabit Ethernet interface. The results are shown in Figure 6. We observe that as the number of rules increases the improvement of PCACK scheme versus PR scheme decreases. In other words, as detection load increases, improvement decreases. Another interesting point is that the maximum relative improvement of PCACK over PR is for small packets of 64 bytes. Small packets require less time for content matching user time and communication system time is the dominant cost factor. In addition, in the case of 64-byte packets, the bottleneck is not the processor, as in the case of larger packets, but the PC1 bus. This is clearly shown in the experiments involving the IDEVAL traces (Figure 4), which contain many small packets for emulating certain types of attacks such as SYN flooding. For this trace, the P-CACK scheme is 3 times more efficient compared to the PR scheme. This is also a nice side effect of the P-CACK scheme, in that it makes the NIPS more robust against TCP SYN flood attacks, given that such attacks consist of a big fraction of small packets. 260 240 220 200 3 180 8 160 I140 n 120 100 80 60 40 20 0

-

2

P-CACK 16 P-CACK 128 P-CACK 256

4 6 8 101214161820 Forwardmg Latency (mlll~seconds

Figure 7. Maximum Loss Free Rate (MLFR) of a sensor using default rule-set.

3.2.3

Figure 8. CDF for latency of a sensor. We notice that latency increases with the PCACK factor.

Forwarding Latency of the Sensor

The highest portion of the latency imposed by our NIPS is due to content matching on the sensors. This happens due to the fact that content matching is the single most expensive operation in every NIPS. To measure forwarding latency, we use two hosts A and B with two Gigabit Ethernet network interfaces each, ethO and ethl. We connect the two interfaces of host A with the two interfaces of host B back-to-back. Everything that host A sends to network interface ethO/ethl is received by host B on network interface ethO/ethl, and vice versa. Host A reads a trace from a file and sends

372

Konstantinos Xinidis, Kostas G. Anagnostakis. .

traffic to host B (using tcpreplayl).Host B runs Snort, which receives packets from interface ethO and sends replies to interface ethl. Host A matches the packet transmission time with the arrival time of the reply and computes the latency. Initially, we estimate the maximum loss free rate (MLFR) of a sensor by replaying a packet trace and measuring the rate at which the sensor started dropping packets (Figure 7). In this experiment we set the input packet buffer size to 16 Mbytes. We use MLFR to compute the latency that a sensor imposes to analyzed packets when reaching its processing capacity. In this experiment, host A replays FORTH.WEB trace at the maximum loss free rate of each communication scheme. We observe that there are packets that experience very high latency. To understand this phenomenon, we measure the time that Snort spends in content and header matching using the rdtsc17 instruction of the Pentium IV processor. The results show that the peaks in time spent for content and header matching coincide with the peaks in latency. This means that, when the required per packet operations increase, so does the latency. A consequence of this property is that packets that require a significant amount of processing slow down other packets that do not. This is a form of head of line (HOL) blocking. Figure 8 shows the cumulative distribution function (CDF) for all ACK schemes when a sensor receives traffic at the MLFR of FORTH.WEB trace. We notice that latency increases with the P-CACK factor. An interesting observation is that the graph is heavy tailed, meaning that while most of the packets experience low latency, 5% of the packets exhibit very high latency (above 20 milliseconds). These are packets that are received from a sensor while the sensor has a temporary excess load. This may happen because, for example, some packets require too many rules to be checked. If too many such packets are received back-to-back, the system reaches (or exceeds) its capacity and the latency increases considerably.

3.2.4

Forwarding Latency of the Splitter

We argue that the overall latency that a packet experiences by our NIPS is due to the processing of the sensors and not the forwarding of the splitter. Also, the cycles spent by the splitter to forward a packet from the input interface to an output interface depend only on the packet length. This means that practically all packets of the same length experience almost the same latency.

Design and Implementation of a High-Performance Network.. 3.2.5

Memory requirements

There is a direct relationship between latency imported by the sensors and required memory on the splitter. The splitter needs memory to save incoming packets until they are acknowledged by the sensors. The amount of memory the splitter needs depends on the highest possible latency that our NIPS will tolerate. If we set this value in a reasonable value, for example, 200 milliseconds then according to the fact that our NIPS analyzes traffic at 800 Mbith, the required memory is approximately 20 Mbytes. This means that the circular buffer of the IXPl200 must be at least 20 Mbytes. This is a reasonable requirement considering that the maximum addressable SDRAM memory of the IXP1200 is 256 Mbytes.

4.

SUMMARY AND CONCLUDING REMARKS

We have presented the design of Digenis, a high-performance Network Intrusion Prevention System (NIPS). The system consists of a customized load-balancing component built using the IXP1200 Network Processor, and a number of sensors implemented on commodity PCs. In contrast to off-theshelf load balancers used in NIPS products, our design exploits the programmability of NPs to move part of the intrusion prevention functionality from the sensors to the NP. We have focused on one method for boosting system performance by optimizing the coordination between the load balancer and the sensors. The result is a 45% improvement in performance, allowing the system to reach speeds of at least 1 Gbit/s. There are several directions that we are currently pursuing. First, we are re-examining the structure of the sensor software. In particular, we consider the possibility of using a more fine-grained protocol processing model such ~ , we try to move part of the protocol as the one demonstrated by ~ r o ' and processing functionality to the NP. Second, we are looking at ways for building a 10 Gbitls NIPS using third-generation NPs.

ACKNOWLEDGEMENTS This work was supported in part by the IST project SCAMPI (IST-2001-32404) funded by the European Union, the GSRT project EAR (GSRT code: USA-022), and by ESTIA, a PAVET-NE project funded by the Greek General Secretariat of Research and Technology (PAVET-NE code: 04BEN8). Kostas Anagnostakis is also supported in part by ONR under Grant N00014-01-1-0795. Konstantinos Xinidis and E. P. Markatos are also with University of Crete. The work of Kostas Anagnostakis was done while at ICS-FORTH.


REFERENCES 1. 2.

3. 4.

5.

6. 7. 8. 9. 10. 11.

12.

13. 14. 15.

16. 17.

18. 19. 20.

Aaron Turner and Matt Bing. tcpreplay Tool, http://tcpreplay,sourceforge.net. S. Antonatos, K. G. Anagnostakis, and E. P. Markatos. Generating realistic workloads for intrusion detection systems. In Proceedings of the 4th ACM SIGSOFT/SIGMETRICS Workshop on Software and Performance (WOSP 2004), January 2004. Z. Cao, Z.Wang, and E.W. Zegura. Performance of hashing based schemes for internet load balancing. In Proceedings of IEEE Infocom, pp. 323-341, 2000. Y. Charitakis, K. G. Anagnostakis, and E. Markatos. An active splitter architecture for intrusion detection (short paper). In Proceedings of the Tenth IEEEIACM Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems (MASCOTS 2003), October 2003. Y. Charitakis, D. Pnevmatikatos, E. P. Markatos, and K. G. Anagnostakis. Code generation for packet header intrusion analysis on the IXP1200 network processor. In Proceedings of the 7th International Workshop on Software and Compilers for Embedded Systems (SCOPES 2003), September 2003. Intel Corporation. Intel PR0/1000 MT Dual Port Server Adapter. http://www.intel.com. Intel Corporation. Intel IXP1200 Network Processor (white paper), 2000. http:Ndeveloper.inteI.com. Internet Security Systems Inc, http://www.iss.net. Intrusion Prevention Systems Group Test - Edition 1, NSS Group Ltd. http:Nwww.nss.co.uklacatalog/. L. Kencl and J. Y. L. Boudec. Adaptive load sharing for network processors. In Proceedings of IEEE Infocom, June 2002. C. Kruegel, F. Valeur, G. Vigna, and R. Kemmerer. Stateful intrusion detection for high-speed networks. In Proceedings of the IEEE Symposium on Security and Privacy, pp. 285-294, May 2002. R. Lippmann, J.W. Haines, D. J. Fried, J. Korba, and K. Das. The 1999 DARPA off-line intrusion detection evaluation. Computer Networks, 34(4):579-595, October 2000. Network Associates, Inc, http://www.networkassociates.com. V. Paxson. Bro: A system for detecting network intruders in real-time. In Proceedings of the 7th USENIX Security Symposium, January 1998. M. Roesch. Snort: Lightweight intrusion detection for networks. In Proc, of the second USENIX Symposium on Internet Technologies and Systems, November 1999. (Software available from http://www.snort.org). R. Russo, L. Kencl, B. Metzler, and P. Droz. Scalable and adaptive load balancing on IBM Power NP. Technical report, Research Report - IBM Zurich, August 2002. Time-Stamp Counter. http://www.intel.com/design/Xeon~applnots/24161825.pdf. Tippingpoint Technologies Inc. http:Nwww.tippingpoint.com. Top Layer Networks. http://www,toulayer.com. K. Xinidis, K. G. Anagnostakis, and E. P. Markatos. Design and Implementation of a High-Performance Network Intrusion Prevention System. ICS-FORTH Technical Report 333, March 2004.

STRIDE: POLYMORPHIC SLED DETECTION THROUGH INSTRUCTION SEQUENCE ANALYSIS P. ~ k r i t i d i s 'E. , P. ~ a r k a t o s ' M. , ~ o l ~ c h r o n a k i sand ' , K. ~ n a ~ n o s t a k i s ~ '~nstituteof Computer Science Foundation for Research and Technology Hellas, P.O. Box 1385 Heraklio, GR-711-10 Greece, (akritid, markatos, mikepo] @ics.forth.gr '~istributedSystems Laboratory, CIS Department, Univ. of Pennsylvania, 200 S. 33'" Street, Phila, PA 19104, [email protected]

Abstract:

Despite considerable effort, buffer overflow attacks remain a major security threat today, especially when coupled with self-propagation mechanisms as in worms and viruses. This paper considers the problem o f designing networklevel mechanisms for detecting polymorphic instances o f such attacks. The starting point for our work is the observation that many buffer overflow attacks require a "sled" component to transfer control o f the system to the exploit code. While previous work has shown that it is possible to detect certain types o f sleds, including obfuscated instances, this paper demonstrates that the proposed detection heuristics can be thwarted by more elaborate sled obfuscation techniques. T o address this problem, we have designed a new sled detection heuristic, called STRIDE, that offersthree main improvements over previous work: it detects several types o f sleds that other techniques are blind to, has a lower rate o f false positives, and is significantly more computationally efficient, and hence more suitable for use at the networklevel.

Keywords:

security; intrusion detection; bufferoverflow detection.

1.

INTRODUCTION

Buffer overflow attacks, popularized in 1996 by Aleph one1,have been a major security concern ever since, because exploiting a buffer overflow vulnerability allows an attacker located anywhere on the Internet to execute arbitrary code on the compromised system. The highly interconnected

P.Akritidis, E. P. Markatos, M. Polychronakis.. address o f code

argument 2

attack

shellcode

l o c a l var.

2

vulnerable buffer

environment of theP1nternet currently creates tremendous exploitation Figure 1. Anatomy of a stack-based buffer overflow attack. By overflowing the buffer, the return address can be overwritten with a value pointing somewhere within the sled. The flow of control will be transferred to the start of the shellcode from any location in the sled.

opportunities. In fact, such vulnerabilities in networked services are currently the main means used for propagation of Internet worms. A tutorial on buffer overflow attacks was provided by Aleph One in 1996'. A buffer overflow attack takes advantage of insufficient bounds checking on a buffer located on the stack to overflow the buffer and overwrite the return address of the currently executing function. Figure 1 shows the typical layout of the stack both before (left) as well as after the buffer ovefflow attack (middle and right). The attack involves injecting data into the buffer which resides in the lower addresses of the stack. The amount of data injected is larger than the buffer size and the resulting overflow overwrites at least the local variables, the saved ebp, and the r e t u r n address,resulting in the stack shown in Figure 1 (middle). The return address is hijacked to point to malicious code that is injected by the attacker, usually within the same overflowed buffer, illustrated as the shaded area in Figure 1 (middle). Besides stack-based buffer overflow attacks, it is also possible (although, perhaps more difficult) to engineer similar attacks on heap-based and statically-allocated buffers. Despite considerable efforts in end-system preventive measure^^-^, adoption of these techniques is proceeding at an alarmingly slow pace. Dealing with this threat therefore requires additional perimeter defense mechanisms, as provided by firewalls and network intrusion detection systems. However, obfuscation techniques make it hard to apply simple rulebased detection techniques as currently used in network intrusion detection. Buffer ovefflows often have features that can be seen as a weakness that can be exploited by detection heuristics. A key observation is that, although the location of the injected code relative to the start of the buffer is known to

STRIDE: Polymorphic Sled Detection through Instruction Sequence

. ..

377

the attacker, the absolute address, which represents the start of the injected code, is only approximately known because the location of the start of the buffer relative to the start of the stack varies between systems, even for the same executable program. To overcome the lack of exact knowledge on where to divert control, the attacker needs to append the malicious code fragment to a sequence of NOP instructions, typically around a few hundred bytes long. The overwritten return address always transfers control somewhere inside this sequence, and thus, after sliding through the NOP instructions, control will eventually reach the worm code. Due to the sliding metaphor, this sequence is usually called a sled. The exact location within the sled where execution will start does not matter: as long as the return address causes the system to jump anywhere within the sled, it will always reach the core of the exploit. To detect buffer overflows, Network Intrusion Detection Systems (NIDSes) rely on signatures, characteristic strings, and regular expressions, such as code sequences included in an attack's shellcode that can identify the attack. However, obfuscation similar to polymorphism9"0, used in viruses since the early 90s, renders signature-based techniques for zero-day worm Polymorphism usually encrypts the shellcode with a detection obsolete11212. different random key each time and prepends it with a decryption routine. When the malicious program starts executing, the decryption routine will execute first, which in turn will decrypt the shellcode, which will then start executing. Since the decryption routine itself cannot be encrypted, some systems base their zero-day worm detection on detecting the decryption routine itself. Unfortunately, decryption routines are usually obfuscated using metamorphism. Metamorphism substitutes (sequences of) instructions with equivalent (sequences of) instructions, making the decryption routine difficult to fingerprint. Metamorphism is also used to obfuscate sleds, by, for example, substituting NOP instructions, with other equivalent instruction sequences. Many existing detection mechanisms have also focused on detecting the sled component in order to detect buffer overflow attacks. For example, signatures to match simple sleds have been included in the shellcode rule set of the Snort NIDS'~. In addition, Snort has been extended with the Fnord plugin'4 that searches for obfuscated sleds. Finally, Toth and Kruegel proposed the Abstract Payload Execution (APE) method15 which further improves the sensitivity of obfuscated sled detection. The rest of the paper is organized as follows. First, in Section 2 we present a classification of obfuscated sleds, and in Section 3 we discuss some existing detection techniques. Then, in Section 4 we propose STRIDE, a novel detection mechanism. In Section 5 we evaluate the detection mechanisms using generated attacks and real network traces, and in Section

378

P.Akritidis, E. P. Markatos, M. Polychronakis..

6 we discuss limitations of sled detection in general and of STRIDE in particular. Finally, we conclude in Section 7.

CLASSIFICATION OF SLEDS The sled is a sequence of instructions responsible for directing the flow of control towards the core code of a buffer overflow attack. Although execution of the sled can start at any position, it always ends up "sliding" inside the core code of the attack. There are many different ways for a sled to achieve its functionality. In this section, we present several types of sleds in order of increasing (perceived) difficulty to detect.

2.1

Simple NOP Sled

The simplest sled consists of a series of NOP (no-operation) instructions. A NOP instruction has no effect on program behavior: it simply advances the program counter. Execution of the sled may start at any position, and the NOPs are used to transfer control, step by step, to the shellcode right after the sled. This simple sled has been demonstrated in the buffer overflow examples of1 and has been used in many other attacks.

2.2

One-byte NOP-equivalents Sled

A NOP sled can be easily obfuscated by replacing literal NOP instructions with one-byte instructions which have no significant effect, and, for the purposes of the attacker, are practically equivalent to NOPs. For example, instructions that increase or decrease a register which is not used by the attacker, instructions that set or clear a flag, and instructions that push or pop a register, can all be used in a sled instead of NOPs. Current polymorphic buffer overflow attack generators use such sleds to avoid detection. The mutate'^ engine uses this technique with a list of of 55 one-byte NOP-equivalent instructions. The Metasploit ~ramework" extends the ADMmutate engine with 3 additional single-byte NOP replacements. We have enumerated 66 such instructions in the Intel IA-32 architecture1'. Although not yet seen in the wild, obfuscated sleds are readily available to attackers.


5c

40

2s

35

<no lOi35,

05

96

68 O E

23

37

. ..

379

shellcode

111

-

ror IOrbl0ll02r, I e a r ."b

IOxlo, I., ,nc

zs.r add $0121910c68,

Zllr

--

push IOrJ7249bO1 0,

IOXPb,

I.,

'wait

a n d 90x37.

i s

ea*

Figure 2. An example of a small sled, executable at every byte offset, which is constructed by interleaving one-byte and multi-byte NOP-equivalent instructions.

2.3

Multi-byte NOP-equivalents Sled

A straightforward extension to one-byte NOP-equivalent sleds is to use multi-byte NOP-equivalent instructions, which, like their one-byte counterparts, simply advance the program counter in order to reach the core of the exploit. However, it is not possible to use any multi-byte NOP equivalent instruction available in the instruction set, because a sled must be executable at every offset. Therefore, a straightforward way to generate multi-byte NOP-equivalents sleds is to restrict the operands of multi-byte instructions to correspond only to the opcodes of one-byte NOP-equivalent instructions, or to the opcodes of multi-byte NOP-equivalents. Consider for example the multi-byte NOP-equivalents sled shown in Figure 2. If control is transferred to the leftmost byte, it will execute instructions cmp , a l ,add SOx249bOc68, %eax,etc. Note $ 0 ~ 3 5% , a l ,sub $ 0 ~ 4 0% that the first argument of the first instruction cmp $Ox35 , %a1, is 0x3 5, which corresponds to the opcode of instruction xor. Therefore, if control is transferred to the penultimate byte from the left, it will execute instructions xor, or, and, etc. leading to the end of the sled. This is true for all instructions in this type of sleds: their arguments are such that if control is transferred to any byte inside the sled, the execution will eventually lead to the end of the sled.

2.4

Four-byte Aligned Sled

Although traditional NOP sleds had to be executable at each and every byte, stack alignment can relax this restriction by constraining the possible placements of the vulnerable buffer. The default behavior of modern compilers is to align the stack at word (4-byte) boundaries19. ~eference" discusses the possibility of exploiting stack alignment to construct sleds that have to be executable every 4 bytes. Pairs of non-destructive 2-byte instructions can be used as NOP-equivalents, but it is also possible to use

380


e2

08 e b

06

eb

-

04

d4

5e

l c

fd

ohellcode

L o o p 0x08

or

ICh,

Ibl

in0 0x06

Figure 3. (a) The ideal trampoline-sled: flow of control is directed to the shellcode in a single step from any position in the sled. (b) An example of a small trampoline-sled that is executable at every byte offset. Control transfer instructions are placed at every second byte and their relative address operand is chosen so that it is a valid NOP-equivalent opcode.

longer instructions with techniques similar to the multi-byte instruction sled discussed earlier. Code sequences starting at non-word-aligned offsets may contain any kind of instruction, including instructions with destructive side-effects or even illegal ones, which can hinder detection.

2.5

Trampoline Sled

Although typical sleds transfer control to the shellcode by sliding it along their body-hence the name sled-, the same functionality can be achieved by jumping directly to the shellcode, as illustrated in Figure 3(a). The body of such a sled consists of control transfer instructions with relative addresses, all pointing directly to the shellcode. Thus, the flow of control will reach the shellcode in a single step from any point it may have entered the sled. Trampoline-sleds can be directly implemented, relying on four-byte alignment, by cramming a jump instruction together with its operands into every four-byte-long slot of the sled. Even if a trampoline-sled has to be executable at every offset, an attacker can carefully choose the operands of the jump instructions to be valid NOP-equivalent opcodes, as explained in Section 2.3. An example of a small trampoline-sled that is executable at every byte offset is illustrated in Figure 3(b). The shortest control transfer instructions available are two bytes long. For example, instructions such as j m p and l o o p take a one-byte operand that specifies the relative address of the jump target. The use of two-byte control transfer instructions places an additional restriction on the maximum jump displacement that can be used for sleds executable at each byte. Generally, the operand of these instructions is encoded as a signed 8-bit immediate value, which allows for a maximum forward relative offset of 127 bytes. Additionally, since the operand must at the same time act as a one-


. ..

38 1

byte NOP-equivalent instruction, the maximum jump displacement is further reduced to the NOP-equivalent opcode with the greater signed integer value that is less than 128. The two NOP replacements with the largest such opcodes that we have come across are push imm8 and push imm32, which result to an offset of 106 and 104 bytes, respectively. Trampoline sleds are still feasible, though, by solely using jumps with relatively large positive displacements, which result to forward execution "bounces". Thus, the flow of control "jumps" and "strides" towards the shellcode.

2.6

Obfuscated Trampoline-sled

Since the number of control transfer instructions that can be used for the construction of trampoline-sleds is limited, one could argue that such sleds can be detected by searching for the specific opcodes of these instructions, much in the same way that Fnord does for NOP-equivalents (cf. Section 3.2). The entropy of the basic trampoline-sled can be increased in order to evade detection, by interleaving NOP-equivalent instructions along with the jump instructions. In this way, the shellcode is not reached in a single step, but in a number of steps which can be tuned by the attacker. This will result to a sparse distribution of the control transfer instructions, which renders simple detection methods ineffective.

2.7

Static Analysis Resistant Sleds

Sleds of this type attempt to evade detection by making it difficult for detection heuristics to statically infer the outcome of the execution of the sled. When the sled is actually executed, its behavior is that intended by the attacker, correctly leading to the shellcode. This can be achieved by either using branches whose target cannot be determined statically or by using selfmodifying code. Static analysis cannot follow branches that cannot be determined statically, such as register or memory indirect jumps, because the contents of the registers or memory are not known during the analysis. Therefore, it cannot continue with the inspection of the corresponding code paths and cannot determine their outcome. Such jumps, however, must specify the target as an absolute address. Also, a sled could modify itself so that invalid instructions, appearing under static analysis to terminate a code path, are overwritten during execution by previous instructions and are actually executed normally. However, the sled must rely on stack alignment to avoid the execution of illegal instructions before they are fixed-up. Again, like indirect branches, write operations require an absolute address.

P.Akritidis, E. P. Markatos, M. Polychronakis.. .

382

To overcome the absolute address problem, present in both indirect branches and self-modifying instructions, the esp register, which holds the stack frame's absolute address, can be used to find the buffer and sled addresses. However, the use of the esp register could hint for static analysis resistant sleds, but, in fact, the absolute address of the sled can be found even without using this register: knowing the injected return address and maintaining a counter while sliding through the sled provides knowledge of the absolute address of the current sled position. This seems to be relatively hard to implement, especially considering the need for 4-byte alignment.

Table 1. Comparative effectiveness of various sled detection schemes.

Sled Type 1. NOP instructions 2. One-byte NOP-equivalents 3. Multi-byte NOP-equivalents 4. Four-byte Aligned 5. Trampoline-sled 6. Obfuscated Trampoline-sled 7. Static Analysis Resistant

Scheme Snort Yes No No No No No No

Fnord Yes Yes No No No No No

APE Yes Yes Yes Yes No No No

STRIDE Yes Yes Yes Yes Yes Yes After extensionx

SLED DETECTION MECHANISMS

3.

In this section we briefly present three techniques which have been proposed for sled detection: NIDS signatures, the Fnord mutated sled detection plugin, and APE. Table 1 summarizes the effectiveness of each technique, along with our proposed detection mechanism, for each sled type.

3.1

NIDS Signatures

Detecting simple NOP sleds such as those described in section 2.1 is relatively straightforward. On the Intel IA-32 architecture, nop is a singlebyte instruction with opcode 0x90. Thus, to detect a simple sled consisting only of nop instructions, a pattern matching rule searching for a sufficiently

* STRIDE can detect sleds that use indirect jumps, and we discuss how it may be extended to

detect self modifying sleds in Section 6.

STRIDE: Polymorphic Sled Detection through Instruction Sequence .. .

3 83

long sequence of bytes with value 0x90 is enough. Indeed, such rules exist for popular NIDSes, such as snort13.

3.2

Fnord

The ~ n o r d mutated '~ sled detection plugin for Snort detects sleds by searching network traffic for long series of one-byte NOP-equivalent instructions. It is, therefore, capable to detect type-2 sleds, such as those described in Section 2.2. It may be the case that its list of NOP-equivalents could be extended with the opcodes of multi-byte NOP-equivalents, making it capable to detect type-3 sleds such as those described in Section 2.3, but we use the standard version here. However, Fnord definitely fails to detect type4 sleds and above, that exploit the alignment of stack variables. There also exist various other tools that offer similar sled detection capabilities with ~ n o r d ~21.' . Since these tools, along with Fnord, all rely on the NOP-equivalents list contained in ADMmutate in order to detect mutated sleds, it is sufficient to consider just one of them.

3.3

Abstract Payload Execution

APE'^ is a detection mechanism that enables the detection of sleds by looking for sufficiently long series of valid instructions: instructions which decode correctly and whose memory operands are within the address space of the process being protected against attacks. To reduce its runtime execution overhead, APE uses sampling to pick a small number of positions in the data from which it will start abstract execution. The number of successfully executed instructions from each position is called the Maximum Executable Length (MEL). When APE encounters a conditional branch, it follows both branches and considers the longest one as the MEL. If the destination of the branch can not be determined statically, APE terminates execution and uses the MEL value computed so far. A sled is detected if a sequence has a MEL value greater than 35. Although APE can be used to detect sleds of type-1 through type-4, it fails, however, to detect sleds of type-5 (trampoline sleds), type-6 (obfuscated trampoline), and type-7 (staticanalysis-resistant sleds). Indeed, although the purpose of type-5, and type-6 sleds is to transfer program control to the shellcode in as few steps as possible using jump instructions, the mechanism that is used by the APE scheme is based on the detection of a sufficiently long execution sequence of instructions, and thus, trampoline-sleds evade detection by having a short sequence of executed

P.Akritidis, E.P. Markatos, M. Polychronakis.. stride(input, input-size, sled-length) { for (i=O; i < input-size-sled-length; i++) if (find-sled(input+i, sled-length)) return TRUE;

{

return FALSE; find-sled(data, len) ( for ( j = 0; j < 4; j + + ) for (i = j ; i < len; i+=4) if (!valid-sequence(data+i, len-i)) return FALSE ; return TRUE;

1 is-valid-sequence(data,len) { / * decode "len" instructions in buffer "data" * / res = decode(data, len); if (res == VALID-DECODE) return TRUE; if (res == ENDS-IN-JMP) return TRUE; return FALSE; 1

Figure 4. Pseudo-code for STRIDE algorithm

instructions. Static analysis resistant sleds also confuse APE, because it errs on the unsafe side when it cannot decide about a code sequence.

4.

THE STRIDE DETECTION ALGORITHM

In this section we describe STRIDE, our new sled detection mechanism which, compared to previous approaches, is able to detect more types of sleds with less false positives. STRIDE is given some input data, such as a URL, and searches each and every position of the data to find a sled. If a sled is found, the input data are considered part of an attack. To detect a sled spanning over at least n bytes and starting at position i of the input data, STRIDE searches for all sequences of instructions of length n - j bytes starting at offset i j of the input data, for all j E (0...n - 1) . If STRIDE finds all n sequences of instructions to be valid sequences, it then concludes that a sled of length n starts at position i . We call a code sequence, starting at a certain point i in the input data, a "valid sequence of instructions of length n at position i ," if it either (1) decodes correctly for n bytes without encountering privileged instructions, or if (2) a jump instruction is encountered along the way. Informally, a valid sequence of instructions is a sequence of instructions which can be used to construct a sled. Such a sequence may only contain valid instructions, and

+


. ..

385

may not contain privileged instructions, i.e., instructions which can be invoked only by the operating system kernel. Figure 4 gives the pseudo-code for STRIDE. The main routine, stride, consists of a loop which tries to find a sled of length sled-length at each and every position of input data i n p u t . Routine f ind-s led ( data, len) finds a sled by attempting to valid all valid sequences of length leni which start at position data+i,for a1 values of i. Aligned sleds are accounted-for by checking for valid sequences at every four bytes instead of at every byte but the check is applied for all four possible displacements. STRIDE is related to previous approaches in several ways. Like snortI3 and ~ n o r d ' ~STRIDE , is able to find long sequences of NOP(-equivalent) instructions. Like APE'^, STRIDE is able to decode the input data and identify sequences of instructions that may be part of a sled. However, STRIDE has two major differences from APE: Table 2. Detection rate of the various detection schemes for traces containing 10,000 different generated sleds of a single type.

Sled Type in Trace NOP instructions One-byte NOP-equivalents Multi-byte NOP-equivalents Four-byte Aligned Trampoline-sled Obfuscated Trampoline-sled

Scheme Snort

Fnord

APE

STRIDE

100% 0% 0% 0% 0% 0%

100% 55.4% 0%

100% 100% 100% 100% 0% Fig. 5

100% 100% 100% 100% 100% 100%

0% 0% 0%

APE detects a sled when it finds a sufficiently long execution sequence of instructions. Therefore, although it is able to detect NOP-based sleds, APE can not detect trampoline sleds, because they jump directly to their destination code and, therefore, do not exhibit long execution sequences. In contrast, STRIDE may consider even short execution sequences (such as a single jump instruction) to be part of a valid sled. STRIDE verifies that each and every byte of a sled (apart from the cases of word-aligned sleds) is the start of a valid sequence of instructions. On the contrary, for APE it is enough to find only one sufficiently long execution sequence to consider it a valid sled.


386

5.

EXPERIMENTAL EVALUATION

We evaluate the accuracy of the detection rate of our proposed algorithm STRIDE, Snort's shellcode signatures13,Fnord mutated sled detection plugin for snort14, and APE, by generating 10,000 different sleds of each type using the Metasploit Framework v2.217, modified to generate sleds ranging from type-1 (simple NOP sleds) up to type-6 (obfuscated trampoline). We also evaluate the false positives rate of the four methods as in15, by applying them to HTTP URIs. The URIs were captured from our institution's LAN, which contains about 150 hosts. Sled detection methods which are based on instruction decoding, employ the decoder used in22.

5.1

Detection Rate

The results of applying all four detection methods on the generated sleds are shown in Table 2. We observe that Snort's shellcode signatures detect simple NOP sleds with 100% success, but fail to detect more elaborate sleds. Fnord is able to detect simple NOP sleds with 100% success too, and in addition is able to detect sleds with one-byte NOP-equivalent instructions with a 55.4% rate. Although it could have achieved a 100% rate for one-byte NOP-equivalent sleds, it achieves a lower-rate due to an incomplete NOPequivalent instruction list. Fnord also fails to detect sleds with multi-byte NOP-equivalent instructions, but it should be possible to update its list of NOP-equivalents to include them as well. However, this is as far as Fnord can get. Indeed, Table 2 shows that Fnord fails to detect sophisticated sleds, such as 4-byte aligned and trampoline sleds. Table 2 suggests that the APE method is able to detect simple NOP sleds, sleds with one-byte and multi-byte NOP-equivalent instructions, as well as four-byte aligned sleds with a 100% success rate. However, APE cannot detect trampoline sleds. This was expected, because trampoline sleds reach the core attack code by executing only a small number of jump instructions, while APE bases its detection method on the sequential execution of a long sequence of instructions. It is interesting, however, to point out that although APE can not detect trampoline sleds, it is able to detect some of the more difficult obfuscated trampoline sleds. Indeed, as Figure 5 shows, APE is able to detect as many as 6% of the obfuscated trampoline sleds for small MEL. This is because the NOP-equivalent instructions that are used for the obfuscation cause an increase of the overall execution steps of the sled, which can now reach a Finally, STRIDE is able to detect simple NOP sleds, sleds with one-byte or multi-byte NOP-equivalent instructions, as well as four-byte aligned sleds and plain or obfuscated trampoline sleds with 100% success, as expected.

STRIDE: Polymorphic Sled Detection through Instruction Sequence . ..

387

low MEL threshold. Nevertheless, the detection rate of APE is still very low, at 6%, even for the minimum suggested MEL value. 7

APE -Obfuscated Trampol~neSled

-

+ STRIDE

APE

-

x fnord 0

MEL (Number of instructions)

Figure 5. Detection rate for APE when applied to obfuscated sleds as a function of MEL.

5.1

Signatures

False Positives (%)

Figure 6. Comparative effectiveness of the various detection schemes. The results for APE are for a MEL value of 35 with 100 samples per kilobyte and for STRIDE for sled length 130 bytes.

False Positives

The results of the false positives rate evaluation for the four methods with real traces are shown in Figure 6. In this experiment STRIDE has a sled length parameter of 130 bytes and APE has a MEL value of 35 instructions with 100 samples per kilobyte. With these parameters APE is sensitive, like STRIDE, to sled lengths of about 130 bytes and above. The Snort shellcode signatures have zero false positives, because there was no sufficiently long NOP-sequence in our traces. Fnord also has almost 0% false positives, because there were very few sequences of bytes in the traces which corresponded to sequences of NOP-equivalent instructions. Although both Snort and Fnord have an attractive practically 0% of false positives rate, they are severely limited in their ability to detect elaborate sleds, such as trampoline sleds. Figure 6 shows that APE has a false positive rate of 0.006%. Finally, STRIDE has a false positive rate of 0.00027%, close to an order of magnitude smaller than APE. Overall, we see that STRIDE seems to strike a good balance between true positives and false positives. That is, it is able to find more true positives than any other method, while keeping the false positives as low as those of Fnord and Snort. The interested reader should notice that the exact value of false positives for APE and STRIDE depends heavily on their parameters. To explore the influence of the parameters to the false positive rate of APE and STRIDE,

P.Akritidis, E.P. Markatos, M. Polychronakis....

388 0.014

APE

-

MELThreshold (number of sled instructions)

0.014

STRIDE

Sled Length (Bytes)

Figure 7. False positives rate for APE and STRIDE with varying parameters.

we investigate the false positives rate for both methods as a function of MEL and sled length, and display the results in Figure 7. We see that as the size of MEL increases, the percentage of false positives for APE decreases. However, we should point out that larger MEL values also decrease the number of detected true positives, as can be seen in Figure 5. Figure 7 also shows that the percentage of false positives for STRIDE decreases with the sled length, and reaches zero for sled length larger than 230 bytes. This is an encouraging result, since typical sleds are usually longer than 250 bytes. Overall, our results suggest that STRIDE is able to have a true positive rate of 100% (Table 2), while having a false positive rate of (close to) 0%.

5.2

PERFORMANCE

Besides being accurate, a worm detection method should also be fast, so as to be able to detect worms in real-time. To evaluate the speed of STRIDE we measured the CPU time consumed by STRIDE with a sled length value of 200 bytes, and compared it to the execution time of APE with a MEL count of 35 on a Pentium 4 machine (2.6GHz clock speed, 512KB cache size) for a trace with 1,093,249 requests. The CPU time for processing this trace was 25 sec for APE (22.9 usec per request) and 4.85 sec for STRIDE (4.4 usec per request). We see that STRIDE outperforms APE by a factor of 5. This is mostly due to the different handling of branch instructions by the two algorithms. Indeed, when APE encounters a branch instruction, whose target can be determined statically it follows both branches, a decision, which may potentially lead to the exploration of an exponential number of execution paths. Unlike APE, when STRIDE encounters a branch instruction, it assumes that it found a valid sequence, without making any

STRIDE: Polymorphic Sled Detection through Instruction Sequence . ..

389

attempt to follow the branch. By being conservative, STRIDE avoids the exponential explosion and significantly reduces the associated run-time cost.

DISCUSSION Although our evaluation has shown that STRIDE has some benefits, we should mention that it still has limitations. For example, STRIDE can only be applied to buffer-overflow-based attacks which use sleds. If an attack does not make use of a sled, then it can not be detected by STRIDE. In addition, STRIDE still cannot detect self-modifying sleds. It is, however, possible, to extend it with a decoder that is capable of identifying memory write operations and handle the sequences that contain them the way it currently handles jump instructions: consider them valid, because they cannot be proved invalid with static analysis. Finally, a worm writer could blind STRIDE by adding invalid instruction sequences at suitable locations in the sled. Note that this would most likely lead to a fraction of the infection attempts crashing the remote process and would most certainly slow down the spread of the worm, while also exposing it to other detection components that look for anomalous behavior at the process-level.

7.

SUMMARY AND CONCLUDING REMARKS

We have presented STRIDE, a new approach for network-level detection of buffer overflow attacks, which relies on the identification of the sled component that is usually part of such attacks. Because it operates at the network-level, STRIDE can be used for detecting worms that replicate through buffer overflow exploits, even if they involve elaborate obfuscation. Our analysis allows us to make three main observations: STRIDE can detect several classes of sleds that cannot be identified by previous proposals. As presented in Section 2.5, trampoline sleds can be used by attackers in order to evade current sled-based detection mechanisms. STRIDE detects such sleds, even in their obfuscated variations. STRIDE achieves high detection rates while maintaining low false positive rates. Snort and Fnord have few false positives but can only detect basic sled types. APE detects more complex sleds, but has an order of magnitude more false positives compared to STRIDE, while also missing two classes of sleds. Our approach can detect all types of sleds presented in this paper, except for Static Analysis Resistant sleds, with a detection rate of 100%, and a false positive rate that reaches 0% for

390

P.Akritidis, E. P. Markatos, M. Polychronakis.. .

reasonable algorithm parameters. As suggested in Section 6, it may also be possible to detect Static Analysis Resistant sleds. This question, however, requires additional analysis and is outside the scope of this paper. STRIDE is more efficient in terms of processing cost. As shown in Table 3, STRIDE has relatively low computational cost, outperforming APE by a factor of 5. This suggests that STRIDE can operate on high-speed links and remain effective even under heavy loads, at a reasonable cost. The high accuracy, low false positive rate, and low processing cost achieved by STRIDE suggest that it is likely to be highly useful as part of an automated network-level defense mechanism against both targeted attacks and large-scale zero-day worm outbreaks, especially as worms become more aggressive and more sophisticated.

ACKNOWLEDGEMENTS This work was supported in part by the IST project NOAH (01 1923) funded by the European Union and the GSRT project EAR (USA-022) funded by the Greek Secretariat for Research and Technology. The work of K. Anagnostakis is also supported by OSDIONR CWSW URI through ONR Grant N00014-04-1-0725. P. Akritidis, E. P. Markatos, and M. Polychronakis are also with the University of Crete. The work of K. Anagnostakis was done while at ICS-FORTH.

REFERENCES 1. Aleph One. Smashing the stack for fun and profit. Phrack, 7(49), Nov. 1996. http://www. phrack.org/phrack/49/P49- 14. 2. A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of USENIX Annual Technical Conference, June 2000. 3. C. Cowan, M. Barringer, S. Beattie, and G. Kroah-Hartman. Formatguard: Automatic protection from printf format string vulnerabilities. In Proceedings of the 10th USENIX Security Symposium, August 2001. 4. J. J. C. Cowan, S. Beattie and P. Wagle. PointGuard: Protecting pointers from buffer overflow vulnerabilities. In Proceedings of the 12th USENIX Security Symposium, August 2003. 5 . C. Cowan, C. Pu, D. Maier, M. Hinton, J. Walpole, P. Bakke, S. Beattie, A. Grier, P. Wagle, and Q. Zhang. Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks. In Proc. of the 7th USENIX Security Symposium, January 1998. 6. M. Frantzen and M. Shuey. StackGhost: Hardware facilitated stack protection. In Proceedings of the 10th USENIX Security Symposium, August 2001.

STRIDE: Polymorphic Sled Detection through Instruction Sequence .. . 7.

8. 9.

39 1

I. Goldberg, D. Wagner, R. Thomas, and E. A. Brewer. A Secure Environment for Untrusted Helper Applications: Confining the Wily Hacker. In Proc, of the 5th USENIX Security Symposium, 1996. V. Kiriansky, D. Bruening, and S. Amarasinghe. Secure execution via program sheperding. In Proceedings of the 1lth USENIX Security Symposium, 2002. T. Detristan, T. Ulenspiegel, Y. Malcom, and M. Underduk. Polymorphic shellcode engine using spectrum analysis. Phrack, 11(61), Aug. 2003. http://www.phrack.org/

phrack/6l/p61-0x09~Polymorphic~Shellcode~Engine.txt. 10. C. Nachenberg. Understanding and managing polymorphic viruses. White Paper, July 1996. http://www.symantec.com/avcenter/reference/striker.pdf. 11. 0 . Kolesnikov, D. Dagon, and W. Lee. Advanced polymorphic worms: Evading IDS by blending in with normal traffic, 2004, http://www.cc.gatech.edu/aok/w/ok~pw.pdf. 12. P. Szor and P. Ferrie. Hunting for metamorphic. White Paper, Sept. 2001. http://www. symantec,com/avcenter/referencelhunting.for.metamorphic.pdf. 13. M. Roesch. Snort: Lightweight intrusion detection for networks. In Proceedings of USENIX LISA 99, Nov. 1999. (software available from http://www.snort.org/). 14. D. Ruiu. Fnord: Multi-architecture mutated NOP sled detector, Feb. 2002. http://www.

~~~~~~~~~~~~~~~~~~fn0rd.c. 15. T. Toth and C. Kruegel. Accurate buffer overflow detection via abstract payload execution. In Proceedings of the 5th International Symposium on Recent Advances in Intrusion Detection (RAID), Oct. 2002. 16. K2. ADMmutate. http://www.ktwo.ca~ADMmutate-0.8.4.tar.g~. 17. Metasploit project, 2004, http:Nwww.metasploit.com/. 18. IA-32 Intel Architecture Software Developer's Manual vol. 1-3. http://developer.intel. com/designl pentium4/manuals/index-new.htm. 19. K. S. Gatlin. Windows data alignment on IPF, x86, and x86-64, Feb. 2003. MSDN Library, http://msdn.microsoft.com/. 20. Prelude IDS, http://www.prelude-ids.org/. 21. NIDSFindShellcode. http:Nwww.ngsec.com/downloads/misc/NIDSfindshellcode.tgz. 22. T. Toth. Apache buffer overflow detector module, Mar. 2002. http://www.infosys.tuwien. ac.at/Staff/tt/abstract-execution/.

PIRANHA: FAST AND MEMORY-EFFICIENT PATTERN MATCHING FOR INTRUSION DETECTION S. Antonatosl, M. ~ o l ~ c h r o n a k i sP.' , Akritidis', K.G. Anagnostakis2 and E.P. ~arkatos'

'institute of

Computer Science Foundation for Research and Technology Hellas, P . 0 Box 1385 Heraklio, GR-711-10 Greece {antonat, mikepo, akritid, markatos)@ics.forth.gr; '~istributedSystems Laboratory, CIS Department, Univ, of Pennsylvania, 200 S. 33'" Street, Philadelphia, PA 19104 [email protected]

Abstract:

Network Intrusion Detection Systems (NIDS) provide an important security function to help defend against network attacks. As network speeds and detection workloads increase, it is important for NIDSes to be highly efficient. Most NIDSes need to check for thousands of known attack patterns in every packet, making pattern matching the most expensive part of signature-based NIDSes in terms of processing and memory resources. This paper describes Piranha, a new algorithm for pattern matching tailored specifically for intrusion detection. Piranha is based on the observation that if the rarest substring of a pattern does not appear, then the whole pattern will definitely not match. Our experimental results, based on traces that represent typical NIDS workloads, indicate that Piranha can enhance the performance of a NIDS by 11% to 28% in terms of processing time and by 18% to 73% in terms of memory usage compared to existing NIDS pattern matching algorithms.

Key words:

network security; intrusion detection; pattern matching; network monitoring; network performance.

1.

INTRODUCTION

Network Intrusion Detection Systems (NIDSes) provide a powerful mechanism to defend against well-known attacks on a computer network or detect network abuse. NIDSes are mainly divided into two major categories: signature-based and anomaly detection. Anomaly-detection NIDS try to spot

S. Antonatos, M. Polychronakis, P.Akritidis.. ,

394

abnormal behavior on network based on statistics like rate of connections, traffic overload or unusual protocol headers. On the contrary, the detection mechanism of a signature-based NIDS is based on a set of signatures, each describing a known attack. As an example, a signature taken from latest Snort, is alert tcp any any -> HTTP-SERVER 80 (content:"/root.exe"; nocase;) This signature instructs that if "/root.exe" is found inside the payload of a TCP packet that is originating from any host and any source port and is destined to an HTTP server on port 80, then an attack on the web server is taking place. While this signature requires full packet inspection, there exist simpler signatures that require only header lookups. Pattern matching inflicts a significant cost to the performance of a NIDS. Previous research results suggest that 30% of total processing time is spent on pattern matchingI3, while in some cases, like Web-intensive traffic, this percentage raises up to 8 0 % ~ Apart . from processing time, memory demands of a NIDS may reach at high levels due to rule-set growth. Although algorithms with low memory demands have been developed, their performance in comparison with algorithms that consume more memory is still poor. Given the fact that link speed increases every year, pattern matching evolves to a highly demanding process that needs special consideration. Minimizing the demands of pattern matching leaves headroom for further heuristics to be applied for intrusion detection, like anomaly detection or sophisticated preprocessors. In this paper, we present Piranha, a pattern-matching algorithm designed for and applied to a NIDS. Our experiments with Piranha implemented in Snort v2.2 indicate that Piranha is faster than existing algorithms by up to 28% in terms of processing time, and requires up to 73% less memory. This improvement relies on the small number of collisions and the compact memory footprint of the algorithm. The rest of the paper is organized as follows: in Section 2 a description of existing state-of-the-art algorithms is provided, Section 3 depicts the Piranha algorithm, while Section 4 presents the performance of Piranha compared to other algorithms in various traffic scenarios and hardware platforms. Finally, our concluding remarks are discussed in Section 5.

2.

BACKGROUND

In this section we describe how a content matching NIDS operates and summarize the key characteristics of pattern matching algorithms that have been recently used in intrusion detection.

PIRANHA: Fast and Memory-EfSicient Pattern Matching for .. .

2.1

Basic NIDS model

A NIDS is usually designed as a passive monitoring system that reads packets from a network interface through standard system facilities, such as ~ i b ~ c aAfter ~ ' ~a .set of normalization passes (e.g., IP fragment reassembly, TCP stream reconstruction, etc.) each packet is checked against the NIDS rule-set. Some -rather old- NIDS organize their rule-set as a two-dimensional data-structure chain, where each element, often called a chain header, tests the input packet against a packet header rule. When a packet header rule is matched, the chain header points to a set of signature tests, including payload signatures that trigger the execution of the pattern matching algorithm. Pattern matching is the single most expensive operation of a NIDS in terms of processing cost. Latest versions of Snort (above version 2.0) organize the rules in groups. Rules that check for the same destination port belong to the same group14.When a packet arrives, its destination port is used to find the appropriate group. Afterwards, multi-pattern matching is performed on patterns of the group in order to extract a set of rules that possibly match. Each rule of this set is then examined separately. In order to understand the interaction between pattern matching algorithm, rule-set and experimental workload, we briefly present some of the pattern matching algorithms that are commonly used in intrusion detection systems.

2.2

Pattern matching algorithms

A number of algorithms have been proposed for pattern matching in a NIDS. The performance of each algorithm may vary according to the case in which it is applied. The multi-pattern approach of Boyer-Moore is fast for a few rules, but does not perform well when used for a large set. On the contrary, Wu-Manber behaves perform well when used with large rule-sets. On the contrary, Wu-Manber behaves well on large sets, but its performance starts to degrade when short patterns appear in rules. E2xB is based on the idea that in most cases we have a mismatch and tries to filter out patterns that do not match. However, E2xB introduces additional preprocessing cost per packet, which is amortized only after a certain number of rules. In the following subsections a more detailed description for each algorithm is provided.

2.2.1

The Boyer-Moore algorithm

The most well-known algorithm for matching a single pattern against an ~ . Boyer-Moore algorithm input was proposed by Boyer and ~ o o r e The

S. Antonatos, M. Polychronakis, P.Akritidis.. .

396

compares the search pattern with the input, starting from the rightmost character of the search pattern. This allows the use of two heuristics that may reduce the number of comparisons needed for pattern matching (compared to the naive algorithm). Both heuristics are triggered on a mismatch. The first heuristic, called the bad character heuristic, works as follows: if the mismatching character appears in the search pattern, the search pattern is shifted so that the mismatching character is aligned with the rightmost position at which the mismatching character appears in the search pattern. If the mismatching character does not appear in the search pattern, the search pattern is shifted so that the first character of the pattern is one position past the mismatching character in the input. The second heuristic, called the good suffixes heuristic, is also triggered on a mismatch. If the mismatch occurs in the middle of the search pattern, then there is a non-empty suffix that matches. The heuristic then shifts the search pattern up to the next ol~ the Boyer-Moore occurrence of the suffix in the pattern. ~ o r s ~ oimproved algorithm with a simpler and more efficient implementation that uses only the bad-character heuristic. Fisk and varghese6 recently developed Set-Wise Boyer-Moore (SWBM), an algorithm based on Boyer-Moore concepts and operating on a set of patterns. SWBM was integrated in Snort and tested using a single traffic trace from an enterprise Internet connection. 2.2.2

The E'XB algorithm

E ~ X Bis a pattern matching algorithm designed for providing quick negatives when the search pattern does not exist in the packet payload, assuming a relatively small input size (in the order of packet size)279.As mismatches are by far more common than matches, pattern matching can be enhanced by first testing the input (i.e., the payload of each packet) for missing fixed-size sub-strings of the original signature pattern, called elements. The collisions induced by E ~ X Bi.e., , cases with all fixed-size substrings of the signature pattern showing up in arbitrary positions within the input, can then be separated from the actual matches using standard pattern r e ~small . input assumption matching algorithms, such as ~ o ~ e r - ~ o oThe ensures that the rate of collisions is reasonably small -experiments have shown collision rates of 10% in the worst case-. In the common case, negative responses can be obtained without resorting to general-purpose pattern matching algorithms. The E ~ X B algorithm was evaluated with traffic traces from diverse environments, including traces containing attacks, traces with normal web traffic, and WAN traffic traces from a local ISP.

PIRANHA: Fast and Memory-Efficient Pattern Matching for .. .

2.2.3

The Wu-Manber algorithm

The most recent implementation of Snort uses a simplified variant of the Wu-Manber multi-pattern matching algorithm16, as discussed by Snort d e v e ~ o ~ e r sThe ' ~ . "MWM" algorithm is based on a bad character heuristic similar to Boyer-Moore, but uses a one or two-byte bad shift table constructed by pre-processing all the patterns instead of only one. MWM performs a hash on the two-character prefix of the current input to index into a group of patterns, which are then checked starting from the last character, as in Boyer-Moore. The performance of MWM was originally measured using text files and various sets of patterns. The first attempt to measure MWM as the basic algorithm for pattern matching in a NIDS was performed in recent Snort implementation14.The results of previous studies14 show that Snort is much faster than previous versions that used Set-Wise Boyer-Moore and ~ h o - ~ o r a s i c k ' .

IMPLEMENTATION The Piranha algorithm is based on the idea that if we find the rarest 4byte substring of a pattern inside the packet payload, then we assume that this pattern matches. Each pattern is now represented by its least popular 4byte sequence, where popular reflects the number of times that a specific substring exists in all patterns. For all the instances of the rare substring, Snort is instructed to check the corresponding rule. Piranha itself can only handle patterns with length greater or equal to 4. For completeness, patterns with length less than 4 are handled separately.

3.1

Preprocessing

Piranha treats every byte-aligned pattern as a set of 32-bit sub-patterns. For example, the pattern "/admin,exe" (Rl) is considered as the set of its 32bit byte-aligned sub-patterns, i.e.,"/adm", "admi", "dmin", "min.", "in.e", ' h e x " and ".exeW.The 32-bit partitioning was chosen as the use of integers results to faster operations. Pattern matching can then be formulated in terms of an AND operation. Every pattern is represented by a gate. The gate has as many inputs as the number of its 32-bit sub-patterns. Each input represents whether the 32-bit sub-pattern has appeared in the payload or not. The gate for pattern R1 can be seen on the top-right part of Figure 1 with all its subpatterns constituting the inputs of the gate. Initially, all inputs are set to zero, and are being switched on based on the sequences seen on the packet. However, the output must not be regarded as an exact match.

S. Antonatos, M. Polychronakis, P.Akritidis..

/adm adrni

dmin

.........

........... ..............

min.

adni

-.--................

................

Figure 1. An example of index table and gates for two patterns. When all the inputs of a gate are switched on, then the pattern is possibly matched

For example, if the packet payload is "/admAAAdmin.exe", then, despite the fact that all 4-byte sequences for R1 have appeared, the pattern itself does not match. Each time the output of the gate is switched on, we consider it as collision and Snort is instructed for further inspection. In order to find fast which inputs to switch on, an index table is maintained. The index table keeps for all 4-byte sequences a list of all patterns that contain them. For example, if we assume that we only have the patterns "/admin.exe" (Rl) and "/admin.sh" (R2), a view of the table is displayed in Figure 1. Sequences "/admM,"admi", "dmin", and "rnin." appear in both patterns, while ".exe", "in.e", and "n.ex" exist only in R1, and "in.sWand "n.sh" only in R2. Each time a node of index table is reached then the appropriate input is switched on. As an example, if the payload is "min.exe", we first access the "rnin." entry of index table and we switch on the "rnin." inputs for R1 and R2, afterwards the "in.e" entry and switch on the "in.eWinput for R l , then we access the "n.exe" entry and switch on the input for R l and finally the ",exe" entry is traversed. The performance of Piranha for a subset of our packet traces, in terms of running time and collisions per packet, is displayed in Table 1 under the "full gates" column.

PIRANHA: Fast and Memory-Efficient Pattern Matching for..

match

match

Figure 2. Optimized view of index table

Although gates present a low rate of collisions, their performance is poor as a lot of steps and transitions are needed in order to take a decision whether a pattern matches or not. In a typical case, the index table is firstly accessed, then the appropriate input is switched on and then the whole gate is checked if all inputs are switched on. In our effort to reduce the number of steps, and consequently, memory accesses, an optimization phase takes place. The optimization phase involves the procedure of selecting one input for each gate, a representative sequence. The rarest sequence is chosen as representative. It is defined as the sequence found in the least number of rules and can be found through the index table by counting the number of rules that is contained in. All other inputs are removed from the gate as well as the corresponding nodes from the index table. For example, trying to optimize our previous example we keep sequence "n.exWas representative for pattern R1 and "n.sh" for R2. The optimized view of the index table is illustrated in Figure 2. After the optimization phase, every gate has only one input, and thus, it can totally be removed (output is equal to input), as we can use the index table for the searching phase -if a node of the index table is reached then a possible match is triggered-. The effect of optimization is shown in Table 1, in terms of running time and collisions. The "full gates" column represents the unoptimized case of Piranha, and the "representative sequence" refers to the optimized case. Although collisions per packet increase as now only one input triggers possible match, the performance increases due to decrease of steps and compactness of memory footprint. Performance is increased by up to 36% even if collisions are two to three times more. Table 1. Effect of optimizing gate inputs. Collisions increase but running time decreases as less steps and memory are required Full gates Representative sequence Running time Collisions Running time Collisions


400

With further optimization during the searching phase as it is described in Section 3.2, collisions and running time drop significantly.

3.2

Searching

The searching phase of Piranha is straightforward. For each 4-byte sequence of the packet payload, the index table is consulted in order to find the patterns that contain this sequence. All these patterns are then sent to Snort for further inspection. Following our previous example, if the payload is "/login.sh", we have to check sequences "/log", "logi", "ogin", "gin.", "in.sV and "n.sh". According to the index table, "n.sh" is found in pattern R2, so we assume that R2 is matched. The rest of the sequences are not contained in any pattern so no checks are necessary. Such an approach would trigger further inspection multiple times for each packet, as shown in Table 2 ("No check" case). We observe that, in the average case, in an unoptimized search we trigger one rule per packet, which is prohibitive in terms of performance. In our effort to reduce collisions, we perform a trivial check before the decision that a pattern is matched. The last two characters of the pattern are checked against the corresponding two characters in the payload, and if the check succeeds then further inspection is triggered. The effect of this optimization is summarized in Table 2. In some cases, up to 75% of triggers are eliminated while the minimum reduction reaches 50%.

EXPERIMENTS We evaluated the performance of Piranha against E ~ X Band MWM algorithms in Snort 2.2 using a set of packet traces. All Snort preprocessors were disabled. Table 2. Collisions per packet without and with checking last 2 bytes of pattern against payload No check Check last 2 bytes forth.web 1.65 0.62 forth.tr 0.67 0.24 ideval2 1.06 0.32

PIRANHA: Fast and Memory-Efficient Pattern Matching for.. .

40 1

Figure 3. Effect of hash-table size on running time

4.1

Environment

All the experiments were conducted on a machine equipped with a Pentium 4 processor running at 2.80GHz, 8KB of L1 cache, 512KB of L2 cache, and 1GB of main memory. The host operating system was Linux (kernel version 2.4.0, Redhat 9.0). We used five sets of packet traces from diverse environments. The first set consists of a full packet trace containing Web traffic (forth.web), generated by concurrently running a number of recursive wget requests on popular portal sites from a host within the FORTH network. The second set contains two full packet traces @rth.tr) and forth.tr2) collected in a local area network at Institute of Computer Science inside FORTH. The third set includes a full-packet trace from the DEFCON "capture the flag" data-set (defcon.02). This trace contains numerous intrusion attempts. The fourth set consists of two full-packet traces (ideval2 and ideval3) which were collected during the DARPA evaluation tests at MIT Lincoln Laboratory. Finally, a header-only trace with uniformly random payload (ucnet00) collected on the OC3 link connecting the University of Crete campus network (UCNET) to the Greek academic network (GRNET)' was used.

4.2

Effect of hash-table size

A complete index table of 32-bit-long patterns would normally contain 232entries, an outrageous number in terms of memory usage. In order to keep the memory footprint as small as possible, the index table was implemented as a hash-table. Since the memory footprint and locality of accesses is critical to the performance of the algorithm, we determined the


402

optimal size of the hash-table by obtaining the running time for different sizes and for all available traces.

fonh we0

forlh.li

foilh 112

devai2

idevai3

ddcon 02

defcol 03

lrcrefoo

Traces

Piranha

sl

E2xB

MWM

Figure 4. Running time for E2xB, Piranha and MWM for patterns with length greater or equal to 4

Results are summarized in Figure 1. Running times for each set are presented normalized to the lowest value. The time was measured using the time facility of the operating system. Small hash-tables suffer from conflicts and consequently longer chains have to be traversed in order to find the correct index. A large hash-table, on the contrary, has fewer conflicts but for every access a performance penalty is paid due to poor cache behavior. We observe that optimal size of the hash table for most of the traces is around 16KB and this is the size we used for all our experiments presented in the paper.

4.3

Comparison against other algorithms

on a11 available We compared Piranha against M W M ' ~and traces. In our experiments, we measured running time in user space (kernel time was negligible). Results are presented in Figure 4. Times are presented normalized against the running time of Piranha algorithm. The performance of Piranha is consistently better compared to other algorithms. Improvement ranges between 10 and 23.50%, with the results remaining the same for the rest of the traces that are not displayed in Figure 4. We also compared our algorithm with AC-Banded", an optimized implementation of ~ h o - ~ o r a s i c kbut ' , running time of AC-Banded was two to four times the time of our algorithm. Results in Figure 4 are for patterns with length greater or equal to four, as four is the length that can be natively handled by Piranha. For completeness reasons, the case of small pattern was

PIRANHA: Fast and Memory-Efficient Pattern Matching for . ..

403

also implemented. Small patterns impose a performance bottleneck for . can natively handle patterns with Piranha and MWM as well as E ~ X BMWM length greater or equal to two while patterns with length one are examined separately. The overhead that small patterns impose in terms of running time can be seen on Table 3. In average case, running time was decreased by 25% is smaller as it is not for Piranha and 20% for MWM. The effect on E ~ X B dependent to pattern length but proportional to the number of patterns. In the last two columns of the table we can observe the performance benefit of Piranha against MWM and E ~ X Bfor all pattern lengths. Despite the performance bottleneck, our algorithm still performs better for all available traces, except the case of defcon.02 trace where improvement is marginal. However, our main contribution is focused on patterns with a fair enough large size as only 3% of patterns have length less than four. Piranha does not only perform better in terms of processing time but also in terms of memory usage. While MWM requires 45MB of memory to process the full rule-set, AC-Banded 96MB and Aho-Corasick 140MB, Piranha consumes only 37MB. Efforts have been made recently in order to develop algorithms with low memory consumption. Tuck et alei5;have developed two modified versions of Aho-Corasick, AC-Bitmap and AC-Path, that reduce memory usage. AC-Bitmap needs 20MB memory while AC-Path only 15MB. However, such algorithms present very high processing time. Comparing Piranha with AC-Bitmap and AC-Path, we observed that they need, in average, three to four times more processing time. Snort also comes with SFKSearch, an algorithm that requires only 14MB of memory, but its performance compared to others is poor - three to four times more processing time against Piranha -. The tradeoff between memory usage and processing time can be seen on Figure 5. Algorithms with low memory usage need three to four times more processing time, while algorithms with high memory usage present high processing capacity. Although the assumption that low memory means high processing time cannot be generalized, there are strong indications that this tradeoff might hold for other algorithms that are not discussed here.

4.4

Evaluation on different architectures

We evaluated the performance of Piranha on different hardware architectures. Our testing environment, besides the machine described in Section 4.1, consists of a Pentium Xeon 2.4 GHz with 8KB L1 cache, 5 12KB L2 cache and 5 12MB main memory, an AMD Athlon MP l.8GHz with 128KB L l cache, 256KB L2 cache and 512MB main memory and a Pentium 3 running at 600 MHz with 8KB L1 cache, 256KB L2 cache and Table 3. Effect of small-patterns on running time


404

MWM pattern length

Piranha pattern length

>=4 25.32 30.80 30.23 9.68 11.26 8.99 8.59 3.48

forth.web forth.tr forth.tr2 ideval2 ideval3 defcon.02 defcon.03 ucnetOO

E2xB pattern length

all 33.59 35.65 36.12 12.70 14.58 9.97 9.20 4.21

Piranha vs. MWM

>=4 28.86 29.80 29.91 10.84 12.69 9.42 8.18 3.59

Piranha E'XB

VS.

%

%

10.18 13.66 15.91 10.55 11.59 0.60 5.00 14.72

11.57 1.28 0.29 14.26 15.47 0.50 2.78 5.77

AC-Path SFKSearch D

w

Aho-Corasicl

Mwrn Piranhk

10

30

50

70 90110 150

Memory usage (MB) Figure 5. Memory usage against processing time

512MB main memory. Results are presented in Figure 6. Running time is normalized against the time of Piranha running on P4 at 2.8GHz. Independent of the underlying hardware platform, Piranha performs better for all traces. As processor clock speed decreases, performance of both algorithms decreases as expected. However, the performance gap seems to decrease with the clock speed for specific traces while for others it remains constant. On Pentium Xeon 2.4GHz, improvement waves between 7.8% and 18.8% while on Pentium 3 600MHz between 10.86% and 14.83% (leaving out the ucnetOO trace where improvement is marginal). Similar results apply to the AMD Athlon architecture, where improvement is ranged between 7.32% and 18.21% (again ucnetOO trace is omitted).

PIRANHA: Fast and Memory-Efficient Pattern Matching for. ..

DEiAi3

OEFCONDZ

OEFCON 03

UCNETm

Traces

rn

Piranha I P4 2 8

Flranha i Xeon 2 4

Piranha1 AMD 1800

Figure 6. Performance of Piranha and MWM on different architectures

4.5

Performance under attack

Intrusion detection systems are themselves subject to being attacked. Some types of attack try to evade NIDS by exploiting weaknesses in "~. protocol handling, like IP defragmentation or TCP r e a s s e m b ~ ~ ~Other attacks aim at overloading the detection engines by exploiting weaknesses in the internal algorithms used, in our case pattern matching. The attacker sends packets with carefully crafted payload in order to force the pattern matching engine to spend more processing time than it would require for an innocent packet. Most of the traffic is then dropped by the NIDS, including packets containing attack, giving the attacker the chance to evade detection. Our previous work on such attacks has shown that the processing time of Snort can be raised by up to 25 times3. Although the worst case scenario for each algorithm and the Snort itself is extremely difficult to be generated, we provide some hints on how a NIDS can be heavily overloaded. For performance reasons, Snort firstly performs the multi-pattern matching and then for all possible matches the whole rule is checked: header processing and exact string matching for all patterns that the rule contains14.Examining the groups of rules that are processed during packet inspection, it can be observed that rule

3 any any (ack:O; alert tcp any any content: "AAAAAAAAAAAAAAAA"; depth: 16;)

flags:SFU12;

is found in all groups as it applies to all source and destination ports. That means that for all packets examined, Snort will try to locate the pattern "AAAAAAAAAAAAAAAA" and for all possible matches will check the rest of the rule. In our example, after the pattern matching phase the


406

acknowledgment number and the TCP flags will be verified. We constructed an attack trace by taking the headers of the forth. web and placing only "A" in the payload. In that way, in every offset of the payload Snort finds that pattern and checks for the rest of the rule. However, the header of the packets is normal (no special TCP flags are turned on and acknowledgment number in non-zero) and thus the rule is never matched. Forcing Snort to generate matches and checks in every offset is very expensive as it can be seen on Table 4. We observe that processing time is raised by 3 to 15 times and that all algorithms are subject to payload attacks, as the way Snort performs detection is exploited and not the nature of the algorithms. Such overload factors can provide the attacker the ability to hide his attack among legitimate traffic. Other payloads were also crafted, like payload including only "a". As the packet payload is capitalized, possible matches are also generated and the overloading still takes place. In the case of MWM, running time is increased further as there are some patterns that start with "aa" and trigger more inspections on the internal structures of MWM. The Aho-Corasick-like algorithms try -as an optimization- to verify their match by calling memcmp() for pattern against the payload before forcing Snort to check the whole rule. The cost of memory-comparing is increasingly high as in each offset a comparison is performed. However, there are some cases where a specific payload can cause Piranha to generate collisions in most of the payload offsets but Aho-Corasick-like algorithms are not affected. This payload can be made by replacing the last character of "AAAAAAAAAAAAAAAA" pattern with another character, like "B". Piranha decides that pattern matches only by seeing the appearance of an "AAAA" but the whole pattern is not really matched. Aho-Corasick algorithm detect that the whole pattern cannot be matched so their time remains practically the same. As Table 4 shows, only Piranha and MWM suffer from this payload attack. Focusing on the worst overall performance (the "worst overall" column) among all attacks described above, Piranha needs 3 times less running time than other algorithms. Table 4. Completion time and overhead factor (attack completion time / original completion time) for different attack payloads. "Time" denotes completion time and "factor" denotes overhead factor Packet payload OrigiAAAAA.. . aaaaa. . . AAA.. .B... Worst nil overall

Piranha MWM AC AC-path AC-Bitmap

Time

Time

Factor

Time

Factor

Time

Factor

21.94 25.91 35.71 81.59 72.87

120.01 233.73 417.72 357.84 409.74

5.46 9.02 11.69 4.38 5.62

118.50 376.72 361.45 212.62 241.88

5.40 14.53 10.12 2.60 3.31

91.47 204.88 28.98 78.81 110.65

4.16 7.90 0.81 0.96 1.51

120.01 376.72 417.72 357.84 409.74

PIRANHA: Fast and Memory-Efficient Pattern Matching for . .

5.

CONCLUDING REMARKS

We have presented the design of Piranha, a novel pattern matching algorithm for NIDS and evaluated its performance under various network traffic characteristics using a diverse set of packet traces. Our comparison against existing algorithms shows that an improvement of up to 28% can be achieved. The improvement is due to its quick decisions on which patterns may match and to its compact memory footprint which infers good cache behavior. Our results on different architectures indicate that Piranha performs consistently better, with the performance gain increasing along with processor speed. Furthermore, we have concluded to some general remarks for pattern matching on NIDS: small patterns inflict a significant performance overhead that needs to be examined carefully, and cacheconscious programming of a NIDS pattern-matching algorithm is a key element to its performance.

ACKNOWLEDGEMENTS This work was supported in part by the IST project SCAMPI (IST-200132404) funded by the European Union and in part by the i-Guard GSRT Project (02-PRAXE-212) funded by the Greek General Secretariat for Research and Technology through PRAXE A. Work of K.G. Anagnostakis is also supported in part by ONR under Grant N00014-01-1-0795, E. P. Markatos, S. Antonatos, M. Polychronakis and P. Akritidis are also at University of Crete. Work of K. G. Anagnostakis was done while at ICSFORTH. We would also like to thank Vasilis Siris for providing the UCnet traces.

REFERENCES 1.

2.

Aho and M. Corasick, Fast pattern matching: an aid to bibliographic search. Commun. ACM, 18(6):333-340, June 1975. K. G. Anagnostakis, E. P. Markatos, S. Antonatos, and M. Polychronakis, E2xB: A domain-specific string matching algorithm for intrusion detection. In Proceedings of the 18th IFIP International Information Security Conference (SEC2003), May 2003.

S. Antonatos, M. Polychronakis, P.Akritidis.. . S. Antonatos, K. G. Anagnostakis, and E. P. Markatos, Generating realistic workloads for network intrusion detection systems. SIGSOFT Softw. Eng. Notes, 29(1):207-215.2004. R. Boyer and J. Moore, A fast string searching algorithm. Commun. ACM, 20(10):762-772, October 1977. C. Courcoubetis and V. A. Siris, Measurement and analysis of real network traffic. In Proceedings of the 7th Hellenic Conference on Informatics (HC1199), August 1999. M. Fisk and G. Varghese, An analysis of fast string matching applied to content-based forwarding and intrusion detection, Technical Report CS2001-0670 (updated version), University of California - San Diego, 2002. M. Handley, V. Paxson, and C. Kreibich, Network intrusion detection: Evasion, traffic normalization, and End-to-End protocol semantics, In Proceedings of USENIX Security Symposium, pages 115-134,2001. R. Horspool, Practical fast searching in strings. Software - Practice and Experience, 10(6):501-506, 1980. E. P. Markatos, S. Antonatos, M. Polychronakis, and K. G. Anagnostakis, ExB: Exclusion-based signature matching for intrusion detection, In Proceedings of CCN'02, November 2002. S. McCanne, C. Leres, and V. Jacobson, libpcap. Lawrence Berkeley Laboratory, Berkeley, CA, available via anonymous ftp to ftp.ee.lbl.gov. M. Norton, Optimizing Pattem Matching for Intrusion Detection, July 2004. http://docs.idsresearch.org/ 0ptimizingPattemMatchingForIDS.pdf. T. H. Ptacek and T. N. Newsham, Insertion, evasion, and denial of service: Eluding network intrusion detection, Technical report, Secure Networks, Inc., Jan. 1998. M. Roesch, Snort: Lightweight intrusion detection for networks. In Proceedings of the 1999 USENIX LISA Systems Administration Conference, November 1999. http:Nwww.snort.org/. Sourcefire, Snort 2.0 - Detection Revisited. October 2002. http://www.snort.org/ docs/Snort-2OPv4.pdf. N. Tuck, T. Sherwood, B. Calder, and G. Varghese, Deterministic memory-efficient string matching algorithms for intrusion detection, In Proceedings of the IEEE Infocom Conference, March 2004. S. Wu and U. Manber, A fast algorithm for multipattern searching, Technical Report TR-94-17, University of Arizona, 1994.

DESIGNATED-VERIFIER PROXY SIGNATURE SCHEMES

Guilin Wang Instititzre for Injbcomm Research (12~) 21 Heng Mui Keng Terrace, Singapore 119613 [email protected]~sg

Abstract:

In a proxy signature scheme, a user delegates hidher signing capability to another user in such a way that the latter can sign messages on behalf of the former. In this paper, we first propose a provably secure proxy signature scheme, which is based on a two-party Schnorr signature scheme. Then, we extend this basic scheme into designated-verifier proxy signatures (DVPS). More specifically, we get two versions of DVPS: weak DVPS and strong DVPS. In both versions, the validity of a proxy signature can be checked only by the designated verifier. In a weak DVPS scheme, however, the designated verifier can further convert such proxy signatures into public verifiable ones, while a strong DVPS scheme does not have the same property even if the designated verifier's secret key is revealed willingly or unwillingly. In addition, we briefly discuss some potential applications for DVPS.

Keywords:

proxy signature, digital signature, information security.

INTRODUCTION Proxy Signatures. In a proxy signature scheme, one user Alice, called original signer, delegates her signing capability to another user Bob, called proxy signer. After that, the proxy signer Bob can sign messages on behalf of the original signer Alice. Upon receiving a proxy signature on some message, a verifier can validate its correctness according to a given verification procedure, and further be convinced of the original signer's agreement on the signed message. Proxy signature schemes have been

410

Guilin Wang

suggested for use in a number of applications, including electronic commerce, mobile agents, and distributed shared object systems etc [15, 4, 281. Most existing proxy signature schemes are constructed in the following way. The original signer Alice sends a specific message and the corresponding signature to the proxy signer Bob, who then uses this information to derive a proxy secret key. With this secret key, Bob can produce proxy signatures by employing a specified standard signature scheme. When a proxy signature is given, a verifier first recovers the proxy public key from some public information, and then checks its validity according to the corresponding standard signature verification procedure. Mambo et al. firstly introduced the concept of proxy signatures and proposed several constructions in [17,18]. After that, a number of new schemes and improvements have been proposed 14, 14-16, 291; however, most of them do not fully meet the desired security requirements (see Section 2.2). In [14], IGm et al. introduced the concept of partial delegation by warrant, and proposed a threshold proxy signature, in which the original signer's signing ability is shared among a delegated group of n proxy singers such that only t or more of them can generate proxy signatures cooperatively. Lee et al. [15] constructed mobile agents for e-commerce applications from non-designated proxy signature, in which a warrant does not specify the identity of a proxy signer so any possible proxy signer may respond this delegation and become a proxy signer. Furthermore, Lee et al. [16] investigated whether a secure channel for delivery of a signed warrant is necessary in existing schemes. Their results show that if secure channels are not provided, the M U 0 scheme [17] and the LKK scheme 1151 all are insecure. To avoid the usage of secure channels and overcome some other weaknesses, they proposed new improvements. However, Wang et al. [28] showed that all of those schemes and improvements proposed in [15-161 are insecure by demonstrating several kinds of attacks. Boldyreva et al. [4] presented the formal model and security notion for proxy signature, i.e., the existential unforgeablity against adaptive chosen-message attacks [lo]. Designated-Verifier Signatures. In 1996, Jakobsson et al. introduced a new primitive called designated-veriJier proofs [13]. Such proofs enable a prover Alice to convince a designated verifier Bob that a statement is true. However, Bob cannot use such proofs to convince a third party of this fact. The reason is that Bob himself can simulate such proofs. Here is their basic idea. When Alice wants to convince only the designated verifier Bob a statement 0 , she actually proves the statement "0 is true or I knows Bob's secret key". Upon receiving such a proof, Bob is convinced that the statement O must be true, since he knows that this proof is not generated by

Designated- Verzfier Proxy Signature Schemes

41 1

himself and that his secret key is not compromised. However, a third party cannot accept the statement O from such a proof since this proof may be generated by Bob even if O is false. Furthermore, Jakobsson et al. proposed an elegant non-interactive designated-verifier proof for Chaum's zeroknowledge undeniable signature scheme [7] to avoid blackmailing [9, 121 and mafia attacks [8]. In other words, they introduced a designated-veriJier signature scheme in the sense that only the designated verifier can be convinced that a signature is issued by the claimed signer. However, Wang [27] pointed out this scheme is insecure since a dishonest signer can cheat a designated verifier easily. Note that in Jakobsson et a1.k scheme any verifier can validate a signature though he does not know whether this signature is produced by the signer or simulated by the designated verifier. In [22], however, Saeednia et al. recently proposed a strong designated-verzfier signature scheme in the sense that without the knowledge of the designated verifier's secret key, any third party cannot check the validity of such signatures. Compared with Jakobsson et al.'s scheme, their scheme is very efficient in both respects of communications and computation. In addition, Steinfeld et al. introduced a new type of signature scheme called z~niversaldesignated-veriJier signature (UDVS) [25, 261. Such a scheme enables any holder of a signature (not necessarily the signer) to designate the signature to a third party as the designated-verifier.

Our Work. As mentioned above, Wang et al. [28] demonstrated several attacks on several DLP-based proxy signature schemes. Those attacks mainly result from the fact that a valid proxy key pair can be forged by an adversary, including the original signer and the proxy signer. However, Wang et al. did not provide improvements to avoid such attacks. In this paper, we first propose a new proxy signature scheme, which is based on the two-party Schnorr signature scheme proposed by Nicolosi et al. [20]. The new scheme is provably secure and as efficient as the schemes in [15-16,4]. Then, by combining the ideas of proxy signatures and designated-verifier signatures, we extend this basic scheme to designated-verifier proxy signatures (DVPS for short). More specifically, we get two versions of DVPS: weak DVPS and strong DVPS. In both versions, the validity of a proxy signature can be checked only by the designated proxy signer. In a weak DVPS scheme, however, the designated verifier can further convert such proxy signatures into public verifiable ones, while a strong DVPS scheme does not have the same property even if the designated verifier's secret key is revealed willingly or unwillingly. In addition, we briefly discuss some potential applications for DVPS in electronic commerce settings.

412

Guilin Wang

Structure. The rest of this paper is organized as follows. Section 2 introduces the computational assumptions, security requirements for proxy signature schemes, and notations. We introduce the new (basic) proxy signature scheme in Section 3, and then extend this scheme into designatedverifier proxy signatures (DVPS) in Sections 4. Finally, Section 5 concludes the paper and points out future work.

2.

PRELIMINARIES

2.1

Assumptions

We review the following computational assumptions that are related to the security of our proxy signature schemes constructed in this paper. Assumption 1: Discrete Logarithm (DL) assumption. Let G,= be a cyclic multiplicative group generated by g of order q. Then, on inputs ( g , g XE ) G,2 where x~ Z , is a random (zmknown) nzmber, there is no probabilistic polynomial-time (PPT) algorithm that outputs the value of x with non-negligible probability. Assumption 2: Computational Diffie-Hellman (CDH) assumption. Let G,= be a cyclic muItiplicative group generated by g of order q. Then, on inputs ( g , g X , g ' )E G; where x, y E Z , are random (unknown) numbers, there is no PPT algorithm that outputs the value of gyYwith non-negligible probability. Assumption 3: Decisional Diffie-Hellman (DDH) assumption. Let G,= be a cyclic multiplicative group generated by g of order q. Then, on inputs ( g , g " , g ? , g Z E ) G,4 where x, y , z ~2, are random (unknown) numbers, there is no PPT ulgorithm that distinguishes with non-negligible probabili@ whether g'?' andgz are eqzral. Those computational assumptions are widely believed to be true for many cyclic groups, such as the multiplicative subgroup G,= of the finite field Z,, where p is a large prime and q is a prime factor of p-1. In practice, lpl=1024 and lql=160 are considered to be suitable for most current security applications. More discussions on those assumptions can be found in [5,2].

Designated-Verijier Proxy Signature Schemes

2.2

Definitions

Definition 1. A proxy signature scheme is usually comprised of the following procedures: Setup: On input of a security parameter I, this probabilistic algorithm outputs two secretlpublic key pairs (xA,yA) and (xB,yB) for the original signer Alice and the proxy signer Bob. Note that those key pairs may be used in a standard signature scheme at the same time. Proxy Key Pair Generation: The original signer Alice and the proxy signer Bob execute this interactive randomized algorithm to generate a proxy key pair (xp,yp) for Bob, such that only Bob knows the value of xp, while yp is public or publicly recoverable. Proxy Signature Generation: The proxy signer Bob runs this (possibly probabilistic) algorithm to generate a proxy signature o for a message m by using the proxy secret key xp. Proxy Signature Verification: A verifier runs this deterministic algorithm to check whether an alleged proxy signature o for a message m is valid with respect to a specific original signer and a proxy signer. The security requirements for proxy signature are first specified in [l7,18], and later are kept almost the same besides being enhanced in [I 51, and formalized in [4]. Definition 2. A secure proxy signature scheme should satisfy the following requirements: Verifiability: From the proxy signature, a verifier can be convinced of the original signer's agreement on the signed message. Identifiability: Anyone can determine the identities of the corresponding original signer and proxy signer from a proxy signature. Unforgeability: Only the designated proxy signer can create a valid proxy signature on behalf of the original signer. In other words, the original signer and other third parties who are not designated as proxy signers cannot create a valid proxy signature. Undeniability: Once a proxy signer creates a valid proxy signature on behalf of an original signer, he cannot repudiate the signature creation against anyone else. Prevention of misuse: The proxy signer cannot use the proxy secret key for purposes other than generating valid proxy signatures. In case of misuse, the responsibility of the proxy signer should be determined explicitly.

Guilin Wang

2.3

Notations

Throughout this paper, p and q are two large primes such that ql@-1) and G,= is a q-order multiplicative subgroup of 2; generated by an element g E ZJ, . The discrete logarithm problem in G, is assumed to be difficult. Hereafter, we call three such integers (p, q, g) a DLP-triple. Let h( ) and h'( ) be two secure cryptographic hash functions. In addition, we suppose that the original signer Alice and the proxy signer Bob possess modp), respeccertz3ed key pairs (x,, y, = gx.tmodp) and (x,, y, = gyB tively. Here, a certified key pair (xA,y,) means that Alice knows the private key x~ and has to prove her knowledge of xA when she registers her public key certificate with a certificate authority (CA). Actually, this is a recommended practice for issuing public key certificates [1,19], and can be used to prevent rogue-key attacks [4]. In addition, we denote by m,, the warrant which specifies the delegation period, what kind of message m is delegated, and the identities of the original signer and the proxy signer, etc.

3.

BASIC PROXY SIGNATURE SCHEME

In this section, we propose a new proxy signature scheme. The basic idea is that the provably secure two-party Schnorr signature scheme proposed in [20] is used to generate a proxy key pair (xp, yp) such that

where rp is a public value, and m,,is a warrant which specifies the related information about a proxy delegation. In fact, (rp, xp) is exactly a two-party Schnorr signature on message m,. The point is that (a) only Bob knows the value of xp, and (b) a valid tuple (rp, xp) can only be generated by Alice and Bob jointly. Therefore, xp can be used as the proxy secret key to generate proxy signatures according to a standard DLP-based signature scheme. At the same time, a verifier can validate such proxy signatures after recovering the public proxy key yp from Eq. (1). In the following description of our scheme, it is assumed that Alice and Bob have agreed on a warrant m,,before generating a proxy key pair for Bob. In addition, as pointed in [20], the hash function h '( ) can be replaced by any secure commitment scheme.

Proxy Key Generation. To generate a proxy key pair (xp, yp) for the proxy signer Bob, Alice and Bob execute the following interactive protocol jointly.

Designated- VerlJier Proxy Signature Schemes

415

(1) Alice picks a random number k, E Z;, computes r, = g k a o d pand c=h I(?",), and then sends c to Bob. (2) Similarly, Bob first chooses a random number k, E Z,' , then computes r, = gk" modp and replies Alice with (c, 7,).

-

(3) When (c, r,) is received, Alice checks whether r j 1modp. If this is true, she computes r, = rA. r, modp, s, = k, + x, . h(m,,,r,) modq, and sends the pair (rA,s,) to Bob. (4) Upon receiving (r,, sA), Bob computes r, = r, . r, modp, and then . r , mod p . checks whether r,Y = I modp, c = h'(r,), and g ' A = If all validations pass, he calculates s, = k, + x, . h(m,+,r,) mod q, and finally sets his proxy key pair (x,, y,) by

y2(m""p)

x, = s,

+ s,

modq, and y, = gxpmodp.

(2)

It is easy to know that the above defined proxy key pair (x,, y,) satisfies Eq. (I), i.e., (rp, x,) is a standard Schnorr signature [23] on the warrant m , with respect to the public key yAyB modp. In addition, note that in the above proxy key generation procedure, we do not assume the communication channel between Alice and Bob is secure. Namely, public channel could be used unless delegation privacy is required. The reason is that the exchanged data, ie., m , , YA, SA,r ~ SB, etc., are useless for other party (to forge proxy key pairs or proxy signatures).

Proxv Sianature Generation. To generate a proxy signature on a message m that conforms to the warrant m,,, the proxy signer Bob performs the same operations as in the standard Schnorr signature scheme [23]. That is, he first selects a random number k E Z; , then computes r = gkmodp and s = k + x, . h(m, m,,, r ) modq. The resulting proxy signature on message m is

Proxv Sianature Verification. To verify the validity of an alleged proxy signature o for message m, a verifier operates as follows: (1) Check whether the message m conforms to the warrant m,. If not, stop. Otherwise, continue. (2) Check whether Alice and Bob are specified as the original signer and the proxy signer in the warrant m,,,, respectively. (3) Recover the proxy public key y, from public information by computing y, = (y, . y,)h("'*,rp). r, mod p. (4) Accept the proxy signature o if and only if the following equality holds:

Guilin Wang

In the above proxy scheme, when the proxy singer Bob generates a proxy signature the warrant m,. is embedded in the input of the hash function h( ). The aim is to use rn, as an identifier of proxy signatures. We now discuss the security of our above scheme. According to the results in [20] and 1211, we have the following Proposition 1 and 2. Then, Proposition 3 holds.

Proposition 1 (Theorems 1 and 2 of [20]). In the random oracle model, ifan adversary, who may compromise the original signer or the proxy signer (but not both), can forge a proxy key pair (xp, yp) that satisJies Eq. ( I ) with respect to a pair (m, rp) in probabilistic polynomial time (PPT) with nonnegligible probability, then the discrete log problem in the multiplicative subgroup can be solved in PPT with non-negligible probability. Proposition 2 [21]. Under the assumption that the discrete log problem in the multiplicative subgroup is intmctable, the Schnorr signature scheme is secure in the random oracle model. Proposition 3. Under the assumption that the discrete log problem in the multiplicative subgroup is intractable, the proposed proxy signature scheme is secure in the random oracle model. Proof (Sketch):In our scheme, we use Nicolosi et al.'s provably secure twoparty Schnorr signature scheme [20] to generate proxy key pair (xp,y,). That is, in their scheme a two-party Schnorr signature for a message can only be generated by the two related parties jointly. In our scheme, a valid proxy key pair (xp, yp) (defined by Eq. (1)) implies that (rp, xp) is exactly Alice and Bob's valid two-party Schnorr signature on the warrant rn, in Nicolosi et a1.k scheme. Therefore, anybody (including Alice and Bob) cannot generate a valid proxy key pair independently. Meanwhile, without a valid proxy key pair anybody cannot generate a proxy signature such that Eq. (3) is satisfied. Because the proxy signature generation algorithm is just the Schnorr scheme [23], which is also provably secure [21] in the random oracle model [3]. Therefore, we conclude that our proxy scheme is unforgeable. Other security requirements are also met in our new scheme, since we can provide similar security analysis as done in [15-171.

Designated-VerlJiev Proxy Signature Schemes

417

DESIGNATED-VERIFIER PROXY SIGNATURES We now present two designated-verifier proxy signature schemes, in which proxy signatures can be only verified by a designated-verifier. Those DVPS schemes are constructed from the basic proxy signature scheme introduced in Section 3. However, note that the Triple Schnorr proxy signature proposed in [4] could also be used as the basic scheme in a similar way.

In the following description, it is supposed that the original signer Alice and the proxy signer Bob have agreed on a warrant m,, before generating a proxy key pair. In addition, we assume Cindy be the designated verifier with certified key pair (xc ,y, = g X c mod p). Other system parameters are the same as in previous section. Proxy key generation procedure is the same as our basic scheme described in Section 3. That is, the original signer Alice and the proxy signer Bob jointly generate a proxy key pair (x,, y,) for Bob such that the proxy public key yp can be recovered from Eq. (I), and that only Bob knows the value of the proxy secret key x,.

4.1

Weak Designated-Verifier Proxy Signature Scheme

Proxy Siclnature Generation. To generate a weak designated-verifier proxy signature on a message m that conforms to the warrant m,, the proxy signer Bob performs as follows. He first selects a random number k E Z,* at uniform, then computes (r, r', s) by Eq. (4), and sends the proxy signature or= (m,", r,, r', s ) to the designated verifier Cindy. Y = gkmodp,

r'= y: modp,

(4)

s = k + x p .h(m,m,,r)modq.

Proxy Sianature Verification. To verify the validity of a weak DVPS designated verifier Cindy operates as follows:

0 ', the

(1) Check whether the message m conforms to the warrant m,,. If not, stop. Otherwise, continue. (2) Check whether Alice and Bob are specified as the original signer and the proxy signer in the warrant m,,, respectively. (3) Recover the values of r and the proxy public key yp by computing r = (r')"~'modp and y, = (y, . y,)h(m+~,r~) . r, modp.

Guilin Wang (4) Accept the proxy signature o' fi and only holds:

if the following equality

The essence of the above scheme is that to restrict the publicly verifiability of a proxy signature, we simply encrypted the value r by releasing r'= y: modp. Therefore, only the designated verifier Cindy can recover r from r ' by using her secret key x,, and then check the validity of such an encrypted proxy signature. Note that in our above scheme, the designated verifier Cindy can convince any third party to accept such a proxy signature o' by simply releasing o = ( m , , rp ,r, s). Weak designatedverifier proxy signature schemes might be suitable in the settings where both the proxy signer and the designated verifier want that without their help, any third party cannot validate proxy signatures. We now state the security of the above scheme as follows. Proposition 4. Under the assumption that the DifJie-Hellman problem in the multiplicative subgroup is intractable, the proposed weak designatedveriJier signature scheme is secure in the random oracle model. Proof: We first prove that except the designated-verifier Cindy (and the proxy signer Bob), any third party (including the original signer Alice) cannot check the validity of a weak DVPS o' = (m,, rp, r',s) for message rn. First of all, note that without the value of r the third party cannot check the validity of o ' . In other words, to validate o' the third party has to recover the value of r from public information. Under the assumptions that DL is difficult and that h( ) can be modeled as a random function [3], neither (m,,, rp, yp, YC)nor s can be used to reveal xc or recover r. Consequently, the third party can only use yc and r ' to recover the value of r. That is, on input (g, y, = g x c modp, r' = gk."cmodp), the third party wants to output r = g kmodp. In [2], it is proved that this problem (called Divisible Computation Dz@e-Hellman Problem) is as difficult as the CDH problem. Therefore, under the CDH assumption, only the designated verifier Cindy can check the validity of a week designated-verifier proxy signature. Now, we prove that the unforgeability. According to Proposition 3, any adversary who is not delegated as a proxy signer by Alice cannot forge a valid proxy key pair (xp, yp). Furthermore, we claim that given a proxy public yp even the designated verifier Cindy, who knows her secret key x, but does not know the proxy secret key xp corresponding to yp, cannot forge a valid proxy signature for a new message m that never appears in Cindy's records of known signature-message pairs. If this is not the fact, i.e., Cindy can forge a valid weak DVPS o' = ( m , , rp, r', s) for a new message m. Then,

Designated-VeriJier Proxy Signatzrve Schemes

4 19

Cindy can compute r = (r')"~'m o d p . The latter means that Cindy can forge a Schnorr signature 5 = (7, s ) for message (m, m,,) with respect to the public key yp. This is contrary to the Proposition 2, i.e., the provable security of the Schnorr signature scheme. Therefore, only the delegated proxy signer Bob can generate valid weak designated-verifier proxy signatures.

4.2

Strong Designated-Verifier Proxy Signature Scheme

Based on the basic proxy scheme proposed in Section 3 and Saeednia et a1.k strong designated-verifier signature scheme [22], we now construct a strong designated-verifier proxy signature scheme. In the new scheme, the designated-verifier Cindy can verify that a proxy signature is signed by the proxy signer Bob, but she is unable to convince anyone else of this fact. Because others know that such signatures may be simulated by the designated-verifier Cindy.

Proxv Sisnature Generation. To generate a strong designated-verifier proxy signature on a message m that conforms to the warrant m,, Bob performs as follows. He first selects two random numbers k~ Z, and t E 2;, then computes (v, c, s) by Eq. (6), and sends the proxy signature 0 = (m,,, r,, C,s, t ) to the designated verifier Cindy. r = y$ modp, C = h(m,m,,,r), s = kt-' - x, . cmodq.

(6)

Proxv Sisnature Verification. To verify the validity of a strong DVPS

o,the designated-verifier Cindy operates as follows: (1) Check whether the message m conforms to the warrant m,,>.If not, stop. Otherwise, continue. (2) Check whether Alice and Bob are specified as the original signer and the proxy signer in the warrant m,, respectively. . rp modp. (3) Recover the proxy public key y, = (y, . y,)h('n*~~'p) (4) Accept the proxy signature o if and only if the following equality holds: c = h(m,m,,F),

where 7 = (gsy;)'."c modp.

(7)

Proxv Signature Simulation. To simulate a strong designated-verifier proxy signature o' for any message m that conforms to the warrant m,v, ~ , at random, and computes the following Cindy picks S'E Z, and r ' Z,* values:

Guilin Wang r = gS'y$modp, c = h(m,m,,, r ) , I = rfc-I mod q, s = s'l-' mod y, t = Ix,' mod q.

(8)

of= ( m w rp, , C , S , t ) is the simulated proxy signature for message m with respect to the proxy public key yp. It is easy to check that of is also a valid proxy signature, i.e., it satisfies Eq. (7). Now we discuss the security of the above scheme. From the results of [22], we obtain Proposition 5, and then Proposition 6 can be proved in a similar way as we did in Proposition 4.

Proposition 5. If a valid strong designated-verzfier proxy signature for Cindy can be generated without the knowledge of the proxy secret key xp or Cindy's secret key xc, then the computational Diffie-Hellman problem may be solved in PPT. Furthermore, the transcriyts simulated by Cina) are indistinguishable from those generated by the proxy signer Bob. Proposition 6. Under the CDH assumption, our strong designated-verlJier proxy signature scheme is secure in the random oracle model.

4.3

Applications

In this section, we briefly introduce two potential applications for designated-verifier proxy signatures (DVPS). Other applications are also possible. Let us first consider the following scenario. A corporate manager Alice will have vacation for one or two weeks, however, some current businesses need to be processed continuously during this period. Naturally, Alice could delegate her signing capability to several assistants to deal with each business with different customer. For example, assistant Bob, as the representative of Alice, is assigned to negotiate a business contract with customer Cindy in this period. During this procedure, some intermediate documents will be produced with digital signatures for authentication or non-repudiation. However, to protect the confidentiality and authenticity of those documents, it may be highly expected that the corresponding signatures could be validated only by the designated receiver. In this case, DVPS could be used. More specifically, Bob's proxy signatures can only be verified by Cindy. Furthermore, if non-repudiation service is required, weak DVPS could be exploited. Another example is about on-line shopping. When a customer Cindy buys a digital product m from an Internet vendor Bob, who sells some digital products (e.g. digital music, movies, and books etc.), she needs a digital receipt from Bob to guarantee the quality, authenticity, and legality of m. This is reasonable since Cindy does not c .>mpletelytrust Bob and his goods.

Designated-Verzfier Proxy Signature Schemes

42 1

Furthermore, Cindy would expect the receipt is bounded with not only the identity of the vendor Bob but also that of the goods producer, say Alice. With such receipts, Cindy will be convinced that digital product m is produced by Alice and sold by Bob. At the same time, to prevent Cindy from illegally re-selling m to others, Alice and Bob want the validity of Cindy's receipt can only be validated by Cindy herself. In such situations, strong designated-verifier proxy signatures, instead of ordinary digital signatures, can be used as such receipts. That is, Alice delegates her signing capability to Bob so that he can generate strong designated-verifier proxy signatures as digital receipts to all potential customers. Note that this approach cannot prevent Cindy to send a copy of digital product to her friends. To deal with this problem, one could exploit some techniques from digital right managements (DRM), such as watermarlung and fingerprinting etc.

5.


In this paper, based on the two-party Schnorr signature scheme proposed in [20], we first proposed a provably secure proxy signature scheme. Then, we extended this basic scheme into designated-verifier proxy signature (DVPS) schemes. Actually, we constiucted two versions of DVPS: weak DVPS and strong DVPS. In both versions, only the designated verifier can check the validity of a proxy signature. In a weak DVPS scheme, however, the designated verifier can further convert such proxy signatures into public verifiable ones, while a strong DVPS scheme does not meet the same property even if the designated verifier's secret key is revealed willingly or unwillingly. Finally, we introduced some potential applications for DVPS. Some other variations can be obtained directly, such as blind proxy signatures from the blind Schnorr signature [24], universally designatedverifier proxy signature scheme by using the techniques in [26], and fully distributed proxy signatures by using the techniques in [11] (though this concrete scheme is insecure [28]). Another interesting work is to design forward-secure proxy schemes.

REFERENCES 1.

2.

C. Adams and S. Farrell, Internet X.509 publtc key infrastructure: Certificate management protocols, RFC 25 10, March 1999. F. Bao, R.H. Deng, and H. Zhu, Variations of Diffie-Hellman problem, in: Information and Communicatins Security (ICICS'03), LNCS 2836, pp. 301-312, Springer-Ve::.ig, 2003.

Gzrilin Wang M. Bellare and P. Rogaway, Random oracles are practical: A paradigm for designing efficient protocols, in: Proc. of 1st ACM Conference on Computer and Communications Security (CCS193),pp. 62-73, ACM Press, 1993. A. Boldyreva, A. Palacio, and B. Warinschi, Secure proxy signature schemes for delegation of signing rights, Cryptology ePrint archive; http:/leprint.iacr.org/20O3/096, May 2003. D. Boneh, The decision Diffie-Hellman problem, in: Proc. of the Third Algorithmic Number Theory Symposium (ANTS198), LNCS 1423, pp. 48-63, Springer-Verlag, 1998. D. Chaum and H. van Antwerpen, Undeniable signatures, in: CRYPT0'89, LNCS 435, pp. 212-2 16, Springer-Verlag, 1989. D. Chaum, Zero-knowledge undeniable signatures, in: EUROCRYPT'90, LNCS 473, pp. 458-464, Springer-Verlag, 199 1. Y. Desmedt, C. Coutier, and S. Bengio, Special uses and abuses of the Fiat-Shamir passport protocol, in: CRYPT0'87, pp. 2 1-39, Springer-Verlag, 1987. Y. Desmedt and M. Yung, Weakness of undeniable signature schemes, in: EUROCRYPT'9 1, LNCS 547, pp: 205-220, Springer-Verlag, 199 1. S. Goldwasser, S. Micah, and R. Rivest, A digital signature scheme secure against adaptive chosen-message attacks, SIAM Journal of Computing, 17(2): 281-308 (April 1988). J. Herranz and Saez, Verifiable secret sharing for general access structures, with applications to fully distributed proxy signatures, in: Financial Cryptography (FC103),LNCS 2742, pp. 286-302, Springer-Verlag, 2003. M. Jakobsson, Blackmailing using undeniable signatures, in: EUROCRYPTt96, LNCS 950, pp.: 425-427, Springer-Verlag, 1994. M. Jakobsson, K. Sako, and R. Impagliazzo, Designated verifier proofs and their applications, in: EUROCRYPT'96, LNCS 1070, pp. 143-154, Springer-Verlag, 1996. S. Kim, S. Park, and D. Won, Proxy signatures, revisited, in: Information and Communications Security (ICICS197), LNCS 1334, pp. 223-232, Springer-Verlag, 1997. B. Lee, H. Kim, and K. Kim. Secure mobile agent using strong non-designated proxy signature, in: Information Security and Privacy (ACISP'OI), LNCS 21 19, pp. 474-486, Springer-Verlag, 2001. J.-Y. Lee, J. H. Cheon, and S. Kim, An analysis of proxy signatures: Is a secure channel necessary? in: Topics in Cryptology - CT-RSA 2003, LNCS 26 12, pp. 6879, Springer-Verlag, 2003. M. Mambo, K. Usuda, and E. Okamoto, Proxy signatures: Delegation of the power to sign messages, IEICE Trans. Fundamentals, Vol. E79-A, No. 9, pp. 1338-1353 (Sep. 1996). M. Mambo, K. Usuda, and E. Okamoto, Proxy signatures for delegating signing operation, in: Proc. of 3rd ACM Conference on Computer and Communications Security (CCS196),pp. 48-57, ACM Press, 1996. M. Meyers, C. Adams, D. Solo, and D. Kemp, Internet X.509 certificate request format, RFC 25 11, March 1999. A. Nicolosi, M. Krohn, Y. Dodis, and D. Mazieres, Proactive two-party signatures For user authentication, in: Proc. of 10th Annual Network and Distributed System Security Symposium (NDSS'03); http:llwww.isoc.org/isoc/conferences/ndss/,

Designated-VeriJier Proxy Signature Schemes

423

21. D. Pointcheval and J. Stem, Security arguments for digital signatures and blind signatures, Journal of Cryptology, 13(3): 361-369 (2000). 22. S. Saeednia, S. Kremer, and 0. Markowitch, An efficient strong designated verifier signature scheme, in: lnformation Security and Cryptology - IClSC 2003, LNCS 2971, pp. 40-54, Springer-Verlag, 2004. 23. C. Schnorr, Efficient signature generation by smart cards, Journal of Cryptography, 4(3): 161-174 (1991). 24. C. Schnorr, Security of blind discrete log signatures against interactive attacks, in: Information and Communications Security (ICICS'OI), LNCS 2229, pp. 1-12, Springer-Verlag, 200 1. 25. R. Steinfeld, L. Bull, H. Wang, and J. Pieprzyk, Universal designated-verifier signatures, in: ASlACRYPT'03, LNCS 2894, pp. 523-542, Springer-Verlag, 2003. 26. R. Steinfeld, H. Wang, and J. Piepnyk, Efficient extension of standard SchnorriRSA signatures into universal designated-verifier signatures, in: PKC 2004, LNCS 2947, pp. 86-100, Springer-Verlag, 2004. 27. G. Wang. An Attack on not-interactive designated verifier proofs for undeniable signatures, Cryptology ePrint archive; http://eprint.iacr.org/2003/2431, Nov. 2003. 28. G. Wang, F. Bao, J. Zhou, and R. H. Deng, Security analysis of some proxy signatures, in: Information Security and Cryptology - ICISC 2003, LNCS 2971, pp. 305-3 19, Springer-Verlag, 2004. 29. K. Zhang, Threshold proxy signature schemes, in: Information Security Workshop (ISW197),LNCS 1396, pp. 282-290, Springer-Verlag, 1997.

TRIPARTITE CONCURRENT SIGNATURES

Willy Susilo and Yi Mu Centrefor Information Security Research School of Information Technology and Computer Science University of Wollongong Wollongong 2522, Australia Email: {wsusilo, ymu)@uow.edu.au Abstract: Fair exchange in digital signatures has been considered as a fundamental problem in cryptography. The notion of concurrent signatures was introduced in the seminal paper of Chen, Kudla and Paterson in Eurocrypt 2004 Chen et al., 2004. In this paper, we partially solve an open problem proposed in Chen et al., 2004. We extend the notion of two party concurrent signatures to tripartite concurrent signature schemes. In tripartite concurrent signatures, three parties can exchange their signatures in such a way that their signatures will be binding concurrently. We present a model of tripartite concurrent signatures together with a concrete scheme based on bilinear pairings. It was noted in Chen et al., 2004 that extending concurrent signatures to a multi-party scheme, where there are three or more participants, cannot be achieved by trivially modifying their construction in Chen et al., 2004.

Key words: Tripartite Concurrent Signatures, Multi-party Fair Exchange.

Willy Susilo and Yi Mu

1.

INTRODUCTION

Fair exchange in digital signatures has been considered as a fundamental problem in cryptography. Fair exchange is a necessary feature in many applications for electronic commerce. Typical applications include contract signing where two parties need to exchange their signature on a contract. Two party fair exchange has been studied extensively in the literature. In general, the method can be broadly divided into two types, namely with or without a trusted party TTP. It was believed that fair exchange without a TTP is not practical, since it requires a large number of communication rounds, until the recent work of Chen, Kudla and Paterson in Chen et al., 2004 that shows a weaker version of two party fair exchange can be done efficiently without any involvement of a TTP. In concurrent signatures, two parties can produce two signatures in such a way that from any third party's point of view, both signatures are ambiguous. However, after additional information, called the keystone, is released by one of the parties, both signatures are binding concurrently. It was noted in Chen et al., 2004 that this type of signature scheme falls just short of providing a full solution to the problem of fair exchange of signatures. In the same paper, they questioned the existence of multi party concurrent signatures. They noted that if multi party concurrent signatures can be constructed and modeled correctly, this will move closer to the full solution of multi party fair exchange. They also mentioned that their scheme cannot be trivially extended to include multiple matching signers, since the fairness of the scheme will not be achieved.

Our Contribution In this paper, we present a novel model of tripartite concurrent signatures that allows three parties to exchange their signatures in a fair way. Our model guarantees fairness as in the seminal paper of Chen et al., 2004. We also provide a concrete scheme that satisfies our model, based on bilinear pairings. We provide a set of security analysis for our concrete scheme. 1.1

Related Work

In Rivest et al., 2001, the notion of ring signatures was formalized and an efficient scheme based on RSA was proposed. This signature can be used to convince any third party that one of the people in the group (who know the trapdoor information) has authenticated the message on behalf of the group.

Tripartite Concurrent Signatures

427

The authentication provides signer ambiguity, in the sense that no one can identify who has actually signed the message. Designated Verifier Proofs were proposed in Jakobsson et al., 1996. The idea is to allow signatures to convince only the intended recipient, who is assumed to have a public-key. As noted in Rivest et al., 2001, ring signature schemes can be used to provide this mechanism by joining the verifier in the ring. However, it might not be practical in the real life since the verifier might not have any public key setup. In Desmedt, 2003, Desmedt raised the problem of generalizing the designated verifier signature concept to a multi designated verifier scheme. This question was answered affirmatively in Laguillaumie and Vergnaud, 2004, where a construction of multi designated verifiers signature scheme was proposed.

2.

PRELIMINARIES

2.1

Basic concepts on Bilinear Pairings

de2q,q, . THEOREM 3. Suppose that the ( t , ~-CDH ) assumption holds in G , then the above scheme is (t', q, ,q, ,q, ,q, ,E) -adaptive chosen message (AUTHCMA2) secure for any t' < t - o(t) . Proofs are omitted due to the length constraint. Please refer to the full version of this paper [I I].

Signcryption in Hierarchical Identity Based Cvypfosystern 5.

SCHEME 2

5.1

Construction

Let H be a cryptographic hash function where H : {O, 1)' -+Z, . use H(.) to hash the string representing the identity into an element in Z , , the same hash function will be used in the signing algorithm too. Similar to [3], H is not necessarily a full domain hash function. Notice that the identity string is hashed to 2, instead G in scheme 1, so we use Ii to denote H(IDi) for 1 l i l! , where & is the number of levels of the hierarchy to be supported. Our second construction of HIDSC, based on the ideas in [9]and [3],is given below. setup : On the input of a security parameter k E N , the root PKG uses the B D H parameter [4] to generate G , G I , q and ;(.,.), where q is the order of groups G and GI. Then the root PKG executes the following steps. 1. Select a from Z i , h, ,h, ,. . .,h, from G and two generators g , g, from G* , where & is the number of levels of the hierarchy to be supported. 2. The public parameters are: (g,g,= ga,g,,4 ,h,, . - .,hy,;(g,, g,)). a 3. The master secret key is dmp = g, . KeyGen: For a user ID1 k - l = (ID,, ID,;..,ID,-,)of depth k - 1 , helshe uses hisher secret key d,,,-, to generate the secret key for a user ID 1 k (where the first k - 1 elements of ID I k are those in ID I k - 1 ) as follows. 1. Pick random rk from Zp. 2. dm,,={doF,(I,)rk,d,,...,dk-I,g'),where F,(x) isdefinedas g,xhk. Sig?: For a user ID I k with secret key F, (Ij)" , g ' , . grk ) to sign on a message M , helshe follows {g, the stepsJ&ow. 1. Pick a random number s from ZI",. 2. Compute h = H ( M .Z(g,, , g,)"). 3. Repeat Steps 1-3 in case the unlikely event s h = 0 occurs. s+h 4. For j = { 1 , 2 , . - - , k l , c o m p u t e y j = d j . 5. Compute z=d," . 6. Return {s,y,,y, ,. - - ,y, ,z) as the signature. Encrypt : To signcrypt a message ME G, to user ID I 1 = {ID,, ID,, .,ID,),the ciphertext to be generated is ,

.a,

+

-

{F,(I,)s,F,(I,)s,..-,F,(I,)s,~(g,,g,)s ~M,g",~~,y,,--.,~,,z). cr

(dTo= g2

ID'[1 with F, (I',)~'J, d', = g"', . - ,d'/ = gr'l) to

n,=,

Decrypt : 1

For

a

user

secret decrypt

key the

Sherman S.M Chow, Tsz Hon Yzlen, et al.

454

signcrypted text (u,,. ..,u,, V , W,y,, y,, .. .,y,, z ) , he/she follows the steps below. 1 1. Compute 0 = ;(g,, g2)' by h(w, d ' & n i=l i ( u , , d'/) 2. Obtain the message M by v . a-' Verify: For ID I k = (IDI,ID2, - .,IDk) 's signature ( 0 , y l , y2,.- .,yk,Z) , everyone can do the following to verify its validity. 1. Compute h = H ( M ,O). h 2. Return T if Z(g,z) = 0 .;(g,,g, y) ) n r = ,Z(yj,hi) , 1 otherwise.

n:=,

5.2

Efficiency Analysis

We first analyze the computational efficiency. For the proposed scheme 1, admissible encoding scheme [4] are required for the hash function H, and H2 , which is computationally expensive as such scheme requires log,(qlp) -bit scalar multiplication in E(Fq) where is the field on which G is based and p is the size of the group G . Using the example from [21], if log, p = 512 and the embedding degree of pairing is 6, then log, q should be at least 2560 and hence 2048-bit scalar multiplication is needed. Scheme 2's hash function does not rely on such admissible encoding scheme. Moreover, chosen ciphertext secure HIDE requires the transformation in Section 4 of [6], while our scheme does not require such transformation as the integrity checking of the ciphertext is obtained from the signature. For the communication efficiency of the scheme, the signcrypted message is shortened by one G, element, as compared with using the scheme in [9] and [3] together.

~ . ( 1 - q , ( 4 , +4s)/4). THEOREM 6. Suppose that the ( t , ~-CDH ) assumption holds in G , then the above scheme is (t', q,, q, ,q, ,q, ,E) -selective identity, adaptive chosen message (AUTH-sID-CMA2) secure for any t'< t - o(t) .

Signcryption in Hierarchical Identity Based Cryptosystem

455

Proofs are omitted due to the length constraint. Please refer to the full version of this paper [l 11.

6.

CONCLUSION

Two concrete constructions of hierarchical identity based signcryption are proposed, which closed the open problem proposed by [16]. Our schemes are provably secure under the random oracle model 121. Moreover, our schemes do not require transformation which is necessary for the case of hierarchical identity based encryption as the integrity checking of the ciphertext is obtained from the signature. We believe that hierarchical identity based signcryption schemes are useful in nowadays commercial organization and also in new network architecture such as tetherless computing architecture. Future research directions include further improvement on the efficiency of hierarchical identity based signcryption schemes and achieving other security requirements such as public ciphertext authenticity ([I 0,161) or ciphertext anonymity ([5]).

ACKNOWLEDGEMENT This research is supported in part by the Areas of Excellence Scheme established under the University Grants Committee of the Hong Kong Special Administrative Region (HKSAR), China (Project No. AoEIE-01/99), grants from the Research Grants Council of the HKSAR, China (Project No. HKU/7144/03E and HKU/7136/04E), and grants from the Innovation and Technology Commission of the HKSAR, China (Project No. ITS/170/01 and UIMl145).

REFERENCES [I] Jee Hea An, Yevgeniy Dodis, and Tal Rabin. On the Security of Joint Signature and Encryption. In Lars R. Knudsen, editor, Advances in Cryptology - EUROCRYPT 2002, International Conference on the Theory and Applications of Cryptographic Techniques, Amsterdam, The Netherlands, April 28 - May 2, 2002, Proceedings, volume 2332 of Lecture Notes in Computer Science, pages 83-107. Springer-Verlag Heidelberg, 2002. [2] Mihir Bellare and Phillip Rogaway. Random Oracles are Practical: A Paradigm for Designing Efficient Protocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security, pages 62-73, 1993. [3] Dan Boneh and Xavier Boyen. Efficient Selective-ID Secure Identity-Based Encryption Without Random Oracles. In Christian Cachin and Jdn Camenisch, editors, Advances In

456

Sherman S.M Chow, Tsz Hon Yuen, et al.

Cryptology - EUROCRYPT 2004, International Conference on the Theory and Applications of Cryptographic Techniques, Interlaken, Switzerland, May 2-6, 2004, Proceedings, volume 3027 of Lecture Notes in Computer Science, pages 223-238. Springer, 2004. [4] Dan Boneh and Matt Franklin. Identity-Based Encryption from the Weil Pairing. In Joe Kilian, editor, Advances in Cryptology - CRYPTO 2001, 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19-23,2001, Proceedings, volume 2139 of Lecture Notes in Computer Science, pages 213-229. Springer-Verlag Heidelberg, 2001. [5] Xavier Boyen. Multipurpose Identity-Based Signcryption : A Swiss Army Knife for Identity-Based Cryptography. In Dan Boneh, editor, Advances in Cryptology - CRYPTO 2003, 23rd Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 2003, Proceedings, volume 2729 of Lecture Notes in Computer Science, pages 382-398. Springer, 2003. [6] Ran Canetti, Shai Halevi, and Jonathan Katz. Chosen-Ciphertext Security from IdentityBased Encryption. In Christian Cachin and Jan Camenisch, editors, Advances in Cryptology - EUROCRYPT 2004, International Conference on the Theory and Applications of Clyptographic Techniques, Interlaken, Switzerland, May 2-6, 2004, Proceedings, volume 3027 of Lecture Notes in Computer Science, pages 207-222. Springer, 2004. [7] Liqun Chen and John Malone-Lee. Improved Identity-Based Signcryption. In Serge Vaudenay, editor, Public Key Cryptography - PKC 2005: 8th International Workshop on Theory and Practice in Public Key Cryptography, Les Diablerets, Switzerland, January 2326, 2005. Proceedings, volume 3386 of Lecture Notes in Computer Science, pages 362379. Springer, 2005. Also available at Cryptology ePrint Archive, Report 200411 14. [8] Sherman S.M. Chow. Verifiable Pairing and Its Applications. In Chae Hoon Lim and Moti Yung, editors, Information Security Applications: 5th International Workshop, WISA 2004, Jeju Island, Korea, August 23-25, Revised Selected Papers, volume 3325 of Lecture Notes in Computer Science, pages 170-1 87. Springer-Verlag, 2004. [9] Sherman S.M. Chow, Lucas C.K. Hui, S.M. Yiu, and K.P. Chow. Secure Hierarchical Identity Based Signature and its Application. In Javier Lopez, Sihan Qing, and Eiji Okamoto, editors, Information and Communications Security, 6th International Conference, ICICS 2004, Malaga, Spain, October 27-29,2004, Proceedings, volume 3269 of Lecture Notes in Computer Science, pages 480-494. Springer-Verlag, 2004. [lo] Sherman S.M. Chow, S.M. Yiu, Lucas C.K. Hui, and K.P. Chow. Efficient Forward and Provably Secure ID-Based Signcryption Scheme with Public Verifiability and Public Ciphertext Authenticity. In Jong In Lim and Dong Hoon Lee, editors, Information Security and Cryptology - ICISC 2003, 6th International Conference Seoul, Korea, November 2728, 2003, Revised Papers, volume 2971 of Lecture Notes in Computer Science, pages 352-369. Springer, 2003. [ l l ] Sherman S.M. Chow, Tsz Hon Yuen, Lucas C.K. Hui, and S.M. Yiu. Signcryption in Hierarchical Identity Based Cryptosystem, 2004. Extended abstract appeared in Security and Privacy in the Age of Ubiquitous Computing, IFIP T C l l 20th International Conference on Information Security (SEC 2005), May 30 - June 1, 2005, Chiba, Japan. Full version available at Cryptology ePrint Archive, Report 20041244. [I21 Jean-S6bastien Coron. On the Exact Security of Full Domain Hash. In Mihir Bellare, editor, Advances in Cryptology - CRYPTO 2000, 20th Annual International Cryptology Conference, Santa Barbara, California, USA, August 20-24, 2000, Proceedings, volume !880 of Lecture Notes in Computer Science, pages 229--235. Springer, 200R.

Signcryption in Hierarchical Identity Based Cvyptosystem

457

[13] Craig Gentry and Alice Silverberg. Hierarchical ID-Based Cryptography. In Yuliang Zheng, editor, Advances in Cryptology - ASIACRYPT 2002, 8th International Conference on the Theory and Application of Cryptology and Information Security, Queenstown, New Zealand, December 1-5, 2002, Proceedings, volume 2501 of Lecture Notes in Con~puter Science, pages 548-566. Springer, 2002. Available at http:/leprint.iacr.org. [14] Florian Hess. Efficient Identity Based Signature Schemes based on Pairings. In Kaisa Nyberg and Howard M. Heys, editors, Selected Areas in Cryptography, 9th Annual International Workshop, SAC 2002, St. John's, Newfoundland, Canada, August 15-16, 2002. Revised Papers, volume 2595 of Lecture Notes in Computer Science, pages 310324. Springer, 2003. [15] Berkeley. Intel Research. Identity Based Cryptosystem for Secure Delay Tolerant Networking. [I61 Benoit Libert and Jean-Jacques Quisquater. New Identity Based Signcryption Schemes from Pairings. In IEEE Information Theory Workshop, pages 155-1 58,2003. Full Version Available at http:/leprint.iacr.org. [I71 Benoit Libert and Jean-Jacques Quisquater. The Exact Security of an Identity Based Signature and its Applications. Cryptology ePrint Archive, Report 20041102, 2004. Available at http://eprint.iacr.org. [18] John Malone-Lee. Identity Based Signcryption. Cryptology ePrint Archive, Report 20021098,2002. Available at http://eprint.iacr.org. [19] Noel McCullagh and Paulo S. L. M. Barreto. Efficient and Forward-Secure IdentityBased Signcryption. Cryptology ePrint Archive, Report 200411 17, 2004. Available at http:l/eprint,iacr.org. [20] Divya Nalla and K.C. Reddy. Signcryption Scheme for Identity-Based Cryptosystems. Cryptology ePrint Archive, Report 2003/066,2003. Available at http:I1eprint.iacr.o1-g. [21] DongJin Park, Kihyun Kim, and Pi1 Joong Lee. Public Key Encryption with Conjunctive Field Keyword Search. In Chae Hoon Lim and Moti Yung, editors, Information Security Applications: 5th International Workshop, WISA 2004, Jeju Island, Korea, August 23-25, Revised Selected Papers, volume 3325 of Lecture Notes in Computer Science, pages 73-86. Springer-Verlag, 2004. [22] Ryuichi Sakai, Kiyoshi Ohgishi, and Masao Kasahara. Cryptosystems based on Pairing over Elliptic Curve. In Proceedings of Symposium on Cryptography and Information Security (SCIS 2000) C-20,2000. [23] Aaditeshwar Seth. Personal Communication, September 2004. [24] Aaditeshwar Seth, Patrick Darragh, and Srinivasan Keshav. A Generalized Architecture for Tetherless Computing in Disconnected Networks. Manuscript. [25] Tsz Hon Yuen and VictorK. Wei. Fast and Proven Secure Blind Identity-Based Signcryption from Pairings. In A. J. Menezes, editor, Topics in Cryptology - CT-RSA 2005, The Cryptographers' Track at the RSA Conference 2005, San Francisco, CA, USA, Febrary 14-18, 2005, Proceedings, volume 3376 of Lecture Notes in Computer Science, San Francisco, CA, USA, February 2005. Springer. To Appear. Also available at Cryptology ePrint Archive, Report 20041121. [26] Yuliang Zheng. Digital Signcryption or How to Achieve Cost (Signature & Encryption) j. In the latter case, as in case (a), AO,-~_,11 Xn-j-l 11 h,2-j-2 is a pre-image of ho( 4 . In summary, if case 2 happens, then we can either find a pre-image of a random string with respect to Hh or a collision of Hh (a formal proof of this claim uses again a reducibility argument). By the assumptions on W,this can happen only with negligible probability. This completes the proof. O

6.

CONCLUSIONS

In this paper, we provided two constructions which solve the data integrity problem for multimedia applications by combining methods from cryptography and watermarking. Technically, we used digital watermarks to encode cryptographic signatures directly in multimedia files. One construction is suitable for images and short media files, whereas the other one is targeted towards streaming applications. Both schemes were shown to be secure under standard

Ensuring Media Integrity on Third-party Infrastructures

507

cryptographic assumptions and can easily be incorporated into existing software systems or used as front-end programs to applications whose code is not under control of the user. Acknowledgement. The work described in this paper has been supported in part by the European Commission through the IST Programme under Contract IST-2002-507932 ECRYPT. The information in this document reflects only the author's views, is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

References Dittmann, J. and Benedens, 0. (2003). Invertible authentication for 3d-meshes. In Proceedings of the SPIE vol. 5020, Security and Watermarking of Multimedia Contents V,pages 653-664. Dittmann, J., Steinebach, M., and Ferri, L. (2002). Watennarking protocols for authentication and ownership protection based on timestamps and holograms. In Proceedings of the SPIE vol. 4675, Security and Watermarking of Multimedia Contents IV, pages 240-2.51. Fridrich, J., Goljan, M., and Du, R. (2001). Invertible authentication. In Proceedings of the SPIE vol, 3971, Security and Watermarking ofMultimedia Contents Ill, pages 197-208. Fridrich, J., Goljan, M., and Du, R. (2002a). Lossless data embedding-new paradigm in digital watermarking. EURASIP Journal on Applied Signal Processing, (2): 185-196. Fridrich, J., Goljan, M., and Du, R. (2002b). Lossless data embedding for all image formats. In Proceedings of the SPIE vol. 4675, Security and Watermarking of Multinzedia Contents IV, pages 572-583. Friedman, G. L. (1993). The trustworthy digital camera. IEEE Transactions on Consunzer Electronics, 39(4):905-9 10. Gennaro, R, and Rohatgi, P. (1997). How to sign digital streams. In Advances in Cryptology (CRYPTO'97), volume 1294 of Lecture Notes in Computer Science, pages 180-197. Springer. Goldwasser, S., Micah, S., and Rivest, R. (1988). A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing, 17(2):281-302. Honsinger, C. W., Jones, P., Rabbani, M., and Stoffel, J. C. (1999). Lossless recovery of an original image containing embedded data. US patent application, Docket No: 77102/E/D. Katzenbeisser, S. and Petitcolas, F. A. P., editors (2000). Infomation Hiding Techniques for Steganography and Digital Watermarking. Artech House. Maas, D., Kalker, T., and Willems, F, M. (2002). A code construction for recursive reversible data-hiding. In Proceedings of the ACM Workshop on Multimedia, pages 15-18. Schneider, M. and Chang, S.-F. (1996). A robust content based digital signature for image authentication. In IEEE International Conference on Inzuge Processing, Proceedings, Lausanne. Steinebach, M. and Dittmann, J. (2003a). Watermarking-based digital audio data authentication. EURASIP Journal on Applied Signal Processing, (10): 1001-101 5. Steinebach, M. and Dittmann, J. (2003b). Watermarking-based digital audio data authentication. EURASIP Journal on Applied signal processing, 10:1001-1015. Xie, L. and Arce, G. R. (1998). A blind wavelet based digital signature for image authentication. In European Signal Processing Conference, Proceedings, Rhodes, Greece.

A NEW FRAGILE MESH WATERMARKING ALGORITHM FOR AUTHENTICATION Hao-Tian Wu and Yiu-Ming Cheung Department of Computer Science, Hong Kong Baptist University, Hong Kong, China

Abstract:

In this paper, we propose a new fragile watermarking algorithm based on the global characteristics of the mesh geometry to authenticate 3D mesh models. In our method, a sequence of data bits is adaptively embedded into the mesh model by properly adjusting the vertex positions, and the bit information can be blindly extracted from the watermarked mesh model using a key. The embedding process is adaptive to the mesh model so that the watermarked mesh is perceptually indistinguishable from the original. We show that the embedded watermark is invariant to affine transformation but sensitive to other operations. Besides, the embedding strength is adjustable and can be controlled to a certain extent that even a trivial tampering with the watermarked mesh would lead the watermark signal to change. Therefore, unauthorized modifications of the mesh models can be detected and estimated.

Key words:

3D models; fragile watermarking; mesh authentication; dither modulation

1.

INTRODUCTION

While the prevalence of network facilitates people's acquirement and distribution of multimedia works, it also challenges the protection of digital works' copyrights. As a potential technique for copyright protection of digital works, digital watermarking for multimedia data (e.g. digital images, video and audio streams) has been proposed and arduously studied in the literature'' 2 . Recently, watermarking 3D objects, such as 3D polygonal meshes and various 3D geometric CAD data, has received much attention in the community and considerable progress has been made. In the l i t e r a t ~ r e ~a- ~ ~ , variety of watermarking algorithms have been proposed to embed watermarks into 3D models, mainly 3D polygonal meshes. For instance, the

510

Hao-Tian Wu and Yiu-Ming Cheung

algorithms3' 946 embed the watermarks by modifying the geometry of the meshes such as vertex coordinates, surface normal distribution, and so forth. They have shown the robustness against some operations to which 3D models are routinely subjected, e.g., affine transformations and mesh simplification. Furthermore, some algorithmsI4,Is modify the topology, i.e. the connectivity, to embed watermarks robust against geometrical operations, but weak to topological modifications. Additionally, some works16,'4 have used the appearance attributes associated with mesh models to embed the watermarks. In the paper'7, data embedding algorithms for NURBS and other types of parametric curves and faces are also proposed. To enhance the robustness of 3D watermarking systems, some fi-equency approaches'8~23 have been recently proposed. In the paper192 20,an algorithm that employs multi-resolution wavelet decomposition of polygonal mesh models is presented. Furthermore, the paper21 proposes an informed watermarking algorithm that constructs a set of scalar basis functions over the mesh vertices, through which the watermark is embedded into the "low frequency" of the polygonal meshes. In the paper22, Guskov's multiresolution signal processing method27 is adopted and a 3D non-uniform relaxation operator is used to construct a Burt-Adelson pyramid28 for the mesh to embed watermark information into a suitable coarser mesh. Mesh spectral analysis technique^^^ are also employed to transform the original meshes to the frequency domain and watermark information is embedded into the low frequency of the Nevertheless, few fragile algorithms4-8have been proposed to authenticate the integrity of 3D models. Actually, the first fragile watermarlung of 3D objects for verification purpose was addressed by Yeo and yeung4, as a 3D version of the approach proposed for 2D image watermarking. Because their algorithm heavily relies on the vertex position, a translation operation, which does not affect the integrity of the mesh model, would easily break the authentication mechanism. In this paper, we shall present a new fragile watermarking algorithm to authenticate 3D mesh models. Compared to the former methods, our approach makes the embedded watermark invariant to integrity-reserved affine transformation, including translation, rotation and uniformly scaling, but sensitive to other geometrical or topological operations. The rest of this paper is organized as follows. In the following section, a new fragile mesh watermarking algorithm is proposed to authenticate the integrity of 3D mesh models. The experiment results using the proposed method are given in Section 3. Finally, we draw a conclusion in Section 4.

A New Fragile Mesh Watermarking Algorithm for Authentication

2.

511

A NEW FRAGILE MESH WATERMARKING ALGORITHM

We perform the watermarking process on meshes, which are the "lowest common denominator" of surface representations. It is easy to convert other representations of 3D models to meshes. The mesh geometry can be denoted by a tuple (K, V) 25, where K is a simplical complex specifying the connectivity of the mesh simplices (the adjacency of the vertices, edges, and faces), and V= {vl, ..., v,) is the set of vertex positions defining the shape of the mesh in v3.

2.1

Extending Dither Modulation to 3D Meshes

We aim to authenticate the integrity of the mesh model, i.e., both the positions and connectivity of vertices need to be verified not having been modified. Our approach extends an implementation of quantization index modulation (QIM) called dither quantization2 to 3D meshes, and embeds a sequence of data bits by properly adjusting the distances fi-om the faces to the centroid of the mesh geometry. To extend dither quantization to the mesh model, we choose the quantization step adaptive to the mesh geometry. Suppose V= (vl, ..., v,} is the set of vertex positions in v3, the position of the mesh centroid is defined by

'

The Euclidean distance d, from a given vertex with the position vi to the mesh centroid is given by

where {vix,viy,viZ)and {v,,, v,, v,,) are the coordinates of the vertex and the mesh centroid on X-axis, Y-axis and Z-axis, respectively. Using Eq. (2), the furthest vertex with the position vd to the mesh centroid can be found out and its corresponding distance D is denoted as

5 12

Hao-TianWzr and Yiu-MingChezrng

We refer to the distance D as the largest dimension of the mesh model and the quantization step S is chosen as

where N is a specified value. The distance from a given face to the mesh centroid is defined as the Euclidean distance from the centroid of the face to that of the mesh. Furthermore, the centroid position of a given facef; with u edges can be obtained by

where v,,, j E (1,2,. .,u) is the vertex position in the facef;. The distance dfi from the face5 to the mesh centroid can be calculated by

Subsequently, we obtain the integer quotient Q, and the remainder Riby

and

To embed one bit value w(9, we modify the position vie of the face centroid so that Q, is an even value for the bit value 0, and an odd value for 1. In order to make Qi%2=w(i) always hold meanwhile reducing the falsealarm probability, we modulate the distance dfiaccording to the bit value in the following way:


513

where d)' is the modulated distance from the face J; to the mesh centroid. Suppose the faceJ; consists of u vertices with the centroid position vie, the position v,, of one selected vertex inJ; will be adjusted using dfi'by

where vv refers to the vertex position i n 5 and viSJ is the adjusted position of the selected vertex. The watermark information embedded in our method is inherently invariant to affine transformations that include any transformation preserving collinearity (i.e., all points lyng on a line initially still lie on a line after transformation) and ratios of distances (e.g., the midpoint of a line segment remains the midpoint after transformation). So the ratio between the distance from each surface face to the mesh centroid and the quantization step, which is proportional to D, remains the same after the model is translated, rotated or uniformly scaled. Otherwise, if the mesh model is processed by other operations that change the ratios, the formula Qi%2=w(i) will not always hold and the embedded watermark will be changed. Since we need to detect a trivial modification on the mesh model, the integer value Qi should be sensitive to the &stance from the mesh centroid to the surface face. In practice, we assign N a large value to obtain a small quantization step S. Please note that the precision of the arithmetic operations must be regarded; otherwise, it may increase the false-alarm probability. The face index of the mesh model is used to represent the connectivity of vertices. If there is any change in the mesh topology, such as mesh decimation or mesh resampling, the face index will be modified and the information hidden in the distances to the mesh centroid would be undermined, therefore the unauthorized modification on mesh topology can be detected.

2.2

The Encoding Process

In this subsection, we will elaborate on how to adjust the mesh surface faces and eventually move them to the desired positions. Please note that faces share edges and vertices with their neighbors, adjusting one face's position may also modify its neighbors' positions. To successfully retrieve the embedded information and preserve the mesh geometry, the centroid position and the largest dimension of the mesh model must remain the same during the encoding process.

514

Hao-Tian Wu and Yiu-Ming Cheung

Since the position of a given face depends on the coordinates of its vertices, we can lock the face position by locking the coordinates of its vertices. To move one face centroid to the desired position so that one bit of the watermark information is embedded, only one vertex position in the face need to be adjusted. To avoid the embedded information is changed by the following encoding operations, the vertices in the moved faces need to be marked. Once one watermark bit value is hidden in the distance from the face to the mesh centroid, all the vertices in the face will be marked and their positions can not be modified any more. The centroid of the mesh

mesh model

The face index I

The scrambled -+ index I'

t

The key K

JI Indexing to a face Qualified-, the face

-

The furthest vertex

-

dimension

kparame

Mark the furthest N vertex Quant~zatlon step Vert~ces Unmark all markmg vertices mformat~on-: A ~n~t~ally

-

Mark all the vertices In the face

1

01t value W[I) of the watermark W pos~tlonof themesh centroid 7

Adjust one vertex position introduced in the face Embedding process finished

I watermarked

I mesh model

Figure I. The flow chart of the encoding process

The overall encoding process is as shown in Fig. 1. At first, all vertices in the original mesh are unmarked, the position of mesh centroid is obtained by Eq. (1). Then the furthest vertex to the mesh cel~troidis found out using Eq.

A New Fragile Mesh Wutermuvking Algovithm for Aztthentication

515

(2) and its corresponding distance to the mesh centroid is calculated using Eq. (3). Since the value of D should not be changed, the furthest vertex is marked and its coordinate will not be modified. The quantization step S can be chosen by specifying the value of N. Using a key, we scramble the face index I to obtain the scrambled index 1', which we will follow in the following encoding process. Before one bit information is embedded in the distance from a face to the mesh centroid, all vertices in the face need to be checked. If there is at least one unmarked vertices in the faceJ, it is qualified to carry one bit value. The distance from the face to the mesh centroid is calculated by Eq. (6) and modulated by Eq. (9) according to the bit value. Noting that the value of D must be maintained in the encoding process, if the modulated distance exceeds it, twice of the quantization step should be subtracted from it so that the embedded bit value is held. Then the coordinate of one unmarked vertex is adjusted using Eq. (lo), whereby the face centroid is moved to the desired position. At the end of the embedding operation, all vertices i n 5 will be marked. If there is no unmarked vertex in a face, which means the face is not qualified, the checking mechanism will skip to the next face until all watermark information is embedded. The above embedding process inevitably introduces the distortion of the mesh geometry as some of the vertex coordinates are changed. However, the distortion can be limited to a predefined range, since the elongate or the reduction of the distance from a face to the mesh centroid is no more than twice of the quantization step in the proposed embedding algorithm. The distortion of the mesh geometry also changes the position of the mesh centroid, although adjusting the vertex coordinate may counteract each other. So in the encoding process, not all faces can be used to embed the watermark information. Otherwise, the centroid position of the mesh model will be lost. A small portion of the vertices are needed to restore it after the embedding process. We refer to this process as the centroid restoration process, which modifies the coordinates of the unmarked vertices in the last faces indexed by I' to compensate the error introduced by the embedding process. The centroid restoration process begins with the calculation of the introduced error E using

where vj is the original vertex position while vj' is the adjusted vertex position after the embedding process. Since the value of D should be maintained in the encoding process, the distance from the mesh centroid to the adjusted vertex should not exceed it. So we adjust the unmarked vertices in the centroid restoration process by the following way:

5 16

Hao-Tian Wz/ and Yiu-Ming Cheung

Firstly, we calculate the admissible adjusting radius rj of an unmarked vertex with the position v, by

Then we use the value of rj to weight the adjusting vector of each unmarked vertex to ensure that the vertex will not be moved outside its admissible range. Suppose the sum of the unmarked vertices used in the centroid restoration process is L, the individual adjusting weight ei can be obtained by

Subsequently, we subtract the individual adjusting weight from vertex position vj to restore the position of the mesh centroid by

where vj' represents the adjusted vertex position after the centroid restoration process and vj the original one. The encoding process ends as the centroid position of the mesh model is restored.

2.3

The Authentication Process

In the authentication process, only the parameter N, the key K and the original watermark W are needed to authenticate the watermarked mesh geometry. The detailed procedure is shown in Fig. 2. At first, similar to the encoding process, all the vertices of the original mesh are unmarked, the centroid position v, ' of the suspect mesh geometry is obtained by Eq. (I), which should equal to the centroid position v, of the original mesh. Then the furthest vertex to the mesh centroid is found using Eq. (2) and its corresponding distance D ' is calculated by Eq. (3), which should equal to the largest dimension D of the original mesh model. The quantization step is calculated by S'=D'/N with the provided parameter N. Since the furthest vertex is marked before the embedding process, it should also be marked before the authentication process. Then the face index I of the mesh is scrambled using the key K to produce the scrambled index I'. Before retrieving one bit value from the distance from a given face to the mesh centroid, the vertex marks in the face need to be checked. If there is at

517


least one unmarked vertex in a faceJ;', the face will be qualified to extract the embedded bit information and its centroid position vi,'will be calculated using Eq. (6). Then the distance DJ from the faceJf;'tothe mesh centroid can be calculated by 2 2 (1 5) D, = \j(vic,y'-v,) + (v;, '-VJ + i - 1

I The suspect L -the mesh mesh model ) , I

ofb

hParaNm

vertex

dimension

I

Mark the furthest vertex Quantization

The scrambled

Vertices marking information

Indexing t o a ~ualiled-4

t

the face

I

The extracted bit value w'(i)

-

Extract~on process fin~shed

1

-

-

step

Unmark all

- vertices

initially

Mark all the vertices in the face

]

watermark W

The extracted . watermark W'

4

The NC ,Authent~cation result value

Figure 2. The flow chart of authentication process

and the integer quotient Qi' can be obtained by

Q,I= D, / S t . The embedded bit information w '(i) can be extracted by

I

Hao-Tian Wu and Yiu-Ming Cheung w' (i) = Qi'%2 . At the end of the extracting operation, all the vertices inJ;' will be marked. If there is no unmarked vertex in a face, no information is extracted and the authentication mechanism will automatically skip to the next face indexed by I'. Since the original watermark W is known, the extraction process will cease once the extracted bit number matches the embedded bit number. After the extraction process, the extracted watermark W' is compared with the original watermark Wusing the following cross-correlation function, given their lengths are both identical to K:

c"(w'

1 NC = K

'=I

(i), w(i)) , I(w' (i), w(i)) =

1 w' (i) = w(i) ,(I 8) 0 w' (i) # w(i)

where NC refers to the normalized cross-correlation value between the original and the extracted watermarks. If the watermarked mesh model has not been tampered, the NC should be 1; otherwise, it will be less than 1. We claim the mesh geometry as being tampered if the resulting NC from Eq. (1 8) is less than 1.

3.

EXPERIMENTAL RESULTS

We have tested the proposed algorithm on several mesh models listed in Table 1 and used a 2D binary image as the watermark. The original mesh model "dog" and its watermarked version are shown in Fig. 4a and Fig. 46, respectively. The capacities of the mesh models using the proposed method are also shown in Table 1. Table 1. The mesh models used in the experiments * Models vertices faces

capacity(bits)

7158 13176 4219 dog wolf 7232 13992 4450 raptor 8171 14568 5695 horse 9988 18363 573 1 cat 10361 19098 6149 lion 16652 32096 10992 * About 1% vertices of each mesh model are used in the restoration process.

To evaluate the imperceptibility of the embedded watermark using the proposed algorithm, we used the Hausdorff distance between the original


519

and the watermarked mesh models to measure the distortion introduced by the encoding process, upon the fact that the mesh topology is not changed during the watermarking process. Fig. 3 describes the amount of the distortion subject to the parameter of N, given that the percent of vertices used for the restoration operation is about 1%. The Hausdorff distance is normalized by the largest dimension D of the mesh geometry. From the experimental results, it can be seen that the introduced distortion on mesh model decreases as the parameter N is increased.

Paremeter N Figure 3. The normalized Hausdorff Distance subject to the parameter N

In our proposed approach, the global characteristics such as the centroid position and the largest dimension of the mesh model are used. If these global characteristics are slightly altered, the watermark information will be dramatically changed and the modifications on the watermarked mesh model can not be located. However, it is easy to locate the tampering if it has little impact on the global characteristics. Since we used a 2D binary image as the Table 2. The NC values between the original and extracted watermarks ' Affine changing reducing adding cropping extracting Models transforma one vertex one 0.0001% 0.1% without face noise tion position faces the key 0.672 1 0.5375 0.02 15 0.0133 0.0200 dog 1.OOOO 0.5934 0.9276 0.0685 0.0083 0.0029 wolf 1.0000 raptor 1 .OOOO 0.9996 0.0063 0.6972 0.0024 0.0225 horse 1.0000 0.8249 0.0737 0.466 1 0.0039 0.0102 0.9993 0.0308 0.7072 cat 1.OOOO 0.0 195 0.0103 lion 1.0000 0.9996 0.0905 0.6363 0.0059 0.0088 * About 1% vertices of each mesh model are use!; in the restoration process and N=1,000,000.

Hao-Tian Wu and Yiu-Ming Cheung watermark, the impact of trivial modifications can be visualized in the extracted watermark image while severe modifications make it meaningless. With the extracted watermark, we can detect the unauthorized modifications and estimate the strength of tampering, if any. In the experiments, the watermarked mesh models went through affine transformations (including translation, rotation and uniformly scaling), modifying one vertex coordinate with the vector {D/500, D/500, D/500), reducing one face from the mesh, adding noise signal that is uniformly distributed within [-S,SI to all vertex coordinates, and cropping 0.1% faces of the mesh model. The processed mesh models after these operations are shown in Fig. 4 (from Fig. 4c to Fig. 4g), respectively. The watermarks are

Figure 4a. The original mesh model "dog"

Figure 4c. The watermarked mesh model after modifying one vertex position

Figure 4b. The watermarked mesh model

Figure 4d. The watermarked mesh model after reducing one face


Figure 4e. The watermarked mesh model after adding noise

521

Figure 4f:The watermarked mesh model after cropping 0.1% faces

Figure 4g. The watermarked mesh model after affine transformations

extracted from the processed mesh models with and without the key and the NC values between the original and the extracted watermarks are calculated using Eq. (1 1). The results are listed in the Table 2.

CONCLUSION In this paper, we have proposed a new fragile mesh watermarking method to authenticate the integrity of 3D mesh model. The watermarking process is conducted in spatial domain and applies to all the mesh models without any restriction. The experimental results have demonstrated that the proposed method is able to imperceptibly and adaptively embed a considerable amount of information into the mesh model, and the embedded watermark can be blindly extracted from the watermarked mesh model to authenticate the watermarked mesh model. In our method, the distortion introduced by the encoding process is quite small and can be controlled

522

Hao-Tian Wu and Yiu-Ming Chezmg

within a predefined range. Compared to the previous works, the embedded watermark using our method is invariant to integrity-reserved affine transformation, but sensitive to other processing that alters the mesh model. Therefore, unauthorized modifications of the mesh models can be successfully detected and estimated.

ACKNOWLEDGEMENT For the use of the 3D models, we would like to thank the web sources of Department of Computer Science, the University of North Carolina at Chapel Hill, USA. Also, many thanks go to Dr. Zheming Lu for helpful discussions at Harbin Institute of Technology, China.

REFERENCE 1. B. Chen and G. W. Wornell, Quantization index modulation: A class of provably good methods for digital watermarking and information embedding, IEEE Trans. Inform. Theory, 47, 1423-1443 (2001). 2. B. Chen and G. W. Womell, Digital watermarking and information embedding using dither modulation, ZEEE Second Workshop on Multimed~aSignal Processing, 273-278 (1 998). 3. Z. Q. Yu, H. H. S. Ip and L. F. Kwork, A robust watermarking scheme for 3D triangle mesh models, Pattern Recognition, 36(12),2603-2614 (2003). 4. M. M . Yeung and B. L. Yeo, Fragile watermarking of three dimensional objects, Proc. 1998 Int'l Con$ Image Processing, ZCIP98,2,442-446 (IEEE Computer Society, 1998). 5. B. L. Yeo and M. M. Yeung, Watermarking 3D objects for verification, IEEE Comput. Graph. Applicat, 36-45 (1999). 6. F. Cayre and B. Macq, Data hiding on 3D triangle meshes, ZEEE Trans. Signal. Processing, 51(4),939-949 (2003). 7. HsuehYi Lin, Hongyuan Mark Liao, ChunShien Lu and JaChen Lin, Fragile Watermarking for Authenticating 3D Polygonal Meshes, Proc. 16th IPPR Conf on CVGZP, 298-304 (2003 ). 8. C. Fomaro and A. Sanna, Public Key Watermarking for Authentication of CSG Models, Computer-Aided Design, 32,727-735 (2000). 9. 0. Benedens, Watermarking of 3D polygon based models with robustness against mesh simplification, Proc. SPZE: Security Watermarking Multimedia Contents, 329-340 (1999). 10. 0. Benedens, Geometry based watermarking of 3D models, ZEEE Comput. Graph., Special Issue on Image Security, 46-55, JanJFeb. 1999. i 1. 0. Benedens, Two high capacity methods for embedding public watermarks into 3D polygonal models, Proc. Multimedia Security Workshop ACM Multimedia, 95-99 (1999). 12. 0. Benedens and C. Busch, Toward blind detection of robust watermarks in polygonal models, Proc. EUROGRAPHZCS Comput. Graph. Forum, 19(C), 199-208 (2000). 13. M . G. Wagner, Robust watermarking of polygonal meshes, Proc. Geometric Modeling Processing, Hong Kong, 201-208 (2001).


523

14. R. Ohbuchi, H. Masuda and M. Aono, Watermarking Three Dimensional Polygonal Models, Proc. ACMMultimedia, Seattle, 261-272 (1997). 15. R. Ohbuchi, H. Masuda and M. Aono, Watermarking Three Dimensional Polygonal Models Through Geometric and Topological Modifications, ZEEE J. Select. Areas Commun., 16,551-560 (1998). 16. R. Ohbuchi, H. Masuda and M. Aono, Geometrical and Non-geometrical Targets for Data Embedding in Three Dimensional Polygonal Models. Computer Communications, Elsevier, 21, 1344-1354 (1998). 17. R. Ohbuchi, H. Masuda and M. Aono, A shape preserving data embedding algorithm for NURBS curves and surfaces, Proc. Comptlt. Graph. k t . , June, 1999. 18. R. Ohbuchi, S. Takahashi, T. Miyasawa and A. Mukaiyama, Watermarking 3D polygonal meshes in the mesh spectral domain, Proc.Graphics Interface, Ottawa, 9- 17 (2001). 19. H. Date, S. Kanai and T. Kishinami, Digital watermarking for 3D polygonal model based on wavelet transform, Proc. ASME Des. Eng. Techn. Conj, Sept 1999. 20. S. Kanai, H. Date and T. Kishinami, Digital watermarking for 3D polygons using multiresolution wavelet decomposition, Proc. Sixth Int. Workshop Geometric Modeling: Fundamentals Applicat., Sept 1998. 21. E. Praun, H. Hoppe and A. Finkelstein, Robust mesh watermarking, Proc. SIGGRAPH, 69-76 (1999). 22. Kangkang Yin, Zhigeng Pan, Jiaoying Shi and David Zhang, Robust mesh watermarking based on multi-resolution processing, Computers & Graphics, 25,409-420 (2001). 23. F. Cayre, P. RondaoAlface, F. Schmitt, B. Macq and H. Maitre, Application of Spectral Decomposition to Compression and Watermarking of 3D Triangle Mesh Geometry, Signal Processing: Image Communications, 18(4), 309-3 19 (2003). 24. Liangjun Zhang, Ruofeng Tong, Feiqi Su and Jinxiang Dong, A Mesh Watermarking Approach for Appearance Attributes, PacEfic Conference on Computer Graphics and Applications, Beijing, 450-451 (2002). 25. H. Hoppe, T. DeRose, T. Duchamp, J. McDonald and W. Stuetzle, Mesh optimization, Computer Graphics (SIGGRAPH '93 Proceedings), 19-26 (1 993). 26. Z. Kami and C. Gotsman, Spectral compression of mesh geometry, Proc. SIGGRAPH, 279-286 (2000). 27. I. Guskov, W. Sweldens and P. Schroeder, Multi-resolution signal processing for meshes, Proc. SIGGRAPH, 325-334 (1999). 28. P. J. Burt and E. H. Adelson, Laplacian pyramid as a compact image code, ZEEE Transactions on Commtmications, 532-540(1983).

NEW PARADIGM IN GRAPH-BASED VISUAL SECRET SHARING SCHEME BY ACCEPTING REVERSAL IN BLACK-WHITE IMAGES

Yuji SUGA Canon Znc., PF Technology Development Center, 30-2, Shimomaruko 3-Chome, Ohta-kzr, T o b o 146-8501, Japan

Abstract:

The visual secret sharing scheme (for short the VSS scheme) with access structure based on graph has been proposed as one of the (2,n)-threshold visual secret sharing schemes. Ateniese et al.' showed a decomposition method into star graphs from a given graph which edges are specified by qualified sets, that is, two different participants (two vertices in the graph) have a common edge if and only if they can decrypt the secret image by stacking each share images. In this paper, we expand the definition of black-white visual secret sharing scheme and propose new decomposition methods by splitting complete npartite graphs. These methods improve contrast of the decoded secret image. Moreover, we obtain several optimal examples and evaluate on graph-based VSS schemes.

Key words:

visual secret sharing scheme; n-partite graph; complete n-partite graph

1.

INTRODUCTION

The visual secret sharing scheme (abbreviated as VSS scheme) proposed by Naor and ~hamir"is a method to distribute secret image S into n shadow images wi (1 = 51 I error(lNV-ID).

Figure I. Statechart model of the purse applet.

The transition labels between two states s, and s2 are of the form:

with i being an input event, g being a guard, and act representing a sequence of actions. We exemplify the semantics with this transition:

The input event (i) is credit (n). The argument n represents the amount of money to be added to the card. The applet uses signed 16-bit integer shorts and it gives an error ( INV-PARAM) on negative values. We abstract fiom that in the Statechart to keep it concise. The actual value of the card is saved in the variable value. A transition can only fire when the corresponding guard g holds. In this example, one can only increase the value of the card by n, when n does not exceed the MAXVALUE-value.If the

568

Arjen van Weelden, Martijn Oostdijk, Lars Frantzen ..

transition is taken, the actions act are performed. In this case, the variable value is incremented by n, the tries variable is reset to zero, and the acknowledgment ackOK is sent to the terminal.

Intuitively, the purse works as follows. At first, the card is in the Uninitialized state. It is initialized by the credit institution, which issues the card to the customer by putting a certain amount n of money on it via the setvalue (n)event. In the Initialized state the customer can query the actual value via the getvalue ( ) event, or pay with the card via the debit (n)event. To increase the value, one must first authenticate at a terminal with a card-specific pin, leading to the Authenticated state. Being in that state, one can add money via the credit (n) event, leading back to the Initialized state. The card

checks that its value does not exceed the MAXVALUE. Furthermore, there is a maximum of five tries to enter the pin. After the fifth wrong attempt, one can no longer credit the card. If the credit institution enters the reset code (called puk) correctly, the card goes back to the Uninitialized state and can be re-initialized via the setvalue (n)event. If the puk is entered wrongly, the card goes to the Invalid state and cannot be used anymore. Two kinds of erroneous events can be sent to the card. Firstly, a syntactically correct input event that is not specified for the actual state may occur, e.g., a credit (n)when the card is in the Initialized state. Such an unspecified input event is called an inopportune event, and the response of the applet should be an error message error ( INV-CMD) , whereas the applet remains in its actual state. Secondly, a syntactically incorrect event may occur, e.g., a command-APDU with a non-existing event-code. This is also implicitly assumed to lead to an error message, while the card stays in its current state.

3.

THE TEST TOOL GAST IN A NUTSHELL

The test tool GAST is designed to be open and extendable. For this reason it is implemented as a library rather than a standalone tool. The functional programming language Clean is chosen as host language due to its expressiveness. GAST can handle two kinds of properties. It can test properties stated in logic about (combinations of) functions. GAST can also test the behavior of reactive systems based on Extended (Finite) State Machines, E(F)SM. Here we will only discuss the ability to test reactive systems. An ESM as used by GAST comes quite close to the Statechart of Figure 1. It consists of states with labelled transitions between them. A transition is

On-the-Fly Formal Testing of a Smart Card Applet

569

of the form s ' l o > t , where s, t are states, i is an input which triggers the transition, and o is a, possibly empty, list of outputs. The domains of the inputs, outputs, and states can be given by arbitrarily complex recursive Algebraic Data Types (ADT). This constitutes the main difference with traditional testing with FSM's where the testing algorithms can only handle finite domains and deterministic systems4. A transition s "?> is represented by the tuple (s, i, t, 0). A relation based specification 6, is a set of these tuples: 6, c SXIXSXO*. The transition function 6f is defined by 6f(s,i) = { (t, 0) I (s, i, t, 0) E 6, ). Hence, i/o s > t is equivalent to (t, o) E &(s, i). A specification is partial if for some state s and input i we have &(s, i) = 0, otherwise it is total. A specification is deterministic if for all states and inputs the size of the set of targets contains at most one element: # &(s, i) < 1. A trace o is a sequence of inputs and associated outputs from a given state. Traces are defined inductively: the empty trace connects a state to itself: s A s . We can t and a transition f "V >z/ form the target state t, combine a trace s 4 to trace s c r ; i / o >t . We define s "" > = 3t.s i / o >t and s 4= 3 t . s 4 t . All traces from state s are: traces(s) { 01s& }. The inputs allowed in state s are given by init(s) = { iI3o.s ' l o > }. The states after trace o in state s are given by s after o E { t I s 4f ) . We overload traces, init, and after for sets of states instead of a single state by taking the union of the individual results. When the transition function, tif, to be used is not clear from the context, we will add it as subscript. The basic assumption for our formal testing is that the Implementation Under Test, iut, is also a state machine. Since we do black box testing, the state of the iut is invisible. The iut is assumed to be total: any input can be applied in any state. Conformance of the iut to the specification spec is defined as (so is the initial state of spec, and to of iut):

-

iut conf spec r V O E tmcesSpec(s,,),ViE init(s,afterspecO),VOE0** (to aftequ, O)

'lo

> 3 (so afterspec 0 )

ilo

Intuitively: if the specification allows input i after trace o, the observed output of the iut should be allowed by the specification. If spec does not specify a transition for the current state and input, anything is allowed. This notion of conformance is very similar to the ioco relation5 for Labeled Transition Systems (LTS). In an LTS each input and output is modeled by a separate transition. In our approach an input and all induced outputs up to quiescence are modeled by a single transition. Quiescence characterizes a

570


state of the iut that will not produce any output before a new input is provided, i.e. a quiescent system waits for input and cannot do anything else. In order to test conformance, a collection of input sequences is needed. At the beginning of each input sequence GAST resets the iut and the spec to their initial state. By applying the inputs of a sequence one by one, GAST investigates if it can be transformed to a trace of spec. The previous inputs and observed responses are remembered in trace o.If ti spec(^, i) f 0 for the current input i and some state s reachable from the L l :I 6 1 state, So, by trace o (i.e. so A s ) , the input is applied to the iut, and the observed output is checked to be allowed by spec. GAST has several algorithms for input generation, e.g.: Systematic generation of sequences based on the input type. Sequences that cover all transitions in ajinite state machine. Pseudo random walk through the transitions of a specification. User defined sequences. In this paper we will only use the third algorithm to generate input sequences. Testing is on-the-fly, which means that input generation, execution, and result analysis are performed in lockstep, so that only the inputs actually needed will be generated. The lazy evaluation of Clean used for the implementation of GAST makes this easy. Within the test tool GAST, the mathematical state transition fimction, &, specifying the desired behavior is represented by a function in the functional programming language Clean. Functional languages allow very concise representations of specifying functions and have well understood semantics. Using an existing language as notation for the specification prevents the need to design, implement and learn a new language. The rich data types and available libraries enable compact and elegant specifications. The advanced type system of functional languages enforces consistency constraints on the specification, and hence prevents inconsistencies in the specification. Since the specification is a function in a functional programming language, it can be executed. This is convenient when one wants to validate the specification by observation of its behavior. Any Clean type can be used to model the state, the input and the output of the function specifying &, including user-defined data types. GAST uses generic programming techniques for generating, comparing, and printing of these types. This implies that default implementation of these operations can be derived without any effort for the test engineer. Whenever desired, these operations can be tailored using the full power of the functional programming language.

On-the-Fly Fonnal Testing of a Smart CardApplet

4.

THE PURSE SPECIFICATION FOR GAST

The specification given in the Statechart is transformed to the functional language Clean in order to let GAST execute and manipulate it. This section gives some details about the representation in Clean of the electronic purse from Figure 1. Due to space limitations we will only show snapshots of the (executable) specification. A parameterized enumeration type represents the state of the purse ::

PurseState = Uninitialized 1 Initialized Short Short I Authenticated Short / Invalid

We use one constructor for each state from the Statechart in Figure 1. The arguments of the constructor I n i t i a l i z e d represent the tries counter and the value. The type S h o r t represents signed 16-bit integers. This implies that there are actually 216x216= 232different i n i t i a l i z e d states, of which some are not reachable. There are similar types for input and output. A transition function purse, similar to &, in Section 3 models the transitions. The only difference with the mathematical specification is that the result is a list of tuples instead of a set of tuples. Some function alternatives specifying characteristic transitions are: purse : : PurseState PurseInput -> [(PurseState, [PurseOutputl)I purse Uninitialized (Setvalue n) = if (n >= 0 & & n . time inputs until error 0.49 25 31 0.09 0.47 9 0.71 41 0.38 51 1 0.05 1 0.52 4 0.06 2 0.50 23 0.48 26 0.80 13 0.06 21 1.28 16 0.09 24 0.07 33 0.52 29 3.82 23 0.26 6 0.30 44 0.18 4 0.50 0.67 2 0.56 -- 19.5 4.20 n/a

comments

0

6 tries allowed in this mutant incorrect overflow during credit negative balance allowed in mutant tries not reset after authenticate tries not reset after reset credit allowed without authenticate setvalue ( 0 ) not allowed credit with negative amount allowed debit with negative amount allowed no check for locked flag not locked after 5 attempts stays authenticated not locked after reset MAXVALUE too low authenticate does not authenticate reset does not make it uninitialized tries 5 5 instead of tries < 5 fresh card has nonzero balance setvalue allowed in initial state setvalue does not initializediunlock MAXVALUE too high MAXVALUE balance not allowed averages original applet, no counterexample

574


For instance, mutant 17 differs from the ideal applet by testing whether the number of remaining authentication tries is less than or equal to five rather than less than five before setting a flag indicating that the applet should no longer accept authentication attempts. This mutant was found after executing 94 paths, within 3.82 seconds, containing 4757 transitions in total. This mutant showed an invalid output after an input sequence of length 29 in path 94. To identify the error, the trace of inputs and associated responses are written to a file. GAST was able to identify the 22 incorrect implementations without any help, using a minimum path length of 50 transitions and a maximum of 100 paths. It took an average of 0.56 seconds to generate and execute, on average, 366 transitions on a 1.4GHz Windows computer. Identifying incorrect behavior for all 22 mutants cost only 12 seconds in total. This shows that GAST is an efficient and effective test tool.

RELATED WORK Two approaches are closely related to ours due to the fact that both rely on tools that implement variants of the ioco testing relation5. Du Bousquet and art in^ use UML specifications, which are translated into Labeled Transition Systems to serve as input for the TGV tool7. Instead of an on-thefly execution, TGV uses additional test purposes to generate test cases. The authors created a tool to automate the generation of test purposes based on common testing strategies. The generated test cases are finally translated into Java code, which communicates with the applet and executes the test. TGV does not treat data symbolically, which can easily lead to a state space explosion when dealing with large data domains. Because we generate test cases on-the-fly based on the (symbolic) EFSM, this problem does not occur. To support symbolic treatment of data, Clarke et use InputIOutput Symbolic Transition Systems. The basic approach is similar to TGV, hence also here test purposes are needed. The test automation is done via a translation to C++ code, which is linked with the implementation. This restricts the IUT to be a C++ class with a compatible interface. Rather than testing properties of the IUT, its implementation (i.e., the Java Card applet) can also be formally verified. Testing and verification are complementary techniques to check the correctness of systems, as explained in Section 1. A common technique used for verifying Java Card applets is to prove their correctness with respect to a specification in the Java Modeling Language (JML). State-based specifications similar to the one in Figure 1 can uniformly be translated to JML specifications, as shown by Hubbers,

On-the-Fly Formal Testing of a Smart Card Applet

575

Oostdijk, and poll9. The resulting annotated Java Card applet can then be verified using one of the many JML toolsi0,for instance, the ESCJava2 static analyzer". Most Java Card applets are small enough to even attempt a formal correctness-proof using the Loop tool, as demonstrated by Jacobs, Oostdijk, and warnier12.

8.


We have presented an approach to automate the testing of Java Card applets using the test tool GAST. The test case derivation is based on a Statechart specification of the applet under test. The specification can directly be translated into a corresponding GAST specification. Tests were completely automatically derived, executed, and analyzed. Discrepancies between the formal specification and its Java Card implementation were successfully detected, which shows the feasibility of this approach. The direct translation from the Statechart model to the GAST specification, and the on-the-fly execution of the test cases enable the developer to start with automatic testing of the applet in the early stages of development. The co-development of the formal model and the implementation, and the facility to do automatic tests, has shown to be very useful. Both the code and the specification have evolved simultaneously, vastly improving the quality of the applet, and leading to a complete and reliable specification. Such a specification delivers insight on how to specify similar cases, and can serve as a pattern for these. The tested mutants, representing typical programming errors, have increased our confidence in the error detecting power of the GAST algorithm. We are planning to compare this with other test tools, e.g., the ioco-based tool T O ~ X 'to~ ,test more complex applets, testing applets on real cards, and testing advanced aspects like the integration, interference, and feature interaction between different applets on one card. Finally, we will compare the testing approach with the formal verification approach, e.g., using JML, to see how far we can get in unifying verification and testing techniques into one common framework, and to investigate the precise shape of their complementarities.

REFERENCES 1 UML resource page. h t t p : / /www. urn1 . o r g . 2 P. Koopman and R. Plasmeijer. Testing reactive systems with GAST. In S. Gilmore, editor, Trends in Functional Programming 4, 1 1 1-129 (2004)

576

Arjen van Weelden, Martijn Oostdijk, Lars Frantzen ...

3 R. Plasmeijer and M. van Eekelen. The Concurrent Clean Language Report, version 2.0. http://www.cs.kun.nl/-clean. 4 D. Lee and M. Yannakakis. Principles and methods of testing finite state machines - a survey. Proc. IEEE, 84(8): 1090--1126 (1996) 5 J. Tretmans. Test generation with inputs, outputs and repetitive quiescence. SofhvareConcepts and Tools, 17(3): 103-120 (1 996) 6 L. du Bousquet and H. Martin. Automatic test generation for Java-Card applets. In 4th Workshop on Toolsfor System Design and Verification, (2000) 7 C. Jard and T. Jeron. TGV: theory, principles and algorithms. In IDPT '02, Pasadena, California, USA, Society for Design and Process Science (2002) 8 D. Clarke, T. Jeron, V. Rusu, and E. Zinovieva. Automated test and oracle generation for smart-card applications. In Proceedings of the International Conference on Research in Smart Cards, volume 2 140 of LNCS, 58-70, Cannes, France (2001) 9 E. Hubbers, M. Oostdijk, and E. Poll. From finite state machines to provably correct java card applets. In D. Gritzalis, S. De Capitani di Vimercati, P. Samarati, and S.K. Katsikas, editors, Proceedings of the 18th IFIP Information Security Conference, Kluwer Academic Publishers, 465-470 (2003) 10 L. Burdy, Y. Cheon, D. Cok, M. Emst, J.R. Kiniry, G.T. Leavens, K.R.M. Leino, and E. Poll. An overview of JML tools and applications. In Th. Arts and W. Fokkink, editors, FMICS '03, volume 80 of ENTCS, pages 73-89 (2003) 11 D. Cok and J. Kiniry. ESClJava2: Uniting ESClJava and JML: progress and issues in building and using ESCIJava2. Submitted for publication (2004) 12 B. Jacobs, M. Oostdijk, and M. Warnier. Source code verification of a secure payment applet. JLAP, 58: 107--120 (2004) 135 . Tretmans and E. Brinksma. TorX: Automated model based testing. In A. Hartman and K. Dussa-Zieger, editors, First European Conference on Model-Driven Software Engineering. Imbuss, Mohrendorf, Germany (2003)

A COMPUTATIONALLY FEASIBLE SPA ATTACK ON AES VIA OPTIMIZED SEARCH Joel ~ a n ~ a v e nMark ', reh hob^, and Kevin J. compton3 EECS Department University of Michigan - Ann Arbor Ann Arbor, MI 481 09-2122, USA '[email protected], [email protected],[email protected]

Abstract:

We describe an SPA power attack on an 8-bit implementation of AES. Our attack uses an optimized search of the key space to improve upon previous work in terms of speed, flexibility, and handling of data error. We can find a 128-bit cipher key in 16ms on average, with similar results for 192- and 256bit cipher keys. The attack almost always produces a unique cipher key and performs well even in the presence of substantial measurement error.

Keywords:

AES, SPA, Rijndael, power attack.

1.

Introduction

In 2001 the National Institute of Standards and Technology selected the block cipher Rijndael as the Advanced Encryption Standard (AES), making it the standard for private key encryption. A cryptographic attack on AES, such as linear or differential cryptanalysis, appears intractable at this time. Therefore, some researchers have investigated side-band attacks, which use information about the physical manifestation of the hardware or software implementing the algorithm [I, 2, 61. Side-band attacks assume access to the hardware performing the encryption. Timing attacks, proposed in 1996, assume only the ability to time the encryption (or perhaps sub-portions of the encryption) [4]. Such attacks are relatively easy to thwart by writing encryption software that uses a fixed sequence of operations. Power attacks, another style of side-band attack, are more difficult to thwart. The most common power attacks assume

578

Joel VanLaven, Mark Brehob, and Kevin J. Compton

the ability to observe the power utilization of the processor or ASIC over time [5]. Power attacks provide both high-level information about the operations being performed on the chip and low-level information about the data being operated upon. The high-level information is similar to timing information and can be dealt with in a similar way. Low-level information about the data arises from sources such as asymmetry in the efficiency of the n and p transistors or the flipping of bits on a bus or in a register. Without great care in the chip design and addition of power inefficiencies, a CMOS chip will use a slightly different amount of power based on the data being calculated [8]. Microprocessors operate on a fixed number of bits at a time (usually words or bytes), so what is actually revealed is the sum of the bits, or the Hamming weight of the data. The two main variants of power attacks are differential power analysis (DPA), which requires the plaintexts or ciphertexts in addition to the power traces for many encryptions with the same key; and simple power analysis (SPA), which exposes the secret key solely from power traces [5]. While in theory most SPA attacks could reveal the key from a single encryption, poor signal-to-noise ratio forces averaging of the error over many encryptions with the same key. DPA is applicable to most ciphers and implementing such an attack is relatively straightforward. SPA is greatly affected by the design of a cipher and the susceptibility of a cipher to this style of attack may not be obvious. This paper details an SPA power attack on an %-bit implementation of AES. We assume that the Hamming weights of the bytes of the expanded key can be measured, possibly with some error. Our approach exploits regularities in the AES key schedule, which could likely be utilized even if different information more specific to the implementation is exposed. It improves upon a previously published attack by Mangard [6] in terms of speed, flexibility, and handling of measurement error. Specifically our algorithm improves upon this work in four ways. It runs approximately 20000 times faster. It nearly always finds a unique solution rather than a handful of candidate solutions. It works on cipher-key sizes of 192 and 256 in addition to 128 bits. It performs well under a more realistic error model. Table I . Time and Discovery Rate of Cipher Keys 128-bit key no error Average time 16ms % of attacks with a unique solution 100%

256-bit key no error 20ms 99.97%

128-bit key with error /o = 0.25) 35s 96%

A Computationally Feasible SPA Attack on AES via Optimized Search

579

With regard to the second item, the previous work required a ciphertext1 plaintext pair to find the correct solution, thus negating a primary advantage of an SPA attack. While the algorithm in this paper cannot guarantee a unique solution, our results show that even with significant errors in the data, it almost always finds a unique solution. Table 1 provides a summary of our results.

2.

AES

In private-key cryptosystems such as AES, both the sender and receiver of a message require access to the same secret key. Public-key cryptosystems allow the sender and receiver to use different keys, only one of which needs to be secret, but require significantly more computational power as well as a significantly longer key. AES (like the DES standard that it replaced) is an iterative block cipher. This means that the data is manipulated in series of "mini-encryptions," called rounds, each of which uses its own key. In order to generate these round keys the AES algorithm expands the 128-, 192-, or 256-bit private key (also called the cipher key) into the needed number of 128-bit round keys using the key expansion algorithm described below.

Key Expansion in AES Our attack exploits the relationships between the round keys resulting fi-om patterns in the key expansion algorithm. As such, it is necessary to carefully describe the algorithm found in the AES specification [3]. The key expansion algorithm is slightly different depending upon the cipher key size. Though our attack works on all three different key sizes, for simplicity we will discuss only the 128-bit key expansion (which is the most commonly used). The 192-bit and 256-bit key expansions are similar, and the results of attacks on those key sizes are summarized in section 5. The 128-bit cipher key is expanded into eleven 128-bit round keys, each of which can be thought of as 16 bytes arranged in a 4-by-4 block. Each successive round key is simply a transformation of the previous round key. Define RK[N, R, CJ for N = 0 ,...,10, R = 0 ,...,3 and C = 0 ,...,3, to be the byte found in the N-th round key at row R and column C. The first round key (i.e.


580

the round key for N = 0) is a copy of the 128-bit cipher key. When N > 0, the round key RK[N, R, C] is equal to 24

I

RK[N-l,R,C]ORK[N,R,C-l],if C>0; RK[N - 1,R, C] O SB[RK[N - 1,R - 1,311, if R > 0 and C = 0; RK[N -1, R, C] O SB[RK[N - 1,3,3]0RC[N], if R = 0 and C = 0.

Here O is the XOR function; SB is an invertible function, called the subbyte function, which maps bytes to bytes; and RC[N] is the N-th round constant, a fixed value independent of the cipher key. The AES standard gives the precise definitions of SB and RC[N]. Each byte other than those in the cipher key is computed from exactly two other bytes. For example, when N>OandC>O,

but then we also have

That is, the computational relationship between bytes is symmetric in the sense that each of the bytes is computable from the other two. This is also true in the cases where N > 0 but C # 0, the only difference being that we have slightly more complicated expressions involving the SB function and RC[N] constants. We picture all of these computational relationships in the hypergraph of Figure 1.

24

The notation here is not the same as the round key function wij]in [3]. The relationship between the two notations is RK[ArJ,q = W[-Rmod 4 , 4 N + C]. Our notation was chosen to make our description of the key schedule structure clearer.


58 1

Figure 1. The Key Schedule Hypergraph for 128-bit Cipher Keys

A hypergraph is a pair (V, E) where V is the vertex set and E c 2 ' is the hyperedge set. If we require that all hyperedges contain exactly two vertices, we have the usual definition of a graph. In our hypergraph, the vertices are the bytes of the round keys and the hyperedges are the 3-element sets of computationally related bytes. The ovals in the diagram represent the vertices of the hypergraph. For clarity, we have not labeled every vertex in the diagram. In the row labeled N,O,O, for example, the eleven vertices should be labeled (o,o,o>,(l, ~ ~ ~ ) 7 ( ~ 7 ~ 7 ~ ) , . . . , ( ~ ~ 7 ~ , ~ >

respectively. The figure shows a blowup of a small section of the hypergraph with the vertices labeled. The shaded triangles represent the hyperedges; the light shaded triangles represent the hyperedges where the subbyte relation is not used to compute the computational relationship. For example, since

we have a light hyperedge {(1,0,1),(0,0,1),(1,O,O)], which is the upperleftmost shaded triangle. From

we get a dark shaded hyperedge {(I,1,0),(0,1,O),(O,O,3)).

582

Joel VanLaven, Mavk Bvehob, and Kevin J. Compton

The bytes of the cipher key RK[O,O,O],RK[O,O,1],...,RK[0,3,3] are assigned to the vertices along the left edge of the diagram. The slightly fuzzy row of vertices at the bottom of the diagram is the same as the top row of vertices; that is, the diagram should "wrap around" and the first and last rows be identified.

3.

Optimizing Search for a Cipher Key

We now give a precise statement of the SPA Key Schedule Problem (in the case of 128-bit cipher keys). Divide a cipher key of 128 bits into 16 bytes RK[O,O,O] to RK[0,3,3] and compute bytes RK[N,R,q as described in section 2. Given just the Hamming weights of these bytes, determine the original 128-bit cipher key. An exhaustive search, cycling through the 2128possible cipher keys, is clearly infeasible. Even if we cycle through only those keys where each byte of the cipher key has the correct Hamming weight, the number of possible keys could be as large as 298,still far too large to search. We need to utilize the Hamming weights of the entire expanded key to reduce the search space to a manageable number of keys. A naive approach would be to search for the cipher key by sequentially assigning possible values for the bytes RK[O,O,O] to RK[0,3,3] (i.e., those bytes for which N = 0) and checking consistency with the Hamming weight information after each assignment. Inspection of Figure 1 shows that this is little better than an exhaustive search. After we have assigned values to RK[O,O,O] and WO,O,l], for example, we have no further information about Hamming weights of other bytes in the key schedule since they do not belong to a common hyperedge. Suppose, instead, that we assign possible values for RK[O,O,O] and RK[1,0,0] corresponding to vertices in the bottom row of the hypergraph. We can then compute RK[0,3,3] and check three values (rather than just two as before) for consistency with the Hamming weight information. This improves on exhaustive search because it eliminates many possible assignments. This is the main idea behind our search sequence optimization.


583

Figure 2. A Fragment of the Key Schedule Hypergraph

Systematic use of this idea results in a highly optimized search. Consider the small fragment of the hypergraph in Figure 2. Suppose we have assigned values consistent with the Hamming weight information for the six shaded vertices. If we then make an assignment to vertex A, we can compute values for vertices B, C, and D, then check that these values are consistent with the Hamming weights. Notice also that if we have values assigned to the six shaded vertices, assigning a value to any one of the vertices A, B, C or D allows us to compute values for the other three. Thus, there are many ways to choose a sequence so that the maximum number of byte values can be computed after successive assignments to vertices in the sequence. However, it is not difficult to see that after each assignment (for at least the first 11 assignments), the pattern of computable values will be a triangular array of the type shown in Figure 2. That is, we can find a vertex sequence So,SI,...,SISso that after values have been assigned to So,...,S,, we can compute (i+l)(i+2)/2 byte values in a triangular array. When i 2 11 a complete triangular array will not fit horizontally in the hypergraph shown in Figure 1 so the increase in the number of computable values is not as great. However, by this stage so many values are determined that maximizing the number of computable values is not so important (Figure 4 illustrates this). After assignments to SO,...,SI5,all 176 bytes can be computed because of the wrap-around in the hypergraph. Besides maximizing the number of computable values after each assignment, speedups can be gained by taking advantage of information available from the subbyte operation used in the dark hyperedges. Maximizing the number of dark hyperedges contained within the triangular array of computable values results in additional pruning in the early stages of the search. This can give approximately an order of magnitude speedup. Because the subbyte is applied to the top vertex in any dark hyperedge, it is possible to easily extract this information without determining the two lower vertices of such a hyperedge. Maximizmg the number of top vertices of dark


584

hyperedges determined instead of whole dark hyperedges, allows a further speedup by a factor of about 2. The search sequence we use is: (9,0,3), (8,0,3), (7,0,3), (6,0,3), (5,0,3), (4,0,3), (3,0,3), (2,07317 (1,0,3), (0,0,3), (0,1,0), (0,l ,I), (0,1,2), (0,1,3), (0,2,0), (0,2,1). There are many other optimal sequences. We can now give a precise description of the search algorithm. Let So,S1,...,SISbe a fixed optimal search sequence of 16 vertices as described above. Suppose that at some time during the search, values have been assigned to So,...,Si and are stored in a global array A. Let consistent ( i) be a Boolean function that returns true precisely when the values computed from these i-tl values are consistent with the Hamming weight information and the information from dark hyperedges mentioned in the previous paragraph. Thus, when i < 11, consistent checks the consistency of (i+l)(i+2)/2 values.25 The search algorithm is a standard backtrack algorithm. Pseudocode for a recursive version of the algorithm is given in Figure 3. (Our implementation was iterative, to optimize performance, but the recursive version here is a little more transparent.) Function search (n) cycles through possible assignments to S,, storing them in an array A at index n.For those bytes that are consistent with the Hamming weight information, the search goes on to search (n+l). For those that are not consistent, it goes on to the next possible byte. If all the bytes have been checked, it returns to the last calling search. Whenever n reaches 16, it writes out a possible solution stored in A. To run the algorithm we initially call search ( 0 ) .

void search (n) {

if (n==16) write A; else f oreach byte w {

A [nl =w; if (consistent(n)) search (n+l);

Figure 3. Pseudocode for the Recursive Search Algorithm

25

In fact, it is really only ,iecessary to check the consistency of the i+l values added since the last consistency check.


585

The Attack in the Presence of Error While work by Mayer-Sommer has shown that it is possible to determine Hamming weights in "an unequivocal manner" [7], measurement and data collection will inevitably have an associated error rate. We model this error by adding Gaussian noise with a mean of zero for each of the measured Hamming weights. This model is reasonable, because even if the actual distribution of noise for a single run is not Gaussian, averaging a number of independent noise measurements together should yield an overall distribution that approaches Gaussian. A mean of zero should be obtainable as part of the method used to calibrate the measurements of the Hamming weights. The measured Hamming weights with this error assumption will be realvalued rather than discrete. Further, it is not possible to search for the exact key that matches the given Hamming weights: all keys match, but some keys are more likely than others. Our attack provides all cipher keys (if any exist) whose round key expansions have Hamming weights differing from the measured Hamming weights by less than some bound (using a sum of the squares metric). Given our assumptions about the nature of the error, the sum of squares difference is a maximum likelihood estimator. This means that any key not reported is less likely than any key that is reported. The bound can be chosen to guarantee with some confidence (e.g. 95%), given an expected amount of error, that the true key will be returned.

Changes to the Algorithm When dealing with error, the definition of the function consistent from Figure 3 needs to be modified. Specifically, consistent will return false if the assignment to Sn gives a sum-of-squares difference greater than a certain bound. Our implementation computes an optimistic estimate of this value. It is computed as the sum of two values: The sum of squares difference between the Hamming weights of those bytes determined by Sn and their measured values. The minimum sum of squares difference between the measured values of all those bytes which are not determined by S, and the integer values closest to those measured values. The bound is determined by adding a fixed value based on desired confidence to the minimum sum-of-squares difference between the measured values and the integer values closest to those values. This method of determining the bound helps to make the work required by the algorithm more uniform than using a fixed bound based on desired confidence.

Joel VunLuven, Murk Brehob, and Kevin J. Compton

5.

Results

We ran all of our simulations on a 5OOMHz Sun Blade 100 with 5 12MB of DRAM. A synopsis of our simulation results can be found in Table 2. As noted in section 4, the bound for the search is determined by the desired confidence given an expected amount of error. The last four entries in the table all assume a different amount of error. The expected amount of error is expressed as a standard deviation of the expected Gaussian noise. For all of the runs with error we targeted a confidence rate of 95%. Table 2. Time and Discovery Rate of Cipher Keys Attack type Average time per attack % of attacks with a unique solution 128-bit no error 16ms 100% 192-bit no error 60ms 100% 256-bit no error 20ms 99.97% 128-bit, o = 0.20 4s 95% 35s 96% 128-bit, o = 0.25 38 min ** 128-bit, o = 0.30 128-bit, o = 0.35 15 hours ** For the entries labeled **, not enough data was collected to provide a meanin&l value

Notice that the run time of our algorithm increases exponentially relative to the expected amount of noise. This is because a higher expected error rate forces us to have a looser bound, and that reduces the amount of pruning of the search space that can be accomplished. Figure 4 graphically shows how large an impact this has. An implication of Table 2 and Figure 4 is when a large amount of noise is present our algorithm's runtime will become untenable. Another interesting result from Table 2 is that the 192-bit implementation takes longer than either the 128 or 256 bit implementations. This is because the 192-bit version of AES has fewer instances of subbyte per expanded key byte than the 128 or 256 bit versions.


587

Figure 4. Average number of calls to search as a function of n

6.

Conclusions and Future Work

We have shown that AES is susceptible to very efficient attacks based solely upon Hamming weights of the bytes of the expanded key. These Hamming weights would likely be exposed in the case of an 8-bit implementation, even if a pre-expanded key were used. Further, this algorithm works well even in the presence of significant Gaussian noise. This work can be extended in the following ways: Modifymg the algorithm to work with 16 or 32 bit implementations without a pre-expanded key. Proving information theoretic bounds about the feasibility of t h s SPA attack on 16 and 32 bit implementations with pre-expanded keys. Significantly improving the algorithm's efficiency in the face of error to handle larger errors. Gathering the data and performing the attack on a real system.

REFERENCES Biham and A. Shamir. Power analysis of the key scheduling of the AES candidates. In Second Advanced Encvption Standard (AES) Candidate Conference, 1999.

588


[2] S. Chari, C. Jutla, J.R. Rao, and P. Rohatgi. A cautionary note regarding evaluation of AES candidates on smart-cards. In Second Advanced Enc~yption Standard (AES) Candidate Conference, 1999. [3] Joan Daemen and Vincent Rijmen. The Design ofRijndae1. Springer-Verlag, 2002. [4] Paul C. Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In CRYPTO, pages 104-1 13,1996. [5] Paul C. Kocher, Joshua Jaffe, and Benjamin Jun. Differential power analysis. In CRYPTO, pages 388-397,1999. [6] Stefan Mangard. A simple power-analysis (SPA) attack on implementations of the aes key expansion. In ICISC, pages 343-358,2002. [7] Rita Mayer-Sommer. Smartly analyzing the simplicity and the power of simple power analysis on smartcards. In CHES, pages 78-92,2000. [8] Jan M. Rabaey. Digital Integrated Cii-cuits: a Design Perspective. Prentice-Hall, Inc., second edition, 2002.

THE PROOF BY 2M-1: A LOW-COST METHOD TO CHECK ARITHMETIC COMPUTATIONS

Sylvain Guilley and Philippe Hoogvorst Ecole Nationale des Teltkommunications, 46, rue Barratrlt, 75634 Paris CEDEX 13, France. E-mail :sylvain.guilley@enstlfr ,[email protected]

Abstract: Injecting faults into an arithmetic device is a way of attacking cryptographic devices.The proof by 2"-1 is a method to detect arithmetic errors induced by this attack without having to duplicate the computations. This method is simple and not too expensive, in terms of computation power when the arithmetic in software and in terms of both silicon surface and power consumption when the arithmetic operations are performed by a hard-wired operator. In that the proof by 2"-1 is well-suited for martcards, in which these resources are limited. The proof by 2"-1 is scalable, in that the designer can choose the parameter m, which determines the level of protection offered and the resources needed for the verification. Key words:

1.

Fault injection, modular computations, Security, Modular Computations

INTRODUCTION

The injection of errors during a cryptographic computation is an efficient attack provided the attacker has access to the target. A smartcard is its typical target. Its power is such that a single uccessful fault induction is enough to break RSA cite [Roneh et al., 1997 Siefert, 20021.

Sylvain Guilley and Philipye Hoogvorst

590

The proof by 2"-I is a self-test method which can verify arithmetic computations either in Z or in Z I n Z , for some (big) integer n and thus detect such fault induction. It is specific to countering fault injection: it does not address any other class of attack, such as DPA [Kocher et al., 19991, SPA, timing attack [Kocher et al., 19961 or E M A [Quisquater and Samyde, 20011. The proof by 2"-1 is scalable, in that the designer can choose the parameter m , which determines the level of protection offered and the resources needed for the verification. All cryptographic applications based on arithmetic operations can take advantage of the proof by 2"-1, such as, [Rivest, Shamir and Adleman, 19781, the Diffie & Hellman protocol [Diffie and Hellman, 19761. Section 2 exposes the principles of using arithmetic residue codes to check arbitrary size arithmetic computations. Section 3 shows the case of decimal computation.Then we switch to a larger modulus. Section 4 exposes how to check modular multiplications. Section 5 concludes the article.

2. Let

PRINCIPLES OF THE PROOF BY y - 1

(z,+,x)

be the ring of integers, M > 1 an integer, ( Z I MZ,;,?)

the

ring of residual classes modulo A4 , and P,(.) be the canonical ring homomorphism

(z,+,x) -+

( Z IMZ,$,?) .

The proof by 2"-1 uses the properties of qw (.) to verify the computations performed by a cryptographic device subject to fault injection with a small computational overhead, which is nearly independent of the size of the operands. Other works [Noufal and Nicolaidis, 19991 use similar concepts but focuses on the synthesis of hardware multipliers. The authors use dedicated structures for fixed-width data paths that cannot be scaled to an arbitrary operand size. Our solution can be implemented using either regular software or off-shelf hardware structures, available in CAD vendors libraries.

The Proof by 2m-I: A Low-cost Method to Check Arithmetic ...

3.

VERIFYING COMPUTATIONS IN Z

3.1

Proof by 9

59 1

When no pocket calculator is available, a simple way exists to check multiplications, which is a lot simpler than doing them twice: the proof by 9, which consists in repeating the multiplication modulo 9. If the actual result of the multiplication and the one obtained with the reduced operands are not congruent modulo 9, one of the results is wrong. Calculating in Z 1 9 2 is easy because any operation involves only 1-digit numbers. As for any positive integer i , 10' is congruent to 1 modulo 9, reducing a number n modulo 9 comes down to adding its decimal digits and reiterating the process until the sum is strictly smaller than 10. At the end a result equal to 9 is replaced by a 0 if necessary. This process is guaranteed to stop because, if n consists p > I digits in base P-1

10, i . e n =

P-1

ni is strictly smaller than n . The

n, 10' , then n'= 0

0

successive sums form a strictly decreasing sequence of integers, which must fall below 10 after a finite number of steps. The process of reduction is roughly linear in complexity with the size of the operands but the complexity of the multiplication in Z 1 9 2 is independent of this size as it always consist of always a single 1-digit by 1-digit multiplication, followed by the reduction of a 2-digit number. The proof by 9 does not prove correctness. To prove correctness the process should be repeated with different prime numbers until the chinese remainder theorem could be used. However P9(x)P9( y ) # P, ( x y ) proves that an error occurred. Otherwise a random mistake is detected with probability 119. In addition, the proof by 9 will detect any error which affects a single digit, except if a 9 was replaced by a 0 or vice versa.

Syfvain Gzdley and Phifippe Hoogvorst

3.2

Proof by M-1

A 119 probability of missing an error is not safe enough for security purposes. Besides, if the operation A x B was to be checked, computing P,(A) and

P, ( B ) would involve a lot of computations, each of them possibly subject to other attacks. However changing the modulus will at the same time yield a much better fault coverage and make it very easy to compute the proof. In particular, any error affecting a single digit in base M will be detected except if a M - 1 is replaced by a zero or vice versa. As no single-bit fault can do that, any single-bit fault will always be detected. Again the cost of the computation modulo M - 1 will be a lot lower than the one of the real computation. The proof by M - 1 is thus a lot cheaper than the repetition of the computations.

3.3

Notations

Let M > 1 an integer. Though M will usually be 2" , with m E {8,16,32,64), we will not use this fact in the rest of the article more than deriving the name of the method from it. An uppercase letter X represents a positive integer, whose base B decomposition is denoted (..., x'"~", x'"~", X [ O ( ~,) in ] which the

)

infinite sequence of integers in [0, B - 11among which only a finite number of them is non-zero. Given a positive integer X , its size in base B , denoted , is the smallest integer x such that x['(~ are)an ]

1xIB

'Jj 2 x, x"'~)' =0. To simplify the notations from now on we will use some shorthands. Unless otherwise specified: the canonical ring homomorphism Z + Z l ( M - l)Z is denoted P(.) instead of P,-,

-

(.) ,

$ and 2 operate in Z l(M - 1)Z,

the digits of X in base M are denoted X i instead of x " ' ~ ] ) , the size o f X in base M is denoted instead of .

1x1

XI,^


3.4

593

Mathematical basis

It is easy to prove that, for any positive integer n and any number M ,

b'n >O,(Mn- 1 ) = ( M - l ) ( M n - ' + M n P 2+...+ M + l ) . Computing modulo M - 1 , this identity becomes: b'n>O,Mn - 1 m o d ( M - 1 ) (1) !'I From Eq. (I), given A = A["M' , the evaluation of A mod ( M - 1 ) 1=0

consists in the addition of the A'" with the following peculiarities: 1. a Carry,,, has weight M , thus is congruent to 1 modulo ( M - I ) , it can be re-injected as the Carryh of the next addition; 2. the reduction ends with the addition of a zero to ensure that the last Carry,,,, is effectively added. This last addition can produce no Carry,,, because, at the preceding addition, each of the operands was at most ( M - 1) .Thus the value of the result was at most 2M - 2 , which can be rewritten as M ( M - 1 ) - 1 and, given than M = 1 mod ( M - I ) , the result of the last addition will be at most (M - 1 ) and no Carry,,, can be generated; 3. at the end if the result is exactly ( M - I), it is replaced by zero. The number of additions needed to reduce a number A modulo ( M - 1) is

+

I A ~ + 1 . It is proportional to log A and inversely proportional to log M .

If this reduction has to be implemented in hardware, the data path consists in a conventional adder, in which the Carry,,, is connected to the Carryi,, together with the control circuitery which instructs the device to perform the final addition of a zero and, if necessary, the replacement of a ( M - 1) by 0.

Checking additions and multiplications in Z

3.5

When computing with integers, the verification process is straightforward: given two operands A and B , an operation * (which can be any of + , or

X)

1. 2. 3. 4.

is performed and verified as follows: evaluate a = P(A) and b = P ( B ) , evaluate R = A * B in 2 , evaluate r = a 2 b in Z l(M - 1)Z, check that P ( R ) = r .

Sylvain Guilley and Philippe Hoogvorst

5 94

The operations involved are: the evaluations of P ( A ) and P ( B ) , which cost

I A ~ +I B ~ +

2 additions, the evaluation of P ( R ) , which costs

I R ~ +1

additions, the operation between a and b , which is a single addition or multiplication, the reduction modulo (M - 1) of the result, which costs two additions at most. Although they add overhead, the reductions of the operands must be performed only once, for the original operands. During the computation the reduced results of any operation will be kept together with the real results for use in the next operations. In that the overhead will be nearly independent of the computation performed.

3.6

Security of the test

Again the proof by 2"-1 can only prove non-correctness: that the results of the integer and of the modular operations are not congruent proves that an error occurred. Otherwise, the probability of an undetected error is exponentially decreasing with lM12 as shown on the table below. 1. Probability of an undetected error 1 ~ 1 2

2. 8

4.

2. 2-' = 3 . 9 2 ~ 1 0 - ~

CHECKING MODULAR COMPUTATIONS

Cryptographic operations seldom involve multiprecision computations in Z itself. Most of the time, the computations are done in Z I n Z , for some integer number n . As there exists no non-trivial ring homomorphism from Z 1nZ into Z l ( M - l)Z (unless n is a multiple of (M - 1) ) the checking of the computations is a little more difficult.

4.1

Modular Addition

Given two operands in Z , A and B , each of them being in [0, N - 11 , their addition modulo N is performed in three steps:


595

1. compute R 1 = A + B i n Z . A s A < N a n d B < N , R 1 < 2 N ; 2. if R 1

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)

Critical Infrastructure Protection (IFIP International Federation for Information Processing) (IFIP International Federation for Information Processing)

Enterprise Information Security and Privacy

Enterprise Information Security and Privacy

Data and Applications Security: Developments and Directions (IFIP International Federation for Information Processing)

Advances in Network and Distributed Systems Security (IFIP International Federation for Information Processing)

Critical Infrastructure Protection II (IFIP International Federation for Information Processing)

Information Processing and Security Systems

Economics of Information Security and Privacy

Role Engineering for Enterprise Security Management (Information Security and Privacy)

Security and protection in information processing systems: IFIP 18th world computer congress : TC11 19th International Information Security Conference, 22-27 August 2004, Toulouse, France

Integrity and Internal Control in Information Systems VI (IFIP International Federation for Information Processing)

Integrity and Internal Control in Information Systems VI (IFIP International Federation for Information Processing)

Evolution of Information Technology in Educational Management (IFIP International Federation for Information Processing)

History of Computing in Education (IFIP International Federation for Information Processing)

Education and the Knowledge Society: Information Technology Supporting Human Development (IFIP International Federation for Information Processing)

Information Security

Information Security and Privacy - ACISP 2011

Information Security

Advances in Digital Forensics III (IFIP International Federation for Information Processing) (IFIP Advances in Information and Communication Technology)

Information Security and Privacy, 10 conf., ACISP 2005

Pathways to Institutional Improvement with Information Technology in Education Management (IFIP International Federation for Information Processing)

Network Control and Engineering for QoS, Security and Mobility, IV: Fourth IFIP International Conference on Network Control and Engineering for QoS, Security ... Federation for Information Processing)

Networked Information Technologies : Diffusion and Adoption (IFIP International Federation for Information Processing)

Handbook of Information Security

Dictionary of Information Security

Handbook of information security,

Enterprise Information Security: Information Security For Non-technical Decision Makers

Information Security and Privacy, 1 conf., ACISP'96

Information and Communications Security

Handbook of information security,

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)

Critical Infrastructure Protection (IFIP International Federation for Information Processing) (IFIP International Federation for Information Processing)

Enterprise Information Security and Privacy

Enterprise Information Security and Privacy

Data and Applications Security: Developments and Directions (IFIP International Federation for Information Processing)

Advances in Network and Distributed Systems Security (IFIP International Federation for Information Processing)

Critical Infrastructure Protection II (IFIP International Federation for Information Processing)

Information Processing and Security Systems

Economics of Information Security and Privacy

Role Engineering for Enterprise Security Management (Information Security and Privacy)

Security and protection in information processing systems: IFIP 18th world computer congress : TC11 19th International Information Security Conference, 22-27 August 2004, Toulouse, France

Integrity and Internal Control in Information Systems VI (IFIP International Federation for Information Processing)

Integrity and Internal Control in Information Systems VI (IFIP International Federation for Information Processing)

Evolution of Information Technology in Educational Management (IFIP International Federation for Information Processing)

History of Computing in Education (IFIP International Federation for Information Processing)

Education and the Knowledge Society: Information Technology Supporting Human Development (IFIP International Federation for Information Processing)

Information Security

Information Security and Privacy - ACISP 2011

Information Security

Advances in Digital Forensics III (IFIP International Federation for Information Processing) (IFIP Advances in Information and Communication Technology)

Information Security and Privacy, 10 conf., ACISP 2005

Pathways to Institutional Improvement with Information Technology in Education Management (IFIP International Federation for Information Processing)

Network Control and Engineering for QoS, Security and Mobility, IV: Fourth IFIP International Conference on Network Control and Engineering for QoS, Security ... Federation for Information Processing)

Networked Information Technologies : Diffusion and Adoption (IFIP International Federation for Information Processing)

Handbook of Information Security

Dictionary of Information Security

Handbook of information security,

Enterprise Information Security: Information Security For Non-technical Decision Makers

Information Security and Privacy, 1 conf., ACISP'96

Information and Communications Security

Handbook of information security,

Recommend Documents