Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "HSPD 12 Workshop May 5, 2005 Washington, DC HSPD 12 Workshop May 5, 2005 Washington, DC Smart Card Industry Panel: Delivering PIV compliant products."— Presentation transcript:

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

2 Moderator: Randy Vanderhoof, SCA Industry Panel: Gilles Lisimaque, Partner ID Technology Partners, Inc. Phone: Stephen P. Howard, Partner ID Technology Partners Dwayne M. Pfeiffer, CISSP Northrop Grumman Corp Industry Panel: Gilles Lisimaque, Partner ID Technology Partners, Inc. Phone: Stephen P. Howard, Partner ID Technology Partners Dwayne M. Pfeiffer, CISSP Northrop Grumman Corp

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)? 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 Gilles Lisimaque ID Technology Partners

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

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 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 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 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 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 and later to ISO 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 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 and later to ISO 24727

12 The delicate choice ahead SP allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP proposes fixes to GSC-IS to provide enough interoperability for the PIV application. SP 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 allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP proposes fixes to GSC-IS to provide enough interoperability for the PIV application. SP 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 allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP proposes fixes to GSC-IS to provide enough interoperability for the PIV application. SP 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 allows to use existing GSC-IS systems in an interoperable manner. These systems and cards are available and SP proposes fixes to GSC-IS to provide enough interoperability for the PIV application. SP 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 ActivCard Atlan Labs Atmel Axalto Cygnacom Department of Defense Dept. of Transportation/TWIC DMDC Dreifus G&D ActivCard Atlan Labs Atmel Axalto Cygnacom Department of Defense Dept. of Transportation/TWIC DMDC Dreifus G&D Gemplus IBM ID Technology Partners Infogard Litronic Lockheed Martin MartSoft MasterCard Mobile Mind NIST Oberthur Philips Raak Technologies Gemplus IBM ID Technology Partners Infogard Litronic Lockheed Martin MartSoft MasterCard Mobile Mind NIST Oberthur Philips Raak Technologies

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 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 140 common card platform FIPS 201 PIV applications benefits from a FIPS 140 common card platform Faster qualification Better interoperability Lower costs Card Platform PIV Application Applet #1 Applet #xyz Global Platform JavaCard Smart Card Alliance FISP 140 Working Group

17 Thank you Gilles Lisimaque Partner ID Technology Partners, Inc. 316-B Cross Green Street Gaithersburg, MD Phone: WEB: Gilles Lisimaque Partner ID Technology Partners, Inc. 316-B Cross Green Street Gaithersburg, MD Phone: WEB:

18 PIV Data Model When do I Use What in the PIV? Stephen P. Howard ID Technology Partners When do I Use What in the PIV? Stephen P. Howard ID Technology Partners

19 Structure of the Data Model

20 Mandatory issuer controlled data Issuer optional Buffer DescriptionInterface AvailableAccess Rule Card Capabilities ContainerContactAlways Read Card Holder Unique IDContact and ContactlessAlways Read X.509 for PIV AuthenticationContactPIN Card Holder Fingerprint IContactPIN Card Holder Fingerprint IIContactPIN Printed InformationContactPIN Card Holder Facial ImageContactPIN X.509 for Digital SignatureContactPIN Always X.509 for Key ManagementContactPIN X.509 for Card AuthenticationContact and ContactlessAlways Security ObjectContactAlways Read PIV Data Model

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 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 SP 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 SP 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 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

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

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 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 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! 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 Stephen P. Howard ID Technology Partners

31 PIV Card and Physical Access How can I use the PIV card in physical access control systems (PACS)? Dwayne Pfeiffer Northrop Grumman Corp. How can I use the PIV card in physical access control systems (PACS)? Dwayne Pfeiffer Northrop Grumman Corp.

32 Mandatory issuer controlled data Issuer optional Buffer DescriptionInterface AvailableAccess Rule Card Capabilities ContainerContactAlways Read Card Holder Unique ID (CHUID)Contact and ContactlessAlways Read X.509 for PIV AuthenticationContactPIN Card Holder Fingerprint IContactPIN Card Holder Fingerprint IIContactPIN Printed InformationContactPIN Card Holder Facial ImageContactPIN X.509 for Digital SignatureContactPIN Always X.509 for Key ManagementContactPIN X.509 for Card AuthenticationContact and ContactlessAlways Security ObjectContactAlways Read PIV Data Model For PACS Usage

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 CODE4 Identifies the government agency issuing the credential SYSTEM CODE4 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 CS1 CREDENTIAL SERIES (SERIES CODE) Field is available to reflect major system changes ICI1 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 PI10 PERSON IDENTIFIER - Numeric Code used by the identity source to uniquely identify the token carrier. (e.g. DoD EDI PN ID) OC1 ORGANIZATIONAL CATEGORY 1 - Federal Government Agency 2 - State Government Agency 3 - Commercial Enterprise 4 - Foreign Government OI4 ORGANIZATIONAL IDENTIFIER OC=1 – FIPS 95-2 Agency Code OC=2 – State Code OC=3 – Company Code OC=4 – Numeric Country Code POA1 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. 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 SP 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 SP 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 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 –SP 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) PIN –PIN pad must be integrated with reader Biometrics –Prior to SP800-76, local use only – not interoperable –SP 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. 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 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 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 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 Personal Identity Verification (PIV) –for all Federal Employees and Contractors SP Interfaces for PIV SP 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 Personal Identity Verification (PIV) –for all Federal Employees and Contractors SP Interfaces for PIV SP 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 M. Pfeiffer, CISSP Northrop Grumman Corporation

50 Contacts Gilles Lisimaque, Partner ID Technology Partners, Inc. Phone: Stephen P. Howard, Partner ID Technology Partners Dwayne M. Pfeiffer, CISSP Northrop Grumman Corp Contact: Randy Vanderhoof


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

Similar presentations


Ads by Google