Smart Card Technology: Introduction To Smart Cards - Page 3
by Dr. David B Everett.
Technical Adviser to Smart Card News
Return to page 2
Smart Card Technology: Introduction To Smart Cards - Page 3
by Dr. David B Everett.
Technical Adviser to Smart Card News
Return to page 2
After the reset signal is applied by the interface device the IC card responds with an answer to reset. For the active low reset mode the IC should respond between 400 and 40,000 clock cycles after the rising edge of the reset signal. The answer to reset is at most 33 characters (including the initial character) and consists of 5 fields,
Each of these fields is sent in order as shown in figure 12. The initial character TS is really a bit synchronisation pattern which may be sent in order to determine the data transmission rate (auto baud rate sensing) and also to determine the sense of the logic. The format of the TS character is shown in figure 13. This shows the two possibilities of the direct and inverse convention. In the inverse convention where the logic level 1 is the space or low state the most significant bit is transmitted first. With the direct convention where the logic level 1 is the mark or high state then the least significant bit is transmitted first. This means that the selection of the appropriate logic sense will result in the initial character being interpreted as `3F' for the inverse convention and `3B' for the direct convention in hexadecimal coding.
The format character TO provides information necessary to interpret the remaining answer to reset characters. The most significant 4 bits use a bit map to indicate the presence or otherwise of TA1, TB1, TC1 and TD1. For example if the most significant bit (b8) is set then TD1 is present in the interface characters field. Similarly the presence of TC1 is indicated by the state of the `b7' bit and so on.
The least significant 4 bits of the TO formal character give the number (binary encoded) of bytes in the historical field. The use of 4 bits restricts the maximum size of the historical character field to 15 bytes.
The interface characters (TAi, TBi, TCi, TDi,) are the complex part of the answer to reset. They carry information relating to the available communication protocols as well as the programming voltage and current parameters for the EPROM. There is currently a proposed revision to the ISO 7816-3 to remove ambiguities and to ensure an effective method of operation for changing the protocol type and the protocol parameters. Much of the complexity is brought about by the desire to achieve backward compatibility with commercial implementations of the T=O communication protocol. At the current time there are commercial applications running either the T=O or T=1 communication protocol while multi-protocol operation is somewhat scarce.
The proposed revisions to the standard may alter this situation. We will discuss the interface bytes and protocol type selection against these proposed revisions but readers are warned that these recommendations are only provisional.
The interface bytes (which are optional) are defined in figure 14. The T0 and TDi characters contain bit maps which indicate the presence or otherwise of the following TAi, TBi, TCi, and TDi bytes.
The TA1, TB1, TC1, and TB2 characters are referred to as the global interface bytes and are fundamental to the operation of the card.
TA1 defines the basic characters of the serial transmission, FI is the clock rate conversion factor and DI is the bit rate adjustment factor. The binary encoded fields are compared against tables supplied in the standard to achieve actual values for F and D as defined below,
An elementary time unit (etu) is the nominal bit duration used in the character frame. Thus as described previously one character frame is equal to 12 etu (1 start etu, 8 data etu, 1 parity etu, 2 guard time etu).
The default values for F1 and D1 are 1 which is defined in the tables to give a value for F of 372 and D of 1. Hence the work and initial etu are the same. At these default values the frequency of the clock should be in the range 1MHz - 5MHz.
TB1 is used to define the EPROM programming voltage and current. The value of II and PI1 are used against tables to obtain the value of I mA and P volts. It should be noted that TB2 is used to define the programming voltage with higher granularity (8 bits instead of 5).
TC1 provides the value of N which defines the extra guard time to be used between successive characters. N can be in the range 0 - 254 etu. When N is equal to 255 this indicates that the minimum guard time ( 2 etu for T = 0 and 1 etu for T = 1 ) should be used. As noted previously the T = 0 communications protocol requires the extra guard time to enable the parity error detection and signalling to be implemented.
TD1 indicates the protocol type TDI as between 0 and 15,
It should be noted that Japan uses T = 14 for a National block asynchronous protocol.
The TD1 byte also contains a bit map that indicates the presence or otherwise of TA2, TB2, TC2 and TD2.
The proposed revision defines a new use for the TA2 interface byte which has a special role in the selection of communication protocols and parameters. We will discuss this further in the communications section.
The Historical Characters
The historical characters may be used to convey information relating to the life cycle of the card. There are clearly other possibilities and the use of these characters is still subject to agreement. This subject is being considered further as part of the emerging part 4 of the ISO 7816 standard.
The Check Character (TCK)
The check character should not be sent when only the T = 0 protocol is indicated in the answer to reset. In all other cases TCK is sent as the last character of the ATR. The check character is calculated such that the Exclusive OR of all the bytes from T0 to TCK inclusive is equal to zero.
Communication Protocols
At the current time there are two communication protocols that are in general use,
The T = 0 protocol is the predominant protocol in France and was the only protocol specified in ISO 7816 - 3. In 1992 ISO standardised the T = 1 protocol as amendment 1 to ISO 7816 - 3. Clearly the IC card and the interface device must operate with a common protocol. The method by which they achieve a common optimum configuration has been the subject of much discussion over the last few years. This principle is intended to be achieved by the use of protocol type selection (PTS). This is effectively a special command sent from the interface device to the ICC after the answer to reset. In order to maintain backward compatibility with existing commercial systems that may only be capable of handling the T=0 communication protocol, some changes are necessary to the original ISO 7816-3 standard. A new concept is proposed which identifies the principle of two modes of operation:
An ICC that operates in a negotiable mode may have its communication protocol changed by the use of the PTS command. An ICC that operates in the specific mode cannot accept a PTS command but may be put into the negotiable mode by a further assertion of the reset command.
Although the ICC indicates to the interface device (by means of TA2) its capability to change to the negotiable mode, an existing device in the market place may however be unaware of these changes and therefore will not be prepared to reset the card.
The operation of these mode changes are shown in figure 15. It should be noted that a multi protocol card which by definition offers the negotiable mode of operation should give priority to the T=0 communication protocol. In other words if the T=0 protocol is available it should be the default protocol offered in the answer to reset.
The TA2 interface byte which is part of the answer to reset data gives the necessary information to allow the appropriate choice of protocol. The coding of this byte when present is shown in figure 16. In fact the presence or otherwise of this byte is used to determine the mode of operation of the card as follows:
It can be seen that bit 8 in the TA2 byte is used to tell the interface device whether the card can change to the negotiable mode.
Protocol Type selection (PTS)
Protocol type selection is used by the interface device to change the communications protocol and/or the default values of FI and DI. The PTS command must be issued immediately after the answer to reset and only applies when the IC card is in the negotiable mode.
The interface device may choose to operate by using the first indicated protocol after the answer to reset and by using the default values of F and D. This results in an implicit selection of the protocol and the communication parameters. Should the interface device wish to effect any change to this situation then it must issue the PTS command.
The PTS request consists of an initial character PTSS (coded FFhex), followed by a format character PTSO, and three optional characters PTS1, PTS2, PTS3 and PCK the check character. This is shown in figure 17. The response from the ICC follows the same format as the request.
The PTS0 format character is encoded as shown in figure 17. The bit map is used to indicate the presence or otherwise of PTS1, PTS2 and PTS3. These are encoded by bits 5, 6 and 7 respectively where a logic `1' level indicates the presence of the character. The protocol type is indicated by bits 1, 2, 3 and 4 which are binary encoded for T=0 to T=15.
The PTS1 character when present is used to define the values for FI as coded for TA1. These parameters are used for defining the work etu (elementary time unit).
The check character PCK is computed such that the exclusive OR (XOR) of all the characters from PTSS to PCK inclusive is equal to zero.
When the ICC implements the PTS request message correctly it replies by echoing the same request as the response message. If bit 5 of the PTS1 response character is set to zero then the default values of F and D will be used.
The T=0 communication protocol
The interface device always initiates the command for the T=0 protocol. Interaction between the interface device and the ICC results in successive commands and responses. For this protocol, data can only flow in one direction for the command response pair. In other words, either the command message contains data for the ICC or the command request data from the ICC which is then included in the response. The direction of data flow is implicit on the definition of the command and hence both the interface device and the ICC need to have the necessary a-priori knowledge. When it is required to transfer data in both directions for a particular command then a "get response" command may be used after the primary command to recover the response data.
The command message consists of a 5 character header which the interface device sends to the ICC. The ICC then replies with a procedure byte after which either data is sent to the ICC, or from the ICC, depending on the particular command. This procedure byte is to allow the interface device to control the Vpp EPROM programming voltage. In the case of EEPROM memory this procedure byte is effectively redundant. The message flow for the T=0 protocol is shown in figure 18. The command header consists of the following 5 bytes:
When P3 is equal to zero the data from the card will be 256 bytes. When data is to be transferred into the card then a zero data transfer is implied.
The normal condition for the ACK procedure byte is for this byte to echo the instruction byte (INS). Other options allow the interface devices to control the Vpp programming voltage as required. The card may optionally send a NULL procedure byte (60hex) which allows further time for the processing of the command. In this situation the IFD should await a further procedure byte. The ISO standard also allows the card to send the first status byte (SW1) as the procedure byte.
There are two status bytes SW1 and SW2. These bytes are sent from the ICC to the interface device on completion of the command to indicate the current card status. The normal response is:
SW1, SW2 = 90hex, 00hex
When SW1 = 6X or 9X various error conditions are reported by the card. ISO 7816-3 defines 5 such error conditions:
= 6D - Invalid INS code
= 67 - incorrect length
= 6F - no particular diagnosis
The T = 1 comms protocol
The T = 1 communication is an asynchronous half duplex block transmission protocol. In terms of the OSI model this protocol operates at layer 2, the data link layer. The physical layer (layer 1) operates in the same way as for the T = 0 protocol except for the error detection and correction. In essence this protocol puts an envelope around a block of characters which allows:
The choice of communication protocol for the ICC is still a hot topic and one has to consider what advantages can be offered by the block protocol and then to examine the price that must be paid.
The most obvious advantage of the T = 1 protocol is the ability to manage data flow in both directions. In our discussion of the T = 0 protocol it was shown that for a particular command that the data is either sent to or received from the ICC. This limitation was really due to the use of a single byte for defining the length of the data related to the command.
The T = 1 protocol also removes the T = 0 restriction of the master slave relationship where the interface device (IFD) always initiates a command to which the ICC responds. For this block protocol a command may be initiated by either the IFD or the ICC albeit within the restrictions of the protocol.
A further advantage of the T = 1 protocol is the ability to chain the blocks of data such that an arbitrarily large block of data may be transferred as the result of a single command by the transmission of the appropriate number of frames chained in sequence.
The block protocol also has a more sophisticated error management system. This allows the use of a block error detection code (EDC) and the ability to re-transmit blocks that are subject to some error condition. By comparison the T = 0 protocol has a primitive character error detection and correction scheme.
Clearly there is a price to be paid for this higher layer protocol. Apart from the more complex software in both the ICC and the IFD the protocol is more demanding on the RAM memory of the ICC which needs to maintain the last sent block in case retransmission is required. In general the T = 1 protocol offers advantages where the application is managing large blocks of data, particularly when it is required to pass data in both directions as part of a particular command. The efficiency of the protocol is only really apparent for larger data transmissions since the underlying physical layer is still operating in character mode as for the T = 0 protocol. The reduction of the character frame to 11 etu (elementary time units) compared with the 12 etu demanded by T = 0 has to be balanced against the administrative overhead of the frame structure which has both a prologue and epilogue.
There can be no doubt that the error control is significantly improved over the T = 0 protocol but at the lower speed of 9600 bit/second operated by many ICC's over very short transmission paths the probability of communication errors is much reduced. However it is clear that there is a move towards the use of the T = 1 protocol and it seems highly likely that this will become the predominant protocol of the future. We should not however dismiss the use of the T = 0 protocol which in some situations may well offer a more optimum technical solution. The T = 1 protocol is specified in the ISO standard ISO 7816 - 3 / AMD.1
This article is continued on page 4
© 1997 Smart Card News Ltd., Brighton, England.
