Smart Card Handbook phần 5 pot

Administrative commands are often specific to particular operating systems and are notnecessarily specified by standards.com-Command classes part 1: card usage security file operations rea

SELECT FILE [FID = '3F00']

response to SELECT FILE

SELECT FILE [FID = '3F00']

response to SELECT FILE

SELECT FILE [FID = '3F00']

response to SELECT FILE

Figure 6.38 Successful transmission of a TPDU using the T= 1 transmission protocol The XORoption is used for the error detection code (EDC) A SELECT FILE command with a FID of'3F00',which selects the MF, is transmitted in the APDU The incrementing of the send sequence count in thePCB byte for each transaction, and the corresponding changes in the EDC, can be readily seen

used The elaborate error correction mechanisms are a typical example Although they may betheoretically interesting, in many cases they are ineffective in dealing with actual transmissionerrors In practice, it is usually better to simply reinsert the card in the terminal and start anew session, rather than using innumerable resynchronization requests to attempt to restabilizecommunications Consequently, the EMV specification imposes several restrictions relative tothe original ISO/IEC standard, as summarized in Table 6.40

6.4.4 The T = 14 transmission protocol (Germany)

The ISO/IEC 7816-3 standard includes a tag in the ATR for designating a national sion protocol Such a transmission protocol is designated T= 14 With the introduction ofthe C-Netz for mobile telephony and card phones in Germany, a protocol was needed forcommunicating with the smart cards used in these systems The character-oriented T= 0protocol was considered undesirable, and at that time there was not yet a standardized block-oriented protocol Consequently, in 1987 Telekom decided to use a protocol developed by aDIN working group This protocol received the designation T= 14, which simply means that

transmis-it is a country-specific implementation It had no significance outside of Germany, but transmis-it had

Table 6.40 Summary of the differences in the implementation of the T= 1 transmission protocolbetween the ISO/IEC 7816-3 standard and the EMV specification

Mechanism or option ISO/IEC 7816-3 EMV

BWT expired Reset the card (for example) Deactivate the card

Smart card sends a request Allowed A maximum of three

to change the IFS successive requests is allowedSmart card sends an S block Allowed Deactivate the card

with an abort request

Zero-length I block Allowed Prohibited

Terminal sends three Behavior according to Deactivate the card

successive blocks without specified error handling;

receiving a valid response usually a resync request

enormous influence on the development of the internationally standardized T= 1 protocol,since the T= 14 protocol formed the principal foundation for this protocol

The T= 14 protocol was used extremely widely in Germany, since it was employed in theC-Netz mobile telecommunications network and public card phones With the closing down ofthe C-Netz at the end of 2000 and the change to the T= 1 protocol for public card phones, the

T= 14 protocol is no longer an important protocol in Germany, which is why it is describedhere only briefly

The T= 14 protocol has a block-oriented structure and works asynchronously using theapplied clock signal The divider (clock rate conversion factor) has a value of 512, which yields

a data transmission rate of 9600 bit/s at a clock frequency of 4.9512 MHz Data transmission

at layer 2 (the data link layer) always takes place using the direct convention The size of thebuffers for transmitted and received blocks must be at least 50 bytes, with a maximum value

of 255 bytes There is no block chaining mechanism

6.4.5 The USB transmission protocol

A future amendment to the ISO/IEC 7816-3 standard will contain a specification for a newtransmission protocol for smart cards This is the Universal Serial Bus (USB) protocol, whichhas come to prevail over competing protocols, such as Firewire and the like, for use with smartcard applications

The USB protocol requires a special hardware component in the smart card microcontroller,but this component is already present in many chips, at least as an option The major advantage

of USB with respect to currently used transmission protocols is that it is an established industrialstandard coming from the PC world USB also offers a higher transmission rate than T= 0 or

T= 1

It presently appears that Version 1.1 of the USB specification will be used for smart cards,with both the low-speed option (1.5 Mbit/s) and the full-speed option (12 Mbit/s) being sup-ported, depending on the type of microcontroller It should be noted that the effective trans-mission rate is significantly lower than the stated values once the required protocol data havebeen subtracted USB Version 2.0, which has a data transmission rate of up to 480 Mbit/s (inthe high-speed mode), will not be used in the foreseeable future

Contacts C4 (AUX1) and C8 (AUX2), which up to now have been specified but not used,will be used to implement the USB interface in smart cards Further details will be specified

in the above-mentioned standard, but it can be expected that it will take several years until all

of the related standardization work is completed

6.4.6 Comparison of asynchronous transmission protocols

With regard to comparing the various transmission protocols, a brief remark with regard toachievable data transmission rates is in order Attempts are often made to compare the T= 0 and

T= 1 protocols based on calculated effective transmission rates However, such calculationsare only valid for specific commands in specific contexts If they are generalized, they becomemeaningless and invalid

Both protocols have their strengths and weaknesses with regard to achievable transmissionrates These are strongly dependent on very many individual factors, such as the transmissionerror rate, the size of the I/O buffer in the card and the specific implementation of the protocol Inshort, it can be assumed that on average and with most applications, the effective transmissionrates of both protocols are nearly the same If you want to increase the transmission rate,changing the protocol will have little effect It is more effective to reduce the divider value,since this yields significantly better results

Two international transmission protocols have been described in the previous sections Inorder to provide an overview, Table 6.41 summarizes the essential features of these protocols,

as well as their advantages and disadvantages

Table 6.41 Comparison of internationally standardized asynchronous data transmission protocolsCriterion T= 0 T= 1 T= 2 (proposed)Data transmission asynchronous, asynchronous, asynchronous,

half-duplex, half-duplex, full-duplex,byte-oriented block-oriented block-orientedStandard ISO/IEC 7816-3, ISO/IEC 7816-3, ISO/IEC 10536-4

GSM 11.11, EMV EMVDivider freely definable, freely definable, freely definable,

usually 372 usually 372 usually 372Block chaining not possible possible possible

Error detection parity bits parity bits, parity bits,

EDC at end of block EDC at end of blockMemory required ≈300 bytes ≈1100 bytes ≈1600 bytesfor implementation

6.5 MESSAGE STRUCTURE: APDUs

Applications protocol data units (APDUs) are used to exchange all data that passes betweenthe smart card and the terminal The APDU is an internationally standardized data unit for theapplication layer, which is layer 7 in the OSI model In smart cards, this layer is located directly

above the transmission protocol layer The protocol-dependent data units of the transmissionprotocol layer are called ‘transmission protocol data units’ (TPDUs ).

A distinction is made between command APDUs (C-APDUs), which represent commands

to the card, and response APDUs (R-APDUs), which represent replies to these commands fromthe card In simple terms, an APDU is a sort of container that holds a complete command tothe card or a complete response from the card APDUs are passed by the transmission protocoltransparently, which means without modification or interpretation

APDUs that comply with the ISO/IEC 7816-4 standard are intended to be independent ofthe transmission protocol Consequently, the content and format of an APDU must not changewhen a different transmission protocol is used This applies above all to the two standardprotocols, T= 0 and T = 1 This demand for protocol independence affects the structure of theAPDUs, since it must be possible to transmit them transparently using both the byte-oriented

T= 0 protocol and the block-oriented T = 1 protocol

6.5.1 Structure of the command APDU

A command APDU is composed of a header and a body The body may have a variable length,

or it may be entirely absent if the associated data field is empty

CLA INS P1 P2 Lc field data field Le field

Figure 6.39 Structure of a command APDU

The header consists of four elements, which are the class byte (CLA), the instruction byte(INS) and two parameter bytes (P1 and P2) The class byte is also used to identify applicationsand their specific command sets For instance, the class byte'A0'is used for GSM, while thecode'8X' is most commonly used for company-specific (private-use) commands ISO-basedcommands are coded by class byte'0X' The standard additionally specifies the class bytes

to be used to indicate the use of secure messaging and logical channels All of this is stillcompatible with using the class byte as an application identifier

