Computer Security -- ESORICS 2009: 14th European Symposium on Research in Computer Security, Saint-Malo, France, September 21-23, 2009, Proceedings ... Computer Science Security and Cryptology)

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

Author: Michael Backes | Peng Ning

36 downloads 1119 Views 10MB Size Report

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

DOWNLOAD PDF

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

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

5789

Michael Backes Peng Ning (Eds.)

Computer Security – ESORICS 2009 14th European Symposium on Research in Computer Security Saint-Malo, France, September 21-23, 2009 Proceedings

13

Volume Editors Michael Backes Saarland University Computer Science Department and MPI-SWS Building E1.1, Campus, 66123 Saarbrücken, Germany E-mail: [email protected] Peng Ning North Carolina State University Department of Computer Science 3320 Engineering Building II, Raleigh, NC 27695-8206, USA E-mail: [email protected]

Library of Congress Control Number: 2009934436 CR Subject Classification (1998): E.3, K.6.5, K.4.4, C.2, D.4.6, H.2.7 LNCS Sublibrary: SL 4 – Security and Cryptology ISSN ISBN-10 ISBN-13

0302-9743 3-642-04443-3 Springer Berlin Heidelberg New York 978-3-642-04443-4 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12755578 06/3180 543210

Foreword from the General Chairs

We warmly welcome everyone to the proceedings of ESORICS 2009, the 14th European Symposium on Research in Computer Security. This year, ESORICS was held in a beautiful walled port city in Brittany in north-western France during September 21–23. We hope that the serenity of Saint-Malo and the high quality of ESORICS 2009 papers facilitated a stimulating exchange of ideas among many members of our international research community. This year, we were pleased to be holding RAID 2009 in conjunction with ESORICS 2009. The conference was followed on September 24-25 by three workshops: DPM 2009 was the 4th International Workshop on Data Privacy Management, SETOP 2009 was the Second International Workshop on Autonomous and Spontaneous Security organized/sponsored by the TELECOM Institute, and STM 2009 was the 5th workshop on Security and Trust Management. Thus, we had a high-quality week of research and debate on computer security. ESORICS 2009 was made possible only through the hard work of many people. Michael Backes and Peng Ning assembled an outstanding Technical Program Committee that reviewed submitted papers and selected an exciting and high-quality technical program. We were most fortunate to have Michael and Peng as Program Chairs to keep ESORICS on a path of academic excellence and practical relevance; we express our sincere thanks to both of them. A debt of thanks is due to our Program Committee members and external reviewers for helping to assemble such a strong technical program. We thank particularly Gilbert Martineau, our Sponsor Chair for his rigorous and unfailing work. We would like also to thank our PHD student, Julien Thomas, who helped us in creating and managing the website. Without the help of the Publicity Chair, ESORICS 2009 would not have had such a success; so, many thanks to Sara Foresti. We are also very grateful to our sponsors: DCSSI, INRIA, Rennes Métropole, Région Bretagne, Fondation Métivier, Saint-Malo, Alcatel-Lucent Bell Labs France, EADS, Orange, TELECOM Institute and CG35. Their generosity helped keep the costs of ESORICS 2009 moderate. We thank everyone, merci, for attending the conference and being a part of this very important event. September 2009

Frédéric Cuppens Nora Cuppens-Boulahia

Foreword from the Program Co-chairs

It is our great pleasure to welcome you to the proceedings of the 14th European Symposium on Research in Computer Security (ESORICS 2009), which was held in Saint Malo, France, September 21–23, 2009. ESORICS has become the European research event in computer security. The symposium started in 1990 and has been organized on alternate years in different European countries. From 2002 it has taken place yearly. It attracts an international audience from both the academic and industrial communities. In response to the call for papers, 220 papers were submitted to the symposium. These papers were evaluated on the basis of their significance, novelty, and technical quality. The majority of these papers went through two rounds of reviews, evaluated by at least three members of the Program Committee. The Program Committee meeting was held electronically, holding intensive discussion over a period of one month since the completion of the first round of reviews. Finally, 42 papers were selected for presentation at the symposium, giving an acceptance rate of 19%. There is a long list of people who volunteered their time and energy to put together the symposium and who deserve acknowledgment. Our thanks to the General Chairs, Frédéric Cuppens and Nora Cuppens-Boulahia, for their valuable support in the organization of the event. Also, to Sara Foresti for the publicity of ESORICS 2009, to Gilbert Martineau for industry sponsorship, to Julien A. Thomas for preparation and maintenance of the symposium website, and to Stefan Lorenz for setting up and maintaining the submission server. Special thanks to the members of the Program Committee and external reviewers for all their hard work during the review and the selection process. Last, but certainly not least, our thanks go to all the authors who submitted papers and all the attendees. We hope that you will find the proceedings stimulating and a source of inspiration for future research. September 2009

Michael Backes Peng Ning

Organization

General Co-chairs Frédéric Cuppens Nora Cuppens-Boulahia

TELECOM Bretagne, France TELECOM Bretagne, France

Program Co-chairs Michael Backes Peng Ning

Saarland University and MPI-SWS, Germany North Carolina State University, USA

Publicity Chair Sara Foresti

University of Milan, Italy

Sponsor Chair Gilbert Martineau

TELECOM Bretagne, France

Web Chair Julien A. Thomas

TELECOM Bretagne, France

Program Committee Mike Atallah Michael Backes David Basin Nikita Borisov Srdjan Capkun Veronique Cortier Marc Dacier Anupam Datta Herve Debar Roger Dingledine Wenliang Du Cédric Fournet Virgil Gligor

Purdue University, USA Saarland University and MPI-SWS, Germany (Co-chair) ETH Zurich, Switzerland University of Illinois at Urbana-Champaign, USA ETH Zurich, Switzerland LORIA, France EURECOM, France Carnegie Mellon University, USA France TELECOM R&D, France The Tor Project, USA Syracuse University, USA Microsoft Research Cambridge, UK Carnegie Mellon University, USA

X

Organization

Guofei Gu Carl A. Gunter Dieter Gollmann Sushil Jajodia Xuxian Jiang Peeter Laud Wenke Lee Donggang Liu Michael Locasto Wenjing Lou Matteo Maffei Heiko Mantel Catherine Meadows John Mitchell David Molnar Peng Ning Alina Oprea Radia Perlman Adrian Perrig Douglas Reeves Kui Ren Mark Ryan Pierangela Samarati Vitaly Shmatikov Wade Trappe Patrick Traynor Dominique Unruh Luca Vigano Dan S. Wallach Andreas Wespi Ting Yu Yanyong Zhang Xiaolan Zhang

Texas A&M University, USA University of Illinois at Urbana-Champaign, USA Hamburg University of Technology, Germany George Mason University, USA North Carolina State University, USA University of Tartu, Estonia Georgia Institute of Technology, USA University of Texas at Arlington, USA George Mason University, USA Worcester Polytechnic Institute, USA Saarland University, Germany University of Darmstadt, Germany Naval Research Laboratory, USA Stanford University, USA University of California at Berkeley, USA North Carolina State University, USA (Co-chair) RSA, USA Sun Microsystems, USA Carnegie Mellon University, USA North Carolina State University, USA Illinois Institute of Technology, USA University of Birmingham, UK Universit` a degli Studi di Milano, Italy University of Texas at Austin, USA Rutgers University, USA Georgia Institute of Technology, USA Saarland University, Germany University of Verona, Italy Rice University, USA IBM Research, Switzerland North Carolina State University, USA Rutgers University, USA IBM Research, USA

External Reviewers Pedro Adao Myrto Arapinis Karthikeyan Bhargavan Bruno Blanchet Johannes Borgstroem Achim Brucker Ahto Buldas

Samuel Burri Ning Cao Sabrina De Capitani di Vimercati Pu Duan Stelios Dritsas Mario Frank

Jason Franklin Deepak Garg Richard Gay Mike Grace Rachel Greenstadt Nataliya Guts Amir Houmansadr

Organization

Sonia Jahid Karthick Jayaraman Guenter Karjoth Emilia Kasper Dilsun Kaynar Felix Klaedtke Panos Kotzanikolaou Dimitris Lekkas Ming Li Alexander Lux Weiqin Ma Yannis Mallios Isabella Mastroeni

Amir Houmansadr Sebastian Moedersheim Tamara Rezk Arnab Roy Silvio Ranise Patrick Schaller Ravinder Shankesi Dieter Schuster Ben Smyth Alessandro Sorniotti Barbara Sprick Henning Sudbrock Michael Tschantz

Marianthi Theoharidou Bill Tsoumas Guan Wang Zhi Wang Zhenyu Yang Yiqun Yin Shucheng Yu Charles C. Zhang Dazhi Zhang Lei Zhang Zutao Zhu

Sponsoring Institutions Alcatel-Lucent Bell Labs EADS France Fondation Métivier CG35 INRIA DCSSI Orange

XI

Rennes Métropole Région Bretagne TELECOM Institute Ville de Saint de Malo

Table of Contents

Network Security I Learning More about the Underground Economy: A Case-Study of Keyloggers and Dropzones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thorsten Holz, Markus Engelberth, and Felix Freiling

1

User-Centric Handling of Identity Agent Compromise . . . . . . . . . . . . . . . . . Daisuke Mashima, Mustaque Ahamad, and Swagath Kannan

19

The Coremelt Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ahren Studer and Adrian Perrig

37

Information Flow Type-Based Analysis of PIN Processing APIs . . . . . . . . . . . . . . . . . . . . . . . . Matteo Centenaro, Riccardo Focardi, Flaminia L. Luccio, and Graham Steel

53

Declassification with Explicit Reference Points . . . . . . . . . . . . . . . . . . . . . . . Alexander Lux and Heiko Mantel

69

Tracking Information Flow in Dynamic Tree Structures . . . . . . . . . . . . . . . Alejandro Russo, Andrei Sabelfeld, and Andrey Chudnov

86

Network Security II Lightweight Opportunistic Tunneling (LOT) . . . . . . . . . . . . . . . . . . . . . . . . . Yossi Gilad and Amir Herzberg

104

Hide and Seek in Time — Robust Covert Timing Channels . . . . . . . . . . . . Yali Liu, Dipak Ghosal, Frederik Armknecht, Ahmad-Reza Sadeghi, Steffen Schulz, and Stefan Katzenbeisser

120

Authentic Time-Stamps for Archival Storage . . . . . . . . . . . . . . . . . . . . . . . . Alina Oprea and Kevin D. Bowers

136

Language Based Security Towards a Theory of Accountability and Audit . . . . . . . . . . . . . . . . . . . . . . Radha Jagadeesan, Alan Jeffrey, Corin Pitcher, and James Riely

152

Reliable Evidence: Auditability by Typing . . . . . . . . . . . . . . . . . . . . . . . . . . Nataliya Guts, Cédric Fournet, and Francesco Zappa Nardelli

168

XIV

Table of Contents

PCAL: Language Support for Proof-Carrying Authorization Systems . . . Avik Chaudhuri and Deepak Garg

184

Network Security III ReFormat: Automatic Reverse Engineering of Encrypted Messages . . . . . Zhi Wang, Xuxian Jiang, Weidong Cui, Xinyuan Wang, and Mike Grace

200

Protocol Normalization Using Attribute Grammars . . . . . . . . . . . . . . . . . . . Drew Davidson, Randy Smith, Nic Doyle, and Somesh Jha

216

Automatically Generating Models for Botnet Detection . . . . . . . . . . . . . . . Peter Wurzinger, Leyla Bilge, Thorsten Holz, Jan Goebel, Christopher Kruegel, and Engin Kirda

232

Access Control Dynamic Enforcement of Abstract Separation of Duty Constraints . . . . . David Basin, Samuel J. Burri, and G¨ unter Karjoth

250

Usable Access Control in Collaborative Environments: Authorization Based on People-Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qihua Wang, Hongxia Jin, and Ninghui Li

268

Requirements and Protocols for Inference-Proof Interactions in Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joachim Biskup, Christian Gogolin, Jens Seiler, and Torben Weibert

285

Privacy - I A Privacy Preservation Model for Facebook-Style Social Network Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Philip W.L. Fong, Mohd Anwar, and Zhen Zhao

303

New Privacy Results on Synchronized RFID Authentication Protocols against Tag Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ching Yu Ng, Willy Susilo, Yi Mu, and Rei Safavi-Naini

321

Secure Pseudonymous Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sebastian M¨ odersheim and Luca Vigan` o

337

Distributed Systems Security Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qian Wang, Cong Wang, Jin Li, Kui Ren, and Wenjing Lou

355

Table of Contents

XV

Content Delivery Networks: Protection or Threat? . . . . . . . . . . . . . . . . . . . Sipat Triukose, Zakaria Al-Qudah, and Michael Rabinovich

371

Model-Checking DoS Amplification for VoIP Session Initiation . . . . . . . . . Ravinder Shankesi, Musab AlTurki, Ralf Sasse, Carl A. Gunter, and José Meseguer

390

Privacy - II The Wisdom of Crowds: Attacks and Optimal Constructions . . . . . . . . . . George Danezis, Claudia Diaz, Emilia K¨ asper, and Carmela Troncoso Secure Evaluation of Private Linear Branching Programs with Medical Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mauro Barni, Pierluigi Failla, Vladimir Kolesnikov, Riccardo Lazzeretti, Ahmad-Reza Sadeghi, and Thomas Schneider Keep a Few: Outsourcing Data While Maintaining Confidentiality . . . . . . Valentina Ciriani, Sabrina De Capitani di Vimercati, Sara Foresti, Sushil Jajodia, Stefano Paraboschi, and Pierangela Samarati

406

424

440

Security Primitives Data Structures with Unpredictable Timing . . . . . . . . . . . . . . . . . . . . . . . . . Darrell Bethea and Michael K. Reiter WORM-SEAL: Trustworthy Data Retention and Verification for Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tiancheng Li, Xiaonan Ma, and Ninghui Li Corruption-Localizing Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Giovanni Di Crescenzo, Shaoquan Jiang, and Reihaneh Safavi-Naini

456

472 489

Web Security Isolating JavaScript with Filters, Rewriting, and Wrappers . . . . . . . . . . . . Sergio Maffeis, John C. Mitchell, and Ankur Taly

505

An Effective Method for Combating Malicious Scripts Clickbots . . . . . . . Yanlin Peng, Linfeng Zhang, J. Morris Chang, and Yong Guan

523

Client-Side Detection of XSS Worms by Monitoring Payload Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fangqi Sun, Liang Xu, and Zhendong Su

539

XVI

Table of Contents

Cryptography Formal Indistinguishability Extended to the Random Oracle Model . . . . Cristian Ene, Yassine Lakhnech, and Van Chan Ngo

555

Computationally Sound Analysis of a Probabilistic Contract Signing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mihhail Aizatulin, Henning Schnoor, and Thomas Wilke

571

Attribute-Sets: A Practically Motivated Enhancement to Attribute-Based Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rakesh Bobba, Himanshu Khurana, and Manoj Prabhakaran

587

Protocols A Generic Security API for Symmetric Key Management on Cryptographic Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Véronique Cortier and Graham Steel

605

ID-Based Secure Distance Bounding and Localization . . . . . . . . . . . . . . . . . ˇ Nils Ole Tippenhauer and Srdjan Capkun

621

Secure Ownership and Ownership Transfer in RFID Systems . . . . . . . . . . Ton van Deursen, Sjouke Mauw, Saˇsa Radomirović, and Pim Vullers

637

Systems Security and Forensics Cumulative Attestation Kernels for Embedded Systems . . . . . . . . . . . . . . . Michael LeMay and Carl A. Gunter Super-Efficient Aggregating History-Independent Persistent Authenticated Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scott A. Crosby and Dan S. Wallach

655

671

Set Covering Problems in Role-Based Access Control . . . . . . . . . . . . . . . . . Liang Chen and Jason Crampton

689

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

705

Learning More about the Underground Economy: A Case-Study of Keyloggers and Dropzones Thorsten Holz1,2 , Markus Engelberth1, and Felix Freiling1 1

Laboratory for Dependable Distributed Systems, University of Mannheim, Germany {holz,engelberth,freiling}@informatik.uni-mannheim.de 2 Secure Systems Lab, Vienna University of Technology, Austria

Abstract. We study an active underground economy that trades stolen digital credentials. In particular, we investigate keylogger-based stealing of credentials via dropzones, anonymous collection points of illicitly collected data. Based on the collected data from more than 70 dropzones, we present an empirical study of this phenomenon, giving many first-hand details about the attacks that were observed during a seven-month period between April and October 2008. We found more than 33 GB of keylogger data, containing stolen information from more than 173,000 victims. Analyzing this data set helps us better understand the attacker’s motivation and the nature and size of these emerging underground marketplaces.

1 Introduction With the growing digital economy, it comes as no surprise that criminal activities in digital business have lead to a digital underground economy. Because it is such a fastmoving field, tracking and understanding this underground economy is extremely difficult. Martin and Thomas [20] gave a first insight into the economy of trading stolen credit card credentials over open IRC channels. The “blatant manner” in which the trading is performed with “no need to hide” [20] is in fact staggering. A large-scale study of similar forms of online activity was later performed by Franklin et al. [10]. The result of this study is that Internet-based crime is now largely profit-driven and that “the nature of this activity has expanded and evolved to a point where it exceeds the capacity of a closed group” [10]. In other words, digital and classical crime are merging. In general, it is hard to estimate the real size of the underground economy. This is because the only observable evidence refers to indirect effects of underground markets. For example, both previous studies [10,20] did not observe real trading, but only announcements of trading and offers of stolen credentials in public IRC channels. It is in fact a valid question how much of the offered data really belongs to online scams— rather than being just the result of “poor scum nigerians and romanians try[ing] to make 20$ deals by ripping eachother off” [3]. In this paper, we report on measurements of the actual kind and amount of data that is stolen by attackers from compromised machines, i.e., we directly observe the goods that can be traded at an underground market. Obviously, this data gives us a much better basis for estimating the size of the underground economy and also helps to understand the attacker’s motivation. M. Backes and P. Ning (Eds.): ESORICS 2009, LNCS 5789, pp. 1–18, 2009. c Springer-Verlag Berlin Heidelberg 2009

2

T. Holz, M. Engelberth, and F. Freiling Bank P1

authenticate using account # / password

keylogger

Victim V1 c1

Attacker A

1

Victim V 2 c2

access with stolen credentials

dropzone 2

Victim V3 c3

2

Webmail P2

Fig. 1. Schematic overview of keylogger-based attacks using dropzones

It may seem as if direct observations of illicitly traded goods are much harder to obtain than indirect ones. In this paper we show that this must not be the case. In particular, we focus on the newly emerging threat of keyloggers that communicate with the attacker through so-called dropzones. A dropzone is a publicly writable directory on a server in the Internet that serves as an exchange point for keylogger data. The attack is visualized in Figure 1. The attacker A first infects victims V1 , V2 and V3 with keylogging malware. This malware secretly collects credentials that victims use to authenticate to online services like a bank P1 or a webmailer P2 . After collecting these credentials, the malware running on a compromised machine sends them to the dropzone, where the attacker can pick them up and start to abuse them [9,30,31,32,34]. We analyzed these keylogger-based attacks by first collecting keyloggers with different techniques such as honeypots [27] or spamtraps, and then executing them within an instrumented environment [37], thereby extracting the location of the dropzone. By accessing the dropzone directly, we harvested the keylogger data just like the attacker would have done this. We perform our case study using two different classes of keyloggers called Limbo/Nethell and ZeuS/Zbot/Wsnpoem. We give details of attacks we observed during a seven-month period between April and October 2008. In particular, we were able to harvest a total of 33 GB of keylogger data from more than 70 unique dropzones, resulting in information about stolen credentials from more than 173,000 compromised machines. We present the results of a statistical analysis of this data. To our knowledge, this is the first time that it has been possible to perform such an analysis on stolen data on such a large scale. It gives rather credible answers to questions about the type and the amount of data criminals steal, which allows us to study the underground economy since these stolen credentials are marketable goods. For example, we recovered more than 10,700 stolen online bank account credentials and over

Learning More about the Underground Economy

3

149,000 stolen email passwords, potentially worth several million dollars on the underground market. Our analysis shows that this type of cybercrime is a profitable business, allowing an attacker to potentially earn hundreds or even thousands of dollars per day. 1.1 Related Work Besides the related work discussed previously, this paper touches on a several related research areas. In the field of phishing prevention and mitigation, there has been some work specific to attacks based on email and fake websites [5,11]. Chandrasekaran et al. [5] generate fake input and investigate a site’s response to detect phishing sites. Gajek and Sadeghi [11] use fake credentials to track down phishers. Our work is complementary to this work: we study the actual dropzone and infer from this data more information about the extent and size of the attack. Recently Kanich et al. studied the conversion rate of spam, i.e., the probability that an unsolicited e-mail will ultimately elicit a sale [15]. This is another example of a direct observation of the underground economy and provides a different point of view into the market mechanisms behind cybercrime. The keylogger-based attacks we study in this paper can be stopped using different kinds of techniques, for example multi-factor authentication, biometrics, or special hardware or software. While techniques like SpoofGuard [7], Dynamic Security Skins [8], or Transport Login Protocol [6] can protect against certain forms of these attacks, e.g., classical phishing attacks, they can not stop keylogger-based attacks that we study in this paper. Preventing this kind of attacks is harder since the user machine itself is compromised, which allows the malicious software to steal credentials directly as the victim performs the login procedure. Modern keyloggers also defeat simple tricks to conceal the entered password as proposed by Herley and Florêncio [12]. However, malware prevention methods and systems that protect confidential information can defend against this kind of attacks [21,35]. 1.2 Summary of Contributions To summarize, our work presented in this paper makes the following contributions: We investigate keylogging attacks based on dropzones and provide a detailed analysis of the collected data, giving a first-hand insight into the underground economy of Internet criminals from a unique and novel viewpoint. We believe that our method can be generalized to many other forms of credential-stealing attacks, such as phishing attacks. We argue that combined with prices from the underground economy, our study gives a more precise estimate of the dangers and potential of the black market than indirect measures performed previously [10,20]. Together with these prior studies, we hope that our results help to relinquish the common mindset we often see with politicians and commercial decision-makers that we do not need to track down and prosecute these criminals because it is too costly. We feel that the sheer size of the underground economy now and in the future will not allow us to neglect it. Paper Outline. We describe in Section 2 in more detail how keylogging based attacks work and introduce two different families of keyloggers. In Section 3, we introduce our

4

T. Holz, M. Engelberth, and F. Freiling

analysis setup and present statistics for the dropzones we studied during the measurement period. We analyze the collected data in Section 4 using five different categories and briefly conclude the paper in Section 5 with an overview of future work. Data Protection and Privacy Concerns. The nature of data analyzed during this study is very sensitive and often contains personal data of individual victims. We are not in a position to inform each victim about the security breach and therefore decided to hand over the full data set to AusCERT, Australia’s National Computer Emergency Response Team. This CERT works together with different banks and other providers to inform the victims. We hope that the data collected during this study can help to recover from the incidents and more damage is prevented.

2 Background: Keylogger-Based Attacks Figure 1 provides a schematic overview of keylogger-based attacks using dropzones. Each victim Vi has a specific credential cij to authenticate at provider Pj to use the service. For example, P1 is an online banking website and V1 uses his account number and a password to log in. The attacker A uses different techniques to infect each victim Vi with a keylogger. Once the victim Vi is infected, the keylogger starts to record all keystrokes: A defines in advance which keystrokes should be logged and the malware only records these. For example, A can specify that only the login process of an online banking website should be recorded. The malware then observes the values entered in input fields on the website and sends this information to a dropzone. This dropzone is the central collection site for all harvested information. The attacker can access the dropzone, extract the stolen credentials, and use them to impersonate at Pj as Vi . 2.1 Studying the Attack The practical challenge of our approach is to find a way to access the harvested information so that it can be used for statistical analysis. To study this attack, we use the concept of honeypots, i.e., information system resources whose value lies in unauthorized or illicit use of that resource [27]. We play the role of a victim Vi and react on incoming attacks in the same way a legitimate victim would do. For example, we use spamtraps, i.e., email accounts used to collect spam, and open email attachments to emulate the infection process of malware that propagates with the help of spam. Furthermore, we also visit links contained in spam mails with client-side honeypots to examine whether or not the spammed URL is malicious and the website tries to install a keylogger via a drive-by download [28,36]. Using these techniques, our honeypot can be infected with a keylogger in an automated way and we obtain information about the attack vector. After a successful infection, we extract the sample from the honeypot for further analysis. We perform dynamic analysis based on an analysis tool called CWSandbox [37] since static analysis can be defeated by malware using many different techniques [17,24,26]. CWSandbox executes the malware in a controlled environment and analyzes the behavior of the sample during runtime by observing the system calls issued by the sample. As a result, we obtain an analysis report that includes for example


