Recently I found myself exploring the EMV protocol through exploring data on chip and pin smart cards. I bought the Akasa AK-ICR-09 smartcard reader from eBay and a mag-strip reader and began crawling through the EMV specification (books 1-3) which I sourced online. I starting playing with gscriptor to navigate my way around the records. This summary explains my findings, first from the mag-strip data and secondly from the EMV protocol investigation. I present a known security flaw in some older EMV smartcards which allowed me to retrieve the PIN number of a live debit card. Some output data has been removed and sometimes replaced with tags <> for security reasons.

I’ve explored some potential security flaws in modern chip and PIN smart cards and some practical recommendations for overcoming them.

Contrary to the claims of some online sources, my smartcard did not contain my PIN information. The track 1 data (start sentinel ‘%’ identifies it as track 1) below shows the format code ‘B’, and my name, expiration date, service code; some discretionary data; the end sentinel ‘?’ and a longitudinal redundancy check. I found the following information on the mag-stripe track two.

%B^^1508221000000000000000591000000? ^=15082215910000000011

Suspicious track one data

%B5545448618530755^^1005503000000000000000000000000

The above track one data is suspicious for the following reasons:

  • It’s out of date – its expiration date is 1005 (05/10)

  • It has no PIN verification value (PVV)

  • The ‘r’ in Mr is lower-case. Name should be all upper-case

  • The surname operator is not prefixed by a space

  • The surname is not all upper-case

  • Digit 3 of the service code indicates that the range of services are limited to ATM only with PIN authentication. Cannot be used in shops.

  • There is no ES (End Sentinel), i.e. ‘?’

  • There is no LRC (Longitudinal Redundancy Check – 1 character)

  • The card number starts with neither 34, 37, 4, or 51 indicating it is a non-standard/fraudulent number (not AE, VISA or MasterCard). MII (Major Industry Identifier) number is 5, implying American Express card, but AE has format 51xxxx-55xxxx.

  • Using the Luhn check, the checksum at the end of the card number is wrong. It should be 4.

Using gscriptor, I typed reset to reset the card. After being reset, the card responds with the ATR (Answer To Reset). These bytes convey information to the terminal that defines certain characteristics of the communication to be established between the card and terminal.

Beginning script execution...

ATR: 3B 6E 00 00 00 31 C0 65 BC D0 02 01 06 71 D6 8C 61
33
Script was executed without error...
Beginning script execution...
Sending: 00 C0 00 00 33
Received: 6F 31 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30
31 A5 08 5F 2D 02 65 6E 88 01 01 82 01 38 83 02 3F
00 86 03 86 FF FF 85 06 01 00 08 0A 05 B7 8A 01 07
90 00
Normal processing.

The last two words of the first response 61 33 indicate that there are 0x33 bytes of respose still available, so the command 00 C0 00 00 33 calls for the next 33 bytes to be received.

3B TS Indicates direct convention. LSB first
6E TO Format byte. Ox0E=14 historical bytes present
00 TB1 VPP not required. C6 contact redundant
00 TC1 Extra guardtime/delay between characters required
00 First historical byte. Rest in compact header format
31 C0 Card service data. TA3 and TB3 present; TC3 and TD3 absent; T=1
65 BC D0 02 01 06 ? Pre-issue data of some kind
71 D6 Use full/partial DF name or file ID; short EF ID or record number
8C
6F 31(file control information)
84 0E (DF name (1PAY.SYS.DDF01)4) 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31
A5 08 (FCI proprietary template)
5F 2D (language preference (en)) 02 65 6E
88 01 01 (Short file ID ‘01’)
82 01 38 83 02 3F 00 86 03 86 FF FF 85 06 01 00 08 0A 05 B7 8A 01 07 <- proprietary data elements from application provider
90 00 Success code

The PSE isn’t part of the ATR, but is considered part of the response to reset when the response length is increase.

Having reset the card and selected the ADF, I found the short file ID; opened the VISA app entering the VISA app state, and could check for the correct PIN. The script uses the command 80 CA 9F 17 00 to check the ‘tries’ counter and sends the command OO 20 00 80 08 24 00 00 FF FF FF FF FF to check if the PIN is 0000. This returns 63 C2 indicating an incorrect PIN.

The command OO 20 00 80 08 24 FF FF FF FF FF is then sent, thus checking the PIN , which returns the success code 00 09 indicating that is indeed the correct PIN.

The card is reset and the ADF selected. The command 80 A8 00 00 02 83 00 is the GET PROCESSING OPTIONS command message. It returns the Application Interchange Profile (AIP) and the Application File Locator (AFL). The data code ‘83’ is a data object coded according to the Processing Options Object Data List (PDOL) provded by the ICC. The response message is the BER-TLV coded data object 80 0E 5C 00 08 01 01 00 10 01 03 01 18 01 03 00 90 00. The tag ‘80’ denotes it as such, ‘0E’ is its length and the rest is the AIP which specifies the supported application functions by the ICC application. This includes the short file ID ‘01’.

This ID is used in the READ RECORD command 00 B2 01 0C 42 sent next, whereby the third code represents the record number (01) and the fourth code is the reference control parameter consisting of the SFI (Short File Indicator = record number) (first 5 bits) and 001 (last 3 bits indicating third code is record number), thus 00001100 = 0x0C. The ‘42’ is the length of the response message.

The secret stuff is the response message containing a record template. The first READ RECORD command returns the record ‘01’ from SFI 1, 0C = SFI<<3|4. This record contains the cardholders name and all of the track one and two data.

