HSPD 12 Workshop

1
Smart Card Industry PanelDelivering 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_at_idtp.com
• Phone [phone]
• Stephen P. Howard, Partner
• ID Technology Partners
• SteveHoward_at_idtp.com
• 703.319.3171
• Dwayne M. Pfeiffer, CISSP
• Northrop Grumman Corp
• dwayne.pfeiffer_at_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_at_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, users
  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
FIPS 140 SCA Working Group Company Working Group
Members

• Gemplus
• IBM
• ID Technology Partners
• Infogard
• Litronic
• Lockheed Martin
• MartSoft
• MasterCard
• Mobile Mind
• NIST
• Oberthur
• Philips
• Raak Technologies

• ActivCard
• Atlan Labs
• Atmel
• Axalto
• Cygnacom
• Department of Defense
• Dept. of Transportation/TWIC
• DMDC
• Dreifus
• GD

15
The Goal of a Common Platform

• The goal of the group is to define a common card
  platform allowing to establish a reference for
  applet developers
• Would allow OS and Card manufacturers to keep the
  qualification of a FIPS 140 qualified platform
  when new qualified application functions
  (applets) are added.
• Would allow application developers to have their
  applet FIPS 140 certified only once on any FIPS
  140 qualified platform and keep this
  certification when used on another FIPS certified
  card platform

16
FIPS 201 PIV applications benefits from a FIPS
140 common card platform

• Faster qualification
• Better interoperability
• Lower costs

Smart Card Alliance FISP 140 Working Group
17
Thank you

• Gilles Lisimaque
• Partner
• ID Technology Partners, Inc.
• 316-B Cross Green Street
• Gaithersburg, MD 20878
• Phone [phone]
• GLisimaque_at_idtp.com
• WEB www.idtp.com

18
PIV Data Model

• When do I Use What in the PIV?
• Stephen P. HowardID Technology
  PartnersSteveHoward_at_idtp.com

19
Structure of the Data Model
20
PIV Data Model
Buffer Description Interface Available Access Rule
Card Capabilities Container Contact Always Read
Card Holder Unique ID Contact and Contactless Always Read
X.509 for PIV Authentication Contact PIN
Card Holder Fingerprint I Contact PIN
Card Holder Fingerprint II Contact PIN
Printed Information Contact PIN
Card Holder Facial Image Contact PIN
X.509 for Digital Signature Contact PIN Always
X.509 for Key Management Contact PIN
X.509 for Card Authentication Contact and Contactless Always
Security Object Contact Always Read
Mandatory issuer controlled data
Issuer optional
21
States 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

22
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

23
When Do I Use What?

• Making Sense of it For Real Applications!

24
Registration Wheres the stuff you need?

• Credential Number
• In the CHUID ? FASC-N SystemCodeCredentialNumbe
  r 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

25
Registration Wheres the stuff you need?

• Issuer Integrity Did they really put this
  there?
• CHUIDs 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

26
Physical Access

• Which credential is asking for access?
• CHUID
• Primarily the FASC-N fields Agency CodeSystem
  CodeCredential 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

27
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

28
Summary
29
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!

30
Thank you for your time!
Stephen P. Howard ID Technology
Partners SteveHoward_at_idtp.com 703.319.3171
31
PIV Card and Physical Access

• How can I use the PIV card in physical access
  control systems (PACS)?
• Dwayne PfeifferNorthrop Grumman
  Corp.dwayne.pfeiffer_at_ngc.com

32
PIV Data Model
Buffer Description Interface Available Access Rule
Card Capabilities Container Contact Always Read
Card Holder Unique ID (CHUID) Contact and Contactless Always Read
X.509 for PIV Authentication Contact PIN
Card Holder Fingerprint I Contact PIN
Card Holder Fingerprint II Contact PIN
Printed Information Contact PIN
Card Holder Facial Image Contact PIN
X.509 for Digital Signature Contact PIN Always
X.509 for Key Management Contact PIN
X.509 for Card Authentication Contact and Contactless Always
Security Object Contact Always Read
For PACS Usage
Mandatory issuer controlled data
Issuer optional
33
Whats in the CHUID?
34
Whats in the CHUID? (continued)

