smart card industry panel: delivering piv compliant products
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
HSPD 12 WorkshopHSPD 12 Workshop
May 5, 2005May 5, 2005
Washington, DCWashington, DC
HSPD 12 WorkshopHSPD 12 Workshop
May 5, 2005May 5, 2005
Washington, DCWashington, DC
Smart Card Industry Panel:Delivering PIV compliant productsSmart Card Industry Panel:Delivering PIV compliant products
Moderator: Randy Vanderhoof, SCAModerator: Randy Vanderhoof, SCA
Industry Panel:Industry Panel:
Gilles Lisimaque, PartnerGilles Lisimaque, PartnerID Technology Partners, Inc.ID Technology Partners, [email protected]@idtp.comPhone: 301-320-5146Phone: 301-320-5146
Stephen P. Howard, PartnerID Technology [email protected]
Dwayne M. Pfeiffer, CISSPNorthrop Grumman [email protected]
Industry Panel:Industry Panel:
Gilles Lisimaque, PartnerGilles Lisimaque, PartnerID Technology Partners, Inc.ID Technology Partners, [email protected]@idtp.comPhone: 301-320-5146Phone: 301-320-5146
Stephen P. Howard, PartnerID Technology [email protected]
Dwayne M. Pfeiffer, CISSPNorthrop Grumman [email protected]
Topics to be covered: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
• 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 CardsStandards & Smart Cards
Gilles LisimaqueGilles Lisimaque
ID Technology PartnersID Technology Partners
[email protected]@IDTP.com
Gilles LisimaqueGilles Lisimaque
ID Technology PartnersID Technology Partners
[email protected]@IDTP.com
In the Beginnings ….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 ….
• 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 …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.
• 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.
The Quest for Interoperability …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 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-73The 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.
• 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 InteroperabilityThe 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
• 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 AheadThe 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
• 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?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
• 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 aheadThe 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
• 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 aheadThe 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
• 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 ModelPIV Data Model
When do I Use What in the PIV?When do I Use What in the PIV?
Stephen P. HowardStephen P. HowardID Technology PartnersID Technology [email protected]@idtp.com
When do I Use What in the PIV?When do I Use What in the PIV?
Stephen P. HowardStephen P. HowardID Technology PartnersID Technology [email protected]@idtp.com
Structure of the Data ModelStructure of the Data Model
Mandatory issuer controlled data Issuer optional
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
PIV Data ModelPIV Data Model
State’s RightsState’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
• 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 TransactionsBack-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
• 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?When Do I Use What?
Making Sense of it For Real Applications!Making Sense of it For Real Applications!Making Sense of it For Real Applications!Making Sense of it For Real Applications!
Registration – Where’s the stuff you need?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
• 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?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
• 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 AccessPhysical 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
• 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
Logical AccessLogical 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
• 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
SummarySummary
PIV is a Very Powerful ToolPIV 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!
• 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 AccessPIV Card and Physical Access
How can I use the PIV card in physical How can I use the PIV card in physical access control systems (PACS)?access control systems (PACS)?
Dwayne PfeifferDwayne PfeifferNorthrop Grumman Corp.Northrop Grumman [email protected]@ngc.com
How can I use the PIV card in physical How can I use the PIV card in physical access control systems (PACS)?access control systems (PACS)?
Dwayne PfeifferDwayne PfeifferNorthrop Grumman Corp.Northrop Grumman [email protected]@ngc.com
Mandatory issuer controlled data Issuer optional
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
PIV Data ModelPIV Data Model
For PACS Usage
What’s in the CHUID?What’s in the CHUID?
What’s in the CHUID? (continued)What’s in the CHUID? (continued)
Federal Agency Smart Credential Number (FASC-N) –Part 1Federal Agency Smart Credential Number (FASC-N) –Part 1
Field nameLength(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
6Encoded by the issuing agency. For a given system no duplicate numbers are active
CS 1CREDENTIAL 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
What’s in the CHUID? (continued)What’s in the CHUID? (continued)
Federal Agency Smart Credential Number (FASC-N) –Part 2Federal Agency Smart Credential Number (FASC-N) –Part 2
Field nameLength(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 CATEGORY1 - Federal Government Agency2 - State Government Agency3 - Commercial Enterprise4 - Foreign Government
OI 4
ORGANIZATIONAL IDENTIFIEROC=1 – FIPS 95-2 Agency CodeOC=2 – State CodeOC=3 – Company CodeOC=4 – Numeric Country Code
POA 1
PERSON/ORGANIZATION ASSOCIATION CATEGORY1 – Employee, 2 – Civil, 3 – Executive Staff, 4 – Uniformed Service5 – Contractor, 6 – Organizational Affiliate,7 – Organizational Beneficiary
What’s in the CHUID? (continued)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.
• 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)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
• 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 RequirementsPACS 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
• 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 OptionsPACS 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)
• 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)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.
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 CommitteePAC Steering Committee
PAC MembersPAC 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
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 FocusInitial 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
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
ContactsContacts
Gilles Lisimaque, PartnerGilles Lisimaque, PartnerID Technology Partners, Inc.ID Technology Partners, [email protected]@idtp.comPhone: 301-320-5146Phone: 301-320-5146
Stephen P. Howard, PartnerID Technology [email protected]
Dwayne M. Pfeiffer, CISSPNorthrop Grumman [email protected]
Gilles Lisimaque, PartnerGilles Lisimaque, PartnerID Technology Partners, Inc.ID Technology Partners, [email protected]@idtp.comPhone: 301-320-5146Phone: 301-320-5146
Stephen P. Howard, PartnerID Technology [email protected]
Dwayne M. Pfeiffer, CISSPNorthrop Grumman [email protected]
Contact: Randy Vanderhoof
1-800-556-6828
www.smartcardalliance.org