The next byte in the command APDU is the instruction byte, which encodes the actualcommand Almost the entire address space of this byte can be exploited, with the sole restrictionthat only even codes can be used This is because the T= 0 protocol allows the programmingvoltage to be activated by returning the instruction byte incremented by one in the procedurebyte The instruction byte thus always has had an even value.17

The two parameter bytes are primarily used to provide more information about the commandselected by the instruction byte They thus serve mainly as switches that select various commandoptions For example, they are used to choose various options for SELECT FILE or specifythe offset for READ BINARY

17 See also Section 16.11.5, ‘The most important smart card commands’

Table 6.42 The most important class byte (CLA) codes according to ISO/IEC 7816-4

b8–b5 b4 b3 b2 b1 Meaning

X X Logical channel number

0 0 Secure messaging not used

0 1 Non-ISO secure messaging using a private method 1 0 ISO secure messaging, header not authentic

1 1 ISO secure messaging, header authentic

'0' Structure and coding compliant with ISO/IEC 7816-4/7/8

'8','9' Structure compliant with ISO/IEC 7816-4,

user-specific coding and meaning of commandsand responses (private use)

'A' Structure and codes compliant with ISO/IEC 7816-4,

specified in supplementary documents (e.g GSM 11.11)

'F' 1 1 1 1 Reserved for PPS

Table 6.43 Summary of the assignment of class bytes to applications

Class Application

'0X' Standard commands compliant with ISO/IEC 7816-4/7/8

'80' Electronic purses compliant with EN 1546-3

'8X' Application-specific and company-specific commands (private use)

'8X' Credit cards with chips, compliant with EMV

'A0' GSM mobile telecommunication systems compliant with GSM 11.11

The section following the header is the body, which can be omitted except for a lengthspecification The body serves a dual function First, it specifies the length of the data sectionsent to the card (in the Lc field)18and the length of the data section to be sent back from the card(in the Le field).19Second, it contains the data for the commands that are sent to the card If thevalue of the Le field is'00', the terminal expects the card to return the maximum amount of dataavailable for the command This is the only exception to the numerical description of the length.The Le and Lc fields are usually one byte long, but they can be converted into fields that areeach three bytes long Such fields can be used to represent lengths up to 65,536, since the firstbyte contains the escape sequence'00' The standard defines this three-byte length specificationfor future applications Due to the limitations of currently available memory sizes, it has notyet been implemented

The previously described parts of the command APDU can be combined to produce thefour general cases illustrated in Figure 6.41

18 ‘Lc’ stands for ‘length command’

19 ‘Le’ stands for ‘length expected’

'00'byte 1 byte 2 byte 3

Figure 6.41 The four possible command APDU cases

6.5.2 Structure of the response APDU

The response APDU, which is sent by the card in reply to a command APDU, consists of anoptional body and a mandatory trailer, as shown in Figure 6.42 The body consists of the datafield, whose length is specified by the Le byte of the preceding command APDU Regardless

of the value specified in the Le byte, the length of the data field can be zero if the smart cardterminates command processing due to an error or incorrect parameters This is indicated inthe two single-byte status words SW1 and SW2 in the trailer

SW1 SW2 data field

trailer body

Figure 6.42 Structure of the response APDU

type 1 SW1 SW2

Figure 6.43 The two types of response APDUs

The card must always send a trailer in response to a command The two bytes SW1 and SW2,which are also called the ‘return code’, encode the response to the command For example, thereturn code'9000'means that the command was executed completely and successfully Thereare more than 50 different codes Their basic classification scheme is shown in Figure 6.44.20

return code (SW1 || SW2)

warning processing execution error checking error normal processing

'61XX'

'9000'

6FXX' '

Figure 6.44 Return code classification scheme as defined by the ISO/IEC 7816-4 standard The returncodes'63XX'and'65XX'indicate that data in non-volatile memory (EEPROM) have been altered, whilethe remaining'6X'codes indicate that this has not occurred

If a'63XX' or '65XX' return code is received after a command has been executed, thismeans that the card’s non-volatile memory (usually the EEPROM) has been modified Ifanother code starting with'6X' is returned, command execution was terminated prematurelywithout modifying the non-volatile memory

It should be noted that although there is a standard for return codes, many applications usenon-standard codes The only exception is the code'9000', which almost universally indicatessuccessful processing With all other codes, it is always necessary to consult the relevantspecification in order to be sure of their meanings

6.6 SECURING DATA TRANSMISSIONS

The entire data exchange between a terminal and a smart card uses digital electrical pulses onthe I/O line of the smart card It is conceivable and not technically difficult to solder a wire

to the I/O contact, record all the communications for a session and later analyze them In thisway, it is possible to gain knowledge of all the data transmitted in both directions

A somewhat more difficult task is to electrically isolate the I/O contact, mount a dummycontact on top of it, and then use thin wires to connect both of these contacts to a computer.With this arrangement, it is easy to allow only certain commands to reach the card or insert

‘foreign’ commands into the communications sequence

Both of these typical types of attack can succeed only if secret data passes unprotected overthe I/O line Data transmission should thus basically be designed such that even if an attacker

20 See also Section 16.10.8, ‘Smart card return codes’

is able to eavesdrop on data transmissions and insert his own message blocks, he will not beable to gain any advantage from doing so.

There are various mechanisms and methods that can be used to protect against these attacksand against even more sophisticated types of attack They are collectively referred to as ‘securemessaging’ These mechanisms are not specific to smart cards, and they have been used for

a long time in data communications systems What is special in the smart card domain isthat neither the processing capacity of the communicating parties nor the transmission rate isparticularly great Consequently, commonly used standard methods have been scaled down

to match the capabilities of smart cards, without in any way reducing the security of thesemethods

The objective of secure messaging is to ensure the authenticity, and if necessary the fidentiality, of part or all of the transmitted data A variety of security mechanisms are used

con-to meet this objective A security mechanism is defined as a function requiring the followingitems: a cryptographic algorithm, a key, an argument and initial data as necessary A generalcondition must also be satisfied, which is that all security mechanisms must behave completelytransparently with regard to existing protocol layers, in order to ensure that existing, standard-ized procedures are not adversely affected by secure messaging This applies particularly tothe two transmission protocols T= 0 and T = 1, as well as to commonly used standard smartcard commands

Before using a secure messaging method, both parties must agree on the cryptographicalgorithm to be used and a common secret key According to Kerckhoff’s principle, the security

of the method relies entirely on this key If it is revealed, secure messaging is reduced to agenerally known additional checksum that decreases the effective data transmission rate and

at best can be used to correct transmission errors

Several different types of secure messaging methods have been known for many years Theyare all relatively rigid and tailored to specific applications Most of them cannot be faulted asfar as security is concerned However, none of them has become internationally predominant

or has proved to be sufficiently flexible to be included in current standards

Security mechanism

key cryptographic algorithm

initial data (optional) argument

Figure 6.45 The data and functions required for a security mechanism

The requirements of transparency with respect to existing commands, use with two damentally different transmission protocols and maximum adaptability have led to the stan-dardization of a very flexible (and correspondingly complex and elaborate) secure messagingmethod in the ISO/IEC 7816-4 standard, with additional related functions defined in ISO/IEC

fun-7816–8.21This method is based on embedding all user data in TLV-coded data objects Threedifferent types of data objects are defined:

rdata objects for plaintext: contains data in plaintext

(e.g., the data section of an APDU)

rdata objects for security mechanisms: contains the results of a security mechanism

(e.g., a MAC)

rdata objects for auxiliary functions: contains control data for secure messaging

(e.g., the padding method used)The class byte indicates whether secure messaging is used for the command The twoavailable bytes can encode whether the method specified in ISO/IEC 7816-4 is used andwhether the header is also included in the cryptographic checksum (CCS).22 If the header isincluded in the computation, it is authentic, as it cannot be changed during the transmissionwithout this being evident

Data objects for plaintext