5

information about changes to the filesystem or the Windows registry, and all network communication generated by the sample during the observation period. When executing, the keylogger typically first contacts the dropzone to retrieve configuration information. The configuration file commonly includes a list of websites that should be monitored for credentials and similar customization options for the malware. From an attacker’s perspective, such a modus operandi is desirable since she does not have to hardcode all configuration options during the attack phase, but can dynamically re-configure which credentials should be stolen after the initial infection. This enables more flexibility since the attacker can configure the infected machines on demand. By executing the keylogger within our analysis environment and closely monitoring its behavior, we can identify the dropzone in an automated way since the keylogger contacts the dropzone at an early stage after starting up. However, certain families of keylogger already contain all necessary configuration details and do not contact the dropzone: only after keystrokes that represent a credential are observed by these keyloggers, they send the harvested information to the dropzone. In order to study this in a more automated fashion, we need some sort of user simulation to actually simulate a victim V . Note that we do not need to generically simulate the full behavior of a user, but only simulate the aspects of user interaction that are relevant for keyloggers, e.g., entering credentials in an online banking application or logging into a webmail account. The keylogger then monitors this behavior and sends the collected information to the dropzone, and we have successfully identified the location of a dropzone in an automated way. More information about the actual implementation of user activity simulation is provided in Section 3.1. 2.2 Technical Details of Analyzed Keyloggers To exemplify a technical realization of the methodology introduced in this paper, we analyzed in detail two different families of keyloggers that are widespread in today’s Internet: Limbo/Nethell and ZeuS/Zbot/Wsnpoem. We provide a short overview of both families in this section. More details and examples are available in a technical report [13]. Limbo/Nethell.This family of malware typically uses malicious websites and drive-by download attacks as attack channel to infect the victims who are lured by social engineering tricks to visit these websites. The malware itself is implemented as a browser helper object (BHO), i.e., a plugin for Internet Explorer that can respond to browser events such as navigation, keystrokes, and page loads. With the help of the interface provided by the browser, Limbo can access the Document Object Model (DOM) of the current page and identify sensitive fields which should be monitored for credentials (form grabbing). This enables the malware to monitor the content of these fields and defeats simple tricks to conceal the entered password as proposed by Herley and Florêncio [12]. The malware offers a flexible configuration option since the sites to be monitored can be specified during runtime in a configuration file. Upon startup, the malware contacts the dropzone to retrieve the current configuration options from there. Furthermore, this malware has the capability to steal cookies and to extract information from the Protected Storage (PStore). This is a mechanism available in certain versions of Windows which provides applications with an interface to store user

6


data [22] and many applications store credentials like username/password combinations there. Once a credential is found, the harvested information is sent to the dropzone via a HTTP request to a specific PHP script installed at the dropzone, e.g., http://example.org/datac.php?userid=21102008_110432_2025612. This example depicts the initial request right after a successful infection with which the keylogger registers the newly compromised victim. The userid parameter encodes the infection date and time, and also a random victim ID. By observing the network communication during the analysis phase, we can automatically determine the network location of the dropzone. The dropzone itself is implemented as a web application that allows the attacker amongst other tasks to browse through all collected information, search for specific credentials, or instruct the victims to download and execute files. We found that these web applications often contain typical configuration errors like for example world-readable directory listings that lead to insecure setups, which we can take advantage of to obtain access to the full data set. ZeuS/Zbot/Wsnpoem. The attack channel for this family of malware is spam mails that contain a copy of the keylogger as an attachment. The emails use common social engineering tricks, e.g., pretending to be an electronic invoice, in order to trick the victim into opening the attachment. In contrast to Limbo, which uses rather simple techniques to steal credentials, ZeuS is technically more advanced: the malware injects itself into all user space processes and hides its presence. Once it is successfully injected into Internet Explorer, it intercepts HTTP POST requests to observe transmitted credentials. This malware also steals information from cookies and the Protected Storage. All collected information is periodically sent to the dropzone via HTTP requests. The dropzone itself is implemented as a web application and the stolen credentials are either stored in the filesystem or in a database. Again, insecure setups like world-readable directory listings enable the access to the full dropzone data, allowing us to monitor the complete operation of a certain dropzone. Similar to Limbo, ZeuS can also be dynamically re-configured: after starting up, the malware retrieves the current configuration file from the dropzone. The attacker can for example specify which sites should be monitored (or not be monitored) for credentials. Furthermore, the malware can create screenshot of 50 × 50 pixels around the mouse pointer taken at every left-click of the mouse for specific sites. This capability is implemented to defeat visual keyboards, i.e., instead of entering the sensitive information via the keyboard, they can be entered via mouse clicks. This technique is used by different banks and defeats typical keyloggers. However, by taking a screenshot around the current position of the mouse, an attacker can also obtain these credentials. In addition, the configuration file also specifies for which sites man-in-the-middle attacks should be performed: each time the victim opens such a site, the request is transparently redirected to another machine, which hosts some kind of phishing website that tricks the victim into disclosing even more credentials. Finally, several other configuration options like DNS modification on the victim’s machine or update functionality are available.


7

3 Studying Keylogger-Based Attacks In this section, we introduce the analysis and measurement setup, and present general statistics about the dropzones. The next section then focusses on the results of a systematic study of keylogger-based attacks using keylogger and a dropzone as outlined in the previous sections. All data was collected during a seven-month measurement period between April and October 2008. 3.1 Improving Analysis by Simulating User Behavior We developed a tool called SimUser to simulate the behavior of a victim Vi after an infection with a keylogger. The core of SimUser is based on AutoIt, a scripting language designed for automating the Windows GUI and general scripting [4]. It uses a combination of simulated keystrokes, mouse movement, and window/control manipulation in order to automate tasks. We use AutoIt to simulate arbitrary user behavior and implemented SimUser as a frontend to enable efficient generation of user profiles. SimUser itself uses the concept of behavior templates that encapsulate an atomic user task, e.g., opening a website and entering a username/password combination in the form fields to log in, or authenticating against an email server and retrieving emails. We implemented 17 behavior templates that cover typical user tasks which require a credential as explained before. These templates can be combined in an arbitrary way to generate a profile that simulates user behavior according to specific needs. In order to improve our analysis, we execute the keylogger sample for several minutes under the observation of CWSandbox. During the execution, SimUser simulates the behavior of a victim, which browses to several websites and fills out login forms. In the current version, different online banking sites, free webmail providers, as well as social networking sites are visited. Furthermore, CWSandbox was extended to also simulate certain aspects of user activity, e.g., generic clicking on buttons to automatically react on user dialogues. We also store several different credentials in the Windows Protected Storage of the analysis machine as some kind of honeytoken. By depositing some credentials in the Protected Storage, we can potentially trigger on more keyloggers. Simulating user behavior enables us to learn more about the results of a keylogger infection, e.g., we can detect on which sites it triggers and what kind of credentials are stolen. The whole process can be fully automated and we analyzed more than 2,000 keylogger samples with our tools as explained in the next section. Different families of keyloggers can potentially use distinct encodings to transfer the stolen credentials to the dropzone and the dropzone itself uses different techniques to store all stolen information. In order to fully analyze the dropzone and the data contained there, we thus need to manually analyze this communication channel once per family. This knowledge can then be used to extract more information from the dropzone for all samples of this particular family. To provide evidence of the feasibility of this approach, we analyzed two families of keyloggers in detail, as we explain next. Note that even if we cannot fully decode the malware’s behavior, we can nevertheless reliably identify the network location of the dropzone based on the information collected during dynamic analysis. This information is already valuable since it can be used for mitigating the dropzone, the simplest approach to stop this whole attack vector.

8


3.2 Measurement Setup With the help of CWSandbox, we analyzed more than 2,000 unique Limbo and ZeuS samples collected with different kinds of spamtraps and honeypots, and user submissions at cwsandbox.org, in the period between April and October 2008. Based on the generated analysis reports, we detected more than 140 unique Limbo dropzones and 205 unique ZeuS dropzones. To study these dropzones, we implemented a monitoring system that periodically collects information like for example the configuration file. For 69 Limbo and 4 ZeuS dropzones we were able to fully access all logfiles collected at that particular dropzone. This was possible since these dropzones were configured in an insecure way by the attackers, enabling unauthenticated access to all stolen credentials. The remaining dropzones had access controls in place which prevented us from accessing the data. We periodically collected all available data from the open dropzones to study the amount and kind of stolen credentials to get a better understanding of the information stolen by attackers. In total, our monitoring system collected 28 GB of Limbo and 5 GB of ZeuS logfiles during the measurement period. 3.3 Analysis of Limbo Victims To understand the typical victims of keylogger attacks, we performed a statistical analysis of the collected data. The number of unique infected machines and the amount of stolen information per Limbo dropzone for which we had full access is summarized in Table 1. The table is sorted by the number of unique infected machines and contains a detailed overview of the top four dropzones. In total, we collected information about more than 164,000 machines infected with Limbo. Note that an infected machine can potentially be used by many users, compromising the credentials of many victims. Furthermore, the effective number of infected machines might be higher since we might not observe all infected machines during the measurement period. The numbers are thus a lower bound on the actual number of infected machines for a given dropzone. The amount of information collected per dropzone greatly varies since it heavily depends on the configuration of the keylogger (e.g., what kind of credentials should be harvested) and the time we monitored the server. The dropzones themselves are located in many different Autonomous Systems (AS) and no single AS dominates. The country distribution reveals that many dropzones are located in Asia or Russia, but we found also many dropzones located in the United States. We also examined the lifetime for each dropzone and the infection lifetime of all victims, i.e., the total time a given machine is infected with Limbo. Each logfile of a dropzone contains records that include a unique victim ID and a timestamp, which indicates when the corresponding harvesting process was started. As the infection lifetime of a victim we define the interval between the timestamp of the last and first record caused by this particular victim. This is the lower bound of the total time of infection since we may not be able to observe all log files from this particular infection and thus underestimate the real infection time. The interval between the last and the first timestamp seen on the whole dropzone is defined as the lifetime of this dropzone. Using these definitions, the average infection time of a victim is about 2 days. This is only a coarse lower bound since we often observe an infected machine only a limited amount of time.


9

Table 1. Statistical overview of largest Limbo dropzones, sorted according to the total number of infected machines

140000 100000 60000

58.0.0.0

93.0.0.0

189.0.0.0

221.0.0.0

0

20000

Victim IP addresses (accumulated)

Dropzone # Infected machines Data amount AS # Country Lifetime in days webpinkXXX.cn 26,150 1.5 GB 4837 China 36 coXXX-google.cn 12,460 1.2 GB 17464 Malaysia 53 77.XXX.159.202 10,394 503 MB 30968 Russia 99 finXXXonline.com 6,932 438 MB 39823 Estonia 133 Other 108,122 24.4 GB Total 164,058 28.0GB 61

0.0.0.0

50.0.0.0

100.0.0.0

150.0.0.0

200.0.0.0

250.0.0.0

IP address space

(a) Cumulative distribution of IP addresses infected with Limbo.

Country # Machines Percentage Russia 26,700 16,3% United States 23,704 14,4% Spain 20,827 12,7% United Kingdom 19,240 11,7% Germany 10,633 6,5% Poland 8,598 5,4% Australia 6,568 4,0% Turkey 5,328 3,2% Brazil 4,369 2,7% India 3,980 2,4% Ukraine 2,674 1,6% Egypt 2,302 1,4% Italy 1,632 0,9% Thailand 1,356 0,8% Other 26,147 16,0%

(b) Distribution of Limbo infections by country.

Fig. 2. Analysis of IP addresses for machines infected with Limbo and their regional distribution

The maximum lifetime of a Limbo victim we observed was more than 111 days. In contrast, the average lifetime of a dropzones is approximately 61 days. Figure 2a depicts the cumulative distribution of IP addresses for infected machines based on the more than 164,000 Limbo victims we detected. The distribution is highly non-uniform: The majority of victims are located in the IP address ranges between 58.* – 92.* and 189.* – 220.*. Surprisingly, this is consistent with similar analysis of spam relays and scam hosts [2,29]. It could indicate that these IP ranges are often abused by attackers and that future research should focus on securing especially these ranges. We determined the geographical location of each victim by using the Geo-IP tool Maxmind [18]. The distribution of Limbo infections by country is shown in Figure 2b. We found a total of 175 different countries and almost one third of the infected machines are located in either Russia or the United States.

10


3.4 Analysis of ZeuS Victims We performed a similar analysis for the ZeuS dropzones and the victims infected with this malware. Figure 3a lists the top five countries in which the dropzones are located based on 205 dropzones we identified with our method. Most ZeuS dropzones can be found in North America, Russia, and East Asia — a results that also applies to the Limbo dropzones. We also found that the dropzones are located in many different Autonomous Systems (68 different AS in total), but several AS host a larger percentage of ZeuS dropzones: The three most common AS host 49% of all dropzones, indicating that there are some providers preferred by the attackers. Presumably those providers offer bullet-proof hosting, i.e., takedown requests are not handled properly by these providers or the providers even tolerate certain abusive behavior. The four dropzones we had full access to contained information stolen from about 9,480 infected machines. Based on this data, we can determine the operating system version of each infected machine since the keylogger also extracts this information. Figure 3b provides an overview of the operating system running on the infected machines. The majority of victims is using Windows XP with Service Pack 2, thus they are not on the latest patch level (Service Pack 3 was released on May 6, 2008). A large fraction of machines run on even older version of the operating system. Only a minority of all victims have the latest service pack installed or are running Windows Vista. We also examined the language version of the operating system. Most infected machines have either English (53.8%) or Spanish (20.2%) as language. Consistent to the machines infected with Limbo, the majority of ZeuS infections can be found in the two network ranges 58.* – 92.* (56.9%) and 189.* – 220.* (25.8%). As explained in Section 2.2, ZeuS can be dynamically re-configured by the attacker via a configuration file. The most frequent configurations are shown in Table 2. Websites that should be logged are listed in the first part of the table and the second part enumerates the websites that should be logged and where a screenshot should be taken. Online banking websites clearly dominate this statistic and indicate that these attacks aim at stealing credentials for bank accounts. Finally, websites where no keystrokes should be recorded are listed at the end of the table. This excluding of websites from the harvesting process is presumably done in order to minimize the logged data.

Country # Dropzones Percentage United States 34 17% Russia 29 14% Netherlands 16 8% Malaysia 14 7% China 8 4%

(a) Top countries in which ZeuS dropzones are located.

OS version # Infected Machines Windows XP SP2 6,629 Windows XP SP0 1,264 Windows XP SP1 1,146 Windows 2000 SP4 285 Other 156

% 70.2 % 13.1 % 12.1 % 3.0 % 1.6 %

(b) Distribution of operating system for machines infected with ZeuS.

Fig. 3. General statistics for ZeuS dropzones and victims


11

Table 2. Overview of top four websites a) to be logged, b) to be logged including a screenshot, and c) not to be logged Website # Appearances (205 dropzones) a) https://internetbanking.gad.de/*/portal?bankid=* 183 https://finanzportal.fiducia.de/*?rzid=*&rzbk=* 177 https://www.vr-networld-ebanking.de/ 176 https://www.gruposantander.es/* 167 b) @*/login.osmp.ru/* 94 @*/atl.osmp.ru/* 94 @https://*.e-gold.com/* 39 @https://netteller.tsw.com.au/*/ntv45.asp?wci=entry 29 c) !http://*myspace.com* 132 !*.microsoft.com/* 98 !http://*odnoklassniki.ru/* 80 !http://vkontakte.ru/* 72

4 Analysis of Stolen Credentials Based on the data collected by our monitoring system, we analyzed what kind of credentials are stolen by keyloggers. This enables a unique point of view into the underground market since we can study what goods are available for the criminals from a first-hands perspective. We mainly focus on five different areas: online banking, credit cards, online auctions, email passwords, and social networks. At first sight, the last two areas do not seem to be very interesting for an attacker. However, especially these two kinds of stolen credentials can be abused in many ways, e.g., for identity theft, spear phishing, spamming, anonymous mail accounts, and other illicit activities. This is also reflected in the market price for these two types of goods as depicted in Table 3 based on a study by Symantec [33]. Identifying which credentials are stolen among the large number of collected data is a challenge. The key insight is that credentials are typically sent in HTTP POST requests from the victim to the provider. To find credentials, we thus need to pin-point Table 3. Breakdown of prices for different goods and services available for sale on the underground market according to a study by Symantec [33]. Percentage indicates how often these goods are offered. Goods and services Bank accounts Credit cards Full identities Online auction site accounts Email passwords Drop (request or offer) Proxies

Percentage 22% 13% 9% 7% 5% 5% 5%

Range of prices $10 – $1000 $0.40 – $20 $1 – $15 $1 – $8 $4 – $30 10% – 50% of total drop amount $1.50 – $30

12


which requests fields are actually relevant and contain sensitive information. We use a trick to identify these fields: when a victim enters his credential via the keyboard, Limbo stores this information together with the current URL. Based on the collected data, we can thus build provider-specific models MPi that describe which input fields at Pi contain sensitive information. For example, Mlogin.live.com = {login, passwd} and Mpaypal.com = {login email, login password}. These models can then be used to search through all collected data to find the credentials, independent of whether the victim entered the information via the keyboard or they were inserted by a program via the Protected Storage. In total, we generated 151,070 provider-specific models. These models cover all domains for which keystrokes were logged by all infected machines. For our analysis, we only used a subset of all provider-specific models that are relevant for the area we analyzed. We also need to take typing errors into account: if a victim makes a typing error during the authentication process, this attempt is not a valid credential and we must not include it in our statistics. We implement this by keeping track of which credentials are entered by each victim and only counting each attempt to authenticate at a specific provider once. During analysis, we also used methods like pattern matching or heuristics to find specific credentials as we explain below. 4.1 Banking Websites We used 707 banking models that cover banking sites like Bank of America or Lloyds Bank, and also e-commerce business platforms like PayPal. These models were chosen based on the ZeuS configuration files since this keylogger aims specifically at stealing banking credentials. In total, we found 10,775 unique bank account credentials in all logfiles. Figure 4a provides an overview of the top five banking websites for which we found stolen credentials. The distribution has a long tail: for the majority of banking websites, we found less than 30 credentials. ZeuS has the capability to parse the content of specific online banking website to extract additional information from them, e.g., the current account balance. We found 25 unique victims whose account balance was disclosed this way. In total, these 25 bank accounts hold more than $130,000 in checking and savings (mean value is $1,768.45, average is $5,225). Based on this data, we can speculate that the attackers can potentially access millions of dollars on the more than 10,700 compromised bank accounts we recovered during our analysis. Banking Website # Stolen Credentials PayPal 2,263 Commonwealth Bank 851 HSBC Holding 579 Bank of America 531 Lloyds Bank 447

Credit Card Type # Stolen Credit Cards Visa 3,764 MasterCard 1,431 American Express 406 Diners Club 36 Other 45

(a) Overview of top five banking websites for

(b) Overview of stolen credit card informa-

which credentials were stolen.

tion.

Fig. 4. Analysis of stolen banking accounts and credit card data


13

4.2 Credit Card Data To find stolen credit card data, the approach with provider-specific models cannot be used since a credit card number can be entered on a site with an arbitrary field name. For example, an American site might use the field name cc number or cardNumber, whereas a Spanish site could use numeroTarjeta. We thus use a pattern-based approach to identify credit cards and take the syntactic structure of credit card numbers into account: each credit card has a fixed structure (e.g., MasterCard numbers are 16 digits and the first two digits are 51-55) that we can identify. Furthermore, the first six digits of the credit card number are the Issuer Identification Number (IIN) which we can also identify. For each potential credit card number, we also check the validity with the Luhn algorithm [19], a checksum formula used to guard against one digit errors in transmission. Passing the Luhn check is only a necessary condition for card validity and helps us to discard numbers containing typing errors. With this combination of patterns and heuristics, we found 5,682 valid credit card numbers. Figure 4b provides an overview of the different credit card types we found. To estimate the potential loss due to stolen credit cards we use the median loss amount for credit cards of $223.50 per card as reported in the 2008 Internet Crime Complaint Center’s Internet Crime Report [14]. If we assume that all credit cards we detected are abused by the attacker, we obtain an estimated loss of funds of almost $1,270,000. 4.3 Email Passwords Large portals and free webmail providers like Yahoo!, Google, Windows Live, or AOL are among the most popular websites on the Internet: 18 sites of the Alexa Top 50 belong to this category [1]. Accordingly, we expect that also many credentials are stolen from these kinds of sites. We used 37 provider-specific models that cover the large sites of this category. In total, we found 149,458 full, unique credentials. We detected many instances where the attackers could harvest many distinct webmail credentials from just one infected machine. This could indicate infected system in public places, e.g., schools or Internet cafes, to which many people have access. Figure 5a provides an overview of the distribution for all stolen email credentials. Webmail Provider # Stolen Credentials Windows Live 66,540 Yahoo! 27,832 mail.ru 17,599 Rambler 5,379 yandex.ru 5,314 Google 4,783 Other 22,011

Social Network # Stolen Credentials Facebook 14,698 hi5 8,310 nasza-klasa.pl 7,107 odnoklassniki.ru 5,732 Bebo 5,029 YouTube 4,007 Other 33,476

(a) Overview of stolen credentials from portals and webmail providers.

(b) Overview of stolen credentials from social networking sites.

Fig. 5. Analysis of stolen credentials from free webmail providers and social networking sites

14


4.4 Social Networks and Online Trading Platforms Another category of popular sites are social networks like Facebook and MySpace, or other sites with a social component like YouTube. Of the Alexa Top 50, 14 sites belong to this category. To analyze stolen credentials from social networks, we used 57 provider-specific models to cover common sites in this category. In total, we found 78,359 stolen credentials and Figure 5b provides an overview of the distribution. Such credentials can for example be used by the attacker for spear phishing attacks. The final type of stolen credentials we analyze are online trading platforms. We used provider-specific models for the big four platforms: eBay, Amazon, Allegro.pl (third biggest platform world-wide, popular in Poland), and Overstock.com. In total, we found 7,105 credentials that were stolen from all victims. Of these, the majority belong to eBay with 5,712 and Allegro.pl with 885. We found another 477 credentials for Amazon and 31 for Overstock.com. This kind of credentials can for example be used for money laundering. 4.5 Underground Market The analysis of stolen credentials also enables us to estimate the total value of this information on the underground market: each credential is a marketable good that can be sold in dedicated forums or IRC channels [10,20]. If we multiply the number of stolen credentials with the current market price, we obtain an estimate of the overall value of the harvested information. Table 4 summarizes the results of this computation. These results are based on market prices as reported by Symantec [33,34]. Other antivirus vendors performed similar studies and their estimated market prices for these goods are similar, thus these prices reflect – to the best of our knowledge – actual prices paid on the underground market for stolen credentials. These results indicate that the information collected during our measurement period is potentially worth several millions of dollars. Given the fact that we studied just two families of keyloggers and obtained detailed information about only 70 dropzones (from a total of more than 240 dropzones that we detected during our study), we can argue that the overall size of the underground market is considerably larger. We also studied the estimated revenue of the individual dropzones. For each dropzone, we computed the total number of credentials stolen per day given the five categories examined in this paper. Furthermore, we use the range of prices reported by Table 4. Estimation of total value of stolen credentials recovered during measurement period. Underground market prices are based on a study by Symantec [33]. Stolen credentials Bank accounts Credit cards Full identities / Social Networks Online auction site accounts Email passwords Total