The second secret stuff shows the record when the reference control parameter is 0x14 = 00010100. The response template is ‘70’ and the record gives the application application effective data, expiry date and PAN (Primary Account Number); the default issuer action code to determine how to handle verification results and the success code.

Having reset the ICC and opened the PSE, I read the records to find the VISA app ID and used it to open the VISA app. I was then in the right state to check the PIN. I used the command 80 CA 9F 17 00 to check how many ‘tries’ I had left. I the used the command 00 20 00 80 08 24 00 00 FF FF FF FF FF to see the response on checking the PIN 0000. This returned the error condition 69 85 (conditions of use not satisfied). This is likely to be due to a change in the VERIFY command to initiate in the ICC the comparison of the Transaction PIN Data and the reference PIN associated with the application.

In order to overcome this problem, I could produce a PCB resembling a smart card with pads in the position of the chip and monitor the exact signals sent from an EMV terminal such as Barclays PINSentry, replicating that command using my smart card reader.

To check when I’m running the risk of blocking the card, I’d use the ‘tries’ check command (above) and the reset command 80 CA 9F 17 00 to reset the counter back to 3.

In order to find my records I used the command 80 A8 00 00 02 83 00 to get my processing options. This returned the AIP as shown below (formatted into columns to show records):

80 0E
Application Interface Profile (AIP)
3C 00
Application File Locator (AFL)
SFI 1st record total records records in offline authenticaion
08 01 01 00
10 01 02 00
18 01 03 02
90 00 success

The ALF shows the files and related records that shall be read for the currently selected application. I found data using the command 00 B2 01 c3 where = “<(SFI<<3)>” | “100”6, where is 08, 10 and 18.

For example, sending 00 B2 01 0C 4f where ‘4f’ is the length of the response message returns the following:

70 4D
Length of record template i.e. from here on
(rest is record template)
5F 20 (length ->) 1A ((cardholders name ->)) 42 45 4C 4C 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2F 54 20 4A 2E 4D 52 57 13 (Expiration date and service code ->)D1 50 82 21 23 80 00 00 00 01 1F 9F 1F 18 (Track one data ->) 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 32 33 38 30 30 30 30 30 30 90 00

ASCII:
pM_..BELL……………/T.J.MRW.
FXX…q..P.!#………00000000000
0000238000000..

This is the cardholder’s name and all of the track one and track two data7. These records provide all that’s needed to clone an EMV smart card. See appendix section 0 for complete records.

The fact that a PIN verifier can clearly be made so easily is a huge worry, since by having the ability to verify a PIN and the ability to reset the ‘tries’ counter, one can trivially check every possible PIN automatically until the correct PIN is found. See Section 10.

This means that thieves with access to stolen cards can find the PIN number of the card without the owner telling them. This also makes void the ‘Verified By PIN’ notion which claims EMV is secure unless the PIN is written or told to another, yet the legal system still considers it secure.

The EMV authentication protocol needs a complete overhaul to fix this and other problems with it, but this will be difficult to implement due to the current momentum of and dependence upon EMV smart cards.

Considering the security flaws in the EMV protocol, whereby should a thief have physical access to the card he/she can find its PIN, the only way to secure the smart card would be by some kind of hardware security module. There are multiple possibilities:

  • Small enclosure disguising the smart card as a shop voucher or membership card, such that a mugger wouldn’t have any interest in it.

  • An enclosure whereby a kind of biometric authentication was required to open it, i.e. retina.

  • An enclosure which destroyed/blocked/disabled the card upon tempering/incorrect PIN entry.

  • An enclosure with GPS tracking, limiting the thiefs time to find the PIN and potentially having him/her arrested.

In order to be secure, the hardware security module must have a strong enclosure or tamper detection and response circuitry which can zeroise the smart card, such as destroy the chip, block it or other. It should have identity based authentication mechanisms, such as biometric facial/finger-print/retina recognition. It should have logically secure APIs and have no physical security flaws such as information leakage or side-channel analysis vulnerabilities.

The ATR (Answer To Reset) is explained below:

3B TS: Direct convention
9F T0: Y = 0b1001, K = 15 (historical)
96 TA1
80 TD1: Protocol T = 0
1F TD2: Protocol T = 15
C7 TA3: Clock stop – no preferenec
Historical bytes:
80 Category indicator byte
Compact data object:
31 E0 73 FE 21 11 63
52 00 40 83 Pre-issuing data
07 LCS (Life Card Cycle)
90 00 Success

D8 Correct checksum I used the command A0 A4 00 00 02 xx xx where xx xx is the file identifier to navigate to EFs (Elementary Files) and DFs (Dedicated Files) and the command A0 B0 00 00 xx to read the binary files where xx is the expected length of the file in bytes. For example, I used the file ID 7F 20 to open the GSM EF, I was able to access the phonebook DF using 5F 50 under the EF 75 10.

When trying to access some files, I had the following problem:

Sending: A0 A4 00 00 02 6F B1
Received: 94 04
Error not defined by ISO 7816
Script was executed without error...

The error code 94 04 is the error code for file ID not found or pattern not found. The command above was intended to access the Voice Group Call Service.

I was, however, able to open some other EFs including emergency call codes and the SIM service table, among others.

This demonstrated to me how easy it was to extract data from a SIM. Although most of this data is non-sensitive, some of it could be used for identity theft.