IDtrust 2009 8th Symposium on Identity and Trust on the Internet Program 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 at least SSH, IPSEC, HTTP, DNS, FTP, POP, IMAP, and SMTP connectivity. Proceedings at ACM Digital Library The proceedings are also available in the ACM International Conference Proceeding Series archive: Proceedings of the 8th Symposium on Identity and Trust on the Internet. Blogging Participants and observers are encouraged to use the tag "idtrust2009" when blogging and tweeting about the symposium. Tuesday, April 14, 2009 - 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 Federal Authentication and Identity Programs are Making Progress and Impacting Industry, But Much Work Remains (Presentation slides: ppt ) Dan Blum, Burton Group 10:00 - 10:15 Break 10:15 - 11:40 Session 1 - Panel - Comparative Identity Systems Panel Moderator: Kent Seamons, Brigham Young University (Slides: ppt ) Radia Perlman, Sun (Slides: ppt ) Ken Klingenstein, Internet2 (Slides: ppt ) Paul Trevithick, Higgins Project (Slides: pdf ) George Fletcher, AOL (Slides: pdf ) 11:40 - 12:00 Break 12:00 - 1:00 Session 2: Panel - Can Federations Scale? Panel Moderator: Dan Blum, Burton Group Peter Alterman, General Services Administration Ken Klingenstein, Internet2 Roger Lambert, Covisint 1:00 - 2:00 Lunch 2:00 - 3:30 Session 3 - Technical Papers - Identity Management Session Moderator: David Chadwick, University of Kent Identity, Credential, and Access Management at NASA, from Zachman to Attributes (Presentation slides: ppt ) Corinne Irwin, NASA Dennis Taylor, NASA (INDUS Corp.) Personal Identity Verification (PIV) Cards as Federated Identities - Challenges and Opportunities (Presentation slides: pdf ) Sarbari Gupta, Electrosoft A Calculus of Trust and Its Applications to PKI and Identity Management (Presentation slides: pdf ) Jingwei Huang, University of Illinois David Nicol, University of Illinois 3:30 - 4:00 Break 4:00 - 5:30 Session 4 - Panel - What is Special About My Application Panel Moderator: Tim Polk, NIST Walter G. Suarez, Institute for HIPAA/HIT Education and Research (Slides: ppt ) Andrew Regenscheid, NIST (Slides: ppt ) Barry Leiba, Internet Messaging Technology (Slides: pdf ) Bob Sunday, Government of Canada (Slides: ppt ) Stephen Whitlock, Boeing (Slides: ppt ) 5:30 Bus Departs for Gaithersburg Holiday Inn 6:00 Social Gathering and Dinner Buffet - Gaithersburg Holiday Inn Wednesday, April 15, 2009 - Full Day 8:15 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00 - 9:50 Keynote Talk II Identity and Trust in Context (Presentation slides: pdf ) Peter G. Neumann, SRI 9:50 - 10:10 Break 10:10-11:40 Session 5 - Technical papers - Federations and Virtual Organizations Session Moderator: Scott Rea, Dartmouth College Palantir: A Framework for Collaborative Incident Response and Investigation (Presentation slides: ppt ) Himanshu Khurana, University of Illinois Jim Basney, NCSA, University of Illinois Mehedi Bakht, NCSA, University of Illinois Mike Freemon, NCSA, University of Illinois Von Welch, NCSA, University of Illinois Randy Butler, NCSA, University of Illinois Safeguarding Digital Identity: The SPICI (Sharing Policy, Identity, and Control Information) Approach to Negotiating Identity Federation and Sharing Agreements (Presentation slides: pdf ) Deborah Bodeau, The MITRE Corporation Usable Trust Anchor Management (Presentation slides: pdf ) Massimiliano Pala, Dartmouth College Scott Rea, Dartmouth College 11:40 - 12:00 Break 12:00 - 1:00 Session 6: Special Session: Browser Security Latest advances in browser security- a report card and forthcoming W3C WSC specification (Presentation slides: pdf ) Anil Saldhana, Red Hat Which Browsers handle SSL certificates in a standard way? David Chadwick, University of Kent 1:00 - 2:00 Lunch 2:00 - 3:30 Session 7: Technical Papers - Applied Cryptography Session Moderator: Nelson Hastings, NIST Privacy-Preserving Management of Transactions' Receipts for Mobile Environments (Presentation slides: pdf ) Federica Paci, Purdue University Ning Shang, Purdue University Sam Kerr, Purdue University Kevin Steuer, Jr, Purdue University Jungha Woo, Purdue University Elisa Bertino, CERIAS, Purdue University Quantum Resistant Public Key Cryptography: A Survey (Presentation slides: ppt ) Ray Perlner, NIST David Cooper, NIST 3:00 - 3:30 Session 8: Technical Papers - Information Cards Session Moderator: Peter Alterman, General Services Administration FileSpace - An Alternative to CardSpace that supports Multiple Token Authorisation and Portability Between Devices (Presentation slides: ppt ) David Chadwick, University of Kent 3:30 - 4:00 Break 4:00 - 5:30 Session 9: Panel - Comparative Authorization Models Panel Moderator: John Sabo, CA, Inc. Radia Perlman, Sun (Slides: ppt ) Rakesh Radhakrishnan, Sun (Slides: pdf ) Dr. Ramaswamy (Mouli) Chandramouli, NIST (Slides: ppt ) Tim Brown, CA, Inc. (Slides: ppt ) 5:30 Bus Departs for Gaithersburg Holiday Inn Dinner (on your own) Thursday April 16, 2009 - Half Day 8:15 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00-10:00 Session 10 - Panel - Defensive PKI - What Happens when PKI Fails? Panel Moderator: Carl Ellison, Microsoft (Slides: pptx pdf ) Tim Polk, NIST Stephen Whitlock, Boeing Kelvin Yiu, Microsoft 10:00 - 10:30 Session 11 - Technical Paper - Usability Session Moderator: Peter Alterman, General Services Administration Usable Secure Mailing Lists with Untrusted Servers (Presentation slides: pptx ) Rakesh Bobba, NCSA, University of Illinois Joe Muggli, NCSA, University of Illinois Meenal Pant, NCSA, University of Illinois Jim Basney, NCSA, University of Illinois Himanshu Khurana, University of Illinois 10:30 - 11:00 Break 11:00 - 12:00 Session 12: RUMP Session (Work in Progress) Session Chair: Neal McBurnett, Internet2 Why Create new ID-related Standards? (Presentation slides: ppt ) Shivaram Mysore, Key Pair Technologies DNSSEC Update Tim Polk, NIST Digital Identity (Presentation slides: ppt ) Bill MacGregor, NIST Group signature with selective disclosure for privacy enhanced ID management (Presentation slides: pdf ) Kazue Sako and Jun Furukawa, NEC Identity Quality Assurance (Presentation slides: ppt odp ) Wes Kussmaul, Reliable Identities 'Break the Glass' Obligation Policies Demo (Presentation slides: pdf ) David Chadwick, University of Kent Easy-To-Use Secure Email (Presentation slides: ppt ) Kent Seamons, Brigham Young University Delivering Anonymous Certificates (Presentation slides: ppt ) James Fisher, Noblis 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 8th Symposium on Identity and Trust on the Internet Kent Seamons Brigham Young University Program Chair Program Committee • Gail-Joon Ahn, Arizona State • Eric Norman, University of Wisconsin • Peter Alterman, GSA • Radia Perlman, Sun Microsystems • Abbie Barbir, Nortel • Tim Polk, NIST • John Bradley, ooTao • Scott Rea, Dartmouth College • David Chadwick, University of Kent • Andrew Regenscheid, NIST • Carl Ellison, Microsof • John Sabo, Computer Associates • Stephen Farrell, Trinity College Dublin • Anil Saldhana, Red Hat • Peter Gutmann, University of Auckland • Krishna Sankar, Cisco Systems • Adam J. Lee, University of Pittsburgh • Frank Siebenlist, Argonne National • June Leung, FundSERV Laboratory • Simson Garfinkel, Naval Postgraduate • Sean Smith, Dartmouth College School • Jon Solworth, Univ. of Illinois – Chicago • Eve Maler, Sun Microsystems • Anna Squicciarini, Penn State • Neal McBurnett, Internet2 • Von Welch, NCSA • Clifford Neuman, USC • Stephen Whitlock, Boeing • Arshad Noor, StrongAuth • Michael Wiener, Cryptographic Clarity Thank You! April 14-16, 2009 IDtrust 2009 Special Thanks • Steering Committee Chair: Neal McBurnett, Internet2 • Local Arrangements Chair - Sara Caswell, NIST • Registration - Teresa Vicente, NIST • Panels Chair - Radia Perlman, Sun Microsystems • General Chair - Ken Klingenstein, Internet2 April 14-16, 2009 IDtrust 2009 Technical Program • Technical Paper sessions (peer reviewed) • Accepted 10 out of 30 total submissions • 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 • Keynote talks • Dan Blum, Burton Group • Peter Neumann, SRI • Panels sessions (6) April 14-16, 2009 IDtrust 2009 RUMP Session • Short Work-In-Progress Talks – Thursday morning – Submit an abstract – 5 minute presentations (subject to change) – Contact: Neal McBurnett • neal@mcburnett.org Courtesy: http://www.flaminghotideas.co.uk/library_travel.htm April 14-16, 2009 IDtrust 2009 Social Gathering and Dinner Buffet • Tuesday, Gaithersburg Holiday Inn, 6 PM 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 April 14-16, 2009 IDtrust 2009 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! April 14-16, 2009 IDtrust 2009 Enjoy the Workshop • The success of the workshop is in your hands – Participate! – Ask compelling questions April 14-16, 2009 IDtrust 2009 U.S. Federal Authentication and Identity Programs are Making Progress and Dan Blum April 14, 2009 Impacting Industry, But Much Work dblum@burtongroup.com Remains Presented for NIST IDTrust 2009 All Contents © 2009i Burton Group. All rights reserved. U.S. Federal Authentication Programs Agenda • Overview of HSPD-12, FPKI, and E-Authentication • Taking the next steps in federated identity • Recommendations U.S. Federal Authentication Programs Three main federal authentication initiatives • Cross-certified federal public key infrastructure (FPKI) bridge is starting to gain traction through agency and shared service provider support • E-Authentication Initiative for common policy, federated identity • Homeland Security Presidential Directive 12 (HSPD-12) mandated Personal Identification Verification (PIV) cards for government employees and contractors Source: GSA U.S. Federal Authentication Programs Multiple missions for multi-level, interoperable authentication • Protect government information and facilities (cybersecurity) • Improve internal efficiency and effectiveness • Extend e-government services to citizens with protection appropriate to the risks involved U.S. Federal Authentication Programs Smartcards • Card issuance continues • As of March 2009, 48% of the PIV-eligible workforce have been issued cards • Emphasis is shifting from issuance to putting the PIV smartcard to use • PIV card usage and deployment challenges include • Integrating card issuance with back-end directory and provisioning functions • Integrating smartcards with desktops, applications, and building access • Life cycle card management AGENCY ELIGIBLE ISSUED TARGET 2009 2010 2011 2012 2015 DOD 3.9M 56% ISSUE LACS CAC is pervasive PACS Next gen CAC (with PIV) coming, but no stats VA 460K 1% ISSUE LACS No stats PACS No stats Source: DHS 256K 0% ISSUE No stats HSPD-12 Public LACS No stats PACS No stats Reports TREAS 129K 71% ISSUE LACS PACS DOJ 112K 11% ISSUE LACS PACS DOE 112K 62% ISSUE LACS PACS USDA 105K 57% ISSUE LACS PACS HHS 96K 27% ISSUE LACS PACS AGENCY ELIGIBLE ISSUED TARGET 2009 2010 2011 2012 2015 DOT 92K 13% ISSUE LACS PACS DOI 83K 26% ISSUE LACS PACS SSA 81K 92% ISSUE LACS PACS NASA 78K 92% ISSUE LACS PACS DOC 49K 38% ISSUE LACS PACS STATE 27K 89% ISSUE LACS PACS COMPLETE GSA 22K 71% ISSUE LACS PACS EPA 19K 91% ISSUE SUBSTANTIALLY COMPLETE LACS PACS DOL 18K 89% ISSUE LACS PACS HUD 11K 100% ISSUE LACS PACS No stats U.S. Federal Authentication Programs Other large federal smartcard initiatives • The Department of Defense (DoD) Common Access Cards (CAC) program is migrating towards FIPS 201 compliance • Department of Homeland Security (DHS) programs will ultimately outfit populations that dwarf PIV’s • Transportation Workers Identification Cards (TWIC) have been issued to more than 1 million workers • First Responder Authentication Credential (FRAC) cards will be issued by states and local governments as well as accredited service providers • Airport Credential Interoperability Solution (ACIS) is in the planning stages • While other programs are not 100% PIV-interoperable, newer specifications are converging U.S. Federal Authentication Programs The significance of all the smartcard work… "Although there are 6 million probes of Defense Department networks a day, successful intrusions have declined 46 percent in the past year because of a requirement that all DoD personnel log on to unclassified networks using Common Access Cards." Lt. Gen. Charles Croom, at the AFCEA SpaceComm 2007 Conference U.S. Federal Authentication Programs Federal PKI • FPKI is starting to gain traction through agency and shared service providers support • Certification Authorities (CAs) from CertiPath, SAFE BioPharma, and Internet 2 (for higher education) are in place Source: GSA U.S. Federal Authentication Programs FPKI: The evolution continues • Revocation and path validation • CRL -> Client-side OCSP support • Client side path validation -> infrastructure path validation • OCSP -> SCVP • Risk aggregation (in the breadth of trust, and concentration of CAs) • Migrate to stronger algorithms, longer keys over time Related issues: Authorization and audit compensate for the breadth of the authenticable population • Authentication is NOT authorization • Beef up authorization, entitlements management • Audit: the most important complementary and compensating control U.S. Federal Authentication Programs Organizational questions ICAM: Identity, Credentials, and Access Management • Subcommittee reports up to Federal CIO council has jurisdiction over smartcard, PKI, and federation programs • OMB, GSA, NIST coordinate fairly closely • ICAM also coordinates with DHS, defense and intelligence community Hopes for authentication continuity with the new administration • ICAM, agency community generally optimistic that there will be continuity on cybersecurity matters, such as HSPD-12 and FPKI • Tension anticipated between cybersecurity, e-government, and social media camps U.S. Federal Authentication Programs Federated identity • E-Authentication Initiative successful on a policy level • Federated identity is in place at multiple agencies and is used for • Many Level 1 and 2 government applications • Reducing identity management silos • Reducing sign-on requirements • Business and citizen-facing government applications didn’t take off • GSA has shut down the E-Authentication Portal and now encourages agencies to deploy locally using E-Authentication guidance U.S. Federal Authentication Programs Industry impact: a large market for products and services • Specifications for PIV-interoperable smartcards will soon be formally released, providing standards for commercial service providers, federal contractors, states, municipalities, and others • DoD/government contracting practices and regulations may come to require PIV support • GSA has approved more than 400 products for various FIPS 201 smartcard-related functions, and 18 products for SAML • Higher education is in the forefront of federating with NIH and other agencies for research and grant-based applications • Federations for law enforcement and medical information sharing are in pilot stages at DHS, DOJ, VA U.S. Federal Authentication Programs Agenda • Overview of HSPD-12, FPKI, and E-Authentication • Taking the next steps in federated identity • Recommendations U.S. Federal Authentication Programs The puzzle of how to create identity interoperability for the masses remains unsolved… U.S. Federal Authentication Programs Where does federated identity apply? A survey once said applications were… But is that correct? The answer depends not just on risk, but also on the mix of compensating controls… U.S. Federal Authentication Programs Change we can believe in? New user-centric schemes for identity interoperability • Information Cards have promising implementations, but few sites support them • OpenID is popular but has trust, security, and usability problems U.S. Federal Authentication Programs Smartphones with OTP software • Reported in the New York Times March 31st • A strong authenticator in every pocket • Planned for BlackBerry too U.S. Federal Authentication Programs In our humble opinion… • The user is not always center • The organization is not always center • Interoperability takes on the context of relationships • Use cases exist for • 1st party (user centric) federation • 2nd party (e.g. today’s typical SAML) federation • 3rd party (e.g. SAML, WS-*) federation U.S. Federal Authentication Programs They may ALL make sense somewhere… WS-* • Pick the technologies that are simplest and most apt to the problem • And find business models, partnerships to solve human and organizational problems U.S. Federal Authentication Programs Agenda • Overview of HSPD-12, FPKI, and E-Authentication • Taking the next steps in federated identity • Recommendations U.S. Federal Authentication Programs Recommendations for agencies • Put newly issued PIV cards to use as required per HSPD-12 • Build consensus on overall agency architecture (e.g., see next slide) among physical facilities, information security, and other groups • Integrate smartcard management and issuance with agency identity management and provisioning systems • Integrate smartcard login with client operating systems • Dovetail PIV rollout with desktop and physical access control system upgrades • Implement robust recovery and emergency access procedures • Enable applications to consume PIV through reduced sign-on approaches (assertions, web access management, Kerberos…) • Enhance identity federation and authorization capabilities U.S. Federal Authentication Programs U.S. Federal Authentication Programs Recommendations for federal authentication governance • Enhance policy and implementation guidance to agencies • Strongly promote federated identity for externally facing e- government applications at assurance levels 1, 2, and 3 • Stay the course with SAML 2.0 • Promote additional federation “schemes” where advantageous • Continue outreach programs to gain industry consensus on federated and user-centric identity U.S. Federal Authentication Programs Recommendations for other organizations in the industry Study Federal authentication initiatives for opportunities to • Gain competitive advantage • Comply with future DoD or civilian agency contract stipulations • Learn how to improve their own IT and security infrastructure References General references • Government's identity management site • HSPD-12 Public Reports • Technical Comparison: OpenID and SAML - Draft 06 Burton Group documents • U.S. Federal Authentication and Identity Programs are Making Progress and Impacting Industry, But Much Work Remains • Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems • Entitlement Management: Ready to Enter the IdM Mainstream • Federation’s Future in the Balance: Teetering Between Ubiquity and Mediocrity • The Information Card Landscape • In Search of the Internet Identity System: Contrasting the Federation Approaches of SAML, WS-Trust, and OpenID • A Relationship Layer for the Web . . . and for Enterprises, Too • Web Access Management Market 2007: Expanding Boundaries • Federation Products 2008 U.S. Federal Authentication Programs Conclusion • The U.S. federal authentication programs for issuing smartcards and extending PKI are gaining traction • Government and industry now have a roadmap for high assurance authentication interoperability • Agencies must now enhance identity management and security infrastructure to leverage strong authentication for logical and physical access control • Meanwhile, federated identity schemes could support many e- government applications • E-Authentication identity federation initiatives must be revitalized to build public/private and federal/state partnerships Session 1 Panel: Comparative Identity Systems Panelists: George Fletcher, AOL Ken Klingenstein, Internet2 Radia Perlman, Sun Paul Trevithick, Higgins Project Moderator: Kent Seamons, Brigham Young University April 14-16, 2009 IDtrust 2009 April 14-16, 2009 IDtrust 2009 April 14-16, 2009 IDtrust 2009 PKI-based authentication Radia Perlman Radia.Perlman@sun.com 1 I don’t care about formats • “Certificate” is a signed thing, asserting by some trusted entity, a mapping between things such as a name and a key 2 PKI-based Authentication Alice Bob [“Alice”, key=342872]CA [“Bob”, key=8294781]CA Auth, encryption, etc. 3 Yes there are issues • How does a user get her private key? • How does a user know the CA’s public key? • How does a user get a certificate? • Revocation.. 4 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 5 Better with smart cards • Badges have smart cards. What’s the problem? 6 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) 7 “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 8 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 9 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) 10 Note • Instead of enrolling with a username and password, your account name is your public key, and you authenticate with your private 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 11 Revisiting the site • Mutual authentication using public keys (e.g., SSL with client certs) 12 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” 13 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) 14 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 15 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 16 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 17 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 18 If there is just one IDP • User authenticates to that IDP • That IDP vouches for the user at all the affiliated sites 19 But what if there are hundreds? • And what if the SPs the user wants to use affiliate with different subsets of them? 20 And what value does the IDP give, anyway? 21 Online vs offline trusted box • Online box solution less secure – Can impersonate all users – More likely to be compromised than an offline box – Knows who is talking to who – May have database that if stolen, can compromise users 22 Also • More expensive (must be high performance, replicated for availability and performance) • Less robust (more boxes have to be up) • Slower (have to talk to 3rd box before Alice can talk to Bob) 23 Online intermediaries vs PKI • Performance • Availability • Security • Privacy 24 Federated Identity: It’s the attributes, urn:mace:incommon:entitlement:clue:zero Ken Klingenstein Internet2 Topics • Federated identity basics • Integration, not differentiation • Attributes kjk@internet2.edu Internet identity • Federated identity • Enterprise centric, exponentially growing, privacy preserving, rich attribute mechanisms • Requires lawyers, infrastructure, etc • User centric identity • P2P, rapidly growing, light-weight • Marketplace is fractured; products are getting heavier to deal with privacy, attributes, etc. • Unifying layers emerging – Cardspace, Higgins, OAuth kjk@internet2.edu Federated identity • Convergence around SAML 2.0 – even MS • Exponential growth in national and international R&E sectors • Emerging verticals in the automobile industry, real-estate, government, medical • Policy convergence for LOA, basic attributes (eduPerson), but much else, including interfederation and the user experience, remains to be developed • Application use growing rapidly • Visibility is about to increase significantly through end-user interactions with a privacy manager kjk@internet2.edu Trust, Identity and the Internet • ISOC initiative to introduce trust and identity- leveraged capabilities to many RFC’s and protocols • Acknowledges the assumptions of the original protocols about the fine nature of our friends on the Internet and the subsequent realities • http://www.isoc.org/isoc/mission/initiative/trust.shtml • First target area is DKIM; subsequent targets include SIP, federated calendaring and sharing, firewall traversal kjk@internet2.edu Federation Update • R&E federations sprouting at national, state, regional, university system, medical and library alliances, and elsewhere • Federated identity growing in business • Many bilateral outsourced relationships • Hub and spoke • Multilateral relationships growing in some verticals kjk@internet2.edu Federating Software • Move from bilateral to multilateral critical for scaling, and thus making metadata standards much more important • Metadata can include signing keys, attribute release policies, attribute consumption policies, DKIM signing keys and so much more…. • Shibboleth does this; vendor SAML products are starting to consume metadata better • MS Geneva will be configurable for InCommon, done right kjk@internet2.edu R&E Federation Killer Apps • Content access – Elsevier, OCLC, JSTOR, iTunes • Government access – NIH, NSF and research.gov • Access to collaboration tools – wikis, moodle, drupal, foodle; soon federated calendaring • Roaming network access • Outsourced services – National Student Clearing House, student travel, plagarism testing, travel accounting • MS Dreamspark • Google Apps for Education kjk@internet2.edu International R&E federations • More than 25 national federations • Several countries at 100% coverage, including Norway, Switzerland, Finland; communities 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 • EU-wide identity effort now rolling out - IDABC and the Stork Project (www.eid-stork.eu) • Key issues around EU Privacy and the EPTID • Some early interfederation – Kalmar Union and US-UK kjk@internet2.edu InCommon •Over 150 members now •Almost three million “users” •Most of the major research institutions •Other types of members • Non usual suspects – Lafayette, NITLE, Univ of Mary Washington, etc. • National Institute of Health, NSF and research.gov • Energy Labs, ESnet, TeraGrid • MS, Apple, Elsevier, etc. • Student service providers •Growth is quite strong; doubled in size for the fifth year straight •Silver profile approved kjk@internet2.edu NIH • Driving agency for much of our government activity • Several types of applications, spanning two levels of LOA and a number of attributes • Wikis, access to genome databases, etc • CTSA • Electronic grants administration • “Why should external users have internal NIH accounts?” • Easier stuff – technology, clue at NIH, user interest • Harder stuff – attributes (e.g. “organization”), dynamically supplied versus statically-supplied info kjk@internet2.edu Principles to be established by InCommon futures process • Community served • Business models • Service and business opportunities • Governance and representation • Pricing and packaging principles – membership models, working with soup, etc. • ----------------------------------------------------------- • The relationship between InCommon and Internet2 kjk@internet2.edu Federation Soup • Within the US, federations happening in many ways – state, university system, library, regional, etc • Until we do interfederation, and probably afterwards, federations will form among enterprises that need to collaborate, regardless of their sector • Common issues include business models, legal models, LOA and attributes, sustainability of soup • Overlapping memberships and policy differences creates lots of complexity in user experience, membership models, business models, etc. • One workshop in, so far… • https://spaces.internet2.edu/display/FederationSoup/Home kjk@internet2.edu Interfederation • Necessary for cross-vertical interactions, global scaling, etc. • Technical issues are tractable – dynamic metadata and metadata tagging, user discovery, etc – as long as basics (LOA, attributes, etc) are kept consistent • Policy issues are interesting – liability, adjudication, privacy, federation operator practices, etc. • Liberty and R&E and ISOC to work together on it kjk@internet2.edu The consumer marketplace • For federated identity, it hasn’t happened yet; existing IdP’s service current application needs. • GSA to engage with multiple federations of IdP’s, including InCommon, for government access • Several natural consumer IdP providers: banks, ISP’s, governments… • Costs are low; lock-in potential high kjk@internet2.edu Integration • Different forms of Internet identity will exist, serving different purposes, arising from different constituencies • The trick is the intelligent integration of the technologies, at user and application level • Cross-overs are happening • Shib and Openid • SAML and high assurance PKI – holder of key • Infocard/Higgins as an overarching user experience • Federation and portal integration kjk@internet2.edu Unifying the application developer experience • Discussions in IETF around oAuth could address API’s • Discussions in OASIS around Shib profiles • Discussions with Kuali/Rice about services • Discussions with portal people about portals kjk@internet2.edu Unifying the user experience • Among various identity providers, including P2P, self-issued, federated • Need to manage discovery, authentication, and attribute release • Cardspace, Higgins, uApprove, etc. • Consistent metaphors, different technical approaches • Starting to deploy kjk@internet2.edu Privacy management • Two approaches emerging • uApprove • http://www.switch.ch/aai/support/tools/uApprove.ht ml • InfoCard/Higgins • Who sets attribute release policies? Who overrides the settings? What logs are kept? kjk@internet2.edu kjk@internet2.edu Attributes • Now that we have a transport system, attention is turning to the cargo… • Standard schema (e.g. eduPerson) have proven very valuable; new attribute needs are emerging (over legal age, citizenship, disabilities, etc.) • Semantics need to be addressed more rigorously in a federated environment • Workshops are beginning to look at these issues • Attributes can conceal identity and preserve privacy, preserve secrecy, generate revenue kjk@internet2.edu The Art of the attribute • Proliferation of attributes – see http://wiki.idcommons.net/Identity_Schemas • Attribute aggregation approaches are beginning • No real understanding of sources of authority, delegation, audit, etc • Mappings and other evils lurk • All of which needs to work with humans as users, authorities, etc. kjk@internet2.edu GSA Attribute Workshop • Begin exploring the attribute issues • Using federal use cases, including • Citizenship, voting residency • Access-abilities • First responder capabilities • PI-person • Motivate the larger requirements, drive privacy policies • Explore rich query languages, etc. • All-star cast at the end of September at NIH kjk@internet2.edu Information Cards IDtrust 2009, NIST Paul Trevithick paul@azigo.com Selector-based Model •  Each identity displayed as a card •  The selector is the wallet •  A selector on every device •  Cards can roam between devices •  Card issuer defines claim set •  Issuer defines auth method •  User authenticates to card (not to RP/SP) 2 Card Types Managed What some other entity says about you (Manual Push) Personal What you say about you (Manual Push) Relationship Coming Soon What we say about you (Automatic Pull & Push) 3 Multiple Token Types + Multi-Protocol* Protocols Token Types •  InfoCard •  SAML •  SAML & ID-WSF •  Kerberos •  OpenID / AX •  Zero Knowledge Proofs •  Username/password (!) •  Proprietary… …all hidden behind a the same card metaphor *Higgins developers are integrating SAML Circles of Trust, WS- Trust STS/IdPs, and ID-WSF 4 Selector Implementations •  Mac, Windows, Linux available now •  Mobile devices coming soon •  Open source and closed source •  Microsoft CardSpace™ •  Azigo (Higgins-based, Adobe AIR-based) •  Novel DigitalMe™ (Higgins-based, native code) •  OpenInfoCard 5 Development Timeline Information Card Foundation Launched June 2008 1.0 Higgins 1.0 Feb 2008 CardSpace™ Jan 2007 6 Community: http://informationcard.net** • Information Card Foundation (ICF) publicly launched in the New York Times June 24th 2008 • **New Website will launch at RSA 2009 • ICF Board member sponsors are shown at left • Eclipse Higgins project is a collaboration led by Azigo and including IBM, Google, Oracle, Novell, CA and others 7 Adoption is just beginning •  Equifax Over 18 card •  Top 10 Website will demonstrate at RSA 2009 •  AAA “RemindMe” discount/loyalty card launching in May •  eGovernment development projects underway •  Telcos experimenting with mobile selectors We are here 8 Appendix: Login Flow 9 1: Alice goes to site (or app) Service Identity Provider Provider (Relying Party) Browser Selector User Agent 10 2: Selector retrieves policy Service Identity Provider Provider (Relying Party) Browser Required and Optional Claims Selector User Agent 11 3: Display cards that match policy (each card points to a different IdP or is self-issued) Service Identity Provider Provider (Relying Party) Browser Selector User Agent 12 4: Select a card Service Identity Provider Provider (Relying Party) Browser Selector User Agent 13 5: Auth to IdP & Request Token Service Identity Provider Provider (Relying Party) Auth Browser Materials + Request token Selector User Agent 14 6: Generate token Service Identity Provider Provider (Relying Party) Browser Selector User Agent 15 7: Forward token Service Identity Provider Provider (Relying Party) Browser Security Token Selector User Agent 16 8: Validate & assess token Service Identity Provider Provider (Relying Party) Browser Selector User Agent 17 9: Alice uses services Service Identity Provider Provider (Relying Party) Browser Selector User Agent 18 OpenID 2.0 George Fletcher AOL, LLC. David Recordon George Fletcher, AOL LLC. OpenID Foundation Chief Architect Identity Services What is OpenID? OpenID is an easy to implement and decentralized identity protocol designed to be used across the Internet. http://openid.net/ Over 35,000 OpenID Relying Parties Nearly One Billion OpenIDs OpenID is a great way to engage citizens via social media. Original OpenID “Design Goals”   Empowers people in a user-centric fashion   De-centralized with no single enforced trust model   Simple specifications: “small pieces loosely joined”   Easily deployable in a vast array of environments   Allows people to choose to invest in portable reputation based upon their OpenID identity   Privacy protecting use cases supported via “Directed Identity” OpenID Brand OpenID Identifiers   URLs directly issued by OpenID Providers   http://openid.aol.com/gffletch   https://recordond.pip.verisignlabs.com/   https://me.yahoo.com/a/69EIy0U13vQcyKjQsmRCurcBZX0glvM-   User owned URLs via Delegation   http://www.davidrecordon.com/   http://practicalid.blogspot.com/   OpenID Provider URLs for Directed Identity   http://openid.yahoo.com/   http://api.myspace.com/openid OpenID Specifications   OpenID Authentication 2.0   http://openid.net/specs/openid-authentication-2_0.html   Extensions   Provider Authentication Policy Extension (PAPE)   http://openid.net/specs/openid-provider-authentication- policy-extension-1_0.html   Attribute Exchange (AX)   http://openid.net/specs/openid-attribute-exchange-1_0.html   Simple Registration (SREG)   http://openid.net/specs/openid-attribute-exchange-1_0.html Two Basic User Interactions How does it work? OpenID OpenID Relying Provider Party How does it work? Present OpenID OpenID OpenID Relying Provider Party How does it work? Discover OP OpenID OpenID Relying Provider Party How does it work? OpenID OpenID Relying Provider Party Establish Shared Secret How does it work? Authentication Request OpenID OpenID Relying Provider Party How does it work? Realm/RP Validation OpenID OpenID Relying Provider Party How does it work? Authenticate User OpenID OpenID Relying Provider Party How does it work? Signed Auth Response OpenID OpenID Relying Provider Party How does it work? Verify Signature OpenID OpenID Relying Provider Party How does it work? Personalized Content OpenID OpenID Relying Provider Party Appendix Security Characteristics   SSL enabled OpenID URLs and Provider endpoints   SSL must be used to protect MITM attacks   Crypto separated from trust and “identity proofing”   Providers can authenticate the user however they please and describe the authentication via PAPE   Obviates the need for the “password anti-pattern”   Core data path is through the browser   Except for establishing the shared secret used to verify authentication assertions   Provider responses are not encrypted; just signed Attribute Exchange Extension   Purpose   Allow the relying party to request/require user attribute data by the OpenID Provider   Attribute specification is extensible   Supports push notifications on attribute data change   Verified Attributes   Proof of concept demos of exchanging signed SAML assertions via OpenID Attribute Exchange as a tie to PKI systems PAPE Extension   Purpose   Allow the Relying Party to request/require certain authentication policies of the OpenID Provider   Allows the OpenID Provider to describe characteristics to the Relying Party of how the user authenticated   Supports extension to other policies (such as those defined in NIST SP 800-63) via the auth_level parameter   Default Supported Policies   Phishing-Resistant Authentication   Multi-Factor Authentication   Physical Multi-Factor Authentication Identity, Credential, and Access Management at NASA, from Zachman to Attributes Corinne S. Irwin Dennis C. Taylor NASA NASA (INDUS Corp.) Code JD, 300 E Street, SW Code 720, NASA GSFC Washington, DC 20546 Greenbelt, MD 20771 1-202-358-0653 1-301-286-4290 Corinne.S.Irwin@nasa.gov Dennis.C.Taylor@nasa.gov ABSTRACT General Terms To achieve the ultimate goal of attribute-based access Security, Design control (ABAC), a robust architecture for Identity, Credential, and Access Management must first be Keywords established. The National Aeronautics and Space Attribute-based Access Control (ABAC), Logial Access Administration (NASA) began formal development of its Control System (LACS), Level of Assurance (LoA) Identity, Credential, and Access Management Architecture using the Zachman Framework for Enterprise Architecture 1. INTRODUCTION in June 2006. The Architecture provided the necessary structure to meet aggressive deadlines for issuance and use On August 27, 2004, President George W. Bush signed of the PIV smartcard. It also led to the development of Homeland Security Presidential Directive 12, Policy for a NASA’s Logical Access Control infrastructure to support Common Identification Standard for Federal Employees not only PIV smartcards, but all authentication credentials and Contractors [HSPD12]. At that time, NASA was in use at NASA. within months of deploying its first smartcards for physical access to its facilities. NASA had also initiated projects for Use of the Zachman Framework has transformed the way Identity Management and Access Management prior to that NASA looks at Logical Access Control, and has HSPD12. NASA responded to the directive by moving its positioned NASA to provide robust attributed-based access existing projects for smartcard badging and physical access control in the future. In this paper, we will discuss the control, identity management, and account management Logical Access Control System (LACS) we are under a single umbrella program. The projects individually implementing at NASA, changes in the way NASA views re-examined and adjusted their requirements to meet Identity Trust and Level of Assurance, technical challenges HSPD12 and its supporting documents. However, it to implementation, and our future vision for Identity, became clear by early 2006 that the projects were still Credential, and Access Management. being developed and implemented in a fairly stovepiped fashion. Integration requirements were not well Categories and Subject Descriptors understood or managed. K.6.5 [Management of Computing and Information Systems]: Security and Protection In June 2006, NASA began the development of the business architecture for Identity, Credential, and Access Management, while we continued system implementation to meet aggressive deadlines for issuance and use of the © 2009 Association for Computing Machinery. PIV smartcard. ACM acknowledges that this contribution was authored or co-authored by an employee, Developing the business and system architecture not only contractor or affiliate of the U.S. Government. As helped to identify integration points among the projects, such, the Government retains a nonexclusive, but also highlighted areas that were not being addressed by royalty-free right to publish or reproduce this existing projects. One of the missing elements was the article, or to allow others to do so, for Government Logical Access Control System (LACS). The Logical purposes only. Access Control Integration Team (LACIT) was chartered in October 2006 to fill this gap. IDtrust '09, April 14-16, 2009, Gaithersburg, MD In this paper, we will discuss how we implemented the Copyright 2009 ACM 978-1-60558-474-4…$5.00 LACS at NASA to meet the requirements of HSPD12 and prepare NASA for comprehensive ABAC. We will explain improve the user experience. The requirements for how we used the Zachman Framework for Enterprise Identity, Credential, and Access Management provided a Architecture [Zachman] to develop an integrated enterprise derived requirement for a single Identity and Credential architecture for Identity, Credential, and Access management system, single AD forest, and single directory Management. We will then provide an overview of infrastructure. NASA’s LACS requirements and use cases. We will When NASA merged its projects to meet HSPD12 examine how NASA’s view of Identity Trust has changed requirements, a project management compliance audit was due to HSPD12 and National Institute of Standards and conducted to determine the project organization and Technology (NIST), Special Publication 800-63, Electronic implementation changes that were needed to more closely Authentication Guideline [SP80063], and explain our need integrate the identity, credential, and access management for Level of Assurance (LoA) attributes to authorize access projects. A major recommendation from the review was to based on the credential presented. Finally, we will look at apply the Zachman Enterprise Architecture (EA) NASA’s future plans to implement a robust ABAC framework to ensure successful implementation of architecture. HSPD12 requirements. 2. THE NASA ENTERPRISE Designing, implementing, and transitioning to a completely new infrastructure that impacts every NASA worker on a NASA is comprised of 10 major field centers, plus daily basis was no simple task. We were, in fact, changing additional facilities. The NASA workforce includes 20,000 the basic enterprise architecture of the Agency. civil servants and 80,000 permanent, on-site contractors. NASA systems are accessed by tens of thousands of 3. USE OF THE ZACHMAN FRAMEWORK additional partners at universities, corporations, and other US and foreign governmental entities throughout the The Zachman Framework for Enterprise Architecture world. Unlike most federal agencies, NASA requires a [Zachman] is a methodology for developing large, complex large number of remote and foreign users to access its systems starting with scope, then working through layers systems in order to meet its mission. The scope of our for the Business, System, and Technology models, and implementation is the entire NASA enterprise. finally providing detailed representations of the system. Each layer addresses Data, Function, Network, People, NASA has historically operated in a highly decentralized Time, and Motivation. IT environment. Each field center, and often each project, would develop its own technical infrastructure to provide The Clinger-Cohen Act was passed by Congress in 1996, access to its systems. The result is that, just prior to and required Federal Agency Chief Information Officers to implementation of our consolidation efforts, NASA had: develop, maintain, and facilitate integrated systems architectures. Since that time, a series of laws, • 13 different identity management systems requirements and guidance issued by Congress, OMB, • 12 different X.500 systems fed from the identity Treasury, NIST, GAO and the CIO Council have management systems established the Federal Enterprise Architecture Framework. Agencies are required to include certified Enterprise • 28 RSA token infrastructures Architects on their staffs, and report EA metrics on an • Hundreds of Active Directory domains annual basis to OMB. Account management and authentication were also highly The Zachman framework is recognized as the standard for decentralized. NASA had at least 7 different account classification of Business, System, and Technology layers management systems. Most access, however, was granted of the Enterprise. Other architecture frameworks, based on approvals on paper forms. including the Federal Enterprise Architecture Framework and The Open Group Architecture Framework utilize Of the approximately 3,000 applications in use at NASA, Zachman’s classification and differentiate themselves by about 1,000 used Active Directory to authenticate users. providing methodologies for development of the The remaining applications used local user tables and framework. custom authentication routines on an application-by- application basis. In June 2006, we commenced a series of workshops with a small group of subject matter experts to develop the Over the years, several attempts to consolidate and business model. The business model includes business centralize NASA’s Active Directory infrastructure failed processes, entity relationships, and definition of actors to due to the lack of political will to consolidate. HSPD12 perform the various tasks in the process. provided the regulatory impetus that NASA needed to consolidate its IT infrastructure, increase security, and As NASA builds out the Identity, Credential, and Access requirements of the Position, the Worker is subject to an Management architecture, the Zachman framework Investigation, and may require a Clearance. The Worker is continues to figure prominently in our development. The issued a Credential once the Investigation is successfully detailed business model is the precursor to any system adjudicated. enhancement. While the initial effort to develop the At the same time, either the Position or the Worker can be business model was difficult and time-consuming, we now granted Membership in a Community. A Worker or find that system enhancements move very quickly from the Community can be granted Access Permission to an Asset business process design through the system and technology or Asset Group. layers. Release reviews are efficient, and there is little re- work during the system design and implementation phases. 3.1 NASA’s Identity, Credential, and Access Management Business Architecture To communicate NASA’s business architecture to the greater NASA community, we created Figure 1, “The Really Big Picture.” Figure 1 was designed by consolidating and simplifying a number of entity/relationship diagrams, state models, and business processes. The figure is a simplification of the business architecture; therefore, some relationships are left out or simplified. It provides a high-level explanation of how our architecture works. A Position is created to perform some work for NASA. A Figure 1: NASA's Really Big Picture Position is assigned to a Worker. Based on the Figure 2: Access Management Business Processes When a Worker wants to access an Asset, s/he presents Permission to the Asset Group HCIE. One would have to his/her Credential to the Access Control device in order to delve into the code of the HCIE itself to discover this gain access through the Access Point to the Asset. relationship. 3.2 Access Management Business and System Less obvious, but no less important, we do not have well- defined asset management processes to support access Models management. NASA does perform asset management per Figure 2 shows the list of Access Management business se: we have inventories of computer equipment and processes. (There are separate lists for Identity and management systems around them. However, those Credential Management.) systems are designed to manage the acquisition, ownership, The circled processes are those that have been implemented and disposal of assets. They are not designed to support at NASA. Notably, the entire set of Community access management to those assets. In the realm of logical Management processes is unimplemented at this time. assets such as applications, NASA is in the process of With no community management, the permission building its application asset inventory. management processes are also unimplemented with regard These to-be-implemented objects are the key to NASA to communities. moving beyond simple communities such as NASA civil As shown in Figure 2, NASA today is only able to assign servants, into more complex, approval-based communities an access permission from a worker to an asset. While such as projects. NASA’s core business is conducted some Basic Levels of Entitlement have been implemented through programs and projects, with multidisciplinary using standard attributes, NASA does not have a system in members matrixed from across the Agency. Project place today to register the access permissions granted on membership cuts across organizational and geographic the basis of attributes. For example, we allow any NASA boundaries, and changes as projects are initiated, civil servant access to our Human Capital Information implemented, and completed. Community Management is Environment (HCIE), based on the identity attribute needed as a precursor to providing ABAC to projects’ IT (employer=NASA) found in our directory. However, there assets. is no system that defines the Community of NASA civil Figure 3, Authenticate Access Request, is shown as an servants, and no registry that shows that the Community, example of a detailed business process. NASA Civil Servants, has been granted an Access Figure 3: Business Process: Authenticate Access Request Human Capital Mgmt Procurement Position Management Contract/Agreement Mgmt Organization/Program Structure Management Identity Management Credential Planning Credential Inventory Position Assessment Production Planning Identity Lifecycle Mgmt Template Management Component Supply Mgmt Identity Maintenance Standards and Controls Biometrics Management Foreign National Foreign Nationals Mgmt Investigation Tracking Credential Mgmt Investigation Management Credential Production PKI Management Credential Lifecycle Mgmt E-QIP System Credential Condition Mgmt Certificate Management Identity Management Investigation Management Credential Management Facility Management Facility Inventory Mgmt Access Management Asset Management Security Clearance Asset Inventory Mgmt Asset Group Mgmt Security Clearance Mgmt Access Rule Management Included in Release 1.x IT Management Included in Release 2.x IT System Inventory Mgmt Included in Release 3.x Authorization Authentication Community Management Access Control Mgmt Permission Management Access Authentication Figure 4: System Model When the Business Model was completed, the System Model was derived from the Business Model. The System 4. TECHNICAL MODEL OF LOGICAL model sets boundaries for identity, credential, and business ACCESS CONTROL management, both internally and externally. In the federal arena, use of the PIV smartcard is generally Once the System Model is derived, assignment of divided into Physical Access Control Systems (PACS) and responsibility can take place. What we found at NASA Logical Access Control Systems (LACS). LACS includes was that several systems had overlap of responsibility, and any logical access including desktop authentication and other areas had not been assigned to any project. The access to systems and applications. authentication and authorization systems were assigned to When HSPD12 was signed, NASA was nearing operational three separate projects: NASA’s Consolidated AD project, rollout of its own smartcard infrastructure for Physical the NASA Enterprise Directory project, and Access Control. However, use of the smartcard for Logical eAuthentication. There was overlap, but no comprehensive Access Control had not yet been addressed. NASA’s IT plan to ensure that these three worked as a system to meet infrastructure has historically been highly decentralized; NASA’s authentication and authorization requirements. systems tend to be implemented at the project or program Therefore, use of Zachman led directly to the establishment level. Authentication is implemented, in most cases, on an of the Logical Access Control Integration Team (LACIT), application-by-application basis. Early attempts to manage which was chartered to address single- and multi-factor the project to smartcard-enable NASA applications to meet authentication and authorization across the Agency. HSPD12 compliance requirements were unsuccessful. The LACIT’s scope was derived from the System Model major reason for this lack of success was that we could not depicted in Figure 4, to include the Authentication and clearly articulate how application owners should make their Authorization modules. applications “HSPD12 compliant,” because we did not have a well-developed strategy for compliance, nor an infrastructure that application owners could use to meet those compliance requirements. . Figure 5: Logical Access Control Framework LACIT was chartered to develop the high-level The framework includes the catchall requirement that the requirements for enterprise-wide one-factor and two-factor LACS must support all validated use cases. authentication. The team was chartered in part because the We identified the use cases by breaking down the work on the business and system models for Access components that are used in an access control transaction, Management revealed that smartcard-enablement of and then listing the types of components we might have. applications could not be addressed in isolation; rather, The components are: smartcard use within the entire spectrum of Logical Access Control at NASA had to be implemented. Smartcard • The credential being presented enablement includes a pre-requisite to utilize central authentication sources closely tied to vetted identities. The • The device being used to present the credential real effort on the part of application owners, therefore, is • The network location of the device being used not smartcard-enablement per se. It is migrating from local authentication to central authentication. • The system/device being accessed • The time conditions under which the access is 4.1 LACS Framework and Use Cases attempted LACIT developed a Logical Access Control Framework (Figure 5), and aligned its requirements with the We turned these into a natural-language construct. Taking Framework layers. The framework and its requirements are the first elements from each component provides an applied to all enterprise authentication services at NASA. example use case: A worker with a NASA PIV Card using It assures that all enterprise authentication services provide a NASA-managed PC on the Center Institutional Network the same level of robust authentication at each layer of the to access a resource on the device being used during framework. normal operations. We ran a program to derive all of the permutations of the use cases. The current raw result is 76,000 use cases, although not all are valid. For example, while a worker should be able to access resources on the items to the minimum necessary to achieve NASA’s device being used when the network service is unavailable, strategic goals. it is not reasonable to expect to access a remote application when the network service is not available. Removing 4.2 LACS Technical Implementation systematically those use cases we know are invalid, just Several systems comprise the LACS at NASA. Figure 7 over 60,000 use cases remain. shows these systems and their relationship with our Identity The addition or subtraction of a single element results in an and Credential management systems. order-of-magnitude change in the number of use cases that The Identity Management and Account eXchange must be addressed. This recognition has driven NASA to (IdMAX) system is the Authoritative distribution source attempt to remove elements from the list of valid use case for all NASA identities, including civil servants, options wherever possible. contractors, foreign nationals, and other affiliates. IdMAX The Use Case model (Figure 6) has helped to scope phases feeds our Common Badging and Access Control System of implementation in a way that is logical and manageable. (CBACS) with identity verification data needed to issue a For example, we are currently focused on implementing Personal Identity Verification (PIV) compliant smartcard those use cases that support institutional and administrative credential. IdMAX also contains the NASA Account systems being accessed from the institutional network. Use Management System (NAMS) workflows needed to issue cases supporting our Mission and specialized systems are other NASA Credentials, including Agency AD accounts, more unique and carry more risk, so they will be RSA tokens, and PKI encryption and signing certificates. implemented in later phases. NAMS supports access management to NASA applications as well. NASA has identified over 3,000 applications It also underscores that the complexity of the service is across the Agency. At this time, about 500 of those increased each time we add an item to one of our applications are integrated into NAMS for access component lists. We are therefore motivated to reduce the management. All applications are required to use NAMS for account management by the end of Fiscal Year 2010. Figure 6: Authentication Use Cases Figure 7: Technical Architecture The NASA Enterprise Directory (NED) provides both NED (for eAuthentication), or the NAF (for AD). Both the web-based lookup and LDAP-supported search of identity NAF and eAuthentication will be smartcard-enabled in FY data for NASA workers. 2009. The NASA Agency Forest (NAF, NASA’s enterprise AD), The Agency RSA service provides an alternate two-factor eAuthentication (built on Sun Access Manager), and authentication service for use cases where a smartcard Agency RSA provide authentication and authorization cannot be used. For example, IT remote users who will services based on the identities in IdMAX, and the never receive a smartcard, and access Moderate risk authorization attributes created through the NAMS process. systems at NASA, will require an alternate such as RSA. The authorization attributes are contained in either the We expect the use of RSA tokens to decline over time, as PIV smartcard use becomes ubiquitous, and smartcards compliance deadlines for all NASA applications that from other issuers are certified and accepted. stretch from 2008 – 2011. The standard requires that all applications utilize NAMS for access management by Primarily because of firewall segmentation between 2010. It requires that all applications utilize either the NAF Centers, the authentication systems of NAF, or eAuthentication by 2011, or have an approved deviation eAuthentication, and RSA are implemented in a distributed to utilize an alternate authentication method. (Agency model. In the example of the NAF, in order to meet or RSA is one of the possible deviations.) exceed all previous performance and reliability requirements, the NAF domain controllers are instantiated By the end of FY 2011, virtually all NASA applications on a one-to-one mapping to match legacy Center domain will be integrated into the Central Authentication and controllers. The motivation here is that newer equipment Authorization Infrastructure, and when this integration is with higher-performance CPUs and robust storage systems complete, attribute-based authorization based on located on the same network segments as previous communities becomes a real possibility. equipment will allow us to guarantee performance These assertions belie the enormous culture change requirements even if all of the exigencies of the previous imposed on the Agency to achieve these goals. Centers environment are not known. and projects must give up control of identities, credentials, HSPD12 directly motivated the change to centralized and access management and control to a central authority. Active Directory services. Centralization had been While there are significant technical challenges that must considered for many years, but Centers were unwilling to be met to implement the infrastructure, the change surrender autonomy due the perceived risk inherent in the management that we have had to implement to convince centralized structure. One of the arguments against our customers to actually use the infrastructure is far more centralization included the classic “risk in putting all your difficult. eggs in one basket”. NASA mitigated this concern by The benefits to the Agency are clear: improved security implementing a strong commercial Security Information and cost containment benefits, brand-new opportunities for and Event Management (SIEM) system to monitor the inter-center collaboration, and the ability to access all NAF. Ultimately the prospect of solving the relatively services from any NASA center as well as remote complex issue of integration of smart card logon once locations. It is more difficult to demonstrate the benefits to centrally versus many times over in each AD instance was centers and projects until some critical mass of applications finally enough to sway the argument to consolidate to one have integrated with the new infrastructure. Yet those Active Directory infrastructure. benefits are real: improved user experience through the use 4.3 If You Build It, Will They Come? of single sign-on, faster and more convenient access to a suite of applications through a central, on-line access NASA’s LACS is largely built. Migration to the Agency management system tied directly to the authorization AD infrastructure is underway, and all NASA centers will source for the application, and improved mobility, be migrated to the Agency AD infrastructure by the end of supporting users as they move from center to center, travel, 2009. Over 700 applications that are integrated with local or telecommute. AD domains today will become part of the Agency AD infrastructure as part of this migration. 5. IDENTITY TRUST NASA’s eAuthentication service has been available for HSPD12 and FIPS Publication 201-1: Personal Identity about a year, and in late 2008, additional servers were Verification (PIV) of Federal Employees and Contractors distributed throughout the Agency to improve availability [FIPS201] established the requirements for a federally- of this re-constructed service. A few applications have interoperable credential for use in federal systems. On the been integrated with eAuthentication already, and several surface, this implies that a non-NASA federal worker need more are in development and test at the time of this writing. only present his or her valid federal credential in order to The Agency RSA infrastructure will be implemented in FY be granted access to the NASA system s/he needs. 2009 to consolidate NASA’s 28 RSA implementations and ensure a consistent process for RSA token issuance, tied to This premise is sound as far as authentication goes; vetted identities in IdMAX. however, it ignores the necessary trust path for authorization to NASA systems. While NASA trusts other The work of LACIT culminated in the publication of a federal agencies to properly identify, vet, and credential NASA Enterprise Architecture Standard, Standard for their employees, only NASA has the right to determine Integrating Applications into the NASA Access access to a particular NASA asset. Management, Authentication, and Authorization Infrastructure, in August 2008. The standard includes These authorization requirements provide a derived corresponding one-to-one binding from the credential to requirement for NASA to create a “NASA Identity” for the person. In total, this mandates a central directory as a other federal workers, which references the credential source of authority for identities. All authorization issued by his/her home Agency. An identity record for decisions are ultimately bound to this central directory. For each non-NASA federal worker that has a business NASA, the central directory is the IdMAX system relationship with NASA is therefore included in NASA’s identities, and the authorization binding system is NAMS IdMAX system. Through NAMS, this NASA identity is (see section 3.2). granted an AD account as well as an entry in NED which Since there is now a single authoritative source of identities references the federal credential (UPN, subject alternate it provides an impetus to consolidate authentication name, etc.) NAMS is used to grant access to the NASA sources. NASA has chosen to have just two primary applications to which access should be granted. authentication sources. The first is Microsoft Active Directory as implemented in a NASA Agency Forest Because eAuthentication was only recently added as an (NAF), a single domain housing accounts for all users who Enterprise authentication service, it was implemented have a requirement for IT access. The second is Sun consistent with the new concept of identity trust. Access Manager as implemented in the eAuthentication Therefore, the discussion in this section focuses on the system. These two systems provide all necessary process impact to the AD infrastructure at NASA. and protocols for authentication of most applications within the Agency. (The RSA infrastructure is provided for 5.1 Previous View of Trusts within the applications as a “deviation” from the standard.) Agency [M0524] provides implementation guidance for usage of The advent of client-server and distributed systems the PIV credential. This memo provides definitions for the beginning in the 1980’s fostered work segregation by terms “Federally Controlled Facilities” and “Federally workgroups and departments. Systems were also deployed Controlled Information Systems”. Using this definitive on application boundaries. These approaches collectively guide NASA has logically drawn a perimeter for inside led to classic stovepiped systems. Each stovepiped system systems that must use one of the NASA authentication contained an island of identities. When business needs sources, NAF or eAuth. Any of the thousands of NASA required interoperability the solution was built bottom-up. systems or applications that do not use the two sources are The interoperability solution would often be case specific in deviation of a prescriptive NASA Enterprise and often relatively novel. Architecture standard (see section 4.3). These systems can Even single vendor solutions such as Microsoft NT only continue to operate if they have an accepted Deviation domains and later AD installations were grown from the Transition Plan. The process for filing a deviation is bottom-up. The number of Microsoft domains grew into defined in Enterprise Architecture Standard Operating the hundreds across the Agency. Interoperability among Procedures (SOP). Restating, all NASA systems must use these Microsoft domains could be obtained with the one of the two NASA authentication sources or have an creation of domain trusts. But, trusts in this model led to accepted Deviation Transition Plan in order to continue to haphazard partial meshes. The trust maintenance model operate with the NASA environment. was complex due to the n times (n-1) number of possible Thus, since all systems and applications must rely upon one trusts required. Even with a large number of trusts the of the two authentication sources, and these sources both mesh was never complete and the majority of users were rely on the same directory of identities, all internal trust not interoperable. When Agency-wide applications were requirements are removed. The only internal trusts deployed AD authentication could not be relied upon to be remaining at NASA are continuing to exist as a deviation. ubiquitously available. As a result, even large, Agency- wide applications relied on their own authentication service 5.3 Previous View of Trusts with External accessing an identity store they created for the application itself. Partners NASA has historically had some number of trusts with 5.2 The Effect of HSPD12 on Internal Trusts contractors, a business-to-government (B2G) relationship. The most significant of these historical trusts are used Per HSPD12 credentials must be “issued based on sound operationally in support of the Space Shuttle program. The criteria for verifying an individual employee’s identity”. major support contractors for Shuttle, such as Boeing and The process also mandates in person registration for the United Space Alliance, have established trusts with NASA. PIV authentication credential, the smartcard. The PIV These trusts arrangements are manifested as NT domain or credential itself is unique per person—there is only one AD trusts. The newer AD forest style trust is implemented PIV credential per person in the Agency. There is a as a Kerberos cross realm trust. At this point in time these subject alternative name must contain a User Principal trusts can only continue to operate as a deviation. Name (UPN) value. The suffix portion of this UPN must be predefined in AD as an alternate UPN suffix. There is Vendors have been approaching NASA for some years added complexity in that within a collection of AD forest with interest in developing PKI, AD, or credential trust trusts there can only be one forest which claims ownership relationships—credential trust in this case referring to of a UPN suffix. So, there is not yet an approach to smartcard and underlying PKI trusts. It is possible to provide authentication and authorization based on a worker exploit PKI trust through the Federal Bridge Certification provisioned with an external PIV credential. Authority (FBCA), now FPKI. This PKI trust arrangement generally has not been utilized for relatively classic Problems also arise with the legacy trusts as referenced in reasons, such as lack of PKI software maturity, lack of a 5.3 above. By definition, contractor identities housed in critical mass of client deployments, problems with contractor directories will not be HSPD12 based certificate status checking availability across disparate identities—that is unless they are replicas of NASA or networks, and perhaps mostly because PKI was a solution other Federal identities. Therefore NASA can not allow awaiting the right high-value problem. AD trusts have access control decisions to be based upon these identities flourished when the AD forest is a subset of the (again, per [M0524]). Even if by policy these identities contractor’s total population and where most of the could be used they would not be in IdMAX, and thus are identities in the forest are dedicated to the contract. Full subject to the same problems as discussed with external scale AD trust relationships with a vendor’s AD system PIV credentials. housing the complete set of identities, possibly numbering NASA’s current tactics for relationships are defined here: several hundred thousand, has generated security concerns and not been implemented. The concerns generally have to G2G: We will accept external PIV credentials for do with limiting authorization only to those individuals authentication and will implement changes to IdMAX and with a specific contract relationship with NASA. AD trusts authentication sources as necessary to create a NASA can imply a basic level of entitlement whereby the entire identity in IdMAX that is bound to the PIV credential community of a trusted domain has some level of access. issued from another agency. B2G: We will continue Active Directory trusts only as a 5.4 The Effect of HSPD12 on External Trusts deviation. These trusts will be one way whereby the As referenced in Section 5.2, [M0524] defines the contractor consumes NASA identities for authentication perimeter of systems and locations which NASA must purposes. NASA will not consume contractor identities for protect under [HPSD12]. NASA must use a PIV credential authentication. eAuthentication authentication has less for authentication and access to these systems and limitation than AD, but is still reliant on the IdMAX based locations. NAMS provides a workflow approval process identity. for defining the authorization of each worker to an NASA will consider Federation as the architecture and application. The NAMS process is implemented based technology matures. A primary problem NASA will face upon the directory of Agency identities, IdMAX. For with Federation is our NAMS requirement for a workflow NASA workers with NASA PIV credential the process is approval process for authorization policy based upon an complete for provisioning, authorization, and access for individual. In other words, any external user requires a NASA resources. static one-to-one mapping to a user object in IdMAX, and NASA is also directed to provide interoperability for other that user must be expressly granted access to any system. Federal PIV credentials. The credentials themselves are C2G: We have no firm requirements yet. NASA does expected to be portable and interoperable because of the not usually interact with citizens, except to provide public firm specifications for the PIV token per NIST data available to anyone. documentation. The credential will also be interoperable because the PKI is rooted in trust through the Shared Services Program (SSP). However, problems arise if the 6. LEVEL OF ASSURANCE individual with an external PIV credential is not housed in According to [M0524], the scope of HSPD12 extends to IdMAX. Without an existent identity in IdMAX there can persons on Federal facilities accessing systems on Federal be no approval process for defining authorizations. Also, facilities. For use cases out of the scope of HSPD12, NIST without an IdMAX identity there can not be an account guidance, especially [SP80063], applies. created in AD (in the NAF). Another technical issue for AD is that the PIV authentication certificate’s subject [SP80063] provides guidance for the authentication alternative name is used for identity binding; at least for credential’s level of assurance (LoA) which agencies Windows 2003 (Windows 2008 offers other options). The should require to access systems of differing security categorizations. (See NIST, FIPS Publication 199: Standards for Security Categorization of Federal basis. A user can log in to an eAuthentication-enabled Information and Information Systems. [FIPS199]) application using a userID/Password to a Low risk application, and be passed using the SAML token to any NASA has about 20,000 civil servants and about 80,000 other low risk application. Upon attempting to access the affiliates, ranging from contractors under formal contract to first moderate application, the user will be prompted that a University partners under loose agreements. Partners are stronger credential is required. world-wide, including citizens of designated countries. The issues regarding identity vetting of foreign nationals Within AD, level of assurance is not so easy to determine. are extensive and will not be addressed in this paper. Of Once a user has authenticated, it is the Kerberos ticket that note is that export control rules can restrict the types of is exchanged for access to AD-enabled systems. The ticket credentials that can be issued to our foreign partners, does not provide information about the type of credential depending on their citizenship and the country from which used to authenticate. This leaves NASA with a they are accessing NASA systems. predicament: either we presume that all AD-based authentication is only at Assurance level 2, or we lock AD According to [SP80063], a [FIPS199] Low system can down to smartcard-only authentication in order to ensure accept a level 2 credential (userid/password), whereas a Assurance Level 4 authentication. Neither of these options Moderate system requires a two-factor credential. [M0524] is practical. requires PIV credentials for all systems accessed by federal workers on federal facilities. This puts us in the odd Presuming that all AD-based authentication is only at position of requiring a higher LoA for the people we trust Assurance level 2 is problematic, since the Worker with an the most, e.g. NASA civil servants accessing applications AD-provided Kerberos ticket most likely got it through from NASA-managed devices while on a NASA network, smartcard login to the desktop. Yet, locking down AD to than the people we know the least about, e.g. IT Remote smartcard-only authentication is also impractical, since users with claimed identities accessing applications from there are multiple use cases we must support for workers unknown devices across the open Internet. who either do not have a smartcard, or do not have access to a desktop with the required reader and middleware to Given the extensive external partners at NASA, LACIT use the smartcard. developed a framework for the credentials that could be used by Remote IT Users. The Application Integration As we move forward, we will also need to distinguish Standard addresses the considerations for Application between PIV smartcards and other smartcards. Since a PIV Owners in determining which credentials to require for smartcard has an assurance level of 4, and other smartcards access to their applications. may only have an assurance level of 2 or 3, this distinction becomes important for access to higher-risk systems. What is important to note is that NASA will be accepting a NASA expects to issue non-PIV smartcards in the future to variety of credentials for the foreseeable future: NASA temporary employees including summer interns, userIds/passwords, RSA tokens, and PIV smartcards. As visiting scientists, and short-term contractors. As stated stated earlier, NASA has two primary LACS services, the before, NASA also plans to accept smartcards issued by NAF and eAuthentication, and one major alternate service: contractors and other entities, once a process for Agency RSA. Agency RSA accepts RSA tokens; the NAF certification and acceptance is established. It is therefore a accepts either UserId/password or Smartcards; and requirement that the authentication ticket, either SAML or eAuthentication accepts any of the three credentials. Each Kerberos, be able to provide information about credentials, of these LACS services will support both low- and certificate types, and possibly even certificate issuer moderate-risk systems, including those accessed remotely. information. This situation drives NASA’s requirement to be able to determine the LoA of the credential used as part of ABAC. NASA has advocated with Microsoft and the MIT We want to grant access to an application not only based Kerberos consortium to include the ability to determine on who the person is and the community to which s/he LoA in the Kerberos ticket presented by the user. belongs, but also based on the credential used to gain access -- we sometimes refer to this requirement as 7. NASA’S IDENTITY AND ACCESS Authorization based on the strength of Authentication. MANAGEMENT FUTURE The Security Access Markup Language (SAML) protocol Fiscal Year 2009 will see implementation of many used by NASA’s eAuthentication implementation supports components of NASA’s identity, credential, and access authorization based on the LoA of the credential presented. management architecture, particularly in the LACS arena. This provides NASA the flexibility to provide access to As of October 27, 2008, NASA had issued PIV smartcards applications at all FIPS risk levels through a single LACS, to over 90 percent of its civil servant and contractor with assurance level restrictions set on a per-application workforce. NASA has begun migration to the Agency AD service, the NAF, and migration will be completed at the process. We need information from the individual’s PIV end of FY 2009. All NASA [FIPS199] High and Moderate authentication certificate to include Subject Alternate systems will be integrated with NAMS by the end of FY Name—UPN. The UPN may contain any arbitrary user 2009, and LACS integration with the NAF and name. This user name and/or the PIV certificate Subject eAuthentication will be well underway. Both the NAF and DN will have to be retained within IdMAX and be made eAuthentication will be smartcard-enabled in FY 2009. available for evaluation during the authentication process. Smartcard-enablement of desktops will follow closely If a UPN is to be consumed then, as previously motioned, behind migration to the NAF, and will be largely complete the suffix matter of the UPN will also have to be retained. at the end of the fiscal year. The Agency RSA service will All PIV credentials are issued by a PKI Shared Service be implemented as well, consolidating the existing RSA Provider and are anchored under the FPKI Common Policy installations, and tying token credentials more closely to Root, and thus will be usable. Any future requirement to vetted identities in IdMAX. accept non-PIV credentials will require full evaluation of trust criteria prior to accepting any other anchors. We plan to continue implementing modules of our Business Architecture. As part of this effort, we plan to NASA’s acceptance of other non-PIV smartcards issued by implement an initial registry of simple communities, and industry is dependent on federal policy and process for register existing Basic Levels of Entitlement (registering certifying and accepting such credentials. Our industry access permissions from established communities to partners are very interested in NASA accepting their assets). We also intend to design and implement the credentials. NASA would prefer not to create its own process for ingesting PIV credential information from policy in this area; this policy should be consistent acrosss NASA partners who are issued PIV smartcards from other the federal government. Agencies into our IdMAX and LACS. As NASA has worked to implement robust ABAC, we We have referenced our need to perform authorization have found that the technology, while non-trivial to based on strength of authentication. We have also pointed implement, is less complex than the policy. HSPD12, out that this information is not available in current perhaps unwittingly, was a catalyst for NASA to implementations of Microsoft Kerberos. We, along with implement an architecture at the business and system levels several other large organizations, have asked Microsoft to that can support ABAC in the near future. And, we could implement this feature. Specifically, we would like to have not hope to solve our policy and technology needs for dynamic binding to a security group per the level of ABAC without our Zachman framework. assurance at time of authentication. This information would then be passed to policy decision points in the 8. ACKNOWLEDGEMENTS Kerberos ticket—in the Privilege Attribute Certificate (PAC) portion of the ticket. We would like the ability to We would like to thank Dale S. Mietla, Synfusion, Inc. for AND access control conditions to include both the normal his extensive work with NASA to understand and static group membership evaluation and this level of implement the Zachman framework for this project. assurance attribute. Further, we are asking for granularity in the authentication process to include group membership 9. REFERENCES assertion mapped to assertion of particular OIDs in the [HSPD12] Homeland Security Presidential Directive certificate policy extension. Of prime importance, the PIV (HSPD)-12, : Policy for a Common Identification Standard Authentication Certificate as specified in [COMMON] for Federal Employees and Contractors. Available at asserts OID id-fpki-common-authentication. This OID http://www.whitehouse.gov/news/releases/2004/08/200408 satisfies level of assurance 4, per [RELYING]. 27-8.html We have also referenced the need for NASA to ingest [Clinger-Cohen] Clinger-Cohen Act, Public Law 104-106, identities into IdMAX as a prerequisite to accepting section 5125, 110 Stat. 684 (1996). credentials from other organizations. Though there is prescriptive guidance for NASA to accept external PIV credentials for authentication, we still have a requirement [Zachman] J. Zachman et al, Zachman International to approve of the individual’s relationship with NASA Enterprise Architecture. Multiple publications available at: prior to granting any form of access to NASA resources. http://www.zachmaninternational.com/index.php. NAMS provides the workflow to define this relationship to NASA. The workflow includes the roles of requester, sponsor, and approver. Role holders are subject to rules [M0524] Office of Management and Budget, enforcing separation of duty. For external workers there is Memo M-05-24, Implementation of Homeland Security also a need for more data to be captured as part of this Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and [FIPS199] NIST, FIPS Publication 199: Standards Contractors. Available at for Security Categorization of Federal Information and http://www.whitehouse.gov/omb/memoranda/fy2005/m05- Information Systems. Available at 24.pdf http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB- 199-final.pdf [SP80063] National Institute of Standards and Technology (NIST), Special Publication 800-63, Electronic [COMMON] X.509 Certificate Policy for the U.S. Authentication Guideline. Available at Federal PKI Common Policy Framework, Version 3647 - http://csrc.nist.gov/publications/PubsSPs.html 1.4, August 13, 2008. Available at http://www.cio.gov/fpkipa/documents/CommonPolicy.pdf. [FIPS201] NIST, Federal Information Processing Standards (FIPS) Publication 201-1: Personal Identity [RELYING] Implementation Guidance for Relying Verification (PIV) of Federal Employees and Contractors. Parties Using the Common Policy Root, February, 2007. Available at http://csrc.nist.gov/publications/fips/fips201- Available at 1/FIPS-201-1-chng1.pdf http://tingwww.cio.gov/fpkia/documents/RPguidance0207. pdf Identity, Credential, and Access Management at NASA, from Zachman to Attributes Corinne Irwin Dennis Taylor VISION: Integrated, secure, and efficient information technology and solutions that support NASA Agenda • Introduction • Zachman Framework • Identity Trust • Level of Assurance • Conclusions April 14, 2009 ICAM at NASA 2 Introduction • NASA includes: – 20,000 civil servant employees – 80,000 on-site contractors – Additional partners world-wide • NASA’s system/application landscape includes: – 3,000 applications, most built in-house – Mission control, research labs, product fabrication, more – Every flavor of every operating system, hardware, software…. • Historically, NASA has been: – Highly decentralized – Autonomous Centers with a B-to-B network infrastructure – Characterized by weak CIO governance • HSPD-12 helped us: – Implement a robust Identity, Credential, and Access Management Architecture – Position NASA for use of ABAC and RBAC April 14, 2009 ICAM at NASA 3 Traditional ICAM - Parallel Environments User Identity Authentication Authentication Authentication Authentication Authentication Credential Credential Credential Credential Credential User User User User User Account Account Account Account Account Authorization Authorization Authorization Authorization Authorization Privileges Privileges Privileges Privileges Privileges Application Application Application Application Application Credit: Owen Unangst, USDA April 14, 2009 ICAM at NASA 4 Future ICAM – Enterprise Single-SignOn (User Perspective) User Identity Authentication Credential User Account Authorization Application Application Application Application Application Application Application Application Application Privileges Credit: Owen Unangst, USDA April 14, 2009 ICAM at NASA 5 Enterprise Architecture • Enterprise Architecture (EA) frameworks provide structure for developing complex, integrated systems • Ideally, one: – Develops an As-Is architecture – Develops a To-Be architecture – Performs gap analysis – Develops plan to move toward the To-Be architecture • NASA used Zachman to develop its ICAM architecture starting in 2006 • At a federal level, the ICAM Sub-committee was tasked in FY2009 with developing the segment architecture for Federal ICAM. April 14, 2009 ICAM at NASA 6 Zachman Framework April 14, 2009 ICAM at NASA 7 The Really Big Picture COMMUNITY ASSET GROUP A PPR O V ED Access Permission Rules ACCESS PERMISSION MEMBERSHIP POSITION WORKER ASSET CLEARANCE ACCESS REQUEST Approved! INVESTIGATION CREDENTIAL ACCESS ACCESS POINT CONTROL Implemented Objects April 14, 2009 ICAM at NASA 8 ICAM Business Processes April 14, 2009 ICAM at NASA 9 Example Business Workflow: Badge Renewal April 14, 2009 ICAM at NASA 10 ICAM Systems Model April 14, 2009 ICAM at NASA 11 Technology Model April 14, 2009 ICAM at NASA 12 Identity Management April 14, 2009 ICAM at NASA 13 Identity and Credential April 14, 2009 ICAM at NASA 14 Full ICAM Model April 14, 2009 ICAM at NASA 15 NCAD—Active Directory Forest and Domain Structure As-Is Structure To-Be CDR Structure To-Be Structure: Supports Migration Activities One Forest One Domain TBD/TPF ndc.nasa.gov April 14, 2009 ICAM at NASA 16 NCAD—Interim/Current Topology April 14, 2009 ICAM at NASA 17 NCAD TO-BE Topology April 14, 2009 ICAM at NASA 18 AD Consolidation Summary • Finally top-down versus grass-roots • Formal project methodology – System Engineering Methodology per NASA NPR 7123 – Project Management Lifecycle per NASA NPR 7120.7 • Detailed large project plan with linked tasks – Project plan maintained by an experienced project scheduler • Formality in test-set development – SIR-TP, SATS, ORTS, all with traceability • Project Manager experienced in large engineering development; experienced program managers for two major contractors leading effort • Brought in personnel with experience in similar consolidation efforts at Army, AF, and Navy-Marines • All eggs in one basket argument…SIEM April 14, 2009 ICAM at NASA 19 Identity Trust • FIPS 201 tells NASA to accept any valid PIV card (from any Federal Issuer) for authentication • Simple enough, except for technology and policy • Only NASA has the right to determine particular access rights —and we have a heavy duty system (NAMS) for this purpose • Internally, was a peck of AD trusts (many hundreds), but still wasn’t enough to be ubiquitous • Now, with NAF and eAuth, we are a single entity on the inside…with ubiquitous authentication service • No trusts necessary on the inside (NASA trusts itself) April 14, 2009 ICAM at NASA 20 Identity Trust External Trusts (G2G) • We will accept (To-Be) the PIV token from anywhere – Need to capture token information for NAF and NED – Need to provision IdMAX – UPN suffix provisioning in NAF – PKI trusts paths and revocation checks • We agree with concept of federated identities – Federation allows us to proxy In-person verification – Need to link identity to relationship with NASA – Need further Federal Guidance • Being worked within FPKI/ISIMC/ICAM subcommittee External Trust (B2G) • To Be worked sometime after G2G • More work needed on this April 14, 2009 ICAM at NASA 21 LoA Introduction: Tokens April 14, 2009 ICAM at NASA 22 LoA and HSPD-12 (To-Be) NIST 800-63 Requirements with M-05-24 and M-07-16 Overlays Acceptable Identity Check Accessed Application Minimum Acceptable Self From Type Credentials FIPS 201 proclaimed ID Check PIV process identity Anonymous Public Acceptable Acceptable Acceptable UserID/Password FIPS 199 Low UserID/Password Required Acceptable Non-Federally controlled facility Two-factor, such as: FIPS 199 PKI soft certificate Required Acceptable Moderate RSA Token Hard-crypto token, such as: Access to PII, RSA Token Required Acceptable FIPS 199 High PIV Auth Certificate Other Smartcard Federally controlled Any PIV Auth Certificate Required facility Application (Smartcard) April 14, 2009 ICAM at NASA 23 Missing—Capture of LoA on Logon April 14, 2009 ICAM at NASA 24 Missing—AuthZ based upon LoA April 14, 2009 ICAM at NASA 25 LoA Summary • We are going to be using a mix of primarily passwords and smartcards for a long time • We need our authentication service to provide an LoA attribute to our authorization mechanism – Authorization based upon strength of authentication • Our eAuth service (based upon Sun Access Manager) can provide this attribute through SAML like structures • We need Microsoft Active Directory to provide a similar functionality in their logon (KINIT, PKINIT) and resultant PAC authorization data • We need capability to map particular policy OID to security group – id-fpki-common-authentication means PIV card (only real measure) April 14, 2009 ICAM at NASA 26 Conclusions • A well-developed Enterprise Architecture is essential to ICAM implementation • NASA must implement Position and Community Management modules in order to support robust ABAC • Integrated data flow means data is only authoritative at the source, and changes can only occur at the source • Identity federation and LoA require additional maturity in the market • Technology is sometimes tricky, but politics is harder! • Single sign-on is a strong motivator for migration April 14, 2009 ICAM at NASA 27 Backup VISION: Integrated, secure, and efficient information technology and solutions that support NASA Use Cases April 14, 2009 ICAM at NASA 29 Future LoA Tokens April 14, 2009 ICAM at NASA 30 Personal Identity Verification (PIV) Cards as Federated Identities – Challenges and Opportunities Sarbari Gupta Electrosoft 11417 Sunset Hills Road, Ste 228 Reston, VA 20190 703-437-9451x12 sarbari@electrosoft-inc.com ABSTRACT + Can be rapidly authenticated electronically In this paper, we describe the challenges in using Personal + Is issued only by providers whose reliability has been Identity Verification (PIV) cards and PIV-like cards as federated established by an official accreditation process.” identities to authenticate to US Federal government facilities and systems. The current set of specifications and policies related to In response, the National Institute of Standards and Technology the implementation and use of PIV cards leave a number of gaps (NIST) published Federal Information Processing Standard (FIPS) in terms of trust and assurance. This paper identifies these gaps 201 – “Personal Identity Verification (PIV) for Federal and proposes approaches to address them towards making the PIV Employees and Contractors” [2] and several related Special card the standardized, interoperable, federated identity credential Publications (found at http://csrc.nist.gov/piv-program) with envisioned within Homeland Security Presidential Directive 12 detailed specifications on issuance and deployment of PIV cards (HSPD-12). to their personnel. The latest version of this standard is FIPS 201- 1 published in March, 2006. Categories and Subject Descriptors The goal of this standard is to support an appropriate level of K.6.5 {Management of Computing and Information Systems]: assurance in conjunction with efficient verification of the claimed Security and Protection identity of an individual seeking physical access to Federal facilities and electronic access to government information systems. The PIV card is a smart card based digital identity General Terms container with a collection of identity credentials that provide Management, Security, Standardization. graduated levels of assurance regarding the identity of the holder of the card. Keywords When implemented and deployed by Federal agencies, the PIV Authentication, Smart cards, PKI, Assurance, Federal Bridge card is envisioned to provide the attributes of security, Certification Authority, Authorization. authentication, trust and privacy using this commonly accepted identification credential. 1. BACKGROUND Homeland Security Presidential Directive 12 (HSPD-12) entitled 1.1 PIV Documentation “Policy for a Common Identification Standard for Federal NIST has published a suite of documents in support of PIV. These Employees and Contractors” was issued in 2004 to enhance are identified below. security, increase Government efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory, FIPS 201-1: Personal Identity Verification (PIV) of Federal Government-wide standard for secure and reliable forms of Employees and Contractors. This document specifies the identification issued by the Federal Government to its employees physical card characteristics, storage media, and data elements and contractors [1] that: that make up the identity credentials resident on the PIV card. “+ Is issued based on sound criteria for verifying an SP 800-73-2: Interfaces for Personal Identity Verification (4 individual employee’s identity parts). This document specifies the interfaces and card architecture for storing and retrieving identity credentials from a + Is strongly resistant to identity fraud, tampering, smart card. counterfeiting, and terrorist exploitation SP 800-76-1: Biometric Data Specification for Personal Identity Verification. This document describes technical acquisition and formatting specifications for the biometric 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 credentials of the PIV system. not made or distributed for profit or commercial advantage and that SP 800-78-1: Cryptographic Algorithms and Key Sizes for copies bear this notice and the full citation on the first page. To copy Personal Identity Verification. This recommendation identifies otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. acceptable symmetric and asymmetric encryption algorithms, IDtrust '09, April 14-16, 2009, Gaithersburg, MD digital signature algorithms, and message digest algorithms, and Copyright 2009 ACM 978-1-60558-474-4…$5.00. specifies mechanisms to identify the algorithms associated with The “X.509 Certificate Policy For The Federal Bridge PIV keys or digital signatures. Certification Authority (FBCA)” defines seven certificate policies to facilitate interoperability between the FBCA and other Entity SP 800-79-1: Guidelines for the Accreditation of Personal PKI domains. The policies represent different assurance levels Identity Verification (PIV) Card Issuers. This document indicating the strength of the binding between the public key and provides guidelines for accrediting the reliability of issuers of the individual whose subject name is cited in the certificate, the Personal Identity Verification cards that collect, store, and mechanisms used to control the use of the private key, and the disseminate personal identity credentials and issue smart cards. security provided by the PKI itself. Of these, the Medium-HW SP 800-87-1: Codes for the Identification of Federal and policy is of relevance to this paper. Federally-Assisted Organizations. This document provides the The “X.509 Certificate Policy for the U.S. Federal PKI (FPKI) organizational codes necessary to establish the PIV Federal Common Policy Framework” governs the public key Agency Smart Credential Number (PIV FASC-N) that is required infrastructure component of the Federal Enterprise Architecture. to be included in the FIPS 201 Card Holder Unique Identifier It incorporates six specific certificate policies of which two are of (CHUID). direct relevance to this paper: id-CommonAuth or id-CommonHW. SP 800-104: A Scheme for PIV Visual Card Topography. This FIPS 201-1 requires the PIV authentication certificate loaded on a document provides additional recommendations on the Personal PIV card to be issued under the id-CommonAuth or id- Identity Verification (PIV) Card color-coding for designating CommonHW policies or under a policy that is equivalent to the employee affiliation. FBCA Medium-HW policy. SP 800-116: A Recommendation for the Use of PIV FIPS 201-1 includes a detailed set of requirements related to Credentials in Physical Access Control. This document identity proofing, registration processes and security controls describes a risk-based approach for selecting appropriate PIV required to securely store, process, and retrieve identity authentication mechanisms to manage physical access to Federal credentials from the card. In many cases, the requirements levied government facilities and assets. by FIPS 201-1 are more stringent than the requirements stemming from one or both of the FPKI policies mentioned above. For the purposes of this paper, it is important to recognize the elements 1.2 PIV CREDENTIALS where the requirements of FIPS 201 differ from the policy The PIV card contains a number of mandatory and optional data requirements of these two FPKI policies. These are summarized elements that serve as identity credentials with varying levels of in the table below: strength and assurance. These credentials are used singly or in sets to authenticate the holder of the PIV card to achieve the level Table 1 - Differences in Requirements of assurance required for a particular activity or transaction. A FIPS 201-1 id-CommonAuth or FBCA Medium-HW Personal Identification Number (PIN) is required to activate the id-CommonHW policy card for privileged operations. policies The mandatory credentials on the PIV card are: NACI has to be NACI not required NACI not required initiated for Interim for regular for regular • Cardholder Unique Identifier (CHUID) PIV card. applicants. Only CA applicants. Only CA • PIV Authentication Private Key and X.509 Certificate NACI has to be personnel are personnel are completed for full required to undergo required to undergo • Biometric Object with cardholder fingerprints scope PIV card. background checks. background checks. The optional elements on the PIV card are: FBI fingerprint Fingerprint check Fingerprint check • PIV Card Authentication Key (CAK) and X.509 check required. not required. not required. Certificate (if CAK is asymmetric) Biometric collected for potential dispute • PIV Digital Signature Private Key and X.509 resolution purposes. Certificate Facial image Facial image not Facial image not • PIV Key Management Private Key and X.509 collected at collected if some collected. Certificate registration. other biometric is collected. • Cardholder Facial Image The applicant must Remote registration Remote registration The reader is directed to [2] for further details on any or all of appear in person at allowable; applicant of applicant possible these credentials. Registrar at least may avoid in-person through existing once prior to encounter prior to subscriber with a 2. U.S. FEDERAL PKI and FIPS 201 issuance. issuance. valid certificate at the same level; In this section, we present a brief overview of the related Federal applicant may avoid PKI policies to aid the understanding of the core thoughts in-person encounter presented in this paper. prior to issuance. FIPS 201-1 id-CommonAuth or FBCA Medium-HW requires the cardholder’s active participation is id-CommonHW policy submitting the PIN as well as the biometric sample. policies • BIO-A – The cardholder is authenticated by matching Two forms of One government One Federal his or her fingerprint sample(s) to the signed biometric original identity issued identification government issued data element in an environment with a human attendant source documents document which picture ID or two in view. The PIN is required to activate the card. This from list in Form I-9 includes or can be non-Federal IDs one mechanism achieves a very high level of assurance presented in original linked with of which is a picture when coupled with full trust validation of the biometric form. At least one biometric data of ID. template retrieved from the card, and requires the must be a applicant. cardholder’s active participation is submitting the PIN government issued as well as the biometric sample. picture ID. • PKI – The cardholder is authenticated by demonstrating Only designated Anyone with a valid No requirement for a control of the PIV authentication private key in a sponsors can submit credential issued sponsor for an challenge response protocol that can be validated using request for PIV card under id- applicant. the PIV authentication certificate. The PIN is required for an applicant. CommonAuth policy to activate the card. This mechanism achieves a very can act as a sponsor. high level of identity assurance and requires the Role separation Only one authorized Only one authorized cardholder’s knowledge of the PIN. implies that at least individual involved individual involved In each of the above use cases, except the symmetric CAK use two authorized prior to issuance of prior to issuance of case, the source and the integrity of the corresponding PIV individuals need to credential to credential to credential is validated by verifying the digital signature on the be involved prior to applicant. applicant. credential. The entity signing the credential objects resident on a issuance of card to PIV card is called a PIV Signer. The PIV Signer has a special applicant. certificate under the Common Policy Framework; however, in Identity proofing Third party audit Third party audit legacy and cross-certified PKIs under the Federal Bridge and registration required for required for environment, the PIV Signer can use a digital signature certificate process self- authorization to authorization to issued under policies equivalent to the Federal Bridge CA accredited by head operate CA. operate CA. (FBCA) Medium-HW and High policies. of agency. Card activated via Card activated by Card activated by 3.1 Decomposition of PIV Authentication and PIN. passphrase, PIN or passphrase, PIN or Authorization biometric. biometric. Identity credentials issued to conform to the PIV standard and related specifications can support a number of mechanisms for authentication of the user as described above. Assuming that technical interoperability have been achieved, the authentication 3. PIV AUTHENTICATION MECHANISMS of the holder of a PIV card can be decomposed into a series of Chapter 6 of FIPS 201-1 provides a series of authentication use activities as described below: cases that can be supported using the electronic credentials resident on a PIV card. They are presented here to facilitate the • Credential Integrity Validation – the relying party (RP) reader’s understanding of subsequent sections of this paper. needs assurance that the identity credential is not tampered • CHUID – The cardholder is authenticated using the • Credential Source Authentication – the RP needs to signed CHUID data element on the card. The PIN is not determine the identity and trustworthiness of the issuer of the required. This mechanism is useful in environments credential where a low level of assurance is acceptable and rapid • Issuer Authority Verification – the RP needs to verify that contactless authentication is necessary. the issuer of the credential has the authority to issue PIV credentials • CAK – The PIV card is authenticated using the Card Authentication Key in a challenge response protocol. • Credential Status Check – the RP may need to check that the The PIN is not required. This mechanism allows contact identity credential is currently valid and not revoked or contactless authentication of the PIV card without the • Proof-of-Possession Check – the RP may require the user holder’s active participation, and provides a low level of presenting the PIV card to prove that he or she is the rightful assurance. owner of the PIV card • BIO – The cardholder is authenticated by matching his The table below illustrates how each of the credentials present on or her fingerprint sample(s) to the signed biometric data a PIV card support the above decomposition steps. element in an environment without a human attendant in view. The PIN is required to activate the card. This mechanism achieves a high level of assurance and Table 2 - CHUID Authentication Table 5 - PKI Authentication Activity Details of execution Activity Details of execution Integrity Validation CHUID signature validated Integrity Validation PIV Authentication certificate signature validated Source CHUID Signer certificate trust path Authentication validated to trust anchor Source PIV authentication certificate trust path Authentication validated to trust anchor Issuer Authority id-PIV-content-signing asserted within Check extendedKeyUsage extension of Signer Issuer Authority Certificate issuer asserts id-Common-HW certificate, or, Check policy, or, explicit trust of certificate explicit trust of CHUID Signer issuer certificate/key certificate/key Status Check Revocation check of PIV Authentication Status Check Revocation check of PIV Authentication certificate certificate (if practical) Proof-of-Possession User provides PIN to activate PIV card ; Proof-of-Possession - uses private key on card in challenge response scheme to match PIV Authentication certificate Table 3 - CAK Authentication Activity Details of execution Following successful completion of some or all of the steps Integrity Validation CHUID contents used in CAK derivation above, the RP knows the identity and a set of attributes of the PIV (possibly 1 ) cardholder with varying degrees of certainty and assurance. The next step is to determine whether the cardholder can be granted Source Issuer key used in CAK derivation access to the requested physical or logical resource. This access Authentication (possibly1) control decision is typically based on one of the following Issuer Authority Explicit trust of PIV card issuer as models: Check authoritative (possibly1) • Identity-based access – the identity of the authenticated Status Check Backend channel status queries (if subscriber determines the authorization that may be granted. practical) This model is appropriate when very fine-grained access provisioning and access revocation is required. For example, Proof-of-Possession PIV card presented can perform challenge a specific Federal employee who is on detail to another response to prove control of a CAK that agency for an extended period may be provisioned access matches derived/registered CAK based on their FASC-N. • Role- or Group-based access – authorization is determined Table 4 - Biometric Authentication based on whether the identity is part of a broader group or Activity Details of execution set or individuals. This model is useful for rapid access provisioning and de-provisioning of groups of users. For Integrity Validation Biometric object signature validated example, all users from a particular agency may be Source Biometric Signer certificate trust path provisioned access rapidly by allowing access to anyone Authentication validated to trust anchor whose PIV agency code matches the target agency. Issuer Authority id-PIV-content-signing asserted within • Attribute-based access - various other attributes (or Check extendedKeyUsage extension of Signer combinations thereof) are evaluated to determine the certificate, or explicit trust of CHUID authorization for the PIV cardholder. These attributes may be Signer certificate/key retrieved from the PIV card or from attribute authorities through backend channels. This model is useful to establish Status Check Revocation check of PIV Authentication specific criteria for access without limiting access to specific certificate (if practical) individuals or groups. For example, users who are from a Proof-of-Possession User provides PIN to activate PIV card; particular agency and whose NACI has been completed provides biometric sample which is successfully may be granted access to a resource. matched to biometric object on card 4. PIV COMPATIBLE AND PIV INTEROPERABLE CARDS As the Federal government rolls out PIV cards for Federal employees and contractors, various other segments of government (e.g., state and local) and industry are also adopting the standards 1 specified for PIV cards. These organizations desire to interoperate A possible symmetric CAK implementation could use the with Federal agencies. To this end, the Federal Identity CHUID and Issuer key as inputs to derive a unique CAK for Credentialing Committee (FICC) defined two new categories of each PIV card. identity credentials that are functionally and technically similar to PIV cards, and may be accepted for access to Federal facilities The challenges in accepting identity credentials as federated and systems [4]. identities in each of the above scenarios are described the sections below. The primary challenges in making these non-Federally issued identity credentials interoperable are that non-Federal organizations cannot: 5.1 Non-Local Agency PIV Cards In accordance with HSPD-12 and FIPS 201, only Federal 1) Satisfy the requirement to conduct a National Agency agencies can issue PIV cards to Federal employees and Check with Inquiries (NACI) on Subscribers contractors. HSPD-12 requires that agencies “require the use of identification by Federal employees and contractors that meets the 2) Issue digital certificates under the Common Policy Standard in gaining physical access to Federally controlled Framework facilities and logical access to Federally controlled information 3) Create Federal Agency Smart Credential Numbers systems.” As agencies deploy PIV-enabled authentication (FASC-N) since these numbers include an Agency mechanisms for physical and logical access, they need to evaluate Code that is only capable of supporting Federal the risks posed by acceptance of PIV cards issued by other agencies. agencies. PIV-Compatible cards conform to the technical specifications for HSPD-12 requires that PIV cards be “issued only by providers PIV but do not support the trust and assurance of PIV cards. whose reliability has been established by an official accreditation process.” NIST has published SP 800-79-1, “Guidelines for the PIV-Interoperable cards conform to the technical specifications Accreditation of Personal Identity Verification Card Issuers” to for PIV and additionally have been issued in a manner that serve as a framework for accreditation [3]. However, accreditation supports trust by Federal relying parties. Specifically, these cards is essentially an agency’s internal risk-based decision to authorize must include an authentication certificate issued by a provider operation of a system. In the context of HSPD-12, accreditation is cross-certified with the Federal Bridge certification authority the subjective process of determining whether a PIV card issuer is (FBCA) at Medium-HW policy and require subscriber registration compliant with FIPS 201-1 and related specifications. Each through an identity proofing process that satisfies NIST SP 800- agency applies its own level of rigor to the compliance checking 63 Level 4 requirements. to determine whether their PIV card issuer can be accredited. FIPS 201-1 does not require an independent audit of the issuance 5. PIV CREDENTIALS AS FEDERATED and management processes for PIV cards. While the PKI IDENTITIES - CHALLENGES credentials resident on the PIV card are issued through an A federated identity supports portability of identity information infrastructure that mandates an independent annual audit, the across disparate security domains. This allows users of one additional requirements that pertain to a PIV card are never security domain to obtain services from a second security domain subjected to an independent audit. without the need for each domain to administer redundant The decision to accept PIV cards issued by other Federal agencies identities for the same user. In promoting a “Government-wide becomes even more complicated because HSPD-12 does not standard for secure and reliable forms of identification”, HSPD- apply uniformly to all Federal agencies. HSPD-12 states that only 12 inherently envisions the use of the PIV card for access to “executive departments and agencies” need to implement a various Federally controlled facilities and information systems. program in compliance with the directive. Effectively, this Thus, an implicit goal of HSPD-12 is to facilitate the use of the implies that Federal government organizations that are outside the PIV card as a federated identity across the Federal government. executive branch are not mandated to implement HSPD-12 When an agency accepts credentials on PIV cards or PIV-like compliant programs. Although not required to do so, many of cards issued by organizations outside of their own agency, it these non-executive branch agencies have decided to implement constitutes a use case of “federated identity”. [Note that using identity credentials technically equivalent to PIV cards (including local agency PIV cards for authentication and authorization is not PKI certificates issued through the Common Policy Framework considered federated use.] There are at least three scenarios of for Subscribers as well as PIV Signers) – however, many of the federated use of PIV or PIV-like cards as described below. process-oriented requirements of FIPS 201-1 are not being followed by these agencies since they are not required to comply • Non-local Agency PIV cards – An agency allows the with HSPD-12. Typically, these same agencies have decided not use of PIV cards issued by other Federal agencies as a to accredit their issuance systems using the framework in NIST means of authentication and subsequent authorization to SP 800-79-1. As a result, while the PIV cards from these agencies agency controlled facilities and systems. are technically indistinguishable from PIV cards issued by executive branch agencies that have followed all required • PIV-Interoperable cards – An agency allows the use of processes, they are, in essence, inferior in terms of the vetting and PIV-Interoperable cards as defined by the FICC for due diligence and hence do not have the same level of assurance. authentication and authorization to agency controlled facilities and systems. Another concern in using the CHUID and biometric objects on the PIV card as a basis for authentication is that the integrity and • PIV-Compatible cards - An agency allows the use of source of these objects have to be verified through validation of PIV-Compatible cards as defined by the FICC for the signature on the CHUID and biometric objects as described authentication and authorization to agency controlled earlier. When the PIV card is issued by an agency that obtains facilities and systems. PKI certificates through the Common Policy Framework, the PIV content signing certificate is clearly distinguishable through the presence of the id-CommonHW policy identifier and an extended • A relying party agency may only accept PKI based key usage of id-PIV-content-signing. However, when the PIV authentication for holders of non-local PIV cards. card issuer is using a legacy branch of the Federal PKI (e.g., one that is directly cross-certified with the FBCA) there is no obvious 5.2 PIV-Interoperable Cards way to differentiate a PIV content signing certificate from a As mentioned earlier, PIV-Interoperable cards are required to regular signature certificate issued under a policy equivalent to include an authentication private key and certificate that can be the FBCA Medium-HW policy. validated through the FBCA under Medium-HW policy. In essence, it is entirely possible that a regular user who has a Additionally, NIST SP 800-63 Level 4 registration requirements digital signature certificate asserting the equivalent of Medium- need to be met by PIV-Interoperable cards. HW policy within the FBCA trust environment, can create PIV- Since the authentication certificate on the PIV-Interoperable card like cards with digitally signed fictitious CHUIDs – a Federal is issued under a policy equivalent to the Medium-HW policy of relying party that verifies the signature on this type of CHUID the FBCA, the assurance provided by this certificate (and would typically consider the CHUID to be trustworthy since the corresponding private key) is very high. However, if the relying signer’s certificate can be validated through the FBCA; yet, this is party desires to use the CHUID, biometric or CAK credentials clearly a scenario that needs to be detected by the relying party to loaded on the PIV-Interoperable card, the assurance level quickly prevent fraudulent CHUIDs being used to gain access. It may be drops off to nearly nothing. This is because the Medium-HW noted that only trusted Certification Authorities (CAs) can issue policy of the FBCA or requirements for Level 4 identity proofing the PIV authentication certificate, so this credential is not under NIST SP 800-63 do not include the collection of biometrics vulnerable to the same type of weakness as the signed CHUID during subscriber registration, nor do they include any form of and biometric objects. background checking or role separation during registration and The above concerns are summarized below. issuance. Table 6 - Risks of Non-local Agency PIV Cards Additionally, for the same reasons described in the previous section on PIV cards issued through legacy PKIs, there is no way Scenario Risk to distinguish that the signer of the CHUID or biometric is an Independent audit of Agencies accepting non-local authoritative signer rather than just another user with a digital compliance not required PIV cards don’t have assurance signature certificate within the FBCA environment. In summary, by HSPD-12; only internal about the rigor of the SP 800-79- the CHUID and biometric credentials on a PIV-Interoperable card risk based accreditation 1 accreditation. have little or no assured association to the identity asserted within using SP 800-79-1. the authentication certificate on the same card. Relying party HSPD-12 mandate does Agencies accepting PIV cards agencies deciding to utilize PIV-Interoperable cards need to not apply to non- from non-Executive branch exercise the utmost discretion in choosing to use the CHUID, BIO Executive branch agencies have little assurance of and BIO-A authentication mechanisms with PIV-Interoperable agencies. compliance with HSPD-12 cards. Agencies with legacy PKI Agencies accepting PIV cards The above concerns are summarized below. don’t have a mechanism to from Issuers that use legacy PKI Table 7 - Risks of PIV-Interoperable Cards indicate authorized PIV certificates have a low level of object signers assurance in the integrity of the Scenario Risk CHUID and BIO objects on the No independent audit or SP Agencies accepting PIV- card. 800-79-1 accreditation Interoperable cards have little required for PIV- assurance of compliance with Interoperable cards HSPD-12. The mitigation strategies to address the identified concerns are as follows: No mechanism to identify Agencies accepting PIV- authorized signers of data Interoperable cards have a low • A relying party agency may analyze the issuing objects on PIV- level of assurance in the integrity agency’s NIST SP 800-79-1 accreditation process and Interoperable cards. of the CHUID and BIO objects on assessment results. The former may additionally require the card. targeted assessments of the latter agency’s PIV issuance activities to more adequately identify the risks of accepting the issuing agency’s PIV cards. The mitigation strategies to address the identified concerns are as • A relying party agency that wants to allow CHUID and follows: BIO authentication for PIV cards issued by another • A relying party agency may require that the issuer of Federal agency, can import the PIV Signer certificates PIV-Interoperable cards demonstrates that it has from the second agency as trusted certificates (after performed a thorough assessment of their issuance careful vetting of the second agency’s processes related facility and processes based on the NIST SP 800-79-1 to issuance of the CHUID and biometric objects); this guideline and are willing to make the results of the would ensure that only signed PIV objects from verified assessment available for review. non-local PIV Signers are accepted for identity • A relying party may wish to include the certificate of authentication purposes. the PIV Signer for each approved PIV-Interoperable card issuer as an explicit trust anchor rather than 7. STRATEGIES FOR RAPID accepting any Medium-HW signing certificate through the FBCA – this limits the acceptable signers of CHUID ELECTRONIC AUTHENICATION OF and biometric objects. NON-LOCAL PIV AND PIV-LIKE CARDS HSPD-12 establishes policy for secure and reliable forms of • A relying party agency may wish to perform identification that can be “rapidly authenticated electronically.” background checking (such as NACI) on the subjects of When using non-local PIV or PIV-like cards, this becomes PIV-Interoperable cards prior to allowing them access difficult since the types of authentication mechanisms that allow to federal facilities and systems. for rapid authentication – namely, CHUID, CAK, BIO, BIO-A – • A relying party agency may only accept PKI based have little or no assurance. The PKI authentication mechanism is authentication for holders of PIV-Interoperable cards. the only one that provides a reasonable level of assurance, While these techniques definitely hinder interoperability, an however, this requires contact readers, PIN use, and possible agency with a low risk tolerance level may wish to employ one or fetching of online revocation lists. In this section, we describe a more of these to allow the controlled acceptance of PIV- novel approach to rapid electronic authentication of non-local PIV Interoperable cards as federated identities. and PIV-like cards. Consider the scenario where an employee of Federal Agency A 5.3 PIV-Compatible Cards needs to work at the facility of Agency B for six or more months. PIV-Compatible cards suffer from all of the assurance related This scenario occurs very often when agency employees are on drawbacks of PIV-Interoperable cards. In addition, there is no detail to another agency. One very effective way to allow this basis for trusting any of the digitally signed credentials on the non-local person rapid but secure authenticated access to Agency card. Relying party agencies wishing to accept PIV-Compatible B’s physical facilities may be use a hybrid PKI-CAK scheme. In a cards for access to facilities and systems should exercise the “Visitor Enrollment” step at Agency B, the employee of Agency utmost caution and perform out of band due diligence of issuance A can present their PIV card to the physical security group. The processes and trustworthiness of the credentials on the PIV latter employs tools (like the PIV Trust Validation Tool being compatible card. developed by NIST) to perform a thorough validation of all of the credentials on the non-locally issued PIV card, including the 6. STRATEGIES TO IMPROVE CHUID, biometric object and PKI credentials. The tool performs full path validation and revocation checking of all digital ASSURANCE IN FEDERATED IDENTITY certificates needed to validate the credentials on this PIV card. USING PIV AND PIV-LIKE CARDS The cardholder validates that they know the correct PIN to In Section 5, we discussed assurance related challenges in using activate the PIV card, and his or her biometric samples match PIV and PIV-like cards issued by external organizations and those stored on their PIV card. At the end of the Visitor related mitigation options. This section offers some additional Enrollment step, Agency B has a high degree of assurance that the strategies to promote the use of PIV and PIV-Interoperable cards cardholder is the genuine owner of the PIV card presented and as federated identities. that the credentials on the card are trustworthy and unmodified. As the last step of the Visitor Enrollment step, a series of random In the near term, we recommend that the Office of Management challenge strings (perhaps five to ten) are issued to the PIV card and Budget (OMB) establish a clear policy that requires and the CAK is invoked to generate responses to each challenge Executive branch agencies to conduct a thorough accreditation of string. The challenge-response pairs are stored along with the their PIV card issuers prior to issuance of PIV cards; agencies cardholder’s unique FASC-N as a part of the physical access should also be required to report their PCI accreditation activities control database (PACS-DB). to the OMB on a yearly basis. Likewise, we recommend that OMB establish policy that PIV and PIV-like cards that are Following the Visitor Enrollment step, when this non-local accepted as a basis for allowing access to Federal facilities and individual needs to enter Agency A’s facilities, the contactless resources, are issued by accredited issuers (in accordance with SP reader at the entry point will likely detect that the CHUID is not 800-79-1). This creates an environment where non-Executive for a local subscriber. In this case, the PACS-DB record for that branch agencies and commercial PIV-Interoperable card issuers CHUID will be retrieved, and one of the stored challenges would undergo SP 800-79-1 accreditation if they wish their cards (selected randomly) will be issued to the visitor’s PIV card and to be accepted by other federal agencies. the CAK invoked to respond. The received response will be compared to the stored response for that challenge string, and on a In the long-term, it may be worth investigating whether the cost successful match, the visitor will be considered adequately of implementing a third-party audit and compliance regime for authenticated. The FASC-N associated with that PACS-DB issuers of PIV, PIV-Interoperable and PIV-Compatible cards can challenge-response pair will then be used for the authorization be balanced against the improved security and ease of federation decision for the targeted facility. Since this CAK based challenge between the digital identities of government and commercial response scheme can be performed with a contactless reader organizations. This would be very similar to the work being done without PIN submission, it allows for painless, rapid and secure by the Liberty Alliance Identity Assurance Expert Group in the authentication of the visitor. The assurance of this scheme can be context of the assurance levels for electronic authentication. further raised through additional mechanisms such as: • Periodic revocation checking of all registered visitors to eliminate the need to do revocation checking in real- time • Adding biometric authentication of the cardholder to strategies to improve the assurance in the credentials carried in match stored biometric objects (collected during the these non-local cards. We also presented a novel approach to registration step) higher assurance authentication of long-term visitors to a Federal facility through the use of a thorough Visitor Enrollment step that The above scheme is most rapid when a symmetric CAK is records challenge-response pairs for the CAK on the card. present on the external PIV card, but works with a asymmetric CAK as well. Certificate path development and validation in real- time is eliminated in the scheme since it is done during the Visitor 9. ACKNOWLEDGMENTS Enrollment step – occasional revocation checking is done in the My thanks to Nabil Ghadiali and Dennis Bailey on supporting the background to validate the current status of the certificates within refinement of the thoughts presented in this paper through lengthy the PACS-DB. When the visitor presents their PIV card for discussions. authentication and access to a facility, the CAK is invoked with known challenge response pairs to establish the identity of the 10. REFERENCES cardholder; additional assurance can be achieved by requiring [1] The White House. August 2004. Policy for a Common cardholder biometric matching with the enrollment record. Identification Standard for Federal Employees and Contractors. Homeland Security Presidential Directive/Hspd- Let’s consider the use of PIV-Interoperable and PIV-Compatible 12. DOI= cards by non-local individuals that need access to Agency A http://www.whitehouse.gov/news/releases/2004/08/2004082 facilities for longer than six months. A similar Visitor Enrollment 7-8.html step can be followed which validates all of the credentials on the card and records the unique GUID of the card, biometric objects, [2] National Institute of Standards and Technology, March 2006. and challenge-response pairs generated by invoking the CAK on Federal Information Processing Standard (FIPS) Publication the card. Additionally, a background check on the visitor may be 201-1, Personal Identity Verification (PIV) of Federal performed if needed. Once the Visitor Enrollment record is Employees and Contractors. completed, the visitor can use their PIV-like card for rapid but [3] National Institute of Standards and Technology, June 2008. secure authentication for access to Agency A facilities. NIST Special Publication 800-79-1, Guidelines for the Accreditation of Personal Identity Verification Card Issuers. 8. CONCLUSION [4] Spencer, J. 2008. Beyond HSPD-12: Interoperability with In this paper, we discussed a number of trust and assurance issues non-PIV Credentials. Office of Governmentwide Policy, related to the use of non-local PIV cards and PIV-like cards as Federal Identity Credentialing Committee. Presentation at federated identity credentials. We presented a number of Federal Information Assurance Conference 2008. Personal Identity Verification (PIV) Cards as Federated Identities – Challenges and Opportunities Dr. Sarbari Gupta sarbari@electrosoft-inc.com 703-437-9451 ext 12 8th Symposium on Identity and Trust on the Internet (IDtrust 2009) April 14-16, 2009 Overview ƒ HSPD-12 requires Federal agencies to issue PIV Cards to all employees and contractors ƒ State/Local governments and commercial entities are issuing PIV-like Cards ƒ Immense opportunity to use PIV Cards (and PIV-like cards) as federated identities ƒ Challenges ƒ Strategies to promote federation Page 2 HSPD-12 Background ƒ Homeland Security Presidential Directive 12 ƒ Issued August 2004 ƒ Mandates Federal Agencies to issue common form of identification to Federal employees & contractors ƒ FIPS 201 - Personal Identity Verification (PIV) of Federal Employees and Contractors ƒ PIV Card: Smart Card based digital identity container with a set of identity credentials ƒ PIV Card Issuers are required to be accredited by Agency Official ƒ SP 800-79-1 – Accreditation Guide Page 3 PIV Card Credentials ƒ Mandatory Credentials: ƒ Cardholder Unique Identifier (CHUID) ƒ PIV Authentication Private Key and X.509 Certificate (PKI) ƒ Cardholder Fingerprints in Biometric Object (BIO) ƒ Optional Credentials: ƒ PIV Card Authentication Key (CAK) ƒ PIV Digital Signature Private Key & X.509 Certificate ƒ PIV Key Management Private Key & X.509 Certificate ƒ Cardholder Facial Image Pictures courtesy www.fedidcard.gov Page 4 Digital Identity Federation ƒ Identity federation can be defined as ‘the agreements, standards and technologies that make identity and entitlements portable’ across otherwise autonomous security domains [Burton Group] ƒ Goal: Enable users of one domain to securely access data or services of another domain Identity Provider Issuance Alice Service Alice Provider Authenticate & Access Resource Domain A Domain B Page 5 PIV-Interoperable & PIV-Compatible Cards ƒ Defined to promote identity federation between Federal and non-Federal Organizations ƒ Issued to personnel not eligible for PIV Cards ƒ State and Local Government ƒ Commercial Organizations ƒ PIV Compatible: ƒ Meets technical specifications for PIV Card ƒ Issuance process does not assure trust by federal relying parties ƒ PIV Interoperable: ƒ Meets technical specifications for PIV Card ƒ Issuance process assures trust in PKI Certificate o E-Authentication Level 4 Registration Requirements o PKI certificate issued under policy mapped to FBCA Medium-HW policy Page 6 FIPS 201 & FBCA Medium-HW Policy FIPS 201-1 FBCA Medium-HW policy NACI has to be completed for full scope NACI not required for regular PIV card. applicants. FBI fingerprint check required. Fingerprint check not required. Facial image collected at registration. Facial image not collected. The applicant must appear in person at Remote registration of applicant Registrar at least once prior to possible; applicant may avoid in- issuance. person encounter prior to issuance. Two forms of original identity source One Federal government issued picture documents. At least one must be a ID or two non-Federal IDs one of government issued picture ID. which is a picture ID. Only designated sponsors can submit No requirement for a sponsor for an request for PIV card for an applicant. applicant. Identity proofing and registration Third party audit required for process approved by head of agency. authorization to operate CA. Page 7 PIV Federation - Risks and Mitigations RISK MITIGATION PIV Card PKI – SSP PKI – OK Agency B BIO – SSP BIO – OK CHUID – SSP CHUID – OK (SSP PKI) Accreditation Quality - ? Review Accreditation Package PKI – FBCA Medium-HW PKI – OK PIV Card BIO – ? BIO – Explicitly trust Signer Cert Agency C CHUID – ? CHUID – Explicitly trust Signer Cert (Legacy PKI) Accreditation Quality - ? Review Accreditation Package Agency A Relying Party PIV-Interoperable Card PKI – FBCA Medium-HW PKI – OK Organization D BIO – ? BIO – Explicitly trust Signer Cert CHUID – ? CHUID – Explicitly trust Signer Cert (Non-Fed SSP) Accreditation not Reqd Require Independent Assessment PKI – ? PKI – Explicitly trust Issuer PIV Compatible Card BIO – ? BIO – Explicitly trust Signer Cert Organization E CHUID – ? CHUID – Explicitly trust Signer Cert (Org PKI) Accreditation not Reqd Require Independent Assessment Page 8 Fostering ID Federation with PIV-like Cards ƒ Suggestions: ƒ OMB Memo: Federal Relying Party can accept PIV- Interoperable Cards only from Issuers that are accredited/assessed using SP 800-79-1 ƒ Update Certificate Profiles for FBCA Medium-HW policy to indicate authority of PIV Object Signers o E.g., Common Policy supports id-PIV-content-signing certificate extension ƒ Align the requirements of FIPS 201, Common Policy and FBCA Medium-HW Policy ƒ Establish 3rd party audit regime for compliance with FIPS 201 requirements Page 9 Summary ƒ Immense opportunity to use PIV Cards (and PIV-like cards) as federated identities ƒ QUESTIONS?? Page 10 A Calculus of Trust and Its Application to PKI and Identity Management Jingwei Huang David Nicol Information Trust Institute Information Trust Institute University of Illinois at Urbana-Champaign Dept. of Electrical & Computer Engineering 1308 West Main Street University of Illinois at Urbana-Champaign Urbana, Illinois 61801, USA 1308 West Main Street jingwei@iti.illinois.edu Urbana, Illinois 61801, USA nicol@iti.illinois.edu ABSTRACT Trust issues exist throughout identity management mech- We introduce a formal semantics based calculus of trust anisms. As identified in [2], organizations have concern that explicitly represents trust and quantifies the risk as- about the business rules and mechanisms of their IdM part- sociated with trust in public key infrastructure (PKI) and ners with respect to the use of shared identity and credential identity management (IdM). We then show by example how information, how their partners protect the information, and to formally represent trust relationships and quantitatively the quality of identity information they provide; individuals evaluate the risk associated with trust in public key certifi- (identity owners) are concerned whether their identity in- cate chains. In the context of choosing a certificate chain, formation in an organization is secure (not being stolen or our research shows that the shortest chain need not be the revealed), how the information is used, and with whom it is most trustworthy, and that it may make sense to compare shared. These trust concerns are beyond technologies, but the trustworthiness of a potential chain against a thresh- are tightly associated with organizational and human behav- old to govern acceptance, changing the problem to finding iors. They are most difficult factors in identity management. a chain with sufficiently high trustworthiness. Our calculus Digital signature and certification, facilitated by PKI, is also shows how quantified trust relationships among CAs considered to provide secure communication in the Internet, can be combined to achieve an overall trust assessment of and as a fundamental tool to support IdM. However, many an offered certificate. risks exist in PKI. The number one risk identified by Ellison and Schneier [8], “Who do we trust, and for what”, reveals the risk of “imprecise use of the word ‘trust’ ”; to avoid Categories and Subject Descriptors such risk, the use of trust relationships in digital certification K.6.5[Management of Computing and Information Systems] and validation need to be precise and to be specific. An [Security and Protection]; I.2.11 [Distributed Artifi- incident [10] in which VeriSign issued an impostor two digital cial Intelligence] certificates associated with Microsoft still reminds people to think whether a certification authority (CA) can be safely General Terms trusted regarding the validity of the issued certificates. A number of PKI trust models have been proposed[33] [23] Theory, Measurement, Security [30] [37]. However, these studies focus on the relationships among certification authorities (or the structure of PKI), Keywords the certification path construction methods, and the perfor- Trust modeling, PKI, Identity management, Risk assess- mance of different PKI structures and path build methods. ment, Uncertainty, Semantics of trust, Social networks Left missing is the explicit and accurate representation of trust relationships and the quantification of risks associated 1. INTRODUCTION with trust in certification paths. In PKI, a certification path corresponds to a chain of trust Trust plays a crucial role and is recognized as a major relationships. In distributed IdM such as federated IDM risk factor in public key infrastructure (PKI) and identity systems, a credential chain also corresponds to a chain of management (IdM). This paper explicitly represents trust trust relationships. What do these trust relationships mean, with well defined semantics, and quantifies the risk associ- exactly? On what precisely does one entity trust another in ated with trust in PKI and IdM. a credential chain? What is the specific context of each trust? How do we quantify the risk associated with trust in a credential chain? Permission to make digital or hard copies of all or part of this work for In a typical public key validation model using PKI, at personal or classroom use is granted without fee provided that copies are least one certification path with shortest length needs to be not made or distributed for profit or commercial advantage and that copies found and validated. When multiple paths exist, typically a bear this notice and the full citation on the first page. To copy otherwise, to short path it chosen in order to minimize the work involved. republish, to post on servers or to redistribute to lists, requires prior specific From the risk point of view this implicitly assumes that each permission and/or a fee. IDTrust ’09, April 14-16, 2009, Gaithersburg, MD, USA certificate has the same level of risk, so the longer a certifica- Copyright 2009 ACM 978-1-60558-474-4 ...$5.00. tion path is, the higher the risk is. However, when quantified Trust Formalization and Quantification. evaluation of risk is introduced to PKI and different risks be- There are two major streams of research on trust formal- come associated with different certificates, some very inter- ization: logical approach and quantitative approach. The esting issues emerge. There are multiple certification paths, logical stream mainly focuses on the semantic structure of but which certification path should be chosen? Should more trust, the logical conditions and effects of trust. Examples than one certification path be considered? Should all cer- include [4] [6] [16]. tificate paths be considered? The quantitative stream mainly focuses on the uncertainty This paper explores some answers to these questions by of trust, trust quantification, and the models & algorithms of introducing and applying a formal semantics based calculus trust computing. Trust has been quantified in several ways, of trust [17] to explicitly represent trust, and to quantify at least including: linguistic values, graded levels, subjective risk associated with trust in PKI and IdM. probability, and probability distribution. In Marsh’s formal- This paper is organized as follows. Section 2 introduces ism [25], trust is quantified as a number in interval [-1, +1); related research; section 3 introduces a motivating scenario; +1 represents complete trust, -1 represents completely dis- section 4 discusses the semantics of trust; from a proba- trust, and 0 represents “no trust” (untrust). In this way, bilistic perspective, section 5 discusses the measurement of Marsh clearly discerns untrust and distrust; but the rela- uncertain trust; section 6 discusses sequence trust aggrega- tion between trust, untrust and distrust is somewhat over tion and parallel trust aggregation models; section 7 applies simplified. A trust value is either between trust and untrust the trust calculus to formally represent trust relationships or between untrust and distrust. Based on a through exam- and quantitatively evaluate the risk associated with trust ination of the concepts of trust developed in social sciences, in public key certificate chains. Section 8 summarizes the Marsh designed a set of formulas to express the relations in research and discusses future directions. trust; while Marsh’s model basically is a heuristic formal- ism. Most quantitative trust models define trust degree as a real value in interval [0,1], e.g. [27] [31] [20]. As addressed in [12], it is a problem regarding how to interpret the mean- 2. RELATED RESEARCH ing of 0, which could be untrust or distrust. Ding et al. [7] In this section, we review the research related to trust defined 1 as fully trust, 0 as fully distrust, and 0.5 as fully models for PKI, trust formalization and quantification. ignorant (untrust). This is a simple approach to discern un- trust and distrust. Most models in this school of research Trust in PKI. are heuristic, the measurement of trust is subjective, and A number of PKI trust models have been studied[33] [23][30] the semantics of trust is not formally defined. [37]. These studies focus on the relation among certification Josang [18] addressed uncertain belief representation by authorities (the structure of PKI), the certification path con- using subjective logic, in which an opinion regarding belief struction methods, and the performance analysis of different is represented as a triple (b, d, u), where b, d, and u denote structures and path build methods. However, explicit and the degrees of belief, disbelief, and uncertainty, respectively, accurate representation of trust relationships and the quan- and b+d+u = 1. Later, Josang et al.[19] applied the subjec- tification of risks associated with trust in certification paths tive logic to represent uncertain trust. Explicit inclusion of is not a consideration of that research. uncertainty u enables to express and explain degrees of trust, Most of public key certification path construction meth- distrust, and untrust, which takes into account incomplete ods[9][40][29] implicitly assume that a certificate has the knowledge about a trustee. We adopt this trust measure same level of risk, so a certification path with the shortest triple, but our model is different from Josang’s model[19]. length has the least risk of being invalid. However, different In their model, although belief opinion is formally modeled, certification authorities have different levels of rigor in the but the semantics of trust is not formally defined, and the identity verification they apply before issuing a certificate, relation between belief and trust is not modeled; hence, their so that different certificates have different levels of risk. trust model was subjectively defined as a heuristic formu- Reiter and Stubblebine [36] work towards a quantitative lation. Although they introduced degree of distrust, their evaluation of risk by studying the metrics for authentica- trust derivation failed to clearly discern the semantics of tion in PKI. Based on their model of “resilient authenti- untrust and distrust. We formally define each degree (of cation”, the authors suggested two metrics to measure the trust, distrust, and undecidable) in terms of formal seman- risk in public key certification: the maximum number of in- tics of trust, and based on the formal semantics, we derive dependent paths with bounded length, and the maximum trust calculation formulas rather than subjectively define the number of nodes which have to be removed (compromised) model. to break all certification paths. The proposed metrics are distinguished by their resiliency to malicious behaviors, but Social Networks based Trust. still follow the implicit assumption that each certificate has The Web has become an open dynamic and decentralized the same level of risk. information/knowledge repository, global electronic markets, Maurer [27] explicitly represent certificate, trust, and rec- and a distributed computing platform. In such a cyberspace, ommendation in a certificate chain in PKI, and quantified people, organizations and software agents need to interact uncertainty of the validity of a statement as “confidence with others with unknown identity. To meet the needs, so- level” in [0,1]. The limitation of his representation is that a cial networks based trust has attracted numerous researchers. single number between 0 and 1 can represent the uncertainty We discuss this field in three categories: (1) Reputation- regarding the validity of a statement, but cannot represent based, to infer the trustworthiness of an entity by consid- the uncertainty due to incomplete knowledge, which is nec- ering its reputation in social networks, e.g. [32] [20] [38]; (2) essary in modeling trust in an open environment. trust relationships based, to infer indirect trust through trusted friends, e.g. [11][7] [19]; (3) vulnerability analysis our model is based on a solid formalism foundation. based, to evaluate trust indirectly by evaluating how vul- nerable is the trust relation network which the trust relies 3. MOTIVATING SCENARIOS on, e.g. [36] and Advogato [22]. The technology and standards of digital signature and cer- Even though tightly related, trust and reputation are es- tification with PKI provide a fundamental and secure ap- sentially different concepts. The reputation of an entity is proach to authentication. An authenticated identity plus a the aggregated opinion that a community of people have set of authenticated credentials (assertions that the entity about how good this entity is. Those people may give their has a set of attributes) may lead to authorizing the authen- opinions about that entity just based on a single encounter, ticated entity access to controlled resources such as informa- and may not trust that entity at all; whereas trust is be- tion, services, or goods, subject to predefined authorization tween two entities. Trust means that trustor believes his policies. An authorization policy usually is based on either expectation on trustee to be fulfilled and he is willing to the rights of the authenticated entity or a trust relationship take the risk for that belief. from the resource controller to that entity. The rationale for reputation based trust computing is that We illustrate the underlying concepts of our research in an agent having high reputation in a domain usually is trust- the following scenarios. worthy in that domain. So, a reputation metric is frequently In Chicago, Alice, a physician, needs helps for treating used as a substitute of a trust metric. Classical reputation the disease of a patient; in the electronic medical messaging systems (e.g. those used in eBay and Amazon) have been system connecting to her clinic, she creates a message to ask developed in e-commerce[5], which have a central trusted au- for help, which is sent to a set of doctors with an attribute- thority to aggregate opinions of users/partners. Some major based messaging system; soon, Alice receives a message with limitations exist. A rating is usually given by a “stranger” digital signature from Dan, a specialist in epidemiology in who knows little about the evaluated subject and is limited Philadelphia; the message says that Dan could help and he to just a single interaction; users of reputation metrics don’t needs further information about the patient; but Alice does know the raters; unfair ratings exist [39]; a very large num- not know Dan; can Alice trust Dan regarding Dan’s profes- ber of transactions are needed for statistical significance. sional performance and regarding whether Dan follows the From network perspective, Kleinberg [21] proposed a pro- terms of use of the privacy data she provides? found model using eigenvector to discover “authorities” and First of all, Alice needs to ensure that the message is sent “hubs” in a network. This work has wide influence in suc- by the person as claimed. To authenticate Dan’s identity, ceeded research; Page et al [32] adopted this thought in well Alice needs to validate Dan’s public key. This is accom- known PageRank algorithm (used by Google) to calculate plished by discovering a certificate chain from an Alice’s the reputation of a webpage; in the same vein, Kamvar et trusted certificate authority (CA) (called trust anchor in al [20] developed EigenTrust algorithm using eigenvector to PKI literatures) to the CA who issues Dan’s public key, and calculate the global trust (actually reputation) from local then by validating each public key in the certificate chain trust in a P2P network. from the public key of Alice’s trust anchor to Dan’s public Trust relationships based trust computing models infer or key. The certification path construction and validation is a calculate indirect trust by using direct trust relationships in standard PKI function. However, any CA in the chain may social networks. Most of them have two basic trust aggrega- make mistakes in its certificate such as issuing the certificate tion operators (or functions): sequence and parallel aggrega- to a wrong entity as [10], key compromised for its limited tion. The logic basis of sequence aggregation is transitivity “cryptographic lifetime” or “theft lifetime” [8] before the ex- and/or transferability of trust. Generally speaking, if agents pired date stated in the certificate, failure in maintaining share trust data with their trusted friends, within a specific CRL (Certification Revocation Lists), and so forth. With context, trust in belief (trust in what trustee believes) is the growth of the length of a certificate chain, the risk gets transitive, trust in performance (trust in what trustee per- higher and higher. How large is this the risk and can it be forms) is not, but can propagates through trust in belief [15]. quantified? If the risk in each certificate chain is quantified, What is the basis for parallel aggregation still remains un- how can this quantified risk be used for certification path clear. Parallel aggregation is an opinion aggregation prob- construction? lem. Ding et al [7] used entropy based aggregation. Many However, the authentication of Dan’s identity is not suf- quantitative trust models use various weighted average, ap- ficient for Alice to trust Dan as an expert in epidemiology. pearing as heuristics designed from intuition, for example, This chain of public key certificates is easily misunderstood the more a trusted friend is, the more the weight of this as a chain of references to Dan’s knowledge of epidemiol- friend’s opinion is in the aggregation. ogy, especially when PGP is used for public key certifica- Our model is a trust relationships based trust model. We tion. Actually, Dan’s public key certificate consists only of believe, formal semantics is important, because without strictly (1) Dan’s public key; (2) Dan’s ID information; (3) certi- defined semantics, the meanings of trust and trust degree fication information such as expiration date; (4) a digital are vague, the conditions and contexts to apply trust are signatures signed by a certification authority who verified not well defined, and the implication of trust are unclear, that the signed public key belongs to Dan, and maintains so that trust may be misused; for probability interpretation the validity of this public key. The relationship in a public of trust degrees, it is critical to explicitly define the sample key certificate is only limited to trust in public key valida- space of that probability. Different from other models in tion. this category, our model has explicitly and formally defined These scenarios reveal and motivate us to consider a num- semantics of trust; based on the formal semantics and prob- ber of relevant issues: ability theory, we derive sequence and parallel aggregation operators, rather than define them as heuristics. In this way, • There are many risks associated with trust in pub- lic key certificate chains and more general credential In the above definition, information x is a reified proposi- chains. These trust relationships are largely depen- tion1 representing either an assertion made by e or a com- dent on the organizational or human behaviors, which mitment made by e to perform (or not to perform) an action; is beyond PKI technology; context k is a reified proposition representing the conjunc- tion of a set of “propositions” to characterize a context. A • Trust is inherently uncertain, being dependent on be- dot over a logical operator is a function to mimic that logical havior of organizations or humans. To support better operator, e.g. ⊃˙ is a function to mimic logical implication. authentication authorization decisions, there is a need Definition (trust in belief ): That trustor d trusts to quantify the risks associated with trust in credential trustee e regarding e’s belief (represented by x ) in context chains; k means that if information x is believed by entity e, then entity d believes x in context k. • The quantified risk associated with trust may be useful in certification path construction and selection; ˙ trust b(d, e, x, k) ≡ believe(e, k⊃x) ˙ ⊃ believe(d, k⊃x) (2) In order to represent uncertainty in trust, the concept of • Trust is subject to a specific context. Alice may trust distrust needs to be introduced. a CA regarding issuing and maintaining Dan’s public In Marsh’s review on the concepts of trust, untrust, dis- key, but not regarding whether Dan is a specialist in trust, and mistrust [26], distrust is regarded as the negative epidemiology; form of trust; untrust is a status where the degree of confi- dence is not enough to trust; mistrust is misplaced trust. • Trust is uncertain. An interesting question here is how More specifically, in our discussion, distrust means trustor to measure the uncertainty in trust in an open envi- d believes the expectancy not to be true, in other words, ronment in which each entity may subjectively give his for distrust in performance, the trustor believes that the ex- own trust? pected information created by trustee e is false, the expected performance of e does not come true, or unexpected behav- • There may be multiple trust paths between Alice and ior comes true; for distrust in belief, the trustor believes the CA issuing Dan’s public key. The connection be- what trustee believes is false. Formally, tween them may be even more complex as a network. How should the risk associated with a trust network distrust p(d, e, x, k) ≡ be evaluated? ˙ ¬x) madeBy(x, e, k) ⊃ believe(d, k⊃ ˙ (3) 4. SEMANTICS OF TRUST distrust b(d, e, x, k) ≡ ˙ believe(e, k⊃x) ˙ ¬x) ⊃ believe(d, k⊃ ˙ (4) 4.1 Concept of Trust Trust is a complex social phenomenon. The concepts de- Here, corresponding to the formal notation of that entity veloped in social sciences provide an important foundation a believes a proposition x, believ(a, x), the formal notation for trust formalization. A large body of research has con- of disbelief is represented by believe(a, ¬x). ˙ tributed to the conceptualization of trust [24] [28][1]. This view of distrust is grounded by the theory of Luh- In this paper, we use the following definition of trust mann [24](chapter 10). The literature addresses that trust [16][15]: Trust is the psychological state comprising (1) ex- and distrust are qualitatively different but functionally equiv- pectancy: the trustor expects a specific behavior of the trustee alent; both of them are based on familiarity; both of them such as providing valid information or effectively perform- reduce social complexity. In other words, both trust and ing cooperative actions; (2) belief: the trustor believes that distrust correspond to certainty, but in different directions. the expected behavior occurs, based on the evidence of the Finally, we define the semantics of a more general form trustee’s competence and goodwill; (3) willingness to be of trust relationships with a specific context but without a vulnerable: the trustor is willing to be vulnerable to that specific expectancy. belief in a specific context, where the specific behavior of the trustee is expected. trust b(d, e, k) ≡ (∀x, trust b(d, e, x, k)); According to the types of the expectancy in trust, there (5) are two types of trust: trust in performance and trust in trust p(d, e, k) ≡ (∀x, trust p(d, e, x, k)). belief. The former is the trust in what trustee performs; the The straightforward meaning of them is that d trust e later is the trust in what trustee believes. These two types regarding e’s every performance or belief in context k. This of trust play important roles in our trust modeling. more general form of trust relationships is more often used in the real world. 4.2 Semantics of Trust and Distrust Similarly, we define Based on the formal semantics of trust defined in the [15], we give a simpler version of the semantics of trust in First distrust b(d, e, k) ≡ (∀x, distrust b(d, e, x, k)); (6) Order Logic as follows. distrust p(d, e, k) ≡ (∀x, distrust p(d, e, x, k)). Definition (trust in performance): That trustor d The general form of distrust is not often in the real world, trusts trustee e regarding e’s performance (represented by but logically it is the extreme end of distrust, which will be x ) in context k means that if information x is made by entity 1 e, then entity d believes x in context k. A reified proposition is a relation representing a “proposi- tion” but it is data rather than a proposition in the repre- ˙ trust p(d, e, x, k) ≡ madeBy(x, e, k) ⊃ believe(d, k⊃x) (1) sentation language. used in uncertain trust model in the next section. 5.1 Formal Definition of Trust Degree Based on the formal semantics of trust presented in the 4.3 Trust Reasoning previous section, as well as the connections of probability The above semantics of trust can be used for trust rea- and conditionals [13] studied in philosophical logic, the de- soning. Generally, trust is placed on an entity (or agent), gree of trust is defined as follows. which behaves autonomously. In other words, the behaviors of the trusted entity is out of control of the trustor. On the tdp (d, e, x, k) = (13) other hand, belief is placed on information (or more exactly, pr(believe(d, x)|madeBy(x, e, k) ∧ beT rue(k)) a proposition). The purposes of formalizing trust are to ac- curately define what trust means when we use trust, and to for trust in performance; use the semantics of trust to infer whether the information tdb (d, e, x, k) = created by the trusted entity or the information representing (14) an expected behavior from the trusted entity to be believed pr(believe(d, x)|believe(e, x) ∧ beT rue(k)) to be true. for trust in belief. In the following, we briefly introduce the logical rules for When the type of trust is not concerned, we omit the trust reasoning based on the formal semantics of trust. superscript p/b. By applying the formal semantics of trust in performance Similar to trust degree, based on the formal semantics of as well as modus ponens, we have distrust, the degree of distrust is defined as: Rule 1: dtdp (d, e, x, k) = pr(believe(d, ¬x)|madeBy(x, ˙ e, k)∧beT rue(k)) ˙ madeBy(x, e, k) ∧ trust p(d, e, x, k) ⊃ believe(d, k⊃x) (7) (15) Similarly, for trust in belief, we have: for distrust in performance; Rule 2: dtdb (d, e, x, k) = pr(believe(d, ¬x)|believe(e, ˙ x) ∧ beT rue(k)) believe(e, k⊃x) ˙ ˙ ∧ trust b(d, e, x, k) ⊃ believe(d, k⊃x) (8) (16) By trust in belief, trust in performance can propagate in for distrust in belief. a network; in other words, for a given context k, if entity a The sample space of the probability representing trust de- trusts b on b’s belief in other entities’ performance, b trusts gree could be any event set that contains the events in which c in c’s performance, then a indirectly trusts c regarding c’s the conditions are true. The minimal sample space is exactly performance. the set of events in which the conditions in the conditional However, when entity a trusts b on belief in a context, probability are true. and b trusts c on performance in a different context, from these two trust relationships, we cannot derive that a trusts 5.2 Measurement of Trust Degree c. The previous subsection provides formal definitions of trust The rules for trust propagation are given as follows. /distrust degrees in probability theory. This subsection gives Rule 3: a frequency interpretation to the probabilities defining trust trust b(a, b, x, k) ∧ trust p(b, c, x, k) ⊃ trust p(a, c, x, k) /distrust degrees. The formal definitions and the frequency (9) interpretation provide a formal interpretation about the se- mantics of the numbers representing trust /distrust degrees, trust b(a, b, x, k) ∧ trust b(b, c, x, k) ⊃ trust b(a, c, x, k) and puts the calculus of trust in a firm theoretic basis. The (10) latter point is important—in practice, this frequency inter- This rule requires the expectancy (x) of trust to be the pretation of trust /distrust degree can be used as a practi- same in the trust from a to b and the trust from b to c. cal method to calculate trust /distrust degrees, by using the Actually, this rule can be extended to a more general form data accumulated in the interaction between a trustor and without a specific expectancy, as follows. a trustee. However, when the data of interactions are not Rule 4: available or not used, a trust /distrust degree may be given as a subjective probability but with the assurance that the trust b(a, b, k) ∧ trust p(b, c, k) ⊃ trust p(a, c, k) (11) calculus itself is nevertheless correct. trust b(a, b, k) ∧ trust b(b, c, k) ⊃ trust b(a, c, k) (12) In the following, we describe measurement of trust /dis- trust degrees and a frequency interpretation of probability. The proof of these trust propagation rules can be found Trust can be divided into two categories: (1) direct trust, in [15] and is omitted here. the trust coming from direct interaction between two parties, and (2)indirect trust, the trust derived from a social network. 5. MEASUREMENT OF UNCERTAIN The derivation of indirect trust will be discussed in the next TRUST two sections; we only need to discuss how to count direct Because trust is placed on another organization, another trust. person, or a group of persons, the features of human behav- The degree of trust is measured with the frequency rate of iors make trust inherently uncertain. In this section, we dis- trustor’s positive experience among all encounters with the cuss the measurement and representation of uncertain trust. trustee. That is, We use probability to measure uncertainty in trust, so that td(d, e, x, k) = n/m, (17) each entity in a distributed computing environment could give his degrees representing uncertainty in trust, based on where, m is the total number of encounters regarding an a common understanding regarding what the numbers mean. instanced expectancy x, and n is the number of trustor’s positive experience. For example, x is an assertion about 5.3 Notation of Uncertain Trust Relationships the authentication of a specific customer, John, who signs A trust relationship can be represented by the degree of on to request a service; d is the service provider; e is the trust and the degree of distrust. identity provider who makes authentication assertion x ; k is The sum of degrees of trust and distrust actually repre- a context such as “sign in for online shopping” ; m is the sents the degree of certainty, denoted as cd, e.g. total times of which e informed d about the authentication of John’s Id in d ’s historic data set; n is the number of cor- cd(d, e, x, k) = td(d, e, x, k) + dtd(d, e, x, k). (24) rect authentication about John; this rate of n/m reflects the The degree of uncertainty, denoted as ud, is defined as probability by which e makes correct authentication about John’s Id. ud(d, e, x, k) = 1 − cd(d, e, x, k) (25) similarly, we have = 1 − td(d, e, x, k) − dtd(d, e, x, k). dtd(d, e, x, k) = l/m, (18) This uncertainty comes from the unfamiliarity of trustor to trustee, or from a trustor’s lack of sufficient information to where l is the number of trustor’s negative experience. n + l evaluate trust of the trustee. is not necessarily equivalent to m, if some encounters are We have td + dtd + ud = 1. hard to say being positive or negative. When ud = 0, td+dtd = 1, which corresponds to the most For the degree of general trust without a specific expectancy, certain situation in which the trustor is sufficiently familiar td(d, e, k) = n0 /m0 , with the trustee, so the trustor can surely make decision to (19) either trust or distrust the trustee. dtd(d, e, k) = l0 /m0 When 0 < ud < 1, td + dtd < 1, which corresponds to a where, m0 is the number of all encounters between trustor typical uncertain situation in which the trustor is not suf- and trustee regarding all instanced expectancy (∀x). n0 is ficiently familiar with the trustee, so there is uncertainty the number of positive experience in those encounters. l0 is regarding trust decision. the number of negative experience in those encounters. In When ud = 1, td + dtd = 0, which corresponds to the the earlier example, m becomes the total times of which e most uncertain situation in which the trustor is completely informed d about the authentication of the identity of any not know about the trustee, so the trustor cannot give the signed custom in d ’s historic data set; n becomes the number degrees of trust or distrust at all. This is the typical case of of correct authentication. “untrust” In practice, people use specific information for a specific Another interesting case is td = dtd = 0.5, which is the problem solving, but when the specific information is not most uncertain situation when ud = 0. available, the general inform may be applied. So, for the A situation easy to be confused is when td = 0. Some case of lack of information about a specific expectancy x, people may think it means untrust; some may think it means td(d, e, k may be used as an estimated value of td(d, e, x, k). distrust; some others may think it’s not sure which case is. Similar to uncertain belief and uncertain trust, a trustor If a trust relationship is defined sole by td, it is hard to may evaluate each encounter as positive (or satisfied, suc- distinguish between these two possibilities. In our notation, ceed) to a certain extent, as negative (or unsatisfied, failed) when td = 0, ud + dtd = 1. So, depending on what ud and to a certain extent, and as undecidable (or hard to say pos- dtd are, there is a probability distribution over distrust and itive or negative) in a certain degree. In such case, trust untrust. /distrust degrees can be refined as: Therefore, a trust relationship can be formally represented Pm as i=1 ep (i) td(d, e, x, k) = , (20) m tr(d, e, x, k) = < td(d, e, x, k), dtd(d, e, x, k) >, (26) where m is the same as defined earlier; or ep (i) ∈ [0, 1] tr(d, e, x, k) = < td(d, e, x, k), dtd(d, e, x, k), ud(d, e, x, k) >, represents the degree of encounter i being positive, ep (i) = (27) 1 represents completely positive, and ep (i) = 0 represents when the value of ud need to appear explicitly. completely not positive. For a general trust relationship without a specific expectancy, Similarly, for distrust degree, we have Pm i=1 en (i) tr(d, e, k) = < td(d, e, x, k), dtd(d, e, k) > . (28) dtd(d, e, x, k) = , (21) m This formal representation of trust relationships has strictly where, defined semantics, so that it can help to avoid mistakes as en (i) ∈ [0, 1], we develop a calculus for trust. which is the degree of encounter i being negative, and 6. TRUST CALCULATION ep (i) + en (i) ≤ 1. (22) In the following, we discuss how to calculate the degree The difference, of trust when trust propagates in trust networks. Basically, there are two types of trust aggregations: sequence aggre- 1 − ep (i) − en (i) (23) gation and parallel aggregation. Sequence aggregation de- represents the degree of uncertainty in trustor’s evaluation scribes aggregation of trust degrees along a trust path; par- of encounter i due to lack of sufficient information for judg- allel aggregation is about how to aggregate trust degrees in ment. several parallel trust paths. 6.1 Sequence Trust Aggregation This property is coincident with people’s intuition regard- The sequence aggregation problem is this: given that a ing trust decreasing quickly in propagation along a trust trusts b (on belief) with a probability distribution trust, path. distrust, and undecidable, b trusts c (either on belief or on Property 2: sequence aggregation is associative. performance) with another probability distribution, what is By this property, the outcome of the sequence aggrega- the probability distribution for a to trust c, that is, what tion is independent to the order of sequence aggregation for are td(a, c, x, k) and td(a, c, x, k)? each pair of trust relationships in a trust path. This prop- The following theorem answers this question. erty is important when applying sequence aggregation in the Theorem UT-1: (1) assume that agent a has a trust in algorithm for trust aggregation in a network. belief relationship with b, Property 3: A trust relationship with ud = 1 is a “zero” element in trust aggregation. tr(a, b, x, k) = < tdb (a, b, x, k), dtdb (a, b, x, k) >, (29) This property says that if the trust of a in b or the trust b has trust in performance relationship with c, of b in c is untrust with ud = 1, the derived trust of a in c is also “untrust” with ud = 1. In other words, in a trust tr(b, c, x, k) = < tdp (b, c, x, k), dtdp (b, c, x, k) >, (30) network, a trust relationship with ud = 1 is the same as and the belief of a in x is conditionally independent to the there is no trust relation between the two entities. provenance of x (or the belief of c in x) given the belief of b The implication of this property is obvious. In a trust in x, then the trust relationship from a to c can be derived network, if there is only one trust path from a to c, then any as follows: “untrust” in the path will make the trust path “broken”which is equivalent to the case that there is no trust path from a tr(a, c, x, k) = < tdp (a, c, x, k), dtdp (a, c, x, k) >, (31) to c. As a result, a will “untrust” c. This property reveals that trust evaluation will not change and by adding or cutting off a trust relationship with td = dtd = tdp (a, c, x, k) = tdb (a, b, x, k) · tdp (b, c, x, k) 0. Therefore, cutting off all trust relationships with td and (32) dtd near 0 will effectively reduce the complexity of a trust + dtdb (a, b, x, k) · dtdp (b, c, x, k), network and the associated computation complexity. Sequence aggregation is a basis for trust aggregation in dtdp (a, c, x, k) = dtdb (a, b, x, k) · tdp (b, c, x, k) a trust network. Sequence aggregation also can be applied (33) + tdb (a, b, x, k) · dtdp (b, c, x, k); independently. For example, in identity management, a cre- dential chain is a trust path, and sequence aggregation can The certainty degree in this derived trust relationship satis- be used for analyzing trust related risk in a credential chain. fies In PGP, a sequence of public key introducers forms a trust cd(a, c, x, k) = cd(a, b, x, k) · cd(b, c, x, k). (34) path, and sequence aggregation can be used to calculate a numeric value of the overall trust along that trust path. (2) if b has trust in belief relationship with c, and the con- A key issue now is aggregation of trust relationships (opin- ditional independent condition is – the belief of a in x is ions) in parallel trust paths, which is difficult due to the conditionally independent to the belief of c in x given the lack of the commonly recognized logic to synthesize different belief of b in x, then the trust relationship from a to c can opinions. In the following, we discuss how to make parallel also be derived, but the derived trust is trust in belief. trust aggregation first, then we discuss how to make trust evaluation in a trust network by using sequence aggregation For reasons of space, the proof of this theorem is omitted and parallel aggregation. here but can be found in [17]. The above assumed conditional independent condition is 6.2 Parallel Trust Aggregation similar to the assumption in belief networks and Markov chains, which assumes an event is only directly dependent In general, as shown in figure 1, parallel trust aggregation on its parents. needs to answer the following question: given that entity a For general trust relationships without a specific expectancy, directly or indirectly trusts (in belief) b1 , ..., bn , b1 , ..., bn the above theorem also true by removing all expectancy x, trust c (either in belief or in performance), and a may also and revising the conditional independent condition as fol- directly trusts c, what is the aggregated trust from a to c? lows: the belief of a in any x is conditionally independent to We assume that in a trust network each direct trust re- the provenance of any x (or the belief of c in any x) given lationship (described by trust degree and distrust degree) the belief of b in any x. and the number of samples used to determine that trust This sequence aggregation operator has some interesting relationship are given. properties. For simplicity, we use td(ei , ej ) (dtd(ei , ej )) to denote Property 1: with the growth of the length of a trust td(ei , ej , x, k) (dtd(ei , ej , x, k)), by omitting x, k, because path, the certainty degree of the aggregated trust multi- they are the same2 ; we use s(ei , ej ) to denote the number plicatively decreases. of samples used in assessing td(ei , ej ) and dtd(ei , ej ); fur- For simplicity, we use subscript i,j represents that a trust thermore, we use a superscript ∗ to denote an aggregated relationship is from entity i to entity j. trust relationship, e.g. td∗ (ei , ej ) (dtd∗ (ei , ej )). In addition, Assume the length of a trust path is n. By theorem UT-1, we omit superscripts p and b when the type of trust is not we have 2 Actually, for a specific trust evaluation regarding the infor- cd1,n = cd1,2 · cd2,3 · ... · cdn−1,n , (35) mation x in context k, a specific sub-network with the same x and k is selected from a real world trust network. See Therefore, we have property-1. detail in subsection6.3. weight (after normalization by trust-in-belief measures) as direct interactions that a has with c. So, the aggregated degree of trust from entity a to c, td∗ (a, c), is: td∗ (a, c) = (s(a, c)/s∗ (a, c)) · td(a, c) + (s(a, b, c)/s∗ (a, c))· (40) (tdb (a, b) · td(b, c) + dtdb (a, b) · dtd(b, c)) The type of td∗ (a, c) depends on the type of td(b, c). For tdp (b, c), td∗ (a, c) will be trust in performance; for tdb (b, c), td∗ (a, c) will be trust in belief. Similarly, we have the aggregated degree of distrust as follows. dtd∗ (a, c) = (s(a, c)/s∗ (a, c)) · dtd(a, c) Figure 1: Parallel trust aggregation in multiple trust + (s(a, b, c)/s∗ (a, c))· (41) paths (tdb (a, b) · td(b, c) + dtdb (a, b) · dtd(b, c)) For the general case shown in figure 3, the aggregated trust degree can be calculated as td∗ (a, c) = (s(a, c)/s∗ (a, c)) · td(a, c) X + (s(a, bi , c)/s∗ (a, c))· Figure 2: A simple example of parallel trust aggre- i=1,...,n (42) gation (tdb (a, bi ) · td(bi , c) + dtdb (a, bi ) · dtd(bi , c)), concerned. where We start from the simplest case as shown in figure 2. Here X entity a has two trust paths to entity c: the direct trust from s∗ (a, c) = s(a, c) + s(a, bi , c), (43) i=1,...,n a to c, and the indirect trust via b. We define parallel aggregation based on the interpretation and of a trust degree as a frequency rate of successful interaction. From the view of entity a, the total number of encounters s(a, bi , c) = s(bi , c); (44) with c regarding the information x in context k is the sum Similarly, the aggregated distrust degree can be calculated of the encounters of both entity a’s direct interaction and as indirect interaction via b with c, that is, dtd∗ (a, c) = (s(a, c)/s∗ (a, c)) · dtd(a, c) ∗ s (a, c) = s(a, c) + s(a, b, c), (36) X + (s(a, bi , c)/s∗ (a, c))· where, i=1,...,n (45) b s(a, b, c) = s(b, c); (37) (td (a, bi ) · dtd(bi , c) among these encounters, the total number of successful en- + dtdb (a, bi ) · td(bi , c)); counters with c is the sum of (1) the successful encounters From the frequency definition of trust degree, a paral- that a directly interacts with c, which is, by frequency rate lel aggregation is derived, which appears in the form of definition of trust degree, weighted average of all parallel trust paths, and the weight s(a, c) · td(a, c); (38) of a path is the rate of the number of the samples in this path to the total number of samples. and (2) the successful encounters that a indirectly interact Generally, the more samples are used in a trust path, the via b with c, which is, by sequence trust aggregation, more accurate the trust degree is in that trust path, and the more weight that trust path will have in aggregation. This s(a, b, c) · (tdb (a, b) · td(b, c) + dtdb (a, b) · dtd(b, c)). (39) is also coincident with people’s intuition regarding opinion A natural interpretation is that a reviews each direct inter- aggregation. action that b had with c, and evaluates each certain (i.e., Parallel aggregation is associative, so that the aggregated positive or negative) interaction (from a’s point of view) as trust relationship will not change with the order of aggre- being the same as that from b’s point of view with probabil- gation. This property, together with the associativity of ity tdb (a, b), and being the opposite of b’s with probability sequence aggregation, is important to make the calculated dtdb (a, b). In a sense b’s direct interactions with c are being result unique in different algorithm implementations which interpreted as a’s interactions with c, and are given the same may aggregate trust paths in different order. sink z is a DAG (directed acyclic graph), represented as T N = (E, A); (46) E is the set of entities, and a, z ∈ E; A ∈ E×E, and each arc (ei , ej ) (ej 6= z) is labeled by trust (in belief) relationship < tdb (ei , ej ), dtdb (ei , ej ) >; (47) each arc to the sink, (ei , z), is labeled by trust relationship < tdx (ei , ej ), dtdx (ei , ej ) > (48) x is either b or p, that is, all arcs to the sink are either trust in belief relationship or trust in performance relationship. An algorithm is designed to make trust aggregation in a network, which recursively simplifies a more complex net- work to a simpler one, by replacing multiple parallel paths into a single arc. Each replacement is made by using se- quence or parallel aggregation. aggregate(a, z, T N ){ Figure 3: Example: trust aggregation in trust net- works – What is the aggregated trust relationship if (a, z) is the only path from a to z in T N , stop; between a and f ? else if a has and only has one path to z, then { use sequence aggregation to aggregate; Finally, it is interesting to interpret this parallel aggrega- remove the last arc in this path to z; tion from the view of trust revision with new information. add arc (a, z) labeled by td∗ (a, z) in T N ; td(a, c) can be regarded as the initial opinion of entity a } else if a has multiple disintersected paths to z, regarding trust in entity c, based on a’s direct interaction then { with c; later, a learns new information from her/his trusted friends b1 , ..., bn regarding their opinion about c, and then use parallel aggregation to aggregate all a revises her/his opinion as td∗ (a, c), by synthesize her/his paths from a to z; friends’ opinions. If a’s opinion is based on a small number remove the last arc in each path to z; of direct interaction, those friends’ opinions may have large add arc (a, z) labeled by td∗ (a, z) in TN; influences on her/his revised opinion; on the other hand, if } else { her/his original opinion is based on a big number of samples, her/his friends opinions may have smaller influences. calculate N = neighbors(z); for each ni 6= a in N do aggregate(a, ni , T N ); 6.3 Trust Evaluation in a Network use parallel aggregation to aggregate all We now show how to use sequence aggregation and par- paths from a to z; allel aggregation to aggregate trust in a network. remove the last arc in each path to z; A trust network is a subgraph of a social network. A add arc (a, z) labeled by td∗ (a, z) in T N ; social network can be regarded as a directed graph with } labeled arcs, where the vertices are entities such individu- als and organizations in society, and the arcs are various } social relationships, typically acquaintance relationships . The example shown in figures 3 to 7 demonstrates the In the context of trust, we only concern a special type of trust aggregation process in a trust network. subgraphs of social networks, called trust networks, in In figure 3, the set of f ’s neighbors is {a,c,d,e}. Apply the which arcs represent inter-individual (or direct) trust rela- algorithm to aggregate trust in each neighbor first. tionships. An arc from vertex a to vertex b represents that Figure 4 shows the process to aggregate trust between a a has direct trust relationship with b which is described as and d. Since the subgraph with a as source and d as sink < td(a, b, x, k), dtd(a, b, x, k) >. In general, all direct trust is still a network, apply the algorithm again. The neighbors relationships in a social network form a directed graph usu- of d are b and c; a has direct trust in b, so no aggregation ally with circles. For the purpose of deriving a new trust is applied; a has a single path to c, apply sequence aggre- relationship by a trust network, trust circle should be elimi- gation, then remove the last arc (b, c) in the path, and add nated. For this reason, we assume a concerned trust network arc (a, c) (bold dash arc) corresponding to the aggregated is a directed acyclic graph (DAG). trust relationship < td∗ (a, c), dtd∗ (a, c) > by the sequence More specifically, for a specific trust evaluation from trustor aggregation. The result is shown in in figure 4 (b); now, a to trustee z regarding information x in context k, we only return to the aggregation between a and d. a has three consider a sub-network (of a real world trust network) with parallel paths to d, (a,d), (a,b,d) and (a,c,d). Apply paral- source node a and sink node z and the arcs in which trust lel aggregation, then remove the last arc in each path, i.e. relationships have the same x and k. Because in this spe- (a,d),(b, d) and (c,d), add a new arc, (a,d)(bold dash arc), cific subset of a trust network, all trust relationships have which is corresponding to the aggregated trust relationship the same x and k, they are omitted. < td∗ (a, d), dtd∗ (a, d) > by the parallel aggregation. The From this point of view a trust network with source a and result is shown in figure 4 (c). Figure 5: Example: trust aggregation in trust net- works – no aggregation needed between a and c Figure 4: Example: trust aggregation in trust net- works – aggregation between a and d Figure 6: Example: trust aggregation in trust net- In figure 5, to aggregate trust between a and c, a has an works – Sequence aggregation between a and e arc to c, so the algorithm do nothing, and return to upper level of the process to aggregate trust between a and f . Figure 6 shows the process to aggregate trust between a of trust relationships. What do these trust relationships ex- and e. There is a single path (a,c,e), so apply sequence actly mean? On what things does each entity trust another aggregation, then remove arc (c,e) and add arc (a,,e) (bold in a credential chain? What is the specific context of each dash arc) corresponding to the aggregated trust relationship trust? In order to avoid misuse trust in PKI, we need to by the sequence aggregation. answer these questions and to explicitly and accurately rep- Returning to the process of aggregating trust between a resent trust in certificate chains. and f , as shown in figure 7(a), there are four parallel trust In a typical public key validation model, a single certifica- paths, (a, f ), (a, d, f ), (a, c, f ) and (a, e, f ), as shown in (a). tion path with shortest length is discovered and validated. Apply parallel aggregation, remove the last arc of each path, An implicit risk evaluation criterion here is that a longer i.e. (a, f ), (d, f ), (c, f ) and (e, f ), and add the new arc (a, certification path has higher risk. This criterion actually as- f ) (red bold dash arc) corresponding to the aggregated trust sumes each certificate has the same level of risk. However, relationship by the parallel aggregation. Thus, we obtain the different certificates have different levels of risk, as they are aggregated trust between a and f , as shown in 7(b). produced by different organizations, with different identity standards. In order to make better decisions on authentica- 7. TRUST QUANTIFICATION IN tion and authorization, it is important to quantify the risk associated with trust in certificate chains. When quantified CERTIFICATE CHAINS evaluation of risk is introduced to certification paths, some As discussed in section 1, a number of PKI trust models very interesting issues emerge. There are multiple avail- have been proposed[33] [23] [30] [37]. However, the explicit able certification paths, but which certification path should and accurate representation of trust relationships and the be chosen? The shortest path? or the one most trusted? quantification of risks associated with trust in certification Should more than one certification paths be considered? paths are missing. Should all certificate paths be considered? In this section, In PKI, a certification path actually corresponds to a chain we explore the answers to these questions. trusts CA4 regarding the validity of the certificates created and maintained by CA4. The trust from CA1 to CA2 is that CA1 trusts CA2 regarding CA2’s performance in the digital certification business, including (1) issuing and maintaining certificates to CA2’s clients, (2) auditing CA2’s subordinate CAs. The latter implies that CA1 trusts CA2 regarding what CA2 believes about the validity of the certificates cre- ated and maintained by CA2’s subordinate CAs. Similarly, the trust from Alice to CA1 is that Alice trusts what CA1 believes about the validity of the certificates created and maintained by CA1’s subordinate CAs and all descendants. In the terminology of our formal trust model, CA2 trusts CA1 on performance in the context of “issuing and maintain- ing certificates”; CA1 trusts CA2 on belief in the context of “issuing and maintaining certificates”; Alice trusts CA1 in the same context. Depending the application, the context of trust could be more specific issues such as “accurate val- idation of key holder’s identity” and “good maintenance of CRL”. Using our formal notation, the above trust relationships can be formally represented and calculated. The expectancy of Alice on Bob is that “public key pk(Bob) is Bob’s”. So, let x be this proposition. In this example, context k is set as “issuing and maintaining certificates”. Assume each of the above trust relationships has a different level of trust. They Figure 7: Example: trust aggregation in trust net- are formally represented as follows. works – parallel aggregation between a and f trb (Alice, CA1, k) = < tdb (Alice, CA1, k), dtdb (Alice, CA1, k) > tdb (Alice, CA1, k) = 0.98; (49) b dtd (Alice, CA1, k) = 0.01; udb (Alice, CA1, k) = 0.01; trb (CA1, CA2, k) = < tdb (CA1, CA2, k), dtdb (CA1, CA2, k) > tdb (CA1, CA2, k) = 0.92; (50) Figure 8: An example of hierarchical PKI (cited b dtd (CA1, CA2, k) = 0.02; from Burr (1998)) udb (CA1, CA2, k) = 0.06; In the following, we discuss the semantics of trust in PKI, trp (CA2, CA4, k) the formal representation of trust relationships in PKI, and the quantified evaluation of risk associated with trust in cer- = < tdp (CA2, CA4, k), dtdp (CA2, CA4, k) > tificate chains, by using our calculus of trust. There are dif- tdp (CA2, CA4, k) = 0.96; (51) ferent types of PKI architectures [3] [34][14] such as single- dtdp (CA2, CA4, k) = 0.01; CA structure, hierarchical structure, mesh structure, bridge structure, and hybrid structure. We mainly discuss two rep- udp (CA2, CA4, k) = 0.03; resentative types: hierarchical and mesh. For hierarchical PKI the certification path is unique so we can directly apply sequence trust aggregation to evaluate 7.1 Trust in Hierarchical Structure PKI the overall risk in the certificate path. An example of hierarchical PKI structure is shown in fig- Using sequence aggregation, the aggregated trust relation- ure 8. ship from CA1 to CA4 is calculated as Alice needs to validate Bob’s public key. CA3 is Alice’s trust anchor, the CA Alice trusts; CA1 is root CA that trp (CA1, CA4, k) everyone including Alice knows its public key; CA4 issues = < tdp (CA1, CA4, k), dtdp (CA1, CA4, k) > Bob’s public key certificate. In this case, the certificate chain tdp (CA1, CA4, k) = 0.883; (52) will be CA1 - CA2 - CA4. p The semantics of the trust relationships in this certificate dtd (CA1, CA4, k) = 0.028; chain are as follows. The trust from CA2 to CA4 is that CA2 udp (CA1, CA4, k) = 0.09; As discussed earlier, when introducing quantified values of trust in certificate chains, we need to answer a number of interesting questions. We discuss those questions in two representative cases. 7.2.1 Using One-path certification By a traditional certification path construction method, the shortest path, CA3->CA5->CA4, will be used to vali- date Bob’s public key. Assume that the trust relationships are as follows. Alice highly trust her trust anchor, CA3. Figure 9: An example of mesh PKI, cited from Burr (1998) trb (Alice, CA3, k) = < tdb (Alice, CA3, k), dtdb (Alice, CA3, k) > The aggregated trust relationship from Alice to CA4 is tdb (Alice, CA3, k) = 0.99; (54) calculated as b dtd (Alice, CA3, k) = 0.0; p tr (Alice, CA4, k) udb (Alice, CA3, k) = 0.01; p p = < td (Alice, CA4, k), dtd (Alice, CA4, k) > Trust from CA3 to CA5 is not high, even somewhat neg- tdp (Alice, CA4, k) = 0.866; (53) ative. dtdp (Alice, CA4, k) = 0.037; trb (CA3, CA5, k) udp (Alice, CA4, k) = 0.097; = < tdb (CA3, CA5, k), dtdb (CA3, CA5, k) > The single-CA PKI is a special case of hierarchical struc- ture, with only a root CA. The semantics of trust, formal tdb (CA3, CA5, k) = 0.65; (55) representation, and calculation are the same as in hierarchi- b dtd (CA3, CA5, k) = 0.25; cal PKI. udb (CA3, CA5, k) = 0.1; 7.2 Trust in Mesh Structure PKI The trust from CA5 to CA4 is fairly uncertain. An example of mesh PKI is illustrated in figure 9. In this case, CA3 is Alice’s trust anchor, i.e. an CA Alice trusts, trp (CA5, CA4, k) and by this CA, Alice finds a certificate chain to CA4, the = < tdp (CA5, CA4, k), dtdp (CA5, CA4, k) > issuer of Bob’s public key certificate. For different structures, while the certification path (cer- tdp (CA5, CA4, k) = 0.75; (56) tificate chain) construction methods [9][40] differ, from the p dtd (CA5, CA4, k) = 0.0; view of a relying party (verifier or recipient), the trust rela- udp (CA5, CA4, k) = 0.25; tionships in a certificate chain have the same semantics. The semantics of the trust relationships in this example By sequence aggregation, the derived trust from CA3 to are as follows. CA4 is In the following pairs of CAs, CA1 and CA2, CA2 and CA4, CA1 and CA5, CA4 and CA5, CA1 and CA3, as well trp (CA3, CA4, k) as CA3 and CA5, each pair of CAs trust each other regard- = < tdp (CA3, CA4, k), dtdp (CA3, CA4, k) > ing the validity of the certificates created and maintained by tdp (CA3, CA4, k) = 0.488; (57) the other; and each pair of CAs trust each other regarding dtdp (CA3, CA4, k) = 0.188; what the other believes about the validity of the certificates created and maintained by a third CA. In the terminology of udp (CA3, CA4, k) = 0.324; our formal trust model, each pair of CAs trust each other on both performance and belief in the context of “issuing and the derived trust from Alice to CA4 is maintaining certificates”; Alice trusts CA3 on both perfor- trp (Alice, CA4, k) mance and belief in the context of “issuing and maintaining = < tdp (Alice, CA4, k), dtdp (Alice, CA4, k) > certificates”. The trust relationships in a bridge PKI are similar to the tdp (Alice, CA4, k) = 0.483; (58) ones in mesh PKI. The difference is that bridge CAs play dtdp (Alice, CA4, k) = 0.186; the role of gateway and issue certificates only to CAs, so all udp (Alice, CA4, k) = 0.331, trust relationships to bridge CAs are trust in belief type. A hybrid PKI consists of many CA groups of different types, which shows a weak trust relationship from Alice to CA4, so some gateway CAs have trust relationships cross groups; so even though certification is verified successfully along the and some others has trust relationships within their groups. certificate chain, Alice may still not trust the validity of The formal representation of the above trust relationships Bob’s public key. are similar to the ones given in hierarchical structure. In the However, a longer path, CA3 -> CA1 -> CA2 -> CA4, following discussion, we give only that part of them needed with a higher level of trust, may make the derived trust from for the trust calculation examples. Alice to CA4 in a acceptable level. Assume trust relationship from CA3 to CA1 being level of each certificate is the same. By combining this ap- proach with our calculus of trust, a better risk evaluation trb (CA3, CA1, k) can be made. We discuss this method as follows. = < tdb (CA3, CA1, k), dtdb (CA3, CA1, k) > First, use Reiter and Stubblebine’s BDP algorithm [35] to get a set of node-disjoint paths of bounded length. Assume tdb (CA3, CA1, k) = 0.98; (59) that the totally number of such node-disjoint paths is k. b dtd (CA3, CA1, k) = 0.01; Second, for each path, use sequence aggregation to calcu- late the aggregated trust in each path. udb (CA3, CA1, k) = 0.01; The aggregated result is a triple < td, dtd, ud >. Consider other trust relationships are as assumed earlier. the semantics of these degrees. td represents the conditional By sequence aggregation along this longer path, the de- probability of the trust anchor believing that the certificate rived trust relationship from CA3 to CA4 is: made by the target, given fact that the certificate is made by the target; dtd is the conditional probability of disbelief trp (CA3, CA4, k) in the certificate; and ud is the degree of uncertainty in = < tdp (CA3, CA4, k), dtdp (CA3, CA4, k) > current information status. When more relevant information becomes available and the uncertainty is resolved, the ud will tdp (CA3, CA4, k) = 0.866; (60) partly go to belief, and partly go to disbelief. In the extreme dtdp (CA3, CA4, k) = 0.037; cases, ud completely goes to belief or disbelief. Consequently udp (CA3, CA4, k) = 0.097; this triple can be regarded as a probability interval [td, td + ud], (and now, td + dtd = 1.) the derived trust relationship from Alice to CA4 is: Assume that the ith path has probability of pi being valid, and the aggregated trust in the ith path is < tdi , dtdi , udi > . trp (Alice, CA4, k) Then, we have = < tdp (Alice, CA4, k), dtdp (Alice, CA4, k) > tdi ≤ pi ≤ tdi + udi . (62) tdp (Alice, CA4, k) = 0.849; (61) dtdp (Alice, CA4, k) = 0.045; Since those paths are node-disjoint, they are statistically independent. So, the probability of this public key, certifi- udp (Alice, CA4, k) = 0.106, cated by k multiple parallel certification paths, being valid and Alice may accept this level of trust to Bob’s public key. is, This example shows when quantified risk is introduced in n Y certificate chains, the most trustworthy certification path p=1− (1 − pi ) (63) with respect to “issuing and maintaining certificates”, need i=1 not be the shortest path. Because each pi has a range, that probability also has a Practical application of the calculus here might be to pro- lower bound and upper bound, i.e. vide a framework for accepting or rejection a validated. The n n risk is that one or more CA’s in the chain may have erro- Y Y neously bound an identity and public key, allowing for sub- 1− (1 − tdi ) ≤ p ≤ 1 − (1 − (tdi + udi )) (64) version of the binding of Bob’s identity and the public key in i=1 i=1 his certificate. If some chain chosen (e.g. the shortest) yields Returning to the example, BDP algorithm outputs two an unacceptably low level of trust, then another chain may paths: CA3 -> CA5 -> CA4, and CA3 -> CA1 -> CA2 be sought and validated, in an effort to find a chain with a -> CA4. For each of them, the trust calculated through high enough trust value. It is important to note here that sequence aggregation is as follows. the different paths through CAs are disjoint and hence sta- For path 1: CA3 -> CA5 -> CA4, tistically independent. In particular, knowledge that all the signatures on one path “checked out” in no way influences the trp (CA3, CA4, k) probability that the signatures on another path will, because = < tdp (CA3, CA4, k), dtdp (CA3, CA4, k) > only one CA signs Bob’s certificate. The situation changes tdp (CA3, CA4, k) = 0.488; (65) significantly though when multiple CAs sign a certificate. dtdp (CA3, CA4, k) = 0.188; 7.2.2 Using multiple-paths certification udp (CA3, CA4, k) = 0.324; Inspired by network reliability, Reiter and Stubblebine’s the interval of the probability that CA4’s certificate for Bob’s research [35] [36] proposed “resilient authentication” by us- public key being valid is [0.488, 0.812], obviously, which is ing redundant multiple independent paths to increase as- very uncertain; for path 2: CA3 -> CA1 -> CA2 -> CA4, surance or reliability. The authors suggest two types of in- dependence: (1) node-disjoint paths with bounded length; trp (CA3, CA4, k) and (2) k-connective paths with bounded length, in which = < tdp (CA3, CA4, k), dtdp (CA3, CA4, k) > to break all path, k nodes have to be removed. By their approach, one misbehaving node (CA) will compromise at tdp (CA3, CA4, k) = 0.866; (66) most one path. So, in the context of public key certification dtdp (CA3, CA4, k) = 0.037; validation, multiple certification paths will make certificate udp (CA3, CA4, k) = 0.097; validation more reliable. The drawback is that there is no quantified trust evaluation on certificates or certification au- the interval of the probability that CA4’s certificate for Bob’s thorities, and there is an implicit assumption that the risk public key being valid is [0.866, 0.963]. So, by using these two paths, the probability that CA4’s It would be perfect to use complete information (all rele- certificate for Bob’s public key being valid has a lower bound vant trust relationships) in the network. However in the real of world, a social network usually is huge. Consider the cost for 1 − (1 − 0.488) · (1 − 0.866) = 0.931, (67) computing, it is unreal to use all information. By Simon’s theory of bounded rationality, a decision making process in and has an upper bound of the real world is limited by bounded rationality i.e. the 1 − (1 − 0.812) · (1 − 0.963) = 0.993. (68) “rational choice that takes into account the cognitive limita- tions of the decision maker - limitations of both knowledge So, by using multiple paths, the interval of the probability and computational capacity”. Thus, it is acceptable to use of the certificate being valid is [0.931, 0.993]. just partial but most relevant information (trust relation- This example shows that using multiple paths for certi- ships) to make trust evaluation in a huge social network. fication is much more certain and more reliable than using single certification path for validation. The above multiple paths certification has a drawback 8. CONCLUDING REMARKS that to derive the trust in the target, for each CA in a path, In order to explicitly represent trust and to quantify the only the trust from the proceed CA to this CA is taken risk associated with trust in public key infrastructure (PKI) into account, and other CAs’ trust relationships to this CA and identity management (IdM), we introduced a formal se- are not considered. For example, in path CA3 -> CA5 - mantics based calculus of trust, and demonstrated how to >CA4, to evaluate trust in CA5, only CA3’s trust in CA5 is apply the trust calculus, to formally represent trust relation- considered; CA1’s opinion on CA5 is completely neglected. ships and to quantitatively evaluate the risk associated with However, CA3’s opinion may be based on a small number of trust in public key certificate chains. This research shows encounters between them; CA1’s opinion may be based on that after introducing formal representation and quantifi- a much greater number of encounters. cation of trust in certificate chains, for using one-path cer- From the perspective of trust in social networks, to avoid tification, the shortest certification path need not be the the above possible bias in trust evaluation, using the trust most trustworthy certification path, and that a chain with relationships in a network of certificates will make the trust an acceptably high level of trust should be constructed for anchor get more opinions about a CA from this CA’s neigh- validation; for using multi-path certification, multiple inde- bor CAs. In this way, the trust anchor can be more objec- pendent certification paths provides much more reliable and tively evaluate this CA. certain public key certification validation. Return to the example story. Assume that the trust from To continue the work presented in this paper, the future CA1 to CA5 is work can go further in several directions. First, knowledge that a certificate has been validated by some path (or some trb (CA1, CA5, k) set of paths) clearly impacts the probability that the certifi- = < tdb (CA1, CA5, k), dtdb (CA1, CA5, k) > cate will be validated by another. This is a feature of the analysis yet to be developed. Other future work is to de- tdb (CA1, CA5, k) = 0.91; (69) velop effective and efficient trust aggregation algorithms in b dtd (CA1, CA5, k) = 0.02; huge size social networks; use trust calculus as heuristic in- udb (CA1, CA5, k) = 0.07, formation in public key certification path building, and other applications of the calculus of trust, for example, modeling and the opinion is based on 5,000 encounters; CA3’s direct trust in privacy protection in healthcare. trust in CA5 is based on just 100 encounters. Then by using parallel aggregation, the aggregated trust from CA3 to CA5 will be 9. ACKNOWLEDGMENTS The US Department of Homeland Security, through grant trb (CA3, CA5, k) award number 2006-CS-001-000001 under the auspices of the = < tdb (CA3, CA5, k), dtdb (CA3, CA5, k) > Institute for Information Infrastructure Protection (I3P) re- search program, partly supported this work. The views and tdb (CA3, CA5, k) = 0.887; (70) conclusions contained in this document are those of the au- b dtd (CA3, CA5, k) = 0.033; thors and should not be interpreted as necessarily represent- ing the official policies, either expressed or implied, of the US udb (CA3, CA5, k) = 0.08, Department of Homeland Security, the I3P, or Dartmouth which is significantly different from CA3’s direct trust in College, which manages the I3P program. CA5 (formula 55). In the following, we briefly discuss how to use the trust 10. REFERENCES relationships in a network of certificates, to evaluate the trust in a CA; and leave the detailed algorithm design and [1] K. Blomqvist. The many faces of trust. Scandinavian analysis for future research. Journal of Management, 13(3):271–286, 1997. For each concerned CA, the trust from the trust anchor [2] D. Bodeau. Sharing Protected Identity and Credential can be evaluated by using the algorithm given in section 6.3; Information (SPICI) Framework for Assessable then use the derived trust as heuristic information in Reiter Identity and Privacy Protection. The MITRE and stubblebine’s multiple independent certification paths Corporation, 2008. discovery. [3] W. Burr. Public key infrastructure (pki) technical Ideally, for trust evaluation in a social network, the more specifications: Part a - technical concept of operations. information is used, the more accurate the evaluation is. 1998. [4] M. Burrows, M. Abadi, and R. Needham. A logic of [21] J. M. Kleinberg. Authoritative sources in a authentication. ACM Transactions on Computer hyperlinked environment. J. ACM, 46(5):604–632, Systems, 8(1):18–36, 1990. 1999. [5] C. Dellarocas and P. Resnick. Online reputation [22] R. Levien. Attack-resistant trust metrics. PhD Thesis, mechanisms a roadmap for future research. In First University of California, Berkeley, USA, 2002. Interdisciplinary Symposium on Online Reputation [23] J. Linn. Trust models and management in public key Mechanisms, 2003. infrastructures. RSA Laboratories, 2000. [6] R. Demolombe. To trust information sources: a [24] N. Luhmann. Trust and Power. John Wiley & Sons proposal for a modal logical framework. In Ltd, 1979. C. Castelfranchi and Y.-H. Tan, editors, Trust and [25] S. P. Marsh. Formalising Trust as a Computational deception in virtual societies, pages 111–124. Kluwer Concept. Ph.D. Thesis, University of Stirling, 1994. Academic Publishers, 2001. [26] S. P. Marsh and M. R. Debben. Trust, untrust, [7] L. Ding, P. Kolari, S. G. Finin, A. Joshi, Y. Peng, and distrust and mistrust - an exploration of the dark(er) Y. Yesha. Modeling and evaluating trust network side. In Proceedings of iTrust2005, LNCS 3477, pages inference. In The Seventh International Workshop on 17–33, 2005. Trust in Agent Societies, at AAMAS 2004, 2005. [27] U. M. Maurer. Modelling a public-key infrastructure. [8] C. Elison and B. Schneier. Ten risks of pki:what In ESORICS ’96: Proceedings of the 4th European you’re not being told about public key infrastructure. Symposium on Research in Computer Security, pages Computer Security Journal, XVI(1), 2000. 325–350, London, UK, 1996. Springer-Verlag. [9] Y. Elley, A. Anderson, S. Hanna, S. Mullan, [28] R. Mayer, J. Davis, and F. Schoorman. An integrative R. Perlman, and S. Proctor. Building certification model of organizational trust. Academic of paths: Forward vs. reverse. In The 10th Annual Management Review, 20(3):709–734, 1995. Network and Distributed System Security Symposium, [29] Microsoft. Pki trust models (slides). 2004. 2001. [30] T. Moses. Pki trust models. [10] R. Forno and W. Feinbloom. Pki: A quention of trust [31] L. Mui and A. Halberstadt. A computational model of and value. Communication of the ACM, 44(6), June trust and reputation. In Proc. 35th Hawaii Int. Conf. 2001. on System Sciences, 2002. [11] J. A. Golbeck. Computing and Applying Trust in [32] L. Page, S. Brin, R. Motwani, and T. Winograd. The Web-Based Social Networks. Ph.D. Thesis, University pagerank citation ranking: Bringing order to the web. of Maryland, College Park, 2005. Technical report, Stanford Digital Library Technologies [12] R. Guha and R. Kumar. Propagation of trust and Project, 1998. distrust. In WWW2004, 2004. [33] R. Perlman. An overview of pki trust models. IEEE [13] A. Hajek. Probability, logic, and probability logic. In Network, 13:38–43, 1999. L. Goble, editor, Philosophical Logic. Blackwell [34] W. T. Polk and N. E. Hastings. Bridge certification Publishing, 2001. authorities: Connecting b2b public key [14] S. Hanna and P. Hesse. Approaches to certificate path infrastractures. 2000. discovery (slides). In PKI’2004, 2004. [35] M. K. Reiter and S. G. Stubblebine. Resilient [15] J. Huang. Knowledge Provenance: An Approach to authentication using path independence. IEEE Trans. Modeling and Maintaining The Evolution and Validity Comput., 47(12):1351–1362, 1998. of Knowledge. PhD Thesis, University of Toronto, [36] M. K. Reiter and S. G. Stubblebine. Authentication http://hdl.handle.net/1807/11112, December 2007. metric analysis and design. ACM Trans. Inf. Syst. [16] J. Huang and M. S. Fox. An ontology of trust – formal Secur., 2(2):138–158, 1999. semantics and transitivity. In Proceedings of The [37] C. Satizabal, R. Paez, and J. Forne. Pki trust Eighth International Conference on Electronic relationships: from a hybrid architecture to a Commerce, pages 259–270. ACM, 2006. hierarchial model. 2006. [17] J. Huang and D. Nicol. A formal semantics based [38] B. Yu and M. Singh. A social mechanism of reputation calculus of trust. In ITI Research Report, (to be management in electronic communities. In Proceedings submitted for journal publication), University of of Fourth International Workshop on Cooperative Illinois at Urbana-Champaign, 2008. Information Agents, pages 154–165, 2000. [18] A. Josang. A logic for uncertain probabilities. [39] J. Zhang and R. Cohen. Trusting advice from other International Journal of Uncertainty, Fuzziness, and buyers in e-marketplaces: the problem of unfair Knowledge-Based Systems, 9(3):279–311, 2001. ratings. In Proceedings of The Eighth International [19] A. Josang, E. Gray, and M. Kinateder. Simplification Conference on Electronic Commerce, pages 225–234. and analysis of transitive trust networks. Web ACM, 2006. Intelligence and Agent Systems Journal, 4(2):139–161, [40] M. Zhao and S. W. Smith. Modeling and evaluation of 2006. certification path discovery in the emerging global pki. [20] S. D. Kamvar, M. T. Schlosser, and H. Garcia-Molina. In EuroPKI2006, 2006. The eigentrust algorithm for reputation management in p2p networks. In WWW ’03: Proceedings of the 12th international conference on World Wide Web, pages 640–651, New York, NY, USA, 2003. ACM. IdTrust 2009, NIST, April 14-16, 2009 A Calculus of Trust and Its Application to PKI and Identity Management Jingwei Huang & David M. Nicol* Information Trust Institute *Department of Electrical and Computer Engineering University of Illinois at Urbana-Champaign {jingwei,nicol}@iti.uiuc.edu 1 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 2 Specific Motivation (to IdM &PKI) ‰ Trust is a foundation for IdM and PKI ‰ Ten risks in PKI (Ellison&Schneier,2000) ‰ Incident: VeriSign, cert for Microsoft ‰ “Who do we trust, and for what?” [Ellison&Schneier,2000] ‰ Current PKI trust models ¾ Assume -- each certificate has the same level of risk ¾ Evaluate risk -- the longer a certification path is, the higher risk is ¾ Focus on: • Structure of PKI (e.g. hierarchical, mesh, bridge) • Certification path discovery (to find shortest one) ‰ Question: How to quantify the risk associated with trust in PKI? 3 General Motivation ‰ On the Web, people need to interact with “strangers”. Î Trust becomes a crucial problem! Î How can we make trust judgment on the entities we don’t know (or are not familiar with)? 4 Methodology ‰ Our approach of trust modeling ¾ Abstract concepts of trust from social studies ¾ Formalize in logic ¾ Extend logical model of trust to uncertainty model ¾ Apply in real domain and make further improvement ‰ Principles to follow: ¾ Semantics consistency ¾ Common sense consistency ¾ simplicity 5 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 6 Our View of Trust trustor Trust trustee Expectancy: Belief in Willingness to expected behaviors expectancy take risk ‰ Trust is a mental state comprising: (1) expectancy (2) belief – expected behaviours to be true (3) willingness to take risk for that belief 7 Trust in Belief / Performance ‰ By different expectancy, two fundamental types of trust can be identified: ‰ Trust in performance ¾ trust what trustee performs in a context e.g. trust ftd.com to deliver a bouquet as ordered. ‰ Trust in belief ¾ trust what trustee believes in a context e.g. trust the opinion of a wine expert regarding the quality of wine products ‰ Trust is context-dependent e.g. trust a physician in healthcare but not in finance 8 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 9 Formal Semantics of Trust ‰ Uses a logical language of situation calculus. ‰ We develop uncertain trust model, based on a simplified version ¾ Simplifies notation ¾ The obtained results remain true for the full version of logic model. 10 Two Types of Trust ‰ trust_p(d,e,x,k) (trust in performance) --- “Trustor d trusts trustee e on a thing x made by e in context k” ‰ trust_b(d,e,x,k) (trust in belief) --- “Trustor d trusts trustee e on trustee’s belief x in context k” 11 Other Notation ‰ Distrust ¾ distrust_p(d,e,x,k) <=> (madeBy(x,e,k) -> believe(d, k~> neg(x)) ) ¾ distrust_b(d,e,x,k) <=> (believe(e,k ~>x) -> believe(d, k~> neg(x)) ) 12 Trust Reasoning ‰ Trust in belief is transitive trust_b(a,b,x,k) & trust_b(b,c,x,k) -> trust_b(a,c,x,k) ‰ Propagation of trust in performance via trust in belief trust_b(a,b,x,k) & trust_p(b,c,x,k) -> trust_p(a,c,x,k) 13 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 14 Formal Semantics of Uncertainty in Trust ‰ Trust is not binary ‰ Using probability logic [Hajek, 2001], we define: ¾ Degree of trust in performance td_p(d,e,x,k) == pr(believe(d,x) |madeBy(x,e,k) & beTrue(k) ) The sample space based on history of interactions ¾ Degree of trust in belief td_ b(d,e,x,k) == pr(believe(d,x) | believe(e,x) & beTrue(k) ) ¾ Degree of distrust defined similarly 15 Measurement of Uncertainty Trust degree is measured by the fraction of successful encounters td = n/m, dtd = l/m; n + l <= m m – total encounters n – successful encounters; l – negative encounters. ‰ General form td = sum(i=1,…,m; ep(i))/m, dtd = sum(i=1,…,m; en(i))/m 16 More on Uncertainty ‰ Not all encounters need to yield ‘positive’ or ‘negative’ as result ‰ Cognitively there are three mental states: ¾ believed ¾ disbelieved ¾ undecidable. ‰ We model multiple sources of uncertainty: ¾ Randomness, inaccuracy, complexity, incomplete information ‰ Uncertainty is represented as probability distribution (td, dtd, ud) or simply (td, dtd). 17 Trust Calculation in Trust Networks ‰ A trust network is a directed graph, comprising a set of nodes – entities, and edges – trust relationships ¾ A subset of a social network ‰ Calculation of trust from a trustor to a trustee though trusted friends in a network? ‰ Two basic operators: ¾ Sequence aggregation: to aggregate trust in a chain ¾ Parallel aggregation: to aggregate trust in parallel structure 18 Sequence Aggregation ‰ When a trusts b (in belief), and b trusts c (in either belief or performance), how much does a trust c? ¾ For simpler notation, we omit subscripts b (for trust in belief) and p (for trust in performance) ‰ From the formal definitions, we derived and proved a theorem defining td, dtd, and cd = td+dtd 1.2 ¾ cd is “degree of certainty” 1 0.8 cd 0.6 ud 0.4 0.2 0 1 2 3 4 5 6 7 8 9 10 11 12 Length of trust path 19 Parallel Aggregation ‰ Combine independent trust paths. ‰ Use sequence aggregation on paths. e.g. td(a,bi,c)= td(a,bi)*td(bi,c) +dtd(a,bi)*dtd(bi,c) ‰ Aggregated trust degree of trust weighted average e.g. aggregated trust from a to c, td(a,c)’ = [m(a,c)*td(a,c) +m(b1,c)*td(a,b1,c) + … +m(bn,c)*td(a,bn,c)] / [m(a,c)+m(b1,c)+…+m(bn,c)] ‰ Path weight proportional to # encounters 20 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 21 Trust in PKI ‰ Motivating question: ¾ How to quantify the risk associated with trust in PKI? ‰ uncertainty is represented as probability distribution on ‰ Apply the calculus of trust to quantifying risk associated with trust in PKI 22 Trust Evaluation in Hierarchical PKI ‰ Chain of trust: Alice – CA3 – CA1 – CA2 - CA4 tr^b(A,CA3,pk.validity) =(1,0,0) tr^b(CA3,CA1,pk.validity) =(0.98, 0.01, 0.01) tr^b(CA1,CA2,pk.validity) =(0.92, 0.02, 0.06) tr^p(CA2,CA4,pk.validity) =(0.96, 0.01, 0.03) ‰ By sequence aggregation tr^b(A,CA4,pk.validity) =(0.866, 0.037, 0.097) 23 Trust Evaluation in Web PKI ‰ Multiple chains of trust exist 1. Alice-CA3-CA1-CA2-CA4 2. Alice-CA3-CA5-CA4 ‰ Assume path1 the same as before tr^b(A,CA4,pk.validity) =(0.866, 0.037, 0.097) ‰ Assume path 2: tr^b(CA3,CA5,pk.validity) =(0.65, 0.35, 0.1) tr^b(CA5,CA4,pk.validity) =(0.75, 0.00, 0.25) then tr^b(A,CA4,pk.validity) =(0.488, 0.188, 0.324) ‰ For using one-path certification, the shortest certification path may not be the most trustworthy path; ‰ In practice, if the shortest path has unacceptable level of trust, another path with high enough level of trust needs to be found 24 Risk in Multiple Independent Trust Paths ‰ If use multiple independent paths for certification, What is the risk level ? ‰ Assume path i having aggregated trust level (tdi, dtdi, udi) ‰ Let p_i be the probability of certification path i being valid, then ‰ The probability of at least one of n paths being valid will be: Ranges of P and (1-P) PL PU 1 - PLl 1 - PU 1.2 1 0.8 0.6 ‰ So, the probability of multiple independent 0.4 certification paths being compromised, 1-p, 0.2 decreases exponentially 0 ‰ In general, multiple independent trust paths 1 2 3 4 5 6 7 8 9 significantly increase trustworthiness and number of parallel trust paths certainty 25 Example ‰ By path-1: CA3-CA1-CA2-CA4 tr^b(CA3,CA4,pk.validity) =(0.866, 0.037, 0.097) ‰ The probability of path-1 being valid, p1 in [0.866, 0.963] 0.963 = td+ud = 0.866+0.097 ‰ By path-2: CA3-CA5-CA4 tr^b(CA3,CA4,pk.validity) =(0.488, 0.188, 0.324) ‰ The probability of path-2 being valid, p2 in [0.488, 0.812] ‰ Evaluate the probability (p) of at least one path being valid: lower bound: 1-(1-0.866)(1-0.488) = 0.931 upper bound: 1-(1-0.963)(1-0.812) = 0.993 so, p in [0.931, 0.993], which is much more certain and trustworthy than any single-path validation, [0.866, 0.963] and [0.488, 0.812]. 26 Outline 1. Motivation 2. Trust conceptualization 3. Trust formalization / Formal semantics 4. A formal semantics based calculus of trust 5. Quantifying risk associated with trust in PKI 6. Discussion and Concluding remarks 27 Concluding Remarks ‰ The semantics of trust needs to be defined explicitly and accurately. ¾ To avoid misuse of trust ¾ To understand trust deeper ¾ To answer questions about trust clearer and more accurate ¾ To make model design clearer ‰ Our research shows: ¾ Trust in belief is transitive; trust in performance is not, but through trust in belief it can propagate in a social network. ¾ With the growth of the length of a trust path, trust along the path decreases multiplicatively; ¾ Multiple independent trust paths significantly increase the trustworthiness and certainty. 28 Next… ¾ Use quantified risk as heuristics for certificate path discovery ¾ We are looking for industrial partners to put it into practice :) 29 Thank you ! & Questions ? 30 Session 4 – Panel What Is Special About My Application? A Health and Healthcare Perspective April 14, 2009 | 4:00 – 5:30 pm Presenter Walter G. Suarez, MD, MPH President and CEO, Institute for HIPAA/HIT Education and Research President, Public Health Data Standards Consortium Co-Chair, HITSP Security, Privacy and Infrastructure Technical Committee Basic Concepts  What is Privacy (of health information)?  An individual's (or organization's) right to determine whether, what, when, by whom and for what purpose their personal health information is collected, accessed, used or disclosed  What is Security (of health information)?  A defined set of administrative, physical and technical actions used or taken to protect the confidentiality, availability and integrity of health information Source: HITSP Vocabulary – modified and expanded from 45 CFR 164.304 Basic Concepts  Confidentiality  The property that data or information is not made available or disclosed to unauthorized persons or processes  Integrity  The property that data or information has not been altered or destroyed in an unauthorized manner  Availability  The property that data or information is accessible and usable upon demand by an authorized person Source: 45 CFR 164.304 Privacy and Security Scenarios  Patient with sensitive conditions (AIDS, mental health)  Patient’s ability to control granular levels of health information (who can access what, when, for what purpose; selective restriction of access; opt-in/opt-out)  Patient asks for accounting of disclosures  Patient that retracts/changes an existing consent  Need to allow access on emergency situations (‘Break the Glass’)  VIP (politician, movie star, sports figure)  Domestic violence victims  Daughter with sensitive tests hidden from Parent What is Special about Health and Healthcare (1)  Medical records among the most sensitive information about a person  Health care is an information-driven field  Everything about the health care system involves information  Information is much more complex than other industries (amount, type, frequency)  Health information is central to the doctor-patient relationship  Privacy and security of health information are central to the doctor-patient relationship What is Special about Health and Healthcare (2a)  Health care is a complex system, when it comes to health information  Many actors (patient, provider, health plan, employer, government, public health, researchers, vendor, etc)  Various types of information (demographic, clinical, financial)  Many processes related to health information (collection, creation, maintenance, access, use, disclosure)  Many devices associated with, and used in the care of patients (hospital/medical devices, home monitoring devices, others)  Various ways of delivering care (in person, remotely/telemedicine, interactively) What is Special about Health and Healthcare (2b)  Health care is a complex system, when it comes to health information (cont)  Different purposes (treatment, payment, operations, public health, research, judicial, legal, etc)  Many places where health information reside  Lack of common identifiers and other standards  Patient IDs (each provider, each payer)  Provider IDs (although being simplified with the implementaiton of the National Provider Identifier)  Payer IDs  Vendor IDs  Medical Device IDs What is Special about Health and Healthcare (3a)  Many laws  Federal laws, including HIPAA, Privacy Act, Education Records Law, Mental Health Records Laws, Public Health information laws  State laws – patchwork of varying types and levels of state privacy laws, few addressing health privacy and security in a comprehensive fashion  Different policies and practices created and used by organizations  Many go above and beyond what federal/state laws require What is Special about Health and Healthcare (3b)  Laws provide rights to consumers to control their information (through Consumer Consent and Patient Authorization)  Laws provide for boundaries/restrictions on what entities that collect, access, use and disclose health information can do with it  Laws also required certain security protections be implemented by entities on the health information they collect, maintain, use or disclose What is Special about Health and Healthcare (4)  Increasing complexities  Expanded use of electronic health records  Increased electronic communications between patients and the health care system (i.e., websites, email)  Electronic networks (Regional Health Information Exchanges, NHIN)  Evolving personal health records  Different levels of ‘sensitive’ health information What is Special about Health and Healthcare (5)  Inter-jurisdictional Portability  Consumer privacy consent laws and requirements, and consumer privacy desires and directives in one jurisdiction may not be legally applicable/enforceable in another jurisdiction  An entity operating in one jurisdiction uses and discloses health information based on its own policies and procedures, created to meet consent requirements under that jurisdiction  When information is disclosed to a different entity in another jurisdiction, the receiving entity applies its own policies and procedures to the received data, which where created to meet consent requirements under the receiving entity’s jurisdiction What is Special about Health and Healthcare (6)  Cross-validation and verification of conflicting consents  What is the most recent/latest consent from a patient?  Does that override other consents for specific data, specific purpose?  Where can I find the various consents issued by a consumer to perform cross-validation and verification? What is Special about Health and Healthcare (7)  Security Requirements  Identification, Authentication  Various actors and systems  Patient, Providers, Payers, Others  Authorization, Access Controls  Who can collect, access, use, disclose what  Audit  Account for access, edit, delete, and other actions, by actor  Account for security threats  Secure data transport, non-repudiation, message encryption  Time-stamp Privacy and Security Interoperability – The Next Challenge Internal Security Internal Security Policies, Procedures Health Policies, Procedures and Practices andHealth Practices Care Care System Secure System Secure System System Architecture Architecture Inter-organizational Exchange Intra-organizational Intra-organizational Security, Privacy, Security Security, Privacy, Infrastructure Privacy Infrastructure Infrastructure Contact Information Walter G. Suarez, MD, MPH President and CEO Institute for HIPAA/HIT Education and Research (703) 354-0042 walter.suarez@sga.us.com An Overview of E-Voting Security Challenges IDTrust April 14, 2009 Andrew Regenscheid Computer Security Division National Institute of Standards and Technology Overview  Background  Security Challenges in E-voting  Strong authentication and Voter privacy  Transparency and Auditability  Usability and Accessibility  Difficulty of making good security decisions  Research Areas in E-voting Page 2 NIST Voting Efforts  NIST provides technical support to the EAC in the development of the voting guidelines  VVSG  Technical research items  UOCAVA voting  Topic Areas  Security  Usability and Accessbility  Hardware & software reliability Page 3 (Nearly) Conflicting Goals  Need to identify and authenticate voters to ensure only eligible people vote  Need to protect voter privacy to prevent coercion  Protect privacy even from insiders  Protect voters from themselves (vote selling)  This is why voting is an interesting crypto problem Page 4 I&A for E-voting  I&A works differently for different systems  Polling place e-voting  I&A performed by officials separately from voting machines  Voters receive a token to vote after checking in  Authentication information varies  Internet voting  Voting systems authenticate voters  Typically, PINs are used Page 5 Transparency and Auditing  Many systems must provide evidence of correct behavior  It’s mostly a matter of:  Who can do the auditing?  What information do they need?  Often owners/operators need assurance of correct behavior by equipment  Auditing can be difficult on voting systems  The general public needs assurance of fair & honest elections Page 6 Usability and Accessibility  These are goals for many systems  Accessibility is mandated by law  Usability hampered by:  Limited opportunity for training  Systems seldom used  Expectation that any voter can walk up to a voting machine and easily vote without assistance  These issues limit acceptable technical solutions to security challenges. 2/6/2009 Page 7 Decision Making  Goal is cost-effective, risk-based security  This is difficult to do with voting  There are no risk assessments on voting systems  It can be difficult to detect security violations  Difficult to monetarily quantify loss Page 8 Current Research  Auditable Voting Systems  Split-Process Architectures  Spread out trust over several pieces of equipment  Detect fraud when at least one device functions properly  End-to-End Voting Systems  Cryptographic schemes  Voters can verify integrity of their own votes  Anyone can verify vote tabulation Page 9 Thank you Page 10 Security and Social Networking Barry Leiba Internet Messaging Technology Aspects of Computer Security  Authentication: Who am I? Prove it.  Authorization: What am I allowed to do?  Access Control: What can I allow others to do?  Privacy: Am I safe from unauthorized viewing?  Integrity: Am I safe from undetected changes?  Non-repudiability: Can I or others deny what they said or did? The Social Networking Model  Everything is shared  You make “friends”  All friends are equal  Some systems allow categorizing friends  It's not convenient  It's not really part of the model  “Friending” is often fairly promiscuous  Friends post public communiques to you Some Problems  IRL, not all friends are equal  You don't usually share everything with everyone  Close friends, work friends, …  IRL, it may not be easy to categorize friends  One friend belongs to multiple categories  The categories overlap in odd ways  Category combinations are unworkable Some Problems  IRL, you choose friends more carefully  Face-to-face information is more certain  Face-to-face interaction provides many cues  IRL, your friends have more limited access  ...to you  ...to what you have to share  ...to your other friends  ...to what your other friends say Example  Joe has a party IRL  Some of Joe's friends are invited  Some are not  The next day, friends post to Joe's “wall”  Thanks for the wonderful party!  What a great time we had!  Check out this pic from the party!  Joe's uninvited friends see that too Example  Is Britney Spears Spam?  Automated filtering in social networking?  Much more a value judgment than with email  You want to be her “friend”; I don't  Is it really her?  What are the tradeoffs? Some Problems  Online presence is vulnerable to malware  Accepting certain things from false “friends” can be dangerous  Once infected, you will infect real “friends”  ...even if they trust you Example  Social Honeypots: Making Friends With A Spammer Near You  Researchers created MySpace identities  Waited for “friend” requests; stored and rejected  1570 requests, most within 2 months  Click traps, Friend infiltrators, Pornography, Pills  1245 contained links  1048 links worked  Only 6 unique clusters Some Problems  “Anonymized” data is aggregated for analysis  Aggregated data is vulnerable (AOL problem)  Anonymization isn't sufficient Example  De-anonymizing Social Networks  Researchers looked at Flickr and Twitter  Anonymized network graph of Twitter  Identified network information from Flickr  Relatively small overlap between the two  Very successful at identifying Twitter users Authentication & Access Control  They like to use other services  Import your address book (from Gmail)  Access photos from Flickr (Yahoo!)  Print your friends' photos (Kodak Gallery)  OpenID  Shared authentication service, no access control  Oauth  Distributed access control  IETF chartering a working group Legal Questions... Is anonymization of data sufficient to protect our privacy? As we live our lives more publicly, do we give up a legal sense of expectation of privacy? References  Web Searchers’ Identities Traced on AOL; Barbaro, M. and T. Zeller Jr.; New York Times article; 9 August 2006; http://www.nytimes.com/2006/08/09/technology/08cnd-aol.html  Is Britney Spears Spam?; Zinman, A. & J. Donath; 4th Conference on Email and AntiSpam; August 2007; http://www.ceas.cc/2007/papers/paper-82.pdf  Social Honeypots: Making Friends With A Spammer Near You; Webb, S., J. Caverlee, C. Pu; 5th Conference on Email and AntiSpam; August 2008; http://www.ceas.cc/2008/papers/ceas2008-paper-50.pdf  De-anonymizing Social Networks; Narayanan, A. and V. Shmatikov; IEEE Symposium on Security and Privacy; May 2009; http://www.cs.utexas.edu/~shmat/shmat_oak09.pdf What is Special About My Application? for the NIST Idtrust 2009 Symposium 14th April, 2009 For information, please contact: Bob.Sunday@pwgsc.gc.ca Secure Channel: The Enabler for Government On-Line • Federal • Provincial Citizens • Municipal Businesses • Business Visitors Typical GOL Services • Canada Site • Gateways • Clusters • EI on the Web • Census 2006 (surveys..) • E-consultation • Dep’t web sites(info) • Tax Filing Online • My Tax Account • Business Tax Account • Record of Employment • Address Change • Interactive Info Service • GC Employee Services • Passport On-line 2 epass Canada (the Common Registration Service) • Single Sign-on • Two-way encryption (user <--> department) • Signature Verification • On-line Registration • On-line or In-Person ID Proving • Out-of-Band Secret option • Time Stamping • Non-Repudiation support • User managed 3 Secure Channel Enabled Applications in Production Department or Agency First Implementation Number of Programs Canada Revenue Agency (CRA) 09/01/2002 40 Service Canada 04/01/2003 9 CRTC 08/25/2004 5 Atlantic Canada Opportunities Agency 08/30/2004 3 Health Canada 09/15/2004 1 Veterans' Affairs Canada (VAC) 11/12/2004 2 Téléfilm 12/06/2004 2 Foreign Affairs Canada 01/12/2005 1 Enterprise Cape Breton Corporation 02/01/2005 3 Environment Canada (EC) 03/30/2005 1 Immigration and Refugee Board 04/22/2005 1 Competition Tribunal 06/06/2005 1 Department of National Defence 10/06/2005 1 National Energy Board 10/07/2005 1 Transport Canada (TC) 11/21/2005 4 International Trade (ITCan) 11/30/2005 1 Bank of Canada 03/06/2006 1 Agriculture and Agri-Food Canada 03/31/2006 1 Canadian Nuclear Safety Commission (CNSC) 05/19/2006 1 Canadian International Trade Tribunal (CITT) 83 Programs in 23 Departments 06/30/2006 1 Natural Sciences & Engineering Research Council (NSERC) 05/14/2007 1 Citizenship and Immigration Canada 4 06/25/2008 1 Issued epass Certificates (since Sept 2002) 5 Weekly Logins and Registrations (April 1, 2008 to February 28, 2009) 6 6 7 So why does GC need to change? • $$$$  Decentralized funding  Expense of PKI  Custom GC code • Risk based Assurance Model • Multi-jurisdiction environment  Provincial, municipal • Changing policy requirements  Digital signature  Positioning for future identity possibilities 8 Innovation Activities (Research Agenda) HiDef Video Remote Conferencing Worker Unlicensed Mobile Centrex Access Telepresence Wireless Migration Voice/Data Virtual GEDS+ Convergence Worlds Cloud Wi-Fi Computing Desktop Common Email IWS Virtualization Addresses PDA Shared Green Access Cards Projection Phase II Study Wireless/Mobile Shared Best Practices Access Cards Phase I Idea Analysis PoC or Study Handoff for Production or Closed 9 Some thoughts 1. Stable interfaces over the long term are still necessary  We must continue to interoperate  Return on investment  Expense of changing 2. Movement of the interface boundary to the human interface will cause new interoperability challenges  Loss of choice  Vendor/Provider lock-in  Dependence on visual environment  Accessibility?  Language choice?  Weakest link in the security chain  If we must go here, then do we standardize the people? 10 Cloud Computing Service Layers Boeing Technology | Information Technology Information Security Services Description Services – Complete business services such as Services PayPal, OpenID, OAuth, Google Maps, Alexa Application – Cloud based software that eliminates Application Application the need for local installation such as Google Apps, Focused Microsoft Online Development – Software development platforms used Development to build custom cloud based applications (PAAS & SAAS) such as SalesForce Platform – Cloud based platforms, typically provided Platform using virtualization, such as Amazon ECC, Sun Grid Storage – Data storage or cloud based NAS such as Infrastructure Storage CTERA, iDisk, CloudNAS Focused Hosting – Physical data centers such as those run by Hosting IBM, HP, NaviSite, etc. Copyright © 2007 Boeing. All rights reserved. General Characteristics by Service Layer Boeing Technology | Information Technology Information Security Relative Inter- Difficulty of Capability Information effectiveness operability enterprise Services Maturity Risk of technical controls Risk integration Services Application Development Platform Storage Hosting Copyright © 2007 Boeing. All rights reserved. Cloud Property Model Boeing Technology | Information Technology Information Security What interfaces are available? How are the interfaces built? Who controls them? Proprietary Open External Where Who Does the service Is the physical provider work for? infrastructure? Outsourced Internal Insourced Copyright © 2007 Boeing. All rights reserved. Example Security Questions Boeing Technology | Information Technology Information Security Where is my data? How is my data protected in transit? Who is responsible if something goes What due diligence did my employees wrong? do prior to using the service? What about business continuity? What leaks are there from the cloud service back into my infrastructure? How does my data securely enter and exit the cloud? External External / Internal distinction fades as effects of deperimeterization increase Internal Insourced Outsourced Will I be able to deliver? Who has access to my data? Distinction Do I have the skills? fades as What about export and Privacy laws? collaboration Do I have the resources? How is the EXT/INT interface increases managed? Can do I recover costs? Can the Outsourcer integrate into my infrastructure? Copyright © 2007 Boeing. All rights reserved. Example Interoperability Questions Boeing Technology | Information Technology Information Security What if I need to switch vendors? Is this where I want to be? What if my collaboration partner uses Do I still need internal cloud services? a different vendor? Do I have to implement proprietary interfaces to do business with the provider? External External / Internal distinction fades as effects of deperimeterization increase Internal Proprietary Open When I run out of resources can I Will this allow me to leverage multiple engage an external cloud service Distinction cloud service providers to jointly provider? Hinders collaboration perform a task? and agility Can I simultaneously engage multiple Will it further enable collaboration service providers? among multiple partners? Who should control them? Copyright © 2007 Boeing. All rights reserved. IDentity and Trust in Context Outline of This Talk ------------------------ • The overall context Peter G. Neumann • Global-scale ID management Principal Scientist • Assessable ID/privacy protection SRI International ComputerSciLab • Health-care as an example Menlo Park, CA 94025-3493 • Attribute-based encryption Neumann@CSL.sri.com • Attribute-based messaging http://www.csl.sri.com/neumann • Lattice-based cryptography Telephone 1-650-859-2375 • References, URLs, search words IDes+2 of April 2009, NIST 1 2 IDentity IDtrust and Trustworthiness ------------------------ ------------------------ Something that identifies a person ‘IDtrust’ begs the question: Why (or class of persons, or process, or trust authentication systems/IDs? piece of hardware, or other computer- Because it’s easy? Alternatives are related entity) – but not necessarily not user-friendly? I’m not paranoid? uniquely. Trustworthiness of mechanisms, systems, and people on which you must depend is very important, but difficult to ensure. Risks: errors, ID fraud, spoofing, ... [References] 3 4 IDeals and IDylls IDiomatic? ------------------------ ------------------------ In the myth of perfect security, our Psychoanalytic terms (IDentity types) beliefs are often misplaced. Perfect • ID: completely unconscious security does not exist. Instead, we division of the psyche (users!) tend to have: • EGO: organized conscious • IDeology: Faith-based security mediation (administrators!) • IDolatry: Worship of physical • SUPEREGO: partially conscious security rather than systemic and morality/conscience/guilt/... operational security. (privacy advocates!) 5 6 The Basic IDea IDealization ------------------------ ------------------------ We need holistic total-system We need to mask underlying trustworthy identity management. complexity to make IDs and IDeally, IDentities should relate ID management more usable – to strong system authentication, with abstraction, encapsulation, fine-grained authorization, invisible encryption/hash functions, nonsubvertible accountability, virtualization, sensible interfaces, real-time and post-hoc analysis, judicious use of anonymization, remediation, revocation, and more. and much more. 7 8 IDiosyncrasies IDiots and IDleness ------------------------ ------------------------ Characteristic peculiarities must be • IDiot: Typically, an attribute accommodated. “One size fits all” associated with someone blamed for is not practical, with many special misusing a dysfunctional human cases: long names, hyphenated names, interface or who is dysfunctional. foreign languages, alternative spellings, • IDleness: Inaction that may result non-ASCII characters, ambiguities, in serious risks, typified by laziness false positives/negatives, and much with respect to security practices. more. Beware of oversimplification! 9 10 IDeograms Global-Scale ID Management ------------------------ ------------------------ IDeograms are symbolic but not ID management, authentication, literal representations, useful for authorization, accountability must identification (candidate or party • adapt to continual change icons in elections), CAPTCHAs (for • transcend local identities confirmations), authentication. • transcend centralized control Caveats: dyslexia, prosopagnosia • transcend untrustworthy systems • transcend untrustworthy people (face-blindness), other disabilities, • avoid conflicts and ambiguities user unfriendliness, ... • scale to large heterogeneity 11 12 Roadmap for Global ID Management Assessable IDentity and ------------------------ Privacy Protection Doug Maughan’s R&D roadmap for ------------------------ cybersecurity addresses GIDM as one Dartmouth-I3P-funded joint project: of 11 hard problems, holistically • MITRE (PI Bruce Bakis) * synergistic with the other 10: • Cornell University scalable trustworthiness, metrics, • Georgia Tech evaluation life-cycles, insider threats, • Purdue University * malware, system survivability, • SRI International situational awareness, provenance, • University of Illinois Urbana * privacy-aware security, usability. [* => project paper presented here.] 13 14 Some Health-Care Challenges Health-Care Risks ------------------------ ------------------------ Patient and personnel identification, • System and information misuse; authentication, authorization, wrong IDs, privacy violations, mal- accountability; correct up-to-date practice, ... (http://www.risks.org). medical histories; network/system/ • Computer-centric doctors may cause data security, integrity, privacy; patient depersonalization. (See The controlled data access for insurance, Computer Will See You Now, Anne medication, research, and analysis. Armstrong-Cohen, The New York Times, March 6, 2009, risks-25.60). 15 16 Health-Care Risk Avoidance Attribute-Based Encryption (ABE) ------------------------ ------------------------ • Trustworthy systems are essential, ABE (Brent Waters et al.) involves but privacy is largely extrinsic. IDs, role-based-like authorization with They demand pervasive oversight. expressive access controls, practical usability, collusion resistance, • Well-defined enforceable policies simplifies key management, and is are essential. holistically well-suited to • Attribute-based encryption might applications such as health care provide natural mappings between (21 papers since 2007). Search: identities and role-based applications. functional encryption Waters 17 18 Attribute-Based Messaging (ABM) Lattice-Based Cryptography (LBC) ------------------------ ------------------------ • UIUC’s ABM (Carl Gunter et al.) • LBC (Chris Peikert et al.), based uses ABE. The messaging system on a problem other than factoring constructively uses access-control or discrete logs, seems resistant to attributes that can be systematically quantum computing. Uses include derived and automatically managed strong public-key cryptography and (10 recent papers). Search: a hash function SWIFFTX with provable properties: a NIST SHA-3 attribute messaging Gunter candidate (11 recent papers). Search: Peikert 19 20 Conclusion CSTB Trustworthiness/ID Reports ------------------------ ------------------------ • Local and global IDentities need • NatlResCouncil, www.nap.edu: trustworthy systems and networks ⋆ Toward a Safer and More Secure with authentication, authorization, Cyberspace, 2007 accountability, and much more. ⋆ IDs Not That Easy: Questions About Enterprise architectures, system en- Nationwide Identity Systems, 2002 gineering, sound operational prac- ⋆ Trust in Cyberspace, 1998 tices, usability, and people tolerance ⋆ Computers at Risk: Safe Comput- are all vital to reducing risks. ing in the Information Age, 1990 21 22 PGN IDentity Reference Other Relevant PGN References ------------------------ ------------------------ • PGN, Security and Privacy in the • Reflections on System Employment Eligibility Verification Trustworthiness, Advances in System (EEVS) ..., House Ways and Computing, volume 70, Academic Means Committee Subcommittee on Press, Elsevier, 269–310, 2007 Social Security, 7 Jun 2007. • Principled Assuredly Trustworthy http://www.csl.sri.com/neumann/ Composable Architectures, 2004: http://www.CSL.sri.com/neumann/ house07.pdf chats4.html, .pdf, .ps 23 24 More PGN References IDiographic Summary ------------------------ • Holistic Systems, ACM IDentity IDeals, offset by SIGSOFT Softw.Eng.Notes, Nov. 2006 kIDstuff fIDelity and http://www.csl.sri.com/ epIDemic avIDity slowed by neumann/holistic.pdf accIDental antIDotes with • Computer-Related Risks, consIDerable fastIDiousness and Addison-Wesley, 1995 indivIDual coincIDences but with • www.CSL.sri.com/neumann improvIDent backslIDing, result in • ACM Risks Forum, www.risks.org self-evIDent nonconfIDence or else unconsolIDated overconfIDence! 25 26 Palantir: A Framework for Collaborative Incident Response and Investigation Himanshu Khurana, Jim Basney, Mehedi Bakht, Mike Freemon, Von Welch, Randy Butler NCSA, University of Illinois 1205 W. Clark St., Urbana IL 61801, USA {hkhurana, mbakht2}@illinois.edu, {jbasney, mfreemon, vwelch, rbutler}@ncsa.uiuc.edu ABSTRACT loss have motivated organizations to ramp-up their secu- Organizations owning cyber-infrastructure assets face large rity stance and better prepare for dealing with such inci- scale distributed attacks on a regular basis. In the face of dents, for example, by establishing Computer Security In- increasing complexity and frequency of such attacks, we ar- cident Response Teams (CSIRTs) [8] and setting up digital gue that it is insufficient to rely on organizational incident investigation procedures [26]. Such capabilities allow for in- response teams or even trusted coordinating response teams. cident response that results in full recovery and patching to Instead, there is need to develop a framework that enables prevent relapse as well as for working with law enforcement responders to establish trust and achieve an effective collab- when appropriate to pursue criminal prosecution. While orative response and investigation process across multiple measuring the success of these capabilities is not easy, anec- organizations and legal entities to track the adversary, elim- dotal evidence and an increasing deployment rate indicates inate the threat and pursue prosecution of the perpetrators. their effectiveness. However, a new breed of large-scale dis- In this work we develop such a framework for effective col- tributed cyber-attaks is emerging that is characterized by laboration. Our approach is motivated by our experiences in a set of motivated, dedicated and resourceful adversaries dealing with a large-scale distributed attack that took place that attack a number of hosts, sites and organizations that in 2004 known as Incident 216. Based on our approach we apan multiple countries. In these attacks adversarial mo- present the Palantir system that comprises conceptual and tivations range from demonstrating hacking skills to crimi- technological capabilities to adequately respond to such at- nal intent for financial gain, and specific targets range from tacks. To the best of our knowledge this is the first work sensitive data theft and public image maligning to network proposing a system model and implementation for a collab- disruptions (e.g., via denial-of-service). These attacks can orative multi-site incident response and investigation effort. be overwhelming to individual organizations responding on their own. A prime example of such a large-scale distributed attack Categories and Subject Descriptors and our motivating use case is a series of cyber attacks K.6.5 [Management of Computing and Information known as Incident 216 [32]. This incident took place in Systems]: Security and protection 2004 and involved an attacker from a foreign country who compromised the integrity of a large number of hosts in U.S. government, higher education, and commercial institutions General Terms and similar institutions abroad. The incident response and Security investigation process for Incident 216 brought to fore new re- quirements and challenges for dealing with large-scale multi- site attacks in a collaborative manner. That is, there is a Keywords need to develop a framework for effective collaboration on incident response, digital investigation, multi-site collabora- incident response and investigation tasks by sharing infor- tion mation and resources. Establishing trust is a major challenge for these collab- orations. First, the affected organizations are chosen by 1. INTRODUCTION the attacker(s), rather than the organizations themselves, Increasing awareness of cyber-security incidents in terms so there may be no existing relationships in place between of their prevalence, impact on productivity and financial the organizations. Second, since the collaborations would typically need to take place only after an incident occurs, involve many organizations and last for the duration of the response/investigation, they need to be short term and dy- Permission to make digital or hard copies of all or part of this work for namic in nature. Third, the collaborations need to deal with personal or classroom use is granted without fee provided that copies are data and information that is sensitive and private in nature. not made or distributed for profit or commercial advantage and that copies This includes 1) sharing of logs across institutional bound- bear this notice and the full citation on the first page. To copy otherwise, to aries with user information in them that faces issues of se- republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. curity and privacy, 2) interaction with law enforcement and IDtrust ’09, April 14-16, 2009, Gaithersburg, MD 3) interaction with the media. Copyright 2009 ACM 978-1-60558-474-4 ...$5.00. These aspects of the collaboration lead to several chal- tion. lenges that must be addressed when designing a collabora- Our work is the first to develop a framework for support- tion framework. First, the framework must provide a means ing multi-site collaborative digital investigation and incident for managing the tasks and processes for response and in- response. We integrate the two areas of prior work, namely, vestigation undertaken by the CSIRTs of the collaborating digital investigation and incident response, by developing organizations; i.e., determine who should do what and when. models for Roles and Responsibilities as well as Processes Second, in order to manage the tasks the organizations must that identify their interaction. Furthermore, we propose to place trust in each other and provide a means to share infor- extend the scope of CERTs/ISACs to support effective col- mation and resources. Third, the framework must provide laborations involving multiple organizations by additionally trustworthy information and data management with effec- becoming ICIMs. tive access control given the sensitive nature of the collabo- The rest of this paper is organized as follows. In the next rations. Section we present lessons learned from Incident 216. In In this work, we review lessons learned from Incident 216 Section 3 we discuss the requirements, challenges and ap- and propose an effective collaboration framework, that com- proach. In Sections 4 and 5 we specify the system model. In prises a system model as well as a system design and proto- Section 6 we discuss the security architecture. In Section 7 type implementation that allows multiple organizations and we discuss the challenge of trust establishment. In Section 8 legal entities to actively collaborate for investigating and we describe the prototype implementation, and we provide responding to cyber-attacks. While the proposed response an evaluation of our approach in Section 9. In Section 10 and investigation system is distributed in nature, it is cen- we discuss related work and we conclude in Section 11. trally managed by a trusted entity, which we call an Inde- pendent Center for Incident Management (ICIM). The sys- 2. INCIDENT 216: LESSONS LEARNED tem model for the response and investigation process defines The scenario motivating our work is an attack by an indi- the roles, responsibilities and processes undertaken by mul- vidual or group against hosts, sites, and organizations across tiple organizations (including law enforcement) to achieve multiple countries. A prime example and our motivating full recovery and prosecution. The system design carefully use case is a series of cyber attacks known as Incident 216. addresses security and privacy of the data (e.g., security and This incident took place in 2004 and involved an attacker network logs) and messages (e.g., emails, instant messages, from a foreign country who compromised the integrity of a web boards) exchanged across organizations during the re- large number of hosts in U.S. government, higher education, sponse and investigation process. The security architecture and commercial institutions and similar institutions abroad. provides identity-based and role-based authorization to facil- While the ultimate motivations of the attacker remain un- itate sharing and collaboration according to organizational known, he seemed to be primarily interested in building this policies and trust relationships. The prototype system im- network of compromised hosts for his own personal interests. plements roles and processes for responding to and investi- The attacker behind Incident 216 used a well-organized gating an incident, incorporates tools for the collaborative process for compromising a large number of hosts and then response and digital investigation process, and provides ad- harvesting user passwords to continue to expand his set equate security and privacy. of compromised hosts. The attacker initially compromised Our approach builds on several well-known principles for some number of hosts using known exploits. He then in- effective collaboration. For trust establishment we adopt a stalled trojan secure shell (SSH) clients on these systems mutual incentives based approach where organizations par- that harvested host, username and password tuples as users ticipate so they can learn more information and can get ac- used the trojan SSH clients to logon to other systems. The cess to additional resources in order to respond to and re- attacker then used those stolen credentials to logon to those cover from the attacks in their organization. Furthermore, systems and then gained administrative privileges via known we use a collaborative access policy enforcement approach exploits for privilege escalation. Once administrative privi- so that organizations providing leadership in the response leges were gained, the attacker would then install a rootkit process can collectively define access policies. For managing to hide himself and trojan the SSH clients to use the new tasks and processes we focus on identifying specific tasks system to gather further account information to repeat the that warrant collaboration and integrate them in a well- process and grow the base of compromised systems. As dis- defined process workflow for each organization. Finally, for cussed by [32], he used the SSH “known hosts” file to find managing data and information we use role based access new attack targets. control with the least privilege principle in mind. We use Besides the fact that the attacker’s collection of com- these principles to design a framework that addresses this promised systems was spread across multiple domains, the important problem of large-scale cyber-attacks. attacker also had supporting infrastructure that was also Dealing with multi-site attacks has long been an impor- spread over multiple domains. Figure 1 shows these sup- tant issue for the security community. For example, Com- porting systems, which included: puter Emergency Response Teams (CERTs) and Informa- tion Sharing and Analysis Centers (ISACs) have been setup • A Password Collector. Every time a trojan SSH around the world for vulnerability and exploit tracking as client captured a hostname, username and password well as facilitating coordination between CSIRTs. We be- tuple, it sent this information over the network to the lieve that institutions like CERTs and ISACs could poten- Password Collector host. The Password Collector host tially serve as ICIMs in our system model. By doing so they was one of the compromised hosts where the attacker would extend their current capabilities to support more ef- installed a service to collect and record these tuples for fective multi-lateral collaboration between the sites, provid- latter use. ing significantly improved incident response and investiga- • A Dynamic DNS Service. The trojan SSH clients that the intruder was monitoring the email of a security administrator, motivating the use of email encryption, which was cumbersome for group messaging. NCSA staff worked side-by-side with FBI investigators to investigate and solve these attacks. One of the hardest chal- lenges investigators faced during the investigation was the lack of knowledge in the field to identify the attacks at each of the attacked sites and hosts, without any existing co- ordination between sites that had been attacked. Further complicating this was a void of automated analysis of the security log information that was available, leaving the in- vestigation up to few individuals who analyzed all of the data by hand. The NCSA investigation team committed over 3000 hours in the pursuit of this investigation. In addi- tion to the forensic investigation from security log analysis, considerable effort was undertaken by legal teams in multi- ple countries to identify the perpetrator and build sufficient evidence against the perpetrator to hold up in court. This aspect of the investigation also faced hurdles in effective col- laboration between prosecutors in multiple countries as well as collaboration among law enforcement personnel and sys- tem administrators. The total duration of the investigation Figure 1: Topology of Incident 216 Attacker Net- lasted over nine months with extensive delays caused by the work repeated time-consuming tasks of establishing trust between the attacked sites as well as in dealing with the complexity of used a statically configured hostname to address their the attack and the tasks required for both incident response network traffic with the captured tuples. This host- and forensic investigation. name was managed by the attacker through a public dynamic DNS site that allowed him to manage the mapping of the hostname to an IP address anony- 3. REQUIREMENTS, CHALLENGES AND mously via a web form. This allowed him to move APPROACH the Password Collector several times during the inves- In this section, we outline the challenges that need to be tigation when he felt it was potentially discovered and overcome and the requirements that need to be met for ef- being monitored. fective collaborative response and investigation of large scale distributed attacks. We then outline our approach, which is • Hacker Tools Repository. On one of the hosts the then detailed over the next three sections. attacker compromised, he installed a set of exploits Requirements and Challenges. In dealing with large- that he used for privilege escalation. These tools were scale attacks with Incident 216 being an example, the inci- made available via a web server already installed on dent response and investigation process faces three kinds of the host. After gaining access to a new host, he would challenges. download these tools and use them to gain privileged First, it is hard to establish adequate levels of trust be- access. tween the involved institutions and personnel. Institutions • Login Route. Instead of logging in directly from his are reluctant to share information and communicate over local system to compromised systems, the attacker al- such matters while effective response to such attacks requires ways went through a series of distributed intermediate them to share information, data (e.g., logs) and communi- systems. Presumably this was done to make the task cate regularly. The core issues behind the reluctance are of tracking a session back to the attacker difficult. security, privacy and financial concerns. For example, logs contain user data that needs to be protected by law, leak- Investigation of Incident 216 was a difficult task because it age of information to media and competitors can harm the required data acquisition across a wide range of distributed institution’s image and lead to financial losses, leakage of in- systems. Within a week of the initial discovery of the at- formation to the adversaries can worsen the ongoing attacks tacker, the investigation spanned a dozen sites. Eventually, causing further delays in recovery, and investment of per- the attacks spanned tens of sites in multiple countries. Many sonnel time towards regular communication without a clear of the system administrators at the various sites were willing view of benefits can be perceived as a waste of resources. and even eager to help in the investigation, but often lacked Second, even after establishing adequate levels of trust, the skills or time to assist, even with just understanding the managing all the tasks and processes in the response and events at their own site. investigation processes is hard. There are a myriad of tasks The result was a highly manual investigation process with and activities that need to be executed and managed. This the lead investigators walking sites through data gathering includes, for example, detecting the attack, evidence gather- on their local systems, and then collecting, managing and ing and storage, forensics and discovery of the attack, restor- analyzing this data. Communication between the various ing services, eradicating vulnerabilities and flaws, sharing investigators was ad hoc, with a combination of telephone data and logs, collaborative decision making, information and email. At one point in the investigation it became clear sharing and analysis, and legal prosecution. Typically, such a complex set of tasks and activities are organized into in- dealing with active adversaries who specifically attack com- tuitive phases such as preparation, analysis, recovery, etc. munications between administrators to disrupt the response However, in large-scale attacks different institutions can be process (as observed in Incident 216). An analysis of such in different phases and, furthermore, depending on the at- threats led to the design of the security architecture that tack sequence and evidence discovery, institutions can have includes strong two-factor authentication, Role Based Ac- multiple phases active. Management of tasks and activi- cess Control authorization, and a secured network perimeter ties is further complicated by the duration of the response around the servers implementing the workspace. In analyz- and investigation process, which lasted several months in ing the interplay between implementing a flexible workspace the case of Incident 216. Such long durations make ad-hoc and meeting the security requirements, we chose a central- approaches insufficient. ized workspace environment for simpilcity but we believe Third, at the core of the response and investigation pro- that a distributed workspace implementation is also feasible cess is analysis of the digital system that includes logs and though perhaps with higher costs. alerts gathered by various system components such as IDSs, Collectively, the workspace along with its default set of server logs, and network logs. These logs can be large in size tools and the security architecture address the remaining (100s of MBs or several GBs per day is not uncommon) and requirements. The presence of such a secured workspace have varying formats across different organizations. Con- with a plethora of useful tools will make it significantly eas- sequently, the tools needed to analyze the digital systems ier for organizations to establish trust and collaborate on the as well as personnel skills required to do so are not always investigation and response process by committing resources available with all organizations that are part of a large-scale and personnel. Knowing that their data is well protected attack. Furthermore, in a collaborative response and inves- and can be anonymized, if needed, will encourage them to tigation effort all of this data will need to be managed for share data and logs. The workspace also allows the collabo- the duration of the effort. rative process to be managed for a long duration, if needed. Approach. In this work we take a comprehensive ap- Lastly, the specific tools in the workspace allow for effective proach of defining a system model, specifying the security data management and analysis. architecture and describing the system implementation to address all of these requirements. The proposed system 4. ROLES AND RESPONSIBILITIES model comprises two components: 1) a Roles and Respon- At the core of any collaborative multi-site response to a sibilities Model that defines the entities involved in the re- large-scale attack is a dedicated team of personnel staffed sponse and investigation, their responsibilities and their in- by the sites and by law enforcement. In this section we teractions and 2) a Process Model that defines the various identify roles played by these personnel and the responsibil- phases of the response and investigation process as well as ities associated with each role. To ensure that these roles the execution of responsibilities in these phases. Combining and responsibilities are comprehensive but not significantly together these components will ensure that the response and overlapping we use the following approach. First, we distin- investigation team members will be able to effectively man- guish between site roles and collaboration roles. While the age the required tasks. In particular, the system model effec- same individual may be assigned to both site and collabo- tively integrates the technical incident response and the legal ration roles, distinguishing the roles allows for contextual- investigation and prosecution process in a multi-site collab- ization of responsibilities (i.e., site versus collaborative) and orative manner. The following risks are minimized by this supports multiple reporting hierarchies to allow for effec- system model: missed or unassigned responsibilities, over- tive team management. Second, we identify roles that cover lapping responsibilities, unclear reporting functions in a site technical, managerial, public relations and legal responsibil- as well as in the collaborative effort, inability to track global ities. These broad set of roles and responsibilities allow for progress and ineffective management of tasks and phases be- the specification of comprehensive policies and procedures in tween a site and the collaborative effort. dealing with large scale attacks effectively. Specifically, the At the core of the system implementation is a collabo- roles in our proposed model can be divided into the follow- rative workspace hosted by the ICIM that is accessible by ing five categories: 1) Site Technical Roles, 2) Collaboration all team members for managing and analyzing data (such as Technical Roles, 3) Site Legal Roles, 4) Law Enforcement logs) and communications. While it is possible to implement Roles and 5) Other Roles. Third, we place the responsibil- this workspace in a distributed manner (e.g., using peer-to- ities of each role in the context of the response and investi- peer systems) we chose a more centralized approach based gation process, as described in Section 5. Next we describe on our model of central management and also to be able to each role and its associated responsibilities. provide better security. In doing so we assume the risks of a The Site Technical Roles are responsible for local inves- single point of failure but benefit from greater security and tigative activities at the site. The Site Lead is the person management assurances. The workspace is equipped with a who leads the investigation in a particular site. He/she is default set of tools specifically geared towards addressing the also the point of contact for that site in the collaborative above requirements. This includes tools for secure email, in- investigation process. The Site Incident Investigator as- stant and web messaging, log and data anonymization, data sists the Site Lead with the local investigation, as well as and evidence storage, and data and log analysis and foren- containment, eradication, and recovery activities. The Site sics. For broad adoption we have composed the workspace Digital Forensics Specialist collects, extracts and stores using open-source tools. digital evidence locally based on the investigation strategy The proposed security architecture is designed to address determined by the Site Lead. This role requires expertise a large number of threats from both passive and active ad- with digital forensic tools and adequate training/knowledge versaries. We enumerate these threats in Section 6. Threats to follow the right procedures so that collection and handling from active adversaries are an important concern as we are of the evidence meets all the legal requirements. The Secu- rity/System Administrator is in charge of maintaining having overall administrative or supervisory authority of a the site Information Technology (IT) system. He/she issues particular site. The Site Lead must keep the Site Execu- necessary authorizations for evidence collection and investi- tive briefed on the investigation process and follow the Site gation. The Security/System Architect assists the in- Executive’s direction. The Media Liason performs the im- vestigation by sharing his/her knowledge of the IT system portant job of interacting with the media and briefing them and the security design of the system. about progress of the incident response and the investiga- The Collaboration Technical Roles are responsible for tion. Utmost care needs to be taken to ensure that no sen- managing and supporting the collaboration. The Collab- sitive information gets revealed that might be against the oration Incident Lead leads the investigation into the interest of the affected site(s) or might hamper the investi- large-scale attack and also acts as a moderator/coordinator gation process. for the entire collaborative investigation process. Typically an experienced investigator in the ICIM is assigned to this 5. PROCESS MODEL role. In the CSIRT model, this is the “incident coordinator” In this section, we propose a process for the multi-site for the designated lead CSIRT [21]. The Collaboration collaborative incident response and investigation approach Investigator helps the Collaboration Incident Lead in in- advocated in this paper. We describe in detail a four-phase vestigating the incident(s). This role will be populated by model that represents the process that each site goes through investigators from the sites as well as from the ICIM. The locally for incident response and investigation (which lever- Collaboration Digital Forensics Analyst is responsible ages the Incident Response Life Cycle presented in [17]), a for extracting relevant data from the evidence collected from four-phase model that represents the collaborative process individual sites. He/she uses different tools available for the and the interactions between the site and collaborative pro- collaborative investigation to perform cross-site analysis and cesses. These phases are illustrated in Figure 2. The collab- construct a global timeline of the events. This role may also orative process is assumed to be executed at the ICIM. be populated by investigators from the sites as well as from Before going to the description of each phase, it needs to the ICIM. The Collaboration Workspace Administra- be mentioned that the division of the response and investi- tor is the person responsible for maintaining the collabo- gation process into phases is not a rigid one. If the process rative environment, which supports exchange of data and enters a particular phase, it does not mean that only activi- messages between sites for the response and investigation ties that are part of that phase are permitted at that point. process. Since the workspace is hosted by the ICIM, this Rather, the implication here is that at least some part of the role should typically be assigned to an administrator from process has progressed up to that specific phase but there is that ICIM. every possibility of revisiting a step belonging to an earlier The Site Legal Roles are filled by lawyers, law enforce- phase if the need arises. Furthermore, different sites might ment, and security personnel local to the site. The Site be in different phases as compared to the collaboration de- Legal Adviser is a law practitioner associated with a par- pending on the progress of the investigation. ticular site and responsible for advising the Site Lead on Preparation. The primary goal of the preparation phase legal matters. This includes advice on legal and regulatory is to develop the capability of handling incidents based on constraints on what action can be taken, reputation protec- risk assessment and lessons learned from prior experience. tion and publication relation issues, when/if to advise part- In a given site the Site Executive leads the effort by estab- ners, customers and investors, etc [30]. The legal adviser lishing an Incident Response Team. Regular training of all also plays a crucial role in formulating and checking organi- concerned individuals is arranged to keep pace with the lat- zational policies to ensure that there is provision for using est security threats and security tools. The site System Ad- forensic tools to collect necessary evidence. The Site Lia- ministrator also plays an important role in the preparation son with Law Enforcement initiates contact with the ap- phase by acquiring tools and resources necessary for incident propriate law enforcement agency when decided by the Site response and effective investigation. Intrusion detection sys- Executive. He/she acts as the point of contact for all report- tems (IDSs), centralized logging, and forensic software are ing and communication between the site incident response some examples of software tools that are deployed for de- team and law enforcement. tection of an incident and also for evidence gathering in The Law Enforcement Roles are filled by government subsequent phases as part of forensic readiness. Detailed personnel. The Legal Prosecutor determines when and policy and procedure documents are formulated that spec- how the litigation process should proceed. He/she advises ify who should be contacted inside and outside the organiza- the Site Lead and/or the Collaborative Incident Lead about tion when an incident occurs. They also contain information what legal recourse may be taken against the perpetrator(s) about how that contact can be made and how much infor- and the appropriate actions to take for building a strong le- mation can be shared especially with outside parties; e.g., gal case. Finally, when the investigation is successfully over, law enforcement and other incident response teams. Taking it is the Legal Prosecutor who takes charge and takes ap- steps to prevent incidents from occurring in the first place propriate legal steps for prosecution of the perpetrator(s). is also an important part of the preparation phase. Sys- The Legal Investigator is a member of law enforcement tem Administrators follow a set of recommendend practices who conducts the investigation with the goal of prosecution. (e.g., those given in [17]) to ensure the security of network, This role exists for both a site and the collaboration. In a systems and applications that includes patch management, collaborative environment, a Legal Investigator might have malicious code prevention, training to increase user aware- to coordinate the investigation with Legal Investigator(s) be- ness, host security, etc. The site Security/System Archi- longing to other agencies and other jurisdictions. tect prepares proper documentation about the site’s net- Finally, the following two roles are also crucial in the work/system designs to aide incident responders. investigation process. The Site Executive is the person To prepare for the legal aspects of incident response and Figure 2: Process Model investigation the Site Executive devises a legal activities co- an incident has indeed occurred. Installation of Intrusion ordination plan in consultation with the Site Legal Adviser. Detection System (IDS), antivirus software and other mon- This plan provides the Site Liason with Law Enforcement itoring mechanisms in the preparation phase helps the Sys- basic guidance in coordinating the activities of the local In- tem Administrator identify signs that an incident may have cident Response Team with that of law enforcement agen- occurred or may be occurring. After getting confirmation cies. about the detection of the incident, an investigation team Detection & Strategy Development. The main fo- comprising of a Site Lead and one or more Site Incident In- cus of this phase is to accurately detect and confirm that vestigator s is created. The Site Lead carries out an initial analysis to determine the category, scope and magnitude of This environment allows Collaboration Lead Investigators the incident as it is vital in choosing the next steps of the to create workspaces and invite site and ICIM personnel response process. to join the collaborative response. Each workspace corre- A strategy regarding containment, eradication, recovery sponds to one incident and provides the collaboration access and investigation is developed at this phase by the Site Lead. to tools, data and messages for executing the response and The Security/System Architect of the site and the Site Legal investigation process whereby each collaborator lives up to Adviser play important roles in formulating this strategy by his/her responsibility as per the assigned role. A Collabora- sharing their knowledge about the technical and legal factors tion Workspace Administrator is assigned for maintenance respectively. The Site Lead then informs the ICIM about the of this environment. incident. Depending on the perceived scale and scope of the Incident Activity Analysis. As part of its day-to-day attack the ICIM personnel are invited to play an active role operations the ICIM receives reports about incidents at var- in developing the strategy. ious sites in its purview. In this phase the ICIM undertakes Local Investigation & Recovery. After validating an an analysis of these reports to determine the level of re- incident, containing the scope and impact of the attack to sponse needed and the role that it needs to play in that minimal level becomes a major concern for the Site Lead. response. When the analysis indicates a large-scale attack Actions regarding containment may include shutting down the ICIM may decide that a collaborative response is war- system(s), segregating a compromised component from the ranted. Examples include evidence indicating a growing or rest of the network, suspension of accounts that are sus- active botnet, zero-day exploit that affects multiple sites, pected to be compromised, etc. At the same time, the website vandalism at multiple sites, and a request to do so Site Digital Forensics Specialist starts the important task from multiple Site Leads. of evidence collection. Using forensic software and toolkits, Collaborative Investigation. Once the ICIM decides he/she obtains and extracts evidence from various sources on a collaborative response a Collaboration Incident Lead is while ensuring their integrity and authenticity. Compre- identified who proceeds to set up a collaborative workspace hensive documentation, particularly that related to chain of for the incident with the assistance of the Collaboration custody of digital evidence, is of utmost importance in this Workspace Administrator. The Collaborative Incident Lead phase. In addition, eradication, for example, malware re- notifies other sites about the workspace and invites them moval and disabling of breached user accounts (if any), is to join. The Collaborative Incident Lead also performs dif- undertaken to ensure that the site is no longer vulnerable to ferent bootstrapping activities for the workspace including, that attack. Finally, System Administrators restore systems but not limited to, assignment of Collaborative Investiga- to normal operation. Recovery may involve such actions as tors and Collaborative Digital Forensics Analyst(s) from the using backups to restore systems when possible, performing ICIM and other sites. In addition, depending on local laws clean installations, etc [17]. and the nature and scale of the attack law enforcement is Per-Site Incident Closure. Once the incident is over invited to participate in the collaboration and investigators and the system recovery is complete, it is important to iden- are assigned appropriate roles. tify the lessons that can be learned from the handling of the An initial task of the collaboration is to formulate a strat- incident. A report containing a critical review of the en- egy regarding containment, eradication, recovery and inves- tire process is placed before management. Based on that tigation. This strategy is documented within the workspace report, the Site Executive may take necessary steps for bet- and often reviewed and updated as the process progresses. ter preparedness that may include modifying the policy and Data analysis is a crucial part of the investigation process. procedures, making changes to the personnel of the incident Availability of data from multiple sites opens up the pos- response team, etc. The Security/System Architect may de- sibility of performing cross-site analysis to establish links cide to modify the design of the system for better security. among events happening at individual sites. This analysis Additional software and hardware may be deployed by the is conducted by Collaboration Investigators, Collaboration System Administrator to bolster the defense of the system Digital Forensic Analysts and Legal Investigators and re- against future threats. Based on organizational policy, the quires member sites to share data and communicate regu- Incident Lead decides on whether to store evidence and in larly. Based on the analysis the collaboration provides sup- what form. It should depend on factors like whether the port to all sites for containment, eradication and recovery. prosecution is finished or not, the laws regarding data re- While this analysis is being conducted, Collaboration Digital tention, hardware cost, etc. Forensic Analysts extract and store forensic evidence accu- ICIM Preparation. Like any site, the ICIM devel- mulated by the collaboration for legal prosecution. Based ops capabilities for handling incidents in this phase. This on the evidence, Collaborative Investigators, with the help includes training of a response team and developing poli- from Collaborative Digital Forensics Analysts, reconstruct cies and procedures including a legal activities coordination the digital crime scene/incident [11] and Legal Prosecutors plan. In addition to developing these capabilities for assist- and Legal Investigators formulate a legal prosecution strat- ing a single site with an incident, the ICIM develops these egy. As needed Collaborative Investigators interact with Site capabilities for leading a collaborative effort in responding Incident Investigators in this phase to assist the latter with to a large-scale multi-site attack. This includes training of local investigation and recovery. One of the benefits of a col- personnel to lead such collaborative teams and developing laborative effort is that the analysis in this phase can assist collaboration-specific policies, procedures, and legal activi- local site investigators to come up with strategies for local ties coordination plans. investigation and recovery. This includes assistance or guid- The cornerstone of preparing for a collaborative response ance for evidence gathering and preservation, forensic tool is setup of a workspace hosting environment for multi- usage, recovery, etc. site collaborative investigation of large-scale cyber-attacks. Collaboration Incident Closure. Once the investiga- tion is over, appropriate legal steps are taken by the Legal Prosecutor(s) for prosecution. The evidence and theory de- veloped in the analysis and reconstruction stage is presented to the appropriate authority. Dissemination of information [13] is another critical task in this final phase. Depending on the policy, the information may be shared with organiza- tions that participated in the incident response or it may be added to a global knowledge repository. Finally, like partici- pating sites, the ICIM should also have a policy on evidence retention for collaborative responses. 6. SECURITY ARCHITECTURE At the core of our approach for collaborative response and investigation is the workspace environment that allows sites to instantiate incident workspaces and collaborate. Given the sensitive nature of this collaboration security for the Figure 3: Security Architecture workspace environment is crucial. In this section we dis- cuss threats against the environment and our approach for addressing them. In our system design, we have worked to cated users have no access to incident workspaces by default. unify our security and system models [14] by modeling sys- They must be granted per-incident roles by the owner of the tem threats and desired security properties. workspace. Threat Model. We consider both insider and outsider Network Security. To protect the workspace environ- threats to the workspace environment. Insiders (i.e., investi- ment from network-based attack, we establish a physical gators with valid system logins) must obtain access to sensi- and electronic security perimeter around the environment tive forensics data only as deemed necessary for the investi- that minimizes exposure via firewalls and private networks, gation. When multiple incident investigations are hosted in- requires encryption for all external network traffic, and em- side the workspace environment, investigators’ access must ploys network- and host-based intrusion detection. Database be restricted to only the incidents they are investigating. and data analysis services that support the user interface Furthermore, access to forensics data within an incident in- are deployed on a dedicated private network with no direct vestigation must be controlled to minimize disclosure of sen- external network access. Leveraging a small number of stan- sitive site information. In our experience, it is typical for site dard protocols via well-known open source software enables personnel to share forensics data only with a small num- system administrators to apply standard, best practice net- ber of trusted collaborators. The workspace environment work security measures to address common attacks. For must enable multiple sites to participate in the collabora- greater network security, the environment can be deployed tion while limiting data disclosure between the sites inside inside a virtual private network to limit exposure to attacks the system, including disclosure of identifying information from external networks. about the participants. Data Privacy. The collaborative environment must pro- Outsiders include the suspects under investigation and vide tools to enable collaborative incident response while others who would desire to obtain sensitive information from respecting each site’s information disclosure policies. The the workspaces or otherwise abuse system resources. Sus- disclosure of sensitive incident data is subject to privacy pects under investigation must not be able to use infor- policies and laws, public relations, the desire to avoid dis- mation from the workspaces to help to cover their tracks closure to competitors and adversaries, and the desire to or otherwise adjust their attack strategy. Furthermore, we avoid negatively impacting an ongoing criminal investiga- must limit a suspect’s ability to disrupt the investigation tion [8, 9, 15]. The ICIM plays a central role in overseeing via denial of service attacks against the workspace environ- and directing data disclosure among participants. This is ment. Sensitive information that must not be disclosed to crucial for enabling the collaboration as otherwise the in- outsiders includes digital forensics data (containing sensitive volved organizations may not end up sharing the necessary site information), personal details about investigators (such information. The ICIM may use both technical and busi- as names, phone numbers, or IP/email addresses), or infor- ness means in supporting data disclosure. Technical means mation about the capabilities and methods of investigators. include the use of anonymization techniques that can hide Authentication and Access Control. To limit work- sensitive information where appropriate; e.g., [33]. However, space access to valid site and ICIM investigators we use in many cases data may not be suitable for anonymization strong two-factor authentication and to limit access to au- or may be rendered useless after doing so. In which case, thorized data and resources between and within incident the ICIM can utilize established procedures for obtaining ap- workspaces we use Role-Based Access Control. The secu- proval from the organizations on each type of data such that rity architecture is illustrated in Figure 3. the investigation team only needs to incur occasional over- Role-Based Access Control (RBAC) is a natural choice head for data sharing. The collaborative environment must for meeting the access control requirements of the collab- support flexible access control policies to facilitate data shar- orative environment. We map authenticated system users ing according to the different information disclosure policies to per-incident roles following the approach presented ear- of the different participants. For example, some data may lier in Section 4. Authorized users have permission to create be provided to ICIM personnel only while other data may new incident workspaces and manage per-incident role-based be shared among all collaborators. Thus, it is not necessary permissions within the workspaces they create. Authenti- for all participants to agree on a common data sharing pol- icy; instead, participants can specify and implement their mended mitigation techniques. When new collaborators see desired access control policies on the data they provide to that the details in the incident overview match what they are the collaboration. seeing inside their organization, and they benefit from the recommended mitigation techniques listed in the overview, they are more inclined to join the collaborative response ef- 7. ESTABLISHING TRUST fort. Furthermore, specific details about the attack can be The collaborative incident response approach that we de- very effective at gaining the interest of new collaborators, as scribe relies heavily on establishing trust between the re- illustrated by the following anecdote. During Incident 216, sponders from the affected organizations. As described in one of the responders needed timely assistance from a new the Introduction, trust establishment is a major challenge organization and was having difficulty getting a response. because the affected organizations are chosen by the at- He noticed that the attacker had collected the password of tacker, the collaboration may be formed only after the in- one of the CSIRT members from the organization, so he cident occurs, and the collaboration involves sensitive infor- asked him, “Is this your password?” When the CSIRT mem- mation. We have observed that some organizations have a ber recognized his password, he responded, “Now you’ve got strict policy against disclosure and cooperation during in- my attention!” cident response, so they would be unwilling to participate in a collaborative approach under any circumstances. How- ever, NCSA staff had very positive experiences collaborat- 8. DESIGN AND IMPLEMENTATION ing with other organizations during the response to Inci- We have developed the “Palantir” prototype system to dent 216 and other incidents, which indicates that many provide a software environment that supports the collabo- organizations see the value in working together to address rative response and investigation process. The Palantir sys- large-scale distributed attacks. In this section, we discuss tem provides the collaborative workspace for discussions and three methods for establishing trust during a collaborative data sharing among incident investigators, as seen in Figure response: (1) leveraging pre-existing collaborations, (2) uti- 4. Collaboration mechanisms in the workspace include a lizing trusted introducer groups and services, and (3) sharing data repository for log files, network traces, and other foren- incident information of interest to the participants. sic data, a wiki for providing an overview of the incident for Leveraging pre-existing collaborations. In today’s world new members, documenting incident details, and keeping of collaborative computing there is an opportunity to create a timestamped incident notebook, secure instant messaging ICIMs with the ability to quickly manage incidents that span for real-time discussions, secure email lists [7, 19, 20] for these environments. For example, grid computing environ- ongoing discussions, anonymization tools [33] for sanitizing ments for scientific research, such as TeraGrid, Open Science data before it is shared, analysis tools [10], and visualization Grid, the Enabling Grids for E-sciencE (EGEE), and the tools [36]. Worldwide LHC Computing Grid (WLCG), have relatively Our implementation is a web application built on open stable member organizations that trust each other for re- source web software that can be accessed by standard web source sharing. Due to their common environments and user browsers. We use the Liferay Portal3 platform, running in communities, security incidents can spread between these the Apache Tomcat4 container, connected to the Apache organizations, which has motivated them to share incident HTTP5 server. Building on open source software enables response contact information and establish processes for co- independent verification of software security through source ordinated response that are primarily email-based. These code reviews and scanning, as performed for the Apache existing collaborations could directly apply our proposed HTTP server by the Scan Project6 and for Liferay and Tom- workspace mechanisms to enhance their existing coordinated cat by the Java Open Review Project7 . processes. Liferay supports secure chat services via the standard Utilizing trusted introducer groups and services. While we XMPP (Jabber) protocol using the open source Openfire8 can leverage pre-existing collaborations, we have seen that Jabber server. Responders can chat via a portlet within attackers do not respect their boundaries, and large-scale at- Liferay (over HTTPS) or via desktop Jabber chat clients tacks often affect organizations with no prior working rela- running the Jabber protocol over TLS. tionships. The incident response community has established For strong two-factor authentication, we support both groups and services to facilitate trust establishment in these one-time password (OTP) hardware tokens and PKI-based cases. For example, the Trusted Introducer1 network pro- smartcards. The OTP tokens and smartcards both require vides vetted contact information for CSIRTs in Europe and a PIN to unlock, providing both “something you have” and facilitates trusted information sharing among accredited re- “something you know” authentication factors. When the sponse teams. Other groups such as the Forum of Incident OTP token is unlocked, it displays a one-time use password Response and Security Teams (FIRST)2 as well as CERTs that the Palantir user enters at the login prompt. When and ISACs act as trusted introducers between organizations the smartcard is unlocked, it authenticates to the server via impacted by distributed attacks. the TLS protocol using private cryptographic data residing Sharing incident information of interest to the partici- on the card. While smartcards save the user from manually pants. Finally, responders can use information about the entering a one-time password, they require hardware and incident to establish trust with new organizations being in- 3 vited to join the collaboration. An overview of the inci- http://liferay.com/ 4 dent for new collaborators can be maintained in the incident http://tomcat.apache.org/ 5 workspace, including timelines, attack vectors, and recom- http://httpd.apache.org/ 6 http://scan.coverity.com/ 1 7 http://www.trusted-introducer.nl/ http://opensource.fortifysoftware.com/ 2 8 http://www.first.org/ http://www.igniterealtime.org/projects/openfire/ Figure 4: A Palantir Workspace software support (i.e., readers and drivers) to interface with provides end-to-end privacy for email discussion lists using the user’s desktop. proxy cryptography, whereby messages are protected both The open source Secure Email List Services (SELS)9 soft- on the network and the mailing list server. ware provides support for email-based group discussions in The open source Framework for Log Anonymization and Palantir. SELS uses the OpenPGP standard for compat- Information Management (FLAIM)11 supports anonymiza- ibility with commonly available email client plugins from tion of log files on the responder’s desktop before upload into the Gnu Privacy Guard (GnuPG) project10 . SELS uniquely the collaborative environment, as well as anonymization by 9 the Palantir server during file upload and prior to export. http://sels.ncsa.uiuc.edu/ 10 11 http://gnupg.org/ http://flaim.ncsa.uiuc.edu/ Supported log types include pcap, netfilter, NetFlows, and Unix process accounting. Roles and Responsibilities. We now describe how the roles and responsibilities from Section 4 map to the Palantir system’s capabilities. The Collaboration Incident Lead is responsible for creat- ing and managing the incident workspace, with the assis- tance of the Collaboration Workspace Administrator. The Collaboration Incident Lead adds Collaboration Investiga- tors to the workspace, where they can coordinate their ef- forts via wiki pages and discussions over instant messaging and email. He also maintains a primary wiki page for the incident with an incident overview, current status, and tech- nical information to be shared among all participants. Collaboration Investigators learn information about the investigation that informs their local site’s response, as well as contribute their knowledge to the collaborative effort. If an investigator obtains information relevant to other sites, he can share it via the workspace. Collaborative Investiga- tors can upload evidence for analysis by other Collaborative Investigators and Collaboration Digital Forensics Analysts. The workspace provides anonymization tools that the Col- laborative Investigators can apply to their site’s data before sharing it. The Collaboration Digital Forensics Analysts apply foren- sics tools available in the workspace to the forensics data provided by the Collaboration Investigators. The analysts Figure 5: Palantir Workspace Template publish requests for evidence, guidelines for evidence collec- tion, and analytical results to wiki pages to inform the other collaborative participants. mented in Palantir is described in Figure 5 and is easily Other areas of the workspace, established by the Collabo- customizable. For each role identified in Section 4 the tem- ration Incident Lead as needed, provide forums for collabo- plate specifies: 1) the role that can assign users to this role, ration among Legal Advisors, Media Liasons, and Law En- 2) the default view (interface layout) when this role is ac- forcement. For example, Media Liasons can draft join press tivated, 3) set of tools (via Liferay portlets) that this role statements in the workspace. can access, and 4) a default set of resources (objects such Process Model. The Palantir system does not enforce a as files) that this role can access via each tool. A factory specific process model on participants. Instead, the collab- within Liferay generates the necessary resources and access orators can use the available tools in the workspace as they policies based on the specified template. see fit according to the response and investigation strategy they have developed. The Palantir system allows subgroups 9. EVALUATION to form and collaborate privately within the investigation To evaluate the Palantir approach, we describe how the workspace, before sharing their results with the larger group. Palantir system would have assisted in the collaborative in- The Collaboration Incident Lead can use the incident’s se- vestigation effort conducted for Incident 216. Collabora- cure mailing list to direct and track the group’s work. Wiki tion played a very important role in this investigation for pages can document current tasks and milestones in the in- tracking the attacker’s widely-distributed activities, under- vestigation, updated as they are completed. Upon further standing the attacker’s methods, and finally locating and experience, we may augment the Palantir system with forms apprehending the attacker. and dialogs that facilitate common incident workflows based Compromise Tracking and Notification. Notifying on best practices. sites that they had been compromised was one of the most As we see in Figure 2, coordination is required between the time-consuming activities in the Incident 216 investigation. local site incident response and the collaborative process. A Network traffic and server logs from the attacker’s password simple but important practice for facilitating this coordina- collectors and web servers provided information about com- tion is for each site to record their local tracking number for promised systems to the incident investigators. Investigators the incident in the Palantir incident wiki. Palantir creates analyzed the latest information each day and notified per- a unique tracking number for each workspace, following the sonnel at newly compromised sites. Network, security, and recommendations in [8]. system administrators at different sites gathered and pro- Workspace Template. In order to realize the Roles vided this data to the investigators. The attacker moved and Responsibilities Model and the Process Model in inci- the password collector several times, requiring the investi- dent workspaces, Palantir provides a Workspace Template gators to contact new administrators to re-establish their that is instantiated for every incident. The template pro- monitoring capabilities. vides ready-to-use containers for each workspace where users Managing the network and server logs for daily analysis can be assigned to roles and automatically get access to an was a manual process. Palantir’s data repository provides authorized set of resources. The template currently imple- the capability for administrators to directly upload their data to the investigators via the secure web interface. In- tigations including ticket tracking [22] and request tracking vestigators can use wiki pages to track which logs have been [35]. analyzed and which sites have been contacted. Using Palan- Going beyond CSIRTs, a number of efforts have been tir tools, the investigators can automate the daily analysis launched worldwide to establish institutions that coordinate process. response to large-scale multi-site attacks. Examples include When contacting newly compromised sites, it is helpful the Computer Emergency Response Teams (CERTs) and In- for the investigators to have a standard incident overview to formation Sharing and Analysis Centers (ISACs) currently share with site personnel. During Incident 216, this overview being operated worldwide. was maintained by a single investigator, but Palantir’s se- Our work is significantly different in that we focus on a cure wiki would allow it to be written and updated collab- framework for supporting multi-site collaborative digital in- oratively by multiple investigators. Additionally, new sites vestigation and incident response. We integrate the two ar- can obtain logins to the Palantir system to read the wiki eas of relevant work, namely, digital investigation and in- pages and participate in the investigation. cident response, by developing models for Roles and Re- Collaborative Analysis. Incident 216 investigators were sponsibilities as well as Processes that identify their inter- hindered by their inability to read the encrypted network action. Furthermore, we propose to extend the scope of traffic from the attacker’s rootkit. From analyzing network CERTs/ISACs to support effective collaborations involving logs, an administrator at one site identified the encryption multiple organizations by additionally becoming ICIMs. In protocol being used but needed the encryption key. Inves- particular, these novel enhancements result in a Process tigators asked for help from colleagues skilled in reverse en- Model (see Figure 2) that allows incident responders and gineering, who were able to analyze the rootkit binary to investigators across multiple sites affected by an attack to locate the encryption key. With the key, the administrator effectively collaborate in their common goals of investigating developed a decryption tool that he shared with the other and responding to the attacks. To the best of our knowledge investigators. Investigators were lucky that the administra- this is the first work proposing a system model and imple- tor at this site had both access to the rootkit logs and the mentation for a collaborative multi-site incident response skill to develop a decryption tool. If this had not been the and investigation effort. We believe that this work can help case, the administrator could have used Palantir to upload develop capabilities to adequately prepare for large-scale at- the logs to be analyzed by another participant. tacks such as Incident 216. The US Department of Home- This is one of many examples in the Incident 216 investi- land Security has conducted two exercises for large-scale gation of system administrators who were highly motivated cyber attacks, Cyber Storm I (February 2006) and Cyber to contribute to the investigation. By sharing information Storm II (March 2008). From the public report of Cyber with them and allowing them to contribute, the investiga- Storm I [1] it is clear that even with the presence of CSIRTs, tion benefited greatly from their expertise. CERTs and ISACs, tools and technologies that provide ad- As described in Section 2, the Incident 216 collaborative vanced collaboration capabilities for incident response and investigation and analysis was hindered by ad hoc communi- investigation are needed. cation methods. Palantir’s secure instant messaging, email Many software systems are available to help CSIRTs in- lists, and wiki pages provide convenient and trustworthy ternally manage incident investigations. Open Source inci- communication mechanisms for the investigators. dent ticket tracking systems include Application for Incident Response Teams (AIRT) [22], Request Tracker for Incident 10. RELATED WORK Response (RTIR) [35], and System for Incident Response in Operational Security (SIRIOS)12 . The Internet2 Research Starting with work that leverages experiences in dealing and Educational Networking Operational Information Re- with paper evidence [25], considerable effort has been spent trieval (RENOIR)13 project is developing a system for inci- in developing models for the digital investigation process. dent reporting to a trusted third-party such as REN-ISAC This includes the Digital Forensic Science process [24], the (Research and Education Networking ISAC)14 . This work End-to-End Digital Investigation Process [34], an approach is complementary to ours. We assume good internal inci- for forensics in military settings [16], the Integrated Digital dent management and incident reporting mechanisms are in Investigation Model [11], the Digital Crime Scene Investiga- place, and we focus on collaborative incident response in re- tion process [12], the Enhanced Digital Investigation Model action to large-scale, distributed incidents. While individual [5], a process for integrating investigations with information components of our solution, such as secure wikis and instant flow [13], the FORZA [18] framework that emphasizes legal messaging, are starting to see more widespread use in the issues, a two-tier investigation approach [6] and the com- incident response community, we believe our work is the first bined forensics and intelligence gathering framework [31]. to bring together these components into an integrated envi- Reith et al. [28] and Pollitt [26] provide good surveys of ronment for collaborative incident response. these and other related works. Similarly, models have been developed that deal primarily with how individual sites should respond to incidents, usu- 11. CONCLUSIONS AND FUTURE WORK ally with the help of a predesignated incident response team. Organizations with cyber-infrastructure assets face large- This includes the Incident Response Life Cycle [17], an in- scale distributed attacks on a regular basis. Based on lessons cident response methodology [27], guidelines for formation learned in dealing with such an attack and the realization and operation of CSIRTs [8], a study of organization mod- that the complexity and frequency of such attacks is increas- els and their impact on incident response [21], best practices 12 and guidelines [3, 29] and a corporate framework for incident http://sirios.org/ 13 management [23]. Additionally, software systems have been http://security.internet2.edu/csi2/ 14 developed to help CSIRTs internally manage incident inves- http://www.ren-isac.net/ ing in general, we argue that is in insufficient to rely on 13. REFERENCES organizational incident response teams or even trusted co- [1] Cyber Storm Exercise Report. National Cyber ordinating response teams. Instead, there is need to develop Security Division, U.S. Department of Homeland a framework that allows an effective collaborative response Security, September, 2006, 2006. and investigation process that include multiple organization [2] T. Ahmed and A. R. Tripathi. Specification and and legal entities to track the adversary, eliminate the threat verification of security requirements in a programming and pursue prosecution of the perpetrators. To that end we model for decentralized cscw systems. ACM Trans. develop a system model and prototype implementation that Inf. Syst. Secur., 10(2):7, 2007. would provide the ability to execute this collaborative pro- [3] C. Alberts, A. Dorofee, G. Killcrece, R. Ruefle, and cess led by an Independent Center for Incident Management M. Zajicek. Defining Incident Management Processes (ICIM). The system model defines an appropriate set of roles for CSIRTs: A Work in Progress. Technical Report and responsibilities as well as the process undertaken by the CMU/SEI-2004-TR-015, Software Engineering collaboration. We describe a workspace environment sup- Institute, Carnegie Mellon University, 2004. ported by ICIMs and define a security architecture for the [4] P. Bajcsy, R. Kooper, L. Marini, B. Minsker, and environment that leverages the roles in the system model J. Myers. CyberIntegrator: A Meta-Workflow System for role based access control. We then describe a proto- Designed for Solving Complex Scientific Problems type implementation of the workspace environment, called using Heterogeneous Tools. In Proceedings of the the Palantir system, that provides a collaboration access to Geoinformatics Conference, May 2006. necessary tools and resources for undertaking the response [5] V. Baryamureeba and F. Tushabe. The Enhanced and investigation while enforcing the security requirements. Digital Investigation Process Model. Process Model In addition, we define a workspace template for incident Asian Journal of Information Technology, 2006. workspaces that supports our system model for roles, re- [6] N. Beebe and J. G. Clark. A hierarchical, sponsibilities and processes. objectives-based framework for the digital Several directions of future work can greatly benefit the investigations process. Digital Investigation, proposed system model and prototype. First, the RBAC 2(2):147–167, 2005. model can be enriched with the addition of role hierarchies, delegations and constraints that provide fine-grained access [7] R. Bobba, J. Muggli, M. Pant, J. Basney, and control and advanced policies such as separation-of-duty. H. Khurana. Usable secure mailing lists with Enforcement of constraints will require a reference moni- untrusted servers. In Symposium on Identity and Trust tor in the workspace environment, which can be designed on the Internet (IDtrust), 2009. by adapting techniques for RBAC in collaborative settings [8] M. J. W. Brown, D. Stikvoort, K. P. Kossakowski, [2]. Second, while the process model does not lend itself to K. P. Kossakowski, G. Killcrece, R. Ruefle, and well-defined workflows there exist several tasks that can be M. Zajicek. Handbook for Computer Security Incident combined into workflows for efficiency and correctness; e.g., Response Teams (CSIRTs). CMU/SEI-2003-HB-002, uploading and analyzing logs. Such workflows can be sup- April, 2003, 2003. ported by developing the concept of wizards in the workspace [9] N. Brownlee and E. Guttman. Expectations for environment that allow users to combine tasks into work- Computer Security Incident Response. IETF RFC flows. Third, the usability aspects of the workspace envi- 2350, June 1998. ronment can be significantly improved by undertaking us- [10] Y. D. Cai, D. Clutter, G. Pape, J. Han, M. Welge, and ability studies and interface enhancements. Based on com- L. Auvil. Maids: mining alarming incidents from data ments from early adopters, we are exploring the possibility streams. In SIGMOD ’04: Proceedings of the 2004 of supporting command-line and thick-client interfaces to ACM SIGMOD international conference on the workspace, using CyberIntegrator [4] to capture data Management of data, pages 919–920, New York, NY, provenance and manage workflows. Fourth, further evalua- USA, 2004. ACM Press. tion of the system in handling real large-scale incidents will [11] B. Carrier and E. H. Spafford. Getting Physical with help provide useful enhancements and validation. the Digital Investigation Process. International Journal of Digital Evidence, 2(2), Fall 2003. [12] B. Carrier and E. H. Spafford. An Event-Based Digital 12. ACKNOWLEDGMENTS Forensic Investigation Framework. In DFWRS’04: We would like to thank the members of the NCSA Inci- Proceedings of the 4th Digital Forensics Research dent Response team, whose efforts in Incident 216 and sub- Workshop, 2004. sequent discussions led to our understanding of these chal- [13] S. Ó. Ciardhuáin. An Extended Model of Cybercrime lenges. Members of that team at the time of Incident 216 Investigations. International Journal of Digital included Jim Barlow, Tim Brooks, Aashish Sharma and Jeff Evidence, 3(1), Summer 2004. Rosendale. [14] P. T. Devanbu and S. Stubblebine. Software This work was funded by the Office of Naval Research un- engineering for security: a roadmap. In ICSE ’00: der award number N00014-06-1-1108. The views and con- Proceedings of the Conference on The Future of clusions contained in this document are those of the authors Software Engineering, pages 227–239, New York, NY, and should not be interpreted as representing the official USA, 2000. ACM Press. policies, either expressed or implied, of the Office of Naval [15] B. Fraser. Site Security Handbook. IETF RFC 2196, Research or the United States Government. Sept. 1997. [16] J. Giordano and C. Maciag. Cyber Forensics: A Military Operations Perspective. International Journal of Digital Evidence, 1(2), Summer 2002. Evidence, 4(1), Spring 2005. [17] T. Grance, K. Kent, and B. Kim. Computer Security [32] S. Schechter, J. Jung, W. Stockwell, and C. McLain. Incident Handling Guide: Recommendations of the Inoculating SSH Against Address Harvesting. In National Institute of Standards and Technology. NIST NDSS’06: The 13th Annual Network and Distributed Special Publication 800-61, January 2004. System Security Symposium, San Diego, CA, February [18] R. S. C. Ieong. FORZA - Digital forensics 2006. investigation framework that incorporate legal issues. [33] A. Slagell, K. Lakkaraju, and K. Luo. FLAIM: A Digital Investigation, 3(Supplement-1):29–36, 2006. Multi-level Anonymization Framework for Computer [19] H. Khurana, J. Heo, and M. Pant. From proxy and Network Logs. In LISA’06: 20th USENIX Large encryption primitives to a deployable Installation System Administration Conference, secure-mailing-list solution. In ICICS’06: Washington, D.C., Dec. 2006. International Conference on Information and [34] P. Stephenson. Modeling of Post-Incident Root Cause Communications Security, pages 260–281, 2006. Analysis. International Journal of Digital Evidence, [20] H. Khurana, A. J. Slagell, and R. Bonilla. SELS: a 2(2), Fall 2003. secure e-mail list service. In ACM Symposium on [35] J. Vincent, R. Spier, D. Rolsky, D. Chamberlain, and Applied Computing (SAC), Security Track, pages R. Foley. RT Essentials. O’Reilly Media, Aug. 2005. 306–313, 2005. [36] X. Yin, W. Yurcik, and A. Slagell. VisFlowCluster-IP: [21] G. Killcrece, K.-P. Kossakowsk, R. Ruefle, and Connectivity-Based Visual Clustering of Network M. Zajicek. Organizational Models for Computer Hosts. In 21st IFIP TC-11 International Information Security Incident Response Teams (CSIRTs). Security Conference (SEC ’06), May 2006. Technical Report Report: CMU/SEI-2003-HB-001, Carnegie Melon University/Software Engineering Institute, 2003. [22] K. Leune and S. Tesink. Designing and developing an Application for Incident Response Teams. In FIRST’06: Forum for Incident Response Teams Conference, Baltimore, MD, USA, June 2006. [23] S. Mitropoulos, D. Patsos, and C. Douligeris. On Incident Handling and Response: A state-of-the-art approach. Computers & Security, 25(5):351–370, July 2006. [24] G. Palmer. A Road Map for Digital Forensic Research. Technical Report Technical Report DTR-T001-01, Report From the First Digital Forensic Research Workshop (DFRWS), 2001. [25] M. Pollitt. Computer Forensics: an Approach to Evidence in Cyberspace. In Proceedings of the National Information Systems Security Conference, volume 2, pages 487–491, 1995. [26] M. M. Pollitt. An Ad Hoc Review of Digital Forensic Models. In SADFE ’07: Proceedings of the Second International Workshop on Systematic Approaches to Digital Forensic Engineering, pages 43–54, Washington, DC, USA, 2007. [27] C. Prosise, K. Mandia, and M. Pepe. Incident Response and Computer Forensics, Second Edition. McGraw-Hill Osborne Media, 2003. [28] M. Reith, C. Carr, and G. Gunsch. An Examination of Digital Forensic Models. International Journal of Digital Evidence, 1(3), Fall 2002. [29] R. L. Rollason-Reese. Incident handling: an orderly response to unexpected events. In SIGUCCS ’03: Proceedings of the 31st annual ACM SIGUCCS conference on User services, pages 97–102. ACM Press, 2003. [30] R. Rowlingson. A Ten Step Process for Forensic Readiness. International Journal of Digital Evidence, 2(3), Winter 2004. [31] G. Ruibin, C. Kai, Y. Tony, and M. Gaertner. Case-Relevance Information Investigation: Binding Computer Intelligence to the Current Computer Forensic Framework. International Journal of Digital Palantir: A Framework for Collaborative Incident Response and Investigation Himanshu Khurana, Jim Basney, Mehedi Bakht, Mike Freemon, Von Welch, Randy Butler IDTrust, April 14 – 16, 2009. Gaithersburg, MD. Introduction • Computer Security Incident Response Teams (CSIRTs) are becoming common • Digital investigation and forensics • Recovery and restoration • Working with law enforcement • CERTs and ISACs provide information sharing and coordination • Vulnerabilities, exploits, policy documents • Recently experienced large-scale cyber attacks require collaboration and not just coordination FBI Major Case 216 – Stakkato (2004) FBI Major Case 216 – Stakkato (2004) • Broad attack against supercomputing centers, DOE labs, Universities and other government and commercial sites internationally. • Simple attack strategy with a highly complex infrastructure • Compromise host -> escalate privilege -> install trojan SSH -> capture passwords -> use SSH known hosts file to find next victim • Lather. Rinse. Repeat Lessons learned from Major Case 216 • Multi-site collaboration is hard • Tens of sites in multiple countries • Trust establishment • Partners not known in advance • Data collection and analysis • Limited skills at each site • Privacy and security issues with data sharing • Lack of tools • Communication and interactions • Adversary was monitoring emails • Total process took 9 months • Law enforcement finally stopped the attacks Requirements and Challenges • Requirements • Trust establishment for data sharing • Management of tasks and activities • Data management and analysis • Challenges • Interactions between site and collaborative activities • Effective responsibilities and reporting • Integrating technical and legal investigation • Tracking global progress Approach • Principles • Mutual benefit for trust establishment • Focused collaboration • Least privilege for access control • Design • Propose a system model for collaboration • Roles and responsibilities • Process model • Secure architecture • ICIM: Independent Center for Incident Management • Analysis tools (open source) • System implementation and prototype Roles and Responsibilities Site Technical Roles Collaboration Technical Roles Collaboration Site Lead Incident Lead Site Digital Coll. Digital Site Incident Collaboration Forensics Forensics Investigator Investigator Spec. Analyst Security/Syste Collaboration Security/Syste m Workspace m Architect Administrator Administrator Site Legal Roles Law Enforcement Roles Site Liaison Legal Legal Site Legal with Law Prosecutor Investigator Advisor Enforcement Other Site Roles Media Site Executive Liaison Process Model Process Model Site ICIM/Collaboration Detection & Strategy Development Incident Activity Analysis Architecture and Security • Address both outsider and insider threats • Strong authentication and authorization • Two-factor, RBAC • Enforce data privacy • Disclosure policies, anonymization Incident Workspace and User Interface Example Integrated Tools • FLAIM: Framework for Log Anonymization and Information Management • SELS: Secure Email List Services • Liferay: Portal and collaboration software • Openfire: XMPP/Jabber Chat Future Work • Software packaging and release • Evaluation in test environment • Usability studies • Explore deployment avenues • Explore suitability of integration with CERTs/ISACs • Quick deployment by any organization involved in an incident • QUESTIONS? • Contact: Himanshu Khurana; hkhurana@illinois.edu, Randy Butler; rbutler@ncsa.uiuc.edu Backup Slides Establishing Trust – a people problem • Challenges • Information privacy (user and organization) • Publicity concerns • Lack of clear incentives for information sharing • Potential approaches • Leverage pre-existing relationships • E.g., Computational grid systems • Utilizing trusted introducer groups and services • E.g., CERTs, ISACs, FIRST, Trusted Introducer • Share information to establish trust • Mutual benefit Safeguarding Digital Identity: The SPICI (Sharing Policy, Identity, and Control Information) Approach to Negotiating Identity Federation and Sharing Agreements Deborah Bodeau The MITRE Corporation 202 Burlington Road Bedford, MA 01730 1-781-271-8436 dbodeau@mitre.org ABSTRACT increasingly need to share identifying and authorization- To perform key business functions, organizations in critical related information. Thus, organizations increasingly need infrastructure sectors such as healthcare or finance to negotiate agreements for identity federations or other increasingly need to share identifying and authorization- sharing of identifying and/or authorization-related related information. Such information sharing requires information. Such negotiations cover, among other topics, negotiation about identity safeguarding policies and identity safeguarding policies and capabilities required to capabilities, as provided by processes, technologies, tools, implement policies, provide agreed-upon functionality, and and models. That negotiation must address the concerns not thus meet business needs while managing risks.1 only of the organizations sharing the information, but also Negotiations that lead to contractual or other of the individuals whose identity-related information is documented agreements to share identity-related shared. SPICI (Sharing Policy, Identity, and Control information must address the concerns not only of the Information) provides a descriptive and analytic framework organizations sharing the information, but also of the to structure and support such negotiations, with an emphasis individuals whose identity-related information is shared. A on assurance. common framework for assessing potential harms – to the partnering organizations that share and rely upon Categories and Subject Descriptors identifying information and to the identified individuals – K.6.5 [Management of Computing and Information facilitates agreement on a risk-appropriate level of Systems]: Security and protection assurance. The SPICI (Sharing Policy, Identity, and Control General Terms Information) approach is being developed under the Security Institute for Information Infrastructure Protection (I3P) Safeguarding Digital Identity project [1]. SPICI is intended Keywords to help organizations identify the capabilities they need, and Identity ManagementIdentity Federation, Information to negotiate how they will provide those capabilities via Sharing, Credentials technologies and business processes, so that they can share identity and supporting information in a way that protects 1. INTRODUCTION individual privacy as well as organizational interests. Thus, To perform key business functions, organizations in SPICI complements, and provides a usage context for, critical infrastructure sectors such as healthcare or finance 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 1 Identity safeguarding capabilities are organizational abilities to not made or distributed for profit or commercial advantage and that create, protect, share, use, and manage identity and/or 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, authorization-related information in a way that safeguards requires prior specific permission and/or a fee. individual privacy and protects organizational interests, using a IDtrust 2009, April 14-16, 2009, Gaithersburg, MD, U.S.A. combination of processes, technologies, tools, and models. For Copyright© 2009 ACM 978-1-60558-474-4…$5.00 brevity, the term ―capabilities‖ is used. automated negotiation systems that can implement handle such information. Consequences to organizations organizational agreements [2, 3]. can include damage to reputation or business relationships, as well as legal liability or financial costs associated with SPICI provides a structure in which identity fraud or error. The concerns of stakeholders, including organizational To address these concerns, organizations must share users of identity information, individuals, and oversight more than identity or authorization-related information. bodies, are expressed as overarching goals and They must also communicate their associated policies for objectives for sharing identity and credential using and protecting that information. For example, an information in an appropriately protected manner. organization that provides identity information might Identity safeguarding capabilities that organizations communicate its retention policy: how long shared identity can use to manage and share identity, policy, and information may be retained. To enable policy enforcement, control information (particularly as represented by the organization also needs to share control information digital credentials) in a protected way are defined. (e.g., start date for the allowable retention period). These capabilities are motivated by related to the Credentials can include policy and control information overarching goals of Unambiguous Identification, (e.g., period of validity), or such information can be shared Assured Authentication, Accurate Authorization, using another mechanism. Privacy Protection, and Accountable Trust and to the Via negotiation, organizations determine what more specific objectives that derive from those goals. capabilities they will use to share identity- and Four levels of assurance are defined for capabilities authorization-related, and supporting policy and control, specifically related to sharing identity and credential information. The set of technologies for managing identity information. The recommended identity safeguarding information and credentials is large and growing. These are capability assurance level depends on organizational increasingly supported by technical, architectural, or and privacy concerns. assurance frameworks intended to facilitate specification and assessment of capabilities. However, these frameworks More specifically, SPICI consists of a descriptive were not designed to facilitate analysis and negotiation. framework, an analytic framework, and a process. The Furthermore, as discussions with stakeholder organizations SPICI descriptive framework identifies five goals for have repeatedly highlighted, technical problems are sharing identifying and authorization-related information frequently overshadowed by the challenges of establishing (and the policy and control information needed to support trust among organizations, by aligning policies and business that sharing), a set of objectives for technologies and/or processes. business processes used for such sharing, and a set of capabilities which can be implemented in IT products SPICI takes into consideration the findings and and/or via business processes to achieve those goals. The recommendations of the Identity Theft Prevention and SPICI descriptive framework also defines four capability Identity Management Standards Panel (IDSP, [4]). SPICI is levels (weak, basic, strong, and enhanced); these levels can informed by existing identity management and identity be achieved by business processes and/or technologies federation frameworks, in particular the E-Authentication (e.g., prototype tools, IT products). The SPICI analytic Guidance [5, 6], the Liberty Identity Assurance Framework framework also defines levels of potential harms associated (LIAF, [7]) and the framework [8] produced by the Focus with sharing identifying and authorization-related Group on Identity Management (FG IdM) of the information, and maps those levels of harm to capability International Telecommunications Union – levels. The SPICI process uses the descriptive and analytic Telecommunication Standardization Sector (ITU-T). frameworks to support negotiation of identity federation The IDSP, E-Authentication, Liberty, and FG IdM agreements, or of agreements for other forms of sharing work all define or rely upon an identity life cycle. The life identifying and authorization-related information. cycle for identity and credential information defined by SPICI builds upon these high-level life cycles. However, 2. BACKGROUND SPICI considers identity- and authorization-related Sharing of identity information, particularly in the form information (and supporting policy and control information) of easily propagated digital credentials, raises privacy as solely in digital form. Hence, SPICI does not consider well as business concerns. The consequences to individuals issuance of foundational documents (e.g., birth certificates) of privacy violations range from minor embarrassment or or subsequent credentials in physical form (e.g., drivers inconvenience to identity theft, misdelivery of medical licenses). services leading to injury or death, or misapprehension by law enforcement. Sharing of identity and credential information also raises concerns for the organizations that 3. NEGOTIATING IDENTITY policy representation and enforcement, for control data FEDERATION AGREEMENTS representation and use, and for communications Organizations that negotiate identity federation between partner systems? What terminology is agreements (or other identity information sharing common to federation or other sharing partners, for agreements, such as a Circle of Trust in the Liberty model roles and responsibilities; for identity and or a simple bilateral agreement) need to address such topics authorization-related attributes, policies, and control as:2 information; for information sensitivity and criticality; and for potential harms and corresponding risk Identity Assurance: How confident can or should the mitigations? federation or information sharing partners be that identified individuals actually exist and are Business Models and Business Rules: How does the distinctively identified; that credentials are correctly identity information sharing or identity federation and securely managed and delivered; that attributes are relate to the business processes and models of the meaningful and correct; and that identity and credential federation or sharing partners? In the case of a information is protected and accountable? federation, how are the costs of operating the federation recovered? What service level agreements Trust Relationships: How much trust does a given (SLAs) related to shared identifying or authorization- federation or sharing partner have in its credential related information are needed to support the business service provider, in the federation as a trusted third processes of federation or sharing partners? What party for the organizations in the federation, in another transparency standards apply, and how are they federation partner, in other federations in which the implemented (e.g., by sharing or review of audit given organization participates, and in other trails)? What liability is accepted or disclaimed, and federations in which other federation partners what enforcement procedures are implemented? participate? To what extent do trust relationships Answers to questions in these areas constrain the choice of depend on the business model and business rules (e.g., technical solutions. The SPICI process uses the SPICI rules for compliance monitoring or auditing)? descriptive and analytic frameworks to provide a starting Attributes: What attributes are needed to make point for negotiating agreements in a way that makes authorization-related decisions about identified explicit the concerns that drive or constrain the choice of individuals? What are the semantics of those technical solutions. attributes? How confident can or should the federation partners be in the quality (e.g., timeliness, correctness) 4. THE SPICI PROCESS of shared attributes? SPICI provides a descriptive and an analytic framework Privacy and the Use of Personally Identifiable that organizations looking to form, join, or evolve an Information (PII): How are the Fair Information identity federation can use to identify issues about Practice Principles3, as they apply to identifying or capabilities that they will need to negotiate, and to frame authorization-related information, interpreted within the discussion of those issues. The following paragraphs the federation or among the partners in identity sketch the process for using SPICI to support analysis and information sharing? What legal and/or regulatory negotiation. The process takes the form of a facilitated requirements apply to the identifying or authorization- discussion, in five stages. related information? How confident are federation or 1. Describe Business Process Needs. Organizational sharing partners that these principles and regulatory representatives – typically the business process owners, requirements are interpreted and met consistently? and the technologists who support them – briefly Technologies and Terminology: What technical describe the business processes that require sharing standards are used for identity data representation, for identifying or authorization-related information. They characterize or describe the identifying or authorization-related information they need or plan to 2 This list of topics is derived from the Internet2 Federation Soup share with each other. They indicate how they intend to report [9], the Liberty Alliance legal framework for a Circle of use federated or shared identity or credential Trust [10], and published examples of federation agreement information. Examples of uses include: to identify an templates. individual, to authenticate an asserted identity, to 3 Fair Information Practice Principles are ―widely-accepted decide whether to provide a restricted service to an principles regarding the collection, use, and dissemination of authenticated individual, to personalize the individual's personal information‖ [11]. While many different versions have interactions with their services, to market additional been articulated, the principles usually address notice, consent services to the individual, and to track an individual's or choice, access and redress, and security. use of their services (for purposes of charging, to can implement (and assure their partners in the provide additional dynamic personalization, for federation that they provide) the recommended auditing and compliance). They identify the types of capabilities. The definitions of the different assurance other organizations with which they expect to share the levels for the six SPICI-value-added capabilities can information. They might also indicate how they plan to help guide those discussions, and help identify areas protect the information as it is sent to them, as they for more detailed negotiation and planning. In addition, send it to another organization, and/or in storage. They SPICI identifies (but does not define assurance levels might also indicate their expectations and plans about for) other capabilities; the negotiation can result in accuracy or data quality. (Thus, to a large extent, they definitions of, and recommendations for, agreed-upon answer the questions that would arise if they were assurance levels of those additional capabilities. drafting a Privacy Notice for the identity- and/or 5. Negotiate Additional Considerations. The authorization-related information.) organizational representatives must also define shared 2. Assess Concerns or Potential Harms. Organizational or cross-organizational processes (e.g., data correction, representatives then identify and assess the potential dispute resolution), legal and financial risk harms associated with the identity- or authorization- management, and (in the case of a federation) the related information they provide to and/or get from the federation business model. This negotiation, while federation. Business process owners identify and assess crucial, is not the focus of SPICI. potential harms related to their business processes; other organizational stakeholders identify and assess 5. SPICI DESCRIPTIVE FRAMEWORK other potential harms. For example, a Chief Privacy SPICI defines five overarching goals for sharing Officer (CPO) might address the harms related to policy, identity, and control information: identified individuals, while a representative of the Unambiguous Identification: A user of identity or organization’s Legal department might consider the credential information (more specifically, a service harms related to unauthorized disclosure and to provider, i.e., an entity that provides a service to possible civil and criminal violations, and an individuals, such as an organization, a system, an organizational risk manager might consider financial application, or a Web service) should be able to and reputational harms. They might capture those distinguish one individual from another well enough to assessments in table form, or using a spreadsheet or make decisions regarding and establish accountability database. (Under the I3P project, a spreadsheet tool has for actual or attempted uses of services. been prototyped.) They could structure and normalize their assessments using the sets of threats and harms Assured Authentication: A user of identity or provided in the SPICI report. Note that harms can be credential information should be able to determine the assessed for different groupings of identity or identity or authorization-relevant attributes of an authorization-related information; for example, if only individual with assurance appropriate to the potential one field in a credential is highly sensitive, it could be harms of misdelivered services. described and assessed separately from the rest of the Accurate Authorization: A user of identity or credential. This lays the foundation for selective credential information should be able to determine application of capabilities and technologies. whether an individual is authorized to use that service 3. Review Recommended Capabilities. Based on these with assurance appropriate to the potential harms of assessments, each organization will have a profile of misdelivered services. recommended capabilities and levels. Many of those Privacy Protection: A user of identity or credential capabilities are defined by the LIAF. However, some information should handle the information regarding an capabilities are related specifically to the sharing of individual that it maintains or uses with care sufficient identifying or authorization-related information. SPICI to protect the individual’s privacy. Privacy protection defines six such capabilities, and (via the framework of can be characterized in more detail by using the Fair goals, objectives, and capabilities discussed below) Information Practice Principles. explains how they and the LIAF capabilities relate. The non-technical organizational representatives check that Accountable Trust. Identified individuals, and the recommendations make sense, and fine-tune the organizational providers and users of identifying and description or assessment as they deem appropriate to authorization-related information, should be able to reflect their organizations’ risk appetite. explain defensibly (i.e., to give an account of) why they trust one another to the extent that they do. 4. Negotiate Capability Implementation. The technologists among the organizational representatives Based on these goals, and on information life cycle are now well positioned to start talking about how they models, SPICI defines a set of objectives, and capabilities for achieving those objectives. Capabilities defined by other Attribute Syntax and Semantics. As defined in SPICI, frameworks and initiatives (in particular, the LIAF) fit into Mutual Understanding is the capability to use syntactic this framework. SPICI currently defines six capabilities and semantic rules (e.g., policy interpretation rules, which are not addressed by other frameworks but are rules for combining attributes) to provide a common crucial to achieving the objectives. understanding of well-founded uses of authorization- For Unambiguous Identification, the objectives and related information. capabilities are: Authorization Attribute Quality: The quality (e.g., Identity Specification: Within the scope of the accuracy, currency) of attributes used to make identification problem, each individual can be uniquely authorization decisions can be determined. characterized. Capabilities: Assignment of Subject Capabilities: Attribute Quality Specification, Attribute Identifier / Attributes, Assignment of Service Provider Quality Assurance. Identifier / Attributes. These capabilities are well Authorization Attribute Validation: The validity of addressed by the LIAF. attributes used to make an authorization decision can Identity Resolution : The unique characterization of an be assessed in the context of the decision. Capabilities: individual can be constructed (or reconstructed) from Conditional Identity/Attribute Validation, Internal identifying and/or authorization-related information. Attribute Validation. As defined in SPICI, Conditional Capabilities: Identity Attribute Correlation. As defined Identity / Attribute Validation is the capability to in SPICI, this is the capability to determine, to a validate, and make authorization decisions based on, specified or calculable degree of confidence, that authorization-related information using conditions that presented credentials or sets of presented identifying involve information not in the credential (e.g., history- information correspond to the same individual by based conditions such as Chinese Wall, location-based correlating or matching presented values with known conditions, time-based conditions, conditions asserted attributes, possibly by relying upon credentials issued by credential issuers). using the LIAF. For Privacy Protection, the objectives and capabilities Initial Identity / Attribute Verification: The association are: of identifying and/or authorization-related information Notice and Consent: Identified individuals are with an individual is verified. Capabilities: In-Person provided with notice of the intended and expected uses Verification, Remote Evidence-Based Verification. of identifying information, and are given the These capabilities are well addressed by the LIAF. opportunity to consent to uses as appropriate. For Assured Authentication (which could be more Capabilities: Notice, Consent. precisely called Assured Credential Authentication), the Usage Restriction: Uses of identity and credential objectives and capabilities are: information are restricted to those to which identity Credential Binding: The credential is bound to the information providers and identified individuals individual and/or to the transaction that the individual consent. Capabilities: Agreement on Terms of Use, requests. Capabilities: Individual Binding, Conditional Use. As defined in SPICI, Agreement on Transactional Binding. Terms of Use is the capability to validate agreement to the terms of use for shared identity and authorization- Credential Property Validation: The expected related information as a precondition for sharing it.4 properties of the credential are validated. Capabilities: Conditional Property Validation, Procedural Property Disclosure / Exposure Restriction: Identity and Validation. credential information is disclosed, or exposed to observation, only in accordance with restrictions to Credential Status Validation: The status of the which credential providers and identified individuals credential (in particular, whether or not it has been consent. Capabilities: Selective Disclosure/Retrieval revoked) can be determined. Capabilities: Conditional Status Validation, Procedural Status Validation. For Accurate Authorization, the objectives and 4 Terms of use for information are statements about restrictions capabilities are: and obligations applicable to any individual or organization that handles the information. Terms of use can include how the Authorization Attribute Comprehensibility: The information may or may not be used (e.g., for what purposes, in intended meaning of attributes used to make combination with what other information, for how long), with authorization decisions can be discerned; the attributes whom else the information may or may not be shared, how the cannot easily be misconstrued. Capabilities: Common information must be protected, and what accountability for Vocabulary, Mutual Understanding via Common using or sharing the information is needed. Protection, Onward Transfer Restriction, Transmission Authentication Guidance.6 The SPICI-defined capabilities Protection. As defined in SPICI, Selective Disclosure / complement those defined by other frameworks, and Retrieval Protection is the capability to provide in, or thereby fill some gaps in those frameworks related to derive from, credentials only such identity or sharing. The SPICI-defined capabilities do not fill all gaps; authorization-related information as is required for however, SPICI is easily extensible to include additional agreed-upon business processes. capabilities. Retention Restriction: Retention of identity and credential information is restricted to the duration and 6. SPICI ANALYTIC FRAMEWORK conditions to which credential providers and identified SPICI identifies potential harms associated with individuals consent. Capabilities: Conditional sharing identity or credential information, consistent with Retention Restriction, Procedural Retention the E-Authentication Guidance. Based on the level of harm Restriction. (minimal, moderate, substantial, or high),7 SPICI recommends capability assurance levels. This is illustrated For Accountable Trust, the objectives and capabilities for Identity Attribute Correlation, i.e., for the capability to are: determine an individual’s identity based on identifying or Policy Specification and Enforcement: The policies authorization-related attributes, which may come from related to the collection, use, sharing, retention, different credentials. This capability involves either maintenance, and destruction of identity-related correlation and aggregation of identity and credential information are transparent and effective. Capabilities: information or reliance on a unique identifier [14]. This Policy Specification, Policy Enforcement. capability is needed when credential tokens are validated, information from them is extracted, and local stores of Trust Specification: Users of identity and credential shared identity or credential information are updated, so information are able to state the extent to which they that the individual can be identified unambiguously. The can or wish to trust its source. Capabilities: Trust four levels of assurance for this capability are: Designation, Trust Assessment, Trust Accreditation. Weak: A service provider (i.e., an entity that provides Accountability: Organizations and individuals are goods or services to an individual) can have little or no accountable for their handling and use of identity and confidence that shared identity and/or credential credential information. Capabilities: Accountability for information refers to a specific individual. Shared Creation/Collection, Accountability for Use, and identity and/or credential information is associated with Accountability for Disclosure/Sharing, which is the information that the service provider maintains based capability to provide accountability for the onward on a single attribute that can frequently be confused or transfer5 of identity or authorization-related conflated, e.g., name. information. Basic: A service provider can have some confidence Recourse: Organizations that handle or use identity or that shared identity and/or credential information refers credential information provide recourse processes to to a specific individual. Shared identity and/or individuals and/or oversight bodies. Capabilities: Access/Correction Process, Violation/Non-Compliance 6 Recourse. The E-Authentication Guidance and the LIAF define assurance levels that apply to both Unambiguous Identification and SPICI defines assurance levels for the six capabilities it Assured Authentication, and maps potential harm levels to defines (Identity Attribute Correlation, Mutual assurance levels. Community acceptance of this lack of Understanding, Conditional Identity/Attribute Validation, granularity is possible largely because of a relatively large Agreement on Terms of Use, Selective Disclosure/Retrieval common experience in the use of credential processes. Protection, and Accountability for Disclosure/Sharing). However, less experience has been captured, and less consensus Higher levels give greater confidence that the can be expected, regarding the set of capabilities that enable corresponding goals and overarching objectives will be sharing of identity or credential information. Thus, SPICI achieved. SPICI capability levels are defined consistent provides more granularity: levels are defined for different with existing frameworks, including the LIAF and the E- capabilities, and potential harms are mapped not to a bundle of capabilities but to each capability. 7 These levels of harm are largely identical to those in the E- Authentication Guidance. SPICI provides additional detail for harms to individuals. When those harms are associated with 5 Onward transfer is the transfer or disclosure of personal unauthorized disclosure of personal information, the SPICI information to an additional party that did not collect or create definitions of moderate, substantial, and high levels of harm are that information and that is not acting on behalf of the party that consistent with the examples of low, moderate, and high collected or created that information. [12] confidentiality impacts in the draft NIST guide [13]. credential information is associated with information business processes, assess their respective concerns, and that the service provider maintains based on multiple determine what capability levels they require or can attributes (e.g., name plus phone number, name plus achieve. The organizations can thus reach agreement on account identifier), or on a single attribute that is how they each provide the relevant capabilities – on the intended to be unique (e.g., SSN, driver’s license processes and mechanisms they will use to achieve the five number). objectives. Under the I3P project, a spreadsheet tool has Strong: A service provider can have high confidence been prototyped. that shared identity and/or credential information refers Table 1. Recommended Level of Identity Attribute to a specific individual. Shared identity and/or Correlation credential information is associated with information Level of Harm that the service provider maintains based on multiple Potential Harm to attributes that comply with an agreed-upon Service Provider N/A Min Mod Sub High specification, or on a single attribute that the service provider and the entity that shared the information Inconvenience, distress or damage accept as unique (e.g., identity credential supplied by Weak Weak Basic Strong Enh. to standing or an agreed-upon Assurance Level 3 Credential Service reputation Provider). Financial loss or Enhanced: A service provider can have very high Weak Weak Basic Strong Enh. liability confidence that shared identity and/or credential Harm to information refers to a specific individual. Shared organizational identity and/or credential information is associated with Weak Weak Basic Strong Enh. programs or information that the service provider maintains based interests on selective retrieval or evaluation of multiple Sensitive attributes that comply with an agreed-upon Weak Weak Weak Basic Strong information breach specification (e.g., age range rather than date of birth), Civil or criminal based on rigorous methods (e.g., statistical methods), Weak Weak Basic Strong Enh. violations or on a single attribute that the service provider and the entity that shared the information have very high Potential Harm to N/A Min Mod Sub High confidence in as unique (e.g., identity credential Individual supplied by an agreed-upon Assurance Level 4 Social harms Weak Weak Basic Strong Enh. Credential Service Provider). Physical harm or Weak Basic Strong Enh. Enh. Table 1 presents the mapping from levels of potential distress harm to the recommended level for Identity Attribute Financial harms Weak Weak Weak Basic Strong Correlation. For example, if an organization’s potential harm from unauthorized release of sensitive information, due to misidentifying an individual and granting them more In addition, an organization that handles identity or privileges than they are entitled to, is high, then the credential information can use SPICI to manage risks, by recommended level of Identity Attribute Correlation is identifying gaps in current or planned capabilities vis-à-vis Strong. If the potential physical harm to an individual, for recommended assurance levels. An identity management or example due to medical mistreatment based on federation solution provider can use SPICI to profile misidentification associated with an incorrect attribute, is product capabilities. Finally, researchers can use SPICI to substantial, then the recommended level is Enhanced. The identify capability gaps as research areas. The work being overall recommended level is the maximum of the performed or leveraged as part of the I3P Safeguarding recommendations across all stakeholders. Digital Identity project aligns with the six capabilities Identity attribute correlation or matching that does not currently defined in SPICI, and in general will produce rely upon a unique identifier is an active research area at the enhanced capabilities: Enhanced level [15, 16, 17]. A service—VeryIDX [15]—that facilitates trust negotiations across organizations that wish to share 7. CONCLUSION digital identities, and an attribute trust framework [18], Organizations that share identity or credential which address Identity Attribute Correlation and information can use SPICI as part of their process of Conditional Identity / Attribute Validation. negotiating identity federation or other identity information sharing agreements. The organizations can determine Minimum-Disclosure Credentials [19], Attribute-Based which capabilities are relevant to their joint and separate Messaging [20], Attribute-Based Encryption [21, 22], Zero-Knowledge Identity Federation [23] and Privacy- Memorandum 04-04, 13 December 2003, Preserving Distributed Queries address Selective http://www.whitehouse.gov/omb/memoranda/fy04/m04 Disclosure / Retrieval Protection in a variety of -04.pdf contexts. [6] National Institute of Standards and Technology Enabling Web Services for Federated Digital Identities (NIST), Electronic Authentication Guideline, NIST (integrated into a demonstration being developed under Special Publication (SP) 800-63, Version 1.0.2, April the I3P project) address Identity Attribute Correlation 2006, http://csrc.nist.gov/publications/nistpubs/800- and Mutual Understanding via Common Attribute 63/SP800-63V1_0_2.pdf and Draft Revision 1, Syntax and Semantics. December 2008, The SPICI analytic framework is extensible; future http://csrc.nist.gov/publications/PubsDrafts.html#SP- versions of SPICI could include definitions of, and 800-63-Rev.%201 recommendations for, additional capabilities. For example, [7] Liberty Alliance Project, Liberty Identity Assurance Trust Calculus [24], also being developed under the I3P Framework, Version 1.1, June 2008, project, addresses Trust Assessment. http://www.projectliberty.org/liberty/content/download /4315/28869/file/liberty-identity-assurance-framework- 8. ACKNOWLEDGMENTS v1.1.pdf This material is based upon work supported by the U.S. [8] ITU-T FG IdM, Report on Identity Management Department of Homeland Security under Grant Award Framework for Global Interoperability, Study Group Number 2006-CS-001-000001, under the auspices of the 17 Temporary Document 0297 (FG IdM Doc 196), Institute for Information Infrastructure Protection (I3P) http://wftp3.itu.int/fgidm/Deliverables/0297-att-1.doc research program. The I3P is managed by Dartmouth [9] Internet2, Federation Soup: An Assembly of College. The views and conclusions contained in this Ingredients, Proceedings of the Federation Soup document are those of the author and should not be Workshop, held 2-4 June 2008 in Seattle, WA, interpreted as necessarily representing the official policies, 7 September 2008, either expressed or implied, of the U.S. Department of http://middleware.internet2.edu/fedsoup/docs/internet2 Homeland Security, the I3P, or Dartmouth College. -fed_soup_report-200809.pdf 9. BIBLIOGRAPHY [10] Liberty Alliance Project, Liberty Alliance Contractual [1] I3P, Safeguarding Digital Identities Overview, 2008, Framework Outline for Circles of Trust, March 2007, http://www.thei3p.org/docs/research/idmgmtoverview. http://www.projectliberty.org/liberty/content/download pdf /2962/19808/file/Liberty%20Legal%20Frameworks.pd f [2] Bhargav-Spantzel, Abhilasha, Squicciarini, Anna C., Bertino, Elisa, Trust Negotiation in Identity [11] Federal Trade Commission (FTC), Privacy Online: Management, IEEE Security and Privacy, March/April Fair Information Practices in the Electronic 2007. Marketplace: A Federal Trade Commission Report to Congress, May 2000, [3] Gateau, B., Feltus, C., Aubert, J., Incoul, C., An agent- http://www.ftc.gov/reports/privacy2000/privacy2000.p based framework for identity management: The df unsuspected relation with ISO/IEC 15504, in Research Challenges in Information Science, 2008. ISBN: 978- [12] Connolly, K. Law of Internet Security and Privacy 1-4244-1677-6. DOI: 10.1109/RCIS.2008.4632091 (2004 Edition), Aspen Publishers Online, ISBN 0735542732, 9780735542730 [4] American National Standards Institute-Better Business Bureau (ANSI-BBB) Identity Theft Prevention and [13] NIST, Guide to Protecting the Confidentiality of Identity Management Standards Panel (IDSP), Final Personally Identifying Information (PII) (DRAFT), Report Volume I: Findings and Recommendations, 31 NIST SP 800-122 (Draft), January 2008, http://csrc.nist.gov/publications/drafts/800-122/Draft- http://publicaa.ansi.org/sites/apdl/ID%20Theft%20Pre SP800-122.pdf vention%20and%20ID%20Management%20Standards [14] National Alliance for Health Information Technology %20Pa/IDSP%20Final%20Report%20- (NAHIT), Safety in Numbers: Resolving shortcomings %20Volume%20I%20Findings%20and%20Recommen in the matching of patients with their electronic dations.pdf records, Point of View Paper #1, December 2007, [5] Office of Management and Budget (OMB), E- http://www.nahit.org/images/pdfs/PatientIdentifierPoint Authentication Guidance for Federal Agencies, OMB ofView.pdf [15] Bhargav-Spantzel, A., Jungha Woo, Bertino, E. [20] Bobba, R., Fatemieh, O., Khan, F., Gunter, C., and Receipt Management- Transaction history based Khurana, H. Using Attribute-Based Access Control to receipt management, Workshop On Digital Identity Enable Attribute-Based Messaging, IEEE Annual Management, Proceedings of the 2007 ACM workshop Computer Security Applications Conference (ACSAC on Digital identity management, November 2007, '06) , Miami, FL, December 2006. pages: 82 – 91, [21] Goyal, V., Pandeyy, O., Sahaiz, A., and Waters, B. http://homes.cerias.purdue.edu/~bhargav/pdf/ReceiptD Attribute-Based Encryption for Fine-Grained Access IM07.pdf Control of Encrypted Data. Proceedings of the ACM [16] Language Resources and Evaluation Conference, conference on Computer and Communications Proceedings of the 2008 Workshop on Resources and Security, 2006. Evaluation for Identity Matching, Entity Resolution [22] Bethencourt, J., Sahai, A., and Waters, B. 2007. and Entity Management, 31 May 2008, Ciphertext-Policy Attribute-Based Encryption. In http://www.lrec-conf.org/proceedings/lrec2008/ Proceedings of the 2007 IEEE Symposium on Security [17] Hatakeyama, Makoto, Shima, Shigeyoshi. Privilege and Privacy (May 20 - 23, 2007). SP. IEEE Computer federation between different user profiles for service Society, Washington, DC, 321-334. DOI= federation. Proceedings of the 4th ACM workshop on http://dx.doi.org/10.1109/SP.2007.11 Digital identity management, November 2008. DOI= [23] Bhargav-Spantzel, A., Squicciarini, A. C., and Bertino, http://doi.acm.org/10.1145/1456424.1456432 E. 2006. Establishing and protecting digital identity in [18] Mohan, A., and Blough, D. "AttributeTrust: A federation systems. J. Comput. Secur. 14, 3 (May Framework for Evaluating Trust in Aggregated 2006), 269-300. Attributes via a Reputation System, " Proceedings of [24] Huang, J. and Nicol, D. 2009. A Calculus of Trust and the Conference on Privacy, Security, and Trust, 2008. Its Applications to PKI and Identity Management. [19] Bauer, D., Blough. D., and Cash, D. "Minimal Proceedings of IDtrust 2009, April 2009. Information Disclosure with Efficiently Verifiable Credentials. " Proceedings of the 4th ACM Workshop on Digital Identity Management, November 2008. Safeguarding Digital Identity: The SPICI (Sharing Policy, Identity, and Control Information) Approach to Negotiating Identity Federation and Sharing Agreements Deb Bodeau The MITRE Corporation dbodeau@mitre.org Presented at IDtrust 2009 This material is based upon work supported by the U.S. Department of Homeland Security under Grant Award Number 2006-CS-001-000001, under the auspices of the Institute for Information Infrastructure Protection (I3P) research program. The I3P is managed by Dartmouth College. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the U.S. Department of Homeland Security, the I3P, or Dartmouth College. http://www.thei3p.org 1 © 2009 The MITRE Corporation; all rights reserved Approved for Public Release; Distribution Unlimited Case Number 09-1056 Outline • Introduction – SPICI in a Nutshell – Intended Use – Descriptive Framework • Related Work • SPICI Process • Risk Functions • Conclusion 2 1 SPICI in a Nutshell • SPICI provides a structure for clarifying business needs and supporting negotiation on risk-appropriate solutions when organizations share identity (and supporting policy and control) information – Includes a descriptive framework of goals, objectives, and capabilities – Includes an analytic framework which maps levels of stakeholder concerns to recommended levels of capabilities – Includes a high-level description of the negotiation process • SPICI complements technical frameworks and reference implementations for identity federation – Technical frameworks identify “who, what, and where” – Reference implementations demonstrate “how” – SPICI helps organizations analyze “when, why, and how much” 3 SPICI Intended Use Our organizations need to share identity-related information to support our interrelated business processes How do we think about this? Key Concepts and Definitions Information Sensitivity Terms of Use Information Life-Cycle What could go wrong? Potential Harms / Concerns How do we decide which controls Damage to reputation or relationships need to be in place? Financial loss or liability Damage to business or organization Risk Functions Unauthorized release of sensitive General Risk Model (aligned with Liberty) information Control- or Practice-Specific Functions Civil or criminal violations Presented as Simple Tables and in Impacts on individuals – social, financial, Spreadsheet Form to Facilitate Discussion physical SPICI gives us a basis for negotiating about technical and procedural controls … avoiding overkill, but managing our risks 4 2 SPICI Descriptive Framework: Goals and Objectives Unambiguous Identification Specify Identities Resolve Identities Verify Initial Identities / Attributes Assured Authentication Accurate Authorization Bind Credentials Make Attributes Understandable Validate Credential Properties Lynchpin Concepts: Ensure Attribute Quality Validate Credential Status Validate Authorization Attributes Potential Harms Terms of Use Information Life-Cycle Privacy Accountable Protection Trust Provide Notice and Consent Specify and Enforce Policies Restrict Usage Assert Trust Requirements Restrict Disclosure Provide Accountability Restrict Retention Provide Recourse 5 Related Work • Identity Assurance – Liberty Identity Assurance Framework (LIAF) • E-Authentication Guidance (OMB 04-04) • NIST SP 800-63, Electronic Authentication Guideline (v. 1.0.2, April 2006; draft revision, December 2008) – NIST SP 800-103 (Draft), An Ontology of Identity Credentials – Identity Framework for Global Interoperability, Focus Group on Identity Management of the ITU • Identity Federation – Liberty Framework Outline for Circles of Trust – Internet2 Federation Soup • Privacy – NIST SP 800-122 (Draft), Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) • Identity Management Technology Research & Development – Technical Frameworks (architectures, specifications, reference implementations) – Specific Technologies 6 3 SPICI Process • Goal: Enable organizations that need to share credential or other identity- or authorization-related information to agree on the processes, procedures, and technologies they will use – Organizations need to protect their business interests – Identified individuals need assurance that their privacy is protected • To share the credential information, organizations also need to share policy and control information – Example of policy information: Use this credential for no more than 6 months after it was issued – Example of control information: This credential was issued on 14 April 2009 SPICI Process 1. Describe business process needs – What credential, identity, or authorization-related information will be shared? – How is credential, identity, or authorization-related information used in business processes? – What supporting policy and/or control information is needed? 2. Assess concerns or potential harms – To the organizations – To individuals 3. Evaluate risk functions to obtain recommendations for appropriate capability levels – Liberty Identity Assurance Level (includes multiple capabilities) – SPICI-defined capabilities 4. Review recommendations and negotiate mutually acceptable implementation mechanisms 5. Negotiate additional considerations • Results of process – Agreements on business rules – Agreements on standards and technologies to be used 8 4 Assessing Potential Harms Harms to Organizational Providers and Users of Shared Identity / Credential Information • Inconvenience, Reputation Damage • Financial Loss or Liability • Organizational Harms • Unauthorized Release of Sensitive Information • Criminal or Civil Violations Definitions of types and levels of harms consistent with LIAF and E-Authentication Guidance Harms to Individuals • Social Harms Due to Misuse, Unauthorized Disclosure, Inaccuracy • Physical Harms Due to Misuse, Unauthorized Disclosure, Inaccuracy • Financial Loss or Liability due to Identity Theft Definitions of types and levels of harms consistent with FIPS 199 and draft NIST SP 800-122 Harms are assessed as N/A, Minimal, Moderate, Substantial, or High 9 SPICI-Defined Capabilities • Identity Attribute Matching – Objective: Resolve Identities • Conditional Identity / Attribute Validation – Objective : Validate Attributes • Mutual Understanding – Objective : Make Attributes Understandable • Selective Disclosure / Retrieval Protection – Objective : Restrict Disclosure / Exposure • Assertion of Terms of Use – Objective : Restrict Uses • Accountable Disclosure / Sharing – Objective : Provide Accountability For each capability, SPICI defines levels (weak, basic, strong, and enhanced) which can be achieved via technical and/or procedural means 10 5 SPICI Risk Functions • For each type of potential harm, the level of harm due to not achieving the overarching goals (which has been assessed for the identity information to be shared) maps to a risk-appropriate capability level • The recommended capability level is the maximum of the levels appropriate to the different types of harms • Example: Risk function to determine recommended level of Identity Attribute Correlation Level of Harm Potential Harm to Service Provider N/A Min Mod Sub High Inconvenience, distress or Weak Weak Basic Strong Enh. damage to standing or reputation Financial loss or liability Weak Weak Basic Strong Enh. Harm to organizational programs Weak Weak Basic Strong Enh. or interests Unauthorized release of sensitive Weak Weak Weak Basic Strong information Civil or criminal violations Weak Weak Basic Strong Enh. Potential Harm to Individual N/A Min Mod Sub High Social harms Weak Weak Basic Strong Enh. Physical harm or distress Weak Basic Strong Enh. Enh. Financial harms Weak Weak Weak Basic Strong 11 Conclusion • SPICI provides I3P Work in the SPICI Framework – An extensible framework • VeryIDX addresses Identity Attribute which clarifies the role Correlation and Conditional Identity / Attribute Validation of specific technologies • Minimum-Disclosure Credentials, or processes in meeting Attribute-Based Messaging, Attribute-Based Encryption, Zero- objectives by providing Knowledge Identity Federation and Privacy-Preserving Distributed capabilities Queries address Selective Disclosure / Retrieval Protection in a – A process for negotiating variety of contexts identity information sharing • Enabling Web Services for Federated Digital Identities address agreements Identity Attribute Correlation and Mutual Understanding via Common – A set of risk functions to • Attribute Syntax and Semantics Trust Calculus addresses Trust support Assessment that process • Investigation into venues for application and standardization is ongoing 12 6 Backup 13 SPICI Overview SPICI Potential Harms and Levels SPICI Goals • Harms to Organizational Providers and Users of Shared Identity / Credential • Unambiguous Identification Information • Assured Authentication – Inconvenience, Reputation Damage – Financial Loss or Liability • Accurate Authorization – Organizational Harms • Privacy Protection – Unauthorized Release of Sensitive Information • Accountable Trust – Criminal or Civil Violations • Harms to Individuals – Social and Physical Harms Due to Misuse, Unauthorized Disclosure, Inaccuracy – Financial Loss or Liability due to Identity Theft SPICI Objectives, Mapping of Harm Levels to Capabilities, and Capability Recommended Capability Levels Levels SPICI Life-Cycle Models 14 7 SPICI Goals Unambiguous Identification Assured Authentication A user of identity or credential information A user of identity or credential information should be able to distinguish one individual should be able to determine the identity or from another well enough to make decisions authorization-relevant attributes of an regarding and establish accountability for individual with assurance appropriate to the actual or attempted uses of services. potential harms of misdelivered services. Accurate Authorization Privacy Protection A user of identity or credential information A user of identity or credential information should be able to determine whether an should handle the information regarding an individual is authorized to use that service with individual that it maintains or uses with care assurance appropriate to the potential harms sufficient to protect the individual’s privacy. of misdelivered services. Privacy protection can be characterized in more detail by using the Fair Information Practices Principles. A user of identity or credential information, Accountable Trust also referred to as a Identified individuals, and organizational service provider, is an providers and users of identifying and entity that provides a authorization-related information, should be service to individuals, able to explain defensibly (i.e., to give an such as an organization, a account of) why they trust one another to the extent that they do. system, an application, or a Web service. 15 SPICI-Defined Capabilities SPICI SPICI Goals & Objectives Capabilities • Unambiguous Identification • Identity Attribute Correlation – Specify Identities – Objective: Resolve Identities – Resolve Identities – Verify Initial Assignments • Conditional Identity / Attribute Validation • Assured Authentication – Objective : Validate Attributes – Bind Credentials • Mutual Understanding – Validate Credential Properties – Objective : Make Attributes Understandable – Validate Credential Status • Selective Disclosure / Retrieval Protection • Accurate Authorization – Objective : Restrict Disclosure / Exposure – Make Attributes Understandable – Ensure Attribute Quality • Assertion of Terms of Use – Validate Attributes – Objective : Restrict Uses • Privacy Protection • Accountable Disclosure / Sharing – Notice and Consent – Objective : Provide Accountability – Restrict Uses – Restrict Disclosure / Exposure Note: Depending on results of project & stakeholder – Support Redress review, capability definitions could change; more • Accountable Trust – Policy Specification and Enforcement capabilities could be added. – Specify Trust Key: – Provide Accountability • Italics + Underline = Capabilities to meet this goal are – Provide Recourse largely defined by LIAF • Italics = Capabilities to meet this goal are partially defined by LIAF 16 8 Example: Motivating Scenario • Dr. Alpha orders Test X for Patient Beta • Test X requires use of Drug X-Static (a controlled substance) • Dr. Alpha practices at Clinic Gamma • Test X must be performed at Laboratory Delta Credential: • Ordering Physician: Hippocrates Alpha • Physician Medical License Number: mmmmmm • Physician Affiliation: Group Practice Gamma • Ordering Physician’s DEA Number or National Provider Identifier: CAnnnnnnn • Credential Issuer: Gamma-Cred • Credential Issuance Date / Time: mm/dd/yy/TOD • Other Credential Information • Could include obligations (e.g., encrypt digitally stored copies of DEA Number or NPI) 17 Example: Assessment of Potential Harms Potential Harm to User or Provider of Shared Assessment Identity / Credential Information The scenario of concern involves a criminal (possibly an insider at Lab Delta) misusing Alpha’s NPI or DEA number to obtain or prescribe vast amounts of X- Static. Inconvenience, distress or damage to standing or Moderate: If Lab Delta does not protect this reputation information, the relationship between Delta and Gamma could be damaged Financial loss or liability Minimal Harm to organizational programs or interests Moderate: Delta and/or Gamma operations could be disrupted during an investigation Unauthorized release of sensitive information Minimal: The NPI or DEA # is not used to authorize access to sensitive patient information Civil or criminal violations Moderate (or Substantial, if part of a pattern of abuse) Potential Harm to Individual (Physician) Assessment Social harms (Inconvenience, embarrassment, Moderate: Dr. Alpha could be perceived as distress, or damage to personal standing or irresponsible reputation) Physical harms (including detention or Substantial: Dr. Alpha could be arrested or detained imprisonment) Financial loss or liability due to identity theft Minimal or N/A 18 9 Example: Assertion of Terms of Use Terms of use for information are statements about restrictions and obligations applicable to any individual or organization that handles the information. Terms of use can include how the information may or may not be used (e.g., for what purposes, in combination with what other information, for how long), with whom else the information may or may not be shared, how the information must be protected, and what accountability for using or sharing the information is needed. Terms of use can also include obligations regarding accuracy and correction processes. 19 Example: Assertion of Terms of Use (Continued): Definitions of Capability Levels Level Definition Weak The individual, and the entity that shares identity and/or credential information, has little or no confidence that the user of the shared information understands and accepts the terms of use for that information. Typically, this lack of confidence is because terms of use for shared identity and/or credential information are not asserted clearly or explicitly to the user of the shared information. While terms of use may be asserted to the individual (e.g., via a Privacy Notice), this assertion is not communicated to users of shared identity and/or credential information. Basic The individual, and the entity that shares identity and/or credential information, can have some confidence that the user of the shared information understands and accepts the terms of use for that information. Restrictions and obligations are communicated informally. Strong The individual, and the entity that shares identity and/or credential information, can have high confidence that the user of the shared information understands and accepts the terms of use for that information. Restrictions and obligations are stated explicitly and formally agreed (e.g., via a contract or Memorandum of Agreement). Redress processes are defined. Enhanced The individual, and the entity that shares identity and/or credential information, can have very high confidence that the user of the shared information understands and accepts the terms of use for that information. Restrictions and obligations are stated explicitly and formally agreed (e.g., via a contract or Memorandum of Agreement). Redress processes and compliance processes or mechanisms (e.g., auditing processes) are agreed. As feasible, enforcement mechanisms (e.g., Digital Rights Management controls, selective disclosure) are agreed. 20 10 Example: Assertion of Terms of Use (Continued): Recommended Capability Levels Level of Harm Potential Harm to Service Provider N/A Min Mod Sub High Inconvenience, distress or Weak Weak Weak Basic Strong damage to standing or reputation Financial loss or liability Weak Weak Basic Strong Enhanced Harm to organizational programs Weak Weak Basic Strong Enhanced or interests Unauthorized release of sensitive Weak Weak Weak Basic Strong information Civil or criminal violations Weak Weak Basic Strong Enhanced Potential Harm to Individual N/A Min Mod Sub High Social harms Weak Weak Basic Strong Strong Physical harm or distress Weak Weak Basic Strong Enhanced Financial harms Weak Weak Basic Strong Strong 21 SPICI Uses • Organizations that share identity (and supporting policy and control) information can use SPICI to establish business trust – Determine which capabilities are relevant to their joint and separate business processes – Reach agreement on how they each provide the relevant capabilities – on the processes and mechanisms they will use to achieve the four objectives • An organization that handles identity information can use SPICI to manage risks (gaps in current / planned capabilities vis-à-vis recommended levels) • An identity management / federation solution provider can use SPICI to profile product capabilities • Researchers can use SPICI to identify capability gaps as research areas 22 11 Usable Trust Anchor Management∗ Massimiliano Pala Scott A. Rea Department of Computer Science Institute for Security, Technology, and Society Dartmouth College, Hanover, NH Dartmouth College, Hanover, NH pala@cs.dartmouth.edu Scott.A.Rea@dartmouth.edu ABSTRACT Keywords Security in browsers is based upon users trusting a set of Trust Anchor, PRQP, Discovery System, Digital Certificate, root Certificate Authorities (called Trust Anchors) which PKI they may know little or nothing about. Browser vendors face a difficult challenge to provide an appropriate inter- 1. INTRODUCTION AND MOTIVATIONS face for users. Providing usable Trust Anchor Management (TAM) for users, applications and PKI deployers is a com- Browser—based trust decisions are facilitated by a set of plex task. The PKIX working group at Internet Engineering Trust Anchors (TA) that come preloaded in the browser or Task Force (IETF) is working on a new protocol, the Trust via an operating system based Trust Anchor Store (TAS) Anchor Management Protocol (TAMP), which will provide that the browser relies upon. These TAS contain many a standardized method to automatically manage trust an- trust anchors that the average user has no idea in respect to chors in applications and devices. Although promising, this their purpose or community of applicability, yet the browser protocol does not go far enough to allow users to gather makes trust decisions on behalf of those users based on the information about previously unknown trust anchors in an presence and configuration of these elements. automatic fashion. We have proposed the PKI Resource Query Protocol (PRQP)—which is currently an Internet At the NIST PKI Workshop in Gaithersburg, MD in 2007 [10], Draft on Experimental Track with IETF—to provide appli- Kelvin Yiu from Microsoft made the revelation that browsers cations with an automatic discovery system for PKI man- were struggling with the growing size of the TAS—he in- agement. In this paper we describe the basic architecture dicated that Microsoft’s browsers were originally designed and capabilities of PRQP that allow Browsers to provide with a TAS of approximately 100 elements in mind, with an a more complete set of trust anchor management services. upper limit of 200. As PKI communities continue to prolif- We also provide the design of a PRQP enabled infrastruc- erate, it was plainly apparent that the current processes of ture that uses a trust association mechanism to provide an managing the TAS primarily at bootstrap and relying upon easy solution for managing Trust Anchors for Virtual Orga- users to tweak thereafter was not going to be sufficient [19]. nizations. As of today, a simple analysis of the default TA stores in Operating Systems (OSes) and browsers reveals 132 TA in Categories and Subject Descriptors Firefox, 152 TA in OSX, 286 in XP, and (obviously heading K.6.5 [Management of Computing and Information in the right direction) just 30 TA in Vista. Systems]: Security and Protection—authentication A simple task like path construction and validation in hier- archical PKIs still raise many issues today that are not com- General Terms pletely solved thus impacting on the operation and manage- Security ment of large-scale PKIs. Most end-user applications today ∗This work was supported in part by the NSF (under grant still rely exclusively on trust lists. For example, some of the CNS-0448499 ), the U.S. Department of Homeland Secu- most widely deployed network applications such as browsers rity (under Grant Award Number 2006-CS-001-000001), and or Mail User Agents (MUAs) use Trust-Lists as a basis for Sun. The views and conclusions contained in this document trust. As described in [15], trust lists build trust by em- are those of the authors and should not be interpreted as bedding digital certificates locally into applications. This necessarily representing the official policies, either expressed approach leads users to completely rely on the application or implied, of any of the sponsors. vendor for management of her own Trust Anchors without being actively involved in deciding what is trustworthy and Permission to make digital or hard copies of all or part of this work for for what purpose. On the other end, the application vendor personal or classroom use is granted without fee provided that copies are is forced to manage a quite large set of trust anchors— i.e. not made or distributed for profit or commercial advantage and that copies the ones that are embedded into the shipped application. 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 specific permission and/or a fee. Another important aspect to consider is the low level of users’ awareness about trust management [5]: in general IDtrust ’09 April 14-16, 2009, Gaithersburg, MD users do not understand protection technologies and poor Copyright 2009 ACM 978-1-60558-474-4 ...$5.00. user interfaces exacerbate the problem. The authors practi- cal experiences participating on the EuroPKI [1, 14] project lists are commonly used in major off-the-shelf applications as well as being reported in other realities [16] show that and provide a very simple solution to the trust management users often require specialized help and support in order to problem for the average user, but they are criticized because correctly add certificates to the ones trusted by default in a the criteria for insertion of a CA into the list are often based given application. Therefore using pre-cooked TA stores en- more on a commercial rather than a security analysis. Also, courages people to accept by “faith” whatever is hardwired the use of the browser as the interface to many internet into applications. and local applications means that the TAs trusted for one context do not necessarily mean they should be trusted for a There are also environments, such as Grid Computing com- different context (yet this is implied by the way the TAs are munities [2–4], that are very sensitive about TAM. In these used). Therefore we deduce a compelling need for a usable communities interoperability is extremely important and PKI approach to provide Trust Anchor Management services that administrators and application developers struggle with prob- would allow organizations to dynamically manage TAs for a lems related to the lack of flexibility in trust anchor man- large number of users. agement. 2.1 The Trust Anchor Management Protocol Our work addresses trust management issues from a prac- tical point of view by providing a model which both helps In response to this growing demand for bulging TAS, the in removing the reliance upon pre-installed trust lists, and IETF PKIX Working Group set about defining a new pro- provides a local trust management system by using cross- tocol (TAMP) that would help to manage them in an auto- certification. The purpose of our work is to let a single mated standardized way. TAMP is a transport independent organization (be it a company or an aggregate such as a protocol that allows an entity designated as a Trust Anchor research network or a Virtual Organization) to unilaterally Manager to query for status and update TAS with TA ele- create trust for its users of selected foreign PKIs or CAs in ments. As TAMP is making its way through the standard- a way that is easily supported by current applications. ization process, it has become apparent through comments on the discussion lists, that the protocol is not broad enough The rest of the paper is organized as follows. Section 2 to cover all use cases for TA management. In fact TAMP presents the related work and current limitations. Section 3 defines only three types of TA: introduces an overview of the possibilities offered by a dy- namic TA management system. Section 4 describes our new (a.) An Apex TA which is the TA that is superior to every hybrid trust model. Section 5 explains how to integrate other TA within the TAS and is used to manage the our hybrid trust model with PRQP in order to provide a rest of the TAS elements; dynamic TA management system. Section 6 contains our (b.) one or more Management TA that is used to manage conclusions and future work. cryptographic modules within the TAS; (c.) one or more Identity TA that are the traditional X.509 anchors used to validate certificate paths for typical 2. RELATED WORK PKI Since the 1976 paper by Diffie and Hellman [22] and the in- Obviously there are many scenarios where the choice of Apex troduction of a public key cryptosystem [18], the presence of TA leads to issues. In particular allowing a user to control some sort of trusted directory for public key access has been their own Apex TA may undermine the possibility for all a steady reality in PKIs. The very nature of the trusted the browser (and OS) vendors to adopt TAMP in the pre- directory strictly depends on the trust model used in the ferred way to manage their respective TAS (however, the infrastructure. In fact the organization of a PKI reflects the later may simply be an effort by browser vendors to bind trust model required by its constituency. In X.509-based users to them by holding onto the responsibility of manag- PKIs (or PKIX), there are three different “pure” trust mod- ing trust for the users, but could also simply be a function els: hierarchical, cross-certification (e.g. bridge CA), and of the TAMP standard not being completed and accepted trust lists. In addition to individual “pure” models, combi- by the community yet). nations of these models may be adopted, with varying ca- pacities and implications for interoperability. In all cases Moreover the current document which specifies the require- models require that participants obtain trusted knowledge ments for the TAM protocol [17] restricts the design to the of one or more public keys to enable them to discover and “push” model. In this model, a centralized service would validate certification paths. This information may be ob- directly manage the application(s) TA store by pushing the tained by using special configurations, by out-of-band man- content directly to the application. This approach is specifi- agement and/or by explicit acceptance of keys offered dur- cally adopted because the current version of TAMP is thought ing network exchanges. In PKIX (X.509-based PKIs), trust to be efficient for enterprises where the control over the anchors are usually provided in the form of self-signed cer- clients can be very strict. Future versions of the protocol, tificates. Although this approach is a convenient implemen- however, could extend this approach to a “pull” model which tation strategy and allows integrity checking, it does not would allow for more interoperable TAM services across an add any fundamental trust enhancement relative to other organization’s boundaries. representations. One potential issue with TAMP is that it specifies that there In the web environment, where browsers are preloaded with should be one and only one Apex TA for each TAS. While an high number of trusted root keys, the inclusion of root this makes perfect sense from a management protocol per- certificates have become commercially valuable assets. Trust spective, it has implications for the browser trust model. A Table 1: Comparison between Trust Models. Hierarchies Cross-Cert Bridge CA Trust Lists Trust Anchor Hierarchy Root Local CA Local CA Listed CAs Inter Domain Support Poor Good Very Good Good Path Construction Very Easy Hard Easy Very Easy Repository Dependency Low High High Low single root that controls the trust settings of all other trust TA from a given enterprise is not a sufficient solution, since anchors in a browser TAS should only be allowed where the this may lead to conflicts for an individual as they interact Apex TA is under direct control of the user. If the Apex TA with multiple organizations, by allowing the TA policy (and was controlled by a single vendor, then that vendor could po- Apex TA) of one organization to control the trust settings tentially lock out any other vendors from being accepted for of another. that user, and enforce a restriction of trade. In some sense, this is the situation today with the current browser trust Therefore we propose that browsers should support a sin- model—the browser vendors determine who is in the trust gle Apex TA, instantiated by a user, that they can utilize to list i.e. the vendors act as an Apex TA—however, out of subscribe to multiple TAS management services (which may band updates by users are permitted in the current browser be organization based), and that the browsers support mul- model, and it is not clear that the equivalent functionality tiple TAS instances that are scoped for a given purpose or is supported in TAMP. Also, TAMP being an “automated” application, for a given enterprise or community of interest. management protocol, means that updates occur without That way, a user of enterprise X services could subscribe to notifying the user once the initial subscription has been en- the enterprise X TAS Management Service (TMS), which tered into. would automatically update a partition of their browser of choice TAS, with those TA’s that enterprise X has deter- mined as trustworthy. The user’s browser would then rely 2.1.1 Current Limitations upon those trust settings in that partition of their TAS, for Putting the responsibility for managing their TAS into the all domains that the user indicates they are applicable to. hands of an uneducated or inexperienced user also has severe trust implications—which is why the vendors have generally This approach would make it possible, for instance, for a undertaken the current process to make a best effort de- user to subscribe to a company TMS, and have a parti- termination at who should be trusted by default and who tion of their browser TAS (it could be the entire TAS, or should not, and allow the users to manage it from there. a separated store altogether) be automatically set to have The problem with this approach is that almost all average the trust settings that the company recommends. The user users have no idea how to make a trust decision about a could then apply those trust settings globally if they wished given TA. Sure, there are standards and processes that can to all transactions they undertake, or could restrict it to only be utilized to facilitate the trust decision, and that is what those dealing with services from the company domain. This most browser vendors currently do for the TAS default set, would mean that browser vendors could be relieved from but a user can not be expected to take on that responsibility managing users initial TAS (thus reducing costs and effort) as an individual, when even experts in the field have issues or offer it as a separated service. Consequently, users would agreeing on trust implications on a regular basis. For in- have a simplified trust decision to make rather than having stance, just because an organization spends $120K to get a to evaluate each TA individually, that is “do I want to adopt Web Trust audit, it does not necessarily mean that it runs a the recommended TA’s from organization X ?”. benevolent Certification Authority (CA)—nor does getting a Web Trust approval necessarily mean that it is running a Now in order to make the above feasible, it should be possi- secure and trustworthy PKI! Yet often this is the yard stick ble to discover what PKIs are trusted by what organization, applied to vendor gated TAS. whether an organization has a TMS, and how to access those services. Until recently, there was no mechanism to discover Putting aside the question of individuals managing their these details. TAS for the moment, a business or enterprise must also make decisions about what TA they intend to trust and for what The PKI Resource Query Protocol (PRQP) [11,12]—recently purpose. This is based upon some assessment (usually risk- adopted as a working item by the PKIX Working Group at benefit based), and they advise their constituents via policy IETF—would facilitate users and application vendors by be- or other method as to which TA’s should make up a TAS ing able to discover appropriate PKI and TMS services. that is acceptable to their enterprise. Individuals within the enterprise then adjust their TAS based on the advice or pol- 2.2 The PKI Resource Query Protocol in a Nut- icy from the enterprise or community to which they belong. shell TAMP is a fantastic protocol to facilitate this process as long as the individual has some way of establishing trust with the Integrating all current protocols and standards to provide enterprise or community. Since individuals are most often an efficient way to discover PKI related services is an open not restricted to having trust relationships with a single en- challenge. The PRQP protocol provides a simple approach terprise or community, an individual adopting a single Apex that changes the current paradigm by allowing for more dy- namic management and configuration of applications and cerned, the notion of Digital Certificates or Public Key In- their TAS. frastructure is a mystery. Many papers [5,20] have discussed the issue of the lack of understanding about security and the PRQP assumes the presence of a Resource Query Author- underlying technologies. Therefore we need a new approach ity (RQA) that would provide applications with the locators that will allow Users to make informed Trust decisions. of services associated to a particular Certification Author- ity (CA). In PRQP, the client and a RQA (the server) ex- A Recent paper [7] has shown that users understand trust change a single round of messages where the client requests through the concept of Institutions and their reliability more a resource token by sending a request to the server and the than Digital Certificates and Certification Authorities. In server replies back by sending a response to the requesting particular the study shows how users tend to rely on well entity. An RQA can play two roles. First, a CA can directly known institutions and their level of reliability more than delegate an RQA as the party who can answer queries about other users’ suggestions (also if well known) or technical de- its certificates, by issuing a certificate to the RQA with a tails. It is therefore clear how the concept of trust should unique value set in the extendedKeyUsage (i.e. prqpSign- be presented to the users in terms of what they can really ing). The RQA will provide authoritative responses for re- understand: “who already trusts this organization (eg., Cer- quests regarding the CA that issued the RQA certificate. tification Authority) ?” Alternatively, an RQA can act as PRQP Trusted Author- ity (PTA). In this case, the RQA may provide responses By integrating PRQP with current applications and enabling about multiple CAs without the need to have been directly the automatic discovery of PKI-related resources, the TA certified by them. In this configuration the RQA may be management problem can be actively put into the hand of configured to respond for different CAs which may or may the users. One major hurdle to overcome however, is how not belong to the same PKI as the RQA’s one. the interface for managing these services are presented to, and interacted with by the user. A sample User Interface (UI) from a common application is reported in Figure 1. It 3. DYNAMIC TRUST ANCHOR MANAGE- is evident that such interface is too complicated for the ma- MENT: THE NEXT CHALLENGE jority of users. In order to be able to provide an easier UI, the application could dynamically discover all the services PKIs enable trust judgments between distributed users with- provided by the PKI and the trust information about the out the need of a direct interaction between them. However, CA provided by other organizations, and present this ad- being able to securely identify a user is not sufficient. In- ditional information to the user in a meaningful way. The deed in order to make trust judgments, a relying party needs PRQP protocol would allow applications to provide such an more information than the user’s bare certificate. For ex- interface for Trust Management. ample, a Web Server or a SSO application must be able to locate critical parameters such as the certificate repositories The Application Vendor Perspective. As far as the and certificate validation servers relevant to the trust path average developer is concerned, the notion of Digital Certifi- under consideration. cates or Public Key Infrastructure is also a mystery. More- over the complexity of current PKI standards makes it dif- Current PKIs often fail to provide such integration, therefore ficult for developers who are not PKI experts to correctly application vendors and users struggle when trying to enable process the information within certificates. Also, because of all the supported protocols. This failure is primarily due to the number of different services and repositories to access the lack of (a.) interoperability between PKIs and (b.) avail- in order to build a simple certificate chain, the average ap- ability of pointers to services. In [11], the authors point out plication either does not implement correctly and fully the how current CA certificates do not provide a good source of standards or has dozens of options to configure those ser- information when it comes to discovering the services that vices and they pass those decisions onto the user who has are associated with them. For example, out of the analyzed no idea how to set them up. browser stores1 , almost no service locators were provided in the certificates (besides a few OCSP pointers). This lack of To solve this problem PRQP provides a simple and efficient flexibility and service availability is also present in current way to enable applications to easily discover PKI services. TA management. Indeed each party involved in TA man- We estimate that it would be possible to get rid of most of agement deals with it independently without considering all the current configuration options faced by vendors in prepar- the different points of view of the other parties. ing UIs, thus allowing for easier UIs and faster development times in applications. When considering Trust Management issues, one of the most common errors is to restrict the view to a single perspective In particular, for TAS Management, PRQP could be used only. We think that the problem should be analyzed from, to discover TAMP data sources. Multiple sources could be at least, three different points of view: the user perspective, dynamically discovered for specific domains and a hierarchy the application vendor perspective, and the PKI vendor per- of stores can be built according to the user’s preferences. spective. In this section we focus on the benefits of adopting The Application Vendor will still be able to dynamically a dynamic approach to TAM and how PRQP is a fundamen- provide its own Trust Anchor Management updates (e.g., tal building block of a viable TAM infrastructure. for OS management purposes or specific trusted domains) while the user would be able to add its own settings. The User Perspective. As far as most users are con- 1 The PKI Vendor Perspective. There are many differ- Firefox, IE, and Konqueror Figure 1: Example UI—Understanding the full consequences of adding a Trust Anchor is beyond the ability of the average users and of many advanced ones. Also, interfaces from other applications suffer from similar problems: either it is misleading and too complex or it provides no useful information to the user. ent types of PKIs that serve different purposes. Besides 4. TA MANAGEMENT FOR CURRENT AP- SSL vendors, a huge market for PKI related services is to- PLICATIONS day totally ignoring commercial vendors. Environments like Computing Grids where Public Key Certificates have been While waiting for standard protocols to be finalized and used for well over a decade are, today, left with little sup- adopted by applications, the need for a solution is com- port by application vendors. By enabling organizations to pelling. The trust model we present in this section allows integrate different PKIs and provide dynamic TA manage- organizations (or Virtual Organizations such as accredita- ment, the occasion for a bigger market is evident. The more tion bodies) to provide users with an easy-to-use solution usable PKIs are, the more the users will be willing to adopt which is compatible with deployed software and supports this technology. There are potentially real world-wide client- the way users make trust decisions. side PKIs everywhere you look—e.g, cellular phones, mobile devices, wireless network authentication, home devices, e- When already deployed infrastructures—established by dif- commerce application, etc... ferent organizations—want to develop a common trust rela- tionship between them, some form of cross-certification must In order to provide more flexible support to the users, PKI be applied to link them. Table 1 reports a summary of the vendors need the capability to deploy more flexible PKIs. In characteristic of different trust models. It could be desir- particular the adoption of PRQP—and eventually its Peer- able to have a model which provides the flexibility typical 2-Peer extension [13]—can enable vendors to activate, move, of cross-certification while not introducing high complexity dismiss, and enhance services easily. This provides PKI de- for certification path building. Our work is based on the ployers with the possibility of molding the infrastructure as integration of two different components: a deployed PRQP the needs or profile of the users change thus being able to infrastructure and a hybrid trust model. Our solution is offer a more usable experience of the offered products. An capable to address trust management issues by providing: example of the benefits of adopting PRQP would be the • a method to avoid multiple trust points hardwired seamless dismissal of an old (or potentially broken) service— into applications (i.e. to avoid embedding large trust like CRLs—in favor of a new one—e.g. OCSP—without the stores); our approach requires a single trust anchor need of re-issuing every certificate because of the usage of (e.g. a Root CA which could, in future, act as an Apex static extensions. TA under TAMP) for inter-hierarchies trust support • a simple trust management system for applications As we wait for trust anchor management protocols to wind based on cross-certificates their way through the standardization process, we still need • the possibility for PKI operators to provide their users to manage trust anchors in environments today. In the next with a set of revocable endorsed TAs section we present a hybrid trust infrastructure that could be deployed in current systems to help manage TAs until Cross-Certification has the interesting characteristic that it TAMP matures. can preserve the organization’s ability to enforce constraints within their hierarchies. Annex G of the ISO document [9] discusses specifically this case by presenting three different types of Cross-Certificates: MyRoot Cert (X) Subject=X Issuer=X pKey(Y) = pKey() Cross-Cert (Y) Subject=Issuer() ExtRoot Cert () Issuer=Subject(X) Subject= akid hash(pKey(X)) Issuer= Serial(X) + Issuer(X) Subject=W Issuer=Subject() hash(pKey()) akid Serial() + Issuer() Cert to be verified (W) Figure 2: Cross-Certificate of an external Root CA. • Hierarchical Cross-Certificates extend path construc- (c) Check that the keyUsage in certificate y supports cer- tion from leaf CAs upwards Root CA, thus allowing tificate signing relying parties to use their local CA as trust anchor (d) Check that the policy and name constrains require- • General Cross-Certificates to interconnect CAs. This ments are fulfilled can be done either at root level or at sub-CA level To continue the chain building process, repeat the steps • Special Cross-Certificates are intended to allow selec- above till one trust anchor or a self-signed certificate is tive establishment of certification paths that may not reached. Special attention should be made during step (b). conform to the restrictions imposed hierarchically In fact the presence and the contents of the authorityKeyI- In this work we combine the hierarchical and cross-certification dentifier can vary depending on the certificate to be verified. models, by using “special” cross-certificates to allow for lo- Four different certificate profiles are hereby reported which cally managed trust path building for applications. In order summarize the possible contents of the authorityKeyIdenti- to better understand how our model is particularly efficient fier (akid ) extension: and why it is supported out of the box by existing applica- α the extension is not present in the certificate. The tions, the next subsection provides a brief description of the chain is actually built by using the subject and issuer certification path building process in PKIX. fields of the certificate β the extension is present in the certificate and it carries 4.1 Certification Path Building the keyIdentifier which, usually, contains the hash of the public key of the issuer Assuming we have a set of trusted certificates and we need to γ the extension is present in the certificate and it carries build a trust path from certificate x up to one trust anchor, the authorityCertIssuer and the authorityCertSerial- we have to identify the issuer of certificate x and check if it is Number. trusted or not. In case it is not, we need to verify if its issuer δ the extension is present in the certificate and it carries is trusted. The process continues until a trusted certificate both the keyIdentifier and the authorityCertIssuer and is identified in the chain or no suitable issuer is found among authorityCertSerialNumber couple. the available certificates or, finally, a self-signed certificate The first two profiles do no require special care when deal- is reached. Therefore the identification of the issuer of a ing with cross-certification while, as we will discuss in detail certificate is a crucial aspect of the path building process. in the next parts of this section, the other two do. In fact, Assuming we want to check if the subject of certificate y is within the last two profiles, the certificate’s issuer is identi- the issuer of certificate x, the needed steps are: fied both by the Issuer field contents and by it’s issuer and (a) check the Issuer field of certificate x to be equal to the it’s serial number in the akid extension. For instance if we Subject field of certificate y want to identify the certificate x we use the couple: (b) If authorityKeyIdentifier extension exists in certificate issuer(x) + serialN um(x) (1) x, then check it matches the data of certificate y MyRoot Cert (X) ExtRoot Cert () Subject=X Subject= Issuer=X Issuer= Cross-Cert (Y) Subject=Subject() Subject= CA Cert () Issuer=Subject(X) Issuer=Subject() hash(pKey()) akid akid hash(pKey(X)) Serial(X) + Issuer(X) Serial() + Issuer() pKey(Y) = pKey() Subject=W Issuer=Subject() hash(pKey()) akid Serial() + Issuer() Cert to be verified (W) Figure 3: Cross-Certificate (Y ) for an external Sub-CA (µ). in the same way, if we want to identify the issuer of certificate By providing the extCrossCA1...n certificates to the client, x we use the couple: it is possible to build a trusted chain of certificates up to the OrganizationA’s root-CA. Indeed by comparing the author- issuer(issuer(x)) + serialN um(issuer(x)) (2) ityKeyIdentifier in the extUserCert with the locally stored where the issuer(x) is the Subject of the issuer of x. This extCrossCA1...n certificates’ contents, the path construction explanation is needed to better understand differences in our can proceed up to orgA rootCA, thus establishing a trusted trust model when trusting Root CAs or subCAs as explained chain from extUserCert up to the only trust anchor needed in Sections 4.3 and 4.4. in the application. Although the basic principles are very simple, further anal- 4.2 The Model Basics ysis is needed to correctly allow the path building process In our model we assume that at least one CA certificate to take place. In the next subsections we provide the de- is installed into the application certificate store and it is tails of our hybrid trust model. In particular we will use the trusted, e.g. this may be the Apex TA in future as required following terminology: by TAMP. To better introduce our solution, a practical ex- • issuer(x) identifies the Issuer field in certificate x ample could be represented by a National Research Network • subject(x) identifies the Subject field in certificate x (NREN)–named OrganizationA— which already established a PKI and wants to provide a way to automatically verify • serialNum(x) identifies the serialNumber field in cer- all the certificates issued by other n NRENs. The root CA tificate x from OrganizationA (orgA rootCA) cross-certifies the other 4.3 Trusting Root CAs NRENs root-CAs (i.e. extCA1 , extCA2 , . . . , extCAn ) by issuing certificates carrying the same details as the original Extending the trust to a whole external PKI is done by ones (e.g. Subject, Public Key and Extensions). The newly issuing a cross certificate for the external root-CA. Figure 2 issued certificates will only differ from the original ones in reports the scenario where the certificate W of the external that they are issued by orgA rootCA within the Organiza- PKI is linked to the organizational PKI throughout Y . If tionA’s infrastructure. The cross-certificates will be referred the akid extension is not present (case α and β of Section as extCrossCA1...n . 4.1), the cross-certificate Y will use the same public key and Subject of the original root-CA whilst having a different If a user from OrganizationA’s hierarchy wants to verify a Issuer (MyRoot). If the akid extension is used (case γ and certificate issued by one of the extCA1...n hierarchies (e.g. δ in Section 4.1) it is important to issue the cross-certificate in order to verify a signed S/MIME message) then a path in such a way it will be referred by the akid of certificate from that certificate (extUserCert) up to orgA rootCA has W . In this particular case of cross-certifying a root-CA, the to be established. Issuer and the Subject contents of the certificate are the ExtRoot Cert (..) Subject=”..” Issuer=”..” MyRoot Cert (X) CA Cert () Subject=X Subject= Issuer=X Issuer=”..” Intermediary CAs Auxiliary CA (Y) Subject=Subject() Subject= CA Cert () Issuer=Subject(X) Issuer=Subject() hash(pKey()) akid hash(pKey(X)) akid Serial(X) + Issuer(X) Serial() + Issuer() Cross-Cert (W) Subject=Subject() Subject= CA Cert () Issuer=Subject(Y) Issuer=Subject() hash(pKey()) akid akid hash(pKey(Y)) Serial(Y) + Issuer(Y) Serial() + Issuer() pKey(W) = pKey() Subject=Z Issuer=Subject() hash(pKey()) akid Serial() + Issuer() Cert to be verified (Z) Figure 4: Our Hybrid Trust Model with Auxiliary CA (Y ). same. This means that, according to (2), the issuer of the The condition (7) is the most hard to match. In fact typi- root-CA is identified in the akid by: cally rootCA certificates have the serialNum set to zero and, as the serial number must be unique within a CA, it is diffi- issuer(issuer(rootCA)) + serialN um(issuer(rootCA)) cult that the serial number required for Y is available under (3) X. As we will discuss in detail in the next sections, the se- where: rialNum constraint can be fulfilled by introducing into the issuer(rootCA) = subject(rootCA) (4) model an auxiliary CA for each external CA/PKI we want to establish a trust with. serialN um(issuer(rootCA)) = serialN um(rootCA) (5) 4.4 Extending the model: trusting subCAs therefore (3) becomes: Figure 3 represents the scenario where we want to issue a issuer(subject(rootCA)) + serialN um(rootCA) = cross certificate to include only a sub-CA, not a whole exter- subject(rootCA) + serialN um(rootCA) nal PKI. In this case we want to be able to verify certificate W by building the chain: hence if the certificate W (with the akid extension carrying the serialN um(λ)+Issuer(λ) identifier) points correctly to W −→ Y −→ X (8) Y if and only if: to do this, the cross certificate Y will have: subject(Y ) = Issuer(λ) = subject(λ) (6) subject(Y ) = subject(µ) and if no akid extension is present in W or if it contains only serialN um(Y ) = serialN um(λ) (7) the keyIdentifier, the path building process does not present particular issues. On the contrary if we are in case γ or δ MyOrg root-CA (X) (Section 4.1), then the path building process will fail because Subject: ”CN=CA X,O=My ORG” it is impossible to issue Y obeying the akid constrains. In Issuer: fact the akid of W identifies the issuer(W): ”CN=CA X,O=My ORG” authorityCertIssuer(W ) = serialN um(µ) + issuer(µ) Auxiliary CA (Y) Subject: = serialN um(µ) + subject(λ) “CN=CA , O=Ext ORG” Ext root-CA () Issuer: Subject: “CN=CA X, O=My ORG” ”CN=CA , O=Ext ORG” hash(pKey(X)) akid Issuer: and to fulfill its requirements (besides the serialNum prob- Serial(X) + Issuer(X) ”CN=CA , O=Ext ORG” lem) it should be: Subject: Subject: Cross-Cert (W) Ext subCA () issuer(Y ) = issuer(µ) = subject(λ) (9) “CN=CA , O=Ext ORG” ”CN=CA , O=Ext ORG” Issuer: Issuer: “CN=CA , O=Ext ORG” , O=Ext ORG” unfortunately with the proposed infrastructure, this is not “CN=CA hash(pKey(Y)) possible because: hash(pKey()) akid akid Serial(Y) + Issuer(Y) Serial() + Issuer() issuer(Y ) = subject(X) 6= subject(λ) (10) pKey(W) = pKey() To overcome this problem, an addition to the model is needed, Subject: ”CN=USER/O=EXT PKI” as detailed in the next section. Issuer: “CN=CA ,O=Ext ORG” 4.5 Introducing auxiliary CAs hash(pKey()) akid Serial() + Issuer() To provide a generally applicable model we introduce an Cert to be verified (usr-cert) auxiliary CA (Figure 4) into our schema. The purpose of this CA, which is identified by the certificate Y , is to provide a more general solution that is capable of addressing the Figure 5: Test bed environment. potential limitations imposed in the path building process by the akid extension. 4.7 Application Support Indeed, to have the akid to correctly point to the cross- certificate W , we have to set subject of the auxiliary CA Y One of the main advantages of this solution is that it is sup- to be equal to the issuer of the sub CA µ. By adding Y to ported out-of-the-box by several widely diffused operating the infrastructure, we have: systems and applications. This section focuses its attention on performed tests and code analysis (whenever possible) to subject(W ) = subject(ν) (11) describe how the hybrid trust model is actually supported. Figure 5 depicts the used test environment. The certificate to be verified in the example is the “usrcert” which is is- issuer(W ) = subject(Y ) = subject(µ) = issuer(ν) (12) sued by subCA-Y from the external organization we want to establish a trust link with. In order to do that, we issue serialN um(W ) = serialN um(ν) (13) a certificate for the subCA-Y which acts as the auxiliary CA in our hybrid trust model. Then subCA-Y issues the therefore the akid of Z points correctly to W because the cross-certificate subCA-W which, in our model, “replaces” serial number of W is equal to serialNum(ν) as in (13), its the original certificate from the external organization in the issuer is equal to Issuer(ν) as in (12) and its public key is path building process. The purpose of the performed tests equal to pKey(ν) as W is the cross certificate for ν. was to establish if the proposed trust model was supported by current applications. Moreover the Subject/Issuer content requirements are also satisfied because: 4.7.1 OpenSSL libraries issuer(Z) = subject(ν) = subject(W ) (14) In the Unix world (e.g. Linux, BSD, Solaris, etc... ), the OpenSSL suite provides the most used cryptographic libraries. It is therefore possible to extend trust to external PKIs/CAs By analyzing the OpenSSL code, it has been possible to dis- by introducing only one auxiliary CA that issues one cross- cover that our model is actually supported by OpenSSL. certificate for the CA to be trusted. Anyway further considerations are needed for special cov- ered cases. 4.6 Revoking Trust Anchors The OpenSSL cryptographic library provides the functions One interesting aspect of the proposed model is the possibil- needed to build the chain of certificates and to verify them. ity of revoking TAs by using standard PKIX mechanisms. In To better understand how the library verifies certificates, fact, because trust is built by issuing standard certificates, it is useful to describe the main involved data structures. it is possible to revoke them by simply using revocation ser- OpenSSL uses different objects during the verification pro- vices that are already in place (e.g., CRLs or OCSP). cess: • the X509_STORE object is actually used to represent Untrusted Trusted Root a collection of certificates and eventually certificates No link between the External Root two path is present revocation lists (CRLs) at this level • the X509_STORE_CTX object holds the data used during an actual verification After loading all the needed data in the X509_STORE, OpenSSL uses this datastructure to initialize the X509_STORE_CTX by calling the following function: Same public Key int X509_STORE_CTX *X509_STORE_CTX_init(...) If the initialization function completes successfully a pointer Server Certificate to be verified to a X509_STORE_CTX data structure is returned (ctx). The following function is then used to perform the verification of the chain of certificates: int X509_verify_cert(X509_STORE_CTX *ctx); Figure 6: SSL/TLS connections and our hybrid trust model. The verify function builds the chain up to the trust anchor by looking in the ctx for a suitable issuer of the current serial number but its issuer is actually different. Hopefully certificate. This process is then repeated until no issuer for this behavior will be fixed in future versions of the software. the certificate is found in the ctx either because of an error As detailed in Section 4.7.4 issues are also present when or because a trust anchor has been reached. The checks SSL/TLS connections are considered. performed to see if certificate B has been issued by certificate A are: 4.7.3 Windows CryptoAPI (a) Check the Subject field of A to be equal to the Issuer field of B It has been possible to successfully test support for our (b) If authorityKeyIdentifier exists in B, then check it model on Windows based systems, in particular it was pos- matches details of certificate A sible to correctly verify certificates in: (c) If keyUsage extension is present in A, then check it • Windows 2000 supports certificate signing • Windows XP (d) returns 0 on success, or a positive for the reason for • Windows 2003 mismatch • Windows Vista Thanks to the addition of the auxiliary CA, the OpenSSL Unfortunately, it was not possible to verify how exactly the verification function returns successfully if the calling ap- path building is done by Windows CryptoAPI because of the plication provides the chain up to the trust anchor. Tests lack of the libraries source code. Anyway every application have been carried out by using applications which use these that relies on the Windows system libraries should automati- libraries (i.e. KMail and Konqueror) and, as we expected, cally support this model. Performed tests show that support results were positive. for the proposed model is available in Internet Explorer as well as in Outlook. 4.7.2 Mozilla Suite 4.7.4 SSL and TLS connections The explained hybrid trust model provides a method for trust path building that follows RFC-5280 [6], therefore all Besides applications based on Microsoft CryptoAPI that applications should be able to support the model. From fully supports the proposed trust model, our tests show that the performed tests, we found out that our model is fully some of the tested software presents issues when setting up supported when one of the following conditions is matched: SSL/TLS channels. In particular the problem we found is present only when extending trust to non-root CAs (Sec- • the CA to be trusted is a rootCA tion 4.4). In OpenSSL, for example, the function used to • the CA is a subCA and the client does not have the build and verify the path up to a trusted anchor for secure original the chain of certificates up to the external channel setup is different than the one used for statically rootCA stored in the local repository. verify a chain of certificates. This is due to the fact that the Regrettably, Mozilla based applications (i.e. Firefox and RFC-2246 [8] standard allows the server to push the chain of Thunderbird) do not fully support our solution in the re- the certificates to the client. Figure 6 depicts the scenario. maining cases because of the way certificates are stored in its local repository. In fact if the original chain of certifi- When setting up an SSL/TLS connection, the application cate is already present in the certificate store an error about makes use of the SSL_CTX family of functions. These func- the presence of two certificates issued by the same authority tions use the chain of certificates that is pushed through the with the same serial number is displayed to the user when channel instead of the certificates in the local store up to importing the cross certificate for the subCA. This is obvi- the TA (which is verified against the local store). Therefore ously an error in the certificate store as it reports wrong in- when the last certificate in the pushed chain is to be veri- formation to the user, i.e. the cross-certificate has the same fied, there might be no way for the application to link the trusted anchor (in the local store) to the external root (in 5.1 Distributing hybrid certificates the original trust path). A possible way to avoid this situ- ation would be to check, at each step of the path building One issue that we have not yet addressed in this paper is how process, if either: to provide the applications with the needed special cross- certificates. In fact, applications need to know that a cross- • a locally stored certificate is a suitable issuer of the certificate for that particular rootCA or subCA exists in or- certificate to be verified. If such a certificate exists, der to correctly build the verification path up to the trusted use it as the issuer instead of proceeding in the path anchor. Since recently, there was no interoperable solution building process by searching in the pushed certificate to dynamically provide applications with references (URLs) chain from the server to certificate bundles. We considered several possibilities • a locally stored certificate has the same public key of when trying to address this issue. For example some sort of the current certificate to be verified. If such a certifi- automatic update system could be implemented to gather cate exists, use its issuer from the local repository as the special cross-certificates from a trusted source. Such the next step in the path building process instead of mechanisms are already in place for updating many mod- searching for the issuer in the pushed certificate chain ern operating systems, therefore a similar solution could be from the server. adopted in some environments. Because we want to pro- In other words, if path checking fails, a second attempt vide a generic and interoperable solution across operating should be made by letting the locally stored certificates to systems and applications, we decided to adopt a different take precedence over those pushed by the peer. By us- approach. ing these simple changes in the path building process of OpenSSL and Mozilla based applications our model is fully In particular, in our solution we used a PRQP server (i.e., supported also for SSL/TLS channel setup. an RQA) to distribute locators (URLs) to sets of certificates endorsed by CAs. In order to do that, we needed to extend 5. INTEGRATING PRQP AND OUR HYBRID the current specifications of the PRQP protocol. To iden- TRUST MODEL tify the packet of endorsed CAs, we specified a new Object Identifier (OIDs) as follows: The first interesting feature provided by this trust model is that trust is locally managed by simply issuing or revoking “special” cross-certificates. This approach saves users from id-ad-prqp-p7endorsedTA ::= { id-ad-prqp 100 } having to perform security checks each time a new certificate is to be added to the application’s repository. By using the proposed model the verification of public-keys (and extCAs which we used to identify the locator for a PKCS#7 signed details) can be performed by CA managers (or experts in object. This object contains the set of certificates that are PKI policy verification and auditing) when issuing the cross- endorsed by a particular CA and it should be signed by the certificate in a reasonably and reliable secure way (e.g. all CA directly. needed steps to verify details about the CA certificate to be cross-certificated will be checked). In our infrastructure, when an application needs to import the set of TAs endorsed by a specific CA, it queries the The second attractive feature of this solution is that no RQA that carries the configuration for the specific CA. In extCA1...n original certificate is needed on the application the case of a single organization, the location of the RQA can to verify the certificates chain. Thus it is possible to provide be provided via DHCP or via DNS SRV records as specified trust into applications by locally storing only certificates in the current PRQP draft. Other configurations based on from one trusted organization which provides the needed Peer-to-peer technologies [13] are also possible. TA in the application’s local store. This hybrid trust model could productively be used together with other Trust-Related When the id-ad-prqp-p7endorsedTA OID is present in the projects. PRQP request, the RQA will provide the client application with one (or more) pointer(s) to the available packages of An attempt to decouple the trust list from the applica- endorsed CAs. The client application will then proceed by tions is the TACAR (TERENA Academic CA Repository) retrieving the PKCS#7 object from the URL received from the project [21], started at the end of 2003. It aims to provide RQA. After verifying the signature on the PKCS#7 object, the a trusted repository to hold the appropriate root CA cer- application can safely import the list of TAs included in the tificates needed by applications. The collected certificates retrieved object. As all the certificates present in the PKCS#7 are those directly managed by the member National Re- object are issued by one single CA (the one that signed the search Networks (NRENs), or belonging to a national aca- data object), only a single trust decision is required from the demic PKI, or to non-profit research projects. As in our user. In the case that the issuing CA is already trusted by solution, this project aims to solve the cross-domain usage the application—eg., the user’s organization CA certificate nightmare of PKI. In particular, the TACAR project pro- or the application’s vendor certificate—no interaction with vides a certified process for gathering and verifying root- the user is actually required. However, we do recommend CA certificates, and publishes them in one easily download- that a simple dialog be presented to the user the first time able and importable trusted file. Therefore, as detailed in the TA package signed by a CA is actually downloaded from the next subsection of this paper, by integrating our hybrid a URL. trust model with the TACAR repository as a trusted source of root-CA certificates, it could be possible to enable inter- domain verification of all TACAR’s provided certificates. 6. CONCLUSIONS AND FUTURE WORK In this paper we described how Trust Anchor Management [10] Kelvin Yiu. 6th Annual PKI R&D Workshop, is a central point for PKI usability. We also explained some “Applications Driven PKI (It’s The Apps, Stupid!)”, of the current standardization activities within IETF and April 2007. in particular we discussed the possibilities offered by com- [11] Massimiliano Pala. PKI Resource Query Protocol bining PRQP and TAMP. We then focused the central part (PRQP). Internet-Draft, Experimental Track, June of the paper on how it is possible to enhance the usabil- 2008. ity of PKIs from a different point of view. In particular, [12] Massimiliano Pala and Sean W. Smith. AutoPKI: A we advocate that by adopting a more dynamic approach to PKI Resources Discovery System. In Public Key PKI services—in particular within browsers—both PKI and Infrastructure, 4th European PKI Workshop: Theory Application vendors can benefit from easier to use services and Practice, EuroPKI 2007, volume 4582. LLNCS, and more flexible infrastructure. In particular we detailed Springer-Verlag, June 2007. different approaches to link certification structures, differing [13] Massimiliano Pala and Sean W. Smith. PEACHES in their security properties, their scalability, their manage- and Peers. In 5th European PKI Workshop: Theory ment requirements, their implications on path construction and Practice, volume 5057, pages 223—238. Lecture and validation, and their dependencies on directory services. Notes in Computer Science, Springer Verlag, June Tests show that the hybrid model, which combines the flexi- EuroPKI 2008. bility of cross-certification with the ease of deployment typ- [14] Massimiliano Pala, Marius Marian, Natalia ical of the hierarchical trust model, is supported by many Moltchanova, Antonio Lioy. PKI past, present and available applications. The solution provided in this paper future. International Journal on Information Security, addresses also trust management issues by using the hybrid 5:18–29, January 2006. trust model to reduce the number of trust anchors needed [15] M. Pala, A. Lioy, M. Marian, and N. Moltchanova. by applications to just one. Still further investigation is The EuroPKI Experience. In Proceedings of the 1st required to better understand possibilities provided by the European Workshop on PKI, volume 3093, pages usage of this model. In particular our efforts are directed to 14–27, Berlin, Germany, June 2004. Springer-Verlag. integrate our trust management system with existing reali- ties (e.g. TACAR) to provide practical support in real life [16] R. Guida, R. Stahl, T. Bunt, G. Secrest, J. environments. We are currently in the process of deploying Moorcones. Deploying and Using Public Key RQA servers for all of the CAs participating in the TACAR Technology: Lessons Learned in Real Life. IEEE project. We believe that operational experience will be im- Security and Privacy, pages 67—71, September 2004. portant in validating the usability of this approach and its [17] R. Reddy, C. Wallace. Trust Anchor Management adoption in specific environments (e.g. research networks Requirements. Internet Draft: Informational, October and grid communities) where simple trust management of 2008. certificates and linking of isolated PKIs is required. We also [18] R. Rivest, A. Shamir, L. Adleman. A Method for hope that our work will provide valuable feedback for the Obtaining Digital Signatures and Public Key standardization of TAMP and provide a useful use-case to Cryptosystems. Communications of the ACM, 21 further promote the standardization of PRQP. (2):120—126, 1978. [19] Sean W. Smith. A Funny Thing Happened on the Way to the Marketplace. IEEE Security and Privacy, 7. REFERENCES 1 (6):74—78, November/December 2003. [1] EuroPKI Infrastructure. EuroPKI website. [Online] [20] Simson L. Garfinkel and Robert C. Miller. Johnny 2: http://www.europki.org. A User Test of Key Continuity Management with [2] GSI working group of the Global Grid Forum. [Online] S/MIME and Outlook Express. In Proceedings of the http://www.gridforum.org/2\_SEC/GSI.htm. 2005 symposium on Usable privacy and security, pages [3] The European Policy Management Authority for Grid 13—24, 2005. Authentication in e-Science. [Online] [21] TACAR Project. TERENA Academic CA Repository. http://www.eugridpma.org/. [Online]] http://www.tacar.org. [4] The International Grid Federation. [Online] [22] W. Diffie, M. Hellman. New directions in http://www.gridpma.org/. cryptography. IEEE Transactions on Information [5] Alma Whittenand and J. D. Tygar. Why Johnny Theory, IT-22 N.6:644—654, November 1976. Can’t Encrypt: A Usability Evaluation of PGP 5.0. In 8th USENIX Security Symposium, August 1999. [6] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280, May 2008. [7] Denise Anthony, James Kitts, Chris Masone, and Sean W. Smith. Technology and Trust. In Eastern Sociological Society Annual Meetings, Feb 2008. [8] T. Dierks and C. Allen. The TLS Protocol. Internet Engineering Task Force: RFC 2246, January 1999. [9] ISO/TC68/SC2. Certificate management for financial services – Part 1: Public key certificates. ISO 15782-1:2003, August 2003. Massimiliano Pala  Scott. A. Rea  Usable Trust Anchor Management Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Trust, Today  “Technical” Trust is achieved by building a path (chain) from the certificate to be verified up to a trust anchor  Trust Anchors are mostly represented by root (self-signed) CA certificates  Deployed Trust Models  Hierarchies (Easiest for Implementers)  Cross-Certification  Bridge-CAs  Trust Lists (Applications) Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Trust Anchors, today  The number of trust anchors built into ap- plications and Operating System is increas- ing and applications were not thought for such a large number (Yiu, Kelvin; Microsoft; 2007)  ~130+ in Firefox Store  ~150+ in OSX Store  ~280+ in XP Store  Level of awareness is very low among users Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Trust Anchors, today (cont.)  Some communities need more flexible Trust Anchor Management (TAM)  Computing Grids  Distribution of Affiliated Cas  Virtual Organizations Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Our Contribution  While waiting for TAMP to be standardized (IETF) … … … …  Usable TAM  Reduce the number of trust anchors built into applications  Ideally to just one  Based on “semi”-cross certification and PRQP integration  Support for deployed applications  Centralized TA management  Revocable set of Endorsed TAs Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Background  Path building process  How to Identify a certificate  Simple path building example  More details on path building process  AKID Extension & path building  The PKI Resource Query Protocol Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 How to identify a Certificate  To identify certificate “ ” Issuer( ) + serialNumber( )  To identify the issuer certificate of “ ” Issuer(Issuer()) + serialNumber(Issuer()) = Issuer() + serialNumber()  In root CAs where Issuer and Subject are the same: Issuer(Issuer( )) = Issuer( ) Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Path Building Process-1  To verify certificate  starting from a set of trusted certificates we need to:  Identify the issuer of  (i.e.,  )  Verify if  is trusted  If it is from the set of trusted certificates, ok  If it is not trusted repeat the process until a trus- ted or a root certificate is identified Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Path building & AKID-2 i. The AKID extension is absent – path building takes places by using Subject/Issuer coupling ii. The AKID extension is present and carries the keyIdentifier – path building takes places as (i.) and keyIdentifier contents are checked iii. The AKID extension is present and carries the authorityCertIssuer + authorityCertSerialNumber – path building takes place as (i.) plus the extension contents are checked iv. The AKID extension is present and carries both – path building takes place as (i.) plus extension contents are checked (both) Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 PRQP in a Nutshell CMC Gateway for CA1 is at http://.../../ Resource Query Authority Where is the CMC Gateway associated with CA1 PRQP defines the message format Client Application between a client (or OS) and a server Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Our Model  Trusting External PKIs  Including a single PKI  Extending the Model  Trusting Sub-CAs  The Final Model  Introducing the Auxillary CAs Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Trusting a single PKI Trusting Sub-CAs MyRoot Cert (X) ExtRoot Cert () Subject=X Subject= Issuer=X Issuer= Cross-Cert (Y) CA Cert () Subject=Subject() Subject= Issuer=Subject(X) Issuer=Subject() hash(pKey(X)) hash(pKey()) akid akid Serial(X) + Issuer(X) Serial() + Issuer() pKey(Y) = pKey() Subject=W Issuer=Subject() hash(pKey()) akid Serial() + Issuer() Cert to be verified (W) Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Trusting Sub-CAs  Certification Path W→Y→X  Cross certificate Y would be such as: subject(Y) = subject ()  Path Validation may fail (AKID content!)  Introducing the Auxillary CA Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Our Model-2 Application Support  Fits standard verification protocol  Supported and works out of the box on different OSes / Crypto Libs:  Windows Systems (XP/2003/Vista)  IE, Outlook  OpenSSL and OpenSSL based software  Konqueror, Kmail  Firefox / Thunderbird  Some exceptions... Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 SSL/TLS Connections & Sub CAs No link between the two path is present at this level Same public Key Server Certificate to be verified Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 PRQP and Hybrid Trust Model-1  PRQP provides a discovery system for endorsed Tas  Our model provides CA admins with simple certificate issuing / certificate revoking mechanisms for endorsedTAs  We extended the PRQP with a new OID for endorsedTA pointer id­ad­prqp­endorsedTA  PRQP server provides pointer(s) to PKCS#7 signed object(s) carrying the endorsed TAs Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 PRQP and Hybrid Trust Model-2 ORGA endorsedTAs PRQP Server Application Organization Mozilla CA endorsedTAs Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Achieved Results  No need of Trust Lists into Applications  One TA (or ApexTA) only  Central Management of Trust  Fingerprint verification of trusted certificates is actually (hopefully) performed  Trust Model Supported by existing applications  works out of the box on different OSes / Crypto Libs  Dynamic support via PRQP integration  endorsedTA Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Questions and Contacts  Dartmouth College pala@cs.dartmouth.edu  OpenCA madwolf@openca.org  Website http://www.openca.org/projects/prqpd http://www.openca.org/wiki/ Usable TAM – IDTrust 2009, Gaithersburg, MD, April 14-16 Advances in Browser  Security Anil Saldhana Anil.Saldhana@redhat.com About the speaker ● Lead Security Architect, JBoss Division, Red Hat ● Co­editor of W3C Web Security Context Specifica­ tion (http://www.w3.org/TR/wsc­ui/) – Targeted for Web User Agents (Browsers) Overview ● Worldwide browser market ● Topics for Browser Security ● Report Card for the various popular browsers ● W3C WSC­UI Specification ● Tips for secure browsing Worldwide Browser Market ● Microsoft IE – 67.55% ● Mozilla Firefox – 21.53% ● Apple Safari – 8.29% ● Google Chrome – 1.12% ● Opera – 0.7% Net Applications Report, Jan 2009 ● http://marketshare.hitslink.com/browser­market­share.aspx?qprid=1 Topics for Browser Security ● Security Indicators – Green Bar (EVCerts) – Padlock ● Security Architecture – Google Chrome ● Private Browsing ● Plugins ● Phishing and Web Site Vulnerabilities Security Indicators ● Extended Validation Certificates (EV Certs) – Special type of X509 Certificates ● Certificate Policies extension field (Issuer has a oid) – CA does extensive background checks on requester – Guidelines issued by CA/Browser Forum  Security Indicators – EV Certs ● CA process for EV Certs –  Verifying the legal, physical and operational exis­ tence of the entity – Verifying that the identity of the entity matches offi­ cial records – Verifying that the entity has exclusive right to use  the domain specified in the EV Certificate – Verifying that the entity has properly authorized the  issuance of the EV Certificate Security Indicators – EV Certs Security Indicators – Padlock ● Browser displays Padlock for a HTTPS site – Firefox 2 displays a YELLOW address bar. – FF3 dropped yellow bar – Tools ­> PageInfo – Opera displays a yellow bar along with the padlock Security Architecture ● Google Chrome – Two protection domains :  ● Browser Kernel with the OS and  ● Rendering Engine with limited privileges in a sandbox – HTML parsing, Javascript VM, DOM : rendering engine. ● Complex  + historical source of security vulnerabilities – Browser Kernel  ● Persistent Resources (Cookies/Password DB) ● OS interaction, user input, network access “The Security Architecture of the Chromium Browser”, http://crypto.stanford.edu/websec/chromium/chromium­security­architecture.pdf Security Architecture ● Google Chrome – Attacker cannot read/write user file system  ● No malware installation   – Two protection domains – one for user, one for web ● 70% of critical browser vulnerabilities avoided ● 30% cannot be avoided via sandboxing Private Browsing ● Temporary state where the browser stores no lo­ cal data – cookies, history ● Use cases – Researching a medical condition – Surprise vacation/party – Internet cafes : shared computers on hourly basis ● Apparently an heavily user demanded feature ● IE8, FF3.1, Opera, Google Chrome and Safari Plugins ● Typically plugins run outside of the browser  process with the full rights of the user. – Plugin crash should not crash the browser – Adobe Flash plugin needs to write flash cookies Phishing and Web Site  Vulnerabilities ● Phishing – User taken to a rogue site imitating a legitimate site – User enters private information (passwords) ● Web Site Vulnerabilities – Cross­site scripting (XSS) – Cross­site Request Forging (CSRF) ● Confused Deputy Attack against the browser – Header Injection ● HTTP headers generated dynamically based on user input Phishing and Web Site  Vulnerabilities ● Browsers maintain a malware list – WARN users when a site is from the list – IE8 scheduled to incorporate – Google shares its list with Firefox and Chrome ● Tracking Cookies – Browsers provide you options to disable 3rd party  cookies – Safari by default rejects 3rd party cooking  Report Card                                  IE           FF               Safari        Chrome         Opera EV Certs                     Y            Y                 Y                 Y                   Y   Padlock                       Y            Y                 Y                 Y                   Y Malware Blacklist      Y            Y                  Y                 Y                  Y Private Browsing       IE8          FF3.1            Y                 Y                  Y Parental Controls       Y           (via addons)    Y                N              (Mini) W3C WSC Specification ● W3C WSC Working Group – W3C, IBM, Mozilla, Opera, Google, Verisign, Oracle,  Wells Fargo etc – Mission: specify a baseline set of security context  information accessible to Web users, and practices for   secure and usable presentation of this information, to  enable users to come to a better understanding of the  context that they are operating in when making trust  decisions on the Web. ● Targeted for Web User Agents ● http://www.w3.org/TR/wsc­ui/ W3C WSC Specification ● Presentation of identity (of website) information ● Error indicators in security protocol ● Augmented Assurance Certificates (EV Certs) – Mandatory:  Organization (O) attribute of Subject ● Validated Certificates  (Known Trust Anchor) ● Mixed Content ● Bookmarking API, Software Installation ● Spec includes Use Cases and Threat Trees W3C WSC – Threat Trees ● Luring Attacks – User taken to a different site than what he believes ● Site Impresonation Attacks ● Cross Site Request Forgery ● Cross Site Scripting ● Network based eaves dropping – Session hijacking, credential stealing or private info Tips for Secure Browsing ● Microsoft Internet Explorer Tips (Source:MS) – Set your browser security to High  – Add safe websites to trusted sites – Block pop up windows  ● Avoids installation of malicious code Tips for Secure Browsing ● Websites with plugins containing peer to peer  technology may install software/viruses – Sites with plugins displaying International TV/sports ● Disable Javascript by default if possible. – NoScript firefox extension can enable it for trusted sites ● Lock down browser configuration based on policies ● Tracking Cookies  – Browser setting to disable auto cookie setting­>Block 3rd  party cookies Privacy-Preserving Management of Transactions’ Receipts for Mobile Environments Federica Paci Ning Shang Sam Kerr CS Department CS Department CS Department Purdue University Purdue University Purdue University West Lafayette, Indiana West Lafayette, Indiana West Lafayette, Indiana paci@cs.purdue.edu nshang@cs.purdue.edu skerr@cs.purdue.edu Kevin Steuer Jr Jungha Woo Elisa Bertino CS Department CS Department CS Department Purdue University Purdue University Purdue University West Lafayette, Indiana West Lafayette, Indiana West Lafayette, Indiana ksteuer@cs.purdue.edu wooj@cs.purdue.edu bertino@cs.purdue.edu ABSTRACT Keywords Users increasingly use their mobile devices for electronic privacy, transaction record, registrar transactions to store related information, such as digital receipts. However, such information can be target of sev- 1. INTRODUCTION eral attacks. There are some security issues related to M- commerce: the loss or theft of mobile devices results in a ex- The combined use of the Internet and mobile technolo- posure of transaction information; transaction receipts that gies (e.g. mobile devices, mobile and wireless communica- are send over WI-FI or 3G networks can be easily inter- tion) is leading to major changes in how individuals commu- cepted; transaction receipts can also be captured via Blue- nicate, conduct business transactions and access resources tooth connections without the user’s consent; and mobile and services. People are able to communicate anytime, any- viruses, worms and Trojan horses can access the transaction where with anyone. Technological advances as well as the information stored on mobile devices if this information is increased number of mobile applications have resulted in not protected by passwords or PIN numbers. Therefore, as- new additions in end-user equipment. Smart mobile devices suring privacy and security of transactions’ information, as are equipped with various communication technologies, such well as of any sensitive information stored on mobile devices as GSM/GPRS, 802.11-WLAN, Bluetooth, NFC and RFID is crucial. In this paper, we propose a privacy-preserving ap- chips as well as GPS for location awareness. Mobile devices proach to manage electronic transaction receipts on mobile today offer a broad spectrum of functions, including web devices. The approach is based on the notion of transaction browsers, operating systems (e.g Symbian), environments receipts issued by service providers upon a successful trans- (e.g., Java virtual machine) for running mobile applications, action and combines Pedersen commitment and Zero Knowl- and e-mail clients. edge Proof of Knowledge (ZKPK) techniques and Oblivious In such context, establishing mutual trust between users Commitment-Based Envelope (OCBE) protocols. We have and service providers is critical. A possible approach to developed a version of such protocol for Near Field Commu- establish trust is to view the transactions users have car- nication (NFC) enabled cellular phones. ried out in the past. The history of former transactions informs about users behavior, their ability and dispositions and thus helps to decide whom to trust. Yahoo! Auction, Categories and Subject Descriptors Amazon, eBay are examples of systems that rate both users K.6.5 [Management of Computing and Information and service providers based on their past interactions his- Systems]: [Security and protection] tory. Maintaining the history of users’ transactions and es- tablishing trust based on these transactions and other fac- tors is a complex task. An important component of any General Terms such solution is represented by systems managing receipts of Security transactions. By receipts we refer to information that char- acterizes a transaction, like the amount paid and the service provider with which the transaction was carried out. Managing transaction receipts on mobile devices is very Permission to make digital or hard copies of all or part of this work for challenging. On one hand, the sharing of information about personal or classroom use is granted without fee provided that copies are transactions should be facilitated among service providers. not made or distributed for profit or commercial advantage and that copies A customer should be able to disclose to a service provider a bear this notice and the full citation on the first page. To copy otherwise, to view of his/her past transactions with other service providers republish, to post on servers or to redistribute to lists, requires prior specific in order to get discounts or to prove good behavior over the permission and/or a fee. IDtrust ’09, April 14-16, 2009, Gaithersburg, MD Copyright 2009 ACM past. On the other hand, transaction receipts need to be 978-1-60558-474-4 ...$5.00. protected as they may convey sensitive information about a user and can be the target of attacks. Moreover, users 2. BASIC NOTIONS should be able to control which service provider has access In this section, we introduce the basic cryptographic no- to information about their past interactions. Assuring pri- tions on which our transaction receipts management ap- vacy and security of transactions’ receipts, as well as of any proach is based. sensitive information, in the context of mobile environments is further complicated by the fact that mobile devices are 2.1 Pedersen commitment not secure. Recent statistics [4] show that millions of lost The Pedersen Commitment scheme, first introduced in [10], or stolen mobile devices which store users’ sensitive data is an unconditionally hiding and computationally binding have been reported. In addition to loss or theft, there are commitment scheme that is based on the intractability of an increasing number of viruses, worms and Trojan horses the discrete logarithm problem.1 The scheme is originally target mobile devices. Moreover, current attacks against described with a specific implementation that uses a sub- Bluetooth and well-known WLAN and GPRS vulnerabili- group of the multiplicative group of a finite field. We re- ties show that it is very easy for attackers to compromise mark that this choice of implementation is not intrinsic to mobile devices [14]. Another issue is related to how ser- the Pedersen commitment scheme itself – it can be imple- vice providers determine whether users are trusted based mented with any suitable abelian groups, e.g., elliptic curves on their past transactions. Trust establishment should be a over finite fields. Therefore, we rewrite the Pedersen com- policy-driven process. Service providers should specify poli- mitment scheme in a more general language as follows. cies stating the conditions users’ transaction receipts must satisfy for a user to be trusted and/or to get a service with Pedersen Commitment favorable conditions. An example such a policy is that a Setup user can receive a discount if he/she has spent $50 or more. A trusted third party T chooses a finite cyclic group G of Thus an important requirement is the introduction of a pol- large prime order p so that the computational Diffie-Hellman icy language that allows service providers to express condi- problem 2 is hard in G. Write the group operation in G as tions against transaction receipts. multiplication. T chooses an element g ∈ G as a generator, To address such issues, we propose a policy-based ap- and another element h ∈ G such that it is hard to find the proach for the management of users transaction history on discrete logarithm of h with respect to g, i.e., an integer α mobile devices that provides: such that h = g α . T may or may not know the number α. T publishes G, p, g and h as the system’s parameters. 1. integrity, confidentiality and privacy of users transac- Commit tion information; The domain of committed values is the finite field Fp of p 2. selective and minimal disclosure of transaction infor- elements, which can be represented as the set of integers mation; Fp = {0, 1, . . . , p − 1}. For a party U to commit a value x ∈ Fp , it randomly chooses r ∈ Fp , and computes the 3. trust establishment based on transaction history. commitment c = g x hr ∈ G. Open Our approach allows a user to prove to a service provider U shows the values x and r to open a commitment c. The that he/she has performed a transaction satisfying a set of verifier checks whether c = g x hr . conditions by such service provider without revealing any in- formation about the transaction. The approach is based on 2.2 Zero-knowledge proof of knowledge (ZKPK) the notion of transaction receipts issued by service providers protocol upon a successful transaction. Our approach combines Ped- It turns out that in the Pedersen commitment scheme ersen commitment and Zero Knowledge Proof of Knowledge described above, a party U referred to as the prover, can (ZKPK) techniques and Oblivious Commitment-Based En- convince the verifier, V, that U can open a commitment velope (OCBE) protocols [6] to assure privacy of informa- c = g x hr , without showing the values x and r in clear. In- tion recorded in the receipts. We have developed a version of deed, by following the zero-knowledge proof of knowledge such an approach for Near Field Communication (NFC) [9] (ZKPK) protocol below, V will learn nothing about the ac- enabled cellular phones. A NFC device embedded in the cel- tual values of x and r. This ZKPK protocol, which works for lular phone is able to communicate not only with Internet Pedersen commitments, is an adapted version of the zero- via wireless connections but also with smart card readers. knowledge proof protocol proposed by Schnorr [12]. In addition, the cellular phone applications, referred to as MIDlets, can access the phone’s tag for reading and writing Zero-knowledge proof of knowledge (Schnorr proto- data. col) The rest of the paper is organized as follows. Section 2 As in the case of Pedersen commitment scheme, a trusted introduces the basic notions on which our approach is based. party T generates public parameters G, p, g, h. A prover Section 3 presents our privacy-preserving approach to man- 1 age transaction receipts; it introduces all key notions of our Let G be a (multiplicatively written) cyclic group of order q and let g be a generator of G. The map ϕ : Z → G, ϕ(n) = approach, including the notion of verification policy, and de- g n is a group homomorphism with kernel Zq . The problem scribes our protocols. Section 4 analyzes the properties of of computing the inverse map of ϕ is called the discrete our approach. Section 5 introduces the system architecture logarithm problem (DLP) to the base of g. whereas Section 6 discusses the implementation and reports 2 For a cyclic group G (written multiplicatively) of order q, experimental results. Section 7 overviews related work. Fi- with a generator g ∈ G, the Computational Diffie-Hellman nally, Section 8 concludes the paper and outlines some future Problem is the following problem: Given g a and g b for work. randomly-chosen secret a, b ∈ {0, . . . , q − 1}, compute g ab . U who holds private knowledge of values x and r can con- commitment c = g x hr . T sends x, r, c to Re, and sends c to vince a verifier V that U can open the Pedersen commitment Se.3 c = g x hr as follows. Interaction • Re makes a data service request to Se. 1. U randomly chooses y, s ∈ F∗p , and sends V the element • Based on this request, Se sends an equality predicate d = g y hs ∈ G. EQx0 ∈ P. 2. V picks a random value e ∈ F∗p , and sends e as a chal- • Upon receiving this predicate, Re sends a Pedersen lenge to U. commitment c = g x hr to Se. • Se randomly picks y ∈ F∗p , computes σ = (cg −x0 )y , 3. U sends u = y + ex, v = s + er, both in Fp , to V. and sends to Re a pair hη = hy , C = EH(σ)[M ]i, where M is the message containing the requested data. 4. V accepts the proof if and only if g u hv = d · ce in G. Open We use this protocol in Section 3.3.3 for proof of receipt Upon receiving hη, Ci from Se, Re computes σ ′ = η r , and ownership. decrypts C using H(σ ′ ). 2.3 OCBE protocols GE-OCBE Protocol The Oblivious Commitment-Based Envelope (OCBE) pro- Parameter generation tocols, proposed in [6], provide the capability of enforcing As in EQ-OCBE, T runs a Pedersen commitment setup pro- access control policies in an oblivious way. Three communi- tocol to generate system parameters Param = hG, g, hi, and cations parties are involved in OCBE protocols: a receiver outputs the order of G, p. In addition, T chooses another Re, a sender Se, and a trusted third party T. More pre- parameter ℓ, which specifies an upper bound for the length cisely, the OCBE protocols ensure that the receiver Re can of attribute values, such that 2ℓ < p/2. T also outputs decrypt a message sent by Se if and only if its committed V = {0, 1, . . . , 2ℓ − 1} ⊂ Fp , and P = {GEx0 : x0 ∈ V}, value satisfies a condition given by a predicate in Se’s access where control policy, while Se learns nothing about the committed GEx0 : V → {true, false} value. The possible predicates are comparison predicates =, 6=, >, ≥, < and ≤. is a predicate such that GEx0 (x) is true if and only if x ≥ x0 . The OCBE protocols are built with several cryptographic Commitment components: This step is the same as EQ-OCBE. T chooses an integer x ∈ V for Re to commit. T then randomly chooses r ∈ Fp , 1. The Pedersen commitment scheme. and computes the Pedersen commitment c = g x hr . T sends x, r, c to Re, and sends c to Se.4 2. A semantically secure symmetric-key encryption algo- Interaction rithm E , for example, AES, with key length k-bits. Let EKey [M ] denote the encrypted message M under the en- • Re makes a data service request to Se. cryption algorithm E with symmetric encryption key • Based on the request, Se sends to Re a predicate GEx0 ∈ Key. P. • Upon receiving this predicate, Re sends to Se a Peder- 3. A cryptographic hash function H(·) : {0, 1}∗ → {0, 1}k . sen commitment c = g x hr . When we write H(α) for an input α in a certain set, • Let d = (x − x0 ) (mod p). Re picks r1 , . . . , rℓ−1 ∈ we adopt the convention that there is a canonical en- P i ℓ−1 Fp , and sets r0 = r − 2 ri . If GEx0 (x) is true, coding which encodes α as a bit string, i.e., an element i=1 in {0, 1}∗ , without explicitly specifying the encoding. let dℓ−1 . . . d1 d0 be d’s binary representation, with d0 the lowest bit. Otherwise if GEx0 is false, Re randomly Given the notation as above, we summarize the EQ-OCBE P i ℓ−1 and GE-OCBE protocols, i.e., the OCBE protocols for = chooses dℓ−1 , . . . , d1 ∈ {0, 1}, and sets d0 = d− 2 di i=1 and ≥ predicates, respectively, in what follows. The OCBE (mod p). Re computes ℓ commitments ci = g di hri for protocols for other predicates can be derived and described 0 ≤ i ≤ ℓ − 1, and sends all of them to Se. in a similar fashion. The protocols are stated in a slightly Q ℓ−1 i different way than in [6], to better suit the presentation in • Se checks that cg −x0 = (ci )2 . Se randomly chooses this paper. i=0 ℓ bit strings k0 , . . . , kℓ−1 , and sets k = H(k0 k . . . k EQ-OCBE Protocol kℓ−1 ). Se picks y ∈ F∗p , and computes η = hy , C = Parameter generation Ek [M ], where M is the message containing requested T runs a Pedersen commitment setup protocol to generate data. For each 0 ≤ i ≤ ℓ − 1 and j = 0, 1, Se computes system parameters Param = hG, g, hi. T also outputs the σij = (ci g −j )y , Cij = H(σij ) ⊕ ki . Se sends to Re the order of G, p, and P = {EQx0 : x0 ∈ Fp }, where tuple hη, C00 , C01 , . . . , Cℓ−1 0 1 , Cℓ−1 , Ci. EQa0 : Fp → {true, false} 3 is an equality predicate such that EQx0 (x) is true if and only In an offline alternative, T can digitally sign c and sends x, r, c and the signature of c to Re. Then the validity of the if x = x0 . commitment c can be ensured by verifying T’s signature. Commitment In this way, after Se obtains T’s public key for signature T first chooses an element x ∈ Fp for Re to commit. T verification, no communication is needed between T and Se. 4 then randomly chooses r ∈ Fp , and computes the Pedersen Similarly, an offline alternative also works here. Open After Re receives the tuple hη, C00 , C01 , . . . , Cℓ−1 0 1 , Cℓ−1 , Ci from Se as above, Re computes σi = η , and ki = H(σi′ ) ⊕ Cidi , ′ ri ′ for 0 ≤ i ≤ ℓ − 1. Re then computes k′ = H(k0′ k . . . k kℓ−1 ′ ), and decrypts C using key k′ . LE-OCBE, the OCBE protocol for the ≤ predicates, can be constructed in a similar way as GE-OCBE. Other OCBE protocols (for 6=, <, > predicates) can be built on EQ-OCBE, GE-OCBE and LE-OCBE. All these OCBE protocols guarantee that the receiver Re Figure 1: A transaction receipt example can decrypt the message sent by Se if and only if the cor- responding predicate is evaluated as true at Re’s committed value, and that Se does not learn anything about this com- formation about the transaction such as the user identifier, mitted value. the identifier of the service provider, the item(s) bought, We remark that for certain applications, we can let Se the price paid for the item(s), the quantity, the date of the know whether Re’s committed value satisfies the specified transaction, and shipment and billing information. We de- predicate, by extending the OCBE protocols with one more note this type of information as transaction attributes. We step: Re shows to Se the decrypted message. We discuss consider only a subset of the possible attributes that can this in more details in Section 3.3.4. be associated with a transaction. The subset includes the user identifier, the service provider identifier, the category 2.4 Shamir’s secret sharing scheme to which the item bought belongs to, the item price and the Shamir’s (k, n) threshold scheme [13] is a method that date of the transaction because they are the more relevant divides a secret into n shares and allows the secret to be attributes to establish trust in the user. reconstructed if and only if any k shares are present. Here k We assume that service providers have a PKI infrastruc- and n are both positive integers and k ≤ n. It is also called ture that allows them to issue users signed transaction re- Shamir’s secret sharing scheme. ceipts. In particular, we assume that each service provider The scheme works as follows. A trusted party, T, chooses is associated with a pair of keys (KP riv , KP ub ) where KP riv a finite field Fp of p elements, with p large enough. Let is the private key used to sign the transaction receipts and the secret message S be encoded as an element a0 ∈ Fp . KP ub is the public key used by other service providers to ver- T randomly chooses k − 1 elements a1 , . . . , ak−1 ∈ Fp , and ify authenticity and integrity of receipts. In order to support constructs a degree k − 1 polynomial f (x) = a0 + a1 x + . . . + a privacy-preserving proof of the possession of such receipts, ak−1 xk−1 ∈ Fp [x]. T chooses n elements α1 , α2 , . . . , αn ∈ the transaction receipts released under our protocol include Fp , and creates the secret shares Si as pairs the transactions’ attributes in clear and their correspond- ing Pedersen commitment. The Pedersen commitments of a Si = (αi , f (αi )), 1 ≤ i ≤ n, transaction attributes are used by a user to prove the pos- where f (αi ) is the polynomial evaluation of f at αi . Given session of the receipt of this transaction to other service any subset of k such shares, the polynomial f (x), of degree providers. To compute the Pedersen commitments of the k − 1, can be efficiently reconstructed via interpolation (see, transaction attributes, the service provider runs the Ped- e.g., [5], Section 2.2). The secret S, encoded as the constant ersen commitment setup protocol described in Section 2.2 coefficient a0 , is thus recovered. to generate the parameters Param = hG, g, hi. Then, the Shamir’s (k, n) threshold scheme has many good proper- service provider publishes G, p, g and h and its public key ties. Most prominently, it is information theoretically se- KP ub . cure, in the sense that the knowledge of less than k shares The structure of transaction receipts is defined as follows. gives no information about the secret S better than guess- ing; and it is minimal, in that the size of each share does Definition 3.1 (Transaction receipt). Let SP be a not exceed the size of the secret. Interested readers can refer service provider and B be a user with which SP has suc- to [13] for more details. cessfully carried out a transaction T r. Let (G, p, g, h,KP ub ) be the public parameters of SP. The receipt for transaction T r carried out by B and SP is a tuple hTRAN-ID, ATTR, 3. PROTOCOLS FOR THE RECEIPTS MAN- COM, SIGi, where TRAN-ID is the transaction identifier; AGEMENT ATTR is the set of transaction attributes {BUYER, SELLER, Our approach is based on the notion of transaction receipts CATEGORY, PRICE, DATE} where 1) BUYER is the user that are issued by service providers to users upon a success- identifier, 2) SELLER is the service provider’s identifier, 3) ful transaction. In the following sections, we first introduce CATEGORY is the selling category of the item being bought, the notion of transaction receipts, the policy language used 4) PRICE is the price of the item and DATE is the date of by service providers to specify conditions against transac- the transaction, respectively; COM is the set of the Peder- tion receipts, and then the privacy-preserving protocol that sen commitments of the attributes in ATTR. Each element allow a user to prove the possession of transaction receipts in COM is a tuple of the form hA, COMMITi where A is the verifying the service provider policies. value of an attribute in ATTR and COMMIT is the Peder- sen commitment g A hr of A and r is a secret known only to 3.1 Transaction Receipts B. SIG is the signature of service provider SP on COM5 . A service provider, upon the completion of a transaction, 5 In what follows, we will use the dot notation to denote the usually sends the user a receipt that specify a set of in- different components of transaction receipt. Example 3.1. Suppose that John Smith has bought for 1. Integrity verification of Receipts Attributes. The $ 30 a book from “BookStore.Com” on the 4th of Novem- user sends a transaction receipt to a service provider ber 2008. A receipt for this transaction, issued according to to satisfy the service provider verification policy. The our protocol, is h “1234”, (“John Smith”, BookStore.Com”, service provider verifies the signature on the transac- “Books”, “$ 30”, “11-04-2008”), (hBUYER, 45785687994674i, tion receipt sent by the user to prove the satisfiability hCATEGORY, 76553940894i,hPRICE,2223422262i, hDATE, of service provider’s verification policy. 58300242341i), 1375350748530-50356376037i (see Figure 1). 2. Secret Sharing on the Mobile Phone. The user 3.2 Verification Policy Language reconstructs the secret r that has been used to com- Service providers usually evaluate users based on previ- pute the transaction attribute commitments. Remem- ous transaction interactions with service providers. Based ber that r has been split for better protection from on users’ historical transactions, service providers are able unauthorized accesses. to determine whether a user can be trusted and whether 3. Proof of Receipt Ownership. The user proves he/she can be qualified to gain some benefits such as a dis- he/she is the owner of the transaction receipt by carry- count or rebate. Service providers define policies, referred ing out a zero-knowledge proof of knowledge protocol to as verification policies, to specify the conditions against with the service provider. attributes which are recorded in transaction receipts. Verification policies are formally defined as follows. 4. Verification of Conditions on Receipts. The ser- Definition 3.2 (Term). A Term is is an expression vice provider verifies that the transaction receipt at- of the form Name(attribute list) where: Name is the name tributes satisfy its verification policy by carrying out of a service or discount or an item, whereas attribute list is an OCBE protocol with the user. a possible empty set of attribute names characterizing the In the following sections, we describe the details of each service. phase of the protocol. Definition 3.3 (Attribute Condition). An attribute 3.3.1 Integrity Verification of Receipts Attributes condition Cond is an expression of the form: “nameA op l”, where nameA is the name of a transaction attribute A, op This phase starts when a user makes a request to a service is a comparison operator such as =, <, >, ≤, ≥, 6=, and l provider and the service provider sends the user the corre- is a value that can be assumed by attribute A. sponding verification policy R ← Cond1 , Cond2 , . . . Condn , n ≥ 1. First the user selects a transaction receipt T r Example 3.2. Examples of policies conditions are the fol- that satisfies such policy. Then, the user sends the ser- lowing: vice provider T r.COM, T r.SIG, T r.ATTR.SELLER, and the identifier of the service provider which has issued T r. • SELLER = “BookStore.Com” The service provider retrieves the public key KP ub of the • DATE < “11-04-2008” service provider that has issued T r to be able to verify the signature T r.SIG. • PRICE > $ 80 3.3.2 Secret Sharing on the Mobile Phones Definition 3.4 (Verification Policy). A verification In order for a user to be able to carry out ZKPK and policy Pol is an expression of the form “R ← Cond1 , Cond2 , OCBE protocols with the service provider, the user needs . . . Condn”, n ≥ 1, where R is a Term and Cond1 , Cond2 , the random secret r, used to compute the Pedersen commit- . . . Condn are attribute conditions. ments of a transaction receipt’s attributes. The security of the protocols strongly depends on r so it is necessary to pro- Given a transaction receipt T r and a verification policy tect it from unauthorized access that can occur on mobile Pol : R ← Cond1 , Cond2 , . . . Condn , n ≥ 1, if for each devices. Mobile device security can be compromised if the Condi ∈ Pol, (ii) ∃ Ā ∈ T r.ATTR such that nameĀ = device is lost or stolen, or due to the vulnerabilities of the Cond.nameA and valueĀ satisfies Cond.(nameA op l), we communication network and/or the device software. To pre- say that T r satisfies Pol, denoted as T r ⊲ Pol. vent these security threats, we adopt Shamir’s secret sharing Example 3.3. An example of verification policy is the scheme that allows one to split a secret in n shares and then following: Pol : Discount(OnItem =“Glamour”, Amount=“$ to reconstruct it if and only if k shares are present. The 15”) ← SELLER = “BookStore.Com”, PRICE > “$ 80 ”, storage of the shares depends on the specific architecture of DATE < “11-04-2008”. The policy states that a user is the mobile devices. Next we will focus on the Nokia NFC qualified for a $ 15 discount on an yearly subscription to mobile phones that we have used in our implementation. Glamour magazine, if the user has spent more than $ 80 at In our implementation the shares are stored on different “BookStore.Com” before “11-04-2008’. mobile phone components and (possibly) on external devices such as a PC or a an external storage unit. We split each ran- 3.3 Protocol to Manage Transaction Receipts dom secret into four shares s1 , s2 , s3 and s4 . The first share The privacy-preserving protocol proves the possession of s1 is stored in the internal memory of the mobile phone. The a transaction receipt and is carried out between a user and a second share s2 is further split into two secrets. A user cho- service provider. The protocol consists of four main phases sen PIN number P and a number P ′ are selected such that (see Figure 2): 6 P ⊕ P ′ = s2 • P ′ is stored in the phone external memory. 6 In what follows we use the term ‘user’; however in practice The third share s3 is stored in the smart card integrated the steps are carried out by the client software transparently in the phone. Finally the fourth secret share s4 is stored to the actual end user. in the user’s PC which has to be accessed remotely by the Figure 2: Approach schema phone. We consider four levels of protection for the secret r according to the level of protection set up by the user needs that correspond to the number k of shares that are needed to be retrieved and then combined to obtain r. to reconstruct r. The possible levels of protection are low, medium, medium-high and high. The level of protection low Example 3.4. Suppose that John Smith has to prove the requires no splitting of the secret r. In this case, r is stored possession of receipt h “1234”, (“John Smith”, BookStore.Com”, in the phone smart card. The medium level corresponds to “Books”, “$ 30”, “11-04-2008”), (hBUYER, 45785687994674i, a value of k equal to 2. In this case the user has to retrieve hCATEGORY, 76553940894i,hPRICE,2223422262i, hDATE, two of the four shares s1 , s2 , s3 and s4 to obtain the secret r. 58300242341i),137535074853050356376037i to service provider If the medium-high level is chosen, three shares are needed “Borders”. In order to accomplish that, John needs to recon- while with level of protection high, all the four shares are struct the secret r used to compute the Pedersen commit- needed to reconstruct the secret. The level of protection is ments contained in the receipt. John sets the security level set by the user7 once the issuer of a transaction receipt sends for r to high and to retrieve each secret share he has to the user the random secret r along with the transaction re- perform the following steps: ceipt containing the Pedersen commitments computed using r. Once set, the level of protection cannot be changed by 1. John retrieves s1 from the phone internal memory. the user. When the user has to prove the ownership of the trans- 2. To retrieve s2 , John inputs the secret PIN number P action receipt sent to the service provider, the r needs to using the phone keypad. P ′ is retrieved from the phone be reconstructed. In order to do that, a number of shares external memory and it is used to compute the second secret share s2 = P ⊕ P ′ . 7 The specification of the security level and the entering of the PIN are the only steps that need to be carried by the 3. John retrieves the secret s3 from the phone smart card. actual end-user. The security level can however be set as a default and the end-user does not need to enter it each time 4. To retrieve the secret share s4 stored at the user’s PC, it receives a new receipt. John connects to its PC by using the phone SELLER attribute to Se. Se chooses the message M , as de- scribed in Section 2.3, to be the content of service (e.g., a coupon code). Then, it composes the envelope using the corresponding attribute value in the received receipt for M , and sends it to Re. Re can open the envelope if and only if the involved attribute value on the receipt satisfies the con- dition specified in the policy, but Se will not know if Re can open the envelope. In the second scenario, the service provider needs to know the result of the condition verification, i.e., it should be in- formed if the attributes on the user’s receipt satisfies the specified policy. There are many instances of such a scenario. For example, the service provider may require its policy be satisfied by a user’s receipt in order to continue the trans- actions. In this case, for user privacy protection, the OCBE protocol for equality predicates, EQ-OCBE, should not be employed, because the service provider will be able to infer Figure 3: Random Secret Reconstruction the attribute value if the verification is successful. However, other OCBE protocols which are for inequality predicates By contrast if John sets up a medium security level, he has can still be used, with one more step appended to the pro- to retrieve only two shares to obtain the secret r. For ex- tocol, described next. ample, John can decide to get the shares s1 and s3 from the In this additional step, the service provider acts as the phone’s internal memory and the phone smart card respec- sender Se, and the user acts as the receiver Re. The service tively without having to insert any PIN number (see Figure provider chooses the message M to be a random bit string, 3). which will be used as a secret of Se. The OCBE protocol for inequality predicates is executed between Se and Re, based on Se’s policy and the involved attribute value recorded in 3.3.3 Proof of Receipt Ownership Re’s receipt, for this secret M . At the end of the proto- Once the user has reconstructed the random secret r, the col, after opening the envelope, Re shows Se the decrypted proof of the ownership of the transaction receipt can be message M ′ . The attribute on the receipt passes Se’s verifi- achieved by engaging a ZPK protocol for the BUYER trans- cation if M = M ′ , or fails if otherwise. The service provider action attribute with the service provider. According to the continues with the transactions in the former case, or aborts ZPK protocol, the user randomly picks y, s in {1, .., p}, com- the transaction in the latter case. Such additional step has putes d = g y hs , where g and h are the public parameters of been added to the OCBE protocols, to allow the service the service provider. The user then sends d to the service provider to learn the result of the verification, at the user’s provider. Once received d, the service provider sends back will. Since the random bit string M contains no useful infor- a random challenge e ∈ {1, .., p − 1} to the client. Then mation about the service content itself, a qualified user must the user computes u = y + em and v = s + er where m is choose to show the correctly decrypted secret message M , in the value of the BUYER transaction attribute and r is the order to continue the transactions with the service provider. random secret, and sends u and v to the service provider. In this sense, the extended OCBE protocols (for inequality The service provider accepts the aggregated zero knowledge predicates) works as a zero-knowledge proof scheme for our proof if g u hv = dce . Otherwise, the interaction with the application. user is dropped. In both scenarios, if the user’s receipt’s attributes need to satisfy multiple conditions in the service provider’s policy, 3.3.4 Verification of Conditions on Receipts a run of the OCBE protocol must be performed for each condition. A receipt’s attributes satisfy the conditions in the We consider two scenarios that require the verification of policy if and only if the user can open all related envelopes. conditions on transaction receipts. In the first scenario, a service provider provides a general service to all qualified users, and does not require to know the outcome of the trans- 4. PROTOCOL ANALYSIS action. For example, a book store may provide a transfer- In this section we analyze the security properties of our able 10%-off coupon code to any user who presents a receipt transaction receipts management protocol. showing a purchase of a product in the “Books” category. Our protocol is built on provably secure cryptographic However, the book store does not care whether this coupon protocols: digital signature scheme, Shamir’s secret sharing code is successfully received by the user; it only cares that scheme, Pedersen commitment, Schnorr’s zero-knowledge proof a coupon code is valid when being used. The book store protocol, and OCBE protocols. simply rejects a receipt if it is shown twice, to prevent a After a user sends a service request to a service provider user from taking advantage of this offer for multiple times. and receives a policy, he/she selects a transaction receipt T r, In such a scenario, the OCBE protocols, (cfr. Section 2.3) and sends back T r.COM, T r.SIG and T r.ATTR.SELLER, can be used directly. Let the user be the receiver Re, and i.e., the receipt’s parts containing Pedersen commitments, the service provider be the sender Se. Re sends a service receipt issuer (seller)’s signature on these commitments and request to Se, and Se responds with its verification policy. the identity of the issuer, respectively. On one hand, since Based on the policy, Re selects a receipt T r which satisfies the service provider verifies the issuer’s signature on the Ped- Se’s policy, and sends T r.COM, T r.SIG, and the value of ersen commitments, it is guaranteed that the Pedersen com- Figure 4: System architecture mitments have not be modified. Thus, the integrity of the tees the integrity and the privacy of the information included Pedersen commitments is assured. On the other hand, the in a transaction receipt and it also protects users against service provider does not learn anything about the actual identity theft. values of the transaction attributes. This is due to the un- conditionally hiding property of the Pedersen commitment. If the user passes the first step above, he/she starts to 5. SYSTEM ARCHITECTURE reconstruct the secret exponent r, which is used to prove We have implemented our protocol on Nokia 6131 NFC [3] the ownership of a receipt and the verification of conditions mobile phones. NFC enabled devices are gaining popular- on receipts, from some of the shares s1 , s2 , s3 and s4 us- ity because they provide easy-to-use mechanisms for ubiq- ing Shamir’s (k, n) threshold scheme. The number of shares uitous accesses to systems and services. Based on a short- needed for the reconstruction depends on the pre-defined range wireless connectivity, the communication is activated level of protection. Since the shares are distributed at dif- by bringing two NFC compatible devices or tags within a ferent locations, and protected by a PIN number, this makes few centimeters from one another. it hard for a party other than the receipt owner to obtain all The system architecture is shown in Figure 4. It consists needed shares to recover r. Furthermore, since the Shamir’s of three main components: a service provider application, threshold scheme is information theoretically secure, unless an external NFC reader and the Nokia 6131 NFC [3] mobile enough shares are collected, any attempt to recover the se- phone. The core architectural component is the NFC mobile cret r is not easier than guessing. phone. It consists of an Antenna, for detecting external tar- Once the secret r is reconstructed, the user carries out a gets such as tags, external readers, or other Nokia 6131 NFC zero-knowledge proof protocol for the BUYER attribute, in mobile phones; an NFC modem, for providing the capability a manner like Schnorr’s as described in Section 3.3.3, with to send and receive commands between antenna, secure ele- the service provider. The user is able to convince the service ment and phone firmware including J2ME environment; a provider that he/she knows how to open the commitment, Secure element, for enabling third-party application de- only if he/she knows the values of both x and r such that the velopment using tag/card emulation; Phone firmware, for corresponding commitment is computed as g x hr . It prevents providing mobile phone functions with NFC features; a SIM an entity who steals a valid receipt but does not know how card, for GSM subscription identification and service man- to open the asked commitment in the receipt from authenti- agement; J2ME environment included in phone firmware, for cating with the service provider. Due to the zero-knowledge enabling third-party application development using Nokia property of the protocol, the service provider does not learn 6131 NFC features; and an External memory. the attribute value x for BUYER. The Secure element within Nokia 6131 NFC can store The last step of our protocol is the execution of the OCBE information securely, which can be used for payment and protocols for the verification of the conditions on the receipt ticketing applications or for access control and electronic attribute values. The OCBE protocols guarantee that a user identifications. Secure element is divided into two sub- can correctly retrieve a message, randomly chosen by the ser- components, Java Card area (also referred to as smart card) vice provider, if and only if the user knows how to open the and Mifare 4K area. Mifare 4K area can be considered as commitments whose committed values satisfy the conditions a memory with access control, and typically it is simpler (equality or inequality) in the service provider’s policy, while to implement than a smart card application. Mifare 4K the service provider learns nothing about the actual values contains data, whereas smart card application contains an of the transaction attributes. executable program. Java Card provides high security en- Based on the above considerations, our protocol guaran- vironment and executes code, which means it can be used for more complex applications. Therefore, we store in the Java Card some of the shares in which the random secret r vide implementation of the BigInteger and SecureRandom is split because of the high security provided by Java Card. classes. In addition, because of the limited memory size Secure element is accessible through NFC modem internally of mobile phones, we reduced the MIDLet’s code size by us- from MIDLets and externally by external readers. MIDLets ing code obfuscation techniques provided by Sun’s NetBeans are Java applications running in the J2ME environment. In IDE. Code obfuscation allows one to reduce a file size by re- the next section we describe in details, how we have imple- placing all Java packages and class names with meaningless ment our protocol to manage receipts by using MIDLets. characters. For example, a file of a size of 844KB can be The NFC reader enables the communication between the reduced to a size of 17KB. service provider application and the mobile phone. It trans- We have also implemented the service provider component mits and receives messages from the NFC cellular phone. as a web application using Java and the Apache Tomcat Ap- The service provider application consists of five main mod- plication Server. The current implementation of the Ver- ules: Request Manager, Message Handler, ZKPK, Receipt ification module only supports the EQ-OCBE and GE- Issuance and Verification. The Request Manager module OCBE protocols for the verification of equality conditions parses users requests and selects from a local repository the and inequality conditions expressed by using the ≥ compar- verification policy that applies to the request. The Message ison operator. We are extending the implementation with Handler module provides all functions supporting the com- support for other comparison operators. munications between the service provider application and We have performed several experiments to evaluate the the external NFC reader. The ZKPK module supports the execution time of the MIDLet and the service provider (SP verification of receipts’ integrity and the ZKPK protocol to for short) application for the proof of the receipt ownership verify the BUYER attribute. The Receipt Issuance mod- and the verification of conditions (equality and inequality) ule provides the functions for creating a transaction receipt, against receipts. We have collected data about the execu- such as the generation of the Pedersen commitments and tion times for verifying the equality conditions on receipts the signature of the commitments. Once created, the trans- and the time for verifying the inequality conditions by using action receipts are stored in a local repository. The Veri- respectively EQ-OCBE and GE-OCBE protocols by vary- fication module supports the steps for the verification of ing the value of parameter ℓ from 5 to 20. ℓ determines the conditions on receipts described in Section 3.3.4. number of commitments ci = g di hri , 0 ≤ i ≤ ℓ − 1 that the user has to send to the service provider to prove he/she satisfies an inequality condition in service provider policy. 6. IMPLEMENTATION AND EXPERIMEN- The experiment compares the envelope creation time at TAL EVALUATION the service provider’s side, and the envelope opening time at the MIDLet’s side, which are the most computationally ex- To evaluate the performance of our protocol, we have de- pensive part for both protocols. We also record the time re- veloped a prototype version of the system. We have imple- quired for generating the additional Pedersen commitments mented a MIDLet that supports the integrity verification of ci in GE-OCBE at the MIDLet’s side. No additional com- receipts attributes, the proof of receipt ownership and the mitment needs to be generated by the user in EQ-OCBE. verification of conditions against receipts. The implementa- We do not include the communication time and the sym- tion of the secret sharing phase is under development. metric encryption time in the comparisons, which vary with We store users’ transaction receipts in the external phone different network settings and plaintext lengths, in order to memory, whereas the secret r used to compute the secure focus on the main operations of the protocols. We also do commitments included in the receipts is saved in the Java not include the signature verification time in the compari- Card component. The execution of the MIDLet is triggered son, for the same reason. when the Mifare 4K captures the verification policy sent by In the experiment, we have executed the verification pro- the service provider’s external NFC reader and the Mifare tocol both at the service provider’s side and at the MIDLet 4K transfers such policy to the phone main memory. The size, for 10 times, and we have computed the average of the MIDLet retrieves from the external memory a transaction obtained values. receipt that satisfies the service provider policy and sends the part of the receipt containing the transaction attributes commitments, the signature affixed on the commitments, Verification of Receipt Ownership and the value of SELLER attribute to Mifare 4K so that MIDLet 0.042 can be read by the service provider’s external NFC reader. SP’s 0.0311 If the service provider application successfully verifies the Application signature on the receipts commitments, the MidLet retrieves the secret r from the Java Card, and performs the other Table 1: Average time (in seconds) to verify the steps of the receipts management protocol. ownership of a receipt at MIDLet’s side and at SP’s The MIDLet runs on Java 2 Micro Edition (J2ME). Since side J2ME is aimed at hardware with limited resources, it con- tains a minimum set of class libraries for specific types of hardware. In our implementation on conventional non-mobile platforms, we used the BigInteger and SecureRandom class, defined in J2SE java.math and java.security packages respec- tively, to implement secure commitments, but both pack- ages are not supported in J2ME. Therefore, we have used Table 1 shows the execution times taken by the verification the third-party cryptography provider BouncyCastle [2], a of receipt ownership phase at MIDLet side and at the SP lightweight cryptography APIs for Java and C# that pro- application side. Commitments Opening Total Creation Envelope Execution Time Equality 0 1.126 1.126 Condition Inequality 5.875 6.088 11.963 Condition (≥) Table 2: Verification of conditions’ execution time (in seconds) at MIDLet’s side (ℓ = 5) Envelope Creation Equality 0.0409 Condition Inequality 0.165 Condition (≥) Table 3: SP’s application’s average execution time (in seconds) for verifying one condition (ℓ = 5) Table 2 and Table 3 report the average verification of con- ditions’ execution time taken, respectively, by the MIDLet and by the SP application for a value of parameter ℓ equal to 5. When multiple conditions are to be verified, the execu- tion time increases accordingly, as the protocol is repeated for multiple rounds. As expected, the execution time to verify inequality conditions takes more time than the verifi- cation of equality conditions. In fact, the GE-OCBE used to verify inequality condition with comparison predicate ≥, re- quires the MIDLet and the SP application to perform more interactions steps. Figure 5 shows the SP application’s ex- Figure 5: SP Application’s Envelope Creation Time ecution time to create the envelope according to GE-OCBE varying the value of parameter ℓ protocol while Figure 6 shows the time taken by the MI- DLet to open the envelope. In both cases, we have varied the value of ℓ parameter from 5 to 20. The graphs show how the value of parameter ℓ dramatically impacts on verifica- tion of conditions’ execution time. With the increasing of the ℓ parameter values, the execution time linearly increases. The verification time increases because when ℓ parameter in- creases, the SP application has to compute an higher number of σij = (ci g −j )y , Cij = H(σij ) ⊕ ki to be sent to the MIDLet running on user’s mobile phone and the MIDLet to decrypt the envelope has to compute an higher number of σi′ = η ri , and ki′ = H(σi′ ) ⊕ Cidi , for 0 ≤ i ≤ ℓ − 1. Therefore, in the implementation of our protocol, the pa- rameter ℓ must be kept as small as possible in order to reduce the computational cost. We expect other OCBE protocols for inequality predicates to give performance results similar to those of GE-OCBE, because the design and operations are similar. Figure 6: MIDLet’s Envelope Opening Time varying the value of parameter ℓ 7. RELATED WORK Commerce Transaction Manager only guarantees confiden- In this section, we compare our approach with other ap- tiality by encrypting the messages exchanged between the proaches for mobile transactions managements. service provider application and the application running on With the advent of high-speed data networks and feature- the phone. In our approach by using digital signatures, Ped- rich mobile, the concept of mobile wallet [8, 1] has gained ersen commitment, ZKPK techniques and OCBE protocols, importance. The ESPRIT project CAFE [1] has introduced we are able to guarantee both privacy and integrity of trans- the notion of electronic wallet, that is a small portable de- actions information. vice which manages off-line digital payments to be used in Finally, MeT initiative [7] has the goal to develop secure commercial transactions. The electronic wallet transacts via and easy methods and platforms for conducting e-commerce a short range infrared channel either directly with compliant transactions on mobile phones. The strategy for MeT is cash registers and wallets held by other individuals, or over to base the framework on existing standards such as WAP, the Internet, to merchants’ tills or service points provided Wireless Transport Layer Security (WTLS), Wireless Iden- by banks and other organizations. The electronic wallet re- tification Module (WIM), Public Key Infrastructure (PKI) lies on a blind signature scheme to guarantee privacy and and Bluetooth. Privacy and security are ensured with digital unlinkability for the electronic payment information while signatures and cryptography services for transaction verifi- our approach preserves only the privacy of transactions in- cation, confidentiality, authentication, and non-repudiation. formation. Mjolsnes et al. [8] have proposed a version of the elec- 8. CONCLUSIONS tronic wallet for online payments. The authors exploits a We have proposed a privacy preserving approach to man- credential server, denoted as credential keeper that securely age electronic transaction receipts on mobile devices. We stores the credentials issued to a user by different issuers. have focused on such type of device because we believe that The credentials represents the wallet of the user. The user in the near future users will conduct business transactions to access his/her credentials at the credential keeper and and access resources and services mostly using their mobile provide them to a service provider, has to present an access phones and PDAs. However, we have also implemented a credential, e.g. a symmetric key, to the keeper server. To in- web-based version of our receipt management system. crease even more security, the access credential is encrypted Our approach is based on the notion of transaction receipt, and protected within a mobile device, and it can only be that records the information characterizing a transaction, activated by using a PIN code or some other authentication and combines Pedersen commitment, ZKPK techniques and method. In our approach we do not need a third component OCBE protocols. We have implemented our approach on to guarantee a secure storage and management of the infor- Nokia 6131 NFC mobile phones and have evaluated its per- mation included in a transaction receipt. The receipts can be formance of on these devices. The experimental results show securely stored on the phone external memory because the that our protocol is quite efficient in verifying equality con- values of the transaction attributes are not stored in clear ditions on receipts; however we need to improve the perfor- but they are substituted by their Pedersen commitments. mance of the inequality conditions’ verification. We believe The Secure Electronic Transaction (SET) [11] protocol that the reasons for the high execution times when verify- was developed to allow credit card holders to make trans- ing inequality conditions are the limited computational ca- actions without revealing their credit card numbers to mer- pability of Nokia 6131 NFC mobile phones and the use of chants and also to assure authenticity of the parties. SET the BouncyCastle API that are not natively supported by deploys dual signature for merchant and payment gateway. these phones. We plan to test our protocol on the Nokia Each party can only read a message designated for itself 6212 NFC mobile phones that support JSR-177 Security since each message is encrypted for a different target. To and Trust APIs. These APIs provide security services to enable this feature, card holders and merchants must reg- J2ME enabled devices without the need of using Bouncy- ister with a Certificate Authority before they exchanging Castle API’s. Since these API’s are natively supported by a SET message. SET assures both confidentiality and in- these kind of phones, we believe that our protocols should tegrity of the messages among card holders, merchants and perform better on such phones. We are currently completing payment gateway whereas our protocol is designed to as- the implementation of our prototype system by developing a sure integrity and privacy of transactions information. SET MIDLet supporting the secret sharing phase of our protocol. authenticates the identity of the cardholder and the mer- We plan to complete the implementation of service provider chant to each other because both are registered with the application’s Verification module in order to support the same certificate authority. However, our protocols do not verification of inequality conditions containing the compar- mandate this requirement. SET is considered to have failed ison predicates <, > and 6=. because of its complexity. It requires cardholders and mer- chants to register in advance and get X.509 certificates to make transactions whereas the users need not to have such 9. ACKNOWLEDGMENTS PKI certificate in our protocol. In our approach only service This material is based in part upon work supported by providers need to have a PKI certificate. the National Science Foundation under the ITR Grant No. More recently, Veijalainen et al. [15], propose an approach 0428554 “The Design and Use of Digital Identities”, by the to manage transaction on mobile devices. Their solution is AFOSR grant A9550-08-1-0260, and by the U.S. Depart- based on the use of an application running on the phone de- ment of Homeland Security under Grant Award Number noted as Mobile Commerce Transaction Manager that pro- 2006-CS-001-000001, under the auspices of the Institute for vides the functionalities to start, terminate and resume a Information Infrastructure Protection (I3P) research pro- transaction with a service provider. With respect to se- gram. The I3P is managed by Dartmouth College. The curity and privacy of transactions information, the Mobile views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the U.S. Department of Homeland Security, the I3P, or Dartmouth College. 10. REFERENCES [1] J-P Boly, A. Bosselaers, R. Cramer, R. Michelsen, S. Fr. Mjolsnes, F. Muller, T.P. Pedersen, B. Pfitzmann, P. de Rooij, B. Schoenmakers, M. Schunter, L. Vallee, and M. Waidner. The ESPRIT project CAFE - high security digital payment systems. In ESORICS, pages 217–230, 1994. [2] Bouncy Castle Crypto APIs. http://www.bouncycastle.org/. [3] Nokia Forum. Nokia 6131 NFC Technical Description. http://www.forum.nokia.com. [4] Help for lost and stolen phones. http://news.bbc.co.uk/1/hi/technology/4033461.stm. [5] W. Gautschi. Numerical Analysis: An Introduction. Birkhauser Boston Inc., Cambridge, MA, USA, 1997. [6] J. Li and N. Li. OACerts: Oblivious attribute certificates. IEEE Transactions on Dependable and Secure Computing, 3(4):340–352, 2006. [7] Met initiative. http://www.mobiletransaction.org. [8] S.F. Mjolsnes and C. Rong. Localized credentials for server assisted mobile wallet. ICCNMC’01: International Conference on Computer Networks and Mobile Computing, 00:203, 2001. [9] Near Field Communication Forum. http://www.nfc-forum.org. [10] T.P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In CRYPTO ’91: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology, pages 129–140, London, UK, [11] SET- Secure Electronic Transaction specification book 1: Business description, 1997. 1992. Springer-Verlag. [12] C-P Schnorr. Efficient identification and signatures for smart cards. In CRYPTO ’89: Proceedings of the 9th Annual International Cryptology Conference on Advances in Cryptology, pages 239–252, London, UK, 1990. Springer-Verlag. [13] A. Shamir. How to share a secret. Commun. ACM, 22(11):612–613, 1979. [14] TechRepublic. Identify and reduce mobile device security risks. http://articles.techrepublic.com.com/5100-22 11- 5274902.html. [15] J. Veijalainen, V. Y. Terziyan, and H. Tirri. Transaction management for m-commerce at a mobile terminal. Electronic Commerce Research and Applications, 5(3):229–245, 2006. Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Privacy-Preserving Management of Transactions’ Receipts for Mobile Environments Federica Paci, Ning Shang, Sam Kerr, Kevin Steuer Jr., Jungha Woo, Elisa Bertino Purdue University April 15, 2009 1 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Offline Shopping 2 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Online Shopping 3 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation How Can Receipts Help? 4 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Receipts Can Help Establish transaction-history-based trust Facilitate services such as discounts/promotions 5 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Challenge in e-Commerce: Receipt Management Customer needs to get e-receipts from offline stores Customer needs to show online transactions to offline stores Privacy & security 6 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Solution: M-Commerce and Cryptography Customer-SP communications Cell phones (NFC) Privacy-preserving management & proofs Digital signatures Zero-knowledge proof of knowledge (ZKPK) Oblivious commitment-based envelope (OCBE) Shamir’s secret sharing scheme 7 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation System Architecture 8 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Near Field Communication (NFC) Technology Courtesy http://www.nfc-forum.org 9 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Near Field Communication (NFC) Technology Courtesy http://www.nfc-forum.org 10 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Nokia 6131 NFC Phone Architecture 11 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Receipt Format Public Param = hG , p, g , hi Pedersen commitment (COM): c = g attr-value hr 12 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Integrity Verification: Digital Signatures Service provider verifies digital signature accord- ing to “SELLER” attribute in receipt. Options which allow signature aggregation Batch RSA signatures Fast Good if there is only one signer Boneh’s aggregate signatures with bilinear maps (elliptic curve pairings) Good for case of multiple signers Slower than batch RSA 13 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Ownership Proof: ZKPK Service provider performs a ZKPK protocol with user (phone) on “BUYER” attribute in receipt. ZKPK can convince SP that user knows the values name and r (authentication) prevent SP from learning the values name and r in clear text (privacy) 14 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK (Schnorr’s Scheme) Public Param = hG , p, g , hi secret r c = g name hr 15 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK (Schnorr’s Scheme) Public Param = hG , p, g , hi s yh d =g .c , (1) secret r c = g name hr 15 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK (Schnorr’s Scheme) Public Param = hG , p, g , hi s yh d =g .c , ∈F p (1) e dom e ran secret r ng c = g name hr c halle . (2) 15 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK (Schnorr’s Scheme) Public Param = hG , p, g , hi s yh d =g .c , ∈F p (1) m e ·r rando s +e secret r ge ,v = a l l en m e c = g name hr . ch e· na (2) + y 3) .u = ( 15 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK (Schnorr’s Scheme) Public Param = hG , p, g , hi s yh d =g .c , ∈F p (1) m e ·r rando s +e (4) accepts if secret r ge ,v = a l l en m e g u hv = dc e c = g name hr . ch e· na (2) + y 3) .u = ( 15 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Strong Protection of Secret Value: Shamir’s Secret Sharing (n, k)-threshold scheme n = 4, k = 2/3/4 (security level L/M/H ) Secret value r can be re- constructed only if k shares are present 16 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Verification of Conditions: OCBE Protocols Service provider performs OCBE protocols with user (phone) to verify whether user satisfies con- ditions on attributes specified in policy OCBE can convince SP that user’s attribute values satisfy conditions given by comparison predicates (authentication) prevent SP from learning user’s attribute values in clear text (privacy) 17 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Verification of Conditions: Policy Language Verification Policy Language: Example Pol : Discount(OnItem =“Glamour”, Amount=“$15”) ← SELLER = “bookstore.com”, PRICE > “$80”, DATE < “11-04-2008.” The policy states that a user is qualified for a $15 discount on an yearly subscription to Glamour magazine, if the user has spent more than $80 at “bookstore.com” before the date “11-04-2008”. 18 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi secret r c = g ctgry hr E, H 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi ) , H (· ,E Q x0 . E (1) secret r c = g ctgry hr E, H 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi ) , H (· ,E Q x0 . E (1) . c secret r (2) c = g ctgry hr E, H 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi ) , H (· ,E Q x0 . E (1) . c R secret r (2) (3). y ← Fq , c = g ctgry hr σ = (cg −x0 )y E, H 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi ) , H (· ,E Q x0 . E (1) pon ] . c c ou R secret r (2) (σ )[ (3). y ← Fq , c = g ctgry hr C = EH σ = (cg −x0 )y h , y = . η (4) E, H 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation EQ-OCBE: Equality Predicates (Li & Li) Public Param = hG , p, g , hi ) , H (· ,E Q x0 . E (1) pon ] . c c ou R secret r (2) (σ )[ (3). y ← Fq , c = g ctgry hr C = EH σ = (cg −x0 )y h , y = . η (4) E, H (5). σ ′ = η r , decrypts C with H(σ) to get coupon 19 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation GE-OCBE: “≥” Predicates (Li & Li) GE-OCBE Similar to EQ-OCBE bit-by-bit fashion More computationally costly than EQ-OCBE parameter ℓ controls capacity and efficiency Other OCBE protocols are similar. 20 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Protocol Overview 21 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation ZKPK Performance Time for receipt ownership verification via ZKPK Customer MIDLet: 0.042 second Service Provider Application: 0.0311 second 22 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation OCBE Performance on Service Provider 23 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation OCBE Performance on NFC Phone Nokia 6131: ARM-9 228 MHz, JVM Interpreter (JBenchmark estimate) 24 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation VeryIDX Framework The VeryIDX IdM Team at Purdue http://veryidx.cs.purdue.edu 25 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation Acknowledgements The I3P Consortium The CERIAS of Purdue University 26 Presented by N. Shang Privacy-Preserving Receipt Management Receipt Management Introduction Privacy-Preserving Receipt Management Solution Implementation The End Questions? nshang@cs.purdue.edu 27 Presented by N. Shang Privacy-Preserving Receipt Management Quantum Resistant Public Key Cryptography: A Survey Ray A. Perlner David A. Cooper ray.perlner@nist.gov david.cooper@nist.gov National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20899–8930 ABSTRACT cal identity-based encryption schemes [5] as well as pairing- Public key cryptography is widely used to secure transac- based short signatures [6]. tions over the Internet. However, advances in quantum com- While both the integer factorization problem and the gen- puters threaten to undermine the security assumptions upon eral discrete logarithm problem are believed to be hard in which currently used public key cryptographic algorithms classical computation models, it has been shown that nei- are based. In this paper, we provide a survey of some of ther problem is hard in the quantum computation model. the public key cryptographic algorithms that have been de- It has been suggested by Feynman [16] and demonstrated veloped that, while not currently in widespread use, are be- by Deutsch and Jozsa [13] that certain computations can be lieved to be resistant to quantum computing based attacks physically realized by quantum mechanical systems with an and discuss some of the issues that protocol designers may exponentially lower time complexity than would be required need to consider if there is a need to deploy these algorithms in the classical model of computation. A scalable system ca- at some point in the future. pable of reliably performing the extra quantum operations necessary for these computations is known as a quantum computer. Categories and Subject Descriptors The possibility of quantum computation became relevant E.3 [Data]: Data Encryption—Public key cryptosystems to cryptography in 1994, when Shor demonstrated efficient quantum algorithms for factoring and the computation of General Terms discrete logarithms [51]. It has therefore become clear that a quantum computer would render all widely used public Algorithms, Security key cryptography insecure. While Shor demonstrated that cryptographic algorithms Keywords whose security relies on the intractability of the integer fac- Quantum computers, public key cryptography torization problem or the general discrete logarithm prob- lem could be broken using quantum computers, more recent research has demonstrated the limitations of quantum com- 1. INTRODUCTION puters [47]. While Grover developed a quantum search algo- Since its invention, public key cryptography has evolved rithm that provides a quadratic speedup relative to search from a mathematical curiosity to an indispensable part of algorithms designed for classical computers [24], Bennet, our IT infrastructure. It has been used to verify the au- Bernstein, Brassard, and Vazirani demonstrated that quan- thenticity of software and legal records, to protect financial tum computers cannot provide an exponential speedup for transactions, and to protect the transactions of millions of search algorithms, suggesting that symmetric encryption al- Internet users on a daily basis. gorithms, one-way functions, and cryptographic hash algo- Through most of its history, including present day, public rithms should be resistant to attacks based on quantum com- key cryptography has been dominated by two major families puting [4]. This research also demonstrates that it is unlikely of cryptographic primitives: primitives whose security is be- that efficient quantum algorithms will be found for a class lieved to be contingent on the difficulty of the integer factor- of problems, known as NP-hard problems, loosely related to ization problem, such as RSA [46] and Rabin-Williams [44, both search problems and certain proposed cryptographic 55], and primitives whose security is believed to be contin- primitives discussed later in this paper. gent on the difficulty of the discrete logarithm problem, such The above research suggests that there is no reason, at the as the Diffie-Hellman key exchange [14], El Gamal signa- moment, to believe that current symmetric encryption and tures [19], and the Digital Signature Algorithm (DSA) [17]. hash algorithms will need to be replaced in order to protect Also included within the second family is elliptic curve cryp- against quantum computing based attacks. Thus, any effort tography (ECC) [32, 40], which includes all known, practi- to ensure the future viability of cryptographic protocols in the presence of large scale quantum computers needs to con- centrate on public key cryptography. Given how vital public key trust models are to the security architecture of today’s This paper is authored by employees of the U.S. Government and is in the public domain. Internet, it is imperative that we examine alternatives to the IDtrust ’09, April 14-16, 2009, Gaithersburg, MD currently used public key cryptographic primitives. ACM 978-1-60558-474-4 In this paper, we provide an overview of some of the public encryption does not use and therefore cannot leak in- key cryptographic algorithms that have been developed that formation about the private key, and protocols can are believed to be resistant to quantum computing based almost always be designed to prevent the decryptor attacks. The purported quantum-resistance of these algo- from revealing information about his or her private rithms is based on the lack of any known attacks on the key. This can be done by encrypting symmetric keys cryptographic primitives in question, or solutions to related rather than the content itself, using integrity protec- problems, in the quantum computation model. This does tion, and reporting decryption failures in a way that not mean that an attack will never be found, but it does makes them indistinguishable from message authenti- yield some confidence. The same type of argument is used cation code (MAC) failures. This type of behavior is to justify the security of all but a handful or cryptographic currently necessary for secure protocols using old RSA primitives in the classical computation model. One-time padding schemes, and is often considered good practice pads [50, 53] and universal hash functions [8] are uncondi- regardless of the key transfer mechanism. tionally secure in any computation model, if used properly, but they are usually impractical to use in a way that doesn’t • Computational cost: There are four basic public key invalidate the proof. Other cryptography often comes with operations: encryption, decryption, signing, and signa- a “security proof,” but these proofs are generally based on at ture verification. On today’s platforms, with currently least one unproved security assumption—virtually any proof used algorithms, these operations generally take a few of security in the classical or quantum computation model milliseconds, except for RSA encryption and signature not based on an unproved assumption would resolve one of verification, which can be about 100 times faster due to the best known unsolved problems in all of mathematics [10]. the use of small public exponents. Key generation time Section 2 lists some of the issues that should be considered may also be a concern if it is significantly more expen- in comparing public key cryptographic algorithms. Section 3 sive than the basic cryptographic operations. Factor- describes a one-time signature scheme known as Lamport ing based schemes such as RSA and Rabin-Williams signatures, and Section 4 describes techniques that have tend to have this problem, as generation of the two been developed for creating long-term signature schemes high entropy prime factors requires several seconds of from one-time signature schemes. Section 5 covers public computation. key cryptographic algorithms based on lattices. Section 6 describes the McEliece signature and encryption schemes. 3. LAMPORT SIGNATURES Other potential areas of research are mentioned in Section 7 The basic idea behind Lamport signatures [33] is fairly and Section 8 discusses issues that may need to be considered simple. However, there is a wide variety of performance by protocol designers if one or more of the public key cryp- tradeoffs and optimizations associated with it. It derives its tographic algorithms described in this paper become widely security strength from the irreversibility of an arbitrary one- used at some point in the future. way function, f . f may be a cryptographic hash function, although the scheme is secure even if f is not collision resis- 2. GENERAL CONCERNS tant. The Lamport scheme is a one-time signature scheme. A number of factors can be considered when examining In order for the scheme to be secure, a new public key must the practicality of a public key cryptographic algorithm. be distributed for each signed message. Among these are: In the simplest variant of Lamport signatures, the signer generates two high-entropy secrets, S0,k and S1,k , for each • Lengths of public keys, key exchange messages, and bit location, k, in the message digest that will be used for signatures: For public key cryptographic algorithms signatures. These secrets (2n secrets are required if the di- commonly in use today, these are all roughly the same gest is n bits long) comprise the private key. The public key size, ranging from a few hundred to a few thousand consists of the images of the secrets under f , i.e., f (S0,k ) and bits, depending on the algorithm. This is not always f (S1,k ), concatenated together in a prescribed order (lexi- the case for candidate quantum-resistant algorithms. cographically by subscript for example). In order to sign If public keys, key exchange messages, or signatures a message, the signer reveals half of the secrets, chosen as are much larger than a few thousand bits, problems follows: if bit k is a zero, the secret S0,k is revealed, and if it can be created for devices that have limited memory is one, S1,k is revealed. The revealed secrets, concatenated or bandwidth. together, comprise the signature. While the act of signing a message clearly leaks information about the private key, • Private key lifetime: A transcript of signed messages it does not leak enough information to allow an attacker to often reveals information about the signer’s private sign additional messages with different digests. Nonetheless, key. This effectively limits the number of messages there is no way in general for the signer to use this type of that can safely be signed with the same key. The public key to safely sign more than one message. most extreme example of this is the Lamport signa- While conceptually the simplest, the above scheme is not ture scheme, discussed below, which requires a new the most efficient way to create a one-time signature scheme key for each signed message. Methods have been de- from a one-way function [20]. Firstly, the size of public keys veloped for creating a long-term signature scheme from and signatures can be reduced by nearly a factor of two, a short-term or even single-use signature scheme, but merely by using a more efficient method of choosing which these often require extra memory for managing and secrets to reveal from a smaller pool. For each bit location, storing temporary keys, and they tend to increase the k, rather than creating two secrets, S0,k and S1,k , the se- effective length of signatures. Private keys used for de- cret key may consist of only S0,k , with the public key being cryption do not generally have limited lifetime, since f (S0,k ). In order to sign a message, the signer would reveal Digest Counter Digest 6 3 F 1 E 9 0 B 3 D Signature f 6 (S0 ) f 3 (S1 ) f (S3 ) f 14 (S4 ) f 9 (S5 ) S6 f 11 (S7 ) f 3 (S8 ) f 13 (S9 ) Public Key f 15 (S0 ) f 15 (S1 ) f 15 (S2 ) f 15 (S3 ) f 15 (S4 ) f 15 (S5 ) f 15 (S6 ) f 15 (S7 ) f 15 (S8 ) f 15 (S9 ) Figure 1: A Sample Lamport Signature with b = 16 H0−7 = h(H0−3 k H4−7 )  PP  PP   P P H0−3 = h(H01 k H23 ) H4−7 = h(H45 k H67 ) @ @ @ @ H01 = h(H0 k H1 ) H23 = h(H2 k H3 ) H45 = h(H4 k H5 ) H67 = h(H6 k H7 ) @ @ @ @ @ @ @ @ H0 = h(K0 ) H1 = h(K1 ) H2 = h(K2 ) H3 = h(K3 ) H4 = h(K4 ) H5 = h(K5 ) H6 = h(K6 ) H7 = h(K7 ) Figure 2: Merkle Hash Tree S0,k for each bit position, k, in the message digest that has consists of eight hexadecimal digits. a value of zero. Thus, the signature would be the concate- Analysis of the performance of Lamport’s one-time signa- nation of S0,k for each bit location in the message digest tures is somewhat prone to confusion. As discussed above, that has a value of zero. The problem with this scheme is the performance is dependent upon the choice of a one-way that an attacker could try to change the value of a signature function and on the value of the base, b, used in generat- by withholding some of the S0,k values, thus changing some ing the public key. Further, as the scheme is a one-time of the zero bits to one. In order to protect against this, a signature scheme the distinction between signing time and binary encoding of the total number of zero bits in the mes- key generation time is not terribly useful, although it does sage digest may be appended to the message digest. This provide a lot of opportunities for a signer to do precompu- counter would be signed along with the message digest as tation. Nonetheless, with a fairly reasonable set of assump- described above. Since an attacker could only try to change tions (e.g., f = SHA-256 with b = 4) one arrives at signa- zero bits to one, the attacker could not reduce the value of ture, verification, and key generation times that are similar the counter, which would be necessary to successfully change to current schemes such as DSA. some of the zero bits to one in the message digest itself. The sizes of signatures and public keys can also be traded off against computation by using hash chains. In such a 4. LONG-TERM SIGNING KEYS FOR ONE- scheme, the message digests would be encoded using digits TIME SIGNATURE SCHEMES with a base b that is greater than two (e.g., using hexadeci- If the signer can precompute a large number of single- mal digits, which would correspond to b = 16). To sign the use, public key - private key pairs, then at little additional kth digit of the digest, Nk , the private key would be Sk , cost, these keys can be used to generate signatures that can the public key would be the result of applying a one-way all be verified using the same public key [36]. Moreover, function, f , to the secret b − 1 times, f b−1 (Sk ), and the sig- the long-term public key associated with this scheme need nature value would be f Nk (Sk ).1 Thus if b were 4 and Nk only be the size of a message digest. To do this, we use hash were 1, then public key would be f 3 (Sk ) = f (f (f (Sk ))) and trees, a technique invented by Ralph Merkle in 1979 [35]. At the signature value would be f 1 (Sk ) = f (Sk ). As with the the bottom of the tree, the one-time public keys are hashed binary scheme, there would be a need to append a “counter” once and then hashed together in pairs. Then those hash to the message digest in order to prevent an attacker from values are hashed together in pairs, and the resulting hash increasing the values of any digits in the message digest. The values are hashed together and so on, until all the public value of the counter toP be appended to the digest, for an n keys have been used to generate a single hash value, which digit digest, would be n−1 k=0 (b − 1 − Nk ). The reduction in will be used as the long-term public key. In this scheme, signature size is logarithmic in the value of the base, while the signer can prove that a one-time public key was used in the cost of generating a one-time key pair is linear, so this the computation that generated the long-term public key by process reaches diminishing returns fairly quickly, but using providing just one hash value for each level of the tree—the a base of 16 is often better than a base of 2. Figure 1 shows overhead is therefore logarithmic in the number of leaves in an example of a Lamport signature for a message digest that the tree. Figure 2 depicts a hash tree containing eight single-use 1 As with the binary scheme above, the signer would not public keys. The eight keys are each hashed to form the need to reveal the signature value for any digit k for which leaves of the tree, the eight leaf values are hashed in pairs Nk = b − 1. to create the next level up in the tree. These four hash values are again hashed in pairs to create H0−3 and H4−7 , to lattices are the shortest vector problem (SVP) [1] and which are hashed together to create the long-term public the closest vector problem (CVP) [52]. Given an arbitrary key, H0−7 . In order for an entity to verify a message signed basis for a lattice, SVP and CVP ask the solver to find the using K0 , the signer would need to provide H1 , H23 , and shortest vector in that lattice or to find the closest lattice H4−7 in addition to K0 and a certified copy of H0−7 . The vector to an arbitrary non-lattice vector. In both the quan- verifier would compute H0′ = h(K0 ), H01 ′ = h(H0′ k H1 ), tum and classical computation models, these problems are ′ ′ ′ ′ H0−3 = h(H01 k H23 ), and H0−7 = h(H0−3 k H4−7 ). If believed to be hard for high dimensional lattices, contain- ′ H0−7 is the same as the certified copy of H0−7 , then K0 ing a large number of vectors close in length to the shortest may be used to verify the message signature. lattice vector. While the the number of additional hashes that need to be Of the various lattice based cryptographic schemes that added to a public key grows logarithmically with the number have been developed, the NTRU family of cryptographic al- of leaves in the tree, the cost of generating a hash tree is gorithms [25, 26, 27] appears to be the most practical. It linear in the number of leaves. It may therefore be desirable has seen some degree of commercial deployment and effort to limit the size of hash trees. If the signer wishes to use has been underway to produce a standards document in the a single public key to sign more messages than the number IEEE P1363 working group. NTRU-based schemes use a of single-use key pairs he or she is willing to generate in the specific class of lattices that have an extra symmetry. While process of generating a public key, then the signer may wish in the most general case, lattice bases are represented by an to use a certificate chain like construction where the longest n × n matrix, NTRU bases, due to their symmetry, can be term public key is used to sign a large number of shorter- represented by an n/2 dimensional polynomial whose coeffi- term keys, which in turn are used to sign even shorter term cients are chosen from a field of order approximately n. This keys and so on. The advantage of this is that short-term keys allows NTRU keys to be a few kilobits long rather than a few can be generated as needed, allowing the cost of generating megabits. While providing a major performance advantage, new one-time keys to be distributed over the lifetime of the the added symmetry does make the assumptions required single long-term key. This technique can also be used for for NTRU-based schemes to be secure somewhat less natu- other signature schemes where the key has limited lifetime, ral than they would otherwise be, and many in the theory not just those that are based on hash trees. One example is community tend to prefer schemes whose security follows NTRUSign, which is discussed later in this paper. more directly from the assumption that lattice problems are One important point to note is that unlike current signa- hard. Such schemes include schemes by Ajtai and Dwork [2], ture schemes, this scheme is not stateless. The signer needs Micciancio [39], and Regev [45]. to keep track of more than just a single long-term private In all NTRU-based schemes, the private key is a polyno- key in order to sign messages. If the signer is using hash mial representing a lattice basis consisting of short vectors, trees, the signer can save a lot of memory by using a pseu- while the public key is a polynomial representing a lattice dorandom number generator to generate one-time private basis consisting of longer vectors. A desirable feature of keys from a seed and a counter rather than saving all of the NTRU and other lattice based schemes is performance. At one-time private keys in memory. The one-time private keys equivalent security strengths, schemes like NTRU tend to are large and are only used twice: once for the purpose of be 10 to 100 times faster than conventional public key cryp- generating the hash tree, and again when the one-time pri- tography, with cryptographic operations taking about 100 vate keys are needed to sign messages, so this makes fairly microseconds on contemporary computing platforms. good sense. The hashes in the tree, however, are used more A number of minor attacks have been discovered against often, and they should therefore be saved in memory. If NTRUEncrypt throughout its 10+ year history, but it has these management techniques are used, then the footprint for the most part remained unchanged. Improvements in of a signing module does not suffer terribly from the short lattice reduction techniques have resulted in a need to in- lifetime of the underlying signature scheme, but the dynamic crease key sizes somewhat, but they have remained fairly nature of the stored information does imply that read-only stable since 2001. NTRUEncrypt has also been found to be or write-once memory cannot be used to store it. vulnerable to chosen ciphertext attacks based on decryption failures [18, 21, 31, 38], but a padding scheme [30], which has provable security against these attacks, has been developed. 5. LATTICE BASED CRYPTOGRAPHY AND In addition to security concerns, the recommended parame- NTRU ter sets for NTRUEncrypt have been changed for perfor- mance reasons. In one case, this was done over-aggressively Unlike Lamport signatures, most public key cryptographic and this resulted in a security vulnerability that reduced the schemes derive their security from the difficulty of specific security of one of the parameter sets from 80 bits to around mathematical problems. Historically, factorization and the 60 [29]. discrete logarithm problem have been by far the most pro- A comparatively greater number of problems have been ductive in this respect, but as previously noted, these prob- found in NTRU-based signature schemes. The first NTRU- lems will not be difficult if full scale quantum computers are based signature scheme, NSS [28], was broken in 2001 by ever built. Therefore, cryptographers have been led to in- Gentry, Jonsson, Stern, and Szydlo a year after its publi- vestigate other mathematical problems to see if they can be cation [22]. A new scheme called NTRUSign [25] was in- equally productive. Among these are lattice problems. troduced in 2002, based on the Goldreich-Goldwasser-Halevi An n-dimensional lattice is the set of vectors that can be signature scheme [23]. In this scheme, the signer maps the expressed as the sum of integer multiples of a specific set of n message digest to a vector, and proves knowledge of the pri- vectors, collectively called the basis of the lattice—note that vate key by finding the nearest lattice point to that vector. there are an infinite number of different bases that will all Since the set of vectors to which a given lattice point is the generate the same lattice. Two NP-hard problems related nearest is non-spherical, it was known that a large number padding the message digest. However, since most strings of messages signed with the same key would leak informa- will not decrypt, the signer will typically have to try thou- tion about the private key. Because of this, the original sands of different paddings before finding a string that will signature scheme included an option, called perturbation, decrypt. As a result, signing times are on the order of 10 to that would allow the signer to systematically choose a lat- 30 seconds. It is, however, possible to make the signatures tice point which was not necessarily the closest lattice point, reasonably short. but which was still closer than any point that could be found without knowledge of the private key. In 2006, it was shown 7. OTHER AREAS OF RESEARCH by Nguyen that the unperturbed NTRUSign could be bro- ken given only 400 signed messages [42]. The developers of In addition to hash based signatures and lattice based NTRUSign estimate that with perturbation, it is safe to and code based cryptography, a number of additional ap- use the same NTRUSign key to sign at least one billion proaches have been used as an alternative basis for public messages [54], but recommend rolling over to a new signing key cryptography [7]. While most of the resulting schemes are currently poorly understood or have been broken, it is key after 10 million signatures [43]. still possible that breakthroughs in these areas could one day lead to practical, secure, and quantum-resistant public 6. MCELIECE key schemes. An additional hard problem that has been used to con- One of the first NP-complete problems used in public struct public key schemes is the syndrome decoding prob- key cryptography was the knapsack problem. Merkle and lem, which asks the solver to correct errors that have been Hellman first proposed a knapsack based cryptosystem in introduced to an arbitrary, redundant linear transformation 1978 [37], but this was soon shown to be vulnerable to of a binary vector. There are, of course, easy instances of approximate lattice reduction attacks [49]. Many similar this problem, namely error correction codes, but in the gen- schemes were subsequently broken, with the last, Chor-Rivest eral case, this problem is known to be NP-hard. One of [9], being broken in 1995 [48]. the oldest of all public key cryptosystems, McEliece encryp- More complex algebraic problems have also been proposed tion [34], works by disguising an easy instance of the decod- as successors to the factoring and discrete logarithm prob- ing problem as a hard instance. The security of McEliece lems. These include the conjugacy search problem and re- therefore relies upon the presumed fact that it is difficult to lated problems in braid groups, and the problem of solving distinguish between the disguised easy code and an arbitrary multivariate systems of polynomials in finite fields. Both hard code. have been active areas of research in recent years in the The easy instance of the decoding problem used by McEliece mathematical and cryptographic communities. The latter is a family of error correction codes known as Goppa Codes. problem was the basis for the SFLASH signature scheme [12], An (n, k) Goppa code takes a k-bit message to an n-bit code which was selected as a standard by the New European word in such a way that the original message can be recon- Schemes for Signatures, Integrity and Encryption (NESSIE) structed from any string that differs from the code word at consortium in 2003 but was subsequently broken in 2007 [15]. fewer than t = (n − k)/ log2 (n) bits. There are approxi- It remains unclear when these or other algebraic problems mately nt /t such codes. To disguise the code, it is written will be well enough understood to produce practical pub- as an n×k matrix, then left-multiplied by an n-bit permuta- lic key cryptographic primitives with reliable security esti- tion matrix, and right multiplied by an arbitrary invertible mates. binary matrix. The resulting n×k binary matrix is the pub- lic key, while the three matrices used to generate it remain 8. CONSIDERATIONS FOR PROTOCOL DE- private. To encrypt a k-bit message, the encryptor treats the mes- SIGNERS sage as a binary vector, left-multiplies the public key, and In order to enable a comparison of the costs associated randomly changes t of the resulting n bits. The private key with various algorithms, Table 1 presents information about holder can then decode the message stepwise. First the pri- key sizes, message sizes, and the amount of time required vate key holder undoes the private permutation—this does to perform certain operations for several public key crypto- not change the number of errors. The errors can now be graphic algorithms. The table includes the algorithms that corrected using the private Goppa code, allowing the private are described in this paper that are believed to be quantum key holder to reconstruct the k-bit linear transformation of resistant (Lamport signatures, McEliece encryption and sig- the original message. Since the private linear transformation natures, NTRUEncrypt, and NTRUSign) as well as some used to construct the public key is invertible, the private key of the public key cryptographic algorithms commonly in use holder can now reconstruct the message. today that are vulnerable to Shor’s algorithm (RSA, DSA, McEliece has remained remarkably resistant to attack dur- Diffie-Hellman, and ECC). The numbers presented in the ta- ing its 30 year history, and it is very fast, requiring only a ble are rough estimates, not benchmark results, but should few microseconds for encryption and 100 microseconds for be sufficiently accurate to enable comparison of the strengths decryption on contemporary platforms. The primary draw- and weaknesses of the different algorithms. back is that in order for the scheme to be secure, n and k Compared to public key cryptographic algorithms com- need to be on the order of 1000, making the total size of the monly in use today, the algorithms presented in this paper public key about a million bits. differ in two ways that may be significant to protocol design- It was recently demonstrated by Courtois, Finiasz, and ers: key size and limited lifetime. Of the algorithms listed Sendrier that there was a corresponding signature scheme [11], in Table 1, limited key lifetime is only an issue for Lam- but this scheme is less desirable than the encryption scheme. port signatures and NTRUSign. In the case of these two To sign a message, the signer decrypts a string derived by algorithms, the limited lifetimes should not pose significant Table 1: A Comparison of Public Key Cryptographic Algorithms at the 80 Bit Security Level Estimated Time (PC) Public Key Private Key Limited Public Private Message Setup Operation Operation Lifetime? Key Size Key Size Size (ms) (ms) (ms) (kbits) (kbits) (kbits) Lamport Signature 1 1 1 1 signature ∼10 ∼10 ∼10 Lamport w/Merkle 1 1 1 240 signatures 0.08 ∼250 ∼50 McEliece Encryption 0.1 0.01 0.1 no 500 1000 1 McEliece Signature 0.1 0.01 20,000 no 4000 4000 0.16 NTRUEncrypt 0.1 0.1 0.1 no 2 2 2 30 NTRUSign 0.1 0.1 0.1 2 signatures 2 2 4 RSA 2000 0.1 5 no 1 1 1 DSA 2 2 2 no 2 0.16 0.32 Diffie-Hellman 2 2 2 no 2 0.16 1 ECC 2 2 2 no 0.32 0.16 0.32 problems, but more consideration will need to be used in bits of security [3]. For the McEliece algorithms, this would deploying these algorithms in order to ensure that keys are imply 1 megabit public encryption keys and 8 megabit public not used too many times. signature keys. With key sizes this large, the ways in which When Lamport signatures are used in conjunction with public keys are distributed must be carefully considered. Merkle hash trees as described in Section 4, the number of With many protocols in use today, it is common to in- signatures that may be created from a given long-term pub- clude a copy of the sender’s certificate(s) in the message. lic key is strictly limited, but that limit may be set to any For example, the server’s encryption certificate is usually value that the creator of the key chooses. If public keys have sent to the client during the key establishment phase of the expiration dates, as they do today, then the maximum can Transport Layer Security (TLS) protocol. Also, email clients always be set to a value that will ensure that the long-term typically include copies of the sender’s signature and encryp- public key will expire before all of the one-time keys have tion certificates in all digitally signed messages. Since most been used. Even a high volume server creating a few thou- public key certificates that have been issued are less than sand signatures a second would take several years to create 2 kilobytes, this is a reasonable practice at the moment, 240 signatures. For most key holders, the maximum num- as the amount of bandwidth wasted by sending a copy of ber of signatures per long-term public key could be set at a a certificate to a recipient that has previously received a much smaller value, which would allow for smaller private copy is minimal. However, if the need to switch to quan- keys and signatures. tum resistant algorithms were to lead to the use of public The situation with NTRUSign is less clear since there key cryptographic algorithms with key lengths comparable is no fixed limit on the number of times that a key may to those required by the McEliece signature and encryption be used. While the developers of NTRUSign recommend schemes, this practice would need to be avoided and other rolling over keys after 10 million signatures in order to be means would need to be used to ensure that relying parties conservative, they believe that a key may be safely used to could obtain copies of the public keys that they need. sign at least a billion messages [43]. For most key hold- The most straightforward solution to this problem would ers, even a limit of 10 million signatures would not be an be to avoid sending certificates in protocol messages, ex- issue. For some high volume servers, however, obtaining a cept in cases in which the recipient has requested a copy new key pair and certificate after every 10 million signatures of the certificate. Instead, the protocol message could in- would be unreasonable, whereas a new certificate could be clude a pointer to the certificate, which could be used by obtained after every billion signatures if the process were au- the recipient to obtain a copy of the certificate if it does not tomated and relatively fast. If NTRUSign is to be used in already have a copy in its local cache. For privacy reasons, the future, and further research indicates a need to impose many organizations prefer not to place end user certificates key lifetimes that are closer to 10 million signatures than to in publicly accessible directories. However, if the directories 1 billion signatures, then high volume servers may need to that hold certificates are not searchable and the URLs that employ one of the techniques described in Section 4 in order point to the certificates are not easily guessable, this should to reduce the frequency with which new certificates need to provide an adequate amount of privacy protection. be obtained. An alternative solution would be to not include a copy Table 1 shows the estimated key sizes that would be re- of the public key in the certificate, but instead include a quired to achieve 80-bits of security (i.e., a security level pointer to the public key along with a hash of the key. In comparable to that provided by an 80-bit symmetric key). this case, since the directory would only include the public While 80-bits of security may be considered adequate at the key, there would be fewer privacy concerns with respect to moment, it is recommended that within the next few years the data in the directory. This would also allow the rely- all such keys be replaced with keys that provide 112 to 128 ing party to validate the certificate before downloading the public key, in which case the relying party could avoid the abstract). In Proceedings of the Thirtieth Annual cost of downloading a very large public key if the certificate ACM Symposium on the Theory of Computing, pages could not be validated, and thus the public key could not be 10–19, 1998. used. [2] M. Ajtai and C. Dwork. A public-key cryptosystem With very large public signature keys, the organization of with worst-case/average-case equivalence. In STOC public key infrastructures (PKI) would also need to be care- ’97: Proceedings of the twenty-ninth annual ACM fully considered. Today, even a very simple PKI may consist symposium on Theory of computing, pages 284–293, of a hierarchy of certification authorities (CA), with a root 1997. CA that issues certificates to subordinate CAs that in turn [3] E. Barker, W. Barker, W. Burr, W. Polk, and issue end user certificates. While the relying party would M. Smid. Recommendation for key management – part have already obtained the public key of the root CA through 1: General. NIST special publication 800-57, National some secure, out-of-band means, the public key of one of the Institute of Standards and Technology, Mar. 2007. subordinate CAs would need to be downloaded in order to [4] C. Bennett, E. Bernstein, G. Brassard, and verify the signature on an end user certificate. If responses U. Vazirani. Strengths and weaknesses of quantum from Online Certificate Status Protocol (OCSP) [41] respon- computation. Special Issue on Quantum Computation ders were needed to verify that neither the intermediate nor of the Siam Journal of Computing, Oct. 1997. the end user certificate had been revoked, this could require [5] D. Boneh and M. Franklin. Identity-based encryption the relying party to download two more public keys in order from the Weil pairing. SIAM J. of Computing, to verify the responses from the two OCSP responders. So, 32(3):586–615, 2003. validating an end user certificate in a simple two-level hierar- [6] D. Boneh, B. Lynn, and H. Shacham. Short signatures chy could require the relying party to download three public from the Weil pairing. In Advances in Cryptology – keys in addition to the end user’s public key. In some PKIs ASIACRYPT 2001, 7th International Conference on today, certification paths involving four or more intermedi- the Theory and Application of Cryptology and ate certificates are not uncommon. While this is reasonable Information Security, pages 514–532, 2001. with the public key algorithms that are in use today, which [7] J. Buchmann, C. Coronado, M. Döring, D. Engelbert, use public keys that are smaller than one kilobyte, such PKI C. Ludwig, R. Overbeck, A. Schmidt, U. Vollmer, and architectures will need to be reconsidered if there is a need in the future to move to public key algorithms that require R.-P. Weinmann. Post-quantum signatures. the use of very large public keys. Cryptology ePrint Archive, Report 2004/297, 2004. [8] J. L. Carter and M. N. Wegman. Universal classes of hash functions (extended abstract). In STOC ’77: 9. CONCLUSION Proceedings of the ninth annual ACM symposium on While factoring and discrete logarithm based cryptogra- Theory of computing, pages 106–112, 1977. phy continue to dominate the market, there are viable alter- [9] B. Chor and R. L. Rivest. A knapsack type public key natives for both public key encryption and signatures that cryptosystem based on arithmetic in finite fields. are not vulnerable to Shor’s Algorithm. While this is no IEEE Transactions on Information Theory, guarantee that they will remain impervious to classical or 34(5):901–909, Sept. 1988. quantum attack, it is at least a strong indication. When [10] S. Cook. The importance of the P versus NP question. compared to current schemes, these schemes often have sim- Journal of the ACM, 50(1):27–29, 2003. ilar or better computational performance, but usually re- [11] N. Courtois, M. Finiasz, and N. Sendrier. How to quire more bandwidth or memory. While this should not achieve a McEliece-based digital signature scheme. In be a major problem for PCs, it may pose problems for more Advances in Cryptology – ASIACRYPT 2001, 7th constrained devices. Some protocols may also have problems International Conference on the Theory and with increased packet sizes. Application of Cryptology and Information Security, It does not appear inevitable that quantum computing pages 157–174, 2001. will end cryptographic security as we know it. Quantum computing is, however, a major threat that we probably [12] N. T. Courtois, L. Goubin, and J. Patarin. will need to deal with in the next few decades, and it would SFLASHv3, a fast asymmetric signature scheme. be unwise to be caught off guard when that happens. Pro- Cryptology ePrint Archive, Report 2003/211, 2003. tocol designers should be aware that changes in the under- [13] D. Deutsch and R. Jozsa. Rapid solution of problems lying cryptography may and almost certainly will be nec- by quantum computation. Proc Roy Soc Lond A, essary in the future, either due to quantum computing or 439:553–558, Oct. 1992. other unforeseen advances in cryptanalysis, and they should [14] W. Diffie and M. E. Hellman. New directions in be at least passably familiar with the algorithms that are cryptography. IEEE Transactions on Information most likely to replace current ones. Cryptanalysts will also Theory, IT-22(6):644–654, Nov. 1976. need to scrutinize these algorithms before they are urgently [15] V. Dubois, P.-A. Fouque, A. Shamir, and J. Stern. needed. While some work has been done already, more work Practical cryptanalysis of SFLASH. In Advances in is needed to convince the cryptographic community that Cryptology – CRYPTO 2007, 27th Annual these algorithms will be as safe, in the future, as factoring International Cryptology Conference, pages 1–12, 2007. and discrete logarithm based cryptography are today. [16] R. Feynman. Simulating physics with computers. International Journal of Theoretical Physics, 10. REFERENCES 21(6&7):467–488, 1982. [1] M. Ajtai. The shortest vector problem in L2 is [17] FIPS 186-2. Digital Signature Standard (DSS). NP-hard for randomized reductions (extended National Institute of Standards and Technology, Jan. W. Whyte. NAEP: Provable security in the presence 2000. of decryption failures. [18] N. Gama and P. Q. Nguyen. New chosen-ciphertext [31] É. Jaulmes and A. Joux. A chosen-ciphertext attack attacks on NTRU. In Public Key Cryptography - PKC against NTRU. In Advances in Cryptology – CRYPTO 2007, 10th International Conference on Practice and 2000, 20th Annual International Cryptology Theory in Public-Key Cryptography, pages 89–106, Conference, pages 20–35, 2000. 2007. [32] N. Koblitz. Elliptic curve cryptosystems. Mathematics [19] T. E. Gamal. A public key cryptosystem and a of Computation, 48(177):203–209, 1987. signature scheme based on discrete logarithms. In [33] L. Lamport. Constructing digital signatures from a Advances in Cryptology, Proceedings of CRYPTO ’84, one-way function. Technical Report CSL-98, SRI pages 10–18, 1984. International, Oct. 1979. [20] L. C. C. Garcı́a. On the security and the efficiency of [34] R. J. McEliece. A public-key cryptosystem based on the Merkle signature scheme. Cryptology ePrint algebraic coding theory. Deep Space Network Progress Archive, Report 2005/192, 2005. Report 42–44, Jet Propulsion Laboratory, California [21] C. Gentry. Key recovery and message attacks on Institute of Technology, pages 114–116, 1978. NTRU-composite. In Advances in Cryptology – [35] R. C. Merkle. Security, Authentication, and Public EUROCRYPT 2001, International Conference on the Key Systems. PhD thesis, Stanford University, June Theory and Application of Cryptographic Techniques, 1979. pages 182–194, 2001. [36] R. C. Merkle. A certified digital signature. In [22] C. Gentry, J. Jonsson, J. Stern, and M. Szydlo. Advances in Cryptology – CRYPTO ’89, 9th Annual Cryptanalysis of the NTRU signature scheme (NSS) International Cryptology Conference, pages 218–238, from Eurocrypt 2001. In Advances in Cryptology – 1989. ASIACRYPT 2001, 7th International Conference on [37] R. C. Merkle and M. E. Hellman. Hiding information the Theory and Application of Cryptology and and signatures in trapdoor knapsacks. IEEE Information Security, pages 1–20, 2001. Transactions on Information Theory, 24(5):525–530, [23] O. Goldreich, S. Goldwasser, and S. Halevi. Public-key Sept. 1978. cryptosystems from lattice reduction problems. In [38] T. Meskanen and A. Renvall. A wrap error attack Advances in Cryptology – CRYPTO ’97, 17th Annual against NTRUEncrypt. Discrete Applied Mathematics, International Cryptology Conference, pages 112–131, 154(2):382–391, Feb. 2006. 1997. [39] D. Micciancio. Improving lattice based cryptosystems [24] L. K. Grover. A fast quantum mechanical algorithm using the Hermite normal form. In Cryptography and for database search. In STOC ’96: Proceedings of the Lattices Conference — CaLC 2001, pages 126–145, twenty-eighth annual ACM symposium on Theory of Mar. 2001. computing, pages 212–219, 1996. [40] V. S. Miller. Use of elliptic curves in cryptography. In [25] J. Hoffstein, N. Howgrave-Graham, J. Pipher, J. H. Advances in Cryptology – CRYPTO ’85, pages Silverman, and W. Whyte. NTRUSign: Digital 417–426, 1986. signatures using the NTRU lattice. In Topics in [41] M. Myers, R. Ankney, A. Malpani, S. Galperin, and Cryptology – CT-RSA 2003, The Cryptographers’ C. Adams. X.509 Internet Public Key Infrastructure Track at the RSA Conference 2003, pages 122–140, Online Certificate Status Protocol – OCSP. RFC 2560 2003. (Proposed Standard), June 1999. [26] J. Hoffstein, N. Howgrave-Graham, J. Pipher, J. H. [42] P. Q. Nguyen. A note on the security of NTRUsign. Silverman, and W. Whyte. NTRUEncrypt and Cryptology ePrint Archive, Report 2006/387, 2006. NTRUSign: efficient public key algorithms for a [43] NTRU Announces Signature Algorithm, NTRUSign, post-quantum world. In PQCrypto 2006: International viewed November 12, 2008, Workshop on Post-Quantum Cryptography, pages hhttp://www.ntru.com/cryptolab/intro ntrusign.htmi. 141–158, May 2006. [44] M. O. Rabin. Digitalized signatures and public-key [27] J. Hoffstein, J. Pipher, and J. H. Silverman. NTRU: A functions as intractable as factorization. Technical ring-based public key cryptosystem. In Algorithmic Report MIT/LCS/TR-212, MIT Laboratory for Number Theory (ANTS-III): Proceedings of the Third Computer Science, Jan. 1979. International Symposium on Algorithmic Number [45] O. Regev. New lattice-based cryptographic Theory, pages 267–288, June 1998. constructions. Journal of the ACM, 51(6):899–942, [28] J. Hoffstein, J. Pipher, and J. H. Silverman. NSS: An Nov. 2004. NTRU lattice-based signature scheme. In Advances in [46] R. L. Rivest, A. Shamir, and L. M. Adleman. A Cryptology – EUROCRYPT 2001, International method for obtaining digital signatures and public-key Conference on the Theory and Application of cryptosystems. Communications of the ACM, Cryptographic Techniques, pages 211–228, 2001. 21(2):120–126, Feb. 1978. [29] N. Howgrave-Graham. A hybrid lattice-reduction and [47] S. Robinson. Emerging insights on limitations of meet-in-the-middle attack against NTRU. In Advances quantum computing shape quest for fast algorithms. in Cryptology – CRYPTO 2007, 27th Annual SIAM News, 36(1), January/February 2003. International Cryptology Conference, pages 150–169, 2007. [48] C.-P. Schnorr and H. H. Hörner. Attacking the Chor-Rivest cryptosystem by improved lattice [30] N. Howgrave-Graham, J. H. Silverman, A. Singer, and reduction. In Advances in Cryptology – EUROCRYPT Science, pages 124–134, 1994. ’95, International Conference on the Theory and [52] P. van Emde Boas. Another NP-complete problem and Application of Cryptographic Techniques, pages 1–12, the complexity of computing short vectors in a lattice. 1995. Technical Report 81-04, University of Amsterdam, [49] A. Shamir. A polynomial time algorithm for breaking Department of Mathematics, Netherlands, 1981. the basic Merkle-Hellman cryptosystem. In Advances [53] G. S. Vernam. US patent #1,310,719: Secret signaling in Cryptology: Proceedings of CRYPTO ’82, pages system, July 1919. 279–288, 1982. [54] W. Whyte. NTRUSign and P1363.1, Apr. 2006. [50] C. Shannon. Communication theory of secrecy http://grouper.ieee.org/groups/1363/WorkingGroup/ systems. Bell System Technical Journal, presentations/P1363.1-2006-04.ppt. 28(4):656–715, 1949. [55] H. C. Williams. A modification of the RSA public-key [51] P. W. Shor. Algorithms for quantum computation: encryption procedure. IEEE Transactions on Discrete logarithms and factoring. In Proceedings of Information Theory, IT-26(6):726–729, Nov. 1980. the 35th Symposium on Foundations of Computer Quantum Resistant Public Key Cryptography: A Survey Ray A. Perlner (ray.perlner@nist.gov) David A. Cooper (david.cooper@nist.gov) What is a quantum computer • Short answer – A classical computer processes classical information. – A quantum computer processes quantum information. • What is the difference? – Classical information is measured in bits (a unit of entropy in the classical limit of physics) – Quantum information consists of qbits (a unit of entropy in real physics) – Either way, available entropy scales with the size of a system. – So it should be possible to build a quantum computer. What can a quantum computer do? (faster than a classical computer) • Simulate a quantum computer – The best known classical algorithm is exponentially more costly in the worst case. – This does NOT mean that a quantum computer can always provide exponential speedup. • Stuff that matters for cryptography – Quadratic speedup over classical brute force search. (Grover) – Polynomial time algorithms for factoring and discrete logs, including elliptic curves. (Shor) • This completely breaks every public key algorithm you’ve probably ever heard of. Why haven’t these monstrosities been built? • Error correction/fault tolerance is much harder for quantum information. – Currently, we’re better off using a classical computer to run simulations. – Threshold theorems say that if we can build good enough components, the cost is only polynomial. • Components are not cheap like transistors – Options include ultra-cold ultra-small solid state devices and charged ions or neutral atoms controlled by lasers. – Pure optical systems may be an important component, but are unlikely to be the whole solution. Quantum Resistance • Quantum resistant algorithms are algorithms we don’t know how to break with a quantum or classical computer. – This is the same criterion we use for security in the classical model (pending P≠NP proof) – As with classically secure algorithms, related “hard problems” add a measure of confidence. – (Classical) algorithms meeting the above criteria do exist at present. The Algorithms General Concerns • Security Assumptions • Public Key Length • Signature Length/Ciphertext Expansion – E.g. RSA has ~1-2 kb (~10 - 20×) • Public Key Lifetime – Mostly an issue for signatures – Can be dealt with using Merkle Trees and certificate chains – Memory (may need more than just the private key) • Computational Cost Lamport Signatures • One time signatures • Basic Scheme: Sign a single bit – Private key consists of two secrets S0 and S1 – Public key is H(S0) || H(S1) – Signature for 0 is S0, signature for 1 is S1 • To sign an n-bit digest, just use n times as many secrets to sign the bits individually. • Many optimizations are possible that trade increased computation for reduced key and/or signature size. Merkle Trees Lamport Signatures • Security Assumption: preimage and second- preimage resistance of a one-way function – Only the message digest needs collision resistance. • Public Key Length: ~n2 for an n-bit one-way function and a 2n-bit digest – ~10 kb for n = 80 – ~20 kb for n =128 • Signature Length: same • Public Key Lifetime: 1 signature • Computational Cost: ~1ms (comparable to DSA) – Includes key generation Lamport Signatures (with Merkle Trees and Chaining) • Security Assumption: preimage and second- preimage resistance of a one-way function – Only the message digest needs collision resistance. • Public Key Length: n for an n-bit one-way function and a 2n-bit digest • Private Key Length: ~250 – 500 kb • Signature Length: ~50 – 100 kb • Public Key Lifetime: 1012 signatures • Computational Cost: ~1ms (comparable to DSA) – key generation: ~1s McEliece Encryption • Start with an error correction code generator matrix, G – Rectangular matrix such that it’s easy to reconstruct x from Gx + e. • x has dimension k • e has hamming weight t or less and dimension n > k • Public key K = PGS – S is k×k and invertible – P is an n×n permutation • To Encrypt m: compute Km + e McEliece Encryption • Security Assumption: indistinguishability of masked Goppa code and general linear code – Decoding problem for general linear codes is NP-complete • Public Key Length: ~500kb • Message Size: ~1kb • Public Key Lifetime: potentially unlimited • Computational Cost: ~100μs – Signatures exist, but very expensive for signer NTRU • Private key is a short basis for an N dimensional lattice • Public key is a long basis for the same lattice. • Save space by representing lattice basis as a polynomial rather than a matrix – This requires all lattice basis vectors to be cyclic permutations. – Many academic crypto schemes employ lattices but do not employ this technique, preferring security assumptions based on a less symmetric version of the lattice problems. • Coefficients are generally reduced modulo q  N  256 NTRU • Security Assumption: unique closest vector problem • Public Key Size: 2-4kb • Ciphertext Size: 2-4kb • Signature Size: 4-8kb • Public Key Lifetime: ~1 billion signatures – Signature scheme has changed in response to a series of attacks. • Computational Cost: ~100μs Other • Hidden Field Equations • Braid Groups • New schemes based on these crop up from time to time, but most have been broken. Implications • Crypto Agility is a Minimum Requirement • Long Signatures or Public Keys – Transmitting certificates may become unwieldy (especially when revocation is considered) • Cache Certificates • Limit Cert Chain Depth • Limited Lifetime Signing Keys – Mostly applicable to high load servers (e.g., OCSP responders) • Use a Merkle tree or subordinate public keys where applicable. Conclusion • All widely used public key crypto is threatened by quantum computing. • We do have potentially viable options to consider. • Protocol designers can think about how to deal with these algorithms now. FileSpace An Alternative to CardSpace that supports Multiple Token Authorisation and Portability Between Devices David Chadwick University of Kent Computing Laboratory Canterbury +44 7796 44 7184 d.w.chadwick@kent.ac.uk ABSTRACT identity. Information Cards have some excellent features in terms This paper describes a federated identity management system of both usability and security. From a usability perspective, the based on long lived encrypted credential files rather than virtual metaphor that Information Cards use for electronic credentials is cards and short lived assertions. Users obtain their authorisation the plastic card that everyone is familiar with. These are displayed credential files from their identity providers and have them bound on the user’s desktop so that the user can select the card he wants to their public key certificates, which can hold any pseudonym to use in any transaction. Cards that are acceptable to the service the user wishes. Users can then use these credentials multiple provider (SP), and hence selectable, appear in full colour, whilst times without the identity providers being able to track their cards that are incompatible with the SP’s requirements are greyed movements and without having to authenticate to the IdP each out and hence not selectable. Cards can be self generated or time. The credentials are worthless to an attacker if lost or stolen, managed. Self generated cards contain information (attributes) therefore they do not need any special protection mechanisms. asserted by the user himself, whereas managed cards contain They can be copied freely between multiple devices, and users attributes that are asserted by an Identity Provider (IdP) or can use multiple credentials in a single transaction. Users only Attribute Authority (AA) (i.e. a trusted third party, TTP). The fact need to authenticate to their private key store in order for it to that the attribute assertions (or claims) of the managed cards do produce a signed token necessary for the service provider to not actually reside on the user’s desktop, but are pulled from the authenticate the user and decrypt the authorisation credentials. IdP on demand, is largely hidden from the user. The only telling The signed token is bound to the service provider and is short feature is that the user has to enter his login credentials with the lived to prevent man in the middle attacks. IdP in order for the claim to be picked up and sent to the SP. This could be seen as a usability disadvantage or inconvenience to users, since the user is distracted from his/her primary task, which Categories and Subject Descriptors is accessing a service provider, into providing authentication C.2.4 Distributed Systems. K.6.5 Security and Protection credentials to an alternative party, the identity provider. But this is really not that much different to users entering their PINs today General Terms in order to activate their plastic cards. Management, Design, Security, Human Factors From a security perspective, CardSpace also contains some excellent features. Firstly it is resistant to phishing attacks, since an SP cannot redirect users to a malicious entity masquerading as Keywords their identity provider, since the users store this information Federated Identity Management, CardSpace, Authorisation, X.509 securely on their PCs in the meta-information of their identity certificates, Information Cards cards. Phishing can only succeed if the attacker can manage to subvert the user’s PC without his knowledge, in order to plant 1. INTRODUCTION subversive cards in the user’s identity selector. Secondly there is Information Cards are the core component of Microsoft’s nothing of value on the user’s desktop that can be stolen by an CardSpace identity management and authorisation system. A adversary, since the credentials or claims are only generated on good high level overview of CardSpace can be found in [1]. demand by the IdP when required. The credentials are short lived, Information Cards are a representation of a person’s online digital cryptographically protected, designed to be transferred as quickly as possibly from the IdP to the SP via the user’s desktop, and can be created to be read by the SP only. So there is little opportunity Permission to make digital or hard copies of all or part of this work for for an attacker to steal them. personal or classroom use is granted without fee provided that copies are However, CardSpace is missing some technical features that 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 critically affect its ubiquity and utility. It may have user otherwise, or republish, to post on servers or to redistribute to lists, acceptance problems as well. These might explain its slow uptake requires prior specific permission and/or a fee. to date. They are: IDtrust '09, April 14-16, 2009, Gaithersburg, MD Copyright 2009 ACM 978-1-60558-474-4…$5.00 94 i) the lack of mobility/portability. In initial versions of to drag and drop them between devices e.g. copy from a laptop to CardSpace, a user’s cards were tied to his Microsoft PC a mobile phone or memory stick etc. We also make it easy for and could not be moved between devices and operating users to pick and send multiple credentials to web service systems. Whilst this has been fixed by defining a card providers. Web browsers simply need to allow the user to transfer format [14, 15], the format is an XML navigate around their filestore and click on several credential files encrypted file which may cause difficulties for in order to automatically transfer (i.e. copy) them to the service constrained devices that currently do not process XML. provider. They have this functionality today. Other benefits of Data structures in XML are typically an order of using the file paradigm for credentials, is that we can then use magnitude greater than equivalent binary structures in existing software for synchronisation of credential files between ASN.1, and XML cryptography is up to an order of different devices, and existing protocols for transferring credential magnitude slower than ASN.1 based cryptography [16]. files between systems. If the credentials are self protected, in Consequently it is still not clear how portable info cards terms of integrity protection (via a digital signature) and will be in practice. confidentiality/privacy protection (via encryption), then no ii) the inability to use multiple cards in a single special protocols are needed for transferring them between transaction. Whilst many transactions only require a systems, and we also protect the user from copying them by single card to ensure success, a large proportion require mistake to a malicious third party, or altering them either multiple cards e.g. showing a student card and visa card intentionally or by mistake. to buy a book with a student discount, or showing a Of course if we move to a file paradigm, there are still a General Practitioner certificate and employee certificate significant number of security mechanisms that we will need to in order to access a patient’s medical record; develop in order to protect the user from phishing attacks, from iii) Users have to learn a new paradigm for interacting with the theft of his credentials and from the loss of his privacy. service providers – the whole CardSpace philosophy. Consequently the CardSpace system needs to be enhanced to 3. THE FILESPACE CONCEPTUAL allow easy mobility and portability between devices, as well as to MODEL allow the use of multiple cards in a single transaction. Whilst Credentials can be short lived or long lived. If they are long lived adding these new features, we should not lose the existing good we need a revocation mechanism, if they are short lived we do features of usability and security that CardSpace exhibits, but if not, the assumption being that during their short life time there is we can improve upon them and upon the user experience of little chance of them being stolen and used to ill effect. Today we Identity Management (IdM) at the same time, for example, by not use long lived credentials for X.509 public key certificates introducing new paradigms to users, then so much the better. As (PKCs) and physical plastic cards, and short lived credentials for Landau and Mulligan state [10] “usability is the key to success”. X.509 grid proxy certificates [2], SAML attribute assertions [3] (for example as used by Shibboleth [4]) and CardSpace credentials. Both short lived and long lived credentials have their 2. AN EXISTING PARADIGM FOR advantages and disadvantages [5]. If we are to use the file CREDENTIALS – CONFIDENTIAL FILES paradigm for credentials, we need to make them long lived so that All computer users today are familiar with using computer files. users can manipulate them, copy them, and use them multiple They are fundamental to the use of any PC. One of the most times, as they do today with their plastic cards. In this case we ubiquitous sets of user abstractions that have been developed are need to make it the responsibility of the SP to check if the those for using the file system. All users today are familiar with presented credentials have been revoked or not. But this is their drag and drop, copy, delete, rename file etc. Thus they are already normal responsibility, since it is part of their risk management a more commonplace paradigm when using computers than are procedures. We can easily help the SP in this function, by the virtual plastic cards of CardSpace. Users also understand that including policy information in each issued credential which different files contain different contents, and that some files may informs all relying parties (SPs) where they can find the contain confidential information whilst others may not. Thus revocation information. This is the standard X.509 model, and users do not need to develop any new skills in order to manipulate X.509 public key certificates use both the CRL Distribution their files. They do it today, all of the time. Points extension [6] to point to revocation lists and the Authority One of the critical objectives we should have when developing an Information Access extension [7] to point to OCSP responders IdM system, is to make IdM and Authorisation very easy to use; [8]. So this is a well known and well used technology that we can as easy say, as manipulating user files is today. As Dhamua and also use for authorisation credentials. Dusseault state [11] “To succeed in the marketplace, identity Next we need to stop authorisation credentials from being stolen management system must…..most important, simplify the process or lost by their owner, or from being sent to a malicious site by of authentication, identification and assertion of credentials”. This mistake by their owner. Clearly we cannot physically do any of implies that authorisation tokens might be easier for users to this, so the next best thing, if they are stolen or lost or sent to a handle if they are simply regarded as files on their desktop rather malicious site, is to ensure they are worthless to the thief. We can than card icons. Users are used to the fact that some of their files easily make authorisation credentials worthless to a thief by may contain public information and some may contain cleanly separating authentication from authorisation, by confidential information, so they do not need to be educated in encrypting the authorisation credentials and then requiring their handling different types of files differently. By turning a user’s rightful owner to authenticate and prove possession by providing credentials into simple confidential files we make it easy for users the decryption key. Then if anyone steals a user’s authorisation 95 credentials they are worthless to the attacker unless the attacker If we encrypt the fields of the authorisation credential using the can either i) authenticate as the user in order to use them (i.e. public key of the holder, then the holder is the only person who masquerade), or ii) trick the user into providing decryption of the can decrypt its contents and read it, by using their private key. If authorisation credential’s contents in order to invade the user’s we introduce a level of indirection, by encrypting the credential privacy. Modern day cryptography should protect against the contents with a randomly generated symmetric key, then encrypt second threat. We protect against the first threat by cleanly the symmetric key with the public key of the holder and store the separating authentication credentials from authorisation encrypted key in the authorisation credential, then this has the credentials, and by requiring anyone who presents an added advantage of speed (since symmetric encryption/decryption authorisation credential to an SP, to also prove to the SP that they is much faster than asymmetric encryption) and we can are the rightful owner of the authorisation credentials before the subsequently use the symmetric key to give relying parties such SP will or can use them. This is akin to protecting today’s plastic as SPs read access to the authorisation credential (as described credit cards with a PIN, and mandating that the PIN be presented later). before the credit card can be used. Then if an attacker steals a user’s authorisation credentials they become worthless to him, 3.2 Obtaining Authorisation Credentials unless he can prove to the SP that he is the user i.e. can In order to issue such an authorisation credential, the issuer needs authenticate as the user to the SP. This should be very difficult for to know four things: an attacker to do if we use a strong authentication mechanism such as a digital signature (rather than the relatively weak 4 digit a) who is the real person that is asking for this credential PIN mechanism of today’s credit cards) and we keep the private to be issued signing key in a piece of hardware to make it difficult to steal. b) are they entitled to be issued with this credential Unless an attacker can steal the strong authentication mechanism c) what unique identifier (pseudonym) do they wish to be (i.e. my hardware) before or after he steals my authorisation inserted into their authorisation credential credentials, that is, sometime during the validity period of my d) which public key are they currently using. authorisation credentials, and without me knowing that he has Item a) is a registration issue and is typically solved at registration stolen my authentication mechanism, then we do not care if he time, when a user first enrolls with an identity provider/attribute simply steals my authorisation credentials. They are useless to authority (IdP/AA1). After registration the user will typically be him. He cannot decrypt them and he cannot masquerade as me. given some issuer specific authentication credential with which to The only thing a user needs to protect and look after herself is her re-authenticate to their systems. Item b) is an internal issue and is authentication mechanism solved by the issuer consulting its internal databases to see which privileges have been assigned to the user. The user may use their 3.1 Contents of Authorisation Credentials assigned authentication credential to prove to the issuer who they All authorisation credentials (also known as attribute assertions, really are and the issuer will then consult its databases to see claims and attribute certificates) regardless of their syntax which privileges this user possesses. For example, when a student (ASN.1, XML or proprietary format) conceptually comprise the first registers at a university, they bring their passport, school following fields: qualifications, language certificates etc. with them to prove who -the unique identifier of the credential holder * they are and that they are qualified to enroll on a degree program. -the unique identifier of the credential issuer In exchange they might be given a unique login id by the -the serial number of the credential university, which they can subsequently use in all their electronic -the authorisation attribute(s) e.g. organisational role, interactions with the institution. It is this login id and its group membership, degree classification, status associated authentication credential (such as a password) that attribute, credit card number, etc. * allows the user to authenticate to the university’s computer - the validity time of the credential systems and assure the university who is the real person that its - policy information of the issuer to control how the computers are talking to. All the user’s degree qualifications and credential should be used e.g. one time use, how to transcripts will be linked to this login id. Note that this login id is obtain revocation information for long lived credentials, of no value outside of the university context. Its raison d’etre is to which services it should be used for, limitations of uniquely identify the user in the computer systems of the liability etc. university. No two users will have the same login identifier - information about the cryptographic algorithm(s) used, (unless the system is broken!). The user may use this login id to to tell the receiver how to validate the credential authenticate to the university to prove who they really are and the - the signature of the credential issuer. university will then consult its databases to see which degree In order to privacy protect these authorisation credentials we need marks and awards this user possesses. In tune with other identity to encrypt all the Personally Identifying Information (PII) of the management systems such as CardSpace and Shibboleth, we don’t holder. This comprises the unique identifier of the holder and the dictate what registration and authentication mechanisms each authorisation attribute(s) i.e. the information marked with an * credential issuer will use, but clearly some will use stronger above. Now if anyone steals one of these encrypted authorisation mechanisms than others. NIST has issued guidelines for the credentials it is useless to them since: registration and authentication procedures that can be used, and i. they cannot read its contents because they don’t have the decryption key, and 1 Note that we do not separate the functions of IdP and AA and ii. they cannot authenticate as the rightful holder because assume the same entity performs both functions, since this is they don’t have the authentication mechanism. typically the case today. 96 this document defines four different levels of authentication that his pseudonym conforms to the policies of the various assurance [12]. credential issuers or federations that he wishes to use. We propose Items c) and d) can be obtained from a public key certificate of two alternatives for pubic key certificate generation: the credential holder, providing that the public key certificate 1. Self issued certificates in which the users create their contains a unique identifier in its subject field, and providing that own unique pseudonyms the holder proves possession of the corresponding private key (see 2. Trusted Certification Authority issued certificates in section 3.3 below). which the CA has a policy for how names are assigned The unique pseudonym and the requested attributes are then and validated before insertion into their certificates. encrypted using a freshly generated symmetric key, and the CAs may issue certificates with genuine pseudonyms or symmetric key is encrypted using the public key, before they are may issue them with names that allow relying parties to all inserted into the authorisation credential. The authorisation identify their real world owners. credential is given a validity time that starts at or shortly after the The important thing to note is that the pseudonym can be time of issuing, and finishes when the accompanying public key irrelevant from an authorisation and identification perspective. certificate expires or earlier, at the option of the issuer. Finally the The only real requirement is that it can act as a primary key into authorisation credential is signed by the issuer and returned to the the databases of both the authorisation credential issuer and the user. relying parties. This is why it must be unique within a federation. But it does not need to be used for either authorisation purposes or for identifying the real life person; it is the certified attributes 3.3 Obtaining public key certificates in the authorisation credentials that are used for authorisation, and In order to obtain an authorisation credential, after authenticating it is the user’s personal information stored with the credential to the IdP/AA with their IdP specific mechanism2, the user issuers that are used to identify the real life person. The identifier presents their public key certificate (PKC) and proof of may only be used for identification purposes if it has been issued possession of the private key, and asks for an authorisation by a trusted CA whose policy states that it bears some relationship credential to be issued containing a subset of their privilege to a real life person or legal entity. Otherwise the SPs should only attributes. The encrypted pseudonym that is inserted into the use the attributes for authorisation and the pseudonym for linking authorisation credential is not the unique identifier that the the user’s transactions in order to build up their own usage IdP/AA knows the user by, but is the unique pseudonym from the profiles. In most developed countries SPs are prohibited by data public key certificate presented by the user. privacy laws from sharing user profiles without the user’s The only technical requirement we have from the PKC is that the consent. pseudonym is unique within the scope of the authorisation system The IdP/AA must store the mapping between the pseudonym (IdP or federation) or systems that the user wishes to use it in, in from the public key certificate and the login/authentication order to prevent the user from masquerading as or being mistaken identifier that it keeps for the user. It may need this for legal for another user of the same system. Whether the identifier is reasons; for example, to identify the user should the user commit similar to the real name of the user, or is a completely fictitious a fraud using the issued authorisation credential. pseudonym such as Father Christmas, or a random number, is not The user is free to generate as many pseudonyms and public key important from a technical perspective. The only technical certificates as he wants to, with each public key certificate requirement is that it is unique. Unique identifiers could be DNS containing the same or different pseudonyms. If the same names, OpenID identifiers, hashes of public keys etc. There are pseudonym is used in different public key certificates for example numerous options to choose from. It is trivial to create globally when the keys expire and are renewed, then the user will need to unique identifiers using user generated pseudonyms, for example, prove to the authorisation credential issuer that she is the owner of by simply pre-pending a base64 hash of the public key to the both private keys, otherwise the issuer will require unique user’s pseudonym, e.g. create an X.509 distinguished name of pseudonyms with each public key (to stop masquerade). The KID=12345678…9, CN=Father Christmas. This gives the user IETF group has devised mechanisms for this as part of the complete anonymity. certificate management procedures of CAs [7]. Revocation of the Additional considerations that the authorisation credential issuer user’s public key certificates is not an issue. If the user loses or might have for the pseudonym, are that the name is not offensive has his private key stolen, he asks the authorisation credential or illegal (e.g. a trade mark that does not belong to the real person issuers to revoke the authorisation credentials that are linked to whose credential this will be), and is not likely to confuse a the key pair. In this way, the thief may be able to masquerade as relying party because it could be mistaken for a different client of the pseudonymous user to an SP, but when he comes to assert the the issuer. Each credential issuer will typically have its own authorisation credentials, the SP will discover that they have been policy for what comprises suitable unique names. Federation revoked, and the thief will not gain access to any resources. If the guidelines can be established for this. The user will need to ensure user has obtained his public key certificate from a CA, rather than using a self-issued one, then the user may ask the CA to revoke the public key certificate as well. 2 Note that we are not concerned in this paper with how a user An IdP/AA may be willing to issue the same authorisation authenticates to his IdP/AA in order to be issued an attributes to the same user in different authorisation credentials authorisation credential. It could be with a username password, containing different pseudonyms, encrypted to different public a single sign on system, a national ID card, etc. We regard this keys. The willingness of the IdP/AA to keep a many to one as a separate issue that is out of scope of this paper, as do the Shibboleth, SAML and CardSpace schemes. 97 mapping of public key identifiers to login identifiers is a policy design. Consequently this paper does not address the issue of issue of the IdP/AA. private key protection, since it has been well researched already The only other requirement we place on the generation of a public and many different hardware tokens are commercially available. key certificate is that it should indicate the location of the Needless to say this is a critical component of this design. corresponding private key. This is used to solve the discovery problem for SPs who subsequently want to obtain the decryption 3.4 Using the Authorisation Credentials keys for the authorisation credentials they are about to accept (see section 3.3). If the user’s private key is held in the SIM card of a Once a user has established a pseudonym, for example issued her mobile phone, then it would be the international telephone own public key certificate, and obtained a set of authorisation number of the SIM card. If the user’s private key is held in a credentials from her various Identity Providers, the system is very portable USB stick such as IBM’s ZTIC [9], or a PKCS#12 file, simple for end users to use. Copying credentials between devices or smartcard, then it would indicate that it is at the same location is simply a matter of drag and drop. They don’t need any special as the user making the service request. security mechanisms to protect them. As already explained, they are useless to an attacker without access to the corresponding Figure 1 below shows a user who has generated public key private key, which the user must keep separately and securely, certificates with two different pseudonyms, which he has preferably in a hardware token so that the private key cannot be abbreviated to David Chadwick and Father Christmas, although copied and cannot be lost or stolen without the user noticing it. the actual identifiers in the public key certificates will be longer than this and unique. The user has then authenticated to several When contacting a service provider, the user simply selects the set IdP/AAs, in whatever way each IdP decrees, and has requested of credentials he wants to present. This should always include the authorisation credentials from each. Under the pseudonym of identity file (i.e. the public key certificate containing whichever Father Christmas the user has been given authorisation credentials pseudonym he wishes to use today) plus the set of authorisation from five different IdP/AAs, in which the identifiers and attributes files he needs that are linked to this pseudonym. have each been indirectly encrypted to the public key within the In order to accept these authorisation credentials, the SP needs to Father Christmas certificate (called Identity.card in Figure 1) as know three things: described above. Note that since these are simply computer files, the user can call the directories and files whatever nicknames he a) that the person presenting the credentials is the rightful wants to. We would expect a unique three character file owner extension to be standardized for FileSpace files in due course. b) that the credentials are still valid and have not been revoked by their issuers c) that it trusts the credential issuers to issue these types of authorisation credentials. The SP can determine b) by reading the unencrypted contents of an authorisation credential and contacting its issuer as determined by the issuer’s policy in the credential e.g. OCSP or CRL repository. The SP can only determine a) and c) by first getting the presenter to decrypt the contents of the credential in real time and then looking at its credential issuers policy to see which issuers it trusts to issue which credentials. Decrypting the credentials in real time is achieved in the following way. The SP inspects the user’s identity file (i.e. X.509 Figure 1. Filestore showing two pseudonyms and the public key certificate) and determines the location of the user’s authorisation files of Father Christmas private key from this. The SP then sends a signed request message to this location, including its public key certificate and the A critical requirement is that the user needs to keep the private authorisation credentials it wants decrypting. The user’s software keys of his various pseudonymous certificates safe and secure validates the message’s signature and SP’s certificate, makes sure somewhere, preferably inside one or more hardware tokens such the message is not a replay, then asks the user if he wants to allow as a mobile phone SIM card or smart card or in a centrally this SP to decrypt these confidential files. This is providing the managed key vault. National identity cards could be used, but user with the ability to confirm consent that she wishes this SP to then the user would not be able to use a pseudonym, and may use these credentials, and stops an active attacker such as a man in have little or no privacy protection since the SPs will know the the middle from hijacking the credentials and masquerading as the identity of the user from the public key certificate attached to the user to a different SP. If the user answers yes, the software ID card. If someone can gain access to any of the user’s private extracts the SP’s public key, decrypts the symmetric keys in the keys, they will be able to masquerade as the user in one or more authorisation credentials using the user’s private key, and of his pseudonyms, and utilise their privileges, until the user encrypts them to the public key of the SP. These encrypted keys, discovers this fact and revokes his authorisation credentials that along with the serial numbers of their respective credentials, are are linked to the relevant key pair. But this is the case with all then returned to the SP in a message signed by the user’s private authentication credentials, and federated identity management key. The signed message contains a nonce, timestamp and name systems including CardSpace, Shibboleth etc. Once an attacker of the SP, to prevent message replay, surreptitious forwarding, can masquerade as a user, then as far as the system is concerned and to limit the time during which the message is valid. The SP they are the user, so there is nothing new in this for the current can validate the signature, ensure the message is not a replay and 98 that it has not timed out, then decrypt the symmetric keys using functions are built-in today. If the private key is held in a remote its private key. It uses each symmetric key to decrypt the contents device such as a mobile phone then this software would need to of the respective authorisation credential with the same serial be built into the phone’s operating system. number. 4. User Experience with CardSpace and Formally the message exchange is as follows: FileSpace The message sent to the user’s private key location contains: The following sections describe the procedures that users will {{authzCredi}i=1 to n, nonce1, ts1, SPPKC}signedPSP experience as they use the CardSpace and FileSpace systems. The message returned from the user contains: 4.1 Obtaining a new identity/pseudonym {{sni, encKeyi}i=1 to n, nonce1, nonce2, ts2, SP}signedPUser This user experience is only relevant to FileSpace. The user has a choice whether to use an existing CA for his new pseudonymous Where: i is the number of authorisation credential sent from the identity, or to generate his own PKC. The latter is simpler and SP to the user’s private key location, gives the user complete pseudonymity. SP is the name of the service provider and SPPKC is its public key If the user chooses an existing CA, then the current process of certificate asking for an X.509 PKC may be used. For example, the user nonce is a random number and ts is a short time in the future (say visits the CA’s web site, requests a new certificate, completes the 2 seconds) registration details including his new email address (say billg@gmail.com), and after clicking on the secret URL sent to PSP is the private key of the SP and PUser is the private key of his email address, the browser creates the X.509 PKC, sends it to the user the CA for signing, then stores the returned PKC in the user’s sni is the serial number of an authorisation credential i certificate store. encKeyi is the symmetric key used to encrypt the contents of If the user chooses to create his own self signed PKC, he will authorisation credential i, encrypted to the public key of the simply need to fill in his chosen pseudonym in the form that is recipient SP provided by the key generation device. If the device is a web The user can send several credentials to the SP, the SP can return browser, a new option in the browser’s menu could be added e.g. several credentials to the user’s private key location, and the Tools>Options>Advanced>Create New Identity Certificate in private key location can return several decryption keys and serial Firefox 3 or Tools>Internet Options>Content>Certificates> numbers in one signed message. This message exchange allows Personal>Create New Identity Certificate in Internet Explorer 7. the SP to know that the user with a particular pseudonym does If it is a hardware device such as a mobile phone or IBM’s ZTIC possess these authorisation attributes and has on demand [9], then the device will need to display such a form. In all cases furnished the decryption keys to it. It allows the user to confirm the user simply enters his pseudonym and the time period during that the only SP that will use these authorisation credentials is the which it should be valid, and the device then creates a new key one that it sent the decryption keys to. Using a private key device pair and corresponding PKC. The user’s new PKC file will need such as ZTIC [9] the user can be assured that no active MITM to be copied or exported from the device to the various filestores attack is taking place. of the various computers and devices on which he wishes to use it. The format of the PKC could be a .cer file (as now) and the A malicious SP that wishes to act as a man in the middle in order export/copy could be carried out by using a memory stick or by to masquerade as the user with another SP (say the user’s bank), emailing the file as an attachment. will have difficulty in doing so. If it provided its own name to the private key location, then even though it has been given the 4.2 Obtaining New Cards and Files symmetric key with which to decrypt the user’s authorisation The way that a new managed information card is obtained by a credentials, it does not have the user’s private key and therefore user is outside the scope of the CardSpace model and cannot create a freshly minted reply from the user to the second specification. IdPs are free to provide whatever web based SP. Thus it cannot forward the signed message to the second SP. interface they wish for this. One typical example will involve the If it provided the name of the second SP to the private key user contacting his chosen IdP via his web browser, establishing location, then the user would see that this is wrong and would not an SSL/TLS session, logging in by sending his username and provide the decryption keys. password over the encrypted link, and then being presented with a A group of malicious SPs that wish to correlate a user’s activities screen which asks the user which attributes he wishes to include between themselves, are technically able to do this with FileSpace in his new information card. The user will tick the set of attributes but only if the user has used the same pseudonymous certificate he wishes to be placed in his managed card, including the ability with all members of the group. However such sharing of personal to include a new random permanent identifier, and a download data is illegal under most data privacy laws e.g. [13] without the screen will then appear allowing the user to navigate around his user’s explicit consent. local filestore and choose the location where his new managed The FileSpace system does require the user’s private key location card is to be deposited. Once he has received the card (as a file to have the software that is capable of performing the various with the prefix .crd on Windows systems), he will logout of his decryption, encryption and signing operations that are described IdP, and enter his local identity selector program (CardSpace on above. If the private key is accessible to a web browser e.g. as a Windows). This displays a new card icon. Clicking on this icon PKCS#12 file or smart card etc. then the assumption is that this gives the user a choice between creating a new self issued card or cryptography software will eventually be built into web browsers, importing a managed card. Selecting the latter allows the user to in the same way that SSL/TLS and CardSpace cryptography 99 navigate around his local filestore to choose the new card from continually being produced.) The conceptual model, including its the location where he has just downloaded it from his IdP. security properties, are more important factors from a design The process in FileSpace will be very similar to that in perspective. A conceptual model can be mapped onto dozens of CardSpace, once the user his new identity PKC. The user contacts different protocols. his chosen IdP via his web browser and opens an SSL/TLS Here is one suggestion using existing standard protocols. Other session with it. The IdP asks the user to login by sending his protocol bindings can equally well be chosen. username and password across the encrypted link (as above). If We suggest the use of X.509 public key certificates (PKCs) for the user’s private key is stored in his browser then mutual identity files since these are ubiquitous. The user’s PKC could be authentication will have been performed automatically by a self issued public key certificate, or a CA issued PKC. It does SSL/TLS, allowing the SP to link the authenticated user to the not really matter which. It does not matter either what validated PKC. If the user has several pseudonyms (i.e. key pairs) distinguished name the public key certificate contains as long as it then the browser will have asked the user (as now) which identity is unique. IdP/AAs should refuse to issue authorisation credentials certificate he wished to use when establishing the SSL link. If the to names that they judge to be non-unique, misleading, or likely user’s private key is not stored in his browser, the IdP will need to to cause confusion to SPs. The PKC must contain a new X.509 display an upload window, allowing the user to select and send certificate extension which points to the private key store. This his PKC file to the IdP. From this, the IdP will determine the extension will need to be defined, and software will need to be location of the private key store and will send a challenge to it written to support it, both in adding it to new PKCs, and in asking for Proof of Possession to be returned. This may entail the reading it at relying parties. If open source software is provided, user entering his PIN into his private key device: mobile phone, this will ensure faster take up. smart card or ZTIC etc. Once the user and his pseudonym have been authenticated, the user is presented with a screen which asks We suggest the use of X.509 attribute certificates instead of him which attributes he wishes to include in his new authorisation signed SAML attribute assertions as the authorisation credentials. file. The user will tick the set of attributes he wishes to be Whilst SAML attribute assertions have several advantages over included and a download screen will then appear allowing the X.509 attribute certificates as follows: user to navigate around his local filestore and choose the location - they are an OASIS standard where his new authorisation file is to be deposited. Once he has - they have gained significant traction in the market place received the authorisation file he will logout of his IdP, and login - they are encoded in XML so that users can view (part to the next one to obtain the next authorisation file. If the user has of) their contents using simple text viewing tools, stored his IdP usernames and passwords in his browser’s although this would not verify their signatures nor encrypted password file, and his key pair in the browser, then the decrypt their encoded contents entire authentication process will be automatic. The user will only However, the major disadvantage with SAML assertions is that need to select the attributes he wishes to be included in his new there is no support for revocation in the OASIS standard. This is authorisation card. something of a showstopper until this feature is supported. 4.3 Using existing Cards and Files The advantages of using X.509 attribute certificates over SAML With CardSpace, the user contacts the SP requesting the service, assertions are as follows: whereupon his identity selector is activated and he is given the - they are encoded using ASN.1 in the same way as PKCs opportunity of choosing a single card to send to the SP. In so the same software can be used for processing both. CardSpace, the identity selector then asks the user for his Consequently no XML processing tools are required. username and password that go with this card, and these are - they are compact and much smaller than SAML relayed to the IdP. After a short delay, the user is returned to the attribute assertions SP’s site and the service is provided. - they can be used by mobile phones and other With FileSpace, the user contacts the SP and requests a particular constrained devices such as IBM’s ZTIC, since these service, whereupon the user is presented with an upload screen, already have the ability to use ASN.1 encoding and allowing him to select the authorisation files and PKC that he decoding, digital signing and signature validation wishes to present to the SP. The SP processes these files, - they outperform the use of XML signatures determines the location of the user’s private key store, and then - they already have standard fields defined for holding sends a message to this location. The device (web browser, revocation information mobile phone etc) pops up a message asking the user if he wants - it is an ISO/ITU-T standard to allow this SP to read these authorisation credential files. The - they are used in biometric certificates user checks the details and answers Yes, and in addition may be For either encoding, a special viewing tool is needed, so that required to enter his PIN, whereupon the device returns a signed when a user double clicks on a credential file, its contents are message to the SP and the SP provides the service to the user. displayed, including the encrypted fields which have been decrypted. Also its signature should be validated, rather like public key certificates are validated and displayed in today’s web 5. IMPLEMENTING THE MODEL browsers. This requires the user’s private key to be present, which Protocols and encoding schemes are not the real issues that will is not a problem if the private key is on a portable device like a affect user acceptance. Usability is. Protocols are relatively cheap smart card which can be attached to the viewing machine, but it is to define (although not necessarily to implement and deploy!) a problem if the private key is kept on a separate device such as a New protocols are being defined all the time. (Take a look at the mobile phone SIM card and the user is trying to view his number of Internet RFCs and OASIS standards that are being credentials elsewhere. For this reason the authorisation credentials 100 should have an optional clear text display field that the user or Providers over SSL/TLS. Alternatively, their browser can transfer issuer can choose to include when they are issued, and in which their public key certificate to the server and their private key the user or issuer can insert their own free form text. device can be asked to provide proof of possession of the private In terms of usability, we expect that users will have a password key by signing a challenge from the server. After receiving the manager in their web browsers in which they can store the POP, the IdP can mint the long lived authorisation credential, and multiple user names and passwords needed to authenticate to their allow the user to download it and store it on their local hard drive various IdPs. Most users already have this today. This gives them under whatever filename they wish (see Figure 1). From now on, an effective single sign on mechanism for getting their whenever the user contacts a service provider which requires a set authorisation credentials issued. The user can either generate their of user credentials, the user simply select the credential files they own X.509 key pair and certificate, or get one issued by one of wish to use through a typical file selection screen, and the the numerous CAs that currently exist, and store this in their browser will send these to the server. The server issues the browser (or preferably keep their private key in a hardware device challenge to the private key device, and this returns the signed connected via a PKCS#11 interface). If the user’s private key is response containing the decryption keys for the credentials. The accessible to the browser, then mutual SSL/TLS authentication user is assured that they are sending their consent to the correct can be performed when the user logs in to one of their Identity service provider, since the contents of the challenge (returned Table 1. Comparison of CardSpace and FileSpace Feature Information Cards/CardSpace FileSpace Modus Operandi Short lived authorization tokens issued on Encrypted long lived authz credentials issued by IdP/AA demand to user for passing to SP when to user to use as required and short lived authentication user authenticates to IdP/AA and decryption tokens issued on demand to SP by user Authz tokens are portable Yes, but might be difficult to move Yes, user simply copies files between devices identity cards to constrained devices Cards/Files open to attack? Cards (meta data) are open to attack Credential files are attack proof. Only the user’s private therefore they have to be strongly authentication key(s) need to be protected protected on the desktop and in the Identity Selector User authentication method at Any that the IdP corresponding to the User proves possession of his private key typically by service provision time selected card chooses to use. entering a PIN to his private key storage device Same authentication credentials No, user must use credentials required by Yes, user uses the same PIN for a given pseudonym for each SP session each card issuer regardless of which SP and IdPs are used User can use multiple No Yes authorization credentials from multiple IdPs per transaction User’s privacy is protected at Not always. In auditing mode, the IdP Yes. IdP is not aware which SPs user is talking to or the IdP? knows all the SPs that the user talks to when, unless it tracks OCSP requests (but SPs can use and when he does this. CRLs instead) User’s privacy is protected at Yes. The IdP can send a one off or Yes. The user determines his own pseudonyms to use the SP? permanent pseudonym when and where Single Sign On Yes but only for repeated use of same Yes, if private key store allows multiple accesses to card. Not if user wishes to use different private key after initial authentication e.g. input of PIN cards for different SPs User consent Yes, the user has to select a card before it Yes, the user must select the authz files and specifically can be used grant the SP the right to decrypt them Credential renewal required No, as short lived credentials are issued Yes, every time public key certificate expires new authz for each SP session, although IdPs may credentials are needed (typically annually) need to re-issue information cards periodically. Acquiring a new Not needed User generates his own key pair/PKC or asks a pseudonymous identity conventional CA to do this. Acquiring a new authorisation User logs into IdP and asks for a new User logs into IdP and asks for a new authorisation file credential managed card which is then imported into which is then copied to his local filestore. User may also his Identity Selector need to enter his PIN into his private key store in order to prove possession of pseudonym. 101 . credentials and SP’s name) can be displayed by either the 4, available at browser or private key device, before the user enters their PIN http://connect.educause.edu/Library/EDUCAUSE+Quarterl to unlock their private key. y/FederatedSecurityTheShibb/39889 (accessed 24 October 2008). 6. COMPARISON WITH CARDSPACE [5] David W Chadwick, Sean Anthony. “Using WebDAV for The table 1 provides a comparison of the FileSpace model with Improved Certificate Revocation and Publication”. In that of information cards and CardSpace. From this, it can be LCNS 4582, “Public Key Infrastructure. Proc of 4th seen that FileSpace has some advantages over CardSpace, in European PKI Workshop, June, 2007, Palma de Mallorca, terms of privacy protection, portability, usability during service Spain. pp 265-279. provision, and single sign on, but has a couple of disadvantages [6] ISO 9594-8/ITU-T Rec. X.509 (2005) The Directory: in that the user has to create her own pseudonyms first and Public-key and attribute certificate frameworks acquire new credentials periodically. [7] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, 7. CONCLUSIONS W. Polk. "Internet X.509 Public Key Infrastructure Whilst CardSpace has some notable and worthwhile security Certificate and Certificate Revocation List (CRL) Profile," and usability properties, nevertheless it has some significant RFC 5280, May 2008 drawbacks as described earlier. In this paper we have looked at [8] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, the problem of federated identity management from a different C. “X.509 Internet Public Key Infrastructure: Online perspective, namely, how can we build a system using a Certificate Status Protocol – OCSP”, RFC 2560, June paradigm that users are already comfortable with, namely 1999. computer files, and from this paradigm, how can we build in the [9] Thomas Weigold, Thorsten Kramp, Reto Hermann, Frank security and usability properties that are necessary for a global Höring, Peter Buhler, Michael Baentsch.“The Zurich identity management system. The resulting system, which we Trusted Information Channel – An Efficient Defence have cheekily called FileSpace, is one possible solution to this against Man-in-the-Middle and Malicious Software complex problem area. The usability advantages of FileSpace Attacks”. In P. Lipp, A.-R. Sadeghi, and K.-M. Koch are that during service provision, the user provides the same (Eds.): TRUST 2008, LNCS 4968, pp. 75–91, 2008. authentication token (typically a PIN) to the same device (his private key store) regardless of the SP or IdPs that are being [10] Landau, S. and Mulligan, D.K. “I’m used, whereas in CardSpace the user has to use the credentials Pc01002/SpringPeeper/ED2881.6; Who are You?”, IEEE of the particular managed card issuer for each service request. Security and Privacy, Vol 6, No 2, March/April 2008, Furthermore in CardSpace the user can only select one card, pp13-15 whereas with FileSpace the user can select as many [11] Dhamua, R. and Dusseault, L. “The Seven Flaws of authorisation files as are required. The procedures for obtaining Identity Management”, IEEE Security and Privacy, Vol 6, a new authorization file or managed card are very similar in No 2, March/April 2008, pp24-29. terms of usability and neither system has an advantage. The [12] William E. Burr, Donna F. Dodson, Ray A. Perlner, W. disadvantage of FileSpace is that the user has to create one or Timothy Polk, Sarbari Gupta, Emad A. Nabbus. more pseudonymous identities, in terms of key pairs and PKCs, “Electronic Authentication Guideline”, NIST Special before he can use the system. This step is not necessary for Publication NIST Special Publication 800-63-1, Feb 2008 CardSpace. [13] Directive 95/46/EC of the European Parliament and of the 8. REFERENCES Council of 24 October 1995 on the protection of [1] David Chappell. “Introducing Windows CardSpace”. individuals with regard to the processing of personal data MSDN. April 2006. Available from and on the free movement of such data. Available from http://msdn.microsoft.com/en-us/library/aa480189.aspx http://ec.europa.eu/justice_home/fsj/privacy/law/index_en. htm [2] S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. “Internet X.509 Public Key Infrastructure [14] Arun Nanda. "Identity Selector Interoperability Profile (PKI) Proxy Certificate Profile”. RFC3820, June 2004. V1.0" April, 2007. Microsoft Corporation. [3] OASIS (2005) “Security Assertion Markup Language [15] Arun Nanda, Michael B. Jones. "Identity Selector (SAML) V2.0”, March, available at Interoperability Profile V1.5" July 2008. Microsoft http://saml.xml.org/saml-specifications (accessed 24 Corporation October 2008). [16] D. Mundy and D.W. Chadwick. "An XML alternative for [4] Morgan, R. L., Cantor, S., Carmody, S., Hoehn, W., and performance and security: ASN.1." IEEE IT Professional, Klingenstein, K. (2004), “Federated Security: The 6(1):30-36, 2004. Shibboleth Approach”, Educause Quarterly, Vol. 27, No. 102 FileSpace An alternative to CardSpace that supports MultipleToken Authorisation and Portability Between Devices David Chadwick University of Kent 17 April 2009 NIST IDTrust 2009 1 Contents • Problem statement and solution idea • User experiences of using InfoCards and FileSpace – At service provision time – At Card/File issuing time • Technical properties of FileSpace • Detailed Comparison of FileSpace and InfoCards • Conclusion 17 April 2009 NIST IDTrust 2009 2 Problem Statement • A user typically has multiple cards – today each plastic card issuer only puts one attribute on a card, Visa member, AAA frequent flyer, IEEE member etc. so why expect that in InfoCards all this information will be on one card. It wont. • But she can only use one of these cards in any given InfoCard/CardSpace transaction • Insufficient for many purposes – buy a book at a discount using Visa card and student card – access patient data using Doctor card and hospital employee card • Users need to be able to select/present multiple cards • Cards may not be easily transported to all devices – e.g. use on a mobile phone – initial version of CardSpace did not have an export capability 17 April 2009 NIST IDTrust 2009 3 Solution Idea • Instead of cards, use files • Files are an existing well known concept to all computer users • Users are already familiar them, know how to drag and drop, copy, delete them etc. • So if every credential (plastic card) becomes a file, then user can copy them easily between devices, send multiple files to service providers etc. 17 April 2009 NIST IDTrust 2009 4 Example user’s directory with FileSpace files 17 April 2009 NIST IDTrust 2009 5 Comparison of User Experiences - at Service Provision Time LOGIN InfoCard FileSpace Click 17 April 2009 NIST IDTrust 2009 6 User Selects FileSpace LOGIN InfoCard FileSpace 17 April 2009 NIST IDTrust 2009 7 User Selects Files To Upload LOGIN InfoCard FileSpace 17 April 2009 NIST IDTrust 2009 8 User is asked to Confirm he is Father Christmas LOGIN InfoCard FileSpace 17 April 2009 NIST IDTrust 2009 9 User’s Private Key could be in a hardware token IBM’s ZTIC USB device Mobile Phone 17 April 2009 NIST IDTrust 2009 10 User is provided with service 17 April 2009 NIST IDTrust 2009 11 Comparison of User Experiences - at Service Provision Time LOGIN InfoCard FileSpace Click 17 April 2009 NIST IDTrust 2009 12 User is asked to choose a single InfoCard 17 April 2009 NIST IDTrust 2009 13 User is asked to provide password for card provider 17 April 2009 NIST IDTrust 2009 14 User is provided with service 17 April 2009 NIST IDTrust 2009 15 User Experience at Enrolment e.g. to get an electronic MasterCard User must Login to his account (over SSL) 17 April 2009 NIST IDTrust 2009 16 Then Ask For Electronic Card/File to be Created • User may need to select which attribute(s) to be included or IDP may choose them • In FileSpace, there is an additional step of sending your Certificate (e.g. Father Christmas) and proving ownership 17 April 2009 NIST IDTrust 2009 17 Then Select Where to Download File To 17 April 2009 NIST IDTrust 2009 18 In CardSpace User then has to Import file into Card Selector 17 April 2009 NIST IDTrust 2009 19 Creating a New Identity • In CardSpace we have self issued cards, whereby a user enters his own attributes into his cards • In FileSpace we have new identity cards, either self issued (e.g. Father Christmas) or issued by a CA such as Versign (e.g. my Bill Gates cert) (so not much difference there then !) 17 April 2009 NIST IDTrust 2009 20 Basic Principles of FileSpace • Clearly Separate Authentication from Authorisation by having separate tokens • Have multiple Authz Tokens linked to one Authn Token – Each Authz Token provides an attribute assertion from a trusted authoritative source • Have one Authn Token per Pseudonym – this is purely a handle on which to hang the Authz tokens. The pseudonym can be anything – user can have as many pseudonyms as he wishes 17 April 2009 NIST IDTrust 2009 21 Token Lifetimes • All FileSpace tokens are long lived and can be used repeatedly – User has to authenticate to service provider that he is the holder of all of them at time of use • In CardSpace all tokens are short lived and issued on demand – this requires authn to the card issuer each time a service is required • Each FileSpace Authz Token can be independently revoked by the issuer (AA) – so if user looses his private key he can ask AAs to revoke his authz credentials (no need to revoke authn credential) 17 April 2009 NIST IDTrust 2009 22 Authn Tokens • Public key certificate containing any subject DN the issuer chooses to put there, subject to it being globally unique (which is mandatory in X.509 anyway!!) • Can be user generated (self issued) – unique DN can be generated by having public key id RDN + user provided CN RDN • Can be CA generated – unique DN can be CA name plus user provided CN RDN • It does not matter since it is not used for authorisation, only for authentication • Contains a pointer to where relying party can find private key in order to validate that the current user is the holder of the private key – solves the Discovery problem – could be mobile phone number, or “user’s browser” 17 April 2009 NIST IDTrust 2009 23 Authz Tokens • Are standard claims/assertions/certificates that say this subject has this attribute, signed by issuer • However, subject id and attribute are encrypted (indirectly) to key public key of subject – Can be lost or stolen but are worthless to finder/thief because he cant decrypt them • Only valid once subject proves to RP that he has the decryption key • In practise we encrypt to a symmetric key and encrypt symmetric key to public key of subject then subject can decrypt symmetric key and encrypt it to public key of RP allowing RP to read the contents 17 April 2009 NIST IDTrust 2009 24 Service Provision • User selects set of Authz Tokens and the matching Authn Token to send to service provider (through file upload function) • SP reads location of private key from Authn token and sends a message containing tokens and asking for decryption keys • User is asked to confirm SP can have these tokens, then enters PIN to private key and device creates decryption keys for the SP and returns them 17 April 2009 NIST IDTrust 2009 25 Protocol Exchange • SP-> private key location: {{authzCredi} i=1 to n, nonce1, ts1, SPPKC}signSP • Private key location -> SP: {{sni, encKeyi} i=1 to n, nonce1, nonce2, ts2, SP}signUser • Where: – n is the number of authorisation credentials to be decrypted – SPPKC is public key certificate of Service Provider – nonce is a random number and ts is a short time in the future (say 2 seconds) – sni is serial number of ith authorisation credential – encKeyi is symmetric key used to encrypt the contents of authorisation credential i, encrypted to the public key of the recipient SP 17 April 2009 NIST IDTrust 2009 26 Detailed Comparison (1) Feature Information Cards FileSpace CardSpace Modus Operandi Short lived authorization Encrypted long lived authz tokens issued on demand by credentials issued by IdP to user to IdP to user for passing to SP use as required and short lived when user authenticates to authentication and decryption tokens IdP/AA issued on demand to SP by user Authz tokens are portable Yes, but might be difficult to Yes, user simply copies files between devices move identity cards to constrained devices Cards/Files open to Cards (meta data) are open to Credential files are attack proof. Only attack? attack therefore they have to the user’s private authentication be strongly protected on the key(s) need to be protected and desktop and in the Identity these can be stored in hardware Selector User authentication Any that the IdP User proves possession of his private method at service corresponding to the selected key typically by entering a PIN to his provision time card chooses to use. private key storage device Same authentication No, user must use credentials Yes, user uses the same PIN for a credentials for each SP required by each card issuer given pseudonym regardless of session which SP and IdPs are used 17 April 2009 NIST IDTrust 2009 27 Detailed Comparison (2) Feature Information Cards FileSpace CardSpace User can use multiple No Yes authorization credentials from multiple IdPs per transaction User’s privacy is Not always. In auditing mode, Yes. IdP is not aware which SPs user is protected at the IdP? the IdP knows all the SPs that talking to or when, unless it tracks OCSP the user talks to and when he requests (but SPs can use CRLs instead) does this. User’s privacy is Yes. The IdP can send a one Yes. The user determines his own protected at the SP? off or permanent pseudonym pseudonyms to use when and where Single Sign On Yes but only for repeated use Yes, if private key store allows multiple of same card. Not if user accesses to private key after initial wishes to use different cards authentication e.g. input of PIN for different SPs User consent Yes, the user has to select a Yes, the user must select the authz files card before it can be used and specifically grant the SP the right to decrypt them 17 April 2009 NIST IDTrust 2009 28 Detailed Comparison (3) Feature Information Cards FileSpace CardSpace Credential renewal No, as short lived credentials Yes, every time public key certificate required are issued for each SP expires new authz credentials are session, although IdPs needed (typically annually) may need to re-issue information cards periodically. Acquiring a new Not needed User generates his own key pair/PKC or pseudonymous asks a conventional CA to do this. identity Acquiring a new User logs into IdP and asks User logs into IdP and asks for a new authorisation for a new managed card authorisation file which is then copied credential which is then imported into to his local filestore. User may also his Identity Selector need to enter his PIN into his private key store in order to prove possession of pseudonym. 17 April 2009 NIST IDTrust 2009 29 Merging InfoCards and FileSpace David Chadwick 17 April 2009 NIST IDTrust 2009 30 Conclusion • FileSpace overcomes a major disadvantage of CardSpace/InfoCards, that of not being able to send multiple cards • FileSpace does not lose out on usability since users already know how to use files (and it could be integrated into Card Selectors) • It has a number of security advantages as well – better privacy protection at the IdP – don’t need to worry about securing the desktop (unless private keys are held there) 17 April 2009 NIST IDTrust 2009 31 Any Questions? 17 April 2009 NIST IDTrust 2009 32 Authorization Models Radia Perlman Radia.Perlman@sun.com 1 Important problems • Something that is understandable for someone to manage the policy • Something that is efficient for a system to check policy – checking if A is allowed to do X when A asks to do X – checking everything A is allowed to do – checking who is allowed to do X • Updating policy (including revocation) must be comprehensible, efficient, and timely 2 Stake in the ground • Basically, most models map to groups and ACLs 3 ACLs • Associated with each resource is an ACL – set of (Who, what they can do) – Note: “resource” can be a set of resources, all with a common ACL • Can be fancier – other things like time of day, IP addresses from which things must be accessed 4 What is who? • Any Boolean combination of – Individuals – Groups – “Roles” • Groups and roles are also any Boolean combination of individuals, groups, and roles • Which means groups can be arbitrarily nested 5 Nested groups Sun employees Sun-MA Sun-CA Sun-MPK Sun-SJC 6 Roles vs Groups • Mostly in the literature used interchangeably • Possible distinctions – Roles have to be explicitly invoked, and might be mutually exclusive, and might require authentication, vs groups: always a member of all groups you are a member of – Roles have names (like “administrator”) that are local to a resource 7 Attributes • Can be treated like a group • “over 21” can be “set of people over 21” • “paid member of ACM” can be “set of people who have paid ACM membership” 8 Models around “what is A allowed to do” • Really not “centrally controlled” • Only within a “scope” • Just like ACL on a file – Alice: read, write – Bob: read – Carol: read, write, delete 9 Proving membership • Could have some things in your (name/key) cert • Or could have a separate credential – Such as a cert vouching: • (public key, attribute/group name) • (name, attribute/group name) – Or knowledge of a group secret – Or coming from an IP address in the US • Note: authorization doesn’t necessarily imply you have to identify yourself 10 X.509 attribute cert model • Attribute, like “clearance”, has an OID • You need a separate PMI (privilege management infrastructure) starting with a SOA (start of authority) to vouch for the attribute • You’d say “I trust US navy” for clearance 11 Name-based model • Hierarchical name • Name of attribute implies who is trusted to assert it • gov.US.navy.clearance is a totally different attribute from gov.Russia.KGB.clearance 12 Name based trust chains, both for identity and authorization 13 Bottom-Up Model • Each arc in name tree has parent certificate (up) and child certificate (down) • Name space has CA for each node • “Name Subordination” means CA trusted only for a portion of the namespace • Cross Links to connect Intranets, or to increase security • Start with your public key, navigate up, cross, and down 14 Intranet abc.com nj.abc.com ma.abc.com alice@nj.abc.com bob@nj.abc.com carol@ma.abc.com 15 Extranets: Crosslinks abc.com xyz.com 16 Extranets: Adding Roots root abc.com xyz.com 17 Conclusion • Groups, ACLs, Identities have been around for years • Can do anything that the other models do 18 Aligning Access Control models with Attributes (RBAC, ResBAC, RiskBAC, TrustBAC & ABAC) IDTrust 2009, 15th April Rakesh Radhakrishnan Principle Architect (Telco) Technology Lead (OpenSSO) Sun Microsystems, Inc. 1 Agenda • Context Aware Security (Adaptive AuthN+ AuthZ) • The 5 AC models • Aligning the AC models • Aligning AuthN with AuthZ • Alignment using Attributes 2 Context Aware Security • Adaptive AuthN (takes into account context and risk) • Adaptive AuthZ (policy based adaptation of AC models) • Alignment of Network, Resource and Service policies with Users • Emphasis is on multiple Attribute Authorities Assertions • Implementation via Abstraction and Master/Macro PDP Context Aware Security Context Aware Security • Takes into account Risk (Risk Model, Risk Levels) • Takes into account Mobility Context (location, device, etc.) • Takes into account User Identity+ Profile/Preferences • Takes into account Real-time Context (Date/Time, TranAmt, etc.) • Takes into account Historical Context (Reputation) RBAC • Role is an Identity Attribute (separation of duty) • Role mining, discovery, mapping, hierarchy, etc. (full life cycle) • Persona (social context), Role (business context) • Role based Provisioning, Role based BP, Role based IT P • Role to Rule to Resource ResBAC • Resource Classification, Categories and Compartmentalization • Resource specific Rules (and life cycle management) • Resources can be a Service (JEE/.NET, VM, OS, NE, Data, etc.) • Labeling, Tagging, Resource specific Risks, Res based AuthN • Resource Classification based Negotiations RiskBAC • Risks at the Network Level (network threat levels) • Risks at the User Level (Reputation) • Device Risks (NAC, Client FW) • Risks at the Transaction Level (value) • Historical Risk Data TrustBAC • Trust based on TPM, TSS, TNC, etc. (Technical Trust) • Trust based on Relationships (Business Trust) • Trust Levels based on Resource Consumed & Risk Factor • Highly Aligned to Resource and Risk Levels • TrustBAC – Dr. James Joshi's work -leading edge ABAC • Role and Persona as an Attribute • Resource Classification and Category as an Attribute • Assurance Level, Risk Level & Trust Level as an Attribute • Device and Location data as Attributes • Reputation Ratings as an Attribute Alignment (Federated ID System) Alignment (with Policies) Alignment with Attributes/XACML • Encapsulates RBAC, ACI, ACL, DAC, MAC, etc. • Specialized PDP's (OS/VM, DLP, JEE/.NET, etc.) • Attribute based Access Control implemented with XACML • Policy Orchestration (Network facing to Service facing) • Alignment of AC Model – Cumulative from RBAC/ResBAC + RiskBAC/TrustBAC Relevance • Relevant for Contextual COMPOSITION (SOA) • Relevant for Convergence (Multi-media Broadband Networks) • Relevant in Health care (Network of Networks) • Relevant for eGOV and Emergency Services • Federated Identity/Attributes as the Foundation for Federated Context 14 In Defense of Role-based Access control with Enhancements (RBAC PLUS) R. Chandramouli (Mouli) mouli@nist.gov ID Trust 2009 April 13,15 - 2009 NIST, Gaithersburg, MD, USA 1 Entitlements (or) Authorizations – Current Reality 1. Have to demonstrate that they meet certain compliance Requirements 2. Hence have to be policy driven 3. Inevitably end up being fine-grained & state-based 4. Fine-grained & state-based means that they are based on Attribute values that can change - Attributes of the User, Subject or Device - Attributes of the Resource being accessed 2 A New Perspective on Old Access Control Models Access Control Model Attribute & State 1. Access control Lists (ACLs) (a) Object-Centric. (b) Object Attribute - None. (c) User Attribute – Name and/or Group Membership (Static) 2. Protection Bits (a) Object-Centric (b) Object Attribute – None (c) User Attribute – Group Membership and/or Owner Status (Static) 3 A New Perspective on Old Access Control Models – Contd .. Access Control Model Attribute & State 3. Discretionary Access Control (a) Object-Centric. Model (DAC) (b) Object Attribute - None. (c) User Attribute – Owner, Grantee or Admin Status (Static) 4. Bell-LaPadula Model (a) Both Subject (User) & Object- Centric (b) Object Attribute – Sensitivity Level (Static) (c) User Attribute – Clearance Level (Static) 4 How Does RBAC Compare UA Role PA Permission User Entities – User, Role and Permission have no attached attributes in ANSI Standard RBAC Relations or Associations - UA and PA – Static Assignments BUT 1. The Tight Coupling of User-Resource is removed by abstraction mechanisms such as ROLES – Grouping Permissions aligned to Business Process and PERMISSION – Object-Operation Pairs 5 How Does RBAC Compare – Contd .. UA Role PA Permission User 1. Parameterize the Entities - Attaching Attributes to User, Role and Permission 2. Make Associations UA and PA dynamic by consulting a rule- base (defined using XACML) You have Fine-grained Dynamic Entitlements based on Attributes driven by Policies expressed using Rule Sets6 How Does RBAC Compare – Contd .. Entity & Attributes Entitlements resulting from Policy Rule Instantiation Entity – Role – Teller Access Restricted to MD Attribute – Region = MD Customer Accounts Entity – Objects underlying Restricts Access only to Permissions Assigned Roles (Dynamic PA) Attribute – Privacy Labels Entity – User Restrict or Deny Access to Attribute – Location certain Resources/Objects Domain State Attributes Physician Role’s entitlements -Physician’s Current Duty restricted to EMRs of Patients Station in a particular Duty Station -- Patients in Duty Station 7 Conclusion • Enhancements to an Access Control Model that provides abstraction mechanisms such as RBAC can support fine-grained Policy Compliant Entitlements • Still some Deployment Issues Remain – e.g., Role Engineering (in spite of tools for Role Mining etc) • Enhancements such as Parameterized Roles do address issues such as Role Proliferation or Role Explosion. • Support for Other Policies such as Least Privilege, Separation of Duty are well known. • Landscape is not that Gloomy as there are reports of successful implementations of ROLES + RULES paradigm in some large Fortune 500 Corporations. 8 IDTrust 2009 Comparative Authorization Models Tim Brown – VP Chief Architect Security CA Security Launch, April '09, Company Confidential How do we get the Authorization issue under control Identity Role & Compliance Implement an Identity Management Management Lifcycle Management process Role Management •Clean-up existing roles/privileges Move towards business Roles Identity •Correlate accounts to unique IDs •Conduct role discovery Management •Adapt model as business changes Implement sound • Assign users to roles authorization processes • • Apply role-based controls Provision users, accounts, Mo privileges del Move towards new Manage change requests and • approvals Identity Compliance Authorization models • Password & registration self- service Ma • Certify user/resource/role entitlements nag • Establish centralized identity e policies • Detect segregation of duties violations • Monitor reports/dashboards Vali dat e CA Security Launch, April '09, Company Confidential Move towards Business Roles and delegated administration model > Move towards Business Roles • Enriches identity-related business processes with real-time analytics • Simplifies user experience • Improves quality of access rights • Preventative controls > Delegate Role creation and Authorization roles to appropriate party • Suggesting roles • Identifying policy violations during provisioning • Highlighting out-of-pattern entitlements Smarter with Suggest Roles Button CA Security Launch, April '09, Company Confidential Embrace new technology > Attribute/Claims Based Identity services will help  More flexibility  More user Control  Additional weighting and risk management > But will come at a cost  New model with more flexibility  Authorization model needs to be redefined  Business models need to adapt to new models > Few Relying Parties accepting Claims > Few trusted Identity Providers none willing to accept liability Smarter with Suggest Roles Button CA Security Launch, April '09, Company Confidential Defensive PKI (What happens when PKI fails?) Kelvin Yiu Steve Whitlock Tim Polk Carl Ellison 1 The Problem • Dec 2008: Exploitation of MD5 collisions • May 2008: Debian (OpenSSL) RNG error • What’s next? – Hash 2nd pre-image attack? – Dead key length? – Dead PK algorithm? • The infrastructure is “too big to fail” • What do we do about it? 2 Defensive PKI (What happens when PKI fails?) Kelvin Yiu Steve Whitlock Tim Polk Carl Ellison 3 Microsoft’s Response Options 1. Remove affected root CA certificates (nuclear option #1) 2. Disable MD5 in certificate validation (nuclear option #2) • Also break CAs that use non-random serial numbers 3. Work with affected CAs to update their infrastructure before attack is practical to others • Trust Sotirov and team, and the security of their PS3 cluster Constraints  Cannot break millions of users (without sufficient justification) • Certificate error UX in latest browsers is very effective in stopping users • Previously issued certificates were not vulnerable • Did not affect all CAs that use MD5 • Many long lived subordinate CA certificates use MD5 How Microsoft responded to the MD5 collision attack • Microsoft immediately contacted affected CAs to assess situation – CAs were cooperative, but needed more time than usual because attack was announced over the holidays – Quick engineering fix, but long QA cycle • Asked all CAs in our “Root CA Program” to provide information on crypto algorithms in use – 52 out of 80 CAs responded. The rest needed more time to gather information – Request includes the CA’s use of 1024 bit RSA and MD5 in their hierarchy – Most newer CAs have issued with SHA1 only – Most have already switched to SHA1 Some Observations… • Revocation was not designed to handle pre-image attacks against hash algorithms – Old expired certificates are vulnerable – Rogue certs will not contain a CDP – CAs revoke by specifying a serial number, but serial number could be changed – Path validation code cannot require CDP since CDP is not present in many intermediate CA certs • Subordinate CA may be signing new certificates with SHA-1, but its own certificate may have been issued a lot time ago and still uses MD5 – Reissuing a subordinate CA certificate may trigger audit – Distribution of new root and subordinate CA certificates is very difficult and time consuming – Not scalable for MS to distribute sub-CA certs through Windows Update • From the experience with the Debian bug, replacing certs would be a very slow process. http://www.eweek.com/c/a/Security/CAs-Not-Getting-Big-Response-to- Debian-Encryption-Flaw/ Defensive PKI (What happens when PKI fails?) Kelvin Yiu Steve Whitlock Tim Polk Carl Ellison 7 The Minor Issues • Usability that degrades trust – Should I accept the NIST certificate? – Now, where did I write down the password protecting my private key? • Fragility – Oops, my root CA certificate expired… – My applications were blocked because their server certificates expired • Our business partners assumed that authentication == authorization • How do I upgrade the hash algorithms (as opposed to how do I get a good one – see Majors) 8 Defensive PKI (What happens when PKI fails?) Kelvin Yiu Steve Whitlock Tim Polk Carl Ellison 9 Defense Begins at Home • Relying Parties have ultimate responsibility to ensure a certificate is acceptable • Acceptability decisions might be based on – Policy – Certificate status – Trust anchor • But these tools are not enough! – Lifecycle issues, crypto issues not adequately addressed 10 Cryptographic Lifecycle • Cryptographic Migration is part of the Lifecycle of a system, but is always an afterthought in the implementation – This is not unique to PKIs! Think about DES… • Migration timelines may vary by application – E.g., NIST SP 800-78-1 requires use of • 2048 bit RSA for signatures after 12/31/2010 • 2048 bit RSA for authentication after 12/31/2013 11 Overreliance on Policy Leaves Relying Party at Risk • Relying parties depend on policies (implicitly or explicitly) to ensure that key sizes and hash algorithms provide acceptable levels of security – This is not agile, and may be inexact on details that matter to your application! • policy mapping can be more abstract, ignoring small discontinuities – To increase security and agility, relying parties need crypto based acceptance controls • Algorithm, key length, parameters 12 Defensive PKI (What happens when PKI fails?) Kelvin Yiu Steve Whitlock Tim Polk Carl Ellison 13 It’s a fault tolerance problem • We know how to do fault tolerance. – Keep running in spite of failures! • The failures we need to address are: – Bad specific key(s) – Bad key length – Bad algorithm • Revocation – Flawed – Not fault tolerant 14 Straw-man Solutions • Enroll not for 1 certificate but for a binding – and get multiple certificates, with different algorithms and keys, as they come available, during the lifetime of the binding. • Get not one timestamp but a living sequence of timestamps, each with a newer, better algorithm or key (and sacrifice blindness). • Fix revocation – CDP today in the attacked certificate – Revoke keys, algorithms, key lengths; not just certs • We need to choose authorities and channels for those 15 Q&A 16 Usable Secure Mailing Lists with Untrusted Servers Rakesh Bobba, Joe Muggli, Meenal Pant, Jim Basney and Himanshu Khurana University of Illinois, Urbana-Champaign {rbobba, jmuggli, mpant, jbasney}@ncsa.uiuc.edu, hkhurana@iti.uiuc.edu ABSTRACT 1. INTRODUCTION Mailing lists are a natural technology for supporting messag- As more and more user communities are engaging in col- ing in multi-party, cross-domain collaborative tasks. How- laborative tasks, use of Email List Services (or simply Mail- ever, whenever sensitive information is exchanged on such ing Lists - MLs) is becoming common; i.e., emails exchanged lists, security becomes crucial. We have earlier developed a with the help of a list server (examples of commonly used list prototype secure mailing list solution called SELS (Secure server software include Mailman and Majordomo). Many Email List Services) based on proxy encryption techniques tasks where MLs are used require exchange of private in- [20], which enables the transformation of cipher-text from formation, especially those that involve messaging in col- one key to another without revealing the plain-text. Emails laborations across multiple administrative domains. For ex- exchanged using SELS are ensured confidentiality, integrity, ample, a ML of security administrators that manage critical and authentication. This includes ensuring their confiden- infrastructure would not want their emails disclosed to hack- tiality while in transit at the list server; a functionality that ers. Specific instances include the multi-domain Open Sci- is uniquely supported by SELS through proxy re-encryption. ence Grid (http://www.opensciencegrid.org/) and Tera- In this work we describe our efforts in studying and enhanc- Grid (http://security.teragrid.org/) systems where the ing the usability of the software system and our experiences Incident Handling and Response policies recommend the use in supporting a production environment that currently is of encrypted and signed mailing lists. In general, use of used by more than 50 users in 11 organizations. As evidence encrypted and signed lists is recommended for incident re- of its deployability, SELS is compatible with common email sponse by IETF [5] and CERT [31]. Additional examples in- clients including Outlook, Thunderbird, Mac Mail, Emacs, clude a list of (1) health care and pharmaceutical researchers and Mutt. As evidence of its usability, the software is being who want to protect patient privacy, (2) corporate execu- used by several national and international incident response tives who want to protect proprietary information, and (3) teams. researchers engaged in collaborative research involving mul- tiple university, government and industry institutions who want to protect their intellectual property. Categories and Subject Descriptors For such MLs cryptographic solutions are needed that pro- H.4.3 [Information Systems Applications]: Communi- vide adequate protection (i.e., confidentiality, integrity, and cations Applications—Electronic Mail ; H.5.2 [Information authentication) for the private content from threats at the Interfaces and Presentation]: User Interfaces—Evalua- client side, at the network paths where the emails are in tion/methodology; E.3 [Data Encryption] transit, and at the server side where the emails are pro- cessed for distribution to the list. That is, there is a need to General Terms develop Secure Mailing Lists (SMLs) as illustrated in Fig- ure 1. Threats to the server side are an important concern in Design, Security, Human Factors practice and lack of good solutions today has forced users to develop their own clunky ones. For example, several critical Keywords infrastructure security protection groups today use out-of- E-mail List Security, Proxy Re-encryption, Usability study band means to distribute passwords to members and require members to use password-based-encryption (supported by commonly available GnuPG plug-ins) so that the list server does not have access to email plain-text, minimizing the trust that must be placed in the mail server. To address this challenge for mailing lists we have ear- lier developed a prototype SELS (Secure Email List Ser- Permission to make digital or hard copies of all or part of this work for vice) [20]. The SELS protocol and software prototype sat- personal or classroom use is granted without fee provided that copies are isfy requirements in the categories of security properties (i.e., not made or distributed for profit or commercial advantage and that copies confidentiality, integrity, and authentication), infrastructure 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 specific compatibility, key management and performance. For con- permission and/or a fee. fidentiality SELS uses proxy encryption techniques that al- IDtrust ’09 Gaithersburg, MD low the list server to transform email cipher-text between list Copyright 2009 ACM 978-1-60558-474-4 ...$5.00. study. The study allowed us to evaluate and enhance the usability of SELS key management by (1) exploring two al- ternate key trust establishment techniques, (2) developing an effective password management solution that balances usability and security, and (3) identifying suitable interface cues that can be introduced to mitigate remaining vulnera- bilities in environments where new software or plug-ins can be deployed. A fully functional version of the software has been pack- aged and released for community use.1 We are actively sup- porting the software via a public email list and making new releases to fix bugs and add features. Our first user commu- nity is incident responders and several national and interna- tional incident response teams have adopted SELS for email exchange. Currently, these include the TeraGrid Security Working Group and the International Grid Trust Federation (http://www.igtf.net/). We report on our experiences in supporting the TeraGrid Security WG for a period of ten months. We present SELS usage statistics, discuss usability and security issues observed in practice and present soft- ware engineering enhancements. Success of SELS is clearly indicated by the fact that there has been a nearly four-fold increase in the number of encrypted emails exchanged by the TeraGrid users since they adopted SELS, with anecdo- tal evidence suggesting that this increase is largely due to Figure 1: Secure Mailing Lists better usability provided by SELS. The rest of this paper is organized as follows. In Section 2 we give an overview of the SELS protocol and software prototype. In Section 3 we evaluate the usability of SELS. members without gaining access to the plain-text. Proxy en- In Section 4 we describe the SELS production environment cryption techniques have been studied for over a decade [1, and our experiences with supporting the TG Security WG. 2, 7, 15, 17, 18, 22, 35] and have been used to design several In Section 5 we discuss related work and conclude in Section applications including simplification of key distribution [2], 6. key escrow [17], file sharing [1], security in publish/subscribe systems [19] and multicast encryption [8]. SELS builds on COTS components to maximize ease of deployment. In par- 2. SELS OVERVIEW ticular, we were able to use the OpenPGP message format In this section we provide an overview of the SELS system [6] and standard GnuPG plug-ins at the client side which architecture focusing more on the list subscriber interaction. facilitated deployment by eliminating the need for develop- We refer the reader to [20] for further details. SELS pro- ing and distributing email-client specific plug-ins. We have vides confidentiality, integrity and authentication for emails implemented the protocol and the system using the Mail- exchanged in a mailing list via public key encryption and man list server, GnuPG and BouncyCastle cryptographic signing by interactions among the following entities. libraries, and standard GnuPG plug-ins and APIs. SELS is viable in enterprise settings, has compatibility with Mi- • List Moderator (LM). LM is a user (or process) that crosoft Outlook, Emacs, Mac Mail, Mutt and Thunderbird, creates a list to be maintained at the list server, au- and has performance that scales to support enterprise mail thenticates users, and helps them subscribe to and un- servers that process hundreds of thousands of emails per day. subscribe from the list. In this work we focus on usability and deployment expe- riences with SELS. We conducted a usability study whose • List Server (LS). LS creates lists, maintains member- high-level goals were to evaluate and enhance the usability ship information (email addresses and key material), (i.e., effectiveness, efficiency, and satisfaction) of the SELS adds and removes subscribers based on information re- key management system for list subscribers with the strong ceived from LM , and forwards emails sent by a valid preference that the solution be compatible with commonly list subscriber to all current subscribers of that list. used email clients. Given this preference we further refined the goals as follows. First, to identify SELS key management • Users/Subscribers. Users subscribe to lists by sending tasks that pose usability challenges across several common join requests to LM and send emails to the list with email clients. Second, to determine the ability of users to the help of LS. complete key management tasks, how much time they take The first major goal of SELS is to minimize trust in LS in doing so, and how satisfied they are with the software. such that LS is unable to access email contents while still Third, to assess how usability is influenced by familiarity providing the necessary list management and email forward- with specific email clients, underlying security tools and ing capabilities. As mentioned in the Introduction, threats learnability. Fourth, to determine if SELS introduces ad- to LS are an important concern. First, compromise of a ditional vulnerabilities for its users. To address these goals 1 we combined several usability techniques in executing this Available at http://sels.ncsa.uiuc.edu ties. The developed components for LM and LS use open- source GnuPG and Bouncycastle libraries as well as GnuPG key management functions. In the world of secure email, OpenPGP and S/MIME are competing standards with native support of S/MIME in email clients being more prevalent. The proxy encryption technique used in SELS requires transformation of text be- tween two public keys, which, in turn, requires that the keys share common parameters. The chosen cryptosystem, ElGa- mal, easily supports this as it is a group based cryptosystem. However, with the RSA cryptosystem this would imply that the modulus be shared between multiple key-pairs, which is inherently insecure. S/MIME supports RSA but not El- Gamal (specifically for message encryption), limiting SELS Figure 2: SELS Protocol Overview compatibility to OpenPGP for now. Recently, Elliptic Curve Cryptography (ECC) has been added to S/MIME standards and is also being supported by some email clients. ECC is trusted list server by an attacker could result in signifi- also a group based cryptosystem, therefore, it will enable the cant disclosure of sensitive information. Second, for lists proxy encryption technique to be employed. In the future with members from multiple organizations, it is difficult to we plan to support ECC and, in turn, achieve compatibility trust a single organization to host the list server. Tradi- with S/MIME for broader adoption of SELS. tional solutions that provide server-side protection tend to have a high overhead for key management. For example, the common practice of out-of-band password distribution for password-based encryption requires users to remember a long list of passwords to decrypt previously sent emails. Instead, SELS achieves this via proxy encryption where LS re-encrypts messages between list subscribers by using proxy private keys but without requiring access to the plain-text. A high-level view of the three-step SELS protocol is pre- sented in Figure 2. In the first step LM and LS create a list L, which involves them establishing an ElGamal key pair each for the list and distributing the list public key com- puted to be the product of their public keys. Note that no single entity has access to the list private key, KL . In the second step, users subscribe to list L by contacting LM. LM creates a key pair for each user and sends it to that user. In addition, LM sends keying material to LS, which allows LS to establish the private proxy key for that user. These keys are all computed from LM and LS’s list keys by simple addi- tion and subtraction of random numbers to ensure that the sum of each user’s private and private proxy keys is the list private key, KL , originally established by LM and LS. This Figure 3: Component Architecture invariant allows for the proxy re-encryption process to exe- cute correctly. In the third step, users send email encrypted We conducted a performance evaluation of SELS and fo- with the list public key, P KL , and optionally signed by their cused on the most expensive operation − the proxy transfor- own private keys. LM executes proxy re-encryption on these mation step at the list server. Consequently, we measured emails once for each subscriber and sends the output to that throughput of the list server with varying list sizes and mes- subscriber. Each subscriber can then decrypt the message sage sizes. Overall, we saw that even the worst through- with their private key. put of 2.5 messages/sec for SELS with list size 10 and mes- The second major goal of SELS is to drive the design sage size 100KB corresponds to a throughput of more than and development process with deployability and adoption in 200,000 messages per day. Since most mail servers in small mind. To that end SELS (1) uses the OpenPGP message for- and medium-sized organizations do not typically process mat [6] and standard GnuPG plug-ins (http://gnupg.org) more than 100,000 messages per day (of which only a subset on the client side allowing users to use their existing email are ML messages) we conclude that adding security to MLs clients and (2) uses open-source off-the-shelf components will not impose an undue overhead on the mail servers. such as the Mailman list server. By using COTS GnuPG components as illustrated in Figure 3 on the client side SELS becomes compatible with any email client for which a 3. USABILITY EVALUATION GnuPG plug-in is available and that includes popular email clients such as Outlook, Thunderbird, Mac Mail, Emacs and 3.1 Approach Mutt. We believes this compatibility to be a crucial factor The high-level goals of the usability study were to evaluate for successful deployment of SELS and this belief has been and enhance the usability (i.e., effectiveness, efficiency, and supported by experiences working with real user communi- satisfaction) of the SELS key management system for list subscribers with the constraint that the solution be compat- ible with existing deployed email clients. To address these goals we combined several usability techniques in execut- ing this study. First, the groupware walkthrough [27] tech- nique (which is based on cognitive walkthrough) was used to determine relevant key management tasks and candidate usable solutions. Application of the technique suggests two possible solutions for key management with a common pass- word management approach. The two key management ap- proaches utilize different GnuPGP key trust establishment mechanisms, namely, key signing and key trust assignment. We then undertook two rounds of focused user studies to design and evaluate the key installation and password man- agement technique as well as the overall usability of SELS. The first round explored the GnuPG key signing approach of trusting keys while the second round explored the key trust assignment approach. In each round we assessed the users’ ability to successfully complete specified key manage- ment tasks, we measured the time they took to do so, and Figure 4: Tasks Identified by Groupware Walk- then they filled out the SUS questionnaire [4] to convey their through satisfaction. Among the specific tasks were a set of vulnera- bility assessment tasks whereby users were required to place trust in messages that may or may not be correct. Since the interfaces from the point of the team users in attempt- we are evaluating security software it is important to ensure ing to accomplish the tasks [27]. We defined these tasks that the system does not introduce new vulnerabilities for and teamwork based on the SELS protocol described earlier the users. and executed the walkthrough with the authors acting as These focused studies were undertaken with a relatively multiple evaluators working simultaneously and recording high expert-to-novice ratio [10, 23] with novices being de- results with detailed notes. Figure 4 identifies the tasks and fined as those with some basic security concepts and ex- required teamwork but details of subtasks have been omit- perts being defined as those familiar with GnuPG tools and ted for simplicity. Based on interviews with several system advanced security concepts. Keeping the intended users in administrators and security professionals we chose the fol- mind (e.g., our current TeraGrid users) as well as the known lowing four email clients with available GnuPG plug-ins for limitations of common email clients in their ability to pro- the walkthrough: (1) Mac Mail, (2) Mutt, (3) Outlook, and vide usable security [13, 32], we decided that all subjects (4) Thunderbird. The walkthrough identified the following must have at least a basic grasp of security concepts. This three issues. allowed us to understand how familiarity with tools and concepts, that novices would learn over time, would affect 1. Installation of multiple keys. The List Moderator SELS usability and security. To further help in obtaining provides each subscriber with 1) a public key, common this understanding we explicitly asked users to perform ba- to all subscribers of the list, that is used to encrypt sic GnuPG two-party secure email tasks in addition to SELS messages to the list and 2) a public-private key pair, tasks. unique to the subscriber, that is used to decrypt mes- One deviation of our work from most studies of usable sages received on the list. The user must then add security is that we asked the subjects to complete tasks in these keys to her GnuPG key ring and assign a pass- the context of secure mailing lists but without a particu- word to the private key. She must also place appro- lar scenario. For usability studies of security systems these priate trust in these keys to be able to use them for scenarios are often used to motivate the need for security. sending and receiving secure e-mails as per the GnuPG However, in our case since all users had some background trust model. In addition the user also obtains a list of in computer security we felt that a scenario to motivate the public keys belonging to list subscribers from the list need for security may not be very helpful. Instead, we asked moderator for the purpose of signature verification and the subjects to focus exclusively on interface cues and their she must similarly install and trust these keys. A ma- knowledge of security concepts for making security decisions. jor difference with standard GnuPG use is that SELS An advantage of this is that the results of the study depend requires users to import and install private keys while only on the usability of the system and the users’ knowl- in standard GnuPG users typically only deal with pub- edge of security concepts and not on the extent to which lic keys. In addition to this new concept, we observed the scenario motivated security. that users would have to install several keys so unless the key installation steps were simple the user might get frustrated. 3.2 Groupware Walkthrough In the early part of the SELS design and implementation 2. Managing and using multiple keys. Whenever a process the authors undertook a groupware walkthrough message is received on any list the user must remember with the goals of identifying key management tasks and the password corresponding to that list and enter it in problems as well as candidate solutions. The groupware order to decrypt the message. All email clients studied walkthrough process involves specifying a description of tasks provide passphrase caching capabilities but limit the and teamwork and then using the technology to walk through caching to only one passphrase, which further compli- cates management and use of the multiple private keys. To evaluate the vulnerability of the interface, each user We note that these issues of installing and managing was asked to deal with malformed emails and use the se- multiple keys arises primarily because SELS uses an curity cues provided by the interface to decide whether or untrusted server. If the server were fully trusted, then not to trust the email. Specifically, the user dealt with at- the subscriber would be able to use the same key pair tacks where the emails were incorrectly encrypted, signed for all lists. or both. Intuitively, (1) a correctly encrypted email should provide assurance that the message was intended for the 3. Prior GnuPG experience. While conducting the recipient because only the recipient has the corresponding walkthrough it became clear that prior experience of private key and (2) a correctly signed email should provide secure email use with GnuPG would greatly benefit assurance that the sender actually generated the message the users; however, it was not clear 1) how much prior because only she has the required signing key. experience would benefit the users and 2) whether lack Measuring the success rate and time taken for these ex- of such experience would make the software unusable. ercises allows us to evaluate the usability and security of TPSE and SELS to a reasonable objective extent. However, Analysis. The results from our walkthrough provided users often have subjective views and insights into usabil- an opportunity to fix the usability problems early on and ity of software. We use the common technique of usability to design a focused user study to evaluate the usability and questionnaires to study these subjective evaluations. Specif- security of the system. For installing keys we designed a ically, we used the System Usability Scale (SUS) [4], which sequence of three emails sent from the list moderator with has proven to be a good guide for gauging the usability as- the following contents: (1) the list moderator’s public key pects of effectiveness, efficiency and satisfaction. SUS is that the user needs to import and trust, (2) the list public designed to give a quick assessment of overall usability and key as well as the user’s private key (for the list) that the consists of ten questions rated on the Likert scale. SUS has user needs to import and trust, and (3) a set of subscriber proven effective in practical settings [29] and is also begin- keys that the user needs to import. GnuPG allows two ways ning to be used in usability studies of secure software (e.g., of achieving trust: signing keys or using the GnuPG trust Polaris [9]). model. We decided to study both ways of achieving trust We conducted two studies as discussed earlier. In Study with the initial assumption and default implementation that I we evaluated the key signing approach and in Study II we the first approach will work because prior usability stud- used the GnuPG trust assignment approach. All the goals of ies in secure email indicated that users find it very chal- Study I and Study II were identical to allow for an effective lenging to deal with the GnuPG trust model [12, 28, 32]. evaluation of proposed approaches. For managing and using multiple keys we proposed a sim- ple approach, namely, recommend that users use the same 3.3.2 Recruiting Users passphrase to protect all private keys and use the passphrase Our process of recruiting users was guided by the desire to caching tools to manage that passphrase. Clearly, this is a (1) get representative users for the system’s target audience tradeoff between usability and security but we believe that and (2) be able to study the impact of familiarity with a as long as the users use a strong password their security similar interface on SELS usability. For studying the impact is only minimally weakened by this approach. To evaluate of familiarity we needed to categorize our users into experts these approaches we needed a user study that asked users to and novices as follows: evaluate SELS with the suggested approaches for installing and managing multiple keys. To characterize how familiar- • Expert. A user who uses GnuPG to send and receive ity with the GnuPG interface (or lack thereof) affects the secure emails at least occasionally and has security- usability of SELS 1) we used both expert and novice users, related knowledge experience from one or more of the i.e., those who were familiar with GnuPG and those who following: classroom, job, personal interest. were not, and 2) we included tasks involving Two-Party Se- cure Email using GnuPG, hereafter referred to as TPSE, in • Novice. A user who has used GnuPG at most rarely our focused user study. but has security-related knowledge experience from one or more of the following: classroom, job, personal in- 3.3 Focused User Study terest. This knowledges includes basic understanding To conduct the user study we identified a set of testing of concepts of confidentiality, integrity and authenti- goals, recruited users, setup the study in a laboratory, con- cation as well as how these concepts are enabled by ducted the study with one user at a time, and took extensive public key cryptography. notes.2 To recruit users we sent out flyers outlining the study and 3.3.1 Testing Goals asking for volunteers. Based on the responses we selected 20 users for the study. Among the users there were two system To measure the effectiveness of the interface, each user administrators, seven computer science graduate students, was asked to perform these tasks: (1) install and trust the and eleven professional engineers. key of another user in case of TPSE, (2) install and trust keys related to the list in case of SELS, (3) exchange signed 3.3.3 Setup and Sequence and encrypted emails and (4) manage multiple keys in case The two studies were conducted in a computer lab and ad- of SELS. ministered by two people, a studyadmin who administered 2 All of these steps were approved by the Institutional Re- the study remotely via email and a studymonitor who ob- view Board and signed consent forms were obtained from served the users during the study and took notes. Users were each user up front. asked to choose one of the following four email clients for the study: 1) Thunderbird, 2) Outlook, 3) Mac Mail or 4) Mutt. key pair and other subscriber’s public keys) as their email A GnuPG plug-in was installed on each of these clients and clients were able to leverage the transitive trust enabled by a key-pair was pre-generated for the users. A standard PC the GnuPG key trust assignment model. with Debian Linux was used for Mutt and Thunderbird and a standard PC with Windows XP was used for Outlook and Part V: SELS Vulnerability. Thunderbird. A Macbook Pro was used for Mac Mail. This part is similar to part III except that the email mes- The study was divided into five parts as described below. sages are sent over the SELS mailing list. The message types Part four differed in Study I and Study II. These differences used are described in Table 1. are noted below. 3.3.4 SELS Training and Documentation Part I: Background Questions. Typically when new security software or new features in User provides background information. This information existing software are evaluated, users are given some training helps us classify him/her as an expert or novice. in the software/features. For SELS we decided that engag- ing in TPSE exercises served as sufficient training because if Part II: TPSE Effectiveness. users are able to install keys and then use them to send and Studyadmin sends email containing keying material and receive secure emails they should be capable of using SELS. instructions to the user. The user is asked to 1) import Therefore, the initial TPSE usability evaluation served as a public-key and place trust in it by signing it, 2) send a both training for SELS as well as providing data for eval- signed and encrypted email using the imported key, and uating the usability issue of prior experience with GnuPG. 3) decrypt and verify a received email. After completing To help users in completing these exercises we provided a these tasks the user was asked to a fill a SUS questionnaire minimal set of instructions in the emails that described the about the experience of exchanging two-party secure email tasks and included key material. These instructions were using GnuPG (TPSE). The user has an option to provide independent of any email client in keeping with SELS ob- additional feedback if he/she desires. jectives. For additional clarification, we referred the study user to the the SELS online documentation. Part III: TPSE Vulnerability. The user received six email messages and was asked to 3.4 Observations and Analysis decide whether he/she trusted the message based on the For each user we took detailed notes of their ability to ex- security cues provided by the email client’s GnuPG plug-in ecute assigned tasks as well as the time taken for each task. and their general knowledge of security. He/she was asked The time taken between emails sent to the user that pro- to forward the message to “studyadmin” with their trust vided the instructions and emails sent back from the user decision (yes or no) and optionally an explanation for their with the results allowed for exact measurements of time decision. The five message types used are described in Table taken to complete the tasks. For study parts two and four 1. the studymonitor offered help to the user in the following ways (if requested): (1) when users were stuck they were Part IV: SELS Effectiveness. asked to look at the instructions carefully, (2) when users The user was subscribed to a mailing list hosted by the found additional instructions on specific clients to be incor- SELS server and received the email messages with the list rect they were offered correct instructions, and (3) when keys as described previously. The user was asked to 1) im- they failed to proceed they were helped as much as needed port keying material for a list sent by the list moderator, 2) so that they could proceed to the next part with this part send signed and encrypted email to the list, and 3) decrypt being counted as a failed task. and verify an email received on the list. Importing keying- A total of 12 users participated in Study I with 3 expert material for a SELS list involved 1) importing the list mod- users and 9 novice users. Out of the 12 participants, 8 par- erator’s GnuPG public-key and placing trust in it by signing ticipants chose Thunderbird, 2 participants chose Mac Mail, it, 2) importing an encryption (decryption) GnuPG key-pair 1 participant chose Mutt and 1 participant chose Outlook. to be used for encrypting (decrypting) messages for (on) the All users except for one were able to complete enough tasks list and placing trust in it by signing it, and 3) importing to allow for user study conclusions. The one that failed in- the GnuPG public-keys of all members of the list. Addi- volved Microsoft Outlook that kept crashing so this client tionally we also recommended that users set the passphrase was excluded from further studies.3 A total of 8 users par- of the imported key-pair for the list to be same as that of ticipated in Study II with 3 expert users and 5 novice users. their GnuPG key-pair for ease of use. After completing these All of them chose to use Thunderbird. While the number tasks, the user was asked to a fill a SUS questionnaire about of expert users per study is small, previous research [26, 24] the experience of using SELS for exchanging signed and en- shows that a small number of users per class is sufficient to crypted email using a list. The user had an option to provide uncover most of the usability issues in a system. Specifically, additional feedback if he/she desires. 3 and 5 users can uncover about 67% and 85% of the usabil- In Study II users were asked to perform a variation in ity issues respectively. However, our quantitative measures tasks for part four with the difference being in the way they are preliminary as larger studies are needed to quantitatively trust keys. Instead of signing each key explicitly users were measure usability [25] asked to place “ultimate” trust in the list moderator’s public key when they received it. Thereafter, they did not have to 3 Interestingly, the GnuPG plug-in for Outlook seemed to place explicit trust in any keys that were already signed crash only when used in conjunction with its key manager by the list moderator (i.e., the list encryption/decryption − a scenario that was not explored in our groupware walk- through. Table 1: Message Types Sent to Users during GnuPG and SELS Focused Studies Message Type Two Party Secure Email (TPSE) using Secure Email List Service (SELS) and Descrip- GnuPG tion Encrypted This message is encrypted for the user and signed This message is signed and encrypted by a valid and signed with a trusted key. member of studylist, with a trusted signature key correctly and the correct list encryption key. Encrypted with The email message is encrypted with a key that This email message is encrypted with a key for wrong key does not belong to the user. Hence the user can- which the user has no secret-key and delivered di- not decrypt it. rectly to the user but made to look like a message delivered on the list by forging the headers. Encrypted and The email message is encrypted with the user’s The email message is encrypted with the list key signed with key, but signed with a key that does not match but signed with a key that does not match the forged “From” the “From” address. “From” address. Encrypted This email message is encrypted with the user’s This email message is encrypted with the list key, correctly but key, but is signed with a key for which the public- but is signed with a key for which the public-key signed with a key is not available to the user. is not available to the user. missing key Encrypted with The user is made to believe that this encrypted The user is made to believe that this encrypted forged “To” message was sent to the user and someone else by only message was sent on the list by forging the forging “To” header. headers. It is encrypted such that the user can decrypt it correctly. Table 2: Usability observations from Study I User Key Install Success Rate Key Install Time SUS Score Changed Type (Avg./Std. Dev. Password min.) TPSE SELS TPSE SELS TPSE SELS Expert 2 of 3 (66.6%) 2 of 3 (66.6%) 6.5 / 2.12 11 / 1.41 85.83 / 5.20 76.67 / 11.55 3 of 3 (100%) Novice 6 of 8 (75%) 2 of 8 (25%) 8.83 / 2.86 25.5 / 0.71 79.38 / 9.33 54.44 / 16.66 3 of 8 (37.5%) Table 3: Usability observations from Study II User Key Install Success Rate Key Install Time SUS Score Changed Type (Avg./Std. Dev. Password min.) TPSE SELS TPSE SELS TPSE SELS Expert 3 of 3 (100%) 3 of 3 (100%) 4/0 12.66 / 2.01 74.17 / 20.21 74.16 / 23.23 2 of 3 (66.6%) Novice 4 of 5 (80%) 5 of 5 (100%) 8.4 / 2.7 18.2 / 3.19 61.5 / 10.98 52 / 13.62 5 of 5 (100%) Table 4: Security observations from Study I and Study II Study I Study II User % of Correctly % of Incorrectly Formed % of Cor- % of Incorrectly Type Formed Msgs. Msgs. Trusted (Avg. rectly Formed Msgs. Trusted Trusted (Avg. /Std. Dev.) Formed Msgs. (Avg. /Std. Dev.) /Std. Dev.) Trusted (Avg. /Std. Dev.) TPSE SELS TPSE SELS TPSE SELS TPSE SELS Expert 100 / 0 100 / 0 16.67 / 14.43 8.33 / 14.43 100 / 0 100 / 0 8.33 / 14.43 16.67 / 28.87 Novice 93.75 / 17.68 100 / 0 18.75 / 17.68 15.63 / 12.94 100 / 0 100 / 0 30 / 20.92 35 / 13.69 Key Management: Installing and Managing SELS Keys. Expert users took 6.5 minutes and 11 minutes on an average to complete key installation for TPSE and SELS respec- The first of the two key management usability issues eval- tively. On the other hand, novice users took 8.83 minutes uated by this work is installation of per-list keying material on an average for TPSE key installation and 25.5 minutes by SELS users. The results of Study I are presented in Ta- on average for SELS key installation when they could suc- ble 2. 66.6% of expert users (2 out of 3) and 75% of novice cessfully complete it. The increase in key-installation time users (6 out of 8) were able to successfully complete the key from TPSE to SELS is due to the fact that SELS involves installation tasks for the second part of the study (i.e., for importing secret keys while TPSE only involves importing TPSE) while 66.6% of expert users (2 out of 3) and only public keys and, furthermore, SELS involves importing mul- 25% (2 out of 8) of novice users were able to complete key tiple keys while our TPSE exercises involved importing only installation tasks for the fourth part of the study (i.e., for one key. SELS). Two-thirds of the users who failed to complete the These results allowed us to quickly conclude that the SELS key installation task for SELS and all the users who failed to key installation process was too cumbersome for novice users. complete the key installation task for TPSE did so because There are two ways to trust keys in GnuPG: using key sign- they either didn’t know how to sign keys or what keys to sign ing and using explicit key trust assignment. We adopted the in the case of SELS. In particular, users could not under- first approach for Study I because we assumed that under- stand what a ‘key-id’ is and how to find the ‘key-id’ of a key. standing the GnuPG key trust assignment model would be very complex for users. This assumption was based in part 52. We believe that the key installation and management on the complexity of this model as it allows for transitive functions played a big role in the SUS scores that the soft- trust establishment and in part on previous usability studies ware received though other factors such as prior familiarity with secure email [12, 28, 32]. However, it turns out that the with GnuPG have affected these scores. In order to ac- key signing approach is not appropriate based on our usabil- count for such prejudices we look at the ratio of SELS SUS ity observations. Instead, the key trust assignment model scores to TPSE SUS scores. In conducting the groupware where the users place explicit trust in the list moderator’s walkthrough we realized that prior experience with GnuPG key and then use that trust to place transitive trust in all would help users in using SELS. Looking at the ratio of SUS other SELS keys (as the list moderator’s key signs all other scores between SELS and TPSE and comparing key instal- keys) turns out be more usable. lation success rates across SELS and TPSE will also help The evaluation results of this approach from Study II are us better understand whether prior experience of GnuPG is presented in Table 3. All the expert and 80% ( 4 out of 5) of necessary to use SELS. The ratio of SUS scores going from novice users were able to complete key installation tasks for SELS to TPSE is 0.89 for experts on average, with a standard the second part of the study (i.e., for TPSE) while all the deviation of 0.1, and 0.68 for novices on average, with stan- experts and novices were able to complete key installation dard deviation of 0.18, in Study I. The average ratio of SELS tasks for the fourth part of the study (i.e., for SELS). While SUS score to TPSE SUS score is 0.994 with standard devia- expert users took 4 minutes and 12.6 minutes on average to tion of 0.09 for experts and 0.84 with standard deviation of complete key installation for TPSE and SELS, respectively, 0.13 for novices. We see that ratio of SELS and TPSE SUS novice users took 8.4 minutes and 18.2 minutes on an av- scores for novices improves significantly in Study II when erage when they could successfully complete it. As can be compared to Study I and is comparable to that of expert seen from the results, there is a significant improvement in users. Furthermore, the same number of novices completed SELS key installation success rate in the case of novice users. SELS key installation as TPSE key installation in Study II We believe that the reason for this is that users find placing while few novices could complete SELS key installation in explicit trust in one key, namely, the list moderator’s key, Study I. This indicates 1) that the key management tech- much easier than signing multiple keys. The second usabil- niques adopted in Study II are significantly better than those ity issue that we dealt with is managing and using multiple in Study I and 2) that if the key management tasks are de- keys. The approach that we took to address this is to lever- fined well with adequate instructions then even novices can age the GnuPG key management capabilities whereby the quickly learn to use SELS effectively. plug-ins help locate the appropriate keys (for encryption, decryption, signing, and verification) but use a simplified Vulnerability. password management solution. In using secret keys the After designing usable security features/software it is im- user is prompted for his password for decryption and sign- portant to evaluate these usable features for vulnerabilities. ing. Since all clients that we dealt with supported password Such an evaluation helps identify limitations of usable fea- caching for exactly one password, we recommended users tures as well as early opportunities to address security prob- (in SELS instructions) to set the passwords for all secret lems. In keeping with our usability design we conducted keys to be the same one. While all the expert users set our vulnerability evaluation on the interface mechanisms, the passphrase for the list key-pair to be the same as that namely, the cues provided by interfaces. We asked users of their GnuPG key-pair only 37.5% (3 out of 8) of novice to make a trust decision on both correctly and incorrectly users chose to change the passphrase in Study I. All the users formed emails where an incorrect email was either encrypted who set the passphrase as recommended had little difficulty incorrectly, signed incorrectly, or both. The results for parts in sending (receiving) messages to (on) the list while users three and five for both Study I and Study II are shown in who did not set the passphrase as recommended had trou- Table 4. In these studies users received two correctly formed ble figuring out which passphrase to use. 40% of users who and four malformed emails from the studyadmin. For Study didn’t follow the recommendation initially did so later after I, the table shows all experts trusted all correctly formed realizing the ease of use it afforded. To address this issue we TPSE and SELS messages. All novices trusted all correctly improved the instructions for Study II where we explained formed SELS messages but some did not trust some TPSE the consequences of password change in that it would be eas- messages (6.25% with a standard deviation of 17.68). We ier to manage decryption functions. Users were positively see interesting results in the case of malformed messages for affected by the inclusion of this explanation in the instruc- both TPSE and SELS. An average of 16.67% malformed tions. Consequently, in Study II all novice users chose to TPSE messages and 8.33% malformed SELS messages were change the password so that they have a single password to trusted by experts. In the case of novices however the aver- deal with. We note that once novice users chose to use a age increases to 18.75% for TPSE and 15.63% for SELS. For single password, they had no difficulty with sending and re- both experts and novices the most commonly trusted mal- ceiving signed and encrypted email as GnuPG plug-ins made formed message is the Encrypted and signed but with it very straightforward. Only one expert user chose not to forged “From” message. This case required the user to change the password but successfully completed the tasks. look carefully at the email headers to come to a right deci- To capture the effectiveness and satisfaction of interaction sion. The slight decrease in average of malformed messages with SELS we asked users to fill out a SUS questionnaire. In trusted, going from TPSE to SELS, is due to the fact that study I, Experts gave TPSE and SELS SUS scores of 85.83 a few users who failed to detect the mismatch between the and 76.67 respectively on average while Novices gave SUS 4 scores of 79.38 and 54.44 on average respectively. In study Surprisingly, in Study II an expert user gave SELS a better II, Experts gave TPSE and SELS SUS scores of 74.17 and SUS score than TPSE. In the exit interview he remarked 74.16 respectively on average while Novices gave 61.5 and “given that the interface cannot be changed SELS is very well integrated with the email client”. email headers and security banner displayed by the email SELS, our study recommends three modifications for GnuPG client’s GnuPG plug-in, for the above mentioned malformed plug-ins to further improve the usability and security of messages, did so for SELS. SELS. We recommend that GnuPG plug-ins for email clients, For Study II, Table 4 shows that both novices and experts 1) support caching of multiple passwords, 2) flag encrypted trusted all correctly formed messages. An average of 8.33% only emails as untrusted and 3) alert users when signer and malformed TPSE messages and 16.67% malformed SELS sender do not match. The first will allow users to establish messages were trusted by experts. In the case of novices different passwords for each private key in a usable man- however the average increases to 30% for TPSE and 35% for ner thus making the system more secure. The second will SELS. The increase in average going from TPSE to SELS strongly recommend users to trust only signed messages in the case of experts is due to the fact that one expert user coming on SELS (which was the primary problem for the tended to trust unsigned messages that came or appeared slightly increased vulnerability measurement for SELS). In- to come on the list. However, the user wondered in his terestingly, this feature is already provided for the Mac Mail responses whether unsigned messages from the list should GnuPG plug-in, and we recommend that all email clients do be trusted. The user even recommended in his comments so. The third will help decrease vulnerabilities for both two- that we mandate signed messages on the list. party secure email and SELS. In the case of novices the average of trusted malformed messages increased compared to Study I because apart from 4. SELS DEPLOYMENT EXPERIENCE trusting Encrypted and signed but with forged “From” After a successful usability study the SELS software was messages, some users tended to trust unsigned messages as hardened and installed in a production environment to sup- long as the sender was known or a member of the list. An- port users. Our first user community was the TeraGrid Se- other observation made during Study II is that users that curity Working Group (or simply, TG-WG) that has been trusted encrypted but unsigned messages did not trust en- using encrypted group email for several years to exchange crypted and signed messages if they could not verify the sensitive information about vulnerabilities, incidents and re- signature, i.e., they did not have and could not fetch the covery procedures for TeraGrid high-performance comput- public-key of the sender. This is because the GnuPG plug- ing systems distributed across 11 sites. Until SELS came in for Thunderbird, the email client used by majority of along they were using password-based symmetric-key en- users in our studies, alerted the users with a yellow ban- cryption in PGP with the passwords being distributed in ner that said “Unverified signature” whenever it could not telephone conference calls. This approach required secure verify the signature on a message. Whereas for encrypted- distribution and maintenance of multiple passwords (a se- only messages it displayed a blue banner, as opposed to a curity issue) and mapping passwords to current and prior green banner for an encrypted and signed message which emails (a usability issue). The community adopted SELS was decrypted properly and whose signature was verified. in the hope for a more usable and secure solution. In this The blue banner did not attract the user’s attention to the section we describe our experiences in supporting the TG- fact that message was unsigned and hence could be untrust- WG over a ten-month period from January through October worthy. This leads us to believe that most users would not 2008. We describe major issues in areas of usability, trust have trusted Encrypted and signed but with forged and security, and software engineering that arose while sup- “From” if the message signer’s key was unknown to the re- porting TG-WG and how they were resolved. Overall, SELS ceiver. Thus making the above attack, which many novices has been very successful in supporting TG-WG as evidenced and a few experts did not detect, viable only as an “insider by the large number of encrypted emails exchanged by the attack”. group. Summary. Effectiveness of SELS is demonstrated by the fact that all novices in Study II were able to successfully install list keys, send and receive messages on the list, and Table 5: SELS new features and enhancements since trust correctly formed messages. An equally important mea- TG sure of effectiveness is the vulnerabilities provided by SELS. SELS Release New Features While this number is greater than ideal (35% for novices), it 0.5.5 New Trust Model, Decryption only user key pair. is only slightly different from that for the TPSE evaluation 0.5.8 Bounce Messages for wrong LK and indicating that SELS introduces minimal additional vulner- HTML messages. abilities, if any. Efficiency of SELS is demonstrated by the 0.6 Two key lengths (1024 and 2048) fact that novices were able to complete key installation in 0.7 Generate and store Revocation Cer- 18 minutes. The study also indicates that effectiveness and tificate for LK, Remove email address efficiency may improve with time as experts were able to from User key pair. successfully complete the key installation and send and re- 1.0 Key Update, Delete a Subscriber, Mailman Patch, Improved error han- ceive messages in around 12 minutes and were more resistant dling to malformed messages (16.67%). In addition, many users were not familiar with the email client used in the study and we assume that gaining familiarity will help as well. Fur- 4.1 SELS Usage Statistics thermore, user satisfaction for SELS, measured by the SUS The List Moderator for TG-WG created two lists, we score, was similar to that of the underlying email client and will refer to them in this paper as List-A and List-B, on GnuPG plug-in combination (i.e., SELS SUS score to TPSE the SELS List Server hosted at NCSA. List-A has 52 sub- SUS score ratio is close to 1). This implies that users will scribers and an average of 32 encrypted emails were ex- find SELS almost as satisfying as secure email in general. changed per month. List-B has 50 subscribers and an aver- While we do not make changes to existing interfaces in age of 2 encrypted emails were exchanged per month. This Table 6: Bugs fixed based on feedback from TeraGrid users and code review ) Bug Number Description Fix 16 Minor coding error in LM ( Code Review) Code fixed 17 Add a check to see if Java is installed correctly Check added (Code Review) 18 Minor coding error in LM (Code Review) Code fixed 19 Minor coding error in LM (Code Review) Code fixed 20 GnuPG prompts different on Windows and *nix This fix was added. LM Code is platform independent platforms. Add functionality to support both. again. 21 Fix file name syntax for revocation certificates This fix was added. LM Code is platform independent on Windows. again. 22 Support bounce for HTML messages from Out- Bounce support added to LS code. look 2007 and Outlook 2003 ( User Feedback) 23 Race condition for GPG interactive command This bug was hard to fix in absence of a multi-platform “—edit-key” used in LM code. expect like module for Python. So used a different approach, using Java, where GnuPG interactive com- mands are no longer required. data has been collected since the TeraGrid lists were created tion made by one of the users to let the members set “full 10 months ago. Prior to using SELS, TG-WG used password trust” in the moderator’s key which is a lower level of trust based symmetric key encryption. In 2006 and 2007, using than “Ultimate” and had them locally sign the moderators that approach, the average number of encrypted emails ex- key. Thus, we retained the transitive trust model which was changed per month on List-A was 9 and and on List-B was shown to be more usable in our study while addressing users’ 3. Conversations with some of the list members indicated concerns. This is an example where users traded some us- that the increase in number of messages on the lists was ability for improved security. This is not surprising given due to the ease of use with which members could exchange that most TG users had prior experience with GPG/PGP secure (encrypted) messages using SELS. and are much more security conscious than an average user. Another concern that TG users had was in managing mul- 4.2 Usability and Security tiple private PGP keys for SELS. PGP keys have multiple About 8 percent of the TG-WG list subscribers, that is 4 key-pairs in them, namely a signing key-pair which is the out of 52,5 needed support while installing keys and send- main key and one or more decryption key-pairs called sub- ing messages using SELS. Given prior GPG experience we keys. In older versions of PGP it was possible to have just deemed all TG-WG users to be “experts”. Therefore, this one key-pair that is either used for signing or decryption or observation matches our usability study results in that most both depending the version. But in the recent version it is expert users were able to install keys and send messages. not possible to generate encryption-only keys. Therefore, Most of these subscribers who had trouble were using an our SELS keys, though intended only to be used for decryp- email client without a GnuPG plugin, e.g. Microsoft En- tion, had a signing key-pair in them along with the decryp- tourage, but were able to import these keys via the com- tion sub-key. So users had concerns that they might acci- mand line. However, when they wanted to send a message dentally use the SELS keys for 1) signing messages or 2) en- they encrypted it using the GPG command-line interface crypting messages outside of the mailing list. This is because and sent an email with the encrypted message as an at- many GPG plugins presented users with a drop down menu tachment. Since SELS supports encrypted attachments only to select a key when signing messages. Those users that when using PGP/MIME their messages were dropped at the had multiple signing keys were worried that their chances of server. Improved dissemination of compatibility information accidentally selecting the wrong key increased when they be- (e.g., via FAQs) provided the needed resolution; in particu- longed to (multiple) SELS lists. To address the first concern lar the need to paste the encrypted message in the body of we explicitly removed the secret key of the signing key-pair the email for Entourage. Some of the subscribers who had from SELS keys after key generation. To address the sec- trouble did not realize that they needed to install a separate ond concern we removed the email address from the name of set of keys for each list and hence had trouble sending and the key. This distinguished SELS keys from most PGP key- receiving email on one of the lists. Again, improved instruc- pairs that can be used for signing/encrypting and reduced tions via email and on the SELS web site by the SELS team the chance of inadvertent misuse. resolved the issue. After the users installed the second set of keys they were successful. 4.3 Features and Enhancements While most of the TG list users were comfortable with SELS 0.5 was the first version that was used for TeraGrid installing and trusting SELS keys, some of them had con- lists. This version had the capability to bounce plaintext cerns about setting “Ultimate” trust in the moderator’s key. messages back to the sender if the list was configured to al- We chose this mechanism to place trust in SELS keys as it low only encrypted or encrypted and signed messages. Ter- was simple, i.e., required users to perform only one opera- aGrid lists were initially configured to allow plaintext mes- tion, and it enabled transitive trust in any key signed by the sages, but were changed to only allow encrypted messages a moderator without requiring any explicit action from users. couple of months later, to avoid sending sensitive messages In order to address this concern we adopted a recommenda- in plaintext by mistake. Over the last ten months SELS was enhanced with many features. Based on user feedback two 5 Most members belonged to both lists. new bounce messages were added for two cases in SELS re- lease 0.5.8. SELS software supports messages sent in a text allows the backup VM to function equally well as the pri- format or messages encrypted as PGP/MIME when sent in mary VM. However, in order for a transition to the backup some other format. So if a message is composed as HTML to function properly at the software level, all changes to the and not sent as PGP/MIME, it will be dropped at the List primary VM are synchronized to the backup by a script that Server. Similarly a message encrypted with an incorrect securely copies SELS software changes, mailman list infor- key is dropped at the server. These messages were being mation, and new user data (user proxy-keys). dropped at the SELS List Server without any notification During the testing and pilot implementation phases of the to the sender which left the sender wondering where his/her project, several changes were made to the service infrastruc- message went. To improve usability, SELS was modified to ture. Initially, all operating system software packages on the always generate a bounce message whenever a message is VMs were automatically updated. However, this caused a dropped. SELS failure (luckily prior to the pilot stage), so the au- While SELS was being used by the TG-WG, the SELS tomatic update configuration was modified to prevent any Team felt the need to support additional clients based on updates of specific packages, namely mailman and sendmail users’ preferences. (which we use as the Mail Transfer Agent or MTA). When- ever updates to either of these two packages are available, 1. GMail with FireGPG: SELS can be used easily with a manual update is performed on the backup VM. If care- Gmail and the FireGPG plug-in. ful testing demonstrates that SELS functionality has been maintained, or after a fix to the package upgrade can be 2. PGP Desktop: Some TG-WG users use PGP Desktop determined (usually a configuration file tweak), then the as a key manager with email clients such as Outlook package update is rolled over to the primary VM. This pe- 2007 and Apple Mail with SELS. A few changes to riodic validation ensures that the backup VM can function the SELS code were needed to make SELS compatible properly equally well as the primary SELS server. Initially, with both PGP and GnuPG. One major change was we manually modified mailman python files in order to in- to revert the encryption algorithm between release 0.7 clude SELS functionality. However, by slightly modifying and 1.0. SELS is back to using CAST5 instead of the SELS code, we were able to amend the mailman instance AES256 since CAST5 is better supported by PGP. after it was upgraded via a simple patch script. Some TG-WG users were using email clients that do not In the duration of supporting TG-WG, there have been have available GnuPG plug-ins, e.g., Outlook 2007 and En- no hardware failures, so no fail overs have been needed. We tourage. However these users are able to use SELS by using decided against using automatic fail overs to prevent the in- the GPG command line for key management and encrypt- stance where both the primary and backup VMs are both ing or decrypting email messages and using Outlook 2007 or listening to the email list IP address. Manual fail overs are Entourage for sending and receiving messages to/from the precipitated when the remote monitoring script indicates List Server. that the primary VM has experienced a hardware failure Other features added include support for automatically or that network has been disconnected from the primary generating and storing a revocation certificate for the list VM. One such instance did occur: a power glitch restarted key LK and functions that automate key updates for sub- the network switches, although the UPS protected the pri- scribers. In Table 5 we summarize new features developed mary VM, which merrily hummed along. The temporary in SELS since the TG-WG has been supported. We also un- network outage caused the mailman daemon to stop pro- dertook a software architecture and code review that helped cessing emails properly, so it had to be restarted. To take us streamline our code and fix many bugs. In Table 6 we this problem into account, the monitoring script now checks present major bug fixes undertaken during this time. whether mailman is working correctly and restarts the dae- mon if this is not the case. 4.4 SELS Production Environment The SELS production environment, shown in Figure 5, 5. RELATED WORK consists of primary and backup industrial-grade, rack mount Secure Mailing Lists. Secure mailing lists have been host servers that support Linux virtual machines for each used for a while in the US Department of Defense as part of individual SELS instance. Both servers feature redundant the Defense Message System (DMS). This system uses en- power supplies (one of which is connected to an uninterrupt- hanced S/MIME techniques presented in [16]. DMS satisfies ible power supply) as well as hardware-based RAID mirrored the identified security properties of strong confidentiality, disk drives. A monitoring script on a remote server watches authentication and integrity. It uses a hardware lockbox at both hosts for network connectivity, which indicates that the server to provide strong confidentiality combined with the hosts are online and working properly. an externally supported key distribution system.6 DMS uses A virtual machine (VM) is created for each instantia- digital signatures to provide authentication and integrity. tion of SELS, then replicated to the backup host. Each Additionally, it uses an outer layer signature to provide au- VM is configured with the hostname of the list, e.g., sels- thentication at LS for encrypted messages. However, to example.ncsa.edu, but has its primary network connection achieve these security properties DMS uses specialized email set up with a different name, e.g., sels-example1 or sels- clients that can process messages to provide these properties example2. This allows each VM to be addressed separately, and a hardware lockbox at the server. In contrast, SELS is but the common hostname ensures that the web interface a purely software based solution and imposes no additional to the Mailman list server works correctly when creating burden on client-side software and only a software plugin on new email lists. Then on either the primary or the backup VM, the SELS list name (sels-example) is set up as a vir- 6 Details on DMS confidentiality property were provided by tual Ethernet interface, i.e., eth0:0. This DNS configuration Stephen Kent of BBN in personal communications. ations and is based on the often used cognitive walkthrough technique. Contextual information such as dynamic nature of group work and variability of tasks for multiple concur- rent users allows for the identification of usability problems that may not be possible with other techniques. Faulker and Wick [10] present an extensive analysis of the benefits of user studies that employ a mix of novice and expert users. In particular, they argue quantitative between-group com- parisons offer exclusive insights into usability problems. Proxy Encryption. Previous proxy encryption schemes enable unidirectional and bidirectional proxy transforma- tions by first setting up a transformation agent that is given the proxy key and then sending messages to the agent for transformation [2, 17, 22]. Unidirectional schemes only al- low transformations from some entity A to another entity B with a given proxy key while bidirectional schemes addi- tionally allow transformations from B to A with the same proxy key. For SELS we need a proxy encryption scheme that allows for the transformation from one entity, LS, to many subscriber entities (i.e., to all list subscribers). The El Gamal based unidirectional proxy encryption scheme of Ivan and Dodis [17] is closest in nature to SELS with the additional relationship between the proxy keys (i.e., ∀i KU0 i Figure 5: SELS Production Environment + KUi = KLK ) imposed to allow for a single list encryption key, P KLK , to suffice. Extending the RSA based unidi- rectional scheme of [17] in a similar manner will not work the server. Furthermore, DMS leverages organizational CAs because it would require the sharing of the modulus across to build trust while SELS leverages personal trust among all list subscribers. Jakobsson [18] and Zhou et al. [35] allow participants. At the same time we believe that there may for proxy transformation without the need for distributing be environments where DMS is a better fit than SELS. proxy keys but use costly threshold crypto-systems to ensure In the open-source arena simple approaches that extend the necessary security. Ateniese et al. [1], Green et al. [15] security solutions for two-party email to mailing lists have and Canetti and Hohenberger [7] extend proxy encryption already been developed; e.g., SSLS7 and Sympa8 . In these schemes with useful properties such as non-interactiveness, solutions, subscribers send emails to the list server encrypted which for SELS might allow for generation of proxy keys with the list server’s public key. The list server decrypts the without involving both LM ’s and LS’s decryption keys. We emails and then re-encrypts them for every subscriber using believe that while deployment of applications based on these their registered public keys. Clearly, these solutions do not novel schemes faces challenges with infrastructure compat- satisfy the confidentiality requirement as they allow the list ibility and lack of commonly available tools, it is an open server access to decrypted emails. problem to overcome these challenges. For example, our Usability of Secure Email has received considerable experiences suggest that users are unlikely to move to a dif- attention since the seminal work of Whitten and Tygar [32], ferent email client just to be able to use an advanced secure which identified several shortcomings of PGP. Garfinkel et email solution. However, advanced future systems based on al. [11, 13] demonstrate the potential high success of digi- these schemes are likely to provide strong security guaran- tally signed email in an e-commerce context with a a user tees and may prove to be very useful in practice. study. Gaw et al. [14] study the social issues that affect the Multi-recipient Email Encryption. The problem of adoption of secure email. Garfinkel and Miller [12] and Roth sending confidential messages to multiple recipients has been et al. [28] explore alternative key management techniques addressed in the past via multi-recipient email encryption that make secure email easier to adopt and they demon- [30], multi-party certified email [34], secure group commu- strate the effectiveness of their techniques with user studies. nication and broadcast encryption. A major difference be- However, to date all usability studies focus on secure two- tween these approaches and ours is that by using a mailing party email exchange. To the best of our knowledge ours is list we remove the user’s burden of managing recipient ad- the first study to focus on secure mailing lists. Furthermore, dresses and public keys while still satisfying the confiden- our study is significantly different in that we utilize usability tiality requirement. In these approaches the sender must techniques to improve secure email software usability with- manage the recipient list and address all of the intended re- out imposing software enhancement requirements. cipients directly. In multi-recipient email encryption, Wei Usability Techniques employed in our study, namely, et al. [30] combine techniques from identity-based mediated groupware walkthrough and focused user study with partic- RSA and re-encryption mixnets to enable a sender to en- ular attention to skill level, are promising techniques that crypt messages to multiple recipients with only two encryp- have not been fully applied to secure systems. Groupware tions (as opposed to one encryption for each recipient in the walkthrough was proposed by Pinelle and Gutwin [27] to al- trivial case). To do so, they use a partially trusted demulti- low for the inclusion of context in groupware usability evalu- plexer that is akin to LS in terms of its security properties 7 but also use an additional fully trusted CA. If their scheme http://non-gnu.uvt.nl/mailman-ssls 8 were to be adapted for mailing lists it would require devel- http://www.sympa.org opment of client-specific plugins. In SELS the sender needs 8. REFERENCES to execute only one encryption allowing compatibility with [1] G. Ateniese, K. Fu, M. Green, and S. Hohenberger. existing messaging formats and tools thereby avoiding the Improved proxy re-encryption schemes with need to develop client-specific plugins. In multi-party cer- applications to secure distributed storage. ACM tified email [34], the sender must maintain each recipient’s Transactions on Information and System Security, public key and encrypt the message individually to each re- 9(1):1–30, 2006. cipient. This overhead is avoided in SELS via the use of [2] M. Blaze, G. Bleumer, and M. Strauss. Divertible mailing lists while still providing confidentiality. protocols and atomic proxy cryptography. In In secure group communication either a trusted group EUROCRYPT, pages 127–144, 1998. controller (e.g., LKH [33]) distributes session keys to group [3] D. Boneh, C. Gentry, and B. Waters. Collusion members or the group members generate session keys in a resistant broadcast encryption with short ciphertexts distributed manner (e.g., TGDH [21]). In either case, list and private keys. In Proceedings of International subscribers would have to maintain state on current ses- Cryptology Conference (CRYPTO), pages 258–275, sion keys and update them on every membership change 2005. (whereas in SELS existing subscribers are not affected by the [4] J. Brooke. SUS: a quick and dirty usability scale. In P. joins and leaves of other members). This makes the use of W. Jordan, B. Thomas, B. A. Weerdmeester and A. L. secure group communication techniques impractical for se- McClelland (eds.). Usability Evaluation in Industry. cure mailing lists as it goes against the nature of the largely London: Taylor and Francis., 1996. offline email use. So-called “stateless” broadcast encryption schemes (e.g., [17], [3]) allow for encryption of messages to a [5] N. Brownlee and E. Guttman. Expectations for dynamic set of group members without the members requir- Computer Security Incident Response. IETF Network ing to maintain state and executing key updates on mem- Working Group, Requests for Comments, RFC 2350, bership changes. However, they vary the encryption key and June 1998. cipher-text sizes depending on the group membership. This [6] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. variation cannot be supported by today’s email standards OpenPGP Message Format. IETF Network Working making such solutions difficult to implement. SELS, on the Group, Request for Comments, RFC 2440, November other hand, addresses the confidentiality and deployability 1998. requirements of secure mailing lists in a practical way. [7] R. Canetti and S. Hohenberger. Chosen-ciphertext secure proxy re-encryption. In CCS ’07: Proceedings of the 14th ACM conference on Computer and 6. CONCLUSIONS communications security, pages 185–194, New York, In this work we have described the process of going from NY, USA, 2007. ACM. the existing SELS prototype [20] to a usable and deployed [8] Y.-P. Chiu, C.-L. Lei, and C.-Y. Huang. Secure software solution. We conducted an usability study whose multicast using proxy encryption. In International high-level goals were to evaluate and enhance the usabil- Conference on Information and Communications ity (i.e., effectiveness, efficiency, and satisfaction) of the Security (ICICS), pages 280–290, 2005. SELS key management system for list subscribers with the [9] A. J. DeWitt and J. Kuljis. Aligning usability and strong preference that the solution be compatible with com- security: a usability study of polaris. In SOUPS ’06: monly used email clients. We have deployed SELS and Proceedings of the second symposium on Usable report on our experiences in supporting the TeraGrid Se- privacy and security, pages 1–7, New York, NY, USA, curity Working Group for a period of ten months. Suc- 2006. ACM Press. cess of SELS is clearly indicated by the fact that there has [10] L. Faulkner and D. Wick. Cross-user analysis: been a nearly four-fold increase in the number of encrypted Benefits of skill level comparison in usability testing. emails exchanged by the TeraGrid users since they adopted Interacting with Computers, 17(6):773–786, 2005. SELS with anecdotal evidence suggesting that this increase [11] S. L. Garfinkel, D. Margrave, J. I. Schiller, is largely due to better usability provided by SELS. The E. Nordlander, and R. C. Miller. How to make secure SELS software is now available for community use. We look email easier to use. In CHI: Proceedings of the forward to continuing to support and improve the software SIGCHI conference on Human factors in computing based on input from the user community. systems, pages 701–710, 2005. [12] S. L. Garfinkel and R. C. Miller. Johnny 2: A User 7. ACKNOWLEDGMENTS Test of Key Continuity Management with S/MIME The authors would like to thank James Marsteller and and Outlook Express. In Symposium on Usable Tim Brooks for facilitating the adoption of SELS by the Privacy and Security (SOUPS ’05), 2005. members of TeraGrid Security Working Group. We thank [13] S. L. Garfinkel, J. I. Schiller, E. Nordlander, Pooja Agarwal for helping with unit testing and code re- D. Margrave, and R. C. Miller. Views, Reactions and view and all the users that participated in the usability Impact of Digitally-Signed Mail in e-Commerce. In evaluation. We also thank Von Welch for helpful discus- Financial Cryptography, pages 188–202, 2005. sions through the course of this effort. This work is funded [14] S. Gaw, E. W. Felten, and P. Fernandez-Kelly. by Office of Naval Research under Grant Nos. N00014-06- Secrecy, flagging, and paranoia: adoption criteria in 1-1108 and N00014-07-1-1173. Any opinions, findings and encrypted email. In CHI ’06: Proceedings of the conclusions or recommendations expressed in this material SIGCHI conference on Human Factors in computing are those of the author(s) and do not necessarily reflect the systems, pages 591–600, New York, NY, USA, 2006. views of the Office of Naval Research. ACM Press. [15] M. Green and G. Ateniese. Identity-based proxy 269–279, 2005. re-encryption. In Applied Cryptography and Network [31] M. J. West-Brown, D. Stikvoort, K.-P. Kossakowski, Security (ACNS), pages 288–306, 2007. G. Killcrece, R. Ruefle, and M. Zajicek. Handbook for [16] P. Hoffman. Enhanced Security Services for S/MIME. Computer Security Incident Response Teams IETF Network Working Group Request for Comments (CSIRTs). CERT Handbook, CMU/SEI-2003-HB-002, (RFC) Document 2634, June 1999. April 2003. [17] A.-A. Ivan and Y. Dodis. Proxy cryptography [32] A. Whitten and J. Tygar. Why Johnny Can’t revisited. In Proceedings of the Network and Encrypt: A Usability Evaluation of PGP 5.0. In 8th Distributed System Security (NDSS) Symposium, 2003. USENIX Security Symposium, 1999. [18] M. Jakobsson. On quorum controlled asymmetric [33] C. K. Wong, M. Gouda, and S. S. Lam. Secure group proxy re-encryption. In PKC ’99: Proceedings of the communications using key graphs. IEEE/ACM Second International Workshop on Practice and Transactions on Networking, 8(1):16–30, 2000. Theory in Public Key Cryptography, pages 112–121, [34] J. Zhou. On the security of a multi-party certified London, UK, 1999. Springer-Verlag. email protocol. In International Conference on [19] A. Kapadia, P. Tsang, and S. W. Smith. Information and Communications Security (ICICS), Attribute-Based Publishing with Hidden Credentials pages 40–52, 2004. and Hidden Policies. In Proceedings of The 14th [35] L. Zhou, M. A. Marsh, F. B. Schneider, and A. Redz. Annual Network and Distributed System Security Distributed blinding for distributed elgamal Symposium (NDSS ’07), February 2007. re-encryption. In ICDCS ’05: Proceedings of the 25th [20] H. Khurana, J. Heo, and M. Pant. From proxy IEEE International Conference on Distributed encryption primitives to a deployable Computing Systems (ICDCS’05), pages 824–824, secure-mailing-list solution. In International Washington, DC, USA, 2005. IEEE Computer Society. Conference on Information and Communications Security (ICICS), pages 260–281, 2006. [21] Y. Kim, A. Perrig, and G. Tsudik. Tree-based group key agreement. ACM Transactions on Information and System Security, 7(1):60–96, 2004. [22] M. Mambo and E. Okamoto. Proxy cryptosystem: Delegation of the power to decrypt ciphertexts. IEICE Transaction on Fundamentals of Electronics, Communications and Computer Sciences, E80(A(1)):54–63, 1997. [23] J. Nielsen. Novice vs. Expert Users. http://www.useit.com/alertbox/20000206.html, Feb 2000. [24] J. Nielsen. Why You Only Need to Test With 5 Users. http://www.useit.com/alertbox/20000319.html, March 2000. [25] J. Nielsen. Quantitative Studies: How Many Users to Test. http://www.useit.com/alertbox/ quantitative testing.html, June 2006. [26] J. Nielsen and T. K. Landauer. A mathematical model of the finding of usability problems. In CHI ’93: Proceedings of the INTERACT ’93 and CHI ’93 conference on Human factors in computing systems, pages 206–213, New York, NY, USA, 1993. ACM. [27] D. Pinelle and C. Gutwin. Groupware walkthrough: adding context to groupware usability evaluation. In CHI ’02: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 455–462, New York, NY, 2002. [28] V. Roth, T. Straub, and K. Richter. Security and usability engineering with particular attention to electronic mail. International Journal on Human Computer Studies, 63(1-2):51–73, 2005. [29] T. S. Tulis and J. N. Stetson. A Comparison of Questionnaires for Assessing Website Usability. In Usability Professional Association Conference, 2004. [30] W. Wei, X. Ding, and K. Chen. Multiplex encryption: A practical approach to encrypting multi-recipient emails. In International Conference on Information and Communications Security (ICICS), pages Usable Secure Mailing Lists with Untrusted Servers Rakesh Bobba, Joe Muggli, Meenal Pant, Jim Basney and Himanshu Khurana IDtrust, April 14 – 16, 2009. Gaithersburg, MD Introduction to Mailing Lists List Moderator (LM) • Mailing Lists (MLs) enable - creates lists users to easily exchange - Subscribes users emails • LS bears all the overhead • Increasingly popular for exchange of both public and List Server (LS) private content  security is - creates lists an important concern - forwards emails - archives email • Little or no work in providing security solutions for MLs • We provide SELS: Secure Email List Services User/subscriber • solutions for confidentiality, - subscribes to lists integrity, and authentication - sends/receives email Untrusted Servers • Existing Solutions • Password based encryption (end-to-end confidentiality) • Clunky to exchange and manage passwords out-of-band whenever a subscriber leaves • Encrypt to LS, which decrypted and re-encrypted with subscriber keys • LS takes care of key management • LS had access to plaintext messages. • Desirable to Reduce Trust Liability • Trust LS to manage lists and forward messages correctly • But do not trust LS with content of messages – “untrusted server” SELS History • Original SELS protocol. • Himanshu Khurana, Adam Slagell, and Rafael Bonilla. SELS: A Secure E-mail List Service. In proceedings of the Security Track of the ACM Symposium on Applied Computing (SAC), March 2005. • Modified, practical version of SELS, with extensive experimentation and integration. • Himanshu Khurana, Jin Heo, and Meenal Pant. From Proxy Encryption Primitives to a Deployable Secure-Mailing-List Solution. In the Eighth International Conference on Information and Communications Security (ICICS '06), Raleigh, North Carolina, December 2006. Protocol Overview Create Group Establish Corresponding LS Key KLS LM LS Establish Proxy Key K’U1, LM, LS implicitly agree KLK = KLM + KLS is list key Establish LM Key KLM KLK = KU1 + K’U1 Transform and Subscribe forward Send signed, Decrypt and encrypted, verify signature email Obtain key pair (KU1,PKU1) U1 U2 U3 Proxy re-encryption at LS ensures that plaintext is not exposed • Assumption: LM is an independent entity not controlled by LS Sending Emails in SELS Keyring: Members’ proxy Keyring: (SKA, PKLK) keys K’Ui Alice LS Encryptk (m,Sig(m)) Encrypt k w/ PKLK Email Sig(m) w/ SKA Email Header Plaintext m (RSA, DSA) (AES, 3DES) (El Gamal) Keyring: (PKA, SKB) Bob LS Encryptk (m,Sig(m)) Transform k W/ K’B Email Sig(m) w/ SKA Email Header Plaintext m (RSA, DSA) (SELS Proxy (AES, 3DES) Re-encryption) Suitable for environments where GPG is/can be used Preliminary Usability Evaluation: Groupware Walkthrough Potential Usability Issues • Installation of multiple keys • List public-key and user decryption key pair (includes private key) • Installing a private key is not common operation • Place appropriate trust in the keys • Sign them or use PGP trust model • Managing and using multiple keys • Users get a private key for every SELS list • Need to remember passwords for each key or set same password for all keys • Most GPG plug-ins cache only one password • Prior GPG experience • Lack of GPG knowledge/experience might make it unusable Focused User Study - Setup • Two Studies • Study I – sign keys to place trust • Study II – use PGP trust model • Two user groups in each study • Novice – no prior GPG experience (8 in study I and 5 in study II ) • Experts – prior GPG experience (3 in study I and 3 in study II) • 5 Parts to each study • Background questionnaire • Two Party Secure E-mail (TPSE) key installation and message exchange using GPG • SUS questionnaire • TPSE Vulnerability Evaluation • Tasks involving SELS key installation and message exchange • SUS questionnaire • SELS Vulnerability Evaluation Focused User Study - Results Observations from Study I User Key Install Key SUS Score Changed Type Success Rate Install Time (Avg. / Passwd. Std. Dev) TPSE SELS TPSE SELS TPSE SELS Expert 2 of 3 2 of 3 6.5 / 2.12 11 / 1.41 85.83 / 5.2 76.67 / 11.55 3 of 3 Novice 6 of 8 2 of 8 8.83 / 2.86 25.5 / 0.71 79.38 / 9.33 54.44 / 16.66 3 of 8 Observations from Study II User Key Install Key SUS Score Changed Type Success Install Time (Avg. / Passwd. Rate Std. Dev) TPSE SELS TPSE SELS TPSE SELS Expert 3 of 3 3 of 3 4/0 12.66 / 2.01 74.17 / 20.21.2 74.16 / 23.23 2 of 3 Novice 4 of 5 5 of 5 8.4 / 2.7 18.2 / 3.19 61.5 / 10.98 52 / 13.62 5 of 5 Focused User Study – Vulnerability Evaluation Message Type and Description Two Party Secure Email (TPSE) using GPG SELS Messages Encrypted and This message is encrypted for the This message is signed and encrypted by signed correctly user and signed with a trusted key. a valid member of list, with a trusted signature key and the correct list encryption key. Encrypted with The email message is encrypted This email message is encrypted with a wrong key with a key that does not belong to key for which the user has no secret-key the user. Hence the user cannot and delivered directly to the user but made decrypt it. to look like a message delivered on the list by forging the headers. Encrypted and The email message is encrypted The email message is encrypted with the signed with forged with the user’s key, but signed with list key but signed with a key that does not “From” a key that does not match the match the “From” address. “From” address. Encrypted correctly This email message is encrypted This email message is encrypted with the but signed with a with the user’s key, but is signed list key, but is signed with a key for which missing key with a key for which the public key the public-key is not available to the user. is not available to the user. Encrypted with The user is made to believe that The user is made to believe that this forged “To” this encrypted message was sent to encrypted only message was sent on the the user and someone else by list by forging the headers. It is encrypted forging “To” header. such that the user can decrypt it correctly. Vulnerability Evaluation - Results Observations from Study I % of correctly formed % of incorrectly formed messages trusted (Avg. / Std. messages trusted (Avg. / Std. User Dev) Dev) Type TPSE SELS TPSE SELS Expert 100 / 0 100 / 0 16.67 / 14.43 8.33 / 14.43 Novice 93.75 / 17.68 100 / 0 18.75 / 17.68 15.63 / 12.94 Observations from Study II % of correctly formed % of incorrectly formed messages trusted (Avg. / Std. messages trusted (Avg. / Std. User Dev) Dev) Type TPSE SELS TPSE SELS Expert 100 / 0 100 / 0 8.33 / 14.43 16.67 / 28.87 Novice 100 / 0 100 / 0 30 / 20.92 35 / 13.69 Useful changes to interfaces • Manage/Cache multiple passwords • Caution users on unsigned messages (Mac Mail already does this) • Alert users when signer and sender do not match SELS Deployment - Production Environment • Redundancy • Two industrial grade servers • Power backup • RAID storage • Partial list isolation • VM for each list • Manual failover • Monitoring scripts SELS Deployment • Customers are Computer Security and Incident Response Teams (CSIRTs) of Computational Grids • Experience with 2 lists from one such CSIRT • ~52 members • Previous used password based security with PGP/GPG tools • Considered expert users • 4 out of 52 faced issues • Compatibility • Misunderstanding about usage SELS Deployment • Security and usability concern of users • Concern about importing “private” key • Removed “signing key” component from SELS user keys • Concern about selecting a wrong key in the interface • Removed “email address” from names of keys for visual distinction • Pushback on placing “Ultimate Trust” in moderator key • Place “complete” or “full” trust in moderator key and sign it locally • Anecdotal evidence to suggest that SELS made it easy to exchange secure messages on these lists Where do we go from here? • Reach out and promote broader adoption • S/MIME is natively supported in popular clients • Develop SELS for S/MIME using recently added ECC support • Improve features based on feedback • Questions? • Contact: • Rakesh Bobba rbobba@illinois.uiuc.edu • Himanshu Khurana hkhurana@illinois.edu • Jim Basney jbasney@illinois.edu • Software: www.sels.ncsa.uiuc.edu Backup Slides Security Requirements X X X • Confidentiality: only authorized users (i.e. list subscribers) should be able to read emails – list server is excluded • Integrity: receivers must be sure that email has not been modified in transit • Authentication: receivers must be able to verify the identity of the sender System Design • Suitable for Server environments MTA List Server SELS where GPG (e.g., Sendmail) Process (e.g., Mailman)Handlers Transformation Agent is/can be used invocation Key Mgmt Crypto Functions (GPG) (GPG, BC Libs) List Moderator Subscriber Interface MUA Interface (GPG Plugin) MUA (GPG Plugin) Crypto Functions Key (GPG, BC Libs) List Crypto Functions Key Mgmt Mgmt Crypto Functions Mgmt (GPG Lib) (GPG) (GPG) (GPG, BC Libs) Legend: COTS component; Developed component Do We Really Need More ID related Standards? www.KeyPairTech.com Where are we now? Technology/mechanism Solutions/Vendors ID Management • Password • Microsof •Workflows • OTP – RSA, OATH • Sun, IBM •Life cycle management of • Smart Card/ Certificate • Oracle, CA different credentials and • Biometrics • Novell tokens • Cookie/Session Id • EMC/RSA •M & A causes tremendous • Kerberos Ticket • Upek, Precise problems • Card Space, STS Biometrics •Rip & Replace – WILL NOT • SAML 1.0, 1.1, 2.0 • Ping Identity WORK • OpenID, GoogleID, • Yahoo, Google, AOL • Change is very very ... hard YahooID, LiveID, etc • Activ Identity, – if not impossible • MAC, IP Authentication Gemalto • Open Source Sofware Key Pair Technologies: IDTrust 2009 What has been our response? • Customer you need: for this service – Customers don’t understand why this need this here versus something different elsewhere • Enterprises has invested in infrastructure which are not flexible – change in algorithm – wait for a new version of this product, BTW, you will need the rest of this kitchen sink • Technologies talk technology, Sales and CxOs talk Value. Both are right and both don’t connect – you do your thing, I will do mine. Where is the MBA course on selling technology to non-technical business folks. Note that the ultimate customer is non-tech person. • Regulation is seen by CxOs as a pain and expense and not as how it saving them money or making them more secure, etc. Identity is the main driver for Regulations today. Key Pair Technologies: IDTrust 2009 Next Steps • Develop a Vision for IDentity1 • Develop lessons learnt from developing and deploying each of these ID technologies • Now we can think about more ID related Standards if they don’t address needs, but, also develop a deployment and migration plan • I am very interested in this topic. You can contact me: shivaram@KeyPairTech.com [1] http://middleware.internet2.edu/idtrust/2009/slides/05-neumann-context.pdf Key Pair Technologies: IDTrust 2009 Concept A claimant produces a claim set. A claim is an assertion about a person (possibly the claimant) E.g., Org==”NIST”, Weight==”80 Kg” A relying party resolves a claim set. If, on weight of evidence, the claim set resolves to a single person, the claim set identifies the person to the relying party. Refinements A digital identity is a digital representation of a claim set. A cryptohash of a digital identity is an identifier for the person identified. Pseudonyms can be produced through secondary claim sets by addition or deletion of claims inclusion of nonces, timestamps, or recipient identifiers Group Signatures with Selective Disclosure for Privacy Enhanced ID management NEC Central Research Labs Kazue Sako Jun Furukawa k-sako@ab.jp.nec.com ○ Self Introduction • Been to many crypto conferences like Crypto, Eurocrypt, FinancialCrypto,… first time to IDTrust • Worked on implementing remote voting based on MIX-nets, which have been used in a private organization with 20,000 voters for nearly 5 years. • My belief: Crypto should help build a better system and serve for the future society – Started discussing the use of Group Signatures at ISO/IEC JTC1 SC27 WG5 …A little discouraged by bad reputation on PKI Ｐage 2 © NEC Corporation 2009 Group Signatures • Generating a single authentication data which provides two levels of verification Verify Group Group Public Key attribute Group SIg. Level２ Cannot Encrypted ID Group Identify User ＯＫ！ Zero Knowledge Authorized Proof Server ID？ Group Only the Level１ ID authority with a authentication data ＯＫ！ Authority secret key can (signature) identify the user Digital Sig. Anyone can verify and Ordinary PKI ID identify the user authentication data ＯＫ！ (signature) Ｐage 3 © NEC Corporation 2009 Group Signatures Selective Disclosure Extension PKey：■■■ SSN：■■ Public Key ： LicenseNo： ■■■ ■■■ PassportNo： CA’s sign： ■■■ ■■■ CA’s sign： ■■■ I have a secret My LicenseNo I have a secret key to a public is 12345 key to a valid key signed by certificate with the CA Licence No 12345 Ｐage 4 © NEC Corporation 2009 Merit of Extended Group Signature Scheme Pkey：■■■ Pkey：■■■ Pkey：■■■ SSN：■■ SSN：67689 SSN：■■ LicenseID： LicenseID： LicenseID： 12345 ■■■ ■■■ PassPortNo： PassportNo： PassportNo： ■■■ ■■■ 39305 CAsig：■■■ CAsig：■■■ CAsig：■■■ One Signed Three Certificate users? for each Same User users? Ｐage 5 © NEC Corporation 2009 Wes Kussmaul CIO, Reliable Identities a unit of The Village Group IDENTITY Identity Is The Foundation Of Security™ IDQA™ Identity Quality Measured in Six “Dimensions” (Patent Pending) PRIVATE PUBLIC 1. Degree to which the Identity Protects Personal Assets 2. Quality of Enrollment Practices 3. Quality of Attestation 3. Quality of Attestation ????? 3. Quality of Attestation What is Authority? Trust Management Engineer Matt Blaze: “A commercial certification authority protects you from anyone whose money they refuse to take." 14 4.Quality of Means of Assertion 5. Quality of the Credential 6. Degree of Assumption of Liability Each of the six Dimensions of Identity Quality is measured using a scale of 0 to 9, with 0 being the lowest rating in a particular “dimension.” Wes Kussmaul CIO, Reliable Identities a unit of The Village Group Break the Glass Confidential Record Obligation Policies 1. (7). Request access to 9. Retrieve Record confidential record 3. Denied (10). Conf.Record 4. Break the Glass Policy Enforcement 6. Granted Point Appl Indep Policy PEP Decision Point 5. Enforce 2. (8). Retrieve Obligations State Email 5. Notify Obligations Security Service State Officer 5. Update State Information 5. Log Audit Secure Audit Trail Web Service Easy To Use Secure Mail Tim van der Horst Kent Seamons seamons@cs.byu.edu ISRL Internet Security Research Lab http://isrl.cs.byu.edu Email is a postcard Almost all email is sent in the clear Email provider can access stored messages Users increasingly trust online service providers to store their email ◦ Google, Yahoo, Hotmail, etc. Encrypted email Encrypted email solves the postcard problem Current solutions ◦ PGP ◦ S/MIME No widespread adoption ◦ Hard to get keys for self and recipients ◦ Many users don’t know what encryption is, or how to use it Our solution Sender  Download and install an email plug-in  Prove her identity to the key server ◦ Receive an email message from the key server ◦ Happens once per email address  No more interaction required with key server to send secure messages to any recipient  Simply specify the email address of the recipient and send secure email messages  The email contents are encrypted and sent to the recipient as an attachment, along with plain- text instructions in the body of the message indicating where to obtain software to decrypt the message Recipient  First-time receipt of encrypted message ◦ The sender and subject line of the message are in plain text ◦ The plaintext body informs the recipient that the message attachment is encrypted and refers the user to a plug-in needed to decrypt the message ◦ The recipient installs the plug-in ◦ Recipient proves her identity to the key server  Receive an email message from the key server  Happens once per email address  Decrypt a secure email messages ◦ Click on the message in the inbox to read the messages ◦ Client software obtains decryption key from the key server based on sender’s and recipient’s email address. The key can be cached at the client. ◦ Message is decrypted and displayed to the user. How our secure email works KDF(x) Security analysis Trust model ◦ Key escrow  Key server can derive all keys ◦ Messages don’t pass through the key server ◦ Business can host their own key server Threats ◦ Basic model thwarts passive observation ◦ Vulnerable to some impersonation attacks  Due to how key server authenticates a user’s ability to receive an email message  Use of a stronger authentication mechanism eliminates this weakness  The design supports a dial for convenience/security Prototypes 3rd party key server ◦ Crypto card to protect master key Clients ◦ Firefox extension for Gmail  Web mail ◦ Thunderbird extension  Standard email client ◦ Java applet  Loosely coupled with any email client  Available to a user for any client that does not have a plug-in available for secure email Future plans Hosta key server for public use Popular email clients ◦ Web: Gmail, Yahoo, Hotmail, AOL ◦ Traditional: Thunderbird, Outlook, Lotus Notes User studies ◦ Obtain feedback from users to guide design decisions Delivering Anonymous Certificates Presented to: IDTrust2009 Presented by: James L. Fisher (jlf@...org) Date: April 16, 2009 Company Confidential/Proprietary Requesting Anonymous Certificates User Anonymous CA Authorizer (Z) • Request for anon key pair + cert = f( assignedGroup, Encrz(trueID) ) • Authorization request = f( Encrz(trueID) ) • Decr( Encrz(trueID) ) • Too many requests? • Generate & send • Authorization granted anon key pair + cert • Has authZ to act • Knows which anon keys • Checks eligibility sent • Knows requestor’s ID • Does not know who • Does not know anon “Two to collude” received them keys sent Company Confidential/Proprietary 2 Requesting Anonymous Certificates User Anonymous CA Authorizer (Z) • Request for anon key pair + cert = f( assignedGroup, Encrz(trueID) ) • Authorization request = f( Encrz(trueID) ) • Decr( Encrz(trueID) ) • Too many requests? • Generate & send • AuthZn granted anon key pair + cert • Has authZ to act • Knows which anon keys • Checks eligibility sent • Knows requestor’s ID • Does not know who • Does not know anon “Two to collude” received them keys sent Company Confidential/Proprietary 3