Amount 10,775 5,682 78,359 7,105 149,458 224,485

Range of prices $10 – $1000 $0.40 – $20 $1 – $15 $1 – $8 $4 – $30 n/a

$107,750 $2,272 $78,359 $7,105 $597,832 $793,318

– – – – – –

Range of value $10,775,000 $113,640 $1,175,385 $56,840 $4,483,740 $16,604,605


900

3500 3000

Estimated earning in $

# stolen credentials

800 700 600 500 400 300 200

2500 2000 1500 1000 500

100 0 0

15

5

10

15

time in days

20

25

(a) Number of stolen credentials per day

30

0 0

5

10

15

time in days

20

25

30

(b) Estimated daily earning for attackers

Fig. 6. Number of unique stolen credentials and estimated amount of money earned per day due to harvested keylogger data for three Limbo dropzones. Other dropzones have a similar distribution.

Symantec [33] to estimate the potential daily earnings of the operator of each dropzone. The results of this analysis are shown exemplarily in Figure 6 for three different Limbo dropzones. These dropzones were chosen since we were able to obtain continuous data for more than four weeks for these sites. However, the distribution for other dropzones is very similar. Figure 6a depicts the number of unique stolen credentials per day. This number varies greatly per day, presumably due to the fact that the malware has a certain rate at which new victims are infected and this rate also varies per day. We also observe that there is a steady stream of fresh credentials that can then be traded at the underground market. On the other hand, Figure 6b provides an overview of the estimated value of stolen credentials for each particular day. We obtain this estimate by multiplying the number of credentials stolen per day with the lowest market price according to the study by Symantec [33] (see Figure 3). This conservative assumption leads to a lower bound of the potential daily income of the attackers. The results indicate that an attacker can earn several hundreds of dollars (or even thousands of dollars) per day based on attacks with keyloggers — a seemingly lucrative business. 4.6 Discussion Besides the five categories discussed in this section, ZeuS and Limbo steal many more credentials and send them back to the attacker. In total, the collected logfiles contain more than three million unique keystroke logs. With the provider-specific models examined in the five categories, we only cover the larger types of attacked sites and highprofile targets. Many more types of stolen sensitive information against small websites or e-commerce companies are not covered by our analysis. As part of future work, we plan to extend our analysis and also include an analysis of stolen cookies and the information extracted from the Protected Storage of the infected machines.

16


5 Conclusion and Future Work Our user simulation approach is rather ad-hoc and does not allow us to study all aspects of keyloggers. The main limitation is that we do not know exactly on which sites the keylogger becomes active and thus we may miss specific keyloggers. Our empirical results show that keyloggers typically target the main online banking websites and also extract information from the Protected Storage. Nevertheless, we may miss keyloggers that only steal credentials from a very limited set of sites. This limitation could be circumvented by using more powerful malware analysis techniques like multi-path execution [23] or a combination of dynamic and static analysis [16]. Another limitation is that we do not exactly determine which credentials are stolen. Techniques from the area of taint tracking [25,38] can be added to our current system to pinpoint the stolen credentials. Despite these limitation, the ad-hoc approach works in practice and enables us to study keyloggers as we showed in Section 3 and 4. The approach we took in this paper works for keylogger-based attacks, but it can in fact be generalized to other attacks as well, for example classical phishing. The abstract schema behind the class of attacks that can be analyzed is shown in Figure 7. There, a provider P offers some online service like an online bank or an online trading platform (like eBay or Amazon). The victim V is a registered user of the service provided by P and uses credentials c to authenticate as a legitimate user towards P . The attacker A wants to use P ’s service by pretending to be V . To do this, A needs V ’s credentials c. So for a successful attack, there must exist a (possibly indirect) communication channel from V to A over which information about c can flow. We call this channel the harvesting channel. Apart from the harvesting channel there also exists another (possibly indirect) communication channel from A to V . This channel is used by the attacker to initiate or trigger an attack. We call this channel the attack channel. The generalization of our approach presented in this paper involves an analysis of the harvesting channel. This is a hard task, which together with more automation is a promising line for future work in this area.

Provider P legitimate use of P by V using credential c

attack channel

Victim V c

goal of A: illegitimate use of P by V

Attacker A

harvesting channel

Fig. 7. Structure of attacks susceptible to our method


17

Acknowledgements. We would like to thank Carsten Willems for extending CWSandbox such that certain aspects of user simulation such as generic clicking are directly implemented within the sandbox. Jan Göbel provided valuable feedback on a previous version of this paper that substantially improved its presentation. Frank Boldewin helped in analyzing the ZeuS configuration files and the AusCERT team was very helpful in notifying the victims. This work has been supported by the WOMBAT and FORWARD projects funded by the European Commission.

References 1. Alexa, the Web Information Company. Global Top Sites (September 2008), http://alexa.com/site/ds/top_sites?ts_mode=global 2. Anderson, D.S., Fleizach, C., Savage, S., Voelker, G.M.: Spamscatter: Characterizing Internet Scam Hosting Infrastructure. In: USENIX Security Symposium (2007) 3. Anonymous. Comment about posting “Good ol’ #CCpower” on honeyblog (June 2008), http://honeyblog.org/archives/194-CCpower-Only-Scam.html 4. AutoIt Script Home Page (2009), http://www.autoitscript.com/ 5. Chandrasekaran, M., Chinchani, R., Upadhyaya, S.: PHONEY: Mimicking User Response to Detect Phishing Attacks. In: Symposium on World of Wireless, Mobile and Multimedia Networks, WoWMoM (2006) 6. Choi, T., Son, S., Gouda, M., Cobb, J.: Pharewell to Phishing. In: Symposium on Stabilization, Safety, and Security of Distributed Systems, SSS (2008) 7. Chou, N., Ledesma, R., Teraguchi, Y., Mitchell, J.C.: Client-Side Defense Against WebBased Identity Theft. In: Network and Distributed System Security Symposium, NDSS (2004) 8. Dhamija, R., Tygar, J.D.: Battle Against Phishing: Dynamic Security Skins. In: Symposium on Usable Privacy and Security, SOUPS (2005) 9. Finjan: Malicious Page of the Month (April 2008), http://www.finjan.com/Content.aspx?id=1367 10. Franklin, J., Paxson, V., Perrig, A., Savage, S.: An Inquiry Into the Nature and Causes of the Wealth of Internet Miscreants. In: Conference on Computer and Communications Security, CCS (2007) 11. Gajek, S., Sadeghi, A.-R.: A Forensic Framework for Tracing Phishers. In: IFIP WG 9.2, 9.6/11.6, 11.7/FIDIS International Summer School on The Future of Identity in the Information Society, Karlstad University, Sweden (August 2007) 12. Herley, C., Florencio, D.: How To Login From an Internet Cafe Without Worrying About Keyloggers. In: Symposium on Usable Privacy and Security, SOUPS (2006) 13. Holz, T., Engelberth, M., Freiling, F.: Learning More About the Underground Economy: A Case-Study of Keyloggers and Dropzones. Technical Report TR-2008-006, University of Mannheim (2008) 14. Internet Crime Complaint Center (IC3). 2008 Internet Crime Report (March 2009), http://www.ic3.gov/media/annualreports.aspx 15. Kanich, C., Kreibich, C., Levchenko, K., Enright, B., Voelker, G.M., Paxson, V., Savage, S.: Spamalytics: An Empirical Analysis of Spam Marketing Conversion. In: Conference on Computer and Communications Security, CCS (2008) 16. Kirda, E., Kruegel, C., Banks, G., Vigna, G., Kemmerer, R.: Behavior-based Spyware Detection. In: USENIX Security Symposium (2006) 17. Linn, C., Debray, S.: Obfuscation of Executable Code to Improve Resistance to Static Disassembly. In: Conference on Computer and Communications Security, CCS (2003)

18


18. MaxMind LLC. MaxMind GeoIP (August 2008), http://www.maxmind.com/app/ip-location 19. Luhn, H.P.: Computer for Verifying Numbers (August 1960) U.S. Patent 2,950,048 20. Martin, J., Thomas, R.: The underground economy: priceless. USENIX; login: 31(6) (December 2006) 21. McCune, J.M., Perrig, A., Reiter, M.K.: Bump in the Ether: A Framework for Securing Sensitive User Input. In: USENIX Annual Technical Conference (2006) 22. Microsoft. Protected Storage (Pstore), Microsoft Developer Network (MSDN) (August 2008) 23. Moser, A., Kruegel, C., Kirda, E.: Exploring Multiple Execution Paths for Malware Analysis. In: IEEE Symposium on Security and Privacy (2007) 24. Moser, A., Kruegel, C., Kirda, E.: Limits of Static Analysis for Malware Detection. In: Annual Computer Security Applications Conference, ACSAC (2007) 25. Newsome, J., Song, D.X.: Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software. In: Network and Distributed System Security Symposium, NDSS (2005) 26. Popov, I.V., Debray, S.K., Andrews, G.R.: Binary Obfuscation Using Signals. In: USENIX Security Symposium (2007) 27. The Honeynet Project. Know Your Enemy: Learning About Security Threats, 2nd edn. Addison-Wesley Longman (2004) 28. Provos, N., Mavrommatis, P., Rajab, M.A., Monrose, F.: All Your iFRAMEs Point to Us. In: USENIX Security Symposium (2008) 29. Ramachandran, A., Feamster, N.: Understanding the Network-Level Behavior of Spammers. SIGCOMM Comput. Commun. Rev. 36(4), 291–302 (2006) 30. SecureWorks. PRG Trojan (June 2007), http://www.secureworks.com/research/threats/prgtrojan/ 31. SecureWorks. Coreflood Report (August. 2008), http://www.secureworks.com/research/threats/coreflood-report/ 32. Stahlberg, M.: The Trojan Money Spinner. In: Virus Bulletin Conference (2007) 33. Symantec: Global Internet Security Threat Report: Trends for July – December 07 (April 2008) 34. Symantec. Report on the Underground Economy July 07 – June 08 (November 2008) 35. Wang, X., Li, Z., Li, N., Cho, J.Y.: PRECIP: Towards Practical and Retrofittable Confidential Information Protection. In: Network and Distributed System Security Symposium, NDSS (2008) 36. Wang, Y.-M., Beck, D., Jiang, X., Roussev, R., Verbowski, C., Chen, S., King, S.T.: Automated Web Patrol with Strider HoneyMonkeys: Finding Web Sites That Exploit Browser Vulnerabilities. In: Network and Distributed System Security Symposium, NDSS (2006) 37. Willems, C., Holz, T., Freiling, F.: Toward Automated Dynamic Malware Analysis Using CWSandbox. IEEE Security & Privacy Magazine 5(2), 32–39 (2007) 38. Yin, H., Song, D., Egele, M., Kruegel, C., Kirda, E.: Panorama: Capturing System-wide Information Flow for Malware Detection and Analysis. In: Conference on Computer and Communications Security, CCS (2007)

User-Centric Handling of Identity Agent Compromise Daisuke Mashima, Mustaque Ahamad, and Swagath Kannan Georgia Institute of Technology, Atlanta GA 30332, USA

Abstract. Digital identity credentials are a key enabler for important online services, but widespread theft and misuse of such credentials poses serious risks for users. We believe that an identity management system (IdMS) that empowers users to become aware of how and when their identity credentials are used is critical for the success of such online services. Furthermore, rapid revocation and recovery of potentially compromised credentials is desirable. By following a user-centric identity-usage monitoring concept, we propose a way to enhance a user-centric IdMS by introducing an online monitoring agent and an inexpensive storage token that allow users to flexibly choose transactions to be monitored and thereby to balance security, privacy and usability. In addition, by utilizing a threshold signature scheme, our system enables users to revoke and recover credentials without communicating with identity providers. Our contributions include a system architecture, associated protocols and an actual implementation of an IdMS that achieves these goals.

1

Introduction

Digital identity credentials, such as passwords, tokens, certificates, and keys, are used to ensure that only authorized users are able to access online services. Because of sensitive and valuable information managed by such services, they have become targets of a variety of online attacks. For example, online financial services must use stronger credentials for authentication to avoid fraud. Because of the serious nature of threats and widespread theft and misuse of identity credentials, there is considerable interest in the area of identity management, which addresses secure use of such identity credentials. User-centric identity management, which allows users to flexibly choose what identity information is released to other entities, offers better control over the use of identity credentials. For instance, users can choose an identity provider that they believe is the most appropriate for each transaction. However, such user-centricity requires that disclosure of identity information needs to be under user control and also expects users to assume more responsibility over their identity usage owing to the absence of a centralized authority [1]. This would be possible only when users have a certain level of awareness and control of how and when their identity credentials are utilized. To satisfy the user-centricity requirement, several currently proposed usercentric IdMSs rely on agent software, which we call an identity agent, that carries M. Backes and P. Ning (Eds.): ESORICS 2009, LNCS 5789, pp. 19–36, 2009. c Springer-Verlag Berlin Heidelberg 2009

20

D. Mashima, M. Ahamad, and S. Kannan

out a number of tasks related to management of identity credentials on behalf of the user. Identity agents can be deployed on users’ devices or on networked entities. These agents assist users and thereby help reduce the burden imposed on them by an IdMS. For example, Windows CardSpace [2] utilizes client-side software to help users manage meta-data related to identity credentials as well as a certain type of authentication credentials used with online identity providers. Another example is GUIDE-ME (Georgia tech User-centric IDEntity Management Environment) [3][4] that utilizes local identity agents installed on users’ devices to control network-resident identity agents that store and manage identity credentials originally issued by identity providers. While an identity agent running on a readily accessible device can potentially offer increased user awareness and flexible control, the nature of a local identity agent on a mobile device will make it an attractive target of theft. In addition, since such devices sometimes are managed by non-expert users, attacks by means of malware are also a concern. The compromise of such agents could allow adversaries to access stored identity credentials and result in possible disclosure of sensitive information, including breach of authentication and authorization in a system where access to services must only be provided to legitimate users. Clearly, we must deal with the problem of misuse of such identity agents. We explore an approach to address these issues by focusing on an IdMS where relying parties (RPs), upon receiving an identity credential, require knowledge of the user’s private key as a proof of credential ownership. In other words, this ownership proof and identity credential issued by an identity provider together work as a credential, following the concept of joint authority discussed in [5]. The user’s private key tied to her identity credential is generally stored on the user’s device hosting an identity agent. In such an architecture, identity misuse by adversaries can succeed only when a legitimate identity owner’s private key is compromised. We believe this assumption is reasonable since RPs are motivated to reliably verify a requester’s identity to provide services only to legitimate users. In addition, the number of IdMSs that satisfy this assumption is growing, including the proof key mechanism in Windows CardSpace [6], Credentica’s UProve [7], and Georgia Tech’s GUIDE-ME. Under this assumption, in this paper, we propose a solution to empower users to have enhanced awareness over their online identity use by introducing a usercentric identity-usage monitoring system [8] and enable users to balance security, privacy, and usability solely based on their own needs. Our approach includes the optional use of an inexpensive storage token, such as a USB drive, to provide additional control. The main insight is that either we have enhanced security from the user provided storage token, or a transaction that is completed on a user’s behalf will be monitored by a monitoring agent chosen and trusted by a user. Furthermore, our proposed architecture does allow a user’s private key to be stored in an off-line safe place, and thereby the risk of compromise of the user’s private key is reduced. Revocation of potentially compromised identity agents or credentials and their recovery can be done more easily and in a timely fashion, compared to the traditional way that involves certification authorities

User-Centric Handling of Identity Agent Compromise

21

and identity providers. We also present an actual implementation and associated protocols and evaluate user-centricity and security against possible threats (e.g., how various threats are addressed by our scheme). We believe that our approach leads to an IdMS architecture that better achieves the goal of the “User Control and Consent” law presented in [9]. The paper is organized as follows. In Section 2, we present an overview of the GUIDE-ME system and identify potential security threats to it. In Section 3, we describe the basic idea of our approach to mitigate the effects of a compromise in a simplified setting. The prototype implementation of our system in the context of the GUIDE-ME architecture is discussed in Section 4, which is then evaluated in Section 5. We will finally discuss related work in Section 6 and conclude the paper in Section 7 with future work.

2

GUIDE-ME Overview and Security Threats

In this section, we briefly describe the high-level architecture of the GUIDE-ME system [3][4][10] as an example of a user-centric IdMS that provides a context for the techniques explored in this paper. In this system, identity agents store and manage users’ identity credentials and corresponding private keys and disclose the credentials based on policies defined in advance by users. In the GUIDEME architecture, there are two types of identity agents. Locally-installed agents (local IdA) run on devices that are with users (e.g., smart phones and laptop PCs), and remote agents (remote IdA) reside in the network. The decision to partition the identity agent functionality between local and remote entities offers a number of benefits that are explained in [4]. The architecture also includes relying parties (RP), which are service providers. The architecture of GUIDEME and communications among entities are illustrated in Fig. 1. In GUIDE-ME, an identity credential is a claim about a set of attribute values for a user and also includes some way to verify the claim. Credentials are defined in a novel way so that users can only disclose the minimal information that is required to complete a transaction. Such minimal-disclosure credentials are realized by using a Merkle Hash Tree (MHT) based implementation [10]. When verifying a credential, in addition to verifying the signature made by an

Fig. 1. Overview of GUIDE-ME Architecture

22


identity provider, a RP verifies a requester’s credential ownership through the requester’s signature on a nonce chosen by the RP (RP Nonce). As introduced earlier, GUIDE-ME utilizes two types of identity agents, a local IdA and remote IdA. A local IdA on a user device stores a user’s private key and meta-data which allows it to refer to identity credentials stored on a remote IdA. A local IdA also manages and checks user’s identity-related policies about the disclosure of identity attributes. A remote IdA is run by a party that naturally holds certain identity credentials for a user, such as an employer or another entity that is trusted by the user. It stores users’ long-term identity credentials issued by identity providers. Its primary responsibility is to manage these identity credentials and to create minimal-disclosure credentials based on authorizations from the user’s local IdA. A transaction in GUIDE-ME starts with a request from a user to a RP. The RP specifies which identity attributes it requires to provide a service (although trust negotiation may be involved, we skip it as it is out of the scope of our paper). A RP Nonce is also given to the user during the negotiation. At the user device, the local IdA creates an “Authorization Token” (AT) that tells the remote IdA to disclose specified identity attributes to the RP that is named by the user. More specifically, based on the meta-data it holds, the local IdA includes in the AT a list of identity attributes to be released, and signs it with the user’s private key so that the remote IdA can verify the authenticity of the token. The local IdA sends a message including the AT and the RP Nonce to the RP. This message is signed with the user’s private key so that the RP can verify the signature on the RP Nonce. The RP then forwards the AT to the user’s remote IdA, requesting the user’s identity credential. The remote IdA, only when the signature on the AT is valid, creates a minimal-disclosure credential and sends it to the RP. The RP finally verifies the provided credential and the user’s signature on the RP Nonce and processes the request when this is successful. In GUIDE-ME like architectures, one possible threat is the compromise of a local IdA. For instance, if a user’s device hosting a local IdA is physically stolen, the adversary can use it in arbitrary transactions in order to misuse the legitimate user’s identity. Although authentication may be supported by a device that runs a local IdA, security schemes based on PINs or passwords can be easily compromised. Furthermore, an infected device may allow adversaries to steal the user’s private key and other data, which could lead to misuse of credentials. Once a local IdA is compromised, the user does not have a simple and effective way to revoke its capability to interact with remote IdAs and RPs to complete identity-related transactions. Because a local IdA has access to the user’s private key, the user must contact the issuing certification authority and identity provider to ask for revocation of the corresponding public key and identity credential. This process usually takes time, so the window of vulnerability might be long enough to allow the adversary to abuse the identity credential. Furthermore, in case the local IdA is compromised and the user does not recognize the problem, the situation would be even worse.


3

23

Approach to Handle Identity Agent Compromise

One major problem that user-centric identity management systems based on identity agents suffer from is that compromise of an identity agent allows an adversary to arbitrarily misuse identity credentials of the victim. The adversary can provide valid user signatures to complete transactions that seem to come from the legitimate user. To avoid this, it is possible to store the private key on a remote IdA, which is often better managed than user devices, and have it provide a signature for ownership verification. We could also hold the key in an external media. However, the possibility of compromise of a remote IdA or theft of an external media cannot be completely ruled out. Thus, to effectively mitigate such threats, it is necessary to eliminate the single point of attack that could give an adversary the full control of stolen identity credentials. In other words, under our assumption, keeping user’s private key in an off-line safe place as long as possible is a better option. Another issue is how to deal with possibly compromised identity agents. To disable compromised agents, the victim’s private key must be revoked. However, propagation of revocation information to relying parties could take a long time because such a process depends on a certification authority (CA) and identity providers. So, it is desirable that a user can revoke it without involving such entities which are not under user control. Furthermore, an IdMS should help legitimate users recognize problems when agents are compromised. To achieve this goal, we need to introduce monitoring functionality which can log identity usage and implement a scheme to detect potential identity misuse. Based on these observations, we propose a scheme using threshold signatures [13][14], which enable us to split a user’s private key into several key shares. Each key share is used to make a partial signature, also called a signature share. If the number of signature shares equals at least a pre-defined threshold, they can be combined into a signature that can be verified with the user’s public key. For example, under a 2-3 threshold signature scheme, any two signature shares

Fig. 2. Basic Idea of Our Approach Using 2-3 Threshold Signature Scheme

24


out of three are enough to generate a complete signature, but any single share is not sufficient to convince other parties. Fig. 2 illustrates the basic idea of our approach in a simplified setting involving only a local IdA under 2-3 threshold signature scheme. In this setting, for the sake of simplicity, we also suppose that the user’s identity credential is stored on the device where the local IdA runs. We deploy one key share on the user’s device and another in a storage token, which can actually be an inexpensive USB drive or removable media. The third key share is stored at the online entity called a monitoring agent. The monitoring agent is run on a trusted third party chosen by a user or could be run on a user’s private home server. Here, we use 2-3 threshold signature scheme, but the number of total key shares and threshold value can vary depending on the underlying system architecture and user needs. For instance, in an architecture utilizing both a local IdA and remote IdA, 3-4 threshold signature scheme is reasonable when an additional key share is assigned to the remote IdA. This case will be discussed later in Section 4. As shown in Fig. 2, if the storage token is not provided by the user (CASE 1 in Fig. 2), the local IdA can create only one signature share and can send it with the identity credential. In this case, the relying party can not verify the validity of the user signature, and is then required to contact the user’s monitoring agent. The monitoring agent can make another signature share and combine them into a complete signature so that the RP can verify it with the user’s public key. On the other hand, if a user inserts the storage token, which contains another key share (CASE 2 in Fig. 2), the local IdA can generate two partial signatures locally which are sufficient for generating a complete signature. Then, the RP can verify the combined signature without contacting the monitoring agent. We briefly discuss the benefits of this approach. First, since a local IdA, storage token, or monitoring agent has only one key share, none of them is a single point of attack because a complete user signature can not be forged with just one share. More importantly, revocation can be done without involving a CA or identity provider by renewing key shares when compromise of one entity is suspected. Furthermore, since the monitoring agent can be used in place of the storage token, the user can use a service even when the storage token is not available at the time of request. This property also offers another benefit which allows the user to balance usability and privacy. Using a storage token allows users to bypass the monitoring feature, but otherwise monitoring is enforced. In other words, the identity-usage monitoring feature can be flexibly turned on or off by a user. We believe that such a user-controllable monitoring mechanism minimizes user’s privacy concern, which is an issue in traditional fraud detection mechanisms [8]. On the other hand, if usability is more important, a user does not have to always carry and use the storage token. We chose to deploy a monitoring agent on a trusted third party, but there are other alternatives. It could be located with a local IdA. If a monitoring agent is running on a user’s device, its functionality would be totally disabled once the device is compromised or stolen. This is a serious security concern. It is also not a good idea to place a monitoring agent with a remote IdA, even if it exists, because


25

