Smart Card Industry Panel: Delivering PIV compliant products

1. Smart Card Industry Panel:Delivering PIV compliant products HSPD 12 Workshop May 5, 2005 Washington, DC

2. Moderator: Randy Vanderhoof, SCA Industry Panel: Gilles Lisimaque, Partner ID Technology Partners, Inc. GLisimaque@idtp.com Phone: 301-320-5146 Stephen P. Howard, Partner ID Technology Partners SteveHoward@idtp.com 703.319.3171 Dwayne M. Pfeiffer, CISSP Northrop Grumman Corp dwayne.pfeiffer@ngc.com 703.556.2963

3. Topics to be covered: • Standards & Smart Cards • PIV Data Model • When do I Use What in the PIV? • PIV Card and Physical Access • How can I use the PIV card in physical access control systems (PACS)?

4. Standards & Smart Cards Gilles Lisimaque ID Technology Partners GLisimaque@IDTP.com

5. In the Beginnings …. • The World of Smart Cards was formless and empty • And ISO WG4 said “let there be a standard for smart cards” and there was ISO/IEC 7816 • After the fifteen parts of the standard were finished, ISO WG4 saw this was good and handed the standard to vendors to work with it, built from it and take care of it. • And the vendors sinned and used the standard for their own selfish proprietary interests instead of sharing the good news and develop interoperability ….

6. In the Land of North America … • A new standard for smart cards (GSC-IS) was develop on the top of ISO 7816 in an attempt to restore interoperability. It provided: • Interoperable source of products (procurement) • Interoperable data models (data definition) • But it still allow applications to be on their own and did not succeed in providing interoperable applications using the various products. • Without enough guidance, and using too often the letter of the law instead of its spirit, user’s of GSC-IS developed incompatible application languages and could not built the interoperable “unified tower” their leaders dreamed about.

7. The Quest for Interoperability … • The PIV application required true interoperability for cards, systems, back ends, between systems and during issuance in order to provide true security. • A new “law” for smart cards was developed for the “land” and was called SP 800-73. • In parallel, an international effort (ISO 24727) based on GSC-IS was launched to develop a true interoperable language, all smart cards around the world (including North America) could use and be interoperable.

8. The new “Law” for Smart Cards in the US government: SP 800-73 • Scope limited to a specific application: PIV • Provides strict guidance for GSC-IS applications on how to ensure the PIV application loaded on any US government smart card will interoperate. • Protects investment of GSC-IS systems allowing them to adapt and interoperate at the card level • Provides a simple, unambiguous solution for future cards to be used in final systems (back ends, CMS, client-applications, etc.) when they become available • Developed as close as possible to the international effort (ISO 24727) to guarantee global interoperability of the card and the various elements of the systems.

9. The Heart of Interoperability • A Common Data Model with unambiguous names and owners has been developed for all PIV cards whatever technology they use (GSC-IS Transitional or SP 800-73 End-State) • Simple commands and functions are nailed down defining how to access and use the various data elements defined in the application • Instead of allowing all cards with all type of languages to be accepted by the system, a limited number of card interfaces have been defined, limiting the translation work of the middleware and the options to work from in applications

10. The Challenges Ahead • In all systems, defining the card is the easy part. • Defining the applications to use it is much more complex • Making sure all cards are issued with the required level of security is a daunting task • And finally, having back end systems from various issuers (agencies) able to cooperate in their security critical missions is a lot of headaches. Buying Cards without knowing the applications and systems they will be used in, is like buying a car without knowing if roads are available

11. Who is working on the solutions? • In order to get true interoperable solutions, some more work is required to define unambiguously the application software, the middleware layers, the issuance systems, the card management systems (if required) and the other elements of the card itself (how other applications can co-exist in the PIV card). • ISO 24727 is working on the international framework allowing to built interoperable application using smart cards. The work is moving very fast for an ISO work but is acknowledged as fundamental by all countries. • NCITS B10 is working out a bridge allowing to move from GSC-IS to SP 800-73 and later to ISO 24727

12. The delicate choice ahead • SP 800-73 allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP 800-73 proposes fixes to GSC-IS to provide enough interoperability for the PIV application. • SP 800-73 offers a new solution for cards, middleware and systems helping new applications to be developed in a better interoperable manner. • New cards will soon be available and they will have to be qualified for security and conformance. • Middleware will be developed in order to work with these new cards • New applications will take advantage of the new cards Until Compliance Tests are defined, no one knows its drawbacks and limitations

