General security

Introduction to Smartcard Security

Introduction

In 1968 and 1969, the smartcard was patented in German by Helmut Gröttrup and Jürgen Dethloff. The smartcard is simply a card with an Integrated Circuit that could be programmed. This technology has been used widely in our daily lives and will become one of the important keys in Internet of Things (IoT) and Machine to Machine (M2M) technology. Smartcard applications could be programmed using Java Card, an open platform from Sun Microsystems. Today, we find smartcard technology mostly used in communications (GSM/CDMA Sim Card) and payments (credit/debit card). This is an example of smartcard technology that has been used in Indonesia:

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Picture 1. EMVd ebit card.

Picture 2. Bolt 4G card.

Smartcard Architecture

Picture 3. Smartcard architecture (image courtesy of THC)

How Does the Smartcard Work?

1. Smartcard Activation

In order to interact with the smartcard that has been connected to a smartcard terminal, it should be activated using electrical signals according to smartcard specification class A, B, or C (ISO/IEC 7816-3). The activation sequence goes like this:

RST pin should be put to LOW state.

Vcc pin should be powered.

I/O pin on the smartcard terminal should be put to receive mode, even though it could ignore the I/O logic while smartcard activation takes place.

CLK pin should provide clock signal to the smartcard.

More detailed information about this smartcard activation (before timing T_a) can be seen in this picture:

Picture 4. Smartcard activation and cold reset.

2. Cold Reset

At the end of activation (RST pin pulled to LOW, Vcc pin has been powered, I/O on smartcard terminal has been put to receive mode and CLK pin supplied a stable clock signal), then the smartcard is ready to enter Cold Reset.

As you can see from the above picture, the clock signal at the CLK pin starts at T_a and the smartcard will set the I/O signal to HIGH in 200 clock cycle (t_a delay) after the clock signal is applied to CLK pin (T_a+ t_a). The RST pin should be kept in LOW state for at least 400 clock cycles (t_b delay) after clock signal has been given to CLK pin (T_a + t_b). The smartcard terminal could ignore the logic in I/O pin when RST pin is on LOW state.

RST pin then change to HIGH state after reaching T_b. I/O pin will begin the Answer-to-Reset from 400 to 40000 clock cycle (t_c delay) after rising edge signal in RST pin (T_b + t_c). If there is no answer after the 40000 clock cycle when the RST pin is in HIGH state, then the smartcard terminal could deactivate the smartcard.

3. Smartcard ATR (Answer-to-Reset)

After the smartcard performs a cold reset, then it will continue with Answer-to-Reset (ATR). The complete ATR structure is covered in ISO/IEC 7816-3, and it looks like this:

TS T0 TA₁ TB₁ TC₁ TD₁ TA₂ … … TD_n T₁ … T_K TCK

For example, this is the Answer-to-Reset that we receive after performing a cold reset on a smartcard:

3B BE 94 00 40 14 47 47 33 53 33 44 48 41 54 4C 39 31 30 30

After receiving the ATR above, we then continue with interpreting the data as follows:

TS = 3B

It means that the smartcard operates using direct convention that works almost like UART protocol. The direct convention operation was covered in ISO/IEC 7816-3.

T0 = BE (1011 1110₂)

- High nibble (B₁₆ = 1011₂) means that there is a data on TA₁, TB₁, dan TD₁.

- Low nibble (E₁₆ = 14₁₀) means that there is 14 bytes of history data (T_K).

TA₁ = 94 (1001 0100₂)

- High nibble (9₁₆ = 1001₂) means that the clock rate is F_i = 512 with f_max = 5 MHz.

- Low nibble (4₁₆ = 0100₂) means that bit rate D_i = 8.

TB₁ = 00

According to ISO/IEC 7816-3, the TB₁ and TB₂ has been deprecated and not used anymore so the smartcard doesn't have to transmit it and the smartcard terminal could just ignore it.

TD₁ = 40 (0100 0000₂)

- High nibble (4₁₆ = 0100₂) means that TC₂contains data.

- Low nibble (0₁₆ = 0000₂) means that the smartcard is using T = 0 protocol.