of the same reason. By deploying a monitoring agent on a trusted third party, we are able to prevent misuse of identity credentials even when identity agents are compromised. It may be argued that requiring RPs to contact a monitoring agent would require changes to the RPs and may impose additional performance overhead. However, we think that our choice is justified by the observation that it ensures accurate reporting of identity usage information to a monitoring agent when the user so desires even in case identity agents are compromised. If such usage information is provided by a local IdA, because of potential compromise of it, a monitoring agent does not have an effective way to verify the accuracy of the information. On the other hand, RPs are motivated to provide correct information to avoid being manipulated by malicious users.

4

Prototype Implementation

Based on the approach discussed in Section 3, we now present a concrete design and implementation of a prototype that extends the GUIDE-ME architecture with a monitoring agent and a storage token. Our prototype is implemented in Java (J2SE), and we use Shoup’s threshold signature scheme [14][15]. We demonstrated the viability of our idea by implementing and evaluating the prototype described in this section. We also conducted response time measurement and confirmed that the additional processing overhead due to threshold signatures and additional communication is in acceptable range. For example, in our experimental setting where a separate PC is used for each entity and a user device is connected via a cable TV Internet service (13 hops away from a RP), response time measured at a user device increased on average by about 0.5 second in case a storage token was used and by 0.8 second when a monitoring agent was involved, compared to the original GUIDE-ME system. Based on the criteria explored in recent research [16], this increase in response time is tolerable for users. 4.1

System Architecture

An overview of the enhanced GUIDE-ME architecture is shown in Fig. 3. A user’s master private key is stored in some off-line safe storage and does not appear in the diagram. We now use the 3-4 threshold signature scheme. Four key shares are generated and are distributed to the storage token, local IdA, remote IdA, and monitoring agent. Although we focus on a setting in which each user has one local IdA, remote IdA, and monitoring agent, a user can have multiple agents of each type in our architecture, which is desirable in terms of system availability. When multiple agents are used, all agents of the same type are assigned the same key share. For example, when a user has multiple devices, all local IdAs have the same key share, and the total number of distinct key shares is always four. By doing so, even if more than one local IdAs belonging to a user are compromised, an adversary obtains only one key share. Thus, the system will not allow him to generate a valid signature to establish the ownership of an identity credential.

26


Fig. 3. Overview of Prototype Implementation

4.2

Implementation Details

We implement each entity (a local and remote IdA, monitoring agent, and RP) by a process and describe the messages exchanged among these processes. In addition, the white boxes in Fig. 3 represent “Information Token ” (IT), which is described next, and the numbers in the boxes represent the numbers of partial signatures made on the corresponding tokens. “Complete” means a complete signature made from three or more partial signatures. The numbers in parentheses represent the partial signature counts when the storage token’s key share is used to bypass monitoring. Although the GUIDE-ME architecture itself provides richer features, such as policy enforcement, we focus on ones related to compromised identity agent handling. We use two key data structures that contain the necessary information which is carried by messages exchanged between the various entities. We use the term “token” to refer to them as well, but they should not be confused with the storage token that was introduced earlier. The first one, an “Authorization Token” (AT), is very similar to the one used in the basic GUIDE-ME system described in Section 2. An AT allows a user to specify which identity attributes she is willing to disclose to a RP for a certain transaction. The only difference is that an AT is signed with a local IdA’s key share instead of a user’s private key. The purpose of this signature is to convince a remote IdA that the AT is actually issued by the legitimate user’s local IdA. Since a partial signature can be verified with the corresponding verification key just like the relationship of a private key and public key [14], the remote IdA can still verify the authenticity of the AT. We also introduce an “Information Token.” The primary purpose of an IT is the verification of ownership based on the user’s signature on RP Nonce. An IT may also include information about a monitoring agent (e.g., its location) when the user intends a transaction to be monitored.


27

Table 1. Protocol Message Description Message Name Identity Request Message

From RP

To User, Local IdA

Description Sent at the end of the initial negotiation phase. Signed by a RP. Contents: List of identity claims to be released, RP’s public key certificate, and RP Nonce Authorization Local Remote Sent via a RP. Message IdA IdA Signed with a local IdA’s key share. Contents: AT and IT with one or two partial signatures Identity Credential Remote RP Convey an identity credential. Message IdA Contents: Minimal-disclosure identity credential and IT with two partial signatures or a complete signature Monitoring Request RP MoA Sent only when a user allows a transaction to Message be monitored, i.e. a storage token is not used. Contents: IT with two partial signatures Monitoring Response MoA RP Only sent as a response to a Monitoring Request Message Message. Contents: IT with a complete signature

Messages exchanged by the entities are summarized in Table 1. In the table, MoA stands for a monitoring agent. We discuss the processing of these messages by each entity next. Local IdA. A local IdA, running on a user’s device, waits for an Identity Request Message, which arrives when the user initiates a transaction with a RP. First, the local IdA verifies the RP’s signature on the message to verify its integrity and authenticity. The identity of the RP must be carefully verified by making sure that its certificate is valid and issued by a trustworthy CA and by additionally using SSL/TLS server authentication etc. It then parses the message to obtain a RP Nonce and information about required identity attributes. Based on requested identity attributes and policies defined by the user, the local IdA allocates and initializes the AT and IT. After that, the local IdA makes partial signature on them. AT is partially signed by using local IdA’s key share. For IT, when only one key share is available, the local IdA makes one partial signature on it. If two key shares, including one from the storage token, are available, the local IdA makes two partial signatures so that the RP has no reason to contact the monitoring agent. Finally, the local IdA sends an Authorization Message to the RP, which then forwards it to the user’s remote IdA. Remote IdA. Upon receiving an Authorization Message forwarded by a RP, a remote IdA first verifies partial signatures on both tokens to see if they are actually generated by the legitimate user’s local IdA. After successful verification, it makes a partial signature on the IT. If the received IT already has two partial signatures, the remote IdA then combines three partial signatures, including its

28


own, into one complete signature. Otherwise, it just adds its own partial signature to the IT. Remote IdA’s primary task is to create a minimal-disclosure identity credential [10] based on the meta-data about credentials specified in the AT. Finally, it sends an Identity Credential Message to the RP. Monitoring Agent. On receiving a Monitoring Request Message from a RP, a monitoring agent makes its own partial signature on the IT in the message, which should already have two partial signatures, and then combines three partial signatures into one complete signature. Finally, it returns a Monitoring Response Message to the RP. A monitoring agent could block a transaction or raise an alarm in a real-time manner when identity misuse is suspected. Although an anomaly detection feature can be implemented, such functionality will be explored in our future work. Currently, a monitoring agent just logs the identityusage information, such as the timestamp and the RP’s identity. In addition, based on the user specified configuration, it sends the summary of usage log to the user periodically via a different and independent channel, e.g., SMS. Relying Party (RP). A RP first receives a request for a transaction from a user. On receiving this request, it prepares a list of required identity attributes based on its policies, sends an Identity Request Message to the user’s local IdA, and waits for an Authorization Message. When this message is received, the RP forwards the message to the remote IdA specified by the user, which will then respond with an Identity Credential Message. Upon receiving it, the RP checks the signature on the IT, and if the IT is accompanied by a complete signature, the RP verifies it by using the user’s public key. Then, the RP verifies the identity provider’s signature on the credential. Only when both signatures are valid, the RP accepts the identity credentials. If the IT in the Identity Credential Message does not have a complete signature, the RP contacts the monitoring agent specified by the user by sending a Monitoring Request Message. This makes the monitoring agent aware of the transaction. The information about the monitoring agent is not included when the user does not want the transaction to be monitored, and in this case, the RP has no reason to contact the monitoring agent. In response, a Monitoring Response Message is sent by the monitoring agent. If the IT in this message has a complete signature, the RP verifies it by using the user’s public key to see whether it should accept the user’s identity credential or not. 4.3

Revocation and Recovery

A user initiates a revocation process when she suspects that her device is lost or an identity agent is compromised or the monitoring agent informs her of suspicious transactions. The user can use her private key with a key share generator tool implemented by us to renew key shares. The tool distributes generated key shares to each entity. Because key shares must be protected, they are transferred via a secure and authenticated channel using the user’s private key and the receiver’s public key. Verification keys also need to be regenerated at the same time


29

and distributed to the user’s remote IdA and monitoring agent. We assume that each user has at least one trustworthy computer to execute the key share generator on it so that these re-generation and re-distribution operations are securely performed. Once key shares are updated, an identity agent under the control of an adversary can no longer create a valid partial signature because its key share is outdated. This revocation process can be completed without involving the certification authority, which helps in shortening the window of vulnerability. Users can also run the key share generator periodically in a proactive manner, which is highly recommended to further improve security. In addition, recovery of compromised or disabled entities can be done by starting a new instance of the entities and re-distributing newly-generated key shares to them. Our approach also offers a variety of options in the event that a service becomes unavailable. In case a user loses her storage token, she is still able to continue using services as described in Section 3. Because the monitoring agent must be involved, such transactions will be always monitored, which is desirable when one of the key shares has been lost. When a local IdA becomes unavailable for some reason, for example because of a hardware problem, the user can quickly create a new instance of a local IdA and continue using the service by using a key share available from her storage token in place of the local IdA’s key share. This would be possible when the local IdA code can be downloaded from a trusted server and run on a new device. In this scenario, a user does not have to renew all key shares by using her private key, which is stored off-line and may not be readily accessible. The local IdA effectively uses the storage token key share until new shares are generated and distributed. Again, all transactions initiated by the user in this situation will be monitored by the monitoring agent. In this way, the monitoring agent in the architecture offers the user flexibility to monitor transactions under her control and provides necessary redundancy to complete operations when user’s local IdA is unoperational or her storage token is lost. In a more extreme scenario where the storage token and the user device are both stolen and the remote IdA or the monitoring agent is compromised as well, the user would have to revoke her private key itself by contacting the certification authority and the corresponding identity credentials by contacting identity providers. However, the likelihood of such a scenario is much smaller than a case in which only one entity is compromised.

5 5.1

Evaluation User-Centricity

In this section, we analyze our approach in terms of properties of user-centricity for federated identity management systems proposed in [17]. Since some properties are already met by the original GUIDE-ME system, we focus on the additional properties that our approach can provide. One major contribution of our work is the integration of an identity-usage monitoring feature in a user-centric way [8]. A monitoring agent running on

30


a trusted third party can log identity-usage information on behalf of the user whenever it is involved in the execution of a transaction. If a user decides that a transaction be monitored, i.e. storage token’s key share is not used, the participating RP must contact the user’s monitoring agent to successfully complete a transaction. In addition, the monitoring feature can be flexibly controlled by users, so it is expected to minimize users’ privacy concerns. For instance, it is possible that for a transaction which could leak sensitive information (e.g., a certain prescription may indicate a medical condition), the user may decide that the monitoring agent must not be involved in the transaction. Notification feature is also implemented by a monitoring agent as mentioned in Section 4. Another property our scheme contributes to is revocability. The GUIDE-ME architecture uses long-term identity credentials that are stored on user’s identity agents. In our modified architecture, as long as the number of compromised key shares is less than the threshold, the user can revoke the compromised key shares by updating the entities with new key shares without involving the identity providers or the certification authority. Each of the key shares can be viewed as a partial privilege to use the identity credentials, and identity misuse happens only when multiple key shares are compromised under our assumption. In our architecture, such privileges of compromised entities can be revoked in a timely manner by the user. Finally, we discuss usability, which is also one of the components of usercentricity. Our proposed solution relies on a storage token, and similar tokens are used in multi-factor authentication schemes, such as [18]. It is argued that such tokens negatively impact usability because a user may not have a token with her when she needs to access services. Thus, mandatory use of such tokens could have undesirable impact on usability. We believe that our approach offers a reasonable middle ground. If the user does not mind the monitoring agent to be aware of all the transactions initiated by her, the storage token is not required at all and the monitoring agent can serve as a network resident software token. In this case, the user’s experience is exactly the same as when the storage token is not required to use a service. The important point is that there is a trade-off between usability and privacy, and users themselves can flexibly balance these based on their preferences. 5.2

Threat Analysis

We present a systematic analysis of the threats against the various entities in our architecture and how they are mitigated by the solutions we discussed. Although we primarily considered the compromise of user devices and local IdAs, we also explore the security impact when the other entities are compromised. Compromise of User Device and Local IdA. A user device hosting a local IdA could be compromised or physically stolen by an adversary. In such a case, the adversary can have access to the key share stored on the device. By exploiting the information on the device, the adversary can try to mount various attacks. The most serious threat is that the adversary can impersonate users and


31

misuse their identity credentials. However, without the possession of storage token’s key share, the adversary can not complete the transaction without being monitored by the monitoring agent. Even if an adversary succeeds in mounting such attacks, the monitoring agent includes functionality to report identity usage information to the user periodically, which helps the legitimate user become aware of the attack. Once the user recognizes the impersonation attack, she can immediately initiate the revocation process to disable the compromised local IdA. Thus, the compromise of the key share stored on a local IdA alone is not a critical risk. A user device could be compromised without being detected by the user. An adversary could compromise the local IdA code or the underlying OS by means of malware or spyware. The most critical consequence of such attacks is the compromise of the storage token’s key share, which could be secretly copied upon its usage, along with the local IdA’s key share. Once the adversary obtains both key shares, no protection would work effectively. Although users could rely on security tools, such as anti-virus or personal firewall software, we can not completely eliminate the risk of the device being compromised. Hardware support to detect tampering [19] should be helpful, but TPM is not always available. However, even in this case, our system offers the user to make a choice based on the degree of her trust in her own device. Specifically, if the user wants to completely avoid this risk, she should never use the storage token with this device. Then, compromise of a user’s device will not allow the adversary to obtain the two key shares even when the OS is compromised. Furthermore, in this case, all transactions will be monitored, which allows the user to counter this threat by giving up some privacy. If the user can partially trust her device, she can choose to use her storage token when necessary and to update all key shares periodically in a proactive fashion to minimize the risk. In this way, our scheme offers trade-off between security, usability, and privacy, and a user is able to balance these based on her own risk threshold. Theft of Storage Token. A storage token used in our system holds one key share. Because a storage token can be lost or stolen, it is important to make sure it is not a weak point in terms of security of the system. An adversary could download local IdA code, assuming it is easily available online for the sake of convenience of legitimate users, and use it with a stolen storage token. However, in this case, the monitoring agent needs to be involved in the transaction. This will allow the user to detect the misuse. If storage token key share is tampered with or corrupted instead of being stolen, a user should be able to recognize the problem from error messages saying that construction of a complete signature failed. As a fall back, even in this case, the user can use services by involving the monitoring agent, as discussed in Section 4.3. As can be seen, a storage token used in our approach requires minimal resources and security features. Although additional security functionality, such as password protection or device-level authentication, could be used, it is not mandatory. In this sense, a storage token can be just a USB drive or removable media.

32


Attacks Against Monitoring Agent. The other component added by us to the architecture is a monitoring agent, and it holds a key share as well as a database that stores a log of identity-usage information. If a monitoring agent is simply disabled by an adversary, the user can notice the problem because a transaction involving the monitoring agent should return an error. In addition, if the user does not receive usage summary reports, which are supposed to be sent periodically, she can realize that something is wrong with the monitoring agent. In such cases, she can contact the trusted party that is running the monitoring agent to address this problem. A more sophisticated attack would replace the monitoring agent code by one that does not record the information about transactions that are initiated by a malicious party impersonating the legitimate user. In this case, a user has no way to become aware of the attack. Therefore, trusted parties running monitoring agents must be responsible for detecting such compromise by checking integrity of the monitoring agent code periodically, and a user should carefully choose a trustworthy party to run her monitoring agent. The compromise of a key share stored at a monitoring agent is less serious because of the 3-4 threshold signature scheme. The compromise of the database that stores accumulated identity-usage information would cause privacy concerns. Although a design of detailed mechanism is part of our future work, the data should be stored in privacy-preserving manner. The encryption of the usage database is also possible to counter this threat. In addition to data stored at a monitoring agent, an attacker has access to the contents of an “Information Token.” Thus, a compromised monitoring agent would allow an adversary to access this token’s contents. Since the token only contains a partial ownership proof that is valid only for a specific transaction, RP Nonce, location information of monitoring agent, and so on, which are not confidential, disclosure of the contents does not jeopardize the system. The other type of concern related to an “Information Token” is that an adversary can replay a fully-signed token in another transaction. However, this will not work as long as a RP checks its nonce in the token which is unique for each session. If an adversary controlling the monitoring agent tries to modify the nonce, a combined signature is no longer valid because the monitoring agent’s partial signature is made on data different from what is partially signed by the local IdA and remote IdA. Compromise of Remote IdA. An adversary could target a remote IdA’s key share. Although he could gain access to a user’s identity credentials, this alone will not allow him to misuse the credentials, by virtue of 3-4 threshold signature scheme and joint authority [5]. Thus, a remote IdA is not a single point of attack either. Although it does not directly result in identity misuse, protection of the information included in credentials stored at a remote IdA should be ensured. This is outside the scope of this paper and will be explored in our future work. A compromised remote IdA could allow an adversary to capture information that is sent to it by other entities. For example, an “Information Token” is included in an Authorization Message in Fig. 3. The adversary can obtain information included in the token. However, because it contains non-sensitive


33

information, it does not jeopardize the system’s security. Regarding an “Authorization Token,” our extensions do not add any new vulnerabilities beyond what must be addressed by the underlying GUIDE-ME architecture. Compromise of Multiple Identity Agents. As shown earlier, the compromise of any single entity is handled by our system. Although it is less likely to happen, we do consider a case in which a user’s local IdA and remote IdA are compromised at the same time. Our system can provide some mitigation of the risk even in this situation. Because we are using the 3-4 threshold signature scheme, two partial signatures are not enough to convince a RP. Thus, the monitoring agent will be contacted which will help users learn of the compromise. This is actually our primary motivation for placing a monitoring agent at a separate and trusted site. In case a user owns multiple user devices to run local IdAs, even if the adversary succeeds in taking control of more than one local IdAs, his attempt to misuse identity credentials will not be successful. As noted in Section 4.1, the same type of identity agents are assigned the same key share. Thus, in this example, the adversary can only obtain a single key share, which is not sufficient to create a complete signature. The same holds when multiple instances of remote IdA and monitoring agent are deployed. Malicious Relying Party. We assume that a non-malicious RP exactly follows the protocol described in Section 4. Although the security of RP is outside the control of users, we discuss the impact that a compromised or malicious RP could have on the system. Adversaries could mount phishing attacks by spoofing a RP site. In this case, anomaly should be detected when a user initially negotiates with the RP. A user or her agent, such as a web browser or local IdA, can do it by verifying the RP’s certificate and signature made by the RP. Furthermore, even if it failed for some reason, for example when a malicious RP somehow owns a valid certificate that establishes plausible credibility, a monitoring agent also can detect anomaly based on the identity, such as IP address, of a RP sending a Monitoring Request Message in case the user intends her transactions to be monitored. A malicious RP might replay tokens or credentials to another (non-malicious) RP. In this case, as long as the non-malicious RP checks the nonce and a remote IdA checks the partial signature on the “Authorization Token,” the malicious RP cannot impersonate legitimate users. This is because, in the protocol, a RP chooses one nonce for each transaction and requires a user to include it in tokens. Finally, it is possible that a malicious RP omits contacting a monitoring agent though it is required to do. In this case, the log kept by the monitoring agent, which is sent to a user periodically, will not include certain transactions even though the user intended them to be monitored. In this case, the user will find out that the RP is not faithfully following the protocol because of the missing transaction records.

34

6


Related Work

A number of federated and user-centric IdMSs have been proposed recently. Liberty Alliance’s identity federation framework [20] involves three entities, identity providers, service providers, and users. The basic protocol goes as follows. When a user wants to use some service provided by a service provider, the user contacts the service provider first. Then, if the user is not authenticated by any identity providers trusted by the service provider, it redirects the user to an identity provider chosen by the user. The user authenticates herself to the identity provider and is redirected back to the service provider with an identity credential after the successful authentication process. OpenID [11] is a lightweight identity management system and has goals similar to those of Liberty Alliance. Although it was originally designed to deal with relatively simple cases, its functionality has been expanded by OpenID Attribute Exchange specification, which enables OpenID providers to transport users’ profile data [21]. CardSpace [2] is a user-centric identity metasystem designed based on The Laws of Identity [9]. It provides a consistent user interface that enables users to select an appropriate identity provider for each context simply by selecting a “card.” In terms of the architecture and protocol, both OpenID and CardSpace have similarity to Liberty Alliance’s. Although these are getting more widely deployed, none of them implement identity-usage monitoring, which our approach offers. Thus, if an authentication credential gets compromised, there is no effective way for a user to become aware of and exercise control over identity usage. Exploring ways to integrate our approach in other IdMSs is part of our future work. In public key setting, threshold cryptography primarily aims to share the knowledge or privilege of a private key among a number of members in order to prevent abuse of the private key as well as to make the signature made by it more reliable [22]. In addition to this objective, it can help eliminate a single point of attack, which is the case with a normal private key. Moreover, because participation of all members is not usually required, threshold cryptography can also be effective for the sake of higher system availability. Practical application of threshold cryptography is explored in online distributed certification authority area [23][24]. The authors utilize threshold cryptography scheme primarily to attain a higher level of system availability, fault-tolerance, and security. In our approach, in addition to the benefits mentioned above, threshold signature scheme is utilized to allow users to balance usability, security, and privacy demands in user-centric identity management context. MacKenzie and Reiter [25] address the problem of securing password-protected private keys stored on a user device and revocation of such keys in case the device is compromised. They employ a network resident server and split the functionality between the user device and the online server to achieve these goals. Although their goals are similar to ours and they ensure security when a device, the online server, or the password is compromised, their scheme requires the server to be always available for public key operations. In contrast, our architecture allows users to have an option to use services even when a monitoring agent is not


35

available. In addition, implementing a monitoring feature, which helps users quickly notice problems, is another advantage of our system.

7

Conclusions

In this paper, by focusing on a user-centric identity management architecture involving identity agents, we presented a way to enable users to exercise more robust and flexible control over online identity usage by utilizing a low-cost storage token and an online monitoring agent. In our approach, a user can revoke potentially compromised identity agents and credentials without involving certification authorities or identity providers. In addition, our scheme ensures that user’s identity usage is monitored by her monitoring agent unless the user explicitly acts to avoid it. Users also are able to determine when the storage token is used, and thereby they can balance usability, security, and privacy based only on their own needs and preferences. We also developed a concrete prototype of the proposed approach and evaluated it in terms of user-centricity and mitigation against threats. Our threat analysis showed how the theft or compromise of each entity in the system can be reasonably handled. Our future work includes the enhancement of monitoring agent’s functionality, such as designing anomaly detection algorithms based on identity-usage information and protection of accumulated usage logs. Exploring a way to protect identity attributes included in credentials from adversaries by means of cryptography is another area. We will also explore how to integrate our approach into other identity management architectures. Finally, although we based our work on identity management systems in this paper, we believe our approach is more general and can be integrated even into other types of systems. Thus, we will further explore such possibilities.

Acknowledgment This research was supported in part by the National Science Foundation (under Grant CNS-CT-0716252) and the Institute for Information Infrastructure Protection. This material is based in part upon work supported by the U.S. Department of Homeland Security under Grant Award Number 2006-CS-001000001, under the auspices of the Institute for Information Infrastructure Protection (I3P) research program. The I3P is managed by Dartmouth College. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of any of the sponsors.

References 1. Hansen, M., Berlich, P., Camenisch, J., Clauß, S., Pfitzmann, A., Waidner, M.: Privacy-Enhancing Identity Management. Information Security Technical Report (ISTR) 9(1) (2004)

36


