IDtrust 2011 10th Symposium on Identity and Trust on the Internet Program with Presentations Notes Transportation There will be a shuttle bus leaving the Gaithersburg Holiday Inn at 8:00 a.m. Wednesday and Thursday morning to travel to NIST. The shuttle will return to the hotel at the end of the poster reception on Wednesday (7:30 PM) but there will not be a return shuttle bus on Thursday. NIST has regular shuttle service to the Shady Grove Metro station. Wireless 802.11b Wireless access points will be available. Blogging Participants and observers are encouraged to use the tag "idtrust2011" when blogging and tweeting about the symposium. Program Wednesday, April 6, 2011 - Full Day 8:00 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00 - 9:15 Welcome How the World has Changed - IDtrust 10th Anniversary Retrospective: Ken Klingenstein, Internet2 (Slides: ppt ) 9:15 - 9:45 Invited Talk Whither Identity Management?: Tim Brown, CA Technologies (Slides: pdf ) Identity management has gone through a number of transitions and continues to evolve. This session will discuss: Where has identity management been? What have we learned? What are the challenges we face? Where is it going? 9:45 - 10:45 Panel - Usability Issues in Identity Management: Improving the engagement ceremony between users and services Panel Moderator: Trent Adams, Internet Society (Slides: ppt ) Larry Drebes, JanRain (Slides: pdf ) Paul Trevithick, Azigo (Slides: pdf ) Ken Klingenstein, Internet2 (Slides: ppt ) Don Thibeau, Open ID Foundation Asking users to know the protocol running a system's identity management solution is like asking them to list the constituent elements that make up the air we breathe. In most cases, users just want to get into a system quickly and easily (often to the detriment of security). This panel brings together cross- protocol practitioners (e.g. OpenID, SAML, OAuth) working on usable solutions that attempt to balance issues such as utility, efficiency, and security. Among the topics to be discussed are technical and usability issues surrounding identity provider discovery. 10:45 - 11:15 Break 11:15 - 12:45 Panel - Privacy: An Emerging Landscape Panel Moderator: Carl Ellison, Independent (Slides: pptx ) Trent Adams, ISOC (Slides: pdf ) Al Zarate, National Center for Health Statistics (Slides: ppt ) Ken Klingenstein, Internet2 (Slides: ppt ) Brian LaMacchia, Microsoft (Slides: pptx ) Privacy, like security, is emerging as a broad and diverse landscape, and advances are happening in several areas. After an opening talk that describes this landscape, talks will drill down into the most important developments in technical and policy activities. We will look at the failure of anonymization technologies for large data sets and its consequence on research. Consent for the release of personal attributes is becoming real in federated and social identity and we will look at perspectives in both the US and Europe. We will also look at new technologies that provide selective personal information release and how they fit into the landscape. 12:45 - 1:45 Lunch 1:45 - 2:15 Keynote Talk National Strategy for Trusted Identities in Cyberspace: Jeremy Grant, NIST (Slides: pptx ) The National Strategy for Trusted Identities in Cyberspace (NSTIC) is a White House initiative to work collaboratively with the private sector, advocacy groups, public sector agencies, and other organizations to improve the privacy, security, and convenience of sensitive online transactions. The Strategy calls for the development of interoperable technology standards and policies - an "Identity Ecosystem" - where individuals, organizations, and underlying infrastructure - such as routers and servers - can be authoritatively authenticated. The goals of the Strategy are to protect individuals, businesses, and public agencies from the high costs of cyber crimes like identity theft and fraud, while simultaneously helping to ensure that the Internet continues to support innovation and a thriving marketplace of products and ideas. The Strategy was developed with substantial input from the private sector and the public. It calls for the effort to be led by the private sector, in partnership with the federal government, consumer advocacy organizations, privacy experts, state and local agencies, and others. NIST has been asked by the White House to lead the implementation of NSTIC. NIST's Jeremy Grant will give an overview of the soon-to-be-released Strategy and detail the role NIST will play in collaborating with the private sector to move NSTIC forward. 2:15 - 3:30 Panel - Privacy and Security Research Challenges for Biometric Authentication Panel Moderator: Elaine Newton, NIST (Slides: ppt ) Ross Micheals, CSC (Slides: pdf ) Stephanie Schuckers, Clarkson University (Slides: ppt ) Terrance Boult, University of Colorado (Slides: ppt ) For biometric technologies to be deployed in support of identity assurance, it is essential to distinguish between the role that biometric technologies can play in Identity Proofing (establishment of identity) versus Identity Authentication (affirmation of the holder of a credential or identifier by which the user is known to the system), as each of these functions typically have differing policies (i.e. in- person versus remote); technology availability (i.e. full desktop system versus embedded scanner); and security and privacy considerations. Biometric systems are typically used as part of an overall security system. Stolen biometric information are a security risk, may be non-revocable, and contain privately identifiable information. Development of countermeasures is needed to minimize vulnerabilities of these systems. Specific R&D challenges that will be noted in this discussion include: biometric template protection algorithms, revocable/cancelable biometrics, anti- spoofing/liveness detection testing, and best practices for e-authentication and the treatment of biometrics in an identity assurance framework. 3:30 - 4:00 Break 4:00 - 5:15 Panel - Successful Implementation of Identity Management Systems Integration Panel Moderator: Steve Whitlock, Boeing Vijay Takanti, Exostar (Slides: pptx ) Mollie Shields-Uehling, SAFE-Biopharma (Slides: ppt ) Debbie Bucci, National Institutes of Health (Slides: pptx ) Over sixty years have passed since the discovery of public key concepts and thirty years since the development public key algorithms. In the last twenty years governments, corporations, universities and individuals have spent fortunes in resources and lifetimes in the process of conversion from concepts and ideals to technologies, products and services that enable e-services. This panel will focus on success stories and examples of working implementations from several different communities. 5:15 - 7:30 Poster Session / Reception at NIST IDtrust did not have a peer review process this year, but we did want to have a more informal process to let people offer some ideas to share. So we invited poster submissions, and the following will be at the reception. Efficient Transmission of DoD PKI Certificates in Tactical Networks Sean R. O'Melia, MIT Lincoln Laboratory Roger I. Khazan, MIT Lincoln Laboratory Dan Utin, MIT Lincoln Laboratory Draft FIPS 201-2 Discussion Point Bill MacGregor, NIST Hildy Ferraiolo, NIST Ketan Mehta, NIST Sal Francomacaro, NIST Ramaswamy Chandramouli, NIST Towards a method for managing distributed access entitlement and access certification (Can we trust that AuthZ attribute?) Corinne Irwin, NASA Dennis Taylor, NASA/ASRC Primus Solutions Trust in National Identity Systems: Exploring Citizen Risk Perception Adrian Rahaman, University College London Angela Sasse, University College London PKAuth: A Social Login Protocol for Unregistered Apps Francisco Corella, Pomcor Karen Lewison, Pomcor System Diagram of Federated Identity, Authentication and Authorization using X.509 Certificates and SAML Robert Cope, Homeland Security Consultants 7:30 Bus Departs for Gaithersburg Holiday Inn Thursday, April 7, 2011 - Half Day 8:00 Bus Departs from Gaithersburg Holiday Inn for NIST 8:30 - 9:00 Registration and Continental Breakfast 9:00 - 9:30 Invited Talk Unified Identity for Access Control: Carl Ellison, Independent (Slides: ppt ) There is much debate over the nature of identity and how it relates to authenticators, identifiers, attributes, named groups, etc. Taken in isolation, these debates rely on near-philosophical concepts of identity. Rather than be another voice in those debates, on those terms, we look here at the functional needs of access control in large scale industrial environments. From those needs, we show a need for more than one form of identifier or attribute, but where each is established in a single statement from some authority on that particular statement. We also show that chains of such statements will be required in normal access control decisions. We then give a single representation of such statements that captures all of the different kinds of statement and an algorithm over chains of those representations that establishes the truth of a chain. The algorithm for proving validity of deductions is not confined to a single organization, so it gives implicit federation not just of identifier but of attributes. 9:30 - 11:00 Panel - 2 Factor Authentication and Higher Level-of-Assurance Issues Panel Moderator: Ken Klingenstein, Internet2 Elaine Newton, NIST (Slides: ppt ) William MacGregor, NIST (Slides: ppt ) Paul Donfried, Verizon Business Solutions (Slides: pptx ) Invited Talk Digital Signatures - Current Barriers: Simson Garfinkel, Naval Postgraduate School (Slides: pdf ) 11:00 - 11:30 Break 11:30 - 12:45 Panel - Creating the Attribute Ecosystem Panel Moderator: Peter Alterman, NIH Jack Suess, InCommon Steering & UMBC (Slides: ppt ) Debbie Bucci, National Institutes of Health (Slides: pptx ) Ken Klingenstein, Internet2 (Slides: ppt ) With the focus of identity management shifting from authentication to the attributes being shared across the ecosystem, key issues around the creation and consumption of attributes are emerging. In those domains where regulation defines roles and permissions, such as pharmaceuticals and financials, attribute schema can be modeled in both syntactic and semantic standards by the federations that operate in those sectors. In the broader public sector, key attributes for many federated uses cases, including "over legal age", citizenship, physical limitations, and at least a few others lack a mechanism for such normalization. This session will look at key issues of the ecosystem (attribute LOA, sources of authority and delegation trails, query languages, inter-state and inter-national jurisdictional issues), the development of attribute schema in some verticals such as government and R&E, and discuss processes for normalization of public and marketplace attributes. 12:45 - 1:00 Wrap Up Program Chair: Carl Ellison, Independent (Slides: pptx ) See Also This workshop is part of the IDtrust Symposium Series •2011: 10th Symposium on Identity and Trust on the Internet (IDtrust 2011) •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 “Ten Years Ago… on a cold dark night” Welcome Acknowledgments and thanks Security Acronymny: then and now What’s working What’s proving hard Acknowledgments NIH and NIST – Peter Alterman, Tim Polk and Bill Burr NSF – Early Adopters and NSF Middleware Initiative Internet2 Membership PKI Labs, PKI Advisory Board, Neal McBurnett Program Committee and Sean Smith Security Acronymny circa 1998 PKI X.500 X.509 CRL RSA PGP Security Acronymny circa 2002 PKI GXA X.500 Liberty X.509 Magic Carpet CRL SAML OCSP Shibboleth LDAP XML RSA HEBCA PGP FBCA XKMS SPKI Security Acronymny circa 2002 E-authentication 9-11-01 OGSA GSS E-SIGN E-LOCK ACES CAM DAVE Observations I was really ignorant in 1998 This is proving really hard There are a lot more approaches, if only because there are lots more needs Partitioning the problem space may be better than the unified solution What’s working At the core, the math of PKI remains extremely elegant The standards, protocols and processes of PKI are open PKI attracts really smart people What’s proving hard Scaling: virtual organizations, federations, bridged hierarchies Trust: collaborative versus legal Integrating security and privacy Mechanics: mobility, archiving, key escrow, identity Authorization: role based versus atomic rights Reconciling humans and lawyers Interrealm Trust Structures Federated administration • basic bilateral (origins and targets in web services) • complex bilateral (videoconferencing with external MCU’s, digital rights management with external rights holders) • multilateral Hierarchies • may assert stronger or more formal trust • requires bridges and policy mappings to connect hierarchies • appear larger scale Virtual organizations • Grids, digital library consortiums, Internet2 VideoCommons, etc. • Share real resources among a sparse set of users • Requirements for authentication and authorization, resource discovery, etc need to leverage federated and hierarchical infrastructures. The Continuum of Trust Collaborative trust at one end… • can I videoconference with you? • you can look at my calendar • You can join this computer science workgroup and edit this computing code • Students in course Physics 201 @ Brown can access this on-line sensor • Members of the UWash community can access this licensed resource Legal trust at the other end… • Sign this document, and guarantee that what was signed was what I saw • Encrypt this file and save it • Identifiy yourself to this high security area Dimensions of the Trust Continuum Collaborative trust Legal trust handshake contractual consequences of breaking trust consequences of breaking trust more political (ostracism, shame, more financial (liabilities, fines and etc.) penalties, indemnification, etc.) fluid (additions and deletions more static (legal process time frequent) frames) shorter term longer term (justify the overhead) structures tend to clubs and tends to hierarchies and bridges federations privacy issues more laws and privacy issues more user-based rules The Trust Continuum, Applications and their Users Applications and their user community must decide where their requirements fit on the trust continuum Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach. Many applications fit somewhere in the middle and the user communities (those that trust each other) need to select a approach that works for them. Integrating Security and Privacy Balance between weak identity, strong identity, and attribute- based access (without identity) Balance between privacy and accountability – keeping the identity known only within the security domain Reconciling Humans and Lawyers Non-repudiation has had a very high bar set… Human nature has been “refined” over a long time We tend to talk globally, think locally and act inconsistently… Conference Outcomes Refine our understandings of security Cross-pollinate PKI research Identify experiments that should be conducted Why PKI? Single infrastructure to provide all security services Established technology standards, though little operational experience Elegant technical underpinnings Serves dozens of purposes - authentication, authorization, object encryption, digital signatures, communications channel encryption Low cost in mass numbers Why Not PKI? High legal barriers Lack of mobility support Challenging user interfaces, especially with regard to privacy and scaling Persistent technical incompatibilities Overall complexity D. Wasley’s PKI Puzzle Federal Activities fBCA NIH Pilot ACES fPKI TWG Others – federal S/MIME work Internet2/NIH/NIST research conference ... The Industry What's the problem with PKI then? It all boils down to one thing: Complexity. Wanted: PKI Experts By Scot Petersen July 18, 2001 The Industry Baltimore in peril PKIforum slows down OASIS-SAML work (XML to leaven PKI) gains buzz RSA buys Securant Ten Years Forward… The issues here have become immensely important The cutting edge is being blunted by the demands of deployment It’s too important for us to be doing it… 10TH SYMPOSIUM ON IDENTITY AND TRUST ON THE INTERNET (IDTRUST 2011) Identity and Access Management “Near the Horizon, Just Over the Horizon” Tim Brown SVP Distinguished Engineer CA Technologies timothy.brown@ca.com Identity and Access Management transitions along with technology and the threat environment Technology and the Threat Landscape is evolving Automation SaaS, IaaS, PaaS, Enablement Virtualization SOA WWW Prevention Client Server Secure Platform/ The Cloud Dumb Terminal  Elastic Web 2.0  Self-provisioning  Pay per use  Collaborative  Virtualized  Mobile Distributed  Simplified  Dynamic x86 Computing IAM Matures Cloud IAM Emerges IAM Emerges •Web SSO •Identity Assurance Mainframe •Role Management •Cloud Access •DLP / PUM Management Limited IAM •Federation •Identity Governance 2 Near the Horizon — Huge amount of information and applications available from anywhere — Multi-Use Identities emerge beyond communities of trust − Facebook, Google, Yahoo — Many communities of trust emerge utilize Cloud based Identities − Healthcare, State and Local Govt, — NSTIC is a Catalyst– National Strategy for Trusted Identity in Cyberspace will be announced on April 15th − Cooperation between standards organizations • OpenID, Kantara, OIX, − Community Frameworks such as TSCP emerge to solve specific problems 3 Near the Horizon — Acceptance of online credentials as legally binding − Commonwealth of Virginia – Enabling digital signing of documents — Emergence of “Trusted Identity Providers” that assume some liability − Governments, Banks, Independent entities — Move to claims based Identity Models and away from simple username and password — Increased use of mobile device as identity and transaction enabler (Stronger Auth necessary in Cloud apps) — Continued increase in sophisticated threat: Insiders take center stage — Privacy and Identity becoming more linked 4 Just Over the Horizon — Security moves closer to the data − Policy based just in time access control with no static roles or groups − All access is granted based on current level of risk and the objects policy − Digital rights management based on encryption — “There’s an App for that” creating the next generation of IAM issues — Identity information will flow between devices and become enable the next generation of social networking — Use of true identity and biometrics increasing. Facial recognition, DNA scans etc (Passport control, India Identity project) — Global standards emerging (Maybe)? — Cloud will drive vendors to have better controls and identity systems 5 that enable collaboration What’s Next — An Identity centric world − That enables the appropriate level of authentication to be used based on risk − That requires the minimal amount of information to be shared for a transaction − That grants access to information only for the time necessary − That is easy to use and acceptable to the masses — Enable the right people to have the right access to the right data at the right time 6 Questions? Usability Issues in Identity Management Improving the engagement ceremony between users and services Panel Moderator: J. Trent Adams (adams@isoc.org) Usability Issues in Identity Management: Improving the engagement ceremony between users and services Asking users to know the protocol running a system's identity management solution is like asking them to list the constituent elements that make up the air we breathe. In most cases, users just want to get into a system quickly and easily (often to the detriment of security). Users just want in. April 6, 2011 Usability Issues in IdM Panel 2 Usability Issues in Identity Management: Panelists • J. Trent Adams, Internet Society (Moderator) • Larry Drebes, JanRain • Paul Trevithick, Azigo • Don Thibeau, Open ID Foundation • Ken Klingenstein, Internet2 April 6, 2011 Usability Issues in IdM Panel 3 Usability Issues in Identity Management: Topics • What is the role of automated IdP discovery, and why does it matter to issues such as adoption, conversion, usability? • What solutions currently exist for IdP discovery? How are they similar and different? How widely deployed are they today, and is there a future roadmap? • What are the goals of the various stakeholders who are interested in IdP discovery? What are the differences between the solutions supporting end users, enterprise, and government, and can they effectively be aligned? • How do solutions interface with legacy systems? Is there a difference in approach for wired, wireless, and mobile systems? • How do the solutions address issues of user privacy? Is it possible to automate IdP discovery in way that minimizes information leakage? • How does IdP discovery relate to attribute discovery, or the discovery of service meta-data? Is there work being done to explore attribute exchange as distinct from IdP? April 6, 2011 Usability Issues in IdM Panel 4 Thank you. Questions? Comments? Send them to: J. Trent Adams (adams@isoc.org) The Internet Society:  InternetSociety.org  info@InternetSociety.org April 6, 2011 Usability Issues in IdM Panel 5 Janrain     Janrain  User  Management  Pla0orm   2 3 Original  UI   4 UI  Helper   5 Current  UI   6 Return  Experience   7 User  Acquisi+on:  Users  Prefer  Interac=ng  On  Mul=ple  Pla0orms   8 User  Data  Management:  Breadth  of  Profile  Data  By  Provider   Friends/   Profile   Social   Network   Email      Name   Loca+on   Birth  Date   Gender   Interests   Contacts   Photo   Publishing   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   9 User  Data  Management:  Depth  of  Social  Data  By  Provider   Full  List  of  Available  Profile  Data  –  www.janrain.com/providerguide     10 Configuring  the  UI  is  “drag  and  drop”   Gain  Insight  through  Ac+onable  Analy+cs   Universal Login Experience Kantara Initiative Co-chair: Philippe Clement (Orange) Co-chair: Bob Morgan (University of Washington) Co-chair: Paul Trevithick (Azigo) User Experience Architect: Valeska O’Leary (Azigo) Objectives   Focus on user experience   Ignore technical feasibility (at least at first)   Multi-language   Support people with various disabilities   Protocol-agnostic   OpenID, SAML, Infocard, Webfinger, userid/password   Could be extended to Facebook Connect, and others   Three deployment architectures   RP-embedded selector   Selector agent web service   Active client Conceptual Architecture IdP IdP Selector RP/SP IdP Learnings   Let the RP/SP use its own UI to initiate login (e.g. “login” button)   Don’t impose a standard button or icon   Ended up with a UI “theme with variations”   E.g. If more than N IdPs than include the search widget   E.g. if support Webfinger then allow email address entry   Lists vs. use icons   Allow search provider name AND keywords Logic drives the UI Next Steps: Metadata   Describing the RP/SP policies to the Selection Agent   What providers are trusted?   What claims are required?   Describing the IdPs to the Selection Agent   Icons (if available)   Claims supported   [Maybe] Expand to non-login use cases   [Maybe] Expand to “multi-IdP” claims aggregation   User selects multiple IdPs to gain all necessary claims Discovery and Federated Identity Topics • Life today and the pull-down list fromHell • Hints at the wrong layer suck • The importance of keeping the continuity of experience • Staying with the story • How does the likely path of interfederation affect discovery kjk@internet2.edu Life Today • Workarounds • Initiating at the IdP – e.g. PSU get to NIH through the PSU research web site. • Hand out Per-IdP URLs (e.g. Google) • Assume one IdP, "click here if you're a weirdo" in its login UI • Models • SP/Embedded – e.g .Elsevier • Centralized/Shared • SP-centric - e.g. NIH Federated Login gateway vs. federation/IdP centrice.g. WAYF, InCommon kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu Moving from /etc/hosts to interfederation • Connecting autonomous federations • Critical for global scaling, accommodating state and local federations, integration across vertical sectors • Has technical, financial and policy dimensions • Technical solutions include eduGAIN and MDX • Policy activities in eduGAIN, Kalmar2 Union, Kantara, Terena kjk@internet2.edu MDX – metadata exchange protocol • Institutions and organizations will pick a registrar to give their metadata to • Institutions and organizations will pick an aggregator (or several) to get their partners metadata from • Aggregators exchange metadata with each other and registrars • If this sounds like DNS registration and routing, it is, one layer up kjk@internet2.edu PEER Big Picture kjk@internet2.edu Implications for discovery • So many IdP’s… • Can sub-select at the SP • Can get sticky at the SP • Discovery for non-web apps • Pop up a browser • Sticky on the device (cookie, cert,…) kjk@internet2.edu Privacy Panel • Trent Adams, Internet Society • Al Zarate, National Center for Health Statistics • Ken Klingenstein, Internet2 • Brian LaMacchia, Microsoft Research Three Forms • American – subject takes responsibility for her own privacy – don’t share any data, but if you do share data, it’s free for everyone • European – recipient of personal data takes responsibility for the subject’s privacy – share data with people you trust to respect your privacy • Census – distillation of useful data from databases while destroying personal data – share anonymized data with those you don’t trust Online Privacy – A Global Perspective •  Framing Online Privacy •  Survey of Global Membership •  International Policy & Regulatory Activities •  The Bumper Sticker April 6, 2011 Online Privacy - A Global Perspective 2 Privacy Overview – “Iʼll know it when I see it.” •  A definitive definition of “privacy” is as elusive as one for “art” April 6, 2011 Online Privacy - A Global Perspective 3 Privacy Overview – An OECD Definition •  OECD defines privacy as a concept that applies to data subjects:
 •  “It is the status accorded to data which has been agreed upon between the person or organisation furnishing the data and the organisation receiving it and which describes the degree of protection which will be provided.”
 •  NOTE: This definition is from the OECD “Glossary of Statistical Terms”, which is maintained as a “comprehensive set of definitions of the main data items collected by the organisation.” … though this definition is not frequently cited, and there is no other concise definition within the OECD.
 http://stats.oecd.org/glossary/detail.asp?ID=6959 April 6, 2011 Online Privacy - A Global Perspective 4 Privacy Overview – Unpacking a Concept { } Sharing (data) in an Online Privacy = explicit context with an expectation of scope. April 6, 2011 Online Privacy - A Global Perspective 5 Privacy Overview – Striking a Balance •  Privacy Protection in the Context of Personal Data on the Internet •  Supports confidence in the overall network •  Network Confidence = Usability (Privacy + Security + Reliability) April 6, 2011 Online Privacy - A Global Perspective 6 Privacy Overview – International ISOC Member Survey •  Regional Differences Emerged, Including: •  Societal – Responses from Asia tended to focus on security of personal data. •  Regulatory - Responses from countries with well-established privacy laws tended to be more specific with policy suggestions. •  Priority - Respondents in countries with low Internet penetration prioritized connectivity over privacy concerns. Full Report: http://www.isoc.org/internet/issues/privacy.shtml April 6, 2011 Online Privacy - A Global Perspective 7 Privacy Overview – International ISOC Member Survey •  Emerging Challenges Included: •  Data Durability – How to effectively manage long-lived personal data. •  Economics of Privacy – What is the value of personal data, and how to balance the transborder flow of legal economic activity & privacy. •  Ownership, Control and Responsibility – Who owns what data, how is it controlled, and who is the responsible party. •  Surveillance – How to protect individuals from intrusive observation from governments and enterprise. •  Transparency and Understanding – How to ensure adequate understanding of how personal data is collected and used. •  Unauthorised Access and Use – How to address issues related to the illegal and/or unauthorised access to or use of personal data. April 6, 2011 Online Privacy - A Global Perspective 8 Privacy Overview – Some Useful Regulatory Foundations Directive 95/46/EC of the European Parliament and Council US Privacy Act Japan Personal Information Protection Act UN Guidelines on Personal Data Files Safe Harbor Privacy Principles 1970 1980 1990 2000 OECD Privacy Guidelines Australian National Privacy Principles CoE Convention 108 APEC Privacy Framework CSA Model Code for the Protection of Personal Information April 6, 2011 Online Privacy - A Global Perspective 9 Privacy Overview – International Regulatory Activities •  OECD •  Preparing an anniversary report on the evolving privacy landscape.
 •  Council of Europe •  Considering how to modernize Convention 108 for the Protection of Individuals with regard to “Automatic Processing of Personal Data”
 •  European Commission •  Reviewing general legal frameworks on personal data protection such as Directive 95/46/EC of the European Parliament and Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data April 6, 2011 Online Privacy - A Global Perspective 10 Privacy Overview – International Regulatory Activities (2) •  APEC Data Privacy Pathfinder Project •  Building on the guidance of APEC data privacy principles, they are developing and testing practical elements of a system to enable accountable cross-border data flows
 •  International Conference of Data Protection and Privacy Commissioners •  2009 – “Madrid Resolution” Statement on The Necessity of International Frameworks in Support of The Protection of Privacy and Personal Data •  2010 – “Jerusalem Declaration” calls for the an intergovernmental conference to develop a binding international instrument on privacy and the protection of personal data April 6, 2011 Online Privacy - A Global Perspective 11 Privacy Overview – Hot-Topic Issues •  Issues Discussed in International Regulatory Bodies: •  “Right to be Forgotten” •  “Privacy by Design” & “Privacy by Default” •  “Transparency” & “Informed Consent” •  “Identification” vs. “Correlation” •  “Data Minimization” •  “Data Protection” •  “Jurisdiction of Origin & Use” •  “Online Activity Tracking” •  “Defining Personal Data” April 6, 2011 Online Privacy - A Global Perspective 12 Privacy Overview – Whatʼs the Bumper Sticker? April 6, 2011 Online Privacy - A Global Perspective 13 Privacy Overview – Whatʼs the Bumper Sticker? (since we’re dreaming anyway…) April 6, 2011 Online Privacy - A Global Perspective 14 Privacy Overview – Whatʼs the Bumper Sticker? { Sharing (data) in an explicit context Online Privacy = with an expectation of scope. } Privacy ~ Secrecy -and- Privacy != Secrecy Online Privacy is more than just the web Privacy. I’ll know it when I see it. April 6, 2011 Online Privacy - A Global Perspective 15 April 6, 2011 Online Privacy - A Global Perspective 16 Achieving Anonymity in Micro Data Files 10th Symposium on Identity and Trust on the Internet April 6-7, 2011 Privacy: An Emerging Landscape Alvan O. Zarate, Ph.D. Scientific Data Analyst National Center for Health Statistics NCHS – the Federal Government’s Principal Health Statistics Agency – Data Collection, • Population Based surveys - Health Interview Survey - Clinical Examination - Family Formation • Records Based data collection - Vital Statistics - Hospital, Nursing home, MDs. 2 Data Collected I • Coroner’s reports • Cause of fetal death • Other cause: suicide, hiv • Drug & alcohol use • Sexual experiences & preference • Sexually transmitted disease • Income • Genetics 3 Data Collected II • Date of birth, gender • Occupation • Education • Race • Geographic area (street, county, state) • Household characteristics 4 Two Requirements • “...shall publish ... and disseminate ... [it’s] ... statistics on as wide a basis as is practicable.” • No identifiable information ... may be used for any purpose other than the purpose for which it was supplied nor may it be released to any party not agreed to by the supplier. Public Health Service Act of 1974 5 Applicable Law • Privacy Act • FOIA (Exceptions for identifiable data) • Public Health Service Act (308(d)) Upheld in Appellate Court • E-Govt. Act (Title V - Confidential Information Protection and Statistical Efficiency Act ( CIPSEA) 6 Terms and Concepts Privacy Informed Consent Confidentiality Disclosure Identifiability De-identification Re-identification 7 Privacy “Informational privacy encompasses an individual's freedom from excessive intrusion in the quest for information and an individual's ability to choose the extent and circumstances under which his or her” information “will be shared with or withheld from others.” Private Lives and Public Policy 1993 8 Informed Consent • agreement to allow personal data to be provided for research and statistical purposes. … based on full exposure of the facts the person needs to make the decision intelligently, • (including possible linkage to other information and identities of other parties who would be given access to identifiable data.) 9 Informed Consent - consequences • A binding contract – strictly observed • Ability to restrict access not authorized - for NCHS denial of congressional claim upheld by U.S. Court of Appeals • Basis of claim to stewardship responsibility 10 Confidentiality “A quality or condition accorded to information as an obligation not to transmit that information to an unauthorized party.” National Research Council 1991 “…the promises … made to a data provider …regarding the extent to which the data provided will allow others to gain specific information about the data provider or data subject.” Private Lives and Public Policy 1993 11 Disclosure • Inappropriate (cf. consent) attribution of information to a data subject. - Information disclosure: sensitive information about an individual revealed - Identity disclosure: data provider identified together with associated sensitive information 12 Identifiable Information • Data which can be used to establish individual identity, whether directly - using items such as name, address or unique identifying number - or indirectly - by linking data about a respondent with other information that uniquely identifies them 13 Direct and Indirect Identifiability Direct identifier: Information that is uniquely associated with a person or the person’s family. Readily available and leads directly to them with few intermediary steps. Indirect identifier: Information items which, in combination are uniquely associated with a person. Information which facilitates such associations. 14 Re-identification by Matching “De-identification” Identified file Name abcdefghijkl Identifier deleted abcdefghijkl “Re-identification” Public use file abcdefghijkl External file abcdefgmno Name 15 16 Data in Combination • Month, day and year of birth • Gender • Zip code 17 Unique-ness Using Three Variables Variables % Unique in voter registration list Birthdate alone 12 Birthdate + gender 29 Birthdate + Zip (5) 69 Birthdate + Zip (9) 97 Sweeney, 1997 18 Data Release •Unrestricted (public use) •Restricted (identifiable/confidential) - Collaborators - Other researchers/agencies - Data Center/Enclave (use but no release) 19 Data Release – Public Use Unrestricted (de-identified) • “…when … microdata are released to anyone who wants them, with no restrictions or conditions of any kind…” (Jabine, 1993. Emphasis added) 20 Disclosure Review - Steps • Study documentation • Check list • Consultation with Confidentiality Officer • Submission to DRB • Presentation/discussion at DRB • Follow-up as necessary • Decision 21 Disclosure Risk Checklist • Series of questions designed to help determine the suitability of releasing data. - geographic detail – explicit & implicit - statistical outliers re selected variables (age, race, occupation, income, household type) - intentional & unintentional error - other data bases containing similar data 22 Assessing Disclosure Risk - I • Key variables (age, gender, occupation, marital status, income … ) • Variables unique to this file (not available for population) - collected by no one else - collection process not replicable (clinical samples, attitudes) • Addition of external data – “enrichment” 23 Assessing Disclosure Risk - II • Geographic detail – explicit and implicit • Proportion of study population included (all v. sample) • Amount of error in data - target and population (e.g. income) • Data sensitivity 24 Data Protection • Remove direct identifiers • Restrict geography • Code to remove detail – larger categories, top coding • Variable suppression (e.g. place of birth) • “Unusual” case suppression (small frequency) • Special handling of data from external sources (esp. area data) • Statistical modification (“noise”) 25 DRB Deliberation • Discussion/Questions re issues raised by data collection program or DRB. • Most resolved at initial meeting • Some require follow up to determine • - frequencies of cases in sample v. general population. • - effect on key statistics of data protection methods employed. 26 Decision •Release/Do not release - decision covers ongoing surveys for three years when there is no change in content or frequencies. After that, new review. •Data use agreements* •Research Data Center * Consent permitting 27 References/Resources I When Data Sharing is Required: I. What is this Requirement? II. HIPAA and Disclosure risk Issues III. Meeting the Challenge. de Wolf V, Sieber JE, Steel P and Zarate AO. IRB: Ethics & Human Research. 27/6 28/1 and 28/2. 2005-2006. 28 References/Resources II • American Statistical Association, Privacy, Confidentiality and Data Security web site http://www.amstat.org/comm/cmtepc/inde x.cfm?fuseaction=main • Disclosure Potential Checklist http://www.fcsm.gov/committees/cdac/ind ex.html 29 Data release problems and resolution -1 Data System Problem/Resolution -NSFG (contextual) Area detail – RDC -NEHIS Establishment/linkage with external files – RDC -NHANES Heavy publicity – PSU modification, 2 yrs file, recodes 30 Data release problems and resolution -2 Data System Problem/Resolution -NHANES (kids) Clinical report/RDC -NSFG (kids) Parents knowledge /statistical “noise” -NHIS size of SMSA Research evidence of disclosure risk/restrict release to 500,000+ 31 Data release problems and resolution -3 Data System Problem/Resolution -NHIS data detail Recoding of occupation disease condition, income, race -Survey sample detail Recombination of info. -Surveys linked with Linkage with external mortality data files/RDC -Vital Statistics Geographic detail – in process 32 The “Culture” of Confidentiality • Individual employee as the most important element • Awareness of responsibility as an ethical as well as legal imperative • Continuous awareness • Seen as protective of study participants and responsive to the research community 33 Issues and Challenges • Synthetic Data Sets • Offsite Designated Agents • Web data dissemination • Data Stewardship/Data centralization • Assessment of security breaches 34 Privacy – Three Definitions • Privacy/Secrecy Basic. Required by law/ethics • Privacy of Shared Data Authorization required (consent) Both parties responsible. Sanctions. Tight agreements. • Anonymization of Data Not easy but possible. More research needed. Restricted access 35 Consent and Federated Identity Topics • Consent • Where and when • How the interface looks today • Where it needs to go • Informed consent • Setting the bar • Engaging the SP’s • Educating the User kjk@internet2.edu Jurisdictional Issues at the Start • At least three policy spaces at play • IdP location • SP location • User’s national and local laws • Known exploits exist today… kjk@internet2.edu Consent • At the point of collection of information • “We intend to use what you give us in the following ways” • At the point of release of information • “I authorize the release of this data in order to get my rubber squeeze toy…” kjk@internet2.edu User interface • Provide users with control, and guidance, over the release of attributes • Includes consent, privacy management, etc. • Basic controls (uApprove) now built into Shibboleth, but largely untapped in deployments. • Additional technical developments would help scalability • Human interface issues largely not yet understood – getting the defaults right, putting the informed into informed consent, etc. kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu kjk@internet2.edu Informed Consent kjk@internet2.edu kjk@internet2.edu Next Steps • Normalize the “presentation of the attributes” language • Field test – get the defaults right • Sift through what really needs consent • Need to complete the business transaction • Europe model more sophisticated but is compounded by national issues • Federations as vehicle for national consent management • ePTID – opaque, non-correlating. Does it need consent? • Cookie consent? • Attribute bundles kjk@internet2.edu New Results using Anonymous Credentials: Constrained Delegation and Revocation Brian A. LaMacchia Director, XCG Security & Cryptography, Microsoft Research Agenda Basics of anonymous credentials Using anonymous credentials in security policy languages Anonymous credential delegation Anonymous principals for the SecPAL language Making anonymous credentials revocable Problem definition Accumulators Using accumulators as privacy-preserving CRLs Revocable delegable anonymous credentials April 6, 2011 IDTrust 2011 2 Anonymous Credentials An anonymous credential allows a principal to prove possession of one or more attributes without revealing the principal’s identity or other additional information. Examples of attributes: “is a US citizen”, “age > 18“, “is an employee of Fabrikam” Unlinkability is a key requirement Should not be able to link multiple uses of a credential One technique: Non-Interactive Zero-Knowledge (NIZK) proofs Prove you have a dig sig from an issuer of the desired attribute Re-randomize the proof to hide identity & provide unlinkability Uses Groth-Sahai proofs (Belenkiy et al., Crypto ‘09) April 6, 2011 IDTrust 2011 3 Anonymous Credential Delegation Keys for anonymous credentials have two forms Private: held by bearer Public: a commitment to the key (can re-randomize) Credential chains: � (����� ) signs Signed key: NIZK proof of signature Attributes: signs Signed key: NIZK proof of signature Attributes: April 6, 2011 IDTrust 2011 4 SecPAL: Security Policy Assertion Language A security policy language for decentralized authorization Supports constrained delegation Logical framework for reasoning about authorization Principals are defined by keys E.g., public key of RSA key pair Principals sign statements (signed credentials) Issuer says Subject can Verb Object Some simple examples: Azure STS says Hospital possess accountName: “hospital” Hospital says Pharmaco can read, write file://localhost/hospital/drugtrialdocuments/ Storage Tenant says Hospital can read, write file://localhost/hospital/ if Hospital possess accountName: “hospital” April 6, 2011 IDTrust 2011 5 Anonymous Principals for SecPAL A principal that proves its ID with an anonymous credential Simple version like a group of principals  E.g., Any US citizen can enter the country But can also merge with delegation  E.g., OS says <1> can say %x can write to /var <1> says <2> can write to /var Notation “”: principal of credential at delegation level i Delegation levels of credentials map to policy Public attributes in credentials are SecPAL statements April 6, 2011 IDTrust 2011 6 Efficiency and Ephemeral Keys Anonymous signatures slower than public key Solution: bootstrap into public key using ephemeral keys E.g., OS says <1> can write /var <1> says RSAKey can act as <1> Now RSAKey can write to /var STS converts to limited, normal token for RSAKey Principal can create new RSA key Individual keys are unlinkable April 6, 2011 IDTrust 2011 7 Revocation for Anonymous Credentials The ability to revoke is an integral part of all systems built on digital signatures (e.g. PKI certificates) We want this capability for anonymous credentials also But how do we revoke an anonymous credential without identifying it explicitly? If we identify it (e.g. list an ID number) then users would also have to reveal that same information to allow relying parties to perform revocation checks  linkability We need a mechanism that allows an RP to see if a credential is revoked without requiring the reveal of a unique ID Answer: Use an accumulator April 6, 2011 IDTrust 2011 8 Accumulators  An accumulator is a mathematical object that aggregates a set of elements into a single value .  represents the set without revealing the individual elements in the set Accumulators allow both membership and non-membership proofs. Membership Proof: Prove that an element is accumulated in , without revealing . Non-Membership Proof: Prove that an element is NOT accumulated in , without revealing . If the contents of the set accumulated in changes, and all the associated proofs can be updated efficiently. April 6, 2011 IDTrust 2011 9 Accumulators for Blacklisting with Privacy  Main idea: Build a privacy-preserving blacklist of revoked credentials using an accumulator.  Like a CRL  Build an accumulated value containing all of the revoked credentials.  When a credential is presented to the RP, the RP can use a non-membership proof to check that the presented credential is not in . ⇒ If the proof succeeds, then the element is not revoked  Checking a non-membership proof does not reveal the element ⇒ Privacy protection  Challenge for authorization delegation:  Can a non-membership proof be delegated without revealing the element?  Even when the set of accumulated elements changes? April 6, 2011 IDTrust 2011 10 Accumulators with Delegable Non-Membership Proofs (ADNMP)  ADNMP satisfy the following properties: Delegatability: ’s owner can delegate the ability to prove that is not accumulated Even when the accumulated set changes, and Without revealing (reveal a delegating key instead) Unlinkability: The delegating keys of different elements are indistinguishable. Re-delegatability: A delegate can re-delegate the proving ability further to other users. Validity: Correctness of delegating keys are verifiable. April 6, 2011 IDTrust 2011 11 Delegatable Anonymous Credentials NymO Nym1 Nym2 Nym1.1 Nym1.2 Nym2.1 • In a DAC system, pseudonyms form a tree – each link between nodes is a delegation. • Nym1.1,Nym1.2 and Nym2.1 can each anonymously prove that she has a credential, which is delegated 2 levels away from Nym O. April 6, 2011 IDTrust 2011 12 Revocable Delegatable Anonymous Credentials (RDAC) NymO Blacklist Authority Nym1 Nym2 Nym1 Nym1.1 Nym1.2 Nym2.1 • Nym1 is revoked. • Nym1.2 can no longer prove that she has the credential • Her only path to the root is gone. • Nym2.1 can still prove anonymously that • She has a credential, which is delegated 2 levels away from NymO. • All of her ancestors (NymO, Nym2) are not blacklisted. April 6, 2011 IDTrust 2011 13 Summary Anonymous credential delegation can be used to enable anonymous principals in an authorization language We can still have constrained delegation even when anonymous Accumulators can be used to build a privacy-preserving revocation mechanism for anonymous credentials For more information: Tolga Acar and Lan Nguyen, “Revocation for Delegatable Anonymous Credentials,” no. MSR-TR-2010-170, 22 December 2010 SecPAL: http://research.microsoft.com/projects/SecPAL/ April 6, 2011 IDTrust 2011 14 Questions? April 6, 2011 IDTrust 2011 15 National Strategy for Trusted Identities in Cyberspace Jeremy Grant NIST April 6, 2011 National Strategy for Trusted Identities in Cyberspace 1 What is NSTIC? Called for in President’s Cyberspace Policy Review (May 2009): a “cybersecurity focused identity management vision and strategy” Guiding Principles • Privacy-Enhancing and Voluntary • Secure and Resilient • Interoperable • Cost-Effective and Easy To Use NSTIC calls for an Identity Ecosystem, “an online environment where individuals and organizations will be able to trust each other because they follow agreed upon standards to obtain and authenticate their digital identities.” National Strategy for Trusted Identities in Cyberspace 2 The Problem Today Usernames and passwords are broken • Most people have 25 different passwords, or use the same one over and over • Even strong passwords are vulnerable…criminals can get the “keys to the kingdom” • Rising costs of identity thef – 123% increase in financial institution Suspicious Activity Reports in last 6 years (FINCEN) – 11.7 million est. victims over 2 years (BJS, 2008) – $17.3 billion est. cost to economy over 2 years (BJS, 2008) • Cybercrime is also on the rise – Incidents up 22% from 2009 to 2008 (IC3 report) – Total loss from these incidents up 111%, to $560 million. National Strategy for Trusted Identities in Cyberspace 3 The Problem Today Identities are difficult to verify over the internet • Numerous government services still must be conducted in person or by mail, leading to continual rising costs for state, local and federal governments • Electronic health records could save billions, but can’t move “No one knows you’re a dog” forward without solving authentication challenge for providers and individuals • Many transactions, such as signing an auto loan or a mortgage, are still considered too risky to conduct online due to liability risks National Strategy for Trusted Identities in Cyberspace 4 The Problem Today Privacy remains a challenge • Individuals ofen must provide more personally identifiable information (PII) than necessary for a particular transaction – This data is ofen stored, creating “honey pots” of information for cybercriminals to pursue • Individuals have few practical means to control use of their information National Strategy for Trusted Identities in Cyberspace 5 Trusted Identities provide a foundation • Enable new types of transactions online Econ • Reduce costs for sensitive transactions omic bene fits •Offer citizens more control over when and Improved privacy how data is revealed •Share minimal amount of information standards •Fight cybercrime and identity thef Enhanced security •Increased consumer confidence TRUSTED IDENTITIES National Strategy for Trusted Identities in Cyberspace 6 Interopera January 1, 2016 The Identity Ecosystem: Individuals can choose among multiple identity providers and digital credentials for convenient, secure, and privacy-enhancing transactions anywhere, anytime. Sign mortgage Alternative Secure with digital payment signature mechanisms; convenient transactions Trustworthy ti se critical service ffe to u ve delivery t- sy c Co d ea e Single Sign-On to her an s corporate portal Security ‘built-into’ the system to Privately post location nhancing reduce user error to her friends National Strategy for Trusted Identities in Cyberspace 7 8 National Strategy for Trusted Identities in Cyberspace But Barriers Exist DoD Led the Way • High assurance credentials come with • DoD network intrusions fell 46% afer it higher costs and burdens banned passwords for log-on and instead • They’ve been impractical for many mandated use of the CAC with PKI. organizations, and most single-use applications. • Metcalfe’s Law applies – but there are barriers (standards, liability, usability) today that the market has struggled to overcome. We've proven that Trusted Identities matter What does NSTIC call for? Private sector • Not a government-run identity program • Industry is in the best position to drive will lead the technologies and solutions • Can identify what barriers need to be effort overcome • Help develop a private-sector led Federal governance model • Facilitate and lead development of government interoperable standards • Provide clarity on national policy and legal framework around liability and will provide privacy • Act as an early adopter to stimulate support demand National Strategy for Trusted Identities in Cyberspace 9 Privacy and Civil Liberties are Fundamental Increase privacy • Minimize sharing of unnecessary information • Minimum standards for organizations - such as adherence to Fair Information Practice Principles (FIPPs) Voluntary and private-sector led • Individuals can choose not to participate • Individuals who participate can choose from public or private-sector identity providers • No central database is created Preserves anonymity • Digital anonymity and pseudonymity supports free speech and freedom of association National Strategy for Trusted Identities in Cyberspace 10 Other countries are moving forward NSTIC is unique in that it is led by the private sector. Europe North America Norway and Sweden (Bank ID); Canada (issued Austria, Belgium, Estonia, Italy and Asia strategy) Germany (general ID); France (health) Taiwan (health); Hong Kong Middle East (transit, financial payments); Afghanistan Singapore (gov’t services); (strategy); Oman Malaysia (general ID, (pending e-payment) e-payment); India (general ID) Africa Latin America Rwanda (general ID) Brazil (banking) National Strategy for Trusted Identities in Cyberspace 11 Industry and Privacy Support Key members of the U.S. technology industry, the privacy community, and the security industry have expressed support for NSTIC “NSTIC has the opportunity to tip the balance of the conversation and focus on identity to socio- economic benefit from what is ofen today one of identity fraud and identity thef. In doing so trusted identities can improve the delivery and lower the cost to the public of financial services, health care, e-commerce and reduce the federal budget.” Salvatore D'Agostino, CEO, Idmachines LLC “Our industry strongly supports the goals “The Administration to my outlined in the Strategy, and we see a vital view has, has conducted a role for a National Program office to work very open process here….I with industry and government in its think that there's a model finalization and implementation.” here perhaps for the Letter to Sec. Locke, White House Cybersecurity broader question of Coordinator Howard Locke, and Patrick Gallagher from TechAmerica, Business Sofware Alliance, and cybersecurity.” Information Technology Industry Council; additional signatures included leadership from Microsof, Jim Dempsey, Vice President for Symantec, PayPal, CA, CSC, RSA/EMC, Infineon , Unisys, Public Policy at the Center for Verisign and Gemalto and other technology firms Democracy & Technology National Strategy for Trusted Identities in Cyberspace 12 The Time is Now Technology Organizations Market NSTIC and individuals is now want these exists, but vision is mature solutions nascent clear • Needs a nudge towards interoperability & standardization • Needs clarity on national policy/legal framework (e.g. liability and privacy) • Needs an early adopter to stimulate demand • Government can meet these needs to facilitate private sector National Strategy for Trusted Identities in Cyberspace 13 Next Steps Convene the Private Sector • Workshops on governance, privacy and technology FY11 Focus • Establish Governance model • Private sector led; multi-stakeholder collaboration • Enable expedited focus on consensus standards and operating rules • Explore models for addressing liability • Pilots: • Develop criteria for selection • Assess potential programs • Prepare for formal pilot launches with funding in FY12 Government as an early adopter to stimulate demand • Ensure government-wide alignment with the Federal Identity, Credential, and Access Management (FICAM) Roadmap • Increased adoption of Trust Framework Providers (TFP) National Strategy for Trusted Identities in Cyberspace 14 Questions? Jeremy Grant jgrant@nist.gov 202.482.3050 National Strategy for Trusted Identities in Cyberspace 15 IDTrust 2011: Privacy and Security Research Challenges for Biometric Authentication Moderator: Elaine Newton, PhD NIST elaine.newton@nist.gov A Generic Biometric System Image from: Newton, Elaine. Biometrics and Surveillance: Identification, De-Identification, and Strategies for Protection of Personal Data. PhD Dissertation, Carnegie Mellon University, Dept of Engineering and Public Policy, ProQuest UMI, May 2009. 2 Notional Histogram of Genuines (Blue) and Imposters (Red) Frequency False Non- False Matches Matches Similarity Scores 3 NIST Biometric Testing • Fingerprint – Ongoing Proprietary Fingerprint Test (PFTII) and MINEX (MINutiae EXchange) testing using various databases of 120K+ subjects – Software development kit (SDKs) –based testing • Face – Data from grand challenges and vendor tests – DOS Database of 37K subjects – Algorithm-based testing • Iris – Data from grand challenges and vendor tests – Algorithm-based testing 4 Authentication Use Case Comparison For law enforcement, immigration, For online transactions, e.g. etc. banking, health, etc. • Enrollment and • Enrollment subsequent recognition – Less controlled – Probably not in person attempts – highly controlled • Subsequent recognition attempts – Supervised / Attended – Unattended • Successful recognition • Successful recognition – Answers the question, – Answers the question, “How “Has this person been confident am I that this is the previously encountered?” actual claimant?” – Is a unique pattern – Is a tamper-proof rendering of a distinctive pattern Passwords v. Biometric Data • P: Known only to the end-user • B: Potentially known by anyone who can encounter the individual in-person or virtually • P: Can be (easily) changed if compromised and periodically renewed to mitigate risk – Can be lengthened to increase security • B: A pattern with some degree of robustness over time that can be used to distinguish individuals • P: Many possibilities for users to choose different credentials for different domains, which could be randomly generated or otherwise have no personally identifying information • B: A presentation of the same biometrics for any application, and many can be used for identification • P: Deterministic • B: Probabilistic Biometric Security Issues Figure by Nalini Ratha, IBM 8 Thank you And now for our panel: Ross Micheals, PhD Terry Boult, PhD Stephanie Schuckers, PhD Biometrics & eAuth Ross J. Micheals / NIST revocable biometric (n.) ri∙vō'∙cə∙bəl bi∙ō∙'me∙trik “I can get another credential.” How can biometrics become a viable option for remote multifactor authentication? Identity Management Biometrics Cryptography U. Uludag and A.K. Jain, “Attacks on biometric systems: a case study in fingerprints,” In Proc. SPIE, Security, Steganography and Watermarking of Multimedia Contents VI, volume 5306, pp. 622-633, 2004. Spoofing Sensor Resubmission or interception & alteration Feature Template Trojan substitution Extractor Synthetic features Matcher Database Resubmission or interception & alteration Resubmission or Decision interception & alteration Spoofing Sensor Resubmission or interception & alteration Feature Template Trojan substitution Extractor Synthetic features Matcher Database Resubmission or interception & alteration Resubmission or Decision interception & alteration Spoofing Sensor Resubmission or interception & alteration Feature Template Trojan substitution Extractor Synthetic features Matcher Database Resubmission or interception & alteration Resubmission or Decision interception & Quo vadis* revocability? alteration (Unnecessary use of Latin inspired by National Academies “Whither Biometrics” Project and related papers.) Spoofing Sensor Resubmission or interception & alteration Feature Template Trojan substitution Extractor Synthetic features Matcher Database Resubmission or interception & alteration Resubmission or Decision interception & alteration Terrance Boult University of Colorado at Colorado Springs Stephanie Schuckers Clarkson University What does it mean to be “multifactor?” Know Have Are Transparent Hardware Biometric Cryptographic Tokens ross.micheals@nist.gov Evaluation of Liveness or Anti-spoofing in Biometric Systems Presented by Stephanie Schuckers Contributors to the research; Bozhao Tan, Aaron Lewicke, Peter Johnson, Joseph Sherry, David Yambay, Rachel Wallace, Greta Collins, Dominic Grimberg, Laura Holsopple, Arun Ross, Emanuela Marasco Funding provided by National Institute of Standards and Technology (NIST), National Science Foundation (NSF), Dept. of Homeland Security (DHS), and the Center for Identification Technology Research (CITeR) © Schuckers 2010 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu The Center for Identification Technology Center Research Scope Research (CITeR) NSF Industry/University Cooperative Research Center (IUCRC) focused on Integrative Identification Research since 2001 - importance of individuals in a global society Research Scope – Physiological, Behavioral, and Molecular Biometrics. Current Emphasis: 2001: WVU Founding Site, MSU Partner, 5 Founding Affiliates - Automated Biometric Recognition 2006: University of Arizona becomes 2nd Site, 10+ Universities - Credibility, psychophysiological and behavioral deception detection 2010: Clarkson Plans 3rd Site, over 20 Affiliates - Logical and cyber identity, intelligence CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu CITeR’s Affiliates • Accenture • Laurea Ltd. • Booz Allen Hamilton • Lockheed Martin • Computer Science Corporation • National Institute of Standards and • DIA/DACA-Defense Academy for Technology (NIST)--pending Credibility Assessment • National Security Agency 2 • Department of Defense—Biometric organizations (1 Clarkson) Task Force • Northrop Grumman • Department of Defense—DDR&E • OU Center for Applied Social Research • Department of Defense— • Raytheon (2 organizations) USSOCOM/SOALT • Morpho Trac Inc. • Department of Homeland Security—S & • Sandia National Labs T 3 memberships (1 Clarkson) • SRC • BORDERS DHS COE • Science Applications International • Federal Aviation Administration, Corporation (SAIC) Information Systems Security (2 memberships) • US Army Picatinny Arsenal • Federal Bureau of Investigation • US Army CERDEC/SBInet Indep. Test • Team Irvine Sensors • West Virginia High Technology Consortium Foundation CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoofing • In 2009, publicized fingerprint spoof attack at Japanese border by a Korean woman • Highlighted vulnerability in fingerprint systems used for identity management • Number of successful spoofing events is unknown CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoofing • Spoofing: “The process of defeating a biometric system through the introduction of fake biometric samples. • Artificially created biometrics: – lifted latent fingerprints – artificial fingers – image of a face or iris – high quality voice recordings – worst case—dismembered fingers • Famous ‘gummy fingers’ by Matsumoto 2002 • Mythbusters episode in 2007 • Spoof attack in early 2009 at Japanese border by a Korean woman CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Biometric Spoofing in Popular Media Cameron Diaz, Charlies Angels Tom Cruise, Minority Report Mythbusters, 2007 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoofing Techniques in our Lab • Dental materials for casts • Cooperative, high quality casts • Mold made from cast, also termed ‘replica’, ‘spoof’, ‘fake finger’ • Materials for Mold: Play-Doh, gelatin, silicon rubber, paint, caulk, wood glue, paper, latex rubber, paper • Cadaver fingers CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoof Techniques in our Lab • Uncooperative • Lifted latent print, stolen fingerprint image • Fingerprint mask generation • Print on transparent film • Expose negative photosensitive silicon wafer • Develop to form cast • Pour silicone or other liquid material to form mold CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Example Photos of Spoof Fingers Caulk Paint Playdoh Silicon Photos of spoof fingers made from various materials CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Same scanner (optical) Different spoof materials Top row, left to right: latex painter’s caulk. gelatin, latex paint. Bottom Row: playdoh. latex rubber. silicon. CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoofing versus Obfuscation • Spoofing—posing as another individual – Positive identification applications • Obfuscation—hiding your identity – Negative identification applications – May form ‘new’ identity for positive identification – Mutilation of fingerprint – Texture-contact lens to hide iris pattern – Theatre makeup/putty to change facial characteristics CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Minimizing Spoofing Risk • Application-specific risk assessment – What is the role of biometrics in my application? (Is it needed?) – Does it improve upon former methods of identity management? – What is the impact of spoofing vulnerability? – What is the public perception of spoofing vulnerability? • Ways to mitigate risk – Multi-factor authentication—password, smart card – Multi-biometrics—require multiple biometrics – Liveness detection or anti-spoofing CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Liveness Detection • Also termed – ‘Vitality Detection’ – ‘Anti-Spoofing’ • Definition: to determine if the biometric being captured is an actual measurement from the authorized, live person who is present at the time of capture • “It is ‘liveness’, not secrecy, that counts,” Dorothy Denning – Your fingerprint is NOT secret. – Cannot reasonably expect it to be absolutely secret – Therefore, must ensure measurement is of the ‘real’ biometric and not a replica. – True for most other biometrics, with some exceptions to be discussed • Typically treated as a two class problem—live or spoof CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Liveness Detection • Rarely does biometric sensor measure ‘liveness’, that is, liveness is not necessary to measure the biometric • Hardware-based • M2SYS-M2-S1 – Requires specialized hardware design – Integrated with biometric sensor • Software-based – Uses information already measured from biometric sensor – Additional processing needed to make a decision • Liveness inherent to biometric – Must be ‘live’ to measure it, e.g., electrocardiogram CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Hardware-based Fingerprint Liveness Detection • Hardware-based – Temperature – Pulse – Blood pressure – Odor • The Lumidigm J110 – Electrocardiogram Anti-Spoof scanner – Multispectral imaging, spectroscopy • MultiSpectral imaging • Should be integrated carefully so with varying spoof cannot be combined with any illumination and live finger to be accepted polarization – e.g. translucent spoof fooling light- absorption-based pulse oximeter CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Example Hardware: Multispectral • MultiSpectral imaging with varying illumination and polarization • Commercial system which The Lumidigm J110 protects from spoofing Anti-Spoof scanner • Hardware approach • Tradeoff—larger and more expensive Rowe et al. Advances in Biometrics, 2008, CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Software-based Fingerprint Liveness Detection • Examples proposed – Skin deformation – Elasticity – Pores – Perspiration pattern – Power spectrum – Noise residues in valleys – Combining multiple features • Must represent variability of live subjects (dry, moist, variable environments, ages, ethnicity) • Reliance on the properties of spoof materials • Must stay one step ahead of would-be attacker—software upgrade CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Example Software: Ridge/Valley Features Ridge Signal • Relies on differences in ridge/valley structure between live and spoofs • Uses features measured from ridges and valleys separately • Sensitive to the sensor being used • Impacted by Valley Signal environmental conditions • Must represent large diversity in both spoof and live images Tan, et al, CVPR, 2006 Ulchida, et al, LN in CS, 2004 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Assessment of Spoofing Vulnerability and Countermeasures Evaluation: How often will a spoof be accepted System by the system vulnerability to spoof attack Terminology: Percent acceptance of spoof fingers Countermeasures Evaluation: Restricted to scope of anti-spoofing module (Anti-spoofing methods) Terminology: (spoof) false accepts, must be traded off with (live) false rejects System level Evaluation: Combining matching and anti- performance spoofing performance measures for complete assessment system assessment CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Spoof Testing on Conventional Systems • Matsumoto et al., 2002 – Method: (1) enroll live, test live; (2) enroll live, test spoof; (3) enroll spoof, test live; (4) enroll spoof, test spoof (all genuine matches) – Data: Live, silicone, and gelatin fingers – Evaluation: Percent accepted in terms of matching performance • Galbally et al., 2006 – Method: (1) enroll and test with live Mold Cast fingers; (2) enroll and test with spoof; (3) enroll live, test spoof – Data: Live and silicone fingers – Evaluation: FAR and FRR in terms of matching performance CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Testing of Liveness Algorithm Module Algorithm No. Spoofs No. Live No. No. Live Spoof impression frames Performance Performance s Perspiration 18 18 1 2 88.89% 88.89% with Fourier space Surface 10 gelatin 23 1 1 100% 100% coarseness 24 plastic clay Distortion 40 (10 45 (2 10 20 88.76% 88.76% Analysis silicone, 10 fingers) gelatin, 10 latex, 10 wood glue) Perspiration 80 58 1 1 80% - 100% 80% - 100% with wavelet space CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu State of Liveness Performance Evaluation • Performance metrics for biometric systems – adapted unmodified for anti-spoofing assessment – Classification rate (percent correctly classified) – FAR/FMR – false accept rate/false match rate – FRR/FNMR – false reject rate/false non match rate – TAR/GAR – true accept rate/genuine accept rate – EER – equal error rate – ROC – receiver operating characteristic – DET – detection error trade-off • Need to distinguish “false accepts” in matching from “false accepts” in spoofing – Need common set of vocabulary CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Performance Vocabulary • Biometric performance terminology – False reject rate—Error associated with rejecting an ‘genuine’ user – False accept rate—Error associated with accepting an un- authorized, ‘imposter’ user • Zero-effort attempt—no willful attempt • Anti-spoofing terminology – False reject rate—similar to above, now anti-spoofing detection algorithm may reject ‘genuine’ authorized user – Spoof false accept rate—error associated with accepting the presentation of a spoof • Non-zero effort attempt—willful attempt CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu State of Liveness Performance Evaluation • Need for performance metrics to assess liveness and systems which incorporate liveness • Need to distinguishing false accepts in matching from spoof false accepts • Must be clear on anti-spoofing impact on false reject rates • Fusion of match scores and “liveness” scores Next issue • Testing procedures—it depends on how you perform spoofing CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Liveness Detection Competition—LivDet 2009 • First liveness detection competition at ICIAP 2009 with a public liveness database • Collaboration with Univ. of Cagliari • Focusing on software-based fingerprint liveness • Scanners used: CrossMatch, Identix, Biometrika • 2000 live and spoof samples for each scanner • Four participants rate of misclassified fake fingerprints rate of misclassified live fingeprints CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu 25 Announcing LivDet II • To compare different methodologies for software-based and system-based fingerprint liveness detection – Algorithm—training set provided, sequestered test set – System—hardware/software system submitted and tested • To become a reference event for academic and industrial research in software-based and system-based fingerprint liveness detection • To raise the visibility of this important research area in order to decrease risk of fingerprint systems to spoof attacks • Results to be presented as part of International Joint Conference on Biometrics (IJCB) 2011 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu 26 Factors impacting performance testing • Material for spoof • Material for mold • Variability in recipes • Individual variability • “Spoofer” variability • Number of attempts • Placement, pressure, etc. • Cooperative or non-cooperative collection of fingerprint pattern • Known versus unknown attacks CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Others developing methods for performance assessment of liveness • Communications-Electronics Security Group (CESG) – Branch of Government Communications Headquarters (GCHQ) – UK – Developing a methodology for biometric security testing • Federal Office for Information Security (BSI) – Germany – Common Criteria Certification – Protection Profiles for anti-spoofing evaluation • Korea Information Security Agency – Methodology designed to evaluate the objective performance of spoof detection technology • Developing ISO Standards CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Liveness Methods Impact on Standard Biometric Characteristics • Ease of Use – Dynamic, time delay – User assisted • Collectability – User assisted • User acceptance – Measurement which requires medical information may not be acceptable to individuals • Universality – Perspiration differences may not be measurable in some individuals – Some individuals require lotion for fingerprint • Permanence – Environmental impact CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Conclusions • Spoof FAR needs to be considered for non-zero effort false accept • FAR accounts only for zero effort false accept rate • Real spoof attempts are ‘rare’ events, likely much smaller than error with detection • Can be used as a flag to ‘secondary’ • Testing • Common terminology • Agreed upon framework for testing • Standards for levels of assurance • System level versus module level testing • Liveness detection or anti-spoofing will impact overall performance of biometric system CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Thank you! Questions? CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu References • C. Jin, H. Kim, S. Elliot, “Liveness Detection of Fingerprint Based on Band-Selective Fourier Spectrum,” Lecture Notes in Computer Sciences, vol. 4817, pp. 168-179, 2007. • K. Uchida, “Image-Based Approach to Fingerprint Acceptability Assessment,” Lecture Notes in Computer Sciences, pp. 294-300, 2004. • A. Antonelli, R. Cappelli, D. Maio, D. Maltoni, “Fake Finger Detection by Skin Distortion Analysis,” IEEE Transactions on Information Forensics and Security, vol. 1, no. 2, pp. 360-373, September 2006. • J. Jia, L. Cai, “Fake Finger Detection Based on Time-Series Fingerprint Image Analysis,” Lecture Notes in Computer Sciences, vol. 4681, pp. 1140-1150, 2007. • Parthasaradhi S, Derakhshani R, Hornak L, Schuckers SAC, Time-Series Detection of Perspiration as a Liveness Test in Fingerprint Devices, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, vol. 35, pp. 335- 343, 2005. • B Tan, S Schuckers, Liveness Detection for Fingerprint Scanners Based on the Statistics of Wavelet Signal Processing, Computer Vision and Pattern Recognition Workshop, 2006 Conference on, Page(s):26 – 26, 17-22 June 2006. • Baldisserra, Denis, Annalisa Franco, Dario Maio, and Davide Maltoni. “Fake Fingerprint Detection by Odor Analysis ,.” In Advances in Biometrics, 265-272, 2005. © Schuckers 2010 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu References--continued • C. Jin, H. Kim, S. Elliot, “Liveness Detection of Fingerprint Based on Band-Selective Fourier Spectrum,” Lecture Notes in Computer Sciences, vol. 4817, pp. 168-179, 2007. • Miura, Naoto. “Feature Extraction of Finger Vein Patterns Based on Iterative Line Tracking and Its Application to Personal Identification.” 29 June 2009. • Wubbeler, Gerd. “Verification of Humans using the Electrocardiogram.” 26 June 2009. • Rowe, Robert K., Paul W. Butler, and Kristin A. Nixon. "Multispectral Fingerprint Image Acquisition." Advances in Biometrics, 2008. • Andy Adler, Stephanie Schuckers, Security and Liveness: Overview, in Encyclopedia of Biometrics, editor: Stan Li, Springer Reference, 2009. • Stephanie Schuckers, Liveness: Fingerprint, in Encyclopedia of Biometrics, editor: Stan Li, Springer Reference, 2009 . © Schuckers 2010 CITeR The Center for Identification Technology Research An NSF I/UCR Center advancing integrative biometrics research www.citer.wvu.edu Addressing Privacy and Security Research Challenges for Biometric Authentication via the BKI: Biocrytographic Key Infrastructure Terrance E. Boult El Pomar Professor of Innovation and Security University of Colorado at Colorado Springs and CEO/CTO Securics Inc 71 719 963 0573 (Cell) Remember the 80s and 90s?  Huge explosion in new Internet protocols  Email, Remote Connections, The Web,…  Security of these protocols was an afterthought!  We need cryptography to protect insecure channels  How can Alice verify a server?  How do we share encryption keys? Solution: Public Key Infrastructure 2 2 Online Identity Problems…  Public Key Infrastructure enabled early e-commerce through secure communication  But Identity and transactions are between people, not machines. How do we “certify” parties in a transaction? ID/Passwords?  Certificates help machines, few people.  How many people even know what is a valid certificate?  Malware/Bot attacks directly capture passwords from machine and browser, sidestepping PKI certificates PKI resolve Identity by what you have 3 What makes an ID trusted? 1. Good protocols for ID management. 2. Strong (levels of) assurance that only intended users can use that ID. (Verifier) 3. Strong link between claimed identity and other attributes (bank account, age, schooling, etc..) (Registration authority) 4. Validity of registration authority/delegate 5. Must have liability for failures in #1-3 4 Identity Limitations of PKI  Ellison and Schneier (2000)*  “Risk #1: Who do we trust, and for what?”  “Risk #2: Who is using my key?”  “Risk #4: Which John Robinson is he?”  “Risk #6: Is the user part of the security design?”  “Risk #8: How did the CA identify the certificate holder”? *C. Ellison and B. Schneier, “Ten Risks of PKI: What You’re Not Being Told About Public Key Infrastructure,” Computer Security Journal, 16(1):1-7, 2000. 5 5 “Three factor” of Authentication security 1. Something you know (passwords,attributes) Easily changed, easily shared, moderate/easy forgotten/lost 2. Something you have (e.g. card, cert) Moderate to change, moderate to share easily forgotten/lost 3. Something you “are” (e.g. biometric) Hard to share, hard to forget/lost, Traditionally impossible to change! 6 6 6 Traditional Biometric “Security” Most vendors Standard claim ARE Templates privacy/security is effectively invertible! protected since they store only templates which Vendor cannotclaims of be inverted. security because templates are are “non- Recovering images from ISO invertible” is like saying minutiae templates allowed a noisy ROT13 is successful attacks against encryption: nine different systems formally true, practically • 81% highest security meaningless. • 90% normal security Cappelli et al. PAMI, Sept. 2007 Wong/Jain ICB09 improved to > 95% . http://biolab.csr.unibo.it 8 8 Biometrics for Verified Web-Identity? ?? Biometrics provide identity assurance, convenient & low cost but  Cannot revoke a fingerprint like a password or credit card!  Like symmetric encryption both sides need the “secret”  Only matching party can really trust match happened, other party must trust the matcher with their data! The TRUSTED identity on the web needs a radically different and asymmetric identity approach. 9 Biometrics and Security  Traditional biometrics must be decrypted to match  Even if not a “secret”, it still must be protected  Cannot change/revoke traditional biometrics.  Strong personal identity, and only strong solution to detect attempts to have multiple identities. Biometrics and Privacy  Concerns of Function creep  Cross DB linking/Surveillance.  Improper impact of innocents from false-matches  Some issues addressed by revocable/cancellable biometrics, fuzzy extractors & other template protection technology 10 10 National Workright Institute Guidelines for IMS 11 11 What you are: online requirements TB’s Requirements for effective biometric-based identity for web: 1) Asymmetric with strong 2-party confirmed non-repudiation 2) Revocable with different token on each transaction! 3) Support for multi-factor “verification only” tokens (no search) 4) Protocols that never send biometric data or tokens from client machine (Enrollment is special case) 5) Strong “verification” of individual issuing credentials 6) Application or even transaction specific accuracy support 7) Should support but not need “central” identity management. 8) Should support various levels of “Spoof” Detection 9) Should support option of secure sensor communication 10) Low-cost or a range of costs 12 Case Study: Revocable Biotokens  Boult et al. 2007*  Assume a biometric produces values v Each is transformed via scaling and translation “ v′ = (v – t) ∗ s  Split v′ into stable component q and residual component r  For user j, leave the residual obscured: r (v′) j  Encrypt q with public key or hash P : w (v′, P) j,1 *T. Boult, W. Scheirer and R. Woodworth, “Revocable Fingerprint Biotokens: Accuracy and Security Analysis,” CVPR 2007. 13 13 The Biotope Biotoken Multi-factors are mixed  Base Biotope mixes biometric data, Company ID/Key , User Public Key.  Uniquely addresses issues of protecting noisy biometric data  Can re-transform with transaction ID and embedded new keys for each traction.  Can have a multiple non- searchable BKI databases 14 Biotope Visualization • Each column is different keys. • Note the differences across keys for same image! • Keys more similar than “people”! • Revoke by changing any key 15 15 Nesting Property  wj is re-encoded using a transformation function T 1st encoding: wj,1(v′, P) 2nd encoding: wj,2(wj,1, T2) nth encoding: wj,n(wj,n-1, Tn)  The nesting process can be formally invertible via the keys, but cryptographically secure  Revocable + nesting = Asymmetric ID 16 16 Bipartite Biotokens  Scheirer and Boult 2009*  Let B be a revocable biotoken. A bipartite biotoken Bp is a transformation bbj,k of user j’s kth instance of B. Any bipartite biotoken Bp,k can match any revocable biotoken Bk for the same user that uses the same transformations.  bbj,k must allow the embedding of some data d into Bp  bbj,k(wj,k, Tk, d)  If Bp,k and Bk match, d is released * W. Scheirer and T. Boult, “Bipartite Biotokens: Definition, Implementation, and Analysis,” ICB 2009. 17 17 Bipartite Biotope® Process Base Biotope token Auth Request Generate local Transaction ID Biotope token Mix Base with TID to embed a nonce key forming bipartite Bipartite biotope token Biotope token Match Authorization and ID + Nonce extract nonce Validate Nonce Server-Side Biotope® Generation Remote Biotope® Matching  Solves “asymmetry” of matching, Man in the Middle, Phishing and remote device hacks on “match” yes/no. Can be use “offline” with sync or to store encryption keys. 18 18 Flat BKI verification with Central Challenges Enroll Create and Store a revocable Derive transaction token Biometric identity BKI token CB with Embed Nonce Enroll Return Nonce as Biometric Matching proof of Transaction in Secure Encoded match Biometric Space Authenticate Match and decode Device Generates a revocable Retransform with identity token TranID (may include password + EIN) 19 19 BKI: Biotope Key Infrastructure Biotoken® rootID Can be used to search and  Add Biotope fields & dates in for duplicate enrollments X509 v3 Cert extension fields.  BCA proofs ID, issues and signs Root Signed user’s “root” certificate Biotoken®  BCA derives operational certificate Master IDs One per application and return it or publishes in a private or public directory.  Alice can locate Bob’s cert, Tiered-BCA signed derives new transaction certificate Operational Biotope® IDs with embed key. She signs cert which can have date-driven and sends to Bob. expiration.  Bob can validate the message, use biometrics to extract key use Single use Bipartite Biotope® tokens with or sign it to validate transaction optional embedded data and identities. * W. Scheirer, W. Bishop and T. Boult "Beyond PKI: The Biocyptographic Key Infrastructure," IEEE WIFS 2010 Wksp on Information Forensics and Security 20 20 A BKI Tree “example” Root BCA, authorizes all BCAs below BCAR (And issues BKI certs for its employees) A employee at BCAR issues and signs BCAD’s certificate(s) A employee at BCAD issues BCAD and signs, BCAB’s certificate BCAC BCAB Certificate signed by BCAA Bob BCAA Bob’s certificate, including his public key and biotoken, Alice is certified Alice’s certificate, including her public key and biotoken, is certified 21 21 One-Way Protocol • Sender creates bipartite biotoken using Receiver’s public certificate • Establishes identity & trust of message Receiver • Provides secure one-way data channel 22 22 Two-Way Protocol • Provides Sender assurance that the Receiver is not an impostor • Strongly Validates one identity in the transaction 23 23 Three-Way Protocol • Provides Receiver assurance that the Sender is not an impostor • Strongly Validates both identities in the transaction 24 24 Certificate Revocation/Reissue  We must consider certificate and biometric re-issue  Scenario 1: Manual re-issue  Certificate owner generates a new public-private key pair and a new biotoken  Scenario 2: Automatic re-issue of biotoken  BCA retains transformation keys, reverts public biotoken to a lower level, issues new transformation keys and public biotoken  Scenario 3: Automatic re-issue of key-pair  BCA issues new key-pair, transmits secret key to owner via bipartite biotoken 25 25 New Applications/Protocols  Financial Payments/PayPal  Key-Exchange  Bio-Kerberos  Bio-S/Key  BKI-enabled LDAP  Biometric Digital Signatures The BKI bring identity to crypto protocols! 26 26 Other Examples of BKI Enabled Services  Financial Transactions  Age Verification  Remote-web access  Secure Documents  Strong anonymous identity  Healthcare IT  Anonymous E-Voting  Multi-use ID Cards  Multi-factor Signatures  Key-management  Data-at-Rest Solutions 27 27 Privacy and De-Duplication • Many ID proofing process require one ID per person (for security or anti-fraud) • De-duplication requires recognition → Invades Privacy !! → New types of security risks !! Is there a way to support de-duplication and yet ensure that the ID system data may not be abused. In particular can we make it impossible to search with latents or use data to plant (or generate) a fakeprint? 28 28 id-privacy example (2,0)-id-privacy P(R) = chance (2,0)-id-privacy P(R) >> chance 29 29 id-privacy A recognition representation is said to have id-privacy when using less than i items for the search input, the stored data cannot identify subjects with probability d greater than random chance, yet when i or more distinct items are present, the subject can be recognized at substantially above chance. – This is statement about representation i.e. d = 0, no algorithm can do recognition with less than i inputs. – For d > 0, algorithms/experiments can provide approximate estimate/bound on d. –Broader and more precise definition than k-anonymity –Defines a new class of problems/representations 30 30 An algorithm for fingerprint id-privacy  Use only intra-finger features. Forest algorithm directly applies, just limit choice of data in pairs.  Can also allow some local feature pairing, resulting in d>0 but improved accuracy. 31 31 BE-Verified? Optional Check BKI Signature BE-Verify Code Released id-privacy Rep Multi-Finger Multi-finger Crypto-Keys Bipartite Biotope Decoding Biotope SSN# BKI Signed PersonalPin? Crypto-Keys SSN# BE-Verify Code PersonalPin? Embedded 32 32 Summary The revocable BKI technology is to biometrics what PKI/RSA was to encryption – a disruptive innovation based on asymmetric protection of information 33 33 Successful Implementation of Identity Management Systems Integration ID Trust 2011: “Near the Horizon, Just Over the Horizon” Vijay Takanti Vice President Security & Collaboration Services Exostar April 6, 2011 Identity Hub Partner 2 Company A DoD DoD Partner 1 Company B Typical Federation: Federation through Exostar: X user account provisioning systems Single interface to an identity hub X life cycle management systems multiple protocols (SAML, WSFED, etc) 2 The Exostar Identity Hub “In Action” P2P Application ForumPass Applicat Supplier Portal ForumPass Application OneAero Supply Chain Platform (SCP) Rolls-Royce Marine (SCP) Boeing (SCP) SAML 2.0 WS-Fed WS-Fed WS-Fed CD-SSO Identity Hub SAML 2.0 SAML 2.0 WS-Fed WS-Fed SAML 2.0 Identty Provider Identty Provider Identty Provider Identty Provider Credental Identty Service Provider Provider Copyright 2010 Exostar LLC. All Rights Reserved. Proprietary and Confidential 3 Thank You Copyright 2010 Exostar LLC. All Rights Reserved. Proprietary and Confidential 4 Overview Overview of of the the SAFE-BioPharma SAFE-BioPharma Digital Digital Identity Identity and and Signature Signature Standard Standard 10th Annual Symposium on Identity and Trust on the Internet April 6th, 2011 NIST SAFE-BioPharma Association Moving BioPharma and Its Partners into the Digital Age: SAFE-BioPharma I December 2003, industry IT professionals from Top Ten Pharma companies saw the need for identity management and digital signatures as fundamental to move pharma processes into the electronic realm – Revolutionary changes underway in medical research and in healthcare – Cost and complexity has created crisis in R&D productivity – Need for rapid, close collaboration between pharma, healthcare providers, research institutions, government and global partners – FDA and EMA moving to fully electronic submission, review and response Series of Working Groups established the SAFE-BioPharma standard – Standard – PKI based, liability, contracts, regulatory participation – Medium Assurance/Hardware – smartcard SAFE-BioPharma II Member-governed non-profit collaboration: SAFE-BioPharma Association July 2005 Policy Approval Authority approved interoperable standard Sept 2005 – Trusted identity and non-repudiable digital signature – Single interoperable digital identity across industry – Technology and vendor neutral – Based on leading government technical and identity proofing standards – Interoperable with Federal agencies – Wrapped in a legal, governance and risk mitigation model – Recognized by world’s leading regulatory authorities – FDA and EMA SAFE-BioPharma Bridge operational Pilots and implementations – Pfizer, GSK clinical, Astra Zeneca regulatory; Firebird Pilot – National Cancer Institute, pharma, medical insts. 3 SAFE-BioPharma III: 2007-2010 Improving usability – Pilots and early adopters: resulted in expansion of the standard – basic, software, roaming – Improvements in identity proofing process and digital signing options – Growth in certified products and applications Building the interoperable network: – Expansion of commercial firms offering credentials and related services – Cross-certification with FBCA & establishment of 4BF (4 Bridges Forum) – EU qualified certificates; Safe Harbor certification Growing use and use cases 4 SAFE-BioPharma Association SAFE-BioPharma Members Alkermes McDougall Scientific Allergy & Asthma Inst. MWB Consulting Amarin National Notary Assn. Amgen Oxford Outcomes Abbott PDC Biotech AstraZeneca* Pfizer* Bristol-Myers Squibb* Premier Purchasing Eli Lilly Roche Forest Labs Sanofi-Aventis* GlaxoSmithKline SNAP Diagnostics IPS Research St. Renatus J&J* Merck* Veroha *Board members 5 SAFE-BioPharma Vendor Community Vendor Partners Vendor Partners Adobe* Tricipher* Arcot* Verizon ARX* Waters Inc.* Gemalto* Issuers Gemini Security Citibank Hitachi Exostar IBM IdenTrust IntraLinks J&J IDBS* Symantec LCSP TransSped Microsoft Safenet* Surety Symyx* *SAFE-BioPharma certified products 6 A Non-Profit, Member-Driven Standards Association Board of Directors & PAA Rick Yborra, BMS, Chair SAFE-BioPharma STAFF CEO •Jon Schoonmaker, Mollie Shields-Uehling Member Consortium Chief, Ops •Gary Wilson, Prog Mgr Working Groups SAFE-BioPharma • Rich Furr, Head, Japan Advisory Reg Afrs SAFE-BioPharma • Tanya Newton, Mgr, Group Technology WG European Reg Afrs Justin Bovee, J&J Astellas Keith Respass, Merck Union • Kevin Chisholm, Exec Asst Advisory • John Weisberg, PR •Federation TF, Group, & Comm Pfizer/Merck •Users Group, Isabelle Davias, •Kay Bross, Member Lilly/Pfizer Sanofi-Aventis & Vendor Progs •Issuers Group Hans van Leeuwen, Merck •Legal, Financial, Admin Global Business & Reg Betsy Fallen, Merck 7 SAFE-BioPharma Association – Non-Profit Standards Collaboration Standards Standards-Related Services Collaborative Association Supporting Innovation Standard Development & Operation of SAFE- Stakeholder outreach Maintenance BioPharma bridge Education & advocacy Governance/legal Cross-cert with FBCA framework Policy engagement Participation in CPWG Certification: Industry awareness & 4BF – network of trusted engagement - Products bridges Information/Best Practices - Issuers Implementation tools Forum Standards engagement: EU Safe Harbor – data privacy Policy forums HL7, CDISC, IHE, Kantara Antecedent Data ID Proofing Media: local, national, Working Groups trade, international –Technical EU qualified digital identities –Federation Process improvements –Users Group –Global Business & Reg Vendor partner program –SAFE EU Advisory Council –Japan Advisory Council Regulatory alignment: –FDA; EMEA; NCAs, PMDA 8 SAFE-BioPharma and Regulators EMA and FDA are on a publicly-announced paths to requiring fully electronic submissions within the next few years FDA helped write SAFE-BioPharma standard – CIO, PDUFA IT Team, 21CFR11 Council, CDER, CBER – Training program; compliance matrix; CIO meetings – FDA has received 10,000s of SAFE-BioPharma submissions since 9/06 EMA helped write standard – 2009 eCTD pilot – 5 companies submitted eCTDs to EMA; evaluation report – Accepting fully electronic eCTD submissions SAFE-BioPharma in Japan – JPMA has established Task Force on SAFE-BioPharma digital signatures – includes JMA and PMDA – Hitachi supporting SAFE-BioPharma implementations in Japan – Successful pilot with 3 hospitals and Astellas signing pharmacovigilance documents – Pilot underway with five Japanese companies 9 4BF –Network of Trusted Cyber-Communities Identrust Abbott Educational & Research Insts. Citi Merck GSK EADS Exostar Raytheon REBCA Boeing AZ J&J&J Verizon; Lockeed CertiPath SAFE Chosen; Martin Bridge CA Bridge CA TranSped Lilly Federal GPO Northrop Bridge CA Grumman SSP SITA Entrust Fed Common DoJ Policy Root CA GSA ARINC VeriSign MSO CertiPath Common Policy GPO ORC Root CA VeriSign US Treasury SSP SSP DoL DoE EPA HUD DoT SSA US PTO Verizon Bus Exostar DoD NRC NASA SSP Interoperability DHS DoJ Root E-Commerce EOP HHS Dot DoD VA DEA USPS Dept. of State State of Illinois ACES 4BF – 4 Bridges Forum www.The4BF.com Collaboration between GSA (USG), SAFE-BioPharma, Certipath and Higher Education to raise awareness and promote use of new network of trusted cyber-communities • SAFE-BioPharma example: Bristol-Myers Squibb, National Cancer Institute, and medical research institutions collaborating on variety of projects using Federal and SAFE digital IDs and signatures • Certipath: facilities access to DOD secure facilities • Higher Education Bridge: NIH grant applications; encrypted e-mail for university and govt. collaborations involving GSA: facilities access; network access; validate credentials from external parties; authentication to Level 3 & 4 applications by USG and private sector • Federal Bridge: Logical and physical access; digital signatures; collaboration among agencies and with external parties Phase II underway – communications and discussion forum – now includes the PIV-i providers – Verisign, Entrust, Verizon 11 SAFE-BioPharma IV: Greater Need for Standard and Many New Uses – 2011 Dramatically changing external environment – Industry facing patent cliff; downsizing; mergers; global collaborations – Clinical trials shift to India, China – Translational medicine – research-clinical practice-research cycle – USG payments for EHRs and forms of “MU” – meaningful use – DEA requirements for 2-factor for ePrescribing of controlled substances – Strengthened HIPAA (privacy) standards; EU data privacy standards Commercial technology providers moving into healthcare – Cloud-based solutions; mobile; multiple form factors – Credentials as commodities – value added services leveraging credentials – 4 Bridges – network of linked cyber-communities Growing use and use cases: – ELNs (basic laboratory research) – Regulatory submissions – Workflow between several/many partners for auth & signing 12 SAFE-BioPharma Association Examples of How SAFE-BioPharma Is Being Used Use Case Company ELNs – basic research Abbott (including China), BMS, GSK, Pfizer, SA/Aventis Pasteur (vaccines) Contracts, SOWs J&J, GSK, Premier, Oxford, MWB Consulting, IPS, Allergy & Asthma Inst. Physician Signatures SNAP Diagnostics ePrescribing (authentication and dig sig) 3 ePrescribing applications companies Purchasing Premier Clinical Research Sanofi-Aventis, BMS, National Cancer Inst. Research Collaboration BMS, National Cancer Institute, Sanofi-Aventis Alliance Management BMS, GSK Regulatory Submissions AZ, BMS, GSK, SA, Eli Lilly, Forest, J&J, Alkermes Document management system McDougall Scientific Legal signatures Veroha Paperless business/regulatory environment Amarin, MWB Consulting, SAFE-BioPharma SAFE-BioPharma Association Pfizer eLabNotebooks Company Profile: Largest research-based pharmaceutical Founding member, SAFE-BioPharma Assoc. Global research organizations Challenges – Productivity – Regulatory compliance • HIPAA • 21 CFR Part 11 – Patent defense Chemistry electronic notebook Scope: Paper lab notebook – Chemist, witness signatures – Patent implications Replace paper with electronic – SAFE-BioPharma digital signatures – TriCipher mySignatureBook Using digital signatures Flattened PDF for distribution Electronic records management Pfizer ELN Results and Benefits Results: Less time on paperwork, more in the lab – > 3300 researchers in 280 departments in 20 countries; – > 550,000 documents signed – >1,000,000 digital signatures! 3.3 million pages not printed! – >16 tons of paper saved Better patent defense – Signed, time-stamped in timely manner Better compliance with internal regulations Easier access to research – Electronic search of records Faster research cycles – More time in lab, less on paperwork; No more delays to collect witness signatures SNAP Diagnostics Company Profile:  Leader in diagnostic technology for detection of sleep apnea and analysis of snoring problems  Provides physicians in the U.S., EU, and Latin America with proprietary diagnostic equipment used in home settings Scope:  Records of at-home tests analysis by company physicians who advise referring physicians re therapeutic approach  Digital forms used in this process digitally signed Results:  Eliminated paper in day-to-day reviews of diagnostic information  Eliminated costs associated with handling, signing, shipping, storing and accessing paper 17 www.diahome.org GSK eSubmissions Move towards fully electronic submissions to FDA Reduce Waste – Costs – Time – Transport Efficiency Gains FDA Forms signed with Digital Signatures – No printing of paper copy to sign – Supports production across sites – No scanning of the signed FDA Form – No extra storage in USRA Archives (currently stores paper copy of Form along w/ e-sub.) GSK Strategic Decisions How to Credential (in-house, outsource, via SAFE-BioPharma) Who should be a Trusted Agent? Limits on signing? – Who should/can sign? What type(s) of document(s)? What tool(s) to use for signing? Meaning of Signature – A corporate signature on an FDA form is required AND – Signatory has a legal obligation as expressly written on the FDA form, and within the CFR sections that apply What to sign? – Initial and supplemental NDA, BLA, eCTD; CBE and CBE-30; annual Reports’ other GSK: Benefits/Cost Savings Savings in scanning, storing, transporting [over initial 9mo.] – Reduced monthly # of in-scope application forms using wet signature from 100% to 20% – Reduced cycle time from preparation of form to inclusion in submission (from average of 8 hrs to minutes) – Reduced records management/archival effort [approx 36 days or $6.1K / £4.1K Cost Savings] – Scanning and printing costs [approx. $.74 / £0.5K] – Enabled cross-site & virtual operations Pilot Study: Bristol-Myers Squibb National Cancer Institute-Cancer Therapy Evaluation Program (CTEP) Working example of how secure, online trusted identities can be used to save time and costs over the hard copy paper systems currently used for clinical trials Employs interoperable digital identities, digital signatures and cloud computing to eliminate reliance on paper forms when starting clinical trials Pilot study goals – accelerate initiation of clinical trials – eliminate reliance on paper forms – lower costs In line with principles of National Strategy for Trusted Identities in Cyberspace (NSTIC) 21 NCI-CTEP Mission: improve the lives of cancer patients by finding better ways to treat, control and cure cancer World’s largest sponsor of cancer treatment clinical trials – 900+ active clinical trials testing new cancer treatment regimens – activates 130 new protocols per year – each protocol produces many signed and exchanged documents among multiple participants – 100,000 pages in 2010 Mandates – initiate clinical trials to patient accrual more quickly – reduce costs – streamline document management while assuring greater document security – have environmentally sound procedures 22 Bristol-Myers Squibb Global biopharmaceutical company Mission: discover, develop and deliver innovative medicines that help patients prevail over serious diseases At leading edge of cancer research and treatment since 1970’s Many documents are signed, transmitted, countersigned Prior to study, process was delayed by sending physical documents via courier or fax for signature During study, electronic documents were stored in the cloud where researchers could access and sign immediately using digital signatures based on interoperable digital identities Paper Use 25 SAFE-BioPharma Association Results Cost Savings – Substantial cost savings anticipated as pilot moves to production – On average, 10% of the documents are shipped overnight and 10% by courier service. – Estimated savings: $500 per user Time Savings – Significant time savings – 3 to 5 business days per signature is typical – Pilot demonstrates that each signature can take minutes Document Loss – Pilot demonstrates elimination of lost or misplaced documents. – Using digital signatures establishes audit trail of when the document was uploaded, of the email sent to alert the signatory that the document is available for signature, and when the document was actually signed Reduced Environmental Impact – Moving to electronic process eliminates use of paper and ink, eliminates document shipment; minimizes storage and retrieval SAFE-BioPharma 2011 Focusing on Projects that Demonstrate Interoperability – BMS-NCI/CTEP pilot; move to production by end of year – Expand to other areas of NIH – Federation – 3-4 SAFE-BioPharma Members and NIH – DEA ePrescribing projects Expand the standard/rules – ICAM lower levels of trust Continue to align internationally – EU, Japan, China SAFE-BioPharma Association From Concepts and Ideals to Technologies, Products & Services 28 SAFE-BioPharma Association  Please visit the SAFE-BioPharma website: http://safe-biopharma.org/  Please visit the 4BF website: http://www.the4bf.com/  Watch the SAFE-BioPharma introductory video: http://www.safe-biopharma.org/video.htm  Contact us for more information: Mollie Shields Uehling Kay Bross, Director Tanya Newton Jon Schoonmaker CEO Member/Vendor Progs Manager, Reg Afrs Chief of Operations & mollie@safe-biopharma.org kbross@safe-biopharma.org (908) 213-1069 Technical Program (201) 849-4544 (513) 489-3840 (o) tanya.newton@safe- (301) 610-6060 (201) 925-2173 (cell) (513) 673-2344 (c) biopharma.org jon.schoonmaker@safe- biopharma.org Kevin Chisholm, Admin. Rich Furr Gary Wilson Jon Weisberg Kevin.Chisholm@SAFE- Head, Reg. Afrs. Prog. Mgr Communications BioPHarma.org RFurr@SAFE-BioPharma.org (781) 962-3172 801-359-9977 o (201) 849-4545 (980) 236-7576 Gwilson@safe- 801-860-9977 m biopharma.org jweisberg@safe-biopharma.org 29 Single Sign-On and Federated Authentication at NIH and Beyond Debbie Bucci National Institutes of Health About NIH • National Institutes of Health (NIH) • Operating division of the U.S. Department of Health & Human Services (HHS) • Primary Federal agency for conducting and supporting biomedical research 2 External Users • NIH provides financial support to researchers around the world. • NIH invests over $28 billion in medical research each year. $5 Billion for Researchers Inside NIH 83% goes to almost 50,000 $23 Billion for competitive grants that Researchers support over 325,000 Outside NIH researchers outside NIH. 3 Authentication Services at NIH NIH iTrust Multifunction single sign-on (SSO) and federated authentication service consisting of: • NIH Login – links internal users at NIH to internal and departmental (HHS) applications and electronic resources • NIH Federated Login – links external users to NIH and departmental (HHS) applications and resources 4 Federated Authentication Partners • Government Departments and Agencies • InCommon Federation – identity and access management federation for the higher education and research communities; nearly 50 major universities access NIH resources through InCommon. • Open Identity Exchange (OIX), OpenID, and Information Card Foundations are working with industry leaders such as AOL, Equifax, Google, PayPal, VeriSign, and Yahoo to provide access at Levels of Assurance (LOA) 1-4. 5 NIH Login • In production since 2003 • Over 55,000 NIH users, 275 applications, 700 URLs • 1.7 -2.4 million transactions per day • Single Sign-On (SSO), including use of Personal Identity Verification (PIV) Cards • Authenticated web services • June 2008 mandated for all new web applications • May 2010 all Login apps must support PIV • Dec 2010 all sensitive applications must use two factor • Delayed to June 2011- issues with Citrix, VPN and legacy applications, desktops and laptops and Non PIV Holders 6 NIH Federated Login • In production since 2008 • 60 Federated applications • University participation up 240% • Over 72,000 external credentials averaging 2-3000 users a week • Scaled to support 1 Million users on track to support over 500,000 external users by end FY11: − wikis, SharePoint, Grids, Library services Acquisition services − Cross-agency, government- wide collaborations − Enterprise/departmental applications 7 Federated View 8 Federated Authentication at NIH General General Services Services Administration Administration Trust Trust framework framework provider provider Private-sector U.S. Government Assessors Assessors Dispute Dispute identity providers & websites & auditors auditors resolvers resolvers User 9 Federated Authentication at NIH General General Services Services Administration Administration Trust Trust framework framework provider provider Universities U.S. Government Assessors Assessors Dispute Dispute & websites & auditors auditors resolvers resolvers User 10 Federal Mandates Mandates for Federated Authentication and Personal Identity Verification (PIV) Card and Common Access Card (CAC) across the Federal Government: •HSPD-12 “Policy for a Common Identification Standard for Federal Employees and Contractors” •FIPS 201-1 “Personal Identity Verification of Federal Employees and Contractors” •NIST SP-800-63 “Electronic Authentication Guideline” •OMB M-04-04 “E-Authentication Guidance for Federal Agencies” •OMB M-06-16 “Protection of Sensitive Agency Information” •OMB M-11-11 “ Continued Implementation of Homeland Security Presidential Directive (HSPD) 12– Policy for a Common Identification Standard for Federal Employees and Contractors “ 11 NIH iTrust Key Points • Aligns with FICAM’s IdM reference segment architecture • Integrates with HHS Operating Divisions and other departments and agencies • Promotes both interoperability and standards • Meets the needs of researchers and clinicians • Offers quick implementation 12 Current Integration Projects • NIH eVIP (electronic Vendor Invoicing Program) – Over 30,000 users and 7,000 vendors across the country will submit invoices, receive payment, and complete other transactions using their own identity credentials • NIH eRA (electronic Research Administration) – Over 250,000 researchers and 9,500 institutions worldwide will apply for grants and access funding, while helping eRA monitor grant disbursement • National Library of Medicine PubMed Database – Secure access for users with OpenID credentials such as Google and Yahoo – 12,000 OpenID users registered in the first six weeks 13 Current Integration Projects • Healthcare Reform Implementation Tracking Tool (HRITT) – HHS, CMS, White House, and other agencies will use MS Project Server to track implementation of the 400+ provisions of the 2010 Patient Protection and Affordable Care Act • National Interagency Confederation for Biological Research (NICBR) – Federated access to a group of applications used by researchers from the National Cancer Institute, National Institute of Allergy and Infectious Diseases, Army, Navy, Department of Homeland Security, CDC, and USDA at Ft. Detrick, MD 14 For Further Information Debbie Bucci Manager, Integration Services Center Division of Enterprise and Custom Applications Center for Information Technology National Institutes of Health Debbie.Bucci@nih.gov NIH Integration Services Center NIHISCSupport@mail.nih.gov NIH Center for Information Technology www.cit.nih.gov 15 Efficient Transmission of DoD PKI Certificates in Tactical Networks Secured Communications at the Tactical Edge Certificate Profile Bandwidth Constrained Links Basic Metadata Fields AF Portal AF Portal Login CAC/ECA Password Public Key Extension Fields Insert your CAC/ECA to begin your login LOG IN Signature Membership & Support Information • • • • • • • Application Data Legend: GIG Metadata (human readable) Frequent certificate transmission consumes scarce bandwidth Random-appearing data Goal: reduce certificate sizes more bandwidth for application data Approach: standard data compression with preplaced dictionary Dictionary Dictionary Original Certificate Compressed USAF MDA Contains metadata USA DISA DISA elements common across DoD PKI certificates Dictionary Compressed Original Certificate Similar profiles lead to redundancies in Standard data compression removes internal data redundancies metadata across DoD PKI certificates Additional redundancies removed using preplaced dictionary Methodology Data Set Average Certificate Sizes 1200 Uncompressed Collect Data 100.0% 100.0% Compressed, no dict. • Certificates obtained from DoD Global 1000 Compressed, w/ dict. Directory Service – 189 for dictionary corpus, 169 for 800 77.0% 82.3% 100.0% Refine and Categorize testing corpus Bytes 600 • Drawn from 22 organizations across DoD 49.4% 63.3% 78.4% • Categorized into distinct profiles 400 44.7% – Profile AB: RSA 1024 bit signature, Dictionary Testing ~7 KB dictionary size 200 Corpus Corpus – Profile C: RSA 2048 bit signature, ~11 KB dictionary size 0 RSA RSA Elliptic Curve Profile AB Profile C 512 bit Signature Dictionary Experiments Dictionary-aided compression can reliably reduce transmission overhead of DoD PKI certificates Lincoln Laboratory POC: Sean O’Melia, sean.omelia@ll.mit.edu, Roger Khazan, rkh@ll.mit.edu, and Dan Utin, danu@ll.mit.edu This work is sponsored by the United States Air Force under Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government. 445601.ai 12712 Federal Register / Vol. 76, No. 45 / Tuesday, March 8, 2011 / Notices themes. There will also be breakouts for of time per speaker will be determined environment since the publication of each subcommittee to meet by the number of requests received, but FIPS 201–1, and specific changes individually. The agenda may change to is likely to be about 3 minutes each. requested by Federal agencies and accommodate Committee business. The Questions from the public will not be implementers. NIST has received final agenda will be posted on the Smart considered during this period. Speakers numerous change requests, some of Grid Web site at http://www.nist.gov/ who wish to expand upon their oral which, after analysis and coordination smartgrid. statements, those who had wished to with the Office of Management and DATES: The SGAC will hold a meeting speak but could not be accommodated Budget (OMB) and United States on Thursday, March 24, 2011, from 8:30 on the agenda, and those who were Government (USG) stakeholders, are a.m. until 5 p.m. The meeting will be unable to attend in person are invited to incorporated in the Draft FIPS 201–2. open to the public. submit written statements to the Office Before recommending FIPS 201–2 to the of the National Coordinator for Smart Secretary of Commerce for review and ADDRESSES: The meeting will be held in Grid Interoperability, National Institute approval, NIST invites comments from the Lecture Room C, in the of Standards and Technology, 100 the public concerning the proposed Administration Building at NIST in Bureau Drive, Mail Stop 8100, changes. NIST will hold a public Gaithersburg, Maryland. Please note Gaithersburg, MD 20899–8100; fax 301– workshop at NIST in Gaithersburg, MD admittance instructions under the 975–4091; or via e-mail at to present the Draft FIPS 201–2. Please SUPPLEMENTARY INFORMATION section of nistsgfac@nist.gov. see admittance instructions in the this notice. All visitors to the NIST site are SUPPLEMENTARY INFORMATION section FOR FURTHER INFORMATION CONTACT: Dr. required to pre-register to be admitted. George W. Arnold, National Coordinator below. Anyone wishing to attend this meeting for Smart Grid Interoperability, National must register by close of business DATES: Comments must be received by Institute of Standards and Technology, Thursday, March 17, 2011, in order to June 6, 2011. The public workshop will 100 Bureau Drive, Mail Stop 8100, attend. Please submit your name, time be held on April 18–19, 2011. Pre- Gaithersburg, MD 20899–8100; of arrival, e-mail address, and phone registration must be completed by close telephone 301–975–2232, fax 301–975– number to Cuong Nguyen. Non-U.S. of business on April 11, 2011. 4091; or via e-mail at nistsgfac@nist.gov. citizens must also submit their country ADDRESSES: Written comments may be SUPPLEMENTARY INFORMATION: The of citizenship, title, employer/sponsor, sent to: Chief, Computer Security Committee was established in and address. Mr. Nguyen’s e-mail Division, Information Technology accordance with the Federal Advisory address is cuong.nguyen@nist.gov and Laboratory, ATTN: Comments on Committee Act (5 U.S.C. App.). his phone number is (301) 975–2254. Revision Draft FIPS 201–1, National Background information on the Institute of Standards and Technology, Dated: March 2, 2011. Committee is available at http:// 100 Bureau Drive, Mail Stop 8930, www.nist.gov/smartgrid/committee.cfm. Charles H. Romine, Gaithersburg, MD 20899. Electronic Pursuant to the Federal Advisory Acting Associate Director for Laboratory Programs. comments may be sent to: Committee Act, 5 U.S.C. App., notice is piv_comments@nist.gov. Anyone hereby given that the Smart Grid [FR Doc. 2011–5250 Filed 3–7–11; 8:45 am] wishing to attend the workshop in Advisory Committee (SGAC) will hold a BILLING CODE 3510–13–P person, must pre-register at http:// meeting on Thursday, March 24, 2011, www.nist.gov/allevents.cfm. Additional from 8:30 a.m. until 5 p.m. The meeting workshop details and webcast will be will be held in the Lecture Room C, in DEPARTMENT OF COMMERCE available on the NIST Computer the Administration Building at NIST in Security Resource Center Web site at National Institute of Standards and Gaithersburg, Maryland. The primary Technology http://csrc.nist.gov. purpose of this meeting is to review the [Docket No. 110124059–1058–02] FOR FURTHER INFORMATION CONTACT: early findings and observations of each William MacGregor, (301) 975–8721, Subcommittee, strategize the Table of Announcing Draft Federal Information National Institute of Standards and Contents for the Committee report to Processing Standard (FIPS) 201–2, Technology, 100 Bureau Drive, Mail NIST, agree on the page limit for each Personal Identity Verification of Stop 8930, Gaithersburg, MD 20899– subcommittee, and look for any Federal Employees and Contractors 8930, e-mail: common overarching themes. There will Standard, Request for Comments, and william.macgregor@nist.gov, or also be breakouts for each subcommittee Public Workshop on Draft FIPS 201–2 Hildegard Ferraiolo, (301) 975–6972, e- to meet individually. The agenda may mail: hildegard.ferraiolo@nist.gov, or change to accommodate Committee AGENCY: National Institute of Standards Ketan Mehta, (301) 975–8405, e-mail: business. The final agenda will be and Technology (NIST), Commerce. ketan.mehta@nist.gov. posted on the Smart Grid Web site at ACTION: Notice and request for http://www.nist.gov/smartgrid. comments. SUPPLEMENTARY INFORMATION: FIPS 201 Individuals and representatives of was issued in February 2005, and in organizations who would like to offer SUMMARY: The National Institute of accordance with NIST policy was due comments and suggestions related to the Standards and Technology (NIST) for review in 2010. In consideration of Committee’s affairs are invited to publishes this notice to request changes in the environment over the last request a place on the agenda by comments on Draft Federal Information five years and specific requests for srobinson on DSKHWCL6B1PROD with NOTICES contacting Cuong Nguyen at Processing Standard (FIPS) Publication changes from USG stakeholders, NIST cuong.nguyen@nist.gov or (301) 975– 201–2, ‘‘Personal Identity Verification of determined that a revision of FIPS 201– 2254 no later than March 17, 2011. On Federal Employees and Contractors 1 (version in effect) is warranted. NIST March 24, 2011, approximately one-half Standard.’’ Draft FIPS 201–2 amends has received numerous change requests, hour will be reserved at the end of the FIPS 201–1 and includes clarifications some of which, after analysis and meeting for public comments, and of existing text, removal of conflicting coordination with OMB and USG speaking times will be assigned on a requirements, additional text to improve stakeholders, are incorporated in the first-come, first-serve basis. The amount clarity, adaptation to changes in the Draft FIPS 201–2. Other change requests VerDate Mar<15>2010 19:12 Mar 07, 2011 Jkt 223001 PO 00000 Frm 00022 Fmt 4703 Sfmt 4703 E:\FR\FM\08MRN1.SGM 08MRN1 Federal Register / Vol. 76, No. 45 / Tuesday, March 8, 2011 / Notices 12713 incorporated in the Draft FIPS 201–2 ‘‘chain-of-trust’’ method can only be it is apparent that terms such as result from the 2010 Business used if the PIV Card Issuer has ‘‘renewal’’, ‘‘reissuance’’, Requirements Meeting held at NIST. retained biometric data through ‘‘replacement’’, ‘‘registration’’, etc., are The meeting focused on business which an individual can be used interchangeably and requirements of Federal departments authenticated. inaccurately and that FIPS 201–1 and agencies. The following is a —Section 2.4 is added to define a 1-to- needs to clearly state the purpose and summary of changes reflected in the 1 biometric match. A 1-to-1 biometric circumstances under which identity Draft FIPS 201–2. Please note that the match is necessary to associate a credential renewal is required. Draft proposed revision of the document has presenting individual with their FIPS 201–2 introduces normative text caused a renumbering of several ‘chain-of-trust’ record. The objective to address this ambiguity. sections of FIPS 201–1 (version in is to reduce replacement cost to —Section 2.5.2.1 is added to recognize effect). The section references below are agencies for lost, stolen, or damaged legal name changes. Name change is consistent with Draft FIPS 201–2. The PIV Cards, to reduce the amount of a very common occurrence, and it changes in Draft FIPS 201–2 are: data gathering, and minimize in- represents a major change in identity • Changes to clarify requirements and person visits without compromising source documents. Specific editorial corrections are incorporated the security objectives of HSPD–12. requirements to manage and record throughout the document. These —Section 2.4 is modified to increase the legal name changes correctly and changes are not intended to modify the maximum life of PIV Card from 5 consistently across identity substantive requirements in FIPS 201–1. years to 6 years. This revision is made management systems were identified • Specific modifications that in response to agency requests to and are included. potentially change an existing synchronize lifecycles of card, —Sections 2.5.3 and 2.5.4 are added to requirement or add a new requirement certificates, and biometric data. provide requirements for post- are reflected in the following list. —Section 2.4.1 is added to introduce a issuance updates made to the PIV special rule for pseudonyms, Card after it is issued to the —In Section 2.1, the second bullet is clarifying the conditions under which cardholder. These requirements are replaced with ‘‘A credential is issued pseudonyms may be approved by the added in response to agency requests. only after the National Agency Check sponsoring agency (i.e., for the —Section 2.5.5 is added to provide with Written Inquiries (NACI) or protection of the cardholder). FIPS details on reset procedures for PIN, equivalent is initiated and the FBI 201–1 does not specify requirements biometrics or other types of resettable National Criminal History Check for issuing PIV credentials under data as per agency requests. (NCHC) is completed,’’ to eliminate an pseudonyms. This use-case requires a —Section 4.1.4 is added to provide inconsistency that was inadvertently normative list of minimum visual card topography zones and introduced by the FIPS 201–1 requirements within the standard. color specifications from SP 800–104 revision. —Section 2.4.2 is added to introduce a ‘‘A Scheme for PIV Visual Card —In Section 2.2, the text is replaced grace period for the period between Topography.’’ SP 800–104 was with a reference to the memorandum termination of an employee or developed after FIPS 201–1 was from Linda Springer, Director Office contractor and re-employment by the published to enhance the uniformity of Personnel Management (OPM), USG or a Federal contractor. If re- of colors and additional zones needed dated 31 July 2008, ‘‘Final employment occurs within the grace by agencies. Credentialing Standards for Issuing period, to obtain a new PIV Card, an —Section 4.1.4.1 is modified to allow Personal Identity Verification Cards NCHC is required and a complete longer names (70 characters) to be under HSPD–12.’’ The purpose of this NACI is not required. For example, an printed on the card in the existing change is to update the identity employee may be detailed to a special zone. This change is made to enable credentialing requirements in assignment for a brief time period printing of complete names for accordance with OPM guidance and, upon completion of the required accuracy. issued after the FIPS 201–1 was assignment, return to the original —Section 4.1.4.3 is added to provide published. agency. In another case, the PIV requirements for compliance with —Section 2.3 is modified to directly Cardholder may move from one Section 508 of the Americans with incorporate the content from the I–9 Federal agency to another within a Disabilities Act. The U.S. Access form that is relevant to FIPS 201. This short period of time. In each of these Board, an independent Federal agency change is made to eliminate confusion situations, repeating the entire devoted to accessibility for people that has resulted from I–9 content that identity proofing and identity vetting with disabilities, requested is not used by FIPS 201–1 processes; process when all the necessary improvements in FIPS 201 to facilitate it also provides a more precise information about the individual was the use of the PIV Card by people requirement statement for the two previously collected in accordance with impaired vision or manual forms of identity source documents. with FIPS 201–1 is inefficient. The dexterity. For example, an —Section 2.3 is modified to introduce grace period to allow reuse of the improvement could allow an the concept of a ‘‘chain-of-trust,’’ existing records held by an agency unsighted person to quickly and maintained by a PIV Card Issuer, addresses this inefficiency. positively orient the card by touch further described in Sections 2.4, 2.5 —Section 2.5 is modified to restructure when presenting the PIV Card to a and 4.4.1. The ‘‘chain-of-trust’’ allows the PIV Card maintenance procedures card reader. srobinson on DSKHWCL6B1PROD with NOTICES the holder of a PIV Card to obtain a slightly. ‘‘Renewal’’ of a PIV Card to —Section 4.1.6.1 is modified to revise replacement for a compromised, lost, re-collect biometric data, currently a the list of mandatory and optional PIV stolen, or damaged PIV Card through facial image and two fingerprint logical credentials. This section is biometric authentication. This templates, is required once every modified based on the inputs received capability is requested by Federal twelve years, to update files to during the 2010 Business agencies because the alternative, account for normal aging. Subsequent Requirements Meeting described complete re-enrollment, is time- to the issuance of FIPS 201–1 and above. The section adds a requirement consuming and expensive. The based on comments received by NIST, to collect alternate iris images when VerDate Mar<15>2010 19:12 Mar 07, 2011 Jkt 223001 PO 00000 Frm 00023 Fmt 4703 Sfmt 4703 E:\FR\FM\08MRN1.SGM 08MRN1 12714 Federal Register / Vol. 76, No. 45 / Tuesday, March 8, 2011 / Notices an agency cannot capture reliable authentication assurance confidence DEPARTMENT OF COMMERCE fingerprints. This section also levels shown in Tables 6–2 and 6–3. specifies a mandatory asymmetric —Section 6.2.5 and 6.2.6 are added to National Oceanic and Atmospheric card authentication key as part of PIV provide authentication mechanisms Administration logical credentials and adds an based on optional PIV data elements. optional On-card biometric Proposed Information Collection; Specifically, an On-card biometric Comment Request; Marianas Trench comparison as a means of performing comparison authentication card activation and PIV Marine National Monument Knowledge mechanism is added in Section 6.2.5 and Attitudes Survey authentication mechanism. The and a symmetric card authentication section includes hooks for additional key authentication mechanism is AGENCY: National Oceanic and keys if they are needed for secure added in Section 6.2.6. Atmospheric Administration (NOAA), messaging. In addition, NIST Commerce. proposes that specific key references —Appendix A is removed. ACTION: Notice. and their use will be defined in a FIPS 201–1 and Draft FIPS 201–2 are future special publication. available electronically from the NIST SUMMARY: The Department of —Section 4.1.7.1 is modified to allow a Web site at: http://csrc.nist.gov/ Commerce, as part of its continuing PIN or equivalent verification data publications/fips/index/html. effort to reduce paperwork and (e.g., biometric data) to activate a PIV respondent burden, invites the general Card to perform privileged operations. NIST will hold a public workshop on public and other Federal agencies to The requirement that all PIV System Draft FIPS 201–2 on Monday and take this opportunity to comment on cryptographic modules be tested and Tuesday, April 18 and 19, 2011 at NIST proposed and/or continuing information validated to FIPS 140–2 Security in Gaithersburg, Maryland. The collections, as required by the Level 2 (logical) or Security Level 3 workshop may also be attended Paperwork Reduction Act of 1995. (physical) is not changed. remotely via webcast. The agenda, DATES: Written comments must be —Section 4.3 is modified to make the webcast and related information for the public workshop will be available submitted on or before May 9, 2011. NACI Indicator optional and to ADDRESSES: Direct all written comments deprecate its use. The NACI Indicator before the workshop on the NIST Computer Security Resource Center to Diana Hynek, Departmental originally was included in the PIV Paperwork Clearance Officer, Authentication Certificate to inform Web site at http://csrc.nist.gov. This workshop is not being held in Department of Commerce, Room 6616, relying systems that the background anticipation of a procurement activity. 14th and Constitution Avenue, NW., investigation had not been completed Anyone wishing to attend the workshop Washington, DC 20230 (or via the before issuing the PIV Card. Since the in person, must pre-register at http:// Internet at dHynek@doc.gov). issuance of FIPS 201–1, timely completion of background www.nist.gov/allevents.cfm by close of FOR FURTHER INFORMATION CONTACT: investigations has improved, online business Monday, April 11, 2011, in Requests for additional information or status checking services are now order to enter the NIST facility and copies of the information collection available, OPM requirements for attend the workshop. In accordance instrument and instructions should be background investigations have been with the Information Technology directed to Dr. Stewart Allen, (808) 944– revised, and OMB reporting Management Reform Act of 1996 (Pub. 2186 or Stewart.Allen@noaa.gov. requirements are in place. These L. 104–106) and the Federal Information SUPPLEMENTARY INFORMATION: improvements provide sufficient Security Management Act of 2002 (FISMA) (Pub. L. 107–347), the I. Abstract controls to make the need for storing NACI Indicator on the PIV Card Secretary of Commerce is authorized to President George W. Bush established optional and to deprecate its use. approve Federal Information Processing the Marianas Trench Marine National —Section 4.3 is modified to add an Standards (FIPS). Homeland Security Monument (Monument) on January 6, option to include country(ies) of Presidential Directive (HSPD) 12, 2009, by Presidential Proclamation citizenship of Foreign Nationals in the entitled ‘‘Policy for a Common 8335. The monument includes PIV Authentication Certificate. This Identification Standard for Federal approximately 95,216 square miles change reflects the desirability of Employees and Contractors’’, dated within three units in the Mariana electronically reading the affiliation of August 27, 2004, directed the Secretary Archipelago. The Mariana Trench Unit Foreign Nationals. of Commerce to promulgate, by is almost 1,100 miles long and 44 miles —Section 4.5.3 is added to allow a February 27, 2005, ‘‘ * * * a Federal wide and includes only the submerged possible future inclusion of an standard for secure and reliable forms of lands. The Volcanic Unit consists of optional ISO/IEC 24727 profile that identification (the ‘Standard’) * * * ,’’ submerged lands around 21 undersea enables middleware a degree of and further directed that the Secretary mud volcanoes and thermal vents along independence from credential of Commerce ‘‘shall periodically review the Mariana Arc. The Islands Unit interfaces and vice versa and thus the Standard and update the Standard includes only the waters and submerged provides adaptability and resilience to as appropriate in consultation with the lands of the three northernmost Mariana PIV card evolution. affected agencies.’’ Islands: Farallon de Pajaros or Uracas; —Sections 6.2.2, 6.2.3.1, and 6.2.3.2 are E.O. 12866: This notice has been Maug; and Asuncion, below the mean modified to remove the qualifier determined not to be significant for low water line. Within the Islands Unit srobinson on DSKHWCL6B1PROD with NOTICES ‘‘(Optional)’’ from the requirement for purposes of E.O. 12866. of the monument, commercial fishing is signature verification and certificate prohibited but sustenance, recreational, path validation in the CHUID, BIO, Dated: February 17, 2011. and traditional indigenous fishing can and BIO–A authentication Charles H. Romine, be allowed on a sustainable basis. mechanisms. These signature Acting Associate Director for Laboratory The Secretary of the Interior has verification and path validation Programs. management responsibility for the functions would be mandatory under [FR Doc. 2011–5259 Filed 3–7–11; 8:45 am] monument, in consultation with the FIPS 201–2 to achieve the BILLING CODE 3510–13–P Secretary of Commerce who, through VerDate Mar<15>2010 19:12 Mar 07, 2011 Jkt 223001 PO 00000 Frm 00024 Fmt 4703 Sfmt 4703 E:\FR\FM\08MRN1.SGM 08MRN1 Towards a method for managing distributed access entitlement and access certification (Can we trust that AuthZ attribute?) Problem: Federation agreement documents may authorize access rights for collaboration partners, yet they alone do not fulfill compliance requirements for authorization. If we must produce audit data for internal access certification, aren’t audit data also required for ABAC and distributed AuthZ? Example Control Requirements: • NIST SP 800-53 Rev 3 AC-3 ACCESS ENFORCEMENT: Control Enhancements...(2) The information system enforces dual authorization, based on organizational policies and procedures...Dual authorization mechanisms require two forms of approval to execute. • Payment Card Industry (PCI) Data Security Standard: Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need to know 7.1.3 Requirement for a documented approval by authorized parties specifying required privileges. 7.1.3 Confirm that documented approval by authorized parties is required (in writing or electronically) for all access, and that it must specify required privileges. Description/As-Is: ICAM Business Architecture Objects: ENTITY Detailed View The As-Is architecture already supports the ability to associate a Person with an affiliation through an agreement. The As-Is architecture also addresses the requirement for explicit Access Permission to be granted, enforcing separation of duties. This can be done on a person-by-person basis, or through access granted to a Community. As implemented today, there is an implicit assumption that the person involved in requesting, sponsoring, and approving access requests is a “NASA” Person. A simplified table entry illustrates that for each Access Permission granted, there is an auditable entry in the Policy Administration Point that shows who requested, sponsored, and approved the access. Access Permission User Requestor Sponsor Approver AssetAPrivilegeB Person:1234567 2345678 3456789 4567890 AssetAPrivilegeA Community:1234 2345687 3456798 4567890 Requirements Mapping/To-Be: Access Permission User Requestor Sponsor Approver AssetAPrivilegeB Organization:Agreement:Person:1234567 Organization:Agreement:2345678 Organization:Agreement:3456789 Organization:Agreement:4567890 AssetAPrivilegeA Organization:Agreement:Community:1234 Organization:Agreement:2345687 Organization:Agreement:3456798 Organization:Agreement:4567890 Proposition: Extend the current architecture to support registration of Access Permissions to federated People and Communities Register federation agreements in Policy Administration Points Add organization/agreement attributes to Access Permission registries Send info in SAML assertion; register table entry in NAMS at point of access. Questions: • What is the best person identifier from an external source? We assume UUID, although many organizations do not support UUID today. • Do we need standard organization identifiers? FASC-N can be used for Federal entities; it gets more complicated in the non-Federal space. • What happens when we federate with a federation? • How do we know freshness? Do we do it every time we have a transaction? How “sticky” should the authorization be? Next Steps: Corinne S. Irwin, NASA • Achieve consensus on the problem space and compliance requirements Corinne.S.Irwin@nasa.gov • Explore technical approaches 202-358-0653 • SAML Profile, attribute schemas • SPML Dennis C. Taylor, NASA/ASRC Primus Solutions • BAE Dennis.C.Taylor@nasa.gov • Define federation agreements/interface definition agreements 301-286-4290 • Define Interconnection Security Agreement (ISA) / modifications PKAuth: A Social Login Protocol for Unregistered Apps Francisco Corella and Karen Lewison Pomcor Dangers of Social Login PKAuth Protocol Flow Step 6: Site redirects browser to application Browser-Resident Applications Step 1: User specifies social site Include AJAX applications implemented in JavaScript, rich Social login allows an application to delegate authentication to a Note:this is POST redirection, applications implemented in Flex or Silverlight. implemented by downloading a social site and gain access to the user’s social context. Social site form and JavaScript code that Examples: Login with Facebook, Twitter, LinkedIn, etc. Step 2: Application obtains site info from well-known file submits the form automatically TLS cert and private key reside in server-side component. Social login is becoming very popular. But social login uses Steps 3, 7, 9: connections from browser to site proxied through OAuth, and OAuth requires registration of the application with server-side component, which authenticates with TLS certificate Step 3: Application sends direct request Application and private key. the site. And a social site has become dominant (Facebook). TLS cert Login with Facebook may become the de facto standard for App presession token Step 4: client-side component creates form in window, tab or frame, Requested access to user’s account at site Access token and submits form. user authentication on the Web. Then: Social site Callback URI Cookie with app Signed app presession token including presession key Step 6: server-side component receives redirected request and • All applications will have to register with Facebook just to app presession key downloads it to client-side component. be able to authenticate their users. Site presession key TLS cert Browser • Facebook will have the power to disable any Web Application Native Applications application by revoking its registration. Application verifies presession token signature. Application verifies that presession key is in presession token. Each application instance running in a user’s machine has its own Dire Consequences TLS client certificate and private key, used in steps 3, 7 and 9. The Step 7: Application gets user identity data instance certificate is backed by an application certificate. Compulsory application registration is very bad for: Step 4: application instance launches external browser. Browser • Web applications, which can be disabled by Facebook Step 6: the callback URI is a local URI, or a URI with a custom Social site • Users who lose access to an application if Facebook revokes Access token scheme, or a URI that targets and ancillary Web server. If a Web the application’s registration server is used, it uses the same application certificate that backs Step 4: Application redirects browser to site User idenfier within social site the instance certificates as a TLS server certificate. • Facebook competitors, who will be at a great disadvantage TLS cert Identity data Application Note:this is POST redirection, • The government, which may have to step in implemented by downloading a Security Properties Social site form and Javascript code that submits the form automatically • Facebook, which may face government regulation Protection against phishing attacks: user is never asked to provide We Need a Social Login Standard… credentials on the fly. Application Protection against CSRF attacks on the site: traditional • …that does not require registration of the application with Browser countermeasure works because user is logged in. Site presession key the site Protection against CSRF attacks on the application: provided by Site verifies association between access token and certificate presession key in cookie • …that allows the user to choose any site (federation) Cookie with app presession key • …that does not have the phishing vulnerabilities and other Step 8: Application logs user in Protection against DOS attacks on callback endpoint: provided by security flaws of OAuth and OpenID signed presession token. Browser User ID within application = user ID within site + site domain name Identity data used to update or create user account Protection against DOS attacks by storage exhaustion: neither site A Candidate: PKAuth nor application keep storage allocated while waiting for input from Step 5: Site verifies user is logged in, identifies an unauthenticated user. Step 9: Application accesses user’s social context PKAuth relies on the Web’s PKI rather than registration to application to user, asks permission authenticate the application and identify it to the user Social site To Do User must be Access token Social site logged in OAuth PKAuth Application gets list of friends Produce a formal specification. and other social data TLS cert Create open source reference implementations. Application Shared secret App’s existing Application publishes updates Application authentication established by TLS certificate Application Use PKAuth to implement decentralized social networks. based on… registration and private key Site identifies User grants application to user, permission Have PKAuth adopted as a social login standard. describes requested access, Identification of Information Information asks permission application to the obtained by contained in TLS Paper Available At… user based on… registration certificate Browser Browser http://pomcor.com/whitepapers/PKAuth.pdf. Site verifies association between access token and certificate TEMPLATE DESIGN © 2008 www.PosterPresentations.com Unified Identity for Access Control Carl Ellison 7 April 2011 IDtrust Trust Insiders 2 Instruct Outsiders This electronic message contains information from the law firm of _________. The contents may be privileged and confidential and are intended for the use of the intended addressee(s) only. If you are not an intended addressee, note that any disclosure, copying, distribution, or use of the contents of this message is prohibited. If you have received this e-mail in error, please delete this message and any attachments and contact me at __________.com. 3 Enforcement by Technical Means • Specific access control: – Account login – Session with cached ID(s) – ACLs on files • Simple ACL, one per file – List of IDs of those permitted to access the file – If one of your cached IDs matches one on the ACL then you get access. 4 Simple ACL 5 Simple ACL ... 6 N Simple ACL M ... ... Work = bNM b=30 sec; N=5e4; M=3e5; Work  60000 man-yrs 7 N Add Named Group M ... ... Work = b(N+M) b=30 sec; N=5e4; M=3e5; Work  73 man-wks 8 N Directory Inheritance M ... ... Work = b(N+1) b=30 sec; N=5e4; M=3e5; Work  10 man-wks 9 Machinery To Do ACLs and Groups • Security IDs (SIDs) • Implemented within the OS • Each OS does it differently, but I’ll use a subset of Windows™ as the example here – It is very common. – It includes both group definitions and directory inheritance. 10 Group Definition in Windows™ Today • SID = (Domain ID, Relative ID) = (D, R) – Each SID has a printable name, local to the Domain, but we don’t deal with that here. • Same SID format for individuals and groups • ACL is list of SIDs; Group is a list of SIDs • Groups are defined in Active Directory™ by: – “(D, R1) is member of (D, R2)” – only a domain administrator of D may make or delete that definition. 11 Multiple Projects ... ... ... ... ... 12 Equivalent Graph ... ... ... ... ... Same graph, but fewer links, so less cost. 13 Groups as Org Chart • Nested named groups allow us to capture the relevant levels of an org chart, for example: – Software Developers • Core Operating System – File system – Scheduler – Crypto • Shell – Explorer – Control Panel • It is often easier to express policies in terms of those org chart groups rather than individuals. • If we want RBAC, we can express roles as SIDs, using the group machinery. 14 Scopes • On the resource side, we can also lump files together in groups of resources, called scopes – This can be done with directories, if all files are on one machine, with propagation of ACLs down the directory structure. – If the files span multiple machines, then scopes can be defined using the group mechanism, as we show in our examples here. 15 Groups and Scopes ... ... ... ... ... Groups Scopes 16 Pretty Good Stuff • With the machinery we have today, we get SIDs for IDs, groups, roles and scopes. • Groups and scopes can be nested as deeply as we want. • We can represent an org chart with nested groups. • We can represent a project hierarchy of files with nested scopes. • So, what’s the problem? 17 Multiple Organizations ... ... ... ... ... 18 Crossing Organization Boundaries ... ... ... ... 19 Crossing Organization Boundaries ... ... ... ... 20 Crossing Organization Boundaries ... ... ... ... 21 Crossing Organization Boundaries ... ... ... ... 22 Crossing Organization Boundaries ... ... ... ... 23 Crossing Organization Boundaries ... ... ... ... ... 24 Crossing Organization Boundaries ... ... ... ... 25 Group Definition – Review • SID = (Domain ID, Relative ID) = (D, R) • D is a globally unique ID; R is unique within D • Same format SIDs for individuals and groups. • ACL is list of SIDs; Group is a list of SIDs • Groups are defined in Active Directory™ today by: – “(D, R1) is member of (D, R2) says D” 26 Extended Group Definition • SID = (D, R), as before • D is a globally unique ID or a public key • Group membership is defined by: – “(D1, R1) is a member of (D2, R2) says D2” • When Ds differ, we express the red links from that graph. – The administrator of D2 has the responsibility for making or deleting that definition. – If D2 is a public key, then “says D2” is a digital signature and this group membership statement can be a certificate or SAML token. 27 Extensions • With just what we’ve presented so far, we get what we need most – efficient and secure groups, roles and attributes across organization boundaries, without anything special for federation. • However, there are other extensions that are easy to provide in this scheme: – Attribute-value pairs – Root stores, cross-certification and bridges – Group definition expressions with , , , etc. 28 Attribute, Value Pairs • Giving a user an attribute A and value V makes her a member of a group of all users who have attribute A and value V. • Like all other names, A should be a SID: (D, R) • So, generalize the SID – From (D, R) – To (D, R, V) which stands for (A, V) = ((D, R), V) • We can say, for example: – “(KS) is a member of (KCA, Eva) says KCA” – “(KCA, Eva) is a member of (K1, Age, 15) says K1” – “((K1, Age) < 21) is a member of (K2, Minor) says K2” – This user’s SIDs include: (KS), (KCA, Eva), (K1,Age,15),(K2,Minor) 29 Notation Summary • Use “” to mean “is a member of” • Let (D, R) mean (D, R, *) • Let (D) mean (D, *) • D can be a public key, so we can write: – (K, R, V) – (K, R) – (K) • “(KS)(KDoD, Clearance, SECRET) says KDoD” 30 Root Stores and Bridge CAs • X.509 gives us “(KS)(KCA,DN) says KCA” • But, we don’t define groups with: – “(KCA, DN)(D, R) says D” • Instead, we say: – “DN(D, R) says D” • To capture this behavior in our notation, we have to create the symbol  and say: – “(, DN)(D, R) says D” – where  means “some K in the local root store or descended from the store by a chain of CA certificates or cross-certificates” • This introduces vulnerabilities (cf., the Comodo RA attack) but matches current practice. 31 Group Definition Expressions • Groups defined as above are of the form: – Group = SID1  SID2  SID3  …  SIDN • Groups can be defined by other expressions: –  as well as  – “(K1, R1)  (K2, R2)  (K3, R3) says K3” 32 Good News, Bad News • The good news is that none of this (except possibly group definition expressions) requires anything new in protocols or over-the-wire data structures. – Claims-based IDPs should be able to handle all this. • The bad news is that none of this is achievable merely by defining a new protocol or wire data structure. • This requires changes inside an OS, file server or PDP. 33 Not covered in these slides (for time) but the designs exist • Level of Assurance – Applied at each node and edge in the graph – Carried by an attribute for use in access decisions • Human readable names • Human interface tools • Certificate chain discovery • Authorization decision logic – We’re just providing the material for that decision. 34 Feedback and Discussion Welcome Send any comments or questions to: – cme@panix.com and/or – cme@acm.org (sometimes drops mail) 35 NIST Update: Part Deux Elaine Newton, PhD NIST elaine.newton@nist.gov Outlook for Identity Management • WH Initiative on the National Strategy for Trusted Identities in Cyberspace (NSTIC) – Aims to improve the security of online transactions of consumers (e.g. online banking) • Remote access for more services, available anytime, anywhere • Risk-based choices of factors and methods • Open standards, interoperable platforms Multi-Factor Authentication (MFA) Initiative • Supported by the Comprehensive National Cybersecurity Initiative (CNCI) – Objective: To improve cyber security through strengthening authentication assurance by • Advancing multi-factor authentication • Shifting the predominance of the username- password paradigm for online transactions • Addressing major gaps for remote authentication for higher risk online transactions Authentication Use Case Comparison For law enforcement, immigration, For online transactions, e.g. etc. banking, health, etc. • Enrollment and • Enrollment subsequent recognition – Less controlled – Probably not in person attempts – highly controlled • Subsequent recognition attempts – Supervised / Attended – Unattended • Successful recognition • Successful recognition – Answers the question, – Answers the question, “How “Has this person been confident am I that this is the previously encountered?” actual claimant?” – Is a unique pattern – Is a tamper-proof rendering of a distinctive pattern Biometric Template Protection (1 of 3) • EU funded a 3 year project known as TURBINE (TrUsted Revocable Biometric IdeNtitiEs) – “To develop an innovative, privacy enhancing technology solution for electronic identity (eID) authentication through fingerprints biometrics, and – “To demonstrate the performance and security of this solution…” http://www.turbine-project.eu/ 5 Biometric Template Protection (2 of 3) • Testing will need to address – Scale for intended applications and – Metrics to evaluate algorithms Security Strength incorporating both the security (bits) properties and accuracy • Biometric Performance • De-Identification • Irreversibility ate Tru n R e • Others o ) Mat a ti M R ch R if ic x F (at 10 -x ate nt - d e t 10 FMR -I a ) De M R N (F 6 Biometric Template Protection (3 of 3) • Testing will need to address Fingerprint databases at – Scale for intended NIST are the largest and applications and can provide scale.  NIST funding biometric and – Metrics to evaluate security experts to develop algorithms metrics, using a NIST Twiki incorporating both the to engage the security and security biometric communities. properties and • Metrics will be used to develop testing protocol accuracy 7 Anti-Spoofing/Liveness Detection Standards Project Threats/ Counter- Data / Data Attacks measures Formats (for Metrics) High Confidence in factors QPL, available to Validation, Measurement/E consumers for or valuation authentication Certification (and access) Program over open networks Credential Revocation • No standard methods to revoke an Identity Provider (IdP)s’ issued credential or its associated attribute(s). – > Investigating techniques for credential and attribute revocation. – >Defining use cases and profiles for revocation. • Lead/PoC: Hildy Ferraiolo (NIST) hferraio@nist.gov, 1-301-975-6972 MFA Biometrics Projects Summary • Metrics for a Benchmarking-Framework to Rank Biometric Template Protection Algorithms (starting FY11) • Anti-Spoofing/Liveness Detection (starting FY11) – Evaluation approaches for fingerprint recognition systems – Leading international standard project in ISO/IEC (SC 37) • Credential Revocation (starting FY11) • Drafting guidelines and requirements for the use of biometrics as a second factor for remote authentication • On-Card-Comparison Testing – Final report available at http://biometrics.nist.gov/cs_links/minex/minexII/minex_report.pdf • Standards and reference implementation for web services (Draft 1 available at bws.nist.gov) Thank you Questions? Elaine Newton, PhD elaine.newton@nist.gov 1-301-975-2532 A Quick Tour of the FIPS 201 Revision William I. MacGregor NIST ITL Computer Security Division william.macgregor@nist.gov NIST, Gaithersburg 7Apr2011 HSPD-12 Implementation • First the eggs, then the chickens… – PIV Cards are the eggs – Applications are the chickens • How many eggs? Roughly, – 4.6M PIV Cards issued to employees (80%) – 1.6M PIV Cards issued to contractors (30%) • Now it’s time for chickens… – “Federal Identity Credentialing and Access Management (FICAM) Roadmap and Implementation Guidance” – Part A: ICAM Segment Architecture completed Sep2009 – Part B: Implementation Guidance work-in-progress Useful URLs • http://www.whitehouse.gov/omb/e-gov/hspd12_reports/ - OMB quarterlies • http://csrc.nist.gov/groups/SNS/piv/standards.html - FIPS 201 & NIST pubs • http://www.idmanagement.gov/ - ICAMSC & GSA ID management resources • http://www.idmanagement.gov/drilldown.cfm?action=hspd12_faqs - FAQs • http://fips201ep.cio.gov/ - HSPD-12 Evaluation Program (APL) • http://www.nist.gov/itl/iad/ - NIST biometrics resources • http://www.whitehouse.gov/omb/memoranda_default/ - OMB Memoranda • There are now dozens of OMB Memoranda, NIST publications, CIO Council publications, Federal PKI Policy Authority publications, GSA documents, OPM documents, and others relevant to HSPD-12. • And, of course, OMB M-11-11. The Larger Context • Built on DoD Common Access Card experience. • Enhanced to scale US Government-wide: – Simple, self-contained app, with assurance processes. – Authenticate, Encrypt/Decrypt, Sign/Verify. – Defined issuance processes, limited crypto capabilities. • Expanding to other communities: – PIV Interoperable (PIV-I) Cards issued by Non-Federal Issuers. – PIV-I uses same blank card stock as PIV. – The Federal Bridge unifies the trust model for all participants. • After five years, new requirements are being heard! The Revision of FIPS 201-1 • NIST was obligated to consider the need for revision of FIPS 201 five years after publication (i.e., in 2010). • NIST determined that FIPS 201-1 should be revised, and prepared Draft FIPS 201-2. • The revision was announced in the Federal Register on 8Mar2011. • On the same day, Draft FIPS 201-2 was available on the NIST website for a 90 day public comment period. The Revision of FIPS 201-1 • 2010: NIST studied the need for revision • 8Mar2011: revision was launched • See the launch announcement – http://csrc.nist.gov/news_events/index.html#mar8 – Leads to Draft FIPS 201-2 (clean & diff) – Also Federal Register Notice (a handy index) • Workshop at NIST on 18-19Apr2011 – Attend in person, registration fee $160 – Watch & listen via webcast, free • Comments must be received by 6Jun2011 Selected Changes Proposed 1. Make card lifecycle management more efficient • Synchronize card, cert, and biometric data lifetimes • Allow biometric reconnect to identity chain-of-trust • Add additional biometric modality, iris • Allow all newly-issued cards to have max lifetime • Replace NACI Indicator with online status check (cond) 2. Remove ambiguity in implementation of PKI • Make asymmetric CAK mandatory, symmetric optional • Make signature verification and PDVAL mandatory 3. Introduce New Functional Capabilities • On Card Comparison for card activation & authentication • Improve adaptability and resilience of readers • Secure Sessions from reader or application to PIV Card • Trust Anchors for readers or applications NIST is often asked…  Shouldn’t smartphones, USB tokens, tablets, and form factors be supported?  If mutually authenticated secure sessions are added, what are the End Entities?  Could authentication mechanisms become location- aware?  Shouldn’t the credential protect the user against unnecessary disclosure of sensitive information? Multi-Factor Authentication and Higher LOA Issues 10th Symposium on Identity and Trust on the Internet Paul Donfried CTO – IAM Universal Identity Services April 7, 2011 Confidential and proprietary material for authorized Verizon personnel only. Use, disclosure or distribution of this material is not permitted to any unauthorized persons or third parties except by written agreement. 1 Remember when we were young… 2 Operators  Skype 3 A new wave of disruptive technology is transforming the dynamics of global business Cloud Delivery Models Borderless Security Global Competition Network Bandwidth and Reach Device Changing Workforce Proliferation Expectations 4 Our vision is to empower individuals with seamless and secure access “I“I need need better better tools tools for for A New Mobile Mindset managing managing my my digital digital personals personals “My “My local local government government andand and and profiles—not profiles—not just just Facebook Facebook healthcare healthcare providers providers are are too too but but retail, retail, bank, bank, and and travel travel slow and inaccessible. slow and inaccessible. accounts. accounts. There There are are too too many many forms forms II want want value based value based relationships relationships and redundancies” and redundancies” with with loyalty loyalty programs” programs” “I“I want want my my profile profile to to be be “To “To stay stay connected connected II need need useable useable acrossacross the the brands brands the ability to move from the ability to move from and and relationships relationships II value. value. II work work toto my my personal personal life life want want themthem to to value value meme and and without without worrying worrying about about only only send send relevant relevant rewards rewards which which password to use” password to use” or or incentives” incentives” Consumer Citizen Community Patient Friend Employee Family Colleague Seamless and secure access to anyone, anywhere on any device 5 Giving power to your end users leads to customer insights, context and repeat business A New Mobile Mindset A better experience based on: Convenience, Freedom, Control and Assurance Consumer Citizen Community Patient Friend Employee Family Colleague UIS Market Facing Services Identity Form Factors Open Open People Services You Need Relying Parties (Verizon & 3rd Party Issued) Standards Standards Info Cards/Open ID Microsoft® Work Login Active Directory® Identity Issuance LDAP Services WS-Trust X.509 LDAP Healthcare SMS OTP OIX RADIUS Authentication SAML Gateway Federation Shopping OATH RADIUS Kerberos Shibboleth X.509/OCSP Banking Risk Services 7 We need an identity ecosystem in the cloud. UIS Profile Management Scale Consumer Value • Improved user experience • Reduced identity risk • Reduced fraud • More control 2011 2012 2013 UID Users 100 million 200 million Discussion © 2011 Verizon. All Rights Reserved. PTE14912 02/11 Digital Signatures: Current Barriers Simson L. Garfinkel Associate Professor, Naval Postgraduate School April 7, 2011 http://simson.net/ 1 NPS is the Navyʼs Research University. Location: " Monterey, CA [& Arlington, VA] Campus Size: "627 acres Students: 1500 ■ US Military (All 5 services) ■ US Civilian (Scholarship for Service & SMART) ■ Foreign Military (30 countries) ■ All students are fully funded Schools: ■ Business & Public Policy ■ Engineering & Applied Sciences ■ Operational & Information Sciences ■ International Graduate Studies 2 Personal Opinion Disclaimer This document was prepared as a service to the DoD community. Neither the United States Government nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government, and shall not be used for advertising or product endorsement purposes. 3 Enhancing mail security with digitally signed mail. April 2011: Epsilon Data Management LLC announces millions of customer email addresses stolen. Epsilon provides email services for: ■ Chase ■ Capital One ■ Citibank ■ etc. If email from banks was digitally signed: ■ The hacker would have gotten the private key. ■ The private key would then be invalidated. ■ Anti-spam systems would reject mail signed with invalidated key. 5 Why donʼt banks sign their mail? From 2003 to 2006, I met with 5 banks to find out why. “No other banks sign their mail.” “Email is a marketing function.” “We use digital signatures internally, but federal regulations prohibit sending signed mail to our customers.” “Most of our customers use web mail, and web mail doesnʼt work with digital signatures.” “Nobody has PGP.” 6 Public key cryptography was invented nearly 30 years ago to secure electronic mail. Since then we have spent a lot of effort on this issue. 1976 – Public Key Cryptography (Diffie & Hellman) 1977 – RSA Encryption (Rivest, Shamir & Adelman) 1978 – Certificates (Kornfelder) 1987 – Privacy Enhanced Mail 1992 – PGP 1998 – S/MIME 2005 – Domain Keys 2009 – National Strategy for Trusted Identities in Cyberspace 7 By 1999 there were two email security standards: PGP and S/MIME Support for S/MIME was built into every mainstream mail client: ■ Outlook Express S/MIME is built into many modern email programs. ■ Outlook ■ Mozilla Thunderbird ■ Evolution ■ Apple Mail S/MIME support in Outlook Express, circa 2001 Just click “sign” to sign and “encrypt” to seal. PGP requires a plug-in 7 8 #1 problem with S/MIME: Two-Party Agreement Encrypted mail: ■ Recipient must have a certificate ■ Sender must get recipient's certificate Sending signed mail: ■ Sender must have a certificate. Replying to signed mail: ■ Recipient-come-sender must have a certificate: But no certificate is required to receive digitally signed mail... 9 My goal: digital signatures for do-not-reply email Lots of companies send “do-not-reply” email: You can either ignore it, or click the links. 10 Much (most?) of the mail that Epsilon sent is do-not-reply mail “If you want to contact Chase, please do not reply to this message, but instead go to www.chase.com/creditcards.” 11 Outline of this talk Digital signatures today ■ Good news! ■ Not-so-good news. DRAFT National Strategy for Trusted Identities in Cyberspace June 25, 2010 ■ Really bad news. • An Accreditation Authority assesses and validates that identity providers, attribute providers, relying parties, and identity media adhere to an agreed upon Trust Framework. • A Trust Framework defines the rights and responsibilities of a particular set of participants in the Identity Ecosystem; specifies the rules that govern their participation; and outlines the processes and procedures that provide assurance. A Trust Framework considers the level of risk associated with a given transaction and its participants. Many different Trust Frameworks can exist within the Identity Ecosystem, as sets of participants can tailor them to their particular needs. However, the participants must align the Trust Frameworks with the overall Identity Ecosystem Framework. The combination of these participants, and the standards and agreements among them, form the trust fabric that makes the Identity Ecosystem possible. The following sections provide a functional example of online transactions that take advantage of the Identity Ecosystem. The example Theories regarding the use of digital signatures. addresses each layer of the Identity Ecosystem and demonstrates the benefits associated with adoption, such as: • Availability of new and innovative services, • Credential acceptance and trust among diverse industries and governments, • Privacy enhancement, • Process efficiency, and • International applicability. This example is not an endorsement of specific technologies or processes; rather, it is intended to articulate one of the many possibilities. Part 1: Execution Layer The Execution Layer is the place where individuals, organizations and NPEs come together to interact in online transactions following established rules. !"#$#%&'()* Suggestions for moving forward. As shown in Figure 1, an individual can +#)#,&* make informed choices about which relying parties to trust aided by the trustmark they hold. When the individual accesses the online services of the 2("$3("#4(%$4 relying party, the relying party may ask 0%$'1'$/()* +56&3("# her to present a credential and attributes to support authorization of the individual’s 00101100 requested action. The relying party can 11010010 -&&"'./&#* request verification of the credential’s 7"8(%'9(&'5%* :(&( validity and the associated digital identity of the individual from a certified identity provider; and validated attribute assertions from certified attribute providers. The user can also provide all validations directly to the relying party ;"'1(,<4 through the mediation of privacy- ;5)',< enhancing technology. Attribute providers may supply attribute values (for example, birth date is March 31, 1974) or Figure 1: Execution Layer attribute claims (for example, individual is 14 12 Good News! Good news about digital signatures! I get signed email messages every day from DoD employers using Microsoft Outlook Apple Mail can verify the signatures 14 Good news about digital signatures! I get signed email messages every day: It even works in Microsoft Outlook Webmail: 15 DoD has issued every employee & warfighter a “CAC” (Common Access Card). HSPD-12 compliant ■ Email Encryption key (with key escrow) ■ Email Signing key ■ Identity Key Widely used today for: ■ Identity badge at DoD facilities. ■ Email signing & encryption ■ Access to websites. ■ etc. 16 CAC interoperates with Apple Mail 17 Defense Travel System (DTS) uses CAC for authentication. 18 DD1351-2 is a standard form for travel reimbursement. Read Privacy Act Statement, Penalty Statement, and Instructions on back before TRAVEL VOUCHER OR SUBVOUCHER completing form. Use typewriter, ink, or ball point pen. PRESS HARD. DO NOT use pencil. If more space is needed, continue in remarks. 1. PAYMENT SPLIT DISBURSEMENT: The Paying Office will pay directly to the Government Travel Charge Card (GTCC) contractor the portion of your reimbursement representing travel charges for transportation, lodging, and rental car if you are a civilian employee, unless you elect a different amount. Military personnel are required Electronic Fund to designate a payment that equals the total of their outstanding government travel card balance to the GTCC contractor. Transfer (EFT) Payment by Check Pay the following amount of this reimbursement directly to the Government Travel Charge Card contractor: $ 2. NAME (Last, First, Middle Initial) (Print or type) 3. GRADE 4. SSN 5. TYPE OF PAYMENT (X as applicable) TDY Member/Employee 6. ADDRESS. a. NUMBER AND STREET b. CITY c. STATE d. ZIP CODE PCS Other Dependent(s) DLA e. E-MAIL ADDRESS 10. FOR D.O. USE ONLY 7. DAYTIME TELEPHONE NUMBER & 8. TRAVEL ORDER/AUTHORIZATION 9. PREVIOUS GOVERNMENT PAYMENTS/ a. D.O. VOUCHER NUMBER AREA CODE NUMBER ADVANCES 11. ORGANIZATION AND STATION b. SUBVOUCHER NUMBER 12. DEPENDENT(S) (X and complete as applicable) 13. DEPENDENTS' ADDRESS ON RECEIPT OF c. PAID BY ORDERS (Include Zip Code) ACCOMPANIED UNACCOMPANIED a. NAME (Last, First, Middle Initial) b. RELATIONSHIP c. DATE OF BIRTH OR MARRIAGE 14. HAVE HOUSEHOLD GOODS BEEN SHIPPED? d. COMPUTATIONS (X one) YES NO (Explain in Remarks) 15. ITINERARY c. d. MEANS/ REASON e. f. a. DATE b. PLACE (Home, Office, Base, Activity, City and State; MODE OF FOR LODGING POC City and Country, etc.) TRAVEL STOP COST MILES DEP ARR DEP ARR DEP ARR DEP ARR DEP ARR DEP e. SUMMARY OF PAYMENT ARR (1) Per Diem DEP (2) Actual Expense Allowance ARR (3) Mileage 16. POC TRAVEL (X one) OWN/OPERATE PASSENGER 17. DURATION OF TRAVEL (4) Dependent Travel 18. REIMBURSABLE EXPENSES (5) DLA 12 HOURS OR LESS a. DATE b. NATURE OF EXPENSE c. AMOUNT d. ALLOWED (6) Reimbursable Expenses (7) Total MORE THAN 12 HOURS BUT 24 HOURS OR LESS (8) Less Advance (9) Amount Owed MORE THAN 24 HOURS (10) Amount Due 19. GOVERNMENT/DEDUCTIBLE MEALS a. DATE b. NO. OF MEALS a. DATE b. NO. OF MEALS 20.a. CLAIMANT SIGNATURE b. DATE c. REVIEWER'S PRINTED NAME d. REVIEWER SIGNATURE e. TELEPHONE NUMBER f. DATE 21.a. APPROVING OFFICIAL'S PRINTED NAME b. SIGNATURE c. TELEPHONE NUMBER d. DATE 22. ACCOUNTING CLASSIFICATION 23. COLLECTION DATA 24. COMPUTED BY 25. AUDITED BY 26. TRAVEL ORDER/ 27. RECEIVED (Payee Signature and Date or Check No.) 28. AMOUNT PAID AUTHORIZATION POSTED BY DD FORM 1351-2, MAR 2008 PREVIOUS EDITION MAY BE USED UNTIL SUPPLY IS EXHAUSTED. Exception to SF 1012 approved byGSA/IRMS 12-91. Adobe Designer 7.0 19 I signed my DD1351-2 “Travel Voucher or Subvoucher” on my MAC with a CAC and Adobe Acrobat. 20 Not-so-good news DoDʼs CA isnʼt part of Acrobat Reader DoD has taught people to ignore signature warnings. 22 Actually, DoD CAʼs arenʼt part of any standard software. DoD may have largest PKI deployment on the planet. ■ 3 million employees with CACs. ■ Millions of contractors But DoD requires that root CAʼs be installed: ■ On every fresh operating system install ■ On home machines ■ On public machines used to contact DoD systems. DoD could: ■ Get roots installed in IE & Firefox ■ Cross-certify with VeriSign “bridge.” 23 DTS isnʼt 100% compatible with MacOS Firefox on Macintosh allows you to create travel orders, but not sign. This is pretty weird... 24 Most signed messages are valid on Windows but not on Mac due to disagreements over S/MIME standard. Original problem: Common Name vs. RFC 822 Name Figure 2. DoD CAC Certificate Figure 4. Apple Mail Digital Signature Error Because the DoD does not put the sender’s email address Figure 3. DOD Email Certificate (RFC 822 Name) in the certificate “Common Name” field, and Apple Mail didn’t check for an email address in the “RFC 822 Name” Current problem: slgarfin@nps.edu field, != SLGarfin@nps.edu the MUA alerted the email recipient that the This difference will produce the following results in signature cannot be verified. Apple Mail: 25 Mailing lists corrupt digital signatures 26 Really bad problems To date, we have been unable to get a DoD certificate to sign do-not-reply email. “Role-Based Certificates” would seem to be the ideal mechanism. ... But DoDʼs policy requires that private keys be held by a person, not a program. ■ Paperwork assumes that a person is sending out the mail. ■ Not clear who the responsible party is! —The programmer? —The person running the program? —The system manager? This makes no sense! ■ We issue SSL certificates to websites (e.g. https://webmail.nps.edu) ■ Has put deployment plans on hold. 28 PGP Confusion S/MIME clients are widely deployed, but... ■ Security “thought leaders” continue to use PGP. ■ Code distributions are signed with PGP. We have now conclusively shown that... ■ PGP’s “Web of Trust” doesn’t scale. ■ PGP’s model doesn’t work against most adversaries. Nevertheless... ■ People like making their own keys. ■ Even “free” S/MIME keys are too hard to get. 29 OpenSSL and Bouncy Castle We have complete S/MIME implementations in C and Java. ■ OpenSSL ■ Bouncy Castle These systems are dramatically harder to use than PGP/GPG 30 Gmail, Hotmail & Yahoo Mail: no support for S/MIME. 31 Domain keys didnʼt help with the Epsilon hack. BEFORE HACK AFTER HACK 32 Theories regarding the use of digital signatures. Usability is the #1 barrier to use. People will use it if there is no cost and no time commitment. People use PKI with: ■ SSL (bad example) ■ Skype ■ Apple iChat 34 There is widespread ignorance regarding the technology. Decision makers largely do not understand: ■ What digital signatures do. ■ Why they should be used. Technologies largely do not understand: ■ The differences between: —S/MIME —PGP —DomainKeys ■ How to choose between the technical alternatives. ■ How to choose a vendor / software package / ideology. ■ How to get certificates. Nobody is sure: ■ Who are the customers and who are the users. ■ The necessity of deploying a technology before it’s used. 35 cution Layer n Layer is the place where rganizations and NPEs er to interact in online following established rules. !"#$#%&'()* Figure 1, an individual can +#)#,&* ed choices about which s to trust aided by the y hold. When the individual online services of the 2("$3("#4(%$4 the relying party may ask 0%$'1'$/()* +56&3("# t a credential and attributes thorization of the individual’s 00101100 tion. The relying party can 11010010 -&&"'./&#* cation of the credential’s 7"8(%'9(&'5%* :(&( he associated digital identity ual from a certified identity validated attribute om certified attribute he user can also provide all rectly to the relying party ;"'1(,<4 mediation of privacy- ;5)',< chnology. Attribute y supply attribute values (for h date is March 31, 1974) or Figure 1: Execution Layer ms (for example, individual is 14 Suggestions for moving forward... Recommendation: Deploy and and mandate for senders. USG must demand that vendors use PKI. ■ Require that email sent to USG employees be digitally signed. —Mandate both S/MIME and DomainKeys ■ Accept HSPD-12 cards for authentication. ■ Don’t let vendors issue usernames & passwords. DOD should get its certificates in browsers ■ Microsoft; Mozilla Firefox; Apple; Android; Blackberry Secure email plans should emphasize signatures, not encryption. ■ Phishing and spam are the major risks. ■ Email interception is a relative rare occurrence. “If youʼve got them by the email, inbox their hearts and minds will follow.” —Not quite John Wayne Questions? 37 The Application and the Ecosystem Acknowledgments • https://spaces.internet2.edu/display/fedap p/Home and Scott Cantor kjk@internet2.edu Federating Applications • What are the issues apps are finding in adapting to a federated world? • What issues will they need to learn about in an attribute ecosystem • Sooner • Later kjk@internet2.edu Federated Applications – The Core Issue • We are still treating federation as an afterthought when this design would improve all web applications. • The core problem is application developers still think their application must reimplement common business logic better resolved elsewhere – its not just passwords we should externalize. kjk@internet2.edu Topics Areas Being Worked on Today kjk@internet2.edu Applications and Federated Life - Today • IdP discovery • User Identification • Session Management • The Boarding Process • Interfederation kjk@internet2.edu IdP Discovery – The Problem Space • Federation creates the IdP discovery problem – where do you send them to authenticate? • In federations, we cannot expose user credentials to authentication systems controlled by unrelated organizations. • As a result, the authentication source has to be selected before credentials are supplied, either explicitly through user choice, or by deriving something from a user identifier. • Need better coordination amongst providers before this becomes too complex for users. kjk@internet2.edu IdP Discovery Models Models • SP/Embedded – e.g .Elsevier • Centralized/Shared • SP-centric - e.g. NIH Federated Login gateway vs. federation/IdP centrice.g. WAYF, InCommon •Common UI "trigger" for consistency kjk@internet2.edu IdP Discovery Work Arounds • Workarounds • Initiating at the IdP – e.g. PSU gets to NIH through the PSU research web site. • Hand out Per-IdP URLs (e.g. Google) • Shared hints • Limiting discovery to expected IdPs • Geolocation kjk@internet2.edu GeoLocation Hints - EDUCAUSE kjk@internet2.edu Oasis Work on Discovery kjk@internet2.edu Web Authentication – Problem Space • Web authentication involves proving the identity of a client and server to each Invokes lots of issues when externalized • Discovery • Authentication attributes & practices • Error Handling • Logout • Timers kjk@internet2.edu Non-Web Authentication – Problem Space • Authentication for non-web • TLS • OTP over TLS • SASL / GSS-API • Project Moonshot • Tie to web authentication – iTunes example. kjk@internet2.edu Project MoonShot –project-moonshot.org kjk@internet2.edu Identity Assurance – Problem Statement • Does 800-63 assurance levels adequately reflect good risk abatement techniques in a federated world, especially outside gov. • If not, is there anything better to use? • Transitive trust arrangements • LOA over time • Self-service password resets kjk@internet2.edu The Next Round of Application Issues • Logout • Provisioning and Deprovisioning • Metadata exchange - uApprove • Account Linking – transitive trust • Identity Assurance from the app view • Error handling • Federated Security Incident Handling kjk@internet2.edu Acknowledgments • https://spaces.internet2.edu/display/fedapp/ Home and Scott Cantor kjk@internet2.edu Attributes Debbie Bucci National Institutes of Health NIH Person • Staff tracking initiative 2009 common bio sketch • EA to investigate common attributes/data values across systems and sources – Clinicaltrials.gov – iEdison – My bibliography – NSF/USDA/NIH – FDP work – AAMC – multi affiliations • NIH External Researcher Conceptual Data Model – June 2010 • ARRA funding – need to track investments across government • Starting the work all over again – common biosketch across the government 2 • Attribute Tiger team Input for various initiatives • Competing interest – What is the scope? • Authentication/authorization/entitlements? • G2G, B2G, C2G • 3 submissions – external to government • Additional input from DHS/DOD Tiger Team • Lead to 12 other sources • Common concerns – Name – PII/Biographic – Contact (Emergency, employer, technical, support, adminstrative, supervisor, business, home) – Clearance – IDP, AP – Organization – Employment 3 The Attribute and the ecosystem Topics • Basics • Common Schema • LOA of attributes • Privacy • Naming • Complexity and Extensibility • Tagging • Complexity vs Metadata • IdP releasing vs SP asking • Query languages • Dealing with Aggregation kjk@internet2.edu Killer Attributes (and the applications that love them) • Human readable identifiers • Email address, eppn, display name, etc • Opaque identifiers • ePTID • Affiliation • Citizenship • Over legal age kjk@internet2.edu Types of attributes • Institutional • Organizational • Reassertion of Official attributes • Temporal – geolocation, etc. • Community or collaboration asserted • Formal – Virtual organizations, groups • Informal – reputation systems, FoF • Self-asserted kjk@internet2.edu Common Schema • NIEM – National Information Exchange Model – www.niem.gov • eduPerson -http://middleware.internet2.edu/eduperson/ • http://www.terena.org/activities/tf-emc2/schac.html • Accessability schema - http://www.w3.org/WAI/ and http://www.w3.org/WAI/intro/uaag.php • http://doc.esd.org.uk/IPSV/2.00.html kjk@internet2.edu Eve Maler’s Attribute Assurance Matrix kjk@internet2.edu Naming • Oids vs URNs vs URLs vs URI’s vs • Registering name spaces kjk@internet2.edu Privacy • Which attributes are PII? • ePTID – opaque, non-correlating, but 1-1 • IP address • Which jurisdiction applies? • IdP? SP? Nationality of user? • Which require consent and for what purpose? kjk@internet2.edu Authorization – Problem Statement • In a federated landscape, with scale in mind, groups more than identities control access • But attributes may express, in addition or instead, a user's relationship with the authenticating organization, membership in groups, or possession of roles or entitlements that signify permission to access application resources. In such cases, authorization may be delegated or distributed to the authenticating organization, or even across additional organizations. This is a relatively common pattern when the authorization policy is simple (typically all or nothing) and applies to large numbers of users at multiple organizations. It is less common as policies become more complex and fine-grained. kjk@internet2.edu Groups • Local Groups • User Identification • Provisioning (and Deprovisioning) • Representation • isMemberOf • eduPersonEntitlement • Groups with Federated Members • Federated Groups • Privacy Implications • Visibility of members to other members • Sharing groups across services kjk@internet2.edu Of Entitlements and Attributes • In entitlements, SP community passes business logic to IdP’s, who compute authorization and pass entitlement • To scale, must have common license terms • SP’s need to be willing to expose business logic • In attributes, IdP’s pass attributes to SP for authorization • Raises privacy issues • To scale, must have shared community attributes kjk@internet2.edu Some key issues • Which schema • Knowing which IdP to ask for which attributes, especially as we get into aggregation • How to ask, e.g. over 18 • Making values extensible, so that they can be tagged, like validation, date, terms of use kjk@internet2.edu Attribute Release • SP Asking vs. IdP Releasing • Specifying requirements (queries, metadata, policy files, web pages, etc.) • Consent kjk@internet2.edu Attribute aggregation • At the IdP • Already doing internal aggregation • Can arrange bulk feeds – e.g. IEEE member • At the SP • Already in the Shib code • At an intermediate point • Portals and gateways do this now • Can greatly simplify trust kjk@internet2.edu “Over legal age” • Use cases are legion and confusing • Legal age of the web site country • Legal age of the IdP country • Legal age of the identity holder’s country • Authoritative sources and delegation • Query languages kjk@internet2.edu Complexity and Extensibility • Complexity • Tagging within attribute vs use of metadata vs context • Extensibility • The ability to add new controlled values • How much flat attribute proliferation can be managed through a structured data space? • DRM of metadata kjk@internet2.edu Principles of the Tao 属性之道 • Least privilege/minimal release • Using data “closest” to source of authority • Late and dynamic bindings where possible • Dynamic identity data increases in value the shorter the exposure. If identity data is cached away from the source there is increased likelihood of staleness and over- exposure which can lead to privacy and data accuracy concerns. 17 kjk@internet2.edu Beyond the first horizon • LOA of attributes • Specifying semantic rules • Shifting from attribute values as text strings to rich signed data • Terms of use • Time limits • etc kjk@internet2.edu Thanks Program Committee Abbie Barbir Richard Wilsher Trent Adams Sara Caswell Peter Alterman Kent Seamons David Chadwick Jon Solworth Elaine Newton Stephen Whitlock Ken Klingenstein Tom Greco Neal McBurnett Tony Nadalin Radia Perlman Von Welch Special Thanks •Sara Caswell • Peter Alterman • Neal McBurnett • Elaine Newton • Ken Klingenstein