According to the standard, all data that are not BER-TLV coded must be encapsulated, whichmeans they must be embedded in data objects Several different tags are used, as shown inTable 6.44 Bit 1 of each tag indicates whether the data object is included in the computation

of the cryptographic checksum If this bit is not set (e.g.,'B0'), the data object is not included

in the computation, while if it is set (e.g.,'B1'), the data object is included

Table 6.44 Tags for plaintext data objects

Tag Meaning

'B0','B1' BER-TLV coded; contains data objects related to secure messaging

'B2','B3' BER-TLV coded; contains data objects not related to secure messaging

'80','81' No BER-TLV coded data

'99' State information for secure messaging

Data objects for security mechanisms

The data objects used for security mechanisms are divided into those used for authenticationand those used for confidentiality The tags defined for this purpose are listed in Tables 6.45and 6.46

Here ‘authenticity’ refers to all data objects related to cryptographic checksums and digitalsignatures Data encryption, and marking such data as encrypted in the context of secure

21 Secure messaging is usually abbreviated to ‘SM’, which many programmers interpret as ‘sado-masochism’ on account of the many degrees of freedom and room for interpretation provided by these two standards

22 For the coding of the class byte, see Section 6.5.1, ‘Structure of the Command APDU’

Table 6.45 Tags for authentication data objectsTag Meaning

'84','85' Cryptogram; the plaintext is BER-TLV coded and does not include data objects

for secure messaging

'86','87' Indicates the padding method used:

'01'– padding with'80 00 '

'02'– no padding

messaging, fall under the heading of ‘confidentiality’ The tags listed shown in the abovetables must be used for secure messaging according to the type of method used

Data objects for auxiliary functions

The data objects for auxiliary functions are used in secure messaging to coordinate the generalconstraints The two parties use these data objects to exchange information about the cryp-tographic algorithms and keys used, initial data and similar basic information In principle,these items can be different for each transmitted APDU, or even between a command andits response In practice, though, auxiliary function data objects are rarely used, since all ofthe general constraints for secure messaging are defined implicitly, so they do not have to bespecifically defined during communications

Based on the options for secure messaging specified in ISO/IEC 7816-4, which have beenonly briefly outlined above, we can describe two fundamental procedures We have kept thesedescriptions as simple as possible in order to make it easier to understand the complex mecha-nisms involved Due to the high degree of flexibility provided by the standard, there are manyother possible combinations of security mechanisms, some of which are even more complex.The two procedures described here represent a compromise between simplicity and security.The ‘authentic mode’ procedure uses a cryptographic checksum (CCS or MAC) to protectthe application data (APDU) against manipulation during transmission The ‘combined mode’procedure, by contrast, is used to completely encrypt the application data, so that an attackercannot draw any conclusions about the data content of the commands and responses that areexchanged A send sequence counter is only used with one of these two procedures Thiscounter, whose initial value is a random number, is incremented for each command and each

response This allows both parties to determine whether a command or response has beenomitted or inserted When a send sequence counter is used in combination with the ‘combinedmode’ procedure, identical APDUs appear to be different This is called ‘diversity’.

6.6.1 The authentic mode procedure

The authentic mode procedure guarantees authentic transmission of APDUs, which meansthat the APDUs are protected against manipulation during transmission The recipient of anAPDU, which means a command or a response, can determine whether it has been alteredduring transmission This makes it impossible for an attacker to modify data within an APDUwithout this being noticed by the recipient

The fact that this procedure is being used is indicated by a bit in the class byte, so that therecipient can act accordingly and check the received APDU for authenticity The actual APDUsare sent in plaintext and are not encrypted The transmitted data are thus still public, and withsuitable manipulation of the transmission channel they could be intercepted and evaluated by

an attacker This is not necessarily a disadvantage, since with respect to privacy legislation

it is better not to send confidential data via a public channel In addition, the card user is atleast theoretically allowed the possibility of seeing what data are exchanged between his orher smart card and the terminal

In principle, any block encryption algorithm can be used to compute the cryptographicchecksum For practical reasons, we assume that DES is used with a fixed 8-byte block length.The individual data objects must therefore be ‘filled out’ to an integer multiple of eight bytes,which is known as padding In this process, data objects that are already an integer multiple ofeight bytes are nevertheless extended by one block After padding, the cryptographic checksum(CCS) of the entire APDU is computed using the DES algorithm in CBC mode This 8-bytechecksum is appended directly to the APDU as a TLV-coded data object, with the four leastsignificant bytes omitted All padding bytes are deleted after the checksum has been computed.The modified APDU is then sent via the interface This procedure extends the length ofthe APDU by eight bytes, which only marginally reduces the transmission rate if normaltransmission block sizes are used

The data objects for the control structures can also explicitly identify the algorithm andpadding method that are used Here again we assume for the sake of simplicity that the smartcard and the terminal implicitly know all the parameters of the secure messaging system beingused

When the protected APDU arrives at the recipient, the latter again pads it to an integermultiple of eight bytes and then computes its own MAC for the APDU By comparing theMAC it has generated with the MAC generated by the sender, the recipient can determinewhether the APDU has been altered during the transmission

A prerequisite for computing a cryptographic checksum is a secret DES key that is known toboth parties If this key were not secret, an attacker would be able to break the authentic modecommunication procedure by intercepting an APDU, modifying it as desired and computing anew ‘correct’ MAC After this, he would only have to replace the original MAC with the newone and send the newly created APDU on its way

In order to better protect the keys used to generate the MAC against attacks based on knownplaintext–ciphertext pairs, dynamic keys are normally used These are generated by encrypting

Step 1

Step 2

Step 3

Step 4

Figure 6.46 Generating a command APDU using the authentic mode procedure This example uses

a case-3 command (e.g UPDATE BINARY), with its header included in the cryptographic checksum(CCS) A response APDU can be generated in a similar manner ‘PB’ indicates the padding bytesStep 1: The initial format of the APDU

Step 2: The data section is converted into TLV-coded data, and the data

objects are padded to an integer multiple of eight bytes

Step 3: The CCS is computed

Step 4: A TLV-coded data object containing the CCS is added to the APDU

a random number that has been previously exchanged between the terminal and the card Asecret key known to both parties is used for this encryption

The additional steps that are needed for the transmission and reception of an APDU that isprotected by the authentic mode procedure naturally reduce the effective data transmission rate

On average, a good approximation is to assume that the rate will be half of that for unprotectedplaintext

6.6.2 The combined mode procedure

Compared with the authentic mode procedure, the combined mode procedure represents thenext higher level of security The data section of the APDU is no longer transmitted as plain-text, but instead in an encrypted form The procedure is an extension of the authentic modeprocedure

In the combined mode procedure, as in the authentic mode procedure, the data objects to beprotected with a cryptographic checksum are first padded to an integer multiple of eight bytesand then encrypted using the DES in CBC mode The header is excluded from this process,

as required for compatibility with the T= 0 protocol (If it is desired to encrypt the header

as well, so that the command being sent the card is unrecognizable, the T= 0 ENVELOPEcommand must be used.) One bit in the class byte indicates the use of secure messaging Thedata are transmitted across the interface after they have been encrypted Since the recipientknows the secret key that was used for encryption, it can decrypt the APDU The recipient thenchecks the correctness of decryption by recomputing the appended cryptographic checksum

in the same level of the transmission layer

When this procedure is used, an attacker eavesdropping on the I/O line cannot discoverwhich data are exchanged between the card and the terminal in the command and response

It is also not possible to replace one of the encrypted blocks within the APDU, since the

PB

TDATA

TDATA

TCCS TDATA

T'DATA

LDATA

LDATA

LCCS LDATA

L'DATA

key (secret)

key (secret)

Figure 6.47 Generating a command APDU using the combined mode procedure This example uses

a Case 3 command (e.g UPDATE BINARY), with its header included in the cryptographic checksum(CCS) A response APDU is created in a similar manner The padding bytes are indicated as ‘PB’.Step 1: The initial format of the APDU

Step 2: The data section is converted into TLV-coded data, and the data

