Smart Card Standards
Smart Card Standards

In order to ensure that smart cards, smart card readers and smart card applications are interoperable, international standards are essential. Standardisation also facilitates the acceptance and growth of the smart card industry. In this section, we elaborate on these standards.

Smart card standards have originated from: 

  • International standards organisations (ISO, CEN etc.)
  • Industry based. 

1. International Standards Organisations

1.1 The International Standards Organisation (ISO)

The basis upon which virtually all existing smart cards are based is the ISO 7816 standard [3]. It specifies the physical and electrical characteristics as well as the formats and protocols for information exchange between the smart card and the reader. The ISO 7816 standard is discussed in more detail in chapter 4 and 5. 

1.2 The European Committee for Standardisation

The Comité Européen de Normalisation (CEN) is a European standards organisation located in Brussels. This organisation defines the CEN 726 standard - Requirements for IC cards and terminals for telecommunications use. Many of the pioneering smart card projects originated in Europe and involved telecommunications organisations. Consequently, the development of smart card standards in Europe was geared towards telecommunications use [4]. These standards played a key role in influencing the ISO standards. 

1.3 The European Telecommunications Standards Institute (ETSI)

A subscriber interface module (SIM) is a smart card that is inserted into a GSM (Groupe Spécial Mobile/Global System for Mobile Communications) cellular telephone. The European Telecommunications Standards Institute (ETSI) has published a number of standards dealing with SIMs and their relationship with a GSM phone. In particular, the GSM 11.4 standard provides a specification for the interface between the SIM card and the GSM cellular telephone. In contrast to the master/slave relationship between a smart card and reader defined by ISO 7816, the GSM 11.4 standard allows the SIM to initiate communication with the phone. Consequently the card contains two APIs: one providing services on the card and one providing services on the phone. The file system and encryption algorithms used to authenticate keys on SIM cards are different from those found on other smart cards. 

2. Industry Standards

2.1 EMV

Three bank card associations, Europay, MasterCard and Visa, collaborated in early 1996 to produce the EMV specifications that define an international, open encryption standard to allow safe, easy electronic commerce. It is used in conjunction with the Chip Card Payment System (CCPS) to offer a cross-platform and banking setup for the use of smart cards. Both EMV and CCPS are non-proprietary systems that allow for common smart card chips as well as standard ATM and point-of-sale platforms to be produced by vendors for sales worldwide. The EMV technical specifications are available on the Internet [5]. The EMV specification is being updated to include a specification for the Secure Electronic Transactions (SET) smart card. The EMV specification comprises three parts:
  • Smart card
  • Terminal
  • Interaction between the application and the card
The EMV specification defines smart card transaction processing and so is more than an API. It is also unique in that it describes a multiapplication smart card - a smart card that contains more than one application. However, the major shortcoming of the EMV architecture is the lack of a well-defined method for sharing data. For example, a cardholder would only want to maintain one set of personal data (e.g. identity number, address, telephone numbers etc.) that would be used by various applications. 

2.2 OpenCard Framework (OCF)

OpenCard was developed by a consortium including IBM, Netscape, NCI and Sun Microsystems [6]. It is an open standard that does not restrict the use of smart cards to computers but provides inter-operability of smart card applications across Network Computers, Point-Of-Sale terminals, laptops etc. OpenCard provides an architecture and a set of APIs that enable application developers to build applications in Java which use smart card readers on any target platform. The Figure 3.1 shows the components comprising the OpenCard Framework architecture.

Figure 3.1: Components of the OpenCard Framework Architecture [7].

The CardTerminal component encapsulates all the card reader related classes. A reader can only be accessed through classes in the card terminal component. The CardAgent component facilitates the interaction with a number of card operating systems. This is the only component that is not directly accessible by the applications. The CardIO component provides access to the file system of a smart card i.e. an application can open, read and write to elementary files on a card. The CardAgentExtensions component offers interfaces to specific smart card functionality such as cryptographic services or other application specific commands.

In addition, the Version 1.0 reference implementation also enables interaction with existing Personal Computer/Smart Card 1.0 supported reader devices. 

2.3 Personal Computer/Smart Card (PC/SC)

Microsoft and several other leading personal computer and smart card companies (including Schlumberger, Bull CP8 Transac, Hewlett-Packard, Siemens Nixdorf Information Systems and IBM) founded the PC/SC Workgroup which resulted in PC/SC which is an interface for communication between smart cards and Win32-based platforms for personal computers [8]. This specification was published in December 1996 and is called the Interoperability Specification for ICCs and Personal Computer Systems (mostly referred to as PC/SC). The PC/SC specification includes a description of the general-purpose interface as well as card authorisation, PIN verification, file access and cryptographic services.

The purpose of the PC/SC architecture and specification is to allow smart card manufacturers and reader manufacturers to develop their products independently. In addition, application programmers can develop smart card applications that are not dependent on a particular type of reader. Figure 3.2 illustrates the PC/SC architecture.

Figure 3.2: The PC/SC architecture.

The PC/SC architecture defines an interface between smart card readers and a resource manager. So, from an application’s viewpoint, all readers behave in the same way. The reader manufacturer then provides a PC/SC driver that connects the reader to the resource manager. The API as seen by the application is provided by the smart card service provider (SSP). This interface can be card-specific, domain-specific or general purpose. Card-specific service providers are generally written by smart card manufacturers and provided together with the smart cards. These SSPs provide applications with easy-to-use commands supported by the particular card. 

2.4 JavaCard

JavaCard was introduced by Schlumberger and submitted by JavaSoft as a standard. JavaCard is a subset of the Java programming language that is interpreted on a standard 8-bit smart card microcontroller. It is comprised of standard classes and APIs that enable Java applets to run directly on an ISO 7816 compliant smart card [9]. JavaCard does not include 32 or 64-bit data types, threads, multidimensional arrays or garbage collection. Smart card specific libraries (such as EEPROM management, security, T=0 and T=1 communication, data protection) are provided to allow programmers to develop applications independent of the underlying specific hardware. In addition to providing APIs, JavaCard also specifies the card initialisation, personalisation and secure loading and development aids.

Figure 3.3: The JavaCard architecture [10].

  Today, there have been 2 visitors (9 hits) on this page!  
Free Domain This site was last updated Monday, 23 January 2017
Copyright © 2006-2017 smfaizhaider. All rights reserved.