1 / 12

The Government Smart Card Interoperability Specification

The Government Smart Card Interoperability Specification. Jim Dray james.dray@nist.gov CardTech/SecurTech, April 2002. History. GSA Smart Access Common ID Card contract May 2000 Post-award Interoperability Committee GSC-IS v1.0 August 2000

watson
Download Presentation

The Government Smart Card Interoperability Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Government Smart Card Interoperability Specification Jim Dray james.dray@nist.gov CardTech/SecurTech, April 2002

  2. History • GSA Smart Access Common ID Card contract May 2000 • Post-award Interoperability Committee • GSC-IS v1.0 August 2000 • Government Smart Card Interagency Advisory Board, Standards TWG • GSC-IS v2.0 NIST Special Pub Q3-02

  3. GSC-IS Objectives • Generic card service provider model • Common high level card service interface • APDU independence • Extensible • Compatible with other models

  4. Applications (Logical/Physical Access, etc) API API (Service) (Service) SPI SPI Basic Service Interface Ext. Service Interfaces GSC-SPM (cards/readers/software) GSC Architectural Model

  5. Basic Services Interface Card Capability Container Service Provider Software Card Reader(s) Smart Card Common Data Model GSC Service Provider Module *Card Reader Driver Layer

  6. Constraints • The BSI is: • Interoperable • NOT operational • APDU set differences preclude interoperability of some essential operational functions • All GSC-IS implementations will require XSIs • A card reader driver layer is not defined

  7. APDU Independence • Possible approaches: • Standardize on one APDU set (compatibility?) • Software drivers for all APDU sets (maintenance?) • Card Capabilities Container • A “hybrid” approach

  8. Card Capabilities Container • Carried on each card • Defines how a card’s APDU set differs from the GSC-IS Virtual Card Edge Interface(VCEI) • Formal grammar • Size depends on number of differences • Low overhead: < 100 bytes

  9. Communications Sequence • SPS reads a card’s CCC • A CCC parser uses the CCC to map APDUs • Card specific APDU set is mapped to the VCEI • SPS also links BSI methods to the VCEI • Card reader driver layer = raw APDU transport

  10. Data Models • Original “J.8” model from GSC-IS v1.0 • DoD Common Access Card model • Mandatory set of core elements: • 3 containers • 7 data elements

  11. GSC-IS Conformance • Card level: • Mandatory core data elements • CCC • Middleware: • BSI • VCEI

  12. The Future • Implementation guidance • Reference implementations • Developer’s toolkits/workshops • Collaborations • Standardization • Security and conformance testing

More Related