2. Chappell, D., et al.: Introducing Windows CardSpace, http://msdn.microsoft.com/en-us/library/aa480189.aspx 3. Bauer, D., et al.: Video demonstration of Credential-Holding Remote Identity Agent (2007), http://users.ece.gatech.edu/gte810u/RIDA_Video 4. Ahamad, M., et al.: GUIDE-ME: Georgia Tech User Centric Identity Management Environment. In: Digital Identity Systems Workshop, New York (2007) 5. Lampson, B., et al.: Authentication in Distributed Systems: Theory and Practice. ACM Transactions on Computer Systems 10(4) (1992) 6. Microsoft and Ping Identity, A Guide to Integrating with InfoCard v1.0, http://download.microsoft.com/download/6/c/3/ 6c3c2ba2-e5f0-4fe3-be7f-c5dcb86af6de/infocard-guide-beta2-published. pdf 7. U-Prove Technology, http://www.credentica.com/u-prove_sdk.html 8. Mashima, D., Ahamad, M.: Towards a User-Centric Identity-Usage Monitoring System, In: Proc. of ICIMP 2008 (2008) 9. Cameron, K.: The Laws of Identity (2004), http://www.identityblog.com/ 10. Bauer, D., Blough, D., Cash, D.: Minimal Information Disclosure with Efficiently Verifiable Credentials, In: Proc. of the Workshop on Digital Identity Management (2008) 11. Recordon, D., Reed, D.: OpenID 2.0: A Platform for User-Centric Identity Management. In: Proceedings of the 2nd ACM workshop on DIM (2006) 12. Shibboleth, http://shibboleth.internet2.edu 13. Desmedt, Y.G., Frankel, Y.: Threshold cryptosystems. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 307–315. Springer, Heidelberg (1990) 14. Shoup, V.: Practical threshold signatures. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 207–220. Springer, Heidelberg (2000) 15. Java Threshold Signature Package, http://sourceforge.net/projects/threshsig/ 16. Akamai Technologies. Retail Web Site Performance (2006), http://www.akamai.com/4seconds 17. Bhargav-Spantzel, A., et al.: User Centricity: A Taxonomy and Open Issues. Journal of Computer Security (2007) 18. RSA SecureID, http://www.rsa.com/ 19. Jaeger, T., et al.: PRIMA: Policy Reduced Integrity Measurement Architecture. In: The 11th ACM Symp. on Access Controll Models and Technologies (2006) 20. Liberty Alliance Project. Liberty Alliance ID-FF 1.2 Specifications, http://www.projectliberty.org/ 21. Hardt, D., et al.: OpenID Attribute Exchange 1.0 - Final, http://openid.net/specs/openid-attribute-exchange-1_0.html 22. Desmedt, Y.: Some Recent Research Aspects of Threshold Cryptography. LNCS (1997) 23. Zhou, L., et al.: COCA: A secure distributed on-line certification authority. ACM Transaction on Computer Systems (2002) 24. Yi, S., et al.: MOCA: Mobile Certificate Authority for Wireless Ad Hoc Networks. In: The 2nd Annual PKI Research Workshop Pre-Proceedings (2003) 25. MacKenzie, P., Reiter, M.K.: Networked cryptographic devices resilient to capture. In: Proc. of IEEE Symposium on Security and Privacy (2001)

The Coremelt Attack Ahren Studer and Adrian Perrig Carnegie Mellon University {astuder,perrig}@cmu.edu

Abstract. Current Denial-of-Service (DoS) attacks are directed towards a specific victim. The research community has devised several countermeasures that protect the victim host against undesired traffic. We present Coremelt, a new attack mechanism, where attackers only send traffic between each other, and not towards a victim host. As a result, none of the attack traffic is unwanted. The Coremelt attack is powerful because among N attackers, there are O(N 2 ) connections, which cause significant damage in the core of the network. We demonstrate the attack based on simulations within a real Internet topology using realistic attacker distributions and show that attackers can induce a significant amount of congestion.

1

Introduction

Over the past two decades, the Internet has become of critical importance for social, business, and government activities. Corporations depend on Internet availability to facilitate sales and the transfer of data to make timely decisions. SCADA networks often use the Internet to enable coordination between physical systems. Unfortunately, malicious parties have been able to flood end hosts with traffic to interrupt communication. In these Denial-of-Service (DoS) attacks, the network link to the server is congested with illegitimate traffic so that legitimate traffic experiences high loss, preventing communication altogether. Such a loss of connectivity can wreak havoc and translate to monetary losses1 and physical damages. Loss of connectivity between SCADA systems can cause damage to critical infrastructures. For example, electrical systems with out-of-date demand information can overload generators or power lines. Unfortunately, a failure in a

1

This research was supported in part by CyLab at Carnegie Mellon under grants DAAD19-02-1-0389 and MURI W 911 NF 0710287 from the Army Research Office, and grant CNS-0831440 from the National Science Foundation. The views and conclusions contained here are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either express or implied, of ARO, CMU, NSF, or the U.S. Government or any of its agencies. In a recent attack, a week-long botnet cyber-attack costs a Japanese company 300 million yen, see article at http://www.yomiuri.co.jp/dy/national/20080601TDY01305.htm and http://blog.wired.com/sterling/2008/06/looks-like-a-ya.html

M. Backes and P. Ning (Eds.): ESORICS 2009, LNCS 5789, pp. 37–52, 2009. c Springer-Verlag Berlin Heidelberg 2009

38

A. Studer and A. Perrig

critical system may set off a chain reaction, as we witnessed during the August 2003 Northeast US blackout.2 A commonality of past Denial-of-Service (DoS) attacks is that adversaries directly attacked the victim. Consequently, defenses that were designed to defend against such attacks aim to identify the source of excessive traffic or prioritize legitimate traffic. Since machines can insert fake source addresses, different tracing schemes have been developed to identify the origin network of malicious traffic in the hope that an ISP will “pull the plug” on malicious activities once the sources are identified. However, attackers often rely on Distributed Denial of Service (DDoS) attacks where numerous subverted machines (also called a botnet) are used to generate traffic. With a large botnet, each malicious source can generate a small amount of traffic to make it more difficult for victims to distinguish legitimate traffic from malicious traffic. To address such stealthy attacks, capability-based systems allow end hosts to identify long-running legitimate traffic, which routers prioritize for delivery. During times of heavy load, routers forward packets with the proper capabilities while dropping packets without capabilities. Once tracing and traffic capabilities are deployed, attackers will look for new ways to launch DoS attacks. Rather than targeting endpoints or the network link directly before a victim, the attacker may aim to disrupt core network links in the Internet. Prior work has shown that disabling important links can cause substantial damage in terms of isolating parts of the Internet [1]. With enough subverted machines under control, a malicious party can generate enough traffic to choke even the largest links. For example, an OC-768 link (the largest type of link currently deployed) has almost 40 Gb/s of bandwidth. A botnet with 350,000 DSL customers spewing 128 kb/s can generate ample data (over 43 Gb/s) and overload such a link.3 Of course, the attacker cannot just spew packets at the different ends of a crucial link. Given legitimate traffic rarely connects to a router, network administrators can easily filter traffic so customer packets destine for routers are dropped. With packets directed at the router dropped, the attacker’s next option may be to send packets for addresses a few hops past the router. However, capabilitybased DoS prevention systems will thwart such an attack. The destinations will not grant malicious sources capabilities. Routers will allow legitimate traffic to traverse the congested link and drop attack traffic that lacks the capabilities. In this work, we investigate the efficacy of a new type of DoS attack that can elude prior DoS defenses and shut down core links (i.e., a Coremelt). To circumvent current DoS defense systems that attempt to eliminate unwanted traffic, the botnet in the Coremelt attack sends only wanted or “legitimate” traffic: 2 3

More information on the August 2003 Northeast US blackout is available at: http://en.wikipedia.org/wiki/2003_North_America_blackout. In a more pessimistic scenario, a botnet of one million nodes with connection speeds of 1 Mb/s per node can congest 25 OC-768 links. What is even more troubling is that home network connection speeds are likely to increase further, for example in Japan and Korea 100 Mb/s connections are commonly available for home users.

The Coremelt Attack

39

connections between pairs of bots. Since in a network with N bots there are O(N 2 ) connections, these “legitimate” flows can exhaust the network bandwidth of core network links. As a result, flows from legitimate clients that need to cross these congested core network links will be severely affected. The goal of this work is to define and analyze such Coremelt attacks. We simulate such an attack using real Internet topology and routing data, and distributions of real subverted machines. This data allows us to examine how Coremelt attacks from real distributions of bots would impact the current Internet. The main contribution of this work is to present the Coremelt attack, a serious attack that is possible even in a network that only permits “legitimate” traffic, i.e., traffic that is desired by the receiver. This attack suggests that more powerful countermeasures are needed to truly eradicate DoS attacks in the Internet.

2

The Coremelt Attack

In this section, we discuss the exact details of a Coremelt attack and the challenges an attacker faces when launching such an attack. In a Coremelt attack, the attacker uses a collection of subverted machines sending data to each other to flood and disable a backbone link. With subverted machines sending data to each other, an attacker can elude capabilityand filtering-based DoS defenses because all traffic is desired by the receiver. When the subverted machines are spread across multiple networks, the attacker has a greater chance of shutting down a backbone link, without crippling smaller tributary links. There are 3 steps to launching a Coremelt attack: 1. Select a core link in the network as the target link. 2. Identify what pairs of subverted machines can generate traffic that traverse the target link. 3. Send traffic between the pairs identified in step 2 to overload the target link. Figure 1 contains the ideal setting for a Coremelt attack. The attacker will select source-destination pairs such that traffic will traverse the target link. For S3

A

S1

Target Link B S2

C

Subverted Machine Normal Machine

Fig. 1. Example Network Where Coremelt Would Succeed (Note: Line thickness indicates available bandwidth)

40


example S1 and S3 will send traffic back and forth, but S1 and S2 will not communicate. If the sum of incoming links’ bandwidths is greater than the target link’s bandwidth, attack traffic can flood the target link without interrupting traffic on the smaller links. When the attack is successful, legitimate nodes A and B in Figure 1 can communicate, but neither can reach C due to the congestion on the target link. When an attacker wants to use Coremelt to disrupt a more realistic network, an attacker needs several things before the attack can work: knowledge of the network topology, a large botnet, and a way to generate traffic that intermediary nodes will forward. Generating a good model of the physical layer of the Internet is an open research problem. However, a botnet owner can use traceroute to map the paths between every pair of bots under her control. With knowledge of all N (N2−1) paths, the nodes simply have to decide which paths traverse the target link and only send attack traffic across those paths. Backbone links can support an immense amount of traffic and thus an attacker needs significant resources to clog such a link. Unfortunately, real botnets on the order of 1 million nodes exist4 and botmasters (the individuals who control a botnet) are starting to rent out botnets for hire.5 With sufficient funds, a malicious party can rent a large enough botnet—or several botnets. Next, an attacker needs a way to generate traffic that appears normal enough that traffic filtering by the ISPs will allow it to pass. TCP is designed to reduce bandwidth usage in response to packet loss, so that traffic will simply slow down once the target link is under stress. One solution is to use non-conforming/greedy traffic that is labeled as TCP, but fails to behave according to congestion-avoidance [2]. UDP traffic is another option, assuming ISPs do not throttle that traffic. The remainder of this work is dedicated to simulation of Coremelt to evaluate its threat and discussion of potential solutions. Before presenting simulation results, we describe the simulator and the attacker and network models we use.

3

Simulation Setup

The goal of this work is to evaluate the strength of a Coremelt attack under realistic conditions. Can a botnet generate traffic in such a way that a backbone link is congested? Will the attack also congest smaller links, or will only the performance on the target link degrade? How large of a botnet is needed to launch such an attack? Given the legal and ethical issues surrounding DoS attacks, rather than renting a botnet and attacking the Internet, we simulate the attack using realistic network topologies and attackers. In this section, we describe the data we use to model the network topology and attacker. We also describe the simulator we use 4

5

Some professionals claim the Storm worm botnet reached 1 to 50 million nodes at one time. http://www.informationweek.com/news/internet/showArticle.jhtml? articleID=201804528 http://www.usatoday.com/tech/news/computersecurity/ 2004-07-07-zombie-pimps_x.htm

The Coremelt Attack

41

to model the flow of traffic in our simulated Internet. We conclude this section with the different metrics we use to quantify the success of a Coremelt attack. 3.1

Network Model

We use Autonomous System (AS) level information to build a graph and select routes between nodes that match the topology of the Internet and likely routes Internet traffic would take. We use the CAIDA AS relationships Dataset [3] from January of 2009 so our model can take into account both the presence of links and the priority of different links when routing traffic in the Internet. Our network model also uses AS information to dictate the resources available for a given AS to handle traffic. For our network model, we build a graph based on the ASes in the Internet. Each node is an AS and an edge between two nodes represents an AS relationship. AS relationships can be one of four types: provider, customer, peer, or sibling. A provider is a larger AS that allows smaller customer ASes to reach a larger fraction of the Internet. Customers pay providers for these services based on the amount of bandwidth used. To reduce fees, ASes often peer with other ASes and exchange traffic for free to increase connectivity (i.e., a back-up link if a provider fails) or to reduce costs (i.e., when peered, traffic between customers of ASes A and B can go directly to each other rather than through a common provider AS C). Sibling ASes are two ASes owned by the same company. To determine the path traffic will take between two nodes in the graph we find the shortest route (in terms of number of AS hops) that does not violate routing policy. This requires that peering ASes will only accept traffic that is destined for their customers. For example, consider the scenario where AS A and B are peers and have different providers such that B’s provider has a shorter route to a destination D. When AS A wants to send traffic to D, A will send traffic to its provider, rather than routing the traffic through B to achieve the shorter path in terms of hops. Once the shortest AS policy abiding path is found, we consider it fixed for the remainder of our simulation. For future work, we plan to investigate how changing routes based on congestion can redistribute traffic and help prevent Coremelt attacks, or if changing routes will simply redirect attack traffic to a new bottleneck link which will subsequently fail. Different links in the Internet have different capacities. However, there is little information available about the bandwidth of a backbone link within an AS. When simulating the Coremelt attack, we want an accurate estimate of how much traffic an AS can support at a time. For example, we want to know the capacity of AT&T’s optic cable between the US and Europe. Obviously, that bandwidth is different from the bandwidth available on the major link of a regional ISP. AS degree is one logical way to estimate the capacity of an AS. An AS’s degree is the number of other ASes that directly communicate with the given AS. The more clients an AS supports and the more peers an AS shares traffic with, the more traffic that AS can support. In our simulations, we consider a number of different capacity functions.

42


– Uniform: every AS can support the same amount of traffic. This scenario is inaccurate, but represents a worst case scenario for high degree ASes under a Coremelt attack. With multiple incoming links of the same bandwidth, high degree ASes are more likely to fail under Coremelt. – Linear: the bandwidth an AS can support grows linearly with AS degree. This is a best-case scenario for high-degree ASes. When an attacker aims to disrupt a major AS, incoming ASes with smaller degrees will be congested and drop traffic such that the high-degree AS can support the aggregate of the incoming traffic. This model is unrealistic due to the cost of increasing bandwidth. Additional interfaces on a router allow an AS to contact a different AS and increase its degree, but increasing the bandwidth within the AS requires purchasing additional links and/or upgrading existing links. – Step: the most realistic of our settings assumes that ASes fall into different classes of resources based on their degree. We analyze the sensitivity of the results under the step model using two different step functions. In Section 3.5, we describe the actual values we use in each scenario. 3.2

Attacker Model

In a Coremelt attack, an attacker is limited by three key properties: the size of the botnet, the distribution of bots, and the amount of traffic each bot can generate. In our simulations, we test a range of botnet sizes and traffic generation capabilities (see Section 3.5 for specific numbers) to test Coremelt’s sensitivity under varying conditions. However, it is difficult to determine a realistic distribution of bots. Coremelt has the greatest chance of success when bots are evenly distributed across the Internet. However, instead of assuming some distribution of bots over the Internet, we use records from real attacks. Once we know the distribution of subverted machines, we can scale the botnet to various sizes. For example, if 50 bots from a 1,000 bot botnet reside in AS M , we simulate a botnet of size 1,000,000 by assigning 50,000 bots to AS M . Once we have a bot distribution and have scaled the botnet to a given size we vary the traffic generation capability of the bots to evaluate when Coremelt will succeed to congest a link. In our simulations, we examine two sets of subverted machines: machines infected with CodeRed and a set of machines used to launch a DDoS attack against a computer at the Georgia Institute of Technology. For the remainder of this paper, we refer to the data sets as CodeRed and GT-DDoS, respectively. The CodeRed set comes from CAIDA data that lists the IP addresses of machines infected with CodeRed scanning for other vulnerable machines in July of 2001 [4]. There are 278,286 infected machines that we can associate with 4746 ASes in our network model. CodeRed was a worm that infected machines running Microsoft’s IIS web server. However, the data still provides a rough approximation of the distribution of vulnerable hosts on the Internet. If admins in a network fail to patch servers, the admins have likely neglected to patch clients in that network. One disadvantage to this data set is that it fails to represent the networks without

The Coremelt Attack

43

servers. Such networks may contain a large number of vulnerable clients, but no servers. Our second data set contains real botnet data and thus can provide a realistic distribution of vulnerable machines. This set includes 5994 unique IPs that we can associate with 720 ASes in our network model. Even though this is a relatively small botnet, we scale this number while maintaining the distribution of bots to simulate larger botnets. 3.3

Simulation Methodology

In this section, we explain how we integrate our network and attacker models and how we simulate the flow of traffic through the network in a discrete fashion. In our simulation, each node in the network is an AS. Each AS has 0 or more bots and can support different amounts of traffic, depending on the function used to simulate AS resources (i.e., uniform, linear, or step). Based on the CodeRed or GT-DDoS data, we know each AS contains some number of bots (B). We scale the botnet by a factor, F , so the number of bots in a given AS changes from B to F B. This assures the same distribution of bots across simulations, while changing the effective size of the botnet. For our simulations, each bot can generate a fixed amount of traffic T . Rather than increasing the memory usage as T increases, we normalize the resources of the ASes with respect to T so each bot only generates one piece of data per time interval. For example, if we assume one bot can generate 14 kilobits per second and an AS can handle 1 gigabit per second, the AS is scaled to handle 74898 meta packets per interval 1·230 (74898 = 14·2 10 ). Our simulator works in two steps: initialization and traffic routing. Initialization handles defining routes and AS statistics. Defining routes involves finding the different routes in the network and selecting which routes an attacker will use to attack a given target. The simulator then assigns the number of bot sources to each AS based on the original botnet distribution and the input scale factor. Finally, the simulator allocates buffers for each AS to store packets where the size of the buffer is based on how many packets the AS can handle in one second. Our simulator is a discrete time simulator where during interval i the ASes forward packets they received in interval i − 1 and collect packets to forward during interval i + 1. At the start of an interval, an AS generates F B (the total number of bots in that AS) packets, selects random destinations for each packet such that the packet will traverse the target AS, and stores the packets in an incoming buffer. This generation in interval i and sending in interval i + 1 simulates the machines in the AS generating the packet, rather than the routers in the AS. If bots in an AS generate more packets than the AS can support, the AS drops the extra packets. Next, the AS forwards the packets received during interval i − 1 to the next hop in each packet’s path. When an AS receives a packet from another AS, the packet is placed in the incoming buffer to be either forwarded to the next hop in the path or delivered—if the destination is in this AS—in interval i + 1. If the AS’s incoming buffer is already full when it receives a packet, the AS randomly selects a packet from the buffer, drops that packet, puts the newly received packet in the buffer, and notes the overload for that

44


AS. In our simulator, there is no legitimate traffic that flows between nodes; all of the traffic flows between bots. The introduction of legitimate traffic could hinder or help a Coremelt attack. Additional traffic could cause congestion on tributary links and prevent attack traffic from reaching the target link, reducing the impact of a Coremelt attack. However, the majority of legitimate traffic will likely use congestion avoidance, allowing greedy/non-conforming attack traffic— which never backs off—to proceed unhampered to the target link. The addition of legitimate traffic on the target link will increase the chance of a successful Coremelt attack since additional traffic on the target link increases the chance of the link exceeding its limit. For each scenario, we simulate the generation and forwarding of packets for 50 intervals. We tested longer simulations, but given the limited diameter of the network, packets either overload the target within a short period of time or the attack fails. 3.4

Metrics

The goal of this work is to measure the success of a Coremelt attack under varying conditions. To quantify the success of an attack, we use two metrics: destructiveness and stealthiness. Destructiveness indicates if a Coremelt attack is able to overload different target ASes in our simulation. Since Coremelt aims to attack the core of the Internet, we define destructiveness as the fraction of the top ten ASes an attacker can congest one at a time with a given botnet size and traffic generation capabilities. A destructiveness of 0.3 means an attacker can shut down 3 of the top 10 ASes. Stealthiness indicates how many non-target ASes are impacted by a Coremelt attack. The goal of Coremelt is to shut down the target while minimizing impact on the rest of the network. Additional congested ASes increase the chances of ASes reacting to the congesting flows (e.g., dropping packets) or tracing the attack traffic back to the bots. To measure the stealthiness of Coremelt, we record the sum of non-target or collateral ASes that are also congested when individually attacking the top 10 ASes. For example, if the attacker happens to congest 3 additional ASes while attacking each of the top ten ASes, the number of collateral ASes is 30. We count a top ten AS as part of the collateral ASes if it is not the current target. An attacker’s goal is to achieve a high destructiveness while maintaining stealthiness by limiting the number of collateral ASes. 3.5

Simulation Parameters

We now present the different values we use during simulation for traffic generation, botnet size, and AS resources. We take a conservative approach to bots’ traffic generation abilities and test botnets where all nodes are connected via dial-up modem or DSL. Specifically, we assume bots can generate either 14 kilobits per second or 128 kilobits per

The Coremelt Attack

45

Table 1. The step function we use to define resources for ASes based on degree Degree (d) d=1 1 < d < 10 10 ≤ d < 999 d ≥ 1000

Link OC-12 OC-48 OC-192 OC-768

Bandwidth # of ASes 601.344 Mb/s 11,042 2,405.376 Mb/s 18,083 9,621.504 Mb/s 1475 39,813.12 Mb/s 10

second. Given the proliferation of high speed links available for home users, these are conservative values. During our simulations, we test a range of botnet sizes. We sweep through a range of values to determine the smallest botnet that can shut down the top ten ASes intentionally and the smallest botnet such that there are zero collateral ASes. During simulation we varied the ASes’ resources based on the three models in Section 3.1: uniform, linear, and step. In the uniform model, we assume every AS backbone has a fixed bandwidth. We run two sets of simulations to determine the sensitivity to resources selected. The first set assumes each AS backbone can handle 2.5 Gb/s while the second assumes 5 Gb/s. Under our linear model, an AS with degree d has d OC-12 links for a total bandwidth of d · 601 Mb/s.6 For example, an AS of degree 3 can support 1,803 Mb/s (3 · 601 Mb/s). Our last model uses a step function to determine the bandwidth of an AS based on its degree. Table 1 contains the list of different classes of ASes in our step function and the number of ASes in each class. To test the sensitivity of the attack under the step model to our function, we also run additional simulations where ASes with degrees of 1000 or more have twice the resources. Note, by giving the target ASes (the top ten ASes) significantly more bandwidth than the rest of the ASes, we are reducing the chance of Coremelt destructiveness and increasing the chance of collateral ASes suffering congestion. These network resources may be less than what ASes can support in real life. However, we have also underestimated the traffic generation abilities of bots. Smaller values for both of these parameters cancel each other to provide a realistic simulation (i.e., attackers generating more traffic that traverses a network with more resources will experience similar results).

4

Simulation Results

Our simulation results indicate that networks where resources follow the uniform and step models are vulnerable to the Coremelt attack. The major difference is the ability to focus an attack. In uniform networks, an attacker can precisely attack a single core AS. However, in networks that follow the step model, an attacker will congest additional ASes when targeting some core ASes. If resources 6

For the exact bandwidth for the different levels of optical carrier links see http:// en.wikipedia.org/wiki/Optical_Carrier.

46


are more like the linear model, an attacker with a very large botnet can launch a successful Coremelt attack, but shuts down the majority of the network in the process causing substantial collateral damage. 4.1

Uniform Network

1

1

0.8

0.8

Destructiveness

Destructiveness