13. The delicate choice ahead • SP 800-73 allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP 800-73 proposes fixes to GSC-IS to provide enough interoperability for the PIV application. • SP 800-73 offers a new solution for cards, middleware and systems helping new applications to be developed in a better interoperable manner. • New cards will soon be available and they will have to be qualified for security and conformance. • Middleware will be developed in order to work with these new cards • New applications will take advantage of the new cards

14. PIV Data Model When do I Use What in the PIV? Stephen P. HowardID Technology PartnersSteveHoward@idtp.com

15. Structure of the Data Model

16. PIV Data Model Issuer optional Mandatory issuer controlled data

17. State’s Rights • If PIV requires it, you must do it • Mandatory for inter-agency interoperability • PIV does not restrict issuers from adding additional applications and data • Demographic information buffers • ePurse schemes • Contactless Biometrics • Contactless CCC • Contactless Security Object buffer • Mutual authentication schemes • BUT… Issuer specific apps and data are not considered interoperable across agencies • Enables appropriate, controlled testing of new capabilities • Enables consideration for future PIV extensions

18. Back-end Transactions • SP800-73 defines operational use cases • Requires back-end transactions to verify against the issuer • Not covered in this presentation • Focus here on structure and support from PIV Data Model to enable these transactions and other operational modes

19. When Do I Use What? Making Sense of it For Real Applications!

20. Registration – Where’s the stuff you need? • Credential Number • In the CHUID  FASC-N “SystemCode||CredentialNumber” –or– GUID • Employee Number • In the CHUID, buried in the FASC-N  PersonIdentifier (PI) – DoD EDI-PI • Employee Name • In the Printed Information buffer • Who is the issuer? • Two places  In the CHUID, buried in the FASC-N as Agency code & PIV Auth. Cert. • Expiration Date of Credential • Two places  CHUID Expiration Date & PIV Authentication Cert. Expiration Date

21. Registration – Where’s the stuff you need? • Issuer Integrity – Did they really put this there? • CHUID’s Issuer Asymmetric Signature and Certificate • Delivers Public key for Signature Object • Signature Object • Individually signed objects  Biometrics, Certificates • Verified signatures = Trust in issuer • Is this the real PIV chip? • Two methods  Card Authentication Key –or– PIV Authentication Key to sign a challenge • CAK proves valid card; PAK proves valid card and confirms bearer through PIN • Is this the rightful bearer of the PIV? • Use Card Holder Fingerprints for Match-to-Card biometric identification that bearer is rightful cardholder • Verified signature of fingerprints = Trust in issuer

22. Physical Access • Which credential is asking for access? • CHUID • Primarily the FASC-N fields “Agency Code||System Code||Credential Number” which are concatenated for full Credential Number • OR Global Unique ID (GUID)  next generation to replace FASC-N credential number • Who is asking for access? • Card Holder Fingerprints • Match-to-Card • Card Holder Facial Image and Printed Information • Look at the picture in the chip to confirm it matches the person • Check their name • Is this card authentic? • Verify issuer signatures  CHUID, Fingerprints • OR, single verification using Signature Object (printed info, images) • Is this the chip or a copy? • Use Card Authentication Key to challenge for a digital signature

23. Logical Access • Mandatory – PIV Authentication Key • Windows Login, Web Access, etc. • Requires pin, proving Card and Card Holder • Optional • Digital Signature  PIN Always enabling Non-Repudiation for critical applications • Key Management  PIN enabling Email encryption, session key generation • Card Authentication  No PIN required, trust card before using other services • Consistent with DoD PKI key usage

24. Summary

25. PIV is a Very Powerful Tool • Enables trust in identity of bearer of the token • Enables a range of security models • Logical/Physical • Biometrically enhanced • Integrity with issuer signatures • Enables range of transactional options depending on Facility and System/Network security requirements • Needs continued focus to assure interpretation of PIV leads to strong cross agency interoperability • Maximize its potential!

26. PIV Card and Physical Access How can I use the PIV card in physical access control systems (PACS)? Dwayne PfeifferNorthrop Grumman Corp.dwayne.pfeiffer@ngc.com