• Federal Agency Smart Credential Number (FASC-N)
  Part 1

Field name Length (BCD digits) Field description
AGENCY CODE 4 Identifies the government agency issuing the credential
SYSTEM CODE 4 Identifies the system the card is enrolled in and is unique for each site (can be concatenated with credential number to create a 10 digit credential number)
CREDENTIAL NUMBER 6 Encoded by the issuing agency. For a given system no duplicate numbers are active
CS 1 CREDENTIAL SERIES (SERIES CODE) Field is available to reflect major system changes
ICI 1 INDIVIDUAL CREDENTIAL ISSUE (CREDENTIAL CODE) Initially encoded as 1, will be incremented if a card is replaced due to loss or damage
35
Whats in the CHUID? (continued)

• Federal Agency Smart Credential Number (FASC-N)
  Part 2

Field name Length (BCD digits) Field description
PI 10 PERSON IDENTIFIER - Numeric Code used by the identity source to uniquely identify the token carrier. (e.g. DoD EDI PN ID)
OC 1 ORGANIZATIONAL CATEGORY 1 - Federal Government Agency 2 - State Government Agency 3 - Commercial Enterprise 4 - Foreign Government
OI 4 ORGANIZATIONAL IDENTIFIER OC1 FIPS 95-2 Agency Code OC2 State Code OC3 Company Code OC4 Numeric Country Code
POA 1 PERSON/ORGANIZATION ASSOCIATION CATEGORY 1 Employee, 2 Civil, 3 Executive Staff, 4 Uniformed Service 5 Contractor, 6 Organizational Affiliate, 7 Organizational Beneficiary
36
Whats 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.

37
Whats 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

38
CHUID Usage (Authentication)
39
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 CHUIDs 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 CHUIDs
  issuer digital signature

40
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 issuers Certificate
  Authority (CA) (e.g., Certificate Revocation List
  (CRL) or Online Certificate Status Responder
  (OCSP)

41
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.
  

42
PAC Mission

• To accelerate the widespread acceptance, usage,
  and application of smart card technology in the
  physical access world by bringing together, in an
  open forum, leading users and technologists from
  both the public and private sectors.

43
Fulfilling the PAC Mission

• How Do We Do It
• Networking and sharing of information
• Education
• Industry outreach
• Multi-vendor collaborative documents
• Media positioning
• Melting pot of new ideas

44
PAC Participants

• The Physical Access Council includes participants
  from across the smart card and physical access
  control industry, including
• End users
• Smart Card Chip developers
• Smart Card manufacturers
• Smart Card Reader manufacturers
• Smart Card Software developers
• Physical access control systems vendors
• Integration service providers
• Government

45
PAC Steering Committee
46
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

47
PAC Goal

• Accelerate the widespread acceptance, usage, and
  application of smart card technology for physical
  access control

48
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

49
Thank you for your time
Dwayne M. Pfeiffer, CISSP Northrop Grumman
Corporation dwayne.pfeiffer_at_ngc.com 703.556.2963
50
Contacts

• Gilles Lisimaque, Partner
• ID Technology Partners, Inc.
• GLisimaque_at_idtp.com
• Phone [phone]
• Stephen P. Howard, Partner
• ID Technology Partners
• SteveHoward_at_idtp.com
• 703.319.3171
• Dwayne M. Pfeiffer, CISSP
• Northrop Grumman Corp
• dwayne.pfeiffer_at_ngc.com
• 703.556.2963

Contact Randy Vanderhoof 1-800-556-6828 rvanderho
of_at_smartcardalliance.org www.smartcardalliance.or
g