The destructiveness of a Coremelt attack in an uniform network is shown in Figures 2 and 3. For the uniform network model, the Coremelt attack is a serious threat. With botnets in the shown ranges, a Coremelt attack is very stealthy and the number of collateral ASes is 0. When the resources of the target ASes double, a successful attack requires roughly twice as many bots. One unexpected result is that destructiveness is not a binary result. One may expect that as soon as an attacker can generate enough traffic to attack one of the top ten ASes, all of the other top ten ASes should be vulnerable. The reason for this lies in the distribution of the bots across different ASes. With a nonuniform distribution of bots, certain targets face more traffic when facing the same size botnet. For example, with X total bots, some fraction of the bots, fi , can send packets to each other such that traffic traverses the target AS i. With a different target AS j, some different fraction fj is able to send packets to each other which traverse the target. If fi > fj , a smaller botnet can successfully attack AS i but fail when targeting AS j. When the resources of the ASes double, the size of the botnet needed to launch a Coremelt also doubles. However, the way we scale a botnet produces some unexpected results for the attacker with greater traffic generation capabilities. Looking at the 14 kbps attacker (Figure 2), an attacker under both CodeRed and GT-DDoS distributions needs roughly twice as many bots when resources change from 2.5 Gb/s to 5.0 Gb/s for each AS. With 128 kbps traffic generation capabilities and the CodeRed distribution, an attacker needs 2.5 times the bots to achieve the same level of destructiveness when AS resources are doubled. The flooring function used to scale the botnet from 278 thousand bots down to tens of thousands causes this anomaly. When the scaling factor is small, the number of bots in an AS changes

0.6 0.4 0.2

0.6 0.4 0.2

CodeRed GT-DDoS

0 180000

200000

220000

240000

260000

0 350000

CodeRed GT-DDoS 400000

450000

Botnet Size

Botnet Size

(a) 2.5 Gb/s

(b) 5.0 Gb/s

500000

550000

Fig. 2. Results when simulating an attacker with 14 kbps per bot when ASes have uniform resources

1

1

0.8

0.8

Destructiveness

Destructiveness

The Coremelt Attack

0.6 0.4 0.2 0 20000

47

0.6 0.4 0.2

CodeRed GT-DDoS 22000

24000

26000

28000

30000

0 40000

CodeRred GT-DDoS 45000

50000

55000

Botnet Size

Botnet Size

(a) 2.5 Gb/s

(b) 5.0 Gb/s

60000

65000

Fig. 3. Results when simulating an attacker with 128 kbps per bot when ASes have uniform resources

in set increments—rather than a linear fashion—as the overall size of the botnet increases. As such, the number of bots that can send packets across the target ASes doubles while the total number of bots changes by a factor 2.5. The GT-DDoS data set originally has roughly six thousand total bots so scaling from 6,000 to 50,000 provides a relatively smooth growth. As such, attacks on a 5 Gb/s AS take twice as many bots as attacks on a 2.5 Gb/s AS. 4.2

Linear Network

With a linear model for network resources, the Coremelt attack fails under reasonable scenarios. The top ten ASes have such a large degree that their resources can handle incoming traffic for any reasonable size botnets with our traffic generation capabilities. When an attacker tries to launch a Coremelt attack in such a network, a large number of collateral ASes will fail. With the linear model and a non-uniform distribution of bots, an attacker may flood every AS on the path to the target AS and still fail to shutdown the target. 4.3

Step Network

In the realistic step network model, the Coremelt attack can successfully target core ASes. However, the distribution of the bots plays an important role when considering collateral ASes. Greater attack traffic generation capabilities allow an attacker to succeed with fewer bots, but congest the same number of collateral ASes. With bots spread through more ASes, an attacker requires fewer bots to successfully launch an attack or can use the same number of bots and congest fewer collateral ASes. Figures 4 and 5 show the destructiveness and the number of collateral ASes under the step model for 14 kbps and 128 kbps traffic generation capabilities, respectively. The results from simulation of the step model where we double the resources for ASes with degrees of 1000 or more are shown in Figure 6. These latter results provide strong evidence that having a botnet spread over more ASes is an advantage when launching a Coremelt attack.

48


1

CodeRed GT-DDoS

70

CodeRed GT-DDoS

0.8

Collateral ASes

Destructiveness

60

0.6 0.4

50 40 30 20

0.2

10

0

0 1e+06

2e+06 3e+06 Botnet Size

4e+06

5e+06

1e+06

(a) Destructiveness

2e+06 3e+06 Botnet Size

4e+06

5e+06

(b) Collateral ASes

Fig. 4. Results when simulating an attacker with 14 kbps per bot when ASes have step based resources

When comparing Figures 4 and 5, we see attack traffic generation capability simply changes the size of the botnet needed to have a given impact. For example, an attacker needs over 3 million bots that can generate 14 kbps to attack the top ten ASes, but only 400,000 bots are necessary if each can generate 128 kbps. At the same time, the number of collateral ASes for a given destructiveness is the same. To achieve a destructiveness of 1, an attacker under the CodeRed or GT-DDoS distributions congest 6 or 71 collateral ASes, respectively. When the resources for the target ASes are doubled (see Figure 6), the advantage of having botnets spread through more ASes is more pronounced. The CodeRed distribution has bots distributed over 4746 different ASes versus the GT-DDoS distribution with 720 ASes. With traffic coming from more directions and greater chance of traffic traversing the target link, an attacker with the CodeRed distribution can achieve a destructiveness of 1 with only 700,000 bots and 48 collateral ASes. To achieve the same destructiveness, an attacker with the GT-DDoS distribution needs an additional 308,000 bots, and congests 128 collateral ASes. 1

CcodeRed GT-DDoS

70

CodeRed GT-DDoS

Collateral ASes

Destructiveness

60 0.8 0.6 0.4

50 40 30 20

0.2

10

0

0 100000

200000 300000 Botnet Size

400000

(a) Destructiveness

500000

100000

200000 300000 Botnet Size

400000

500000

(b) Collateral ASes

Fig. 5. Results when simulating an attacker with 128 kbps per bot when ASes have step based resources

The Coremelt Attack

CodeRed GT-DDoS

120

CodeRed GT-DDoS

100

0.8

Collateral ASes

Destructiveness

1

49

0.6 0.4 0.2

80 60 40 20

0

0 500000

750000 Botnet Size

(a) Destructiveness

1e+06

500000

750000 Botnet Size

1e+06

(b) Collateral ASes

Fig. 6. Results when the top ten ASes double their resources. (attacker traffic generation = 128 kbps per bot).

These results indicate that an attacker with a realistically distributed botnet under realistic traffic and network settings can launch a focused Coremelt attack which causes core links to fail. This attacker can launch such an attack without raising suspicion by congesting a large number of tributary links.

5

Previous Work and Potential Coremelt Defenses

In this section, we discuss work related to attacks on the core of the Internet or DoS defenses. We also discuss if such DoS defenses could mitigate a Coremelt attack. Magoni [1] analyzes attacks on the core of the Internet. His study shows how the targeted removal of links could significantly impact connectivity in the Internet. However, his paper simply assumes that a malicious party could disable a link, without discussing any specific attack mechanism. A number of prior works examine how to prevent DoS attacks using systems to trace traffic to the source, capabilities that allow legitimate traffic preference over attack traffic, puzzles to force attackers to expend work to impact the victim, or techniques to balance resource allocation across different users. Unfortunately, none of these solutions provides a satisfactory solution to the Coremelt attack, because these defense mechanisms attempt to stop traffic that is unwanted by the destination or use a definition of fairness that fails to protect non-attack traffic in the worst case scenario. Trace back systems [5, 6, 7, 8, 9, 10] help defend against DoS attacks where an attacker would use a small number of machines from the same network to flood a victim with traffic containing spoofed addresses. Once the victim knows the source of the traffic, administrators on the attacker’s network can turn off ports, stopping the attack traffic. In Coremelt and other DDoS attacks, a victim has trouble separating legitimate traffic from attack traffic. The flows between bots in the Coremelt attack consume relatively limited bandwidth and appear as legitimate as any other flow traversing the core link. Without a way to differentiate legitimate and attack traffic, tracing traffic provides no help during a Coremelt attack.

50


In capability-based systems [11, 12], traffic which a destination wants to receive is given priority at congested routers. The destination gives legitimate sources a capability that ensures prioritized delivery. If an attack occurs, attack traffic will lack the proper capability and be dropped by congested routers. In a variant of capability-based systems [13], rather than approving wanted traffic the destination asks the source’s ISP to filter unwanted traffic. In Coremelt, bots want traffic from other bots and will grant capabilities for the traffic (or never mark attack traffic as unwanted), easily circumventing capability-based DoS defenses. One solution to DoS attacks is to use puzzles to increase the cost for an attacker to consume victims’ resources [14, 15, 16, 17, 18]. If the amount of work needed to complete the puzzle is large enough, the attacker will be unable to launch a successful attack. Most of these are designed as challenges a client must perform before a server will provide a service. However, Portcullis [17] uses puzzles to allow clients to acquire capabilities in a capability-based DoS system. After acquiring the capability, the legitimate traffic requires no additional work and can proceed unhampered by the DoS attack. If we were to adopt puzzles to all network traffic, as opposed to just traffic associated with acquiring capabilities, the puzzles may become the bottleneck rather than the links. During a Coremelt attack, the resources needed to send traffic across the target link will increase, effectively degrading the performance of any machine using the target link. One final approach to DoS mitigation is to fairly distribute the available resources across all users [19, 20]. In these schemes, a max-min fair bandwidth allocation ensures all flows achieve the same output rate.7 The goal is to isolate legitimate traffic from attack traffic such that an attack flow can only use as much bandwidth as a non-attack flow. Here how flows are defined plays a key role on how a Coremelt attack impacts legitimate traffic. In Core-Stateless Fair Queueing [20], the endpoints of a connection define a flow (i.e., IP addresses of the client and the server). With a small number of attackers flooding a given link, the fair sharing will prevent the attack flows from impacting legitimate users. However, in a Coremelt attack with N bots, there are O(N 2 ) sourcedestination pairs contributing bandwidth to the link. With so many pairs, even if bandwidth is shared fairly (i.e., every flow or source-destination pair receives the same amount of bandwidth), the bandwidth a legitimate flow receives is drastically reduced. Chou et al. [19] focus on fair allocation of bandwidth within the core of the network and define flows based on the source and destination router (i.e., where a packet enters and exits the core of the network). With flows defined by routers—rather than endpoints—a botnet must be widely distributed to disrupt all traffic across the link. When legitimate traffic traverses the same pair of routers as attack traffic, the bandwidth allocation mechanism considers all of the traffic the same flow. As a result, once the link is congested, 7

In addition to equal sharing of bandwidth, network administrators can assign different weights to different flows. Flows with larger weights will receive a larger, but fixed, fraction of the bandwidth.

The Coremelt Attack

51

the scheme will drop packets from this flow with no preferential treatment for non-attack traffic. However, traffic traversing pairs of routers that include zero Coremelt traffic will proceed unhampered, independent of the amount of attack traffic.

6

Conclusion

Internet connectivity is crucial for social, economic, and government purposes. Loss of connectivity due to malicious activity can cause serious financial and physical damage to services. Traditional Denial of Service (DoS) attacks attempting to disrupt connectivity flood a victim with unwanted traffic. Researchers have proposed a number of defenses to address such DoS attacks. In this work, we present Coremelt, a new type of DoS attack where N attackers send traffic to each other, overloading the core of the network with the O(N 2 ) pairwise connections. The malicious sources and destinations want the traffic, allowing the packets to elude traditional DoS defenses that assume attack traffic is unwanted by the receiver. Simulation of the attack on a realistic model of the Internet topology with a realistic attacker model shows that a Coremelt attack can cause serious congestion in the Internet. Hopefully, this work will motivate researchers to investigate solutions to this debilitating attack.

Acknowledgments We would like to thank Chris Lee and Wenke Lee for sharing their data on real botnets. We would also like to thank the anonymous reviewers for their insightful comments and feedback that helped improve the quality of this paper.

References 1. Magoni, D.: Tearing down the internet (2003) 2. Savage, S., Cardwell, N., Wetherall, D., Anderson, T.: TCP Congestion Control with a Misbehaving Receiver. ACM SIGCOMM Computer Communication Review 29(5) (1999) 3. CAIDA: As relationships dataset (January 5, 2009), http://www.caida.org/data/active/as-relationships/ 4. Moore, D., Shannon, C.: The caida dataset on the code-red worms (July-August, 2001), http://www.caida.org/data/passive/codered_worms_dataset.xml 5. Burch, H., Cheswick, B.: Tracing anonymous packets to their approximate source. In: Proceedings of the Large Installation System Administration Conference (2000) 6. Goodrich, M.: Efficient Packet Marking for Large-Scale IP Traceback. In: Proceedings of ACM CCS (November 2001) 7. Snoeren, A.C., Partridge, C., Sanchez, L.A., Jones, C.E., Tchakountio, F., Kent, S.T., Strayer, W.T.: Hash-Based IP Traceback. In: Proceedings of ACM SIGCOMM 2001, pp. 3–14 (2001)

52


8. Snoeren, A.C., Partridge, C., Sanchez, L.A., Jones, C.E., Tchakountio, F., Schwartz, B., Kent, S.T., Strayer, W.T.: Single-Packet IP Traceback. IEEE/ACM Transactions on Networking (ToN) 10(6) (December 2002) 9. Savage, S., Wetherall, D., Karlin, A., Anderson, T.: Practical network support for IP traceback. In: Proceedings of ACM SIGCOMM (August 2000) 10. Yaar, A., Perrig, A., Song, D.: Pi: A path identification mechanism to defend against DDoS attacks. In: Proceedings of IEEE Symposium on Security and Privacy (May 2003) 11. Yaar, A., Perrig, A., Song, D.: SIFF: A stateless Internet flow filter to mitigate DDoS flooding attacks. In: Proceedings of IEEE Symposium on Security and Privacy (May 2004) 12. Yang, X., Wetherall, D., Anderson, T.: A DoS-limiting network architecture. In: Proceedings of ACM SIGCOMM (August 2005) 13. Argyraki, K., Cheriton, D.: Scalable Network-layer Defense Against Internet Bandwidth-Flooding Attacks. IEEE/ACM Transactions on Networking (2009) 14. Aura, T., Nikander, P., Leiwo, J.: DoS-resistant Authentication with Client Puzzles. In: Proceedings of Security Protocols Workshop (2001) 15. Dean, D., Stubblefield, A.: Using client puzzles to protect TLS. In: Proceedings of USENIX Security Symposium (2001) 16. Juels, A., Brainard, J.: Client puzzles: A cryptographic countermeasure against connection depletion attacks. In: Proceedings of ISOC NDSS (1999) 17. Parno, B., Wendlandt, D., Shi, E., Perrig, A., Maggs, B., Hu, Y.-C.: Portcullis: Protecting connection setup from denial-of-capability attacks. In: Proceedings of the ACM SIGCOMM (August 2007) 18. Wang, X., Reiter, M.: Defending against denial-of-service attacks with puzzle auctions. In: Proceedings of IEEE Symposium on Security and Privacy (May 2003) 19. Chou, J., Lin, B., Sen, S., Spatscheck, O.: Proactive surge protection: A defense mechanism for bandwidth-based attacks. In: USENIX Security Symposium (2008) 20. Stoica, I., Shenker, S., Zhang, H.: Core-stateless fair queueing: A scalable architecture to approximate fair bandwidth allocations in high speed networks. In: Proceedings of ACM SIGCOMM (1998)

Type-Based Analysis of PIN Processing APIs Matteo Centenaro1, Riccardo Focardi1 , Flaminia L. Luccio1 , and Graham Steel2 1