27. PIV Data Model For PACS Usage Issuer optional Mandatory issuer controlled data

28. What’s in the CHUID?

29. What’s in the CHUID? (continued) Federal Agency Smart Credential Number (FASC-N) –Part 1

30. What’s in the CHUID? (continued) Federal Agency Smart Credential Number (FASC-N) –Part 2

31. What’s in the CHUID? (continued) • Global Unique Identification Number (GUID) • Issuer assigned IPv6 number included to enable future migration away from the FASC-N into a robust numbering scheme for all issued credentials.

32. What’s in the CHUID? (continued) • Expiration Date • 8 bytes in length and encoded as YYYYMMDD. • Authentication Key Map • Defined as part of the High Assurance Profile in TIG SCEPACS v2.2 • Can be used as a proof of an authentic PIV and its bearer (when used with PIN) • Is an optional field which enables the application to discover the key reference. • A method of implementing the symmetric challenge/response protocols using the Card Authentication Key in SP800-73 • Issuer Asymmetric Signature • Is implemented as a SignedData Type, as specified in RFC 3369

33. PACS Device Requirements • PIV Card Readers • Contactless Card-to-reader interface ISO/IEC14443 • Contact Card-to-reader interface ISO/IEC 7816 • Able to read and process CHUID • Reader-to-panel/host interface is not specified (PACS specific) • Access Control Panels • Minimum be able to process FASC-N and Exp. Date • Migration to process GUID • Optionally be able to check CHUID’s issuer digital signature • PACS Host • Minimum be able to process FASC-N and Exp. Date • Migration to process GUID • Minimum at registration, be able to check CHUID’s issuer digital signature

34. PACS Options • PIN • PIN pad must be integrated with reader • Biometrics • Prior to SP800-76, local use only – not interoperable • SP800-76 will state interoperability requirements • Verify CHUID Issuer Digital Signature • Requires interface to issuer’s Certificate Authority (CA) (e.g., Certificate Revocation List (CRL) or Online Certificate Status Responder (OCSP)

35. Physical Access Council (PAC) • The Physical Access Council is the first of several new Smart Card Alliance Technology and Industry Councils • This council has been created to foster increased collaboration within the physical access control system industry and market segment and to produce tangible results • Speeding smart card adoption and industry growth.

36. PAC Steering Committee

37. PAC Members Broad cross-section of smart card and physical access control industry vendors and users Members:Accu-Time Systems, ADT Federal Systems, Anteon, BearingPoint, Bordes Group, Condortech, Corestreet, CTS, EDS, Fargo Electronics, GE, GSA, GTSI, HID Corp., Hirsch Electronics, Honeywell, IBM, ID TECH, Identicard, IDTP, Indala, Integrated Command Software, ISR Solutions, Johnson Controls, Legic, Lenel, Lockheed Martin, MartSoft, MDI, NARA, NBS Technologies, Omnikey, ORGA, Proctor & Gamble, Precise Biometrics, Raytheon, RSA Labs, SafeNet, SafLink, SAIC, SC Solutions, SECOM, Sharp, SIA, Siemens, SoftwareHouse, Sun Microsystems, SuperCom, Translore, US Dept of Justice, US Dept of Transportation/Volpe Center, US Marshal Service, Veridt, Xtec

38. Initial PAC Activity Focus • Understand U.S. Government PACS requirements • HSPD12 - Homeland Security Presidential Directive • Policy for a common identification standard • FIPS 201 - Personal Identity Verification (PIV) • for all Federal Employees and Contractors • SP800-73 - Interfaces for PIV • SP800-76 - Biometric Data Specification for PIV (draft) • Two white papers by mid-June 2005 • FIPS 201 Executive Summary (overview) • FIPS 201 Implementation Issues (technical) • Create Education tools for Smart Card usage in Physical Access Control Systems

39. Contacts Gilles Lisimaque, Partner ID Technology Partners, Inc. GLisimaque@idtp.com Phone: 301-320-5146 Stephen P. Howard, Partner ID Technology Partners SteveHoward@idtp.com 703.319.3171 Dwayne M. Pfeiffer, CISSP Northrop Grumman Corp dwayne.pfeiffer@ngc.com 703.556.2963 Contact: Randy Vanderhoof 1-800-556-6828 rvanderhoof@smartcardalliance.org www.smartcardalliance.org