objects are padded to an integer multiple of eight bytes

Step 3: The CCS is computed

Step 4: A TLV-coded data object containing the CCS is added to the APDU

Step 5: The APDU data section is encrypted

blocks are linked to each other by using the DES in CBC mode Any replacement would beimmediately noticed by the recipient.

With regard to the cryptographic algorithm, the comments made in the description of theauthentic mode procedure apply here as well In principle, any block encryption algorithm can

be used The keys should be dynamic, as with the authentic mode procedure, which means thatsession-specific derived key should be used for every session

With regard to the security benefits, general usage of the combined mode procedure for allAPDUs can be recommended However, increased security is accompanied by a considerablereduction of the effective transmission rate A good approximation for the difference in thetransmission rates for unprotected APDUs and those protected using the combined modeprocedure is a factor of four The speed difference between the authentic mode and combinedmode procedures thus amounts to a factor of two It is therefore necessary to carefully examineeach case, in order to determine which data should be transmitted in such a secure but time-consuming fashion

6.6.3 Send sequence counter

Using a send sequence counter mechanism for secure messaging does not by itself constitute

a security mechanism It only makes sense to use a send sequence counter in combinationwith the authentic mode or combined mode procedure, since otherwise any modification ofthe count by an attacker would remain undetected

The working principle of a send sequence counter is that each APDU contains a sequencenumber that depends on when it is sent This allows the deletion or insertion of an APDU in thecourse of the procedure to be immediately noticed, so that appropriate measures (terminatingthe communications) can be taken by the recipient

This function is based on a counter that is initialized with a random number This number

is sent to the terminal by the card at the start of the communications process, in response to arequest from the terminal The counter is incremented each time an APDU is sent The countershould not be too short, but it should also not be too long, in order to avoid generating excessivetransmission overhead The following description assumes the commonly used value of twobytes, but longer counters may be used in practice

There are two basic ways to incorporate a sequence count into command and responseAPDUs The counter value can be placed directly in the APDU as a numerical value in a dataobject, or the counter value may be XOR-ed with a matching amount of data in the APDU,following which a cryptographic checksum is computed and the modified data are restored

to the APDU The recipient of this APDU knows the expected counter value, and can usethis value to modify the APDU in the same way as the sender After this it can compute thecryptographic checksum and check the correctness of the received APDU

The following process takes place during communications The terminal first requests aninitial counter value from the smart card The smart card returns a two-byte random number tothe terminal The terminal then sends the first secured command to the card, accompanied by

a send sequence count Either the authentic mode or combined mode procedure can be used

to protect the counter and the body The card receives the protected APDU and first checkswhether there is any sign of manipulation, based on the authentic mode or combined mode

SSC XOR

Figure 6.48 Two options for a send sequence count in a command APDU In the first option, the sendsequence counter is a TLV-coded data object in the data section In the second option, the send sequencecount is only coupled to the APDU data by an XOR operation used to compute the CCS

procedure It then compares the counter value to the expected value If these values match, noAPDU has been inserted or deleted during the transmission

generate an

initial value x

for the SSC

communications process using the SSC ASK RANDOM

APDU with SSC = x+4

random number as initial value for the SSC

APDU with SSC = x+3

APDU with SSC = x+2 APDU with SSC = x+1

Figure 6.49 Transmitting APDUs using a send sequence counter (SSC)

It is apparent that using a send sequence counter is attractive not only when several mands have to be executed in a particular order, but also for individual commands, since eachsession is made unique if a counter is used Using a counter primarily provides protectionagainst ‘replaying’ previously sent APDUs and deleting APDUs

com-If a send sequence counter is used together with the combined mode procedure, eachencrypted block is different, which creates a condition known as diversity This is the result of

incrementing the counter for each APDU and the fact that with a good encryption algorithm,changing a single bit in the plaintext affects the appearance of the entire ciphertext block.

to which application.23 This permits up to four logical channels,24 so up to four sessionswith applications in the card can run in parallel However, there is a limitation with regard

to communicating with the various applications in the smart card, which is that the externalprocesses that access the card must be mutually synchronized and are not allowed to interleavetheir commands, since the response APDU from the card does not contain any informationabout the logical channel of the originating command This means that it is impossible toexternally determine which return code has been sent back in response to which command.Due to the absence of channel identification, no new command can be sent until the response

to the previous command has been received

The primary application for this very powerful mechanism is using several applications inparallel For example, suppose a cardholder is conducting a telephone conversation using theGSM application in a multiapplication smart card In order to confirm an appointment with theother party, she needs to briefly consult her personal organizer, which is located in the samecard Using a second logical channel, the terminal searches for a file in the personal organizerapplication, in parallel with the GSM application, and then tells our highly stressed managerwhether she can agree to the proposed date This is a typical use of logical channels Anotherconceivable example is securely transferring electronic funds between two electronic purses

in the same card

The potential utility of logical channels for applications is matched by the difficulties thattheir management entails for the smart card operating system In principle, each logical channelrepresents nothing less than a separate smart card, with all of its states and conditions Thiseffectively means that the operating system must concurrently manage all the data for severalparallel sessions within its memory The associated costs should not be underestimated, and inparticular this requires microcontrollers with large amounts of RAM If secure messaging andall possible types of authentication are also required for each logical channel, the amount ofmemory needed very quickly rises to a level that can only be met by the highest-performancetypes of currently available smart card microcontrollers

23 See also Section 6.5.1, ‘Structure of the command APDU’

24 There is a proposal to revise and upgrade the ISO/IEC 7816-3 standard to increase the number of possible logical channels to eight by using an additional RFU bit

Smart Card Commands

Communications procedures between a terminal and a smart card are always based on themaster–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 andreturns 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 applica-tions and are optimized for this purpose Deviations from these precisely specified protocolswithin application procedures are not permitted The transmission protocols allow data to besent to the card and received from the card in a manner that is completely transparent to the trans-port 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 terminalalso 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 ac-tivities 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 authorizationmedium or both at the same time This has led to the generation of command sets that areoptimized for these applications and transmission protocols and that are used only in the smartcard realm Due to the severely limited memory capacity of smart cards, combined with marketpressure to allow only moderate increases in this capacity for cost reasons, command sets areusually tailored to specific applications All commands that are not needed in a given applicationare relentlessly removed during program optimization Only a few operating systems exhibitextensive 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 newtechnologies Each company active in this area attempts to create its own commands that aretailored to the needs of its operating system or anticipated application This often arises fromnecessity, since functionally equivalent commands may not exist in the standards Companiesmay also deliberately attempt to improve their positions relative to the competition, or todeny their competitors access to a particular application area, by using commands that are

Smart Card Handbook, Third Edition W Rankl and W Effing

2004 John Wiley & Sons, Ltd ISBN: 0-470-85668-8

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 easilyexpandable and proven system, which may later allow additional functions to be incorporatedinto a single card On the other hand, there are many examples of systems in which the use ofsmart cards was only made possible by using highly optimized special commands

There are currently 13 international standards and more or less stable draft versions ofstandards that define typical smart card commands They define considerably more than 100commands, along with their associated procedures To a large extent, the defined commandsare mutually compatible in terms of coding and functionality

The majority of the commands currently used with smart cards are defined in the ISO/IEC7816-4 standard, which is a general international standard It is not dedicated to any particulararea, such as telecommunications or financial transactions, but instead attempts to address allsmart card applications The commands in ISO/IEC 7816-4 are complemented by three sup-plementary, specialized sections of this family of standards ISO 7816-7 defines commandsfor querying and managing smart card databases with structures based on structured querylanguage (SQL) ISO/IEC 7816-8 contains commands for executing and parameterizing cryp-tographic 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 initialletters of Europay, MasterCard and Visa, the three initiators of this specification Due to thestrong 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 asthe ISO/IEC 7816 family of standards

