Transcript Presentation title

Smart Card Industry Panel:
Delivering PIV compliant products
HSPD 12 Workshop
May 5, 2005
Washington, DC
Moderator: Randy Vanderhoof, SCA
Industry Panel:
Gilles Lisimaque, Partner
ID Technology Partners, Inc.
[email protected]
Phone: 301-320-5146
Stephen P. Howard, Partner
ID Technology Partners
[email protected]
703.319.3171
Dwayne M. Pfeiffer, CISSP
Northrop Grumman Corp
[email protected]
703.556.2963
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)?
Standards & Smart Cards
Gilles Lisimaque
ID Technology Partners
[email protected]
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 ….
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 GSCIS developed incompatible application languages
and could not built the interoperable “unified
tower” their leaders dreamed about.
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.
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.
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
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
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
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
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
PIV Data Model
When do I Use What in the PIV?
Stephen P. Howard
ID Technology Partners
[email protected]
Structure of the Data Model
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
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
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
When Do I Use What?
Making Sense of it For Real Applications!
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
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
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 FASCN 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
Logical Access
• Mandatory – PIV Authentication Key
– Windows Login, Web Access, etc.
– Requires pin, proving Card and Card Holder
• Optional
– Digital Signature  PIN Always enabling NonRepudiation 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
Summary
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!
PIV Card and Physical Access
How can I use the PIV card in physical
access control systems (PACS)?
Dwayne Pfeiffer
Northrop Grumman Corp.
[email protected]
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
Mandatory issuer controlled data
Issuer optional
For PACS Usage
What’s in the CHUID?
What’s 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
1
CREDENTIAL SERIES
(SERIES CODE)
Field is available to reflect major system changes
1
INDIVIDUAL CREDENTIAL ISSUE
(CREDENTIAL CODE)
Initially encoded as “1”, will be incremented if a card is
replaced due to loss or damage
CS
ICI
What’s in the CHUID? (continued)
Federal Agency Smart Credential Number (FASC-N) –Part 2
Field name
Length
Field description
(BCD digits)
PI
10
PERSON IDENTIFIER - Numeric Code used by the identity
source to uniquely identify the token carrier. (e.g. DoD EDI PN ID)
ORGANIZATIONAL CATEGORY
OC
1
1 - Federal Government Agency
2 - State Government Agency
3 - Commercial Enterprise
4 - Foreign Government
ORGANIZATIONAL IDENTIFIER
OI
4
OC=1 – FIPS 95-2 Agency Code
OC=2 – State Code
OC=3 – Company Code
OC=4 – Numeric Country Code
PERSON/ORGANIZATION ASSOCIATION CATEGORY
POA
1
1 – Employee, 2 – Civil, 3 – Executive Staff, 4 – Uniformed Service
5 – Contractor, 6 – Organizational Affiliate,
7 – Organizational Beneficiary
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.
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
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
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)
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.
PAC Steering Committee
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
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
Contacts
Gilles Lisimaque, Partner
ID Technology Partners, Inc.
[email protected]
Phone: 301-320-5146
Contact: Randy Vanderhoof
1-800-556-6828
[email protected]
Stephen P. Howard, Partner
ID Technology Partners
[email protected]
703.319.3171
Dwayne M. Pfeiffer, CISSP
Northrop Grumman Corp
www.smartcardalliance.org [email protected]
703.556.2963