TC₂ = 14 (20₁₀)

This is the Waiting Time Integer (WI) with a value of 20. From the ISO/IEC 7816-3, the value could be used to calculate Waiting Time (WT) with this formula:

History bytes = 47 47 33 53 33 44 48 41 54 4C 39 31 30 30

This could be converted to ASCII : G G 3 S 3 D H A T L 9 1 0 0

4. Protocol and Parameter Selection Interface (PPS)

After getting Answer-to-Reset (ATR), the smartcard interface then could send PPS instruction to choose which protocol and parameter it would use to make data transfer between the smartcard and the terminal easier.

5. Data Transfer Between Smartcard and Terminal

After the Protocol and Parameter Selection (PPS) has been setup, the smartcard and the terminal interface could begin transferring data using Application Protocol Data Unit (APDU). The complete structure for APDU is covered in ISO 7816-4.

Vulnerabilities

There are quite a lot of vulnerabilities related to the java card, and most of them have been documented across the Internet. This is some of the smartcard's attack vector:

1. Physical attack:

Reverse engineering.
Smartcard cloning.

2. Remote attack:

IMSI catcher.

Attacking a Smartcard

1. Physical Attack

Physical attack could be carried out if the attacker has physical contact with victim's smartcard and gets access to important data on the smartcard. Once the attacker has access to that important data, he/she could perform a smartcard cloning or reprogramming of the smartcard.

1.1. Reverse Engineering

Picture 5. Typical smartcard front side.

Picture 6. Typical smartcard back side.

Picture 7. Smartcard IC "die"

Reverse engineering smartcard at silicon level is not an easy task and requires some special tools such as Scanning Electron Microscope (SEM) and/or Focused Ion Beam (FIB).

1.2. Smartcard Cloning

For this purpose, an attacker could use a couple of devices like an oscilloscope and smartcard reader. This is an example of DIY smartcard reader (phoenix reader):

Picture 8. DIY smartcard reader (phoenix reader).

However, there's a catch for the phoenix reader like the one in the above picture – its lack of application for interfacing with smartcard. The reference schematic for phoenix reader used in the above picture was developed by Dejan Kaljevic and is freely available.

Picture 9. Phoenix reader schematic.

Smartcard cloning is not just about programming the smartcard, but also retrieving important information about the victim's smartcard such as which vendor issued the card. The more convenient way to interact with the smartcard is by using PCSC reader with an opensource application called pcsc_scan. This is an example of pcsc_scan usage:

Picture 10. Information retrieved from smartcard payment.

Picture 11. Information from 3G/4G smartcard.

As you may see in the picture above, we could get some information from the smartcard attached to the terminal. Picture 10 shows a smartcard that's commonly used in a financial institution which complies with the EMV standard, and picture 11 shows a smartcard (USIM) that's commonly used for communication (3G/4G). That information could be used to determine what kind of encryption the smartcard uses, since vendors tends to follow standard specs and not use custom encryption. Attackers could then use the information to perform a remote attack.

2. Remote Attack

Remote attacking smartcard could be achieved by exploiting vulnerabilities in the smartcard. For example; by injecting malicious "binary sms".

2.1. IMSI Catcher

The cost for this kind of attack is quite high, since the attacker must have some kind of hardware that could run OpenBTS and work as a fake BTS. In order to become a fake BTS, that hardware should generate a stronger signals than the real BTS to force the victim's terminal (i.e mobile phone) to connect to the fake BTS.

Picture 12. Fake BTS (IMSI catcher) illustration.

After the victim's mobile phone is connected to the fake BTS, the attacker then could send a payload using the Over-the-Air (OTA) method that is common for GSM networks and direct the payload to the smartcard inside the mobile phone.

Conclusion

From the explanation above, we can conclude that an attacker who could exploit a vulnerability on smartcard would result in a catastrophic event, especially if it's related to a critical infrastructure, such as a SCADA installation that utilizes GSM networks or financial institution that utilize GSM networks for their mobile banking. In order to prevent such an attack on a smartcard, vendors could implement some protection, such as developing custom EEPROM for java card.

References