Dipartimento di Informatica, Universit` a Ca’ Foscari Venezia, Italy 2 LSV, ENS Cachan & CNRS & INRIA, France

Abstract. We examine some known attacks on the PIN verification framework, based on weaknesses of the security API for the tamperresistant Hardware Security Modules used in the network. We specify this API in an imperative language with cryptographic primitives, and show how its flaws are captured by a notion of robustness that extends the one of Myers, Sabelfeld and Zdancewic to our cryptographic setting. We propose an improved API, give an extended type system for assuring integrity and for preserving confidentiality via randomized and nonrandomized encryptions, and show our new API to be type-checkable.

1

Introduction

In the international ATM (cash machine) network, users’ personal identification numbers (PINs) have to be sent encrypted from the PIN Entry Device (PED) on the terminal to the issuing bank for checking. The PIN is encrypted in the PED under a key shared with the server or switch to which the ATM is connected. The PIN is then decrypted and re-encrypted under the key for an adjacent switch, to which it is forwarded. Eventually, the PIN reaches the issuing bank, by which time it may have been decrypted and re-encrypted several times. The issuing bank has no direct control over the intermediate switches, so to establish trust, the international standard ISO 9564 (ANSI X9.8) stipulates the use of tamper proof cryptographic Hardware Security Modules (HSMs). These HSMs protect the PIN encryption keys, and in the issuing banks, they also protect the PIN Derivation Keys (PDKs) used to derive the customer’s PIN from non-secret validation data such as their Personal Account Number (PAN). All encryption, decryption and checking of PINs is carried out inside the HSMs, which have a carefully designed API providing functions for translation (i.e., decryption under one key and encryption under another one) and verification (i.e., PIN correctness checking). The API must be designed so that should an attacker gain access to a host machine connected to an HSM, he cannot abuse the API to obtain PINs. In the last few years, several attacks have been published on the APIs in use in these systems [8,9,10]. Very few of these attacks directly reveal the PIN. Instead, they involve the attacker calling the API commands repeatedly with slightly different parameter values, and using the results (which may be error codes) to

Work partially supported by Miur’07 Project SOFT.

M. Backes and P. Ning (Eds.): ESORICS 2009, LNCS 5789, pp. 53–68, 2009. Springer-Verlag Berlin Heidelberg 2009

54

M. Centenaro et al.

deduce the value of the PIN. High-profile instances of many PINs being stolen from hacked switches have increased interest in the problem [1,2]. PIN recovery attacks have been formally analysed, but previously the approach was to take a particular API configuration and measure its vulnerability to combinations of known attacks [26]. Other researchers have proposed improvements to the system to blunt the attacks, but these suggestions address only some attacks, and are “intended to stimulate further research” [22]. We take a step in that direction, using the techniques of language-based security [24]. One can immediately see that the current API functions allow an ‘information flow’ from the high security PIN to the low security result. However, the function must reveal whether the encrypted PIN is correct or not, so some flow is inevitable. The language-based security literature has a technique for dealing with this: a ‘declassification policy’ [25] permitting certain flows. The problem is that an intruder can often manipulate input data in order to declassify data in an unintended way. Again there is a technique for this: ‘robust declassification’ [23], whereby we disallow ‘low integrity’ data, which might have been manipulated by the attacker, to affect what can be declassified. However, the functionality of the PIN verification function requires the result to depend on low-integrity data. The solution in the literature is ‘endorsement’ [23], where we accept that certain low integrity data is allowed to affect the result. However, in our examples, endorsing the low integrity data permits several known attacks. From this starting point, we propose in this paper an extension to the languagebased security framework for robust declassification to allow the integrity of inputs to be assured cryptographically by using Message Authentication Codes (MACs). We present semantics and a type system for our model, and show how it allows us to formally analyse possible improvements to PIN processing APIs. We believe our modelling of cryptographically assured integrity to be a novel contribution to language based security theory. In addition, we give new proposals for improving the PIN processing system. There is not room here to describe the operation of the ATM network in detail. Interested readers are referred to existing literature [10,22,26]. In this paper, we first introduce our main case study, the PIN verification command ( 1). We review some notions of language based security ( 2). We describe our modelling of cryptographic primitives, and in particular MACs for assuring integrity, and we show why PIN verification fails to be robust ( 3). Our type system is presented ( 4), the MAC-based improved API is type-checked ( 5), and finally we conclude ( 6). For lack of space we omit all the proofs (see [14]). The Case Study. We have observed how PINs travelling along the network have to be decrypted and re-encrypted under a different key, using a translation API. Then, when the PIN reaches the issuing bank, its correspondence with the validation data 1 is checked via a verification API. We focus on this latter API, which we call PIN V: it checks the equality of the actual user PIN and the trial PIN inserted at the ATM and returns the result of the verification or an error 1

This value is up to the issuing bank. It is typically an encoding of the user PAN and possibly other ‘public’ data, such as the card expiration date or the customer name.

Type-Based Analysis of PIN Processing APIs

55

code. The former PIN is derived through the PIN derivation key pdk , from the public data offset , vdata, dectab (see below), while the latter comes encrypted under key k as EPB (Encrypted PIN block). Note that the two keys are preloaded in the HSM and are never exposed to the untrusted external environment. In this example we will assume only one key of each type (k and pdk ) is used. The API, specified below, behaves as follows: The user PIN of length len is obtained by encrypting validation data PIN V(PAN , EPB, len, offset, vdata, dectab ) { x1 := encpdk (vdata); vdata with the PIN derivation key x2 := left(len, x1 ); pdk (x1 ), taking the first len hexadecx3 := decimalize(dectab, x2 ); x4 := sum mod10(x3 , offset); imal digits (x2 ), decimalising through x5 := deck (EPB); dectab (x3 ), and digit-wise summing x6 := fcheck(x5 ); if (x6 =⊥) then return( format wrong ); modulo 10 the offset (x4 ). In fact, the if (x4 = x6 ) then return( P IN correct ); obtained decimalised value x3 is the else return( P IN wrong )} ‘natural’ PIN assigned by the issuing bank to the user. If the user wants to choose her own PIN, an offset is calculated by digit-wise subtracting (modulo 10) the natural PIN from the user-selected one. The trial PIN is recovered by decrypting EPB with key k (x5 ), and extracting the PIN by removing the random padding and checking the PIN is correctly formatted (x6 ). Finally, the equality of the user PIN (x4 ) and the trial PIN (x6 ) is returned. The given code specifies a strict subset of the real PIN verification function named Encrypted PIN Verify [18]. Example 1. Let len=4, offset =4732, dectab=9753108642543210, this last parameter encoding this mapping: 0 → 9, 1 → 7, . . . , F → 0. Let also x1 = encpdk (vdata) = A47295FDE32A48B1. Then, x2 = left(4, A47295F DE32A48B1) = A472 , x3 = decimalize(dectab, A472) = 5165, and x4 = sum mod10(5165, 4732) = 9897. This completes the user PIN recovery part. Let now (9897, r) denote PIN 9897 correctly formatted and padded with a random r, as required by ISO1 and let us assume that EPB = {|9897, r|}k . We thus have: x5 = deck ({|9897, r|}k ) = (9897, r), and x6 = fcheck(9897, r) = 9897. Finally, since x6 is different from ⊥ (failure) and x4 = x6 the API returns PIN correct .

2

Basic Language and Security

In this section, we recall a standard imperative language core and some basic security notions. An expression e is either a variable x or an arithmetic/Boolean operation on expressions e1 op e2 . Denoting Boolean expressions by b, the syntax of commands is c ::= skip | x := e | c1 ; c2 | if b then c1 else c2 | while b do c. Memories M are finite maps from variables to values and we write M(x ) to denote the value associated to x in M. Moreover, e ↓M v denotes the evaluation of expression e in a memory M giving value v as a result: for example, x ↓M M(x ) and x + x ↓M M(x ) + M(x ). Moreover, M, c ⇒ M denotes the execution of a command c in a memory M, resulting in a new memory M . Finally, M[x → v ] denotes the update of variable x to the new value v . For example, M, x := e ⇒

56

M. Centenaro et al.

M[x → v ] if e ↓M v . Security APIs are executed on trusted hardware with no multi-threading, we thus adopt a standard big-step semantics similar to that of Volpano et al. [28] which can be found in [14]. Security. A security environment Γ maps each variable to a level of confidentiality and integrity. To keep the setting simple, we limit our attention to two possible levels: high (H) and low (L). For any given confidentiality (integrity) levels 1 , 2 , we write 1 C 2 ( 1 I 2 ) to denote that 1 is as restrictive or less restrictive than 2 . In particular, low-confidentiality data may HL be used more liberally than high-confidentiality ones, thus in this LL case L C H; dually, H I L. We consider the product of the HH above confidentiality and integrity lattices, and we denote with LH the component-wise application of C and I (on the right). Definition 1 (Indistinguishability). Let M| denote the restriction of memory M to variables whose security level is at or below level . M1 and M2 are indistinguishable at level , written M1 = M2 , if M1 | = M2 | . Two configurations are indistinguishable, written M1 , c = M2 , c, if whenever M1 , c ⇒ M1 and M2 , c ⇒ M2 then M1 = M2 . They are strongly indistinguishable, written M1 , c ∼ = M2 , c, if M1 , c = M2 , c and M1 , c ⇒ M1 , M2 , c ⇒ M2 . Noninterference requires that data from one level should never interfere with lower levels. Intuitively, command c satisfies noninterference if, fixed a level , two indistinguishable memories remain indistinguishable even after executing c. Definition 2 (Noninterference). A command c satisfies noninterference if ∀ , M1 , M2 we have that M1 = M2 implies M1 , c = M2 , c. Noninterference formalizes full security, with no leakage of confidential information ( = LL) or corruption of high-integrity data ( = HH). The property proposed by Myers, Sabelfeld and Zdancewic (MSZ) in [23], called robustness, admits some form of declassification (or downgrading) of confidential data, but requires that attackers cannot influence the secret information declassified by a program c. In our case study of section 1, PIN V returns the correctness of the typed PIN which is a one-bit leak of information about a secret datum. Robustness will allow us to check that attackers cannot abuse such a declassification and gain more information than intended. Consider a pair of memories M1 , M2 which are not distinguishable by an intruder, i.e., M1 =LL M2 . The execution of c on these memories may leak confidential information violating noninterference, i.e., M1 , c =LL M2 , c. Robustness states that if the behaviour of the command c is not distinguishable on M1 and M2 then the same must happen for every pair of memories M1 , M2 the attacker may obtain starting from M1 , M2 . To characterize these memories note that: (i) they are still indistinguishable by the intruder, i.e., M1 =LL M2 , as he is deterministic and starts from indistinguishable memories; (ii) they only differ from the initial ones in the low-integrity part, i.e., M1 =HH M1 , M2 =HH M2 , given that only low-integrity variables can be modified by intruders. Following MSZ, we require that attackers start from strongly indistinguishable, terminating configurations to avoid they ‘incompetently’ self-corrupt their observations.


57

Definition 3 (Robustness). Command c is robust if ∀M1 , M2 , M1 , M2 s.t. M1 =LL M2 , M1 =LL M2 , M1 =HH M1 , M2 =HH M2 , it holds M1 , c ∼ =LL M2 , c implies M1 , c =LL M2 , c. This notion is a novel simplification of that of MSZ, who allow a malicious user to insert untrusted code at given points in the trusted code. In security APIs this is not permitted: an attacker can call a security API any number of times with different parameters but he can never inject code inside it, moreover, no intermediate result will be made public by the API. This leads to a simpler model where attackers can only act before and after each security API invocation, with no need of making their code explicit. Memory manipulations and multiple runs performed by attackers are covered by considering all =HH memories. Example 2. We write x to denote a variable of level . Consider a program P in which variable xLL stores the user entered PIN, yHH contains the real one, and zLL := (xLL = yHH ) , i.e., zLL says if the entered PIN is the correct one or not. This program is neither noninterferent nor robust. M1 M2 To see this latter fact, consider the memories on the yHH : 1234 yHH : 5678 right. It clearly holds that M1 =HH M1 , M2 =HH M2 xLL : 1111 xLL : 1111 and M1 =LL M2 , M1 =LL M2 , but the execution of M1 M2 P in the first two memories leads to indistinguishable y : 1234 yHH : 5678 HH results in zLL , false/false, thus M1 , P ∼ =LL M2 , P , xLL : 1234 xLL : 1234 while for the second ones we get true/false, and so M1 , P =LL M2 , P . Intuitively, the attacker has ‘guessed’ one of the secret PINs and the program is revealing that his guess is correct: the attacker can tamper with the declassification mechanism via xLL .

3

Cryptographic Primitives

In order to model our API case-study, we now extend arithmetic and Boolean expressions with confounder generation new(), symmetric cryptography encx (e), decx (e), Message Authentication Codes (MACs) macx (e), pairing pair(e1 , e2 ) and projection fst(e), snd(e). We extend standard values as, e.g., Booleans and integers, with confounders r ∈ C and cryptographic keys k ∈ K. On these atomic values we build cryptographic values and pairs ranged over by v : more specifically, {|v |}k and v k respectively represent the encryption and the MAC of v using k as key, and (v1 , v2 ) is a pair of values. We will often omit the brackets to simplify the notation, e.g., we will write {|v1 , v2 |}k to indicate {|(v1 , v2 )|}k . Based on this set of values we can easily give the semantics of the special expressions mentioned above. For example, we have encx (e) ↓M {|v |}k whenever e ↓M v and x ↓M k . Moreover, decx (e ) ↓M v if e ↓M {|v |}k and x ↓M k ; otherwise decx (e ) ↓M ⊥, representing failure, and analogously for the other expressions. Confounder generation new() ↓M r extracts a ‘random’ value, noted r ← C , from a set of values C . In real cryptosystems, the probability of extracting the same random confounder is assumed to be negligible, if the set is suitably large, so we symbolically model random extraction by requiring that extracted values

58

M. Centenaro et al.

are always different. Formally, if r , r ← C then r = r . Moreover, similarly to [3,4], we assume C to be disjoint from the set of atomic names used in programs. Full semantics of expressions can be found in [14]. To guarantee a safe use of cryptography we also assume that every expression e different from enc, dec, mac, pair, and that every Boolean expression, except the equality test: (i) always fails when applied to special values such as confounders, keys, ciphertexts, and MACs (even when occurring in pairs), producing a ⊥; (ii) never produces those values. This is important to avoid “magic” expressions which encrypt/decrypt/MAC messages without knowing the key like, e.g., magicdecrypt(e) ↓M v when e ↓M {|v |}n . However, we permit equality checks as they allow the intruder to track equal encryptions, as occurs in traffic analysis. Security with cryptography. We now rephrase the notions of noninterference and robustness in order to accommodate cryptographic primitives. In doing so, we extend [13] in a non-trivial way by (i) accounting for integrity primitives such as MACs; (ii) removing the assumption that cryptography is always randomized via confounders. This latter extension is motivated by the fact that our case study does not always adopt randomization in cryptographic messages. Notice, however, that non-randomized encrypted messages are subject to traffic analysis, thus confidentiality of those messages cannot be guaranteed except in special cases that we will discuss in detail. In order to extend the indistinguishability notion of definition 1 to cryptographic primitives we assume that the level of keys is known a-priori. We believe this is a fair assumption, since in practice it is fundamental to have information about a key’s security before using it. Since we have only defined symmetric key cryptography we only need trusted (of level HH ) and untrusted keys (of level LL). The former are only known by the HSMs while the latter can be used by the attackers. This is achieved by partitioning the set K into KHH and KLL . As the intruder cannot access (or generate, in case of MACs) cryptographic values protected by HH keys, one might state that such values are indistinguishable. However, an attacker might detect occurrences of the same cryptographic values in different parts of the memory, as occurs in some traffic analysis attacks. Example 3. Consider the program zLL := (xLL = yLL ), which writes the result of the equality test between xLL and yLL into M1 M2 zLL . Given that it only works on LL variables it xLL : {|1234|}k xLL : {|9999|}k can be considered as an intruder-controlled proyLL : {|1234|}k yLL : {|5678|}k gram. Consider the memories M1 and M2 , with k ∈ KHH . An attacker cannot distinguish {|1234|}k from {|9999|}k and {|1234|}k from {|5678|}k . However, running the above intruder-program on these memories, he respectively obtains zLL = true and zLL = false, i.e., the resulting memories clearly differ. The intruder has in fact detected the presence of two equal ciphertexts in the first memory which allows him to distinguish M1 and M2 . Patterns and indistinguishability. This ability of the attacker to find equal cryptographic values in the memories is formalized through the notion of pattern inspired by Abadi et al. [4,5] and already adopted for modelling noninterference


59

[13,20]. Note that we adopt patterns to obtain a realistic notion of distinguishability of ciphertexts in a symbolic model, and not to address computational soundness as is done, e.g., in [4,5,6]. Patterns p extend values with the new symbol v representing messages encrypted with a key not available at the observation level . More precisely, we define a function p (v) which takes a value and produces the corresponding pattern by replacing all the encrypted values v protected by keys of level with v , and leaving all the other values unchanged. For example, for {|1234|}k in the example above we have pLL ({|1234|}k ) = {|1234|}k while pHH ({|1234|}k ) = {|1234|}k . Function p (v) descends recursively into subvalues. For example, if k ∈ KLL we have pLL ({|{|10|}k , 20|}k ) = {|{|10|}k , 20|}k . In case of MACs, we just descend into subvalues, i.e., p (v k ) = p (v )k , i.e., we assume that all messages inside MACs are public. Notice that, in v , v is the whole (inaccessible) encrypted value, instead of just a confounder as used in previous works [4,5,13,20]. In these works, each new encryption includes a fresh confounder which can be used as a ‘representative’ of the whole encrypted value. Here we cannot adopt this solution since our confounders are optional. To disregard the values of counfounders, once the corresponding ciphertext has been accessed (i.e., when knowing the key), we abstract them as the constant ⊥. Given a bijection ρ : v → v , that we call hidden values substitution, we write pρ to denote the result of applying ρ to the pattern p, and we write Mρ to denote the memory in which ρ has been applied to all the patterns of M. On hidden values substitutions we always require that keys are correctly mapped. Formally ρ({|v |}k ) = {|v |}k . Definition 4 (Crypto-indistinguishability). Let p (M) denote M| in which all of the values v have been substituted by p . M1 and M2 are indistinguishable at , written M1 ≈ M2 , if there exists ρ such that p (M1 ) = p (M2 ) ρ . Example 4. Consider again M1 and M2 of example 3. We observed that they differ at level LL because of the presence of two equal ciphertexts in M1 . Since k ∈ KHH we obtain the values of xLL and yLL below. It is impossible to find a hidden values substitution ρ mapping the first pLL (M1 ) pLL (M2 ) memory to the second, as {|1234|}k cannot be xLL : {|1234|}k xLL : {|9999|}k mapped both to {|9999|}k and {|5678|}k . Thus yLL : {|1234|}k yLL : {|5678|}k we conclude that M1 ≈LL M2 . If, instead, M1 (yLL ) were, e.g., {|2222|}k we might use ρ = [{|9999|}k → {|1234|}k , {|5678|}k → {|2222|}k ] obtaining pLL (M1 ) = pLL (M2 )ρ and thus M1 ≈LL M2 . Noninterference and robustness. Security notions of section 2 naturally extend to the new cryptographic setting by substituting = with ≈ everywhere. We need to be careful that memories do not leak cryptographic keys, i.e., that keys disclosed at level are all of that level or below, and that variables intended to contain keys really do contain keys. This will be achieved in section 4 via a notion of memory well-formedness.

60

M. Centenaro et al.

Formal analysis of an API attack on PIN V. We now illustrate how the lack of integrity of the API parameters can be exploited to mount a real attack leaking the PIN, and we show how this is formally captured as a violation of robustness. We consider the case study of section 1 and concentrate on two specific parameters, the dectab and the offset , which are used to respectively calculate the values of x3 and x4 . A possible attack on the system works by iterating the following two steps, until the whole PIN is recovered [9]: 1. The intruder picks a decimal digit d, changes the dectab function so that values previously mapped to d now map to d + 1 mod 10, and then checks whether the system still returns PIN correct . Depending on this, the intruder discovers whether or not digit d is present in the user ‘natural’ PIN contained in x3 ; 2. when a certain digit is discovered in the previous step by a PIN wrong output, the intruder also changes the offset until the API returns again that the PIN is correct. This allows the intruder to locate the position of the digit. Example 5. In example 1 we let len=4, dectab=9753108642543210, offset =4732, x1 = A47295FDE32A48B1, EPB ={|9897, r|}k . With these parameters the API returns PIN correct . The attacker first chooses dectab =9753118642543211, where the two 0’s have been replaced by 1’s. The aim is to discover whether or not 0 appears in x3 . Invoking the API with dectab we obtain the same intermediate and final values, as decimalize(dectab , A472) = decimalize(dectab, A472) = 5165. This means that 0 does not appear in x3 . The attacker proceeds by replacing the 1’s of dectab by 2’s: with dectab =9753208642543220 he obtains that decimalize(dectab , A472)=5265 = decimalize(dectab, A472)=5165, reflecting the presence of 1’s in the original value of x3 . Then, x4 =sum mod10(5265, 4732) =9997 instead of 9897 returning P IN wrong . The intruder now knows that digit 1 occurs is in x3 . To discover its position and multiplicity, he now tries variations of the offset so to ‘compensate’ for the modification of the dectab. In particular, he tries to decrement each offset digit by 1. For example, testing the position of one occurrence of one digit amounts to trying the following offset variations: 3732, 4632, 4722, 4731. Notice that, in this specific case, offset value 4632 makes the API return again P IN correct . The attacker now knows that the second digit of x3 is 1. Given that the offset is public, he also calculates the second digit of the user PIN as 1 + 7 mod 10 = 8. The above attack is based on the lack of integrity of the input data, which allows an attacker to influence the declassification mechanism. We now show that this is formally captured as a violation of robustness. We adopt a small trick to model the PIN derivation encryption of x1 : we write vdata as a ciphertext, e.g., {|A47295FDE32A48B1|}pdk , and we model the first encryption as a decryption x1 := decpdk (vdata). The reason for this is that we have a symbolic model for encryption that does not produce any low level bit-string encrypted data. Notice also that this model is reasonable, as the high-confidentiality of the encrypted value is ‘naturally’ protected by the HH PIN derivation key. Consider now the four memories below, that only differ in the value of EPB and dectab. It clearly holds that M1 ≈HH M1 , M2 ≈HH M2 and M1 ≈LL M2 ,


61

M1 ≈LL M2 , the last two using ρ = [{|1234,r |}k → {|9897,r|}k ]. Since parameters are all at level LL, these memories could be built by an attacker sniffing all encryptions arriving at the verification facility. If we execute PIN V in M1 and M2 we obtain P IN wrong in both cases as for memory M2 , the encrypted PIN is wrong, and for memory M1 , the encrypted PIN M1 M2 is correct but the dectab will change the value of dedectab dectab rived PIN. It follows M1 , PIN V ≈LL M2 , PIN V. In {|9897, r|}k {|1234, r |}k M1 and M2 the dectab is the correct one. Thus, exeM1 M2 cuting PIN V gives, respectively, P IN correct and dectab dectab P IN wrong and so M1 , PIN V ≈LL M2 , PIN V, {|9897, r|}k {|1234, r |}k breaking robustness. To overcome this problem, integrity of the input must be established.

4

Type System

We now give a new type system to statically check that a program with cryptographic primitives satisfies robustness and, if it does not declassify any information, noninterference. We will then use it to type-check a MAC-based variant of the PIN verification and PIN translation API. We refine integrity levels by introducing the notion of dependent domains used to track integrity dependencies among variables. Dependent domains are denoted ˜ where D ∈ D is a domain name. Intuitively, the values of domain D : D ˜ are D:D ˜ determined by the values in the set of domains D. For example, PIN : PAN can be read as ‘the PIN value relative to the account number PAN’: when the PAN is fixed, the value of the PIN is also fixed. A domain D : ∅, also written D, is called integrity representative and it can be used as a reference for checking the integrity of other domains. In fact, integrity representatives cannot be modified by programs and their values remain constant at run-time. ˜ written [D : D], ˜ is The integrity level associated to a dependent domain D : D, ˜ higher than H, i.e., [D : D] I H. In some cases, e.g., in arithmetic operations, ˜ and we we necessarily loose information about the precise result domain D : D ˜ ˜ The only record the fact the value is determined by domains D, written • : D. ˜ ˜ ˜ resulting integrity preorder is [D : D1 ] [• : D1 ] I [• : D2 ] I H I L with ˜1 ⊆ D ˜ 2 . We write δI to note the new integrity levels L, H, [D : D], ˜ [• : D], ˜ and D δC to note the usual confidentiality levels L, H. We also write C in place of [•], to denote a constant value with no specific domain. Based on new levels δ = δC δI , we can give the type syntax: τ ::= δ | cKμδ (τ ) κ | encδ κ | mKδ (τ ) | (τ1 , τ2 ) Type δ is for generic data at level δ; types cKμδ (τ ) κ and mKδ (τ ) respectively refer to encryption and MAC keys of level δ, working on data of type τ ; κ is a label that uniquely identifies one key type and label μ indicates whether the ciphertext is ‘randomized’ via confounders (μ = R) or not (μ missing); we only consider untrusted and trusted (constant) keys, respectively of level LL and

62

M. Centenaro et al. Table 1. Security Type System - Cryptographic expressions with trusted keys (enc-r)

Δ(x ) = cKR Δe:τ HC (τ ) κ Δ encR x (e) : encLCLI (τ ) κ

(dec-μ)

Δ(x ) = cKμ HC (τ ) κ

(enc-d)

(mac)

Δ(x ) = mKδ (τ ) Δ e : τ Δ macx (e) : LL L(τ )

Δ e : encδC CLI (τ ) κ Δ decμ x (e) : τ

LC (τ ) = H

Δ(x ) = cKHC (τ ) κ Δ e : τ CloseDDdet (τ ) Δ encx (e) : encLCLI (τ ) κ

HC; encδ κ is the type for ciphertexts at level δ, obtained using the unique key labelled κ; pairs are typed as (τ1 , τ2 ). A security type environment Δ : x → τ maps variables to security types. The security environment Γ can be derived from Δ by just ‘extracting’ the level of the types as follows: L(δ) = L(Kδ (τ ) κ) = L(encδ κ) = δ and L((τ1 , τ2 )) = L(τ1 ) L(τ2 ). Notice that we write Kδ (τ ) κ to indifferently denote encryption and MAC key types. We also write LC (τ ) and LI (τ ) to respectively extract the confidentiality and integrity level of type τ . The subtype preorder ≤ extends the security level preorder on levels δ with encδC δI κ ≤ δC L. Moreover, from now on, we will implicitly identify low-integrity types at the same security level, i.e., we will not distinguish τ and τ whenever L(τ ) = L(τ ) = δC L, written τ ≡ τ . This reflects the intuitions that we do not make any assumption on what is stored into a low-integrity variable. We do not include high keys in the subtyping and we also disallow the encryption (and the MAC) of such keys: formally, in Kδ (τ ) κ and (τ1 , τ2 ) types τ, τ1 , τ2 = KHC (τ ) κ. We believe that transmission of high keys can be easily accounted for but we leave this extension as future work. Closed key types. In some typing rules we will require that types transported by cryptographic keys are ‘closed’, meaning that they are all dependent domains and all the dependencies are satisfied, i.e., all the required representatives are present. As an example, consider cKμHC (τ ) κ with τ = (H[D], H[D : D]). Types transported by the key are all dependent domains and are closed: the set of dependencies is {D}, since [D : D] depends on D, and the set of representatives is {D}, because of the presence of the representative [D]. If we instead consider τ = (H[D], H[D : D], H[D : D ]) we have that the set of dependencies is {D, D } and the set of representatives is {D}, meaning that the type is not closed: not all the dependencies can be found in the type. We write CloseDD(τ ) to denote that τ is closed and only contains dependent domains. When it additionally does not transport randomized ciphertexts we write CloseDDdet (τ ). We will describe the importance of this closure conditions when describing the typing rules. Typing cryptography and MACs. Expressions are typed with judgment Δ e : τ , derived from the rules in Table 1. For lack of space we only report rules for trusted cryptographic operations; full type-system can be found in [14].


63

Table 2. Security Type System - Commands Δ(x ) = δC H Δ e : δC H pc δC H Δ, pc x := declassify(e)

Δ(x ) = τ

Δ e : τ pc L(τ ) LH Δ, pc x := e

Δ(x ) = mKHC (L[D], τ ) Δ z : L[D] Δ e : LL Δ e : LL Δ(y) = τ IRs(L[D], τ ) = {D} CloseDD(L[D], τ ) Δ, pc c1 Δ, pc c2 pc L(τ ) LH Δ, pc if macx (z, e) = e then (y := e; c1 ) else c2 ; ⊥MAC R Rule (enc-r) is for randomized encryption: We let encR x (e) and decx (e) denote, respectively, encx (e, new()) and fst(decx (e)), i.e., an encryption randomized via a fresh confounder and the corresponding decryption. The typing rule requires a trusted key HC. The integrity level of the ciphertext is simply the least upper bound of the levels of the key and the plaintext; the confidentiality level, instead, is L, meaning that the resulting ciphertext preserves secrecy even when written on an public/untrusted part of the memory. Rule (dec-μ) is for (trusted) decryption and gives the correct type τ to the obtained plaintext, if the confidentiality of the plaintext is at least H. This is to avoid that indistinguishable ciphertexts are decrypted and then written on low variables, breaking noninterference in a trivial way. Rule (enc-d) is the most original one. It encodes a way to guarantee secrecy even without confounders, i.e., with no randomization. The idea comes from format ISO0 for the EPB, which intuitively combines the PIN with the PAN before encrypting it in order to prevent codebook-attacks. Consider, for example the ciphertext {|PAN, PIN|}k . Since every account, identified by the PAN, has its own PIN, the PIN can be thought of as at level [PIN : PAN] (‘the PIN is fixed relative to the PAN’). Thus equal PANs will determine equal PINs, which implies that different PINs will always be encrypted together with different PANs, producing different EPBs. This avoids, for example, allowing an attacker to build up a codebook of all the PINs. Intuitively, the PAN is a sort of confounder that is ‘reused’ only when its own PIN is encrypted. The rule requires CloseDDdet (τ ) which intuitively ensures that the ciphertext is completely determined by the included integrity representative (e.g., the PAN), playing the role of confounder. As in (enc-r) integrity is propagated and confidentiality of the ciphertext is L. Rule (mac) is for the generation of MACs. Here, the confidentiality level of the key does not contribute to the confidentiality level of the MAC, which just takes the one of e. This reflects the fact that we only use MACs for integrity and we always assume the attacker knows the content of MACs. The reason why we force integrity to be low is technical and, more specifically, is to forbid declassification of cryptographic values, which would greatly complicate the proof of robustness. By the way, this is not limiting as there are no good reasons to declassify what has been created to be low-confidentiality.

Typing rules for commands. As in existing approaches [23] we introduce in the language a special expression declassify(e) for explicitly declassifying the confidentiality level of an expression e to L. This new expression has no operational import, i.e., declassify(e) ↓M v iff e ↓M v . Declassification is thus only

64

M. Centenaro et al.

useful in the type-system to isolate program points where downgrading of security happens, in order to control robustness. Judgments for commands have the form Δ, pc c where pc is the program counter level. It is a standard way to track what information has affected control flow up to the current program point [23]. For example, when entering a while loop, the pc is raised to be higher or equal to the level of the loop guard expression. This prevents such an expression to allow flows to lower levels. In Table 2 we report the rule for declassification plus the only two that differ from [23]. The first rule lets a high integrity expression to be declassified, i.e., assigned to some high-integrity variable independent of its confidentiality level, when also the program counter is at high-integrity and the assignment to the variable is legal (pc δC H). The high-integrity requirement is for guaranteeing robustness: no attacker will be able to influence declassification. Assignments (second rule) are only possible at or above the pc level and at lower integrity levels (dependent domains) if LI (pc) = H. This makes sense since we never move our observation level below LH and is achieved by requiring pc L(τ ) LH. The third rule is peculiar of our approach: it allows the checking of a MAC with respect to an integrity representative z. The rule requires that the first parameter z is typed at level L[D]; the second parameter e and the MAC value e are typed LL. If the MAC succeeds, variable y of type τ is bound to the result of e through an explicit assignment in the if-branch. Notice that such an assignment would be forbidden by the type-system, as it is promoting the integrity of an LL expression to an unrestricted type τ (as far as pc is high integrity). This can however be proved safe since the value returned by the LL expression matches an existing MAC, guaranteeing data integrity and allowing us to ‘reconstruct’ their type from the type of the MAC key. Side conditions IRs(L[D], τ ) = {D} and CloseDD(L[D], τ ) ensure that the MAC contains only values which directly depend on the unique integrity representative given by variable z. The ‘then’ branch is typed without any particular restriction, while the ‘else’ one is required to end with a special failure command ⊥MAC which just aims at causing non-termination of the program (it may be equivalently thought of as a command with no semantics, which never reduces, or a diverging program as, e.g., while true do skip). This is needed to prevent the attacker from breaking integrity and robustness by just calling an API with incorrect MACs. In fact, we can assume the attacker knows which MACs pass the tests and which do not (unless he is trying brute-force/cryptanalysis attacks on the MAC algorithm, that we do not account for here) and by letting the else branch fail we just disregard those obvious, uninteresting, information flows. Security results. We now prove that well-typed programs satisfy robustness and, in case they do not declassify any information, noninterference. Our results hold under some reasonable well-formedness/integrity assumptions on the memories: (i) variables of high level key-type really contain keys of the appropriate level, and such keys never appear elsewhere in the memory; (ii) values of variables or encrypted messages at integrity H, or below, must adhere to the expected type; for example, the value of a variable typed as high integrity pair is


65

˜ are uniquely deexpected to be a pair; (iii) values for dependent domains [D : D] ˜ termined by the values of the integrity representatives D, e.g., when they appear together in an encrypted message or a MAC or when they have been checked in an if-MAC statement; (iv) confounders are used once: there cannot be two different encrypted messages with the same confounder. Condition (iii) states, for example, that if a MAC is expected (from the type of its key) to contain the PAN, of level [PAN] and the relative PIN, of level [PIN : PAN], encrypted with another key, all of the possible MACs with that key will respect a function f[PIN:PAN] , pre-established for each memory. For example, let us assume f[PIN:PAN] (pani ) = pini. We have that all of these MACs are wellformed: pan1 , {|pin1 |}k k , pan2 , {|pin2 |}k k , . . . , panm , {|pinm |}k k , as they all respect f[PIN:PAN] . Our first result states that a well-typed program run on well-formed memory, noted Δ M, always returns a well-formed memory: Proposition 1. If Δ, pc c, Δ M and M, c ⇒ M then Δ M . From now on, we will implicitly assume that memories are well-formed. The next result states that when no declassification occurs in a program, then noninterference holds. This might appear surprising as MAC checks seem to potentially break integrity: an attacker might manipulate one of the MAC parameters to gain control over the MAC check. In this way he can force the execution of one branch or the other, however recall that by inserting ⊥MAC at the end of the else branch we force that part of the program not to terminate. Weak indistinguishability will thus consider such an execution equivalent to any other, which means it will disregard that (uninteresting) situation. The next lemmas are used to prove the main results. The first one is peculiar to our extension with cryptography: if an expression is typed below the observation level , we can safely assign it to two equivalent memories and still get equivalent memories. We cannot just check the obtained values in isolation as, by traffic analysis (modelled via patterns), two apparently indistinguishable ciphertexts might be distinguished once compared with others. Lemma 1 (Expression -equivalence). Let M1 ≈ M2 and let Δ e : τ and e ↓Mi vi . If L(τ ) or L(Δ(x)) then M1 [x → vi ] ≈ M2 [x → vi ]. Lemma 2 (Confinement). If Δ, pc c then for every variable x assigned to in c and such that Δ(x ) = τ it holds that pc L(τ ) LH. Theorem 1 (Noninterference). Let c be a program which does not contain any declassification statement. If Δ, pc c then c satisfies noninterference.2 We can now state our final results on robustness. We will consider programs that assign declassified data to special variables assigned only once. This can be easily achieved syntactically, e.g., by using one different variable for each declassification statement, i.e., x1 := declassify1 (e1 ), . . . , xm := declassifym (em ), and avoiding placing declassifications inside while loops. These special variables are 2

For technical reasons this results does not hold for level LH (see [14] for details).

66

M. Centenaro et al.

only assigned here. We call this class of programs Clearly Declassifying (CD). We do this to avoid, one more time, that attackers ‘incompetently’ hide flows by resetting variables after declassification has happened. Theorem 2 (Robustness). c ∈ CD and Δ, pc c imply c satisfies robustness.

5

A Type-Checkable MAC-Based API

We now discuss PIN V M a MAC-based improvement of PIN V, which prevents the attack of section 3, and several others from the literature. We show PIN V M is type-checkable using our type system, and we also show where the original API fails to type-check. The new API initially checks a MAC of all the parameters. Intuitively, the MAC check guarantees that the param- PIN_V_M ( PAN , EPB , len , offset , vdata , dectab , MAC ){ if (macak (P AN, EP B, len, of f set, vdata, dectab)== MAC ) eters have not been manipthen EPB := EP B ;len := len;offset := of f set; ulated. Some form of ‘legal’ vdata := vdata;dectab := dectab; manipulation is always possiPIN_V ( PAN , EPB ’ , len ’ , offset ’ , vdata ’ , dectab ’ ); else ret := ”integrity violation”; ⊥MAC } ble: an intruder can get a different set of parameters, e.g., eavesdropped in a previous PIN verification and referring to a different PAN, and can call the API with these parameters and the correct MAC validating their integrity. This is actually captured by our notion of dependent domains by typing all the MAC checked variables as dependent on the PAN. We show typing in detail: all the parameters PAN, EPB, len, offset, vdata, dectab, MAC are of type LL, since we assume the attacker can read and modify them. The important element is the mac key ak which has type mKHC (L[PAN], τ ) with type τ = encL[•:PAN] κek , L[LEN : PAN], L[OFFS : PAN], encL[•:PAN] κpdk , L[DECTAB : PAN]. Note that IRs(L[PAN], τ ) = {PAN} and CloseDD(L[PAN], τ ), meaning that L[PAN] and τ are all domains which only depends on representative PAN. All the checked variables are typed according to the above tuple, e.g., PAN with L[PAN], EPB with encL[•:PAN] κek and so on. Key ek is typed as R cKR HC (H[PIN : PAN]) κek and key pdk as cKHC (H[HEX : PAN]) κpdk . The result of the API will be stored in the ret variable whose type is LL. To complete the typing of the MAC we need to type the two branches. The else branch is trivial: the assignment to ret is legal and then it is followed by the MAC-fail command. The other one amounts to checking the original API with the new high integrity types. What happens is that x1 is typed H[HEX : PAN] by rule (dec-μ) and x2 , . . . , x4 are typed H[• : PAN] as results of arithmetic operations. x6 (which is modelled as decR k (EPB )) is typed H[PIN : PAN] by rule (dec-μ). Thus, x7 := declassify(x4 = x6 ), which we explicitly add to the code, can be typed LH as x4 = x6 types H[• : PAN] ≤ HH. Theorem 2 guarantees that PIN V M is robust. In the original version of the API, without the MAC check, x4 and x6 would only be typeable with low integrity, and hence the declassification would violate robustness. PIN translation API. This API is used to decrypt and re-encrypt a PIN under a different key and, possibly, a different format. In [14] we specify a


67

MAC-based extension of the API for specifically translate from ISO-1 to ISO0 and we type-check it. ISO-0 is not randomized and pads the PIN with data derived from the PAN. We thus use our (enc-d) typing rule to prove its security.

6

Conclusions

We have presented our extensions to information flow security types to model deterministic encryption and cryptographic assurance of integrity for robust declassification. We have shown how to apply this to PIN processing APIs. Most previous approaches to formalising cryptographic operations in information flow analysis have aimed to show how a program that is noninterfering when executed in a secure environment can be guaranteed secure when executed over an insecure network by using cryptography, see e.g., [7,13,16,20,27]. They typically use custom cryptographic schemes with strong assumptions, e.g. randomised cryptography and/or signing of all messages. This means they are not immediately applicable to the analysis of PIN processing APIs, which have weaker assumptions on cryptography. [11] presents what seems to be the only information flow model for deterministic encryption, that shows soundness of noninterference with respect to the concrete cryptography model. However, it does not treat integrity. Gordon and Jeffreys’ type system for authenticity in security protocols could be used to check correspondence assertions between the data sent from the ATM and the data checked at the API [17]. However, this would not address the problem of declassification, robustness or otherwise. Keighren et al. have outlined a framework for information flow analysis specifically for security APIs [19], though this also currently models confidentiality only. The formal analysis of security APIs has usually been carried out by Dolev-Yao style analysis of reachability properties in an abstract model of the API, e.g., [12,21,29]. This typically covers only confidentiality properties. We plan in future to refine our framework on further examples from the PIN processing world and elsewhere, and to model other cryptographic primitives which can be used to assure integrity such as (unkeyed) hash functions and asymmetric key digital signatures. We have also begun to investigate practical ways to implement our scheme in cost-effective way [15].

References 1. Hackers crack cash machine PIN codes to steal millions, http://www.timesonline. co.uk/tol/money/consumer_affairs/article4259009.ece 2. PIN Crackers Nab Holy Grail of Bank Card Security. Wired Magazine Blog ’Threat Level’, http://blog.wired.com/27bstroke6/2009/04/pins.html 3. Abadi, M.: Secrecy by typing in security protocols. JACM 46(5), 749–786 (1999) 4. Abadi, M., Jurjens, J.: Formal eavesdropping and its computational interpretation. In: Kobayashi, N., Pierce, B.C. (eds.) TACS 2001. LNCS, vol. 2215, pp. 82–94. Springer, Heidelberg (2001) 5. Abadi, M., Rogaway, P.: Reconciling two views of cryptography (the computational soundness of formal encryption). JCRYPTOL 15(2), 103–127 (2002) 6. Ad˜ ao, P., Bana, G., Herzog, J., Scedrov, A.: Soundness of formal encryption in the presence of key-cycles. In: de Capitani di Vimercati, S., Syverson, P.F., Gollmann, D. (eds.) ESORICS 2005. LNCS, vol. 3679, pp. 374–396. Springer, Heidelberg (2005)

68

M. Centenaro et al.

7. Askarov, A., Hedin, D., Sabelfeld, A.: Cryptographically-masked flows. Theoretical Computer Science 402(2-3), 82–101 (2008) 8. Berkman, O., Ostrovsky, O.: The unbearable lightness of PIN cracking. In: Dietrich, S., Dhamija, R. (eds.) FC 2007 and USEC 2007. LNCS, vol. 4886, pp. 224–238. Springer, Heidelberg (2007) 9. Bond, M., Zielinski, P.: Decimalization table attacks for PIN cracking. Technical Report UCAM-CL-TR-560, University of Cambridge, Computer Laboratory (2003) 10. Clulow, J.: The design and analysis of cryptographic APIs for security devices. Master’s thesis, University of Natal, Durban (2003) 11. Courant, J., Ene, C., Lakhnech, Y.: Computationally sound typing for noninterference: The case of deterministic encryption. In: Arvind, V., Prasad, S. (eds.) FSTTCS 2007. LNCS, vol. 4855, pp. 364–375. Springer, Heidelberg (2007) 12. Delaune, S., Kremer, S., Steel, G.: Formal analysis of PKCS#11. In: IEEE Computer Security Foundations Symposium, June 23-25 2008, pp. 331–344 (2008) 13. Focardi, R., Centenaro, M.: Information flow security of multi-threaded distributed programs. In: ACM SIGPLAN PLAS 2008, June 8, 2008, pp. 113–124 (2008) 14. Focardi, R., Centenaro, M., Luccio, F., Steel, G.: Type-based analysis of PIN processing APIs (full version). Technical Report CS-2009-6, Universit` a Ca’ Foscari, Venezia, Italy (2009), http://www.unive.it/nqcontent.cfm?a_id=5144 15. Focardi, R., Luccio, F.L., Steel, G.: Improving pin processing api security. In: Workshop on Analysis of Security APIs, July 10-11 (to appear, 2009) 16. Fournet, C., Rezk, T.: Cryptographically sound implementations for typed information-flow security. In: POPL 2008, pp. 323–335. ACM Press, New York (2008) 17. Gordon, A., Jeffrey, A.: Authenticity by typing for security protocols. Technical Report MSR-2001-49, Microsoft Research (2001) 18. I. Inc. CCA Basic Services Reference and Guide for the IBM 4758 PCI and IBM 4764 PCI-X Cryptographic Coprocessors. Technical report, 2006. Rel. 2.53–3.27 (2006) 19. Keighren, G., Aspinall, A., Steel, G.: Towards a type system for security APIs. In: ARSPA-WITS 2009, York, UK, March 28-29, 2009, pp. 173–192 (2009) 20. Laud, P.: On the computational soundness of cryptographically masked flows. In: POPL 2008, pp. 337–348. ACM Press, New York (2008) 21. Longley, D., Rigby, S.: An automatic search for security flaws in key management schemes. Computers and Security 11(1), 75–89 (1992) 22. Mannan, M., van Oorschot, P.: Reducing threats from flawed security APIs: The banking PIN case. Computers & Security 28(6), 410–420 (2009) 23. Myers, A.C., Sabelfeld, A., Zdancewic, S.: Enforcing robust declassification and qualified robustness. Journal of Computer Security 14(2), 157–196 (2006) 24. Sabelfeld, A., Myers, A.C.: Language-based information-flow security. IEEE Journal on Selected Areas in Communications 21(1), 5–19 (2003) 25. Sabelfeld, A., Sands, D.: Declassification: Dimensions and principles. Journal of Computer Security (to appear) 26. Steel, G.: Formal Analysis of PIN Block Attacks. TCS 367(1-2), 257–270 (2006) 27. Vaughan, J.A., Zdancewic, S.: A cryptographic decentralized label model. In: IEEE Symposium on Security and Privacy, pp. 192–206. IEEE Computer Society, Los Alamitos (2007) 28. Volpano, D., Smith, G., Irvine, C.: A sound type system for secure flow analysis. Journal of Computer Security 4(2/3), 167–187 (1996) 29. Youn, P., Adida, B., Bond, M., Clulow, J., Herzog, J., Lin, A., Rivest, R., Anderson, R.: Robbing the bank with a theorem prover. Technical Report UCAM-CL-TR-644, University of Cambridge (August 2005)

