PC/SC Applications and New Developments Boris Balacheff Member of PC/SC Technical Workgroup CTST’ 2000 Miami

PC/SC Revision 1.0 Limitations Emergence of Multi-application smartcards finds a lack of support in Revision 1.0 (I.e. Windows for Smartcards, JavaCards…): It is not possible to manage dynamically the off-card components that are used to interact with on-card applications Smartcard reader support is not up-to-date with current reader technology developments No support for synchronous and contactless cards CTST’ 2000 Miami

Multi-Application Cards Currently, Service Providers are mapped to a specific card-type (using ATR) in the Resource Manager database With multi-application cards, the card-type does not reflect the card’s functionality/applications Need for a flexible and dynamic mechanism to update Service Provider information on the PC platform along with on-card applications changes ATR = Answer To Reset CTST’ 2000 Miami

Multi-Application Cards (cont.) It is not enough that the PC/SC Resource Manager can only recognise a smartcard based on manufacturer-specific ATR information To be able to dynamically assign Services Providers, information describing the card must be held on the card Need for a card recognition mechanism that is more flexible, in order to reflect what is on the card dynamically CTST’ 2000 Miami

Enhanced Smartcard Readers Revision 1.0 only supports readers with basic APDU communication capabilities Reader technologies with extended capabilities become widespread (pinpads, displays, multi-slot, SecurePin, biometrics…) Need to allow interoperability between cards and PC applications that use these new reader capabilities APDU = Application Protocol Data Unit CTST’ 2000 Miami

Other Card Technologies Contactless cards are a growing market Synchronous cards are already used by many applications Need to provide some support to allow the same interfaces and look-and-feel as asynchronous cards, at the PC application level CTST’ 2000 Miami

Introducing PC/SC Revision 2.0 Revision 2.0 of PC/SC aims at addressing these limitations. It does this by introducing the following: A New card recognition mechanism A Dynamic Service Provider Assignment mechanism A Mechanism for enhanced smartcard reader support Support for contactless and synchronous cards CTST’ 2000 Miami

Card-Aware Application PC/SC 2.0 Architecture ICCSPs in the PC/SC Revision 1.0 sense Card-Aware Application Interfaces Enhanced reader capabilities ADSP IFD SP ICCOS-SP Resource Manager ADSP Locator Abstraction of reader capabilities Slot 1 Slot 2 Pin Pad Display IFDSP = IFD Service Provider. This Service Provider interfaces the extended capabilities of an Enhanced IFD (I.e. SecurePIN, Display, Biometrics, Multiple slots…). ICCOS-SP = ICC Operating System Service Provider. This Service Provider interfaces functionality relative to the card OS. ADSP = Application Domain Service Provider. This Service Provider interfaces functionality specific to an on-card application. ADSPL = ADSP Locator. This Service Provider is used by the Resource Manager to be able to list on-card applications, find the ADSP for a specific application. IFD Handler New component to manage dynamic access to on-card applications Reader Smart Card CTST’ 2000 Miami

Typical Responsibility Application Developer Revision 2.0 Approach Card and Reader Card Operating System Card Applications CardInfo Structure IFD Subsystem (IFD + IFD Handler) Software Components ICCOS Service Provider (ICCOS-SP) Application Domain Service Provider (ADSP) ADSP Locator (ADSPL) IFD Service Provider (IFDSP) Typical Responsibility Card Vendor Application Developer Card Issuer IFD Vendor CTST’ 2000 Miami

Card Recognition Resource Manager Smartcard Initial Access Data ATR History Bytes Communications Parameters Initial Access Data Command Data Structures 1 CardInfo structure ADSPL id ICCOS id CardInfo 3 Initial Access Data 2 Smartcard CTST’ 2000 Miami

Service Provider Assignment Guid of ADSP IIDs of Interfaces ID_ADSP_AppX IID_I1, IID_I2 6 Application ListAppInterfaces 3 Instantiate (from ADSPL id) ADSP-L 2 ID_ADSP_AppX + reader name 8 Find AppInterfaces I1 and I2 1 AppInterfaces and corresponding ADSP Guids 7 ListAppInterfaces 4 AppInterfaces 5 Resource Manager ADPSL= Application Domain Service Provider Locator, or ADSP Locator. Smartcard CTST’ 2000 Miami

ICC-Aware Application Enhanced IFDs ICC-Aware Application ADSP IFD SP These components are responsible for implementing and interfacing the Enhanced Reader Capabilities ICCOS-SP Resource Manager ADSP Locator Slot 1 Slot 2 Pin Pad Display IFD Handler Reader Smart Card CTST’ 2000 Miami

Contactless and Synchronous Cards ICC-Aware Application ADSP IFD SP ICCOS-SP Resource Manager ADSP Locator Slot 1 Slot 2 Pin Pad Display These components are responsible for implementing PC/SC support for Contactless and/or Synchronous cards The darker components are responsible for handling the support of a contactless card type. For contactless cards, functionality such as ATR, insertion/removal, and card selection, will have to be emulated in these component to match the specification model. Contactless support will be provided for ISO 14443 proximity ICCs. IFDs supporting Synchronous cards will have to support ISO 7816-10 for Synchronous card types 1 and 2. IFD Handler Reader Smart Card CTST’ 2000 Miami

Further Information WhitePaper on PC/SC Revision 2.0 available at: http://www.pcscworkgroup.com CTST’ 2000 Miami