The GSM 11.11 specification, which was developed for use in the telecommunicationsarea, forms the normative basis for the SIM, while the TS 13.101, TS 31.111 and TS 102.222standards specify the basic commands for the USIM Due to the simple fact that a tremendousnumber 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 thesestandards and must therefore be specified individually One example is the command setspecified for multisector electronic purse systems, which is defined in the CEN EN 1546standard This European standard defines all commands necessary for an electronic purse, alongwith 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 cording to their functionalities However, it must be remembered that only subsets of all thesecommands are implemented in real-life smart card operating systems Depending on the pro-ducer of the operating system, more or less significant deviations from the functionality andcoding described in this chapter may be encountered However, the basic functions describedhere are in principle present in all operating systems Of course, the functionality may beseverely restricted due to considerations of memory capacity or cost Whenever a new applica-tion is being planned, exact specifications of the coding and functions of all of the commandsmust 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 com-mands The basis for this selection is formed by the following standards and specifications:

ac-Standards and specifications for smart card commands

GSM 11.11 GSM 11.14 (SIM)

TS 31.102

TS 31.111

TS 102.222 (UICC, USIM)

ISO/IEC 7816-4

payment systems EMV 2000 (credit & debit cards)

EN 1546 (electronic purses) ISO/IEC 7816-7

Open Platform

(application management)

Figure 7.1 The most important standards and specifications for smart card commands

ISO/IEC 7816-4/7/8/9, EMV 2000, GSM 11.11, TS 311.111, EN 726–3 and EN 1546–3 tensive tables listing the coding of the most important smart card commands can be found inSection 16.10.7, ‘Smart card command encoding’

Ex-Naturally, it is impossible to buy a single smart card anywhere in the world that contains allthe commands described here As a conservative estimate, the memory required for their fullimplementation would be five to 10 times as large as the total amount of memory in the largestcurrently available smart card microcontrollers However, it is not at all necessary for a smartcard to be able to execute all of these commands Depending on the intended application areaand operating system, certain classes of commands may be supported more comprehensivelythan others

For example, with a multiapplication card you would certainly want to make sure thatadditional applications can be installed in the card after it has been personalized A card forcryptographic applications, assuming it has adequate memory capacity, will contain the fullspectrum of cryptographic commands, along with the various algorithms Each applicationarea 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 ofthe above-mentioned standards Some of these commands are nonetheless very useful and willprobably 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 thecoding of typical smart card commands in this chapter This information can be found inSection 16.10.7, ‘Smart card command encoding’

Some commands are supported by nearly all smart card operating systems and have only alimited number of options For such commands, the command and response APDUs are fullydecoded in their descriptions The internal processing sequences of seven typical commandsare also shown in psuedocode in Chapter 5 in the description of the ‘Small OS’ operatingsystem

For a given application, smart card commands can be classified into operational mands, which are commands needed for normal use, and administrative commands, which arecommands needed for managing the smart cards and the application For reasons related tointeroperability, operational commands are generally specified in complete detail in the stan-dards Administrative commands are often specific to particular operating systems and are notnecessarily specified by standards.

com-Command classes (part 1: card usage)

security

file operations

read write

select search

identification

authentication cryptographic algorithms numeric operations

database

application-specific financial transactions

telecommunications

user management database management database query

health care local public transport

Figure 7.2 Classification of smart card commands that are primarily used for operational functions(while the card is in actual use)

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 commandsalso have parameters for selecting additional functions These options often exist only in thestandard, rather than in actual operating systems, since they may be too complicated or have nopractical significance Therefore, this chapter does not list or explain every option defined in thestandards, since our aim is to concentrate on practical functions In describing the commands,

Command classes (part 2: others)

create delete

write data completion modify access conditions

test error-detection codes write data patterns test data patterns

Figure 7.3 Classification of smart card commands that are primarily used for administrative functions(before and after the smart card is in actual use)

we have generally used the standard that has the largest number of functional options for thecommand in question

7.1 FILE SELECTION COMMANDS

Without exception, file management in all modern smart card operating systems is oriented Among other things, this means that before any action can be performed on an object(which corresponds to a file), it must first be selected Only then does the system know whichfile is meant, and all subsequent file-specific commands apply to this file alone Of course, theaccess conditions for the file still must be checked within the operating system, in order todetermine whether the command in question is allowed or even possible

object-The master file (MF) is always implicitly selected after the card has been reset, so it does nothave to be specifically selected Other files are subsequently selected by executing the SELECTFILE command A file is addressed using its 2-byte file identifier (FID) or, in the case of adirectory file (DF), a 1-byte to 16-byte DF name A DF name can contain an internationallyunique application identifier (AID) that is 5 to16 bytes long It is possible to pass only a portion

of the AID, omitting the less significant bytes (those to the right) An additional parametercauses the card to select the first, last, next or previous DF relative to the DF identified by theabbreviated AID

In connection with an older set of command definitions, the GSM 11.11 standard allowsonly the 2-byte FID to be used for file selection The ISO command set, by contrast, also

supports a type of file selection using the path name of the file in question The path name can

be either relative, in which case the file is selected starting from the currently selected DF, orabsolute, in which case the file is selected starting from the MF

Only successful selection of a new file causes the previously selected file to be deselected

If the selection cannot be completed, for instance because the requested file does not exist,the previous selection remains in force This ensures that a file is always selected, even in theevent of an error

After successful file selection, the terminal may request information about the new currentfile if necessary This request, including the desired number of data items, is sent to the cardusing the SELECT FILE command The exact contents of these data items are defined in theapplicable standard The data items returned by the card may include information about thestructure, size and amount of free memory of the newly selected file The amount of data mayalso depend on the file type

Table 7.1 lists the explicit file selection options permitted by ISO/IEC 7816-4 for theSELECT FILE command, and Figure 7.4 depicts the sequence of events in a typical fileselection process

Table 7.1 The functionality of SELECT FILE according to ISO/IEC 7816-4

first, last, next, or previous DF (if a partial AID is transferred)

• switch: return information about the selected file

Response • information about the selected file (if selected via the switch)

• return code

In addition to explicit file selection using an FID, DF name or a path specification in aSELECT FILE command, implicit file selection can be used However, this is only possiblewith standard read and write commands A file can be selected before the command is actuallyexecuted by specifying its 5-bit short FID as a supplementary parameter However, in this casethe file must be an EF and it must be located within the current DF The advantage of thismethod lies in simplified command execution and increased processing speed, since it is notnecessary to send an explicit SELECT FILE command to the card.1

1 See also Section 5.6.2, ‘File names’

Smart card Terminal

THEN return code= OK

ELSE return code= file not found

THEN file selection successfulELSE file could not be selected

Figure 7.4 Sample processing sequence for the SELECT FILE command

GSM 11.11 defines the STATUS command, which returns the same data to the terminal

as successful file selection using SELECT FILE These data provide information about thecurrently selected file: its type and structure, size, FID, access conditions and whether it isblocked This command is rarely used, and its main purpose is to allow the terminal to determinewhich file is currently selected during a session and the currently valid access conditions

Table 7.2 The functionality of STATUS according to GSM 11.11

Table 7.3 The functionality of CLOSE APPLICATIONaccording to EN 726-3

CLOSE APPLICATIONCommand • FID (of the current DF)Response • return code

7.2 READ AND WRITE COMMANDS

Read and write commands primarily support using smart cards for secure data storage Thesecommands can be used to write data to appropriate EFs and subsequently read these data Ifthese EFs have specific access conditions, only authorized users are allowed to read them Thedata are thus stored in the card with protection against unauthorized access

Since there are various types of EF data structures, there are also various types of read andwrite commands for these files Unfortunately, this does not fully correspond to an object-oriented file management system In a purely object-oriented system, the operating systemmust be built such that an object can determine its own access mechanisms This is not the casefor smart card file management This non-compliance dates back to the historical emergence ofcommands that were subsequently incorporated into current standards The precursors of smartcards, which are memory cards, have only one memory region that can be read and writtenusing offset and length parameters Externally, this memory can be regarded as a single file with