Declassification with Explicit Reference Points Alexander Lux and Heiko Mantel Computer Science, TU Darmstadt, Germany {lux,mantel}@cs.tu-darmstadt.de

Abstract. Noninterference requires that public outputs of a program must be completely independent from secrets. While this ensures that secrets cannot be leaked, it is too restrictive for many applications. For instance, the output of a knowledge-based authentication mechanism needs to reveal whether an input matches the secret password. The research problem is to allow such exceptions without giving up too much. Though a number of solutions has been developed, the problem is not yet satisfactorily solved. In this article, we propose a framework to control what information is declassified. Our contributions include a policy language, a semantic characterization of information flow security, and a sound security type system. The main technical novelty is the explicit treatment of so called reference points, which allows us to offer substantially more flexible control of what is released than in existing approaches.

1

Introduction

Information systems process a wide range of secrets, including national secrets, private data, and electronic goods. Confidentiality requirements may also originate from security mechanisms, e.g., the confidentiality of passwords (for authentication mechanisms), of cryptographic keys (for encryption), of random challenges (for security protocols), or of capabilities (for access controls). Static program analysis can be applied to ensure that secrets cannot be leaked during program execution or, in other words, that the flow of information in a program is secure. The resulting security guarantee is usually captured as a lackof-dependency property, which states that the output to untrusted observers is independent from all data that they are not authorized to obtain. While strict lack-of-dependency properties like noninterference [1] are rather attractive from a theoretical point of view, they become impractical if secrets shall be deliberately released. For instance, an electronic good (initially a secret) should be released to a customer after it has been paid for and an authentication attempt necessarily reveals some information about the stored password. In these cases, it is necessary to relax strict lack of dependency to some extent – but how much? The research community has been actively searching for solutions and proposed a number of approaches in recent years. However, the problem of controlled declassification is not yet satisfactorily solved. Mantel and Sands proposed in [2] to distinguish carefully whether a given approach controls what can be declassified, where declassification can occur, and M. Backes and P. Ning (Eds.): ESORICS 2009, LNCS 5789, pp. 69–85, 2009. c Springer-Verlag Berlin Heidelberg 2009

70

A. Lux and H. Mantel

who can initiate declassification. Based on these dimensions of declassification, a taxonomy of known approaches to control declassification was developed in [3]. In this article, we focus on what information may be declassified. When reviewing existing approaches to controlling the what dimension with similar syntax, we found significant differences on the semantic level. For instance, delimited release [4] uses so called escape hatches to indicate what may be declassified by a program. An escape hatch has the syntax declassify(exp, d ), where exp is an expression and d is a security domain in the given flow policy. Semantically, the escape hatch specifies that the value of exp in the initial state (i.e. before program execution begins) may be revealed to the security domain d . This permission dominates all restrictions that are defined by a given flow relation . That is, if the policy contains an escape hatch declassify(exp, d ) then the initial value of exp may be revealed to d – even if exp incorporates variables from a security domain d such that d d . Delimited non-disclosure [5] indicates that the expression exp may be declassified in the program c by commands of the form declassify (exp) in {c}. Security domains are not explicitly mentioned in declassification commands because implicitly a flow policy with only two domains, public and secret, is assumed. Under this flow policy, declassification always constitutes an exception to the restriction that information must not flow from secret to public. Interestingly, delimited non-disclosure permits declassification of the value exp in any state in which exp is evaluated during the execution of the command c. This local view is different from permitting the declassification of the initial value of exp or of the value of exp in the state before the execution of the command c starts. That is, despite the syntactic similarities between delimited release and delimited non-disclosure, these approaches differ significantly in their semantics. The implicit assumptions of initial and local reference points can also be observed in further approaches, e.g., in [6,7,8] and [9], respectively. In this article, we propose explicit reference points as a concept to support a flexible specification of what secrets may be declassified. A declassification guard dguard(r , exp, d ) specifies the values that may be declassified by an expression exp and by a reference point r . The reference point determines a set of states with the intention that the value of exp in any of these states may be declassified to domain d . Unlike in earlier approaches, our framework allows one to make explicit in which states exp is evaluated. Delimited release and delimited non-disclosure can be simulated by placing reference points at the beginning of a program or at all points where exp is evaluated, respectively. However, our framework goes far beyond providing a uniform view on initial and local reference points. Rather, explicit reference points can be placed at any point in a program, and this is adequately supported by our semantic characterization of security. In Section 2, we elaborate the limitations of leaving reference points implicit and sketch the use of our declassification framework. Our novel technical contributions are presented in Section 3 (policy language), Section 4 (security condition), and Section 5 (security type system and soundness result). We conclude with a presentation of further examples and a comparison to related work.

Declassification with Explicit Reference Points

2

71

From Implicit to Explicit Reference Points

Many approaches to controlling what is declassified implicitly assume that reference points are either always initial or always local (see Section 1). We point out the limitations of this assumption in Section 2.1 and offer a first glance at the explicit treatment of reference points in our framework in Section 2.2. 2.1

Initial versus Local Reference Points

As a running example, we consider a program that calculates the average of 100 salaries. We assume that the individual salaries (which constitute inputs to the program) must be kept secret, but that the resulting average may be published. We capture this requirement by a two-level flow policy forbidding that information flows from a security domain secret to a security domain public (i.e., secret public). The domain assignment associates the program variables sal1 , . . . , sal100 (storing the individual salaries) with the domain secret and the program variable avg (storing the resulting average) with the domain public. The desired control of what is declassified can be expressed with delimited release (see P1 below) as well as with delimited non-disclosure (see P2 below): P1 =

avg := declassify((sal1 + sal2 + ... + sal100 ) / 100, public)

P2 =

declassify((sal1 + sal2 + ... + sal100 ) / 100) in {avg:=(sal1 + sal2 + ... + sal100 ) / 100}

So far, we do not observe any significant differences between the two implicit assumptions of initial versus local reference points. However, differences become apparent if we place the program fragments into a larger context. For instance, P3 =

sal1 := sal1 ; sal2 := sal1 ; . . . ; sal100 := sal1 ; P1

effectively assigns sal1 to avg. Intuitively, this clearly is a breach of security because the policy permits only to declassify the average value of all salaries, but not the value of any individual salary. In this case, delimited release is, indeed, a suitable characterization because P3 violates this security condition. In contrast, delimited non-disclosure is not suitable to detect such an information leak. Each of the following two programs (where Avg = (sal1 + sal2 + ... + sal100 ) / 100) satisfies delimited non-disclosure although P4 as well as P5 intuitively incorporate the same insecurity as P3 : P4 =

sal1 := sal1 ; sal2 := sal1 ; . . . ; sal100 := sal1 ; P2

P5 =

declassify(Avg) in { sal1 := sal1 ; sal2 := sal1 ; . . . ; sal100 := sal1 ; avg:=Avg}

However, this does not mean that delimited release is fully satisfactory. There are programs for which delimited release is too restrictive. Consider, for instance, P6 =

sal1

Computer Security -- ESORICS 2009: 14th European Symposium on Research in Computer Security, Saint-Malo, France, September 21-23, 2009, Proceedings ... Computer Science Security and Cryptology)

Computer Security - ESORICS 2010: 15th European Symposium on Research in Computer Security, Athens, Greece, September 20-22, 2010. Proceedings ... Computer Science Security and Cryptology)

Computer Security - ESORICS 94

Computer Security - ESORICS 92

Advances in Information and Computer Security: 4th International Workshop on Security, IWSEC 2009 Toyama, Japan, October 28-30, 2009 Proceedings ... Computer Science Security and Cryptology)

Computer Security: Art and Science

Computer Security - ESORICS 96, 4 conf

Computer Security and Cryptography

Computer Security and Cryptography

Computer Security - ESORICS 2004, 9 conf

Computer Security - ESORICS 98, 5 conf

Computer Security - ESORICS 2000, 6 conf

Computer Security - ESORICS 2008, 13 conf

Computer Security - ESORICS 2003, 8 conf

Computer Security - ESORICS 2005, 10 conf

Computer Security - ESORICS 2002, 7 conf

Computer Security - ESORICS 2007, 12 conf

Computer Security - ESORICS 2006, 11 conf

Coding and Cryptology: Second International Workshop, IWCC 2009 (Lecture Notes in Computer Science Security and Cryptology)

Computer security handbook

Computer Security Handbook

Computer Security Fundamentals

Essential Computer Security

Computer Security Fundamentals

Computer Security Basics

Foundations of Computer Security

Computer Security Handbook

Computer Safety, Reliability, and Security (Lecture Notes in Computer Science)

Fundamentals of Computer Security

Metasploit Toolkit [computer security

Statistical Methods in Computer Security

Computer Security -- ESORICS 2009: 14th European Symposium on Research in Computer Security, Saint-Malo, France, September 21-23, 2009, Proceedings ... Computer Science Security and Cryptology)

Computer Security - ESORICS 2010: 15th European Symposium on Research in Computer Security, Athens, Greece, September 20-22, 2010. Proceedings ... Computer Science Security and Cryptology)

Computer Security - ESORICS 94

Computer Security - ESORICS 92

Advances in Information and Computer Security: 4th International Workshop on Security, IWSEC 2009 Toyama, Japan, October 28-30, 2009 Proceedings ... Computer Science Security and Cryptology)

Computer Security: Art and Science

Computer Security - ESORICS 96, 4 conf

Computer Security and Cryptography

Computer Security and Cryptography

Computer Security - ESORICS 2004, 9 conf

Computer Security - ESORICS 98, 5 conf

Computer Security - ESORICS 2000, 6 conf

Computer Security - ESORICS 2008, 13 conf

Computer Security - ESORICS 2003, 8 conf

Computer Security - ESORICS 2005, 10 conf

Computer Security - ESORICS 2002, 7 conf

Computer Security - ESORICS 2007, 12 conf

Computer Security - ESORICS 2006, 11 conf

Coding and Cryptology: Second International Workshop, IWCC 2009 (Lecture Notes in Computer Science Security and Cryptology)

Computer security handbook

Computer Security Handbook

Computer Security Fundamentals

Essential Computer Security

Computer Security Fundamentals

Computer Security Basics

Foundations of Computer Security

Computer Security Handbook

Computer Safety, Reliability, and Security (Lecture Notes in Computer Science)

Fundamentals of Computer Security

Metasploit Toolkit [computer security

Statistical Methods in Computer Security

Recommend Documents