Smart Card Technology: Introduction To Smart Cards - Page 4
by Dr. David B Everett.
Technical Adviser to Smart Card News
Return to page 3
Smart Card Technology: Introduction To Smart Cards - Page 4
by Dr. David B Everett.
Technical Adviser to Smart Card News
Return to page 3
The frame consists of three fields:
as shown below:
| Prologue Field | Information Field | Epilogue Field | ||
| Node
Address NAD |
Protocol
Control Byte PCB |
Length LEN |
Optional INF |
Error
Detection LRC or CRC EDC |
| 1 Byte | 1 Byte | 1 Byte | 0-254 Bytes | 1/2 Bytes |
The prologue field consists of three bytes:
The NAD byte uses bits 3 -1 to identify the source address and bits 7 - 5 to identify the destination address. The bits 4 and 8 are used for Vpp control which will not be discussed further here. The node address byte allows the use of multiple logical channels where required otherwise both addresses should be set to zero.
The PCB byte allows the identification of three types of block frame,
The information block is the frame which is used to transmit application commands and data between the ICC and the IFD. The receive - ready block is used as an acknowledgment when the protocol is sending data as a sequence of chained blocks. The supervising block is used to establish control parameters and to effect a resynchronisation or abort status as the result of some error condition. The information block also acts as an acknowledgement byte in the non chaining mode.
The LEN byte indicates the number of bytes (if any) in the information field of the frame. Its allowed range of values are from 00 - FE hex. This allows a maximum information field of 254 bytes.
The information field is used to convey the application commands and data.
The epilogue field contains the block error detection code which may be either an LRC (longitudinal redundancy check) or a CRC (cyclic redundancy check). The LRC is 1 byte while the CRC occupies 2 bytes. This option is defined by the specific interface characters.
Specific interface characters.
We have previously discussed the specific interface characters given by the answer to reset (ATR). The T = 1 protocol uses three of these characters to establish the necessary options before communication can take place. These bytes are assigned as follows (where i > 2),
The IFSC is the information field size for the card. There is also an IFSD which is the information field size for the interface device. This has a default value of 32 bytes and can only be changed by means of an S - block request from the IFD to the ICC.
Waiting times
The T = 1 protocol uses two waiting time parameters to help flow control,
The character waiting time is the maximum time between successive characters in a block while the block waiting time is the maximum time between the leading edge of the last character in a block sent by the IFD and the leading character of the next block sent by the card.
The character waiting time may be used to detect an error in the length of a block while the block waiting time may be used to detect an unresponsive card. There is also a block guard time (BGT) which is defined as the minimum time between the leading edge of the last character of one block and the leading edge of the first character in the new block to be sent in the alternative direction. The CWT and BWT are calculated from the values of CWI and BWI coded as shown previously in the specific interface bytes by means of the following equations:
The minimum value for the BWT is 100 mS + 11 etu when the card operates with the default frequency of 3.58 MHz. The block guard time has a value of 22 etu such that the delay between the start of the last character of a received block and the start of a transmitted block is greater than BGT but less than BWT. Accordingly the minimum inter block time is 11 etu which is equal to one character time.
Protocol control byte
The protocol control byte identifies the different types of block and carries some control information including a single bit sequence number (N) and a block chaining bit (M). Other bits are used to identify transmission errors. The PCB is coded as follows: Type PCB (bits 8-1) Function
The I blocks can occur as independent blocks or as part of a chain. The "More" bit is set to indicate that further blocks are to follow. The sequence number of the sender alternates between '0' and '1' starting with '0'.
The R blocks are used to acknowledge the successful or otherwise receipt of transmitted blocks. The sequence number N carries the value of the next expected value of N where the transmitter alternates the value as mentioned above. While blocks transmitted as part of a chain must be acknowledged by an R block the receipt of a successful stand alone I block may be acknowledged by an I block response. The two correspondents manage the sequence numbers of their I blocks independently alternating between '0' and '1'. The R block has three possible states as shown in the table.
| Type | PCB (bits 8-1) | Function | |||||||
| I | 0 | N | 0 | 0 | 0 | 0 | 0 | 0 | Standard I Block |
| I | 0 | N | 1 | 0 | 0 | 0 | 0 | 0 | Chain bit set |
| R | 1 | 0 | 0 | N | 0 | 0 | 0 | 0 | No errors |
| R | 1 | 0 | 0 | N | 0 | 0 | 0 | 1 | EDC / Parity error |
| R | 1 | 0 | 0 | N | 0 | 0 | 1 | 0 | Other errors |
| S | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | Resynch request |
| S | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | Resynch response |
| S | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | IFS request |
| S | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | IFS response |
| S | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | Abort request |
| S | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | Abort response |
| S | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | WTX request |
| S | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | WTX response |
The S blocks are used to invoke four control states as shown in the table. The resynch request is used by the IFD (only) to force a reset of the block transmission parameters to their initial values. A chain may be aborted by either the IFD or ICC perhaps due to some physical error such as memory corruption. The ICC may send an IFS request to invoke a change in the IFSC it can support. Similarly the IFD may send an IFS request to indicate a new IFSD it can support. The S block control also allows the ICC to request an extension to the block waiting time (BWT) that may be necessary to execute a command received in an I block. The INF field in this block contains a single byte integer value which is to be calculated as a multiple of the BWT value. In all cases the receiver of an S block should send the appropriate response block.
The T = 1 Protocol in operation
Using the notation of the ISO 7816 standard we can show the basic operation of the protocol. A more complete definition can be obtained from the standard.
M = More data bit
The More data bit is set when an additional I block is to follow in the chain
Where N = Sequence number of next expected block
The protocol defines that the IFD and the ICC each have the right to transmit in turn where communication commences with transmission of a block by the IFD.
Normal I block transmission
I Block Transmission with chaining
Note that an I block was used by the ICC to acknowledge the last block in the chain sent by the IFD. The ICC may send chained blocks in the same way as shown for the IFD.
Error handling in I block transmission
Error in I block receipt
Error in I block chain response
In both cases the transmitter is notified to retransmit the block received in error. There are of course a large number of possible error scenarios but they are all based on the simple concepts shown above.
Summary
In this article we have given a brief overview of the technology of Smart cards. We have looked at the basic components that make up the Smart Card and have explored the elements of the chip which are at the centre of this technology.
Many poeple have questioned why the introduction of Smart cards have been so slow for which the typical response has always related to the lack of standards. We have tried to show here that the standards do exist and that the central core necessary to build cards and devices are fairly well defined. It is particularly appropriate at this time to comment that there are several major commercial projects using Smart Cards such as "Mondex" (Global Electronic Cash) that are based on these ISO standards. Similarly we can now also report on the major payment schemes of Visa, Mastercard and Europay who have worked together to produce specifications based on the ISO standards for the introduction of chip cards in their varioius systems.
It has been said many times before but now at last we really are seeing the day of the Smart Card.
© 1997 Smart Card News Ltd., Brighton, England.
