Many banks across USA, Europe, and Asia have introduced a new payment system, EMV, also known as Chip and PIN. EMV is a complex standard that defines the protocol used between a point of sale terminal and a smartcard. I provide a general understanding of EMV and details of the parts related to my project in the next chapter.
In a normal payment scenario (e.g. purchasing food at a supermarket) the terminal is owned by the supermarket and the smartcard is owned by the issuer bank. Thus the card user has no control over the transaction entities. In this scenario it is possible for someone to tamper with the terminal such that the amount shown on the display is higher than the amount requested to the card. The user will confidently enter the PIN and authorize the transaction.
Financial fraud in the UK has not decreased over the last years, even after Chip and PIN has been introduced. According to APACS [3] the overall level of frauds has remained relatively the same, even if the level of particular types of fraud has changed. Murdoch et al. [22] suggest that EMV has simply moved fraud, but not eliminated it. Therefore the discovery of vulnerabilities and the development of solutions against financial fraud remains an important need.
It was the main goal of this project to create a man-in-the-middle device, called Smart Card Detective (SCD), that would be able to prevent the attack described above. Such a device would have to intercept the communication between a card and a terminal, provide the user with the ability to observe the amount requested by the terminal, and then continue or reject the transaction based on the user decision.
Another goal of this project was to build a device that is small enough to hold it in a hand like you hold a mobile phone, and cheap enough for many users to actually afford. The motivation for this was to prove that a miniature device, able to perform man-in-the-middle EMV operations such as protecting users against fraud can be built.
After first creating a prototype board to prove the correctness of my design, I managed
image 1.1 The Smart Card Detective
to create a hand-held device that provides a trusted display for a transaction and allows users to defend against relay attacks. In Image 1.1 you can see an image of the final device.
A recently discovered vulnerability allows the use of any card (possibly stolen) without knowing its PIN. The French press has published news about the attack but they reported the scenario as being hard to execute in practice because it required specialized and complex hardware.
I have managed to implement this attack on the SCD quite easily as I already had a robust framework in place which made the implementation straightforward. This proves that a small and cheap device is able to tamper with a complex system such as EMV, but also suggests that technically competent criminals may have already developed their own devices.
The results of experiments using multiple cards and readers as well as some interesting findings are presented.
SCD overview
In this chapter I present the Smart Card Detective, giving an overview of the components involved, its functionality and the applications implemented so far. Details about the implementation, the challenges encountered, and the decisions made, are described in the next chapter.
1. Hand-held device
An illustration of the SCD with the main components highlighted is shown in image 1.2.
image 1.2. Image of the SCD, component side (a) and user interface side (b)
The user interface is composed of an LCD with 16 characters divided in two rows, 4 push-buttons, 4 low-power LEDs, and a power switch. The LCD can be placed in two positions, differing by a 180 degrees rotation such that the LCD screen can be read in different orientations of the SCD.
image 1.3 Smartcard Interface PCB
The user smartcard is inserted into the card slot (user interface side), and the SCD is connected to the terminal using a smartcard interface. For the smartcard interface I have designed a special Printed Circuit Board (PCB) having the same dimensions as a bank smartcard, which assures a reliable connection between the terminal and the SCD (see image1.3).
A normal usage scenario is as follows: first the user inserts the smartcard in the SCD, then switches on the device and selects the desired application. At this point the user insertsthe PCB card interface into the terminal and proceeds with the selected application. The applications are presented below.
2. Applications
There are currently five applications implemented: Forward Commands, Store PIN, Modify PIN, Filter Amount and No PIN.
The applications are selected from the boot menu. In order to access the boot menu the button BB must be pressed while resetting the device (pressing the RST button on the component side). Once the boot menu is accessed, the user can press BC to scroll through the list of applications and then select the desired application by pressing BD.
Forward Commands shows live information about the transaction on the LCD and logs the commands and responses without modifying or blocking the transaction. The log is stored in the EEPROM of the device and can be retrieved via any programming interface. The log mechanism can be used with all the applications presented below.
The Store PIN application as its name suggests is used to store a PIN into the EEPROM memory. This PIN is used by the Modify PIN application to modify the PIN that is transmitted in a transaction. In this way the user can make any transaction without ever typing the real PIN. To store the PIN I currently extract the necessary information from the VERIFY command. As a result the keypad of a terminal (including CAP readers) can be used to type the desired stored PIN.
Filter Amount represents the main goal of this project. This application eavesdrops on the communication between the card and the terminal until the terminal sends a Generate AC command. At this point the SCD blocks the communication and shows the requested amount to the user. The user can check the transaction amount by scrolling through the menu displayed pressing BC. Then pressing BA will allow the transaction
to continue while pressing BD will terminate the transaction and restart the SCD.
Finally, the No PIN application is the implementation of the attack discovered recently by Steven Murdoch. Using this application the user can make a Chip and PIN transaction without knowing the PIN of a card even though the transaction receipt will read PIN VERIFIED.
Details about the design and implementation of the SCD are presented in the next chapter.
An evaluation and analysis of the applications implemented as well as results from real
tests are presented in Next capter.
Evaluation
With the hardware and software in place it was time to perform an evaluation of the SCD, in terms of hardware, software, and functionality. The results and observations are presented below.
Most of the tests have contributed to progressively improve the device in terms of performance and functionality. During the laboratory experiments I used the three analysis tools presented earlier: the .NET debugger to trace commands and responses as seen by the terminal emulator, the AVR dragon to check the state of the microcontroller (in terms of memory, execution path and I/O levels), and the oscilloscope to trace the signals from card and terminal (amplitude, frequency, bit duration).
1. Basic functionality
One of the first things to test was the correct functionality of the peripherals: the LCD, buttons and LEDs. This was done in a method (TestHardware) that performs simple I/O operations.
The next step was to verify the correct transmission of bytes between the terminal and SCD. This was done first by means of the terminal emulator as I could create my own test case and verify the results. Initially I verified that the ATR is correctly sent by the SCD, and then I checked that sequences of commands are correctly received and responded to. After that I created a reliability test case, where I wanted to verify the correct transmission of a large number of bytes. For this scope I created a loop transaction flow using the terminal emulator. A similar loop was used in the SCD. The SCD successfully exchanged data uninterrupted for 30 min (approximately 10 MB of data at a terminal frequency of 4 MHz, considering data is sent half of the time) before I ended the test. Similar tests have been done to check the correct communication between the SCD and card.
Once the SCD proved to work with the terminal emulator, I started the tests with CAP readers, which provide a real test scenario. I have used three different CAP readers, from Vasco, Natwest and Barclays. They execute a real transaction flow and have different working characteristics. The Vasco reader operates at 1 MHz, while the Natwest and Barclays readers run at 1.5 MHz. Also the Vasco reader starts a transaction but stops the power and clock soon after receiving the ATR. The transaction is then restarted when
the user selects the desired application. The Natwest reader keeps the power and clock from the moment the card is inserted until the transaction is over. Finally the Barclays reader behaves similarly to the Vasco reader but sends an initial short restart signal before actually starting operation. The diversity of operation provided by these three readers provided a good input to improve the SCD functionality. The evaluation of the complete SCD functionality including tests on CAP readers is discussed in section 3.
2. Power consumption
The main objective of the SCD was to be used as a hand-held device in real payment scenarios. Thus power consumption is a critical factor as the battery may be exhausted very quickly if good power management is not in place.
Using a variable power supply I tested the SCD operation with different voltage and current intensity. I found several factors that make a big difference in the overall power consumption, as presented below.
First of all, it is important the way in which the I/O line is set up for reception mode. The pull-up resistor of the I/O pin (PB6 for the card) should be enabled instead of driving the line high. When the line is driven high the power consumption of the ICC is much higher (with spikes of about 30 mA difference) than when using the pull-up resistor. I have noticed an important difference by changing the sequence of the following instructions,
which set the card I/O line to reception mode (state Z) :
• Good way :There are six I/O ports (labeled A through F) available in the AT90USB1287. Most of the ports have 8 pins. The direction (input or output) of each pin is controlled by
DDRB &= ˜( BV(PB6 ) ) ;
PORTB |= BV(PB6 ) ;
• Bad way :
PORTB |= BV(PB6 ) ;
DDRB &= ˜( BV(PB6 ) ) ;
table 1. Port pin configurations for AT90USB1287. Extracted from datahseet
the DDRx registers (where bit 3 of DDRB controls the pin PB3 of port B), while the PORTx registers control the voltage on that pin (high or low). The possible states for each port are shown in table 1.
Back to setting the I/O line correctly, what happens in the first case is that initially PB6 is set as input with no pull-up (assuming PORTB6 was 0), and then PORTB6 is set to 1 which enables the pull-up. This sequence will cause the voltage on the I/O line to gradually increase from 0 to approximately 3.78 V which is given by the pull-ups of the AT90USB1287 and ICC. In the second case, the I/O line is first set to high and then
DDRB6 is set to 0, changing the pin direction to input which enables the pull-up resistor. In this case the voltage on the I/O line spikes to around 5 V and then decreases slowly to the value of 3.78.
I also noticed that the ICC does not drive the I/O line correctly (after testing with several cards). When the ICC transmits a ZERO bit to the SCD, it pulls the line low (ground) correctly. However, when the card transmits a ONE bit, it first uses the pull-up resistor to rise the voltage to around 4 V and then immediately switches the port to high impedance such that the voltage drops to around 1.5 V. Thus, if the SCD uses the high impedance mode on the I/O line as well, the communication ends. So the terminal (and implicitly the SCD) must enable the pull-up resistor on the I/O line even when it is receiving a byte from the ICC. Such functionality does not respect the EMV standard which states that the voltage used by the card for a transmitted bit ONE should be [3.5, 5] V for VCC = 5V.
Another important power consumer is the LCD. The model I use (EVERBOUQUET MC0802A-SGR) consumes between 10-30 mA during operation. There are other LCDs with lower power consumption, but this was chosen based on its low cost (£5). In this situation is very important to use the LCD only when needed. After many experiments I realized that the best method to reduce the LCD power consumption is to delay sending any commands to the LCD until the last possible moment. Although the HD4778 controller (available in the MC0802A LCD) provides commands for turning the LCD on and off, these do not change the power consumption. In fact, sending a power off command (with or without prior initialization) to the LCD will increase the power consumption. Resetting the SCD after using the LCD seems to be the best solution to keep a low power consumption. This will restart the LCD controller, which will not start running (and thus will not consume power) until a first command is sent.
With all the improvements in place, the total consumption of the SCD (including LCD
and card operation) is around 40 mA.
and card operation) is around 40 mA.
Image 4. Battery discharge for a CR2430 cell battery under low current consumption
(less than 2 mA) (a), and estimated discharge for two CR2430 batteries under higher
consumption (average of 30 mA)
The battery discharge in time for one of the 3V CR2430 cell batteries is shown in figure 6.1(a). As it can be seen, this type of batteries are designed for a load of at least 2.5 K Ω (i.e. less than 2 mA at 5V). In full operation the SCD consumes up to 40 mA, while in sleep mode it consumes less than 20 mA. Considering an average consumption of about 30 mA, and based on several measurements of the battery voltage during operation, I approximated the discharge of two CR2430 batteries under continuous use of the SCD as shown in figure 6.1(b) (the green area represents the time during which the two batteries provide enough voltage for correct operation of the SCD).
3. Functionality tests
After checking (and fixing problems as necessary) the basic functionality and performance of the SCD, I went on to verify the applications described.
After checking (and fixing problems as necessary) the basic functionality and performance of the SCD, I went on to verify the applications described.
The first series of tests have been done on CAP readers, as they perform a transaction with all the necessary steps for testing my applications, including PIN verification (VERIFY command) and amount authorization request (GENERATE AC command).
Tabel 2. Log of CAP transaction
The SCD successfully executes all applications (Forward Commands, Modify PIN, Filter Amount, and No PIN) on the Vasco and Natwest CAP readers (see Tabel 2). Using the log functionality with the Forward Commands application I captured the information of a CAP-Identify transaction, where the user enters the PIN and gets a secure code for online authentication. This transaction is shown in table 6.2, where non-essential information that could be used for identification has been marked with X or omitted. The
transaction flow is the same for the Modify PIN and No PIN applications, while for Filter Amount the transaction might end after the VERIFY command if the user does not accept to continue.
transaction flow is the same for the Modify PIN and No PIN applications, while for Filter Amount the transaction might end after the VERIFY command if the user does not accept to continue.
Based on the log from the CAP transaction, I observed two important differences from the standard EMV specification. Firstly, the CAP application does not use the traditional SELECT 1PAY.SYS.DDF01 command to start the transaction, but the selection by Application Identifier (AID). As can be seen from the log, the CAP reader issues multiple SELECT commands (with different AIDs) before finding the correct CAP application on the card (AID = A0000000048002 in this case). This suggests that the CAP reader has
several applications installed, possibly for different cards. Secondly, after using the AID selection, the CAP reader does not issue a final SELECT command before continuing with the transaction, as it is specified in the EMV standard.
The final test consisted in verifying the correct operation of the SCD with a real terminal,
completing an online transaction. For this purposes I have asked permission to use the
completing an online transaction. For this purposes I have asked permission to use the
Image 5. Forward Commands application tested on Natwest CAP reader. The SCD
has blocked the transaction after the PIN has been entered and is waiting for the user to
select if the transaction should continue (yes) or not (no)
SCD at the cafeteria in our department. After a few failed attempts, the SCD has successfully executed the Filter Amount and No PIN applications. The unsuccessful attempts were caused by an incorrect implementation of TLV object decoding. Using the logs from the failed attempts I was able to replicate the live transaction on the terminal emulator and thus find and correct the issue.
I was expecting the Filter Amount application to work correctly since I tested the functionality on CAP readers and terminal emulator. However I was surprised to see that the No PIN application succeeded, which shows the vulnerability has not been fixed yet. Recently, a journalist from TAC Presse (France) has come to our department to make a reportage about the vulnerabilities of Chip and PIN cards.
First Steven Murdoch has helped us in setting up the relay attack, where a fake terminal shows a transaction for £5.00 but actually requests a payment authorization for £123.45. Using the SCD between a real card and the fake terminal we were able to see the correct amount (£123.45) on the display and cancel the transaction (see Image 6).
Image 6. SCD operating as trusted display in a relay attack scenario: demonstration
system (a), close up on fake terminal and SCD displays (b). Images offered by Steven
Murdoch
system (a), close up on fake terminal and SCD displays (b). Images offered by Steven
Murdoch
Then we have used the SCD to perform the No PIN attack at the local cafeteria and even in some random shops in Cambridge. We have successfully bought books and DVDs worth over £50 at one of the shops using the journalist’s card but typing PIN 0000. Even more, we have performed the tests without warning and nobody has noticed the hidden device or fake card (the card interface connected to the SCD). After the transaction we have disclosed the attack to the shop manager who said that such attacks occur very often.
The manager mentioned that during busy periods like Christmas credit card frauds occur at least once a week. Because shops cannot longer check the cards (as the current policy is to let the customer handle the card insertion and removal) the criminals can use fake cards and devices similar to the SCD to perform fraud.
The manager mentioned that during busy periods like Christmas credit card frauds occur at least once a week. Because shops cannot longer check the cards (as the current policy is to let the customer handle the card insertion and removal) the criminals can use fake cards and devices similar to the SCD to perform fraud.
1 comments:
I need much more information on this. There was a forum dedicated to it but has since been removed - http://www.smartcarddetective.com/forum/ all the instruction needed are included by it's creator. Please post as much you can find. I recently bought one online but it came unprogrammed.
Post a Comment