The following is taken from What’s an ATR, APDU..? Smart card terminology explained | Smartcard Focus Buzz!
Smart cards started out purely as plastic cards with chip modules embedded into them, with the usual pattern of gold or silver contacts in a standard position. These contacts provide a relatively simple two-way serial comms interface, over which a PC or another system can talk to the card, sending it commands and getting back responses.
When a contact smart card is inserted into a smart card reader, such as the popular ACR38, Omnikey 3121 or Cloud 2700R, the reader sends power and a reset signal to the card, and the card responds with a dozen or more bytes of data known as the Answer To Reset (ATR). This is usually a fixed sequence for any particular make and model of card, and is intended to tell the reader/system some (limited) information about the card and its capabilities, for example the maximum speed it can operate at, and its preferred voltage and clock frequency.
After receiving the ATR, the reader, reader drivers and/or host software can then adjust various parameters before getting stuck in with talking to the card (we’ll come to that bit later!)
With contactless smart card technology, some cards, such as dual-interface Java cards, work in a similar way, even though the comms is done wirelessly. The contactless smart card reader will energise the card when it enters the RF field, and receive the same or a similar ATR, after which two-way comms is established with the on-board microprocessor.
Other contactless cards though, such as MIFARE Ultralight or MIFARE Classic, are less intelligent and don’t have an on-board micro, or a proper ATR, in which case the reader or reader driver will effectively make one up, usually according to the PC/SC standard, to indicate the type of card found. Contactless readers, such as the ACR122, ACR1252 and Omnikey 5021 CL all work in the same way, although there are sometimes subtle differences between them when it comes to handling MIFARE cards and/or switching into different communications modes with different types of cards.
There are three main communications modes when talking to a microprocessor based smart card, known as T=0, T=1 and T=CL. The last of these is the one used for contactless smart cards, whereas T=0 and T=1 are two different options that can be used for contact smart cards. Some smart cards will only support one mode, while others support both, although they will normally have a preferred mode, indicated by their ATR. Of these, T=0 is a simpler protocol where individual blocks of data, no longer than 256 bytes, are sent back and forth, and the application is responsible for assembling any commands or responses that are longer than the block length. With T=1, the lower level driver, or the smart card reader itself, looks after this task, although in practice the application still has to handle some aspects of fetching multiple block responses.
Smart cards generally work using a set of commands, sent from the application to the card in a block known as an APDU (Application Protocol Data Unit), and which the card will respond to with an APDU response. The response may be a simple “Ok – done that” confirmation message, or it might be some data, for example the contents of a particular file on the card, or an encrypted version of some data, using a secret key.
It is important to realise that different cards implement different commands, as well as having different capabilities, such as which encryption algorithms they support, how much data they can store, and whether they have key and random number generation facilities on board.
Some cards are fixed function, with a set of commands specified by the manufacturer, and no facility to run customised processes on the card itself, whereas others, such as Java cards, rely on custom applications being developed and installed on the card, in which case the commands used to communicate with the application are devised by the app developer.
Finally, you may have noticed the terms PC/SC and CCID mentioned often in relation to smart card readers. The PC/SC standard was originally created as a cross-platform method for interfacing readers with software applications, and has been fully implemented by Microsoft on Windows, and partly implemented on Linux in PC/SC Lite. This removes the need for a software application to know exactly which make or model of smart card reader is attached, by standardising the methods for finding out what readers are available, detecting smart cards being inserted or removed, and then communicating back and forth with a particular card. This works well, although in practice, particularly with contactless cards, this sometimes needs additional code to deal with special cases, and it is also important when developing apps on Windows to realise that the operating system is also looking for cards in the background, as part of the Microsoft native PKI smart card logon functionality.
The most recent USB smart card readers also conform to the CCID standard, which specifies how they communicate at a low level (ie the actual commands sent via USB). This means that, in theory, any CCID smart card reader can be installed on Windows without the need for a dedicated driver, because the default Microsoft driver will be automatically selected, just like other USB class devices (keyboards, mice and flash memory sticks).