PC/SC Workgroup Specifications Overview

PC/SC Workgroup Specifications Overview

The current release, Version 2.01.6 was released in May 2009. It incorporated changes to Part 10 to remove wLcdMaxCharacters and wLcdMaxLines fields from PIN_PROPERTIES to maintain backward compatibility.

Version 2.01.5 was released in December 2008. A warning was added regarding the use of GET KEY PRESSED and WRITE DISPLAY, and added error cede return when SET_SPE_MESSAGE exceeds storage capability. 'C' Structures were revised and structure packing notes removed. Also, #define feature was removed.

Version 2.01.4 was released in July 2007. Both Part 3 and Part 3 supplement were slightly revised. Part 3, sec. 3.1.3.2.3 added ATR ISO 14443B. Part 3 supplement added LR 164 to section 2.1.2.2.

Release Version 2.01.3 was released in January 2006. Revisions were made to Part 3 to correct some syntax errors and revise class byte for commands, and text was added to section 3.2.2.1.1. Cards were added to Part 3 Supplement, and Part 10 had revisions for GET_KEY_PRESSED.

Version 2.01.2 was released in August 2005 and revised Part 2, Section 3.1.1 Operating Voltage Condition, and Section 3.2 ISO/IEC 7816-10 Compatible Card and IFD; Part 3 to add specifications for identification of contactless cards and now includes information on the RID number (in a supplemental document); Part 10 has been added to address IFD's with secure pin entry capabilities. A minor edit was made on Sept. 12 to correct PIN structure information in Part 10, and an additional edit on September 29 to update the company name "Schlumberger" with "Axalto".

The PC/SC Specification Version 2.0 was first released in August 2004. Since then, the PC/SC Workgroup has made several enhancements, which are now posted as Final Release Specification Version 2.01.3. We will continue our efforts to improve our Specifications.

Please direct your questions or comments to: admin@pcscworkgroup.com

The PC/SC Specification builds upon existing industry smart card standards - ISO 7816 and EMV - and compliments them by defining low-level device interfaces and device-independent application APIs as well as resource management, to allow multiple applications to share smart card devices attached to a system. As with all previous versions, Specifications 2.01.6 is completely platform independent, and can be implemented on any operating system.

Revision 2.01.6 of the PC/SC Specifications extends the specification to cover a broader range of smart card based products. It focuses on the support of two main technologies:

• IFDs with extended capabilities
  Covered by an IFD Service Provider (IFDSP), which provides interfaces to manage new functionality, allowing IFD capabilities such as pin pad, display and multi-slot. The concept of application context is introduced to represent a list of IFD functions with security features required for ICC aware applications and ICC Service Provider (ICCSP).
• Support of contactless ICCs
  Also embedded in the actual scheme of PCSC. The impact on the specification is that new tags must be defined (in part 3), and functionality must be ensured by the IFD Subsystem.

Earlier plans to introduce dynamic assignment of ICC Service Providers and enhanced card recognition where dropped in this release due to lack of industry interest.

The PC/SC Specifications 2.01.6 are divided into ten parts. A brief summary of each part is provided below:

• Part 1: Provides an overview of the system architecture and components defined by the Workgroup.
• Part 2: Details compliant ICC-IFD (smart card - Interface Device) characteristics and interoperability requirements.
• Part 3: Describes the interface to, and required functionality for, compliant IFD devices. There is also a supplement to provide information on RID numbers
• Part 4: Discusses design considerations for IFD devices. In particular, it provides a recommended implementation for PS/2 keyboard integrated IFDs.
• Part 5: Describes the interfaces and functionality supported by the ICC Resource Manager, a required system level component.
• Part 6: Describes the ICC Service Provider model, identifies required interfaces, and indicates how this may be extended to meet application domain-specific requirements.
• Part 7: Describes design considerations for application developers, and how to make use of the other components.
• Part 8: Describes recommended functionality for ICCs intended to support general purpose cryptographic and storage requirements. This is oriented toward support of Internet and PC standards for security and privacy.
• Part 9: Describes the management of IFDs with some extended capabilities such as secure PIN entry or user interface functionality.
• Part 10: Describes the management of IFDs with secure pin entry capabilities.

This image depicts the architecture defined in the PC/SC Specifications, and clearly shows the relationship amongst the various components defined in the Specifications.

As shown, ICC devices are accessed by PC-based applications through an IFD peripheral device. There may be multiple IFDs per system, and a variety of I/O channels are supported. RS-232C serial IFDs, keyboard based IFDs, and PC CARD IFDs are expected to be the most common, but the design is not limited to these. Associated with each IFD in the system is an IFD Handler. While the implementation may vary by system, this will likely correspond to a device driver.

The ICC Resource Manager is intended to provide a system level service. It manages the ICC and IFD resources, controls shared access to these devices, and supports transaction management primitives.

The Service Provider(s) provide a high level interface mapped onto a specific ICC implementation. The Workgroup has defined common interfaces for widely implemented services (Authentication, File Access, Cryptography) and defined how extensions for domain-specific requirements are supported. Cryptographic interfaces are isolated in a Cryptographic Service Provider, in recognition of existing import/export issues.

Finally, applications written to take advantage of this architecture will typically make use of both the Resource Manager and a specific ICC Service Provider.

This picture shows the components of the PC/SC architecture and the part of the Specification that describes its interface.