Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Copyright 19962005 Apple, Axalto/ Schlumberger, Gemplus, Hewlett-Packard, IBM, Infineon, Ingenico, Microsoft, Philips, Siemens, Sun Microsystems, Toshiba and VeriFone. All rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. BULL CP8, GEMPLUS, HEWLETT-PACKARD, IBM, MICROSOFT, SCHLUMBERGER, SIEMENS NIXDORF, SUN MICROSYSTEMS, TOSHIBA AND VERIFONE DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. BULL CP8, GEMPLUS, HEWLETT-PACKARD, IBM, MICROSOFT, SCHLUMBERGER, SIEMENS NIXDORF, SUN MICROSYSTEMS, TOSHIBA AND VERIFONE DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS.
Windows, Windows NT, Windows 2000 and Windows XP are trademarks and Microsoft and Win32 are registered trademarks of Microsoft Corporation. PS/2 is a registered trademark of IBM Corporation. JAVA is a registered trademark of Sun Microsystems, Inc. All other product names are trademarks, registered trademarks, or servicemarks of their respective owners.
Revision History Revision 2.00.11 2.01.00 Issue Date May 28, 2004 June 23, 2005 Comments Spec 2.00 Final Draft Spec 2.01 Final Release
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Contents
1 1.1 1.2 1.3 1.4 1.5 INTRODUCTION Motivation Objectives History of the PC/SC workgroup Organization of this Specification Target Audience 1 1 2 3 3 3 4 4 5 6 6 7 7 8 8 8 8 9 9 10 10 10 11 11 12 12 14 15 15 15 15 15 15 16
1.6 Related Documents 1.6.1 ICC-Related Standards 1.6.2 Personal Computer Interface Specifications 2 SYSTEM ARCHITECTURE AND COMPONENTS OVERVIEW
2.1 Architecture overview 2.1.1 Integrated Circuit Card ( ICC) 2.1.2 Interface Device (IFD) 2.1.2 Interface Device Handler (IFD Handler) 2.1.2.1 Slot Logical Devices 2.1.2.2 Functional Logical Devices 2.1.3 ICC Resource Manager 2.1.4 Service Providers 2.1.4.1 ICC Service Provider (ICCSP) 2.1.4.1.1 ICCOS Service Provider (ICCOSSP) 2.1.4.1.2 Application Domain Service Provider (ADSP) and ADSP Locator (ADSPL) 10 2.1.4.1.2.1 Application Domain Service Provider (ADSP) 2.1.4.1.2.2 ADSP Locator (ADSPL) 2.1.4.1.3 Card Recognition System. 2.1.4.1.4 Cryptographic Service Provider (CSP) 2.1.4.2 IFD Service Provider (IFDSP) 2.1.5 ICC-Aware Application 2.2 2.3 Specification Breakdown System Requirements
2.4 Relevant Objects 2.4.1 System 2.4.2 User 2.4.3 Process 2.4.4 Terminal 2.4.5 ICC
Page i
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
2.4.6 3
IFD
16 17
Page ii
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
1 Introduction
The PC/SC Workgroup was initiated to develop a specification that can facilitate the interoperability necessary to allow Integrated Circuit Card (ICC) technology to be effectively utilized in the PC environment. In addition to development of the specification, the PC/SC Workgroup members are committed to implementation of both hardware devices and PC system components necessary to validate the design efforts. This is deemed a critical step in the process of moving toward accepted standards and will provide a base of experience from which to further refine and/or enhance this specification. The PC/SC Workgroup will retain ownership of this specification until such time as it can be submitted and accepted by a formal standards body. The Workgroup will work with other interested parties to make this happen as quickly as possible. Until that time, the PC/SC Workgroup will support the general review by the PC and ICC communities at large, and evolution of the specification as necessary to respond to this general review process. This specification is available on a royalty-free basis to any party wishing to implement a compliant product.
1.1
Motivation
The Integrated Circuit Card (ICC) is an intrinsically secure computing platform ideally suited to providing enhanced security and privacy functionality for applications running within general purpose computing environments such as the personal computer (PC). ICCs are capable of providing secure storage facilities for sensitive information such as: Private keys. Account numbers. Passwords. Medical information. At the same time, the ICC provides an isolated processing facility capable of using this information without exposing it within the PC environment where it is at potential risk from hostile code (viruses, Trojan horses, and so on). This becomes critically important for certain operations such as: Generation of digital signatures, using private keys, for personal identification. Network authentication based on stored secrets. Maintenance of electronic representations of value (that is, prepaid purchase credits). Currently, the use of ICCs in the PC environment is hampered by the lack of interoperability at several levels. First, the industry lacks standards for interfacing PCs to IFDs. This has made it difficult to create applications that can work with IFDs from a variety of vendors. Attempts to solve this problem in the application domain invariably increase costs for both development and maintenance. It also creates a significant problem for the PC user in that an IFD used with one application may not work with future applications.
Page 1
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Second, there is no widely accepted high-level programming interface for common ICC functionality. Encapsulation of ICC interfaces can dramatically simplify application development and reduce costs by allowing low-level interface software to be shared across multiple applications. In addition, a standardized high-level interface allows applications to reduce their dependency on a specific ICC implementation, making it far more likely that an application will be able to use future, enhanced ICCs. To increase the flexibility and independence of PC-based software components necessary to deal with multi-application ICCs, it is also important to reflect the different roles of ICC vendors and ICC issuers through the mechanisms provided for ICC-application deployment. Only by separating ICC technologies from the ICC-applications can specific ICC technologies become transparent to ICC-based PC applications when dealing with ICCapplications.Third, mechanisms to allow multiple applications to effectively share the resources of a single ICC are not defined. These are critically important as we rapidly move toward the deployment of multiple-application ICCs and generic cryptographic ICCs that will be used as part of a multiprocessing PC environment. Without agreed upon standards for device sharing, it becomes effectively impossible for application developers to ensure that they can complete an operation using ICC services without interruption. To optimize the benefit to both the industry and end users, it is important that solutions to these issues be developed in a manner that supports a variety of operating environments and a broad base of applications. Only through this approach can we support the needs of all constituencies and encourage development of ICC-based PC applications, as a cost-effective solution to meeting requirements in a very diverse set of markets. ICC technology offers a vital addition to the security infrastructure of the PC and network environments. It is an enabling technology for network commerce in general. To achieve this potential, however, it is essential that a consistent framework exists into which the diverse efforts of application developers, network technology vendors, and ICC technology vendors can be coherently channeled. Establishing this framework will enhance the applications and services available to the end consumer, enhance the marketplace for application developers, enhance the marketplace for network technology vendors, and enhance the marketplace for ICC technology vendors. Establishing this framework is the basic motivation of the PC/SC Workgroups efforts.
1.2
Objectives
This document provides an overview of the specification, describing the minimum functionality required of ICCs, ICC Interface Devices (IFDs), and PCs to allow interoperability among compliant elements as provided by a variety of vendors. The specification as a whole seeks to achieve the following objectives: Maintain consistency with existing ICC-related and PC-related standards while expanding upon them where necessary and practical. Enable interoperability among components running on various platforms (platform neutral). Enable applications to take advantage of products and components from multiple manufacturers (vendor neutral). Enable the use of advances in technology without rewriting application-level software (application neutral).
19962005 PC/SC Workgroup. All rights reserved.
Page 2
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Facilitate the development of standards for application-level interfaces to ICC services in order to enhance the fielding of a broad range of ICC-based applications in the PC environment. Support an environment that encourages the widest possible use of ICCs as an adjunct to the PC environment.
1.3
At the time of release of revision 1.0 of the specification in December 1997, the PC/SC Workgroup was composed of Bull CP8, Gemplus, Hewlett-Packard Corporation, IBM Corporation, Microsoft Corporation, Schlumberger, Siemens Nixdorf, Sun Microsystems, Toshiba, and Verifone. At the time of publication of Revision 2.0 of this specification, the PC/SC Workgroup now consists of the following core member companies: Apple, Gemplus, Infineon Technologies, Ingenico, Microsoft Corporation, Philips Semiconductors, Schlumberger, and Toshiba. The PC/SC Workgroup has also brought a large number of associate member companies into the group.
1.4
The Interoperability Specification for ICCs and Personal Computer Systems is composed of nine parts. These are intended to apply only to devices and software intended to operate as a part of an overall system that includes a personal computer. Their potential application in other environments is outside the scope of this specification. The Parts of this specification detail specific interoperability requirements for compliant devices, reference design information, programming interfaces, and functional compatibility requirements. These documents include: Part 1. Introduction and Architecture Overview Part 2. Interface Requirements for Compatible IC Cards and Interface Devices Part 3. Requirements for PC-Connected Interface Devices Part 4. IFD Design Considerations and Reference Design Information. This part is here as an example reference only. Part 5. ICC Resource Manager Definition Part 6. ICC Service Provider Interface Definition Part 7. Application Domain/Developer Design Considerations Part 8. Recommendation for Implementation of Security and Privacy ICC Devices Part 9. IFDs with Extended Capabilities This document is Part 1, Introduction and Architecture Overview. It discusses the overall purpose and goals of the specification, provides references to related material, and defines the smart card terminology used in this specification. It also presents the components and architectural assumptions underlying this specification.
1.5
Target Audience
Page 3
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Operating system developers who wish to support ICCs as standard peripheral devices OEMs interested in developing Interface Device peripherals OEMs interested in developing ICC products for use with PCs Application developers who wish to create ICC-based products
1.6
Related Documents
ISO/IEC 7816 - 1 Identification Cards - Integrated Circuit(s) cards with contacts Part 1: Physical characteristics ISO/IEC 7816 - 2 Identification Cards - Integrated Circuit(s) cards with contacts Part 2: Dimensions and location of the contacts ISO/IEC 7816 -3 Identification Cards - Integrated Circuit(s) cards with contacts Part 3: Electronic signals and transmission protocols ISO/IEC 7816 -3/1 Identification Cards - Integrated Circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols AMENDMENT 1: Protocol type T=1, asynchronous half duplex block transmission protocol ISO/IEC 7816 -3/2 Identification Cards - Integrated Circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols AMENDMENT 2: Revision of protocol type selection ISO/IEC 7816 -4 Identification Cards - Integrated Circuit(s) cards with contacts Part 4: Inter-industry commands for interchange. ISO/IEC 7816 -5 Identification Cards - Integrated Circuit(s) cards with contacts Part 5: Numbering system and registration procedure for application identifiers. ISO/IEC 7816 -6 Identification Cards - Integrated Circuit(s) cards with contacts Part 6: Inter-industry data elements ISO/IEC 7816 -10 Identification Cards - Integrated Circuit(s) cards with contacts Part 10: Electronic signals and answer to reset for synchronous cards ISO/IEC 7811 1995 Identification Cards [ REFERENCE TO PHYSICAL SPECS IN 7811] ISO/IEC 14443 -1 Identification Cards Contactless integrated circuit(s) cards Proximity cards Physical characteristics ISO/IEC 14443 -2 Identification Cards Contactless integrated circuit(s) cards Proximity cards Radio frequency power and signal interface ISO/IEC 14443 -3 Identification Cards Contactless integrated circuit(s) cards Proximity cards Initialization and anticollision ISO/IEC 14443 -4 Identification Cards Contactless integrated circuit(s) cards Proximity cards Answer to Select and Transmission Protocol ISO/IEC 15693 1 Identification cards Contactless integrated circuit(s) cards Vicinity Integrated Circuit(s) Card Physical Characteristics ISO/IEC 15693 2 Identification cards Contactless integrated circuit(s) cards Vicinity Cards Air Interface and Initialization ISO/IEC 15693 3 Identification cards Contactless integrated circuit(s) cards Anticollision and Transmission Protocol
Page 4
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
EMV 96 Integrated Circuit Card Application Specification for Payment Systems, Version 3.1.1 EMV 96 Integrated Circuit Card Specification for Payment Systems, Version 3.1.1 EMV 96 Integrated Circuit Card Terminal Specification for Payment Systems, Version 3.1.1 RFC 2279: F. Yergeau, UTF-8, a transformation format of ISO 10646 (Obsoletes 2044), Alis Technologies, January 1998 CEN prEN 726-1: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 1: System Overview CEN prEN 726-2: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 2: Security Framework CEN prEN 726-3: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 3: Application-Independent Card Requirements CEN prEN 726-4: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 4: Application-Independent Card-Related Terminal Requirements CEN prEN 726-5: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 5: Payment Methods CEN prEN 726-6: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 6: Telecommunication Features CEN prEN 726-7: Identification Card Systems - Telecommunications Integrated Circuits Cards and Terminals - Part 7: Security Module
Page 5
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
The architecture defined by this specification, in terms of software and hardware components, is depicted in Figure 2-1.
IFD Handler
IFD Handler
IFD Handler
IFD
IFD
IFD
ICC
ICC
ICC
The elements that comprise the architecture are defined in the following sections.
Page 6
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Page 7
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Page 8
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
The ICC Resource Manager solves three basic problems in managing access to multiple IFDs and ICCs. First, it is responsible for identification and tracking of resources. This includes: Tracking installed IFDs and making this information accessible to other applications. Tracking known ICC types, along with their associated Service Providers and supported Interfaces, and making this information accessible to other applications. Tracking ICC insertion and removal events to maintain accurate information on available ICCs within the IFDs. Second, it is responsible for controlling the allocation of IFDs and resources (and hence access to ICCs) across multiple applications. It does this by providing mechanisms for attaching to specific IFDs in shared or exclusive modes of operations. Finally, it supports transaction primitives on access to services available within a given ICC. This is extremely important, as current ICCs are single-threaded devices, which often require execution of multiple commands to complete a single function. Transactions allow multiple commands to be executed without interruption, ensuring that intermediate state information is not corrupted.
Page 9
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
In the Revision 1.0 service provider introduction mechanism, which is now deprecated, an ICCSP needed to be introduced to the Resource Manager in order to be used. Typically, this was done through an ICC setup utility provided by the ICC vendor. This utility must provide four pieces of information about the card: 1. Its ATR string and a mask to use as an aid in identifying the ICC 2. An identifier for the Service Provider(s) that support the ICC 3. A list of ICC Interfaces supported by the ICC 4. A friendly name for the ICC; to be used in identifying the ICC to the user (in most cases, the user will supply this to the setup utility) 2.1.5.1.1 ICCOS Service Provider (ICCOSSP) The ICCOS Service Provider encapsulates access to functionality from a specific ICC Operating System through high-level programming interfaces. Interfaces for commonly implemented file access and authentication services are defined by this specification. If an ICC implements these services, it shall make use of the defined interfaces. However, additional interfaces may be defined and implemented to meet domain-specific requirements.Typically, an ICCOSSP needs to be introduced to the Resource Manager, to map it to a particular ICCOS. There is a onetoone relationship between ICCs and their ICCOSSP. This will then be used in the new card recognition system (See 2.1.5.1.3). 2.1.5.1.2 Application Domain Service Provider (ADSP) and ADSP Locator (ADSPL) 2.1.5.1.2.1 Application Domain Service Provider (ADSP) The ADSP is a service provider intended to interface with oncard applications. This differentiates the ADSP from a regular ICCSP which interfaces to an ICCtype or ICCOS. ADSPs support oncard applications in a flexible way that is compatible with multi application card environments. Contrary to ICCSPs, as defined in Revision 1.0, which can only be mapped to the ICC using the ATR through the Resource Manager, the ADSP uses a dynamic assignment mechanism using an ADSP Locator (see 2.1.5.1.2.2), and a specific Card Recognition System (see 2.1.5.1.3). The ADSP Locator mechanism allows dynamic assignment of an ADSP. This in turn will allow multiple ADSPs to be available to offcard applications for the same ICC. A modification to an oncard application only needs to be accompanied with an updated implementation of the corresponding ADSP. 2.1.5.1.2.2 ADSP Locator (ADSPL) The static linking between ICCType and available ICCSPs, as performed by the Resource Manager (RM), is not possible in a multiapplication card environment. The ADSP Locator is introduced to the Resource Manager to allow dynamic assignment of ICC Service Providers.
19962005 PC/SC Workgroup. All rights reserved. Page 10
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
The ADSPL is itself a service provider (typically written by the ICC issuer) that is loaded by the Resource Manager. It allows the RM to provide offcard applications with: A way of listing oncard applications. A way of retrieving a reference to the appropriate ADSP implementation related to a chosen oncard application.
The provider of the ADSPL is responsible for specifying the way in which ADSPs should be introduced to the ADSPL. The design of the ADSPL could be such that it can retrieve an appropriate ADSP automatically when it is needed. 2.1.5.1.3 Card Recognition System In general, ICCs are identified by the ATR String they present to the offcard system. The flexibility of this common card recognition method is limited, due to the restricted length and complexity of an ATR. Card issuers, manufacturers and card application developers need to share the available ATR. Complex multiapplication cards require an enhanced card recognition mechanism to retrieve the basic information for identifying an ICC. All information regarding the identification of an ICC must be available on the ICC itself. The identity information is stored in a ICC Info Structure (or extended ATR). The information can be placed, for example, in a file or applet depending on the used ICC technology. The ICC must include a command in the ATRs historical bytes, which can be used by the offcard system (Resource Manager) to retrieve the ICC Info Structure. Specifying a command within the historical bytes of an ICC is described in more detail in the ISO 78164 document. When dealing with this type of enhanced ICC, the Resource Manager interprets the historical bytes of the ATR, sends the included command back to the ICC, and retrieves the ICC Info Structure. The information from this structure is used by the Resource Manager to identify the ICC. Part 5 of this specification defines a number of fields that can be used in the ICC Info structure, including a reference to the ICCOS and a reference to an ADSPL. When the ICC is inserted, the Resource Manager will retrieve the ICC Info, get the ADSPL reference from the ICC Info Structure and load the ADSPL. When appropriate, the Resource Manager will retrieve the list of oncard applications from the ADSPL. The off-card application gets this list from the Resource Manager. It can then choose from this list the appropriate on-card application and load the corresponding ADSP to interact with the oncard application. ICCs supporting the enhanced Card Recognition mechanism do not need to be introduced to the Resource Manager as ICC-Types anymore. For these cards, only the ICCOSSP and ADSPL are introduced to the Resource Manager. 2.1.5.1.4 Cryptographic Service Provider (CSP)
Page 11
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
The Cryptographic Service Provider, as defined in Revision 1.0 of this specification, encapsulates access to a specific ICC cryptographic functionality through high-level programming interfaces. It should expose only cryptographic functions to PC applications. Other functionality should be implemented in other Service Providers. In Revision 2.0, a CSP can be implemented as an ADSP for an ICC that comprises the new card recognition system, or as a traditional ICCSP if the ICC is using the deprecated introduction mechanism of Revision 1.0. The notion of CSP does not represent a different type of service provider technology; it is there only to segregate cryptographic functions to facilitate the handling of export/import regulations. Interfaces are defined in this specification for general-purpose cryptographic services including: Key generation. Key management. Digital signatures. Hashing (or message digests). Bulk encryption services. Key import/export. 2.1.5.2 IFD Service Provider (IFDSP) When extended IFD capabilities are available, they are presented to the ICC-aware application or ICC Service Provider through high level programming interfaces implemented in an IFD Service Provider (IFDSP). An IFDSP encapsulates access, and interfaces with an IFDs functionality in the same way an ICC Service Provider interfaces with an ICCs functionality. For each Application Context (which defines some type of functionality), the IFDSP may provide different interfaces. The interface implementation by the IFDSP interacts with the implementation of the IFD Handler in a mode that is transparent to the Resource Manager. This specification defines interfaces for commonly implemented services. However, additional interfaces may be defined and implemented for specific capabilities. Since an IFD Service Provider can be composed of modular components, the services associated with an IFD can evolve, as in an IFD with download capability. However, such download procedure is out of the scope of this specification. Part 9 of the Specification describes four predefined services that can be exported by an IFDSP, the support of which depends on IFD capabilities and security requirements: Secure PIN, Display, User confirmation, and Generic user entry.
Page 12
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
requests to the ICC, which is typically a single user, single-threaded, but multiple application environment. This overall architecture can alternatively be presented as a peer-to-peer communication protocol, as illustrated in the following figure.
ICC-Aware Application
Services Requests
ICC Application
Peripheral Side
ICC Side
Figure 2-2. ICC/PC Communication Layers the example shows ISO 7816
Page 13
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
2.2
Specification Breakdown
The following illustration shows how the different parts that make up this specification can be related to the overall system architecture:
PART 7
Applications
PART 6
PART 9
PART 10
PART 5
ICC Resource Manager
P A R T 1
PART 3
IFD Handler IFD Handler IFD Handler
PART 4
IFD IFD IFD IFD IFD IFD
PART 2
ICC ICC ICC ICC ICC
PART 8
ICC
Page 14
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
2.3
System Requirements
In order to support the above-described architecture, the host PC system is assumed to provide: A general purpose Operating System environment that supports: Multiple concurrent processes. Process separation at the kernel level. A shared library mechanism to facilitate code reuse and dynamic linking to shared code. Asynchronous event/messaging support. An interprocess communication facility. A memory management facility. Support for 3rd party peripheral devices to include: Installable peripheral devices. The ability to support multiple devices of a given type.
2.4
Relevant Objects
Within the PC/SC Workgroup architecture, the following objects are recognized as being particularly relevant to ICC operations. A brief description is provided here because these terms are used within other Parts of this specification with a specific definition intended.
2.4.1 System
The system is the computer and connected peripheral devices. These specifications focus on personal computers with a single user; however, they can be extended to multiuser, multiple terminal computers.
2.4.2 User
The user is the end user of the PC system. In general, a user is identified and authenticated based on an Operating Systemdefined mechanism. Processes started on behalf of the user are generally deemed to be running on the users behalf and have the access rights and/or security attributes associated with the user. In terms of this specification, the user is also the ICC cardholder.
2.4.3 Process
This document uses the term process in its larger computer science definition. It refers to executing software along with its associated data and the security context under which it is running. Typically, a process is associated with the user (except for certain OS processes) and takes on the permissions and privileges of the user as determined by the Operating System.
2.4.4 Terminal
A terminal in this context consists of a station through which the user interacts with the PC. It normally consists of the primary user interface elements (monitor, keyboard,
19962005 PC/SC Workgroup. All rights reserved. Page 15
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
mouse, and so on) and co-located peripherals, such as IFDs. Multiple processes may be associated with a single terminal, but at most one process controls the terminal at any given time.
2.4.5 ICC
ICCs are intelligent devices that may be used as PC peripheral devices. They will generally be owned by an individual, the cardholder, though they might be owned by a group. It is generally assumed these are high-value devices, which will remain in the possession of the cardholder when not required by an application. In this specification, it is assumed that the cardholder is responsible for physical protection of the asset, but that the ICC itself will provide logical protection to its internal services.
2.4.6 IFD
IFDs are assumed to be peripheral devices on the PC making use of standard I/O channels. They may be system wide or associated with a specific terminal. Most existing PC devices support only a single user. However, this specification is intended to be equally usable on multi-user computers including existing Unix workstations. The PC/SC Workgroup architecture supports flexible mechanisms for managing peripheral devices and managing connections between applications and these devices, to address both single user and multi-user environments.
Page 16
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview
Authentication Cryptogram.
AC Application
application.
ADSP Locator (ADSPL)
A service provider that allows enumeration of oncard applications and assignment of an appropriate ADSP.
Application Identifier. A data element that identifies an application in a card. An application identifier may contain a registered application provider number. If it contains no application provider number, then this identification may be ambiguous.
AID ALW Access
condition indicating a given function is always accessible National Standards Institute. protocol data unit.
ANSI American
The implementation of a well-defined and related set of functions that perform useful work on behalf of the user. It may consist of software and or hardware elements and associated user interfaces. identifier for a list of requirements associated with a set of functions and security features present in an IFD. entity that provides an application.
Application Context An
Application Specific Command set. A DF can be associated, optionally, with an ASC. This means that when selecting this application, the general command set is extended or modified by this specific command set. The ASC is valid for the whole subtree of this application unless there are other ASCs defined at the lower level of this application.
ASN.1 object Abstract ATC Application ATR
Transaction Counter.
Answer-to-Reset. The transmission sent by an ICC to the reader in response to a RESET condition.
Page 17
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview ATS Answer to Select. The transmission sent by an PICC type A to the PCD in response to a SELECT condition
ATQA Answer to Request for PICC type A. This is sent by the PICC type A back to the PCD upon a REQA command.
ATQB
Answer to Request. The transmission sent by an PICC type B to the PCD in response to a REQUEST condition
decimal.
Guard Time. contiguous data memory that is allocated when requested for data field.
Certification Authority
Trusted third party that establishes a proof that links a public key and other relevant information to its owner Holder Verification.
Card IDentifier. Number assigned to active PICCs that allows concurrent access to several cards from a single PCD Byte of the Command Message.
CLA Class
CLK Clock.
The reset of an ICC that occurs when the supply voltage (VCC) and other signals to the ICC are raised from the inactive state and the reset (RST) signal is applied.
Cold reset Command A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Command/response pair Set
Contact A conducting element ensuring galvanic continuity between integrated circuit(s) and the external interfacing equipment. Cryptogram Result
of a cryptographic operation.
Page 18
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview CWI Character CWT Character CRC Cyclic Data unit
Redundancy Check
The smallest set of bits that can be unambiguously referenced. Driver Kit.
Encryption Algorithm (ANSI X3.92). Public sector standard for DES. Encryption Standard (FIPS Pub 46).
Dedicated file. File containing file control information, and, optionally, memory available for allocation. It may be the parent of elementary files and/or dedicated files. of bytes that uniquely identifies a DF in the card.
DF name String
DIR file Directory file. An optional elementary file containing a list of applications supported by the card and optional related data elements defined in ISO 7816/5. DSA Digital Signature Algorithm. A cryptographic algorithm used in generating digital signatures as specified in FIPS 180-1. DSS
Digital Signature System. A procedure for generating digital signatures as specified in FIPS 180-1.
EDC Error
Detection Code.
EF
Elementary file. A set of data units or records which share the same identifier. It cannot be a parent of another file. An IFD with extended capabilities. including rejection of a command.
Enhanced IFD
Elementary Time Unit. The nominal bit duration used in communication between an ICC and a reader. Defined in ISO 7816-3, paragraph 6.1.1. Control Information. Logical, structural, and security attributes of a file as defined in
FCI File
ISO/IEC 7816.
File identifier A FMD File Function
management data.
A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction.
Page 19
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview Functional Logical Device
A physical part, a group of physical parts, or a functionality of an IFD exposed as a logical device. This is at the same level as the slot logical device.
GND Ground. Guardtime The minimum time between the trailing edge of the parity bit of a character and the leading edge of the start bit of the following character sent in the same direction. GUI Graphical
User Interface.
Half-duplex transmission Two-way electronic communication that takes place in only one direction at a time. Communication between people is usually half-duplexone listens while the other speaks (Source: Microsoft Press Computer Dictionary). I-block Information block associated with the T=1 protocol and the 14443 transmission protocol. ICC
Integrated Circuit Card. In this specification, used to refer to a plastic card containing an integrated circuit, which is compatible with ISO 7816. A data structure stored on the ICC. It contains the information required for the enhanced card recognition mechanism. A friendly name associated with the ICC .This label is in the UTF-8 format, according to RFC-2279. operating system of an ICC. identifier associated with the ICC OS. It is a part of the ICC Info
ICC Label
ICCOS The
ICCOS-REFID An
Structure.
ICCOSSP
System
ICCSP
A service provider that interfaces ICC functionality. ICCOSSPs and ADSPs are ICCSPs. specific implementation of the ICC technology. Electrotechnical Commission.
ICC-Type The
Interface Device. A terminal, communication device, or machine to which the integrated circuit(s) card is electrically connected during operation. As used in this specification, refers to a PC peripheral device that supports bidirectional I/O to an ISO 7816 standard ICC.
IFD Service Provider (IFDSP) A
capabilities.
IFD Subsystem The IFS Information
IFD, I/O channel, I/O device driver and IFD handler on the PC side.
Page 20
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview IFSC Information IFSD Information IFSI Information Inactive
Field Size for the ICC associated with the T=1 protocol. Field Size for the terminal associated with the T=1 protocol.
The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0.4 V or less with respect to ground (GND).
INF Information INS Instruction
Byte of Command Message associated with the T=0 and T=1 protocol. Electronic component(s) designed to perform processing and/or file for storing data interpreted by the card.
Integrated Circuit(s)
memory functions.
Internal Elementary File Elementary ISO International Key qualifier An
Key Pad An arrangement of numeric, command, and potentially function and/or alphanumeric keys laid out in an ordered manner. LEN Length. Level Number
of DFs in the path to a file, starting the path from the MF. Redundancy Check associated with the T=1 protocol. Card Terminal
LRC Longitudinal
Message
String of bytes transmitted by the internal device to the card or vice versa, excluding transmission-control characters. file. Mandatory unique dedicated file representing the root of the structure. address associated with the T=1 protocol. ACK.
Nibble Half
a byte. The most significant nibble of a byte consists of bits b8 b7 b6 b5 and the least significant of bits b4 b3 b2 b1. used in the T=0 and T=1 protocol.
Page 21
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview Password
Data that may be required by the application to be presented to the card by its user before data can be processed. Concatenation of file identifiers without delimitation. If the path starts with the MF identifier, it is an absolute path.
Path
PC Personal computer. For purposes of this document, PC refers to any host computer to which the ICC reader is attached. PCB Protocol
Proximity Integrated Circuit(s) Card. Contactless cards operating without mechanical contact to the IFD, using magnetic coupling. Identification Number.
arrangement of alphanumeric and command keys to be used for PIN entry. Application Identifier Extension.
PIX Proprietary
Plug and Play (PnP) A technology that detects the presence of hardware and directs the automatic loading of software drivers for that hardware. It also detects changes in the hardware set and directs drivers to load or unload as a result. (Source: MSDN Development Library) Provider
Authority who has or who obtained the rights to create the MF or a DF in the PICC Identifier
card.
PUPI Pseudo-Unique PTS Protocol RATS
Type Selection.
Request for Answer to Select. Command sent by the PCD to a type A PICC to obtain its ATS.
R-APDU Response R-block Receive RF Radio
APDU.
Ready Block.
Frequency
ICC Reader (or Reader) As used in this specification, refers to the slot of a PC peripheral device that supports bidirectional I/O to an ISO 7816 standard ICC. An IFD may have several slots and therefore be composed of several readers. It is associated with a ReaderName. Record
String of bytes that can be handled as a whole by the card and referenced by a record number or by a record identifier.
Page 22
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview Record Identifier Value associated with a record that can be used to reference that record. Several records may have the same record identifier within an EF. Record number
A sequential number assigned to each record that uniquely identifies the record within its EF. Command, Type A. Command sent by a PCD to probe its energizing field for type A PICC presence.
REQA Request
REQB Request
Command, Type B. Command sent by a PCD to probe its energizing field for type B PICC presence. A message returned by the ICC to the terminal after the processing of a command message received by the ICC. for Future Use. application provider identifier.
Response
RFU Reserved
TPDU.
Acknowledge. Block.
S-block Supervisory
Script A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Secrets Algorithms, SFI Short
File Identifier. Hash Algorithm Rev 1. A one-way hash, or message digest algorithm.
Reader
The terminus (on the PC side) of the ICC communication protocols (ISO 7816-3, ISO 7816-10, or ISO 14443). Messaging.
SM Secure SM
Security Module. A device containing logically and physically protected secrets in such a way that unauthorized access is not feasible. In order to achieve this the module may in addition be further physically, electrically, and logically protected. PIN Entry
SPE Secure
Page 23
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview SPK Secure Presence Key. An isolated key implemented as part of an IFD subsystem. It is designed to provide a user confirmation signal to an ICC. State A Space State H
High state logic level. state logic level. (as defined in ISO 1177).
State L Low
TDOL Transaction
Template A grouping of data objects based upon their location within application structures that gives the context within which the data objects are to be interpreted. The template is given a name (a tag), which is used to reference the context and is also used as the tag for a constructed data object within which the data objects may appear in the value field. TLV Tag-Length-Value. TPDU Transport TTL Terminal UID Unique VCC Supply VCD Vicinity
Transport Layer.
Vicinity Integrated Circuit(s) Cards (VICC): Contactless ICCs which operate without mechanical contact to the VCD using magnetic coupling.VPP Programming Voltage. The reset of an ICC that occurs when the supply voltage (VCC) and the clock (CLK) lines are maintained in their active state and the reset (RST) signal is applied. Indication that an error may have occurred when processing a
Warm reset
Warning condition
command.
Page 24
Interoperability Specification for ICCs and Personal Computer Systems Part 1. Introduction and Architecture Overview WI Waiting
Time Integer. file for storing data not interpreted by the card.
Time Extension.
Page 25