Smart cards and smart objects communication protocols: Looking to the future. Denis PRACA Hardware research manager, Gemplus research Lab, France Anne-Marie PRADEN Silicon design program manager, Gemplus Lab, France ABSTRACT There is a lot of noise made around communication protocols and smart cards over the last few months. We will discuss about existing protocols and their adaptation to smart cards, limitations of ISO7816-3 protocol and the way to improve it. Finally, we will talk about security problems linked to some long-range wireless protocols. The protocols we will move on are the following: ISO 7816-3 standard and enhanced USB MMC ISO 14443 Bluetooth Improved communication with smart cards is useful if you consider applications such as biometrics on card, multimedia storage with copyright management, secure data storage KEYWORDS ISO7816-3, ISO14443, USB, MultiMediaCard, Bluetooth, JINI, SmartObject
1- INTRODUCTION In this paper, we will first discuss about the need to improve the low level communication protocol to smart card and the different way to do that. We will first take a look at the existing ISO7816-3 standard and then see how to improve it or change it to another existing standard. The applications for which we have to improve the performance are: Use of biometrics patterns in the card to replace PIN code Large memory cards used to securely stored personal or corporate information (Address book, price list, ) Smart card used to store multimedia content (Pictures, MP3, video, ) Card active in a network environment (The card must be able to be a master to query information over a network) Considering this list of applications, we will concentrate on 3 parameters while analyzing the protocols: Net Bandwidth The ability for the card to initiate a transaction The possibility to open multiple channels for multi-application purpose The last parameter is more related to high level protocol such as TCP/IP, but some elements in the lower level can help implementation. 2- ISO 7816-3 The performance of ISO7816 protocol is given by the elementary time unit (etu) value derived from D and F parameters. Accepted parameters by the card are sent by the card with the ATR (Answer to reset). F is the clock rate conversion factor, and D the baud rate adjustment factor. The formula that gives the etu value is: 1 etu = F/D * (1/f) where f is the clock frequency Tables are given in the standard; these tables give on one hand, the value of F for each FI coding and the corresponding f max allowed, on the other hand the D value for each DI coding. The corresponding bandwidth is given by the formula: Gross Bandwidth (Kb/s) = 1/etu =(D/F )*f * 1024. The bandwidth depends mainly on D value and not on F or f as the ratio F/f in the ISO tables is a constant value (except for F=0001). That is to say that the card clock may be high (max 20MHz) but the bandwidth is not increased accordingly. The protocol is basically an asynchronous protocol. It needs some extra bits to synchronize, in T=0 protocol, the physical layer overhead is as follow: 1 start bit 1 parity bit 2 guard time bit inter characters. For one character (8 bits), the protocol adds 4 bits, then the ratio to apply on the gross bandwidth is then 2/3 and defines the net bandwidth: Net bandwidth = 2/3 * Gross bandwidth In T=1 protocol, the overhead is reduced by 1 bit because the minimum guard time is 1 bit. In the case: Net bandwidth = 8/11 * Gross bandwidth The real bandwidth must take into account the T=1 block structure overhead, inter block guard time and data structure overhead: Block structure overhead: 5 bytes Block guarding time overhead: 22 bits Data structure overhead: 5 bytes
The total overhead is then Block overhead + Guarding time + Data overhead = 5 + 22/8 + 5 = 12,75 bytes for 254 bytes of real data. Real bandwidth = Net bandwidth * 254/266,75 Conclusions: Clock frequency Gross bandwidth Real bandwidth Timing for 64Mo downloading (1 hour of MP3 Music file) 5 MHz 430 Kbits/s 305 Kbits/s 28 40 (1720s) This protocol is basically a master/slave protocol where the card is always the slave. This problem is bypass by GSM standard at an application level, the mobile phone must periodically pool the card to allow it to be master in a transaction. T=1 protocol can be considered as a multi-channel protocol with addressing capabilities. 3- ENHENCED ISO 7816-3 ISO 7816-3 limitations comes from several issues in the standard: Electrical interface rising and falling edges gives a Max bandwidth of 500 khz. We have to redefine the I/O circuit in order to use a tri-state instead of open drain F/D ratio gives the number of clock cycles within an etu. A minimum number is needed in order to synchronize. 4 clock cycles seems to be acceptable. With a clock frequency of 20 Mhz, the gross bandwidth could be 1/etu = (D/F)*fmax = fmax/4 = 5 Mbit/s. Using an internal PLL, the minimum F/D ration can be decreased down to 1, giving a real bandwidth of 13,85 Mbit/s with a 20 Mhz clock signal. Clock frequency can be increased. The EMC radiation and power consumption in the card may dictate limitation of the frequency, but it seems that a frequency of 80MHz is conceivable in consideration of design care. In conclusion to enhance the ISO7816 standard in term of bandwidth we may: Change the electrical characteristics to the IO pin from open-drain to push-pull Change the F/D factor to the minimum (ex: 4) (new D factor : D=465) Increase the fmax to 80MHz for example (new F factor : 40Mhz, 80MHz) Advantages of this solution are: New smart-card readers may keep compatibility with existing cards New cards may be used with existing readers (if the RFU factors are ignored in the reader) Disadvantage: Increasing clock frequency will have impact on power consumption in the card, and then in mobile s battery life. With these changes in the standard the bandwidth would be: Clock frequency Gross bandwidth Real bandwidth Timing for 64Mo downloading (1 hour of MP3 Music file) 20 MHz 5 Mbits/s 3,46 Mbits/s 2 28 (148 s) 40 MHz 10 Mbits/s 6,92 Mbits/s 1 14 (74s) 80 MHz 20 Mbits/s 13,85 Mbits/s 37s 20 MHz with PLL 20 Mbits/s 13,85 Mbits/s 37s 40 MHz with PLL 40 Mbits/s 27,70 Mbits/s 18,5 80 MHz with PLL 80 Mbits/s 55,40 Mbits/s 9,25
Another way to improve this standard is to use a synchronous protocol, but problem of compatibility may occur. These enhancements don t solve the master/slave problem. 4- USB USB seems to be well adopted in the PC world and commonly used. USB smart card seems to be a good concept in this area. A USB smart card would be a mean to adapt the smart card to the PC world and not the opposite. This new solution consists of replacing ISO7816 transport layers by USB protocol in the smart card. Advantages of this solution are:! Reduce the Reader to the minimum : just an adaptation connector! Ease the Smart-Card penetration in the PC world! Use a high speed bus But what about GSM mobiles world? Has the USB Smart-Card an interest in this area? What is the performance gain? What is the incremental cost for the mobile? Example of Music is taken also in this part of the report. Performances: The use an USB bus for downloading of music gives these theoretical results (considering that the bandwidth is not shared with other devices). (The download of music uses a bulk transfer for full and high speed and interrupts transfer in low speed). Speed bus Real bandwidth Timing for 64Mo downloading (1 hour of MP3 Music file) Low speed 375 Kbits/s 23 20 (1400s) Full speed 9,5 Mbits/s 54 High speed 416 Mbits/s 1,23 These figures assume that there are no bottlenecks in the smart-card system and any other peripherals requiring bandwidth on the bus. Complexity: Complexity of USB hardware is essentially located in the host side. Host function hardware is around 5 times more complex in term of number of gates than the hardware device function (4 endpoints without double buffering). The device hardware function complexity depends of the number of endpoints managed, on the double buffering function which speeds-up the exchanges (for bulk of isochronous mode) and on the width of the buffers. Here are for different functions the hardware complexities in term of number of gates. For a low speed device interface with an 8 bytes block size, it requires about 4k gates. For a full speed device interface, it requires between 14k to 20k gates, depending the numbers of end point and the size of the fifos. We have no figures for a high interface. For the host side, the hardware complexity is about 30k gates. For comparison, an 8 bits microcomputer currently used in a smart card requires about 15k gates. The software complexity for a device is relatively low, few Kbytes of code are needed. For the host side, this is more complex, the host must support all types of transfer and be aware of all types of peripherals supported. On PC hardware, USB drivers require about 100 Kbytes of code. Clock recovery:
5- MMC The clock recovery internally in the card itself seems to be a technological challenge. Solutions are: Embed an oscillator in the card (difficult to package), practically only feasible with low speed because of precision requirements of high speed. External oscillator: needs a coupler between Card and GSM or PC. Decrease interest of this technology for the card. Use of USB like bus with an added clock pin coming from the GSM: no compliance with real USB bus. Recovery of clock with D+ and D- signals: need experiments, seems to be a real technological challenge, need mixed technology (Analog PLL, with a fast locking and very precise). Conclusions: USB seems to be a good candidate for the PC world, the bandwidth may reach 10 Mb/s with some possibility to enhance to USB2.0 high speed capability. But USB is too complex for low cost mobile equipment and some technical issues like clock recovery are to be solved. The master/slave problem is not directly solved by USB, but the standard includes an interrupt mode of transfer, allowing the slave device to be periodically pooled by the master. This capability is driven by the low-level protocol stack and is transparent for the application. An association grouping together the major silicon memory providers, mobile phone and multimedia device manufacturers drives the MultiMediaCard specifications. The basic protocols characteristics are: Variable clock rate 0-20 Mhz No explicit reset signal. Power-on reset circuitry on the card 3 wires serial data bus (Clock, Command, Data) Up to 64k cards addressable by the bus protocol Up to 30 cards stackable on a physical bus Error protected data transfer Easy card identification Sequential and single/multiple block oriented data transfer Synchronous transfer relative to the clock signal On the CMD line, Command and response tokens are transferred serially from the host to cards or from the cards to host respectively. On DATA line, data are transferred from the card to the host or vice-versa. After a power-on reset the host initializes the cards in assigning a session address for each. Each card has a Card Identification number (CID) unique whose MID field (Manufacturer Identification) is assigned by MMCA. Two types of data transfer commands: Sequential commands: these commands initiate a continuous data stream on data line which is stopped when a stop command follows on the CMD line Block-oriented commands: these commands send a data block succeeded by CRC bits. Single or multiple blocks are possible. Multiple block transmission is terminated when a stop command is sent on CMD line. For block write operation, a busy signaling is used on data line. As data id transfer on a specific line and commands or status on an another line, there is no overhead in the protocol if you use the sequential mode (No error protection in this case). The bandwidth is then directly related to the clock frequency and can be up to 20 Mbit/s. The drawbacks of this protocol are: The card is always slave No card insertion detection, the initialization procedure has to be done each time a card is inserted.
Conclusions: This protocol is very simple to implement, the bandwidth is very interesting and the possibility to stack multiple cards is important in many applications. But some improvement concerning hot insertion and extraction have to be considered as well as a way to make the card master of a transaction, either at the lower level of protocol or by the system driver. Work is done in the MultiMediaCard association around a secure MMC card that will probably use WIM specifications as a basis. 6- ISO 14443 ISO 14443 is the new standard for wireless close coupling smart cards. Its used a 13.56 Mhz magnetic field produced by the reader to power supply the card. The communication from the reader to the card is done by an amplitude modulation of this magnetic field. The return path use an impedance modulation of secondary coil located in the card, seen by the reader as a current modulation in the primary coil. Basic bandwidth is 115 kbit/s but can be upgraded up to 800 kbit/s. The standard integrate some features to detect multiple cards present in the field and to select one. The higher protocol level use a ISO7816-3 T=1 derivative. 7- BLUETOOTH Bluetooth is a wireless communication protocol design for the last 10 meters. Its primary goal is to replace cables between portable devices such as mobile phones, computers, PDA s with a maximum gross bandwidth of 1 MBit/s. In many of these devices, a smart card is used for security and user authentication. The idea to use to the same protocol to share a same security device is interesting but some limitation to the integration in smart card may be found: Power requirement bluetooth is too high for the existing or short coming battery compatible with smart card thickness. An efficient multidirectional antenna requires some volume But wireless communication accommodates to new form factor, as the device doesn t need to be plugged in a reader. This open a new range a devices we called smart objects WIRELESS SECURITY PROBLEMS When the cable is suppressed, the link to a secure device is open to any kind of observation from a hostile device. Bluetooth is well protected against this type of attack by the use of strong encryption algorithm and by the fast frequency hopping used by the radio link. But the main problem is the pairing of devices: to be able to communicate, 2 devices must share a secret. The user of the devices has to enter this secret like a PIN code on the 2 devices he wants to connect. The management of this PIN code is complex: On devices without keyboard like headsets, the PIN code is hard coded You have to remember as many PIN code as pair of devices you want to connect or make them permanent but with security problems How to lend a device to a friend for a limited period of time? We think that to solve this problem, we must use a trusted device acting as an authorization center. 8- CONCLUSIONS There is no ideal candidate to succeed to ISO7816-3, but some good features must be kept: Synchronous data transfer Separate DATA and COMMAND line USB interrupt mode to avoid collision management Stackable cards Electrical insertion and removal detection like in USB to simplify connectors
1- The implementation must be simple both in the card and in the device using the card Another important issue is the global system performance. There is no need to improve the bandwidth if the system is unable to process the data at full speed. Most today smart card use 8 bit microcomputers, the amount of processing capabilities seems not to be able to process more than several hundreds of kbit/s. DMA capabilities must be added for fast transfer of data to memory and new memory architectures will be studied. Today large Flash silicon memories write cycles are limited and pipelining of multiple flash is mandatory. 9- REFERENCES ISO/IEC 7816-3: Information technology-identification cards-integrated circuit(s) cards with contacts- Part 3: Electronics signals and transmission protocols MultiMediaCard System Specification, Version 2.2 Universal Serial Bus Specification: Revision 1.1