IDtrust 2008 7th Symposium on Identity and Trust on the Internet Program and Proceedings Notes Transportation There will be a shuttle leaving the Gaithersburg Holiday Inn at 8:00 a.m. Tuesday morning to travel to NIST. The shuttle will leave at 8:15 a.m. Wednesday and Thursday. The shuttle will return to the hotel at the end of the sessions on Tuesday and Wednesday. There will not be shuttle service the afternoon of Thursday. Wireless 802.11b Wireless access points will be available for SSH, IPSEC, HTTP, DNS, FTP, POP, IMAP, and SMTP connectivity. Only WPA1 access will be provided, and users must sign NIST's Visitor Network Access Agreement with regard to security patches, anti-virus software, etc. NIST's Visitor Network Access Agreements are available in the registration area. Blogging Participants and observers are encouraged to use the tag "idtrust2008" when blogging about the symposium. Tuesday, March 4, 2008 - Full Day 8:00 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00 - 9:10 Welcome and Opening Remarks Program Chair: Kent Seamons, Brigham Young University (Slides: ppt ) 9:10 - 10:00 Keynote Talk I Identity Interoperability, Standards, and the State of Adoption (Presentation slides: ppt ) Dan Blum, Sr. VP and Principal Analyst, Burton Group 10:00 - 10:30 Break 10:30 - 12:00 Session 1 - Technical papers - Identity Management Session Chair: Carl Ellison, Microsoft A Client-Side CardSpace-Liberty Integration Architecture (Presentation slides: ppt ) Waleed Alrodhan, University of London Chris Mitchell, University of London Identity Protection Factor (IPF) (Presentation slides: pdf odp ) Arshad Noor, StrongAuth OpenID Identity Discovery with XRI and XRDS (Presentation slides: ppt ) Drummond Reed, Cordance Les Chasen, NeuStar William Tan, Neustar 12:00 - 12:15 Break 12:15 - 1:00 Keynote Talk II Identity and Policy for Security, Trust and Privacy (Presentation slides: pdf ) Rakesh Radhakrishnan, Chief Identity Integration Architect, Sun Microsystems, Inc. 1:00 - 2:00 Lunch 2:00 - 3:30 Session 2 - Panel: Open Reputation Management Systems Panel Moderator: Abbie Babir, Nortel (Slides: pdf ppt ) Drummond Reed, Cordance Corporation (Slides: ppt ) Tony Nadalin, IBM Chris Hagenbuch, SafeTSpace (Slides: ppt ) Rakesh Radhakrishnan, Sun Microsystems (Slides: pdf ) 3:30 - 4:00 Break 4:00 - 5:30 Session 3 - Technical papers - Access Control in Open Systems Session Chair: Carl Ellison, Microsoft A Content-Driven Access Control System (Presentation slides: pdf ppt ) Jessica Staddon, PARC Philippe Golle, PARC Paul Rasmussen, PARC Martin Gagne, U.C. Davis Secure Roaming with Identity Metasystems (Presentation slides: ppt pdf ) Long Nguyen Hoang, Helsinki University of Technology Pekka Laitinen, Nokia Research Center N. Asokan, Nokia Research Center Secure Communication for Ad-Hoc, Federated Groups (Presentation slides: pdf ppt ) Ludwig Seitz, Swedish Institute of Computer Science Andreas Sjöholm, Axiomatics and Swedish Institute of Computer Science Babak Sadighi, Axiomatics and Swedish Institute of Computer Science 5:30 Bus Departs for Gaithersburg Holiday Inn 6:00 Social Gathering and Dinner Buffet - Gaithersburg Holiday Inn Wednesday, March 5, 2008 - Full Day 8:15 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00 - 9:15 Welcoming Remarks OASIS and the IDtrust Member Section: John Sabo, CA, Inc. (Slides: ppt ) 9:15-9:45 Session 4 - Technical papers - Public Key Infrastructure I Session Chair: Bill Burr, NIST User-Centric PKI (Presentation slides: pdf ppt ) Radia Perlman, Sun Microsystems Charlie Kaufman, Microsoft 9:45 - 10:00 Break 10:00 - 11:00 Session 5 - Panel - Federations Today and Tomorrow Ken Klingenstein, Internet2 (Slides: ppt ) Patrick Harding, Ping Identity (Slides: pdf ) 11:00 - 11:30 Break 11:30 - 1:00 Session 6: Panel: Liberty Alliance Identity Assurance Framework: Advancing Common Levels of Trust, Certification, Accreditation and Business Rules Panel Moderator: Peter Alterman, National Institutes of Health (Slides: ppt ) Douglas Pelton, Wells Fargo (Slides: ppt ) Lena Kannappan, FuGen Solutions, Inc. (Slides: pdf ) Jan Riis, Lakeside A/S (Slides: ppt ) 1:00 - 2:00 Lunch 2:00 - 3:30 Session 7: Technical Papers - Public Key Infrastructure II Session Chair: Andrew Regenscheid, NIST Public Key Superstructure "It's PKI Jim, But Not As We Know It!" (Presentation slides: ppt ) Stephen Wilson, Lockstep Consulting Audit and Backup Procedures for Hardware Security Modules (Presentation slides: odp ) Túlio Cícero Salvaro de Souza, UFSC Jean Everson Martina, University of Cambridge Ricardo Felipe Custódio, UFSC Securing the core with an Enterprise Key Management Infrastructure (EKMI) (Presentation slides: pdf odp ) Arshad Noor, StrongAuth 3:30 - 4:00 Break 4:00 - 5:00 Session 8: Technical Papers - Practice & Experience: Health Care Session Chair: Scott Rea, Dartmouth College A Federation of Web Services for Danish Health Care (Presentation slides: ppt ) Esben Dalsgaard, Digital Health Denmark (SDSD) Kåre Kjelstrøm, Silverbullet A/S Jan Riis, Lakeside A/S Security and Privacy System Architecture for an e-Hospital Environment (Presentation slides: pdf ppt ) Kathryn Garson, University of Ottawa Carlisle Adams, University of Ottawa 5:00 - 5:30 Session 9: RUMP Session Session Chair: Neal McBurnett, Internet2 Impromptu Rump Session. Sign-ups will be taken prior to the session by Neal McBurnett. Privacy View of Systems Engineering (Presentation slides: ppt ) David Weitzel, Mitre Safeguarding Digital Identity (Presentation slides: ppt ) Bruce Bakis, Mitre Update on XML Signature, XML Security (Presentation slides: ppt pdf ) Frederick Hirsch, Nokia Wireless Access using an Identity Provider (Presentation slides: ppt ) Kent Seamons, Brigham Young University Vehicle Infrastructure Integration (VII): Trusting Your Car to Be Anonymous James L. Fisher, Noblis 5:30 Bus Departs for Gaithersburg Holiday Inn Dinner (on your own) 8:00 Birds-of-a-Feather Sessions Gaithersburg Holiday Inn, Washingtonian Room Thursday March 6, 2008 - Half Day 8:15 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00-11:00 Session 10 - Identity and Access Control in the Enterprise using OASIS Security Standards Panel Moderator: Hal Lockhart, BEA Systems, Chair, Oasis Technical Committees (SAML, XACML) (Slides: ppt ) Anil Saldhana, Red Hat, Member, Oasis Technical Committees (SAML, XACML) (Slides: ppt ) Anthony Nadalin, IBM, Member, Oasis Technical Committees (SAML, XACML) (Slides: ppt ) Andreas Sjöholm, Axiomatics, Oasis Technical Committee (XACML) (Slides: ppt ) Sunil Madhu, Securent (Cisco), Oasis Technical Committee (XACML) (Slides: ppt ) 11:00 - 11:30 Break 11:30 - 12:00 Session 11 - Invited Talk OpenID: Current Status and Challenges (Presentation slides: ppt pdf ) George Fletcher, Chief Architect, Identity Services, AOL 12:00-12:30 Wrap up See Also This workshop is part of the IDtrust Symposium Series •2010: 9th Symposium on Identity and Trust on the Internet (IDtrust 2010) •2009: 8th Symposium on Identity and Trust on the Internet (IDtrust 2009) •2008: 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) •2007: 6th Annual PKI R&D Workshop •2006: 5th Annual PKI R&D Workshop •2005: 4th Annual PKI R&D Workshop •2004: 3rd Annual PKI R&D Workshop •2003: 2nd Annual PKI Research Workshop •2002: 1st Annual PKI Research Workshop 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Identity and Trust Infrastructures Kent Seamons Brigham Young University Program Chair Sponsors • 7th Symposium on Identity and Trust on the Internet (IDtrust) (Previously the PKI R&D Workshop) • Our new name reflects the expanding scope and interests of this community • Researchers and practitioners from industry, government, and academia March 4-6, 2008 IDtrust 2008 Sponsors • National Institute of Standards and Technology (NIST) • Internet2 • OASIS IDtrust Member Section • Federal PKI Policy Authority March 4-6, 2008 IDtrust 2008 Program Committee • Kent Seamons, Brigham Young University • Arshad Noor, StrongAuth (chair) • Eric Norman, University of Wisconsin • Peter Alterman, National Institutes of • Tim Polk, NIST Health • Scott Rea, Dartmouth College • Abbie Barbir, Nortel • Andrew Regenscheid, NIST • Jim Basney, NCSA • John Sabo, Computer Associates • David Chadwick, University of Kent • Ravi Sandhu, Univ. of Texas at San Antonio • Joe Cohen, Forum Systems and TriCipher • Carl Ellison, Microsof • Krishna Sankar, Cisco Systems • Stephen Farrell, Trinity College Dublin • Stefan Santesson, Microsof • Richard Guida, Johnson & Johnson • Frank Siebenlist, Argonne National • Peter Gutmann, University of Auckland Laboratory • Russ Housley, Vigil Security, LLC • Sean Smith, Dartmouth College Thank You! • Himanshu Khurana, NCSA • Ann Terwilliger, Visa International • June Leung, FundSERV • Von Welch, NCSA • Neal McBurnett, Internet2 • Stephen Whitlock, Boeing • Bob Morgan, University of Washington • Michael Wiener, Cryptographic Clarity • Clifford Neuman, University of Southern California March 4-6, 2008 IDtrust 2008 Special Thanks • Steering Committee Chair Neal McBurnett, Internet2 • Local Arrangements Chair Sara Caswell, NIST • Dee Schur, OASIS • General Chair Ken Klingenstein, Internet2 March 4-6, 2008 IDtrust 2008 Technical Program • Technical Paper sessions (peer reviewed) – Identity Management – Access Control in Open Systems – PKI – Practice and Experience: Health Care • Submissions up 50% over last year • Each paper received 4 reviews on average • Some papers received shepherding – Thank you authors and PC members • Published in the ACM Digital Library as part of the ACM International Conference Proceedings Series March 4-6, 2008 IDtrust 2008 Technical Program • Panel Sessions - Reputation Management - Federations Today and Tomorrow - Liberty Alliance Identity Assurance Framework - Identity and Access Control in the Enterprise • Invited Talk – OpenID Status and Challenges – George Fletcher Chief Architect, Identity Services, AOL March 4-6, 2008 IDtrust 2008 Keynote Speakers Dan Blum Rakesh Radhakrishnan Senior VP and Principal Analyst Lead Architect Burton Group Sun Microsystems March 4-6, 2008 IDtrust 2008 RUMP Session • Short Work-In-Progress Talks – Wed afternoon – Submit an abstract – 5 minute presentations (subject to change) – Contact: Neal McBurnett • neal@bcn.boulder.co.us Courtesy: http://www.flaminghotideas.co.uk/library_travel.htm March 4-6, 2008 IDtrust 2008 Last Minute Instructions - Speakers • Speakers please contact your session chairs in advance – At the beginning of the break before your session • An electronic copy of each presentation should be given to Neal for the web site (ppt/odp/pdf) March 4-6, 2008 IDtrust 2008 Social Gathering and Dinner Buffet • Tuesday, Gaithersburg Holiday Inn, 6 PM March 4-6, 2008 IDtrust 2008 Bird-of-a-Feather • Propose a topic for informal Birds-of-a-Feather sessions – Signup to attend a session that interests you • Wednesday, 8 PM Room available at the Holiday Inn March 4-6, 2008 IDtrust 2008 Looking to the Future • Please make plans now to submit a technical paper for next year – Submission deadline will be in the fall (October) • Complete a survey at the conclusion of the workshop – your feedback is important to us! March 4-6, 2008 IDtrust 2008 Enjoy the Workshop • The success of the workshop is in your hands – Participate! – We welcome outrageous comments and questions March 4-6, 2008 IDtrust 2008 Identity Interoperability, Standards, and the State of Adoption Presented for the ID Trust 2008 March 4, 2008 Dan Blum Senior VP, Principal Analyst Security and Risk Management Strategies Burton Group dblum@burtongroup.com All Contents © 2007 Burton Group. All rights reserved. Identity Interoperability 2 Thesis • Identity is key to Internet applications and information security but interoperability remains an issue • PKI, federated identity and user-centric identity are • Three generations of standards • All targeting identity interoperability • Overlapping and related, but catering to different communities • We’re early on the adoption curve, have unsolved issues • Standards cannot yet automate business relationship establishment, trust or authorization • Nonetheless, there are many opportunities for deployment Roadmap for Presentation 3 • Discuss interoperability use cases, and adoption • Evaluate key standards • Conclusion and recommendations Mapping the Use Cases 4 Identity Interoperability Tax Play Use cases Benefits Buy User Business Government Regulatory Work Customer IT and app facing integration Law Employee Value and Enforcement services supply chain Use Cases – Seem like Islands? 5 Identity User- Interoperability Land Tax centric Play Use cases of PKIBenefits Territories Buy User Business Government Regulatory Work Federateintegration Customer facing IT and app Law Employee d Value and Enforcement services supply chain Spaces Federated Spaces 6 What is federated identity? • Agreements, standards, and technologies that make identity and entitlements portable across domains Basic model Agreements, protocols, infrastructure •Configuration data •Configuration data •Certificates •Certificates •SAML protocol •SAML protocol •Credentials Assertion •Authorization system Identity Provider Relying Party HTTP HTTP User-Centric Identity 7 What is user-centric identity? • User brokers or controls identification and authentication process to relying parties Basic model • User must be present (or further A priori agreements may not be necessary issues of broker service addressed) • Client software must be installed • IDP must implement Identity Provider Relying Party a token service • Technical and privacy policies must map from user, IDP, RP User takes some of the responsibility State of the Market 8 Federated identity adoption is expanding • Enterprises with many federation partners, trying to scale • Multi million user deployments underway • Community federations: higher education, telecommunications, automotive, government, pharmaceutical, financial services, petroleum… Many commercial products support SAML 2.0 • Vendors have moved quickly to support converged standard; still some growing pains • Enterprises implementing multiprotocol scenarios Yet divergence continues - between federated and user-centric spaces, and between some of the vendors State of the Market 9 Adoption of federated identity in business growing, but not universal • Deployment barriers • Standards and tools that work for 10s or 100s of partners still to hard to scale when deploying 1000s of partners • Partners not ready, or unwilling • Difficult for small business to deploy • Application service providers don’t focus on identity • Relative high cost for some implementers • Concerns about risk, liability, and audit • Difficult to build business agreements Trust is the elephant in the road Federated Identity Adoption 10 Incentives must outweigh disincentives Incentives Disincentives • Transactional revenue • Technical complexity - • New business opportunities • Deployment cost • Lower admin costs • Trust issues - + + Federated Identity Adoption 11 Where strong affinities exist federations form • Pair-wise federations (many) • Hub and spoke federations (collections of multiple pair-wise) • Communities of interest (some) Employee t ives services i ncen Dis t ives Value and en Inc supply chain + Roadmap for Presentation 12 • Discuss interoperability use cases, and adoption • Evaluate key standards • Conclusion and recommendations Where do the Standards Fit? 13 Identity Service Identity Information Initial focal point Evaluating the Standards 14 Exchange alone can be a complicated problem Standards are complex, with multiple interoperability points • Protocol • Schema • Profiles • Core features • Optional features It’s a fairly significant task to test them • Especially the full functionality for SAML 2.0, Information Cards or PKI Evaluating the Standards 15 Ingredients that impact interoperability confidence level • Maturity of standard • How long has it been available? • Commercial availability • Is it available from several vendors? • Conformance testing • Is there a conformance testing program? • Interoperability testing • Is there formal interoperability testing? • Field experience • How many production deployments exist? • Flexibility • How much can you do with it? Scoring the Standards 16 Developing a score card Commercial Maturity availability Conformance Interoperability testing testing Field Flexibility experience SAML 17 SAML – What its for How it scores • Open standard for browser- (Feb 2008) based federation Commercial Maturity • Integrated in Web services availability security standards and Information Cards Confor- Interop • SAML 2.0 – powerful, mance testing testing complex and coming - replacing SAML 1.x • Use SAML as the baseline Field Flexibility experience standard for business federations XACML 18 XACML – What its for How it scores (Feb 2008) • Express security policies and access rights Maturity Commercial availability • Designed to work with SAML • Use XACML when building Confor- Interop mance entitlements engines testing testing • Use XACML if context is bounded and you want to Field express policies in an experience Flexibility interoperable, automated manner SPML 19 SPML – What its for How it scores (Feb 2008) • Provision accounts among applications, organizations Maturity Commercial in structured, automated availability way • Consider SPML when large Confor- Interop volumes of accounts must mance testing testing be held at multiple federated identity sites Field • And account information is experience Flexibility complex and federations will be stable over time Information Cards 20 Information Cards – What its for How it scores (Feb 2008) • User centric identity specifications Maturity Commercial availability • Leverages WS-Trust security token service (STS), and other WS-* specifications Confor- Interop mance • Implemented in Windows testing testing Vista CardSpace and Higgins Open Source project Field • Consider Information Cards experience Flexibility for user-centric pilots, projects or architectures How Identity Standards Score 21 Summing up standards (Feb 2008) Information SAML XACML SPML Cards Are they delivering the promise of interoperability? SAML XACML SPML Information Yes Not yet Not yet Cards (Extends SAML) (Ahead of its Looks promising time) Other Standards or Specifications 22 OpenID • Popular user-centric system, allows chaotic expansion • No trust model, insecure protocol, no id assurance WS-Federation passive profile • Required for Microsoft environment • Unhelpful, duplicates SAML functionality Liberty Alliance • Morphed into deployment forum, ceded much of its standards work to OASIS • Its most important specifications now part of SAML 2.0 • Identity Assurance Framework & Concordia initiatives promising Authorization 23 Most identity interoperability work emphasizes authentication, and exchanges Authorization is an even more difficult problem • Tied to business context: Environment, risk, liability • Tools cannot establish or maintain business relationships, trust, define roles or initial agreements • Tools useful for yes/no decisions, passing roles or attributes Need up front work to bound the context Then see what can be automated Roadmap for Presentation 24 • Discuss interoperability use cases, and adoption • Evaluate key standards • Conclusion and recommendations Use Cases are not Islands 25 Identity Interoperability Tax Play Use cases Benefits Buy User Business Government Regulatory Work Customer IT and app facing integration Law Employee Value and Enforcement services supply chain Convergence 26 How and when will we see ubiquitous identity interoperability? On the dark side: On the bright side: We don’t really We have standards know yet; too and products for many hard many tactical unsolved opportunities problems • New apps • Business • Improve models convenience • Trust models • Cost savings • Scalability of • Increase deployment assurance Identity System Standards 27 Recommendations • Don’t force fit all projects into a consolidated solution • Tailor deployments for each IT tier (organizational, regional, functional) • Stick to patterns that work – enterprise portal, value chain, industry hub • Pick the right standard(s) for the task • But be prepared for issues that may arise with new standards • Keep the solution as simple as possible • Develop and document implementation procedures • Encourage ‘best practices’ • Makes the process repeatable References 28 Burton Group Identity and Privacy Strategies • Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems • Federation Products 2008 • Picking the Right Federation Product for the Job • Federation's Future in the Balance: Teetering Between Ubiquity and Mediocrity • Information Card Landscape • Comparing SAML, WS-Trust, and OpenID • Business and Legal Issues in Federation • Federated Identity Technical Position • SAML 2.0: Convergence Point for Browser-Based Federation A Client-side CardSpace-Liberty Integration Architecture Waleed A. Alrodhan Chris J. Mitchell Royal Holloway, University of London Royal Holloway, University of London Egham, Surrey, TW20 0EX Egham, Surrey, TW20 0EX United Kingdom United Kingdom W.A.Alrodhan@rhul.ac.uk C.Mitchell@rhul.ac.uk ABSTRACT between the Liberty Alliance Project scheme and the Mi- Over the last few years, many identity management schemes, crosoft CardSpace scheme. frameworks and system specifications have been proposed; The remainder of this paper is organised as follows. Sec- however these various schemes and frameworks are typically tion 2 provides an overview of the Liberty Alliance Project not interoperable. In this paper we propose an approach to and the Microsoft CardSpace identity management system. enable interoperation between two of the most prominent Section 3 presents the proposed integration model. In sec- identity management schemes, namely the Liberty Alliance tion 4 we provide an operational analysis of the proposed Project scheme (specifically the ID-FF LEC Profile) and the integration model, section 5 contains a brief review of re- Microsoft CardSpace (formerly known as InfoCard) scheme. lated work, and section 6 concludes the paper. This integration should enhance interoperability by enabling users to make use of identity management systems even if the 2. THE LIBERTY ALLIANCE PROJECT AND system participants are using different schemes. The main MICROSOFT CARDSPACE advantages and disadvantages of the proposed integration This section provides a brief introduction to the two iden- model are also investigated. tity management architectures for which interoperation is enabled, namely the Liberty Alliance Project scheme and Categories and Subject Descriptors Microsoft CardSpace. K.6.5 [Management of Computing and Information Systems]: Security and protection 2.1 The Liberty Alliance Project and the ID- FF Single Sign-On Profiles General Terms The Liberty Alliance Project (www.projectliberty.org) is an industry collaboration that was started in December 2001 Identity Management by 16 major companies, including Sun, GM, United Airlines, and France Télécom. This collaboration now involves more Keywords than 150 members, including government agencies, compa- CardSpace, Liberty, Federation, Integration nies, banks and universities. According to the project web- site, there are more than 400 million Liberty-enabled iden- 1. INTRODUCTION tities and clients across the world. The Liberty Alliance Project (henceforth abbreviated to It has become common for Internet users to access mul- Liberty) aims to build open standard-based specifications for tiple independent systems in a single working session, and federated identity, provide interoperability testing, and to hence users have a need for multiple digital identities. How- help provide solutions to identity theft. Liberty also aims to ever, managing these digital identities can be a complex and establish best practices and business guidelines for identity difficult job, and to solve this dilemma a number of Iden- federation. tity Federation systems have been proposed and deployed. Figure 1 shows the general Liberty model, which is essen- These systems are typically not interoperable, which makes tially a single sign-on model [2]. In this model, a principal it difficult to use them in open environments such as the (or user) can federate its various identities to a single iden- Internet. tity issued by an identity provider, so that the user can ac- This paper proposes an approach to address this problem. cess services provided by service providers belonging to the Specifically, it proposes a method to enable interoperation same circle of trust by authenticating just once to the iden- tity provider. This, of course, relies on a pre-established trust relationship between the identity provider and every Permission to make digital or hard copies of all or part of this work for service provider in the circle of trust. The model provides personal or classroom use is granted without fee provided that copies are a level of pseudonymity and unlinkability via the use of not made or distributed for profit or commercial advantage and that copies pseudonyms instead of real identifiers in the communications bear this notice and the full citation on the first page. To copy otherwise, to between the identity provider and the service providers, and republish, to post on servers or to redistribute to lists, requires prior specific this enhances user privacy. In the example shown in figure permission and/or a fee. IDtrust ’08, March 4-6, 2008 Gaithersburg, MD. Copyright 2008 ACM 1, the principal has federated its identities within two dis- 1978-1-60558-066-1 ...$5.00. tinct circles of trust, which results in the user having two and proxy (LEC) profile [3]. 2.2 Microsoft CardSpace CardSpace is the name for a Microsoft WinFX software component that is built on the concept of the “identity meta- system”. This identity metasystem is designed to comply with the Laws of Identity, as promulgated by Microsoft [1]. The metasystem provides a way to represent identities us- ing claims, and a means to bridge technology and organi- sational boundaries using claims transformations [7]. The CardSpace identity management architecture is designed to provide the user with control over his digital identities in a user friendly manner, and to tackle identity management Figure 1: The Liberty model. security problems such as breaches of privacy and identity theft, with no single identity authority control. CardSpace works with Internet Explorer browsers (CardSpace plug-ins identities, one for circle of trust A and the other for circle of for browsers other than Microsoft Internet Explorer can also trust B. It merits mentioning that these two identities could be developed, such as the Firefox Plug-in1 ). also be federated, but this would require a pre-established The concept behind CardSpace is relatively simple; it trust relationship between the identity providers. is based on the identification process we experience in the As shown in figure 2, the Liberty implementation spec- real world when using physical identification cards. In the ifications are divided into three frameworks: the Identity CardSpace system, an identity provider issues virtual iden- Federation Framework (ID-FF) [12], the Identity Web Ser- tification cards (named InfoCards) to users, who can later vices Framework (ID-WSF) [11] and the Service Interface use them to identify themselves to any service provider who Specifications (ID-SIS) [5] and [6]. In this paper, we focus trusts this identity provider. It merits mentioning here that on the ID-FF. the InfoCard is stored in the user’s machine and does not contain any security-sensitive information. CardSpace is an identity federation model that essentially facilitates a single sign-on service, although it is not clear from the published Microsoft papers and documents how single sign-on sessions are handled within the metasystem. The CardSpace metasystem makes use of Web Services (WS- *) protocols to achieve its objectives. Note that most of these protocols make use of a Security Token Service [4]. 2.3 Message Flows within the Liberty ID-FF LEC Profile and the CardSpace Frame- work Before describing the proposed integration model, we briefly describe the message flows within both the Liberty ID-FF LEC profile and the CardSpace framework. There are three main roles within both identity management architectures: Figure 2: The Liberty Frameworks. 1. The Identity Provider or Identity Issuer (IdP), which issues the identity to the user; The ID-FF provides approaches for implementing the fed- eration and single sign-on model, and the techniques needed 2. The Service Provider (SP), as referred to in the Liberty for that model, including session management and iden- specifications, or the Relying Party (RP), in Microsoft tity/account linkage. In order to realise this federation model, terminology; the SP or RP needs to identify the user a set of profiles is required (so called ID-FF Liberty pro- before providing services to him/her; files). An ID-FF Liberty profile may best be defined as the 3. The Principal or User. combination of message content specifications and message transport mechanisms for a single client type (that is, user It is important to mention that, in order for a principal to agent) [3]. employ Liberty federation using the LEC profile, the prin- There are many types of ID-FF Liberty profile, includ- cipal must possess a Liberty-Enabled browser in order to ing Single Sign-On and Federation Profiles, Register Name handle and understand the messages sent and received. To Identifier Profiles, Identity Federation Termination Notifica- make the browser Liberty-Enabled, the principal needs to tion Profiles, Single Logout Profiles, Identity Provider Intro- install certain java components on the machine; such com- duction, NameIdentifier Mapping Profile and NameIdentifier ponents can be downloaded freely from the Internet (e.g. the Encryption Profile. In this paper we are primarily concerned SecureID ID-FF 1.1 and ID-FF 1.2 Java Toolkits2 , and the with the Single Sign-On and Federation Profiles. The cur- rently defined Single Sign-On profiles are the Artifact profile, 1 http://xmldap.blogspot.com/2006/05/firefox-identity- the Browser POST profile and the Liberty-enabled client selector.html Sun FederationSPAdapter3 ). Figure 3 shows the message flow within the ID-FF LEC profile, if we assume that the client has already been au- thenticated by the IdP. Note that the Liberty-Enabling component must be installed on the Principal’s PC prior to performing the protocol. The main steps in the protocol are as follows: 1. User Agent → SP : Service Request (HTTP Request with Liberty Enabled Header) 2. SP → User Agent : Authentication Request + “option- ally” an IdP List 3. User Agent or User : Selects the IdP to be used 4. User Agent → IdP : SAML-Assertion Request 5. IdP → User Agent : SAML-Assertion Response Figure 4: The MS-CardSpace profile message flow. 6. User Agent → SP : Authentication Response + SAML- Assertion (within an HTML Form) 7. SP → User Agent : Service Granted! 3. User Agent ↔ RP-STS : User Agent retrieves Policy via WS-SecurityPolicy 4. User Agent ↔ User : User picks an InfoCard 5. User Agent ↔ IdP : User Authentication 6. User Agent ↔ IdP-STS : User Agent retrieves secu- rity token via WS-MetadataExchange and WS-Trust 7. User Agent → RP-STS : User Agent presents the security token via WS-Trust 8. RP → User Agent : Welcome, you are now logged in! Unlike the ID-FF LEC profile, in Step 4 of the CardSpace message flow the user is presented with the InfoCards that can be used to identify himself to that particular RP, and picks one of them. The WS-MetadataExchange and WS- Trust messages in step 6 are transported using SOAP, which is carried via an SSL connection to provide confidentiality (integrity is preserved using an XML signature). If the RP does not have an STS server, the messages in steps 3 and 7 will be carried using HTTP over an SSL/TLS channel. Figure 3: The ID-FF LEC profile message flow. In the remainder of this paper we assume that all SPs and IdPs support at least one of the two identity architectures The SAML messages in steps 4 and 5 are bound to SOAP, (either Liberty or CardSpace, or both). In such a situation, which is carried over an SSL connection to provide confiden- Windows users will face one of the following two scenarios: tiality (integrity is preserved using an XML-Signature). As shown in the figure, how the IdP is selected in step 3 is not • Scenario A: The Identity Provider/Identity Issuer sup- specified in the Liberty specifications. ports both identity management architectures (Liberty Figure 4 shows the message flow within the CardSpace and CardSpace). In this case the IdP perform the diffi- framework. As shown in the figure, there is an additional cult task of maintaining two different identity architec- component here, namely the Security Token Service (hence- tures, thereby providing flexibility to users when they forth abbreviated to STS), which is responsible for the se- federate their identities with the SPs or RPs. Users are curity policy and token management within the IdP (and able to access services provided by Service Providers optionally within the RP). The User Agent here is essen- regardless of which identity management architecture tially an CardSpace enabled browser (also called the Service they adopt. Requestor ). Note that the CardSpace component must be • Scenario B : The Identity Provider/Identity Issuer sup- installed on the Principal’s PC prior to step 3 of the proto- ports only one identity management architecture (ei- col. The main steps in the protocol are as follows: ther Liberty or CardSpace). In this case, users are only able to access Service Providers using the identity 1. User Agent → RP : HTTP GET Login HTML Page management architecture supported by their Identity Request Issuer or IdP. 2. RP → User Agent : HTML Login Page + CardSpace In Scenario B, Windows users have a compatibility prob- Tags (XHTML or HTML object tags) lem if the Relying Party is CardSpace-Enabled while their 2 http://www.sourceid.org IdP is Liberty-Enabled, or vice versa. Table 1 shows the ap- 3 http://docs.sun.com/source/819-4682 plicability of the identity management systems in all of the possible scenarios that might occur; L.E. stands for Liberty or SP. This means that, in the presence of such an adaptor, Enabled, and CS.E. stands for CardSpace Enabled. The we can change the last two entries in the fifth row of table 1 (X) sign indicates that there is no compatibility problem, to (X) instead of (×), which implies that such a user would whereas the (×) sign indicates the opposite. have the ability to make use of an identity system regard- less of the identity management architecture adopted by the RP or the SP. That is, this integration model is designed to Table 1: The applicability of the identity manage- resolve the incompatibility situation that may occur if the ment architectures. IdP is Liberty-enabled and the RP is CardSpace-enabled, or User L.E. IdP CS.E. IdP L.E. IdP CS.E. IdP vice versa. Agent L.E. SP CS.E. RP CS.E. RP L.E. SP Before describing the proposed integration model, we out- Unenhanced × × × × line a major difference between the scope of the Liberty ID- L.E. X × × × FF and the CardSpace framework. The CardSpace frame- CS.E. × X × × work’s main goal is to support the authentication of a user L.E. and CS.E. X X × × by a trusted third party (i.e. an IdP) and the provision of assertions by the trusted third party to the SP that claims regarding attributes of the user are correct. By contrast, in 3. THE INTEGRATION MODEL Liberty, the ID-FF is designed to achieve Identity Federation by asserting to the SP that the user has been successfully There is a noticeable similarity between the message flow authenticated by a trusted third party (i.e. the IdP) using an within the ID-FF LEC profile and the message flow within authentication method, and no claims (i.e. user attributes) the CardSpace framework. This similarity can be exploited are involved in the authentication process. Nevertheless, in order to integrate the two identity management archi- asserting user attributes by a trusted third party can be tectures. This section presents the motivation for this in- achieved using the Liberty protocols; however, this falls un- tegration proposal, and describes the proposed integration der the Liberty ID-WSF, which is a different framework, as model. discussed earlier in this paper. 3.1 Motivation The identity management architecture adaptor proposed here is a piece of software installed on the user’s machine Liberty is currently the leading identity management ar- which understands both the Liberty and CardSpace frame- chitecture for identity federation, and it has gained the ac- works, and their message flows and formats. The adaptor’s ceptance of a number of technology-leading companies and main job is to interpose itself between IdPs and SPs/RPs ad- organisations. By contrast, the CardSpace metasystem cur- hering to different identity management architectures, in or- rently only works on the Windows operating system (this der to translate particular messages generated by one party seems likely to continue, at least in the near future), and is to the other. We consider operational details of the identity deployed freely with Windows Vista, with backwards com- management architecture adaptor later in this section. patibility with Windows XP. Given the wide use of Win- Before presenting the integration model and its message dows, CardSpace is likely to have a significant impact despite flow, we note the following restrictions on its operation: this restriction. Thus, enabling integration between these two systems is likely to be of significant benefit to a wide 1. Given that the Liberty specifications are based only on range of service providers and users. It seems that interop- SAML-Assertion tokens, only SAML-Assertion tokens eration between Liberty and CardSpace can be achieved by are permitted within the integration model, i.e. other integrating the frameworks. security tokens supported by CardSpace (e.g. Kerberos The CardSpace identity management architecture consists v5 tickets) are not permitted. The SAML-Assertion of two parts: tokens will simply be forwarded from the IdP to the 1. The user agent supporting components: i.e. the service SP/RP. requestor and the identity selector. These components 2. For the proof of rightful possession of the security to- are responsible for managing the cards and communi- ken, only asymmetric techniques are permitted. In the cating with other parties in the model. It appears that asymmetric proof technique, the IdP inserts the pub- these components could be integrated with the Liberty lic key of the User Agent in the security token, so that ID-WSF services; however, how this might be achieved the User Agent can use its private key to prove rightful is beyond the scope of this paper. possession of the token to the RP (or SP). There is a 2. The Identity Framework : i.e. the message flow and clear resemblance between the CardSpace asymmetric the rules for communication between the parties. This proof-key technique [8], and SAML holder-of-key con- framework is similar to the Liberty ID-FF LEC pro- firmation method [9]; hence, mapping between these file, in which the user agent is “Liberty-enabled” in the techniques is viable using a relatively simple process. same way as the user agent is “CardSpace-enabled” in 3. For a CardSpace-enabled RP and a Liberty-enabled the CardSpace framework. IdP, the identity management architecture adaptor will discard any token freshness restrictions requests im- 3.2 Integrating the two schemes posed by the RP, since the Liberty-enabled IdP may In the integration model we propose, we introduce an iden- not be capable of understanding them. tity management architecture adaptor that is both Liberty- enabled and CardSpace-enabled. We propose placing this In the CardSpace framework, the claims to be asserted adaptor in the user’s machine. This gives the user the abil- in the RP Security Policy are represented as attributes of ity to use any IdP, and access a service provided by any RP an Attribute Statement, that is contained within SAML- Assertion requests and responses exchanged before the se- CardSpace-enabled. Note that the Liberty-Enabling com- curity token can be retrieved from the IdP. However, in ponent must be active on the Principal’s PC prior to step the Liberty ID-FF, the IdP does not expect any SAML 4 of the protocol, and the CardSpace component must be Attribute Statements in the AuthenticationRequestEnvelope, active on the Principal’s PC prior to step 3 of the protocol. i.e. the SOAP envelope that carries the authentication re- Here, the message flow would be: quests. This presents a problem that must be solved before 1. User Agent → RP : HTTP GET Login HTML Page the Identity Management Architecture Adaptor can convert Request the relevant messages. We propose two possible solutions to this problem. 2. RP → User Agent : HTML Login Page + CardSpace Tags (XHTML or HTML object tags) 1. We could convert the claims in the CardSpace Security 3. User Agent ↔ RP-STS : User Agent retrieves Policy Policy into attributes within a SAML Attribute State- via WS-SecurityPolicy ment in the AuthenticationRequestEnvelope. However, for this to work, we must ensure that the IdP is able to - [The identity management architecture adaptor process such statements in order to assert them in the converts the CardSpace RP Security Policy, re- AuthenticationResponseEnvelope. However, this solu- ceived from the RP, into a Liberty Authentica- tion goes outside the Liberty standards, and would tion Request, and forwards it to the Liberty- potentially require the Liberty-Enabling software com- Enabling component] ponent to be modified. 4. User Agent or User : Selects the IdP to be used 2. Alternatively, we could make the integration model 5. User Agent → IdP : SAML-Assertion Request only accept CardSpace Security Polices with no claims 6. IdP → User Agent : SAML-Assertion Response listed, and hence the RP that issues the polices will only require an assertion that the user has been au- - [The identity management architecture adaptor thenticated by a trusted third party. However, this converts the Liberty Authentication Response, solution will severely impact on the usability of the received from the IdP, into a CardSpace IdP-STS integration model. Retrieved Security Token, and forwards it to the CardSpace component] Figure 5 shows the message flow for the integration model in the case where the IdP is CardSpace-enabled and the SP 7. User Agent → RP-STS : User Agent presents the is Liberty-enabled. Note that the Liberty-Enabling compo- security token via WS-Trust nent must be active on the Principal’s PC prior to perform- 8. RP → User Agent : Welcome, you are now logged in! ing the protocol, and the CardSpace component must be active on the Principal’s PC prior to step 3 of the protocol. Here, the message flow would be: 1. User Agent → SP : Service Request (HTTP Request with Liberty Enabled Header) 2. SP → User Agent : Authentication Request + “option- ally” an IdPs List - [The identity management architecture adaptor converts the Liberty Authentication Request, re- ceived from the SP, into a CardSpace RP Retrieved Security Policy, and forwards it to the CardSpace- enabling component] 3. User Agent ↔ User : User Picks an InfoCard 4. User Agent ↔ IdP : User Authentication 5. User Agent ↔ IdP-STS : User Agent retrieves secu- rity token via WS-MetadataExchange and WS-Trust Figure 5: Message flow within the integration model - [The identity management architecture adaptor (a). converts the CardSpace Retrieved Security To- ken, received from the IdP-STS, into a Liberty As described above, the identity management architecture Authentication Response, and forwards it to the adaptor interposes itself between the IdP and the SP/RP Liberty-enabling component] in order to translate messages at certain stages of the pro- tocol run. The identity management architecture adaptor 6. User Agent → SP : Authentication Response + SAML- must be able to make four types of message conversion, in- Assertion (within the HTML Form) cluding two token forwarding operations. Figure 7 shows 7. SP → User Agent : Service Granted! the message types that need to be converted by the identity management architecture adaptor, along with the respective message formats. Figure 6 shows the message flow for the integration model Thus, the identity management architecture adaptor soft- in the case where the IdP is Liberty-enabled and the RP is ware must perform two types of task: 4. AN ANALYSIS OF THE INTEGRATION MODEL The integration model takes advantage of the similarity between the ID-FF LEC profile and the CardSpace frame- work, and this should help to reduce the effort required for full system integration. Moreover, the proposed integration model is designed to be implemented without the need for technical cooperation between Microsoft and Liberty. Implementing such a model might be non-trivial task, but the benefits could be significant. If interoperability between leading identity management systems is not supported, then this could be a major obstacle to the global adoption of such schemes. The proposed model is designed to integrate two frame- works with somewhat different scopes. This difference in scope has given rise to the most serious obstacle facing this integration model, namely the dilemma of translating the CardSpace Security Policy claims. Neither of the two so- lutions proposed in this paper are ideal, since they either Figure 6: Message flow within the integration model involve reducing the applicability of the scheme, or making (b). modifications to the core of the Liberty-Enabling software component. One potential limitation of the proposed model is that the • Convert the formats of four types of message. user agent must be both CardSpace-enabled and Liberty- enabled. However, Windows Vista user agents (i.e. browsers) • Forward the converted messages to either liberty en- will, by default, be CardSpace-enabled, and to make the abling or CardSpace software components. browsers Liberty-enabled will simply require the installation of certain java scripts on user machines; as a result this does For the first task, implementing the required message con- not seem to be a major issue. Another possible limitation versions should not be difficult, since all the messages for- of the proposed model is the added restrictions on the token mats are open and published (XML definitions). However, type, encryption and freshness requests; these restrictions the second task is not so straightforward, since it requires will prevent the users from utilising certain features offered a well-defined set of APIs in order for the identity manage- by CardSpace. However, these restrictions only affect the ment architecture adaptor software to communicate with the CardSpace framework because, from the Liberty perspec- Liberty-Enabling and CardSpace components. The precise tive, token handling will remain the same [10]. details of the operation of the adaptor will therefore depend A further possible limitation is the necessity for interac- on how these components are implemented. Indeed, it is tions between the adaptor and the CardSpace metasystem; possible that the adaptor could be integrated into the re- because of the closed nature of CardSpace, this might not be spective components. straightforward, unless a well-defined set of APIs is publicly available. Finally, use of the proposed integration model will result in a delay at the user system while the identity man- agement architecture adaptor performs the necessary con- versions; however, any such delay is likely to be very small. 5. RELATED WORK Recently, the Bandit4 project has developed an open source integration system between Liberty and CardSpace (a demo is available at the project’s web site). Although the source code is provided, it seems that there is no published specifi- cation of the integration system, which makes it difficult to discover exactly how the Bandit scheme works. One obvious difference between the integration scheme we propose in this paper and the Bandit integration scheme re- lates to the location of the integration adapter. Unlike the scheme discussed above, in Bandit the integration adapter is placed on the RP (or SP), not on the user machine. We believe that placing the integration adapter on the user ma- chine increases the usability of the scheme. It is much sim- pler for a user to deploy an integration scheme, and it seems Figure 7: Message format conversions. likely that many well-known service providers will only sup- 4 http://www.bandit-project.org port a single identity management system for operational and commercial reasons. 6. CONCLUSIONS In this paper we have proposed a model enabling integra- tion of Liberty and CardSpace. This integration model takes advantage of the similarity in the message flows between the Liberty ID-FF LEC framework and the CardSpace frame- work. The proposed integration model is based on a client- side identity management architecture adaptor that converts the format of messages within the message flows of the two schemes. We have also presented an analysis of the main limitations and benefits of our proposed integration model. The model is designed to integrate two frameworks with somewhat different scopes, and this has caused certain tech- nical problems, in particular in translating the CardSpace claims. In this paper we have suggested possible solutions for such problems. We believe that enabling interoperation between the two most prominent identity federation architectures could be of major benefit to both the users and producers of these systems. 7. REFERENCES [1] K. Cameron. The laws of identity, May 2005. Microsoft Corporation. [2] K. Cameron and M. B. Jones. Design rationale behind the identity metasystem architecture, February 2006. Microsoft Corporation. [3] S. Cantor, J. Kemp, and D. Champagne (editors). Liberty ID-FF bindings and profiles specification — 1.2-errata-v2.0, 2004. Liberty Alliance Project. [4] M. B. Jones. A guide to supporting InfoCard v1.0 within web applications and browsers, March 2006. Microsoft Corporation. [5] S. Kellomai (editor). Liberty ID-SIS employee profile service specification — version: 1.0, 2003. Liberty Alliance Project. [6] S. Kellomai (editor). Liberty ID-SIS personal profile service specification — version: 1.0, 2003. Liberty Alliance Project. [7] Microsoft Corporation. A technical reference for InfoCard v1.0 in windows, August 2005. [8] Microsoft Corporation and Ping Identity Corporation. A guide to integrating with InfoCard v1.0, August 2005. [9] R. Monzillo, C. Kaler, A. Nadalin, and P. Hallem-Baker (editors). Web Services Security: SAML Token Profile 1.1, February 2006. OASIS Standard Specification, OASIS Open. [10] P. Thompson and D. Champagne (editors). Liberty ID-FF implementation guidelines — version 1.2, 2004. Liberty Alliance Project. [11] J. Tourzan and Y. Koga (editors). Liberty ID-WSF web services framework overview — version: 1.1. Liberty Alliance Project. [12] T. Wason (editor). Liberty ID-FF architecture overview — version: 1.2. Liberty Alliance Project. Waleed A. Alrodhan Royal Holloway, University of London Information Security Group  Introduction  Liberty Alliance Project (ID-FF LEC profile)  Microsoft CardSpace  Integrating the two schemes  Analysis 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Ithas become common for Internet users to access multiple independent systems in a single working session.  Hence, users need multiple digital identities.  There are many solutions. (e.g. Federation, User Centric, CardSpace, etc.)  Interoperability? 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Introduction - An industry collaboration, started in December 2001. - Liberty aims to build open standard-based specifications for federated identity, provide interoperability testing, and to help provide solutions to identity theft. - There are more than 40 million liberty-enabled identities and clients across the world (LAP, 2005). 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The Basic Federation Model SP1 Federation IdP SP2 Circle of trust A 1 SP3 Chris SP4 the researcher SP5 Federation Chris IdP SP6 ”Principal“ Circle of trust B 2 Chris SP7 the musician SP8 IdP: Identity Provider SP: Service Provider 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The Specifications The charts in this slide are taken from the Liberty Alliance Project website 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The ID-FF Liberty Profiles - “The combination of message content specification and message transport mechanisms for a single client type (that is, user agent) is termed a Liberty profile.” (Liberty Alliance Project - Liberty ID-FF Bindings and Profiles Specification) - There are many Profiles: - Single Sign-On and Federation Profiles, Register Name Identifier Profiles, Identity Federation Termination Notification Profiles, Single Logout Profiles, Identity Provider Introduction, NameIdentifier Mapping Profile, NameIdentifier Encryption Profile - There are three Single Sign-On and Federation Profiles: 1. Artifact profile 2. Browser POST profile 3. Liberty-enabled client and proxy profile 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Liberty-Enabled Client and Proxy Profile It is assumed that the client has already been Authenticated by the IdP User Agent → SP: Service Request .1 IdP )HTTP Request with Liberty Enabled Header( : SP → User Agent. 2 +Authentication Request PS 4 optionally” an IdPs List“ TT :User Agent OR User. 3 P/H Obtaining IdP OA 5 1 :User Agent → IdP. 4 L/S SAML-Assertion Request SAM :IdP → User Agent. 5 2 6 SP SAML-Assertion Response :User Agent → SP. 6 3 +Authentication Response SAML-Assertion (within the HTML Form) )Redirect, HTTP (HTML Form) POST( User Agent :SP → User Agent. 7 Principal Liberty-Enabled) 7 !Service Granted (User) (Web Browser 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Introduction - WinFX software component that is built on the concept of the “identity metasystem”. - Designed to provide the user control over his digital identities in a user friendly manner, and to tackle problems such as privacy breaching and identity theft, with no single or central identity authority control. 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Introduction II - Currently deployed with Windows Vista. (works with multiple browsers) - The identity is defined as a set of claims, where the claim is an assertion of the truth of something. - Based on the identification process we experience in the real world when using physical identification cards. - Laws of Identity. 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  InfoCard Example ds:KeyInfowsid:Identitywsa:EndpointReferenceUserNamePasswordAuthenticate< xmlns:wsp=”http://schemas.xmlsoap.org/ws/2002/12/policy” >Username>Waleed >UserNamePasswordAuthenticate >TokenService1234abcd >TokenServiceReference >ic:InfoCardPolicy< Royal Holloway Student Card >SupportedTokenTypes< ... ”/>TokenType URI=”urn:oasis:names:tc:SAML:1.0:assertion< Royal Holloway >SupportedTokenTypes2008-03-04 T00:30:05Z >SupportedClaims< ”>SupportedClaim URI=”http://.../ws/2005/05/identity/claims/givenname< >DisplayTag>First Name >SupportedClaim ”>SupportedClaim URI=”http://.../ws/2005/05/identity/claims/surname< http://www.rhul.ac.uk/sts >DisplayTag>Last Name >SupportedClaimSupportedClaims />RequireAppliesTo< >ic:InfoCardPolicy... >InfoCard 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The Message Flow 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The Basic Model User Agent → RP: HTTP GET .1 Login HTML Page Request : RP → User Agent. 2 HTML Login Page + CardSpace Tags STS ) XHTML or HTML object tags( IdP 3. User Agent↔ RP-STS: User Agent retrieves Policy via WS-SecurityPolicy SOAP/HTTPS 1 4. User Agent ↔ User: 6 5 User Picks an InfoCard 5. User Agent ↔ IdP: RP User Authentication 6. User Agent ↔ IdP-STS: User Agents retrieves security token 2 Via WS-MetadataExchange and 4 3 STS WS-Trust :User Agent → RP-STS. 7 7 User Agent presents the security token via WS-Trust 8 User Agent :RP → User Agent. 8 User )CardSpace Enabled Browser( !Welcome, your are now logged in 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Why? L.E. IdP CS.E. IdP L.E. IdP CS.E. IdP L.E. SP CS.E. RP CS.E. RP L.E. SP Ordinary User Agent     L.E. User Agent     CS.E.User Agent     This can This can L.E. & CS.E.User Agent    !be changed !be changed  7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  How? • CardSpace architecture consists of two parts: 1. The user agent supporting components. (ID-WSF?) 2. The identity framework. (ID-FF LEC) • Different scopes? 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  The Identity management architecture adaptor • A piece of software installed on the user’s machine which understands both the Liberty and CardSpace frameworks, and their message flows and formats. • The main job is to interpose itself between IdPs and SPs adhering to different identity management architectures, in order to translate particular messages generated by one party to the other.  Assumptions • IdP-IdP integration is out of scope. • In case of L.E. IdP & CS.E. RP, we assume that there is a pre- established trust relationship. (Pseudonyms, CardSpace Ref./InfoCard ID) 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Restrictions • Only SAML tokens. • No end-to-end encryption. (secure channels) • Only Asymmetric proof of rightful possession. (holder-of-key) • In case of CS.E. RP & L.E. IdP, token freshness requests are discarded. 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  How to represent the claims? • SAML Attribute Statement. (Requires some modifications to the Liberty enabling component) • Authentication with no claims. (severely impact on the usability of the integration) 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Liberty Enabling Identity CardSpace Enabling Component Management Component Architecture Adaptor Authentication RP Retrieved Request within Security Policy )SOAP Envelope IdP-STS Authentication Retrieved Response Security Token within ,WS-Trust( 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  First Scenario More details of message flow can be found in the paper. STS IdP S /HTTP /SOAP CardSpace-Enabled 5 SAML 4 1 2 SP 3 6 Liberty-Enabled User Agent Liberty-Enabled and) CardSpace-Enabled 7 Principal (User) Web Browser + an IdM (architecture adaptor 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Second scenario More details of message flow can be found in the paper. IdP Liberty-Enabled CardSpace-Enabled S 1 TTP 6 P/ H SOA RP 2 4 3 STS 7 User Agent 8 Liberty-Enabled and( User CardSpace-Enabled Web Browser + an IdM architecture adaptor( 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Analysis - The proposed integration model is designed to be implemented without the need for technical cooperation between Microsoft and Liberty, however, Implementing such a model is non-trivial task. - CardSpace and the Liberty ID-FF are designed to somewhat different scopes. - User-agents still need to be CardSpace and Liberty enabled. - There is no end-to-end encryption. 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)  Analysis II - There are restrictions on the token type, encryption and freshness requests. - Interaction with CardSpace enabling component. (APIs) - Delay? - Bandit project. 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Identity Protection Factor (IPF) Arshad Noor StrongAuth, Inc. 550 Lakeside Drive, Suite 10 Sunnyvale CA 94085 arshad.noor@strongauth.com ABSTRACT Keywords Since the dawn of computing, operating systems and appli- Access Control cations have used many schemes to identify and authenti- Asymmetric key cate entities accessing resources within computers. While Authentication the technologies and schemes have varied, there appears to Identification & Authentication have been little attempt to classify them based on their abil- Identity Protection Factor (IPF) ity to resist attacks from unauthorized entities. Identity Management Shared-secret With the proliferation of identity management technologies Symmetric key in the market today, it is becoming increasingly difficult to assess and compare them with each other. As the threat 1. INTRODUCTION level continues to rise on the internet, and regulations gov- erning information technology continue to grow, risk man- User ID/Passwords, One-Time Password (OTP) tokens, agers need more objective mechanisms to assign risk to biometrics, smartcards, Network Information Services their systems so they may apply appropriate mitigating con- (NIS) aka Yellow Pages, Kerberos, Secure Socket Layer trols. (SSL), Lightweight Directory Access Protocol (LDAP), Se- curity Assertion Markup Language (SAML), OpenID, This paper attempts to describe a classification scheme that CardSpace - these are just a small sample of the dizzying will permit the comparison of seemingly different identifi- array of identification and authentication (I&A) technolo- cation and authentication (I&A) technologies on the basis gies the computer industry has created to address varying of their vulnerability to attacks. With a better understand- business and security requirements in the Identity Manage- ing of related authentication technologies, companies can ment (IdM) space. determine the appropriate technology to use for mitigating authentication risks. However, except for the rather simplistic “what-you-know, what-you-have and what-you-are” method of classification, Categories and Subject Descriptors there has been little attempt to create a formal classification scheme for I&A technologies on the basis of their resis- D.4.6 [Operating Systems]: Security and protection – au- tance to attack. While most technologists have an intuitive thentication. understanding of the relative merits of each I&A technolo- gy, and security practitioners are more than likely to have a General Terms deeper understanding of it, the lack of a formal classifica- tion method is indicative of the immaturity of the profes- Management, Security, Standardization. sion. This paper attempts to introduce such a classification scheme. It is intended to be a first step within a process Permission to make digital or hard copies of all or part of this work for that will, hopefully, lead to more research and consequent- personal or classroom use is granted without fee provided that copies are ly, a validation of this scheme or the creation of a better not made or distributed for profit or commercial advantage and that copies one. Besides bringing clarity to this segment of security bear this notice and the full citation on the first page. To copy otherwise, management, the benefits of such a classification will lead to republish, to post on servers or to redistribute to lists, requires prior spe- cific permission and/or a fee. to better risk-management of systems. IDtrust '08, March 4-6, 2008 Gaithersburg, MD 1.1 Organization of Paper Copyright 2008 ACM 1978-1-60558-066-1…$5.00 This paper begins by describing some of the problems in 20th century, the use of the User ID/Passwords as the basis the area of authentication technologies in Section 2. In of authentication in restricting access to computerized re- Section 3, an overview of the IPF Scale and the technolo- sources, was a very reasonable control mechanism. Given gies that make up the scale is provided. It also explains the controlled physical access to computing devices and the why this particular model makes sense. In Section 4, the closed architectures of computers of the time, it was fairly characteristics, strengths and vulnerabilities of each level of difficult for attackers to compromise computing resources. the IPF Scale are presented. Section 5 compares this con- cept with some well-known frameworks and papers on the With the explosive growth of the personal computer and subject. Section 6 identifies where more research needs to Local Area Network (LAN) based computing since the late be conducted in this area and the paper finally concludes in eighties, and of the internet and the World Wide Web since Section 7. the mid-nineties, computing resources are now available at even the remotest corners of the planet. Simultaneously, in 1.2 Some Definitions an attempt to take advantage of the internet and the WWW, companies are racing to transform their business practices - Before delving into the problems of authentication tech- and as a consequence, their computing infrastructure - to nologies, it is useful to establish this paper's definition of deliver personal and business services to their customers identification and authentication, so that the proper context over the internet. is established for discussion. As a result, not only are hitherto closed computing systems Within the context of computerized information systems, opening up to the internet, but an unprecedented number of Access Control – the discipline of restricting access to users are now connecting to these computing systems computer resources – is defined to consist of three distinct through web-portals from all parts of the globe. processes[1]: Even though there have been many advances in the field of i. Identification – where a resource claims (or is identi- Identification & Authentication (I&A) technology in the in- fied through other means) a specific and unique identifi- tervening period, most companies - including banks and er. Depending on the resource making the claim, the other firms providing financial services - web-enabling identifier may be a User ID, a Distinguished Name of a their service delivery have chosen to rely on the ubiquitous digital certificate, a Fully-qualified Domain Name, an User ID/Password as the means of identifying and authenti- Internet Protocol address, etc. NIST Special Publica- cating users. tion 800-63[2] refers to this resource as “Claimant”, which this paper will use from time-to-time. This has resulted in a multitude of problems: ii. Authentication – where the claimed identifier is veri- fied by the access control mechanism, through some i. Consumers of services are forced to register with a mul- means. Depending on the resource, the verification pro- titude of web-sites and acquire new User IDs and Pass- cess may consist of using technologies such as Pass- words to avail these services. As a result, the average words, Digital Signatures, Reverse DNS lookups, etc. consumer now has more than a dozen credentials, if not A successful verification deems the resource to be “au- more. Most users tend to reuse passwords for multiple thenticated”. credentials, thereby increasing the risk to more valuable iii. Authorization – where the privileges associated with accounts; an authenticated identity are determined. This is the fi- ii. In order to achieve the quickest and widest adoption of nal step of determining whether the claimant may be their web-enabled service, businesses use the path of granted access to another restricted resource. least resistance and require users to only choose a User ID and Password to register for availing the service. Similar definitions of Identification and Authentication are While this has the desired effect in the short-term, the presented by the authors of “Who goes there?: Authentica- long-term problems are just now starting to surface as tion Through the Lens of Privacy”[3]. businesses grapple with the problems of identity-theft; iii. Knowledgeable , but unethical, computer professionals When discussing identity protection, this paper restricts it- have recognized opportunities to gain financially by self only to the Authentication process part of Access Con- stealing User ID/Passwords and taking advantage of the trol. products and services available over the internet in the name of legitimate users; 2. PROBLEMS IN AUTHENTICATION iv. The number and types of attacks that attempt to com- promise end-user computers and their accounts have With the introduction of time-shared computers in large grown tremendously over the last ten years – phishing, corporations and government sectors in the latter part of the pharming, key-stroke loggers, root-kits, cross-site scripting (XSS), SQL injection – these are just a small Note: One assumption this paper makes is that the risk of sample of the types of attacks that have surfaced since compromise to an I&A technology is based on the client- the advent of the WWW; server architecture using a network for the transport of credentials. This is the typical scenario for the vast major- The availability of more sophisticated authentication mech- ity of systems in use today. However, the IPF can also be anisms have not made a huge difference towards managing used to rate I&A technologies where no network is used for risk in most companies. In an attempt to cut costs and to authentication. Examples of the latter are computer oper- ease the process of registration, businesses have avoided ating systems authenticating users against a local database using the more resilient authentication mechanisms in favor of credentials, or an application authenticating users local- of the User ID/Password. ly against its own credential database. To make matters worse, in an attempt to simplify the pro- A second assumption this paper makes about secret-based cess of authenticating to web-sites, new schemes for au- authentication is that the shared secret between the human thentication are being hatched by the technology industry. user and the system is not maintained in plaintext on the The Liberty framework[4], OpenID[5], CardSpace[6] are system. some examples of “federation” where a single, or a small group of identity-service providers (IdSP) manage the I&A 3.1 IPF Scale processes, while service web-sites - also called “Relying Parties” in this context - are provided assertions by the The eleven (11) layers of the IPF Scale are: IdSP about user-identities. While this has the benefit of off-loading the I&A process to IdSP from the service- IPF Description provider's point-of-view, unless the underlying authentica- tion technology used by the IdSP was strong, the consolida- 0 No identification or authentication tion of user-credentials at the IdSP could lead to a larger compromise for service-providers. 1 Shared-secret based authentication on a local system, or a network without any network en- Finally, in another example of the immaturity of the com- cryption puting industry, the fact that companies that have suffered a breach are not required to report compromises in a techni- 2 Shared-secret based authentication with net- cal manner to some authority, similar to the National High- work encryption way Traffic Safety Administration (NHTSA) for automo- 3 Multiple shared-secret based authentication biles, or the Federal Aviation Administration (FAA) for air- without an external token, but with network en- lines, makes it impossible for the industry to compile statis- cryption tical data that would provide insights to risk and mitigation techniques that work. In a telling example of the failure of 4 Asymmetric-key based authentication with legislation, the “Breach Disclosure” laws of 37+ US states Private Key in a file do not require compromised companies to provide any technical information about the compromised infrastructure 5 Multiple shared-secret based authentication or the mechanics of the compromise, thus disabling the en- with external token and network encryption tire industry from learning from another company's misfor- tune. 6 Asymmetric-key based authentication with Private Key generated and stored on crypto- 3. IDENTITY PROTECTION FACTOR graphic hardware token and using keyboard for authentication to token Just as the medical industry has coined the term “Sun Pro- 7 Asymmetric-key based authentication with Pri- tection Factor (SPF)” as a measure of the ability of sun- vate Key generated and stored on cryptographic screen lotions to block the sun's harmful rays from burning hardware token and using an external PIN-pad human skin[7], this author introduces the term Identity for authentication to token Protection Factor (IPF) as a measure of the ability of an I&A technology to resist attack from unauthorized enti- 8 Asymmetric-key based authentication with Pri- ties. vate Key generated and stored on cryptographic hardware token using an external PIN-pad and The IPF uses a numerical scale ranging from zero (0) to ten being physically present at the machine (10) to indicate the relative effectiveness of the I&A tech- where the resource exists and where authentica- nology to protect credentials, with higher numbers indicat- tion is performed ing a greater ability to resist attack. 9 Asymmetric-key based authentication with Pri- the authentication technology to use for a computer system, vate Key generated and stored on hardware the only factor that truly matters, at the end of the day, is cryptographic token, using an external PIN-pad, the authentication technology's ability to resist attacks. If being physically present at the machine where an authentication technology with a given IPF rating is not authentication is performed and using M of N matched appropriately with the risk that a business wishes control for authentication to token to assume in a given computer system, it is only the ran- domness of attacks that prevents the computer system from 10 Non-existent/Unknown being certainly compromised. 4. CHARACTERISTICS OF THE IPF 3.2 A one-dimensional linear scale? Following are the technological characteristics of each lay- Given the diversity of business, security, operational and er of the IPF Scale, with examples of real-world technolo- user requirements, the IPF Scale begs the question – why a gies, and potential attacks against them. linear scale on a single dimension? Risk-management deci- sions are a lot more complex than can be plotted on a one- 4.1 IPF 0 dimensional scale, so how can security professionals and business managers be expected to make a complex decision There are business situations where a computing device on authentication technology based on a one-dimensional does not require human users to identify and authenticate scale? Chung and Neuman identify multiple dimensions in themselves to avail services from the device. Kiosks in establishing the Strength of Security of network public facilities, such as airports and museums, are com- protocols[26]. However, the current paper has chosen to mon examples of these business situations. focus on only a single dimension for the reason explained below. While the application providing services to the public does operate with the privileges of a User ID known to the un- It is the contention of this author, that while it is true that derlying operating system, for the purposes of our classifi- many variables determine the final outcome of computing cation system, we assume this application has an IPF of infrastructures - cost, ease-of-use, operational complexity, Zero (IPF 0) because it does not prompt the human user - availability, ubiquity, etc. - authentication technologies within the context of the application - to identify and/or au- have only one single over-riding factor that truly matters: thenticate themselves. Such applications are typically built their ability to resist attacks! If an authentication technolo- without any credential databases for authentication. gy is compromised, nothing else matters to the business at that point. (Note: At the time of writing this paper, news Note: However, within the context of the operating system reports have appeared in the computing press about the in which this application executes, I&A technology with a $7.9B loss of Societe' Generale to have been caused by higher IPF rating is assumed to be in force. poor password management of internal trading systems at this bank[8]). I&A technologies with a rating of IPF 0 are assumed to provide no credential risk-mitigation benefits. An analogy in the field of civil engineering serves as a telling example: while civil engineers do pay attention to 4.2 IPF 1 factors such as cost, operational complexity and aesthetics, only a single feature truly matters when constructing a I&A technologies with an IPF of One (IPF 1) are defined as bridge – structural integrity of the design and materials those using a shared-secret based authentication mechanism used to construct the bridge, and the ability of the bridge to without any network encryption, such as SSL, TLS, IPSec carry its load given the adverse conditions the bridge may or message-level security, to protect the credential. be exposed to in its environment. The collapse of the Taco- ma Narrows Bridge (“Galloping Gertie”) in November IPF 1 technologies are different from IPF 0 in that they add 1940[9] is still used as a case-study in the field of Civil En- an authentication mechanism to IPF 0 technologies to in- gineering, to teach engineering students the importance of crease their degree of resistance to attacks. All other char- focusing on design. The more recent collapse of the inter- acteristics of the application and/or system remain the same state bridge on 35W, in Minneapolis in the state of Min- as IPF 0. nesota, US in August 2007[10] serves as another example of what truly matters when all is said and done. The primary example of an I&A technology with IPF 1 is the ubiquitous User ID and Password being transported to It is the position of this paper, that regardless of what fac- the server over a protocol such as the Hyper-text Transfer tors a company might take into account when determining Protocol (HTTP), or a User ID and Password being authen- ticated against a local file or database on the machine 4.4 IPF 3 where the credential is presented. I&A technologies with an IPF of Three (IPF 3) are defined I&A technologies with a rating of IPF 1 are capable of be- as those combining multiple shared-secret based authenti- ing compromised by any of the following forms of attacks: cation mechanisms. Because multiple shared-secrets are used to authenticate an identity, this allows such I&A • Dictionary attacks against the password file; schemes to have a higher IPF rating. • Attacks on the password using Rainbow tables; • Snooping of network traffic for credentials; IPF 3 technologies are different from the prior level in that • Keystroke loggers to capture the credentials; they add a second shared-secret credential to increase their • Phishing attacks that prompt the legitimate user to pro- degree of resistance to attacks. All other characteristics of vide their credentials to the attacker; the application and/or system remain the same as IPF 2. Given the nature of IPF 1 I&A technologies – the use of a Examples of I&A technologies with IPF 3 are those that shared secret to authenticate the user - an attacker can com- combine a User ID and Password with: promise a credential without the knowledge of the creden- tial-owner or server, and usurp the identity of the legitimate • Non-electronic One-Time Password (OTP) tokens – user. So, a compromise to IPF 1 I&A technologies can go such as from a sheet of paper with predesignated OTPs; undetected for long durations after the compromise itself • The selection of a predesignated graphic from an array has occurred. This paper identifies this characteristic fea- of graphics; ture of I&A technologies as being “compromise-blind”. • Predesignated answers to specific questions; • Biometrics-based technology; 4.3 IPF 2 In all cases, the second authentication credential is also a I&A technologies with an IPF of Two (IPF 2) are defined shared secret that must be sent to the authenticator as part as those using a shared-secret based authentication mecha- of the authentication process. nism with some form of network encryption, such as SSL, TLS, IPSec or message-level security, to protect the cre- From a vulnerability point of view, IPF 3 I&A technologies dential. need to be compromised by multiple types of attacks. The User ID/Password part of the authentication set is capable IPF 2 technologies are different from the prior level in that of being compromised by the same attack techniques as IPF they add network and/or message-level security to increase 1 or IPF 2 technologies, while the second shared-secret of their degree of resistance to attacks. All other characteris- IPF 3 I&A technologies is susceptible to phishing at- tics of the application and/or system remain the same as tacks[14]. IPF 1. IPF 3 I&A technologies – regardless of the number of I&A technologies with a rating of IPF 2 are identical to shared-secrets used to authenticate the identity - are com- I&A technologies with ratings of IPF 1, with one excep- promise-blind. tion: they are not susceptible to compromise through snooping of network traffic, thus giving them a higher IPF 4.5 IPF 4 rating. Otherwise, all other characteristics and vulnerabili- ties remain the same. I&A technologies with an IPF of Four (IPF 4) do not use shared secrets for authentication. They use a form of au- Other examples of I&A technologies with a rating of IPF 2 thentication based on asymmetric cryptographic keys – would be those based on biometrics alone. On the surface, more popularly known as Public Key cryptography. while biometric I&A technologies appear to use an external authenticator – fingerprint, iris scan, etc. - the reading is ul- IPF 4 technologies are drastically different from the prior timately translated into a shared-secret - the template. Bio- level in their use of public-key cryptography to increase metrics-based I&A technologies also have their own unique their degree of resistance to attacks. All other characteris- attacks that render them susceptible to compromise[11], tics of the application and/or system remain the same as [12], [13]. IPF 3. IPF 2 I&A technologies, like IPF 1 technologies, are com- An example of an I&A technology with IPF 4 is the X.509 promise-blind. digital certificate using the Client Authentication protocol from SSL or TLS[15]. Another example is the Secure While public-key cryptographic authentication systems are Shell (SSH) Protocol when using public-keys[16]. generally considered to be superior to shared-secret based authentication systems (because no secrets are shared be- Given the nature of public-key cryptography, the network tween the client and the server), I&A technologies with a communication between the client, where the credential is rating of IPF 4 are easier to attack than systems with a rat- presented, and the server where it is authenticated, is en- ing of IPF 5. crypted or cryptographically transformed to prevent replay- attacks; this also eliminates attacks from network-snooping. Nonetheless, external OTP tokens are susceptible to a Public-key cryptography also makes it possible to authenti- phishing attack where the attacker can setup a website that cate a user without having to send the Private Key to the mimics the legitimate server site, and then prompts the le- authenticator; merely proof of possession of the Private gitimate user for their User ID, Password and the OTP se- Key is sufficient to authenticate the user. cret. Upon receiving these, the attacker uses these values to immediately authenticate to the legitimate server site while The defining characteristic of this IPF 4 technology is that displaying an error message to the legitimate user. Thus, the Private Key of the client's asymmetric key-pair is stored an attacker can compromise IPF 5 I&A technologies with- in a file. This file is on the client machine's file-system or out direct access to the token, and without compromising an external drive accessible as part of the client machine's the client or server machines. file-system with standard ownership privileges. However, because the window of opportunity is extremely While the Client Authentication protocol of SSL/TLS and short, and the legitimate user must succumb to a phishing the Public Key Authentication protocol of SSH is robust, attack first, the attacker will have a harder time compromis- the primary vulnerability in this technology is that the file ing an IPF 5 technology than ones with lower IPF ratings. containing the Private Key – typically called a Crypto- graphic Keystore - can be compromised by malware IPF 5 I&A technologies are partially compromise-blind. If through: the external OTP token is stolen or missing, the legitimate user can suspect their credential may get compromised un- • Dictionary attacks that guess the password/PIN protect- less they notify appropriate authorities to take corrective ing the Cryptographic Keystore; and/or action. However, until an Administrator disables that spe- • Keystroke loggers that capture the password/PIN pro- cific OTP credential, the server remains compromise-blind. tecting the Cryptographic Keystore; 4.7 IPF 6 Once compromised, the attacker can establish a new SSL/TLS session with the server – either from the legiti- I&A technologies with an IPF of Six (IPF 6) is the first lev- mate user's PC or from the attacker's own PC if they have el on the IPF Scale that provides a significant ability to re- copied the Cryptographic Keystore file to their machine - sist attacks against compromise of the credential. Not only while assuming the identity of the legitimate user. Neither does it use X.509 digital certificates with the SSL/TLS pro- the legitimate user, nor the server would know that the cre- tocol (or Public Key with the SSH protocol), but it also dential had been compromised. Thus, this I&A technology uses a cryptographic hardware token – rated at FIPS 140-2 using this specific implementation at IPF 4 is compromise- Level 2 (or above). The token is used to generate and store blind. the asymmetric key-pair on, thus eliminating an attacker's ability to copy the Private Key from the client machine[18]. 4.6 IPF 5 In this implementation of an IPF 6 technology, there is little I&A technologies with an IPF of Five (IPF 5) are identical scope for an attacker to compromise the credential from a to IPF 3 - i.e. authentication is based on multiple shared se- remote location: crets – with one exception: in addition to the User ID/Pass- word credential, they use an external electronic One-Time • A dictionary attack (or a Rainbow table attack) is not Password (OTP) token to generate a shared-secret which is feasible since there is no password database on the serv- valid for a very short duration[17]. er to attack; • A keystroke logging attack does not serve much purpose, While IPF 5 technologies drop back to shared-secrets for since the the physical hardware token is necessary to authentication, they are different from prior levels in that complete the Client Authentication protocol in SSL/TLS they add an external hardware token to increase their de- or the Public Key Authentication protocol in SSH; gree of resistance to attacks. All other characteristics of the application and/or system remain the same as IPF 4. • Network traffic is encrypted by the nature of this proto- I&A technologies with an IPF of Seven (IPF 7) differ from col, so an attacker would not learn anything from snoop- IPF 6 in that they use external PIN pads - or other physical ing the network; authentication devices - that are hard-wired to the crypto- • Even if the attacker managed to steal the physical token, graphic hardware token. This allows the legitimate user to launching an attack on the token to access the Private authenticate to the token directly without using the key- Key will be useless, since most token implementations board of the client machine for the authentication process, lock up the token after a small number – typically 3-5 - thereby increasing technologies at this level to resist attacks of incorrect attempts, thus rendering the token useless better than technologies at IPF 6. until the token is unlocked by a Security Officer of the legitimate user's company; IPF 7 I&A technologies are not compromise-blind, since an attacker would not only have to have physical access to the However, there is a possibility that an attacker – once hav- cryptographic hardware token, but also manipulate the ing gained access to the legitimate user's client machine, hard-wired connections between the authentication input and with significant knowledge of the client and server ap- device and the cryptographic token. Servers continue to re- plications, could launch a social-engineering attack with main compromise-blind until an Administrator disables a software of his/her creation. The attack software could specific credential. prompt the legitimate user for the password/PIN to the to- ken; and if the legitimate user typed in his/her password or 4.9 IPF 8 PIN – assuming this to be a legitimate request from an ap- plication on their PC – this would give the attacker access I&A technologies with an IPF of Eight (IPF 8) differ from to the token. IPF 7 in that they require the physical presence of the legit- imate user at the machine where the protected resource is For this attack to work, the attacker must have more than being accessed. This is the same machine where the user the average attacker's knowledge about hardware tokens, presents his/her credential and where the application per- the SSL, TLS or SSH protocols, the look & feel of the forms the authentication. client application that interacts with the hardware token, and finally, a great deal of knowledge of the server applica- By having the legitimate user be present at the machine that tion to be able to manipulate it remotely. will perform the authentication, the machine operators can be assured that there has been no physical tampering of the Slightly less complex – but equally compromising - attacks connections between the cryptographic hardware token and might result in the legitimate user signing objects that the input device presenting the authentication credential. he/she did not intend to sign. This difference distinguishes IPF 8 technologies from those at IPF 7 and adds to the technology's ability to resist at- IPF 6 I&A technologies are not compromise-blind, since tacks. the legitimate user would be aware of the loss of a hard- ware token (if it is external), or would be prompted for a However, IPF 8 technologies are susceptible to compro- PIN to the token. However, until an Administrator disables mise by a knowledgeable insider, someone who has unfet- a specific cryptographic hardware token's credential, the tered access to the server. server remains compromise-blind. IPF 8 I&A technologies are not compromise-blind. 4.8 IPF 7 4.10 IPF 9 In an IPF 6 I&A technology, if the cryptographic hardware token that stored the Private Key were embedded on the I&A technologies with an IPF of Nine (IPF 9) go above motherboard of the client machine as in a Trusted Platform and beyond IPF 8 by adding the requirement that no single Module (TPM)[19], or when an external cryptographic to- individual may gain access to the server individually, and ken is inserted into the client machine through some port, that a quorum of legitimate users must be present and au- the Private Key to the legitimate user's credential would be- thenticated to gain access to the server resource. come accessible to software on the machine. This is typically implemented as an M of N control, where Should the attacker, using a keystroke-logger, capture the M is a subset of N, but represents a majority to establish a PIN or pass-phrase to the cryptographic hardware token, quorum. M and N are both odd numbers. Examples of an they would be able to compromise the legitimate user's cre- M of N control is when 3 of 5, 4 of 7, etc. legitimate users dential and establish an authenticated session to the server. are required to authenticate to the server to access the re- source. By requiring such a control, implementers reduce the risk Oracle and 7 other companies, in November 2006, founded of a sole insider-attack on the resource. While it is still the Identity Governance Framework (IGF) to address the possible to compromise the resource through collusion of governance of identity-related information across enterprise legitimate insiders, operators of such an infrastructure must IT systems[21]. The project is now subsumed under the manage that risk through adequate process controls. Liberty Alliance Identity Framework[22]. IPF 9 I&A technologies are not compromise-blind. Most applications currently depend on tightly-coupled ap- plication programming interfaces (API) to repositories of 4.11 IPF 10 information that includes the attributes of credential own- ers. For example, a Human Resource application has a In keeping with typical scales, this author believes that I&A need to lookup various attributes - such as Social Security technologies with an IPF of Ten (IPF 10) - implying per- Number, tax-related information, medical information, ben- fection - do not exist. There is no such thing as perfect se- efits information, etc. - of personnel whose credentials are curity, and consequently there is no perfect identification stored in the HR database. The HR application may use and authentication technology. one of many APIs – Java Database Connectivity (JDBC), Open Database Connectivity (ODBC), Lightweight Direc- 5. COMPARISON WITH OTHER FRAMEWORKS tory Access Protocol (LDAP), Simple Object Access Proto- col (SOAP), etc. - to access this information depending on There are a number of frameworks and concepts that have what type of repository holds the attributes. However, once been created in the field of identity management. The IPF the application is built to access a specific repository, they is compared to some of these frameworks/concepts to place usually have little flexibility in dealing with the repository the IPF in perspective. schema, or changes in policies with respect to the identity attributes. 5.1 The Liberty Alliance Framework The IGF allows the creation of loosely-coupled systems to In response to an effort by Microsoft to consolidate User reference such identity attributes without hard-coding them ID's and Passwords through a service called Passport, Sun into applications, using XML-based protocols, Client ap- Microsystems and 33 other companies created a consortium plications use the Client Attribute Requirements Markup called the Liberty Alliance to provide an alternative to Mi- Language (CARML)[23] to specify their requirements for crosoft's Passport technology[20]. identity attributes, while the service providers use the At- tribute Authority Policy Markup Language (AAPML)[24] to The Liberty Alliance framework supports many authentica- indicate the attributes they serve and the policies under tion technologies - User ID/Password, OTP, X509 digital which they serve up the attributes. certificates, etc. - and uses Security Assertion Markup Lan- guage (SAML) to federate credentials through an identity Even though the framework does provide a means to create service provider (IdSP). No matter how many web-service loosely-couple applications, it still requires users to authen- providers federate their identity management services to the ticate to some credential verifier before the user can use the IdSP, the end-user must still authenticate to the IdSP before application. While the IGF framework is not explicit in its a SAML assertion can be created to send to the web-service documentation about what forms of authentication are re- provider. quired, given that the framework is now part of the Liberty Alliance, it can be safely assumed that the Liberty-support- It is at the point of authentication at the IdSP that the IPF ed authentication technologies will be supported by the rating would come into play. The IdSP could offer differ- IGF. Therefore, web-service providers can choose to de- ent classes of identity management services based on the fine IGF policies, using AAPML, that serve up different IPF ratings of the authentication technology used which levels of attribute data based on the IPF rating of the au- would allow the web-service providers to manage the risk thentication technology used by the end-user. of their computer systems based on the IPF ratings they choose to accept in the SAML assertions. So, once again, the IGF and the IPF Scale are complemen- tary, providing two completely different benefits and ser- So, the Liberty framework and the IPF Scale are comple- vices to web-service providers and consumers. mentary, each providing a different benefit to web-service providers and consumers. 5.3 NIST Special Publication 800-63 5.2 Oracle's Identity Governance Framework The National Institute of Standards and Technology (NIST) published Special Publication 800-63[2] that defines four Levels of Assurance (LoA) for electronic authentication with Level 1 being the lowest and Level 4 the highest level • The security state of the client machine from which the of assurance. The NIST publication has some overlap with claimant is authenticating to the Verifier. Once again, a the IPF Scale. Relying Party can have little assurance in a claimants' credential if the machine from which they're using the Where they are similar is that they both focus on authenti- token has been compromised; cation technologies and their abilities to resist attacks. However, the NIST publication's authentication LoA be- More work needs to be done in this area to determine the comes confusing because it combines secret sharing optimal way to combine these factors. schemes with asymmetric key schemes within the same level. It is this paper's contention that due to the nature of 5.4 Microsoft's CardSpace asymmetric key-based authentication schemes at IPF-6 or above, they provide significantly better protection of cre- Microsoft introduced an identity meta-system, dubbed dentials than secret sharing schemes. Thus, this author be- CardSpace, to simplify the management of computer-based lieves that the IPF Scale provides better clarity with respect identities[25]. Using standards such as WS-Security, WS- to authentication technology than the NIST LoA frame- SecurityPolicy, WS-Trust, WS-MetadataExchange, SOAP, work. XML and SAML, CardSpace allows an end-user to submit a Security Token provided by an Identity Provider (IdP), to Secondly, the NIST LoA framework is not sufficiently a Relying Party (RP) instead of a credential. granular to distinguish between implementations of a spe- cific authentication technology. As this paper described When an end-user needs to authenticate to an RP's site to earlier, even when using an asymmetric key-based authenti- access a secured resource, the user is presented with the op- cation technology (which is FIPS 140-2 Level 2/3 ap- tion of submitting a security token in addition to other tra- proved) it is possible to differentiate the protection factor ditional forms of authentication supported by the RP. If the rating into at least 4 factors - IPF-6 through IPF-9 - based user chooses the option to submit a security token, they are on how the credential owner is authenticated to the crypto- given the choice of selecting a card from their local graphic token. The NIST LoA collapses such differences CardSpace environment on their client PC. into a single Level 4. It is this author's contention that the IPF Scale provides better risk-management with lesser am- Unless the card they selected was created by a local “self- biguity to implementers. issued identity provider” on their PC, the user is redirected to make a request to a third-party IdP for the security token. Where they differ are, the NIST publication factors in reg- The IdP, after having authenticated the requester, generates istration processes and identity proofing in addition to au- a security token - that is digitally signed and encrypted if thentication technologies in determining the LoA, while the there is sensitive information embedded in it - which is IPF focuses only on the authentication technology. The used by the end-user to submit to the RP. The RP after LoA is designed to provide a business-level assurance re- having verified the token, makes an authorization decision garding claimants' identities and is broader in scope than to allow/disallow access to the secured resource by the end- the IPF Scale. user. This author concedes that there is value in providing this CardSpace, in its first iteration, supports four methods of level of business assurance regarding a claimants' identity, having end-users authenticate to the third-party IdP. These but believes that that a more useful scheme might be to cre- are: ate a quantitative Identity Proofing Score that assigns a quantitative value to various degrees of identity-proofing, 1) User ID/Password; and then combine it with a more granular IPF rating to ar- 2) Kerberos tickets; rive at a more granular Level of Assurance. 3) X.509 digital certificates from either soft (file-based) or hard-tokens; This author, additionally, believes that an LoA must take 4) SAML security tokens created by the “self-issued iden- more factors into consideration when determining a level; tity provider” some factors that need to be factored are: The IPF Scale and CardSpace are complementary. • The operational practices of the verifier's infrastructure; CardSpace has effectively created four levels of authentica- a Relying Party can have little assurance in a Level 3 or tion to the IdP, which is more coarse-grained than the IPF 4 credential if the operations of the Registrar or the Ver- Scale. While this may be acceptable to many RP's, this au- ifier have weaknesses that are unknown until after a thor believes that it is not granular enough to manage risk breach is discovered; effectively. While more analysis is required to determine this, it should • Identification of probabilities for compromises of I&A be possible to define an element in the WS-SecurityPolicy technologies with specific IPF ratings, based on histori- document created by RP's regarding the IPF rating of au- cal breach data; thentication that is acceptable to the RP. The IdP, upon re- • Establishment of a repository with IPF values of known ceiving this security policy from the RP, can authenticate I&A technologies; the end-user using an authentication credential with that • Investigation about the possibility of creating an interna- IPF rating, and then assert if the end-user was successfully tional database of breaches, with sufficient technical de- authenticated at that IPF rating in the security token gener- tail to assist researchers and practitioners on how to im- ated by the IdP. prove computer security; • A methodology for assessing the risk of a given applica- 5.5 Higgins – Open source identity framework tion system, and how implementers of the application may choose an I&A technology with a specific IPF to Higgins is an open source identity framework from the mitigate the credential risk. Eclipse project, with a goal towards integrating identities and profile information across multiple sites and applica- 7. CONCLUSION tions. Using standards such as WS-Trust, SAML, LDAP, OpenID, etc., it allows end-users to manage their identities There is a plethora of identification and authentication and associated attributes using “i-cards”. On the surface, it (I&A) technologies available to the information technology appears t be the “open-source” equivalent to CardSpace, (IT) community today. With the exception of the “some- but Higgins inter-operates with CardSpace as one of the thing-you-know, something-you-have and something-you- identity registries. are” classification scheme, there has been no methodology based on the risk of compromise to credentials, to assist im- To a large degree, the mechanics of Higgins are similar to plementers of systems in choosing appropriate I&A tech- CardSpace. And to the same degree, the IPF Scale is com- nology to address their business risk. The Identity Protec- plementary to Higgins too. Just as CardSpace redirects the tion Factor (IPF) rating is an attempt to create such a classi- end-user to an IdP for authentication and to acquire a secu- fication scheme. rity-token from a “security token service”, Higgins also supports a Token Service that allows end-users to authenti- Covering the gamut of shared-secret based I&A technolo- cate to an IdP and generate a security token that can be gies and asymmetric-key cryptography based solutions that handed to the RP. Since Higgins supports WS-SecurityPol- incorporate the use of cryptographic hardware tokens, this icy, WS-Trust and WS-Security too, it is conceivable that paper presents the IPF Scale and ranks known I&A tech- the same element definitions for CardSpace that define an nologies against this scale on the basis of their protection IPF rating, can be used within the Higgins framework. levels. 5.6 Comparison summary Using the IPF Scale and IPF ratings of individual I&A technology products, implementers of information systems As can be seen from comparing IPF to various identity will have a means to assess the relative strengths of I&A frameworks in this section, the IPF quantifies a unique as- technologies and their ability to resist attacks to the creden- pect of authentication technology that makes it possible to tial. complement and integrate with almost all identity manage- ment frameworks, while adding unique value to the field of The paper concludes that there is no perfect I&A technolo- risk management. gy, and that further research is necessary to validate the as- sumptions and granularity of this model, to create an IPF 6. FURTHER RESEARCH repository of products, and most importantly – to determine the probability of a compromise of each IPF layer based on This is a first attempt at assigning a numerical rating to historical breach data. This information will become cru- I&A technologies so they may be compared to each other cial towards reducing identity-based risks in the future. in mitigating risks of compromise. There are many areas that this author believes requires further research: REFERENCES • Validation of the assumptions of this model. Are there [1] “Information Security for Lawyers and Law Firms” - Sharon Nelson, benefits and attacks that have been overlooked? David Isom, John Simek, 2006, ISBN 1590316630 • Validation of the granularity of this model. Would a [2] NIST Special Publication 800-63 – Electronic Authentication Guide- line, William Burr, Donna Dodson, Tim Polk, April 2006 - http://csr- model that has more granularity – say from zero (0) to c.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf one-hundred (100) serve the community better? [3] “Who goes there?: Authentication Through the Lens of Privacy” – [15] The TLS Protocol Version 1.0 - http://www.ietf.org/rfc/rfc2246.txt Stephen Kent, Lynette Milett, 2003, ISBN-10: 0-309-08896-8 [16] SSH Authentication Protocol - http://www.ietf.org/rfc/rfc4252.txt [4] Liberty Alliance - http://projectliberty.org/liberty/specifications__1 [17] A One-Time Password System - http://tools.ietf.org/html/rfc2289 [5] OpenID - http://openid.net/ [18] Security requirements for cryptographic modules - http://csrc.nist.- [6] Microsoft CardSpace - http://msdn2.microsoft.com/en- gov/publications/fips/fips140-2/fips1402.pdf us/library/aa480189.aspx [19] Trusted Platform Module FAQ - https://www.trustedcomputing- [7] Sun Protection Factor (SPF) - http://en.wikipedia.org/wiki/Sun- group.org/faq/TPMFAQ/ screen#Sun_protection_factor [20] Alliance forms against Microsoft Passport – USA Today, December [8] Poor password Management may have led to bank meltdown – In- 2001 - http://www.usatoday.com/tech/news/2001/12/20/anti-pass- foWorld, February 2008 - port-alliance.htm http://www.infoworld.com/article/08/02/04/Poor-password-manage- [21] Oracle Identity Governance Framework (IGF) - http://www.oracle.- ment-may-have-led-to-bank-meltdown_1.html com/technology/tech/standards/idm/igf/index.html [9] “Galloping Gertie Collapes November 7, 1940” - http://www.ws- [22] Liberty Alliance Identity Governance - http://www.projectliber- dot.wa.gov/TNBhistory/Connections/connections3.htm ty.org/index.php/liberty/strategic_initiatives/identity_governance [10] Interstate 35W Bridge Collapse website - http://www.dot.state.m- [23] Client Attribute Requirements Markup Language (CARML) - n.us/i35wbridge/index.html http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF- [11] T. Matsumoto, H. Matsumoto, K. Yamada, S. Hoshino, "Impact of CARML-spec-03.pdf Artificial Gummy Fingers on Fingerprint Systems," Proceedings of [24] Attribute Authority Policy Markup Language (AAPML) - SPIE Vol. #4677, Optical Security and Counterfeit Deterrence Tech- http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF- niques IV, 2002. AAPML-spec-08.pdf [12] How to hack biometrics - [25] Introducing Microsoft CardSpace - http://msdn2.microsoft.com/en- http://www.theinquirer.net/en/inquirer/news/2005/07/30/how-to- us/library/aa480189.aspx hack-biometrics [26] Modelling the Relative Strength of Security Protocols, 2nd Work- [13] Attacks on Biometric Systems: A Case Study in Fingerprints - shop on Quality of Protection, Oct 30, 2006, Alexandria, VA, USA - http://biometrics.cse.msu.edu/Publications/SecureBiometrics/Uludag http://www-scf.usc.edu/~hochung/papers/qop18-chungneuman.pdf Jain_BiometricAttacks_SPIE04.pdf [14] Phishing attack targets one-time passwords - http://www.theregister.- co.uk/2005/10/12/outlaw_phishing/ Identity Protection Factor (IPF) Arshad Noor StrongAuth, Inc. arshad.noor@strongauth.com IDtrust 2008 – Page 1 Today's Goals ● What is IPF? ● What is the IPF Table? ● Description of IPF Levels IDtrust 2008 – Page 2 The Problem? UserID-Passwords CardSpace LDAP One­time Password Tokens Smartcards Biometrics NIS/NIS+ KERBEROS OpenID SAML Higgins Liberty SSL/TLS with Client­Auth IGF IDtrust 2008 – Page 3 What is IPF? “Identity Protection Factor (IPF) is a measure of the ability of an I&A technology to resist attack from unauthorized entities.” IDtrust 2008 – Page 4 Why 1 dimension? ● Resistance to attack ● What about – Cost? – Ease-of-use? – Convenience? – Deployment issues – Integration issues ● Answer: "Galloping Gertie" IDtrust 2008 – Page 5 IPF Table IPF Description 0 No identification or authentication 1 Shared-secret based authentication on a local system, or a network without any network encryption 2 Shared-secret based authentication with network encryption 3 Multiple shared-secret based authentication without an external token, but with network encryption 4 Asymmetric-key based authentication with Private Key in a file 5 Multiple shared-secret based authentication with external token and network encryption 6 Asymmetric-key based authentication with Private Key generated and stored on cryptographic hardware token and using keyboard for authentication to token 7 Asymmetric-key based authentication with Private Key generated and stored on cryptographic hardware token and using an external PIN-pad for authentication to token 8 Asymmetric-key based authentication with Private Key generated and stored on cryptographic hardware token using an external PIN-pad and being physically present at the machine where the resource exists and where authentication is performed 9 Asymmetric-key based authentication with Private Key generated and stored on hardware cryptographic token, using an external PIN-pad, being physically present at the machine where authentication is performed and using M of N control for authentication to token 10 Non-existent/Unknown IDtrust 2008 – Page 6 IPF-0 * ● NO identification or authentication ● Example: Self-service Kiosks * However, the software is assumed to be executing with the computing environment (and privileges) of a user authenticated with a credential at a higher IPF level. IDtrust 2008 – Page 7 IPF-1 ● Shared-secret based authentication on a local system, or a network without any network encryption Shared Secret-1 IDtrust 2008 – Page 8 IPF-1 Features ● Adds authentication credential to IPF-0 ● Can be compromised by: – Dictionary attacks, network snooping, shoulder- surfing, keystroke loggers, phishing, social- engineering, rogue employee ● Compromise-blind ● Example: UserID-Password IDtrust 2008 – Page 9 IPF-2 ● Shared-secret based authentication with network encryption Shared Secret-1 SSL, TLS or IPSec IDtrust 2008 – Page 10 IPF-2 Features ● Adds network encryption – such as SSL, TLS or IPSec - to IPF-1 ● Can be compromised by: – Dictionary attacks, network snooping, shoulder- surfing, keystroke loggers, phishing, social- engineering, rogue employee or technology- specific attacks (for biometrics) ● Compromise-blind ● Examples: – UserID-Password – Biometrics that convert reading to a template IDtrust 2008 – Page 11 IPF-3 ● Multiple shared-secrets based authentication without an external token, but with network encryption Shared Secrets 1 and 2 SSL, TLS or IPSec IDtrust 2008 – Page 12 IPF-3 Features ● Adds another shared-secret to IPF-2 ● Can be compromised by multiple attacks: – Dictionary attacks, network snooping, shoulder- surfing, keystroke loggers, phishing, social- engineering, rogue employee and technology- specific attacks (for biometrics) ● Compromise-blind ● Examples: – UserID-Password with biometric – UserID-Password with image-selection – UserID-Password with answer to question IDtrust 2008 – Page 13 IPF-4 ● Asymmetric-key based authentication with Private Key in a file Client Authentication SSL, TLS PIN Auth to keystore-file IDtrust 2008 – Page 14 IPF-4 Features ● Uses asymmetric cryptography – does not use a shared secret ● Uses a file-based cryptographic keystore ● Compromised by copying keystore AND: – Dictionary attacks, keystroke loggers ● Compromise-blind ● Examples: – X509 digital certificate with Private Key in a file – Public/Private key-pair with Private Key in a file IDtrust 2008 – Page 15 IPF-5 ● Multiple shared-secrets based authentication with an external token and with network encryption Shared Secrets 1 and 2 SSL, TLS or IPSec PIN Auth to external OTP device using shared secret IDtrust 2008 – Page 16 IPF-5 Features ● Adds external hardware token for second shared-secret to IPF-3 ● Can be compromised by multiple attacks: – Dictionary attacks, network snooping, shoulder- surfing, keystroke loggers, phishing, social- engineering, rogue employee or technology- specific attacks (for biometrics) ● Partially compromise-blind; token loss/theft is immediately detectable ● Examples: – OTP token with UserID-Password – OTP token with biometric IDtrust 2008 – Page 17 IPF-6 ● Asymmetric-key based authentication with Private Key generated and stored on cryptographic hardware token and using keyboard for authentication to token Client Authentication SSL, TLS PIN Auth to HW crypto token using keyboard IDtrust 2008 – Page 18 IPF-6 Features ● Asymmetric cryptography – no shared secret ● Adds external hardware cryptographic keystore to IPF-4 ● Compromised by: – Social-engineering attack – Keystroke-logging AND theft of token ● Client is not compromise-blind; but server can be until client certificate is revoked ● Examples: – X509 digital certificate with Private Key on token IDtrust 2008 – Page 19 IPF-7 ● Asymmetric-key based authentication with Private Key generated and stored on cryptographic hardware token and using an external PIN-pad for authentication to token Client Authentication SSL, TLS PIN Auth to HW crypto token using external PIN reader IDtrust 2008 – Page 20 IPF-7 Features ● Adds external PIN reader to IPF-6 ● Compromised by: Social-engineering attack? ● Client is NOT compromise-blind; but server can be until client credential is disabled ● Example: – X509 digital certificate with Private Key on token with external PIN reader IDtrust 2008 – Page 21 IPF-8 ● Asymmetric-key based authentication with Private Key on cryptographic hardware token using an external PIN-pad and being physically present at the machine where the resource exists and authentication is performed PIN Auth to HW crypto token Client Authentication using external using SSL, TLS PIN reader and being physically present at site IDtrust 2008 – Page 22 IPF-8 Features ● Adds requirement to be physically present at the authentication site, to IPF-7 ● Compromised by: – Rogue employee ● NOT compromise-blind ● Example: – X509 digital certificate with Private Key on token with external PIN reader and requiring physical presence at authentication site IDtrust 2008 – Page 23 IPF-9 ● Asymmetric-key based authentication with Private Key on hardware token, using an external PIN-pad, being physically present at the machine where authentication is performed and using M of N control for authentication to token PIN Auth to HW crypto token using external Client Authentication PIN reader and using SSL, TLS multiple humans being physically present at site IDtrust 2008 – Page 24 IPF-9 Features ● Adds requirement of multiple humans to be physically present at the authentication site, to IPF-8 ● Compromised by: – Collusion of rogue employees ● NOT compromise-blind ● Example: – X509 digital certificate with Private Key on token with external PIN reader and requiring physical presence of multiple humans at authentication site IDtrust 2008 – Page 25 IPF-10 ● Does not exist; there is no perfect authentication mechanism IDtrust 2008 – Page 26 Other frameworks ● No conflict with Liberty (including Identity Governance Framework), CardSpace or Higgins: they all require authentication using some credential at some point which can have an IPF rating ● Some overlap with NIST 800-63 – Has a broader focus – Level of Assurance - which must look at process controls – Mixes technology and process controls – might be useful to define an Identity Proofing Score and combine it with IPF to create a compound value IDtrust 2008 – Page 27 Next steps ● Validation of model – Are these levels sufficient? Or do we need more granularity? ● Probabilities of compromises of I&A technologies with specific IPF ratings based on historical breach data – Database of (anonymized) breaches with sufficient technical data to assist researchers ● Repository of IPF ratings for technologies ● Model for risk-assessment model and use of specific IPF technologies to manage risk IDtrust 2008 – Page 28 Conclusion ● Questions? ● Contact Information – www.strongauth.com – www.strongkey.org – info@strongauth.com – (408) 331-2000 IDtrust 2008 – Page 29 OpenID Identity Discovery with XRI and XRDS Drummond Reed Les Chasen William Tan Cordance Corp. Neustar, Inc. Neustar, Inc. 3020 Issaquah-Pinelake RDF #74 46000 Center Oak Plaza 46000 Center Oak Plaza Sammamish WA 98075 Sterling VA 20166 Sterling VA 20166 +1.206.618.8530 +1.571.434.5474 +1.571.434.5400 drummond.reed@cordance.net les.chasen@neustar.biz william.tan@neustar.biz ABSTRACT Internet identity management frameworks such as SAML [1], The work examines the identity discovery problems that needed Shibboleth [2], Liberty Alliance [3], Information Cards [4], to be addressed by the OpenID 2.0 protocol in order to enable a Higgins [5], and OpenID [6] all must deal with the “identity user-centric Internet identity layer. The paper illustrates how the discovery problem”. OASIS XRI and XRDS specifications were applied to help solve Of these frameworks, the one most distinguished by how it these identity discovery challenges. The work also considers handles discovery is OpenID. Due to its origin as a means of interoperable identity discovery for other Internet identity combating blog spam, the premise of OpenID is that a user may frameworks such as SAML, Information Cards, and the Higgins assert their identity by using their own identifier—for example Project, and recommends future work. the URL of their blog, home page, social network profile, or any other web resource the user controls. An OpenID relying party Categories and Subject Descriptors (RP) can then discover from that identifier the user’s OpenID C.2.4 [Computer-Communications Networks]: Distributed provider (OP) and initiate OpenID authentication. systems – distributed databases. D.4.6 [Operating Systems]: This approach is unquestionably “user-centric” because it gives Security and protection. H.5.2 [Information Interfaces and the user complete control over the identifier they use and Presentation]: User Interfaces – user-centered design. H.5.4 therefore the set of OPs that an RP may query. (The issue of [Information Interfaces and Presentation]: whether an RP will accept authentication from the user's selected Hypertext/Hypermedia – architectures, navigation, user issues. OP selected is out-of-scope for the OpenID protocol.) However K.6.5 [Management of Computing and Information Systems]: even with this very direct approach, there were still identity Security and protection – authentication, unauthorized access. discovery challenges that needed to be solved in the steps up from K.8.3 [Management and Maintenance]: Security and protection. OpenID Authentication 1.0 [7] in 2005 to OpenID Authentication 2.0 [8] in 2007. In this paper we explore these challenges and General Terms show how the OASIS XRI and XRDS specifications were Design, Security, Human Factors, Standardization, Verification. employed to overcome them. We also look at how XRI and XRDS are being used by other Internet identity management frameworks, and conclude by suggesting future work. Keywords User-centric identity, identity discovery, XRI, Extensible Resource Identifier, identifier, resolution, XRDS, Extensible 2. IDENTITY DISCOVERY CHALLENGES Resource Descriptor Sequence, OpenID, Yadis, SAML, IN OPENID information card, i-card, Higgins Project. The basic OpenID authentication scenario is that a user logs into an RP site by entering their OpenID identifier rather than a 1. INTRODUCTION conventional RP-specific username. The RP then resolves the In enterprise identity management frameworks, the context of an OpenID identifier to discovery the user’s OP. In OpenID 1.0, the identity being asserted is generally known, or can be discovered only supported identifier was a URL, and resolution was either directly via mechanisms specified in the framework. But when the directly to the user’s OpenID server, or to an HTML page context is the Internet as a whole, this approach is no longer containing a meta tag with the URL of the OpenID server. viable. Early OpenID usage raised the following challenges. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are 2.1 Service Description not made or distributed for profit or commercial advantage and that copies As soon as OpenID began to evolve into V1.1 [9], there arose the bear this notice and the full citation on the first page. To copy otherwise, need not just to discover the user’s OpenID service endpoint, but or republish, to post on servers or to redistribute to lists, requires prior to describe its capabilities (if nothing more than whether it specific permission and/or a fee. supported OpenID V1.0, V1.1, or both). In addition, the OpenID IDtrust '08, March 4-6, 2008, Gaithersburg, MD, USA. protocol was designed to be extensible so it can include transfer Copyright 2008 ACM 1978-1-60558-066-1 …$5.00. other useful identity information, such as attributes or authorizations. For example, the Simple Registration extension (SREG) [10] was developed to automatically transfer the most 2.5 Extensibility frequently-request attributes needed for site registration. Thus Lastly, OpenID architects and users recognized that if OpenID is OPs needed the ability to describe whether they supported SREG to develop into a generalized framework for user-centric Internet or other OpenID extensions. identity, it must be extensible to a wide variety services that may In addition, OpenID 1.0 was not the only URL-based be associated with an OpenID identifier. These services should all authentication protocol; it was actually preceded by Lightweight share a common, interoperable description format, including the Identity (LID) [11]. Users who wanted their OpenID identifier to ability for services—with the user’s permission—to communicate work with either protocol needed a way to describe that it and interact with each other on the user’s behalf. supported both capabilities. Again, these were not the purposes for which HTML header link These requirements were all difficult to fulfill with HTML link tags were designed. Clearly a more robust but still lightweight tags; they called for a more generalized, standardized service solution is needed. description mechanism. 3. ADDRESSING THESE CHALLENGES 2.2 OpenID Recycling In conventional username/password identity schemes, if a user WITH XRI AND XRDS account is abandoned, the RP can delete the credential and At the same time OpenID 1.1 was evolving, the XRI Resolution reassign the username to another user. With OpenID, this option 2.0 specification [12] was under development at the XRI is not available since the RP does not assign the user's identifier— Technical Committee at OASIS. The previous 1.0 version was a that choice is up to the user. generalized identity discovery framework developed for use with XRIs (Extensible Resource Identifiers)—abstract identifiers This introduces the “OpenID recycling problem”: if a user loses designed for network-, domain-, and application-independent control of their OpenID identifier (for example, if the domain resource identification. XRIs essentially serve the same function name registration for their URL expires), a new registrant of that for URIs (and any other form of network address) that domain URL can gain access to the same private resources as the previous names serve for IP addresses. registrant because the new registrant can point the URL to their own choice of OP. However because XRI resolution was based on HTTP(S) and XML, there was nothing to prevent the resolution protocol from This problem still exists even if the OpenID identifier is assigned being generalized to work with URLs as well as XRIs. This by a service provider who can control reassignment, because became a key design goal of XRI Resolution 2.0, and lead to the service providers with large namespaces cannot afford to following features being incorporated into identity discovery for permanently lock up names within that namespace. OpenID Authentication 2.0. 2.3 Resolution Integrity and Trust 3.1 Service Endpoint Discovery with XRDS From a security standpoint, the weakest link in the OpenID Documents protocol is the discovery stage. This is not only where an XRI infrastructure uses the XRDS (Extensible Resource untrustworthy RP will focus a phishing attack, but also where Descriptor Sequence) format for discovery documents. By resolution of a standard HTTP URL may be hijacked. The use of contrast with DNS, which describes resources using binary an HTTPS URL provides significant (but not complete) protection resource record types, XRDS documents are a simple, easily from these attacks. extensible XML format for describing the capabilities of any However OpenID cannot make HTTPS resolution the default due XRI-, IRI-, or URI-identified resource in a manner that can be to implementation and usability challenges—it is often not consumed by any XML-aware application (or non-XRI aware feasible for an individual to obtain an SSL certificate, and browsers via a proxy resolver). outsourced Web hosting services do not always support HTTPS Figure 1 is an example of an XRDS document describing the infrastructure. So although HTTPS is recommended, a user must resource identified by an XRI for the user of a telephone number, explicitly have it provisioned, then request to use it at every xri://(tel:+1-201-555-0123)*home . (This particular XRI OpenID RP by typing their fully qualified HTTPS URL (not a illustrates the ability of XRI syntax to include identifiers from shortcut like “username.provider.com”). other namespaces, essentially acting as an “XML for identifiers”.) 2.4 Privacy and Non-Correlation Another widely recognized privacy implication of the OpenID 1.x protocol is that it required users to share the same OpenID identifier (or one of a small set they control) with every site. While in some cases this is desirable for cross-site attribute and reputation management, in many other cases such correlation keys are neither necessary nor desirable. In fact other Internet identity frameworks including Liberty Alliance and Information Cards have gone out of their way to avoid introducing such keys. Figure 1. An example XRDS document *home 2005-05-30T09:30:10Z xri://(tel:+1-201-555-0123) *residence https://example.com/example/resource/ xri://(tel:+1-201-555-0123)!1234 xri://=!4a76.c2f7.9033.78bd xri://(tel:+1-201-555-0123)!1234 xri://$res*auth*($v*2.0) application/xrds+xml http://resolve.example.com http://resolve2.example.com xri://(tel:+1-201-555-0123)!1234 xri://$res*auth*($v*2.0) application/xrds+xml;https=true https://resolve.example.com http://openid.net/signon/1.0 http://example.com/openid/ https://example.com/example/resource/ /media/pictures image/jpeg http://pictures.example.com By requesting an XRDS document (MIME type in DNS [13]. Elements with equal priority are selected randomly, application/xrds+xml) when resolving an OpenID identifier, which can be used to achieve round robin behavior [14]. an OpenID RP can easily determine the OpenID service endpoints associated with a user’s identifier. Each service endpoint, 3.2 Preventing OpenID Recycling with described by the element, can be identified Persistent XRI I-Numbers using one or more elements. This element accepts The OpenID recycling problem reflects a generic issue in resource a URI, IRI, or XRI to identify the service type. This makes the identification: the fact that semantic identifiers—the identifiers XRDS format extensible by any specification or service provider people find easiest to remember and use—are often the least without the need for a central type registry. persistent. The reason is the evolutionary nature of semantics— In addition to advertising the service types it supports, each people constantly change names, addresses, and service providers. service endpoint can include a set of URIs representing concrete This runs directly contrary to identity management policies that network endpoints at which this service is available. Redundant depend on a persistent binding between an identifier and the network endpoints can be expressed by using more than one resource it represents (user, device, application, domain, etc.) element. Priority among multiple URIs for the same This problem is minimized in enterprise contexts because service endpoint (or multiple service endpoints of the same type) identifier reassignment policies can be tightly enforced. is expressed using a priority attribute with the same semantics as Unfortunately such policies are not feasible at Internet scale. The domain name secondary market, for example, exists for the very 3.3 Automatic Trusted Resolution with XRI I- purpose of transferring domain name registrations. Names One solution has been to create separate Internet registry and XRI architecture includes two options for secure resolution. The resolution infrastructure for persistent identifiers. The IETF URN first is to require HTTPS for each request in the resolution chain. (Uniform Resource Name) [15] and Handle [16], [17], [18] For example, the i-name @cordance*drummond requires two specifications were developed for this purpose. However because XRDS document requests: 1) query the @ registry for *cordance they lack the human usability of DNS, their adoption has largely (* is assumed after the @), 2) query the @cordance registry for been limited to digital artifact registries and DRM systems where *drummond. In HTTPS secure resolution, each resolution query identifier non-reassignability is an absolute requirement. must use an HTTPS service endpoint, or else resolution fails. A primary motivation for development of the XRI specifications The second option is for each XRDS document in the resolution at OASIS was solving this usability problem by providing a chain to include a signed SAML assertion that resolvers can uniform syntax and resolution protocol for both reassignable and verify via public key information discovered in the previous persistent identifiers. In XRI parlance these known as i-names and XRDS. The two options are not exclusive; indeed the i-numbers. XRI resolution makes it very efficient for each specification recommends that SAML trusted resolution be used reassignable i-name to have a synonymous persistent i-number in conjunction with HTTPS trusted resolution to ensure that is discovered in the same resolution call. For example, in confidentiality. Figure 1, the local i-name *home, shown in the element is synonymous with the i-number RPs using OpenID Authentication 2.0 can advantage of this xri://=!4a76.c2f7.9033.78bd, shown in the capability by automatically resolving all XRIs using at least the element. HTTPS trusted resolution protocol. It is relatively easy for XRI This architecture enables XRI registry infrastructure such as that authorities to comply with this requirement because XRI is an implemented by XDI.org [19] to enforce policies requiring each abstraction layer for URIs; thus an XRI resolution service i-name registration to have a synonymous i-number, and for endpoint only needs to be provisioned with one SSL certificate, i-numbers to never be reassigned, as in URN or Handle registries. no matter how many XRI identifiers it hosts. XDI.org, for example, mandates HTTPS support for the XRI global registry However, synonym assertions must be verified before they can be and resolution infrastructure it oversees [22]. trusted. XRI Resolution 2.0 specifies two automated verification methods: a) confirming that the synonyms were assigned by the The result is that unlike URLs, all XRI i-names used as OpenID same XRI authority, or b) if they were assigned by different identifiers can automatically default to secure resolution, without authorities, confirming that they are authorized synonyms by the need for a user to type a special prefix. checking for the existence of an reference between the two XRDS documents. 3.4 Anti-Correlation with Pairwise Identifiers The result is a deep structural solution to the OpenID recycling The premise of OpenID 1.x was that users would share one problem. Although OpenID Authentication 2.0 does not require globally unique URL (or one of a presumably small set of URLs) XRIs, it specifies that when an XRI i-name is used as an OpenID with RPs. This stood in stark contrast to other Internet identity identifier, after discovery the RP must use the synonymous frameworks such as Liberty Alliance ID-WSF and Information canonical i-number as the user’s claimed identifier, and that this Cards, which go to great lengths to use pairwise identifiers so synonym must be verified [20]. Since this i-number will never be they introduce no new correlation handles at the protocol level. reassigned, both the registrant and the RP are protected from OpenID Authentication 2.0 addressed this issue by adding support future reassignment of the i-name. This also enables XRI for “directed identity”—a term for the use of pairwise-unique registries to safely reassign i-names to new registrants by pairing identifiers coined by Microsoft Chief Identity Architect Kim them with a new persistent i-number. Cameron [23]. This was accomplished by adding the new service It should be noted that for backwards compatibility, the OpenID endpoint type “http://specs.openid.net/auth/2.0/identifier_select”. Authentication 2.0 specification also supports the ability for an When a user enters an OpenID identifier resolving to a service OpenID service provider to add a fragment to a URL in order to endpoint of this type (typically by entering the URL or i-name of distinguish the current user of that URL from a previous or future their OpenID provider, rather than their own OpenID identifier), user [21]. However this solution to OpenID recycling works only the RP knows it must ask the OP for the user’s identifier. The OP for service providers who strictly control their entire URL can then offer the user the choice of using one of their existing namespace. For other URLs, transfer of the domain will also OpenID identifiers, or having the OP generate a pairwise-unique transfer control of URL fragments. Furthermore, reassignment of identifier for this specific relationship. In fact the user need not the base URL to a new registrant terminates the ability of the know or remember this identifier as the OP can store and previous registrant to assert that identity because a fragment automatically use it in future logins to the same RP. cannot be resolved. XRI i-numbers do not have this limitation; they can continue to be used indefinitely without regard to the This directed identity feature works with both URLs and XRIs, reassignment of any i-names with which they have previously however by assigning XRI i-numbers in the OP’s own XRI been associated. delegation space, OPs can take advantage of their persistence and security features discussed above. 3.5 Extensibility to New Services have (if any) that satisfy it. If the claims are not “self-issued”, but Much of the market interest in OpenID lies in its larger potential come from a third-party identity provider (“managed”), the card to serve as a framework for many user-centric identity services, itself contains the metadata necessary for the selector to send an all keyed off a user’s OpenID identifier(s). To do this, these authentication token to the provider and obtain a security token services need to share a common discovery mechanism that bearing the claims, which it then passes to the RP. enables different services to interoperate on the user’s behalf. In this architecture, an RP does not need to discover a service An example is the new OAuth 1.0 protocol, released by the endpoint for the identity provider directly; all interactions are OAuth community in October 2007 [24]. OAuth might be called handled through the selector client. This has clear privacy “OpenID for applications”, i.e., it enables a user to delegate to a advantages. However one drawback is that it does not provide the website or application the ability to access the user’s private RP with an addressable network endpoint for further discovery or resources—without the user needing to reveal their actual interaction with the user. This has led to proposed “OpenID credentials. Information Cards” [29]—standard information cards issued by a user’s OP and conveying a security token containing the user’s OAuth 1.0 assumes that OAuth providers and consumers are authenticated OpenID identifier. RPs accepting OpenID configured manually. However the OAuth community quickly information cards can then invoke OpenID 2.0 discovery to locate recognized the need for automated discovery of OAuth service other identity services for the user. endpoint URIs and other configuration metadata. By December 2007 they had published the first draft of OAuth Discovery 1.0 [25]. This specification makes extensive use of XRDS 4.3 The Higgins Project The Higgins Project is a protocol-independent open-source architecture, and specifically the ability for it to be extended by: Internet identity framework designed to integrate identity, profile, a) new service type URIs, IRIs, or XRIs from any namespace, b) and relationship information across multiple heterogeneous new XML elements and attributes from other XML namespaces, systems. Started by Parity and including IBM, Novell, Oracle, and c) new trust models based on existing XRDS elements such and Google as contributors, Higgins achieves interoperability via as and and/or three primary framework elements: extension elements. 1. The Higgins Data Model—a uniform identity data 4. INTEROPERABILITY WITH OTHER model based on RDF and OWL [30]. INTERNET IDENTITY FRAMEWORKS 2. Context providers—Higgins components that Although we have focused on the relevance of XRI and XRDS to implement the Higgins data model to provide a common OpenID discovery, these technologies are equally applicable to API for access to any identity data store, from an LDAP other Internet identity frameworks. In fact they may play a key directory to an XML document [31]. interoperability role, as discussed in this section. 3. I-cards—a consistent user interface metaphor for all identity interactions, regardless of the underlying 4.1 SAML protocols or token types. I-cards are essentially The OASIS SAML specifications include authentication flows synonymous with “information cards”, but broader in very similar to OpenID except for the initial discovery steps [26]. function because they include card types not defined by So it is not surprising that they can be adapted to use the same Microsoft [32]. XRDS discovery mechanism as OpenID 2.0. The only difference In the Higgins data model, every identity subject in a context that is the use of a SAML authentication service endpoint. This flow exposes a Higgins API is addressable with the combination of a was demonstrated by Pat Patterson of Sun at Internet Identity ContextId and a local SubjectId. For interoperability, Higgins Workshop in December 2006 [27]. required ContextIds to be in a form that enables automated This flow can be further enhanced to provide automated discovery discovery of Higgins context provider configuration metadata, of the SAML metadata [28] necessary to interact with the SAML while at the same time supporting the native identifier types that service provider. By including an XRI as the value of the may be used across a very wide variety of Higgins contexts. element in the SAML authentication The Higgins Project was able to satisfy these requirements with service endpoint, an RP can use XRI trusted resolution to resolve the XRI/XRDS 2.0 framework. First, it lets them express this identifier and obtain another XRDS with service endpoint(s) ContextIds as filenames, URLs, or XRIs [33]. Second, it lets them advertising the location of the service provider’s SAML metadata define a small set of Higgins service endpoint types and extension documents (which should also be retreived using HTTPS). elements for expressing Higgins context provider configuration metadata in XRDS documents [34]. The result is that any Higgins 4.2 Information Cards component can resolve the ContextId portion of a Higgins The information card architecture implemented by Microsoft address, discover the Higgins configuration metadata in the CardSpace, the Higgins Project, and others takes a different XRDS document, and perform automatic configuration. approach to identity discovery. First an RP publishes a machine- readable policy description of the claims they require for XRI and XRDS also help enable a new of i-card called a authentication/authorization to a Web resource. When the user “relationship card” or “r-card”. R-cards are intended not just for browses that page, their identity selector client reads the policy one-time attribute exchange, but for ongoing, user-permissioned and presents the user with a choice of the information cards they data sharing relationships. To support this functionality, r-card metadata includes an XRI provisioned by the r-card issuer. An that layer must be able to both support and consume identity selector accepting this r-card can resolve this XRI to reputation services. This is another area of focus of the discover the service endpoint(s) for the r-card data sharing OASIS IDtrust Member Section, and may spawn a new protocol(s) spoken by both the selector and the RP. The Technical Committee in that section by mid-2008. appropriate protocol can then be used to synchronize updates to r- card data, such as a change-of-address for a magazine or mailing 6. REFERENCES list subscription. [1] S. Cantor, J. Kemp, R. Philpott, E. Maler, 2005. Assertions Initial r-card implementations use an early version of the XDI and Protocols for the OASIS Security Assertion Markup (XRI Data Interchange) data sharing protocol under development Language (SAML) V2.0. http://www.oasis- at the OASIS XDI Technical Committee [35]. Although the final open.org/committees/security. XDI 1.0 specifications are not expected until later this year, XDI [2] The Shibboleth Project, 2007. Internet2/MACE. is well suited to sharing data in the Higgins Data Model because it http://shibboleth.internet2.edu/. too uses an RDF graph model—one in which all nodes are [3] Liberty Alliance Project Specifications, 2007. The Liberty addressable using XRIs. Higgins r-cards correspond to XDI link Alliance Project. contracts—XDI graphs that express the policies governing usage, http://www.projectliberty.org/liberty/specifications__1 synchronization, redistribution, and retention of XDI data. Higgins clients can resolve the XRI in an r-card to an XRDS [4] A. Nanda, 2007. Identity Selector Interoperability Profile document to discover an XDI service endpoint and request the V1.0. Microsoft Corporation. associated link contract to set up a data sharing relationship. [5] Higgins Project Charter, 2005, Eclipse Foundation. http://www.eclipse.org/higgins/higgins-charter.php. 5. CONCLUSION AND FUTURE WORK [6] OpenID Specifications, 2007. OpenID Foundation. This paper has shown that performing secure, privacy-protecting http://openid.net/developers/specs/. identity discovery is a challenge even for a discovery-oriented [7] B. Fitzpatrick, 2005. OpenID Authentication 1.0. OpenID protocol like OpenID. OpenID 2.0 was able to meet these Foundation. http://openid.net/specs/specs-1.0.bml. challenges by taking advantage of the abstract resource identification and discovery features of the OASIS XRI and [8] B. Fitzpatrick et al, 2007. OpenID Authentication 2.0. XRDS framework. Other Internet identity frameworks including http://openid.net/specs/openid-authentication-2_0.html. SAML, Information Cards, and the Higgins Project have also [9] B. Fitzpatrick, D. Recordon, 2006. OpenID Authentication been able to support new features and address interoperability 1.1. OpenID Foundation. http://openid.net/specs/openid- issues using XRI and XRDS. authentication-1_1.html. However we are still a long ways from a fully generalized and [10] J. Hoyt, J. Daugherty, D. Recordon, 2006. OpenID Simple interoperable identity discovery layer for the Internet. For this Registration 1.1. OpenID Foundation. level of abstraction, XRI and XRDS are at the same stage DNS http://openid.net/specs/openid-simple-registration-extension- was twenty years ago, and must mature under usage just as DNS 1_0.html. did. Key areas of future work include: [11] J. Ernst, 2005. Lightweight Identity (LID). Netmesh • Caching and scalability testing. XRI authority servers and Corporation. http://lid.netmesh.org/. resolvers need the same high-performance XRDS caching as [12] G. Wachob et al, 2007. Extensible Resource Identifier (XRI) DNS nameservers and resolvers. Resolution 2.0 Committee Draft 02. OASIS XRI Technical • Proxying. XRI 2.0 includes basic support for proxy resolvers Committee. http://docs.oasis-open.org/xri/2.0/specs/cd02/xri- that offload the work of XRI resolution and XRDS parsing to resolution-V2.0-cd-02.pdf. another web server. Proxy resolvers are attractive both for [13] Ibid, Section 4.3.3. simplicity and performance reasons, but special attention [14] Ibid, Section 4.3.3. must be paid to security, privacy, and caching requirements. [15] R. Moats, 1997. URN Syntax. Internet Engineering Task • PKI integration. While XRI 2.0 includes basic support for Force (IETF) Request for Comments (RFC), RFC 2141. signed SAML assertions and a simple mechanism for key http://www.ietf.org/rfc/rfc2141.txt. discovery, it has the potential to become a much more robust and generalize framework for key distribution and [16] Sam Sun, Larry Lannom, Brian Boesch, 2003. Handle management. The XRI Technical Committee recently joined System Overview. Internet Engineering Task Force (IETF) the OASIS IDtrust Member Section to further explore this Request for Comments (RFC) 3650. HDL= area. http://hdl.handle.net/4263537/4060 • Reputation. After basic location and configuration metadata, [17] Sam Sun, Sean Reilly, Larry Lannom, 2003. Handle System the type of discovery metadata in greatest demand is Namespace and Service Definition. Internet Engineering reputation. In a context as large as the Internet, where Task Force (IETF) Request for Comments (RFC) 3651. relationships are often dynamic and traditional trust cues and HDL= http://hdl.handle.net/4263537/4068 metrics may not be available, reputation is an essential [18] Sam Sun, Sean Reilly, Larry Lannom, Jason Petrone, 2003. ingredient, as sites like eBay and Slashdot have shown. It is Handle System Protocol (Ver 2.1) Specification. Internet especiallly relevant to an identity discovery layer because Engineering Task Force (IETF) Request for Comments http://blogs.sun.com/superpat/entry/yadis/xri_identifier_resol (RFC) 3652. HDL= http://hdl.handle.net/4263537/4086 ution_with_saml [19] S. Blackmer et al, 2006. XDI.org Global Services [28] Cantor, S. et al, 2005. Metadata for the OASIS Security Specifications V1.0. XDI.org. http://gss.xdi.org. Assertion Markup Language (SAML) V2.0. OASIS [20] Ibid [8]. Section 7.3.2.3. Standard. [21] Ibid. Section 11.5.1. [29] Hardt, D; Bufu, J., 2007. OpenID Information Cards 1.0 – Draft 01. Sxip Identity Corporation. [22] Ibid [19], Section 5.3 https://openidcards.sxip.com/spec/openid-infocards.html [23] K. Cameron, 2005. The Laws of Identity. Microsoft [30] Higgins Project, 2007. The Higgins Data Model. Corporation. http://wiki.eclipse.org/Higgins_Data_Model [24] Atwood, M et al, 2007. OAuth Core 1.0. OAuth.net. [31] Higgins Project, 2007. Context Providers. http://oauth.net/core/1.0/ http://wiki.eclipse.org/Context_Provider [25] Hammer-Lahav, E., 2007. OAuth Discovery 1.0 Draft 1. [32] Higgins Project, 2007. I-Cards. http://wiki.eclipse.org/I-Card OAuth.net. http://oauth.googlecode.com/svn/spec/discovery/1.0/drafts/1/ [33] Higgins Project, 2007. ContextId. spec.html. http://wiki.eclipse.org/ContextId [26] Hodges, J., 2007. Technical Comparison: OpenID and [34] Higgins Project, 2007. Context Discovery. SAML, Draft 6. http://identitymeme.org/doc/draft-hodges- http://wiki.eclipse.org/Context_Discovery saml-openid-compare-06.html [35] Reed, D., Sabadello, M., 2008. The XDI RDF Model. [27] Patterson, P, 2006. YADIS/XRI Identifier Resolution with OASIS XRI Technical Committee. http://wiki.oasis- SAML 2.0. open.org/xdi/XdiRdfModel OpenID Discovery Using XRI and XRDS IDtrust Symposium, March 4-6, 2008 Drummond Reed, Cordance Les Chasen, NeuStar William Tan, NeuStar Overview  The OASIS XRI and XRDS specifi- cations played a key role in identity discovery for OpenID 2.0  We’ll explain the five key discovery challenges they helped solve  We’ll suggest potential interoperability with other identity protocols/frameworks What is XRI (Extensible Resource Identifier)?  An OASIS Technical Committee  Started January 2003  An open standard language for abstract structured identifiers  Identifiers that are independent of domain, application, protocol, or language  Identifiers that resolve to other identifiers  “XML for identifiers” Synonyms XRI Layer Reassignable Persistent “i-name(s)” “i-number” XRDS Docu- XRDS ment Resolution Domain Name Other Concrete concrete Identifier IP Address TN identifier Layer types Local Path/Query URI/IRI What is OpenID?  An open community specification for user-centric Internet authentication  Based on the concept that users have their own globally-resolvable identifier and OpenID authentication service  Prime use case: eliminate the need for separate usernames and passwords for different websites Relying Party (RP) XRDS Document OpenID Provider (OP) Evolution from OpenID 1.x to 2.0  OpenID 1.0 “hardwired” a URL to an OpenID identity server  This was very rigid and not extensible  As the OpenID 2.0 tent grew, it needed a more flexible and robust discovery layer The challenges for OpenID 2.0 identity discovery  Service description  OpenID recycling  Resolution integrity and trust  Privacy and non-correlation  Extensibility Challenge #1: Service description  Describe what versions of OpenID an OpenID identifier supports  Enable redundant, prioritized OpenID provider endpoints  Describe what other authentication protocols may be available (e.g., LID, SAML) Service description: the solution  XRDS (Extensible Resource Descriptor Sequence) documents  The XML analog of DNS resource records  Very simple set of elements describing  Synonyms for an identifier  Service endpoints for an identifier  Expiration and trust verification metadata *example 2005-05-30T09:30:10Z xri://= xri://=!7c4.58ff.7c9a.e285 xri://@!2017.cd67.94c8.023!c83d xri://$res*auth*($v*2.0) http://res.example.com/=!1234.5678.a1b2.c3d4/ http://openid.net/openid/1.1 http://openid.net/openid/2.0 +openid http://authn.example.com/openid/ Challenge #2: OpenID recycling  With usernames/passwords usernames can be recycled  The service provider controls the binding with the credential  With OpenID, that’s no longer true  The user controls the binding to the credential  Losing control of the identifier = losing control of the credential Challenge #2: OpenID recycling  Service providers with large name- spaces can’t afford to assign names once and lock them up forever  Examples: AOL, Yahoo  DNS names are inherently recyclable – an entire industry exists to serve the secondary domain name market OpenID recycling: the solution  Synonyms  Support the binding of a recyclable identifier with a non-recyclable synonym  Authenticate based on the persistent synonym  Treat the recyclable identifier as only a temporary handle for the persistent synonym OpenID recycling: the solution  Persistent synonyms is a primary raison d’être for XRI  XRI distinguishes between reassign- able “i-names” and persistent “i-numbers” at the syntax level  XRDS documents provide automated synonym mapping  XRI Resolution 2.0 includes automated synonym authorization verification *example 2005-05-30T09:30:10Z xri://= xri://=!7c4.58ff.7c9a.e285 xri://@!2017.cd67.94c8.023!c83d xri://$res*auth*($v*2.0) http://res.example.com/=!1234.5678.a1b2.c3d4/ http://openid.net/openid/1.1 http://openid.net/openid/2.0 +openid http://authn.example.com/openid/ Challenge #3: Resolution integrity/trust  OpenID could not specify HTTPS resolution for all OpenID URLs  Too many users do not have access to HTTPS certs or infrastructure  Thus the default had to be HTTP  This forces users with HTTPS URLs to have to type the entire string, e.g., https://my.openid.identifier.tld Resolution integrity/trust: the solution  As abstract identifiers, XRIs always map to concrete service endpoints  XRI resolution offers three trusted modes:  HTTPS, SAML, or both  Thus all XRI i-names can use HTTPS resolution as the default  No need for users to know/do anything Challenge #4: Privacy & non-correlation  OpenID 1.x assumed users would share the same identifier(s) with every RP  Violates the Fourth Law of Identity:  A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. Privacy & non-correlation: the solution  Directed identity  Users can enter the URL or XRI of their identity provider  The discovered XRDS doc contains a directed identity service endpoint  The RP redirects the user to their OP to select their identifier  The OP can also generate a pairwise unique “per relationship” identifier Privacy & non-correlation: the solution  Directed identity supports means OpenID 2.0 satisfies the Fourth Law  It is the only mode some large service providers currently support  Yahoo  Ideally users will have a choice of whether to use a public or directed identifier Challenge #5: Extensibility  OpenID is a framework for user-centric identity services  RPs need to be able to discover what OpenID extension specs an OP supports  SREG, AX, PAPE (more coming)  The discovery format itself needs to be extensible Extensibility: the solution  XRDS documents  Service types are declared using URIs, IRIs, or XRIs – anyone can extend  Multiple types can be declared for the same service endpoint  Elements can be added from any XML namespace  XRDS documents can redirect or refer to other XRDS documents Extensibility: the solution  Example: OAuth  “OpenID for services/applications”  Allows users to authorize a website or application to access protected resources without providing their credentials directly  OAuth Discovery uses XRDS extensibility http://api.example.com/ 2007-12-31T23:59:59Z AUTH-HEADER POST-BODY URL-QUERY HMAC-SHA1 http://oauth.net/core/1.0/endpoint/request https://api.example.com/session/request POST PLAINTEXT ... Interoperability with other identity frameworks  SAML  Information Cards  Higgins SAML  OpenID can use SAML!  Shown by Pat Patterson at the Internet Identity Workshop in December 2006  Same discovery steps, similar protocol flow, just using SAML tokens  Can also use XRDS documents for automated discovery of SAML metadata Information Cards  Information cards can carry discoverable OpenID identifiers  XRDS discovery is not used in the information card flow  But sharing an OpenID claim can enable the RP to do XRDS discovery on other identity services Higgins  Higgins needed a solution for cross- domain context discovery  Higgins resolves a URL or XRI to an XRDS document to discover:  The service endpoint URI(s) for the context  The Higgins context configuration metadata needed to open the context *mycontext 2999-01-01T00:00:00.000Z xri://@ !12345 @!12345 $context+jdbc jdbc:postgresql://192.168.1.102/mydatabase dbuser dbpass Future work  Caching and scalability testing  Proxying  Performance optimization  Integration with authority servers  PKI integration  Reputation discovery Conclusions  OpenID may or may not become an Internet-wide authentication standard  But OpenID identity discovery model has already proved broad utility  XRDS resolution provides a common discovery format for URLs and XRIs  It can provide an interoperable foundation for Internet identity layer Contact us  Drummond Reed, Co-Chair, XRI TC  http://xri.net/=drummond.reed  drummond.reed@cordance.net  Les Chasen, NeuStar, Editor, XRI TC  http://xri.net/=les.chasen  les.chasen@neustar.biz  William Tan, NeuStar, Editor, XRI TC  http://xri.net/=wil  william.tan@neustar.biz  Learn through the IDtrust Knowledgebase of educational materials and background on the standards  Share news, events, presentations, white papers, product listings, opinions, questions, and recommendations through postings, blogs, forums, and directories.  Collaborate with others online through a wiki interface http://idtrust.xml.org Identity & Policy (for Security, Privacy and Trust) March, 4th 2008 NIST Identity and Trust Symposium Rakesh Radhakrishnan Chief Identity Integration Architect (Telco) Sun Microsystems, Inc. 1 Agenda • Vertical Integration of Identity Systems (mapping identifiers and aggregating meta-data) • Policy based Security Service invocation (SaaS) • Pervasive Policy Paradigm • FAM Policy System Architecture • Policy Orchestration (papers + POC/Pilots and Prototypes) 2 Identity and Trust 3 Identity and Trust 4 Vertical Integration (Identity & Security) User & Device Centric IDS User ID & Profile Device ID & Profile User & Device specific Policies Access & Sensor Network IDS AM Agents for Wifi, WiMAX, BPL, Cable head end, xDSL, RFID/EPC & more Core & Federated Network IDS FM integration with OAM, NG IN, HSS, HLR, NAC, FW & more Content & Service Centric IDS Integration with Service Registry Repository, ESB, DRM, Service specific Policies, & more. 5 Policy based Security Services (SAAS) • Authentication Services (many Authentication types/contexts) • Policy Services (Rule Management Services) • Federation Services (CDSSO, COT, interlinked Federation) • Session Services (distributed sessions – network facing and service facing) • Logging Services (end to end) • Token Management Services (token table, token transfers, etc.) • Repository Services (agnostic to repository technology) • Key Management Services (certificates, algorithms, enc/dec) • Identity Reputation Services (history of transactions) • Identity Assurance Services (NIST/Liberty) • Identity and Trusted Computing (Resource labeling+TPM) • Identity Privacy Management Services (icons) • Role Management Services (full life cycle of roles) • Identity Context Services (location, presence, etc.) • Identity Mobility Services (roaming, distributed sessions, etc.) • Identity Service Management Services (service provisioned to entities) • Identity DRM Services (disintermediation) • Identity Audit and Compliance Services (reporting) 6 Policy based Security Services (SAAS) 7 Pervasive Policy Paradigm 8 Pervasive Policy Paradigm 9 Pervasive Policy Paradigm 10 Pervasive Policy Paradigm 11 Policy System for SOA (FAM 8.x Architecture) 12 Policy System for SOA (FAM 8.x Architecture) access obligations 2. access request PEP 11. obligations requester service 3. request 10. response 8. request context context PDP 9. response 7. resource resource handler context 4. attribute 6. attribute query 5c. resource 1. policy PIP attributes 5b. envrionment attributes 5a. subject attributes PAP subjects environment 13 Pervasive Policy Paradigm • To provide a method for combining individual rules and policies into a single policy set that applies to a particular decision request • To provide a method for flexible definition of the procedure by which rules and policies are combined • To provide a method for dealing with multiple subjects acting in different capacities • To provide a method for basing an authorization decision on attributes of the subject & resource • To provide a method for dealing with multi-valued attributes • To provide a method for basing an authorization decision on the contents of an inf resource • To provide a set of logical and mathematical operators on attributes of the subject, resource and environment • To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components • To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects, resource and action • To provide an abstraction-layer that insulates the policy-writer from the details of the app env • To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement 14 Pervasive Policy Paradigm • Identity enabled Derived Device Policies • Identity enabled Access Networks Policies • Identity enabled QOS/QOE Policies • Identity enabled Session Specific Policies • Identity enabled Privacy Preservation Policies • Identity enabled Service Security Policies • Identity enabled Content Control Policies • Identity enabled Enterprise Network Policies • Identity enabled Regulatory Requirement Policies • Identity enabled Event Log Policies • Identity enabled Contextual Policies • Identity enabled Policy Assurance (with PCCP) • Policy Orchestration 15 Policy Orchestration for Control & Alignment 16 Policy Orchestration using XML & XACML 17 Policy Orchestration for Control & Alignment 18 100+ XACML Papers & Series • NIST Paper on Device & Log Policies (PDA or any Mobile IP Devices) • NCSA Paper on Policies for VO (PIP and PCCP) • Dr. Mouli's papers on RBAC/XACML, Privacy Policies, Enterprise Policies and Policy Inference (4 papers) • Papers on Contextual Policies and Mobile Agents • Joint papers with ISV, NEP & Industry Forum ­ Book 1: Identity and Security (06/07) ­ Book 2: Identity and Policy (06/08) ­ Book 3: Identity and SOA -09 (context, mobility, Enterprise SOA, etc.) ­ Book 4: Identity and Trust -09 (TCG, TPM, COT, TNC, etc.) ­ Book 5: Identity and eGov 10 (Assurance and Reputation) 19 100+ POC, Pilot and Proto-types • Cisco, Juniper, Alcatel, Nokia/Siemens and many more NEP's integrate with FAM for NAC policies • Trust Digital and I-Ovation like ISV's for Device policies • TAZZ & Bridge-water for BB 4G Networks for IMS, IPTV policies • Kabira and Telcordia for RT-Charging Policies (session based policies) • True-baseline, Cisco and Juniper for QOS policies • Layer 7 Technologies for Service policies • Reactivity and Securent for Enterprise Network policies • Log Logic for Event and Log Policies • CDN policies (projects) • OSS/BSS TMF Co-op and policy orchestration • I-pass for Network facing policy orchestration • Sun ESB and FAM for service policy orchestration 20 What did we learn? • XACML is great for abstraction of policies and Attributes (ABAC) -service orchestration automatically invokes polices • Policies themselves require operator or user defined workflow (e.g., device + NAC + user level authN -iPass) • Continuity in end point security (event based Policies) • RT Policy Checking and Certification is very important (PCCP) requires orchestration • Policy Information Point can leverage XDI (PIP) and can share context via an Open ESB • Use-full for aligning Service SLA with Network QOS • Changes is Environment (code RED, breaches in the network, etc.) forces dynamic policy work-flows • Alignment to Audit Rules and Log based Policies • Session Specific policies invoked when highly Security Sensitive Service is invoked. 21 What did we learn? • Stage 0 – Registration is Key for Success – this includes identity provisioning, role management and rule definitions, workflow definitions, etc. • Do not forget things like -Support multiple password policies for a user, depending on the targets on which he is having account etc. • RBAC is a project by itself • POC and Demo’s when followed up with Real Projects require Executive Sponsors, Resources (SI, Partners), and a methodology • Most projects are JEE environments with Heterogeneous platforms • Not all XACML profiles will be leveraged for initial stages of project – resource profile with request response works well for most use cases (H and M), RBAC profile is extremely power full, XACML –WS policy has been used, privacy policy exchange tested, QOS policies trialed. • Plan for acquisitions and mergers impacting project 22 What did we learn? • Policy Orchestration works – not all use cases require end to end orchestration – but will require a subset of policies to be orchestrated – NAC policy, Device Policy and AuthN policy for example – with the Req-Resp model between multiple PEP and PDP’s • PIP integration is basically Secure Exchange of Context Data and Profiles (location, presence, preference, etc.) • Policies are integral part of Identity Assurance • PCCP – Policy Compliance and Checking points external to a PMP will be required for ongoing continuous validation of legitimacy of policy with inference and other techniques • XACML –DRM ? Abstraction from multiple DRM techniques • Delegation and Administration profile in a PMP (3rd party) • Obligation (3rd party) 23 What did we learn? • Its not easy – The tools are there – but it requires extensive discipline and Project Management • Each project is driven by specific domain level requirements (Privacy and Audit or QOE) • Partners are extremely important for creating an Eco System • POC and Proto-type in a Lab is a different project from Production (Architecture Assessment helps and Pilots as well) • Leverage Speciality integration partners • Address scope with phases (1 to 5) • Create Policy Building Blocks (with XACML abstraction) • Align with Role Management, Resource Management and SOA projects • Policy Infrastructure is key for ID Governance 24 An evolving Identity System Users S/XACML Web S/XACAML Web S/XACML Web S/XACML Web S/XACAML Web S/XACAML Web Federation Service Federation Service Federation Service Federation Service Federation Service Federation Service Federated Access Manager PCCP PIP (Compliance (Context and Identity Support System Core Identity System Engine) Checking Engine) Rule Role Resource Manager Manager Manager Identity Identity Assurance Trusted Reputation Resource Systems Provisioning and Workflow (Identity, Role, Rule and Resource Provisioning) Systems Log, Audit and Reporting 25 26 Thank You !!! rakesh.radhakrishnan@sun.com http://www.network-identity.com 27 Open Reputation Management Systems ORMS „ D Develop l scenarios i ffor reputation t ti managementt z Reputation of individuals, business partners, services processes, possibly even data „ D Develop l reference f model d l and d reputation t ti ttechnology h l z Flexible reputation data model z Framework and protocol/s for exchanging and porting reputation data z Evaluation algorithms for mapping reputation to risk / risk levels z Support for privacy privacy, multiple identities identities, identity resolution portable Summary of actual Peer reviews past behavior, by service provider Digital Identity ⇒ Trust in specific attribute or future behavior? specific Background check R l id Real identity tit Identity Verification, Identity Proofing against external data = Strong Identity Reputation (in Policy) Reputation Define Policy Monitor, Enroll & Reputation Audit, Proof Report Users Reputation Issue & Enforce Manage User Access Control Rights Reputation Reputation Thoughts „ Need anti-use cases „ Need to consider protections and fail-safe mechanism / policy to prevent cascading impact... whether accurate, in error or malicious... kind of like the circuit breaker in the stock market „ A "reputation score" should likely be computed within a situation / context with an expiration, rather than via static assignment. This has more to do with ensuring the right context, t t rather th than th assuming i that th t scoring i resultslt wouldld b be highly variable. Thoughts „ Humans and entities, roles and personas.... which is to be considered when Jim uses a credit card at a store? Jim is a homeowner h or Ji Jim iis th the sole l proprietor i t off a construction t ti company. „ Contexts and aggregations .... what info is relevant ? Jim th citizen the iti andd Jim Ji the th sole l proprietor i t are bboth th bbaddddrivers; i Jim the citizen pays taxes, but Jim the sole proprietor can't pay some bills „ Att ib t weighting Attribute i hti and d order d off precedence d ... is i it ever more or less important to.... be a good driver, to pay your bills, to receive a reference letter from a priest, to be a democrat / republican, republican etcetc.?? Thoughts „ Constraints and Degrees of Freedom... likely better to define independent dimensions of reputation and then look f trends for t d in i deviation d i ti ffor di dimensions i rather th ththan tto develop an aggregate value too early in the process „ Threats and vulnerabilities... playing the reputation system; use off surrogates, t cascading di iimpact;t h homogeneity it off analyses „ Reputation "qualities" .... freshness / stallness, trend (d i ti or other) (derivative th ) OpenID Provider Reputation IDtrust Symposium, March 4-6, 2008 Drummond Reed, Cordance OpenID has a crying need for reputation services!  The OpenID authentication protocol has no inherent trust model  Any OpenID user can register with any OpenID provider (OPs)  This leaves a wide open question for OpenID relying parties (RPs): Which OpenID Providers should we trust??? The evidence  The largest OpenID providers in the world...  Yahoo  AOL  Google Blogger  ...do not accept OpenID logins  They only issue OpenIDs The solution the OpenID community prefers...  ...is not a top-down federation model, but an organic reputation network model  This fits the open, scalable, organic nature of OpenID  It would also map easily into the OpenID protocol flow Relying Party (RP) 2A. XRDS Document OpenID Provider Reputation Service OpenID Provider (OP) Trust, a dictionary definition • Real-world or Social: The concept of social trust can be obtained from dictionaries, such as Merriam Webster: " • 1 : assured reliance on the character, ability, strength, or truth of someone or something • 2 a : dependence on something future or contingent : HOPE b : reliance on future payment for property (as merchandise) delivered CREDIT • 3 a : a property interest held by one person for the benefit of another b : a combination of firms or corporations formed by a legal agreement; especially : one that reduces or threatens to reduce competition • 4: (1) : a charge or duty imposed in faith or confidence or as a condition of some relationship (2): something committed or entrusted to one to be used or cared for in the interest of another b : responsible charge or office c : CARE, CUSTODY " Basic Trust Models • Suspicious still. Don't ever trust anyone, even after they have done something nice. • Suspicious until. Don't trust anyone until they prove themselves. • Trust until. Trust people until they screw up. • Trust still. Trust people even after they make mistakes, sometimes even when they hurt you. Models in Practice Implementing Trust Models • NSA: "a trusted system or component is one with the power to break one's security policy“ • X.509: "Generally, an entity can be said to "trust" a second entity when it (the first entity) makes the assumption that the second entity will behave exactly as the first entity expects…” • ABA Digital Signature Guidelines (ABADSG) I: trust is not defined per se, but indirectly, by defining "trustworthy systems" (or, systems that deserve trust) …” • PGP: even though PGP uses the word trust extensively, such as in web-of-trust… Confusing the Implementation… • Public Key Infrastructures • PGP Web of Trust • Trust Frameworks- Liberty, Bayesian, WS-Trust and others • Policy and Governance • Trust Metrics -karma, feedback • Reputation Identity Verification • Personal Consent • I am Chris • Parental Consent • This is my child Chris • Peer Verification • Based on what I know of (Distributed Trust) Chris, that is Chris • Delegated • Based on Chris’s breeder Administration documents, or derivatives, (Financial Institution) this is Chris Trust in the Veracity of Identity A basic explanation of a Trust and Reputation system • Peers store opinions on their experiences; they store an opinion about the people they interact with and the systems they are on. • Peers share their opinions providing recommendations for people and systems. • A peer’s opinion can be weighted based on how much the querying peer trusts them. • The aim of the system is to eliminate malicious peers and systems An Example • David has two friends John who is a mechanic and Scott who is a Doctor. • David trusts Scott with a medical complaint but not to fix his car and respectively, trusts John to fix his car but not to diagnose a medical condition. • So in the context of fixing a car John is trustworthy, but Scott is untrustworthy. • What one peer may consider a good file is not what another peer would consider good. For instance peer A’s priority in a good file is its content regardless of its quality. The Doppelganger effect • People want multiple identities it; – Use a pen/pseudo name – Anonymity • People have identities within different contexts; – Family – Work – Online Friends A FOAF Example A Layer Deeper Trust and Reputation are based on context of interaction The Need for Common Data Models • How to describe the trust among persons from one site to another? • Do interactions on one site affect another… would it be helpful to know? • What commonality exists and how can they become transparent? • How can privacy be preserved? I am a Power Seller on ebay Would You Buy From Me on Auction Fire? The Need for Transparency • How do my actions follow me? • How can trust be transferred, or reputation be borrowed from one site to another? • Can other commercial data enrich my reputation – credit score, etc? Identity & Policy (for Open Reputation) March, 4th 2008 NIST Identity and Trust Symposium Rakesh Radhakrishnan Chief Identity Integration Architect Telco) Sun Microsystems, Inc. 1 Agenda • Reputation Data explained • Need for ID Governance for ORMS • ID Assurance for ORMS • XDI and XACML/AAPML • Policy based Reputation Context 2 Reputation • Reputation: A specific characteristic or trait ascribed to a person or thing • Security Sensitive (stakeholder owning and managing the data- TRW for Credit Reports, External Entity rating Doctors, etc.) • Reputation aids in Rating Services (credit rating, lawyer rating, device rating, etc.) • Needs a Refutation process (by the entity concerned) • Needs to align with Privacy and other concerns • Common Representation and Interpretation of Scores • XDI - a single pointer for multiple reputation data sources 3 Liberty Alliance Identity Governance 4 Liberty Alliance Identity Governance 5 Liberty Alliance Identity Governance ­ Declarative Syntax ­ Which client may specify attribute requirements ­ Providers of Identity related Attributes to express policy on the usage of information ­ Align with Privacy and other concerns ­ PPEL (preference expression language) • Strict • Cautious • Moderate • Flexible • Casual 6 Identity Assurance and ORMS ­ IA Levels • Little of No confidence • Some confidence • High confdence • Very High confidence ­ IA Level's aligned to Impact Levels 7 Identity Assurance and ORMS ­ Mapping IA level required when sharing – Reputation Data – trivial reputation data, security sensitive reputation data, etc. ­ Financial Reputation for Loan might require higher levels of IA, etc. ­ Reputation Data can lead to higher or lower IA levels. ­ Assurance and Reputation – critical to managing Identity Lifecyles ­ Reputation Data and IA level linked to Specific Services and COT that deliver such services 8 XDI and XACML ­ Integration of Policy based and Reputation based -Trust Systems • Policy based -structured organisation environment • Reputation based – unstructured user community • Reputation-based Trust can be formalized by relations between Trustors, Trustees, Actions and Trust Levels (policies) • The two combined improves Trust Management –(paper from Europe in 2006) ­ Potential Synergies - • XDI mapping to multiple Reputation Data Sets • XACML mapping to multiple Data Specific policies 9 Policies based Reputation Context ­ Policy Orchestration and ABAC – leverages reputation context for the delivery of contextual services • Driving Record and Ratings -for a given individual and specific periodic analysis of matching automobile insurance providers – may be offered as a service -that complies with privacy preference policies of defined by the user. • Doctor Reputation and Rating -for a given city and specific area of specialization (autism and PDD) – may be offered as a service -that complies with the NAB (national autism board) with (policies for) the ratings validated by parents of autistic kids in area 10 Thank You !!! rakesh.radhakrishnan@sun.com http://www.network-identity.com 11 A Content-Driven Access Control System Jessica Staddon1 Philippe Golle1 Martin Gagné2∗ Paul Rasmussen1 1 2 Palo Alto Research Center University of California at Davis {staddon, pgolle, rasmussen}@parc.com gagne@cs.ucdavis.edu ABSTRACT population and [28] shows that even characteristics like pro- Protecting identity in the Internet age requires the ability fession and nationality can be identifying. Hence, identity to go beyond the identification of explicitly identifying infor- protection requires the ability to control access to an indi- mation like social security numbers, to also find the broadly- vidual’s attributes, even those attributes an individual may held attributes that, when taken together, are identifying. share with many others. We present a system that can work in conjunction with nat- We propose a system that protects identity and other sen- ural language processing algorithms or user-generated tags, sitive information by controlling access to an individual’s to protect identifying attributes in text. The system uses a attributes through encryption. Attributes can be extracted new attribute-based encryption protocol to control access to from text with natural language processing tools such as such identifying attributes and thus protects identity. The [17] or through the manual association of attributes by user system supports the definition of user access rights based on tagging. Inference detection algorithms such as [28] can de- role or identity. We extend the existing model of attribute- termine what sets of attributes allow sensitive information, based encryption to support threshold access rights and pro- such as identity, to be inferred. Attributes can be of varied vide a heuristic instantiation of revocation. granularity. For example, we might want to group all social security numbers into an “SSN attribute” since it is likely that any SSN should be protected. In contrast, we may not Categories and Subject Descriptors need to protect all names, so it might make sense to repre- E.3 [Data]: Data Encryption sent each name as its own attribute and only control access to the ones deemed sensitive. Once attributes have been identified, our system uses a General Terms novel protocol for attribute-based encryption to offer protec- Security tion against sensitive inferences based on those attributes. Passages in unstructured documents and fields in forms are encrypted based on their attributes, and users are assigned a Keywords decryption key according to the attributes they are allowed Access control, attribute-based encryption, secret sharing, to access. The encrypted document can then be released and inference control, revocation. shared publicly with the assurance that no one will be able to recover identifying, or otherwise sensitive, information, 1. INTRODUCTION without the proper access rights (in the form of a decryp- tion key). Identity protection is about more than protecting social With this ability to define fine-grained access rights based security numbers, passport numbers and other values as- on document content, the system can ensure users are only signed for the explicit purpose of identification. Recent re- able to access information about certain individuals. For search has shown that even broadly held attributes, when example, a user authorized to view articles about a partic- taken together, can be identifying. For example, [18, 27] ular former CIA agent Valerie Plame Wilson, can be given demonstrate that the triple of gender, zip code and date of the capability to decrypt any article provided it mentions at birth is unique to a large fraction of individuals in the U.S. least three of the following four organizations, as the pres- ∗ This work was done while interning at the Palo Alto Re- ence of any three is strong evidence that the text is about search Center. Valerie Wilson: Brewster, Jennings and Associates (a CIA front company), London School of Economics (one graduate school she attended), College of Europe (another graduate school she attended) and the CIA (her employer). Permission to make digital or hard copies of all or part of this work for Alternatively, the system can protect all identities by pre- personal or classroom use is granted without fee provided that copies are venting the user from decrypting enough information to infer not made or distributed for profit or commercial advantage and that copies identity. For example, an employee of a mortgage company bear this notice and the full citation on the first page. To copy otherwise, to who arranges property appraisals might be given a decryp- republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. tion key that allows them to view the property address and a IDtrust ’08, March 4-6, 2008 Gaithersburg, MD. contact number for the applicant, but not identifying infor- Copyright 2008 ACM 1978-1-60558-066-1 ...$5.00. mation like the applicant’s social security number or enough place a user in the revocation scheme with a conjunction of demographic attributes to infer identity. attributes, and users store the keys assigned by the revoca- We have implemented a research prototype of our system. tion scheme to each of their conjunctions, this may lead to Our implementation is based on interviews conducted with high communication overhead (O(2m ), where m is the total professionals who routinely deal with sensitive data in their number of attributes). work. The implementation allows the system administrator Commercial Offerings. There are a number of commer- to define access rights for different users of the system by cially available products that provide identity protection by the user’s identity or role. However, it goes beyond tradi- finding, and optionally, protecting, identifying information tional role-based access control (RBAC) systems (see, for in documents. The vast majority of these focus on pat- example, [14]) by tying enforcement of those access rights tern matching explicitly identifying information like social to document content, as opposed to the categorization of a security numbers and account numbers (see, for example, document. For example, while with RBAC it may be nat- [29, 24]). The product offered by MortgageGrader [21] goes ural to block access to all performance appraisals, with our a step further by protecting race and other attributes to system it is easier to distinguish between Bob’s access to protect against discrimination, not identification. The only Mary’s performance appraisal and Bob’s access to his own commercial technology of which we are aware with even the performance appraisal. In addition, our system provides an potential to protect against identification through the as- efficient approach to protecting sensitive content because it sociation with broadly held attributes is the technology of allows a single (encrypted) version of a document to be cir- AreteQ [1]. However, their main application appears to be culated within an organization while ensuring that each user protecting sensitive military information such as weapons will only be able to view the portions of the document they development and they do not appear to offer encryption as are authorized to see. a mode of protection. Overview. This paper is organized as follows. In section 2, we survey related work. In section 3 we describe various use cases for our technology based on field interviews we 3. USE CASES conducted. We describe our model in section 4. Our novel Prior to developing our encryption algorithms and re- attribute-based encryption protocol is presented in section 5 search prototype, we conducted interviews with financial and our prototype system is discussed in section 6. Our sector and legal professionals who routinely deal with sensi- model of attribute-based encryption with revocation and our tive data. These interviews suggested a number of use cases heuristic construction are in section 7. We conclude in sec- for content-driven access control that we describe now in tion 8. turn. Mortgage Lending. In order to comply with privacy leg- 2. RELATED WORK islation (e.g. the Gramm-Leach-Bliley Act) and to sup- port separation of duty mandates in Sarbanes-Oxley, lending Our system is related to work in a number of different companies need to decompose processing of financial infor- areas, each of which we discuss in turn. mation into several roles and control the financial informa- Attribute-Based Encryption. Our encryption proto- tion that is accessible by employees based on their role. For cols are forms of attribute-based encryption. The notion example, a lender might provide access to a loan application of attribute-based encryption (ABE) is introduced by Sahai for the purposes of evaluating the credit of the applicant and and Waters in [25]. In follow-on work, Goyal, Pandey, Sahai appraising the property for which the loan is sought. The and Waters [19] extend the model of [25] to accommodate credit evaluator needs identifying information such as the general monotone access rights and provide a novel secret applicant’s social security information and name, but does sharing-based scheme for supporting general access rights not need the property address, whereas the appraiser may whose security relies on standard BDDH. only need the address. With our system, the application We further extend the model of [19] by allowing for user can be encrypted once and the different keys assigned to the revocation. In addition, our use of ABE for identity protec- credit evaluator and the appraiser ensure that each person tion, and other undesired inferences stemming from docu- will be able to view only the information they need. ment content, is new. Our protocols are designed with this Mergers and Acquisitions. When a company is inter- application in mind. In particular, in section 5.1 we present ested in being merged or acquired, it needs to make its fi- a scheme that leverages an understanding of topic detection nancial data available to potential “suitors” for review. The algorithms in the natural language processing community to current approach to this involves the construction of a vir- control access to text about a targeted individual. tual “dataroom” which houses all the relevant records and Revocation and Broadcast Encryption. Revocation to which suitors are given access. The difficulty is that it is schemes and broadcast encryption schemes exist for both desirable to parameterize the extent of the access according the symmetric key and public key settings (see, for exam- to the stage of the negotiations. A new suitor may be only ple, [16, 23, 12, 8]). In either setting, the goal is to distribute given coarse financial information whereas a suitor who is keys to users so that given any target subset of users, it is deemed to be more serious might be allowed to see names possible to encrypt a message so that exactly those users can of clients and more detailed records. To achieve this fine- decrypt the message. In our setting, users have previously grained access control today it is necessary to sanitize the assigned access rights and based on these, it may not be documents and records differently for the various suitors. necessary to revoke arbitrary subsets of users. The natural With our system, the data can be encrypted once, and the adaption of revocation and broadcast encryption schemes to suitor’s decryption key determines what data they can ac- our setting leads to high overhead. In particular, if we re- cess. Legal. In the United States there is a broad trend to- and their negations w1 , . . . , wm , and outputs secret pa- ward storing court records online. These records contain a rameters dσ . wide array of identifying information including social secu- rity numbers, names, and addresses, some of which may be Encrypt(mk, M, T ) takes as input a master key mk, a mes- redacted upon request (see, for example, Florida statutes sage M , and a subset T ⊂ W of the attributes that take [15]). A potentially more efficient approach would be to en- the value true in the message M , and outputs a cipher- crypt the identifying fields and passages and ensure through text C. the decryption keys that only authorized users can access Decrypt(T, dσ , C) takes as input a set of attributes T ⊆ W, the identifying content in the online record. a secret key dσ corresponding to a boolean formula σ and a ciphertext C, and outputs a message or a special 4. MODEL symbol ⊥. As discussed in section 1, we present encryption schemes that take as input documents (or document regions) on which such that if T satisfies σ, then we have automated or manual content analysis has been performed Decrypt(T, dσ , Encrypt(mk, M, T )) = M. to generate tags that reflect the meaning of the document. For example, the tags may be keywords in the document, or Informally, an ABE scheme is secure if a user can only metadata associated with the document such as the name decrypt portions of documents that satisfy the boolean for- of the document’s author or the date the document was cre- mula that describes the access rights of the user. Formally, ated. Following the terminology introduced by Sahai and we define the security of an ABE scheme through the fol- Waters in [25],we refer to these tags as attributes, and our lowing game between an adversary and a challenger: encryption protocol as an attribute-based encryption (ABE) protocol. Setup: the challenger runs the Setup algorithm, gives the Let W = {w1 , . . . , wm } represent the set of all attributes. public parameters to the adversary and keeps the mas- These attributes are boolean variables that take the value ter key to himself. true in documents or portions of documents associated with the attribute, and take the value false otherwise. For exam- Phase 1: the adversary adaptively issues queries σ1 , . . . , σm , ple, let wi represent the attribute ‘John Smith’. The variable where each σi is a boolean formula over the variables wi takes the value true in portions of documents that involve in W and their negations. The challenger responds ‘John Smith’, and false everywhere else. by running the KeyGen algorithm and gives the se- Access rights to a document can be represented formally cret key dσi corresponding to σi to the adversary. In as a monotone boolean formula over the variables w1 , . . . , wm addition, the adversary adaptively issues encryption and their negations w1 , . . . , wm . (In what follows, we de- requests for a message M and attribute set T . The note the boolean operator AND by ∧ and OR by ∨). A user challenger responds by running Encrypt and gives the can access all documents or portions of documents whose resulting ciphertext C to the adversary. assignment of values to the boolean variables w1 , . . . , wm Challenge: the adversary outputs two equal length mes- satisfy the boolean formula that expresses the user’s access sages M0 and M1 , and a subset T ∗ of W such that rights. For example, if a user has rights to all documents T ∗ satisfies none of the boolean formulas σi issued in that contain both the attributes w1 and w2 , but not w3 , R this is represented by the formula: w1 ∧ w2 ∧ w3 . Phase 1. The challenger picks a bit b ← − {0, 1}, en- More generally, we represent the access rights of a user crypts C ← Encrypt(mk, Mb , T ) and outputs C. in disjunctive normal form (DNF), i.e. as a disjunction of Phase 2: the adversary adaptively issues queries σm+1 , . . . , σn conjunctions of the variables w1 , . . . , wm and their negations. such that T ∗ does not satisfy σi for m + 1 ≤ i ≤ n. We refer to the conjunctions that make up the disjunctive The challenger answers these queries as in Phase 1. formula as “subformulas” of the user’s access rights. For example, the conjunction (w1 ∧ w2 ) is a subformula of the Guess: the adversary outputs a bit b0 . access right (w1 ∧ w2 ) ∨ (w1 ∧ w3 ) ∨ (w4 ). Let T ⊂ W, and let σ be a boolean formula over the We define the advantage of the adversary in attacking the variables w1 , . . . , wm and their negations. We say that T scheme as satisfies σ if σ is satisfied when the variables in T are set 0 1 AdvA (λ) = P r[b = b ] − to true and the variables in the complement of T are set to 2 false. The ABE scheme is secure if the adversary’s advantage is Definition 4.1. An ABE scheme consists of four algo- negligible. In this paper, we prove the security of the ABE rithms1 : scheme proposed in section 5 in the selective-set model (fol- lowing [9, 10, 6]). Specifically, we assume that the set T ∗ Setup(λ, W) takes as input a security parameter λ and a is given by the adversary at the beginning of the game, be- set of attributes W = {w1 , . . . , wm }, and outputs the fore he receives the public key. We note that schemes secure public parameters and a master key, (pub, mk). The against selective attacks are also secure against adaptive at- set W must be part of the public parameters. tacks, with a loss of 2m (where m is the number of keywords) in the efficiency of the reduction. KeyGen(mk, σ) takes as input a master key mk and a monotone boolean formula σ over the variables w1 , . . . , wm The proof of security of our ABE scheme is based on the 1 A similar definition was independently proposed in [19]. Bilinear Decisional Diffie-Hellman (BDDH) assumption. We briefly describe BDDH here, referring the reader to [7] for Setup(λ, W). additional information. Say W = {w1 , . . . , wm }. Let G and G0 be groups and let e : G × G → G0 be an admissible bilinear map (see [7]). Bilinear Decisional Diffie-Hellman Let G1 and G2 be Select a random generator g ∈ G and a random integer groups of prime order q, with an admissible bilinear map S ∈ {0, . . . , |G| − 1}. Compute h0 = e(g, g)S , and select (see [7]) ê : G1 × G1 → G2 , and let g be a generator of R G1 and h = ê(g, g). The BDDH problem is to distinguish 4- g1 , . . . , g m ← − G. The values g1 , . . . , gm are associated with tuples of the form (g a , g b , g c , habc ) and (g a , g b , g c , hd ), where attributes w1 , . . . , wm . The public key is (G, g, h0 , g1 , . . . , gm ) a, b, c, d are random elements of the set {1, . . . , q − 1}. We and the master key is mk = S. say that a polynomial time adversary A has advantage  in solving the BDDH problem if |P r[A(g a , g b , g c , habc ) = KeyGen(mk, σ). true] − P r[A(g a , g b , g c , hd ) = true]| > . First assign the secret value S to the root of the tree. Then, values are assigned to all the nodes in the tree recur- sively as follows: 5. AN ABE SCHEME BASED ON SECRET SHARING • if an OR gate is assigned secret value s, assign the To leverage secret sharing (see, for example [26]) to achieve secret value s to all its children. ABE, we choose a master secret and associate shares of the • if an AND gate with k children is assigned secret value secret with each of the attributes that make up the user’s s, generate k − 1 random values sP 1 , . . . , sk−1 in the set access right. The shares are user-specific to prevent unau- {1, . . . , |G| − 1} and set sk = s − k−1i=1 si mod |G| and thorized users gaining access to documents through collu- assign a secret value si to each child. sion, and are stored in encrypted form to ensure that they can only be accessed when a document with the appropriate When this is done, a key is associated with each leaf of attributes is received. If a document has a set of attributes the tree: a leaf with keyword wi assigned secret value s is that satisfies a user’s access rights, then the user is able associated with a key (d0 = g r , d1 = g s · gir ) where r ← R − to reconstruct the document encryption key (a function of {1, . . . , |G| − 1} (different r for each leaf). The secret key dσ the master secret), and thus, decrypt the document. A key associated with σ is the set of secret keys associated with all point is that as part of the decryption process the shares the leaves of σ. are randomized to be specific to the particular document, so that the ability to access one document doesn’t imply the ability to access others. To summarize, this construction Encrypt(mk, T, M ). R takes as input an arbitrary secret sharing scheme that real- Select r0 ← − {0, . . . , |G| − 1}. 0 0 0 izes a user’s access rights and consists of the following two Compute u = g r , vj = gjr for wj ∈ T and w = h0r · M . components: Return C = (u, {vj }wj ∈T , w). • Generate shares of a master secret: Associate with Decrypt(T, dσ , C). each literal in a Boolean formula, σ, that describes Say C = (u, {vi }wi ∈T , w). the user’s access rights, a share of the master secret, For each leaf in σ that is satisfied by T , associate h = where the sets of shares capable of reconstructing mas- e(u, d1 ) · e(vi , d0 )−1 to the leaf, where (d0 , d1 ) and wi are ter secret is as indicated by σ. respectively the secret key and the keyword associated with • Encrypt shares based on their corresponding attribute: the leaf (note that e(u, d1 ) · e(vi , d0 )−1 = e(g, g)rs where Each share, s, is associated with a literal, Ws , such r = logg u and s is the value associated with the leaf by the that Ws must be present in a document, or document KeyGen algorithm). Then, associate a group element with region, in order for the user to be able to recover a each node in σ that is satisfied by T in a bottom-up fashion randomized version of s. as follows: To demonstrate this construction yields a secure ABE, • if h is associated with one child of an OR node, asso- we provide an instantiation of this scheme using the secret ciate h with the OR node as well. sharing scheme of [2] and prove it secure using the BDDH • if h1 , . . . , hk are associated with each of the k children assumption. Following this we introduce an example using Q of an AND node, associate h = ki=1 hi to the AND another approach to secret sharing that reduces storage for node. certain access rights. In this instantiation, the user access rights are described At the end of this process, the value h = e(g, g)rS = h0r will by boolean formulas σ on the attributes, represented by a be associated with the root of σ (where r = logg u). We can rooted tree2 in which each internal node is either an AND then compute M = w · h−1 . or an OR gate, and the leaves are keywords. We say that a leaf wi is satisfied by a set of attributes T if wi ∈ T , an Theorem 5.1. If the Bilinear Decision Diffie-Hellman prob- AND node is satisfied if all its children are satisfied and an lem is hard, then the scheme above is a secure ABE scheme OR node is satisfied if one of its children is satisfied. The in the selective-set model. tree σ is satisfied if the root is satisfied. If user U is given access σU , then he should be able to read every document Proof. Let A be an adversary that can obtain advantage D whose set of attributes TD satisfies σU .  against the scheme. We show how to use this adversary to build an adversary B that breaks the Bilinear Decision 2 We often abuse notation and denote the tree by σ, as well. Diffie-Hellman problem. Given (g, A = g α , B = g β , C = g γ , Z), algorithm B runs determines whether (g, A, B, C, Z) is a valid Bilinear Diffie- algorithm A on a set of attributes S. A then outputs a set Hellman tuple with probability 1/2 + /2. of attributes T ∗ that he wishes to attack. Algorithm B produces the public key as follows: 5.1 A Variant for Threshold Access Rights Select ω1 , . . . , ωm and ρ at random in {1, . . . , |G| − 1}. As discussed earlier, our ABE protocol leverages auto- For each wi ∈ T ∗ , compute gi = g ωi . mated content analysis in order to achieve content-driven For each wi ∈ S \ T ∗ , compute gi = B · g ωi . access control. In high security applications such as gov- Compute h0 = e(g, g)ρ · e(A, B)−1 (so, implicitly, S = ρ − ernment, it is important to have control over the number of αβ). “false positives” output by the content analysis. For exam- Algorithm B then runs algorithm A with the public key ple, if a government analyst is granted access to all docu- it just produced, and answers A’s queries as follows: ments about “Karl Rove” and the “leak”, it may be impor- tant to ensure that the rights the analyst receives don’t in- – Encryption queries. Those can be answered simply advertently allow access to other documents about Rove, or by running the encryption algorithm with the public key. documents pertaining to other leaks. A common approach to topic detection in content analysis is to identify a set – KeyGen queries. Say A issues a key extraction for of keywords corresponding to a topic [11]. To reduce false the formula σ. Note that T ∗ cannot satisfy σ, otherwise the positives, the user will receive “threshold” access rights that query would not be allowed. B can compute the secret key require ` out of k keywords to be present in order for the corresponding to σ as follows. user to be able to decrypt the document. We briefly present First, assign the temporary key (A, g ρ ) to the root, which a variant of the previous scheme that uses a different se- ‘implicitly’ assign the secret value S to the root. Remember cret sharing mechanism in order to reduce user storage for that ρ = S + αβ. We show how B can compute the secret threshold access rights. keys of all the leaves of a tree rooted at a node that is not satisfied by T ∗ using only an ‘implicit’ description of its secret value s through (dˆ0 = g α , dˆ1 = g s+αβ ): Setup(λ, W). The same as before. • if the tree is rooted at an OR node, then all its chil- dren are unsatisfied by T ∗ , so we can implicitly give KeyGen(mk, σ). them the secret value s by assigning the temporary key Let S be the master secret, and let W1 , . . . , Wk represent (dˆ0 , dˆ1 ) to each of them and computing the secret keys the attributes in σ. Recall that user U has access to any for each recursively. document or document region with ` attributes in the set, W1 , . . . , Wk . Let q(x) be a polynomial of degree ` − 1 over • if the tree is rooted at an AND node with k children, {1, . . . , |G| − 1} and let a1 , . . . , a` ∈ {1, . . . , |G| − 1} be dis- then at least one of its child c is not satisfied by T ∗ . Se- tinct elements. Finally, let r ← R − {1, . . . , |G| − 1}. The secret R lect k−1 random values s1 , . . . , sk−1 ←− {1, . . . , |G|−1} key, dσ , is g r , g q(a1 ) · g1r , . . . , g q(ak ) · gkr , where gi , i = 1, . . . , k and assign a secret value si to each child except for c. are defined as before. The secret keys for the subtree rooted at these nodes can now be computed using the KeyGen P algorithm. Encrypt(mk, T, M ). Then, implicitly pass the secret value s − k−1 i=1 to c by The same as before. Q assigning it the temporary key (dˆ0 , dˆ1 · k−1i=1 g −si ) and the secret keys for the tree rooted at c are computed Decrypt(T, dσ , C). recursively. the user computes e(g q(ai ) · If Wi ∈ {W1 , . . . , Wk } ∩ T , 0 0 0 • if the tree is rooted at a leaf with keyword wi , then by gir , g r )/e(gir , g r ) = hr q(ai ) . If {W1 , . . . , Wk } ∩ T has at 0 design, wi 6∈ T ∗ because the tree is rooted at an unsat- least ` elements, the user recovers hr S using polynomial in- isfied node. Select a random value r̂ ∈ {1, . . . , |G| − 1} terpolation. and put r = r̂ + α. Then the secret key associated to this leaf is (g r , g s+rwi ) = (A · g r̂ , dˆ1 · Aωi · B r̂ · g r̂ωi ). This variant improves on the efficiency of the general con- struction in that user storage is on the order of the number – Challenge query. When A issues two messages M0 , M1 of attributes in σ (as opposed to the number of subformulas on which he wishes to be tested, B first selects a random bit in σ). The proof of security can be adapted to this variant. b ∈ {0, 1}, computes the ciphertext (C, {C ωi }wi ∈T ∗ , (e(C, g)ρ · Finally, we note that a novel secret sharing-based scheme Z −1 ) · Mb ) and returns it to A. Note that e(C, g)ρ · Z −1 = for threshold access rights appears in [25]. The mechanics e(g, g)γS e(g, g)αβγ Z −1 so if (g, A, B, C, Z) is a Bilinear Diffie- of our scheme are a bit different from theirs and these dif- Hellman tuple, this is just e(g, g)γS = h0γ as it should be, ferences allow the above variant to be easily extended to otherwise, it’s just a random element in the group. permit user revocation as described in section 7. Eventually, algorithm A outputs a bit b0 . If b0 = b, B outputs 1, otherwise, B outputs 0. 6. PROTOTYPE SYSTEM If (g, A, B, C, Z) was a Bilinear Diffie-Hellman tuple, then We have implemented a prototype of our content-driven A will guess the correct bit with probability 1/2 + , oth- access control system in Java. Our system assumes that doc- erwise, the distribution of (e(C, g)ρ · Z −1 ) · Mb is indepen- ument regions (e.g. paragraphs or fields in forms) are tagged dent of Mb , therefore, the adversary cannot guess the cor- according to the attributes present (e.g. names, phone num- rect bit with probability more than 1/2. Thus, B correctly bers, etc.). The tags indicate the attributes present and Figure 1: These two screenshots from our prototype system show an unencrypted mortgage application on the left and the same document, with ciphertexts represented by black boxes, on the right. The ciphertexts are generated with our attribute-based encryption scheme, using the attributes, address, name, SSN, phone number and date of birth. Figure 2: The left side of this figure shows the administrator window for defining the Creditor’s access rights at the top and the Creditor logging into the system at the bottom. The right side of the figure shows the mortgage application as it appears to the creditor, the creditor can view SSNs and years of birth, but other sensitive information remains encrypted. their precise location in the document. Location is impor- sensitive portions of documents, and to define access rights tant because the user interface of the prototype represents that allow users selective access to encrypted content. A the encrypted regions as black bars. As much as possible, region can be determined to be sensitive by its associated we size the black bars in a manner that is independent of tags. To illustrate how our tool might be used we discuss two the length of the text they represent, to resist attacks such scenarios. The first concerns processing a mortgage appli- as those described in [20]. cation; the second deals with a company that is attempting Since our focus is on content protection, we will not dis- to satisfy investors while protecting sensitive internal infor- cuss the creation of tags in detail, but we note that there mation. We describe each in turn and provide screenshots exist well-known tools for identifying and tagging sensitive of the tool’s output. information in documents. For example, sensitive content Residential Loan Processing. A typical mortgage ap- may be tagged with tools for extracting patterns and enti- plication is shown in the figure on the left side of figure 1. ties automatically from documents [17], in combination with The application contains several fields with potentially sen- user interface tools for reviewing and manually annotating sitive information, specifically, the applicants’ names, SSNs, documents [3, 4]. addresses, phone numbers and dates of birth. These types Our encryption tools assume a simple XML encoding to of information form the attributes in our attribute-based embed tags in documents. In the demo prototype depicted encryption protocol, that is, a user authorized to view the below, the XML encodings indicating the locations of the phone number attribute will be able to decrypt any phone sensitive attributes in the document are generated manually. number in the encrypted mortgage application. Figure 1 Our access-control system allows a data owner to encrypt shows the unencrypted mortgage application on the left and Figure 3: The left side of this figure shows the administrator window for defining the Clerk’s access rights at the top and the Clerk selecting the mortgage application to decrypt below. The right side of the figure show the mortgage application as it appears to the Clerk. The Clerk can view names and phone numbers, but other sensitive information remains encrypted. Figure 4: The left side of this figure shows the original Enron email in unencrypted form and the right side shows the same email but with external companies and a passage about an asset sale encrypted, as these are potentially sensitive. the encrypted application (using the scheme of section 5) on ated with an access right, as we describe in section 4. the right. The encrypted fields in the form are depicted as On the left side of figure 2 we also show the creditor log- black boxes. Note that any two fields corresponding to the ging in, and on the right side of the figure we show the cred- same type of attribute contain a rectangle of the same size itor’s view of the document. The creditor is able to decrypt to give resistance to attacks that leverage the length of the the SSNs, names and year of birth, but other potentially redaction “bar” to infer the information removed [20]. sensitive information such as addresses and phone numbers, We consider two users and demonstrate how the system remains in encrypted form. ensures each will be able to decrypt the information they Second, we consider a clerk whose job is to follow up with need in the encrypted application, while other sensitive in- applicants after loan approval for quality assurance pur- formation remains encrypted. First, we define a creditor poses. The clerk needs to know the phone numbers and who needs the applicants’ names, social security numbers names of the applicants, but doesn’t need other potentially and year of birth to run a credit check. The left side of fig- sensitive information such as SSNs and addresses. Figure 3 ure 2 shows the window in which the administrator selects shows the clerk user being created and given the necessary the attributes to which the creditor should have access and access rights on the left, and the clerk decrypting the loan creates the corresponding decryption key for the creditor. application with their assigned decryption key on the right. The term “keys” is used in the window because we found it The clerk is able to decrypt phone numbers and names but more intuitive to users to think of each attribute having an not dates of birth, SSNs and addresses. associated key, as opposed to a decryption key being associ- Protecting Corporate Identity. An email from the Figure 5: The left side of the figure shows an investor being given access to asset sale information. The right side shows that the investor can view asset sale information although actual company names remain encrypted. Enron corpus [13] appears in figure 4 on the left side. This are certain to be instances in which it’s necessary to block email provides information about an Enron asset sale that the access of rogue users to new documents introduced to might be important for a company to share with investors the system. Because this may be a rare event we choose as proof that the company is taking the right steps toward not to add user revocation to the existing schemes by as- viability. However, the email also mentions several exter- signing users additional keys based on revocation schemes nal partners who might not have given permission for their such as [22] and encrypting the document ciphertexts ac- names to be released. The right side of figure 4 shows this cording to such a revocation scheme. Rather, we propose a information protected, the company names have been en- heuristic extension to the scheme of section 5 that incurs no crypted and a paragraph that contains information on an additional user storage. asset sale and the purchasing company has been encrypted. We begin by defining our efficient ABE scheme with user Note that the black boxes indicating ciphertexts all have the revocation. An ABE scheme with user revocation consists of same size to resist attacks like those in [20]. the same four algorithms as a standard ABE scheme with the In figure 5 we see an investor user being created and being following differences. The first difference is that we assume given the right to access information about the asset sale that the number of attributes m = |W| is even, and that (but not external company names)3 on the left, and we see every document is tagged with a set T of exactly |T | = the email as it is viewed by this investor on the right. m/2 attributes. We justify these assumptions by noting that Finally, we make some comments about the performance every attribute Wi has a negation Wi . If all attributes and of our code. We have implemented a research prototype their negations are included in W, the set W is of even and have not optimized for speed. The slow part of our im- size m and every document is naturally tagged with m/2 plementation involves pairing computations (using Miller’s attributes (for each attribute, either the attribute itself, or original algorithm). Steps that don’t rely heavily on pairing its negation). computations are relatively fast. For example, generating a user decryption key for 2 attributes averaged 200 ms on an Setup(λ, W, U , v) takes as input a security parameter λ, a iBook G4. In the current prototype, decrypting content can set of attributes W = {W1 , . . . , Wm } where m is even, be quite slow, taking several seconds, however, we expect a set of users U = {U1 , . . . , Un } and an upper-bound that leveraging recent improvements in computing pairings v on the number of users who can be revoked. The (see, for example, [5]) will improve the performance of our algorithm Setup outputs the public parameters and a prototype. master key, (pub, mk). The set W and U must be part of the public parameters. 7. EXTENDING THE ABE MODEL TO USER KeyGen(mk, Ui , σ) takes as input a master key mk, a user REVOCATION Ui ∈ U, and a monotone boolean formula σ over the variables W1 , . . . , Wm and their negations W1 , . . . , Wm , Although revocation is likely to be needed less in the and outputs secret parameters dUi ,σ . document access setting that we consider than in the pay- television setting that motivates much of the existing broad- Encrypt(mk, M, T, R) takes as input a master key mk, a cast encryption and cryptographic revocation schemes, there message M , a subset T ⊂ W of the attributes that 3 Note that NetCo, an organization that was part of Enron, take the value true in the message M such that |T | = is protected along with the external company names. With |W|/2, and a set R ⊆ U of revoked users such that additional content analysis it might be possible to distin- |R| = v (for simplicity, we assume that there are always guish NetCo from the external companies. exactly v revoked users; the introduction of dummy users allows for revocation of fewer than v “real” users). Setup(λ, W, U, v). The algorithm Encrypt outputs a ciphertext C. Say W = {w1 , . . . , w2m } and U = {U1 , . . . , Un }. Let e : G × G → G0 be an admissible bilinear map between groups Decrypt(T, dUi ,σ , C) takes as input a set of attributes T ⊆ G and G0 . Select a random generator g ∈ G and let h = W such that |T | = |W|/2, a secret key dUi ,σ corre- e(g, g). Select a random integer S ∈ {0, . . . , |G| − 1}. Select sponding to a boolean formula σ for user Ui and a ci- a random polynomial p of degree m + v such that p(0) = S. phertext C, and outputs a message or a special symbol Define gi = g p(i) for 1 ≤ i ≤ 2m. Finally, choose a random ⊥. value ui > 2m for user Ui such that ui 6= uj for all i 6= j. The public parameters are (G, g, n, m, v), and the master such that if T satisfies σ and Ui 6∈ R, then we have key is mk = (h, (g1 , . . . , g2m ), (u1 , . . . , un ), p). Decrypt(T, dUi ,σ , Encrypt(mk, M, T, R)) = M. In other words, user Ui can decrypt all documents whose KeyGen(mk, Ui , σ). The key generation is exactly as described in section 5, attributes satisfy the access rights of Ui , provided Ui ’s right except that we assign the secret value g p(ui ) to the root of to decrypt these documents were not revoked. the tree. 7.1 Security Definition Formally, we define the security of an ABE scheme with Encrypt(mk, M, T, R). R user revocation through the following game between an ad- Select r ← − {0, . . . , |G| − 1}. versary and a challenger: Compute u = g r , vj = gjr for wj ∈ T , µj = g rp(uj ) for Uj ∈ R and w = hrS · M . Setup: the challenger runs the Setup algorithm, gives the Return C = (u, {vj }wj ∈T , {µj }Uj ∈R , w). public parameters to the adversary and keeps the mas- ter key to himself. Decrypt(T, dUi ,σ , C). Phase 1: the adversary adaptively issues queries of the fol- Say C = (g r , {vi }wi ∈T , {µi }Ui ∈R , w). lowing types: Exactly as in the scheme described in section 5, user Ui recovers the value g rp(ui ) associated with the root of the • Key query: (σ, Ui ), where σ is a boolean formula tree of the formula that describes Ui ’s access rights. Pro- over the variables in W and their negations and vided C does not revoke user Ui , user Ui now has m + v + 1 Ui ∈ U. The challenger responds by running the values of the form g rp(x) for distinct values x. By polyno- KeyGen algorithm and gives the secret key dUi ,σ mial interpolation, Ui can compute hrp(0) = hrS and recover corresponding to σ for user Ui to the adversary. M = w · h−rS . • Encryption query: (M, T, R), where M is a In the interest of space, we note simply that the variant message, T ⊂ W is a subset of the attributes of section 5.1 can be modified in the same way to achieve such that |T | = |W|/2, and R ⊆ U is a subset of revocation. users such that |R| ≤ v. The challenger responds by computing Encrypt(mk, M, T, R) and giving the resulting ciphertext to the adversary. 8. CONCLUSION We propose a system to protect identity and other sen- Challenge: the adversary outputs two equal length mes- sitive information by controlling access to an individual’s sages M0 and M1 , a subset T ∗ of W such that |T ∗ | = attributes through encryption. |W|/2 and a subset R∗ of U with the following prop- Our system encrypts not only sensitive personal informa- erty: if T ∗ satisfies one of the key queries (σ, Ui ) issued tion, but also groups of personal attributes which may in- in Phase 1, then Ui ∈ R∗ . directly allow for the inference of a person’s identity, even R though none of the attributes is directly sensitive. Personal The challenger then picks a bit b ← − {0, 1}, encrypts ∗ ∗ C ← Encrypt(mk, Mb , T , R ) and outputs C. attributes are encrypted with an attribute-based encryption scheme, which allows for efficient, fine-grained access con- Phase 2: the adversary adaptively issues key and encryp- trol based on the content of documents. In addition, we de- tion queries as in Phase 1, such that all queries (σ, Ui ) scribed a heuristic extension of our encryption scheme which satisfy the following property: if T ∗ satisfies (σ, Ui ), supports revocation of access rights. then Ui ∈ R∗ . The challenger answers these queries as We have implemented and tested our identity protection in Phase 1. scheme. Our prototype implementation demonstrates the usefulness of our scheme in financial and corporate applica- Guess: the adversary outputs a bit b0 . tions. Our tool is broadly applicable for identity protection We define the advantage of the adversary in attacking in other application areas as well, such as the medical and the scheme as in section 4, and say that the ABE scheme legal domains. with user revocation is secure if the adversary’s advantage is negligible. 9. REFERENCES 7.2 An ABE Scheme With User Revocation [1] AreteQ. http://www.areteq.com Our efficient ABE scheme with user revocation is formally [2] J. Benaloh and J. Leichter. Generalized secret sharing defined below. It is a heuristic extension of the scheme of and monotone functions. In Advances in Cryptology – section 5 and is inspired by [23]. CRYPTO ’88, LNCS 403, 27-35, 1989. [3] E. Bier, E. Ishak and E. Chi. Entity Workspace: an [14] D. Ferraiolo and R. Kuhn. Role-based access control. evidence file that aids memory, inference and reading. Proceedings of the 15th National Security Conference, Intelligence and Security Informatics, 2006 1992. [4] E. Bier and E. Chi. Entity quick click: rapid text [15] The 2007 Florida Statutes, 119.0714 Court files, court copying based on automatic entity extraction. CHI records; official records. 2006. [16] A. Fiat and M. Naor. Broadcast encryption. Advances [5] I. Blake, V. Murty and G. Xu. Refinements of Miller’s in Cryptology– Crypto ‘93, pp. 480-491. algorithm for computing Weil/Tate pairing. [17] GATE: General Architecture for Text Engineering. Cryptology ePrint Archive, report 2004/065. http://gate.ac.uk/ [6] D. Boneh and X. Boyen. Efficient selective-ID secure [18] P. Golle. Revisiting the uniqueness of simple identity-based encryption without random oracles. demographics in the US population. In WPES 2006. Advances in Cryptology – Eurocrypt 2004. [19] V. Goyal, O. Pandey, A. Sahai and B. Waters. [7] D. Boneh and M. Franklin. Identity based encryption Attribute-Based Encryption for Fine-Grained Access from the Weil pairing. In SIAM J. of Computing, Vol. Control of Encrypted Data. In ACM CCS, 2006. 32, No. 3, pp. 586-615, 2003. [20] D. Lopresti and A. L. Spitz. Quantifying information [8] D. Boneh, C. Gentry and B. Waters. Collusion leakage in document redaction. In HDP ‘04. resistant broadcast encryption with short cipertexts [21] MortgageGrader. http://www.mortgagegrader.com and private keys. Advances in Cryptology – Crypto [22] D. Naor, M. Naor and J. Lotspeich. Revocation and 2005. tracing schemes for stateless receivers. Advances in [9] R. Canetti, S. Halevi and J. Katz. A forward-secure Cryptology – Crypto 2001. public key encryption scheme. Advances in Cryptology [23] M. Naor and B. Pinkas. Efficient trace and revoke – Eurocrypt 2003. schemes. Financial Cryptography, 2000, pp. 1-20. [10] R. Canetti, S. Halevi and J. Katz. Chosen-ciphertext [24] Redact-It. http://www.redact-it.com security from identity based encryption. Advances in [25] A. Sahai and B. Waters. Fuzzy Identity-Based Cryptology – Eurocrypt 2004. Encryption. In Advances in Cryptology – Eurocrypt [11] F. Chen, A. Farahat and T. Brants. Multiple 2005, pp. 457-473. similarity measures and source-pair information in [26] D. Stinson. Cryptography: Theory and Practice, CRC story link detection. Human Language Technology Press, 1995. Conference, North American Chapter of the [27] L. Sweeney. Uniqueness of simple demographics in the Association for Computational Linguistics Annual US population. LIDAPWP4. Carnegie Mellon Meeting (HLT/NAACL 2004); 2004 May 2-7; Boston; University, Laboratory for International Data Privacy, MA; USA. East Stroudsburg PA: ACL: 2004; 313-320. Pittsburgh, PA, 2000. [12] Y. Dodis and N. Fazio. Public-key broadcast [28] J. Staddon, P. Golle and B. Zimny. Web-based encryption for stateless receivers. ACM CCS inference detection. In USENIX Security 2007. Workshop of Digital Rights Management, 2002. [29] Vontu. http://www.vontu.com [13] Enron Email Dataset. http://www.cs.cmu.edu/ enron/ 3/1/2008 A content- content-driven access control system Jessica Staddon, PARC Philippe Golle, PARC Martin Gagne, U. C. Davis Paul Rasmussen, PARC March 2008 Whose birthday is it? Date of birth + Gender + Location = Identity 3/14/2006 [Sweeney 2000, Golle 2006] Attributes are sensitive 1 3/1/2008 Tie access rights to attributes Document attributes include the document’s content Both documents talk about Plame and Wilson. Leak document talks about Novak and Hadley too. Our approach Automated entity extraction to identify names, places, etc. – text is tagged based on content Sensitivity identification based on the entities – May involve topic detection Document encryption based on content of document – A form of attribute-based encryption This talk 2 3/1/2008 First attempt Associate a key with each possible user access right – User stores a single key corresponding to their access right – Encrypt content with every key corresponding to a satisfying access right – Low user storage, high document overhead “Any content “Any content “Any content “Any content that’s not about Plame about Rove about Rove about Plame and not and not and Plame ” or Rove” Rove” Plame” A second attempt… Associate a key with each set of tags – Encrypt document region with key corresponding to tags that are and aren’t in region – User stores all keys corresponding to sets of tags satisfied by their access rights – Low document overhead, high user storage Plame, Rove, not Wilson User with access to “all content that’s not about Wilson” stores: Plame, not Rove, not Wilson … 3 3/1/2008 Overview of our approach Plame Plame Rove Rove Not Not Create a key for each tag The encryption of a document region is: 1. Encryption of the text under a randomly selected Plame, Rove symmetric key (e.g. AES) AES Encrypted 2. Keys corresponding to tags associated with region Users store AES key encrypted under tag keys – If a region doesn’t have the right tags, the user AES Key won’t be able to recover the AES key and so can’t decrypt the region User with access right “Plame and Rove” stores: A S e E K y AES A Encrypted S+ e E K y Some of the missing details… Randomize the process to make it work more than once! – Document region ciphertext includes randomized versions of keys – AES keys are randomly generated from a base AES key – What users learn from decrypting 1 document region has no impact on their ability to decrypt a 2nd region Regions must have the right tags in order for a user to decrypt 4 3/1/2008 A small example: Set- Set-up Analyst has permission to read anything pertaining to Plame leak – Can read any document pertaining to at least 2 of “Plame”, “Rove”, and “Novak” Initialization: – Groups G and H, each of prime order Generators g and h, respectively – Bilinear map e(.,.): e(g,g)=h – a1, a2, a3, r, r1, r2, r3, random elements in {1,…,|G|-1} – Q(x) a polynomial of degree 1 Let D be a document about Plame and Rove (not Novak) Encryption & Decryption S1 S2 S3 Analyst’s key: gr, gQ(a1)+r(r1) , gQ(a2)+r(r2), gQ(a3)+r(r3) Encryption of D: – gr’ – gr’r1 – gr’r2 AES – EK(D) where K=hr’Q(0) Encrypted Sketch of Decryption: 1. e(gr, gr’ri)=hrr’(ri) 2. e(gQ(ai)+r(ri) , gr’)=hr’(Q(ai)+r(ri)) 3. From 1 & 2, recover hr’Q(ai), for i=1, 2, and use polynomial interpolation to recover K=hr’Q(0) 5 3/1/2008 What have we achieved? Fine-grained, content-driven access control Encryption overhead grows with the # tags – Not with the number of access rights User storage grows with the complexity of the access rights – Not with the number of access rights Secure provided Bilinear Decisional Diffie-Hellman is hard Prototype implementation – Defines access rights in terms of categories of information – Addresses, DOBs, SSNs, Phone Numbers, Company Names, etc. Extensions Can implement any access right expressible as a Boolean formula – E.g. (Plame & Wilson & Novak) or (Plame & Wilson & Libby) Attributes can be metadata (e.g. user-generated tags) in addition to extracted entities Supports revocation as a heuristic extension – Revoked user can’t access new content that matches their old access rights – Idea: Adapt scheme in spirit of broadcast encryption scheme of Naor-Pinkas 2000 6 3/1/2008 Other use cases Mortgage applications – Encrypt the fields of the application according to content type – Appraiser can decrypt address, but not SSNs – Credit checker can decrypt SSNs and not addresses – A single encrypted copy of the document can be maintained Mergers and Acquisitions – Encrypt company records for “virtual data rooms” – Partners access rights change as negotiations progress Can decrypt more and more data Conclusion Even seemingly innocuous attributes can be sensitive when taken together To preserve privacy, access control should be in terms of the attributes of the content Our encryption protocol supports attribute-based access rights 7 3/1/2008 Thanks! 8 Secure Roaming with Identity Metasystems Long Nguyen Hoang Pekka Laitinen N. Asokan Helsinki University of Technology Nokia Research Center Nokia Research Center Finland Finland Finland silver@cc.hut.fi pekka.laitinen@nokia.com n.asokan@nokia.com ABSTRACT other while providing a consistent user experience regardless of The notion of identity metasystem has been introduced as the which identity system is used. means to ensure inter-operability among different identity systems Technically, identity metasystem introduces the concept of an while providing a consistent user experience. Current identity “information card” modeled after a business card, license, badge, metasystems provide limited support for secure roaming: by etc. In general, an information card is a digital representation of “roaming” we refer to the ability of a user to use the same set of user identity. A card may be managed or self-issued. Managed identities and credentials across different terminals. We argue cards are issued by trusted authorities known as identity providers that in order to support different types of roaming, the identity and contain only metadata describing how to get security tokens metasystem client should be structured as a set of distributable from those identity providers. Secret credential needed when components. We describe such distributed client-side software generating authentication token are managed by those identity architecture and how that architecture is implemented by adapting providers. Self–issued cards, on the other hand are managed by Novell’s Bandit project. We use our implementation to users themselves with the help of the local identity system on demonstrate how credentials are stored in a trusted device in the their devices. Secret credential information needed to generate form of a mobile phone but can be used on less trusted terminals security tokens for self-issued cards should be persistently stored in the form of PCs. on user devices themselves (or be provided by the user every time). This leads to the issue of roaming. To illustrate the issue, Categories and Subject Descriptors let us consider the following example scenario: K.6.5 [Management of Computing and Information Systems]: Alice has a number of information cards on her home PC. She Security and Protection, Authentication. uses them to access her web-based emails as well as for other services. When she decides to go on a trip, she loads her information cards on her mobile phone before leaving. When General Terms Alice arrives at the station, she notices some kiosk PCs that she Management, Design, Security, Human Factors. can use to access the Internet. Alice wants to check her mail. Since she is unsure whether the kiosks are trustworthy, she does Keywords not want to transfer all of her self-issued cards to the kiosk Identity metasystem, Mobility, Roaming. machine. Yet, she would prefer to use the kiosk for reading email because it has a convenient display and keyboard. Alice starts up 1. IDENTITY METASYSTEMS the identity metasystem on the kiosk as well as on her phone. They discover each other and establish a secure Bluetooth [10] As more and more transactions are carried out over the Internet, connection. With a single click on her phone, Alice allows her the need for easy-to-use and secure authentication mechanisms information cards to appear on the identity selector user interface becomes increasingly evident. This has resulted in a number of (UI) on the kiosk. When Alice attempts to sign in to her e-mail identity systems intended to save the users from having to create, account, her phone prompts her for authorization instead of asking manage, and use various passwords for different service her to username/password on the terminal. She confirms on her providers. Each of these systems uses different protocols and phone and her mails can then be read on the kiosk as normal. requires different types of user interaction. More recently, the When she finishes her reading, she leaves the kiosk and the notion of Identity Metasystem [1] has gained ground. The main Bluetooth connection terminates. Her information cards, as a purpose of identity metasystem is to put an abstract identity consequence, disappear from the kiosk’s identity selector UI.In management layer on the Internet to allow existing identity this example, although Alice is willing to trust the kiosk as the systems based on various technologies to inter-operate with each means to read her e-mail while she is physically present at the kiosk, she does not want to reveal the keys that can be used by Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are malicious software on the kiosk to access her mail after she has not made or distributed for profit or commercial advantage and that left. copies bear this notice and the full citation on the first page. To copy The most well-known identity metasystems so far are Microsoft otherwise, or republish, to post on servers or to redistribute to lists, CardSpace [2][3][4][5] and the open-source Bandit project [6]. requires prior specific permission and/or a fee. Both CardSpace and Bandit allow the possibility to export IDtrust '08, March 4-6, 2008 Gaithersburg, MD. Copyright 2008 ACM 1978-1-60558-066-1…$5.00. information cards from one device and import them into another but the export/import operation results in the transfer of the entire information card, including the secret credentials that are part of to the RP through the identity selector system to prove the user’s self-issued cards. Currently these systems are unable to support identity to the service. the usage scenario described above. To support such scenarios, the identity metasystem functionality should be split up into parts so that some can stay on a trusted device like the mobile phone, while the others can be migrated to a less trusted terminal temporarily. In this paper, we show that there are different ways to partition the functionality of an identity metasystem thereby allowing two or more devices to co-operate in providing the identity metasystem client functionality. Therefore we argue that in order to realize such scenarios, the identity metasystem client should be structured as a collection of distributable components. In this paper, we propose a distributed software architecture for identity metasystem clients. We also study different ways to distribute client functionality among two or more devices. We then describe how we have implemented our architecture using the Bandit client implementation where one part of the client is running on a PC and the other on a mobile phone. Figure 1: Identity metasystem authentication process The rest of this paper is structured as follows. In Section 2, we give a brief review of the identity metasystems architecture in 2.2 Microsoft CardSpace general and its current realizations. In Section 3, we describe our Microsoft CardSpace [2][5], previously known as InfoCard, is the distributed architecture and discuss different ways to partition the first commercial implementation of the identity metasystem client functionality between two devices In Section 4 we describe concept and the one with the most widespread deployment since it the technical details on how we have adapted the Bandit identity is shipped as part of Windows Vista platform. Figure 2 depicts the metasystem to our architecture to support secure roaming. system architecture of CardSpace. Services or applications on the Finally, in Section 6, we discuss possible extensions and platform trigger CardSpace system via an “activator” conclude. (infocardapi). The core part of the system, the CardSpace service handles all token and management requests, and invokes other 2. IDENTITY METASYSTEMS services such as user interface or low-level storage. However, in the current version 1.0, secure roaming is not possible: in order to 2.1 General Concept use the same information cards on multiple machines, the end The identity metasystem model emphasizes the roles of three key user has to export his information cards to a file (with a .crds agents: the relying party (RP), the identity provider (IdP) and extension) and then import it into the CardSpace system on the identity selector system (ISS). A RP is any system capable of another machine. Although import/export is conceptually simple, authenticating users based on their information cards, it can be a it involves moving all data associated with the card, including program, a web server, or any other service. The user is required sensitive data like credential secrets of self-issued cards. If Alice to prove their identity before accessing to the resource. The IdP, in our example scenario in Section 1 uses CardSpace, she has to as in Kim Cameron’s vision [7], issues information cards to user remember to remove all the cards including the secret data from and provides authentication service. Finally, the identity selector the kiosk before she leaves. Moreover, even if she remembers to is the system that is responsible for handling messages between an do this, she has no way of knowing if her cards and credentials RP and an IdP, and providing a secure mechanism for user to had been copied before they were removed from the terminal. manage their information cards. Figure 1 expresses a simple authentication process in identity metasystem. Whenever a user 2.3 Novell Bandit project wants to access a service (e.g., a web page), the RP offering the Bandit project [6] is an open-source, cross-platform service first sends the security requirements on user implementation of the identity metasystem concept. Technically, authentication it expects to be satisfied (which is stated in RP’s Bandit consists of a set of loosely-coupled identity components policy). On the user’s terminal, the identity selector interface that provide identity services while ensuring both interoperability processes these policies and automatically displays appropriate and collaborations between agents. Figure 3 shows the high-level information cards that satisfy the policies. The user can choose system architecture of Bandit. On the top is the management user one of these cards. It should be noted that, conceptually, an interface, called DigitalMe. The main ISS module handles all information card contains nothing but metadata saying only where requests. Bandit does not only specify and implement the identity and how to retrieve the identity information. Once the user selects selector as CardSpace does but also provides a common a card, the identity selector facilitates the authentication of the framework for easily integrating any digital identity management user to the identity provider (which requires an additional system to Bandit using Higgins framework [10]. Bandit supports authentication mechanism to be specified in the information card. the possibility of using multiple storage providers where For example, this authentication may be based on a information cards and other data used by the client can be stored username/password or a digital signature and certificates) and persistently. Currently it allows the storage provider to be the sends a request for security token based on RP's policies. The IdP local file system, or a Bluetooth-connected storage device, or an verifies the request and issues a security token in return. To online database. As an open source project, Bandit constitutes an complete the authentication process, the security token is passed excellent platform for further development. Identity Selector/Manager UI ISS Remote IdP Higgins Identity Local IdP Attribute Service (IdAS) Card Store Provider LDAP OpenID Other IdP IdP IdP Registry File Bluetooth Store Store Figure 3: Novell Bandit architecture [6] Figure 2: Microsoft CardSpace architecture [5] Self-issued IdP, Remote IdP: The identity provider is responsible 3. ARCHITECTURE OF IDENTITY for managing user’s digital identities in the form of information cards and issuing security tokens on demand. Remote IdP is METASYSTEMS maintained by a well-known, trusted organization while self- 3.1 General Architecture issued IdP is managed locally (in the operating system) by end There is no definitive identity metasystem architecture. In users themselves. As the identity provider maintains all the user general, identity metasystems are expected to follow the credentials, it must be secured. For example, the self-issued IdP principles set out by the “laws of identity” [7]. As we saw in can be protected using end user’s local trusted machine. Section 2, different realizations of the architecture have been implemented. Fortunately, those realizations have similar IdP Authentication: In order to obtain a security token from an characteristics. Figure 4 depicts our own definition of identity IdP, the identity metasystem must first authenticate to the IdP that metasystem architecture. The architecture consists of loosely- is specified in the chosen information card. Authentication coupled identity components with interfaces between them: mechanisms can be based on self-issued card token or other existing authentication technologies such as username/password, Relying Party: the relying party can be considered a “remote” Kerberos [13], or Public Key Infrastructure (PKI)[14], depending component in a whole identity metasystem. In general, a relying on IdP's security policy. In general, this component provides an party is any system hosting some services which require abstract way to authenticate an end user to an identity provider. authentication before being accessed. In the context of identity metasystem, a relying party first publishes its security policy Trigger: The trigger is a “bridge” between identity metasystem - (using [11][12]) then authenticates the user based on a security aware applications and the identity selector system. Whenever an toke-claim assertion. end user accesses a service that supports the identity metasystem, the trigger is used to activate the authentication process by first Identity Selector: The role of the identity selector is to provide a collecting the relying party’s policy, then activating the identity consistent identity management tool for end users. This selector. At the end of the process, the trigger dispatches the component also operates as a contextual connector between security token returned from the identity selector to the relying relying parties and identity providers such that the end user can party. choose which identity provider should be used to authenticate the end user to the particular relying party. Technically, the identity selector requests a security token from the identity provider and then passes that issued token to the relying party according to the information card chosen by the end user. Figure 4: System components and interfaces Figure 5: Configuration 0 – all in terminal Card Storage: Responsibilities of the card storage include information card manipulation, card enumeration as well as 3.2 Distribution of Identity Components filtering possible information cards based on what type identity An identity metasystem, which supports secure roaming, is information is required based on RPs' policies. expected to support various use cases in run time. For example, the end user may use his trusted device as a simple external Credential Storage: The credential storage maintains user’s storage device or a full-featured device including the user credentials including personal information, certificates and other interface interaction to establish the connection to the terminal critical data. In practice, the credential storage and the card where service is consumed. The terminal, in return, should adapt storage are typically combined. For example with self-issued its functionality to different settings according to client profile set cards, metadata and private user information are stored together in on the trusted device. This yields to a technical issue that identity one XML document. metasystem components, not only within a system but also across Every identity component is aware of other components. For distributed systems, should be able to seamlessly cooperate to example, component A may send a request to a specific complete a particular task. We call these use cases component B (unicast) or a group of components (multicast) or all “configurations”. In this section, we list out six typical (broadcast). Here a middleware becomes useful because it configurations together with their strong points and drawbacks. provides a seamless mechanism for inter-component Configuration 0 - "all in terminal": This configuration is the communication. We will discuss more about this in Section 4. simplest configuration in which all identity components are In distributed systems, components should communicate via well- packed in the terminal side. This is also the starting point for defined interfaces. In Table A1, we list some common operations every identity metasystem. Because user’s information is kept in for each interface between the identity components in an identity one place, having the same identity profile on multiple machines metasystem. Figure A1 shows a simplified sequence diagram of securely is not possible. Configuration 0 is on the level of identity component interaction for the scenario described in roaming that is currently supported by CardSpace, i.e., Section 1. The low-level connections between the identity export/import functionality of cards. Although CardSpace allows components are assumed to be established beforehand (implicit user to export all his cards onto an external device and then setting, configuration setting, or dynamic discovery) and secure import them from that device, CardSpace cannot directly use enough. If the transport layer is not secure enough then the cards that are on an external device. security semantic needs to be improved in the application protocol Configuration 1 - "external storage": In this configuration, the layer between the distributed identity components which may be trusted device provides credential storage service and card storage future topics. Interface If and Ip are special in that their binding service. It is more like an external database such as an USB stick protocols are decided on demand: security policy of identity or a smartcard. The advantage of this configuration is that the provider decides the binding protocol of Ip and If. For example, if trusted device does very little processing. It is noted that an IdP states in its policy that it requires username/password communicating channels between the host and the device must be authentication, the identity selector must establish an SSL protected as the self-issued IdP in the terminal accesses directly to connection to the IdP, capture user’s input from If and send those the credential storage component running on the trusted device. credentials through a secure channel over Ip. Alternatively, the However, to gain better performance, we can rely on the security authentication to the IdP can done using a smart card (If) without of the transport protocol being used in Is as long as it is secure having to use SSL connection. Binding protocols for other enough. interfaces are unspecified, they can be RPC [15] calls or SOAP [16] requests or any custom-defined messages. Figure 6: Configuration 1 – External storage Figure 7: Configuration 2 – mobile identity provider Configuration 2 - "mobile identity provider": This configuration Configuration 4 - "all in trusted device": Next natural step is to extends the functionality of the trusted device in configuration 1. have all the components in the trusted device. In this case, the The device can now operate as a self-issued identity provider. The user experience is the same as in configuration 0 except that now self-issued IdP component running on the trusted device is everything is done on the trusted device instead of the terminal. responsible for issuing security tokens when self-issued The difference between configuration 3 and 4 is that the end user information cards are used. The identity selector on the terminal both uses and authenticates to services in the trusted device, and can also use managed information cards and request for security this actually converges to the case where an identity metasystem tokens from remote identity providers over the network as usual. is supported in the trusted device. Although this configuration is This configuration is considerably more secure than configuration the most secure in the context of mobile identity metasystem, it is 1 since the interfaces between the terminal and the trusted device not applicable for every device because of their limited are Ip and Ic and the data transmitted over them is not that capabilities (storage space, memory, processing power, etc.). sensitive. Furthermore, user’s credentials always stay in the trusted device as the credential store component is only accessed locally by the self-issued IdP component that is also residing in the trusted device. One tradeoff is the increase in the resource consumption in the trusted device when issuing the security tokens (including parsing the request from the identity selector component, retrieving corresponding data, generating/signing/encrypting the security token before sending it back to the identity selector component). Configuration 3 - "mobile identity selector": In this case, the trusted device supports built-in identity selector feature. The end user browses and uses services on the terminal but performs all the authentication related operations on his trusted device. Whenever he is asked to prove his identity, the trigger component on the terminal activates the identity selector user interface on the trusted device so that he can choose one of his information cards. This gives advantage and convenience to the end users because they perform all security related operations on their trusted devices (including the authentication related user interface If). This is also a benefit when the terminal itself does not have a Figure 8: Configuration 3 – mobile identity selector proper display, e.g., auto ticket seller or electronic door access. Figure 9: Configuration 4 – all in trusted device Configuration 5 - "external service operator": This is a special Figure 10: Configuration 5 – external service operator configuration which is not possible with current technologies but identity components from the Bandit project to our middleware. we still describe it because it might be an interesting case in Open-source identity components from other identity metasystem future. In this scenario, all of user’s essential data (personal and implementation can also fit into our middleware. Figure 11 shows managed information cards, user credentials, and profile settings) the high-level architecture of our middleware. It is noted that so are stored on a network server; the user device only operates as an far only WS-Trust [18] is supported. Other methods, OpenID [19] access terminal for the end user. We assume that there is an for example, can be added to the system as an extension which external service operator providing personal identity management can be considered in future study. services via (mobile) network. For example, when an end user is accessing a service using his trusted device, the device displays Connectivity Endpoint: Connectivity endpoint is used for his information cards which have been loaded on demand from a transport-level messaging. It is also used for service broadcasting remote server. In the case, if the end user loses his trusted device, and discovery. Our middleware can support various types of he just goes to his personal identity management service, logs in, endpoints (Bluetooth, USB, IP, IrDA, etc.). Each endpoint is and locks his profile usage for the lost device. The lost device controlled by a Session Manager. poses no threat as there is no sensitive information stored on it. Session Manager: This module handles the state of the each session. It maintains a list of connected target devices and their 4. IMPLEMENTATION service profiles. A service profile contains information such as the In the configurations listed in Section 3 there are two connected unique component container identifier, the negotiated systems: one on a terminal and one on a trusted device; each configuration, and the transport media being used. In addition, as system contains some of the identity components (e.g. identity a gateway for all incoming/outgoing messages, Session Manager selector, credential storage) and each of those components are can be a firewall, only allowing a certain set of configured expected to cooperate seamlessly regardless of whether they are operations from certain sources. For example in configuration 2, located in the same platform or distributed across different the trusted device allows only operations defined for Ip and Ic systems. For example, authentication process in section 2.1 may interfaces sent from the terminal. be executed using any of the configurations listed in section 3.2 in Repository Service: This module maintains a lookup table of which one identity component should be aware of others references to identity components. The content of the lookup table components. We have implemented the middleware for enabling is updated when two systems negotiate and configure their service seamless communication between the identity components. The profiles to work together or when a system disconnects. The result is that the main target secure roaming of identity becomes purpose of the repository service is for dynamic communication possible (with configurations 2, and 3). in the case where we do not want to work with fixed, implicit configurations. 4.1 High Level Architecture The main idea is based on the Web Services model [17]. One Component Container: This module wraps identity components identity component hosted by an identity system is considered a that are running on the local system. Each Component Container “service” of that system, and it can be discovered by other is marked with a unique identifier so that one identity component identity components. Components/services communicate using can be identified uniquely among connected systems. For SOAP messages so that they can be implementation language and example one identity component can be addressed using naming platform independent. In this section we propose an extension to convention as follows: Novell’s Bandit project which supports configurations specified “ - ”. in Section 3.2. In our work, we adapt the implementation of - componentX componentY OperationABC ParamsXYZ The Session Manager determines how to reach the target component(s): if the target component belongs to local Component Container, the message is forwarded to that container which hosts the target component. Otherwise, the Session Manager passes the request to its Endpoint to be transferred to the remote system. The Session Manager on the remote machine receives the request from its Endpoint and delivers it to the Component Container hosting the target component. The Figure 11: High-level system architecture container finally passes the request to the target identity component for processing. The response message follows the SOAP Engine: This module encapsulates requests from local same path where the source and target have switched their places. identity components into SOAP requests [16] and parses SOAP The structure of the SOAP response is composed as follows: responses sent from remote identity components. Configuration Profile: This module manages the service profile of the local system. It is useful when there is a need to componentX store/retrieve persistent attributes of the local system (e.g. system componentY identifier). OperationABC Utility Module: The utility module provides some common error_code functions for other modules (e.g. converter, encoder/decoder or file manipulation) as well as basic cryptography functions. ParamsXYZ One user session goes through the following four phases: Phase 1 - Connection setup: Before exchanging messages, the two systems must be able to locate each other and discover their Phase 4 – Session termination: In this final phase, user’s offered services. This phase depends on the discovery mode of metadata information and any temporary data including session user’s trusted device. In active mode, the device broadcasts its information, cache, and history data on the terminal are cleaned profile and users can do pairing using the terminal. In listen mode, up. After the session termination the terminal should turn into its the terminal broadcast its service and users do pairing using the default configuration mode (i.e., configuration 0). trusted device. We assume there are discovery mechanisms that can be used by our system (for example, Devices Profile for Web Services [20]). 4.2 Implementation Environment We have implemented a prototype of our proposed extensions. In Phase 2 - Session initiation: User confirms the connection setup this section we describe the application flow of configuration 2 (either on the trusted device or on the terminal, depending on the (mobile identity provider). On the terminal side, we use the working mode), and optionally enters additional security code or identity components from Novell’s Bandit project (implemented PINs if required. After that, the session manager modules and the in C++ language) and wrap them in our middleware. On trusted repository service modules on both systems are updated so that device side, we decided to use J2ME [21] as a platform. This is identity components can locate the correct target components both an advantage and a challenge since J2ME is widely later. The terminal and the trusted device are now ready to supported on mobile phones but has a limited set of features. We exchange messages. have implemented the identity components for the J2ME environment from scratch, used open-source libraries such as Phase 3 - Message exchange: Before sending out a request kXML [22] for XML document processing and Bouncy Castle message, one identity component queries the Repository Service [23] for cryptographic operations. module for the target components and forms the request to be sent to the local Session Manager. The structure of the SOAP request is composed as follows: explicitly declared trusted by the end user in configurations where Ic is a cross-system interface (configuration 2 for example). When a relying party asks for a security token, Bandit's DigitalMe user interface on the terminal collects RP's certificate, policies, and requested claims. If the security token specified on RP's policy is expected to be from a managed identity provider, the authentication process is done normally as described in [3]. If the token is expected to be self-issued, the identity selector component constructs a request and sends it to the self-issued IdP component on the trusted device using our middleware. Once the self-issued IdP component receives the request, it generates a SAML token [25] with relevant attribute values extracted from the card store on the trusted device through Is. The security token is signed with a RP specific private key and encrypted by the public key of the RP before sending it back to the terminal and subsequently passed to the RP. Figure 12: Bandit implementation As described above, although the role of the trusted device in the authentication process is important, its functionality is quite Let us start with the current implementation of Bandit project. simple. Most of complex processing including collecting Figure 12 shows Bandit’s high-level design. The main module ISS certificate, user interface and service execution are done in the loads complete set of available i–card documents [24] from the public terminal. The heaviest processing is to generate a specific Store Provider through Ic’. To get a self-issued token, the selector RP-card key pair. Ideally, it should be done in the IdP in the passes an i-card object together with other parameters to the self- trusted device. However, if the trusted device has limited issued IdP module. This design causes security problems when we computational power, RP-specific key pairs may be generated on move to distributed environment because the identity selector has a trusted terminal. Each RP specific key pair needs to be access to all secret information and keeps the loaded i-card object generated only once and transferred to the trusted device. One in memory. Besides, we have observed that the card enumeration way to store the generated key pairs for later use is to put them in is only needed in 3 cases. The first one is when populating and a new XML extension of the i-card format to store private data. displaying user’s information cards, which only needs card’s metadata such as name, id, and picture. The second case is to import/export cards and this should be done directly from the 5. CONCLUSION storage component instead of selector component. The last case is The notion of using a trusted device to secure transactions on a to get the claim values and secret data in order to generate a self- less trusted terminal is well-known [27][28][29] . However, these issued security token. In this case, the self-issued IdP should have methods propose their own protocols/frameworks, making it a direct and secure channel the credential store to access user’s difficult to interoperate with other identity systems. The private data (Is in our design). distinguishing feature of our work is that we have shown how an existing identity metasystem can be extended to support the use of Therefore, we have made changes to Bandit’s components and a trusted terminal. Our contribution is two fold: (1) specifying the wrapped them in our architecture as described in 4.1. Table A2 architecture for identity metasystem implementation that makes it compares the changes between the Bandit implementation and our easy to distribute identity components; and (2) using (1) to current implementation. implement a two-device configuration which enables digital identity roaming across security domains. To summarize, we are In configuration 2, the user’s information cards (self-issued or able to move to the next level of current dimension of identity managed) are stored as i-card documents on the trusted device metasystem [30]. In our current work, we are planning to extend side. Ic-operations which involve card enumeration now only our implementation to support configuration 3 (mobile identity work with the metadata. We have defined some filtering rules to selector) and configuration 4 (all in mobile device) on various be used by Card Storage component to expose only metadata part types of devices. We plan to support not only J2ME platform but of information card content (denoted by i-card* in Table A2). also the Symbian operating system [26] because Symbian When the trusted device connects to a public terminal, only the provides a strong platform for security processing plus a very public portion of i-card structure is transferred to the terminal so good native user interface. In addition, we are developing that end user can use their information cards on the terminal mechanisms for securing inter-component communication which identity selector. The main idea is to give only non-sensitive can be used instead of or in addition to any transport-level secure metadata section of the i-card document to the terminal and let the communication mechanisms. We also intend to study the usability terminal provide the user interface functions. All “metacards” and and system performance aspects with the intention of improving other temporary data such as history, cache, session on the the overall user experience. The final target is to give the end terminal will be deleted when the trusted device disconnects. users better security and richer user experience. For the addCard, editCard and removeCard operations, in the current implementation we assume that user can only add or edit cards from a trusted terminal like a home PC (or on the trusted device itself). These operations require that the terminal has been 6. REFERENCES [15] Sun Microsystem. Remote Procedure Call. Request for [1] Microsoft organization. Microsoft’s Vision for an comments 1831. August 1995. Identity Metasystem. Microsoft Whitepaper, May http://tools.ietf.org/html/rfc1831 2005. http://msdn2.microsoft.com/en- [16] W3C Working Group. Simple Object Access Protocol us/library/ms996422.aspxhttp://zoo.cs.yale.edu/classes (SOAP). http://www.w3.org/TR/soap/ /cs457/tsui_digital_identity_management.doc [17] W3C Working Group. Web Services Architecture. [2] David Chappell. Introducing Windows CardSpace. February 2004 http://www.w3.org/TR/ws-arch/ Windows Vista Technical Articles, April 2006 [18] OASIS. WS-Trust Version 1.3. March 2007 http://msdn2.microsoft.com/en- http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws- us/library/aa480189.aspx trust-1.3-os.html [3] Arun Nanda, Microsoft Corporation. Identity Selector [19] OpenID community. OpenID Authentication 2.0 - Interoperability Profile V1.0 April, 2007 Draft 11. 2007. http://www.openid.net/specs/openid- http://www.microsoft.com/downloads/details.aspx?Fa authentication-2_0-11.html milyID=B94817FC-3991-4DD0-8E85- B73E626F6764&displaylang=en [20] Microsoft organization. Devices Profile for Web Services February 2006 [4] Michael B. Jones. The Identity Metasystem: A User- http://schemas.xmlsoap.org/ws/2006/02/devprof/ Centric, Inclusive Web Authentication Solution. W3C Workshop on Transparency and Usability of Web [21] Sun Microsystem. Java 2 Platform, Micro Edition Authentication. New York City, March 2006 (J2ME). Java ME homepage http://java.sun.com/javame/index.jsp [5] CodeIdol.com. InfoCard Architecture and Security http://codeidol.com/csharp/indigo/InfoCard/InfoCard- [22] kXML A small XML pull parser Architecture-and-Security/ http://kxml.sourceforge.net/kxml2/ [6] Novell corp. Bandit project [23] The Legion of the Bouncy Castle. Bouncy Castle Java http://www.bandit- cryptography API project.org/index.php/Welcome_to_Bandit http://www.bouncycastle.org/java.html [7] Kim Cameron. The Laws of Identity. Microsoft [24] Information card format Whitepaper, May 2005. http://en.wikipedia.org/wiki/I-Card http://www.identityblog.com/stories/2004/12/09/thela [25] OASIS. SAML Token Profile Version 1.1. February ws.html 2006 http://docs.oasis-open.org/wss/oasis-wss- [8] Microsoft organization. Windows Data Protection. SAMLTokenProfile-1.1 Microsoft MSDN, 2001. [26] Symbian Ltd. Symbian OS 2003 http://msdn2.microsoft.com/en- http://www.symbian.com us/library/ms995355.aspx [27] B. Parno, C. Kuo, and A. Perrig., Phoolproof phishing. [9] Higgins Project. Higgins home page In Proceedings of Financial Cryptography and Data http://www.eclipse.org/higgins/ Security 2006, Lecture Notes in Computer Science [10] The Official Bluetooth® Technology Info Site 4107, Springer. http://www.bluetooth.com/bluetooth/ [28] M. Mannan, P.C. van Oorschot, Using a Personal [11] Web Services MetadataExchange. August 2006. Device to Strengthen Password Authentication from an http://schemas.xmlsoap.org/ws/2004/09/mex/ Untrusted Computer. In Proceedings of Financial Cryptography and Data Security 2007. [12] Web Services Policy Framework. March 2006. http://schemas.xmlsoap.org/ws/2004/09/policy/ [29] D. Balfanz, E. Felten, Hand-held computers can be better smart cards. In Proceedings,8th conference on [13] Massachusetts Institute of Technology. Kerberos: The USENIX Security Symposium - Volume 8, 1999. Network Authentication Protocol http://web.mit.edu/Kerberos/ [30] Axel Nennker. The CardSpace dimensions. Published on Ignisvulpis’s blog June 2007. [14] Internet X.509 Public Key Infrastructure Certificate http://ignisvulpis.blogspot.com/ and Certificate Revocation List (CRL) Profile. RFC 3280. April 2002. http://tools.ietf.org/html/rfc3280 APPENDIX a) User adds a self-issued card b) User adds a managed card c) User interface of identify selector populates list of information cards d) User picks a card Figure A1: Interaction between identity components Table A1: Interface operations Interface Operation Input Output Description Ip getSecurityToken token type , display token, Get security token from identity provider relying party, security token credential 1 required claims optional claims 2 Ic getFirstCard N/A i-card* 3 Get first card from store 3 getNextCard N/A i-card* Get next card from store 3 getCard N/A i-card* Get specific card from store addCard i-card 4 card ID Add one card to store 4 editCard card ID, i-card N/A Modify one card removeCard card ID N/A Delete one card from store Ir activateSelector x-informationCard security token Browser extension HTML parsing It getToken token type , security token Get security token from selector then pass it relying party, to relying party. required claims optional claims manageCards N/A N/A Open selector’s user interface for card management If getCredential N/A credential Obtain credential from user to authenticate to IdP Is getUserPrivateData card ID private data Manipulate claim values and other info such as key-pair, master key, PIN. addUserPrivateData card ID, N/A private data editUserPrivateData card ID, N/A private data removeUserPrivateData card ID, N/A private data type In getCardContent card ID i-card4 called when exporting cards addUserPrivateData card ID, N/A called when importing cards, adding private data personal cards editUserPrivateData card ID, N/A called when edit personal cards private data removeUserPrivateData card ID, N/A private data type 1 Credential being used to authenticate to identity provider 2 Optional claims which are selected to be send by end user. These claims are subset of optional claims stated in RP’s policy 3 i-card* denotes filtered i-card document with only public metadata section 4 i-card denotes full i-card document Table A2: Comparison of Bandit implementation and our implementation Interfac Bandit implementation Our implementation Operation e Input Output Input Output Ip getSecurityToken token type , display token, token type , display token, i-card, security token i-card*, security token relying party, relying party, credential credential required claims required claims optional claims optional claims Ic getFirstCard N/A i-card N/A i-card* getNextCard N/A i-card N/A i-card* getCard card ID i-card card ID i-card* addCard i-card card ID i-card card ID editCard card ID, i-card N/A card ID, i-card N/A removeCard card ID N/A card ID N/A It getSecurityToken token type , security token token type , security token relying party, relying party, required claims required claims optional claims optional claims manageCards N/A N/A N/A N/A If getCredential N/A credential N/A credential Is getUserPrivateData addUserPrivateData editUserPrivateData removeUserPrivateData In getCardContent addUserPrivateData editUserPrivateData removeUserPrivateData Require access control for cross device boundaries. Haven’t been implemented yet. In current implementation, Is and In-operations are replaced by getCard, addCard with full i- card document Secure Roaming with Identity Metasystems Long Nguyen Hoang, Helsinki University of Technology *Pekka Laitinen, Nokia Research Center N. Asokan, Nokia Research Center IDTrust 2008 1 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 2 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 3 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen What is identity metasystem? • provides abstract identity management layer • allows inter-operability between different identity systems Relying Party 2. • provides consistent user experience Relying party’s security policy • introduces information cards Policy 3. UI display appropriate cards Access 1. resource • existing implementations 4. User picks 7. Token is presented • CardSpace by Microsoft a card 6. Token is • DigitalMe by Bandit project created 5. Authenticate and request for security token Identity Provider IDTrust 2008 4 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 5 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Why do we need roaming? How may different devices do you use to access Internet services? trusted mobile Alice’s phone laptop PC at home library PC Bob’s PC PC at work internet café laptop your own devices friend’s devices public devices You want to use your information cards in all of them ! IDTrust 2008 6 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Solutions for roaming, part 1 Existing solution: export/import information cards • bad security: requires trusting all classes of devices at same level • bad usability: export-import-remove cards IDTrust 2008 7 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Solutions for roaming, part 2 Potential solution: smart card or any removable hardware token • good security: can manage different trust levels between device classes • good usability: insert smart card to PC and information cards become available • bad security: no user interface on smart card • just bad: need extra hardware IDTrust 2008 8 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Solutions for roaming, part 3 “The right solution”: mobile phone as personal trusted device • good security: can manage different trust levels between device classes • good usability: connect phone to PC and information cards become available • good security: has user interface • just good: everybody has mobile phone IDTrust 2008 9 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 10 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen General architecture of identity metasystems Relying IdP Remote Party Authentication IdP Ip Ir If It Identity Ip Self-issued Trigger selector IdP Ic Is Card Storage In Credential Storage IDTrust 2008 11 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Distribution of components Relying Remote Party Ip IdP Ir Trigger IdP Authentication It If Identity Ic Card selector Storage Ip In Self-issued Is Credential IdP Storage Terminal Trusted Device Configurations 0: Configuration 1: All in one device External storage IDTrust 2008 12 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Distribution of components, continued Configuration 2: Configuration 3: Mobile identity provider Mobile identity selector IDTrust 2008 13 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 14 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Distributable system architecture IdP Session Trigger Authentication Manager Bluetooth Endpoint Card Identity Storage selector Repository Service USB Self-issued Credential Endpoint IdP Storage SOAP Engine Component container IrDA Endpoint Util Security Configuration Module Module Profile IDTrust 2008 15 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Implementation • Configuration 2 has been implemented • Middleware • allows distribution of components • components are loosely coupled • SOAP messaging between components • DigitalMe (modified from version 0.4.1309) on Linux • BlueZ Bluetooth driver • Java ME (MIDP 2.0) on mobile phone • Bouncy Castle’s crypto library • kXML for XML processing • Connection endpoints • Bluetooth • IP IDTrust 2008 16 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Example sequence flow 1. RP sends its policy. 2. Trigger forwards RP’s policy to Selector. Relying IdP Remote Party Authentication 3. Selector fetches card metadata from Card IdP Storage and displays them in Selector’s UI. 11 Ir Ip If 4. User selects a card. 1 4 2 5 6 5. Security token is requested from Self-issued It Ip IdP. Trigger Identity selector Self-issued IdP 6. User is asked to approve security token 10 9 8 request. 7. IdP requests credentials from Credential Ic 3 Is Storage. 7 8. Credentials are returned; IdP generates RP Card Storage In Credential specific key pair and creates security token. Storage 9-11. Security token is forwarded to RP. PC mobile phone IDTrust 2008 17 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Implementation issues Relying Party IdP Authentication Remote IdP Issues with DigitalMe: Ir Ip • Components are tightly coupled (ISS and If ISS store provider) It Identity Ip Self-issued Trigger selector IdP • ISS handles master key and RP specific key pair generation (master key sent over Ic’ Ic Ic’ Is interface) Card Storage In Credential Storage ÆWe adapted DigitalMe to our distributable architecture Store Provider Issues with mobile phone: • RSA key generation takes time Æ RP specific key pair should be stored to avoid unnecessary regeneration IDTrust 2008 18 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Outline What is identity metasystem? Why we need roaming? Roaming configurations Implementation Conclusion IDTrust 2008 19 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Conclusion designed and implemented architecture that enables distribution of identity metasystem components to two (or more) terminals Alice’s laptop manage & home use cards use cards PC use cards PC at internet café IDTrust 2008 20 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Thank you! Questions? IDTrust 2008 21 © 2008 Nokia SecureRoaming.ppt / 2008-03-04 / Pekka Laitinen Secure communication for ad-hoc, federated groups Andreas Sjöholm Ludwig Seitz Babak Sadighi Swedish Institute of Computer Swedish Institute of Computer Swedish Institute of Computer Science, Box 1264, 164 29 Science Science, Box 1264, 164 29 Kista, Sweden Box 1263, SE-16429 Kista, Kista, Sweden Axiomatics AB, Electrum 223, Sweden Axiomatics AB, Electrum 223, 164 40 Kista, Sweden ludwig@sics.se 164 40 Kista, Sweden andreas@axiomatics.com babak@axiomatics.com ABSTRACT tual Organisations became increasingly popular, a new as- Ad-hoc federated groups are getting increasingly popular as pect of information sharing got into the focus of attention: means of addressing collaborative tasks that require infor- cross-organisational, ad-hoc collaborations. Today clients mation sharing. However, in some application scenarios, the for such applications include the scientific community, busi- security of the shared information is vital. Managing the ness and the military. Even other public organisations (e.g., communication security of such groups in an efficient way is health-care, firefighters, police) are increasingly interested in a difficult task. tools facilitating ad-hoc collaboration for achieving common This paper presents an architecture that enables secure goals. communication for ad-hoc, cross-organisational groups. Our As an application scenario, imagine the occurrence of a architecture covers group admission control, group key man- major traffic incident on a major public road. Several ve- agement and secure group communication. The groups in hicles are involved in a pile-up, including trucks with dan- question are expected to be ad-hoc groups where the po- gerous chemicals. The harsh weather is complicating the tential participants have no prior knowledge of each other rescuers work. A police car is quickly on site followed by and thus federation mechanisms need to be used to establish additional rescue workers such as ambulances and firefight- group admission rights. In order to handle group admission ers. we use the SAML and XACML standards, for group key It soon becomes apparent that many other public and management we use the TGDH protocol. Our approach thus governmental authorities and agencies such as the road ad- supports decentralised management of the most important ministration authority, the national meteorological institute, tasks in secure group communication using an integrated a foreign embassy and the hazardous materials unit must be approach based on established security standards. We have involved as their competence are necessary or they need to also produced a demo implementation to show the feasibility be informed. These actors need to share information, coor- of our architecture. dinating their efforts and avoiding fragmentation. This research was pursued as part of the TrustDis project Such ad-hoc collaborations are expected to work without funded by the Swedish Governmental Agency for Innovation extensive infrastructure and formation should require min- Systems (Vinnova). imal set-up time by being parallel to informing a group of actors. This type of collaborative group can be expected to accommodate for several hundreds of users spread amongst Categories and Subject Descriptors different organisations with little or no knowledge of each K.6.5 [Management of Computing and Information other except for a goal or interest in common. Systems]: Security and protection Frequently, information sharing in such heterogeneous groups is subject to security related questions such as confi- Keywords dentiality and integrity. While these questions have clear so- lutions in client-server and even decentralised architectures, Access Control, Tree-based Group Diffie-Hellman, Secure implementing the same solutions for ad-hoc groups without Group Communication loosing the advantages of ad-hoc group collaboration is far from obvious. 1. INTRODUCTION The lack of a controlled infrastructure and a central au- The core concept of the Internet has always been to share thority in an ad-hoc collaborative environment makes it dif- information distributed among different locations. As Vir- ficult to maintain both security and manageability. Who can join and be part of a collaborative network? How can sensi- tive information be exchanged in a group of mostly unknown members? How can a user, away from his home network, be Permission to make digital or hard copies of all or part of this work for authenticated? Who enforces the rules of the network? How personal or classroom use is granted without fee provided that copies are can administration be kept manageable under such circum- not made or distributed for profit or commercial advantage and that copies stances? bear this notice and the full citation on the first page. To copy otherwise, to A solution which addresses the questions above, applica- republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ble to large ad-hoc groups, is needed. This paper presents a IDtrust ’08, March 4-6, 2008 Gaithersburg, MD novel architecture that deals with the problems of authori- Copyright 2008 ACM 1978-1-60558-066-1 ...$5.00. sation, authentication, confidentiality as well as availability • Full representation of the group: All members shall in such groups. have a complete, consistent representation of the group The rest of this paper is structured as follows: In section and its members. 2 we define the problem at hand. Section 3 presents related work. In section 4 we present our architecture designed to • Distributed functionality: It must be possible to dis- solve the problems. Our demo implementation of the ar- tribute functionality (such as PDPs), thus preventing chitecture is presented in section 5. We then discuss the single points of failures. advantages and drawbacks of the architecture in section 6. • Implementation of leader role with possibility of dele- Finally we summarise, give a conclusion and point to future gation: A group leader shall exist with the role of cre- work in section 7. ating the policies that regulate group admission con- trol. It shall be possible to issue constrained delega- 2. PROBLEM STATEMENT tions of this role. The two main problems we face with respect to secure • Fault tolerance and self healing: Link disruption must group communication are[1]: not jeopardise the security and operability of the group more than that the functionality can be restored when • Who may join the group? the link is restored. During disruption when members are lost or cut off from each other, the group must be • How can the group members share cryptographic keys functional as partitioned and autonomous groups. in order to ensure confidentiality and message integrity? Summarising one can say, that the problem is to find an A sensible solution to the first problem is a combination architecture that is able to solve all of these problems in an of federated identity management and a policy based access integrated, efficient, and decentralised way. control system. This requires a Policy Decision Point (PDP) which issues access control decisions, Policy Enforcement Points (PEP) that enforce the PDP’s decisions, and Policy 3. RELATED WORK Information Points (PIP) that provide and the policies used We present related work in the areas of group key agree- by the PDP [14]. The federated identity management sys- ment schemes and of group admission control. Further we tem is needed in order to provide certified information about present related work that combines both to create secure the user (e.g., roles, affiliations, qualifications) to the PDP. group communication solutions. jj A large number of group A common solution to the second problem are group key key management systems use trusted third parties (TTPs) agreement schemes that allow all participants of the group to distribute the keys to the group members (e.g., [10, 15]). to compute a common group key. Such a scheme needs to The use of a TTP greatly simplifies key management and provide new group keys to the members in reaction to the update issues, due to the centralisation. However, the cen- following events [9]: tralisation also disqualifies such schemes for our application scenario (we further discuss this in subsection 4.1). • Single member join: A new member joins the group. In the area of contributory group key agreement schemes, the Tree-based Group Diffie-Hellman (TGDH) protocol by • Single member leave: A current member leaves the Kim, Perrig, and Tsudik [9] is an approach that fulfils our group. requirements. Therefore we choose it as component of our architecture. • Group merge: Two groups merge into one. Furthermore the Dynamic SubTree (DST) group key agree- • Group partition: A group is split into new groups. ment scheme by Mao et al. [11] could be considered, since its average time cost is less than TGDH’s. However, DST In order to be cryptographically secure, the key agreement uses the unrealistic assumption that group member depar- scheme needs to fulfil the following cryptographic require- ture times is known in advance. ment [9]: Another promising approach is the PFMH tree based con- tributory group key agreement protocol suite (PACK) by Definition 1. Key Independence: Yu, Sun, and Liu [16]. PACK seems to have better theo- Assuming that the key agreement scheme has produced retical performance than TGDH for single user join, while the sequence of keys K = {k1 , k2 , k3 , . . . , km } in reaction to the author’s simulation results suggest worse performance a sequence of group events. for single user leave. A passive adversary who knows a proper subset of group Kim, Mazzocchi, and Tsudik propose a number of ap- keys K  ⊂ K cannot discover any other group key ki ∈ proaches for admission control in peer groups [8]. The pa- (K \ K  ). per’s main focus is on admission by voting whereas the use of access control mechanisms is limited to Access Control This requirement also ensures that a new group member Lists. can not decrypt any of the messages sent before the join The commercial product MindAlign from Parlano adver- event, and an ex-member can not decrypt any messages sent tises secure communication for federated groups. No de- after the leave event (Forward and Backward Secrecy). tailed information on the technical details could be obtained1 . Secondary problems that need to be addressed are: 1 Actually since Parlano has been acquired by Mi- crosoft, there is no information at all available from • Scalability: The group communication architecture must the Parlano website, our main source of information was scale well with the number of users. http://en.wikipedia.org/wiki/MindAlign. Judge and Ammar propose a Group Access Control Ar- ing XML. chitecture for Secure Multicast and Anycast [7]. This ar- Another determining factor in our choice of XACML is the chitecture provides group policy management, member au- fact that the upcoming version 3.0 of XACML [13] has sup- thorisation and group key management. However, their key port for delegation, a feature that is very important for our agreement scheme is not key independent. Moreover, the ac- decentralised group management approach. The delegation cess control engine used in this architecture is not further mechanism allows authority holders to delegate a precisely specified. constrained part of their authority to others, thus facilitat- Agarwal et al. suggest an integrated solution for secure ing decentralised administration, without the risk of giving group communication [2]. This approach uses GDH, the pre- away too much authority. decessor of TGDH for group key agreement. Furthermore Using these delegation features, the broad access control the non-standard access control system Akenti is used to de- policies for group communication can be specified by a co- termine group admission. Sine work both on this approach ordination authority, while power to create fine-grain autho- and on Akenti appears to have ceased (last update of Akenti risations (e.g., for specific subjects) can be delegated to the was 2005), this does not seem like a promising candidate for organisations participating in the group. solving our problem. Using SAML [4] as assertion language for supporting fed- We can therefore summarise, that a number of promising erated identity is an obvious choice when combined with approaches for contributory group key agreement schemes XACML. In order to evaluate a specific request, an XACML exist. Their main difference lies in the performance opti- PDP needs to establish an evaluation context. This includes misation of specific group events. Thus alternative schemes collecting attributes for the subject of the request. Provid- can be investigated, should future experiments indicate per- ing such attributes in a secure way is a typical application formance problems with our TGDH based approach. for SAML. As for comprehensive architectures including group ad- Having chosen SAML as syntax and protocol suite for at- mission control, related work seems to either rudimentary tribute assertions, an Attribute Authority (AA) is needed to or based on outdated, non-standard access control technol- generate the SAML assertions and to manage the federation ogy. of attributes. The Assertion Server4 is a system closely inte- grated with XACML 3.0 and SAML. It’s main function is to provide attribute assertions and to manage attributes. Be- 4. SECURITY ARCHITECTURE sides this the Assertion Server handles attribute hierarchies, In this section we present our architecture for secure group delegation of attribute authority and parallel administration communication TgdhXacml and explain some of the choices of multiple sources of attribute authority. It can be queried we made. according to the protocol defined in the SAML V2.0 [4] stan- dard. 4.1 Contributory key schemes versus TTPs Internally it uses XACML policies to represent attribute As we pointed out in section 3 our main problem with value assignments (including attribute hierarchies) and at- TTPs is their centralisation. Setting up a TTP and recon- tribute authority (including authority delegation), however figuring it when the group structure changes drastically, is a user never needs to see these internal policies. bound to introduce delays in availability. Using the Assertion Server, a PDP can gather all neces- TTPs availability can also become problematic when the sary attributes in order to evaluate a request. Multiple As- number of users increases dramatically, furthermore the TTP sertion Servers can serve one PDP and one Assertion Server can be a single point of failure and therefore a prime target can serve multiple PDPs. for attacks. Finally the use of a TTP raises the question Figure 1 shows an example set up with a policies and some of who should provide and maintain this service, which can attributes provided externally by an Assertion Server. All increase the level of distrust between group members and XACML policies have been greatly simplified to make them thus limit the information they are willing to provide. All less verbose. In our application scenario from the intro- these points speak against using a TTP in our ad-hoc, feder- duction, a crisis coordinator has the authority over a group ated group scenario. Therefore we have not considered TTP resources allocated to the incident, which has been named based key management systems for our approach. Incident23. He issues a root policy delegating authority over these resources to the Police board, however the authority 4.2 XACML and SAML constrains the possible subjects to members of the police When choosing systems for authorisation and for support- force (Delegated Subject must have organisation = Police). ing federated identity, our main objective was to use widely Alice who is a member of the police board, coordinates the accepted standards. This choice stems from the facts that a police operation. In the second policy, she allows Bob who range of different actors have to interoperate and to agree on is the policeman on site to access said resources. In order a common authorisation model as well as both a direct (cor- to be valid, this policy needs to be supported by the root porate’s policy) and a indirect (through SOX2 ) requirement policy. This is the case, since the Assertion Server confirms to exclusivly use open standards. both that Alice has the role = Police board attribute and XACML [6] is a widely accepted access control standard Bob has the organisation = Police attribute. with good support both from the industry and the scientific community [3]. Furthermore a range of useful support tools 4.3 Architecture are available both specifically for XACML3 and for process- We now proceed to tie together the different components 2 of our approach into an integrated architecture. The in- Sarbanes-Oxley Act 3 4 see: http://www.oasis-open.org/committees/xacml under Available from: the heading Additional Information http://www.sics.se/spot/assertion server.html This could be made voluntarily by asking a member to take responsibility for lowering the workload on a stressed member or to start up dummy members that do not participate in the group communication and just provide additional services. • Synchronisation of policy and assertion databases Since it should not make a difference which PDP or Assertion Server a member is using, databases con- taining attribute and policy information must be syn- chronised. An approach would be to use a replicat- ing database server. If the underlying distributed net- work layer supports data replication this feature can be used. • Communication security The context handler gets provided with a group master key from the TGDH layer which allow it to encrypt and decrypt messages. The group master key is used as seed go generate an AES-256 content encryption key (CEK). Thus even if a CEK is compromised, the current group master key remains secure. Our TGDH layer also provides DSA keys for all group members, which are used for digital signatures. DSA has been chosen for message authenticity instead of a MAC algorithm because DSA is asymmetric and thus the DSA public key can be sent in clear text together with the join group request. The raw data communication protocol for the group is Figure 1: Example for a delegation and related at- managed by the network layer. tribute assertions provided by an Assertion Server. • Implement API As the TgdhXacml provides no user functionality, ap- tegrating component deployed with all group members is plications are to be plugged in on top of the TgdhX- called the context handler. The purpose of the context han- acml. This can be any kind of service that provides or dler is to coordinate information and integrate the services retrieves information. needed for TGDH and XACML in a ad-hoc environment. This means that a group member’s context handler must Figure 2 shows an example layout of the TgdhXacml ar- implement the following functionality: chitecture for a group with four members. Every member Mi has a context handler, coordinating the other modules. • Locate information for XACML contexts All members are also running the TGDH protocol and a The most important functionality of the context han- PEP. Additionally some members are running applications, dler. TgdhXacml stores a list of addresses where cer- PIPs and Assertion Servers. tain information and services can be found in the dis- In the example the members M 1 and M 3 provide an As- tributed group (such as PDPs and Assertion Servers). sertion Server. The Assertion Server’s attribute database The TgdhXacml context handler uses these addresses needs to be synchronised between these two members. Mem- to provide the access control component with addi- bers M 2 and M 4, both provide a PIP, therefore the policy tional information (e.g., policy databases, assertion server database must also be synchronised. The top level of the locations). architecture is the application layer. • Respond to queries about the TgdhXacml environment Observe that member M 3 is not running any application, All members in the group should have the same in- which implies that M 3 is a virtual member that was only formation about services and newly joined members set up to lower workload of the other members and increase need to be updated on this knowledge. Therefore the availability of the attribute database. context handler must be ready to provide the TGDH sponsor with information about the environment, such 4.4 Authentication as lists of PDPs and Assertion Servers. Since all Diffie-Hellman offspring lack authentication and are susceptible to active attacks (such as man-in-the-middle • Start up (additional) PDPs and Assertion Servers attacks), TgdhXacml needs a mechanism to authenticate Upon creation of the group the group leader’s context group members. This authentication is to provide a unique handler starts up one PDP, one Assertion Server and identifier that can be used to bind attribute assertions to one PIP and publishes this information in the list of specific group members. available services. Other members can later start ad- In order to prevent man-in-the-middle attacks, this au- ditional modules if the workload is too high for a sin- thentication infrastructure needs to be set up over secure gle member or just to distribute services in the group. channels prior to joining the group. We use a X.509 v3 Figure 2: The architecture of our group communication system. based public key infrastructure for our approach, because it Tools that support the creation of XACML policies exist5 , is the most widespread standard and is supported in several however analysing these and integrating them into our group open source libraries. management architecture is out of the scope of this paper. The group creator either generates a self-signed certificate The second task is supported by the XACML v3.0 Ad- or requests a certificate from a Certificate Authority (CA). ministrative Policy standard [13]. An example for the ba- Other members’ certificates must be signed by a CA accord- sic principle of delegation using administrative policies was ing to a certificate infrastructure policy. We then use the shown in figure 1. A full XACML delegation policy is shown Distinguished Names (DN) from these certificates as subject in appendix A. identifiers in the XACML policies and SAML assertions. The third task is supported by restricting access to the In our application scenario it is reasonable to assume pre- group key, used to encrypt all communication between group existing authentication structures within the organisations members. Thus only group members will have access to the participating in the group. Nevertheless chances are that applications available within the group. Furthermore these incompatibilities between different authentication systems applications can be programmed to enforce additional ac- would require some further federation mechanisms in order cess control policies towards members of the group trying to become interoperable. This however is out of the scope to access them. Such application access control could also of this article. make use of the access control infrastructure already avail- able within the group (PDPs, Assertion Servers, PIPs). 4.5 The modified join protocol This section describes the protocol used when a new mem- ber wants to join the group. It is slightly modified from the classical TGDH protocol in order to accommodate for the 5. DEMO IMPLEMENTATION access control and the transfer of DSA public keys we added. In order to demonstrate the feasibility of our architecture, A join request must contain the TgdhXacml group name we have produced a demo implementation for the main ele- one wishes to join, the blinded key for the TGDH join- ments of our architecture. This includes the context handler, protocol, the potential member’s DSA pubic key and au- the TGDH layer, XACML PDP and PEPs, SAML assertions thentication certificate. and Assertion Servers. The join request is broadcasted to all members of the The code was written in the Java programming language group. One existing TgdhXacml context handler declares and includes a basic graphical user interface shown in figures itself as the sponsor and further on only that context han- 4 and 5. dler will react to the join message. The sponsor now checks The interface allows users to the validity of the authentication certificate and requests an admission decision from a group PDP, in order to determine • join and leave the group, if the new member should be allowed to join. Thus the spon- sor acts as PEP, creating a valid XACML request and then • to display a list of PDPs available in the group, enforcing the PDP’s decision. • send and receive encrypted messages, If the join request is denied, the sponsor notifies the poten- tial member and takes no further action. If the join request • display the TGDH tree (Show Tree), is permitted the sponsor sends a message containing vital tree information such as tree structure, blinded keys, se- • show the current master group key, the number of quence numbers, PDP and Assertion Server lists to the new members and the position of this member in the tree member. The sponsor also blocks the whole TGDH tree and (Show info), broadcasts an update message containing the new blinded • and to start a new PDP for the group. keys in the tree. Figure 3 shows a sequence diagram of a join. The distributed network layer has been implemented by using IP Multicast. 4.6 Management The TGDH layer is based on the TGDH library from Lijun One important goal of this architecture is to support se- Liao at Ruhr-University Bochum, Germany6 . curity management of ad-hoc collaborative groups. This The Assertion Server and the XACML PDP are open mainly boils down to supporting the following tasks: source projects previously published by SICS7 . We currently use non-synchronised flat files as attribute and policy databases 1. Controlling who may join a group based on attributes and a simple PIP has been localised with each PDP, per- forming non-optimised policy retrieval. 2. Delegating administrative power The core components that where build from scratch ac- cording to our architecture are the Context handler and the 3. Controlling access to information at the application PEP. The Context handler is configured by a simple file, level specifying the group name the multicast address and port The first task is accomplished by creating XACML ac- and the DSA key parameters for this member. cess control policies that define the conditions of group ad- As a simple application layer we implemented a group chat mission. After these have been defined, the job of decid- sending and receiving strings. ing on group admission is automatically performed by the 5 For example: http://xacml.dif.um.es/ PDP. Updates of the group admission policies may be neces- 6 http://www.nds.ruhr-uni-bochum.de/research/top/gc/tgdh/ sary, but they will certainly occur less frequently than actual used with kind permission 7 group admission decisions. See: http://www.sics.se/spot for more information Figure 3: The sequence of diagram of the join protocol. Figure 4: GUI at start. Figure 5: GUI after a few joins. Figure 4 shows the user interface at start. The certificate access is going to be available or dedicated communication has already been loaded and a master key for the group infrastructures will be provided (e.g., the Rakel8 digital ra- was generated. The DN of the group certificate is displayed dio communication system in Sweden). together with some other TGDH tree information. As for the second problem, we assume that the main In figure 5 a few users have joined the group, thus expand- bottleneck will be communication cost and not computa- ing the TGDH tree and some encrypted messages have been tion (since the computational power of even small mobile sent (in this version the chat shows a lot of debug informa- platforms is quite high, especially if they include dedicated tion too). crypto-hardware). Considering the low communication cost This demo exemplifies how we intend our architecture of the TGDH join and leave events, it would require a con- components to interact and shows some necessary steps for stant stream of such events to seriously disrupt the function an implementation of the full architecture (customising a of our architecture. This is quite unlikely for our applica- PEP, adapting a TGDH library etc). Since it was produced tion scenario, since new members will more probably join as as part of Andreas Sjöholm’s master thesis, the time frame a batch and then want to stay group members for a period did not allow for the extensive testing that would have been of time. required to get meaningful performance data. Such testing Concerning the use of XACML and SAML in our autho- will be performed on a more complete version of the archi- risation architecture, common criticisms are: tecture, including distributed attribute and policy databases and a more advanced application layer. • These standards are too complicated because they pro- vide too much functionality (thus confusing the users). 6. DISCUSSION • The use of XML as base syntax introduces unnecessary In this section we first discuss issues related to the contrib- verboseness. utory group key agreement component of our architecture. We then proceed to discuss issues related to the authorisa- It is true that the full range of XACML and SAML func- tion components. tionality is not needed for addressing our problem. How- A criticism voiced about contributory group key agree- ever, building custom made proprietary systems is not a ment schemes [5] claims that: reasonable approach either, since we then would loose inter- operability through standard compliance, and make future • An established communication layer is required which extensions more complicated. must support broadcast operations. Therefore we claim that a reasonable approach is to create profiles for the use of XACML and SAML in specific appli- • If there are frequent changes in the group member- cations, that define subsets of the full functionality. Such ship, due to member mobility and/or link outage, the profiles can address the access control problems in the spe- topology of the ad-hoc group may change before the cific vocabulary of the application, thus making them un- key agreement scheme has been completed. derstandable for users. Since the profile only restricts the use of policy and assertion syntax, future updates of the We believe that our application area does not face these functionality can simply be achieved by updating the profile problems to a degree that would make contributory key agreement schemes problematic. In a crisis management sce- 8 see http://www.krisberedskapsmyndigheten.se nario as presented in the introduction either mobile internet /default 176.aspx for more information (thereby allowing the use of new features of the standard). in the demo with a more realistic service. A suitable appli- With custom made approaches, this would often require a cation could be Helping Hand9 , a graphical utility for cross redesign of the whole authorisation infrastructure. actor support in emergency response. There are two possible problems with the verboseness of XML encodings: Firstly it can be a question of band- APPENDIX width use, secondly understanding and reading the docu- ments (policies or assertions in our case) can be very diffi- A. EXAMPLE POLICIES AND ASSERTIONS cult for humans. The former problem can be addressed by In this section we present the full policies from figure 1 and various XML compression techniques, e.g., WBXML [12]. the related SAML attribute assertions. In order to reduce The latter problem can be addressed by appropriate user- the verboseness, we have defined the following abbreviations: interfaces that support policy editing and attribute manage- nsp = "urn:oasis:names:tc:xacml" and ment without requiring direct interaction with the raw XML string = "http://www.w3.org/2001/XMLSchema#string" format. Please note that both policies are contained in a single Poli- For our architecture as a whole, some points should be ob- cySet and follow the XACML 3.0 syntax, which is quite dif- served: Group members are trusted, no protection against ferent from the XACML 2.0 syntax. The first policy (Root- insider attacks is inherently provided by this architecture. Policy) delegates to the Police board the authority to create This is due to the peer-to-peer nature of our group, as policies for accessing resources from the group Incident23, opposed to a client-server group where there would be a provided the subjects of these policies are members of the group leader taking certain security responsibilities. At the police force. TgdhXacml middleware layer, the damage an insider attack The second policy (Alice’sPolicy) is issued by Alice, and could do is the same as an active attacker can do. Such in- gives Bob access to the resources from the group Incident23. sider attacks must instead be prevented at application layer. We are convinced that the benefits of having a flat group Our architecture relies on no single point of control or command since group key establishment (TGDH) is self will happen in case of network disruption is inability to propage policy updates (database synchronization, see Fig- ure 2) and reovcation information, but group functionality will not be affected. of when planning to use our architecture is that it requires Police potential group participants. Such frameworks often exist tions makes distributed authentication possible and makes TTPs such as a Kerberos server unneccessary (which would have been hard to implement across multiple organizations). This by letting only one authoritative representative per or- ganization mutually authenticate with the crisis coordinator and thereafter take advantage of the Assertion Server and Incident23 In this paper we have presented an architecture support- This architecture allows decentralised management of group admission control and therefore makes it possible to spread the administrative workload to the most competent parties, while not exposing the full set of rights to all delegates. In the future we plan to investigate how to provide a bet- ter administration interface for policy and attribute man- 9 developed at the Viktoria Institute, see agement. We also consider to replace the chat application http://www.viktoria.se/∼landgren/crossactorsupport IssueInstant="2007-11-16T13:27:15Z" >Police board asServer Category="nsp:3.0:attribute-category: ... delegate" AttributeId="role" DataType="string"/> NameQualifier="nsp:1.0:subject :subject-id">Alice DataType="string"> >Police board RuleCombiningAlgId="nsp:1.0:rule-combining- algorithm:permit-overrides"> This one asserts that Alice has indeed the role Police Alice IssueInstant="2007-11-16T13:33:28Z" Version="2.0"> asServer ... Bob AttributeId="nsp:1.0:subject: subject-id" DataType="string"> >Police Police. The combination of these two assertions validate the Incident23 by a PDP. Without these assertions, the second policy would B. REFERENCES [1] A. Sjöholm. Secure Group Management in Dynamic Networks. Master Thesis at Department of Computer and System Sciences, Royal Institute of Technology, Stockholm, Sweden, 2008. [2] D. Agarwal, O. Chevassut, M. Thompson, and G. Tsudik. An Integrated Solution for Secure Group Communication in Wide-Area Networks. In Proceedings of the Sixth IEEE Symposium on Computers and Communications (ISCC’01), Hammamet, Tunisia, July 2001. IEEE Computer The SAML assertions would look like this (slightly abbre- Society. [3] A. Anderson. Xacml References and Products, Version [15] W. Wang and B. Bhargava. Key Distribution and 1.83, January 2007. Update for Secure Inter-group Multicast http://docs.oasis-open.org/xacml/xacmlRefs.html. Communication. In Proceedings of the 3rd ACM [4] S. Cantor, J. Kemp, R. Philpott, and E. Maler Eds. workshop on Security of ad hoc and sensor networks Assertions and Protocols for the OASIS Security (SASN), pages 43–52, Alexandria, VA, USA, 2005. Assertion Markup Language (SAML) v2.0. Standard, ACM. Organization for the Advancement of Structured [16] W. Yu, Y. Sun, and R. Liu. Minimization of Rekeying Information Standards (OASIS), March 2005. Cost for Contributory Group Communications. In http://www.oasis-open.org. Proceedings of Global Telecommunications Conference [5] A. Chan and E. Rogers. Distributed Symmetric Key GLOBECOM, volume 3, pages 1716–1720, St. Louis, Management for Mobile Ad hoc Networks. In MO, USA, November 2005. IEEE Computer Society. Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), volume 4, pages 2414–2424, Hong Kong, China, March 2004. IEEE Computer Society. [6] S. Godik and T. Moses Eds. eXtensible Access Control Markup Language (XACML). Standard, Organization for the Advancement of Structured Information Standards (OASIS), February 2003. http://www.oasis-open.org/committees/xacml. [7] P. Judge and M. Ammar. GOTHIC: A Group Access Control Architecture for Secure Multicast and Anycast. In Proceedings of the 21st Annual Joint Conference of the IEEE Computer and Communications INFOCOM, volume 3, pages 1547–1556, New York, USA, June 2002. IEEE Computer Society. [8] Y. Kim, D. Mazzocchi, and G. Tsudik. Admission Control in Peer Groups. In Proceedings of the Second IEEE International Symposium on Network Computing and Applications, pages 131–139, Cambridge, MA, USA, April 2003. IEEE Computer Society. [9] Y. Kim, A. Perrig, and G. Tsudik. Tree-based Group Key Agreement. ACM Trans. Inf. Syst. Secur., 7(1):60–96, 2004. [10] J. Kohl and C. Neuman. The Kerberos Network Authentication Service (V5). Technical report, The Internet Engineering Task Force IETF, 1993. http://www.ietf.org/rfc/rfc1510.txt. [11] Y. Mao, Y. Sun, M. Wu, and R. Liu. Dynamic Join-Exit Amortization and Scheduling for Time-Efficient Group Key Agreement. In Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), volume 4, pages 2617–2627, Hong Kong, China, March 2004. IEEE Computer Society. [12] B. Martin and B. Jano Eds. Wap binary xml content format. W3c recommendation, World Wide Web Consortium, June 1999. http://www.w3.org/TR/wbxml/. [13] E. Rissanen, H. Lockhart, and T. Moses Eds. XACML v3.0 administrative policy. Standard, Organization for the Advancement of Structured Information Standards (OASIS), June 2006. http://www.oasis-open.org/committees/xacml. [14] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, and D. Spence. AAA Authorization Framework. Request For Comments (RFC) 2904, Internet Engineering Task Force (IETF), August 2000. http://www.ietf.org/rfc/rfc2904.txt. Secure communication SCENARIO for ad‐hoc, federated groups Andreas Sjöholm Severe accident andreas@axiomatics.com Axiomatics AB • Group G collaboration ll b ti Swedish Institute of Computer Science goal Babak Sadighi Ludwig Seitz • Can involve many Axiomatics AB SICS organizations i ti (nodes) ( d ) SICS THE EMERGING EVERNET PROBLEM A federated collaborative group • How can confidentiality and integrity be ensured? • An in common goal • Who may join a group? • No intra-knowledge g between nodes • Dynamic infrastructure and group composition The ad-hoc and federal structure of the group worsen the • Uses the Evernet as medium situation. i i A middleware GROUP KEY solution DISTRIBUTION Group policy • Contributory / Key dealer / TTP ? enforcement f t • Symmetric / Asymmetric ? Context handler • Computational C i l andd decisional group key secrecy Encryption/ • Implicit key Integrity authentication Tree based Group Tree‐based tgdh Root node d DH : Diffie‐Hellman (group key) Two nodes (siblings) can compute an in common (parent) secret key by knowing its own key and the other’s Proposed in 2004 at UC blinded key. Irvine and UC Berkeley Virtual nodes A l two Apply t partt DH recursively to a group via binary tree TGDH: A member (leaf ) can compute the master key,key k<0,0>, k<0 0> Member by knowing all ancestors’ keys and knowing the nodes blinded keys of all ancestors direct siblings. access control and trust XACML – eXtensible Access Control Mark Markupp Language Lang age SAML – Secure Assertion Markup Language Assertion Server PKI ATTRIBUTE Middleware ‐ TGDHXACML ASSERTION & DELEGATION 1 CC delegates 1. d l resource group: incident123 2. Alice has attribute role: Police Board 3. Alice creates administrative policy t targeting ti Bob B b 4. Bob can access group JOIN event discussion • XACML/SAML too excessive • Block-free Block free TGDH • Sync of data (policies, assertions) • Questions? Q ti ? www.oasis-open.org IDtrust Member Section John Sabo, CA, Inc. john.t.sabo@ca.com PKI IDtrust Steering Committee  Dr. Abbie Barbir, Nortel  June Leung, FundSERV  Arshad Noor, StrongAuth  John Sabo, CA, Inc. Many thanks to Ann Terwilliger, Visa who recently left the committee! www.oasis-open.org OASIS provides a neutral setting where government agencies, companies, research institutes, and individuals work together to advance the use of trusted infrastructures. The old OASIS PKI Member Section has restructured as the OASIS Identity and Trusted Infrastructure (IDtrust) Member Section The IDtrust MS has expanded its scope to encompass additional standards-based identity and trusted infrastructure technologies, policies, and practices. Four Strategic Focus Areas: • Identity and Trusted Infrastructure Components • studies and projects addressing technology-based Identity and Trust models and standards, relevant protocols and standards, trust infrastructures, and costs, benefits and risk management issues • Identity and Trust Policies and Enforcement • policies and policy issues; policy mapping and standardization; assurance; technical validation mechanisms; and trust path building and validation Four Strategic Focus Areas: • Education and Outreach • documenting trust use cases and business case scenarios, best practices and adoption reports and papers; organizing conferences and workshops; and establishing Web-based resources • Barriers and Emerging Issues Associated with Identity and Trusted Infrastructures • data privacy; interoperability; cross border/organizational trust; outsourcing; cryptographic issues; application integration; and international issues IDtrust Member Section TCs  OASIS Digital Signature Services eXtended (DSS-X) Technical Committee Advancing new profiles for the DSS OASIS Standard  OASIS Enterprise Key Management Infrastructure (EKMI) Technical Committee Defining symmetric key management protocols  OASIS Public Key Infrastructure (PKI) Adoption Committee Advancing the use of digital certificates as a foundation for managing access to network resources and conducting electronic transactions  OASIS Extensible Resource Identifier (XRI) Technical Committee Defining a royalty-free URI-compatible scheme and resolution protocol for abstract structured identifiers used to identify and share resources across domains and applications  Open Reputation Management Systems (ORMS) Technical Committee Providing the ability to use common data formats for representing reputation data, and standard definitions of reputation scores IDtrust Member Section Study on the Use of PKI in OASIS Standards  Survey initiated in 2006, addressing  Use and applicability of PKI in OASIS standards  Instances where the standards explicitly or implicitly define expectations regarding using PKI for authentication, encryption, or digital signature  Assumptions made within the standards regarding the methods and systems used to support the PKI  Whether explicit PKI-specific standards are referenced or expected (such as ISO, IETF etc.)  Perceived barriers to the deployment of PKI  Soon to be posted on idtrust.xml.org  Learn through the IDtrust Knowledgebase of educational materials and background on the standards  Share news, events, presentations, white papers, product listings, opinions, questions, and recommendations through postings, blogs, forums, and directories.  Collaborate with others online through a wiki interface http://idtrust.xml.org IDTrust Member Section  Tremendous growth and energy  Many opportunities to get involved  ! European Security Workshop, London, Sept 28 – 30 2008 !  Consider joining OASIS and participate in the MS and/or TCs  Contacts:  Dee Schur  Dee.schur@oasis-open.org  http://www.oasis-open.org/join  Idtrust.xml.org User-centric PKI Radia Perlman Charlie Kaufman Sun Microsystems Microsoft 16 Network Circle 1 Microsoft Way Menlo Park, CA 94025 Redmond, WA 98052 1-425-651-4094 1-425-707-3335 radia.perlman@sun.com charliek@microsoft.com ABSTRACT problems as well as to each other. We do not focus on particular The goal of supporting Single Sign-On to the Web has proven syntax (such as SAML or X.509), or the details of particular elusive. A number of solutions have been proposed – and some deployed systems, but rather the properties of families of schemes have even been deployed – but the capability remains unavailable that may or may not use the same standardized syntax. For to most users and the solutions deployed raise concerns for both example, we use the term “certificate” to refer to any digitally convenience and security. In this paper, we enumerate desirable signed statement, which would include X.509 identity attributes in a scheme for authenticating from an Internet browser certificates[12], “attribute certificates” [7], or SAML assertions to a web site and the authorization that follows. We categorize the [3]. currently deployed or advocated approaches, describing their After describing the properties of currently deployed or advocated benefits and issues, and we suggest incremental improvements to solutions, we describe an approach which is truly “user-centric”, such schemes. We then outline a design for public-key based in the sense that not only does the user decide which attributes to authentication particularly suited to what we believe to be the divulge to which sites, but mutual authentication to web sites with common case: users, acting on their own behalf (as opposed to as which the user has an existing relationship is directly performed an employee of an organization), performing actions on the web between the user (the user’s machine) and a server, rather than, such as making a purchase or maintaining an account at a service for instance, having the user authenticate to a third party (an provider. We contrast the usability/privacy/security properties of “Identity Provider”), and have that identity provider vouch for the our design with other identity management/authentication user. Also, the user’s private attributes, although perhaps stored schemes deployed or being proposed today. Our design is truly (encrypted) at some service on the web to facilitate user roaming, user-centric, in the sense that the user acts as his own CA, and as a are not available to anyone except the user, the user’s local decision point for authorizing release of user information to web machine, and on servers to which the user chooses to reveal them. sites, rather than having an Identity Provider be the center of trust. 2. DESIGN GOALS Categories and Subject Descriptors Today, users typically have independently configured and K.6.5 [Management of Computing and Information Systems]: maintained user names and passwords at lots of different web Security and Protection – Authentication, Unauthorized access sites, and must enter the appropriate ones when visiting particular (e.g., hacking, phreaking). sites. This is both inconvenient and insecure. Ideally, users would like to be able to authenticate to a machine once when they log in (possibly using the evolving “best practice” technologies like General Terms smart cards and fingerprint readers) and then have the machine Design, Security, Human Factors. authenticate to all visited web sites securely, efficiently, and transparently. We first list some desirable attributes (as a means Keywords for comparing various approaches). There are inevitable trade- Web services, PKI, authentication, single sign-on offs; no solution meets all of the goals. 2.1 Single Sign-on 1. INTRODUCTION As with the slogan “the network is the computer”, the user This paper starts with a description of various problems that it experience should be of a single authentication step, for instance, would be desirable to address when using the Internet, particularly activating a smart card and inserting it into a machine, or typing a in the context of a user doing business with a variety of services username and password. After that, the user should be able to on the web. Then we describe a variety of existing approaches, access any service on the net with which the user has an ongoing and review their strengths and weaknesses compared to the set of relationship, and be logged into the user’s account without the user consciously doing another authentication. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are 2.2 Protection from Phishing not made or distributed for profit or commercial advantage and that Safety: If a user is tricked into authenticating to an evil site (e.g., copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, phishing), the site should gain no credentials with which to requires prior specific permission and/or a fee. impersonate the user, either at the site the user intended to visit, or IDtrust ‘08, March 4–6, 2008, Gaithersburg, MD at other sites to which the user has access. Copyright 2008 ACM 1978-1-60558-066-1…$5.00. 2.3 Minimal Dependence on Third Parties desirable for the user to be able to access the web through Efficiency: A user should be able to communicate directly with a whatever authentication methods are practical for the situation. web site without having to first communicate with other Authorization based on authentication method: If there is the machines. ability to log into different machines using different credentials as Robustness: A user should be able to communicate with a web described above, some logins will be more secure than others. site even if other sites are not reachable at the time. Therefore, it might be desirable for authorization decisions to depend on where the user is authenticating from, as well as how Off-line Trusted Entities: It is desirable to have the system he authenticated. For instance, the user might decide that making operate in a way that the most trusted components are not trades in his brokerage account only be possible when he has connected to the network. The reason for this is that a system that authenticated with his smart card, or be working on his home requires a trusted server to be on-line in order for authentication desktop machine, whereas checking his available balance might between other systems to work will be less secure because: be authorized from any location and using any authentication • An on-line server is an attractive target for network- method. based attacks. It is likely to have security flaws, and Or a server holding a company’s confidential files might allow thus likely to be compromised. Even if not access to those files only to users that have authenticated from an compromised, it is subject to DDOS attacks. onsite machine using a smart card. • Such a server must be replicated for availability and performance, and each replica must be physically secured. 2.6 Additional user attributes Convenient access to user information: There is some 2.4 Flexible use of accounts information that the user always knows, for instance, home Multiple accounts with the same service provider: A user may address. It might be convenient for this information to be have multiple accounts with the same service provider. For automatically filled in when required, but it is less necessary than instance, other information that the user might need and not easily • one account for purchasing work-related items, and remember, such as passport number and credit card numbers. another for personal items Authenticated Attributes: There are some attributes that a user • entering chat rooms with different pseudonyms cannot simply claim by filling information into a field, such as whether they are over 18 (e.g., for purchasing alcohol over the • multiple email accounts with a single email provider web), or whether they are not a citizen of one of the countries It is desirable for authentication to be automatic, while still currently disapproved of by some government (e.g., for export allowing the user to choose which account to access. control decisions), or whether they are employed by a company that has corporate membership in some organization (e.g., a Multiple users with the same account: A family might share an service that allows all employees of member corporations to have account at a site such as a DVD-by-mail service. A user would access to on-line search). like to be able to access all his private accounts through a single sign-on, but also be automatically logged into accounts on sites in 2.7 Credential loss or theft which he is one of several authorized users. One-step revocation: The user might want to change the Easy and Secure Account Creation: It should be easy to create a credential with which he performs his single sign-on. This might new account and have it automatically use, for future be because, as is good security practice, he changes his password authentication, the credentials with which the user is currently periodically, or because his smart card has been stolen. When this logged in. If the user has several potential credentials (e.g., happens, accounts at all servers must (within a reasonable amount password, set of client certificates), the user should be able to of time) know not to accept the old credential. select which should be used for this new account. Protection against loss of credentials: In many schemes (including the one we advocate) a lot of important information is 2.5 Convenient Roaming stored, encrypted with the user’s private key or password. If the Convenient Roaming: A user would like to be able to access user forgets this password or loses the smart card with the private accounts from a variety of different platforms (home desktop key, it should be possible to salvage all the information. machine, work machine, laptop, cellphone, hotel lobby shared desktop machine). One-step rollover to a new credential: Once the old credential is revoked, it should be convenient to start using a new credential, Least Privilege: Machines (even a user’s own machine) are not without the requiring the user, for instance, to individually necessarily secure. Logging in with “full credentials” to perform a reinstalling his account at each service provider. single operation such as printing a boarding pass, or checking to see what conference room the next meeting is in, might be taking 2.8 Minimal platform changes an unwarranted risk. Deployability of an authentication scheme depends critically on Credential Agility: Although a smart card might be the most how many different components must be updated before it can be secure choice for user authentication, the desktop machine in the used. Virtually all of the schemes being proposed or deployed fall hotel lobby from which the user would like to print his boarding into one of two categories: schemes that can be deployed on client pass might not have a smart card reader. Or the user might have devices with supporting infrastructure without modifying the left his smart card at home, and still want to do work. It is existing web sites; and schemes that can be deployed on web servers with supporting infrastructure without modifying the password on multiple systems, allowing servers to impersonate deployed base of clients. Schemes that require changes to both the user to other servers. clients and servers face a chicken and egg problem, since there is Furthermore, prompts for usernames and passwords take place on substantial cost and no benefit to deploying the first half of the ordinary web pages that can be easily forged, tricking users into solution. giving away that information to impostor sites. While the Note that some client changes are easier than others. All of the protocols for authenticating web servers to browsers are major browsers are highly extensible (though incompatibly), cryptographically strong, the visual cues by which browsers allowing add-ons to be installed that do additional processing. identify web sites to users have been shown to be ineffective[27]. There are a wide range of such add-ons aimed at specialized Users should not be expected to understand the arcana of URLs, processing of web site logons. Users should be leery of installing and know, e.g., that http://84.212.151.26/www.creditunion.com is add-ons from unfamiliar web sites, though most are not. Two not actually the web site “creditunion.com”. problems with such add-ons are that they may not be available to users who are logging on to kiosk or otherwise unfamiliar Although it might be desirable for a user to use a different machines, and they may not be available for the browsers on password at every site, there is no way for a user to remember all specialized devices like cell phones. the different usernames and passwords at all the sites at which the user has an account. Neither can the user pick a strong password and use it everywhere because sites have incompatible restrictions on what kinds of characters must and must not be contained in 2.9 Access Privacy passwords. A user should be able to access sites without any server being able to know which other services a user is using. Where possible, it is The user can’t even use the same username at all places for desirable for a user to have a degree of anonymity where the reasons such as: server knows that the user is authorized to access something without knowing the identity of the user. If the user is accessing • The username the user has been using is already in use two different sites, the user may wish that the two sites not be able at some new site the user would like to register with. to determine that the requests to them originate with the same • The site might have its own syntax rules about carbon based life form. usernames that the user’s customary username does not fit (such as minimum or maximum length, or legal 3. EXISTING SCHEMES characters in the name). In this section we review existing schemes. By “existing”, we mean either deployed or advocated. We are intentionally grouping • The user might not want anyone to be able to correlate families of schemes that have similar properties for the purposes his accounts at different sites. of our discussion, and hope their developers won’t be offended by our glossing over design aspects they might consider to be crucial. • Some sites use the user’s email address as their This is also a rapidly growing field, and we are not attempting to username. Email addresses tend to change, since they make our list complete. are often provider-based or employer-based. • The user might have several accounts at a site, and wish 3.1 Classic Username/Password to select which one to use for the session. While within an enterprise or a university environment, more sophisticated authentication schemes based on centrally registered To prevent passwords used at multiple sites from being exposed if “accounts” are used for file, database, and sometimes http access, one of the sites is compromised, sites should store a hash of the the dominant authentication means on the World Wide Web user’s password for verification rather than the actual password. remains username and password. On a good day, those credentials Unfortunately, many sites store the cleartext password. This is are protected from eavesdropping by SSL. They are used for obviously done at sites which email the actual password to the everything from accessing banks and brokerage accounts to email user when the user has forgotten the password. and social networking sites, and by and large users have to choose When forgotten password recovery is to be based on the (dubious) separate usernames and passwords for each site they use. Payment security of email, there are two possibilities: schemes are predominantly based on users typing in credit card numbers and expiration dates to merchant sites. The • A site keeps the user’s actual password, and emails the inconvenience of these mechanisms is well known and the password to the email address the user has registered security weaknesses are well publicized. Users cannot remember with, when the user claims to have forgotten her high quality secrets (even in small quantities, much less in large password. ones), smart cards are not widely deployed (especially outside of an enterprise), and there is no coordination among Internet • A site keeps a hash of the user’s password, and resets services that would allow any centrally managed form of the password to some single-use password. When the authentication to be accepted everywhere. user logs in (or clicks on the link in the email), the user is asked to set the password to something else. Passwords present many security issues: some obvious and some more subtle. Users often choose passwords that are easy to guess, The first system has the advantage that someone cannot users write them down, the passwords are exposed to keyboard maliciously claim to have forgotten someone else’s password, and loggers and shoulder surfers, and users tend to use the same cause that person to go through the inconvenience of resetting their password. This would likely be only a minor inconvenience make a purchase, than someone who is making a first unless the user does not have access to email at the time. time purchase. The second system has the advantage that someone who steals the • If an account is to be maintained, and the user must password database at one merchant cannot easily impersonate find and authenticate with a username/password at the users at other systems. With the first system (cleartext passwords site, security questions for retrieving this forgotten stored), even if a user were to customize passwords at different information must be chosen by the user. sites, a thief who notices the user’s password is “amazonPwD89351” might guess that the user’s password at ebay Furthermore, in the case of an occasional purchase at a site, not might be “ebayPwD89351”. only is the experience typically more onerous for a returning user than a first time user, but the ongoing relationship (the merchant Evaluating this “classic” username/password authentication keeping information about that user) is of extreme negative value against our design goals, it fails at Single Sign-on (the user must to the customer. Not only is it less convenient for the user to make separately authenticate to each site) but provides some protection a future purchase (because of having to first go through the against phishing: it is easy for the attacker to trick the user into procedure for recovering the old username and password, which revealing the password to a target site, but at least the password is even if succeeds is likely to take several minutes), but the user’s (hopefully) only useful in impersonating the user at the target site. personal information is stored in a database that is likely to be It would be much worse if phishers could obtain a password that broken into at some point. Most information the web site needs, would allow access to all of the user’s resources. It actually fares such as the user’s address, is reliably maintained in the user’s fairly well against the other criteria. Roaming is easy – passwords head, thank you, and not a burden to type in. Other information, can be typed into any machine. Credential loss recovery is such as the credit card that the user used last time the user different for every site and there is no coordinated recovery if the purchased something, is not only dangerous to store, but is likely user loses many at once (e.g., they were all stored on a sticky note to be out of date when a customer only purchases something from or in a file on a stolen laptop). It has no dependence on third that merchant every few years,. Also, users tend to have many parties, allows maximum flexibility to users with multiple credit cards, and have reasons (perhaps based on the current accounts, and by definition requires no platform changes. balances on each of their cards, or current promotional rebates) for selecting a particular card for a particular purchase. Storing Another merchant practice that causes inconvenience for users, as credit card information is thus not very useful to a customer and well as making them more vulnerable to security and privacy very dangerous. problems, is for merchants to maintain customer information beyond anything that adds value to the user. An occasional There should be a law: purchase of merchandise from a web site does not require a long term relationship with the user -- it is largely for the merchant's After a merchant has been paid, a customer must be allowed benefit that the merchant maintains personal information about to request that any subset of the information about that user the user after the transaction has completed. stored at the merchant (including all of it) must be deleted by the merchant. And of course, the merchant should be Worse yet, in the case of the occasional purchase from an on-line required to comply with this request. merchant, it is often more onerous to be a returning customer than a new customer. If it has been several years since the user last But there are some web sites that do need to maintain an ongoing interacted with the merchant, it is very likely the user has relationship with a user -- DVD subscription services in which a forgotten his username and password on the site. A new user need user maintains a movie queue, brokerage services where a user only type in information that he knows (such as his home address) trades online, airline accounts where a user purchases tickets and and credit card (which he copies from a credit card he selects. accesses their frequent flier points, tax packages where users prepare their taxes and where their records are maintained year A common experience for a user that has purchased something after year, to name a few. from the site several years ago is that once she types her email address (needed to obtain a receipt), she is informed by the site 3.2 Enhanced Username/Pwd Schemes that she is indeed a returning user, and must now log in, Browsers usually have a feature where they will remember, for furnishing her username and password. Given that she has almost various sites, what the user’s username and password are, and fill certainly forgotten both, she now has to go through a “username them in for the user. The problem with this is that then it becomes recovery procedure” that may or may not succeed (because she even more likely the user will not remember his username and doesn’t remember which telephone number she gave them when password when he winds up needing to access the site from a she bought from them 4 years ago), or what she made up for different machine, or discovers all that state irretrievably gone answers to the few amazingly inappropriate security questions the when his computer dies and he needs to replace it. The less web site makes her choose from. Personally, I have no pet, no frequently a user needs to type his username and password to a favorite sports team, I don’t remember my 2nd grade teacher’s site, the more likely it will be that the user will forget the name, and my father does not have a middle name. username and/or password when the user actually needs to How many things are wrong with this currently widely deployed remember and type it. strategy? The Local Password store approach requires no changes to servers. Browsers typically have this feature “built-in” for storing • It should be no less convenient for someone who has this information when HTTP authentication [8] is used, but there previously purchased something at the merchant to are a growing collection of add-ons that support it for the more While users don’t check the identity of a web page before entering common case where passwords are entered on a web page. a password, the automation software will. The flip side is that the Examples include PwdHash[19], TrustBar[10], credentials for the one single sign-on are much more valuable PasswordVault[20], Pvault[5], Sxipper[23], and Passpet[29]. The than those of any particular web site, so if some phishing attack idea is that plug-in software installed on client machines notices (or getting the user to run hostile software on his machine) can password prompts from servers and automatically satisfies them acquire that secret the damage is greater. (usually invisibly to the user except for a small delay). PwdHash is a little different from the others. It does not keep a database of 3.3 Identity Provider Federated Solutions A variety of web-based schemes have been proposed (Liberty[25], passwords, and does not change the user experience at all (users web services[26], Shibboleth[15][21]) in which a user have to type in as many usernames and passwords as they ever authenticates to an "identity provider", which provides the user did). PwdHash improves security in the common case where a with a credential that identifies the user to a service provider. In user uses the same password at lots of sites. It hashes the such systems, the service providers must be affiliated with the password typed by the user with the site name to get a unique identity provider in a trust relationship (in a previously arranged password for each site. This means that breaking into one site will "federation" arranged between the service provider and the not enable impersonation of the user at other sites and breaks identity provider), and the user must "link" the identity at the phishing for passwords. service provider with the user's identity at the identity provider. These systems are relatively straightforward conceptually, but in practice involve a lot of fragile trickery dealing with the plug-in As originally conceived, browsers were designed so that web sites architectures of the various browsers. could not interact with one another except in specific limited ways. A web site can store state associated with a user session – There is no standard password prompt that web pages display, or even a long term memory associated with the site – in the form though they do have a lot in common. The password field usually of a cookie on the user’s machine. The short term memory enables is configured to echo some special character rather than what the users to log into a web site once rather than for each page viewed, user types in the field, and it is often called “password”. Figuring but it is forgotten when the user logs out (of either the site or the out exactly how to recognize a password prompt page and browser), and not shared with other sites. The long term memory respond correctly for the great variety of existing web sites is a survives reboots and allows web sites to know what user last continuing challenge for people who maintain this sort of accessed the web site from a particular machine, but it’s generally software. considered identification rather than authentication because This approach often has as a design goal that the user never sees machines are frequently shared. And like the short term memory, the actual password, and it is long and randomly chosen to make it this is designed not to be shared with other web sites. difficult to guess. That means that the software must also The cookie scheme works well for sessions within the pages of a recognize the account creation page and know what various site’s single web site, but an SSO scheme can’t create a cookie visible rules are for acceptable passwords so it can fill in appropriate to web sites whose DNS names (contained in the URL) are not ones. For sites that require periodic password changes, the sufficiently similar to those of the sign-on site. The common software can automatically change the password while the user is workaround for this involves HTTP/URL redirection. If I enter doing something else. the URL of a site into my browser, my browser will go to the site A challenge with this approach is keeping the various password whose DNS name is embedded in the URL, and try to retrieve the databases synchronized if the user accesses the web from multiple data associated with the URL. A site can – if it chooses – provide machines. Another is that the software (and database) must be a different URL for my browser to fetch instead. The URL to installed on any machine from which the user wants to access the which I am “redirected” need not have any similarity to the web, which may not be allowed in the case of kiosk or borrowed original URL, so by generating a URL that contains data, this machines. provides a mechanism for independent sites to interact. The Most of the add-on schemes either have some sort of roaming second site can – if it chooses – give my browser a third URL to built in or have some sort of export to a file capability to allow retrieve, with the chain extending indefinitely. such roaming to take place manually. They also generally allow Most web SSO schemes work with some variant on the following: the roaming of other personal data like addresses, phone numbers, 1) When a web site that is part of a federation receives an and favorite web sites. http request, it looks for authentication information Measuring these add-on schemes against our design goals, they do included as a session cookie or part of the URL. If there a good job at providing single sign-on. They typically depend on is none (and there won’t be the first time through), it third parties only to support roaming. Their support of roaming, redirects the browser to the IDP (identity provider) site carrying additional user information, access privacy, and failure with a URL that begins with the name of the IDP site recovery is potentially very good, though the details vary by but includes (as data) the URL in the request. scheme. Dealing with shared accounts and users with multiple 2) The IDP site looks for a cookie indicating that the user accounts is a user interface challenge, since it conflicts with is already “logged in”. If so, it redirects the user’s seamless single sign-on, but these schemes have the potential to browser again, pointing it back to the original URL, this do as well as is possible. The most interesting issue regards how time adding the user’s authentication information. these schemes deal with phishing. They generally cite protection from phishing as a major feature, since users don’t know the site 3) Now back at the original web site, there is still no passwords and therefore can’t be tricked into revealing them. cookie, but there is additional information in the URL authenticating the user, so the web site creates a session cookie and returns it along with the page associated Identity Provider solutions do help the issue of service provider with the original request. In normal use, the two impersonation (phishing), because the Identity Provider site is not redirects take place so quickly that the user doesn’t likely to have a relationship with the evil site, nor would the user notice that anything extra is going on. The have given permission for any of the user's information to get authentication takes place seamlessly. shared with the evil site. If the user has authenticated to the real If when the user reached step 2, he had not yet logged into the identity provider, the user will not be tricked by unaffiliated identity provider (i.e. no cookie), then instead of redirecting the service providers. user back to the original web site the identity provider However, especially with user authentication based on username authenticates the user using any of a number of techniques that and password, the Identity Provider approach is very vulnerable to could include username and password, but could also involve a user being spoofed by a site impersonating the Identity Provider, smart cards or X.509 certificates. After the user authenticates, the especially because the user will often not type in the URL for the IDP sends the user’s browser a web sign-on cookie and then Identity Provider, but instead be redirected to the page in which redirects him back to the original web site. the user is prompted for his username and password. And the This design requires no changes to the browser. Functionality put username/password at the Identity Provider is particularly in the browser for other purposes is exploited to do the disastrous to divulge to an impostor site, because compromise of authentication. Web sites that want to join a federation and the that information compromises the user at all sites the user has identity providers must carefully coordinate what they are doing, linked with that identity provider account. but there could be many identity providers operating Looking at how well this sort of solution meets the other design independently with collections of web sites behind each of them. goals, identity providers are unlikely to actually provide single They would not be aware of one another. sign-on, but rather a reduced number of sign-ons. That’s because Several problems with this sort of approach are: it is unlikely that a single identity provider will sign up all of the • There are limits on the maximum size of a URL and of sites a user wants to access. Banks, brokers, and other particularly cookies, and if applications are already running close to sensitive sites will likely affiliate with no identity provider or only those limits adding authentication information can push with very specialized ones. These schemes are totally dependent them over. Remember though, that you can (with some on third parties, introducing both security and availability issues. cost in performance) always substitute a URL, an They are likely not to work very well with shared accounts or encryption key, and a cryptographic hash for an users with multiple accounts because the http redirection arbitrary amount of information and then store the real technology is hard to make both flexible and transparent. They information at the URL encrypted with the key. handle roaming well. They handle carrying specific kinds of user configuration information along like credit card numbers and • A web site might want to affiliate itself with multiple other authentication-related information, but they are unlikely to identity providers and allow the users logged into any deal with ad-hoc information like lists of favorite sites. They are one of them to authenticate seamlessly. The problem is well qualified to carry information that requires attestation, like that the site doesn’t know to which identity provider it age, memberships, and corporate affiliations, and can enhance should redirect a user. If the identity providers privacy by proving affiliations without identifying the individual cooperate, there are ways of smoothing over this, but requestor to the web site. In principle, they should be able to do a without browser changes or configuration restrictions good job of credential changes because credentials need only be there are no perfect solutions. revoked in one place (at the IDP). While client-only • Similarly, a user might have many identity providers, enhancements are largely transparent to web sites, Identity and might want to have accounts at many service Providers are often transparent to the client software. Web sites providers, where not all the service providers are can deploy them without requiring that users install any new affiliated with the same identity providers. Currently software on their machines (which is particularly important when advocated schemes are largely silent on the issue of dealing with kiosks, specialized devices (like cell phones), and a dealing with multiple identity providers. user base running a variety of types of browsers. • Although in theory user authentication to the identity 3.4 CardSpace provider can be done with any sort of technology, it is CardSpace [4] is a system that allows a user to select one of usually deployed with a username and password. If it several “cards” (signed assertions about various attributes of a were done with a stronger mechanism, say smart cards, user) to present to a service provider. These cards might be signed it would lose the benefit of being deployable on any by an identity provider, in which case CardSpace becomes similar browser from any machine. Given the fragility of server functionally to the systems we described in section 3.3. It authentication to the user, if a user can be tricked into improves on those schemes by having local storage for typing the user’s identity provider username/password remembering things like what credentials are associated with to a site impersonating the identity provider to the user, which sites and by having the user be prompted with a difficult to that evil site can then impersonate the user, not just at spoof UI asking what information the user would like to pass to the identity provider, but at any affiliated site. the web site. The cost of those security improvements is that it requires additional software be installed on all clients as well as • If the identity provider is currently not reachable, there all servers and it asks users lots of questions (breaking the is no way for the user to attach to any of the service transparency of other single sign-on solutions). providers. CardSpace provides another mode of operation with self-issued telephone number to be called every time this stock changes cards, which is like having a private identity provider on the value” service ought to verify a phone number. client. This eliminates the need for any initial user registration Email address is routinely verified by web sites, and they do this with an identity provider, and the need to have another machine in by sending a token to the web site, which you have to return by the authentication loop. With self-issued cards, CardSpace is clicking on the link in the received email. This low tech solution similar to one aspect of the scheme we propose in Section 4 is secure enough in practice. (registering the user’s public key directly with the service provider as a method of authenticating the user). For authenticating the attributes listed above as needing to be authenticated, there are only ad hoc and not very secure 3.5 Controlling Access to User Information mechanisms deployed. For downloading export-controlled code, Section 3.3 only discusses how the Identity Provider solution typically a check of IP address is made, with perhaps a form that addresses single sign-on. An enhancement to the Identity Provider you have to click agreeing that you are not a citizen of one of the Federation solutions is to also store user information (such as frowned-upon countries. This does not prevent someone from address, credit card, phone number, etc.) at some location. It using a proxy site to disguise his IP address, or downloading it at could be at the Identity Provider, or at another machine, or some a public machine while visiting an approved country. of the user’s information might be at one server, and some at The identity provider solutions have a solution, in that identity another. For simplicity, we will assume all the user information is providers can sign the attributes. However, this implies that there stored at the Identity Provider. are sites out there that are trusted to assert all the needed attributes The vision is that the user can set policy on each item of personal for a user, that the user has some mechanism for authenticating to information, as to which information should be made available to those sites and requesting the signed attributes, and – perhaps which web sites. Information that has been approved to be sent to hardest of all – there is some infrastructure in place that enables a site is sent automatically to that site when needed. users to find them. This might be a mechanism for keeping user personal information 3.7 Strong Password Techniques more secure, because then the service provider would not need to A strong password protocol solves the problem of doing mutual keep the user’s information in a database, and there would be authentication using a weak secret (such as a password) in such a fewer databases on the web with personal information for the way that neither side in the exchange (client or server), or an user. Since each database has some probability of being broken eavesdropper, can do a dictionary attack. This form of mutual into, the fewer places that user information is stored, the more authentication might be a more reliable way of ensuring that the likely it is that it will remain secure. user is not fooled by an imposter web site than TLS, or TLS However, it is likely that service providers will keep the alone, because of the problems we mention in section 3.9. information. They might use the identity provider to retrieve the Because this form of authentication is mutual, TLS authentication information when the user is first setting up an account, but it is in is redundant except when establishing the shared secret initially. the service provider’s interest (less bandwidth, latency, and work), The straightforward mechanism of sending a password does not to store the user information on the service provider site so that in do mutual authentication. There are other protocols such as subsequent interactions it would not need to be retrieved from the CHAP[23] in which the password is used as a secret in a identity provider. challenge/response protocol. Variants of such protocols can be used for either one-way authentication or mutual authentication. 3.6 Authenticated Attributes However, these sorts of exchanges are subject to dictionary attack, Some attributes are intuitively ones that need more proof than just by at least one side in the exchange, and by an eavesdropper. having the user fill in fields on a form. Examples are: There are a number of cryptographic techniques for authenticating • I am a member of an organization that is authorized to with a weak secret (a password) in a cryptographically strong way. use the services of this site, for free. The first of these was EKE[1], though there are others • I am over 18. SPEKE[13], SRP[28], PDM[18]. • I am not a citizen of one of the countries that the Roughly, these protocols weave a password into a Diffie-Hellman company I am communicating with is barred from exchange in such a way that someone impersonating either side allowing downloads to. can only verify one password guess during an authentication, and • My credit card number is X. an eavesdropper cannot even verify a single password guess. A strong password protocol provides mutual authentication. Both Other attributes seem like they would not need proof, such as: the server and the user must know the password in order for • Address authentication to complete. • Telephone number For usability, it would be desirable for the user to use a single • Email address password at all the service providers. The obvious vulnerability there is that all the service providers could then impersonate the First, even attributes that seem like they would not need proof user at the other service providers (at which the user used the might, in certain situations. It would seem as though the “rent out same password). To solve this problem it has been suggested (e.g., my house for a week” service, or the “demolish my house” service in PDM[18]) that the password at a site named "X" be a hash of would need some sort of proof of address. And the “register my the user's single password, and the string "X". Problems with strong password solutions as currently advocated: The challenge in both cases is scalability. It is logistically difficult to securely provision all of the components in the system with • The user must first install a password in a secure way at secret keys, and Kerberos is designed for configurations where all each service provider. components are willing to fully trust a centrally managed service. • If the user changes his password periodically, the user will wind up with unsynchronized passwords, and be 3.9 SSL Client Certificates confused about which passwords to use at which sites. The SSL and TLS protocols provide for the ability to do mutual authentication (user to server as well as vice versa), but as Strong password protocols might be useful as a mechanism of deployed, authentication is almost always just server to user. authenticating to the Identity Provider in a way that is more secure than sending the user’s password directly, or somewhat more Public key based authentication of clients to servers eliminates the secure than doing a protocol such as CHAP in both directions. straightforward man-in-the-middle (phishing) attacks because the However, it does require changing software at both client and server learns nothing that would allow it to impersonate the user server machines. to another server. But the UI problem remains that users are unlikely to notice that they are connected to impostor web sites, 3.8 Kerberos so if they enter confidential information on a web page, that Kerberos [16] is a secret key based system commonly used within information might be given to an unauthorized server. Users can an enterprise to authenticate non-web based clients and servers. be tricked by web sites for several reasons: There are a number of ways that it could be used for web • Confusion around server names, where a misspelled authentication with different side effects. name might not be noticed, or worse yet, In Kerberos-based systems, a KDC stores a secret (or with the internationalized names can look identical to the PKINIT[30] enhancement, a public key) for each user, and a expected name secret for each server. Each time a user wants to connect to a server, the user first contacts the KDC and obtains a (short-lived) • Confusion around URLs, where understandably users ticket to that server. might not know which part of the URL is the real DNS name The KDC can impersonate the user at any server in the realm (as can an Identity Provider), and although it is possible to do cross- • Faulty trust anchors, in which an evil-doer manages to realm authentication, Kerberos is mainly practical within an trick any of the trust anchors into issuing a faulty enterprise. certificate The initial authentication is usually done with a password, though • Also, because there are so many cases in which the web PKINIT is used in organizations in which all employees are site the user wants to visit chooses to use a self-signed provided with smart cards. certificate or an expired certificate rather than go A KDC is similar in some ways to an identity provider. However, through the hassle and/or expense of obtaining a with Kerberos, the ticket provides a shared key between the user's certificate from one of the commonly configured trust machine and the server, and a cryptographic mutual authentication anchors, users have been trained to ignore security exchange is done between the user's machine and the server. In warnings around certificates and accept anything. contrast, with the http-based Identity Provider solutions such as Therefore, it would be relatively easy for a web site to Shibboleth and Liberty, the client machine is given secret present itself as any server name, using a self-signed information in a redirected URL, and the client machine sends certificate, and many users will merely accept the that information to the server. Given that it is possible despite certificate signed by the “unknown trust anchor”. TLS, (for instance, by presenting a self-signed certificate claiming Client side PKI is not usually deployed for use between to be the server name and having the user click “OK”) to unaffiliated clients and servers over the Internet. It is used within impersonate a server to the user’s machine, the Kerberos approach organizations (where the user is an employee/student/etc. of the is somewhat more secure than the Identity Provider approaches, organization operating the server). Nevertheless, use of since the actual secret is not sent to a server. certificates between unaffiliated clients and servers is rare. There One way to integrate Kerberos with web authentication is for an is work on Bridge CAs that might enable PKI use across Identity Provider to use Kerberos tickets as the secrets it sends to organization boundaries, but it hasn’t penetrated the broad servers. In this configuration, the browser client is unaware of the population yet. There have been some CAs deployed to give users use of Kerberos. The Identity Provider goes to the KDC to get certificates. A typical method of doing this is: Kerberos tickets for the authenticated client to forward to the • the user contacts the CA and tells the CA the user's service. In this configuration, the security properties are email address and public key essentially the same as with other Identity Provider schemes. Another way to do the integration is for the client to authenticate • The CA sends a token to the email address to the server using Kerberos as an HTTP authentication • The user, after receiving the email, sends the token to mechanism within the TLS encrypted tunnel. This is most useful the CA (proving that the user has access to the email in scenarios where the clients and servers are already provisioned account) with Kerberos in support of other protocols. The security properties resemble those of other intranet protocols. • The CA sends the client the certificate, which is stored in the browser. Why are client certificates not widely used in practice? • The simplest scheme is to have {priv}pwd be world- readable. If the user's password were sufficiently strong • It is confusing for users to obtain a certificate. this would even be reasonably secure, but most users do • Some CAs, wanting to be able to provide more not choose passwords strong enough to withstand an assurance to their certificates, would require onerous offline dictionary attack. Kerberos version 4 [14] was procedures such as mailing them a notarized letter. They deployed in this mode (anyone could request a may also charge for certificates both initially and for credential for the user which would enable an offline renewals. dictionary attack). • Historically it has been hard to move certificates from • The next enhancement is to have a simple browser to browser (vendors believed they were making challenge/response protocol (perhaps in a TLS- certificate based authentication more secure by protected exchange based on server-side authentication) introducing this inconvenience) making roaming in which the user proves knowledge of her password difficult. before the server sends {priv}pwd. This is similar to the "pre-authentication" that was introduced in Kerberos • Users are likely to have different usernames with version 5[16]. Someone impersonating the server would different service providers, and today browsers don’t be able to do a dictionary attack, but others would only remember which certificate to send to a particular web be able to do an on-line attack. Without TLS protection, site (the user must select it each time). an eavesdropper would also be able to launch a dictionary attack. However, in practice, it is more • Certificates are generally issued to some name for the difficult to arrange to be eavesdropping on the private user, for example, his email address, which might not be key download exchange than merely to send a message the same as the account name at the server, and might to the server requesting it to send {priv}pwd. When not even be stored as a property of the account, so it is used with TLS server-side authentication, this approach not necessarily straightforward for the server to know would be quite deployable and quite secure today. which account is being accessed, based on the Various schemes for doing this have been proposed (for certificate. example, Pvault [5] and SACRED [6]). Another issue with currently deployed PKI-based solutions is that • Another approach would be to use a strong password- TLS has no ability for the client to request a particular certificate based credentials download protocol such as in [17]. from the server. If there were many CAs in the world, and a particular user chooses to trust only some subset of them, then Ultimately, of course, it would be desirable for users to have smart there is no way for the server to be able to guess which certificate cards. USB connections are nearly ubiquitous today, and there are to send a user. USB-based smart cards. Or phones can communicate with a work station using bluetooth technology. A fairly small change to TLS would enable this sort of negotiation. Such a change is proposed in [11], and a usable With strong password techniques, someone impersonating the subset is specified in RFC4366 [2], but it has not been widely server or client can only do an on-line dictionary attack, and deployed. someone eavesdropping gets no opportunity for a dictionary attack. However, if someone were to steal the server database, One big advantage of PKI over the other solutions is that the CA then one would be able to do an off-line attack, since the server need not be on-line, which is important for the reasons we gave in must store the user's private key encrypted with a password. section 2.3. 4. TOWARDS A USER-CENTRIC PKI 3.10 Obtaining the user’s private key In this section we describe a number of ways of addressing, not If user authentication is to be done using public keys, the first only the single sign-on problem, but also the issue of providing challenge is obtaining the user's private key(s). Unlike a user information in a way that is convenient, safe, and under password, it cannot be carried in the user's head (because user control of the user. One aspect of our approach, doing mutual memorable passwords are nearly always weak keys, and weak authentication without using 3rd party CAs, is philosophically private keys offer little value). Ideally a user would have a smart similar to that used for email in [9], as well as to self-issued cards card, but there are problems with smart cards that have prevented in CardSpace. We also address other issues, though, including them from being widely deployed: one-stop revocation and switchover to a new user credential, that have not been addressed before. • Users lose them, and need a backup plan for when the smart card is either not with the user, or permanently 4.1 User Information/User “Wallet” lost. Once a user has obtained a private key (either with a smart card or • Not all machines have a method for attaching a smart having downloaded the private key from the net and decrypted it card. with a password), we propose that information about a user be available on the net. We will call this information the user’s If the user does not have a smart card, another approach is to store “wallet”. It can contain information such as the user’s credit card {priv}pwd (the user's private key encrypted with the user's number, address, and passport number. We will advocate that it password), in some location on the net (for instance a directory). also carry information that can enable any machine to recreate the There are various means of downloading the private key to the environment of the user’s home machine, such as browser machine the user is using, using only a password. bookmarks, preferences, and long-lived cookies. This requires the installation of support software (perhaps a user would separately authenticate and download the various browser plug-in) on the host machine, which should be easy for wallets, presumably with different credentials. the user’s own machine and could be constructed so as to be For instance, if it is desired to support authorization based on safely installable on a kiosk machine. which authentication method was used (as described in section The Liberty approach has user information stored at a server and 2.5), there might be a wallet that is unlockable with a password, retrieved by other servers. The server that stores the user’s and more secure information might be only unlockable with the information has access to all the user’s information at all times, so private key in the user’s activated smart card. if that server is broken into, all user information for all users can be stolen. 4.3 Establishing a relationship with a Another approach is to store this information in the user’s service provider machine. The problem with this is that this information would not So far the user has a private key, and no certificates. Certificates be available if the user were working at a different machine. are not strictly necessary for public key authentication. We propose instead a scheme where each server either certifies or We advocate that the user information be stored at a server in the stores the user’s public key. web, but that this information be encrypted with the user’s public key. This information would therefore not be accessible to the A user establishes an account with a web site through the server on which it was stored. This greatly increases security for following steps: the user. • The client machine makes an initial contact with the We also claim that it will be easier for the user to reliably and server, using current server-side authentication to be conveniently decide policy for which web sites should be allowed reasonably certain the user has reached the correct to access which information than it would be if the user had to set server. up the policy at a remote server. • The user creates an account. The account is given a The user’s machine should download and decrypt the user’s username, through some mechanism such as is done wallet. When a web site requests information, the user’s machine today. The account name on that server is stored in the can let the user know what information is flowing, and the user user’s wallet. If the user creates multiple accounts on can make decisions such as “let anyone see this information”, the same server, the wallet keeps track of all the “don’t let anyone other than my machine access this information”, usernames, and software allows the user to select from “always let this web site see this information”. It might be a these when the user visits that service provider. burden if the user must make a yes/no decision for every piece of • The user’s machine sends the server machine the user’s information, every time, but it can be made quite convenient, for public key. The server either stores this information instance, by having the wallet software fill in all the fields in a with the user’s account, or certifies the public key and form, and then let the user change or erase fields. Also, for fields sends the client machine the resulting certificate, which like “credit card number”, the user could select from a list of the user stores in the user’s wallet. credit cards. • The server sends its public key to the client machine. This approach does require reaching a 3rd party in order to The client either stores the merchant’s public key in the download the wallet (2.3) when logging in from a new client user’s wallet, or certifies the public key and sends the platform. However, this access only needs to take place once per server the resulting certificate. login session (or once ever, from the user’s home machine), as opposed to solutions such as those in section 3.3, which require 4.4 Connecting to a service provider accessing the identity provider for a token every time a service Now assume that a user already has an account with a service provider is accessed. provider. The user’s machine has first downloaded the user’s wallet. The user asks to connect to a service provider. The wallet 4.2 Least Privilege software finds the account names for that user at that service Suppose a user is using a less trusted machine, and only wants to provider, and if there is more than one, asks the user to select one. unlock a subset of his personal information. For instance, he may The user’s machine and the server perform mutual authentication want his name and address book, but not credit card information. based on the server’s and user’s public keys. If all information in the user’s wallet is unlocked simultaneously, Mutual authentication will be done with public keys. Either each then there would be no way for the user to get enough information side will have stored the other side’s public key, and there is no to print a boarding pass at the machine in the hotel lobby without need for certificates, or one or both sides can instead store a also giving that machine credit card numbers and access to all the certificate signed by the other side, and present that certificate confidential files which the user is authorized to access. during subsequent visits. This problem can be solved by having some of the information in When would it be the case that the service provider would sign a the wallet be protected with an additional level of encryption, certificate for the user’s key (and have the user store this most likely based on a password. It would be burdensome to have certificate and present it during future authentications), rather than every item of information separately locked, but it would be simply storing the user’s public key with the account? A good use practical to have some of the information directly unlocked by the case for this is when the service provider might not store any private key, and other information require an additional key to information associated with the account, but instead sign a unlock. Or to have separate wallets stored on the network, one for certificate authorizing use of the account to a particular public low-risk information, and one for higher-risk information. The key. For instance, a user might pay a site that stores information a There are several possible ways in which a site can find out about monthly subscription fee, allowing unlimited free downloads the revocation status of a user’s public key: during that month. The user might pay the site with anonymous • Each web site can check the revocation status of each cash, and create a public key (which the user keeps in her wallet) user account, communicating with that user’s revocation for use at that site, along with the certificate from the site which server periodically, or each time the user logs in. authorizes that public key to use the service for a specified time. • The web site can register with the revocation service When might it make sense for the service provider to send the when the user creates the account, so that the revocation client machine a certificate (signed by the user), rather than service will notify each of the user’s web sites if the having the user store the server’s public key in the user’s wallet? user’s key has been revoked. A possible reason for this is to keep the user’s wallet smaller. There is a potential privacy issue. The user might not want the 4.5 Unlinkable Accounts revocation service to know all the web sites that the user is A user might want it to be difficult (or preferably impossible) for registered with. However, if he uses different keys for different two web sites to compare accounts and discover which accounts sites, and possibly even different revocation servers for the are for the same identity. If the user uses the same public key at different public keys, this will help. All revocation schemes face different sites, it is evident that the accounts belong to the same painful performance vs. timeliness trade-offs. user. For this reason, a user might want to use different public keys to 4.7 Key Rollover Although section 4.6 addresses the problem of informing all the authenticate to different sites. This can be accomplished by using relevant service providers of the invalidity of the user’s old public the “main” private key (the one stored in the user’s smart card), key, the user will want to be able to resume use of his account for unlocking the user’s wallet, and storing other public key pairs, with a new public key. and the sites on which each public key is to be used, in the user’s wallet. One method of doing this is as follows: CardSpace automatically creates a different public key for signing • Before the user’s current public key becomes unusable, self-issued cards, for each service provider. the user creates a “next” public key pair. • He certifies the next public key with his current private 4.6 Revocation of the user credentials key. Call this certificate the “next key” certificate. Suppose the user’s smart card were stolen, and he wishes to change his private key. With our scheme, there is direct • He escrows the “next” private key by breaking it into n authentication between the user and a server. The user is acting as shares, with a quorum of k [22], encrypts each share his own CA, and therefore there needs to be some sort of with the public key of an escrow agent, and stores all revocation mechanism. In CardSpace, in the mode where the user the encrypted pieces in his wallet, or at some trusted is his own identity provider, revocation would need to be done storage location on the net, along with the certificate manually, with the user remembering every site with which he’d signed by his current private key that delegates to the registered with the stolen credential, and having some method of next public key. authenticating, (without the stolen credential) to assert the • If he needs to revoke his key, he obtains the escrowed authority to revoke the old credential. “next” private key (through some out of band method of This model is impractical, both because the user will not authenticating to the site that is storing the escrowed remember all the sites, and because the process of individually pieces, or authenticating to the escrow agents), and revoking the old credential at each of those sites would be stores the “next key” certificate at the revocation service onerous. URL. We advocate a one-stop revocation mechanism by use of a A web site that is checking for the user’s key validity will either “revocation service”. Such a service is trusted to inform servers retrieve from the revocation service URL in the user’s account a about revocation status of a user’s public key. status of “public key is P”, or one or more “next key” certificates. If a user needs to revoke his public key, he contacts the revocation If a web site has not checked the validity of the user’s public key service, authenticating with some sort of method other than using recently, it might encounter a string of “next key” certificates. The his private key (because he likely does not have access to his web site might be storing P for the user, and the revocation private key when he needs to revoke it). This might be with a service URL might contain “P”, “next key is P1” (signed by P), phone call in which they call his home phone back, or through an “next key is P2” (signed by P1), and so forth. email interaction similar to what is done today for password While the reassembly of the “next key” and revocation of the resets. This need not be super secure because the threat is a denial previous one can be automated, the process by which a user of service threat, not an impersonation threat, and the user has to chooses escrow agents and later authenticates to them cannot. It’s go through the same sort of procedure as he would have needed to intended that the genuine user can complete this procedure while do in order to establish the account with revocation service in the the person who has stolen the user’s credentials cannot; that first place. makes it inherently messy and fragile. Making the user experience In our scheme, when the user registers with a web site (see section straightforward, secure, and robust will be a real challenge. 4.3), in addition to telling the web site his public key, he also tells the site the URL for the user’s revocation service. 4.8 Preventing Loss of the Wallet wallet. Likewise, the server either stores the user’s public key, or certifies the user’s key and gives the Information user’s machine the certificate to store and present on If the user loses his smart card, and the user’s wallet is only stored future visits. encrypted with the key in the smart card, the user will lose all this important state. • Authentication to a server with which the user has an ongoing relationship is done using public keys. For this reason, it would be valuable to escrow the user’s private key, or escrow some other key with which the user’s wallet • When the user creates an account at a service provider, information is encrypted, if the user would not like to share in addition to telling the service provider the user’s knowledge of his private key with the escrow agent. public key, the client also tells the service provider an Escrow of a key can be done quite securely. The key can be associated revocation service. broken into shares using a quorum scheme [22] such that k out of • The service provider registers with the revocation n shares can recover the secret. Each of the shares is then service if it wishes to be notified when the user revokes encrypted with the public key of each of n escrow agents, and his public key. (or else, the service provider checks stored someplace safe. The encrypted pieces need not be given to periodically). the escrow agents until the key needs to be recovered. • If the service provider registers with the revocation 4.9 Authenticated Attributes service, the revocation service informs the service Some of the systems we covered in section 3, (e.g., Shibboleth) provider if the user’s key has been revoked. have some capability for authenticated attributes, such as proving membership in an organization whose members are allowed to use Properties of this approach: the service for free. In theory a user could acquire signed • The user has the perception of single sign-on, which is credentials, by someone authorized to assert such attributes, and done when the user activates and inserts his smart card, present them to a service provider when required to access a or downloads her private key from a server (goal 2.1). service. These credentials could be acquired at time of access to the service (as in Shibboleth), or collected and stored in the user’s • Authentication to web sites is strong, so no credentials wallet as certificates (asserting the attribute to a public key owned can be compromised by phishing (goal 2.2). by the user). If acceptable to the service, the user’s privacy could be protected by only proving the required attribute and not • Contact between a user and a server can be done revealing the user’s identity. There are issues, as we discussed in directly. There is no need for redirection to and from section 3.6, such as how a user finds a site that is trusted by the identity providers. This is more efficient (goal 2.3) service provider to assert the attribute. In theory there might be a • Contact between a user and a server works even if no single site that is completely trusted by a service provider to make other machines other than that server are currently decisions about all user attributes. This attribute assertion site reachable (goal 2.3). could make complex decisions about all the attributes, in whatever way is appropriate for each, and then simply make • User information is still available from anywhere on the assertions to the service provider. web, but encrypted, so that the user’s information is safe and directly under the user’s control (goals 2.3, 2.5, and A fully general solution to authenticated attributes has not been 2.6). proposed or deployed, and is largely orthogonal to what we propose here. If solved, it could be added to the authentication, • There is no on-line trusted service whose compromise revocation, and credential rollover solutions we propose here. can enable user impersonation (goal 2.3). 5. CONCLUSIONS • There is no on-line trusted service whose compromise In our solution there is no need for federations of identity can leak private information for large numbers of users providers and service providers. Also, no traditional PKI is (goal 2.3). needed, except for initial contact by a user with a service provider • Credential backup through a quorum of backup agents as provided with TLS today (and which would be a necessary step safely protects against credential loss (goal 2.7) in an Identity Provider solution as well). These enhancements do require changes to both clients and The basic ideas are: servers (failing to meet goal 2.8), but they can be deployed • The user carries his private key around on a smart card, incrementally with benefits accruing with each step. or downloads it from a server. • Once the user obtains his private key, he downloads the 6. ACKNOWLEDGMENTS rest of his “wallet” information from a server, which We wish to thank Eve Maler, Ray Perlner, and the anonymous stores it encrypted with the user’s public key. reviewers for helping with background information and helpful comments. • When a user wishes to enroll with a web site, the user’s machine exchanges public keys with the server, and either certifies the server’s key with the user’s private key, or stores the server’s public key in the user’s 7. REFERENCES [15] Morgan, R., Cantor, S., Carmody, S., Hoehn, W., and [1] Bellovin, S. and Merritt, M. 1992. Encrypted Key Exchange: Klingenstein, K. 2004. Federated Security: The Shibboleth Password-Based Protocols Secure Against Dictionary Approach. Educause Quarterly. pp. 12-17 Attacks. Proceedings of the IEEE Computer Society [16] Neuman, C., Yu, T., Hartman, S., and Raeburn, K. 2005. The Symposium on Research in Security and Privacy, May 1992. Kerberos Network Authentication Service (V5). Internet pp. 72-84 RFC 4120. July, 2005. [2] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., DOI=http://www.ietf.org/rfc/rfc4120.txt?number=4120. and Wright, T., 2006. Transport Layer Security (TLS) [17] Perlman, R. and Kaufman, C. 1999. Secure Password-Based Extensions. Internet RFC 4366 April, 2006. Protocol for Downloading a Private Key. Proceedings of the DOI=http://www.ietf.org/rfc/rfc4366.txt?number=4366. 1999 Network and Distributed Systems Security. February [3] Cantor, S., Kemp, J., Philpott, R, and Maler, E. 2005. 1999. Assertions and Protocols for the OASIS Security Assertion [18] Perlman, R. and Kaufman, C. 2001. PDM: A new Strong Markup Language (SAML) V2.0. OASIS Standard March Password-based Protocol. 10th USENIX Security 2005. DOI=http://docs.oasis- Symposium, August 2001. open.org/security/saml/v2.0/saml-core-2.0-os.pdf. [19] Ross, B., Jackson, C., Miyake, N., Boneh, D., Mitchell, J., [4] CardSpace. DOI=http://msdn2.microsoft.com/en- “Stronger Password Authentication Using Browser us/library/aa480189.aspx. Extensions”, 14th Usenix Security Symposium, 2005. [5] Chandra, R., Mehrotra, S., and Venkasubramanian, N. 2005. [20] Rubenking, N. 2003. PC-Mac PasswordVault 2.0. PC Pvault: A Client Server System Providing Mobile Access to Magazine, 2/13/03. Personal Data. Proceedings of the 2005 ACM workshop on [21] Scavo, T. 2005. Shibboleth Architecture: Technical Storage security and survivability (StorageSS), 2005. Overview. Working Draft 01, January 9, 2005. [6] Farrell, S. 2004. Securely Available Credentials Protocol. DOI=http://shibboleth.internet2.edu/docs/draft-scavo- Internet RFC 3767 June, 2004. shibtechoverview-01.pdf. DOI=http://www.ietf.org/rfc/rfc3767.txt?number=3767. [22] Shamir, A. 1979. How to Share a Secret. CACM vol 22. no. [7] Farrell, S. and Housley, R. 2002. An Internet Attribute 11, pp 612-613. Certificate Profile for Authorization. Internet RFC 3281 [23] Simpson, W. 1996. PPP Challenge Handshake April, 2002. Authentication Protocol (CHAP). Internet RFC 1994. DOI=http://www.ietf.org/rfc/rfc3281.txt?number=3281. August, 1996. [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., DOI=http://www.ietf.org/rfc/rfc1994.txt?number=1994. Leach, P., Luotonen, A., and Stewart, L. 1999. HTTP [24] Sxipper, http://www.sxipper.com. Authentication: Basic and Digest Authentication. Internet RFC 2617. June, 1999. [25] Tourzan, J. and Koga, Y. 2004. Liberty ID-WSF DOI=http://www.ietf.org/rfc/rfc2617.txt?number=2617. Architecture Overview. Version 1.0. Liberty Alliance Project. [9] Garfinkel, S., Miller, R., “Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook [26] Web Services Architecture. 2004. W3C Working Group Express”, Symposium on Usable Privacy and Security, 2005. Note. DOI=http://www.w3.org/TR/ws-arch/. [10] Herzberg, A. and Gbara, A. 2004. Security and Identification [27] Wu, M., Miller, R., and Garfinkel, S. 2006. Do security Indicators for Browsers against Spoofing and Phishing toolbars actually prevent phishing attacks? Proceedings of Attacks. Cryptology ePrint Archive, Report 2004/155. DOI= the 2006 SIGCHI conference on Human Factors in http://eprint.iacr.org/2004/155.pdf. computing systems. 601-610. DOI= http://portal.acm.org/citation.cfm?id=1124863. [11] Hess, A., Jacobson, J., Mills, H., Wamsley, K., Seamons, K.E., and Smith, B. 2002. Advanced Client/Server [28] Wu, T. 1998. The Secure Remote Password Protocol. Authentication in TLS. Network and Distributed System Proceedings of the 1998 Internet Society Network and Security Symposium, San Diego, CA. February 2002. Distributed System Security Symposium. March 1998. pp. 97-111 [12] Housley, R., Polk, W., Ford, W., and Solo, D. 2002. Internet X.509 Public Key Infrastructure Certificate and Certificate [29] Yee, K., Sitaker, K., "Passpet: Convenient password Revocation List (CRL) Profile. Internet RFC 3280 April, management and phishing protection", Proceedings of the 2002. second symposium on Usable privacy and security (SOUPS), DOI=http://www.ietf.org/rfc/rfc3280.txt?number=3280. 2006. [13] Jablon, D. 1996. Strong Password-Only Authenticated Key [30] Zhu, L. and Tung, B. 2006. Public Key Cryptography for Exchange. Computer Communication Review, Vol. 26, no. Initial Authentication in Kerberos (PKINIT). Internet RFC 5, ACM SIGCOMM. October 1996. pp. 5-26 4556. June 2006. DOI=http://www.ietf.org/rfc/rfc4556.txt?number=4556 [14] Kaufman, C., Perlman, R., and Speciner, M. 2002. Network Security: Private Communication in a Public World. Prentice Hall PTR. pp 307-336. 3/4/2008 User-centric PKI Radia Perlman Charlie Kaufman Radia.Perlman@sun.com charliek@microsoft.com 1 Motivation • Why can’t things be simple? 2 1 3/4/2008 Motivation • Why can’t things be simple? • I can’t cope with username/pwds – I’m not alone… • The federated identity things seem really complicated to me 3 I don’t care about formats • “Certificate” is any signed thing 4 2 3/4/2008 My view of federated things • Microsoft created the “Passport” vision, with Microsoft the center of the world • Others said, “Hey, let’s not anoint one organization to be an eternal monopoly • So, the notion of lots of IDPs, and a federation is the set of SPs that trust that IDP 5 If there is just one IDP • User authenticates to that IDP • That IDP vouches for the user at all the affiliated sites 6 3 3/4/2008 But what if there are hundreds? • And what if the SPs the user wants to use affiliate with different subsets of them? 7 And what value does the IDP give, anyway? 8 4 3/4/2008 Downside of IDP (vs. peer-to-peer mutual authentication) • Security (on-line IDP can impersonate all users) • Availability (if IDP is down, nothing works) • Performance (bouncing around between boxes) • Privacy (IDP knows everyone you talk to) 9 Upside of IDP • ? 10 5 3/4/2008 Quick rant on today’s web 11 Perils of Perlman 12 6 3/4/2008 Buying something • Scenario: Buy something from a merchant you haven’t bought from recently • All prepared with your info, credit card, etc. • It asks you for your email address… 13 You’re a returning user! • Type your username and password! 14 7 3/4/2008 You’re a returning user! • Type your username and password • Of course you can’t remember it, so… 15 You’re a returning user! • Type your username and password • Of course you can’t remember it, so… – you manage to find “recover username” 16 8 3/4/2008 You’re a returning user! • Type your username and password • Of course you can’t remember it, so… – you manage to find “recover username” – suddenly you are in a Monty Python movie • Answer the following questions three: – Telephone number – Address – Mother’s maiden name 17 axã eâÄx • It should be no more onerous to be a returning user than a new user 18 9 3/4/2008 Security questions for password/username recovery • Favorite sports team • 2nd grade teacher’s name • Pet’s name • Father’s middle name • My middle name 19 axã eâÄx • Security questions must be specifiable by the user • I’d say “or selectable from a very large list”, but I’m sure they can come up with an arbitrarily long list of questions I can’t answer 20 10 3/4/2008 Security question in comedy routine (Q&A Chosen by user, to be asked by the bank for phone verification of customer) 21 Security question in comedy routine • Question: “Are you wearing underwear”? 22 11 3/4/2008 Security question in comedy routine • Question: “Are you wearing underwear”? • Answer: “I don’t think that’s an appropriate question” 23 Keeping customer information • I do not want to do “single click ordering” • I do not mind typing in my address • I do not mind typing in my credit card number • Merchants insist on keeping all of this information • And eventually this information gets stolen 24 12 3/4/2008 axã eâÄx • After a merchant is paid, any subset of information about a customer (including all of the information) must be expunged by the merchant at the customer’s request 25 Simple intra-organizational PKI 26 13 3/4/2008 Within an organization • Should be trivial, single CA • To create an account – Sysadmin told username and initial pwd – Types that into “create new account” tool – Tool generates key pair, certifies public key, encrypts private key with pwd, stores cert in dir • User logs in – Types name and pwd, retrieves private key – Accesses resource: authenticates with public key 27 Better with smart cards • Badges have smart cards. What’s the problem? • Doesn’t do mutual authentication, but could, by having everything (including client machine) know CA’s public key 28 14 3/4/2008 And, IDP and Kerberos also work • Within an organization, also easy to have everything trust the same KDC, or IDP • But better without having an online trusted box 29 Online vs offline trusted box • Performance, availability • Security – Can impersonate all users – More likely to be compromised vs offline box – Knows who is talking to who – May have database that if stolen, can compromise users 30 15 3/4/2008 But our talk is really about individuals 31 How about individuals? • Think of this as just doing what we do with username/pwd, but more securely, and without torturing the user • Assume first the user has a smart card with a secret (private key, or secret key) 32 16 3/4/2008 “Wallet” • A bunch of data cryptographically protected with the user’s smart card secret • Downloadable from one or more places • Contains, for instance, public keys of various merchants, perhaps private keys to use with that merchant, information such as passport number and credit card numbers 33 Enrolling at a site • Just like today, except username/pwd is replaced by “public key” • The wallet information (such as address) can be filled into the form, to save the user typing, or the user could drag info she wants into the form • The SP sends the user its public key 34 17 3/4/2008 Enrolling Depend on current SSL-PKI “create account” Client SP Stuff I want from you User cuts and pastes from wallet, or software makes best guess filling in fields and user can erase or change fields Wallet {addresses} {credit cards} {telephone numbers} Passport number Per site info (its public key, your key pair for that site) 35 Note • Instead of enrolling with a username and password, your account name is your public key, and you authenticate with your public key • And by saving the SP’s public key (a la SSH), you can do mutual authentication, knowing you are again reaching the same site as before 36 18 3/4/2008 Revisiting the site • Mutual authentication using public keys (e.g., SSL with client certs) 37 One-step revocation • Suppose you are using your public key at lots of sites – (not sure how useful different keys for each site is) • And someone steals it • Use “revocation service” 38 19 3/4/2008 Enrolling Depend on current SSL-PKI “create account” Client SP Stuff I want from you My public key URL of my revocation server Wallet {addresses} {credit cards} {telephone numbers} Passport number Per site info (its public key, your key pair for that site) 39 Revocation service • SP learns user’s revocation server along with the user’s public key • SP can “enroll” with that revocation service, to be notified in case of revocation • Or SP can check periodically • User has to have some sort of out-of-band mechanism to authenticate and revoke the key • User can store {next keys} signed by current key, and escrow the future private keys 40 20 3/4/2008 Authenticated attributes • User can have, in wallet, certs signed by whoever is trusted to assert the attribute, that a public key associated with the user is over 18, a citizen, whatever • Can send such certs to SP when needed, along with proof of knowledge of the private key 41 Yes, things can go wrong • Establish trust, then after increasingly large purchases, skip town • Credit cards today somehow work “well enough” – certainly could be improved, but banks seem to think it’s not worth the bother 42 21 3/4/2008 Federated Identity: What is it? Client (User) Server (Sometimes) Identity Provider (IDP) Many variations on this theme: IDP holds secret information needed by client to authenticate to server. 43 Federated Identity: What problems are we trying to solve? • Something more convenient for the user than username/password? • Something more secure than username/password? • Reducing aggregate administrative costs of maintenance? 44 22 3/4/2008 Federated Identity: What problems are we trying to solve? • Something more convenient for the user than username/password? • Something more secure than username/password? • Reducing aggregate administrative costs of maintenance? • Something new we can implement, publish papers about, and use to excite customers? 45 What do users want? • Don’t want to remember so many usernames and passwords • Don’t want to type usernames and passwords as often • Don’t have to type address/phone number/email address as often • Less hassle when I forget a password or someone steals it 46 23 3/4/2008 What do users not want to give up? • Sign-on from anywhere • Not needing to carry smart cards or other hardware • Ability to have lots of accounts at a single vendor, share some accounts (without sharing all of them) • Having more than one credit card • Having more than one email address, phone number, etc. and choosing which to give to a site 47 Users’ Security Goals? • For most, vaguely understood worries about ‘identity theft’ or ‘stolen credit card numbers’ • For a few of us geeks: – Servers can’t correlate identities – Some degree of anonymity – No authority can know all the things I do – Not putting ‘all eggs in one basket’ in case of kiosk or hijacked machine 48 24 3/4/2008 Reducing Administrative Costs • Users forget usernames & passwords – Centralize password reset – Less often if fewer to remember • Recovery when passwords are stolen – Revocation in bulk rather than site by site – Correlate suspicious activity • A wallet full of smart cards is impractical – A single hardware token should work with many services 49 Service Provider Security Goals • Authentication that’s harder to compromise – Get users to choose hard to guess passwords and not use the same ones on multiple sites – Make phishing attacks and other network based attacks harder to mount • Discourage users from sharing subscriptions • Make it easier to track down users who misbehave 50 25 3/4/2008 Special Cases • My credit card number should not be secret – Purchases should be authorized through some strong protocol – Issuing banks or alternate intermediaries like PayPal should deploy this – should not be linked to other aspects of federation • If I get a AAA or AARP or ACM discount, proof of membership should be partly automated 51 The Allure of Federated Identity • Authenticated attributes (sometimes with anonymity) – Classic examples: • Age > 21 • Employee of Microsoft • Member of IEEE • Paid attendee of IDTrust 2008 • What is the end-to-end scenario in which this is useful? 52 26 3/4/2008 Bottom Line • Current State of the Art is awful! • Something simple based on roaming credentials and SSL client certificates could solve the most important problems • Federated identities could potentially solve those same problems, but they are harder to deploy and no better 53 Bottom Line • Current State of the Art is awful! • Something simple based on roaming credentials and SSL client certificates could solve the most important problems • Federated identities could potentially solve those same problems, but they are harder to deploy and no better • Why is the world so excited about them? 54 27 Federations in R&E: Current Soup and Future Bread Topics • The Research and Education Sector • Shibboleth • InCommon and international R&E federations • Next Steps • Inter-federation soup • Collaboration management platforms and the attribute ecosystem Presenter’s Name The Research and Education Sector • Intense need to collaborate • For both research and education • Inter-institutional and international • Historic roles • Innovator in networking • Technology transfer • Shaping a new generation of consumers Presenter’s Name R&E Engagements • TCP/IP, first as a technology and then as a market-maker • SAML/Shibboleth, first as a technology and then as a market-maker • Collaboration tools and collaboration management platforms Presenter’s Name Shibboleth • Deployments > 10,000; countries > 20 • Shib 2.0 release ~ Mar 4, 2008 • Landmark release; strong platform for years to come, on which considerable enhancements will be broadly provided • “More interoperable with commercial SAML systems than they are with each other” • OpenSAML 2.0 already heavily used by Verisign, Tata, etc. • It is suggested that federations migrate to 2.0 sooner than later. Presenter’s Name Shib and OpenId • Shib 2.0+ containing an OpenId provider under discussion • Shib 2.0++ may contain more clever and useful integration of federated and ad hoc identity management • The OpenId platform within Shib will have a warning reminding applications to use caution in their consumption of external identities. • UK leading development, with broad conversation, but OpenId is generally a US concern. Presenter’s Name Missing pieces • End-user attribute release management • InfoCard? • Attribute release editors within Shib • Dynamic metadata (not dynamic trust) • N-tier tokens Presenter’s Name InCommon •Approximately 80 members and growing steadily •More than two million “users” •New types of members • {St. Mary’s of the Plains} • National Institute of Health • Student service providers • Energy Labs • MS, Apple •On third generation of Steering Committee •Has less value right now than it will… Presenter’s Name The DreamSpark Nightmare • Microsoft delivery of developer kits, source code, etc to students • Shows how far down you can bury federation in the user experience (and way under a LiveId and custom WAYF) • A learning experience for us all • Showed the value in implementing the full features of Shib (such as the ePTId generator) • http://www.pcworld.com/article/id,142597-c,software/article .html • https://downloads.channel8.msdn.com/ • Asserting “studentness” is highly useful Presenter’s Name InCommon Next Steps • New members • MS, Apple, Michigan, University of Mary Washington, William and Mary, Lafayette, Emory, Richmond • Pending – MIT, Google, student service companies, medical consortia, 1200 institutions from the National Student Clearinghouse • InCommon Silver • LOA-2 • Not hard but lots of thought upfront – profiles, audit guides, etc. • Rich new set of applications from NIH • Intended to be ultimately revenue neutral • Remarkable barn-raising experience so far… Presenter’s Name Federations • Almost everywhere now • Internationally – UK (2-3 new members a day), Spain, France, Sweden, Finland, Switzerland, Netherlands, Germany, Denmark, Norway, Australia, Brazil, Japan, Canada, etc. • State university systems • Community college libraries • Medical associations • DoJ and DoD • All do SAML; most are Shib • Limited interfederation interactions – Kalmar Federation, UK-Australia, MS, Elsevier Presenter’s Name International federation highlights • Several countries at 100% coverage, including Norway, Switzerland, Finland • Community served varies somewhat by country, but all are multi-application and include HE • UK intends a single federation for HE and Further Education ~ tens of millions of users • Real use cases involving international team science now driving interfederation peering urgency Presenter’s Name International Activities • http://www.terena.org/activities/refeds/ • A summary of discussions among R&E networks, including a survey of national efforts • http://www.jisclegal.ac.uk/access/ • Excellent policy analytics, especially around international issues of privacy, peering, and attributes • http://ec.europa.eu/idabc/ • TransEuropean activities in IdM for use among citizens, governments, and businesses Presenter’s Name IDABC • IDABC stands for Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens. • http://ec.europa.eu/idabc/en/document/6484/5644 • eID Interoperability for PEGS -Report on interoperable eIDM technical solutions, December 2007 ( http://ec.europa.eu/idabc/servlets/Doc?id=29619). Offers technical assessment of several technologies • Final recommendations due soon. • Federated approaches are likely; open source standards may be identified Presenter’s Name Interfederation • We used to know more… • We thought there was primarily peering and we could do that • Things changed… • A rich mix of emerging relationships – nested, leveraged, peered, orthogonal, etc. Presenter’s Name Some of those relationships • Nested – UC Trust and InCommon • eduRoam – single application cross- federation • Texas • Multi-homed SP –Microsoft, Elsevier, student service industry, etc. Presenter’s Name Peering • Efforts between InCommon and EAuth collapsed a while ago • We got close, but EAuth priorities changed • International Peering • UK Feasibility analysis • Attribute Alignment • Privacy due out in May • Peering drafts to follow Presenter’s Name Some of the bases to touch in peering • Typical issues - • Problem resolution and adjudication, liability and indemnification, financial considerations, impact on member agreements, etc. • New issues - • Metadata exchange • Attribute mapping • Transitive trust Presenter’s Name UK Bilateral Interfederation Template • Purpose, scope and limits of agreement • Entity assurance • Member-operator behavior • Problem resolution • Member-member behavior • Interfederation infrastructure Presenter’s Name Peering Parameters Parameters: •LOA •Attribute mapping •Legal structures • Liability • Adjudication •Metadata •VO Support •Economics •Privacy Presenter’s Name Federation Soup • Workshop to held early June, with NSF support likely • Bringing together all manners of federation to figure out federation relationships • InCommon, JISC, state federations, library federations, university system federations, grid federations, etc. • Topics include alignment of policies, technologies, attributes, metadata, etc. • Approaches include peering, nested, leveraged, and a whole lot of ad hoc • Outputs may include best practices, multi-homing, etc. Presenter’s Name Emerging key themes • Privacy and consent • Privacy and the aggregation of attributes • The glory of ePTID • Support of collaboration and virtual organizations • Complexity • Lack of federal law coupled with state laws Presenter’s Name Future issues • Filling in some of the missing policy pieces • Dynamic metadata, maybe dynamic trust • End-user experience – wayf and privacy manager • Attribute mapping • Federations as trusted metadata sources • Inter-federation • Collaboration management platforms and the attribute ecosystem Presenter’s Name Collaboration and Federated Identity • Two powerful forces being leveraged • the rise of federated identity • the bloom in collaboration tools, most particularly in the Web 2.0 space but including file shares, email list procs, etc • Collaboration management platforms provide identity services to “well-behaved collaboration applications” • Results in user and collaboration centric identity, not tool-based identity Presenter’s Name Collaboration Management Platforms • Management of collaboration a real impediment to collaboration, particularly with the growing variety of tools • Goal is to develop a “platform” for handling the identity management aspects of many different collaboration tools • Platform includes a framework and model, specific running code that implements the model, and applications that take advantage of the model • This space presents possibilities of improving the overall unified UI as well as UI for specific applications and components. Presenter’s Name Comanage • A collaboration management platform, supported in part by a NSF OCI grant, being developed by the Internet2 community, with Stanford as a lead institution • Open source, open protocol • Uses Shibboleth, Grouper, and Signet • Parallels activities in the UK and Australia Presenter’s Name Comanageable applications • Already done • Sympa, Federated wikis, Asterisk (open-source IP audioconferencing), Dim-Dim (open-source web meeting), Bedeworks (federated open-source calendar) • Immediate targets • Rich access controlled wikis • Web-based file shares, IM, Google Apps for Education • Domain science resources • Instruments • Grids Presenter’s Name Some general COmanage comments • A limited number of consoles present the basic identity services; can move directly between services as a standard workflow • Early in the development; the GUI is particularly primitive • Underlying store is an LDAP directory; alternatives include MySQL db, RTF store, etc. • COmanage can be deployed by a campus, a department, a VO, a VO service center; COmanage instances communicate with each other by the “attribute ecosystem” voodoo Presenter’s Name Collaboration Management Platform (CMP) and the Attribute Ecosystem Collaboration File Email Phone/ Federated Domain Domain Calendar List Video Science Science Tools/ Resources Sharing Manager Conference Wiki Instrument Grid Application Attributes Collaboration Management Authorization – Co Authorization – manage People Other Authentication Platform Group Info Privilege Info Picker Functions Attribute/Resource Info Data Store Attribute Ecosystem Flows Home Org & Id Providers/ Sources of Laboratory X Sources of University A University B Authority Authority How Collaboration Management Platforms (CMP) Communicate Federation Co Campus SAML Attribute Co Linked Ecosystem Identities Virtual Co Virtual Organization Organization Service Co Batch Center Key Co Co COmanage CMP Presenter’s Other Name CMP Discussion Topics • Likeliness of other vertical sector federations • Peering between a service sector vertical and R&E federations • Federations and OpenId • Government interactions and federations • Sanctioned sources of authorities for attributes • Other roles for federations • As trusted distributors of other metadata Presenter’s Name Federation: Today and Tomorrow March 5, 2008 Patrick Harding CTO Ping Identity • Market Leader for Secure Internet Single Sign-On • Founded in 2002 • Based in Denver, Colorado USA • Privately held © 2007 Ping Identity Corporation 2 Yesterday • The Register – “OASIS Ratifies SAML” - 11/2002 “SAML SAML is an XML XML-based based framework for web services, that allows the exchange of authentication and authorization information among business partners. It enables web- based securityy interoperability p y functions,, such as single g sign-on, across sites hosted by multiple companies” “PKI PKI has been dogged by issues of complexity, integration difficulties and user apathy” http://www.theregister.co.uk/2002/11/07/oasis_ratifies_saml/ © 2007 Ping Identity Corporation 3 These Enterprises Are All Federating © 2007 Ping Identity Corporation 4 So Are These Service Providers © 2007 Ping Identity Corporation 5 B2B Federation Today • Protocol Debate is Over • Organizations Have Enabled 5 – 10 Federation Connections ` The Value of Federation Has Been Justified • Common Business Scenarios Have Become Apparent © 2007 Ping Identity Corporation Common Use Cases • Outbound SSO ` for users to access software software-as-a-service as a service (SaaS) applications, applications business process outsourcing (BPO) services, and trading partners • Inbound SSO ` for relationships such as BPOs and managed services where external users access the enterprise’s resources over the Internet • Internal SSO ` for the enterprise and its acquisitions, affiliates, subsidiaries and joint ventures • SSO to third third-party party hosted industry hubs ` for information sharing by users and application access among industry organizations © 2007 Ping Identity Corporation 7 Today Federation is Enterprise-Centric BPO Provider Service Customers Business P id Providers BPO Provider Customer Business Software on Customer Demand Provider Enterprise Business Software on Customer Demand Provider Dealer Supplier Content Trading JV Partner Provider Partners “High Leverage” Partner Drives Federation © 2007 Ping Identity Corporation The Federation Challenge Identity Federation Can Takes 6–9 6 9 Months to Implement with Some Vendors 60 days per 50 partners x = Over 12 years connection Does not scale! “Federation has been dogged by issues of complexity, integration difficulties and user apathy apathy” © 2007 Ping Identity Corporation 9 Not Always a Business Issue • Perception p that lawyers y must get g involved • Companies rely on existing business contracts to address: ` Operational service level agreement disputes ` Liability associated with protecting sensitive information • Most Service Providers are actually happy to out source authentication to their customers and partners © 2007 Ping Identity Corporation 10 Technical Friction • Partners must negotiate which of many, many many, many many SAML options to use ` Multiple profiles & bindings ` Multiple identifier options ` Fl ibl attributes Flexible tt ib t ` Authorization overloaded onto authentication • Service Providers NOT leveraging SP-Initiated SP Initiated SSO ` IdP Selection/Discovery is poorly defined • Products require manual configuration of partner information • Certificate Management is problematic ` Trust established through manual exchange of certificates © 2007 Ping Identity Corporation 11 Speed to Connect is Crucial • Simplifying Federation Connectivity • Publish Conventions and Best Practices ` IIndustry d convergence on POST/Redirect POST/R di bi bindings di ` Optionally use email address/domain for IdP Discovery • Automated meta-data exchange • Dynamic domain-based trust • Standard Attribute Schemas for B2B © 2007 Ping Identity Corporation 12 What’s Coming? • Business Themes • User-Centric User Centric Use Cases? ` Collaboration • OpenID ` Cloud Computing • CardSpace ` Master Data Management ` Increasing Internet Crime • High Assurance/PKI ` SaaS & OnDemand Apps pp Environments • Identity Assurance Framework • Federated Web Services • Holder Holder-of-Key of Key SAML ` REST vs. SOAP POST ` User Present (or Not) ` oAuth vs. WS-* vs. ID- WSF © 2007 Ping Identity Corporation 13 Identity Assurance Expert Group (IAEG)  Goal: to foster adoption of identity assurance services, and uniformity and interoperability amongst identity service providers by promulgating overarching values  Public SIG exists alongside to solicit and encourage broad public participation 1 IAEG Key Activity: Identity Assurance Framework  GUIDANCE (vs. policy) on what Federation members should consider and have policies for  1.0 focused on IdPs/CSPs; Future phases to consider RPs & Federation Operators  Enable Federations to map their policies, practices and technologies to each other and ensure comparable trust levels  HARMONIZED, BEST-OF-BREED industry identity assurance approaches  Re-use contributions from other sources (EAP, US E-Auth Federation, T-Scheme, TSCP, others)  Build upon accepted industry standards  NEUTRAL, COMPREHENSIVE & GLOBAL  Cover all aspects of identity assurance: risk classification and assurance levels, service assessment criteria for organizations, credential management & identity proofing; business rules and certification models Liberty IAF: The Picture Liberty Alliance Identity Assurance Framework Upcoming Activities  IAF in draft review  (http://www.projectliberty.org/liberty/content/download/3736/24651/file/lib erty-identity-assurance-framework-v1.0.pdf)  Public webcasts:  March 5, 8 am PT, Credential Management Service Assessment Criteria  March 12, 8 am PT, Identity Proofing Service Assessment Criteria  March 26, 8 am PT, Certification/Accreditation Business Rules  Public input welcome: https://maa.projectliberty.org/id/idf-feedback.html  Panel Session, RSA Conference, SF, April 9, 9:10 am  Pre-Conference workshop, TowerGroup Conference, Boston, May 28  Panel Session, Gartner Identity and Access Summit, London, June 23-25  Panel Session, Burton Catalyst Conference, San Diego, June 23-25  Others, TBD Backup Why was Liberty Alliance Formed?  Foster the ubiquitous, interoperable, privacy-respecting, identity layer (holistic identity management):  Liberty represents all constituencies toward this objective  (vendors, enterprise, government, consumers, universities, SME’s, etc.)  Must be an open, collaborative system vs. single vendor strategy  Identity is important & complex. We must come together OR:  industry will become more fractured  governments will intervene  Develop privacy-compliant practices to exchange identity information  Develop standards-based model to …  Interoperate in heterogeneous environments  Avoid proprietary vendor lock-in  Provide flexible foundation for future growth  Scale to the WWW  Deliver consumer & enterprise confidence that security, privacy and data integrity will be maintained 6 More than Technology Technology Standards and Guidelines Business and Privacy Guidelines Assurance An Ecosystem of Interoperable Products & Services Identity Assurance Framework & Assessors 7 The Liberty Process - Market Centric  By …  Listening to the Market  Collaborating with other relevant groups  Documenting the requirements  Developing specifications and frameworks to meet the needs  Certify the products & assessors  Continuous evolution and improvement 8 Identity Assurance Roadmap  Phase One of Certification Program for CSPs/IDPs, ratified in Identity Assurance Framework v1.0 FINAL (Q2 2008)  Launch Accreditation Program to enable the Certification model and spur the market (Q2 2008)  Scope and define Phases 2 and 3 for Federation Operators and Relying Parties (begins Q3 2008) 9 Getting Involved with Identity Assurance Liberty Alliance Identity Assurance Expert Group (formal membership in Liberty Alliance is required) http://www.projectliberty.org/liberty/membership/become_a_member Identity Assurance Special Interest Group (formal membership in Liberty Alliance is not required) http://wiki.projectliberty.org/index.php/IASIG Identity Assurance Framework for Review and Comment http://www.projectliberty.org/liberty/content/download/3736/24651/file/liberty-identity-assurance- framework-v1.0.pdf 10 ID-Trust: Liberty Alliance Panel Advancing Common Levels of Trust An Operational Perspective Policy rules, agreements Vendor product support PKI and trust agreements Managing the trust agreements over time – an operations view 2 Policy rules, agreements  Get aligned  Policy harmonization  Agree on definitions: NIST assurance levels, ANSI standards, etc. – extend / connect with enterprise policies  Extra-organizational policy  If possible, leverage high level terms and positions on implementation issues – subscribe, translate, and qualify  Stay aligned  Rate of change  Understand the requirements of change  Plan for the change process  Backward compatibility  Recognize that all agents won’t keep pace  Attempt to keep all agents subscribed  Risk level changes, etc.  Recourse and penalty  There will be non-compliant applications. Plan for it. 3 Vendor product support A better dialog required Requests for standards implementation Application certification (interoperation) Ask for instrumentation Assume the need for application meta- information and output to analytic products 4 PKI and trust agreements Ad-hoc, non-SAML, PKI “federations” Extra-enterprise trust domains? Defined by the “relying-application” Either active or passive Application level domains? Defined as enterprise or extra-prise Industry [pki] Trust-Authorities Default [pki] trust-stores (appropriate?) Industry Trust structures: benefits? 5 An Industry Trust Authority – Who does it help? How? Technology, Business, or both? Business Process Enhancement? Information Security Improvement? FI Compliance Policy Improvement? Customer Experience Improvement? 6 Managing the trust agreements over time – an operations view Domain Issuer Credential Server Application Issuer Virtualizer Network Validator LDAP Authorization Facilitator attributes Policy information Domain Root or bridge credential Long-term, little change End User Issuer Credential Issuer credential Changes periodically End-entity certificate Changes regularly 7 A Financial Industry Bridge Certification Authority  Support growing digital certificate use in Financial Institutions  (Technology)  PKI has moved from a “star” technology to a role as second-clarinet in the technology orchestra  Digital certificates in heavier use as internet utilities become e-transportation network  Enable businesses to snap together new connections: less cost, new products faster  (Business Processes)  Using best / favorite certified digital certificate provider instead of negotiating and building connections for each project / service  Secure connections with strong, standard security components and protocols (Information Security enhancing)  Using FI policy approved digital certificate issuers, FIs reduce risk of trusting the un- trustworthy  Maintain connections with a strong policy framework across institutions (Policies and Compliance)  The non-technical… a policy / trust authority board to decide which issuer certificate authorities conform to FI standards and requirements  Interact with customers using strong, financial-Institution issued credentials (Customer experience)  Defining a trusted set of issuers with common issuance policies, regularly certified for use outside of a single institution. 8 Conclusions 1. Identify good policy – subscribe and maintain 2. Work with vendors to deliver robust standards based products 3. Observe to formation of informal, un-defined “federations” [not necessarily SAML] 4. Bridge PKI and federation are not exactly the same thing 5. A federation could provide a bridge service as part of a federation 6. Trust agreements are not one-time static events 9 Multi-Domain Identity Management Deployment Interoperability, Validation and Certification 7th Symposium on Identity and Trust on the Internet (IDTrust 2008) Lena Kannappan, Founder & CEO, FuGen Solutions, Inc. Connecting Identities Everywhere.™ March 4-6, 2008 Copyright 2006-2008 FuGen Solutions, Inc. - Confidential FuGen Solutions FuGen Solutions enables successful Multi-domain Identity Management Deployments FuGens’ MISP™ Services include:  Managed Identity Interoperability and Compliance Verification  Federation Partner on-boarding  Federation Partner Certification program implementations  On-going real-time monitoring and reporting  Founded in February 2006, privately held, HQ’d in Sunnyvale, CA  Customers include Financial Institutions and Government Agencies “The path to simplicity in Identity Management is not so easily bought. Outside the lab environment, enterprises have a staggering and complex array of products intersecting with ever-changing demands.” The Burton Group Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 2 Federated World  Federation Models & Communities 1. Corporate Federation 1. Internal/External 2. Identity Federation (COT) 3. Internal/Intranet Federation 4. IDP to IDP Roaming/Proxying 5. Federated Communities 6. Identity Brokering models  Standards  SAML 1.1, SAML 2.0  Shibboleth  Liberty Alliance  WS-Federation  WS-Trust, WS-Policy (WS-*)  IDP or IP Centric Customers  SP Centric models or Relying Parties  Pairwise IPs and RPs  Distributed Identity issuers Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 3 Identity Management: Model of the Future SP Ecosystem of Enterprises IdP IdP IdP IdP User Store User Store “SaaS” Applications SP SP SP SP SP CRM HR MRP IdP Enterprises will need to adapt to the user centric model as enterprise users will require access to consumer services Who to trust and how? How to manage the identity “network”? Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 4 Enterprise Identity Management Deployment Models Model #1: Delegated Domains Model #2: Multi-Domain with Same IdM Technologies Cascading Business Rules & Policy Different Business Rules & Policy Corp – Parent Corp B Federation Corp A Delegation Delegation Corp – Regional Federation Location Corp – Subsidiary Corp C Corp A Federation Federation Federation Corp D Corp B Corp C Proprietary OpenSource Identity & Access System Implemn Model #3: Multi-Domain with Different IdM Technologies Connecting Identities Everywhere.™ Different Business Rules & Policy Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 5 Corporate Federation COT - External Service Providers BUSINESS FOR Business 401 K CUSTOMERS Appln EMPLOYEES Partner #1 WS-Trust Business End End Partner #2 Point Point Travel End End Point www.companyIDP.com Point ADFS HR Svcs End WS-Fed Point Business Partner #3 Security End SAML 2.0 Product Point End Point End Point ASP Service #2 ASP Service #1 OUTSOURCING Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 6 Primary Authentication Methods RF Badge  Automated Login  Active Directory, NT  User Id/Password Token  Native SSO Biometrics  LDAP  Token LDAP  RSA SecurID Smart  PKI Digital Certificates Card  Smart Cards, USB Keys  Kerberos User ID &  Strong Authentication PKI Password  2 Factor Auth Digital  Biometrics Certificate Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 7 Multi-Domain IDM Deployment Interoperability Federated Identity Management Business Criteria Regulatory and Compliance Standards Governance and Policy aspects Technology requirements Privacy implications Security and Trust needs Legal requirements Identity Provider Service Provider CA CA IBM IBM MSFT OASIS SAML 1.1 / 2.0 MSFT Sun WS-* (Security, Trust, Federation, …) Sun RSA Liberty Alliance ID-WSF RSA Ping Identity OpenID, Higgins, OAuth, XRI/XDI Ping Identity Open Source Open Source OpenID OpenID Web2.0 Web2.0 Custom Custom Others Others Client Identity Technology: CardSpace, OSIS, Higgins Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 8 Current Federation Architecture Deployment Issues  Fast emerging technology/need;  Multi-protocols, Several Features Companies moving towards / Sub-Features Federation  Partner Disparate infrastructure  Need of federation not understood  Trust models due to lack of knowledge as well as  Policy and Legal aspects lack of resources to deploy; Leads  Various Authentication to poor or failed implementation mechanisms, Encryption  Deployment Interoperability and methods Verification; Standards compliance  Types of Assertions  Need to minimize risks/guesswork  Data integration issues  Deployment profiles Identity Mapping, Attribute Mapping, Meta Data Exchange and Policy mapping issues Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 9 Deployment Interoperability challenges and Need beyond Product level certifications Business Drivers Federation Solutions & (top-line, Standards Technology Bottom-line) Choices Choices Business ………….…………………....Technology Standards & Technology (SAML, WS-* Liberty, etc) Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 10 Deployment Interoperability challenges and Need beyond Product level certifications Business Drivers Federation Solutions & (top-line, Standards Technology Bottom-line) Choices Choices Business ………….…………………....Technology Best Deployment Practices Profiles Standards & Technology (SAML, WS-* Liberty, etc) Interoperability & Cross-Domain Issues Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 11 Deployment Interoperability challenges and Need beyond Product level certifications Business Drivers Federation Solutions & (top-line, Standards Technology Bottom-line) Choices Choices Inter-Federation, Best Deployment Certification and Practices Profiles Accreditation Deployment Profiles Standards & (business, compliance, governance, policy, tech criteria) Technology (SAML, WS-* Liberty, etc) Product Level Conformance Interoperability & Standard/Protocol Cross-Domain Issues Profiles Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 12 User Centrism models in Federation SP/RP SP/RP User User User User AP/AB IDP IDP/IB User User IDP/IB SP/RP SP/RP User Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 13 Identity Management Challenges for Consumer Service Providers Other OpenID providers IdP SP IdP IdP Service Providers Web 2.0 users need to develop an demand ease of ecosystem of use and choice of trusted IdPs identity provider SP SP IdP SP Other OpenID Relying Parties Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 14 User Privacy model for Providers User Consent Service Provider/ Identity Provider Usage Directives Relying Party policy policy User Policy Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 15 Next Generation thinking to User profiles and Privacy framework Converged Government Services profile Profile Healthcare Google, Yahoo … profile profile User Federation Centrism Employer/ Blogs, Wikis Enterprise profile profile • Layered user profiles •Multiple personas Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 16 Closing Thoughts  User Centrism and Federation and NOT User Centrism Vs Federation  Strong Authentication will play a significant role in Federation  Standards and industry efforts still need to mature – cohesive approach is important  SAML, Web Services and Light weight technologies will co-exist  Layered profiles for the converged, ubiquitous and federated world; New generation privacy framework will emerge while embracing current successful models  Identity Assurance Services – Inter Federation Requirements – Assessment and Accreditation of Federations  Need to tackle Identity Architecture Deployment Interoperability challenges to increase adoption ! Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential 17 Questions Connecting Identities Everywhere.™ Copyright 2006-2008 FuGen Solutions, Inc. - Confidential Liberty Alliance Identity Assurance Framework from a practical point of view ... in a Danish context Jan Riis jri @ lakeside.dk IDTrust’08 - NIST - Gaithersburg - 2008-03-05 A little History  Danish Healthcare has been working 3 years with Identity Based Web Services  2005 MedCom and Danish Regions  ”Competed” for the first standard/profile  No governance towards standardization:  No Authentication levels defined  No high level architecture for WS communication  No criteria for assuring trust of key WSP’s Consequences  Parties started out with 6 levels of ”authenticity”  Some based on PKI  Some based on username/pwd  Some levels for ”delegated trust” (systems vouching for user authenticity)  Some levels target cross-cutting security properties (non-repudiation of messages etc.) There is a need for IAF!  ITST standardized authentication levels in 2006 for all public systems  Directly referred to NIST work  2007 Health sector standards were aligned with national guidelines  Without the national/international standards, this would not have happened! Trust relationships?  NIST Authentication levels does not relate directly to “trust”  So how will the concept of “trust” be used in Danish Health Care?  Enter: “Digital Health Denmark”  Aims at increasing treatment quality by “enabling” access to all relevant information A few years from now? Public Other Regional Health Solutions Solutions Governmental services (eg. public Medication/Prescription) Private Private Practitioners Hospital Solutions Solutions Solution 1 - establish trust? Public S Other S Regional T S T Health S Solutions Solutions Governmental services (eg. public Medication/Prescription) Private S Private S Practitioners T S T Hospital S Solutions Solutions Solution 2 - National ESB+PKI? Other Public Health Regional Solutions Solutions National ESB+STS solution Private Practitioners Private Solutions Hospital Solutions Governmental services (eg. public Medication/Prescription) National Distributed ESB+PKI Other Public Health Regional Solutions Solutions National ESB+STS solution Private Practitioners Private Solutions Hospital Solutions Governmental services (eg. public Medication/Prescription) Preconditions for implementation  Based on a “Federated ESB” pattern  Other parties are now exposing services on the “National ESB”  Digital Health is responsible for QoS etc.  Preconditions:  Common understanding of levels of authentication assurance  Very strong governance as to which criteria must be met=to Many join parts of IAF ESB the national  Assessment criteria for services for the ESB  Accreditation and certification rules Taking IAF further?  IdP’s/STS’ are also WSP’s  My wish: Separate the WSP assessment criteria from and create “SPAF”  Make IAF an IdP specialization of “SPAF” Another example of IAF usage  Health Professionals will once and again need access to other domains (other federations) Other Public Health Regional Solutions Solutions National ESB+STS Trust! solution IdP/STS Private Practitioners Private Solutions Hospital Solutions Governmental services (eg. public Medication/Prescription) Thank You! Questions? Public Key Superstructure “It’s PKI Jim, But Not As We Know It!” Stephen Wilson Lockstep Consulting Pty Limited 11 Minnesota Ave Five Dock NSW 2046 AUSTRALIA +61 414 488 851 swilson@lockstep.com.au ABSTRACT While PKI has had its difficulties (like most new technologies) the 1. INTRODUCTION: unique value of public key authentication in paperless transactions HOW DID PKI GET SO HARD? is now widely acknowledged. The naïve early vision of a single PKI has been a notoriously disappointing technology. Much of all-purpose identity system has given way to a more sophisticated the difficulty experienced bringing it to market can be traced back landscape of multiple PKIs, used not for managing identity per se, to the earliest PKI simply coming too soon. In the absence of well but rather more subtle memberships, credentials and so on. It is specified applications, an intuitive but ultimately distracting meta- well known that PKI’s successes have mostly been in closed phor was allowed to dominate the agendas and rule the thinking of schemes. Until now, this fact was often regarded as a compromise; developers, product managers, policy makers, lawyers and stan- many held out hope that a bigger general purpose PKI would still dards setters. Ironically, while the metaphor was deceptively eventuate. But I argue that the dominance of closed PKI over simple, it bred almost unlimited complexity. open is better understood as reflecting the reality of identity Technically of course, an X.509 certificate does little more than plurality, which independently is becoming the norm through the bind a name to a public key value. This sort of arcane service Laws of Identity and related frameworks. hardly makes for compelling advertising, so naturally the early This paper introduces the term “Public Key Superstructure” to CAs and web browser vendors needed a simpler bit of imagery. describe a new approach to knitting together existing mature PKI What, they asked, was an X.509 certificate like? Whoever first components to improve the utility and strategic appeal of digital suggested it was like a passport deserves a special place in the certificates. The “superstructure” draws on useful precedents in PKI hall of infamy. the security printing industry for manufacturing specialized secu- rity goods without complicated or un-natural liabilities, and inter- 1.1 The digital passport red herring national accreditation arrangements for achieving cross-border The notion of a digital passport had extra traction in the mid recognition of certificates. The model rests on a crucial re- 1990s as it was already widely appreciated that creating “trust” in imagining of certificates as standing for relationships rather than and on the Internet was going to be a crucial challenge.1 So the identities. This elegant re-interpretation of otherwise standard ele- world was much enamored with the idea that proving one’s ments could truly be a paradigm shift for PKI, for it normalizes identity with a universally recognized passport is literally the key digital certificates, grounding them in familiar, even mundane to doing business online. Perhaps the charm of the passport management processes. It will bring profound yet easily realized metaphor distracts people from the reality that most business is benefits for liability, cost, interoperability, scalability, accred- actually done in a local context. Furthermore, personal identity is itation, and governance. not usually paramount, at least not in business; as a general rule in all walks of life, the less identification needed the better. General Terms The implied objective of a one-size-fits-all digital certificate was Authentication, Security, Standardization, Legal Aspects. perhaps the single biggest complicating factor in all of PKI. By trying to make one certificate type meet the needs of all possible Keywords transactions, the legal arrangements became almost entirely Public key infrastructure, PKI, digital certificates. unmanageable. A good question is why the futility of the universal PKI project wasn’t spotted sooner. The first Certification Authorities set up shop years before any Permission to make digital or hard copies of all or part of this work for meaningful e-commerce was on offer. Imagine trying to draft a personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy 1 otherwise, or republish, to post on servers or to redistribute to lists, Peter Steiner’s cartoon “On the Internet, nobody knows you’re a requires prior specific permission and/or a fee. dog”, the exemplar of the ‘trust problem’, appeared in New Yorker magazine in July 1993, thus predating almost all e- IDtrust '08, March 4-6, 2008 Gaithersburg, MD commerce as we know it today. Copyright 2008 ACM 1978-1-60558-066-1…$5.00 subscriber agreement when you have no idea what a certificate is Leaving aside the practical matter that it shouldn’t even be going to be used for. Any reasonable Threat & Risk Assessment necessary for both counterparties to carry a certificate and belong has to explicitly relate to the application and its context. In the to a CA, the deep limitation of Cross Certification is its inability absence of any actual details, the only possible risk mitigation to recognize different certificates as being fit for different ploy is to enforce strenuous proof-of-identity checks on certificate purposes. Consider whether it even makes sense to ask if the cert- subscribers so that in the event that something goes wrong, there ificate of for instance a Taiwanese doctor is “equivalent” to the is the prospect of sheeting home some blame. certificate of an American immigration official. Cross Cert- ification together with its offspring, the Bridge CAs, are premised If any trustworthiness at all could be vested in this type of on the assumption that one identity is all we need. As we shall see certificate, then it is premised entirely on the rigor of the CA’s later, that notion has been repudiated several times over in the certification practices. And so in turn the quite artificial situation decade or more since PKI got its false start. arose where CAs, all of them brand new “trust” businesses, com- peted on the quality of their arcane Certification Practice State- 1.2 E-mail not a killer application for PKI ments, as if customers could really be expected to read and care A total lack of real applications would explain why e-mail became about these tomes. by default the most talked about PKI application. Many PKI So the digital passport idea, divorced as it was from any actual vendors to this day continue to illustrate their services and train application, led immediately to legal complexities. The metaphor their users with imaginary scenarios where our heroes Alice and all on its own is likely to also be responsible for several Bob breathlessly exchange signed e-mails. Like the passport operational quagmires, as follows. metaphor, e-mail seems easily understood, but it manifestly has not turned out to be a ‘killer application’, and worse still, has 1.1.1 Cost to the end user contributed to a host of misunderstandings. Retail digital certificates are famously expensive and inconvenient The story usually goes go that Alice has received a secure e-mail to obtain. In many jurisdictions, the de facto proof-of-identity test from stranger Bob and wishes to work out if he is trustworthy. was precisely (and arbitrarily2) the same as that of a passport. She double clicks on his digital signature and certificate in order Such a level of identity vetting is highly unusual in everyday to identify his CA. And now the fun begins. If Alice is not business. In Australia, an opt-in national PKI for healthcare immediately trusting of the CA (presumably by reputation) then professionals was met with strong opposition on this basis; admin- she is expected to download the CP and CPS, read them, and istrators long complained of PKI being a “slow and unwieldy satisfy herself that the registration processes and security process” because of the personal identity vetting, and have cited standards are adequate for her needs. “resistance from doctors and staff to fill out [registration] forms” Does this sort of rigmarole have any parallel in the real world? A as a major reason for the slow uptake of certificates [7]. simple e-mail with no other context is closely equivalent to a 1.1.2 The failure of Post Office CAs letter or fax sent on plain white paper. Under what circumstances The national postal authorities of several countries, including should we take seriously a message sent on plain paper from a Australia, Belgium, Hong Kong, Malaysia, the UK and the US, stranger, even if we could track down their name? rather quickly started up CA businesses on the strength of their In truth, the vast majority of serious communications occurs not existing privileged positions as passport registrars. Most post between strangers but in a rich existing context, where the office CAs failed to generate any sustainable free market customer receiver has already been qualified in some way by the sender as base for their certificates. likely being the right party to contact. In e-business, routine transactions are not usually conducted by e-mail but instead use 1.1.3 Cross Certification special purpose software or dedicated websites with purpose built The most unfortunate (albeit subtle) side effect of the passport content. Thus we see most of the digital signature action in cases metaphor in my view was the way it helped to inspire Cross such as e-prescriptions, customs broking, trade documentation, Certification and certificate “policy mapping” as the dominant company returns, patent filing and electronic conveyancing. frame for creating PKI interoperability. Cross Certification is the orthodox way for certificates issued in different domains to be Several important simplifying assumptions flow from the fact that assessed for ‘compatibility’. What’s really going on here is a most e-business has a rich context, and these should be heeded determination as to whether or not one CA’s detailed processes – when planning PKI: especially their registration policies – are equivalent to another’s. 1.2.1 Emphasize straight-through processing In spite of the common worked example of Alice and Bob exchanging e-mails, the receiver of most routine transactions – 2 such as payment instructions, tax returns, medical records, In Australia, the identity vetting protocol for passports and the import/export declarations, or votes – is not a human but instead related know-your-customer rules for opening a bank account is a machine. The notion that a person will examine digital were codified in legislation in 1988. The same identification certificates and chase down the CA and its practices is simply standard was uncritically adopted by default eight years later false in the vast majority of cases. One of PKI’s great strengths is when Standards Australia made its first efforts to standardize the way it aids straight-through processing, so it has been a great PKI [23]. Yet there is no logical connection in fraud mitigation pity that vendors, through their training and marketing materials, measures between face-to-face retail banking and online have stressed manual over automatic processing. transactions, and no obvious reason for the same identity vetting standards to have been carried over. 1.2.2 Play down Relying Party Agreements tication system. Traditional PKI requires an enterprise to commit The sender and receiver of digitally signed transactions are hardly itself to establishing novel and incredibly complex policies and ever un-related. This is in stark contrast to orthodox legal analyses procedures, in addition to deploying public key components. of PKI which foundered on the supposed lack of contractual Allowing any new technology to so impact a business is plainly privity between Relying Party and CA. For example the Austra- asking for trouble. lian Government’s extensive investigation into legal liability in From the late 1990s a succession of critics sought to demolish digital certificates after 111 pages still could not reach a firm con- PKI, usually on the basis of the mirage of a universal digital clusion about whether a “CA may owe a duty of care to a [Relying passport. The best known popular critique was probably that of Party] who is not known to the CA” [22]. The fact is, this sort of Ellison and Schneier in 2000 [13] which detailed ten risks that we scenario is entirely academic and should never have been given were supposedly “not being told about”. On closer examination the level of attention that it was. The idea of a “Relying Party however, most of their concerns apply to the quality of security Agreement” to join in contract the RP and the CA is moot in all policies and the safekeeping of cryptographic keys in any setting, “closed” e-business settings where PKI in thriving. It is this not just PKI. And when Ellison and Schneier do focus on PKI, it lesson that needs to be generalized by PKI regulators, not the is actually the special case of a global infrastructure that they have hypothetical model of “open” PKI where all parties are strangers. in mind. For example, their argument that PKI doesn’t resolve “which John Robinson is he” is unimportant in closed PKIs where 1.2.3 Play down certificate path discovery communities of interest already have – indeed, must have – The fact that in real life, parties are transacting in the context of reliable mechanisms for guaranteeing unique handles in their local some explicit scheme, means that the receiver’s software can namespace. No PKI implementation should ever change the way predict the type of certificate that will most often be used by users are known by the parties they deal with. senders. For instance, when doctors are using e-prescribing software, there is not going to be a wide choice of certificate Another much cited assault on PKI came from academic law options; indeed, the appropriate keys and certificates for authen- professor Jane Winn in her catchy 2001 exposé of “the shocking ticating a doctor issuing a prescription will likely be installed at truth” [28] about digital certificates. Winn lampooned the both the sending and receiving ends, at the same time that the prospects of forming new contracts over the Internet purely on the software is (see also a worked example at subsection 4.4). When a strength of strangers’ certificates. Yet far from producing the doctor writes a prescription, their private key can be program- definitive critique of PKI in general, she herself wrote that “what matically selected and invoked to create a digital signature, is now becoming apparent is that a more important [application] according to business rules enshrined in the software design. And for digital signatures than ‘open’ Internet commerce among when such a transaction is received, the software of the pharm- strangers may be ‘closed’ Internet commerce systems among acist (or insurance company, government agency etc.) will simi- parties already in contractual privity with each other or to a larly ‘know’ by design which certificates are expected to verify system administrator” (emphasis added). the digital signature. All this logic in most transaction systems can It is this point that helps explain why, in the face of such be settled at design time, which can greatly simplify the task of widespread disillusionment and cynicism, PKI through the early certificate path discovery, or eliminate it altogether. In most to mid noughties continued to grow steadily and thrive in pockets. systems it is straightforward for the sender’s software to attach the Well known examples include the Johnson & Johnson corporate whole certificate chain to the digital signature, safe in the PKI,5 the Pan Asia Alliance trade documentation system,6 knowledge that the receiver’s software will be configured with the Swedish financial sector’s BankID,7 the US Patent & Trademark necessary trust anchors (i.e. Root CA certificates) with which to Office online patent filing system,8 the pharmaceutical industry’s parse the chain. SAFE Biopharma scheme,9 and Skype.10 2. BIG PKI: ONLY EVER A STRAWMAN It’s possible that the florid ambitions of early PKI were amplified by dot-com mania. One analysis of the underwhelming demand “Big PKI” should have always been seen as a strawman, one that for third party CA audit services suggested: was construed with no real compelling need. Instead, in the vain attempt to allow stranger-to-stranger e-business, PKI inevitably “[During] the Internet boom there was a belief that e-business grew ever more bloated and vulnerable to criticism. was going to release a massive pent-up demand to conduct stranger-to-stranger commerce. But truly un-vetted business Just consider the conventional sort of definition of PKI. NIST introduction is rare” [15]. defines PKI as “personnel, policy, procedures, components and facilities to bind user names to electronic keys so that applications can provide the desired security services”.3 Microsoft considers it to be “the combination of software, encryption technologies, 5 processes, and services that enable an organization to secure its See http://www3.ietf.org/proceedings/04nov/slides/ communications and business transactions”4 (the definite article at easycert-1/easycert2.ppt. the start of the definition rather extravagantly seems to admit no 6 See http://www.paa.net. other way for an organization to transact other than PKI). From 7 See http://www.bankid.com. the outset, this language sets PKI apart from any other authen- 8 See http://idtrust.xml.org/entrust-us-patent-office-success-story. 9 See http://www.safe-biopharma.org. 3 See http://csrc.nist.gov/nissc/1999/program/isso/tsld005.htm. 10 See http://share.skype.com/sites/security/2006/02/ 4 See http://tinyurl.com/3ahtaw. zui_and_the_skype_pki.html. In parallel with the dawning realization that PKI works best when has a particular type of relationship with the RA. By extension, a parties are not strangers, several other shifts in the identity Relationship Certificate can thereby stand for the Subject’s rights management landscape at large have informed contemporary or entitlements to participate in certain transactions sanctioned by thinking, as follows. the relationship. In a great many cases, significant and powerful credentials derive directly from membership of chartered prof- 2.1.1 The need for more than one certificate essional associations, or simply from being employed by a com- The chair of the IETF PKIX Working Group Dr Stephen Kent has pany, and so can be instantiated by the relationship the user has criticized the rigidity and unreality of orthodox “big CAs”. In with the organization’s administration. Under these circum- 2005 he told a conference of the Asia PKI Forum: stances, a Relationship Certificate issued by the administrator “For many big CAs, there is an assumption that a single means nothing more and nothing less than the fact that the certificate is all a user should need. This assumes that one Subject is a member of the organization; in particular, this type of identity is sufficient for all applications, which contradicts certificate makes no formal representations about the subject’s experience. For personal privacy and security, multiple identity outside the organization. Relationship Certificates should independent certificates per user are preferable” [18]. lose their meaning outside the context of the relationship.11 Relationship Certificates have philosophical parallels with the 2.1.2 Supply chain perspective of certificates idea of “authorization PKI” which has been floated sporadically In 2005 the OASIS PKI Technical Committee developed a new as an alternative to “authentication PKI”. For example, a recent digital certificate supply chain to help better describe various cost IETF draft for secure Internet routing suggests that “[if] issuers components that impact on return on investment in PKI [27]. The need not verify the right of an entity to use a subject name in a supply chain recognizes separable components of a PKI: certificate, they avoid the costs and liabilities of such − the toolkits, libraries, services and so on used to PKI-enable verification” [6]. I believe that Relationship Certificates represent software applications a fundamental shift in the way we think about PKI mainly because they break the nexus between authentication and authorization. A − end user support Relationship Certificate can evince its Subject’s authorization to − digital certificates themselves act in a given role on a given transaction domain without needing to separately establish the person’s “identity”. In this regard, − Registration Authority services, costs and overheads Relationship Certificates differ from two superficially similar constructions: − Certification Authority operations − Attribute Certificates. Classically, Attribute Certificates do − key media (e.g. smartcards, SIM cards), if applicable. not bind public keys to users but rather only bind authorizations to names. They therefore cannot be used on App. Help Desk CA Help Desk their own to validate digital signatures, but instead are generally used in conjunction with some other general Registration purpose public key “identity” certificate (a degree of com- Key RA CA Key Key media plexity that appears to have inhibited the take-up of Attribute Certificates media media Certificates in commercial PC applications). Relationship Certificates on the other hand are just regular public key Application End user certificates. They stand alone to assert the Subject’s role or Tool kits responsibilities, and can be processed by conventional Figure 1: Digital Certificate Supply Chain software. That is, Relationship Certificates can substitute for conventional X.509 certificates in standard applications One important upshot of the supply chain perspective is that it without any software modifications; only the “business rules” more vividly underscores the separation of CA and RA, which for interpreting what a certificate means need updating. most often are legally treated as the one entity. For instance, the most detailed legal analysis yet to be carried out on PKI in − SPKI (“Simple PKI”). SPKI [12] was formulated in the late Australia, by law firm Clayton Utz in 2000, assumed that the CA 1990s in response to some of the challenges summarized carries out the functions of RA [22]. Decoupling the CA from the above, as a way of mapping an authorization directly to a RA can be usefully extended further to create a wholesale key, thereby skipping the cumbersome mappings of names to approach to certificate production, as we shall see later. keys (using regular Identity Certificates), and authorizations to names (using Attribute Certificates). In this regard Rela- 2.1.3 Relationship Certificates tionship Certificates closely resemble SPKI Authorization Greater separation of CA and RA helps the fresh formulation of Certificates. Unfortunately, SPKI has not penetrated the “Relationship Certificates”, originally developed by me for the market as far as hoped, perhaps because it positions itself Australian Government’s Gatekeeper PKI program [5]. Orthodox digital certificates representing the personal identity of their Subjects are issued after an RA performs identity proofing 11 In the real world, all credentials have context, and the on the applicant. They therefore represent an affirmation by the appropriate credential depends on the transaction at hand. For RA that the Subject has passed certain documented threshold tests example, if a doctor were pulled over by a traffic cop and asked relating to evidence of identity. A Relationship Certificate simply to show her drivers licence, she should get nowhere trying to represents a different type of affirmation, namely that the Subject present her medical qualifications. implicitly as an adjunct to the name-key mapping. SPKI is person may of course have different identities in different often associated with a needlessly complicated triangle domains. For example, a person may have one identity formed from Identity, Authorization and Attribute certifi- associated with being customer in a bank and another identity cates; see for example [20]. associated with being an employee in a company.” [17] Further operational details of how Relationship Certificates could The notion of what I would call identity plurality is not merely a be implemented are provided in Section 4 and a worked example semantic or philosophical point. A simple example demonstrates provided in subsection 4.2.3. that in business we clearly conduct ourselves according to mul- tiple identities, and that we seamlessly switch between them with- 2.1.4 Smart key media out trouble. Furthermore, when we exercise a context-dependent The historical complexity faced by users in managing keys and identity, we beneficially mask our biological one. Imagine that a certificates is being almost entirely put to bed by an increasingly company Acme Inc. has a corporate bank account with A Banking rich array of smart key media. With key pair generation integrated Corporation (ABC). The Acme company secretary, Alice, would into their chips, and certificate lifecycle management being be a signatory to the Acme bank account and would have custody absorbed into card management systems, PKI enabled smartcards of an ABC key card for the purpose. Alice might also hold a in particular are set to transform PKI. They are exactly as easy to personal account with ABC. Now, when she banks on behalf of use as any conventional magnetic stripe card. Acme, Alice exercises a different identity compared with when she banks on her own behalf, even if she happens to access both 2.1.5 New thinking about identity accounts during the same visit to the branch or ATM. The Finally, we can look to the new wave of thinking about identity in distinction is both emotional – Alice probably won’t feel any real general as an indication of better ways to utilize PKI. Much of the attachment to the millions of dollars she routinely handles for the focus of “identity 2.0” (as promoted by organisations such as company – and legal. Corporate law says clearly that the Acme sxip12) is on the multiplicity of things that we say about ourselves, account holder is not Alice but the company. and the things that others say about us. That is, identity 2.0 begins with a realization that the usefulness of online identity depends on One deep implication for PKI of identity plurality is that it inverts context, and it must be responsive to the natures of the diverse the expectation that closed PKI is a compromise while open PKI relationships we have with those we transact with.13 is the proper long term goal. On the contrary, we should now appreciate that open PKI would be a special and highly theoretical It seems to be increasingly accepted that people live with multiple instance. It is the closed PKIs – each with its own arrangements identities. The preeminent exposition of modern identity theory is and business rules – that represent the general case. probably Kim Cameron’s Laws of Identity [10]. The laws include a new definition of digital identity as “a set of claims made by one 3. WHAT IS PKI REALLY GOOD FOR? digital subject about itself or another digital subject”. Cameron I contend that clearly the best use of PKI is to help automate knows that this sort of relativist definition might not sit electronic transactions in a particular context between parties that comfortably with everyone: already have a formal relationship. “We recognize [that our definition] does not jive with some The orthodox textbook amount of the benefits of PKI invariably widely held beliefs – for example that within a given context, list authentication, integrity and something called “non-repu- identities have to be unique. Many early systems were built with diation”. These high level properties may actually be delivered by this assumption, and it is a critically useful assumption in many all manner of technologies, a fact that made early PKI’s over- contexts. The only error is in thinking it is mandatory for all inflated marketing claims seem frankly silly, even at the time.14 contexts.” [10] But Cameron is certainly not alone, not anymore. Other resear- 3.1 A clearer benefit description for PKI chers have reached the view that there may be a many-to-one We need a more sophisticated shared understanding of what mapping of identities onto entities; see e.g. Jøsang and Pope: makes PKI unique. I suggest its unique benefits would be better told as follows: “An identity is a representation of an entity in a specific application domain. For example, the registered personal data − Digital signatures create long-lived, tamper-resistant of a bank customer, and possibly also the customer's physical evidence of ‘who did what to whom’, which is so critical to characteristics as observed by the bank staff, constitute the electronic transactions carrying high legal risks or identity of that customer within the domain of that bank. … A compliance requirements. − PKI, when deployed with hardware key media like smart- 12 See http://www.sxip.com. cards, is recognized as “the only practical solution [to eaves- 13 dropping and account hijacking] today” [9]; digital signatures However, many in the identity 2.0 movement go from this background to a position of desiring all diverse relationships to 14 be federated into a multi-context transcendent identity. In my PKI has no monopoly on “non-repudiation” despite the term opinion this is one step too far. Dick Hardt’s famous identity 2.0 only being coined in connection with it. PKI marketing too conference presentation is frankly utopian in the way it often suggests that only PKI delivers non-repudiation. If this advocates linking all our reputations together, for it overlooks were true, credit card holders who use their cards online could the privacy problems arising when linked records are exposed try to mischievously repudiate any one of their payments on the by accident, when wrong doers exploit the linkages, or when a basis that it was not digitally signed and therefore did not have user seeks to sever one of their relationships for some reason. “non-repudiation”! originated by the end user protect against Man-in-the-Middle 3.2 PKI in plain English attack, while smart key media offer a sufficiently compact The steadily improving automation of digital signature and logic engine to be certifiably resistant to malware. certificate management operations means that the way we describe − Digital certificates can convey authority information – like PKI to lay people can now side-step the technical details of credentials, licences, affiliations and so on – and digital asymmetric cryptography, hash functions and so on, and focus signatures bind that authority information directly to instead on what it actually does. A fresh, plain English description messages, to decentralize and greatly simplify transaction might run as follows (assuming smartcards are the key media). processing. A smartcard plus application software combine to produce PKI digital signatures are persistent over both time and ‘distance’, digital signature codes for electronic transactions. Unlike any meaning the separation of sender and receiver. At essentially any other electronic signature method, digital signature codes are time in the future15 a digitally signed transaction can be easily re- unique to the owner and also to each transaction. Digital validated to prove where it originated: all that is needed is a signatures operate as if a personalized electronic stamping trusted copy of the root public key, the certificate chain, and the machine was inside each smartcard, creating a specific tamper relevant CRLs (all of which are routinely available from any resistant ‘mark’ on each message or file created by the card decent CA). In addition, authority information about the sender holder. Digital signatures remain valid indefinitely; at any time can be sealed into their certificate at the time of issue, and this in future, the ‘mark’ can be easily verified to prove its origins. authority information also has great longevity, thanks to the Digital Certificates are electronic notices that bind identities to digital signature of the Certificate Authority on the certificate. such devices as smartcards.16 Certificates can thereby bind The integrity of digitally signed data is not reduced by being individuals to transactions signed using their smartcards. A copied or forwarded across systems or across borders. In contrast, digital certificate can identify the card holder and can also hold other authentication technologies rely heavily upon audit logs to any other information that the issuer is qualified to declare. If prove ‘who did what to whom’; forwarding non-PKI transactions the issuer is authoritative over information such as professional from one system to another complicates and dilutes the strength of credentials, then that information can be sealed within its the audit trail. So PKI is uniquely suited to complex transaction digital certificates and thus bound to each card holder plus the environments, like healthcare, pension fund management and transactions they sign. trade documentation, where there are multiple relying parties, To process digitally signed transactions, the receiver’s software formal authorizations, and/or long lifetimes. requires a copy of the sender’s certificate, plus a special “master code” – known as a root certificate – which is used to 3.1.1 The challenge of persistent credentials mathematically validate all certificates in a given PKI scheme. Verifying transactions originating from professionals is a case in Different master codes define different PKI schemes, be they point. Consider a lawyer who signs conveyancing documents sector-specific, national or general purpose such as SSL relating to a land sale. When the contract is settled, all parties (the website authentication. Application software can ship with all buyer, the seller, their respective banks and so on) will be acutely necessary master codes, or can have them installed later. interested to know that the lawyer’s credentials are valid. It is straightforward to check credentials online, at the time, by looking Digital certificates can be electronically revoked at any time. up a database of qualified practitioners. But in electronic Revocation may be requested by the holder in the event that conveyancing, what becomes important is the ability to check the they lose their smartcard. Alternatively, revocation of a credentials of a lawyer who signed documents in the past. Unless professional’s certificate may follow automatically from their special measures are taken to archive practitioners’ databases, it is membership lapsing, their qualifications being cancelled, or difficult to obtain definitive machine readable information about their employment changing. the state of someone’s credentials at a given time in the past. With digital signatures and digital certificates on the other hand, the 3.3 Modern PKI success stories matter becomes trivial: if Relying Party software knows the Many of the more recent PKI success stories resonate with the relevant Policy OID and has a trusted copy of the root public key, concepts of identity plurality and digital certificates having more then it can verify the credentials of the lawyer at the same time as to do with multiple relationships than a single identity. Examples it verifies the digital signature, no matter how old it is (with follow. reason, as qualified by the long term risks mentioned previously). − A large public hospital in Australia developed a new “Known Customer” certificate to be issued on smartcards to several thousand of its staff [8]. The intended digital signature applications include electronic medical notes created by 15 Several very long term risks ultimately threaten the validity of nurses, electronic hospital discharge notes, and online old digital signatures. Brute force attack by future computers on employee self-service access to pension fund administration, asymmetric cryptographic algorithms, exploitation of likely leave forms and so on. The hospital’s human resources weaknesses in MD5 and SHA-1, and eventually the possibility of quantum computing, all mean that any digital signatures 16 intended to remain valid for a few decades should have their This simplified account deliberately but without loss of keys and certificates comprehensively archived. Note that the generality suppresses the intermediate detail that the certificate stability and usability of archive media over the decades is actually binds the identity to a key pair, which is separately another quite separate challenge. bound to the smartcard by way of hardware key management. department will operate a delegated Registration Authority Such arrangements have been studied extensively and piloted by workstation. A commercial back-end CA will independently both the legal and medical professions in Australia, as mentioned manufacture customized certificates on request from the RA, in subsection 3.3. In response to market demand for PKI-based and inject them onto smartcards. The same CA will be able to digital credentials that convey richer information about produce similar but distinct Relationship Certificates for professional qualifications without being burdened with artificial other communities of interest in the health sector. Overlap registration requirements, the Australian Government PKI between healthcare communities is commonplace, with program recently introduced a special category for Relationship geographically related area health services often sharing Certificates [5]. information management resources and infrastructure. “Interoperability” of the hospital’s staff certificates with other 4.1.1 The Relationship Certificate profile local applications will be easily fostered simply by To be most effective, Relationship Certificates would have promulgating knowledge of the certificate Policy OIDs. information in their X.509 (or similar) profile to specify the precise nature of the relationship between RA and Subject, − The Australian government has been exploring how digital allowing straight-through processing by any Relying Party certificates can act as electronic credentials for a number of software application configured to recognize the validity of the different types of professionals. A state association for legal relationship. The best way to codify the meaning of a Relationship professionals has researched how digital “practicing certi- Certificate is probably in the Policy OID, which can be specified ficates” can be issued to attorneys.17 The most compelling at design time. application for digital signatures in the practice of law is Ideally, technical controls should be implemented as well to make electronic conveyancing. E-conveyancing is forecast to it difficult to misuse a Relationship Certificate outside its intended provide direct savings of AU$70 per transaction for vendors context. One way to implement technical restrictions on misuse and purchasers, and an overall saving to industry of AU$33 would be to include a Critical extension in the profile. Recall that million p.a. by 2010, assuming 66% of transactions are by the X.509 standard requires any software processing a certificate then done online [24]. which has an extension marked as Critical to reject that certificate − Most e-health projects around the world anticipate the use of unless it expressly recognizes the extension. Since special purpose digital certificates. The use of digital signatures in the software (as opposed to general purpose web and e-mail clients) is pharmaceutical industry has been fostered by the Food & usually used in PKI-enabled transaction systems, within Drug Administration’s Title 21 Code of Federal Regulations communities of interest, programming in awareness of Critical (21 CFR Part 11) in respect of Electronic Records and extensions is easy. And by the same token, it is safe to assume that Electronic Signatures. Health smartcards in France18 and if a given software program does not recognize the Critical Germany19 are currently being upgraded with PKI-capable extension, then it is proper behaviour to reject the certificate, on chips so as to support a new wave of applications that require the grounds that such certificates are not supposed to be used patient signatures, such as e-prescribing. The Australian outside special purpose applications. Critical extensions proved federal Department of Health and Ageing in 2006 unpopular in the past because they were thought to harm commissioned independent security analysis that strongly interoperability. But if a special purpose Relationship Certificate endorsed digital certificates for e-prescribing [2]. is only intended to work with certain applications, then “interoperability” is more or less moot, since no other applications should be expected to accept it. 4. PUBLIC KEY SUPERSTRUCTURE Having painted a newly optimistic picture for the future of PKI, 4.1.2 Practical benefits of Relationship Certificates one that resonates with broader identity management trends, I will Relationship Certificates would bring major simplifications over now describe a number of fresh ways to better knit together extant third party identity certificates in several areas: mature building blocks – X.509 and similar certificates, RAs, CAs and PKI audit services – to deliver better, more flexible trans- − Overheads associated with registering for certificates are action authentication. greatly reduced; customers already known to the administrator in a community of interest will be able to 4.1 Relationship Certificates in practice receive certificates almost automatically without having to Relationship Certificates, as described in subsection 2.1.3, are present in person at an unfamiliar RA. best managed within an arrangement where a defined “community of interest” deploys digital certificates that represent membership − Certificate Subjects will require no legal relationship with the of the community. Operationally, Relationship Certificates are backend CA; any important new obligations introduced by issued with the administrator of the community acting as a PKI – such as responsibility to safeguard one’s smartcard and delegated RA. promptly report its loss – can be folded into the administrator’s formal contractual relationship with its members, rather than expressed in the traditional CA’s “Subscriber Agreement”. 17 See news about this project at http://www.galexia.com/public/projects/projects-Law.html − Users will no longer be required to pay up-front for a (accessed 31 Jan 2008). certificate from a third party CA in order to use PKI-enabled 18 applications. http://www.sesam-vitale.fr/programme/programme_eng.asp. 19 http://www.die-gesundheitskarte.de (in German). − Furthermore, the price of certificates should fall towards − ‘Process Security (end-to-end process controls from raw “wholesale” levels, because the cost of identity proofing materials, through to end product, full audit trail in place for associated with traditional identity certificates will be each print job, destruction of unused/damage stock, eliminated. protection of confidential information, employee screening and confidentiality clauses) − Support overheads and complexities may be lessened by having just one help desk for all business, application and − ‘Order Processing certificate-related matters. − ‘Quality Assurance 4.2 Wholesale certificate production − ‘Dispatch & Delivery (secure & auditable dispatch system, Historically, CAs have been tied legally into the whole of the sign-off for delivery, secure transport arrangements, secure certificate management process, no matter how they might packaging, appropriate labeling not to identify as checks, operationally involve RAs in the registration and certificate processes for lost/stolen consignments)’ (adapted from [14]). lifecycle management processes. CAs tend to be joined in liability arrangements and contracts to potentially any wrongdoing or Accredited printers under the British CPAS variously emphasize misadventure associated with certificates. Certificate policies, their personnel screening, internal segregation of access- practice statements and user agreements have been corre- controlled security cages, and perimeter fences and monitoring spondingly difficult to construct. To date, the separation of roles systems. Clearly a similar degree of effort is involved physical, of RA and CA has done little to quarantine the two functions from procedural and personnel security for security printing operations one another, nor to simplify liability arrangements. Accreditation as for well run CAs such as those typified by accreditation under remains complex and sensitive to the slightest changes at either Identrust, WebTrust for CAs, Australia’s Gatekeeper PKI scheme, the RA or CA. or the UK’s tScheme. There might be a new way however of looking at backend CAs, 4.2.3 Worked example: barcodes and certificates likening them to conventional security printers, and dramatically A practical worked example of how digital certificates could simplifying the way that legal liability is apportioned when replace a conventional paper security mechanism helps to further something goes wrong with a digital certificate. develop the comparison between backend CAs and security printers. 4.2.1 The business of security printing For decades it has been well known that in order to combat fraud, Consider a stock exchange that arranges for statutory special care must be taken in printing certain documents: blank announcements made by listed companies to be communicated by checks and prescription pads in particular, as well as business fax and secured by means of barcodes. Each listed company is forms, concert tickets, gift vouchers, barcodes and so on. A whole provided with a roll of self adhesive barcode labels. The barcodes industry has been built around special printing technologies, uniquely identify the company and are individually serial including watermarks, holograms, reactive inks that detect numbered. When a statutory announcement needs to be made in photocopying, and micro-printing. Moreover, a coherent business accordance with the stock exchange’s Listing Rules, the model has been built around security printing bureau services. In announcement is printed, signed by a duly authorized company many sectors, standards have been introduced to cover the officer, and has a barcode label affixed to it, before being faxed to necessary security of premises and processes, and formal the announcement processing centre. When received, optical accreditation schemes govern compliance with these standards. character recognition software scans the fax, extracts the For example, since 1 January 2005, written prescriptions for announcement, and verifies the barcode, before broadcasting the controlled substances in California must be on tamper resistant news across stockbrokers’ screens. See Figure 2 below. security prescription forms produced by a printer approved by the State Board of Pharmacy.20 And the United Kingdom’s payment Security Distribute bar codes clearing regulators APACS introduced a formal Check Printer Accreditation Scheme (CPAS) in 1995.21 Printer 4.2.2 The governance of security printing Listed Company Many of the standards governing security printing closely Achieve Listing Listing Listing Listing Listing resemble those for traditional CAs. For example, check printer Listing Listing Listings Rules Rules Rules Rules Rules Rules Department Officer accreditation typically covers assurance of the following aspects of the operation: − ‘Equipment & Materials Announcements Processing Announcement Fax Stock Affix − ‘Premises Security (external security for prevention of Exchange bar code unauthorized access, and internal security with appropriate restrictions on access to different areas Figure 2: Authenticating faxed company announcements by means of secure barcode 20 See http://www.ag.ca.gov/bne/security_printer_list.php. The barcode label is an authentication token. Inclusion of a 21 barcode on a fax is taken as reasonable evidence that the sender is See http://www.apacs.org.uk/payment_options/cheques_ a listed company, operating under the stock exchange’s rules. accreditation_scheme.html. Clearly such barcode labels are precious items. They need to be produced by a reputable security printer, with the ordering and Furthermore, the company officer, as certificate Subject, would distribution processes being subject to strict controls. generally have execute a user agreement with the CA. In contrast, Now let us consider how the announcement processing system requiring them to sign up with the security printer responsible for could be reengineered to use PKI and electronic messaging in the barcodes would be unthinkable! Finally, changing backend place of fax machines. Figure 3 shows a nearly identical system, CA typically triggers major re-accreditation of any regulated end- where the listings unit operates an RA (not shown), and instead of to-end PKI solution, because peak documents like the CP and ordering barcode labels from a security printer, it orders digital CPS tend to intertwine all of the operational aspects. In the “real certificates from a backend CA. In order now to make an official world”, if the stock exchange gets a better deal from a competing announcement, the company officer would use the certificate to printer, the changeover in backend operational matters would be digitally sign an electronic message. completely invisible to the listed companies. Note that the certificates issued in this particular scheme are an Comparing the digital certificate approach to the barcode system instance of Relationship Certificates. They are not intended in any is suggestive of a more streamlined approach to PKI operations way to stand for the “identity” of company officers. Rather, they and accreditation. First note, referring to the list of security represent nothing more and nothing less than the fact that each requirements on the previous page, that security controls can be Subject is an officer of a company listed on the stock exchange. clearly separated according to whether they relate to (1) the risk of impersonation, which tends to be managed by process or (2) the risks of counterfeiting or theft, which tend to be managed by CA Distribute certificates, keys technology: − Impersonation related risks o the company listing process must be robust and difficult Listed Company Achieve Listing to subvert. Listing Listing Listing Listing Listing Listing Listings Rules Rules Rules Rules o it must be difficult to fraudulently order barcodes or Rules Rules Department Officer certificates. Announcements Announcement Message − Counterfeiting and theft related risks Processing App Stock Digitally o barcodes, private keys and certificates must be difficult sign Exchange to counterfeit. o the security printer or backend CA must be difficult to Figure 3: Authenticating electronic company announcements subvert. by means of digital certificate Let’s compare the security requirements of announcement o barcodes or private keys must be distributed and stored methods that alternately use barcodes or digital certificates. carefully. Regardless the authentication method, the announcement system At the front-end of this authentication scheme, where the stock requires a common set of security controls: exchange deals with its companies, there is no logical difference 1. The company listing process (which is where the between using barcodes or digital certificates, so we should expect relationship between a company and the stock exchange the security of existing stock exchange registration processes to is established) must be robust and difficult to subvert. carry over to the PKI implementation without change. And at the backend, there is no need for either a security printer nor a CA to 2. It must be difficult to fraudulently order barcodes [or be concerned with the details nor even the integrity of the digital certificates]. company listing and customer service processes, so long as there 3. Barcodes [or private keys and digital certificates] must are controls in place to mitigate against wrongful ordering. be difficult to counterfeit. 4.2.4 Implications of security printing for CAs 4. The security printer [or backend CA] must be difficult So, why couldn’t we treat backend CAs in the same way as we to subvert. treat regulated security printers? If a CA was set up as a service 5. Barcodes [or private keys] must be distributed and bureau, responsive to a particular set of RAs with which the CA stored carefully. has a specific arrangement, producing certificates on instruction more or less automatically via standard certificate request If the conventions of orthodox PKI were to be applied to this protocols, then a number of major simplifications to PKI manage- operation, then a number of additional complexities would be ment and governance could follow: imposed from outside on how the stock exchange runs its business. In particular, most PKI regulators today would expect − The CA need have no interest at all in the semantic contents standardized identity proofing for all certificate recipients at a of the certificates it produces on instruction from a contracted level equivalent to passport application, irrespective of how the RA. So long as there are safeguards in place to mitigate existing listing rules operate.22 against false certificate requests being injected between the 22 In the current climate of concern for homeland security, anti- identity vetting processes, but nevertheless, that is an exercise money laundering, improved corporate governance and so on, it that is not logically connected with PKI per se and the two happens that many organizations are looking to strengthen their should not be confused. RA and the CA, the CA need not know anything at all about “[PKI] interoperability is something of a will-o’-the-wisp. You the RA’s business process, nor the intended application of think you understand what people mean by it, and then quickly the certificates. The CA’s business model and detailed realize that you don’t. In my experience, it’s possible when processes could be held entirely constant over a wide range discussing interoperability to be at cross-purposes for all of the of different PKI applications. Protecting against injection of time. Interoperability between members of the same PKI is false certificate requests is a standard feature of most CA-RA axiomatic. Certificates issued by one bank should be products and is an express part of most if not all PKI product recognizable by another. Interoperability becomes an issue certification. when it is between different PKIs … But this still leaves the basic question of interoperable in respect of what?” [21]. − There is no need for a contract or other legal arrangement between end users of certificates and the backend CA (just as The best place to start thinking about interoperability is to unpack there is no need for end users of checks and barcodes to have with a functional focus how digital certificates can help with any relationship with the respective security printer). authentication. A fine definition of authentication comes from the APEC eSecurity Task Group: “The means by which the recipient − The CA’s liabilities are straightforward to analyse and codify. of a transaction or message can make an assessment as to For example (and in stark contrast to orthodox RA/CA whether to accept or reject that transaction” [2]. In the case of arrangements) it seems clear that a CA would not normally be digital certificates, from the perspective of the receiver or Relying joined in legal action resulting from an RA being negligent in Party, the central question is really very simple: What information registering an impostor for a certificate. On the other hand, is available, in the certificate chain and elsewhere, to help the acts of omission or commission by a CA in producing poor receiver decide whether to accept or reject the certificate and quality certificates which led to harm on the part of message hence a digitally signed message? recipients, could be identified and prosecuted as such, and There are three main things the receiver needs to know about a isolated from the RA. certificate in order to tell if it is fit for purpose: − The meaning of the root key – which in orthodox PKI has led 1. What representations does the certificate make about to so much confusion – can be likened to a unique watermark its Subject? Or equivalently, was the certificate inten- featured in all products from a given security printer. The ded to be used in the transaction concerned? With Rela- chaining of a certificate back to the CA root would represent tionship Certificates standing for specific credentials or the simple fact that the certificate has come from an memberships conferring particular authorizations, each accredited facility (see subsection 4.4.1 for more details). The will bear a unique Policy OID indicating its intended Root CA signature means only that it is extremely unlikely applicability and context. that a certificate has been forged, and does not impart any approval or endorsement of the contents of the certificate.23 2. Is the certificate valid (i.e. not revoked)? Note that while revocation status is usually thought of as a − It should be much easier to novate backend CA service question posed in real time, sometimes it will be back- arrangements from one supplier to another. dated; that is, we may need to know if the certificate Note that the security printing model would essentially preserve Subject was valid at the time they launched the trans- the physical, procedural, personnel and technological security action (see e-conveyancing discussion in subsection controls of most current CA accreditation schemes, in order to 3.1.1). protect against counterfeiting and subversion of the backend 3. Was the certificate issuer acting in compliance with process. In particular, the benchmark of Common Criteria EAL4 applicable standards and regulations? Relevant rated CA and RA products would probably be retained, to help standards will vary from one domain (or PKI scheme) to prevent fraudulent ordering of certificates. another; examples include the Australian government’s Gatekeeper program, the finance sector’s Identrus and 4.3 Revisiting certificate interoperability the more general purpose WebTrust for CAs. As discussed above, the historical focus on cross certification All of the information that an application needs in order to accept appears to have been a well-intended but misguided attempt to or reject a certificate could be found in the certificate chain, under determine the equivalence of certificates issued in different the right circumstances. Compared with orthodox PKI which domains. If we take time to revisit the business need for referred vaguely to “chains of trust”, we need to be more precise accreditation of PKIs, we can formulate a more powerful and yet about what certificates issued to CAs represent. If they represent lower cost approach to interoperability. each CA’s compliance with standards (like Webtrust for CAs or 4.3.1 How should certificates “interoperate”? Identrust) then when an end user certificate chains back to the Is there a topic in PKI more important and yet more confused than root we can be sure that all intermediate CAs are doing what interoperability? A senior finance sector executive captured the they’re supposed to do. And if the end user certificate’s Policy uncertainty perfectly: OID matches our expected value, then the certificate can be relied upon. For more details, see subsection 4.4.1. 4.3.2 Cross recognition versus cross certification When transactions cross between jurisdictions or communities of 23 When couched in this way, the certificates issued by a Root CA interest, users must be able to determine whether or not to accept can be seen recursively as special instances of Relationship a transaction signed using an certificate issued elsewhere. This Certificates. then is the fundamental issue in electronic authentication, rather than the quite arbitrary question of whether counter parties’ purpose as circumscribed by the scope of the audit, and that the certificates happen to be equivalent, as discussed in subsection certificate was issued by a CA that was, at the time of the last 1.1.3. inspection, found to be in compliance with its own policies and In contrast to cross certification, cross recognition is defined as procedures as well as any other prescribed standards. “an interoperability arrangement in which a relying party in one For an illustration, see Figure 4 which depicts a digital signature PKI domain can use authority information in another PKI of a qualified doctor chaining through a Relationship Certificate domain to authenticate a subject in the other PKI domain” [1]. to an issuing CA, the certificate of which is signed by a Root CA Users in a community of interest require information and guidance representing a health sector scheme. from their community leaders about the fitness for purpose of Signed: Health Root CA Signed: Health Org CA whichever external certificates can be expected to be received Credentials Signed: Doctor XYZ Event Summary Health Org CA by Public Key … by Public Key … Dig Sig verified Dig Sig verified with incoming transactions. With a range of CAs issuing Subject: - - - Patient ID - - - Subject: - - - certificates for different uses, it is essential that a Relying Party Diagnosis - - - Ext: Lic No. XYZ Validity: - - - can tell if an incoming certificate is acceptable for the transaction Protocol - - - Validity: - - - Issuer: Root CA Results - - - Issuer: Org CA Policy OID: - - - concerned; ideally their software application should be able to Prescribed - - - Policy OID: - - - decide on-line and automatically whether to accept or reject a Public Key: - - - Public Key: - - - given certificate. If a CA has been accredited under an external PKI scheme, then Transaction User Certificate CA Certificate the issue boils down to whether or not that accreditation is Figure 4: Imputing fitness for purpose from a certificate chain acceptable to the local community of interest for the intended use of the certificates [26]. This is perhaps the simplest statement of If we adopt a somewhat fresh interpretation of what it means for the problem of cross recognition of PKIs. various CAs to sign certificates, then the chain in Figure 4 allows fitness for purpose to be imputed as follows. 4.4 How to convey “fitness for purpose” In this example, the user certificate issued by (or on behalf of) a Where a CA is audited or accredited under a particular scheme, its reputable health organisation represents nothing more and nothing standing under that scheme should be made available to Relying less than the fact that the Subject has a meaningful medical Parties online. Webtrust for CAs does this to some extent by way qualification. The Policy OID in that certificate directly represents of a web seal on the CA’s site, but this requires out-of-band a transaction domain on which the digital qualification is deemed examination by the Relying Party, at least on occasion. That is, to be valid. For example, if the health organisation were a medical the fact of accreditation is not machine readable. It would be far practitioner registration board, then it could be that its certificates better for a Relying Party application to be able to recognize confer the authority to sign e-prescriptions and other transactions programmatically the fact of accreditation. under certain legislation (and the Certificate Policy would call out 4.4.1 Rendering CA audits machine readable that legislation explicitly and incorporate, probably by reference, all associated rights, responsibilities, terms and conditions). On A more powerful and interoperable way to represent accreditation the other hand, if the health organisation were a hospital, then its is to use a conventional X.509 certificate issued by (or on behalf certificates might have a more restricted scope of meaning, such of) the auditor. In 1999, I proposed an “accreditation based” way as the authority to admit patients for procedures according to a to construct PKI, in which “the X.509 certificate issued by an contract between the hospital and a doctor. Similarly, a certificate intermediate CA to a user CA is interpreted explicitly as a issued by a Health Maintenance Organisation (HMO) or private compliance certificate, directly analogous to the paper certificate health insurer could confer authority to order particular tests issued by a [quality standard] certifier to a compliant electronically. In these cases the Certificate Policy would call out organisation” [25]. The basic thrust of this proposition was the applicable contract from which the certificate Subject’s adopted by the Australian Government PKI program in its authority obtains. Gatekeeper Accreditation Certificate CA initiative, which, while not yet operational, is envisaged will: So, if the digital signature on a health transaction chains correctly to a user certificate issued by the authoritative Health “… issue a digital certificate – the Gatekeeper Accreditation Organization CA, then the receiver can be assured of the veracity Certificate (GAC) – to each Gatekeeper Accredited CA. of the provider’s credentials. It is straightforward for receiving Issuance of the GAC would confirm that the CA has satisfied software that deals with a whole class of healthcare transactions to the Australian Government’s requirements for Gatekeeper be configured with the Policy OIDs of all issuers of certificates Accreditation. In issuing a GAC, Finance will not be acting as deemed to be authoritative for those transactions (obviating the a Root Certification Authority as it does not impose a policy need for complex certificate path discovery, as discussed in regime on digital certificates issued by subordinate CAs” subsection 1.2.3). (emphasis in original) [4]. Turning to the Health Organisation CA itself, it has been issued a (Note the evident reluctance to act as a Root CA, an inhibition certificate by a Health Sector Root CA. We interpret the signature that will be considered in more detail in subsection 4.4.2.) of the Root CA as conferring membership of a health sector A key advantage of the accreditation based PKI model is that the scheme. For a CA to hold a valid certificate signed by the Root audit certificate can be parsed and interpreted by entirely means that the CA has been deemed to have met the scheme rules, conventional X.509 software. The existence of a valid and current and has passed whatever audits are specified by those rules. If the certificate chain extending from an end user back to a recognized conditions of membership of the scheme are ever breached then auditor can be interpreted to mean that the user certificate is fit for the CA’s certificate can, as an ultimate sanction, be revoked. 4.4.2 Root CA as “conformity assessment” anchor with the fact that national ISO 17025 accreditation bodies have Now we can consider re-inventing the role of Root CA. Orthodox established multilateral Mutual Recognition Arrangements formulations of the role and responsibility of Root CAs have (MRAs) enables a new way of achieving “interoperability” historically been confusing (if not confused). It has been difficult between PKIs, as we shall soon see. to avoid unspecified legal liabilities growing as we move up the Multilateral MRAs are nowadays administered by overarching “chain of trust” from CA to Root. “co-operations” to which numerous national accreditation bodies But what exactly is it that a Root CA does? Or what should it do? are signatories. Examples include the Asia Pacific Laboratory As we saw in the previous subsection, there is a presumption that Accreditation Cooperation (APLAC) and the International Root CAs “impose a policy regime on digital certificates issued by Laboratory Accreditation Cooperation (ILAC).25 Just as there are subordinate CAs” [4]. At least one PKI scheme – Australia’s standards like ISO 17025 for ‘auditing the auditors’, recently Gatekeeper – is reluctant to have Certificate Policy imposed by another level has been added to govern accreditation bodies. For the Root CA. Instead, it prefers to allow member CAs to remain example, ISO 17011:2004 General requirements for accreditation entirely autonomous in the way they construct their OID trees. bodies accrediting conformity assessment bodies is used by APLAC as the basis for its MRA. Accreditation bodies can join Operationally of course, a PKI needs a top-most CA that spawns the MRA under a number of headings according to the broad other operational CAs, and provides a “trust anchor” to which focus of their activities, such as inspection, calibration, testing, or certificates can chain. Relying Party software needs a dependable reference materials production. copy of the Root CA Public Key, and when a chain of certificates is established that terminates at a self signed Root CA certificate, Note that the accreditation of inspection bodies can be fine tuned it is said that they can be “trusted”. In terms of certificate parsing to meet particular needs. When a certain field demands special and processing, this much is conventional wisdom and yet the skills and qualifications, ISO 17025 needs to be interpreted in res- point of chaining CAs together has not been obvious, and pect of the type of inspection at hand and any special techniques confusion has reigned over the types of bodies thought most apt to involved. When a specialist field has its own conformity require- have custody of Root CAs. ments, as might be set by local standards, accreditation bodies can produce supplementary requirements for accreditation of partic- The plain English synonym for Root CA certificate, “trust ular types of inspection bodies, to augment the general require- anchor”, happens to be suggestive of a precise and powerful new ments of ISO 17025. Thus for example, Australia’s National Ass- type of role for Root CAs, which derives from existing audit and ociation of Testing Authorities publishes detailed Accreditation control structures. Obviously, most PKIs already embody various Requirements, all based on ISO 17025, but fine tuned to a wide forms of audit, against standards that vary in rigor from one range of domains, including information technology.26 industry to another. But regardless of the details of a particular audit methodology, it is possible to gauge whether or not the audit In relation to PKI governance, it is especially noteworthy that the has been conducted in a manner that is suitable for its information security community has already successfully applied environment. In the field of technical inspection or “conformity ISO 17025 accreditation to overseeing the ISO 15408 Common assessment”, the pivotal question of ‘who audits the auditors?’ has Criteria evaluation scheme. The Common Criteria arrangement long been addressed by a nested system of international inspection [11] requires security evaluators to be accredited in accordance and accreditation standards. Across a very wide range of technical with ISO 17025. domains – from traditional materials testing to independent software validation – the standard ISO 17025:1999 General 4.4.3 Scaleable global PKI from an ISO 17025 MRA One reason that the Common Criteria scheme as been uniformly Requirements for the Competence of Calibration and Testing adopted with relative ease across 25 countries27 is the existence of Laboratories [16] has been applied in the accreditation of ins- MRAs. The practical result of an MRA is that assessments done pection bodies.24 The outcome of such accreditation is an asser- by accredited inspection bodies in one country can be readily tion that a given inspection body is independent and competent to accepted by interested parties in other jurisdictions. International carry out audits in its field of expertise, no matter what that field trade in particular benefits from MRAs because goods that are may be, and regardless of the peculiarities of the standards that subject to safety and type testing, such as electrical equipment, apply to that field. This outcome of auditor accreditation coupled can be evaluated once in the country where they’re made prior to export, and subsequently accepted by a large number of importers 24 In the first expression of the accreditation-based PKI model [25], I suggested that quality management systems were a suitable model for what CA auditors do, and that the peak standard 25 ILAC members include American Association for Laboratory ISO/IEC Guide 62 General requirements for bodies operating Accreditation (A2LA; http://www.a2la.org), ACLASS Accred- assessment and certification/registration of quality systems could itation Services (http://www.aclasscorp.com), International Acc- be applied. More recent research indicates that ISO 17025 (form- reditation Service (IAS; http://www.iasonline.org), the United erly known as ISO/IEC Guide 65) is a better fit for PKI auditors Kingdom Accreditation Service (UKAS; http://www.ukas.com) because it tests the competence of auditors and is generally more and Australia’s National Association of Testing Authorities apt for technically demanding fields. It should be noted that a (NATA; http://www.nata.asn.au). number of superficially similar accreditation standards exist 26 including ISO/IEC 17020:1998 General criteria for the operation See http://tinyurl.com/2yevj8. 27 of various types of bodies performing inspection. To build a See List of Common Criteria Recognition Arrangement mem- working PKI using these standards, a technical choice of high bers at http://www.commoncriteriaportal.org/public/consumer/ order standard would be made by expert standards bodies. index.php?menu=4 (accessed 8 Jan 2008). around the world without the need for repeat testing. APLAC As described in subsection 4.4, to convey the results of the describes this as the “free-trade goal of ‘tested/inspected once, conformity assessment in this proposed PKI, special digital certi- accepted everywhere’”.28 ficates will be issued by (or on behalf of) PKI auditors to each The ability to accept and rely upon a specialized technical audit approved CA. The meaning of each these certificates is simply done in another country is surely the key to international PKI, if it (but precisely) that the Subject has passed an audit according to is accepted that different digital certificates can mean different detailed procedures and standards that would be uniquely things, as argued throughout the earlier parts of this paper. ISO- indicated by a Policy OID. Different audit regimes and different 17025 MRAs represent a hugely important asset in this regard auditors would map onto different OIDs. because they can accommodate a flexible range of audit matters. Now, it is just as important that the status of the PKI auditors also Member accreditation bodies can be empowered under an MRA be conveyed to receivers, and for that purpose, a special digital to implement new supplementary accreditation guidelines within a certificate will similarly be issued by (or on behalf of) an broadly defined scope such as “inspection”,29 and have the accreditation body to each accredited PKI auditor. In accordance outcomes of their accreditations recognized in other countries, with the regular provisions of ISO 17025, accreditation bodies without them having to review in detail the substance of those would be chiefly concerned with the independence and the guidelines. In turn, the outputs of organisations that have passed competence of PKI auditors. It may be the case that additional inspection under those new guidelines can be accepted across considerations, specific to PKI, are needed to be applied to make borders in other participating jurisdictions. Therefore, cross- this determination, but as discussed, ISO 17025 accommodates border PKI could be constructed as follows. this nicely. We should expect supplementary guidelines to be The new PKI model treats digital certificates as the products of a developed during the course of establishing the PKI model. special class of manufacturers, namely, RAs and CAs working in The chain of digital certificates corresponding to the different concert. The model also rests on the fact that from one jurisdiction levels of conformity assessment could terminate at the accred- (or industry) to another, reasonable decisions have already been itation body, with a self signed certificate. And yet the existence made and broadly accepted regarding the appropriate standards of international accreditation co-operations and MRAs presents that should govern RAs and CAs (including for example X.509, the tantalizing prospect of cross border PKI resulting almost as a the PKIX series, RFC 3647, or the detailed Identrus technical by-product of existing arrangements, with a conceptually simple requirements). Some jurisdictions and industries have gone one switch from paper-based audit and accreditation certificates to step further to select or design for themselves an appropriate PKI digital certificates representing the same thing. conformity assessment program. Examples include Webtrust for To operationalize the PKI, national accreditation bodies would act CAs (which was adopted by Microsoft as a pre-condition for as jurisdictional Root CAs. It would not be necessary for these being included in Internet Explorer’s list of Trusted Certification bodies to actually build and operate the CAs themselves; rather, Root Certification Authorities), Gatekeeper, Identrus they could outsource certificate production and concern them- accreditation (which has come to be recognized by Gatekeeper30), selves only with an RA. When looking at the potential legal or various countries’ local regulations implemented under the liability of an accreditation body taking on the role of digital European community framework for electronic signatures31. certificate issuer, we should be reminded that their proposed role Referring to the three preconditions for being able to accept a in PKI is the identical to their role in traditional conformity certificate cross-border, as defined in subsection 4.3.1, the assessment schemes; that is, they ‘audit the auditors’. As such, proposed PKI model will deliver two32 of them: their potential liability is well understood in industry, and tends to 1. the conformity of the certificate issuer with agreed be well contained. If the digital certificates issued by accreditation standards would be assessed by an approved PKI bodies in this proposal are understood to mean nothing more and auditor, and the results of that assessment conveyed to nothing less than the fact that the certificate Subject is an the receiver, and accredited PKI auditor, then the fact that the accreditation body is acting as a “Root CA” shouldn’t introduce any new liabilities. 2. the intended purpose of the certificate would be precisely specified by its Policy OID (the uniqueness of Figure 5 illustrates the proposed ISO 17025 MRA based PKI. The which on the relevant domain would be enforced by the grey boxes represent the chief participants in the PKI, from CA audit). through to international cooperation association (note that every one of these players already exists). The nested boxes show the scope or community of each participant: the smallest boxes are for 28 See http://www.aplac.org/aplac_mra.html. the members served by each CA, intermediate for the CAs 29 See the various scopes of recognition for each of the APLAC inspected by each auditor, and largest for the auditors inspected MRA signatories at http://www.aplac.org/aplac_mra.html by each accreditation body (note how the communities are nested (accessed 8 Jan 2008). at the levels of country, auditor and CA). The block arrows 30 indicate the frame-work that governs the work of each participant. See http://www.dbcde.gov.au/Article/0,,0_4-2_4008- At the top level, a working assumption is that of the existing types 4_116523,00.html (accessed 8 Jan 2008). of MRA, an appropriate heading for PKI would be “inspection” 31 (as opposed to calibration or testing). See http://europa.eu/scadplus/leg/en/lvb/l24118.htm (accessed 8 Jan 2008). 32 The third precondition had to do with the certificate not being revoked; the ability to perform a CRL or OCSP check is taken for granted here. Cooperation MRA (scope: Inspection) cooperation, which issued (or had issued on its behalf) a Cooperation digital certificate to the accreditation body. Peer evaluation w.r.t. equivalence The certificate chain conveys the membership of all participants in Multiple countries the scheme as anchored by the root key controlled by the top level cooperation. And yet certificates that chain through different Accreditation Accreditation Body Body ISO 17025 auditors and accreditation bodies are entirely autonomous. Neither Accreditation w.r.t. competence, independence the root nor the intermediate accreditation bodies would impose Multiple auditors any arbitrary policies on the conduct of end user CAs and communities of interest. The uniqueness of the end user certificate PKI PKI Auditor Auditor PKI Audit Regime Policy OIDs plus the separation of powers of auditors and Conformity assessment w.r.t. PKI standards accreditation bodies means that the one PKI could embrace any number of diverse communities, and could accommodate existing Multiple CAs closed PKI programs like Identrus or WebTrust for CAs so long as their methods are transparent and compatible with ISO 17025. CA CA PKI Standards 5. CONCLUSIONS There is no intrinsic reason that PKI should be as complex as it Figure 5: A PKI based on ISO 17025 Mutual Recognition has. Plenty of complicated physical principles have been success- Note that the proposed PKI can be grown from the bottom up. It fully engineered and deployed as commercial technologies, such is not necessary for an international cooperation to come on board as magnetic stripe cards. PKI historically has been unwittingly right away; in the interim it would be practical to have local self- burdened by well intended metaphors, such as that of the passport, signed trust anchors for each of the jurisdictional accreditation that associated it with a vague ideal – universal identification of bodies. Whenever a new body joins an MRA and has its processes strangers online – which turned out to be hugely complicated and approved, it follows that all CAs within its jurisdiction automatic- not even necessary. Meanwhile, smaller scale, closed PKIs have ally enter the fold of the international scheme. Thanks to their prospered in support of special purpose applications. This fact can maturity and long established authority, having accreditation now be appreciated as the natural state of affairs, resonant with bodies in the PKI solves the hoary problem of infinite regress; that the modern view of identity plurality. is, how far back do you go before you find a CA you can “trust”? We should build on the deeper lessons of successful closed PKIs, The answer is you stop at a national body, or ultimately at an to regard certificates as evincing not absolute identity but rather international cooperation like APLAC or ILAC. Most important any number of relationships, with special meaning in the contexts of all, because there are existing protocols and agreements by in which the certificates were issued and intended to be used. This which national accreditation bodies recognize and work with one simple change of aspect could herald a true paradigm shift, another, this approach to PKI provides a natural and robust means rendering digital certificates and their production much more for cross-border recognition of digital certificates. mundane. Radical improvements would result on several fronts. In closing this account of an international PKI, let us remember Firstly, the practical application of PKI would be greatly what it is that a certificate chain can represent. If the receiver of a simplified by breaking the nexus between authentication and auth- digital certificate knows what end user Policy OID is appropriate orization, for it allows X.509 formatted Relationship Certificates to the transaction at hand, and if the receiver’s software has a to stand alone in most transactions. Secondly, by localizing RA trusted copy of the root key, then any certificate featuring that functions and more effectively decoupling certificate production, OID which chains to that root key can be taken to be fit for we could operate back-end CAs along the same lines as security purpose, no matter which CA issued it. Certificate chains in this printers, with vastly simpler legal arrangements than seen in international PKI scheme would each embody an unambiguous orthodox PKI. And finally, existing nested frameworks for con- cascade of dependable assertions: formity assessment and accreditation provide the ready means for cross-border recognition of certificates, knitting together today’s − The end user was vouched for with reference to a certain CP heterogeneous PKI applications, policies and audits into the one by an RA authoritative in a given community, and was issued international Public Key Superstructure. a certificate with a corresponding unique Policy OID, produced by a named CA. − The CA was approved with reference to agreed standards, 6. ACKNOWLEDGMENTS CPS etc. by a named PKI auditor, which issued (or had The concept of “Relationship Certificates” was originally re- issued on its behalf) a digital certificate to the CA. searched and developed by Lockstep Consulting under contract to − The auditor was approved with reference to ISO 17025 by a the former Australian Department of Finance and Administration, named accreditation body, which issued (or had issued on its represented by the Australian Government Information Manage- behalf) a digital certificate to the auditor. ment Office (AGIMO). The author gratefully acknowledges the permission of AGIMO to reproduce aspects of that work. − The accreditation body was approved with reference to a Mutual Recognition Agreement by a named international [15] Freeman, R., Trust Services – A Market Appraisal, Mack 7. REFERENCES Interact (2002) [1] APEC Telecommunications Working Group – E-Authent- http://www.tscheme.org/library/tSi0156_01%20TSP%20mar ication Task Group, Achieving PKI Interoperability (1999). ket%20status%20report.pdf (accessed 19 Nov 2007). [2] APEC Telecommunications Working Group, Electronic [16] International Organization for Standardization, General Authentication: Issues Relating to its Selection and Use requirements for the competence of testing and calibration ISBN 981-04-7690-6 (2002). laboratories, ISO/IEC 17025:1999. [3] Australian Department of Health and Ageing, Electronic [17] Jøsang, A. & Pope, S., User Centric Identity Management, Signatures for Prescribing and Dispensing, eHealth Branch AusCERT Security Conference 2005 (Gold Coast, Australia) (2006) http://www.msia.com.au/esig_prescript_document.pdf (2005). (accessed 31 Jan 2008). [18] Kent, K. Global PKI: Status, Trends and the Future Taipei [4] Australian Government Information Management Office International PKI Conference (Taipei, September 2005) (AGIMO), Gatekeeper PKI Framework Cross Recognition http://www.pki.org.tw/pkiforum2005/d_file/01_Stephen%20 Policy, Department of Finance and Deregulation (2008) Kent.pdf (accessed 23 Nov 2007). http://www.gatekeeper.gov.au/__data/assets/file/0004/52276/ [19] National Office for the Information Economy, Liability and Cross_Recognition_Policy.rtf (accessed 8 Jan 2008). Other Legal Issues in the use of PKI Digital Certificates, [5] Australian Government Information Management Office Australian Department of Communications, Information (AGIMO), Relationship Certificate Guidebook, Department Technology and the Arts (2000). of Finance and Administration (2006) [20] Nazareth, S. & Smith, S. W. Using SPKI/SDSI for http://www.agimo.gov.au/__data/assets/pdf_file/0016/52252/ Distributed Maintenance of Attribute Release Policies in Relationship_Guidebook.pdf (accessed 19 Nov 2007). Shibboleth, Computer Science Technical Report TR2004- [6] Barnes, R. & Kent, S. An Infrastructure to Support Secure 485, Dartmouth University (2004) Internet Routing, IETF Secure Inter-Domain Routing http://www.ists.dartmouth.edu/library/spk1004.pdf (accessed Working Group (2007) http://tools.ietf.org/id/draft-ietf-sidr- 31 Jan 2008). arch-00.txt (accessed 31 Jan 2008). [21] Smith, P., Trust and Digital Certificates, 16th Payment [7] Barnett, S. A pilot project: Sending encrypted specialist Systems International Conference (Belgium, 2000). letters to GPs, Health Openware Foundation Argus Forum, [22] Sneddon, M. Legal Liability and e-transactions, Australian (Canberra, Australia, 2004). Department of Communications, Information Technology [8] Brewer, J. & Wilson, S., Smartcards and PKI at Medicare and the Arts (2000). http://www.egov.vic.gov.au/pdfs/ Australia, Australian Electrical & Electronic Manufacturers publication_utz1508.pdf (accessed 23 Nov 2007). Association ICT Forums (2006) [23] Standards Australia, Strategies for the implementation of a http://www.aeema.asn.au/ArticleDocuments/41/Smartcards% Public Key Authentication Framework (PKAF) in Australia, 20and%20PKI%20at%20Medicare%20Australia%20- Miscellaneous Publication MP 75 (1996). %2014Feb06.pdf (accessed 31 Jan 2008). [24] Victorian Office of the Chief Information Officer, Land [9] Burr, W. Electronic Authentication in the U.S. Federal Exchange (LX) Case Study, Government of Victoria (2004) Government, Asia PKI Forum, Tokyo (2005) http://www.egov.vic.gov.au/pdfs/Land%20Exchange-shh- http://www.asia-pkiforum.org/feb_tokyo/NIST_Burr.pdf 30April-v1.0-CIO.pdf (accessed 21 Nov 2007). (accessed 23 Nov 2007). [25] Wilson, S. New models for the management of public key [10] Cameron, C. The Laws of Identity, Microsoft Corporation infrastructure and root certification authorities. In Proceed- (2005) http://www.identityblog.com/stories/2005/05/13/ ings of Information Security Management & Small Systems TheLawsOfIdentity.pdf (accessed 31 Jan 2008). Security (IFIP WG 11. 1/2) (Amsterdam, Sept 30 - Oct 1, [11] Common Criteria, Arrangement on the Recognition of 1999). Kluwer, Deventer, The Netherlands, 1999, 221-230. Common Criteria Certificates in the field of Information [26] Wilson, S. Leveraging external accreditation to achieve PKI Technology Security (2000) cross-recognition, Australian Attorney General’s Privacy http://www.commoncriteriaportal.org/public/files/cc- and Security in the Information Age Conference (Melbourne, recarrange.pdf Australia, 16-17 Aug 2001) [12] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., http://www.ag.gov.au/www/agd/agd.nsf/Page/Privacy_Privac & Ylnen, T. SPKI Certificate Theory RFC 2693, IETF SPKI yandSecurityintheInformationAgeConferencePapers Working Group (1999) ftp://ftp.isi.edu/in-notes/rfc2693.txt (accessed 31 Jan 2008). (accessed 31 Jan 2008). [27] Wilson, S. Guidelines on how to determine Return on [13] Ellison, C. & Schneier, B. Ten Risks of PKI: What You’re Investment in PKI, OASIS PKI Education Sub-committee, not Being Told about Public Key Infrastructure Computer V 1.4 (2005) http://idtrust.xml.org/guidelines-how- Security Journal 16, 1 (2000). determine-return-investment-pki (accessed 14 Jan 2008). [14] Forey, M., Cheque Printer Accreditation Scheme, Xplor [28] Winn, J. K. The Emperor's New Clothes: The Shocking Document Management Conference (Anaheim, California, Truth About Digital Signatures and Internet Commerce, 37 USA, 2002). Idaho L. Rev. 353 (2001) Public Key Superstructure It’s PKI Jim, but not as we know it! 7th Annual “IDtrust” Symposium 5 March 2008, Gaithersburg MD, USA Stephen Wilson Lockstep Consulting Pty Ltd About Lockstep • Consultants specialised in PKI, smartcards & privacy • Developing novel de- identification and online safety solutions About Lockstep • Asia PKI Forum • Gatekeeper Policy Committee • Aust. Law Reform Commission Historical PKI experience The passport metaphor • Non-descript applications – impossible for CAs to manage risk • Stranger-to-stranger e-business – “It’s good to trust but it’s better not to” • Novel TTP business models – Imposed incredible CPSs upon users • Notion of a single identity – “Interoperability” = cross certification “Cross-certification and policy mapping has been a rat hole that has sucked up vast amounts of energy better spent elsewhere” Anonymous, Feb 2008 PKI thickets 1999 RSA Conference “Fading PKI Market” June 2003 Identrus Verisign IPO 1999 2002 2005 2008 PKI in practice • Works best in closed communities – Automates transactions in context – This is a Good Thing • Embedded keys & certificates • Fits with identity plurality PK Superstructure CA as Security Printer Security Distribute bar code labels Printer Listed Company Achieve Listing Listing Listing Listing Listing Listing Listing Listings Rules Rules Rules Rules Rules Rules Department Officer Announcements Announcement Fax OCR Affix bar code Stock Exchange CA as Security Printer CA Distribute certificates, keys Listed Company Listing Listing Listing Listing Listing Listing Listings Rules Rules Rules Rules Rules Rules Department Announcements Announcement Message Message App App Digitally sign Stock Exchange Security printer implications • Decouples registration from production • Manages risks associated with registration & production separately • No contract between Subscriber & CA • No exposure of CPS to Subscriber • Easier to novate CA service providers • Accreditation not affected by new Policies “Relationship Certificates” Signed: Health Root CA Signed: Health Org CA e-Prescription Signed: Dr Lic. xyz Credentials Health Org CA Patient name - - Subject: - - - Subject: - - - Med - - - Ext: Lic No. xyz Validity: - - - Dose - - - Issuer: Health Org Issuer: Root CA Repeats - - - Policy OID: - - - Policy OID: - - - Public Key: - - - Public Key: - - - Transaction User Certificate CA Certificate Health Organisation Context “Relationship Certificates” • Form of “Authorization PKI” • Kill the holy cow of authentication being primary over authorization • Preserves X.509 formats, software • Not SPKI: no ‘primary’ ID certificate • Not Attribute Certs: we can sign with cert Lockstep anonymous e-voting Certificate Serial No. CA Candidate Poll Candidate Key Sign Candidate Dig Register Certificate smartcard Serial No. Poll Key Install anon. certificate Generate key pair Identify voter 2 Candidate Candidate Enrol to vote Roll 1 Candidate 2 Candidate Smartcard Candidate Signed distribution process Sign Dig ballot 1 Candidate A. Background B. Register C. Vote Lockstep clinical study privacy (1) Distribute investigator packs Logistics Certificate Server Randomisation Collection (3) Load pt smartcard Study sponsor Certificate Patient ID with Stepwise (2) Enrol patient Study ID anonymous ID into study Key Sign Dig Lockstep clinical study privacy Certificate Patient ID Study ID (6) De-identified secure Key (4) Patient presents follow up data, “sealed” for follow-up with Stepwise ID Logistics Certificate Server Randomisation (5) Investigations Collection as per protocol Study sponsor Tests Discussion See also www.lockstep.com.au/technologies swilson@lockstep.com.au Audit and backup procedures for Hardware Security Modules Túlio Cicero Salvaro de Jean Everson Martina† Ricardo Felipe Custódio Souza Computer Laboratory - LabSEC – UFSC∗ LabSEC – UFSC∗ University of Cambridge Florianópolis – SC – Brasil Florianópolis – SC – Brasil Cambridge – United Kingdom custodio@inf.ufsc.br salvaro@inf.ufsc.br Jean.Martina@cl.cam.ac.uk ABSTRACT and destroy (private) keys, maintaining an audit trail of ev- Hardware Security Modules (HSMs) are an useful tool to ery operation which was done during their existence. Such deploy public key infrastructure (PKI) and its applications. systems are known as Hardware Security Modules (HSMs). This paper presents necessary procedures and protocols to HSMs are specialised tamper-proof devices in which cryp- perform backup and audit in such devices when deployed in tographic functions and embedded software have been built PKIs. These protocols were evaluated in an implementation to properly manage keys and control their life cycles. They of a real HSM, enabling it to perform secure backups and are designed in such a way that if an unauthorised attempt to provide an audit trail, two important considerations for a to access them is made, this is considered an attempt to safe PKI operation. It also introduces a ceremony procedure tamper and all critical internal parameters and keys are de- to support the operation of such HSMs in a PKI environ- stroyed. ment. Although very common in the banking industry, HSMs are also desirable in PKI, but not always implemented. As shown in Table 1, their common usage in the banking indus- Categories and Subject Descriptors try leads to specialisation of the HSMs to perform tasks such C.2 [Computer communication network]: Miscellaneous; as PIN calculations or payment protocols, that are suitable D.4.6 [Security and protection]: Cryptographic controls; in such industry. E.3 [Data Encryption]: Public key cryptosystems In a PKI environment, the required characteristics are dif- ferent from those for banks. In a PKI HSM, it is necessary to establish who can configure, who can access the keys and Keywords who can audit the system. For a PKI HSM, it is desirable Key Management, Public Key Infrastructure, Embedded to have at least three different roles for users. Cryptographic Hardware, Hardware Security Module, Key It is also recommended not to establish these roles for Life-cycle, PKI Ceremony single users since they are easily corruptible, but also to use triggered group mechanisms, such as defined by Shamir[17] 1. INTRODUCTION and Blakley [2]. Securely managing keys is one of the most important and resource consuming tasks required to guarantee the security Table 1: Comparison between Bank and PKI HSMs on a public key cryptosystem. This is due to a close re- Bank HSMs PKI HSMs lationship between security and the proper management of PIN Calculation Strong authentication private keys. A public key cryptosystem can be considered Role based authentica- Identity based authenti- secure as long as the private keys are secured. Taking this tion cation as a premise, it should be guaranteed that a (private) key is strictly secure during all events in its life cycle. This goal can Dual key entry Strict key life-cycle con- be achieved by designing systems to securely create, manage trol Payment protocols Fully auditable opera- ∗ Computer Security Laboratory at Federal University of tion Santa Catarina. Cryptographic speed Triggered group mecha- † Supported by CAPES Foundation/Brazil on grant #4226- nisms 05-4 Normally, it is established groups of administrators (also known as security officers), operators (also known as users), Permission to make digital or hard copies of all or part of this work for and auditors, who can track all operations done by the pre- personal or classroom use is granted without fee provided that copies are vious groups. The administrators are responsible for creat- not made or distributed for profit or commercial advantage and that copies ing auditors, operators and the keys managed by the latter. bear this notice and the full citation on the first page. To copy otherwise, to The operators are responsible for releasing the keys for use republish, to post on servers or to redistribute to lists, requires prior specific in an application. The auditors are responsible for analysing permission and/or a fee. IDtrust ’08 March 4-6, 2008, Gaithersburg, MD the hardware’s logs, which register everything that happens Copyright 2008 ACM 1978-1-60558-066-1 ...$5.00. inside the HSM - for instance, when a key is used. Responsi- bility and trust in the keys generated, used and destroyed in As already exposed in section 1, this work is directly de- HSMs are anchored in these three groups. Moreover, every rived from the work by Martina[13] in the effort of estab- person who is designated as a member of a group should be lishing an open protocol to run embedded in HSMs. The carefully selected and all tasks executed by him be registered protocols proposed by Martina in his work are used to cre- by automated devices in the PKI context. ate a liable environment to store our private keys for PKI Much has been written about HSMs, especially concerning usage. The main characteristics of these protocols are the administrators and operators. However, there is no detailed existence of an internal PKI, where all administrative keys information about audit schemes or backup procedures in are subject of, the existence of groups to share the control HSMs. All developments in this field were done by compa- over the roles being used, and the existence of two different nies[9, 14, 10, 5, 11], which never published all their internal roles: the administrators (security-officers) and the opera- mechanisms due to industrial secrets concerns and users, tors (users). Another important characteristic of this work and people outside these companies, have no detailed infor- is the establishment of policies when enabling keys to use, mation about their internal protocols. giving in this way a very strict control over their usage. In this context, “backup” is a way of making a copy of the Although we see a growing concern about key escrow sys- internal state of the HSM. With a backup, one can prepare tems to give availability to (private) keys [16, 3] in a secure new hardware and put it to work as a fully functional copy way, there is very few specific work relating this with the of the previous HSM. Additionally, the HSMs are products confinement idea of Hardware Security Modules, where we produced by specialised companies and are given some eval- have a cryptographic perimeter. uation tests, as described by FIPS 140-2[8]. Some companies have been working in addressing the prob- The HSMs are very expensive devices to use in places such lems of make backup copies of operational HSM. Ncipher as universities and research centres. There are many of these Corporation, address the problem in their nShield Series[14], institutions that would like to deploy a PKI for internal use. by designing what they call a Security World. A security Due to the high cost of the HSMs, most of these institutions world consists in a cryptographically wrapped environment decide not to use them. Keys are kept in the memory of the that is saved in the host machine with all the content of host machine which runs the certificate management system. the HSM. This security world will only be unwrapped in This is a security concern. an authorised HSM, that belongs to the security world in Recently, the National Education and Research Network question. This approach gives very little auditing data, and (RNP), a Brazilian social organisation, has created a work- trusts blindly in the administrators’ group. ing group called GT ICPEDU, the main aim of which is to Other approach includes token replication [5], which in- study and develop hardware and software to deploy PKIs for volves just copying the private keys to other tokens in a con- its members. One of its projects was to design an HSM. The trolled way, leaving administrative and auditing data behind hardware architecture of this HSM was conceived by the GT and without backup. ICPEDU and built by a local company. The software im- It can look simple, but it is not easy to make a backup of plementing the full keys’ life cycle protocol designed for use an HSM. First of all, rigid control is needed in the number in PKI environments, called OpenHSM, was the product of of keys and their usage. This requirement must be taken an undergraduate final work [18] and a master’s thesis [12]. into account when the backup procedure is carried out. A The keys’ life cycle protocol passed through several stages of basic protocol might be for administrators to copy the in- development and improvement. Part of its final version was ternal data of the HSM and transfer it to new hardware. described by Martina [13]. Two important parts of the pro- The problem with this and other protocols is that it is hard tocol, which have not been described yet, are presented by to control the backup and keep it safe. To improve simple this paper: backup procedures and an audit control mecha- protocols, the backup may remain encrypted by the admin- nism. istrators’ public key. If this is done, only the administrators This paper considers in section 2, why auditors and backup can install the backup onto new hardware. However, doing are important issues in the use of HSMs in PKI deployments this means trusting the administrators blindly. and presents related works about these services. Section 3 Blind trust issues are always not recommended by best describes the premises used to state the audit and backup security practices in PKI [4]. It has shown that it is advis- schemes and two basic algorithms used to create and authen- able to have an independent group to audit the procedures ticate groups. Section 4 describes the auditing scheme while performed by administrators. To achieve this, we should in- section 5 describes in detail the backup schemes. Section 6 troduce the auditors role. A protocol should be designed to presents the certification practice statement, in which is de- take into account two different kinds of user profiles — ad- scribed the steps to be followed when a PKI is deployed and ministrators who make the backups and auditors who trace briefly introduces the backup-file creation ceremony. The the number of backups created, and the number of them statement includes policies and tasks, and explains how the made operational. witnesses can guarantee the backup procedure. Section 7 Each time the HSM is used, the auditors should analyse gives an overview of the main contributions to the field the logs produced. To carry this out properly, it is necessary this paper presents and the next step to be undertaken by to have previously established a PKI practice statement. the working group. Appendix states the primitive functions This statement is a document which describes different cer- used in the proposed algorithms. These are session key gen- emonies, including important ones such as when a backup is eration, secret sharing schemes, asymmetric key generation, created, and when a backup HSM is made operational. We load and store information, encryption and decryption, and will discuss this issue in Section 6. cryptographic token tasks. Other important and parallel work to be overviewed is the key management in group protocols and communications 2. RELATED WORK [15, 1]. Although not directly related, studies in this field show that it is often difficult to assure the behaviour of any Algorithm createGroup(DS, id, m, n, ch , krh ) 1 involved party in group protocols. So, in this way, this is a Creates a group based on secret sharing scheme, gener- reinforcement for the point of applying an auditing strategy ating a key pair (kri and kui ) and a certificate (ci ) for and a ceremony design to trace these known problems. each member (si ). The members’ certificates are issued by HSM using its private key (krh ) and information en- tered using the host machine (hm). The issued certificate 3. BASIC ALGORITHMS and corresponding private key are stored into the cryp- This paper deals with backup and audit procedures of an tographic token (ct) belonging to each group’s member. HSM. Some premises were taken into account to facilitate The group’s session key (ks), which is split in n shares, the description of these procedures. Moreover, there are two is also returned as a result of the algorithm run. basic protocols that are used to create and to authenticate 1: ks ← genKeySession() groups. This section lists these premises and protocols. 2: Ks ← splitSecret( ks, m, n ) The premises are: 3: for ksi in Ks do • HSM when initialised generates a key pair (krh , kuh ) 4: (kri , kui ) ← genKeyPair() and a self signed certificate (ch ). This certificate is 5: idi ← load( hm, si ) used to uniquely identify the HSM and is trusted to 6: ci ← genCert( idi , kui , ch , krh ) issue certificates to the groups’ members; 7: store( ctsi , kri , ci , ch ) • each type of group has different data storage (DS). 8: eksi ← encrypt( ksi , ci ) N.b. administrators’ data storage (ADS) for admin- 9: store( DS, id, ci , eksi ) istrators, auditors’ data storage (AudDS) for audi- 10: end for tors and operators’ data storage (ODS) for operators 11: store( DS, id, m, n ) groups. Although they look like different pieces in the 12: return ks algorithm descriptions, when analysing and formalis- ing the algorithms we consider them part of the owning principals; id and his certificate ci . Finally, in steps 11 and 12, the • each group has an identifier (id) which uniquely refers values of m and n are stored and the group’s session key is to one group of the same type in an HSM. This is not returned. true for administrator groups because an HSM has just Authenticating a group and recovering the group’s session one valid group at the same time; key (ks) is another common procedure used in the HSM. • each group uses the secret sharing scheme[17, 2], own- To authenticate, the algorithm authenticateGroup uses ing a symmetric key (ks), that is split in n shares where a nonce u in order to avoid Dolev-Yao’s replay attack[6] as at least m must be joined to recover the group’s key. explained by Martina[13]. The thresholds must follow the rule: 1 ≤ m ≤ n. A set of shares is represented by Ks; Algorithm authenticateGroup( DS[, id] ) 1 • each member of each group receives a key pair (kri , kui ) Authenticates a group identified by id in the data storage and a certificate (ci ), issued by HSM. Each member DS. The member’s certificates are read from the crypto- owns a cryptographic token (ctsi ) to store this infor- graphic token ct. The process is, basically, to decrypt at mation for authentication; least m pieces of shared secret, using members’ private • A share is assigned to each group’s member. This share key, joining after to recover the group’s session key ks. is encrypted by using the public key of the member’s 1: m ← load( DS[, id] ) certificate. The shares are used for group authentica- 2: for i = 1 to m do tion; 3: ci ← load( ctsi ) • every internal certificate is verified before its use; 4: eksi ← load( DS[, id], ci ) 5: u ← genKeySession() The first common algorithm to be stated, after the premises 6: eu ← encrypt( u, ci ) presented, is the createGroup(). It works to create admin- 7: eksu ← ctDecrypt(ctsi , eksi , eu ) istrators, operators and auditors groups. 8: ksi ← decrypt( eksu , u ) The createGroup() algorithm starts creating a session 9: end for key ks for the group. In step 2, ks is split in n parts where 10: ks ← joinSecret( Ks ) at least m are required to recover it, resulting in Ks, a set 11: return ks of shares. The steps between 3 and 10 are executed n times, a time for each member of the group. Starting the loop, A group’s authentication starts loading from DS the in- in step 4, a key pair is generated for the current member. formation of threshold m identified by id. This information Following, in step 5, the HSM loads from the host machine is used for the iteration which will use enough shares to the name of the member idi . This name will be used in step recover the group’s session key. In step 3, the current mem- 6 as the member’s distinguished name on the certificate ci ber’s certificate (ci ) is loaded from his cryptographic token. issued by the HSM. After that, the private key (kri ), the In step 4, the encrypted share belonging to the member is certificate (ci ) and the HSM’s certificate (ch ) are stored in loaded from DS. In steps 5 and 6, the nonce u is generated his cryptographic token ctsi . In order to perform future and then encrypted by using the member’s public key (which authentication, the member’s share is encrypted and, after, can be found in ci ). In step 7, the encrypted share and the stored into the group’s data storage (DS) with identification nonce are sent the cryptographic token to be decrypted us- 1 ing the member’s private key. The result of this operation All descriptions for principals and primitive functions are available in the Appendix under section A will be the shared secret encrypted using u as a key session. In step 8, a piece of the group’s secret is decrypted. After at encrypted by using its key session. After that, all required least m shares be decrypted, ks can be recovered as stated data describing the auditors group are stored into AudDS, in step 10 and, finally, the algorithm returns ks in step 11. such as the group’s identifier (id), certificate (cau ) and en- crypted private key ekrau . Finally, the group’s certificate is 4. AUDITING SCHEME exported as a result of the algorithm. To meet all the security requirements of the process, au- In order to achieve the objectives of auditors groups the dit trails must be created, and a specific group of people, next algorithm is presented. It implements the protocol to who will act as the HSM auditors, should be defined. Their export the HSM’s logs. It enables the auditors to trace all main purpose is to collect auditing data from the HSM, en- operations that have occurred in the HSM. The algorithm, abling them to analyse the administrators group behaviour basically, authenticates the auditors group which is request- and to report any incident to the PKI’s management team. ing the log and, using its private key, signs the log package. This team should take the necessary procedures in order to Afterwards, the signed log package is exported. guarantee the security of the whole PKI. Algorithm exportLog( id [, rangeDate] ) 1 The auditors groups in an HSM should be considered as Allows an auditors groups, identified by id, to export the an inspection body. They always act with the purpose of signed HSM’s logs. It’s possible to specify a date range assuring that other groups are acting and behaving as ex- rangeDate pected by their controlling authority (like PKI policy team). 1: ks ← authGroup( AudDS, id ) The auditors group is also an important piece in the whole 2: ekr ← load( AudDS, id ) OpenHSM protocol, because it checks the auditing trail dur- 3: kr ← decrypt( ekr, ks ) ing the entire life of an HSM, and assures that no tampering, 4: L ← load( LDS, rangeDate ) physical or logical, happens to the HSM while it is being used 5: sL ← sign( L, kr ) or kept in storage. 6: return( sL ) Our proposal states that the HSM should have at least one auditors group, but this does not limit the possibility of having more than one. Even the auditors group should The exportLog algorithm starts when an auditors group not be trusted by other groups, and should be inspected by informs its identifier id and, optionally, a date range, spec- others. No destruction or changes to the auditors groups ifying a period for the logs. In step 1, the auditors group are planned, because a new group can easily be created if is authenticated and the group’s session key ks is returned an existing one has been compromised, since they do not as result of it. The group’s encrypted private key is loaded perform any vital cryptographic operations in the OpenHSM in step 2, and then, decrypted. In step 4, the specific block protocol. of log is selected and, therefore, signed in step 5 using kr. The creation of an auditors group must be made just after Finally, the signed log sL is exported. the initialisation of the HSM, and the creation of the admin- istrator groups, so it will be possible to audit everything that 5. BACKUP SCHEME happens in the HSM life cycle. The createAudGroup al- The following sections present diagrams and descriptions gorithm has been proposed to handle the creation of auditors of the algorithms relating to the backup procedures, show- group. ing how to create a new operational HSM by installing the most recent copy of the data used by the old HSM into new Algorithm createAudGroup(id, m, n) 1 hardware. Creates an auditors group id following threshold n and m, authenticating the administrators group before. A 5.1 Preparing an HSM to be a backup unit key pair is created and assigned to it The first step, in having a secure backup system, is ob- 1: ksad ← authenticateGroup( ADS ) taining a spare hardware which is specifically configured to 2: ch , ekrh ← load( ADS ) replace the existing HSMs when required. This hardware 3: krh ← decrypt( ekrh , ksad ) should be on standby, ready to become functional by receiv- 4: ksau ← createGroup( AudDS, m, n, ch , krh ) ing data previously copied from an operational HSM. 5: krau , kuau ← genKeyPair() The preparation requires no initial information from any 6: cau ← genCert( id, kuau , ch , krh ) operating HSM, only the hardware in its factory state. The 7: ekrau ← encrypt( krau , ksau ) procedure is even possible when there are no operational 8: store( AudDS, id, cau , ekrau ) HSMs. As soon as an HSM is prepared to be a recipient, it 9: return cau becomes possible to make a backup of the operational HSM. A backup of an operational HSM can only be made by using The createAudGroup algorithm starts when the admin- the certificate of the backup HSM. The administrator group istrators group enters the identifier, id, and the thresholds must install this certificate into the operational HSM before for the new group, m and n. In step 1, the administra- it can create any backup file. tors group is authenticated using authenticateGroup() Once the backup HSM is a backup unit, it cannot be used algorithm, recovering the group’s session key (ksad ). From for other activities. The backup itself is an encrypted copy ADS, the certificate ch and encrypted private key ekrh of of the data from an operational HSM. This encrypted copy is the HSM is loaded. The private key is decrypted in step made by the administrators of the HSM from which should 3 using ksad . In step 4, the auditors group is created and make new copies from time to time, as established in the the group’s key session ksau is the result of it. In step 5, PKI practice statement. The physical security of the HSM the key pair of the group is created. HSM, in step 6, issues is responsible for guaranteeing the backup private key, krbkp , the group’s certificate. In step 7, the group’s private key is enclosed. The algorithm proposed to handle the preparation of an could have been generated anywhere. So, here, it is essen- HSM to be a backup unit is as follows: tial to have a record and an auditing group to inspect it. Certificates that have been imported must be verified by the Algorithm prepareBkpHsm( idbkp ) 1 auditor group: importing a flawed backup certificate could Prepares an HSM to be a backup unit, generating a key lead to leakage of sensitive material. pair (krbkp and kubkp ) and, then, issuing a self-signed To import a backup certificate into a operational HSM, it certificate cbkp using it. The certificate is exported as must be initialised and must have an administrators group result of it beforehand. The algorithm to import a backup certificate 1: krbkp , kubkp ← genKeyPair() into an operational HSM is as follows: 2: cbkp ← genSelfSignedCert( krbkp , kubkp , idbkp ) 3: store( BDS, krbkp , cbkp ) Algorithm importBkpCert( cbkp ) 1 4: return cbkp Imports a backup Certificate (cbkp ) which has been ex- ported from a backup HSM. The authentication of ad- To run the prepareBkpHsm algorithm, the administra- ministrators group is required. tors group sends the information idbkp to the new HSM, 1: ks ← authenticateGroup( ADS ) which is used for issuing the self-signed backup certificate 2: ekrh ← load( ADS ) cbkp . Starting in step 1, the HSM generates a key pair 3: krh ← decrypt( ekrh , ks ) krbkp and kubkp . This pair and the idbkp information are 4: scbkp ← sign( cbkp , krh ) the required data to issue the self signed certificate cbkp in 5: store( BDS, scbkp ) step 2. Therefore, krbkp and cbkp are stored in the backup data storage (BDS), keeping krbkp inside the cryptographic To start the importBkpCert algorithm, the adminis- perimeter of the HSM until it is necessary to recover a secure trators group must give the backup certificate cbkp to the backup. HSM. Following, the HSM authenticates the administrators To enable the administrators to follow the next algorithm, group, in step 1, and release the HSM’s private key krh over the result of this algorithm is a certificate cbkp , which con- the steps 2 and 3 (this process is covered in section 4). Fi- tains the information sent by the administrators during the nally, cbkp is resigned using krh and stored into backup data initial phases of this protocol run. storage (BDS). The backup certificate is resigned to avoid any unauthorised inclusion in the BDS of unrelated backup 5.2 Importing a Backup Public Key Certifi- HSM certificates. cate Figure 1 illustrates how a backup certificate is exported 5.3 Creating Backups One of the most important operations in an HSM is to create secure and targeted backups. First, it must be stated that the backup creation process is a very delicate procedure, because it goes directly against normal goals, i.e., to keep sensitive cryptographic material inside the HSM protected perimeter. It is also something that must be done to ensure the continuity of the key life cycle, even in the case of a hardware fault, or because of tampering. Figure 1: Copying the backup certificate. from a backup HSM and imported into an operational one. It is possible to use the same or different host machines to do so. By running the remote management system in the Host, the new hardware is commanded to work as a backup Figure 2: Creating backups. HSM. Upon receiving the command, the new hardware gen- erates its own key pair and self signed certificate. Next, Despite this, periodic copies of the HSM content must be Host downloads the certificate and saves it as a file. By made in order to enable the recovery of the whole environ- using the remote management system again, the certificate ment just in case of a failure. Figure 2 illustrates this idea. is uploaded into the operational HSM. After this, the opera- Data can only leave the internal perimeter of the HSM tional HSM can make backups of its internal data. With this in an encrypted form; the design of the proposed backup design, there is no limit to the amount of backup certificates process can therefore be described as ”secure” as stated in that can be imported into an operational HSM. The backup, FIPS 140-2[8]. And it can also be labeled as ”targeted” be- made in this way, can be installed in any one of the prepared cause the Backup Package File BP F can only be opened in backup HSM. Thus, the PKI management team could de- previously designated HSM s. cide to have additional backup HSMs prepared, which can The administrators group must exist as at least one backup be used if one of them fails. certificate must be imported to perform the backup of an Purely cryptographic means cannot assure the origin of HSM. Additionally, for security reasons, it is necessary to a backup certificate because it is a normal certificate and have one or more auditors groups. The last requirement comes to not blindly trust to a single group (administrators made. The backup receiver unit has its private key krbkp , group) the backup process. which it keeps protected against disclosure inside the HSM The following algorithm is proposed to handle the gener- perimeter and will be used for decrypting the backup pack- ation of a security copy: age file BP K, recovering the content of the HSM. Recovering backup procedure authenticates administra- Algorithm bkpHsm() 1 tors and an auditors group. Both authentications are only Creates a secure copy of an operational HSM just af- required whereas these procedures are considered adminis- ter the administrators group authentication. This copy trative and necessary to keep the auditors aware of a new can be recovered at any backup HSM whose backup cer- operational HSM. tificate has already been imported into the operational The following algorithm is proposed to handle the security HSM. This procedure copies the whole internal environ- copy recovering: ment, excluding non-exportable (N XD’s) data. 1: ks ← authenticateGroup( ADS ) Algorithm recoverBkp(seBP F , EKSbkp , idaudit ) 1 2: ekrh , ch ← load( ADS ) Recovers a backup package file BP F , extracted from a 3: krh ← decrypt( ekrh , ks ) signed encrypted package seBP F , in a previously pre- 4: store( BP F , load( CT L ) ) pared HSM, authenticating administrators group and an 5: store( BP F , load( ADS ) ) auditors group identified by idaudit . Both authentication 6: store( BP F , load( AudDS ) ) are not really required to happen by cryptographic means 7: store( BP F , load( ODS ) ) 1: krbkp ← load( BDS ) 8: store( BP F , load( KDS ) ) 2: ksbkp ← decrypt( eksbkp , krbkp ) 9: store( BP F , load( BDS ) ) 3: BP F ← decrypt( seBP F , ksbkp ) 10: Cbkp ← load( BDS ) ) 4: store( CT L, load( BP F ) ) 11: ksbkp ← genKeySession() 5: store( ADS, load( BP F ) ) 12: eBP F ← encrypt( BP F , ksbkp ) 6: ksadm ← authenticateGroup( ADS ) 13: seBP K ← sign( eBP K, krh ) 7: store( AudDS, load( BP F ) ) 14: for cbkpi in Cbkp do 8: ksaudit ← authenticateGroup( AudDS, idaudit ) 15: eksbkp ← encrypt( ksbkp , cbkpi ) 9: store( ODS, load( BP F ) ) 16: end for 10: store( KDS, load( BP F ) ) 17: return seBKP , EKsbkp 11: store( BDS, load( BP F ) ) Once the backup process is triggered, the administrators The private key of the backup HSM (krbkp ) is loaded from group is authenticated using authenticateGroup algorithm, backup data storage BDS in step 1. In step 2, the session stated by step 1. In step 2, the HSM’s certificate (ch ) and key ksbkp used to encrypt the backup package file (BP F ) encrypted private key (ekrh ) are loaded from ADS, and is decrypted using krbkp . The BP F is decrypted in step 3 then, the HSM’s private key is released in step 3. The steps using ksbkp , released previously. As explained before, this between 4 and 9 copy the current content of all data stored algorithm must authenticate the administrators group and into backup package file (BP F ), excluding non-exportable a auditors group, so, in steps 4 and 5, the HSM reads CT L data storage (N XD) as explained by Martina[13]. Briefly, and ADS from BP F and, in step 6, authenticates the ad- the N XD stores a part of the secret required for the ad- ministrators group. Once again, in step 7, AudDS is read ministrators to perform any action over operators groups, from the BP F , enabling the HSM to authenticate the audi- then, once the backup is recover in a new HSM, each oper- tors group in step 8. Finally, in steps 9 to 11, ODS, KDS ators group must explicitly authorise the adminitrators to and BDS are read from BP F and a new instance of the act again on its behalf. This gives assurance to the opera- HSM is made fully operational. tors group in question that no backup of their keys can be recovered and become usable without their consent. 6. ADDITIONAL PROCEDURES In step 10, the HSM loads the set of backup certificates Security hardware by itself, in real situations, is not suf- (Cbkp ) previously imported to define the target HSMs. The ficient to guarantee the security of critical systems. Addi- backup session key is generated in step 11 and used in step tional procedures are necessary, such as the testimony of 12 for encrypting the BP F . A signature is made in step 13 witnesses. These procedures and testimonies should be pre- from the encrypted backup package file for external checks. viewed in a PKI practice statement as well as the description Therefore, in steps 14 to 16, the loop performs an encryp- of all ceremonies. Important ceremonies include the creation tion of the backup session key ksbkp using each public key of of backups and the moment at which a backup HSM is made backup HSM’s certificates, creating as many encrypted ses- operational. sion keys as backup certificates there exist. Finally, the list Despite very pertinent to PKI operation, this topic is of- of encrypted backup session keys and the signed encrypted tenly forgotten. Recently, it was revisited by Ellison [7], backup package file (seBKP ) are exported as a result of the who points its real importance to cover all outbound oper- execution. ations, normally done by human nodes, in any secure op- eration which involves mechanised nodes. Normally we do 5.4 Recovering Backups have to consider for security reasons, all operations in any Recovery of HSM backups is only allowed in HSMs al- security protocol or algorithm, even those needed to create ready prepared as backup HSM, i.e., where the algorithm the requisites to their operation. from subsection 5.1 were run, and the exported backup cer- In our case,as a prerequisite, every operation must be tificate has been imported previously before the backup was logged because these logs allow the auditors groups to create Figure 3: Creating backup file ceremony activity trails. If any problem occurs with the main HSM, mony steps, involving as many people as possible and, ide- its backup can be recovered. Its internal state will be just as ally, recording the ceremony. at the backup procedure, without logs and procedures done After a ceremony, a final report must be generated us- subsequently. So, just a backup does not solve their prob- ing all available data, which should also include ceremony lems. The auditors groups have an important role in this steps’ registers and logs. Finally, attendees present sign the context: tracing operations, controlling the administrators, report guaranteeing the veracity of the operation. Tests on validating the operators groups’ activities and others. the ceremony steps should be performed beforehand, using As shown in the last section, the creation of a backup a parallel environment to try to avoid problems. These cer- involves many steps and, consequently, some critical points emonies will also allow the auditors groups to follow the are met. A useful way of avoiding possible mistakes and system trail using logs. maintaining the systems is to perform ceremonies. Figure 3 Additionally, to avoid any possible compromise of the so- shows the ceremony to create backup files in the OpenHSM. lution, some additional measures should be taken. If, for The full ceremony description for the OpenHSM usage is instance, an HSM becomes inoperative, the HSM should not not the focus of this present paper, but this small fragment be repaired. In this case, the HSM should be burnt, for in- already shows us two important concerns: stance, in a incinerator. This eliminates any possibility of keys being recovered. • A log extraction in the beginning of the ceremony, to Finally, the operational HSM and its backup HSM should enable us to trust the HSM before starting the proce- be kept in different sites, avoiding the loss of both at the dure, thus avoiding operation if any tamper tentative same incident. was tried since last operation; • A log extration in the end of the ceremony, enabling 7. FINAL CONSIDERATIONS us to assure that the operation succeeded and that Open Hardware Security Module (OpenHSM) is a project nothing else happened during this operation. carried out by the National Education and Research Net- work (RNP). RNP provides a Brazilian infrastructure of ad- Ceremonies should become essential resources for all main vanced networks for collaboration and communication in the operational activities. Ceremony steps should be planned fields of teaching and research. OpenHSM is a specialised and should extract logs from the beginning and the end HSM directed to PKI applications such as Certification and of the executed procedures, with registers of all the cere- Registration Authorities. This paper described the deployment of the OpenHSM in key infrastructure’s hardware security modules. In a Public Key Infrastructure. Its main contribution was to Fourth European PKI Workshop: Theory and improvements in the auditing system and backup operations Practice, EuroPKI 2007, volume 4582 of LNCS, pages for the OpenHSM project. It covered descriptions of algo- 220–235. Springer-Verlag Berlin Heidelberg, 2007. rithms used by the OpenHSM to enable it to perform secure [14] nCipher Corporation Ltd. Nshield user guide linux backups and provide an audit trail. It also introduced a cer- version 4.17.38. http://www.ncipher.com, 2004. emony procedure to support the operation of such HSMs in [15] S. Rafaeli and D. Hutchison. A survey of key a PKI deployment. management for secure group communication. ACM The next step in this project will be synchronising the in- Comput. Surv., 35(3):309–329, 2003. ternal clock to a trusted external time source. Then, the [16] P. Samarati, M. K. Reiter, and S. Jajodia. An OpenHSM can also be used as a security time stamping authorization model for a public key management server. Other future work can include the formal analysis of service. ACM Trans. Inf. Syst. Secur., 4(4):453–482, all protocols relating to the OpenHSM and the creation of 2001. all related ceremonies. [17] A. Shamir. How to share a secret. Commun. ACM, 22(11):612–613, 1979. 8. ACKNOWLEDGEMENTS [18] T. C. S. Souza. Aplicações embarcadas para We would like to acknowledge the Brazilian Research Net- gerenciamento de chaves criptográficas. Technical work (RNP) for the financial support in the GT ICPEDU report, Federal University of Santa Catarina, 2005. workgroup, Brazilian Chamber of e-Commerce (Câmara e.net) for scholarship support in LabSEC, and also to Chris Sow- ton, Kristian Glass and Mark Reynolds for proof reading the APPENDIX paper. A. CONVENTIONS The algorithms in this paper are subject to conventions 9. REFERENCES from Table 2. This table presents the objects which store [1] Y. Amir, Y. Kim, C. Nita-Rotaru, and G. Tsudik. On data from the HSM. This information is used to, with the the performance of group key agreement protocols. protocols, manage the HSM. For instance, in the auditors ACM Trans. Inf. Syst. Secur., 7(3):457–488, 2004. data storage AudDS has details of auditors groups such as [2] G. R. Blakley. Safeguarding cryptographic keys. In groups’ name, groups’ size and others. AFIPS 1979 National Computer Conference, pages 313–317. AFIPS, 1979. [3] J. Brown, J. M. G. Nieto, and C. Boyd. Efficient and Table 2: Principals of the Protocols secure self-escrowed public-key infrastructures. In Principal Description ASIACCS ’07: Proceedings of the 2nd ACM ADS Administrators Data Storage symposium on Information, computer and AudDS Auditors Data Storage communications security, pages 284–294, New York, BDS Backup Data Storage NY, USA, 2007. ACM. BP F Backup package file [4] S. Chokhani, W. Ford, R. Sabett, C. Merrill, and CT L Certificate Trust List S. Wu. Internet X.509 public key infrastructure KDS Keys Data Storage certificate policy and certification practices framework. RFC 3647, 2003. LDS Log Data Storage [5] Chrysalis-ITS. Luna pki hsm planning and integration N XD Non-exportable data guide. http://www.chrysalis-its.com, 2002. ODS Operators Data Storage [6] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, Additionally, these are the description of all primitive 29(2):198–208, 1983. functions used, along with the algorithms, which have not [7] C. Ellison. Ceremony design and analysis. Cryptology been introduced yet. Basic functions are considered prim- ePrint Archive, Report 2007/399, 2007. itive when only a couple of operations are done and/or its http://eprint.iacr.org/. name is self-explanatory: [8] FIPS. Security requirements for cryptographic ctDecrypt(ct, edata, eu) Uses the private key stored in modules, FIPS PUB 140-2, 2002. the cryptographic token ct to decrypt data edata and [9] IBM Coorporation. Ibm 4758 model 2 and 23 pci nonce eu. Before returning the result, data is encrypted cryptographic cooprocessor manual. 2000. using nonce u. [10] iVEA (Rainbow Technologies). Cryptoswift hsm user’s decrypt( edata, k ) Decrypts encrypted data edata using guide. http://www.rainbow.com/, 2001. key k ( symmetric or asymmetric ). [11] iVEA (Rainbow Technologies). Cryptoswift hsm user’s guide. http://www.rainbow.com/, 2001. encrypt( data, k ) Encrypts data using key k (symmetric [12] J. E. Martina. Project of a hardware security module and asymmetric). If k is a certificate, its public key is focused on public key infrastructures and its used. applications. Master’s thesis, Federal University of genCert( id, ku, cca , krca ) Certification authority ca gen- Santa Catarina, March 2005. erates a certificate with identification id and public key [13] J. E. Martina, T. C. S. Souza, and R. F. Custódio. ku. cca is the certification authority certificate and krca OpenHSM: An open key life cycle protocol for public is its private key. joinSecret( Ks ) Joins the shares Ks in order to recon- struct session key ks. Remember that the set Ks must have the minimum number of shares, as when split. load ( DS[, a )] Reads information from data storage DS (DS might represent the host machine). Optionally, it specifies one or more pieces of information to restrict the result, such as identifiers. genKeySession() Generates a random session key. genKeyPair() Generates an asymmetric key pair genSelfSignedCert( kr, ku, id ) Generates a self signed certificate with identification id and public key ku. kr is the private key. sign( data, kr ) Signs data using the private key kr. splitSecret( ks, m, n ) Splits, using secret sharing scheme, session key ks in n shares where at least m of them are required to reconstruct it. store ( DS, ... ) Stores into data storage DS all other re- maining parameters. Audit and backup procedures for Hardware Security Modules Jean Martina Jean.Martina@cl.cam.ac.uk Joint work with: Túlio de Souza, UFSC, Brazil Ricardo Custódio, UFSC, Brazil Hardware Security Modules What could we think? Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD If we thought..... PIN Calculation Role based authentication Dual key entry Payment protocols Cryptographic speed Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD If we thought..... Strong authentication Identity based authentication Strict key life-cycle control Fully auditable operation Triggered group mechanisms Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD What we (the authors) think: HSM designed for PKI Inside the box Auditing Scheme Backup Scheme Additional Procedures Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD HSM Designed for PKI(platform) What we had: FIPS 140-2 Level 3 Hardware (Equivalent) Upgradeable firmware Open source based Smart-card support Ethernet connection Java management interface Crypt Interfaces (OpenSSL, PKCS#11) Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Inside the Box (before) Built-in PKI to control the HSM Administrators (security officers) Threshold Cryptography Operators (users) Managed keys Extended operational policies Additional operations Changes administrators Change key's ownership Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Auditing Scheme Everything must be logged Auditors group Threshold Cryptography Trace administrative operations Initialisation Typical operations Backup control Unlimited Auditors groups Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Backup Scheme (Initialise) Only one key operational at a Backup HSM time Targeted 2. cBKP 1. prepareBkpHsm( idBKP ) Host 3 Steps: Operational HSM 3. importBkpCert( cBKP ) Prepare backup unit Import backup certificate 4.generateBackup(file) Generate backup file Questions: Answers: Do we need a spare unit? Yes, but the relation is n/n How to trust a self-signed certificate? Auditors will check this in an additional Is it secure? procedure (ceremony) Well, if nothing bad happens.... Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Backup Scheme (Operate) Backup HSM's HSM Encrypted Data HSM's Operational Encrypted HSM Host Data Backup HSM HSM's Operational Encrypted HSM's HSM Data Encrypted Data Backup Host HSM Operational HSM Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Ceremonies? Additional Procedures Why? Cryptography only can not guarantee “human factor” Out bound threats must be addressed Log strategies Log extraction before (check initial state) Log extraction in the end (what happened) Witnesses Written Acts Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD One Ceremony Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Final Considerations HSMs in general are designed for Banks Auditing is a key issue for a PKI HSM HSM's backups are a contradictory issue Keep the key protected, however spread encrypted copies for safety. Ceremonies are an important tool Very few work in general Already operational in ICP-EDU project in Brazil Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD ICP-EDU Brazilian National Education and Research Network 11 HSMs 10 CAs 300 SSL Certs and 3000 End-user Certs 2008 Increase to 35 HSMs, more CAs, and 100.000 end users Certs Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Future Work Formal verification Hardware improvement Better CMS integration Full ceremony set Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Questions Federal University of 7th Symposium on Identity and Trust on the Internet (IDtrust 2008) Santa Catarina Gaithersburg, MD Securing the Core with an Enterprise Key Management Infrastructure (EKMI) Arshad Noor StrongAuth, Inc. 550 Lakeside Drive, Suite 10 Sunnyvale CA 94085 arshad.noor@strongauth.com ABSTRACT Keywords The last twenty-five years has witnessed an emphasis on Enterprise Key Management Infrastructure (EKMI) protecting the network and computing host as a proxy for Key-management (KM) protecting data from unauthorized access. While this was a Public Key Infrastructure (PKI) reasonable strategy at the dawn of network-based comput- Symmetric Key Client Library (SKCL) ing, given the state of the internet today with its security is- Symmetric Key Management System (SKMS) sues, this strategy is proving to be hopeless. Symmetric Key Services (SKS) Symmetric Key Services Markup Language (SKSML) This paper advances the notion that the time has finally XML Encryption (XENC) come to begin what we should have done initially – protect XML Signature (DSIG) the core of our computing infrastructure: the data – in addi- tion to protecting the network and computing host. 1. INTRODUCTION The paper describes an architecture - and a specific imple- Most security professionals are familiar with symmetric- mentation of that architecture - to enable the encryption of key based cryptography when presented with terms such as data across the enterprise in a platform and application-in- Data Encryption Standard (DES), Triple DES (3DES) dependent manner. The architecture describes the use of a and the Advanced Encryption Standard (AES). Some Public Key Infrastructure (PKI) and a Symmetric Key are also familiar with Public Key Infrastructure (PKI) as Management System (SKMS) within an Enterprise Key an enterprise-level solution for managing the life-cycle of Management Infrastructure (EKMI), to securely - and cen- digital certificates used with asymmetric-key cryptography. trally - manage the life-cycle of the symmetric encryption keys used for data encryption. However, the term Symmetric Key Management System (SKMS) - the discipline of securely generating, escrowing, Categories and Subject Descriptors managing, providing access to and destroying symmetric encryption keys - almost always draws blank stares. Given D.4.6 [Operating Systems]: Security and protection – the number of applications that needed to encrypt data in cryptographic controls. the past, this is not surprising; symmetric encryption key E.3 [Data Encryption]: Public key cryptosystems, Stan- management has traditionally been buried within the busi- dards. ness applications performing encryption. These applica- tions primarily focused on business functions, but managed General Terms encryption keys as an ancillary function. Consequently, Management, Design, Security, Standardization. there was no reason to emphasize key-management. This paper advances the notion that the time has come to address SKMS as an application-independent, enterprise-level de- fense mechanism. Additionally, this article advocates the Permission to make digital or hard copies of all or part of this work for use of a PKI for securing an SKMS within an Enterprise personal or classroom use is granted without fee provided that copies are Key Management Infrastructure (EKMI). not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior While encryption has been in use for centuries[1], comput- specific permission and/or a fee. er-based cryptography entered the general-computing field with the advent of the DES algorithm. The primary busi- IDtrust '08, March 4-6, 2008 Gaithersburg, MD Copyright 2008 ACM 1978-1-60558-066-1…$5.00 ness uses for this technology was within the military and later banking. Given the nature of what encryption tech- nology was protecting, implementers were willing to live for how personal information must be secured in Cana- with custom key-management solutions, however contrived da, when used within computerized systems; they may have been. With the explosion of the world-wide • Directive 95/46/EC of the European Parliament, aka web, businesses have been racing to implement business the European Union Directive or EU Directive[12], processes on the Internet, bringing sensitive information which specifies rules for how personal information significantly closer to attacks. Although businesses have must be secured in the EU, when used within computer- invested billions in firewalls, intrusion detectors, intrusion ized systems; prevention systems and other network and host-based de- • Thirty-eight US “computer breach disclosure” laws re- fense mechanisms, the US has witnessed more than 400 quiring companies that have breached sensitive infor- breach disclosures[2] since the passage of California's mation of US residents, to disclose those breaches to af- Breach Disclosure law[3]. Of some note are the disclo- fected individuals. Most of these laws provide a “safe- sures by the University of California over the years, with harbor” to the company by not requiring a disclosure, if the most recent one in Los Angeles (UCLA)[4]. Given that the affected data affected was encrypted; this is the seventh breach disclosure by the University of California across all their schools, it's reflective of a situa- With the publication of each new computer breach, govern- tion spiraling out of control. ments across the world are reacting with increasing legisla- tion that regulates the protection of sensitive data. Compa- All data breaches pale in comparison to the one at TJX[5], nies are also becoming sensitive to adverse publicity and which is currently ranked as the largest breach ever with private lawsuits when stolen data or lost laptops and com- nearly 95M credit card numbers exposed at this Mas- puter tapes, etc. are publicized in the media. As a result, sachusetts-based retailer[6]. A quarterly financial state- security professionals now accept that sensitive data needs ment[7] filed by this company in August 2007 shows that, to be encrypted across the enterprise – on desktops, laptops, so far, it has taken a charge of US $216M against this sin- Personal Digital Assistants (PDAs), mobile telephones, etc. gle breach. At least three lawsuits are pending against TJX - and not just on servers and on-line or off-line storage with the full extent of damage yet unknown. within the Data Center. Breaches at retailers such as TJX, Ralph Lauren, BJ's, 1.1 Organization of Paper DSW and credit-card processing companies such as This paper begins by describing some of the problems with CardSystems have prompted credit-card giants Visa, Mas- current key-management systems and architectures in Sec- tercard, American Express and Discover to standardize on tion 2. In Section 3 an architecture for an SKMS is pre- security requirements for merchants and card-acquirers sented with an explanation for why this particular architec- through the Payment Card Industry's Data Security ture makes sense and the rationale for the design decisions Standard (PCI-DSS)[8]. One critical element required that were made. Section 4 describes the SKSML protocol within PCI-DSS is the encryption of credit-card numbers and how applications are expected to use it. In Section 5, and a robust key-management system to accompany it. the paper goes on to describe a specific implementation of This effort is aimed at strengthening controls protecting this architecture in an open-source product and the experi- sensitive data on systems that have potential for causing fi- ence gained from such an implementation. Section 6 dis- nancial damage to customers and the credit-card brands. cusses the security required for such an architecture. Sec- tion 7 provides a high-level plan for how an SKMS can be While the Retail sector has been particularly battered by built for production use in an IT environment and what are data-breaches, the need to encrypt sensitive data in compa- the issues that implementers must take into consideration. nies is also driven by the following regulation across the The paper finally concludes in Section 8. world: • The Health Insurance Portability and Accountability 2. PROBLEMS WITH CURRENT SYSTEMS Act of 1996 (HIPAA)[9], which specifies rules for how Why is symmetric key-management a problem? After all, medical information must be secured within the US applications seem to have addressed the problem within the when used within computerized systems; applications for decades, and appear to be continuing to do • The Financial Modernization Act of 1999, aka the so. The problem becomes obvious from the perspective of “Gramm-Leach Bliley Act” (GLBA)[10], which spec- a manager in IT Operations. As an illustration, if the IT ifies rules for how financial information must be se- Operations Manager was responsible for the following in a cured within the US when used within computerized retail enterprise that accepted credit-cards for payment: systems; • The Personal Information Protection and Electronic • A Point-of-Sale (POS) application used in hundreds of Documents Act (PIPEDA)[11], which specifies rules stores across the country; • An e-commerce application that required credit-card tion, database encryption, etc., have their own built-in key- numbers for payment; management. • A payment-processing application in the back-office that communicated with the credit-card network for set- In the presence these technologies what advantage would tling transactions; an abstract key-management system offer implementers? • A back-office database that consolidated transactions for accounting; and Aside from the issue that current implementations of such • A business analytics application for determining retail technologies offer incompatible key-management designs , fraud; the single biggest issue with such techniques is that it does not address the problem completely. the IT Operations manager would have five applications that required encryption and thus, key-management. With An application, typically, consists of many layered tech- the proliferation of laptop and PDA losses or thefts, compa- nologies in a stack, through which data must pass before it nies are now mandating encryption on these devices, thus is stored on storage media. The layers vary depending on adding two more key-management schemes to the infras- the complexity of the application, its architecture, operating tructure. Finally, add database and operating system-spe- system and physical implementation. File, database and cific encryption to the mix, and you round out the picture storage-media encryption occur at some of the lowest lay- with 8-10 key-management infrastructures. ers of such a technology stack, oblivious to the applications that create the data. Implementers of such encryption Since applications are typically purchased from multiple schemes offer this feature as a benefit, because it does not vendors, each vendor, focusing primarily on their own busi- require applications to be modified to take advantage of the ness application, implements encryption and perform key- encryption capabilities; all applications can immediately management functions using its own design. As a result, start using it. the IT Operations staff are forced to manage at least 8-10 distinct symmetric key-management infrastructures, each However, the lower in the technology stack the encryption with its own technology, training, documentation, proce- occurs, it leaves open the possibility for attackers to com- dures and audits (PCI-DSS regulated entities are required to promise a layer higher up in the stack and avail themselves perform annual audits of any system that stores credit- to plaintext data. Even in a perfectly functioning encryp- cards). tion system (consisting of file, database or media-based en- cryption),, data could be compromised in one of many lay- Not only does this border on the ridiculous as it raises Total ers above the encrypting layer. Cost of Ownership (TCO) for the company, but more im- portantly, one could argue that there is the potential for a On the contrary, encrypting at the application layer allows compromise in such a security strategy because “with so implementers to encrypt data at the highest possible layer many pots cooking on the stove simultaneously, something in the stack, leaving little “wiggle-room” for the attacker to is bound to get burned”. compromise the data. While there is no guarantee that an attacker cannot compromise the application layer and still Presented with the problem in this perspective, the logical get to the data before it is encrypted (or after it is decrypt- solution springs to clarity: the key-management capability ed), it, nonetheless, reduces the attack surface to the small- needs to be abstracted from applications that need the capa- est possible target within the stack. It allows implementers bility, and managed independently in its own infrastructure. to focus their resources on protecting just one layer - the Applications need only have access to a key-management application layer - towards making the most effective use service, thus enabling encryption and decryption, without of encryption. having to be aware of implementation details. Such a solu- tion is not unlike the architecture of the Domain Name Sys- Encrypting at the application-layer also has the added bene- tem (DNS) for hostname-IP-address resolution, the Dynam- fit, that once data is encrypted at this highest stack-layer, ic Host Configuration Protocol (DHCP) for dynamic IP-ad- implementers need have little concern for the safety of data dress allocation or a Relational Database Management Sys- in lower layers of the stack: the data is protected no matter tem (RDBMS) for data management. how many technology layers it must pass through on the host or the network. 2.1 File, Database and Disk-based Encryption 3. ARCHITECTURE There are many commercial technologies on the market to- day that are capable of transparently encrypting data at the An Enterprise Key Management Infrastructure (EKMI) is file, database or storage-media layer. These technologies, defined as a collection of technology, policies and proce- which include encrypting file systems, full-drive encryp- dures for managing all cryptographic keys within an enter- prise – both symmetric and asymmetric. Therefore, an The Symmetric Key Services (SKS) server functions as a EKMI consists of a PKI and an SKMS. centralized service-provider on the network, listening for and responding to KM requests. When requested, it gener- Note: In the short-to-medium term, PKI and SKMS will be ates all keys centrally based on predefined policies, es- managed as distinct entities within enterprises. However, crows them, and then sends the symmetric key to the autho- the two infrastructures will merge towards a cohesive in- rized client. The client and server communicate with each frastructure in the not-too-distant future. This paper dis- other using a secure protocol: Symmetric Key Services penses with detailed discussions of PKI except where it in- Markup Language (SKSML) (discussed later). tegrates with an SKMS, and focuses more on the discussion of the SKMS itself. By using the client-server architecture, not only are the cen- tralized policy definition requirements addressed, but also The PKI part of an EKMI is a standard public key infras- the centralized key-management requirements. tructure issuing and managing X.509 and PKIX-compliant An alternative architecture is to define policies centrally digital certificates. It uses industry-standard protocols for and push them down to the clients, and similarly have the communicating with client requests: CMS, PKCS#10, clients generate keys locally and push them up to the serv- PKCS#7, etc., and the digital certificates issued out of the er. However, the SKMS architecture avoided this design PKI are managed per the PKI's Certificate Policy (CP) and for one reason: to avoid the possibility of catastrophic data- Certification Practices Statement (CPS). Nothing unusual loss. here, so we won't dwell on this too much. We will point out where digital certificates from a PKI are needed to en- If a client were to generate a symmetric key locally, en- able the capability described in this paper. crypt the plaintext, delete the plaintext (to eliminate the vulnerability), but cannot persist or send the generated The SKMS, on the other hand, has an architecture based on symmetric key to the server for any reason, the plaintext the the following business, technical and operational re- might be lost forever. quirements: While it is possible to design around such conditions, the • Centralized policy-definition and key-management; complexity of the SKCL increases significantly because it • Platform, application and language independent; is difficult to predict potential catastrophic conditions on a • Highly-available; yet KM client applications were re- client machine - especially mobile devices. With central- quired to continue functioning - i.e., encrypt and de- ized policy-definition and key-generation, this loss is crypt data - even in the absence of the KM service; avoided altogether by escrowing the symmetric key first, • Highly-scalable; and then sending it to the client for use. • Very secure; • Leverage existing standards and security certifications Given that a client-server architecture makes it possible to of cryptographic components; have multiple servers servicing numerous clients using hundreds of application, the following schema was chosen Given these requirements, the following design decisions to uniquely identify every symmetric key in the system. were made for the SKMS architecture: This is how applications will map the symmetric key they've used, to the ciphertext: 3.1 Client-Server • Every enterprise is assigned a unique Domain-ID - a While key-management can be easily abstracted from ap- monotonically increasing sequential number - to distin- plications even while running locally on the same machine guish its SKMS from others'. The design chose to as the application, the requirement that KM policies be de- reuse the Private Enterprise Numbers assigned by fined centrally and symmetric keys be managed centrally IANA[13] for this purpose. While using DNS-style do- led the design towards a client-server architecture for key- main-names was an option, the design opted for sequen- management. tial numbers as it was similar to other identifiers in the SKMS; besides, since humans would rarely need to The client is implemented as a library, named the Symmet- know these identifiers, it was more efficient to maintain ric Key Client Library (SKCL), and is much like the them as numerals; name-service library in DNS or the database connectivity • Every server within an SKMS is also assigned a unique libraries - ODBC, JDBC, etc. - for RDBMS. Client appli- Server-ID - once again, a monotonically increasing se- cations use the SKCL to request and receive KM services quential number - to distinguish a server from others from the server. within an SKMS domain; • Every symmetric key generated by a server is assigned a unique Key-ID - a monotonically increasing sequen- tial number - to distinguish it from every other key gen- Despite these advantages of ASN, the design chose to use erated by that SKS server; XML for the protocol for the following reasons: Concatenating the Domain ID, the Server ID and the Key i. XML is equally well-understood, accepted and support- ID, with simple hyphens to separate them, allows the ed by the general computing community - not just the SKMS to create a unique Global Key-ID (GKID) that can PKI or protocol-development community; be referenced by a client, anywhere on the internet. An ex- ii. It is extremely easy to understand and explain XML - ample of a GKID would be 10514-3-34348, indicating that even to non-computer professionals; this is key ID 34348, generated on SKS server number 3 iii. There are significantly larger number of developers within an SKMS for the organization whose domain is rep- who know and use XML than ASN, thereby increasing resented by the unique private enterprise number, 10514, as the probability of adoption and making a larger pool of issued by IANA. candidates available for its development; iv. XML is the lingua-franca of Service Oriented Architec- It is necessary for applications to be modified to maintain ture (SOA) - the architecture for a new class of applica- the GKID with the ciphertext so that applications know tions that has the support of every major software ven- which symmetric key to use to decrypt the ciphertext. For dor in the world; applications that use a structured database of any kind, this v. XML does not require special tools; its messages can be is relatively easy by modifying the database schema as a assembled and debugged using simple text editors; one-time enhancement activity. For standalone ciphertext vi. While ASN definitely is more compact than XML, with files, it is recommended to use the World Wide Web Con- the exception of a small number of use-cases, the ver- sortium's XML Encryption standard whose schema allows bosity of XML is not a handicap in an environment for identifying the unique identifier of the encryption key, whose bandwidth only keeps increasing every few the URL for locating the key and many other encryption years. With gigabit networking now showing up in new parameters along with the ciphertext. The implementation computers for LANs, 108Mb/s for WiFi-enabled de- experience described in Section 5 shows how this design vices expected to become the standard by the end of this was used successfully for relational databases as well as decade, and broadband connectivity to be near the standalone ciphertext files. 1Mb/s range for small mobile devices, bandwidth is not a constraint for the vast majority of computing devices. 3.2 XML-based protocol Primarily driven by the ease-of-use feature and industry To support platform, application and programming-lan- trends, it was decided to use XML for the representation of guage independence, the SKCL and the SKS server com- the key-management protocol. municate using an eXtensible Markup Language (XML)- based protocol, named the Symmetric Key Services 3.3 Scalability and Availability Markup Language (SKSML). Details of this protocol are defined in the next section. There are well-known and proven design architectures for creating highly-scalable and highly-available software sys- SKSML is designed to be a very thin layer, leveraging the tems for servers. However, most of the work in creating Simple Object Access Protocol (SOAP) for sending and re- such software requires addressing basic infrastructure re- ceiving messages. SOAP is well-understood, accepted and quirements such as authentication, authorization, logging, supported industry-standard for sending and receiving com- performance management, scheduling, persistence, etc. plex messages in client-server communications. SOAP li- braries are available for every major programming lan- This architecture chose to leverage the capability built into guage and platform, allowing almost every modern operat- the Java 2 Enterprise Edition (J2EE) for these services ing system to support applications using SOAP and thus, rather than develop them from scratch. SKSML. The J2EE architecture was created to address precisely The question arises - why was Abstract Syntax Notation such infrastructure issues, while scaling to address the re- (ASN) not used for the protocol? quirements of extremely large and demanding infrastruc- tures. It has evolved over the last decade and continues to The PKI community has been using ASN, successfully, improve with the input of millions of Java developers. Java across all major platforms for a number of years. ASN is Enterprise Edition 5 (JEE5), the latest incarnation of this well-understood, accepted and supported by the PKI com- architecture, has once again improved on this design munity and has the advantage of being compact, thus al- through the community-development process. lowing for significant efficiencies in communication, as well as by small devices where space is at a premium. By choosing J2EE, and the newer JEE5, the architecture 3.4 Application Integration addressed every infrastructure requirement for a scalable and highly-available service, allowing the designers to con- Since the SKCL is merely a library, it is necessary for an centrate on the core functionality required within an application to integrate the SKCL to take advantage of the SKMS. benefits offered by an SKMS. However, unlike the DNS model, an application cannot just use the SKCL, acquire On the client side, scalability of the SKCL isn't expected to the symmetric key, use it and carry on without maintaining be a major issue (even for an e-commerce transaction serv- some state of the operation it performed. er, which would still be an SKMS client) because the client library would execute within a thread of the client applica- In order for an application to be able to decrypt its cipher- tion. It is expected that the designers of the client applica- text, it must maintain knowledge of the GKID of the sym- tion will have addressed performance issues for their appli- metric key it used in the cryptographic operation. Without cation in general, and the SKCL will benefit from those de- the GKID, the application will never know which symmet- sign improvements. ric key to request from the SKMS. The SKMS architecture abstracted the cryptographic pro- This architecture recommends the modification of the cessing of the SKMS service to execute outside the service. database schema of the application, to include the storage This allows implementations to use third-party crypto- of the GKID in the same database or file where the cipher- graphic accelerators for enhancing the performance of text is stored. If the symmetric key was requested from a SKMS clients and servers, if desired. Using well-known non-default domain – one in which the client normally does interfaces such as Public Key Cryptography Standard #11, not belong – the client application may also need to main- Cryptography API (CAPI) and Java Cryptography Exten- tain the URL of the SKS service where the key can be lo- sion (JCE) allows the SKMS architecture to provide flexi- cated. bility to implementers for dealing with scalability. For example, where a database schema before SKMS inte- The architecture defines the notion of a “global” SKS gration might look like the following: (GSKS) server, used for defining policy for the SKMS do- main. All other SKS servers, named “local” SKS servers, Employee table are expected to replicate symmetric keys generated by them to the GSKS. Since every symmetric key has a unique Name Type Comment GKID within an SKMS domain, a single GSKS, appropri- ID Long Unique identifier ately sized, is capable of storing every local SKS servers' symmetric keys for redundancy. The GSKS itself never Name Char generates any symmetric keys itself; it only serves as a cen- DOB Date tralized repository within an SKMS infrastructure. In the SSN Char event of an outage of a local SKS server, the client just ..... contacts the GSKS and requests the symmetric key, much as the nameservice library contacts a different DNS server After including the GKID, the schema might resemble the when the first is unavailable. SKMS implementations must following: ensure that they have implemented sufficiently redundant GSKS servers to accommodate their business requirements. Modified Employee table Finally, to ensure clients can continue processing – encrypt and decrypt – even in the face of network failures, the Name Type Comment SKMS architecture includes “secure key-caching” on the ID Long Unique identifier client side. How and when a client may cache keys is GKID Char Unique key identifier based on “key-caching policies” defined on the SKS server, NAME Char centrally. All SKMS clients can be directed by centralized “key-caching policies” to either cache or not cache sym- DOB_CIPHERTEXT Date metric keys on the client-side, securely. While imple- SSN_CIPHERTEXT Char menters have the flexibility to choose the strategy that SSN_SHA256 Char SHA-256 hash of SSN works best for them, this design uses the “message-level” ..... security built into the SKMS architecture to enable secure key-caching. By associating a GKID with every ciphertext in the database, an application can now retrieve the required sym- metric key from an SKMS to decrypt data when it needs it. the organization implementing the SKMS has the use of However, when ciphertext is transmitted from one applica- a PKI for this purpose. tion to another, it must carry the GKID with it. It is rec- ommended that the W3C XML Encryption standard be With this, the client application is now ready to make re- used for the transmittal of such information, since the XML quests for symmetric key services from the SKMS. Encryption schema allows for specifying details such as the GKID, SKS server, etc., along with the ciphertext. 3.5 Security An alternative choice to this design was to use a complex Given that a centralized key-management system would be data structure in the ciphertext – such as the Cryptographic the ultimate treasure trove to attackers, it is incumbent that Message Syntax (CMS) – to embed many cryptographic el- the architecture consider known threats and address them ements into a binary “blob” that can be stored within a sin- with appropriate counter-measures. The design of the gle data element in the database. This has the advantage of SKMS addresses a number of threats by using “message- carrying many required pieces of information for crypto- level” security in the messages that were in transit or during graphic processing, together. rest. However, this design avoids this for the following reasons: Message-level security addresses the following vulnerabili- ties in the following manner: i. Most applications expected to use the SKMS will be the traditional client-server, enterprise applications that use • Authenticity of requests and responses: Every mes- an RDBMS for data-storage. Developers of such appli- sage arriving at the client or server is assumed to be cations expect to see the database schema laid out in its from an untrusted source. As such, the architecture re- entirety rather than to have data structures collapsed quires that every message be digitally signed and veri- into blobs within a single element; fied against a trusted certificate hierarchy known to ii. Collapsing data-structures into a single element hides clients and servers within the SKMS. This requires ev- information that might help improve performance of the ery SKMS client and server be provisioned with an client application. For instance, if the application deter- X.509/PKIX-compliant digital certificate for signing re- mined that the same GKID was in use for the next 100 quests and responses. This ensures that clients and records, it might be able to cryptographically process servers are dealing with only properly validated mes- the next 100 records after fetching the symmetric key sages; once, as opposed to fetching it once per record; • Integrity of requests and responses: To ensure that iii. It allows the application developers to use standards the messages sent and received by SKMS clients and such as XML Encryption by “exporting” the data ele- servers do not lose their integrity either accidentally or ments into XML elements more easily and efficiently through a deliberate attack, all SKSML messages use than if additional processing had to be performed to digital signatures to verify the integrity of the mes- “explode” the data-structure for conversion to XML. sages. These are the same signatures used for authen- Once again, this design assumes that XML significantly ticity checking; eases the adoption of complex technologies by neo- • Confidentiality: Since an SKMS deals with the most phytes, so decisions were made to favor XML. sensitive data within an IT infrastructure, it is incum- bent on the architecture to protect the payload to the Applications link in the SKCL as any other library in the fullest extent possible. For transmission of the sym- standard software development process. Once linked in, metric key to clients, the design uses public-key encryp- the client application need two additional pieces of infor- tion, using the digital certificate of the recipient. Since mation before they can make requests of an SKS server: the client is expected to be the only one having access to the private key corresponding to the targeted digital 1. A list of the SKS/GSKS servers that the client may con- certificate, the payload can only be accessible to autho- tact when it needs SKMS services. This information is rized recipients. For storage and recovery of the sym- provided in a text file (much like the /etc/resolv.conf metric key within the databases, the SKMS architecture file for DNS clients) and simply lists the URL's of the uses the public-key in the digital certificate of the SKS SKS/GSKS servers that the client may contact. server to protect the payload. The architecture also per- 2. A digital certificate with a corresponding key-pair to be mits the creation of “global” SKS servers, and Security used for signing requests and for decrypting server re- Officers, with their own digital certificates, so that the sponses. The key-pair and digital certificate is provi- symmetric key is encrypted with their public-keys too. sioned to the client in an out-of-band process using any This allows the symmetric key to be recovered, through of the traditional PKI mechanisms. It is assumed that an appropriate process, by entities other than the SKS server that generated the symmetric key. • Database access: The SKMS architecture uses an (Note: This protocol is currently working its way through RDBMS to store its data. Traditionally, Database Ad- the standards process at the Organization for the Advance- ministrators (DBA) have privileged access to such ment of Structured Information Standards (OASIS), and databases over application administrators and security has not been finalized yet. It is, however, targeting for an- officers. To ensure that the SKMS database contents ticipated standards status by the summer of 2008). are protected from unauthorized manipulation, the SKMS design protects database objects with digital sig- 4.1 Request for a single new symmetric key natures. For example, when SKMS objects are stored in the database, a new digital signature is computed and This request forms the most basic request – for a single stored with the object by the SKS server. When reading new symmetric key without specifying a key-class. (Note: the object back from the database, the SKS server veri- Key-classes are designations that allow clients to request fies its digital signature to ensure that the integrity of keys conforming to specific business requirements.) The the message has not been compromised. abbreviated request (without the WSS header) is as follows: • Key protection: The astute reader will have recog- nized that the SKMS architecture relies on the crypto- EHR-EMT xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01> EHR-HOS 10514-1-2783 EHR-INS 10514-3-532 EHR-NUR 10514-2-1423 EHR-PAT 10514-6-243 EHR-PHY Not only is each GKID individually named, but there is no need to specify a key-class, since the returned key is going In this request, the client application (assumed to be some to belong to whatever class it belonged to, at the time of Electronic Health Record application) is requesting nine (9) key-generation. new symmetric keys, each corresponding to the named key- class. It is assumed that the EHR application is choosing 4.5 Request for a key-caching policy object to encrypt different parts of this new health record with dif- ferent symmetric keys, so that target users of this EHR will The only request type that does not request a symmetric need to request only a subset of the nine symmetric keys to key, is when a client needs to know its key-caching policy view data meaningful to their business process. (KCP). This is normal in three situations: For example, when this patient's health record is stored, en- i. When the client has been connected to the SKMS for crypted with nine symmetric keys, applications used by the first time and is making its first request for a sym- nurses will be authorized to request only keys that conform metric key and must know its caching policy before it to the EHR-DEF (Default) and the EHR-NUR (Nurse) key- can request a key; classes. This allows them to perform their work without ii. The current key-caching policy on the client machine compromising the security of other parts of this EHR. has expired and the client must refresh it to get new pol- icy information; It is possible for an application to request multiple new iii. The key-caching policy object on the client is either symmetric keys of the same class with the following re- corrupted, or the integrity of the object cannot be veri- quest – for three new keys of the “ATM-Class” key-class: fied; The Permissions element in SKSML allows SKMS imple- mentations to restrict the use of the symmetric key based on 10514-1-235 one or more of the following categories: 10514-4 DES-EDE Policy • Permitted Applications; HR-Class • Permitted Dates; http://www.w3.org/2001/04/xmlenc#tripledes-cbc • Permitted Durations – i.e., between any two date-times; 192 • Permitted Levels – for multi-level security (MLS) Active aware systems; • Permitted Locations – that can be based on GPS coordi- nates; 10514-23 • Permitted Times; Payroll Application • Permitted Transactions – i.e., the actual number of en- 1.0 crypted transactions permitted with a key; and • Permitted Uses; http://www.w3.org/2000/09/xmldsig#sha1 If a permission appears for a specific category in the KUP, NIG4bKkt4cziEqFFuOoBTM81efU= the SKCL enforces the use of the key according to that per- mission. If a permission does not appear for a specific cat- egory, the key can be used within that category without re- strictions. For example, if two (2) applications are explicit- 2007-01-01 ly listed within PermittedApplications, then only the listed 2007-12-31 applications are authorized to use the symmetric key. However, if the PermittedApplications category is missing from the KUP, then all applications are allowed the use of 07:00:00 the symmetric key within that client. 19:00:00 While this is an atypical method of granting use, it permits the KUP to be minimal when granting broad access to keys. complex. E9zWB/y93hVSzeTLiDcQoDxmlNxTuxSffMNwCJmt1dIqzQH 4.7 Response with multiple symmetric keys BnpdQ81g6DKdkCFjJMhQhywCx9sfYjv9h5FDqUiQXGOca8E U871zBoXBjDxjfg1pU8tGFbpWZcd/ATpJD/UJow/qimxi8+ huUYJMtaGHtXuLlWtx27STRcRpIsY= In response to a request for multiple symmetric keys - new or existing - the SKS server responds with the following SKSML (shown without the WSS header): with the recipients' public key so that only the targeted re- cipient of the response message may decrypt it. 10514-4-1235 (Content removed for conciseness). The KUP object provides detailed information on how the 10514-1-2385 SKCL may use the associated symmetric key. Other than (Content removed for conciseness). some meta-data, the heart of the KUP is in the Permissions element. SKSML allows SKMS implementations to re- 10514-3-1237 strict the use of symmetric keys by specifying a complex (Content removed for conciseness). xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 10514-4-1238 xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' (Content removed for conciseness). xsi:schemaLocation= 'http://docs.oasis-open.org/ekmi/2008/01 symkeyResponse.xsd'> The content inside each Symkey element is similar to the 0-0-0 response presented in the earlier section (Response with a single symmetric key). The SKCL parses through each HR-Class Symkey and processes it as if it were a single-key response. 9025 A KeyUsePolicy to issue a symmetric key with 4.8 Response with a key-caching object the requested key-class does not exist for this request. Please contact your Security Officer if you have any questions. Provide In response to a request for a KeyCachingPolicy (KCP) them the following information if asked: the SKS server responds with the following SKSML SRID: 10514-2-8643 (shown without the WSS header): message with its request. It is up to the application to de- 10514-17 termine how to process the ErrorCode and ErrorMessage elements. Corporate Laptop Symmetric Key Caching Policy A response for multiple symmetric keys that results in par- This policy defines how company-issued laptops will manage symmetric keys used for file/disk tial success will return the following SKSML that includes encryption in their local cache. This policy must both symmetric keys and SymkeyError's: be used by all laptops that use the company EKMI. 2008-01-01T00:00:01 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 2008-12-31T24:00:00 xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' 86400 xsi:schemaLocation= 'http://docs.oasis-open.org/ekmi/2008/01 Active symkeyResponse.xsd'> 3 86400 3 86400 The KCP essentially tells the client machine how many Applications are expected to keep track of which requests new and used symmetric keys (used for at least one encryp- received successful responses, which ones did not, and how tion transaction) it may cache and for how long. This poli- to deal with the mixed result. cy is defined centrally for individual, group and/or all clients requesting key-management services. The Policy- 5. IMPLEMENTATION EXPERIENCE CheckInterval tells the client how frequently it must check back with the SKS server for updates to the KCP. This is Based on the design and protocol described in earlier sec- to ensure that client machines' caching policies can be tions, an open-source software implementation of this ar- changed centrally with a small notice period. chitecture[14] was released on the Internet in 2006. 4.9 Response with a fault message The SKMS consisted of two centralized SKS servers – a primary and a disaster recovery server – and any number of In the event the SKS server cannot respond to a request for clients using the Symmetric Key Client Library (SKCL) one or more symmetric keys successfully, it sends back the to request services from the SKS servers. (While they are following SKSML (shown without the WSS header): referred to as clients, the client software may themselves be database servers, web-servers, application-servers and/or any business application). The SKSML protocol implemented in this software is cessful call by xenc retrieved the required symmetric key based on a DRAFT 1.0 version of the protocol (which is a from the SKS server and decrypted the data successfully. little different from the DRAFT 3.0 protocol described ear- lier in the paper). This protocol is currently going through Key-caching was tested by first getting the key-caching a standardization process at OASIS[15]. policy from the SKS server. This led to the SKCL request- ing and receiving symmetric keys from the SKS server to Each implemented SKS server consisted of: conform to the KCP. Once the keys were cached on the client, the client was disconnected from the network and • a server-class computer running an operating system – xenc was used to successfully encrypt and decrypt files on typically Linux, UNIX or Windows - that had a compli- the local client. ant Java Virtual Machine (JVM) available for it; • a relational database to serve as the storehouse for the 6. SECURITY symmetric encryption keys; • a J2EE-compliant application server to host the applica- Given the sensitivity of the information managed within the tion that would respond to requests over the network, SKMS implementation, the infrastructure was predicated serving as the workhorse of the SKMS; on an extraordinary level of security. (As with any security • a JCE-compliant cryptographic provider to perform the architecture, the controls and procedures in place at the cryptographic operations of key-generation, key-protec- implementation determined the degree of vulnerability the tion, digital signing, verification, etc.; SKMS had against attacks; we still continued to configure • an optional, but strongly recommended, Hardware Se- the firewall and other operating system controls to secure curity Module (HSM) or Trusted Platform Module the machine.). (TPM) for securely storing the cryptographic keys that protect the database's contents; The implemented SKMS incorporated the following securi- • the SKS server software itself, consisting of an Enter- ty features: prise Archive (EAR) and a Web Archive (WAR) file for the administration console, along with ancillary util- • all symmetric keys were generated using multiple com- ities; pliant cryptographic providers – some hardware and others in software; Each SKCL client platform consisted of: • all symmetric encryption keys were themselves, en- crypted using multiple RSA asymmetric keys – one be- • a client machine running an operating system – once longing to the SKS server, one to the GSKS and one ot again, typically, Linux, UNIX or Windows, but includ- the Security Officer; ed the OS/400 - that had a compliant Java Virtual Ma- • all database records on the SKS server were digitally chine (JVM) available for it; signed before storage, and verified upon retrieval to en- • a JCE-compliant cryptographic provider to perform the sure their integrity hadn't been compromised; cryptographic operations of encryption, decryption, dig- • all administrative operations through the console were ital signing, verification, etc.; digitally signed and maintained in a history log for audit • an optional, but highly recommended, Trusted Platform purposes, and verified upon retrieval; Module (TPM), smartcard or other USB-based crypto- • all administrative operations through the console re- graphic token for securely storing the cryptographic quired SSL/TLS-based client-authentication; keys that protect the clients' authentication credentials; • only digitally signed client-requests were accepted by • the SKCL software itself, consisting of an API callable the SKS server from SKCL clients; by Java applications for communicating with the SKS • only digitally signed responses from the SKS server server and performing cryptographic functions (non- were accepted by SKCL clients; Java applications used a Java Native Interface (JNI) li- • all symmetric keys were transported, encrypted for the brary to call the SKCL); specific client making the request; • all cached-keys on the client were digitally signed and To exercise the protocol a client utility called “xenc” was encrypted on storage, decrypted and verified upon re- created that would encrypt files, directories and data in re- trieval to ensure their integrity; lational database tables. Using xenc and the implemented architecture, we were successfully able to demonstrate the To have this level of security enabled within the SKMS, request of symmetric encryption keys from dissimilar client and to ensure that this security could scale to internet lev- platforms and receive symmetric keys based on predefined els, the architects of the open-source SKMS software predi- policies at the server. The encrypted data was stored in the cated the use of a PKI to secure the SKMS. W3C XML Encryption standard for compatibility and transferred to other platform machines, where another suc- The PKI allowed the implementers to manage large num- thorization and the symmetric-key policy in force for the bers of digital certificates much more easily than managing requester (or the default policy), generates a new symmet- raw asymmetric cryptographic keys. With the use of a ric key based on this policy, assigns it a Global Key-ID PKI, every SKMS client and server was issued a digital (GKID), escrows the key (which includes encrypting it certificate. Not only was the security level maintained, but with multiple RSA keys), encrypts the key with the re- once the digital certificates were issued, the provisioning of quester's transport digital certificate, logs the transaction symmetric key-management services was completely auto- details (which includes digitally signing the transaction) mated thus providing the internet-level scalability required and responds to the client with a WSS-compliant SOAP re- for enterprise operations. sponse. 6.1 Operation The SKCL client, upon receiving the response, verifies the authenticity and integrity of the request, caches the secured The following diagram explains how the implementation object if so configured, decrypts the symmetric key and the works. embedded key-use-policy and returns it to the calling appli- cation. The calling application at this time may choose to have the SKCL perform the actual encryption or perform it, itself. A similar process is repeated when a client application needs to decrypt a previously-encrypted object such as a file, directory of files, database record, etc. The application determines the GKID of the symmetric key it needs (which was previously stored with the encrypted ciphertext in the XML Encryption format for files, and in a corresponding column for an RDBMS) and makes a request for this key to the SKCL. The SKCL checks to see if the requested key is in the key-cache. If it is, it goes through the standard secu- When a client – be it a laptop, a DB application or an e- rity-checks and returns the symmetric key to the applica- commerce web-server - needs a symmetric key to encrypt tion; if not, it makes a request to the SKS server for this some information, it makes a request for a new symmetric symmetric key. Upon receiving the request and after the key to the linked in SKCL. standard security-checks, the SKS server responds with the symmetric key to the client. If the key does not exist for The SKCL checks its key-cache to determine if it has any any reason, or the client is not authorized to receive the cached symmetric keys that are valid for use. If so, it re- key, or for other error conditions, the SKS server returns a trieves the key, decrypts it, verifies its integrity, checks its SOAP Fault to the requesting client. key-use-policy (every symmetric key object has an encryp- tion policy embedded in it, previously defined by the site It is noteworthy to mention, that given this operational in- Security Officer) and then hands the requesting application frastructure, it was feasible to use a unique symmetric key the symmetric key for use. to encrypt every record in a database. With such an en- cryption policy, the breach of any key reduces the exposure If any of the local checks result in no valid symmetric key of the database down to just a single record. This is in being available for use, the SKCL creates a new symmet- stark contrast to existing designs, where a single key typi- ric-key request, digitally signs it with its authentication cre- cally encrypts an entire database or dataset, thus magnify- dentials, and sends the request to one of its pre-configured ing the loss associated with the loss of that single key. SKS servers as an OASIS Web Services Security (WSS)- compliant SOAP request. (Note: It is noteworthy to men- tion here, that since all requests and responses between the 7. BUILDING AN SKMS SKCL and the SKS servers were secured (digitally signed The construction of an SKMS began with the creation of a and encrypted) at the message-level, transport-level securi- PKI – or procurement of PKI services - to manage the is- ty (SSL/TLS or IPSec) was not required for the operations suance of digital certificates to every client. The architec- of the SKMS; plain old HTTP was sufficient. Administra- ture deliberately eschewed the use of User-ID/Password tion console communications, however, did rely on mutual- for authentication because of their inability to prevent at- ly-authenticated SSL/TLS). tacks against single-factor credentials. The clients and servers in an SKMS use digital certificates for authentica- The SKS server, upon receiving such a request, verifies the tion, and secure storage & transport of symmetric keys authenticity and integrity of the request, determines the au- within the infrastructure. (Notwithstanding the use of digi- tal certificates, the administration console allows an Opera- REFERENCES tions/Security officer to “deactivate” any client or server on [1] History of cryptography - the network without revoking the digital certificate of the http://en.wikipedia.org/wiki/History_of_cryptography affected entity). [2] A chronology of data breaches - http://www.privacyrights.org/ar/ChronDataBreaches.htm Simultaneously, the application that will use the SKCL was [3] California's Senate Bill 1386 - http://www.strongauth.com/regula- created/modified to integrate the SKCL's API, accommo- tions/sb1386/sb1386Index.html date the encrypted data (ciphertext) and the GKID in its [4] Breach at UCLA exposes data on 800,000 - http://www.computer- database. world.com/action/article.do?command=viewArticleBasic&articleId= 9005925 Multiple SKS servers were deployed and encryption poli- [5] Retailer TJX reports massive data breach - http://www.infoworld.- cies configured on the servers while digital certificates com/article/07/01/17/HNtjxbreach_1.html were issued to clients that communicate with the servers. [6] TJX Breach was twice as big as admitted, banks say - The applications were now ready to start requesting key- http://www.theregister.co.uk/2007/10/24/tjx_breach_estimate_grows management services from the SKS servers. The SKMS [7] TJX Form 10Q - transitioned to Production status at this point, and tradition- http://www.theregister.co.uk/2007/10/24/tjx_breach_estimate_grows al operational activities took over (backup, configuration [8] PCI Security Standards Council - https://www.pcisecuritystandard- management, DR, etc.). s.org/index.htm [9] Health Insurance Portability and Accountability Act of 1996 (HIPAA) - http://aspe.hhs.gov/admnsimp/pl104191.htm 8. CONCLUSION [10] The Financial Modernization Act of 1999, aka “Gramm-Leach- While symmetric encryption has been in use for decades Bliley Act (GLBA) - http://www.ftc.gov/privacy/privacyinitiatives/glbact.html within general computing, we have reached a confluence of [11] Personal Information Protection and Electronic Documents Act inflection points in technology, the Internet and in regulato- (PIPEDA) - ry affairs, that require IT organizations to implement Sym- http://www.privcom.gc.ca/legislation/02_06_01_01_e.asp metric Key Management Systems (SKMS) as independent [12] Directive 95/46/EC of the European Parliament aka EU Directive - infrastructures. Using the soon-to-come Symmetric Key http://www.cdt.org/privacy/eudirective/EU_Directive_.html Services Markup Language (SKSML) standard from OA- [13] IANA Private Enterprise Numbers (PEN) as used by RFC2578 - SIS and the architecture defined in this paper, , IT organiza- http://www.iana.org/assignments/enterprise-numbers tions have another – and perhaps, one of the most effective [14] StrongKey - http://www.strongkey.org – defense weapon in their arsenal against an increasingly [15] OASIS Enterprise Key Management Infrastructure Technical Com- hostile Internet. mittee - http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=ekmi Securing the Core with an Enterprise Key Management Infrastructure (EKMI) Arshad Noor StrongAuth, Inc. arshad.noor@strongauth.com IDtrust 2008 – Page 1 Today's Goals ● What is an EKMI? ● What are its components? ● How do you build one? ● How do you secure one? ● What is the SKSMS Protocol? IDtrust 2008 – Page 2 What is an EKMI? An Enterprise Key Management Infrastructure is: “A collection of technology, policies and procedures for managing the life-cycle of all cryptographic keys in the enterprise.” IDtrust 2008 – Page 3 What is an EKMI? ● PKI “A collection of technology, policies and procedures for managing the life-cycle of asymmetric cryptographic keys in the enterprise.” ● SKMS “A collection of technology, policies and procedures for managing the life-cycle of symmetric cryptographic keys in the enterprise.” IDtrust 2008 – Page 4 EKMI Components ● Public Key Infrastructure (PKI) EKMI ● Symmetric Key Management PKI SKMS System (SKMS) IDtrust 2008 – Page 5 The problem ● Define Policy ● Define Policy ● Define Policy ● Define Policy ● Define Policy ● Define Policy ● Generate ● Generate ● Generate ● Generate ● Generate ● Generate ● Encrypt ● Encrypt ● Encrypt ● Encrypt ● Encrypt ● Encrypt ● Decrypt ● Decrypt ● Decrypt ● Decrypt ● Decrypt ● Decrypt ● Escrow ● Escrow ● Escrow ● Escrow ● Escrow ● Escrow ● Authorize ● Authorize ● Authorize ● Authorize ● Authorize ● Authorize ● Recover ● Recover ● Recover ● Recover ● Recover ● Recover ● Destroy ● Destroy ● Destroy ● Destroy ● Destroy ● Destroy ● Audit ● Audit ● Audit ● Audit ● Audit ● Audit .........and on and on IDtrust 2008 – Page 6 Ideally... ● Encrypt ● Decrypt ● Encrypt ● Decrypt SKS Server ● Define Policy ● Encrypt ● Generate ● Decrypt ● Protect ● Escrow WAN ● Authorize ● Recover ● Destroy ● Encrypt ● Audit ● Decrypt SKS Server ● Encrypt ● Decrypt ● Encrypt ● Decrypt IDtrust 2008 – Page 7 Typical SKMS DR Data Center Primary Data Center VA/CRLDP PKI Global SKS Server Intranet (DR Mode) Global SKS Server “Local” SKS Server DMZ Corporate Network Reverse Internet Web Proxy IDtrust 2008 – Page 8 Global SKS Server ● One per enterprise ● Define all SKMS objects here: – Clients, Servers, Client Groups, Key Groups, Key Use Policies, Key Cache Policies, Grants ● DR Mode GSKS server is identical but Read-Only* ● HSM critical to security of server IDtrust 2008 – Page 9 SKS Server ● Any number per enterprise, as needed – One per continent recommended for global enterprises ● Configured to replicate to GSKS* ● HSM critical to security of server IDtrust 2008 – Page 10 SKMS Client ● Any number per enterprise ● Maintains a list of SKS servers to get KM services from: 1) Nearest SKS server on network 2) GSKS Server 3) GSKS DR-Mode Server ● HSM, smartcard token or TPM chip strongly recommended for security IDtrust 2008 – Page 11 Client Examples ● Database servers ● Web Application servers ● Network File servers ● Desktops/Laptops ● Automated Teller Machines (ATM) ● Point-of-Sale (POS) Registers ● Personal Digital Assistant (PDA) ● Smart mobile devices: Banking, Healthcare IDtrust 2008 – Page 12 The Big Picture Java RPG C/C++ Application Application Application 3 2 1 7 7 6 Network RPGNI JNI Application DB Server Server 4 SKCL 5 Crypto Module Crypto Module Key Cache Client Server 1. Client Application makes a request for a symmetric key 2. SKCL makes a digitally signed request to the SKS 3. SKS verifies SKCL request, generates, encrypts, digitally signs & escrows key in DB 4. Crypto HSM provides security for RSA Signing & Encryption keys of SKS 5. SKS responds to SKCL with signed and encrypted symmetric key 6. SKCL verifies response, decrypts key and hands it to the Client Application 7. Native (non-Java) applications make requests through Java Native Interface IDtrust 2008 – Page 13 SKMS Security ● Every request/response is digitally signed ● Every response is encrypted ● Every object in database is digitally signed ● All symmetric keys in cache are digitally signed and encrypted ● All crypto code is abstracted – FIPS 140-2 devices are easily integrated ● Administration console does not use UserID and Passwords; only SSL Client Auth. IDtrust 2008 – Page 14 SKSML Protocol ● Symmetric Key Services Markup Language ● Donated to OASIS on royalty-free basis by StrongAuth, Inc. ● Currently a TC DRAFT; anticipated standard in Summer 2008 ● Two (2) Request types: Key and CachePolicy ● Three (3) Response types: Key, CachePolicy and Fault IDtrust 2008 – Page 15 SKSML Protocol Request for a new Symmetric Key ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01"> 10514-0-0 Server ID Domain ID Key ID IDtrust 2008 – Page 16 SKSML Protocol Request for an existing Symmetric Key ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01"> 10514-4-312 Server ID Domain ID Key ID IDtrust 2008 – Page 17 SKSML Protocol Request for a new Symmetric Key of particular KeyClass ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01"> 10514-0-0 HR-Class IDtrust 2008 – Page 18 SKSML Protocol Request for many new Symmetric Keys of specific KeyClasses ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01"> 10514-0-0 EHR-CDC EHR-CRO EHR-DEF EHR-EMT EHR-HOS EHR-INS EHR-NUR EHR-PAT EHR-PHY IDtrust 2008 – Page 19 SKSML Protocol Request for many existing Symmetric Keys ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01"> 10514-4-312 10514-4-313 10514-4-314 10514-4-315 10514-4-316 IDtrust 2008 – Page 20 SKSML Protocol Successful response with one key ....... IDtrust 2008 – Page 21 SKSML Protocol Successful response with multiple keys ....... ....... ....... IDtrust 2008 – Page 22 SKSML Protocol Failed response for one key ....... IDtrust 2008 – Page 23 SKSML Protocol Failed response for multiple keys ....... ....... IDtrust 2008 – Page 24 SKSML Protocol Mixed response for multiple keys ....... ....... ....... ....... IDtrust 2008 – Page 25 SKSML Protocol Symkey element 10514-1-287 ....... huUYJMtaGHtXuLlWtx27STRcRpIsY= IDtrust 2008 – Page 26 SKSML Protocol KeyUsePolicy element 10514-4 DES-EDE KeyUsePolicy HR-Class http://www.w3.org/2001/04/xmlenc#tripledes-cbc 192 Active ...... IDtrust 2008 – Page 27 SKSML Protocol Permissions element ..... ..... ..... ..... ..... ..... ..... ..... ..... IDtrust 2008 – Page 28 SKSML Protocol KeyUsePolicy element 10514-4 DES-EDE KeyUsePolicy HR-Class http://www.w3.org/2001/04/xmlenc#tripledes-cbc 192 Active 10514-23 Payroll Application 1.0 http://www.w3.org/2000/09/xmldsig#sha1 NIG4bKkt4cziEqFFuOoBTM81efU= 2008-01-01 2008-12-31 07:00:00 19:00:00 IDtrust 2008 – Page 29 SKSML Protocol Symmetric Key Response 10514-1-235 10514-4 DES-EDE KeyUsePolicy HR-Class http://www.w3.org/2001/04/xmlenc#tripledes-cbc 192 Active 10514-23 Payroll Application 1.0 http://www.w3.org/2000/09/xmldsig#sha1 NIG4bKkt4cziEqFFuOoBTM81efU= 2008-01-01 2008-12-31 07:00:00 19:00:00 Yjv9h5FDqUiQXG0ca8EU871zBoXBjDXmlNxTux+mt1tXuLlWtx27STRcRpIsY= IDtrust 2008 – Page 30 SKSML Protocol SymkeyError element 10514-0-0 Payroll SKS-100010 Unauthorized to request this key-class IDtrust 2008 – Page 31 SKSML Protocol SymkeyError element 10514-2-2254 SKS-100004 Unauthorized request 10514-0-2254 SKS-100001 Invalid GKID IDtrust 2008 – Page 32 SKSML Protocol Request for a Key Caching Policy IDtrust 2008 – Page 33 SKSML Protocol Full SOAP request for a Key Caching Policy MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25n S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzI1MTcy MDMwWjBtMREwDwYKCZImiZPyLGQBARMBMjEZMBcGA1UEAxMQUE9TIFJlZ2lzdGVyIDIyMjEkMCIG A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIElua YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf U7LA3JhpUS4TlX0XFWqrcmltLOiVG7YBFarJFluBFJW2X6q8FuvUprv4V9nJrgiwAPtkiRyIx96n qKXIxkUlQ4idlEg1AZI9dEdf4Y5cqBBCygPYnBoTudglM7R47AjR4nr4ks8CAwEAAaOBqTCBpjAO\ MTAvoC2gK4YpaHR0cDovL2RlbW8uc3Ryb25na2V5Lm9yZy9kZW1vLXN1Yi1jYS5jcmwwDQYJKoZI hvcNAQELBQADggEBACK05PtvZD4WPglOe+EHUiApzFyCdRzf0pFZtxRwG9lR1PZUWUjmwTNfGFsL S6kyoHgUfVa5fpT1EU1mXUB/Lmo3hFGyprZjfmD7DwuBcYgmZHv7yHrmGOMIOXjFTACvHpM0vOce hVx2e4VE0yhBLu/ldH9awGGDp6Bk2XzxqQcs8y6ZzOXZAnPgKQZdjbFKERSsy/d1D8pk5baBk4bd Zh568OcaUrbm9ZReRVTVaY5qiQpkOU+tDrBSj/HIL6GAqegYllkz6KYCy6RVOy6iVVSjHocDqdJr EVOR+ds6xn8mmojdlERrILmuxiLpibPp609SfnDIxNlzLwe5g7ep3lc= | xgITEmXg4yMMg+RkKDTyVUw87VM= tlWtno1OMA7Os8GCZrUhmHXmmhM= Uv1zAePPoQmFey6UyslAYc2IzArOPwfXB48eTehoYaESrgzYVXSJetis2+2Jd8AgAsh1LF6Ayh67LhIAdigZPHR/9SxUYh4= 2007-03-01T23:04:47Z 2007-03-01T23:04:52Z IDtrust 2008 – Page 34 SKSML Protocol Key Cache Policy Response 10514-17 Corporate Laptop Symmetric Key Caching Policy This policy defines how company-issued laptops will manage symmetric keys used for file/disk encryption in their local cache. 2008-01-01T00:00:01.0 2008-12-31T24:00:00.0 86400 Active 3 7776000 3 7776000 IDtrust 2008 – Page 35 SKSML Protocol SOAP Fault ERROR: Other error reported; please review logs for details. Server error message is: No authorization to request this key:10514-2-2; if you believe this response is an error, please contact your Security Officer skf:SymkeyFault symkey.sks.msg.severe.0085 10514-2 O=StrongAuth Inc,CN=POS Register 222,UID=2 Active 10514-3 10514-2-2 2006-08-03 15:34:55.0 Failed IDtrust 2008 – Page 36 OASIS EKMI TC ● Technical Committee with 4 goals: 1. Standardize Symmetric Key Services Markup Language (SKSML) 2. Create Implementation & Operations Guidelines 3. Create Audit Guidelines 4. Create interoperability test-suite for SKSML IDtrust 2008 – Page 37 EKMI TC Members ● FundServ* (Canada) ● Wells Fargo ● MISMO ● OS Software company ● NuParadigm Government ● Database SW company Systems ● Storage/Security SW company ● PA Consulting (UK) ● Storage/Security SW company ● PrimeKey (Sweden) ● Govt. Agency (New Zealand) ● Red Hat ● Individuals representing Audit ● StrongAuth* and Security backgrounds* ● US Dept. of Defense ● Visa* ● Wave Systems * Founder Members IDtrust 2008 – Page 38 Conclusion ● Questions? ● Contact Information – www.strongauth.com – www.strongkey.org – info@strongauth.com – (408) 331-2000 IDtrust 2008 – Page 39 A Federation of Web Services for Danish Health Care Esben Dalsgaard Kåre Kjelstrøm Jan Riis Chair, SOSI steering committee Solution Architect Solution Architect / Project Manager Digital Health Denmark (SDSD) Silverbullet A/S Lakeside A/S Rugaardsvej 15 Skovsgaardsvaenget 21 Aabogade 15 DK-5000 Odense C, Denmark DK-8362 Hoerning, Denmark DK-8200 Aarhus N, Denmark (+45) 2092 8244 (+45) 2160 7252 ead@sdsd.dk kkj@silverbullet.dk jri@lakeside.dk ABSTRACT Federated Identity Management, Web Services, SOA, SAML, Having relevant, up-to-date information about a patient’s health WS-Trust. Single sign on, X509 Certificates, Digital Signatures, care history is often crucial for providing the appropriate SOAP, Security Token Service, Health Care, Electronic Patient treatment. In Denmark, IT systems have been built to support Records. different work flows in the health sector, but the systems are rarely connected and have become islands of data. 1. INTRODUCTION The IT system landscape in the Danish health care sector contains To remedy this situation, a service-oriented architecture based on a plethora of different systems targeting various needs: patient web services for online exchange of health care data between the administration, general practitioning, specialized care, electronic vast array of heterogeneous IT systems in the sector is being built. health recording, citizen access through web based health portals, etc. The architecture forms a federation of web services and enables secure and reliable authentication of end-users and systems in the The systems fall more or less uniformly into three classes: Danish health sector. The architecture is based on national and international standards and specifications. Yet it defines its own 1) Off-the-shelf systems typically obtained by privately held profile for secure interchange of data due to a lack of available companies (e.g. health centers) international profiles that could handle the special needs of the 2) Tender based regional systems (e.g. for hospitals) and health sector at the time of project inception. 3) National systems, typically tender based systems hosted by The architecture has evolved through a pilot project from mid health care related departments. 2005 to the end of 2007, and is being tested in a small scale 1st quarter 2008. This paper aims to convey experiences from the Some of these systems are integrated today, but typically project, so rich in benefits that the architecture has been accepted integration has been done locally, with the aim to reduce and standardized as the foundation for the future of system information redundancy. The real benefit in terms of quality of integration in the health sector in Denmark. patient treatment and care, however, lies in a deeper integration of health care systems across organizational boundaries, such that all Categories and Subject Descriptors relevant information for treatment and care is made directly C.2.4 [Distributed Systems]: Distributed applications available in the systems that the health care professionals use in their daily work. D.2.11 [Software Architectures] Founded in the strategic vision to strive for better quality in D.2.12 [Interoperability]: Distributed Objects patient treatment, better systems for health care professionals, and D.2.13 [Reusable Software]: Reusable Libraries the optimization of resources, the health care sector in Denmark has started the work on a national health care integration General Terms architecture that supports this vision. Performance, Design, Reliability, Experimentation, Security, The quest for universal availability of relevant and up-to-date Human Factors, Standardization, Legal Aspects, Verification. information has been the most important force in shaping the architecture. There are, however, many other premises that have Keywords governed this work, for instance the fact that in this domain, the “business” is never closed even if some or all of its IT systems Permission to make digital or hard copies of all or part of this work for become unavailable: People will still need treatment and care. personal or classroom use is granted without fee provided that copies are In 2005, the Danish health care sector launched an initiative with not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy the purpose of analyzing, profiling and testing a combination of otherwise, or republish, to post on servers or to redistribute to lists, national and international standards in order to standardize service requires prior specific permission and/or a fee. based integration mechanisms including measures for strong IDTrust ’08, March 4–6, 2008, Gaithersburg, MD. authentication of principals based on PKI. Copyright 2008 ACM 1978-1-60558-066-1…$5.00 The initiative was coined the SOSI project for “Service Oriented Law” [22]. These laws govern who can access what kinds of System Integration”. It was initiated by the Capital Region of information and why, and points out that citizens have a right to Denmark, The Region of South Denmark, and the Danish know to whom information has been disclosed. Medicines Agency. Present in the steering committee was also the In 2004, a web based national health portal, Sundhed.dk, [23] was Danish Ministry of Science, Technology and Innovation. The launched with the purpose of providing a single point of access to project was funded by Danish Regions and is now governed by health information for citizens. One vision of the portal is to make the Danish National eHealth initiative: Digital Health Denmark it possible for a citizen to learn what health care information is [4]. registered about her, and who has viewed it in compliance with the laws. 1.1 Life in the Health Sector The Danish health sector is financed by the Danish government The health portal hence has a need to pull information from GPs, via taxes and treatment is otherwise free. As opposed to other hospitals, laboratories and more, and to act as a medium between countries such as e.g. the USA this means that there is only one GPs and citizens e.g. for electronic consultation. major health care provider, and that many facilities including In summary, health care professionals across the sector need to hospitals are owned by the public sector. exchange information about patients that pass from one The health sector employs a wide array of different professionals, practitioner to the next in order to provide the best possible care. most notably hospital doctors and nurses, general practitioners At the same time, citizens have the right to gain insight into their (GP), and caregivers to the elderly and disabled. own health care records. In contrast to most of the other organizations in the health sector, These needs call for an IT-infrastructure that provides up to date GPs are private and often times small businesses employing only health care information about patients across the sector and across one or a few doctors as well as a secretary. The use of electronic the country in a timely fashion. health record systems (EHR) is widespread in this part of the sector: Today doctors receive patients in their consulting room 1.2 Privacy vs. Safety from behind a computer screen, running an EHR system. Health care records often contain sensitive data, which could potentially harm a person’s reputation or private life, should it be From time to time, the secretary will act on behalf of the GP in exposed to unauthorized people. More seriously, though, these taking blood samples, screening patients over the phone while records are the basis on which a patient receives care, and errors checking health records on his own computer, etc. caused by negligence, malicious intent, or the like can potentially GPs will prescribe medications for the elderly or disabled, submit cause physical harm. patients to hospitals, receive patients from hospitals for outpatient For these reasons, health care records are surrounded by security treatment, and more. measures. For hospital doctors and nurses, life is somewhat different from Ensuring the confidentiality of information while in transit from that of their GP colleagues. one practitioner to the next, and while being stored, is imperative Sometimes a doctor will work with patients in a ward all day to avoid eavesdropping by unauthorized individuals. together with a nurse in a situation akin to that of the GP. Wards Organizations that handle sensitive data are bound by Danish law are often equipped with a single computer that must be shared to ensure that only authorized staff gains access. In order to between the two professionals. At other times, a doctor must take comply with the privacy acts then, a practitioner should only be ward rounds and share computers with local nurses and other able to access information that she is authorized to, and which is doctors. of relevance with respect to her current treatment of a patient. Doctors typically use IT systems in a read-only fashion while Identifying health care personnel with a high degree of certainty, employing a dictation machine to take notes and make and performing authorization checks are hence prerequisites for adjustments in patient treatment. Information is then entered into exposing information. the system by a secretary who acts on behalf of the doctor. Yet even with all the locks and latches of the world, information Where GPs typically use a single system for all purposes, hospital will eventually be spilled to unauthorized people, typically doctors and nurses will use a set of systems during the day. through authorized personnel. When such a breach is detected, it is imperative to be able to trace the identity of the malefactor for In another part of the sector, caregivers follow the directions of forensic purposes. GPs in administering medicine for the elderly and disabled. Sometimes those receiving care will live in a nursing home, The need for privacy is complicated by the fact that access to sometimes in private homes. information is sometimes a matter of life and death. While citizens have the right to privacy, safety has a higher priority in Danish Because of the geographical distribution of clients, caregivers health care. In other words, the life of a patient takes precedence have a need for mobile access to medical information. In over the unconfirmed exposure of sensitive information to Denmark, this is usually realized through portable computers in authorized health care staff. the shape of PDAs. In nursing homes, a number of computers are shared by different caregivers in a situation akin to the one in In the event of unconfirmed exposure, tracking the identity and hospitals. following up on such an event is a necessity in ensuring privacy. Caregivers cannot prescribe and have only limited access to health Hospital doctors and nurses typically use not just one, but several care information, but can report the administration of medicines. IT systems during the day. In the worst case scenario, a user has different identities and uses different credentials with each system. Danish law protects the rights of patients through “The Danish Act on Processing of Personal Data” [20] and “The Danish Health Logging in and out of systems can therefore be a time consuming There exists within the context of SOAP based web services a task if care is not taken. profusion of specifications aimed at solving various well-known The first step towards providing a faster and simpler issues from the world of computing: security, reliability, authentication mechanism is hence to create a single identity with messaging, addressing, transactions, etc. single credentials for access to all systems. The second step is to Each specification adds levels of complexity and typically provide a single step of authentication to all systems, so called provides not just one, but multiple ways of achieving the same single sign on (SSO). overall goal. Add to this the fact that often times, specifications from different bodies compete to become the de-facto standard, 1.3 Availability each attacking the problem at hand in slightly different ways: The existence of health care IT systems is justified only by There’s the recipe for non-interoperability. promises of improvements in the overall quality and efficiency of patient treatment. The solution to this problem comes in the shape of profiles that cut through the stack of specifications, paving a narrow path of When work routines based on IT systems replace manual, paper design choices for specific usage scenarios. based ones, health care professionals will begin to plan their daily schedule accordingly. This means that once a certain quality of In the world of federated single sign on over the Internet, a service (QOS) has been established for day-to-day operations, this number of profiles and specifications exist. OASIS defines the QOS has to be maintained. SAML specification [14], which is implemented by the Internet2 initiative Shibboleth [6]. A large group of non-Microsoft In a complex of systems that exchange clinical information, any companies drive The Liberty Alliance Project [21], whose participant must hence minimize the impact caused when other specifications extend SAML. IBM and Microsoft push the WS- systems fail for instance by switching to emergency states where Federation [7] specification and implement support in a range of only locally cached information is available. products. The longer such external information systems are unavailable the The Ministry of Science, Technology and Innovation (MVTU) higher the risk of inefficiency or errors in patient treatment, and drives much of the standardization effort in the Danish public hence the higher the risk of physical harm, adverse effects or sector. It does so in part by evaluating international profiles and permanent maladies. As a safeguard, applications, power sources, specifications and classifying them in an interoperability communication lines, etc. must therefore be highly redundant, and framework [25]. For federated identity management, SAML 2.0 is built with robustness in mind to ensure continued operations even classified as the preferred framework of choice. Any Danish SSO when external systems are down. architecture should hence build on SAML, which was therefore chosen for SOSI as well. 2. THE SOSI SOLUTION The Danish National board of Health is responsible for an overall 2.1 Security Architecture IT-strategy with an ambitious goal: to provide a connected health An IT system that participates in a service-oriented architecture care sector in which health professionals have access to all must weigh the risks associated with revealing information to relevant EHR data regardless of where citizens seek treatment and unauthorized people against available security measures. no matter where or when this information was registered [5]. It is In the health sector, risks generally include unauthorized nonetheless important to stress that the motivation for the SOSI disclosure of sensitive information and in some cases physical solution is primarily rooted in user requirements. harm. While some types of information e.g. classifications of Most health care professionals wish to provide the best possible diseases may be harmless if disclosed, others such as patient quality possible in their work, and hence base their decisions on records are often not. all accessible and relevant information. There are therefore Because in Denmark it is legally the responsibility of the data examples of health professionals starting up at least five owning organization to prevent unauthorized disclosure, every applications every morning: some local, some regional, and some web service provider must perform a risk analysis and potentially national. Single sign on as well as infrequent sign on are hence strengthen security measures before exposing information via the examples of real world requirements. federation. The SOSI project aimed at evaluating standards and technologies That said, it still makes sense to define a set of basic security that could provide value to users by standardizing authentication properties that are always in place, and to lay out a simple set of mechanisms, standardizing the way service providers should security choices that can be implemented depending on identified expose services and by providing tools that could lower the risks. threshold for both service providers and service consumers to be part of this new game. A cornerstone in the security architecture of SOSI, the CIA triad addresses the aspects of Confidentiality, Integrity and Availability Given the environment of disparate IT systems scattered across [19]: the country with a need for common information, it was decided to realize this goal through a national Service-Oriented When in transit, data will pass over a number of networks and Architecture (SOA) via SOAP based web services over HTTP. confidentiality is ensured through the use of encryption techniques to avoid eavesdropping, no matter the content. The architecture had to address the availability and security issues identified earlier and build on existing infrastructure to reduce Communicating parties also need a guarantee that data has not costs, while adhering to national and international standards in been altered during transit. The integrity property is also order to ensure maintainability. guaranteed via cryptographic techniques. Finally, services must be available to be of any value to users, components that enable Java access to the Windows crypto API guaranteed by redundancy of critical components, communication have been used and evaluated in the SOSI project. lines, and enforced through policies and agreements. Last but not least the current OCES operator has several web Single sign on is achieved through the use of a trusted third party, services that support the OCES initiative, e.g. services for who will verify credentials on behalf of all parties in the converting certificate subject serial number to the national Danish federation. This is a delegation of trust model, which reduces the person identification number. burden of federation participants: instead of knowing all possible In mid 2005, when the SOSI project was initiated, none of the users, it is enough to be able to verify claims from the trusted third existing Single sign on projects gave good solutions to the party. particular needs of the project. Although there was a SOAP SAML assertions are useful for propagating claims about digital binding for SAML, no profile existed that laid out a complete identities that can be used in e.g. authorization checks. To be protocol stack for exchanging SOAP messages with SAML trusted by a third party, though, credentials must additionally be assertions, while achieving Single sign on to web services. supplied for external verification. There was and still is a heavy bias towards providing SSO for Credentials come in many shapes and sizes with different security browser-based clients, with specifications relying on facilities properties. While passwords may be simpler to manage, they are such as HTTP redirect and cookies. susceptible to eavesdropping attacks and may be easy to crack if However, most health care applications in Denmark are non- not chosen carefully and changed often. X509 certificates offer browser based. In most cases users need specialized and highly stronger properties, non-repudiation and confidentiality, but supportive systems, something which until very recently was not require equally careful handling of private keys to be trusted. feasible to build with web browser technology. The SOSI federation employs strong credentials based on X509 certificates, which provide a high level of certainty in the Many of the existing SSO projects include services or components identification of the sender. that increase system dependencies instead of reducing them, thereby introducing potential single points of failure. One of the 2.2 Architectural Building Blocks best examples is that most SSO profiles mandate service provider When designing how exactly confidentiality and integrity should initiated user authentication, typically done by communicating be realized through cryptography, it came down to reusing an with an authentication service. existing national VPN based health care network or to employ In browser-based applications, where connectivity is a “end-to-end” message encryption/signing. Although end-to-end precondition, service provider initiated authentication is natural encryption/signing may seem captivating because messages can and probably the only viable solution, in part because client then pass freely over potentially any network, the benefits were systems are very thin and mostly session based applications. If the deemed smaller than the burden of encrypting and signing streams central authentication service is unavailable, service providers of very large messages. cannot be called either. . A large part of the health sector organizations in Denmark are already connected to the above mentioned VPN network known as However, in a pure web service integration architecture, where “SDN” [8]. The network was originally planned for clients more often than not are servers themselves, it is possible to teleconferencing, exchanging large amounts of data e.g. x-ray build more fault tolerant architectures. images, and accessing web based applications in a secure manner. Client-initiated user authentication can for instance be mandated, Any organization that wants access to services on SDN is and issued security tokens be cached in client system for later use. evaluated for relevancy and must sign a mutual agreement per In a model where security tokens are additionally off-line system-to-system connection. Although cumbersome, this verifiable by service providers, only users that are not already procedure provides a certain degree of certainty that the network authenticated will be affected if the authentication service is is primarily made up of organizations with legal business in the unavailable. health sector. So, although many of the existing profiles had elements that could By supplying an integrity and confidentiality protected transport be reused, the use-cases and interaction schemes were not. A basic mechanism, which is immune to known security attacks, and SAML and WS-Trust based profile [9] was therefore created which has many of the relevant organizations connected already, based on the following principles: SDN is useful for web services as well. 1. A user should be able to authenticate with the federation Part of the Danish it-strategy is the mandated use of digital once and then be able to use any service for which she has signatures for secure identification of health care personnel. An authorization for as long as she can present a valid federated important precondition in the design of a solution for SOSI would security token. The design should, in other words, help therefore be to leverage the Danish national certificate initiative, reduce the number of sign-ons to the federation. OCES. 2. Basic information security should be provided by the existing OCES provides all the features of a nationally implemented X509 security infrastructure. based PKI. What makes OCES even more interesting is the Open 3. Using a client initiated authentication scheme, a WS client Source components and commercial products that surround the (WSC) system should be responsible for logging the user into initiative which can also be used in WS integration. Specifically a the federation before starting to interact with any WS Signature Server [1] that enables secure centralization of private provider (WSP). keys in the client environment and the OpenOCES [18] 4. Inspired by current work on short-lived PKI certificates Step 6. Upon receipt, the WSPs validate the security token by [16][17] the security token must have a limited lifetime and verifying the STS digital signature and leverage the hence eliminate the need for revocation checks by WSPs. embedded attributes for logging and authorization. 5. Security tokens must be off-line verifiable by WSCs and Step 7. Finally a result, i.e. business information or an error is WSPs, i.e. without having to communicate with any third returned. party. 6. Security tokens should be able to carry basic end-user and client-system attributes that most WSPs use for authorization Certificate Attribute- Authority (CA) Service and/or logging. The design should support trust re-use, such 6 that when the credentials within the security token have been verified, the embedded attributes can also be trusted. In effect 3 this reduces the effort that WSPs must put into implementing 2 web services. It also stabilizes the entire architecture by 7 Web Service Provider 1 Web Service Provider 2 reducing system dependencies to a minimum. Security Token Service (STS) 7. Security tokens must not be subject to theft, i.e. measures must be put in place to hamper hostile token takeover. The proposed technical solution consists of: • A trusted federation Security Token Service (STS) with a 4 1 maximum validity of 24 hours. • 5 Security tokens as digitally signed SAML Assertions 5 • Client initiated authentication that results in STS signed Web Service SAML assertions Client • Core attributes embedded in the SAML security token Figure 1: a simple WSC/WSP interaction • Message integrity through digital signing of SAML It is important to note the temporal flexibility between steps 1-4 assertions combined with web service body data. and steps 5-7: The authentication request for the STS could be executed as part of the user’s log-on to the WSC system. They • Confidentiality of transport, but not of message data in a could even be performed asynchronously and would only become trusted circle of participants. blocking if the user entered a step in a workflow where entrance Figure 1 shows a simple interaction between a WSC, an STS, and to the federation was needed, for instance in order to gather a number of WSPs. Please note the WSC initiated authentication information from outside the system. scheme and that the WSPs are not depending on access to the STS What is actually happening in the STS is that the user’s long lived to verify security tokens and basic attributes: credentials are converted to short lived credentials combined with Step 1. The user authenticates with the federation either just-in- core attributes. In the SOSI project these short-lived security time before calling a service or as part of the local log- tokens were coined “virtual health professional identity cards” (or on to the WSC system. The WSC builds a SAML ID cards for short). The STS issues digitally signed ID cards that assertion with core attributes and user credentials, in this by PKI properties are verifiable by service providers without on- case a digital signature. line access to the STS or attribute services. Step 2. The STS checks that In effect the federation is established by the sole STS certificate, a. the digital signature of the WSC system is valid which also means that the STS certificate must be protected viciously. In the SOSI project it was discussed whether a security b. the WSP system certificate is valid and not revoked breach on the STS should be handled by policies and emergency c. the WSP is on the white-list of systems that are allowed procedures (e.g. by phoning all service providers and having them to enter the federation shut down their services) or having all service providers check the STS certificate for revocation from time to time. d. the user’s digital signature is valid The latter seems to be the only manageable solution and was e. the user’s certificate is valid and not revoked decided upon. The solution hence yields a system dependency Step 3. The STS now seeks to verify that the client-specified from WSPs to the CA revocation service, but these calls are done core attributes are valid by using backend attribute infrequently and independently of the high volume business calls. services. Some of these verified attributes are cached for The risk of compromising the federation certificate is comparable a short period for optimization purposes. to the risk of compromising the CA root certificate, which is Step 4. If everything is OK, the security token is digitally considered to be very low. signed by the STS and returned to the WSC. The maximum validity of ID cards is 24 hours in the SOSI Step 5. The security token can now be used in interactions with architecture. However, the amount of trust a WSP can put into the different WSPs until it expires. security token depends on how “fresh” the token is. In other words the level of trust degenerates over time. If the token is 5 minutes old when received by a WSP, the WSP message-id, which is required on all messages in the shape of a can be pretty confident that the same user is still operating the Universally Unique Identifier (UUID), used to prevent replay console. The SOSI proposal opens up for the possibility that a attacks. WSP can choose to reject security tokens that are “not fresh All messages are integrity protected through an additional digital enough” at its own discretion. In effect this means that users are, signature on the XML that makes up the SOAP body, the WS- within 24 hours, only challenged to authenticate themselves when Addressing headers, and the SAML token. This ties the sender’s they use a service that needs authentication proof, which is more identity to the supplied information and prevents identity theft: “fresh” than the security token the user currently holds. Without this signature, an eavesdropper would be able to create a It is worth noting that this mechanism is in direct opposition to the new message and embed a stolen SAML assertion, effectively “single-sign-on” requirement: If all WSPs reject ID cards that are impersonating someone else. more than 5 minutes old, the user will be forced to re-login to the Messages are confidentiality protected only when in transit via the federation every 5 minutes, effectively disabling SSO. underlying transport layer. The federation is made up only of This kind of time-out requirement should, however, only happen well-known parties who have signed an agreement before being for service-operations, which provide or receive very sensitive granted physical access. Further each party is bound by laws not information and hence demand very rapid security token time- to disclose sensitive information, and it was therefore decided that outs, which means they are more likely to require a real digital it was not necessary to employ message encryption. signature and hence entail the end-user to provide credentials for The profile defines an SSO mechanism, which uses WS-Trust activating the private key. [15] messages to perform authentication via a trusted third party, The decision, of which credential strength, security token time-out the Security Token Server (STS). WS-Trust was chosen over its level and which verifiable authorization attributes the specific SAML equivalent because it seemed to have the most momentum service provider should require, must be based on a thorough risk with respect to actual implementations in products at the time. analysis. The profile uses a request-response model and leverages the The time-out level is a true measure of “trust”, and hence a SAML specification’s SOAP binding to embed the assertions in scheme where WSPs’ have different time-out requirements for SOAP headers. In this respect, the profile is completely in different (types of) client systems can be considered. In a national compliance with the SAML specification. service infrastructure this can also be used for governing client systems towards federation compliance. 3. IMPLEMENTING SOSI At the time of writing, the pilot project is being tested on a smaller For the STS and WSPs’ to be able to distinguish which client scale, yet many relevant observations have been made not least in system an ID card pertains to, the request needs to carry the process of realizing the architecture. information about the “system-principal” that is performing the request on behalf of the user. 3.1 Participating Systems The current profile mandates that any request will carry two From the outset of the SOSI project, two existing hospital systems digital signatures: One from the user on the SAML assertion and were planned to implement the solution: One in the capital region one from the requesting system on the entire message, which of Denmark and one in the region of South Denmark. provides a combination of system identity and message More specifically it was planned to improve the quality of authentication. available patient related medicines information by connecting the The STS will check both signatures as well as both certificates medication modules of these systems with the national medication and will acknowledge successful verification by embedding and prescription services hosted by the Danish Medicines Agency. references to the original certificates, and sign the ID card itself. The latter, then had to be enhanced as well to be able to By including secure certificate hashes into the issued ID card, participate in the federated solution. The fourth party in the WSPs will be able to verify message authentication signatures system setup was the authentication service (STS). without checking the client-systems’ certificate for validity or Local systems (WSC) National federation revocation since the revocation checks have been performed (WSPs) “recently” by the STS. Rich client STS 2.3 A New Profile Rich client Rich client EHR system SOSI defines a web service profile where every request and Rich client Rich clients response message will carry an assertion that identifies the sender, Medication and every assertion will contain credentials that allow the receiver module to verify the identity of the sender. National Medication & Credentials come in the shape of digital signatures over the XML Prescription elements that make up the SAML assertion stored in compliance Cryptomathic Signer with the XML-Signature specification [26]. A receiver can use the unique certificate identifier to lookup the person or company via Figure 2: Participating systems overview trusted web services. Since health care personnel moves around and uses the rich client Routing information is embedded in the SOAP messages to enable part of the medication applications at different terminals, PKI other transport mechanisms than HTTP. WS-Addressing [26], the private key handling is complicated somewhat. Fortunately this de-facto standard for such information in web services, is problem had already been identified and solved by the regions leveraged and profiled. WS-Addressing contains a unique when the clinical workplaces were integrated with the Danish eHealth Portal [23]. In both cases a regional “signing server” [1] When the (real) performance problems have been solved, more was introduced that centrally handles and protects private keys for doctors will be allowed access to the system, and the false startup all end users (see figure 2). penalties should disappear. Since the new facilities can be When the EHR system needs to authenticate the user with the activated on a per user basis, the systems can be scaled at a very national federation, it challenges the rich client with parts of the fine grained level, enabling the monitoring of STS and WSP STS request. Once the signed challenge returns to the EHR systems very carefully as more users get access. system, it can produce the final STS request and store the returned 3.2 Lowering the Threshold ID card locally for 24 hours. As the user then moves to another The outlined architecture puts quite a burden on service providers terminal, the same ID card can still be used in the national web and clients. In order to join, a party must be able to handle SAML, service federation. speak SOAP over HTTP, create and verify digital signatures, The requirements of the STS service were specified and quotes communicate with a trusted third party, check revocation lists, and were requested from relevant vendors. The STS was required to more. handle the following number of requests for ID cards with the Because the architecture is based on standards it might be possible following response times for the pilot test period: to find commercial off-the-shelf (COTS) products that would be • Verification and signing of 12.000 ID cards in 24 hours able to handle these tasks. Each product would require some configuration, though, and might have a steep price tag on it. In • A maximum continuous throughput (MCT) of 1500 ID some parts of the health sector, in particular at the GP’s, steep cards per hour, with a peak of 10 simultaneous ID card prices are not an option. requests. Further, the federation is built on existing software, which was not • Mean response times < 2 seconds while upholding MCT initially meant to communicate with other systems. Hence, any • 95% percentile < 5 seconds while upholding MCT implementation of federation infrastructure will include some amounts of custom code. • 99% percentile < 10 seconds while upholding MCT It is crucial to the success of the health federation that all parties Of the two quotes received, one based was on an off-the-shelf have the means to join in. As a remedy to the situation, it was solution, and one was custom development. The off-the-shelf decided early on to establish an open source organization, which solution was considerably more expensive than the custom would provide software that implemented federation infrastructure solution and had some annoying limitations in the usage of and that could support the vendors that were to use the Open SAML/WS-Trust. In addition, the modules that had to be Source products. developed to encompass the special health sector needs were proprietary, which made it difficult to move to another product A set of tools would make it viable for even small companies to without considerable expenses. The STS was optionally requested join in, lowering the threshold and enabling the federation. to be developed under a reciprocal Open Source license, which Faced with a lack of product support due to a lack of profiles for only the custom solution adhered to. SAML based web service interactions, it was clear early on that The custom solution was chosen for the pilot project and has now support for the SOSI profile would have to be implemented into been developed and committed to the Public Danish Open Source every IT system in the federation in a custom manner. initiative [12]. This fulfills the needs for the SOSI pilot project While the SAML AttributeStatement although somewhat verbose and a few soon to come smaller projects, but as the national in its syntax is not hard to implement, creating XML digital federation develops, and the commercial STS market is maturing, signatures is an entirely different story. the custom made STS will most probably be replaced with an off- the-shelf product. A programmer whose development platform does not support the XMLDSig [28] standard out-of-the-box will have to piece signing At time of writing 3 of 4 systems have been developed/enhanced and verification functionality together e.g. from a crypto API. and a very slow scale-up has begun. Until now only a few doctors This includes creating secure hashes of data, implementing have been authorized to use the new facilities in their clinical canonicalization algorithms, encrypting and decrypting, base 64 systems and only a few dozens of ID cards have been retrieved encoding and decoding, manipulating XML structures, and more. from the STS. Nonetheless users have welcomed the solution and can see the benefits and perspectives right away. As a remedy to this ailment it was decided early on by the open source organization to build a Java based library, “Seal.Java” [2] The overall work flow has performance issues, which are that would provide an abstraction, which would allow a developer currently being analyzed by the vendors. On the STS the biggest to work with high-level primitives and not worry about envelope bottleneck is the OCES web service that resolves the Danish formats, digital signatures, or the darker secrets of the base-64 person ID from the PKI certificate. This STS back-end algorithm. verification more often than not accounts for a 2 second “delay” which of course is unacceptable. The EHR systems that entered into the SOSI project from the hospital side were mainly Java based, and while Seal.Java was One of the problems in the current state of the project is that the relevant here, it could not be used with the EHR systems from the systems are actually misleadingly slow because they were built for GP side that are mostly rich Win32 or .NET applications. This higher transaction volumes. In the current sparse user volume, fact spawned Seal.NET [10], with the exact same purpose as its caches and prepared database statements and connections are Java sibling. getting evicted between invocations, which results in unnecessary startup penalties almost every time the user is accessing the Both projects have been constructed on an Open Source license system. and are available for general scrutiny via the web. Third party software often suffers from the “not invented here service interface, the WSDL, including data models and service syndrome”, a problem which the library projects sought to address end-points, is defined independently of the code that implements by going to great lengths in testing, tuning, and publishing quality it. reports. When response times are high, multi-threading issues Unfortunately not that many off-the-shelf toolkits give good fixed, code coverage of the test suite well above 95%, and long support to such a development paradigm. Now that tooling was term endurance testing of all API methods does not show any already being implemented, it was decided to craft a contract-first leaks; when the entire library is built from scratch, and all tests WSDL tool that would allow for the easy creation of service exercised on a nightly basis with fresh results published online in interfaces as well. the morning [3], chances are that others will accept it as stable and useful as well. Tooling is an important mechanism to help bridge the gap between specifications and products. Tools can make the This aggressive strategy for quality reporting has proven to be difference as to whether a particular IT system will be able to highly effective. Adoption of both libraries is high with most participate in a certain scenario or not and without them, the SOSI peers using them. This makes it very easy and low-cost to project would not have been possible. implement minor adjustments and optimizations to the SAML profile, because most vendors just need a new version of the While providing tools and libraries to lower the threshold of library to be able to produce a new request or response XML. integrating existing systems, there is also a risk associated with such a strategy: Source code, no matter how well written, will Parallel to the developed Open Source components, a support always have flaws, errors, or lack a feature for a given situation. organization was established. Vendors can contact a support Without an organization to maintain the code, it will eventually mailing list for free and very rapidly get answers to general work fail to be helpful.. flow or detailed coding questions, or solve problems or advice to workarounds with the libraries within hours. The response to this On the other hand, it is actually possible to tune the profile over sort of support has been very positive and has had a very positive time or align it with coming standards, when all parties rely on a influence on the vendor / customer relationship. few infrastructure components. Given the volatility of the current specifications for federations of services, this might prove to be a 3.3 The XML Schema Challenge crucial strength. During development of the libraries, the idea surfaced that it would be useful to implement XML Schema validation for the 3.4 Federation Verification and Control XML, SAML, SOAP, WS-Trust, etc. that was passed around. Because the federation is established by digital signatures from Validation would improve overall quality and general faith that the authentication service (STS), all parties in the federated standards were followed. infrastructure are able to check federation security tokens (ID cards) by validating the STS signature and the STS certificate. Unfortunately that proved to be very difficult. Checking the signature is a matter of working with XML- A profile that cuts across specifications is in effect limiting the Signatures, something that enjoys library support in many number of possible choices a developer can make. Wouldn’t it be programming languages. The STS certificate check is a little more great if it were possible to express the new set of limited choices involved as the entire chain up to the issuing authority must be in supporting schemas as well? It isn’t! For instance, how do you validated including revocation checks. Fortunately it can be done express that it is a requirement to have an enveloped signature rather infrequently due to the very low risk that STS credentials inside a SAML Assertion if the user authenticated using PKI? should get compromised. As a hardening measure, the SOSI Expressing such complex conditions is beyond and above what production STS has been placed in the same production room as you can do with XML Schema. Even if it were possible, the the Danish OCES CA services, hence the same policies for access, problem of how to version a set of XML Schemas in concert audit etc. are enforced for this system. arises: There is no great way today in which existing schemas can Having one key pair that establishes a federation makes it easy to be narrowed under the same name space. establish test federations e.g. for pre-production, integration-test For development purposes, it was therefore decided to modify the and other development stages. This has been employed in the original schemas, SAML, SOAP, etc. to allow only those elements SOSI project, where the OCES CA has issued two certificates – that were mandated by the profile. While helpful for testing, these one for production and one for integration/pre-production. schemas would not be used for production because they were However, the STS production certificate will expire some day, overly strict and hence not compatible with COTS products that and various mechanisms have been put in place to make a smooth will often attach extra non-critical SOAP headers, id’s, etc. transition from one certificate to another. For instance the Recently, a central test center for web services in the Danish Seal.Java library has STS certificate checks incorporated that are health sector [11] has been launched. The test center is capable of resistant to STS certificate renewal. emulating clients and servers for various concrete services to a While developing and testing the solutions, the vendors have had certain point not including too much business logic. It is manned some trouble with the VPN based dedicated health network (SDN) by staff that can monitor requests and responses, and aid in through which all production services are accessed. None of the debugging. The center provides value in ensuring that all parties vendors could be authorized to access SDN directly as they are wishing to implement a service will get past syntactical obstacles not public health related companies, and since the production with the profile as well as with the model of the service in servers are never on two networks at the same time, it was very question. cumbersome getting access to logs, debugging information, not to For reasons of maintainability, loose coupling, and reuse, web mention changing configurations or deploying new software services should be designed in a contract-first manner, where the versions. As mitigation for this, the test federation was established on the crucible. Most notably a security gateway, SOSI-GW, is being public Internet, where developers can access a test STS from their developed that enables trusted domain cross-over. This vastly development environments. Unfortunately some services e.g. reduces the effort in implementing SOSI support for web service back-end ones used by the STS for core attribute verification only clients and will enable single-sign-on to the national federation exist on SDN and the semantics and performance aspects can across multiple client systems. The gateway becomes the single therefore only be tested in the production environment. This is one point of entry to the national web service federation from the of the issues that must be resolved in the coming national trusted domain, and all sorts of common services can be infrastructure. centralized in this service. 3.5 Standardization Digital Health Denmark is also launching initiatives to analyze There is no profile without a specification, and the SOSI efforts possibilities for limiting the impact when the back-end have therefore been captured in a document known as The Apt verification systems of the STS fail. One possibility is to allow the Web Service (DGWS) [8]. STS to issue partially verified ID cards as long as every attribute verification state is clearly stated. The STS may also cache Owned by the Danish Centre for Health Telematics (MedCom), verification states and skip re-verification if the cached who is responsible for standardizing the communication between verification has not decayed too much. This reduces the impact of parties in the health sector and operating SDN, the specification failing verification services or decayed attributes to users who are has now reached version 1.1. using federation services that need these specific attributes. While there might be a few adjustments to make on DGWS in the Of interest is also the possibility to use “break the glass” solutions aftermath of the first pilot, this version is currently poised to combined with logging and control mechanisms. If for instance a become the de-facto standard for all web service communication WSP requires a newly verified STS attribute, and the presented ID in the Danish health sector. card contains a non-verified or decayed attribute, the WSP may To ensure compliance, MedCom staff mans the aforementioned choose to return a “break the glass” warning that informs the test center [11] and is providing practical assistance in testing that client system and subsequently the user that she will be subject to web service clients and servers implement not only DGWS, but investigation if proceeding. This could be combined with also the business data exchanged in DGWS SOAP envelopes. asynchronous mechanisms that seek to resolve the unverified claims. With specifications, tools, and a certifying entity in place for free, there should be a viable chance of getting even the smaller The SOSI project has not produced any results in the area of web vendors on board the federation. service governance, but as the solution scales to multiple clients and providers this will become a very important issue. Digital 4. LOOKING FORWARD Health Denmark is also launching initiatives to meet these Federated identity management has evolved over the past few challenges. years, and there are now a couple of frameworks that might address the needs in the SOSI architecture. Most notably, the 5. CONCLUSION Liberty Alliance recently published version 2.0 of its Liberty ID- The proposed architecture and profile have been developed and WSF, which defines interaction scenarios for web service clients tested in real life, and the results are very promising with respect with SAML via SOAP over HTTP. Future work will examine to both the development process as well as the implementation Liberty and alternatives in order to evaluate whether it would be effort. feasible to align the SOSI project without critical impact. At the time of writing end-user feedback has not been Parallel to the initiatives in the health sector, MVTU is driving systematically gathered yet, but purely from a technical other pilot projects that address slightly different needs, but define perspective the proposed architecture exhibits a set of nice similar architectures. The OIOSI [24] project for instance is being qualities that support the special requirements for the health pushed for secure asynchronous business document exchange via sector: the internet using PKI and web services. • Single-Sign-On to Web Services within the national The health sector specific infrastructure must to be aligned with a federation / trust domain. future national infrastructure for all of the public sector without violation of the identified design criteria. • Authentication levels. Users and systems can be authenticated with different degree of certainty, depending While digital signatures are currently being touted in Denmark as on the credentials that the principal presents. This is in the technology to identify citizens and professionals alike, it is accordance with the guidelines [13] from NIST on which loved more by engineers than by end users. A digital signature is MVTU has based their authentication guidelines. cumbersome to deal with and certificate management is not mature from an end-user’s perspective. • Reduction of impact of unavailability of services. If, for instance the STS is unavailable, only users without a security On the longer term, biometrics and RFID for near field token or with an expired security token will be hindered in identification could have a place as the identifying technology, performing their treatment. All other users can continue to e.g. to release the private key of a certificate instead of a treat patients until their security token expires. password. The driving force for biometrics or RFID will, however, not be the increased security, but the fact that • Reduction of the effort that WSCs and WSPs must put into identification will become easier for end users. implementing web services. WSPs only have to trust/check one certificate (the federation certificate owned by the STS) At the time of writing multiple initiatives governed by Digital Health Denmark that extend the SOSI architecture are in the • Maximum performance. The number of requests/messages [13] NIST, Electronic Authentication Guideline, 2006, is minimized. When trust has been established and the user http://csrc.nist.gov/publications/nistpubs/800-63/SP800- has logged in to the federation, the WSC and WSP 63V1_0_2.pdf communicate directly with no third party involved. [14] OASIS, 2007, SAML 2.0, http://www.oasis- • Transparency and flexibility through the use of Open open.org/committees/tc_home.php?wg_abbrev=security#sam Source licensed tools and products. lv20 • Reuse of existing infrastructure. The design reuses existing [15] OASIS, 2007, WS-Trust, http://docs.oasis-open.org/ws- infrastructure for establishing secure channels that takes care sx/ws-trust/v1.3/ws-trust.pdf of confidentiality and stream integrity and prevents known [16] PGP Corporation, 2006, PGP White Paper – Revocation cryptographic attacks. Made Simpler, The positive experiences with the architecture and profile http://download.pgp.com/pdfs/whitepapers/Revocation- outweigh the downside of not yet having international standards SLCs_060104_F.pdf that fit the requirements of the Danish health sector. [17] Profile for Short Lived Credential Services X.509 Public Key SOSI is currently acknowledged as the best solution to the Certification Authorities with secured infrastructure. integration challenge, and at the time of writing, multiple projects http://www.tagpma.org/files/IGTF-AP-SLCS-20051115-1- that implement modules and systems based on the SOSI design, 1.pdf its standards and the associated Open Source tools are in the [18] TDC, 2007, OpenOCES, http://www.openoces.org/ making. [19] The CIA Triad, 6. REFERENCES http://en.wikipedia.org/wiki/Information_security [1] Cryptomathic, Cryptomathic Signer, [20] The Danish Data Protection Agency, The Act on Processing http://www.cryptomathic.com/Default.aspx?ID=124 of Personal Data, Datatilsynet, Law no. 429, May 31st, 2000, [2] Danish Regions, 2006-2007, SOSI Components, https://www.retsinformation.dk/Forms/R0710.aspx?id=828 http://www.sosi.dk/twiki/bin/view/ProjectManagement/SOSI [21] The Liberty Alliance, 2007, Liberty Alliance Project, Products http://www.projectliberty.org/ [3] Danish Regions, 2006-2007, SOSI Seal Component, [22] The Ministry of Health and Prevention, The Health Law, http://www.sosi.dk/sosi/seal/ Law no. 546, June 24th, 2005, [4] Digital Health Denmark, 2007, http://www.sdsd.dk/ https://www.retsinformation.dk/Forms/R0710.aspx?id=1007 4 [5] Digital Health Denmark, 2007, National IT strategy, http://www.sdsd.dk/arch/_img/9080664.pdf [23] The Ministry of Health and Prevention et al., 2007, Sundhed.dk, http://www.sundhed.dk [6] Internet2/MACE, 2007, Shibboleth Project – Internet2 Middleware, http://shibboleth.internet2.edu/ [24] The Ministry of Science, Technology and Innovation, 2006, OIO Serviceorienteret Infrastruktur, [7] Lockhart et al., 2007, Web Services Federation Language, http://www.oio.dk/arkitektur/soa/infrastruktur http://www.ibm.com/developerworks/library/specification/w s-fed/ [25] The Ministry of Science, Technology and Innovation, 2006. The Interoperability Framework. [8] MedCom, 2003-2008, The Danish Health Network, http://standarder.oio.dk/English/ http://www.medcom.dk/wm110002 [26] W3C, 2006, Web Services Addressing 1.0 – Core, [9] MedCom, 2007, The Apt Web Service (DGWS), http://www.w3.org/TR/ws-addr-core/ http://sundcom.health-telematics.dk/svn/DGWS/ [27] W3C, 2002, XML-Signature Syntax and Processing, [10] MedCom, 2006-2007, Den Gode Webservice Tools, http://www.w3.org/TR/xmldsig-core/ http://www.medcom.dk/wm110344 [28] W3C, 2002, XML-Signature Syntax and Processing, [11] MedCom, 2007, Testcenter, http://testcenter.medcom.dk/ Recommendation. http://www.w3.org/TR/xmldsig-core/ [12] National IT and Telecom Agency, 2007, Software exchange: Forum for software development in the public sector, http://www.softwareborsen.dk/ A Federation of Web Services For Danish Health Care IDTrust 2008 Kåre Kjelstrøm, kkj@ silverbullet.dk The Danish Health Sector Hospital Many systems Caregiver Exchange Many computers Few systems Doctor Doctors PDA access Nurses Information Web access to own data Single system Doctor Secretary General Practitioner Patient Requirements:Privacy vs. Safety Health Confidentiality Authentication & Authorization Records Emergency Access Record Activity Requirements:Availability New work Redundancy routines based Of systems on IT Redundancy of lines Only loose dependency! Requirements:Single-Signon Often multiple logins to multiple systems multiple times a day Login Login SSO Login Reduce number of logins to external systems! Requirements: Preconditions National PKI infrastructure with SSN lookup Health care network (VPN) Existing specifications and profiles Rich non-browser clients High Level Proposal: SOSI Service-Oriented System Integration Message integrity thru SOAP Web Services PKI Signatures on SAML tokens and body data Confidentiality & Integrity protected Security Token Hospital VPN Network Service (STS) Federation of Trust SAML 2.0 assertions as security tokens Nursing Home Central National Services Existing Infrastructure GP Client initiated SSO ID card: SAML Security Token Embedded into every SOAP message header SOSI IDCard Version: 1.0 ID: QYZ1234 Offline verifiable Valid: 10/25-2008 - 10/26/2008 credentials (signature) Issuer: EPJQ 3.0 Type: User System: EPJQ 3.0 Identifies person or Organization: Region X system Organization ID: 1234 Owner: S.Miley AuthorizationCode: 5678 Role: Surgeon SSN: 0101121234 Contains “core” Email: s.miley@abc.dk Occupation: Doctor attributes Service Interaction Timeout  Maximum ID card lifetime: 24 hours  Authorization by service provider  Service provider decides timeout level  Based on risk analysis SOSI ID-Kort Version: 1.0 ID: QYZ1234 Gyldig: 25/10-2006 - 26/10/2006 Udsteder: EPJQ 3.0 Type: User System: EPJQ 3.0 Organisation: Region X Organisation ID: 1234 Indehaver: S.Miley Autorisationsnr: 5678 -IDCard Valid? -IDCard ”fresh” enough? Rolle: Kirurg CPR: 0101121234 Email: s.miley@abc.dk Stilling: Læge -Person authorized? Trail Blazer: Medicines Information Receive patient: Receive patient: Fetch data Fetch data Discharge patient: Issue Receipt: Upload data Upload data GP Hospital Web Services at the Danish Medicines Agency Participating Systems Local systems (WSC) National federation (WSPs) Rich client STS Rich client EHR system Rich Richclient client Rich clients Medication module National Medication & Cryptomathic Prescription Signer STS Performance  Verification and signing of 12.000 ID cards in 24 hours  A maximum continuous throughput (MCT) of 1500 ID cards / hour, with a peak of 10 simultaneous ID card requests.  Mean response times < 2 seconds at MCT  95% response times < 5 seconds at MCT  99% response times < 10 seconds at MCT Implementing SOSI? SAML? COTS? SOAP? XML Signature? Cost? STS & WS-Trust? Integrate with legacy system? IDCards? Revocatio PKI? n Lists Lowering the Threshold Code Libraries Support Organizations .NET library Java library Technical Support Center Toolkits Contract First WSDL Engineer .NET code gen Security Gateway MedCom Web Service Test Center Looking Forward Partially verified Biometrics, RFID, Near IDCards? Field Identification? ”Break the glass” solution: Heightened control Alternatives from National IT- and Telecom Agency? Service governance Liberty ID-WSF 2.0 a replacement? Summary  Federation of health care systems using SOAP web services, SAML and WS-Trust  Single-Sign-On to Web Services within the national federation / trust domain.  Reduction of impact of unavailability of services.  Reduction of the effort that WSCs and WSPs must put into implementing web services.  High performance architecture where the number of requests/messages is minimized.  Transparency and flexibility through the use of Open Source licensed tools and products.  Reuse of existing infrastructure. The design reuses existing infrastructure for establishing secure channels that takes care of confidentiality and stream integrity and prevents known cryptographic attacks ? Questions Security and Privacy System Architecture for an e-Hospital Environment Kathryn Garson Carlisle Adams School of Information Technology and School of Information Technology and Engineering (SITE) Engineering (SITE) University of Ottawa University of Ottawa Ottawa, Ontario, Canada K1N 6N5 Ottawa, Ontario, Canada K1N 6N5 kgars062@uottawa.ca cadams@site.uottawa.ca ABSTRACT The Mobile Emergency Triage (MET) project provides doctors Hospitals are now using electronic medical records and computer with decision support for triage, diagnosis, and treatment of applications in order to provide more efficient and thorough care patients in an emergency room setting. The project will be for their patients. The Mobile Emergency Triage system provides implemented first as a trial and then a full production version in doctors with decision support for emergency care by pulling the emergency room of a hospital in Ottawa, Canada. Doctors will information from a patient’s health record and a medical literature be using a tablet PC with the MET software to help them in their database. In order to achieve compliance with privacy legislations tasks. The MET software pulls information from a collection of PIPEDA and PHIPA, security and privacy measures must be put medical literature and electronic health records (EHRs) to provide in place. Encryption and access control are necessary for ensuring doctors with evidence-based decision support. The agent-based proper authorization and confidentiality for patient records. system is interactive allowing the doctor to input symptoms and Strong authentication and audit logs are required to ensure access view possible diagnosis and treatment options. The doctor can only by those allowed. We discuss differences in security make treatment decisions based on this information or enter technologies and detail the ones used in our MET system. A new additional data and receive different information. encryption technology called policy-based encryption proves to be quite useful within a health care environment for providing both The MET system is set up on a wireless network giving doctors encryption and access control. We propose an extension to an the ability to travel patient to patient while having full access to existing scheme which allows for the use of this cryptography in a the software. This system requires security and privacy hospital setting. technologies to prevent malicious users from having access to sensitive patient data. Patients’ EHRs are transmitted over a Categories and Terms: wireless network to these devices and then stored on the PC. D.4.6 [Operating Systems]: Security and protection Proper access control needs to be put in place to ensure only K.6.5 [Management of Computing and Information Systems]: Security authorized users can have access to records. We will discuss in and protection this paper the steps we have taken to ensure privacy of patient’s E.3 Data Encryption medical records. This project has greatly benefited from the input of a number of disciplines while working on the system. 1. INTRODUCTION Management, computer science, engineering and medical science Many hospitals are moving away from paper-based medical professionals have been working on this project together. Getting records to use electronic health care records. Specialized software opinions and ideas these diverse backgrounds has been a great and electronic diagnostic tools are offering a new level of patient opportunity. care. The move towards electronic based systems provides streamlined automated processes and specific applications that The goal of this paper is to present the technologies to be used can help doctors with diagnosis and treatment of patients. The with the MET project to add security and privacy functionality. introduction of these technologies raises privacy risks with We also discuss our motivations for adding security to this project regards to patient information. A malicious person trying to based on privacy laws in Canada. Different alternatives will be compromise many patient records will be able to collect large discussed for their advantages or disadvantages in this setting. amounts of data easily if these records are available electronically. One of the most promising technologies for use in a health care environment is policy-based cryptography for access control. We discuss this concept and propose an extension to an existing Permission to make digital or hard copies of all or part of this work for scheme to add more flexibility for use in our environment. personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, Organization of paper to republish, to post on servers or to redistribute to lists, requires prior We first talk about the current environment of the hospital setting specific permission and/or a fee. and what changes will happen with the introduction of electronic medical records. In section 3 we present our goals for securing IDtrust ’08, March 4-6, 2008 Gaithersburg, MD our system and providing privacy measures. Then we compare Copyright 2008 ACM 1978-1-60558-066-1…$5.00 access control and encryption methods available to satisfy these goals in section 4. We discuss a policy-based encryption scheme that works naturally in the health care setting. In section 5 we compare authentication mechanisms for use with our system. The Personal Health Information Protection Act (PHIPA) is Then we give some details of other security issues we faced and privacy legislation in the province of Ontario which builds on how we solved them in section 6. We give a brief overview of the PIPEDA[14]. system architecture and how each privacy module will interact within the MET system in section 7. We discuss related work in Principle 7 of PIPEDA describes the safeguards that should be in section 8 and conclude in section 9. place to protect sensitive data. Here we highlight the aspects that pertain to our project: 2. HOSPITAL ENVIRONMENT 1. Sensitive information should be protected with a The hospital environment is unique in both the fact that it contains higher level of security: Medical records are always such highly sensitive data and this data is required in emergency considered to contain highly sensitive data. For our situations. Emergency situations may overshadow the need for project we need to ensure that all patient data is secured privacy procedures. Doctor’s main functions are to treat patients, by the best available methods. The sensitive information not to follow complicated steps for accessing data. The workflow needs to be protected from unauthorized users during in the hospital must be taken into account when designing the both transmission and storage. system. Our goal should be to provide security for the MET software while minimizing tasks required by staff for using it. 2. Methods of protection should include technological methods such as the use of passwords and Our trial will run in a hospital that currently uses a paper based encryption: We should investigate different encryption system for medical records and is migrating towards electronic and authentication methods to find which would be records. The paper medical record consists of documents and most suitable for a health care environment such as the reports pertaining to one patient. It could include patient one for the MET project. The most secure password admission information, medical history, diagnosis reports, and lab scheme may be great for privacy but may not be reports from the current stay as well as previous hospital visits. feasible in a health care emergency environment. We Some parts of the medical record, such as lab reports which are need to find technological solutions that are practical. available in electronic form, are printed and stored in the medical record file. These paper based records are considered the real 3. Limit access to a ‘need to know’ basis: Access control authentic record even if the electronic form is still in existence. methods need to be used. We can limit access to individual documents of a medical record for both read The electronic system for accessing the available electronic and write permissions. Employee roles within the documents is currently a read-only system since reports are not hospital and permissions associated to those roles can modified electronically. Employees sign in with their username be used in determining a good access control model. and password to the software system on shared computers. The shared computers are in areas of high traffic and usually are 4. Both PHIPA and PIPEDA specify that medical records already logged in to a general account. Each staff member who should be protected from loss, theft, unauthorized wants to access software or records will sign in to that software access, disclosure, copying, use, or modification with their own information. Access rights are basic in that regardless of what format they are in. Electronic records everyone who uses the system can read all records. There are must be protected by access control and include an groupings of staff and these groupings determine read and write integrity mechanism. Furthermore, we must have an access rights to documents in medical records. When the hospital audit functionality to ensure that no malicious use of the moves to a full electronic system, these groupings will be defined system goes unnoticed. formally in policies. Currently staff members only have access to the network from inside the building, but are moving towards These privacy guidelines are not restricted to Canada. In the US, remote login. This will not be a part of our initial trial but may be title II of the Health Insurance Portability and Accountability Act something to consider for the long term. (HIPAA 1996) outlines standards for security and privacy of patient health records. They encourage the use of electronic data The procedure for obtaining a paper medical record is interchange in the health care system while protecting straightforward. A doctor can place a call to the records information. Physical and technical safeguards similar to the department requesting a document. Porters or other employees PIPEDA safeguards are outlined. Similarly in Europe they have will bring the requested documents to their department. Records the EU Data Protection Directive (1995). are assigned either to one doctor or one area of the hospital specifically, and are returned by the end of the day. If moved or Our goals for the MET project are to satisfy these privacy passed on, medical records should be notified to be able to track guidelines using the appropriate technology. We plan to use the documents. Generally if a medical record stays in one area of encryption to secure all data transmission and storage of patient the hospital is not necessary to notify them, since many doctors records. We want to enforce read and write access control not may see one patient during their time in that area. only for a medical record but for individual documents within that record. The security measures put in place should include end-to- end encryption of patient records, strong authentication, 3. PRIVACY GOALS authorization, data integrity, and audit logs. In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) describes guidelines for the protection Another privacy goal specified by the hospital staff is to make of personal electronic information[15]. PIPEDA provides sure none of these records leave the hospital premises. With the guidelines for handling personal information in electronic form. paper based system, paper records are not to be removed from the hospital. Because in our case the tablet PCs may leave the have to be reflected by changing the permissions for the affected hospital, we don’t want any records that are currently on the PC to roles. be able to leave with it. We will investigate the options we decided on for dealing with this privacy issue. Role Based Access Control will provide protection from unauthorized access. It would also allow us to limit information 4. ENCRYPTION AND ACCSS CONTROL disclosure to a strictly ‘need to know basis’. Coupled with Encryption is necessary in our system for protecting sensitive data network encryption this would cover most of our privacy goals. such as patient records. We want this data to be stored encrypted However this may be more work than we need to make our and transmitted encrypted so that no one sniffing the network can system secure as we will discuss next. get access to the data (particularly since a portion of the network is wireless). There are many options for securing data using 4.2 Encryption Only encryption such as network encryption using SSL and data It may be unnecessary to employ both encryption and access encryption using public key cryptography. We will discuss the control as separate technologies in our system. We present here options we considered as well as propose a policy-based options we considered that combine encryption and access control encryption solution. functionality. 4.1 Network Encryption & Access Control Traditional encryption methods such as public key cryptography In complying with PIPEDA we want to ensure all transmissions (PKC) are cumbersome to apply to access control. In a public key with sensitive data are encrypted. The Wired Equivalent Privacy system, each user is assigned a public key and private key. A (WEP) protocol is intended to provide confidentiality on wireless document is usually encrypted for a single recipient using their networks however many weaknesses have been found that could specific public key. Only the recipient can decrypt to recover the lead to a relatively easy attack[4]. It is not considered to be secure original document by using their private key. Managing keys in against any more than a casual eavesdropper. For our purposes we this system has often been a limiting factor in real world need more than this in order to comply with our first privacy goal applications. Keys need to be created and distributed to all users of protecting sensitive data with a high level of security. through the use of digital certificates. Users who leave the system or lose their keys need to have their certificate revoked. A Virtual Private Network (VPN) is another consideration for Certificates and keys have a finite lifetime and need to be securing our wireless network. IPSec and SSL can each be used to renewed. Old keys however still need to be kept in order to be implement a VPN. IPSec has been notoriously complex to able to decrypt documents that are encrypted under it for as long configure and manage and we will not consider it for this as the document’s lifetime. implementation[2]. SSL meanwhile has been used as a much easier alternative and has implementations that have proven to be secure. For our system, we need a way to encrypt medical records for access by multiple recipients, who are not necessarily known at SSL/TLS uses a handshake protocol to establish shared keys encryption time. PKI doesn’t offer this flexibility on its own; between a client and server. All communications between client intended recipients are known and their keys are used in the and server use the shared key to encrypt data. This creates an encryption process. If we wanted to use PKI, we would have to ‘encrypted channel’ between the client and server. SSL provides add access control methods to allow for managing multiple confidentiality and data integrity through cryptography. The recipients. We could then use roles to control access control and handshake protocol allows for authentication of the server, so the public keys to provide encryption when transmitting[19]. However client is assured of a secure connection with the proper server. this adds unnecessary complexity to the system. It would be easier OpenVPN uses SSL/TLS technology and has been shown to offer to encrypt all transmissions on the network and use traditional the SSL security properties of authentication, confidentiality, and access control methods. Thus PKI does not offer a feasible data integrity[10]. Client software for the VPN would be set up on solution for this case. all tablet PCs and server software on MET servers. Users accessing the network would do so by logging into the VPN 4.3 Identity/Role-Based Encryption software. Identity-based encryption (IBE) potentially offers more flexibility for our environment than PKI. The main idea behind identity- Encrypting all transmissions on the network will secure data from based encryption is that any string can be used as an encryption anyone who is not logged onto the network. It is still necessary to key[17]. For example, a person’s unique email address can be used. implement an access control system to manage permissions and A document can be encrypted with the recipient’s email address. access to patient data for employees who access the software. The recipient must identify themselves to a trusted authority to Role-Based Access Control (RBAC) allows for controlling which receive the decryption key to recover the original document. This users have access to which data on a network[6]. Users are is often how this scheme is described in order to compare it with assigned one or more roles and must authenticate to the system PKI in sending an encrypted document to a single known when requesting access to a resource. Each role has permissions recipient. IBE reduces the need for key management, as a user’s assigned to it, dictating which resources are available to that role. public key is a well known unique string such as their email We can express read or write access for documents based on the address. The private key is obtained by authenticating to a trusted roles of employees using an RBAC system. Policies would need authority (the Private Key Generator, PKG), and so the user to be created from the employee groupings and rules about which doesn’t need to keep keys. Managing user accounts becomes documents they should have access to. Changes in policies would easier. When a user leaves the system, they no longer have access to decrypt because they can’t log in to the system to authenticate finite number of document types in a hospital setting and the (e.g., because their password or account has been disabled). access rules for these document types. For example all x-ray lab reports are available to be read by doctors. Therefore these Advantages of this encryption scheme include users not having to documents can be encrypted under a policy specifically for that manage their own keys and no need for key certificates. From a type. This will also ensure that we have a finite number of policies usability point of view this is ideal. Doctors using our system to manage. won’t have to worry about details of encryption. When they need to access a document, they will simply identify themselves by If a policy is changed or updated, then all documents encrypted logging into the system. However, we will not be encrypting for under that policy will also have to be updated. This can be done one identity as mentioned earlier. For our application we need to automatically by decrypting and then encrypting under the new encrypt for multiple people. policy. It will not affect staff having access since they will receive the updated key when they try to get access. If they have a Using a more general approach, rather than encrypting on a document open already, then the update won’t affect them. If they unique string such as an email address, we can encrypt for a modify and save the document, it will be encrypted under the new general grouping such as a role. This allows for multiple people to available policy. In our system, the database will have access to get access if they belong to that role. But what if we want to decryption keys as well as policies to encrypt under. This will control access for multiple roles? For example a doctor and nurse allow for indexing of records which are stored encrypted under may have access to a patient’s record but not administrative the policies. Keys are not private to individual users but rather personnel. So we want to encrypt for doctors and nurses. Again keys are distributed based on user permissions. Thus, allowing the further generalizing this approach gives us a more flexible database to use these keys is not compromising individual users’ solution. Encrypting based on a policy can allow a document to be private keys. encrypted for access by multiple roles. In traditional PKI we have revocation of keys which allows for 4.4 Policy Based Encryption users to leave the system and to manage compromised keys. In A policy-based encryption scheme offers the greatest flexibility our system, we would have two scenarios that may require key for our security needs. The approach is relatively simple and revocation. If a staff member leaves or their role is changed, and builds on the idea of encrypting under an arbitrary string. A if a key is compromised. For the first scenario, if the user’s role is document is encrypted under a policy which is a combination of changed this will be reflected their account and they will receive rules. Note that in IBE, if the public key can be an arbitrary string, the corresponding decryption key from the PKG. If the staff then this string need not be an identity. Rather, the string may be a member no longer works at the hospital, their account will be complete access control policy (or a hash of that policy) for the disabled and they won’t be able to log in, and thus won’t be able document that is to be encrypted. A user wishing to have access to to have access to the system. Therefore, key revocation is not a document will authenticate by logging into the system and will needed for these types of changes to accounts. However we do obtain a decryption key associated with their role from the PKG. need revocation in the case of a key compromise. If the user’s role satisfies the requirements of the policy, their decryption key will decrypt the document. Boneh and Franklin propose adding a time period to keys in order to handle this situation[5]. Since the policies and keys used in our The policies can be as simple as combining a few roles or more system are strings, we can also associate them with a time period. complex to include other rules such as time constraints. In our Adding a time period to the policy can be done by simply adding implementation for the MET project, a small number of simple another constraint in conjunction with other rules. Decryption policies will be created. Groupings are clearly assigned in the keys generated during that time period will contain the proper workplace already so policies would be able to be created based time to fit the policy. Updating a policy’s time period will disable on this information. Each document type will have an associated keys which have been acquired and saved from previous access policy. An example policy could be “doctors or nurses can decryptions. Users who are using the system properly will be have read access for lab reports”. receiving the proper key each time they make a request to have access to a document and so will not need to keep track of Corresponding keys for the decryption process will be created updating keys. In the event of key compromise, updating the based on a user’s role. When a user logs in, a trusted authority policy (and updating records in batches) is sufficient to disable the (TA) will authenticate them and provide the decryption key key. associated with the user’s role. Then, when the user makes requests for records, if the user’s role fits the policy their Molva and Bagga propose a policy-based encryption system that decryption key will decrypt the document and they will have looks promising for use in the MET system[3]. In their encryption access. scheme a document is encrypted under a policy which is a combination of conditions or rules. Let’s consider an easy Keeping usability in mind, it would be favorable to automate the example of a policy that would be used in our system. An encryption process. Staff should not be asked to enter a policy or employee with the role of doctor or nurse can read a document. choose from a list of policies every time they create a new This policy pol will specify an action act of reading a resource res document. Because of the nature of the hospital setting, we can which is a document. In Molva and Bagga’s encryption system make policies dependant on the type of document. If a document the document would be encrypted under the following policy of a certain type is entered in the system, it will be encrypted based on a corresponding policy. This is possible because of the pol = OR Figure 1. Policy-Based Encryption application, we plan to have few rules combined in a very simple The document res will be encrypted using policy pol as follows manner. We will also have limited number of credentials for c = PolEnc(res, pol) users, as their roles will be the credentials and we have a limited number of actions possible. They also state ways of maximizing A user can decrypt c by providing their credentials cred = the efficiency of encrypting by pre-computing and caching some (alice:doctor) that satisfy the policy pol values. Decryption is more efficient than encryption in their res = PolDec(c, pol, cred) scheme and would cut down on the computation time in the overall system. See Figure 1 for a diagram demonstrating the encryption and decryption process. A brief description of the way their By extending their scheme to allow for more expressive policies, encryption works is that each set of conjunctions is assigned a we can adapt this system for use in our MET project. Using mask. Each disjunction is assigned a random key value. Then, simple policies that specify actions allowed on the document each key value is encrypted by each mask. A user who satisfies encrypted under that policy we strive to keep the encryption any of the sets of conjunctions will be able to retrieve each key process efficient. We also have minimal number of credentials for value, and decrypt the entire document. users based on their roles in the hospital. Finally, we can automate the encryption process by specifying policies for each document Their scheme works well for a policy that specifies one action for type, thus allowing staff members to enter documents in the a specific resource. In our case, we would need for the policy to system without worrying about encryption details. be applied to more than one action. For example if it is a doctor asking for access to a patient’s record then they can read and 4.5 Network Encryption & Access Control vs. write, but if it’s a nurse then they can only read. Molva and Bagga’s scheme allows for policies that are made of combinations Policy-Based Encryption of rules, but don’t include information about the action allowed on 4.5.1 Access Control with Network Encryption the resource for those who fit the policy. Access control and network encryption using a VPN plus a role- based access control mechanism would allow us to store the Therefore, we add expressive functionality to their system by records in readable format. This has the advantage that for storing allowing actions to be specified for each conjunction. Since the over long term, records won’t be made obsolete from out of date idea is to be able to encrypt under any arbitrary string, it seems encryption methods. However, this allows anyone who gets fairly reasonable to say that we can add this information to the physical access to the servers storing the records access to the policy to encrypt under. A policy could therefore be represented records in readable format. If they were encrypted then the as attacker would have no advantage by getting the encrypted format records. Encrypting the database separately requires an added pol2 = AND step, and each document would require decryption and re- Using default values for actions, all users would be able to encryption under SSL for transmission on the network. The perform these actions. However, a user would only be allowed to policy-based encryption would be a simpler solution for providing perform the action if they also satisfy the other rules in the complete encryption and access control at the same time. conjunction. In the example of pol2, upon presenting a credential for the role of a doctor, a user could decrypt and have write 4.5.2 Policy-Based Encryption access. The action rule will signify what permissions the user has The policy-based encryption method has the advantage that for that particular document. This will result in treating keys for encryption and access control are in one package. Not only would each credential in a different way, allowing default key values for it provide for encryption during transmission but also for storage. the actions. Records will be transmitted to the devices encrypted, and be decrypted once on the PC. This ensures all sensitive information The efficiency of the Molva and Bagga encryption system being transmitted is secure. The encryption scheme also allows us depends on the number of conditions that are combined to form to implement access control as only those who satisfy the policy the policy. The complexity increases with the number of can decrypt and have access to the record. There is no need for computations required to encrypt for each rule. For our users to manage their own keys nor is there need to distribute keys. There will be no difference for the user experience between 5.1 Fingerprint Biometrics the two choices. In either case, the user will log in and will have One of the most common biometrics in use for authentication is access to documents for which they have permission. the fingerprint. Using the fingerprint readers has an advantage that users don’t need to ‘remember’ to bring a token with them to A general disadvantage of any encryption scheme is the fact that work. However some usability problems may make this less the records are stored encrypted. The decryption keys must be desirable to use. In order to provide your fingerprint for kept for the lifetime of the record. The decryption algorithm must verification, a user must place their finger in a certain position. also be available to recover the original documents. In order to Factors such as placement, heat, cold, and perspiration can all ensure these are both available, it may be necessary to keep a affect how accurate the system is[11]. We want our users to be able backup of the keys and algorithm. Or it would be possible to store to log in every time because the setting is the emergency room of the records in readable format somewhere physically secure and a real hospital. not connected to a network. We would need to store backup copies of the records in plaintext regardless of which system we Another factor with fingerprint biometrics is that not everyone can use, due to possibilities of hardware failure. give the fingerprint to enroll. Fingerprints damaged by injuries could be a problem. We want to make sure everyone can use the Overall, the policy-based encryption method provides the most system, including current employees and future employees. In the compliance with PIPEDA regulations with the least amount of healthcare setting many employees may be wearing hygienic complexity. We get a high level of security for the sensitive data. gloves which would not allow them to use the fingerprint reader The data is protected by encryption while stored and transmitted without first removing them. This is a real usability problem in protecting it from malicious people who may be eavesdropping. our setting. When discussing the fingerprint option with doctors The records are also protected from unauthorized access as only who will be using the system, they seemed reluctant to use users of the system with the proper account permissions set up are fingerprints in the authentication stage and wanted something given a decryption key. We have limited the access on a ‘need to easier. know’ basis by forming policies constraining access to documents based on roles. The users of the system will not have to know about the security technologies used and their only security task 5.2 RFID Reader will be to log in as they already do on other hospital computer The RFID reader offers an alternative to the fingerprint reader. systems. Doctors carry employee badges which can be equipped with a barcode. To sign in a doctor swipes their card (or, if it is a proximity reader, simply has their badge somewhere on their 5. AUTHENTICATION person) and provides their login password. Everyone can be given The security of the encryption system relies on strong a badge and it will always be accepted. They don’t have to have a authentication. The system is only as secure as its ability to high entropy password which may be hard to remember. They prevent unauthorized access. Currently in the hospital, the may be less likely to simply tell someone their password to let standard username and password method is used without any them have access, since they would also have to provide their restrictions on password choice. We wanted to explore card. However this option is still available if the doctor wishes to authentication options that would be both secure and usable so as delegate his tasks to another employee for a period of time. This not to change the user experience too much. provides for a flexible authentication system compared to using a fingerprint which cannot be delegated. We decided to go ahead The username and password combination is the most popular with using the doctor’s badges and the RFID reader as the second authentication method. There are many reasons why this is not a factor in our authentication system. secure method[1]. Users will choose very easy to remember passwords that are also easy to break. If we imposed restrictions Unlike the fingerprint method, a doctor can forget their employee on the password choice to force users to have stronger passwords, badge. If they borrow someone else’s pass or get a temporary one, they would do what they could to make logging in easier, by this will not work with the reader since it will be a different pass. writing them down for instance. We have already had feedback We could manage to have temporary badges available for the day from doctors who would not be happy having password which can be associated with their account. One way around this restrictions being put in place and encouraged us to look at other is to use a common backup method of asking the user a series of options. Passwords are subject to social engineering attacks which pre-answered questions. If the user answers correctly and provides could be easy to manipulate in an emergency setting. If a their usual login information along with it, then the user can log in malicious person claims there’s an emergency and asks for a staff for the day. Proper tracking of these events is important for being member’s password, they may be more likely to divulge able to notice and document malicious behavior. information. A two-factor authentication would be desirable to provide 6. OTHER PRIVACY CONCERNS improved security. Our motivation for finding a proper two-factor There are other security and privacy issues that we wanted to authentication mechanism lies in working with what we have. address for our MET project. The specific security needs arise One factor will be the username and password system without because of the environment and physical location of the project. restrictions on the password. The second factor could be a Some security measures we will include in our system are audit biometric fingerprint or RFID tag. The tablet PC is equipped with logs, integrity mechanisms, and automatic purging of sensitive both a fingerprint reader and RFID reader. We discuss both and files. what we chose for the second factor in our authentication scheme. 6.1 Audit Logs files being purged when the PC is turned off or rebooted. The An important privacy requirement and a feature our system must connection to the wireless network can be used as an event trigger ultimately include is an audit log. Audit logs allow for tracking to purge all files. When the tablet PC is taken out of range and no user’s activity on the system. If by any chance someone is longer has a connection with the network, the patient data files misusing the system, then a record of that activity must be will be erased. A doctor who is in the wireless network area doing available. For example if a doctor is accessing large amounts of his work will not lose any data. It would only affect tablet PCs patient records that clearly aren’t all their patients, this would be that are taken far enough away from the hospital department with worth investigating. It could be that a malicious user has gotten the network connection available. access to that account and is stealing patient information. It would be a good addition to our system to add logging functionality of 7. SYSTEM ARCHITECTURE all access and changes to patient records. Specifically we want to The tablet PCs being used in the trial are the Motion Computing track when a user logs on and off, which records they request, and C5 models[13]. The PCs are equipped with a fingerprint reader and which records they make changes to. RFID scanner. The devices will ensure that doctors are able to travel patient to patient while having access to the information 6.2 Integrity Mechanisms they need on the wireless network. Another privacy aspect is not only protecting the data from unauthorized access but also from unauthorized modification. The MET software and privacy functionality will be implemented Ensuring proper access control for read/write permissions is in Java using the JADE development environment. The system is essential. However we also want to include some sort of integrity agent-based with multiple agents each assigned a specific task in mechanism to be able to check that no changes have been done the software. A central temporary storage area, called a maliciously. For example if someone changes a record stored in blackboard, will be used to store patient records and medical the database we need to be able to check this. information that agents are using. Adding an encryption agent seemed reasonable but has not become a practical solution. All A Message Authentication Code (MAC) applied to a record agents will need access to encryption services for pulling and would provide us with a way of checking for any changes pushing information to and from the databases, the blackboard, made[8].We could do this on an individual record basis, creating a and the tablet PC. Multiple encryption agents would be needed for MAC of the entire record, storing the MAC value elsewhere on the servers, the tablet PC, and the databases. Integrating the the system, and comparing the stored MAC with a freshly- security functions as a layer, or set of services, available to all computed MAC for every record read event. agents in the system proved a better solution. The MET architecture is reflected in figure 2 below. The security and encryption services layer will provide encryption, decryption, 6.3 Purging Files authentication, and account management services. In addition, a Consider the scenario where a doctor has their tablet PC which monitoring agent on the tablet PC will be necessary to track when they bring home everyday. At the end of their shift, they may to purge the files in the event of a disconnection from the network have seen a number of patients and have their data saved on the or system reboot. PC. The doctor goes home and someone in their household uses the PC for other purposes. It could be connected to the Internet at this point and anyone with access to the PC could have access to 8. RELATED WORK the sensitive records. 8.1 Encryption and Access Control Role-based access control systems using public key cryptography We need a system of preventing records from leaving the hospital have been proposed. Wilkinson, Hearn, and Wiseman describe an which is facilitated by the use of the tablet PCs. A doctor may not access control system that uses encryption to control access to notice or remember that he still has files on his PC when leaving documents[19]. Documents are encrypted under a group’s public the hospital. It’s much more obvious with paper-based records, key, and members of that group can decrypt with the group public where a doctor has to actually carry them out or knowingly put key. They also describe how symmetric keys could be used as the them in a bag. If it becomes a habit of taking the tablet PC home, group keys, however they conclude that asymmetric cryptography then the doctor may not remember to erase patient data each time. will provide better protection from key compromise at proxies. This means we need to know when a tablet PC is being taken out While the scheme does provide security measures that we are of the hospital so that we can erase those files that haven’t been looking for, it still suffers from the key management issues of deleted. public key cryptography schemes. It also doesn’t seem straightforward how to encrypt a document for multiple groups or One simple thing to do is to purge all files on shutdown. However multiple roles. sometimes PCs are not shut down properly especially in the case of a tablet PC which may lose battery power. Therefore it would Kapadia, Tsang and Smith propose an attribute-based encryption be better to implement on system startup. Each time the laptop is system that allows for role based access control[9]. Their system booted, the files are purged. Since doctors wouldn’t be turning it relies on hidden credentials and policies. In our case, the policies off and on all day, they shouldn’t lose any records until they are will most likely be public since there are a finite set of policies done their work. We don’t need to implement this on hibernate created based on well-known rules. It would be better to have a states, so that if a doctor leaves his PC for a while with no activity system that doesn’t rely on having secret policies. Other attribute- then he’ll still have the information he needs on it. based encryption schemes aren’t as efficient as the Molva and If a tablet PC leaves the hospital while still turned on, we still Bagga scheme discussed next[7]. need to purge the files. In this case we can’t rely simply on the Figure 2. MET Architecture Most policy-based encryption schemes that have been proposed 9. CONCLUSION & FUTURE WORK are based on the Boneh-Franklin ID-based encryption scheme We presented alternative security and privacy technologies using bilinear pairings over elliptic curves[5]. Smart proposed a considered for use in our system architecture for an e-hospital scheme extending this for encrypting on multiple identities[18]. environment. The motivation for the inclusion of high security Molva and Bagga further extend their work to propose a policy- technologies comes from the requirements by privacy legislations based cryptography scheme including an encryption scheme and PIPEDA and PHIPA. Our system therefore includes encryption signature scheme[3]. They propose using a policy as a public key for data confidentiality, integrity mechanisms, authentication, to encrypt a document. A user obtains their decryption key based authorization, and audit logs. An additional security measure put on their credentials and can decrypt if these credentials satisfy the in place for our project also involves automatic deletion of policy rules. As mentioned earlier their scheme is a good basis for sensitive data when tablet PCs are taken out of the hospital area. us to extend our work on. Our main contribution is the use of a policy-based encryption 8.2 Examples of Privacy Technologies Used in scheme in providing data encryption and access control. We propose extending Molva and Bagga’s work to suit a health care Health Care Environments environment for access control with a patient’s records database. Voltage is great example of a company using the technologies Policy-based cryptography looks promising for use in different discussed here for security and privacy solutions in health care settings. The uses of this type of system could span many environments. They offer an identity-based encryption for email environments including corporate settings and email systems. The messaging that is currently being used in hospitals in the United usefulness in creating keys based on roles and the simplicity of States[20]. Similarly, Secure Computing offers policy-based key management give policy-based encryption many advantages cryptography products. They implemented a token based over current encryption schemes. authentication system with audit logs to ensure HIPAA compliance for a system in a hospital[16]. 10. REFERENCES Mont, Bramhall, and Harisson from the Hewlett Packard Lab in [1] A Adams, M Sasse, “Users are not the enemy”, In Bristol, UK have developed a messaging service using identity- Communications of the ACM, pp 40-46, 1999 based cryptography for a hospital[12]. Their scheme uses the fact [2] Array Networks Inc. SSL VPN vs IPSec VPN, Jan. 2003. that any string can be used to encrypt on including a role. When a white paper. user wants to send a message they choose a role to encrypt it under, and recipients of the message can decrypt if they belong to [3] W Bagga and R Molva, “Policy-Based Cryptography and Applications”, In Lecture Notes in Computer Science, pp. that role. Anyone who doesn’t belong to the role cannot see the 72-87, Springer Berlin / Heidelberg, 2005. message. This provides a secure email system for use within the hospital. [4] A Bittau, M Handley, J Lackey, “The Final Nail in WEP’s Coffin”, The 2006 IEEE Symposium on Security and Privacy SP, pp. 386-400, 2006. [5] D Boneh and M Franklin, “Identity-Based Encryption from IBE Technology in a Health Care Trial”, Hewlett-Packard the Weil Pairing”, In Proceedings of CRYPTO 2001, pages Laboratories, technical report HPL-2003-21, 2003. 213-229, Springer-Verlag, 2001. [13] Motion Computing, “Motion C5”, 2007, [6] D Ferraiolo, J Cugini, R Kuhn, “Role-based access control http://www.motioncomputing.com/ (RBAC): Features and motivations”, In Proceedings of the [14] Personal Health Information Protection Act (PHIPA 2004) 11th Annual Conference on Computer Security http://www.health.gov.on.ca/english/public/legislation/bill Applications, pp 241–248, 1995. _31/personal_info.html [7] J Holt, R Bradshaw, KE Seamons, and H Orman, “Hidden [15] Personal Information Protection and Electronic Documents credentials”, In Proceedings of the 2003 ACM Workshop Act (PIPEDA 2000) on Privacy in the Electronic Society, ACM Press, 2003. http://www.privcom.gc.ca/legislation/02_06_01_01_e.asp [8] RR Jueneman, SM Matyas, CH Meyer, “Message [16] Secure Computing, 2007, Authentication”, IEEE Communications Magazine, pp 29- http://www.securecomputing.com/ 40, 1985. [17] Shamir, “Identity-based cryptosystems and signature [9] A Kapadia, P Tsang, SW Smith. "Attribute-Based schemes”, In Proceedings of CRYPTO 84 on Advances in Publishing with Hidden Credentials and Hidden Policies." cryptology, pp. 47-53. Springer-Verlag New York, Inc., In 14th Annual Network and Distributed System Security 1985. Symposium (NDSS '07), pp. 179-192, 2007. [18] N Smart. “Access control using pairing based [10] S Khanvilkar, A Khokhar, “Virtual Private Networks: An cryptography”, In Proceedings CT-RSA 2003, pp 111–121. Overview with Performance Evaluation”, IEEE Springer-Verlag LNCS 2612, April 2003. Communications Magazine, pp 146-154, October 2004. [19] T Wilkinson, D Hearn, and S Wiseman, “Trustworthy [11] G Lassmann, “Some results on robustness, security and access control with untrustworthy web servers”, In usability of biometric systems”, In Proceedings of the Proceedings of the 15th Annual Computer Security 2002 IEEE International Conference on Multimedia and Applications Conference, pp 12. IEEE Computer Society, Expo ICME ’02, pp 577-579, 2002 1999. [12] MC Mont, P Bramhall, CR Dalton, and K Harrison, “A [20] Voltage, http://www.voltage.com Flexible Role-based Secure Messaging Service: Exploiting Security and Privacy System Architecture for an e-Hospital Environment Kathryn Garson, Carlisle Adams University of Ottawa Agenda „ Introduction „ Hospital Environment „ Privacy Goals „ Encryption and Access Control „ Authentication „ Other Privacy Concerns „ System Architecture „ Conclusion 1 Introduction „ Mobile Emergency Triage (MET) project ‰ Software provides doctors with interactive decision support for triage and treatment of patients ‰ To be used as a trial in Ottawa hospital ‰ Wireless network allowing physicians to travel patient to patient with tablet PC ‰ MET software pulls patient records from database ‰ Sensitive data transmitted over wireless network, stored on servers and tablet PC „ Need access control and encryption to protect sensitive information Hospital Environment „ Highly sensitive data required in emergency situations ‰ Cannot have security measures get in the way of physician’s access to information „ Patient records currently paper moving towards electronic ‰ Each record consists of multiple documents ‰ All will be available in electronic form 2 Hospital Environment „ Current system in emergency department is read-only ‰ Employees sign in with username and password (no restrictions) ‰ High-traffic areas ‰ Access depends on employee role and associated permissions ‰ Only access from within hospital, remote log-in will not be a part of our trial Privacy Goals „ Personal Information Protection and Electronic Documents Act (PIPEDA – Canada) „ Personal Health Information Protection Act (PHIPA – Ontario) ‰ Extends PIPEDA „ Principle 7 of PIPEDA specifies safeguards to be used to protect sensitive data 3 Privacy Goals „ Sensitive information should be protected by high level of security „ Include technological methods such as passwords and encryption „ Limit access on a ‘need to know’ basis „ Medical records should be protected from loss, theft, unauthorized access, disclosure, copying, use, or modification Privacy Goals „ United States ‰ Title II of Health Insurance Portability and Accountability Act (HIPAA) has similar privacy standards „ Europe ‰ EU Data Protection Directive „ Our goal is to satisfy these privacy guidelines ‰ Provide encryption and access control ‰ Use appropriate authentication method ‰ Additional privacy need: automatic deletion of records 4 Encryption and Access Control „ Network Encryption and Access Control „ Encryption Only „ Identity-Based Encryption „ Role-based Encryption „ Policy-Based Encryption Network Encryption and Access Control „ Wired Equivalency Privacy (WEP) Protocol not considered secure „ Virtual Private Network (VPN) using SSL ‰ All communications between client and server are encrypted using a shared key ‰ OpenVPN uses SSL technology and provides authentication, confidentiality, and data integrity ‰ Physician’s device and MET servers will have VPN software 5 Network Encryption and Access Control „ Still need access control to manage access within network „ Role-Based Access Control (RBAC) systems work well in hospital environment ‰ Permissions already based on employee role ‰ Authenticate to system when asking for resources „ RBAC and VPN will provide security we need Encryption Only „ May be unnecessary to separate access control and encryption „ Traditional Public Key Cryptography ‰ Each user has a private and public key ‰ Keys managed by use of certificates ‰ Encryptions are done for a particular user ‰ Problems: cumbersome management of keys, cannot encrypt easily for multiple recipients ‰ Would need to add access control methods to organize encryptions based on roles 6 Identity-Based Encryption „ In Identity-based encryption, any string can be used as the public key ‰ E.g. email address ‰ Recipient authenticates to a trusted authority and receives the corresponding private key „ Users don’t need to manage their own keys ‰ Public key is well-known and unique to that person, no certificate necessary ‰ Private key is generated when user authenticates themselves „ However, we still need to figure out how to encrypt for multiple recipients based on role Role-Based Encryption „ Using a more general approach, encryption can be done on a role ‰ Since any arbitrary string can be used as public key, can use a string such as “doctor” ‰ Allows to encrypt a document with access control rules „ However, we need to be able to express more complex rules ‰ E.g. “a doctor or nurse can have read access” 7 Policy-Based Encryption „ Document is encrypted under a policy, which is a combination of rules ‰ Can be simple policies such as “ OR „ User wishing to decrypt ‰ Authenticates to a Trusted Authority ‰ Receives a private key based on their role containing credentials ‰ If their credentials satisfy policy rules, their key can decrypt document Policy-Based Encryption „ Automated encryption process ‰ Physicians and staff will not have to manage private keys ‰ Authentication process allows to decrypt ‰ Policies can be specified by document type ‰ Staff entering/saving documents will not have to select which policy to encrypt under 8 Policy-Based Encryption „ Encryption system by Molva & Bagga „ Consider a policy stating “an employee with the role of doctor or nurse can read a document” pol = OR act = read doc = document „ The document is encrypted temp = PolEnc(doc, pol) „ A person can decrypt if their credentials satisfy the policy cred = (alice:doctor) doc = PolDec(temp, pol, cred) Policy-Based Encryption 9 Policy-Based Encryption „ Encryption in their system ‰ Each conjunction is assigned a mask ‰ Each disjunction is assigned a key ‰ Each key is encrypted by each mask ‰ User who satisfies one conjunction will be able to decrypt „ Our goal is to extend their work ‰ Want to include multiple actions ‰ Want to add key revocation Policy-Based Encryption „ Multiple actions ‰ What if a doctor is allowed to modify a document, while a nurse can only read ‰ Keep track of which conjunction in policy was satisfied „ E.g. AND ‰ Trap call to OS, if write action requested, and conjunction with was satisfied, open document in write mode „ Policies can contain action elements ‰ Corresponding keys will contain requested action as well 10 Policy-Based Encryption „ Key revocation ‰ What if an ex-employee kept the decryption key, need to change key in current use ‰ Add a time period to policy ‰ Can only decrypt if decryption key was generated/retrieved during that time period „ Example pol = AND<01/25/2008-02/25/2008, time> Policy-Based Encryption „ Updates to policies and keys should not interrupt system usage ‰ Can update documents in batches ‰ Any document currently opened will be saved encrypted under new policy ‰ Any person wishing to decrypt a document under new policy will be issued a corresponding updated key ‰ Anyone who saved old keys will not be able to decrypt new documents 11 Policy-Based Encryption „ Provides both encryption and access control ‰ Documents are encrypted for storage and all transmissions ‰ Policy determines who can decrypt to have access „ Policy can be based on document type ‰ Allows for small number of policies to manage ‰ Allows for encryption to be done automatically „ Small number of decryption keys based on roles Authentication „ Security of encryption system relies on strong authentication „ Username and password most common ‰ Users choose weak passwords ‰ Imposing restrictions makes it hard to remember „ Two-factor authentication ‰ Provides better security ‰ Staff won’t have to remember hard passwords 12 Authentication „ Fingerprint Biometrics ‰ Tablet PC to be used in trial has fingerprint reader ‰ Some problems, including doctors wearing gloves ‰ After discussing with doctors, agreed this was not an option „ RFID Reader ‰ Employee badges have a barcode ‰ Can scan badge barcode ‰ Second-factor of ‘something you have’ ‰ Need to include a backup method for when someone forgets their badge for the day Other Privacy Concerns „ Audit logs ‰ Track user activity on system ‰ Log on/off, records requested, records modified „ Integrity mechanisms ‰ Protect data from unauthorized modification ‰ Message Authentication Code (MAC) to be able to verify integrity of records „ Automatic deletion of files ‰ Preventing records from leaving hospital ‰ Security measure asked for by hospital staff 13 System Architecture „ MET system is multi-agent ‰ Information agents, task agents, interface agents „ Blackboard central temporary storage area ‰ Agents pull/push information from/to the blackboard „ Integrating security functionality ‰ As encryption agents „ Problem in organizing agents in this way, encryption and decryption agents needed at blackboard, databases, and tablet PC, will be accessed by all agents ‰ Security as a set of services „ All agents have access to set of encryption services System Architecture 14 Conclusion „ Policy-based encryption ‰ Extensions to existing system „ Authentication mechanisms ‰ Employee badge with a barcode „ Additional security needs ‰ Audit logs, integrity mechanisms, deletion of files „ Integrating security into multi-agent system Questions 15 Systems Engineering View of Privacy David Weitzel, M.S., J.D. © 2007 The MITRE Corporation. All rights reserved Statutory Foundations  Privacy Act of 1974 – System of Records Notices (SoRN)  E-Government Act of 2002 – Privacy Impact Assessments (PIAs)  Freedom of Information Act (FOIA) – FOIA requests  Homeland Security Act – Statutorily Mandated Privacy Officer  Paperwork Reduction Act – OMB Form Control Numbers  Federal Information Security Management Act – FISMA Certification & Accreditation & POAMs  National Archives, 44 USC 21 et. seq. – Records retention & disposal 2 © 2007 The MITRE Corporation. All rights reserved Fair Information Practices  Collection limitation  Notice  Choice  Data quality  Finality / use limitation  Security  Accountability 3 © 2007 The MITRE Corporation. All rights reserved Privacy is a Systems Problem Intersection of Privacy and Technology Collection • RFID and biometrics • Assured deletion—especially across the enterprise—of personal information Processing Destruction • Integrity and hygiene of consolidated and aggregated personal information • De-identification of personal information Disclosure Use • Data flow mapping • Security controls to enable appropriate and prevent inappropriate cross- boundary sharing of Retention • Detection and personal information prevention of attempts at incompatible secondary use • Privacy enterprise architecture • Privacy system requirements for system development life cycle (SDLC) • Tools to support analytical aspects of Privacy Impact Assessment • Privacy risk modeling • Privacy policy automation and enforcement 4 © 2007 The MITRE Corporation. All rights reserved Build It In – Create Virtuous Cycles  Architecture IS policy – Lessig – Code  Feedback and control via budget & governance processes – OMB 300s – FISMA inventory, C&A, POAMs – PIAs & SORNs – OMB Form Control Numbers – NARA Records Retention Schedules  Unless privacy, information security, and other policy control points are built into the architecture of systems, the chance for appropriate control points to be added later, is, harder, more costly, less effective 5 © 2007 The MITRE Corporation. All rights reserved A Privacy Approach Privacy Systems Engineering  A repeatable, scalable systems engineering-based approach to uncovering, understanding, and addressing privacy issues – Explicitly considers multi-dimensional context as well as technology – Uses risk management to minimize unintended consequences Work Stakeholder Processes Interests – Aligns privacy Culture of Data Legal solutions with Sharing Organizatio Compliance mission requirements n Ethics and Mission Social Norms Policy Security … Compliance Change Maintenanc Budget Managemen e t Model System Privacy Integration Program 6 © 2007 The MITRE Corporation. All rights reserved Privacy Systems Engineering (1 of 2) Analyzing Privacy in a System Context • Relatively narrow scope, i.e., a specific technology, issue, practice, or policy • Can be used to evaluate privacy enhancing technologies (PETs) Privacy Risk • Underlying risk model well-defined: potential violations of privacy principles or Assessment mandates • Development and use of technology testbeds when appropriate • Can be used as formal input to Privacy Impact Assessment • Moderate scope, i.e., a system or business process • Design alternatives explicitly considered within the context of the system or business process Privacy Impact • Expanded risk model Broadening Assessment Context – Risks related to information life cycle – Systematic analysis of data flows • Can be used as formal input to Privacy-Based Systems Analysis • Broad scope, i.e., mission or program • Focuses on interaction and integration of technology, processes, and people • Surfaces unintentional consequences of adopting particular approaches and solutions Privacy-Based • System alternatives explicitly considered and evaluated within the context of the Systems mission or program Analysis – Includes high-level policy and social dimensions – Includes potential application of PETs • Expansive risk model, less well-defined 7 © 2007 The MITRE Corporation. All rights reserved Privacy Systems Engineering (2 of 2) Developing Privacy in a System Context: Model Privacy Program Foundational Privacy Fundamental tenets that guide a privacy program Principles Analytical Tools Organization People and processes responsible for assessing privacy risks and for Redress & Response developing and implementing plans to manage those risks effectively Monitoring & Compliance Policy Privacy rules of behavior and ways to adhere to them Awareness & Training Systems Administrative, physical, and technical safeguards Systems Development & Development Security that control privacy risks & Security Programs to make the organization, its Policy Awareness & vendors, and the public aware of the Training organization’s privacy posture and practices Organization Monitoring & Programs to monitor adherence to privacy Compliance rules of behavior Redress & Systems and processes to respond if Response needed to privacy issues and incidents Foundational Analytical Principles Tools to support privacy risk management Tools 8 © 2007 The MITRE Corporation. All rights reserved Safeguarding Digital Identity Bruce J. Bakis, The MITRE Corporation http://www.thei3p.org Supported by DHS and NIST 1 Approved for Public Release; Distribution Unlimited (MITRE Case Number: 08-0090). © 2008 The MITRE Corporation. All rights reserved Approved for Public Release; Distribution Unlimited (MITRE Case Number: 08-0090). © 2008 The MITRE Corporation. All rights reserved Background and Context • MITRE is leading a 2-year privacy-preserving Identity Management (IdM) research activity: Cornell, Georgia Tech, Purdue, SRI International, University of Illinois • Supported by the National Institute of Standards and Technology and the Department of Homeland Security • Managed by Dartmouth College’s I3P – www.thei3p.org – IdM: http://www.thei3p.org/projects/idmgmtoverview.html 2 Approved for Public Release; Distribution Unlimited (MITRE Case Number: 08-0090). © 2008 The MITRE Corporation. All rights reserved Contacts • The MITRE Corporation – Bruce Bakis, 781.271.6915, bbakis@mitre.org – www.mitre.org • The I3P – Eric Goetz, 914.954.2466, eric.d.goetz@dartmouth.edu – Charles C. Palmer, 914.954.2466, charles.c.palmer@dartmouth.edu – www.thei3p.org 3 Approved for Public Release; Distribution Unlimited (MITRE Case Number: 08-0090). © 2008 The MITRE Corporation. All rights reserved What’s new with XML Signature Frederick Hirsch 4 March 2008 Frederick Hirsch, Nokia. March 2008 XML Signature • W3C Recommendation February 2002 • Enables representation of Signature and meta data in XML • Designed to enable flexible signing of XML content • May also sign binary and non-XML content • Flexible • Signatures over content in same XML document, or other content • Inclusion of signature within XML content or separate • Transforms of content before hashing to sign • Choice of KeyInfo mechanisms, choice of algorithms • Signature properties Frederick Hirsch, Nokia. March 2008 Canonicalization 1.1 • XML Canonicalization 1.0 • W3C Recommendation 15 March 2001 • Required algorithm for XML Signature inclusive canonicalization • Exclusive XML Canonicalization • W3C Recommendation July 2002 • Support canonicalization of portions for XML document, excluding inheritance of attributes from ancestors XML elements not in the subset. • XML Canonicalization 1.1 • W3C Proposed Recommendation, January 2008 • Update to enable use of additional attributes in XML namespace with different inheritance properties, including xml:id and xml:base • Some additional clarifications Frederick Hirsch, Nokia. March 2008 XML Signature, 2nd Edition 1. Require support for Canonicalization 1.1 algorithm, recommend its use for inclusive canonicalization. 2. Incorporate document errata 3. Provide clarifications, but no conformance affecting changes (other than #1) Frederick Hirsch, Nokia. March 2008 XML Signature, 2nd Edition Status • In process to become a W3C recommendation. • Will also undergo IETF review in order to produce update to RFC 3275. • Working group has produced a draft intended to become a W3C Proposed Edited Recommendation Frederick Hirsch, Nokia. March 2008 XML Security Specifications Maintenance WG • Chartered in 2007, operating in early 2008. • Chair - Frederick Hirsch. • W3C Team - Thomas Roessler • Producing XML Signature, 2nd Edition • Interop tested C14N11 and XML Signature • Held public workshop regarding future directions. • http://www.w3.org/2007/xmlsec/ws/report.html • Provided input to W3C team for charter for possible subsequent working group. Frederick Hirsch, Nokia. March 2008 Possible Future Work • Requirements for XML Signature canonicalization, reference and transform processing, algorithms, performance and XML environment. • Specifications for Canonicalization and XML Signature. • Algorithms for XML Encryption • Maintenance of some other XML Security specifications. Frederick Hirsch, Nokia. March 2008 Tim van der Horst and Kent Seamons Internet Security Research Lab ISRL Brigham Young University Internet Security Research Lab http://isrl.cs.byu.edu  Problem  Users have too many passwords  Difficult to share data with outsiders  Project Goals – Convenience and Security  Remove the need for site specific passwords  Simple for users to understand and use  Existing identifiers (email, IM, text messaging)  Easy for administrators to deploy and manage  Our Approach  Leverage forgotten password approach  Make it easier and more secure  SAW (Simple Authentication for the Web) User Web Site I’m Alice  Step 1:  The user submits her email address  Step 2:  If her address is authorized, a random secret is generated and split into two shares Tokens are:  Step 3: • Short-lived • Single-use From:  The user SAW_TokenGenerator@securecomm.org returns both tokens To: student@some.edu  Manually: Subject: [SAW-https://securecomm.org/login] ATemail=2fe32... By clicking a link in the email  Automatically: Click on the link below ONLY if you recently initiated a Using the SAW request to log toolbar in to https://securecomm.org/login: https://securecomm.org/login?ATemail=2fe322492847eb5dea... User’s Email Provider It is difficult to provision guest access to access- restricted wireless networks Current wireless authentication schemes  Global passphrases 1. Too inflexible  Username/password 2. Too  User-specific digital certificates heavyweight Goals  Bring lightweight decentralized authentication to the wireless realm Users can authenticate to relying parties with whom they have no pre-established relationship  Be highly portable Users authenticate via passwords not cryptographic keys  Provide strong protections to user login credentials Relying parties or eavesdroppers never learn the user’s password A. Harding, T. W. van der Horst, and K. E. Seamons. Wireless Authentication using Remote Passwords. 1st ACM Conference on Wireless Network Security (WiSec), Alexandria, VA, March 2008.  How do users authenticate to identity providers when they cannot directly communicate?  Giving relying parties the plaintext password is not desirable  Allowing an encrypted tunnel invites misuse and requires IP-level connectivity  Forwarding several small messages of known composition offers a good compromise  How do identity providers inform relying parties that users have successfully authenticated?  A message sent to•Secure, mutual that effect authentication by the over could be identity provider forged/destroyed and potentially an insecure enables user impersonation channel  Token-based approach User (U) Wireless Access Point (RP) Identity Provider (IDP) Msg ID: Alice ID: Alice PW: LuckyDuck User (U) Wireless Access Point (RP) Identity Provider (IDP) I’m Alice` Secure Remote Password (SRP) 1. Use SRP to establish a mutually authenticated session key between user and her identity provider 2. Use that key to facilitate a SAW token distribution Create a generic protocol that supports web site login and wireless access  Surrogate SRP (sSRP)  Mode 1 No PKI! No passive attacks, Limits active attacks  Model 2 RP and IDP have SSL server certificates No client certificate Prototypes built for wireless access and web site login Usability studies being planned XACML – The Standard Hal Lockhart, BEA Systems What is XACML?  XML language for access control  Coarse or fine-grained  Extremely powerful evaluation logic  Ability to use any available information  Superset of Permissions, ACLs, RBAC, etc  Scales from PDA to Internet  Federated policy administration  OASIS and ITU-T Standard Trends Driving Fine-Grained Access Control  De-perimeterization  No longer just “them and us”  Firewall is no longer sufficient  Service Oriented Architecture  Multiple access contexts for each service  Software as a Service (looking forward)  Complex interactions of internal and external components OASIS XACML History  First Meeting – 21 May 2001  Requirements from: Healthcare, DRM, Registry, Financial, Online Web, XML Docs, Fed Gov, Workflow, Java, Policy Analysis, WebDAV  XACML 1.0 - OASIS Standard – 6 February 2003  XACML 1.1 – Committee Specification – 7 August 2003  XACML 2.0 – OASIS Standard – 1 February 2005  XACML 2.0 – ITU/T Recommendation X.1142 Powerful Policy Expression  “Anyone can use web servers with the ‘spare’ property between 12:00 AM and 4:00 AM”  “Salespeople can create orders, but if the total cost is greater that $1M, a supervisor must approve”  “Anyone view their own 401K information, but nobody else’s”  “The print formatting service can access printers and temporary storage on behalf of any user with the print attribute”  “The primary physician can have any of her patients’ medical records sent to a specialist in the same practice.” Key XACML Features  Federated Policy Administration  Multiple policies applicable to same situation  Combining rules to resolve conflicts  Decision may include Obligations  In addition to Permit or Deny  Obligation can specify present or future action  Examples: Log request, require human approval, delete data after 30 days  Protect any resource  Web Server, Java or C++ Object, Room in building, Network Access, Web Service, Geographic Data, Health Records, etc. Novel XACML Characteristics  Large Scale Environment  Subjects, Resources, Attributes, etc. not necessarily exist or be known at Policy Creation time  Multiple Administrators - potentially conflicting policy results  Combining algorithms  Request centric  Use any information available at access request time  Zero, one or more Subjects  No invented concepts (privilege, role, etc.)  Dynamically bound to request  Not limited to Resource binding  Only tell what policies apply in context of Request  Two stage evaluation XACML Concepts  Request and Response Contexts – Input and Output  Policy & PolicySet – combining of applicable policies using CombiningAlgorithm  Target – Rapidly index to find applicable Policies or Rules  Conditions – Complex boolean expression with many operands, arithmetic & string functions  Effect – “Permit” or “Deny”  Obligations – Other required actions  Bag – unordered list which may contain duplicates XACML Concepts Target Target Target Condition Effect Rules Obligations Policies Obligations PolicySet Policies and Policy Sets  Policy  Smallest element PDP can evaluate  Contains: Description, Defaults, Target, Rules, Obligations, Rule Combining Algorithm  Policy Set  Allows Policies and Policy Sets to be combined  Use not required  Contains: Description, Defaults, Target, Policies, Policy Sets, Policy References, Policy Set References, Obligations, Policy Combining Algorithm  Combining Algorithms: Deny-overrides, Permit-overrides, First-applicable, Only-one-applicable Request and Response Context xacml Policy.xml domain-specific xacml Context/ xacml Context/ domain-specific PDP inputs Request.xml Response.xml outputs XACML 2.0 Profiles  Digital Signature  Integrity protection of Policies  Hierarchical Resources  Using XACML to protect files, directory entries, web pages  Privacy  Determine “purpose” of access  RBAC  Support ANSI RBAC Profile with XACML  SAML Integration  XACML-based decision request  Fetch applicable policies  Attribute alignment XACML Benefits  Standard Policy Language  Investment protection  Skills reuse  Leverage XML tools  Policy not in application code  Reduce cost of changes  Consistent application  Enable audit XACML Performance  Some public comments based on ignorance  Many optimization opportunities  Policy encoding  Request context  Partial evaluation  Decision Caching  Precomputed admin chaining  Complex policies cost more to evaluate than simple  But is the difference more significant that other factors? Current Work - XACML 3.0  Administration/Delegation  Schema generalization  WS-XACML  Obligation combining rules  Policy provisioning  Metadata/vocabulary advertisement  Closely coupled PDP/PEP Delegation with XACML 2.0  Use of Intermediary Subject Category  Print Format Service can read any file a user wants printed, but not otherwise  Access Subject + Intermediary Subject  Delegation by modifying attributes  User can enable family member’s access  Policy protects subject repository  Policies protecting each policy repository Administration/Delegation  Two primary use cases  “HR-Admins can create policies concerning the Payroll servers”  “Jack can approve expenses while Mary is on vacation”  Backward compatible  Likely to define two compliance levels  Policies can contain Issuer  Policies can be Access or Admin  Admin policies enable policy creation Administration/Delegation  Situation – all information values used as policy inputs  If policy issued by trusted issuer – use  If not, look for Admin policy for Issuer covering current Situation  Chain back to Trusted Issuer  Actual processing is complex, because of interplay with policy combining Other 3.0 Work  Schema generalization  Improve extensibility  WS-XACML  Builds on WS-Security Policy – more fine grained  Good for privacy policies  Obligation combining rules  XACML 2.0 accumulates all Obligations  Characterize Obligation types – enable different treatments  Policy provisioning  From repository distribute distinct policy subsets XACML Interoperability Demo  Burton Catalyst Conference  San Francicso - June 28, 2007  Participating Organizations  BEA, CA, IBM, Jericho Systems, Oracle, Redhat, Securent, Symlabs  Interop Features  Stock Trading Environment  Two Usecases  Authorization Decision – 18 Scenarios  Policy Exchange – 8 Scenarios www.oasis-open.org Identity and Access Control Extensions for Java Enterprise Edition (EE) Anil Saldhana Red Hat Inc. Anil.Saldhana@redhat.com http://anil-identity.blogspot.com IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 1 www.oasis-open.org  Anil leads JBoss Security and Identity Management at Red Hat Inc.  Member of OASIS Consortium  Secretary of SAML Technical Committee.  Member of XACML, WS-Federation and Enterprise Key Management TCs.  Member of W3C  Co-editor of WSC-XIT Specification (WIP) IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 2 www.oasis-open.org  Java Enterprise Edition (EE) is the premier specification in the Java Enterprise World.  Java Community Process (JCP) is the standards body.  Currently in version 1.5  Containers  Web, Enterprise Java Beans (EJBs) etc.  Coarse-grained security using RBAC. IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 3 www.oasis-open.org Java EE  Java Enterprise Application Server Java EE Application Server Legacy Infrastructure Browser Web Server or Java EE Application Server Java EE Application Server Database/ Messaging/ LDAP IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 4 www.oasis-open.org  Java EE Security  Underspecified.  Containers perform 2 sequential steps  Establish Principal (Authentication)  Determine Roles and undertake enforcement  RBAC based coarse-grained access control.  Roles shield • Web Resources, EJB Methods, Message Destinations.  Security is an aspect external to app IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 5 www.oasis-open.org  Java EE Containers Authentication I KNOW YOU! WHO ARE YOU? Username SAML2 Assertions Java Principal WS-Trust Claims in Kerberos Principal Java Subject Java EE Container IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 6 www.oasis-open.org  Java EE Containers Authorization WHAT ROLES DO YOU HAVE? GO AHEAD! Java EE Container Java Principal Access Java EE Policies IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 7 www.oasis-open.org  Identity Extensions  Identity entering authentication phase  Certificates (CLIENT-CERT in Web world)  Username (JMS Connections)  Unspecified  Java Principal (in Subject) is the exit artifact.  Federated Identity can always be represented as a Java Principal.  Automatic extension of the Java EE Spec. IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 8 www.oasis-open.org  Authorization Extensions  Specification mandated rules are insufficient  Web : Roles against web URL for resources • Contextual security needs to be provided (XACML) • Web resource accessible by employees on business days between 9am and 5pm from a particular subnet only.  Allow multiple policy technologies to make one collective decision  JACC, XACML, Custom Policies plug-n-play IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 9 www.oasis-open.org  Authorization Extensions  Example of a policy for resources Policy for Test X. Anyone can perform any action on any resource if current-time is 08:23:47-05:00. 08:23:47-05:00 IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 10 www.oasis-open.org  Use Case – JBoss Portal  Portlets are web components running in a Portlet Container (JSR-168)  Portal page can contain multiple sub components such as sub pages, sub windows etc.  Subcomponents need entitlements. • An identity may have access to 5 subcomponents out of 20 on a page. IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 11 www.oasis-open.org  Use Case – JBoss Portal IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 12 www.oasis-open.org  Use Case – JBoss Portal  Need for fine-grained authorization is evident  XACML is a strong candidate (+)  Alternative is a custom ACL implementation (-)  JavaEE web.xml access control semantic falls short.  Identity can be a federated identity IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 13 www.oasis-open.org  Use Case – JBoss Portal - Policy encoding="UTF-8"?> RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"> Policy Policyfor forPortal PortalUse UseCase. Case. Effect="Permit"> Portal Portalaccessible accessiblebetween between99am amand and5pm 5pm MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> http://host/companyportal/ DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://host/companyportal/ DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 14 www.oasis-open.org  Use Case – JBoss Portal - Policy FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal"> FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> /> 09:00:00 DataType="http://www.w3.org/2001/XMLSchema#time">09:00:00 FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal"> FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> /> 17:00:00 DataType="http://www.w3.org/2001/XMLSchema#time">17:00:00 IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 15 www.oasis-open.org  Use Case – JBoss Portal - Policy Effect="Permit"> The EighteenYearOld page accessible if you are 18 The EighteenYearOld page accessible if you are 18 MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> http://host/companyportal/EighteenYearOld/ DataType="#anyURI">http://host/companyportal/EighteenYearOld/ DataType="#anyURI"/> FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-equal"> FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only"> DataType="http://www.w3.org/2001/XMLSchema#integer"/> 18 DataType="http://www.w3.org/2001/XMLSchema#integer">18 IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 16 www.oasis-open.org  Use Case – JBoss Portal – Request encoding="UTF-8"?> …> DataType=“…#string"> Anil Saldhana Anil Saldhana DataType="…#anyURI"> http://host/someportal/ http://host/someportal/ DataType=“…#string"> read read DataType=“…#time"> 09:23:47-05:00 09:23:47-05:00 IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 17 www.oasis-open.org  Use Case – JBoss Portal – Response encoding="UTF-8"?> access_control-xacml-2.0-context-schema-os.xsd"> NotApplicable NotApplicable Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 18 www.oasis-open.org  Q&A IDTrust08 – 7th Symposium on Identity and Trust on the Internet, NIST 19 www.oasis-open.org XACML 2.0 Interop 2008 Anticipated Participants  Axiomatics  BEA Systems  IBM  Oracle  Red Hat  Cisco  Sun  U.S dept of Veterans Affairs Goals  The interop will demonstrate the use of XACML V2.0 capabilities in a healthcare scenario involving the election and enforcement INCITS compliant clinical roles and patient privacy directives. Features/Highlights  Privacy and security in XACML policy  HL7 role-based  Use of HL7 consent code  Over-ride of patient election by declaring an emergency  Use of obligations to continue to enforce dynamic patent privacy directives even after release to another system Scenario Discharge Summaries Emergency Dept Referral Lab Results History & Physical … … ?? Hospital Community Clinic Challenges to healthcare data exchange: Proper Authorization & Privacy Scenario  In the scenario, examples of likely patient privacy directives are stored in a shared policy administration point (central repository).  Each participant will act as a healthcare enterprise (partner facility) within an identity federation sharing a common repository of patient privacy preferences and consent directives.  Partner/users (clinicians) request protected patient information from their healthcare facility. Before the release of protected patient medical information to the clinician, each participant will evaluate the clinician roles (in the form of HL7 clinical permissions) and the patient privacy directives stored in the central repository. Scenario (continued)  Access to patient information will not be “all or nothing,” rather portions of the medical record not releasable to the clinician based on the patient privacy directives will be “filtered” from the provided information view.  Variations on policy will be used to demonstrate that the patient privacy directives are being honored.  Changes to the patient privacy directives at the central repository will be reflected in changes to access to the patient information at the partner facility. XACML Interop at RSA2008 Andreas Sjöholm Product manager Axiomatics XACML Interop at RSA2008  2nd XACML Interop  Demonstrate XACML 2.0 interoperability  XACML 2.0 capabilities in a healthcare scenario  Utilizing HL7 etc.  Axiomatics, BEA Systems, IBM, Oracle, Red Hat, Cisco, Sun and U.S dept of Veterans Affairs High level objectives  Control access to specific portions of a healthcare record  Filter sensitive clinical information from being viewed  Ensure obligations are met  Provide vehicle to override consent (emergency overrides) = can-know or must-not-know basis Use Cases  Policy exchange  Authorization Decision Req/Resp  Fine grain auth  HL7 Permission based access  HL7 Patient consent directives  Data filtering obligations  Emergency override obligation Interoperability configuration Embedded Client External Web Service – standard PEP PEP Application – authorizes –browser fine grained, – user’s access,specific, Provides vendor initial access context provide and operations API to auth Application on client resource for facilitate containerpassing – hosts request web response Context and application handlers (incl and – obligations) separated provide fdu to common need Resources of normative services – MR, lab&test such XACML as auth and authorization results. Authorization Tagged and client with general –attributes standard API API to enterprise application for submitting requests and response. Gets applications context from PIP. Use Case: Policy Exchange Pri focus (inner): PAP creates policy Notification PDP uses Next step (outer): Larger context with Attribute management Manager services Use Case: Fine Grain Auth  Web browser access Health Care App  When auth needed for specific action Healthcare auth client collects attrib etc.  Embedded PEP take requests  Normative XACML resp/req  Coarse grained auth: front end, establish context Patient Consent Directives  Patient authorizes direct providers, but those not assigned to their case should not have access.  Patient authorizes normal care, except for Dr. Bob Busybody (who is his nosy neighbor)  Patient authorizes normal care, and further authorizes use of their data by cancer researchers  Patient authorizes normal care, but requires a confidential S/MIME email sent describing each access. Patient Consent Directives HL7 confidentiality codes N Normal CDA Restricted by consent directive S Sensitive SSA Shared Secret Access PSY Psychiatry related item MA Masked access U User based access … … HL7 Permission codes PRD-006 Patient Identification and Lookup PRD-017 Review Progress Notes PRD-012 Review Past Visits PRD-003 Review Medical History PRD-005 Review Vital signs/Patient Measurements PRD-009 Review Current Directory of Provider Information PRD-010 Review Patient Medications … … HL7 Permission based access  XACML 2.0 RBAC Profile  Demonstrate use of HL7 Identifiers  Local roles vs. HL7 standard permissions (inter-organizational purposes)  Requesting user obtains a set of HL7 permissions  Maps to virtual role HL7 Permission based access Request Policy references Patient Consent refer the request to This policy requires an Directive Access the approprate policy attribute which Policy for indicates consent The CDA code to the access Policy for The MA code These policies Policy for implement an XACML Resolving conflicting RBAC model Request Confidentiality codes Policy for The S code This policy combines the Policy for The request starts different consent The N code Permission always at the top directives. For Policy Set level policy set instance, if a which uses the record is marked confidentiality with both CDA and Policy for codes N, then both these The U code policies have to say permit. Top-policy for resolving conflicting confidentiality codes …policy when accessed resource has confidentiality code N (Normal)… …policy when access subject is role:physician. Access request Subject Attribute: subject-id = Julius Hibbert Subject Attribute: subject-role = physician Resource Attribute: resource-id = record/patient/ BartSimpson Resource Attribute: conf-code = CDA Resource Attribute: conf-code = N Resource Attribute: constented-subject-id = Julius Hibbert Resource Attribute: resource-type = medical record Decision response  Access permitted  XACML Obligations - filter out certain sensitive data Patient’s directives Sensitive data filter XACMLPatientPrivacy  JAVA EE  Java Server Faces (JSF) 1.2  Java API for XML Web Services (JAX-WS) 2.1  Functionality  Patient elections  Local entity patient search  Patient Demographics  Patient Chart (problem list, procedures, lab, meds, vitals and radiology)  Clinical Notes  Patient Directive override for chart items, demographics, and notes. Emergency override Thank you and see you at RSA2008! Sunil Madhu’s presentation is not available, due to encryption in the Microsoft Powersoft source document. What is OpenID? OpenID: Status and Challenges ! Lightweight ! De-centralized ! Single-Sign-On ! System IDTrust Symposium ! “OpenID is a free and easy way to use a March 4-6 2008 single digital identity across the Internet.” George Fletcher ! http://openid.net What’s Happening? What’s Happening? ! OpenID Foundation ! Adoption… It’s growing :) " Established " OpenID Providers Yahoo!, Blogger, AOL, Live Journal, IPR, Process, Membership, Bylaws ! " MyOpenID.com, LinkSafe, etc defined ! 60 listed at openiddirectory.com " Board announced " OpenID Relying Parties " Local chapters ! Plaxo, Pibb, Magnolia, Blogger comments, Live Journal, Wordpress, wikis, blogs, etc ! Many, many more listed at openiddirectory.com What’s Happening? What’s Happening? ! Specifications ! OpenID 2.0 Specification Highlights " OpenID 2.0 Final " Enhanced security RP verification (Section 13) OpenID Attribute Exchange 1.0 Final ! " ! Associations via SSL " OpenID Provider Authentication Policy " Better user experience Extension (Draft) ! Directed Identity ! Identifier recycling protection " Enhanced privacy ! Pseudononymous identifiers Relying Party Verification Directed Identity in Action Authenticate User OP Identifier AuthN Req Rsp Create Association OP RP Create Assoc_handle Check AuthN Rsp Check CreateAssoc_handle AuthN Req Verify -- claimed_id realm Verify -- realm Discover claimed_id OP Verify -- return_to return_to Verify -- return_to return_to What’s Next? Challenges ! Specifications ! Perception " Interesting discussions around ! Relying Party (business) federation and SSO/SLO ! User Experience " Finalization of the Provider Authentication Policy Extension ! Technical " Reputation Extension Perception Challenges Challenges ! What is it good for? Where does it fit? ! Adoption by Relying Parties " Risk management ! "But OpenID doesn't have the privacy ! Do I trust the user? characteristics that would make it suitable for ! Do I trust the OpenID Provider? government applications or casual web surfing.” ! If the user is “bad” what do I lose? ! What is the liability in a fraudulent ! Kim Cameron’s Blog -- Sunday Feb. 24 transaction? [Microsoft is a founding board member of OIDF] Challenges Challenges ! User Experience ! User Experience " The user themselves :) " Bridging the gap… identity agents ! What is an OpenID? ! Be proactive ! Why do I need one? ! Detect when the user is authenticated ! How will it help me? ! When that identity can be used a another ! Is it secure? site ! Ask the user if they want to “login” with their current identity? Technical Challenges Lessons Learned ! OpenID 2.0 more complex ! User education still needed " Open source libraries available " Spreadopenid.com ! OpenID 2.0 “backward compatibility” " Driving usage is better than text ! Difficult to “chain” to back-end web ! Relying Party support needs substantial service calls growth before OpenID can become mainstream " Attribute Exchange is the best option right now ! On-the-fly risk mitigation is non-trivial for " May need it’s own extension those resources that require it Questions & Answers ! Contact Info: ! George Fletcher ! George.fletcher@corp.aol.com ! http://practicalid.blogspot.com