Smart Cards - Answer To Reset (ATR)


Card Trick

One of the least explored areas of EMV lays in initial stages of terminal to card communication. A card lodges a data message in its memory upon power up. Layout of this message conforms with ISO/IEC 7816 and can be retrieved by a card reader (sReaderState.cbAtr). The ATR message contains information on proposed card communication parameters, card's manufacturer or issuer, application selection options, country code and more. The ATR functionality is fully documented in ISO/IEC 7816 and many more documents, however those documents focus on Smart Cards in general and not payment cards. Therefore the aim of this article is to explain ATR in relation to EMV/NFC technology.

In this article we will review the ATR data elements (DE), but  focusing on DE importance in a  payment transaction. ATR fields covered:

  • The initial byte (TS)
  • The format byte (TO)
  • The interface bytes (TAi, TBi, TCi, TDi)
  • The historical bytes (T1,T2. TK)
  • The check byte (TCK)

The Initial Byte (TS)

The initial byte TS is a mandatory bit communication synchronization pattern. ATR values for this byte should read 0x3F or 0x3B. Processing of this value is usually handled by the card reader's driver. It's also advisable to check this value as an initial sanity check for card being plugged in.


The Format Byte (TO)

The format byte is another mandatory field providing a bitmap from which one implies the remaining ATR fields. The first (most significant) 4 bits refer to the presence of TA1, TB1, TC1 and TD1 characters. The least significant bits refers to the size of historical data in bytes allowing an additional 0 - 16 bytes of historical data to be added to the message.


The Interface Bytes (TAi, TBi, TCi, TDi)

These conditional bytes are referred to as the global interface bytes and define a card's operational abilities. In brief these fields refer to:

  • TA1 - the card's chip clock-rate and bit rate adjustment factor
  • TB1 - EEPROM programming voltage and current
  • TC1 - extra guard time to be used between successive bytes
  • TD1 - indicates sub-bytes presence and protocol type. Only two meaningful values for protocol type here are T = 0 or T = 1, all others are currently reserved for future use (RFU).

Subsequent fields TAi+1, TBi+1, TCi+1 and TDi+1 are out of scope for this article.


The Historical Bytes

Historical Bytes typically hold Information about the Card Issuer, Type of Card or Operating System Version and this is where it becomes complicated. These bytes can be lodged in a proprietary format of a card manufacturer/issuer, or can be formatted in "compact TLV". Unlikely EMV TLV, compact TLV uses 4 most significant bits to tell a tag and 4 least significant bites for data length. However the first byte of historical data coded in compact TLV should always read 0x00 or 0x80.

Some known compact TLV tags:

Tag 0x1h: Country code in (ISO 3166-1)

Example: 0x12 0x00 0x36 -> Australia

Tag 0x2h: Issuer identification number (ISO 7812-1)

Example: TBA

Tag 0x3h: Card service data byte

When a bit is set to 1 in the card service data byte one may use that service.

BitDescription
8 Application selection: by full DF name
7 Application selection: by partial DF name
6 BER-TLV data objects available in EF.DIR
5 BER-TLV data objects available in EF.ATR
4 EF.DIR and EF.ATR access services: by READ BINARY command
3 EF.DIR and EF.ATR access services: by GET DATA command
2 EF.DIR and EF.ATR access services: by GET RECORD(s) command
1 EF.DIR and EF.ATR access services: RFU

Example: 0x31 0xC0 ->

  • Application selection: by full DF name
  • Application selection: by partial DF name
  • EF.DIR and EF.ATR access services: by GET RECORD(s) command

Tag 0x4hInitial access data

Example: TBA

Tag 0x5hCard issuer data

Example: TBA

Tag 0x6hPre-issuing data

Example: 0x64 0x19 0x16 0x01 0x02

Tag 0x7h: Card capabilities

When a bit is set to 1 the card has the specified capability selection mode:

BitDescription
8 DF selection by full DF name
7 DF selection by partial DF name
6 DF selection by path
5 DF selection by file identifier
4 Implicit DF selection
3 Short EF identifier supported
2 Record number supported
1 Record identifier supported

Example: 0x71 0xD6 ->

  • Record number supported
  • Short EF identifier supported
  • DF selection by file identifier
  • DF selection by partial DF name
  • DF selection by full DF name

Tag 0x8h: Status indicator

Example: TBA

Tag 0xEh: Application identifier

Example: TBA


Summary

As demonstrated above, a good understanding of ATR is a very important part of EMV functionality. In particular the ATR's historical data can provide a payment device with several important clues to a card's processing (selection options and the way card's service options can be retrieved). Please let us know if you can contribute with your knowledge to this article - our team of EMV experts is ready to update information as we endeavour to start a community repository of EMV expertise.

Further reading on this topic can be found in our knowledge base document: Complete list of known ATRs.

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...