a transparent structure The first smart cards were built according to the same principle, andthe definitions of the commands for reading and writing transparent files date from this time.Later, when other types of file structures were defined, new commands specifically adapted tothese structures were defined for use with such files As a result, there are two different types

of file access

Therefore this class of commands must be divided into commands for accessing EFs withtransparent structures and commands for accessing EFs with the other types of structures(cyclic, linear fixed and linear variable) However, several standards (such as EN 1546 forelectronic purses) explicitly state that read commands for files with transparent structures mayalso be used to read files with other types of structures In any case, such commands can beused to obtain additional data about the internal structure of the file

An EF with a transparent logical structure is amorphous, which means that it does nothave any internal structure It corresponds to a linearly addressable memory with byte access.The READ BINARY command is used to read such a file, while the WRITE BINARY andUPDATE BINARY commands are used for writing

Table 7.4 The functionality of READ BINARY according to

ISO/IEC 7816-4

READ BINARY

Command • number of bytes to be read

• offset to the first byte to be read

• optional: short FID for implicit selection

Response • data read from the file

• return code

The fundamental difference between the WRITE BINARY and UPDATE BINARY mands relates to the secure state of the card’s EEPROM The secure EEPROM state is thelogical state of the EEPROM bits when the memory cells have taken on their minimum-energystate Since the memory cells are small capacitors, this means the state in which they contain

com-Table 7.5 The functionality of WRITE BINARY according to

ISO/IEC 7816-4

WRITE BINARY

Command • number of bytes to be written

• data bytes to be written

• offset to the first byte to be written

• optional: short FID for implicit selection

Response • return code

Table 7.6 The functionality of UPDATE BINARY according to

ISO/IEC 7816-4

UPDATE BINARY

Command • number of bytes to be overwritten

• offset to the first byte to be overwritten

• optional: short FID for implicit selection

Response • return code

no charge, which is usually the logic 0 state In order to change a bit from state 0 to state 1, itmust be erased This restores the charge on the capacitor

A WRITE command can only be used to change bits from the non-secure state, which isusually logic 1, to the secure state, which is usually logic 0 In this case, the WRITE commandproduces the logical AND of the transferred data and the file content By contrast, if the securestate of the chip corresponds to logic 1, the WRITE command must produce the logical OR ofthe data provided by the command and the data in the file The result of the logical coupling

of the data provided by the command and the data in the file is that the secure state of theEEPROM is always achieved using a WRITE command In addition, a WRITE command maysupport write once, read multiple (WORM) access, depending on the file WRITE commandsoriginate from a time when using atomic operations for file access was still unknown in thesmart card realm They are presently used only very rarely

An UPDATE command, by contrast, performs a genuine write to the file The previous state

of the data in the file does not affect the content of the file following execution of an UPDATEcommand UPDATE BINARY can thus be considered to be equivalent to using ERASE toerase the file, followed by WRITE BINARY

These commands can be utilized to construct physically secure smart card counters Theprinciple involves a bit field in which each bit that is set represents a monetary unit When

a payment is made, the counter is decremented bit by bit using OR operations generated byWRITE BINARY commands After authentication, the counter value can be increased againusing an UPDATE BINARY command The main advantage of this technique is that it makes

it impossible to increase the counter value by manipulating the EEPROM, such as by heating

it, since the secure state of each bit represents a value of 0

As their names suggest, READ BINARY is a read command, while WRITE BINARY andUPDATE BINARY are write commands The file is always accessed using a length parameterand an offset to the first byte to be addressed Some operating systems also permit implicitfile selection before the actual data access occurs, using a supplementary short FID parameter.However, this option is not present in all standards and operating systems.

Figure 7.5 illustrates a typical command sequence using READ BINARY followed byWRITE BINARY and finally UPDATE BINARY The effects on the content of the selectedfile are shown in Figure 7.6 Of course, this example assumes that file selection is successfuland that the access conditions for the file to be written are met

READ BINARY

number of bytes to be read= 5]

requested data :='03'||'FF'||'00'

||'FF'||'00'

THEN READ BINARY successfulELSE abort

WRITE BINARY

to be written= 2, data ='F0 F0']

THEN WRITE BINARY successfulELSE abort

UPDATE BINARY

to be written= 2, data ='F0 F0']

THEN UPDATE BINARY successfulELSE abort

Figure 7.5 Accessing a file with a transparent structure

ERASE BINARY is an exception among the commands that operate on transparent EFs Itcannot be used to write data to a file, but only to erase data starting from a given offset If nosecond offset parameter is stated, the command erases all data to the end of the selected file Inthis case, erasing data means that the data region specified in the command is set to the logicalerased state This state must be defined separately for each operating system, since it may not

be the same as the physically erased state of the memory

Because the structures of linear fixed, linear variable and cyclic EFs are fundamentallydifferent from the structure of a transparent EF, special commands for accessing these particulardata structures are available in addition to the commands described above All of these fileshave record-oriented structures For write access, the smallest addressable unit in the data field

is a single record For read access, either an entire record or part of a record may be read,

(a) file content with READ BINARY

(b) file content after WRITE BINARY

(c) file content after UPDATE BINARY

Table 7.7 The functionality of ERASE BINARY according to

ISO/IEC 7816-4

ERASE BINARY

Command • offset to the first byte to be erased

• optional: offset to the last byte to be erased

• optional: short FID for implicit file selection

Response • return code

starting with the first byte of the record These file structures, which transform a linear, dimensional memory into a memory that can be addressed in two dimensions, yield access typesthat are significantly more complex than those used with a transparent structure In principle,all possible data structures can be emulated using a transparent structure, but in specific casesthis may prove considerably more complicated than using a higher-level structure

one-After an EF with a record-oriented structure has been selected, the card’s operating systemcreates a record pointer whose initial value is undefined The value of this pointer can be setusing a READ, WRITE, UPDATE RECORD or SEEK command The pointer for the currentfile is saved as long as this file is selected After successful explicit or implicit selection ofanother file, the value of the record pointer is again undefined

All commands for record-oriented files can use a parameter byte to specify the type ofaccess to the file The basic type is direct access using the absolute number of the desiredrecord This type of access does not alter the record pointer The number of the desired record

is sent to the card, and the response contains the content of the record in question

If the parameter byte specifies the first record, the operating system sets the record pointer

to the first record in the file, and this record is read or written according to the type of commandused The parameter value ‘last’ accesses the final record in a similar manner The additionalparameter values ‘next’ and ‘previous’ allow the next and previous records, respectively, to beselected and read or written Finally, the parameter value ‘current’ can be used to address therecord marked by the current value of the record pointer

Hiro Protagonist 2

1

3 4 5 6 7 8

Y.T.

Juanita Raven Onkel Enzo The Black Sun Cosa Nostra Pizza Enki

record content record number

Figure 7.7 Accessing a file having a record-oriented structure

This large variety of access methods for record-oriented data structures originates fromthe typical structure of a telephone directory Consider a record whose initial part contains asurname and given name, followed in the same record by the associated telephone number.Using READ RECORD and the parameters described above with a telephone directory mappedinto an EF, you can ‘page’ forwards and backwards as desired within the directory or jump

to the first or last entry The record pointer can also be changed using the search commandSEEK, which is described below

Joshua Calvert Quinn Dexter Louise Kavanagh Alkad Mzu Ione Saldana Kiera Salter Ralph Hiltch Fletcher Christian Kelly Tirrel Gerald Skibbow

Figure 7.8 Example of a telephone number list in a file with a ‘linear fixed’ structure

ISO/IEC 7816-4 also provides the option of reading all records from the first record up to aspecified record number Similarly, all records from a specified record number through to thelast record can be read in a single command–response cycle using READ RECORD Althoughthese commands are very practical, the capacity of the I/O buffer can quite easily be exceeded

if they are used with large files

Figure 7.9 illustrates the execution of several read and write operations on the file shown

read all records from the first record to n

• optional: short FID for implicit file selection

Response • data read from the file

