Smart Card Commands
Communications procedures between a terminal and a smart card are always based on the master–slave principle. This means that the terminal, acting as the master, sends a command to the card, which as the slave immediately processes the command, generates a response and returns its response to the terminal. The card thus never sends data without first having received a corresponding command from the terminal. Even the ATR is no exception to this rule, since it is a response to the reset signal, which is also a type of command to the card. Actual communications always employ a transmission protocol, such as T = 0 or T = 1. These relatively uncomplicated protocols meet the special requirements of smart card applications and are optimized for this purpose. Deviations from these precisely specified protocols within application procedures are not permitted. The transmission protocols allow data to be sent to the card and received from the card in a manner that is completely transparent to the transport layer. The data are embedded in a sort of container called an application protocol data unit (APDU). APDUs sent by the terminal to the card are the commands to the card. The terminal also receives the responses to its commands in APDUs embedded in the transmission protocol. There are a large number of commands based on this mechanism, and they initiate specific activities within the card. The simplest examples are read and write commands for smart card files. In smart card applications, the card is used as a data storage medium, an authorization medium or both at the same time. This has led to the generation of command sets that are optimized for these applications and transmission protocols and that are used only in the smart card realm. Due to the severely limited memory capacity of smart cards, combined with market pressure to allow only moderate increases in this capacity for cost reasons, command sets are usually tailored to specific applications. All commands that are not needed in a given application are relentlessly removed during program optimization. Only a few operating systems exhibit extensive command sets that have not been reduced to those needed for a particular application. A diversification effect is also seen with smart card command sets, as is typical with new technologies. Each company active in this area attempts to create its own commands that are tailored to the needs of its operating system or anticipated application. This often arises from necessity, since functionally equivalent commands may not exist in the standards. Companies may also deliberately attempt to improve their positions relative to the competition, or to deny their competitors access to a particular application area, by using commands that are highly optimized with regard to card functions and memory usage. In any case, a decision to use commands based on available standards always means choosing an open, more easily expandable and proven system, which may later allow additional functions to be incorporated into a single card. On the other hand, there are many examples of systems in which the use of smart cards was only made possible by using highly optimized special commands. There are currently 13 international standards and more or less stable draft versions of standards that define typical smart card commands. They define considerably more than 100 commands, along with their associated procedures. To a large extent, the defined commands are mutually compatible in terms of coding and functionality.

The majority of the commands currently used with smart cards are defined in the ISO/IEC 7816-4 standard, which is a general international standard. It is not dedicated to any particular area, such as telecommunications or financial transactions, but instead attempts to address all smart card applications. The commands in ISO/IEC 7816-4 are complemented by three supplementary, specialized sections of this family of standards. ISO 7816-7 defines commands for querying and managing smart card databases with structures based on structured query language (SQL). ISO/IEC 7816-8 contains commands for executing and parameterizing cryptographic functions, and Part 9 of the ISO/IEC 7816 family adds file management commands to the basic command set. There is no significant international standard in the area of financial transactions, but there is an industry standard. This is the EMV specification, whose name comes from the initial letters of Europay, MasterCard and Visa, the three initiators of this specification. Due to the strong market position of the companies behind it, this specification has achieved the status of a reference for all smart card operating systems, and it has the same degree of significance as the ISO/IEC 7816 family of standards. The GSM 11.11 specification, which was developed for use in the telecommunications area, forms the normative basis for the SIM, while the TS 13.101, TS 31.111 and TS 102.222 standards specify the basic commands for the USIM. Due to the simple fact that a tremendous number of smart cards are used in telecommunications applications, these standards represent a de facto standard for commands for smart card operating systems. In principle, special commands used only in a restricted area are not covered by these standards and must therefore be specified individually. One example is the command set specified for multisector electronic purse systems, which is defined in the CEN EN 1546 standard. This European standard defines all commands necessary for an electronic purse, along with the associated procedures. A standard such as this, which is limited to a single application, arises only in areas of particular interest to government agencies or specific branches of industry, due to the very high cost of generating such standards. The commands in the standards and specifications described above can be classified according to their functionalities. However, it must be remembered that only subsets of all these commands are implemented in real-life smart card operating systems. Depending on the producer of the operating system, more or less significant deviations from the functionality and coding described in this chapter may be encountered. However, the basic functions described here are in principle present in all operating systems. Of course, the functionality may be severely restricted due to considerations of memory capacity or cost. Whenever a new application is being planned, exact specifications of the coding and functions of all of the commands must be requested from the producer(s) of the operating system(s) under consideration. The following sections describe the most important and most widely used smart card commands. The basis for this selection is formed by the following standards and specifications: ISO/IEC 7816-4/7/8/9, EMV 2000, GSM 11.11, TS 311.111, EN 726–3 and EN 1546–3. Extensive tables listing the coding of the most important smart card commands can be found in Section 16.10.7, ‘Smart card command encoding’. Naturally, it is impossible to buy a single smart card anywhere in the world that contains all the commands described here. As a conservative estimate, the memory required for their full implementation would be five to 10 times as large as the total amount of memory in the largest currently available smart card microcontrollers. However, it is not at all necessary for a smart card to be able to execute all of these commands. Depending on the intended application area
and operating system, certain classes of commands may be supported more comprehensively than others.

For example, with a multiapplication card you would certainly want to make sure that additional applications can be installed in the card after it has been personalized. A card for cryptographic applications, assuming it has adequate memory capacity, will contain the full spectrum of cryptographic commands, along with the various algorithms. Each application area requires a different selection of commands from the various classes. In each of the following descriptions, the standard or specification in which the command is defined is identified in order to maintain an overview. If no source is given, the command in question is used internally by smart card manufacturers and cannot be assigned to any of the above-mentioned standards. Some of these commands are nonetheless very useful and will probably be incorporated into a standard in the future. They thus are listed here with descriptions of their basic functionality. In the interest of readability, we have omitted descriptions of the coding of typical smart card commands in this chapter. This information can be found in Section 16.10.7, ‘Smart card command encoding’. Some commands are supported by nearly all smart card operating systems and have only a limited number of options. For such commands, the command and response APDUs are fully decoded in their descriptions. The internal processing sequences of seven typical commands are also shown in psuedocode in Chapter 5 in the description of the ‘Small OS’ operating system. For a given application, smart card commands can be classified into operational commands, which are commands needed for normal use, and administrative commands, which are commands needed for managing the smart cards and the application. For reasons related to interoperability, operational commands are generally specified in complete detail in the standards. Administrative commands are often specific to particular operating systems and are not necessarily specified by standards. For each command, the response shown in its description is the one received by the terminal in the event of successful execution. Otherwise, if an operation is forbidden or an error occurs in the card, the terminal receives only a 2-byte return code. Some of the described commands also have parameters for selecting additional functions. These options often exist only in the standard, rather than in actual operating systems, since they may be too complicated or have no practical significance. Therefore, this chapter does not list or explain every option defined in the standards, since our aim is to concentrate on practical functions. In describing the commands, we have generally used the standard that has the largest number of functional options for the command in question.