• return code

Table 7.9 The functionality of WRITE RECORD according to ISO/IEC

7816-4

WRITE RECORD

Command • record data for writing

• number of the record to be written

or

mode (current, first, last, next or previous record)

• optional: short FID for implicit file selection

Response • return code

Table 7.10 The functionality of UPDATE RECORD according to ISO/IEC

7816-4

UPDATE RECORD

Command • record data for overwriting

• number of the record to be overwritten

or

mode (current, first, last, next or previous record)

• optional: short FID for implicit selection

Response • return code

Smart card Terminal

READ RECORD

command processing

THEN READ RECORD successfulELSE abort

UPDATE RECORD

command processing

THEN UPDATE RECORD successfulELSE abort

UPDATE RECORD

command processing

THEN UPDATE RECORD successfulELSE abort

READ RECORD

command processing

THEN READ RECORD successfulELSE abort

Figure 7.9 Sample read and write operations for a record-oriented file

The APPEND RECORD command, given its functionality, could just as well be classified

as a file management command It can be used to append records to existing record-orientedfiles The data for the entire new record are provided together with the command A relativelycomplex memory manager, in smart card terms, is a prerequisite for the availability of thiscommand with its full functionality The function of the memory manager is to create a linkbetween the new record and the ones already present in the file It is then possible, withinthe limits of the available memory, to add an arbitrary number of new records However, thenumber of new records that can be added is often restricted in order to simplify matters

In this case, when a record-oriented file is created, memory is reserved as necessary foradding future records This space can later be filled using APPEND RECORD commands.Once this free space is used up, the APPEND RECORD command cannot be used again forthis file

If APPEND RECORD is used in conjunction with a linear fixed or linear variable file, thenew record is always added at the end of the file If the structure is cyclic, however, the newrecord is always numbered 1, which corresponds to the currently written record in files of thistype

APPEND RECORD can be used for various purposes One possibility is a telephone tory, as already mentioned Another possibility is a log file, in which the data to be recordedare written directly to the card by creating new records.

direc-Table 7.11 The functionality of APPEND RECORD according to

ISO/IEC 7816-4

APPEND RECORD

Command • record to be written

• optional: short FID for implicit file selection

Response • return code

There are two commands that complement the file-based read and write commands Theyare designed for direct access to data objects Depending on the selected DF, certain datacan be written to or read from files or internal operating system structures, bypassing the file-oriented access mechanisms Data objects can be written using PUT DATA and read using GETDATA For both of these commands, the exact structure of the TLV-coded data objects must betransferred with the command This means that it is necessary to know whether application-specific or standard coding is used for the data objects This information is important insidethe operating system, since it allows the objects to recognize the data according to how theyare packaged The appropriate access conditions must be satisfied in advance for both of thesecommands

Table 7.12 The functionality of GET DATA according toISO/IEC 7816-4

GET DATACommand • number of data objects to be read

• tag of the data objects to be readResponse • read data objects

• return code

Table 7.13 The functionality of PUT DATA according toISO/IEC 7816-4

PUT DATACommand • structure of the data objects to be written

• data objects to be writtenResponse • return code

7.3 SEARCH COMMANDS

Record-oriented structures are well suited to storing sets of related data with identical structures

in a single file A typical example is a telephone directory containing names and telephonenumbers A search command can be used to avoid having to read the entire directory, record

by record, when looking for a particular name

The SEEK command can be used to search for a specified character string in a oriented data structure An offset can be supplied with the command The length of the searchstring is variable The command must tell the operating system in which direction to search.This can be either from the starting location onwards (in the direction of increasing recordnumbers) or from the starting location backwards The starting location for the search mustalso be specified The first record, last record or current record can be specified as the startingposition If the search string is found, the operating system sets the record pointer to the location

record-of the string and informs the terminal that the search was successful

m-byte search pattern offset

'01' n

Figure 7.10 Searching within a record-oriented file

The ISO/IEC 7816-9 standard describes two commands that can be used to search for data

in transparent and record-oriented files The SEARCH RECORD command is the ISO/IECversion of the GSM 11.11 SEEK command The major difference between these two commands

is that according to ISO/IEC 7816-9, a short FID can also be transferred within the commandfor implicit EF selection

The command sequence shown in Figure 7.11 illustrates some ways in which the SEEKcommand can be used This example is based on the linear fixed file shown in Figure 7.7

Table 7.14 The functionality of SEEK according to GSM 11.11

• switch: return the record number of the located record

Response • record number (if selected by the switch)

• return code

The SEARCH BINARY command can be used to search for specific data in a selectedtransparent file The file may be selected either explicitly by a previously transferred command

Smart card Terminal

SEEK

search direction=''forward from thebeginning''|| send record number]

return code] THEN''Hans''found

ELSE''Hans''not foundSEEK

search direction=''backward fromthe end''|| send record number]

THEN''Alex''foundELSE''Alex''not found

Figure 7.11 Sample command sequence using the SEEK command

Table 7.15 The functionality of SEARCH RECORD according to ISO/IEC 7816-9

• switch: return the record number of the located record

• optional: short FID for implicit file selection

Response • record number (if selected by the switch)

• optional: short FID for implicit file selection

Response • offset to the located data

• return code

or implicitly via a command parameter The result is the offset from the start of the file to thefirst byte of the located search string.

7.4 FILE MANIPULATION COMMANDS

There are several commands that allow the content of a file to be modified by means other thansimple writing The main representatives of this class are the INCREASE and DECREASEcommands They increase or decrease the value of a cyclically structured file whose contenttakes the form of a counter The amount of the increase or decrease is transferred as a commandparameter

The cyclic file structure is defined to meet the needs of logging functions These commandsare primarily used for simple electronic change purses and counters For the sake of simplicity,

an example cyclic file with only one record is shown in Figure 7.12 The starting value of therecord is 10 On conclusion of the process, the record has the same value again

Table 7.17 The functionality of DECREASE according

to GSM 11.11DECREASECommand • value to be subtractedResponse • subtracted value

• new value of the record

• return code

Table 7.18 The functionality of INCREASE according

to GSM 11.11INCREASECommand • value to be addedResponse • added value

• new value of the record

Smart card Terminal

DECREASE

command processing

new value= 7 || return code]   IF (return code= OK)

THEN DECREASE successfulELSE DECREASE could not be executedDECREASE

command processing

new value= 5 || return code] THEN DECREASE successful

ELSE DECREASE could not be executedINCREASE

command processing

new value= 10 || return code] THEN INCREASE successful

ELSE INCREASE could not be executed

Figure 7.12 Sample command sequence using INCREASE and DECREASE

Table 7.19 The functionality of EXECUTE according to EN726-3

EXECUTE

Command • data to be passed to the executable file

Response • data returned by the executable file

• return code

7.5 IDENTIFICATION COMMANDS

In addition to being used as secure data storage media, smart cards can also be used to identifyindividuals The usual procedure involves exchanging secret information that is known only

to the user and the card This is usually a personal identification number (PIN)

Everyone is familiar with PIN verification from personal experience The PIN is entered

at a terminal, and shortly thereafter the display shows whether the PIN was correct or, if not,how many attempts are still allowed In this procedure, the smart card receives the PIN fromthe terminal in a VERIFY command The PIN is usually a four-digit number, which the smartcard compares with a value stored in its EEPROM If the entered PIN matches the stored PIN,the card’s internal state changes, the terminal receives a response confirming a positive result,and the retry counter is reset to its original value of 0 If the entered PIN does not match the

stored PIN, the retry counter is incremented If it reaches its predefined maximum value, thecard is blocked for further PIN verification.

Many smart card operating systems allow several PINs to be used In such cases, it ismandatory to send the identification number of the relevant PIN in all associated commands,

so that it can be correctly addressed As a rule, however, card issuers attach great importance

to having only one PIN per card, even when it is technically possible to have more than one.This is essential for customer acceptance and user friendliness

The abbreviation ‘CHV’ is often used in place of ‘PIN’ in the telecommunications industry.CHV stands for ‘cardholder verification’ and means exactly the same thing as PIN Since some

of the commands described below originated in the telecommunications industry, their namesuse the abbreviation CHV instead of PIN

Table 7.20 The functionality of VERIFY CHVaccording to GSM 11.11

VERIFY CHVCommand • PIN

• number of the PINResponse • return code

The ISO/IEC 7816-4 standard describes a PIN verification command that is largely thesame as the GSM 11.11 command Its name is VERIFY, and it can be used not only forPIN comparison, but also for verifying biometric features Compared with PIN verificationaccording to the GSM specification, there is only one significant difference in the coding.ISO/IEC makes a distinction in the command between a global PIN and an application-specificPIN The command can thus be used to specify whether to verify a PIN that applies to theentire smart card or one that is only applicable to the current DF

Table 7.21 The functionality of VERIFY according to ISO/IEC 7816-4

VERIFY

Command • PIN or biometric feature (= secret)

• number of the PIN or biometric feature

• switch: global or application-specific secret

Response • return code

In some applications, the cardholder is expected to choose his or her own PIN the first timethe PIN is entered The null-PIN method can be used for this purpose With this method, thePIN is set to zero when the card is personalized This PIN code has a special meaning for somesmart card operating systems, which reject all VERIFY commands containing a null PIN anddemand that the PIN first be changed using the CHANGE REFERENCE DATA command Inthis way, the user is forced to change his or her PIN, since it is not possible to alter the securitystate of the card if a null PIN is entered This method is not standardized, but it can sometimes

be used to advantage if it is supported by the operating system

PINs have steadily proliferated since their introduction as identification numbers for holders Currently, the average card user is expected to keep track of perhaps 10 to 20 differentPINs for various cards and other authorizations The fact that this expectation is unrealistic isshown by the large number of people who jot down the PIN on the card itself If smart cardsare used, the user can be allowed to choose a PIN at will, and thus to use the same PIN forall of his or her cards Although this may cause security problems, since anyone who illicitlyacquires one PIN thereby knows all of them, it is still better than writing the PIN on the cardwhere everyone can read it.

card-The CHANGE CHV command allows the PIN to be altered card-The ISO/IEC 7816-8 equivalent

to this command is CHANGE REFERENCE DATA, which has the same input and outputparameters If the PIN currently stored in the card is known, it can be replaced with a new one

If the current PIN is entered incorrectly, the operating system increments the retry counter toprotect against possible attempts to use this mechanism to discover the PIN As soon as thecurrent PIN is correctly passed to the card, the card stores the new PIN it has received in theappropriate memory location and resets the retry counter

Table 7.22 The functionality of CHANGE CHVaccording to GSM 11.11

CHANGE CHVCommand • old PIN

• new PIN

• PIN numberResponse • return code

If a retry counter has reached its maximum value, it can be reset using the UNBLOCKCHV command with a second PIN, which is called the personal unblocking key (PUK) ThePUK is usually longer than the standard 4-digit PIN (8 digits, for example) The user need notmemorize the PUK, since it is only needed if the PIN has been forgotten It is sufficient if theuser has a record of the PUK somewhere at home However, just resetting the retry counterwould not help the user very much, since he or she would still not know the correct PIN.Consequently, the command UNBLOCK CHV must also provide the card with a new PIN

It should not be possible to use this command to alter the PIN of a hybrid card, which has

a magnetic stripe as well as a chip Otherwise the PIN recorded on the magnetic stripe wouldnot match the PIN in the chip, which would cause severe problems With such cards, the retrycounter is simply reset and the customer is sent a letter with the original PIN

Table 7.23 The functionality of UNBLOCK CHVaccording to GSM 11.11

UNBLOCK CHV

• new PINResponse • return code

The ISO/IEC 7816-8 standard has its own command for resetting the retry counter when

it has reached its maximum value This command is called RESET RETRY COUNTER Acertain security state must be achieved before this command can be executed As a rule, thisstate is achieved by means of a successful authentication Despite its name, this command canalso be used to replace the current PIN with a new PIN

Table 7.24 The functionality of RESET RETRY COUNTER according to

ISO/IEC 7816-8

RESET RETRY COUNTER

Command • number of the PIN

• option: [PUK || new PIN]

• if option selected: number of the PUK

• switch: global PIN or application-specific PIN

Response • return code

GSM includes two other commands that can be used to control PIN querying They are ABLE CHV and ENABLE CHV, which switch PIN verification off and on If PIN verification

DIS-is dDIS-isabled, all file access restrictions that require prior PIN verification are dDIS-isabled Both ofthese commands are very popular in the mobile telecommunications area, since they eliminatethe need to re-enter the PIN every time the mobile telephone is switched on From a securityperspective, these commands are questionable, since they disable protection against unautho-rized use that is provided by the PIN Of course, the user could also use CHANGE CHV tochoose a trivial PIN, such as''0000'', which offers just as little protection

The ISO/IEC 7816-8 commands for these functions are called ENABLE VERIFICATIONREQUIREMENT and DISABLE VERIFICATION REQUIREMENT Depending on the ap-plication, a certain security state must be achieved before these commands can be executed

Table 7.25 The functionality of DISABLE VERIFICATION REQUIREMENT

according to ISO/IEC 7816-8

DISABLE VERIFICATION REQUIREMENT

Command • reference data (e.g., PIN)

• number of the reference data

For obvious reasons, the PIN verification procedures described above are subject to attack,since a large financial gain could be realized using a lost or stolen card and the right PIN Allcommands associated with PIN and PUK comparison must be protected against analysis of thecard’s electrical or timing behavior For instance, current consumption during the execution ofVERIFY PIN must be constant, regardless of whether the entered PIN is correct It is equallyimportant for the time required to execute PIN commands to be independent of whether thePIN is correct Varying execution times could have fatal consequences for the card’s security,

Table 7.26 The functionality of ENABLE VERIFICATION REQUIREMENT

according to ISO/IEC 7816-8

ENABLE VERIFICATION REQUIREMENT

Command • reference data (e.g., PIN)

• number of the reference data

and thus ultimately the security of the entire system Such variations could be used to determinethe value of the correct PIN in a very simple manner, causing all of the system’s PIN codes to

be rendered worthless as a means of user identification

7.6 AUTHENTICATION COMMANDS

In addition to commands for identifying the cardholder, there is a further set of commandsfor authenticating the terminal and the card Since each of these communications partners isequipped with a complete computer, the procedures can be made much more complex, andthus more secure, than those used for PIN verification

In PIN verification, the card receives a secret code in plaintext (the PIN) via the interface,and it only has to compare this with the PIN held in memory Tapping the transmission linewould thus have fatal consequences Modern authentication procedures are designed to makesuch attacks impossible

In principle, authentication involves verifying a secret known to both of the communicatingparties without requiring it to be sent across the interface The procedures are constructed suchthat tapping the data transmission would not compromise the security of the authentication.2Depending on the operating system, various commands are available for authenticating thecard or the terminal, or both at the same time For the sake of clarity, here and in the rest ofthis chapter we refer to authentication between the card and the terminal However, in terms ofinformation technology what actually happens is that the ‘outside world’ authenticates itselfwith respect to an application in the card This does not involve verifying that the card as awhole is genuine, but only that the embedded microcontroller shares a secret with the externalworld This should be taken into account in certain applications

In many operating systems, the keys used for authentication are protected by a retry counter

If a terminal unsuccessfully attempts authentication too many times, the card blocks the sociated key for further authentication tests This is a perfectly acceptable procedure withregard to system security, but it does have one drawback Resetting the retry counter for theauthentication key to its initial value often involves very complex, logistically cumbersomeand costly administrative procedures Consequently, some systems do not have retry countersfor authentication keys

as-For security reasons, only card-specific keys should be used for authentication These keyscan be generated from a unique feature of the card A serial number or chip production number

2 See also Section 4.11, ‘Authentication’