Article

EMV Protocol Fuzzer

The world-wide introduction of the Europay, MasterCard and Visa standard (EMV), to facilitate communication between smartcards and EMV-enabled devices, such as point-of-sale (POS) terminals and automatic teller machines (ATMs), has altered the security landscape of the daily markets.

Surprisingly limited public research exists addressing security aspects of hardware and software specific implementations. This is something we wanted to put right and therefore started a new research programme to specifically look at this area.

Previous research has already uncovered security issues in this technology, asking serious questions of the processes used to develop and test modern EMV-enabled devices. Based on discussions with those involved in these areas MWR identified a need to further develop structured and formal security evaluation approaches in order to provide the highest levels of assurance to all interested parties.

As a result of this research we are pleased to present an EMV protocol fuzzer that can be used as a tool to evaluate the security integrity of a device under test (DUT). This solution includes a Python interface to facilitate control of the EMV fuzzer, in effect allowing on-the-fly monitoring and emulation of an EMV stream with the DUT. Various predefined security tests were also developed to formalise the security evaluation procedure. Our design is ready to be interfaced with a fuzzing algorithm and thus presents the first step towards a fully automated EMV fuzzing solution.

In order to test our solution, the proof of concept implementation of our EMV fuzzer was used against some real-world POS devices. This resulted in the identification of security issues and was part of the validation of our approach to the initial problem we were looking to solve. The security issues identified are currently being addressed by those affected and more details will be provided when it is appropriate to do so.

We are now providing details of our approach, information about our proof of concept implementation and limited technical details of our findings.

Introduction

The EMV standard, also known as Chip and PIN, is used primarily by banks across the globe as the industry de-facto standard for authenticating smartcard transactions. The most widely used chip card implementations of the EMV standard are Visa, MasterCard, American Express, JCB and Discover/Diners Club International [1], [2]. Since EMV is based on the ISO 7816 standard, which secures inter-operation between smartcards and associated terminals, this research also applies to other implementations where smartcards are present such as in subscriber identity modules (SIMs) and DTV decoders.

Although the standard defining EMV is in principal secure, vulnerabilities can easily be introduced into the terminal-smartcard authentication procedure by the hardware and software specific implementation of the actual EMV-enabled device. Recent work by [3] indicated the ease, at that time, with which vulnerabilities could be found in existing POS devices by using a programmable smartcard, without the need for sophisticated card-emulating or man-in-the-middle attack hardware. In the aforementioned case a vulnerability was discovered, by modifying the smartcard response data, before the PIN verification stage, until an error exception occurred in the POS device. The fact that an error could be introduced after only a few attempts, by hand, illustrated a potential gap in the assurance processes that were in use at the time. As a result it was easy to theorise that additional vulnerabilities might exist in current POS devices used world-wide. Exploitation of the security issue found in [3], which leads to system level execution of malicious code, was completed to highlight the impact and implications of the issue. Full details of this have never been released, except to those responsible for resolving the issues.

In order to ensure the security integrity of an EMV-enabled terminal, it is necessary to test it against a multitude of response vectors, which have potentially not been accounted for in the design stages. This case lends itself particularly well to an automated electronic solution, such as an EMV fuzzing device, which would be able to test a target terminal for potential vulnerabilities in a fast, controlled and reproducible manner. Furthermore, interest has been expressed in the recent peer-reviewed literature [4] to automate the process of fuzzing POS devices in real time. This is an attractive solution to the security testing of such devices before they are deployed in-field.

In this work an automatic EMV Fuzzing device is presented. It is based on the research presented in [1], whereby a USB interface with a PC allows the communication between the smartcard and POS terminal to be monitored and modified in real-time. The EMV fuzzer is controlled by means of Python scripts allowing the simple automation of various pre-defined security tests, in effect formalising the security evaluation procedure. The proposed design automates insertion and retraction of the emulated smart card by means of a linear actuator and is ready to be interfaced with an automated fuzzing algorithm. This work presents the first step towards a fully automated EMV fuzzing solution.

Implementation

The functional block diagram of the proposed design is shown below.

functional diagram

Functional unit one (FU1) represents the EMV fuzzing hardware and firmware. FU1 is comprised of a central microcontroller (FU1.1), a USB control interface (FU1.2) that communicates with the controlling python scripts (FU2), the ICC interface (FU1.3) that connects to a smartcard, an emulated ICC interface (FU1.4) that is connected to the DUT as well as a robotic arm (FU1.5) that automates the insertion and retraction of FU1.4 from the DUT. FU1.5 also includes a DUT reset switch in the form of a relay which can be used to reset the DUT during the fuzzing operation. The complete design with the various functional units indicated above is shown later.

The interfacing python scripts are controlled by FU3. FU3.1 implements predefined functions that are useful in the security evaluation of devices using an EMV protocol interface. FU3.2 illustrates how a fuzzing algorithm can interface with the system described above, using both the interfacing python functions as well as the developed security tests.

Hardware design

The hardware portion of the design is concerned with FU1. First FU1.1 – FU1.3 is implemented in soft-substrate on a PCB as shown below. Next the design of FU1.4 is implemented in PCB form. Finally FU1.5 is realised on a separate PCB which interfaces with FU1.1 – FU1.3.

emv fuzzer front2

emv fuzzer back

The aforementioned sub-systems are interconnected to form FU1 as shown next.

complete sys

Software design

The software implementation can be subdivided into the firmware written for FU1.1 and the Python software written for FU2. The firmware for FU1.1 is based on [1] with the source code available at [5]. Various modifications and additions have been made to the existing firmware – with some details contained in the appended technical report.

Notably, real-time modification of the EMV stream is supported, as required for the seamless interface with the automatic fuzzing algorithm. A method of abstracting the interfacing Python functions away from low-level timing management is devised. This allows the user to focus on the data stream exchange, rather than being constantly forced to debug timing issues. Furthermore, a new method of fostering the control bytes is implemented allowing the user more control over the EMV communication flow, which is otherwise almost entirely dependent on the DUT. Details are available in the appended report.

Preliminary results

As mentioned earlier, only some results will be presented here. After the correct vulnerability disclosure procedure has been followed with affected parties, the remaining results will be published.

The communication stream between a Point-of-sale (POS) terminal and a VISA smart card (ICC) is captured. Data sent from the POS device is introduced by the symbol (-->) whereas data sent from the smart card is preceded by the symbol (:). A command header is shown using the notation: [CLA INS P1 P2 P3].

--> [CLA INS P1 P2 P3] = [00 a4 04 00 0e] (Select 1PAY.SYS.DDF01)
--> POS DATA: 31 50 41 59 2e 53 59 53 2e 44 44 46 30 31
: 61 2f
--> [CLA INS P1 P2 P3] = [00 c0 00 00 2f] (Request data)
: 6f 2d 84 0e 31 50 41 59 2e 53 59 53 2e 44 44 46 30 31 a5 1b 88 01 01 5f 2d 02
65 6e 9f 11 01 01 bf 0c 0c c5 0a ff ff 3f 00 00 00 03 ff ff 03

--> [CLA INS P1 P2 P3] = [00 b2 01 0c 00] (Read record)
: 6c 35
--> [CLA INS P1 P2 P3] = [00 b2 01 0c 35]
: 70 33 61 31 4f 07 a0 00 00 00 03 10 10 50 10 56 69 73 61 20 43 61 72 64 20 20
20 20 20 20 20 9f 12 10 56 69 73 61 20 43 61 72 64 20 20 20 20 20 20 20 87 01 01

--> [CLA INS P1 P2 P3] = [00 b2 02 0c 00] (Read record)
: 6c 1b
--> [CLA INS P1 P2 P3] = [00 b2 02 0c 1b]
: 70 19 61 17 4f 07 a0 00 00 00 03 80 02 50 09 56 49 53 41 20 41 75 74 68 87 01
0f

--> [CLA INS P1 P2 P3] = [00 b2 03 0c 00] (Read record)
: 6a 83

--> [CLA INS P1 P2 P3] = [00 a4 04 00 07] (Select VISA Debit/Credit (Classic))
--> POS DATA: a0 00 00 00 03 10 10
: 61 87
--> [CLA INS P1 P2 P3] = [00 c0 00 00 87] (Request data)
: 6f 81 84 84 07 a0 00 00 00 03 10 10 a5 79 50 10 56 69 73 61 20 43 61 72 64 20
20 20 20 20 20 20 87 01 01 9f 38 03 9f 1a 02 5f 2d 02 65 6e 9f 11 01 01 9f 12 10
56 69 73 61 20 43 61 72 64 20 20 20 20 20 20 20 bf 0c 3f 5f 54 08 46 49 52 4e 5a
41 4a 4a 42 03 49 01 36 5f 55 02 5a 41 5f 56 03 5a 41 46 5f 50 15 68 74 74 70 3a
2f 2f 77 77 77 2e 66 6e 62 2e 63 6f 2e 7a 61 2f c5 0a 01 01 7f 51 47 00 02 0f ff
02

--> [CLA INS P1 P2 P3] = [80 a8 00 00 04] (GET PROCESSING OPTIONS)
--> POS DATA: 83 02 07 10
: 61 0c
--> [CLA INS P1 P2 P3] = [00 c0 00 00 0c] (Request data - AIP/AFL)
: 80 0a 5c 00 18 01 04 01 08 01 01 00
--> [CLA INS P1 P2 P3] = [00 b2 01 1c 00] (Read record) 
: 6c 50
--> [CLA INS P1 P2 P3] = [00 b2 01 1c 50]
: 70 4e 5f 25 03 14 01 08 5f 24 03 16 01 31 5a 08 ** ** ** ** ** ** ** ** 5f 34
01 00 9f 07 02 ff 00 8e 10 00 00 00 00 00 00 00 00 41 03 02 03 1e 03 1f 00 9f 0d
05 f0 68 3c 88 00 9f 0e 05 00 10 c0 00 00 9f 0f 05 f0 68 3c 98 00 5f 28 02 07 10

--> [CLA INS P1 P2 P3] = [00 b2 02 1c 00] (Read record)
: 6c f4
--> [CLA INS P1 P2 P3] = [00 b2 02 1c f4] (Read record - SDA/DDA)
: 70 81 f1 8c 15 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04
8d 17 8a 02 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 9f 08
02 00 8c 5f 20 1a 4e 45 54 53 48 49 2f 4c 2e 4d 52 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 5f 30 02 02 01 93 81 90 57 91 b1 aa c1 60 65 45 10 80 34 80 28 ba
1d 9b 8d 9c 5a 26 67 51 03 6e 78 73 c3 7d d5 3c 49 4d f9 eb 37 7a d9 2b 78 9c 89
99 c3 1c d5 cd 37 e6 67 d8 26 c9 11 ac fd fc de 9e c6 7b 14 56 f3 50 37 1f af 48
77 87 83 46 fa 7e ce c4 f0 55 fc 4d 45 05 fc 80 a5 86 33 6a 66 5a c8 be 8c 7b f3
aa f4 d5 54 b2 5b 11 7b 3a 1f bd 11 e3 0c 14 a6 76 86 df 94 4a d0 a9 9e 76 83 8c
34 ea 10 fd d9 dc d1 27 7c bd 96 fe af 99 33 8a 50 3b 47 57 cc e7 9f 4a 01 82 8f
01 95

--> [CLA INS P1 P2 P3] = [00 b2 03 1c 00] (Read record)
: 6c 96
--> [CLA INS P1 P2 P3] = [00 b2 03 1c 96] (Read record)
: 70 81 93 90 81 90 5e 93 bd 2e d9 af 2f 65 cc 71 85 34 4b 00 4f 2c a9 9e 31 e1
af 43 65 d3 62 69 57 04 45 c3 c8 b0 b8 2f 99 93 61 3e ff 83 eb 3b 62 67 4f 54 dd
ea dd c1 d4 82 2c 72 60 33 ff dd 11 3d e3 56 eb 47 0e 5a 34 75 02 72 a1 18 82 65
56 30 97 50 ce 85 21 48 7d 75 d8 c2 c9 f6 f8 03 bb b0 03 a5 e5 ea b6 4a b3 0c 2d
e5 69 bd fd 37 f7 24 1a 03 6a 01 96 38 f5 fa 1d ce df af d3 83 62 d2 44 aa 44 44
2a 1b eb b3 80 60 21 1d 23 a3 36 b1 73 09 e3 5d

--> [CLA INS P1 P2 P3] = [00 b2 04 1c 00] (Read record)
: 6c 30
--> [CLA INS P1 P2 P3] = [00 b2 04 1c 30] (Read record)
: 70 2e 9f 32 01 03 92 24 ba 97 8a 34 75 dd 97 ce 7d 7b d3 1b 15 eb ed 23 e6 1b
1f eb b7 61 89 98 be 98 5e e4 d1 e1 33 d6 c9 11 00 db 9f 44 01 02

--> [CLA INS P1 P2 P3] = [00 b2 01 0c 00] (Read record)
: 6c 32
--> [CLA INS P1 P2 P3] = [00 b2 01 0c 32] (Read record)
: 70 30 57 13 49 01 36 82 02 22 60 67 d1 60 12 01 00 00 00 02 60 00 0f 9f 1f 18
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 32 36 30 30 30 30 30 30 30

--> [CLA INS P1 P2 P3] = [80 ae 80 00 1d] (Generate AC)
--> POS DATA: 00 00 00 00 00 39 00 00 00 00 00 00 07 10 40 80 04 80 00 07 10 15
01 07 00 07 3e 27 20
: 61 14
--> [CLA INS P1 P2 P3] = [00 c0 00 00 14] (Request data)
: 80 12 80 00 40 e9 16 66 e6 20 e5 d9 cb 06 01 0a 03 a0 a8 00

--> [CLA INS P1 P2 P3] = [00 82 00 00 10] (External authenticate)
--> POS DATA: cc 69 18 5e 4b c7 b0 dd 30 30 00 00 00 00 00 00
: 67 00

--> [CLA INS P1 P2 P3] = [80 ae 40 00 1f] (Generate AC)
--> POS DATA: 30 30 00 00 00 00 00 39 00 00 00 00 00 00 07 10 40 80 04 80 40 07
10 15 01 07 00 07 3e 27 20
: 61 14
--> [CLA INS P1 P2 P3] = [00 c0 00 00 14] (Request data)
: 80 12 40 00 40 d7 a5 50 61 a9 fb 17 95 06 01 0a 03 60 ac 00

YouTube demonstrations

Two video demonstrations are provided here.

The first demo presents sniffing EMV communications between a POS terminal and VISA ICC.

The second demo shows how the data captured in the previous video can be replayed to the POS terminal.

This data can now be modified to test the DUT for various vulnerabilities. Additional videos will be added at a later stage illustrating this possibility.

Conclusion

An EMV protocol fuzzer to test the security integrity of EMV-enabled devices is presented. The EMV communication stream between the DUT and smart-card can be monitored and modified in real-time. Interfacing high-level Python functions have been developed, compatible with a high-level fuzzing algorithm. Furthermore, robotic automation has been included to automatically insert and retract the emulated ICC into/from the DUT – a feature necessary for automatic fuzzing. Future work should focus on developing an EMV fuzzing algorithm as well as developing new methods of reading data from the DUT in order to obtain more information about an induced system crash.

Link to the technical paper

Here is the link to the technical paper for more details.

EMV Fuzzer Summary Paper

References

[1] O. Choudary, “The Smart Card Detective: a hand-held EMV interceptor,” University of Cambridge, Cambridge, England, 2010.

[2] J. P. Degabriele, A. Lehmann, K. G. Paterson, N. P. Smart and M. Strefler, “On the Joint Security of Encryption and Signature in EMV,” Springer Topics in Cryptology, pp. 116-135, 2012.

[3] MWR InfoSecurity, “PINPADPWN,” in Blackhat, City of Las Vegas, USA, 2012.

[4] G. de Koning Gans and J. de Ruiter, “The smartlogic tool: Analysing and testing smart card protocols,” in IEEE Fifth International Conference on Software Testing, Verification and Validation, Montréal, Canada, 2012.

[5] O. Choudary, “Google code: smartcarddetective,” University of California, Berkeley, 2 May 2011. [Online]. Available: https://code.google.com/p/smartcarddetective/. [Accessed 1 September 2014].

[6] EMVCo, “EMV Integrated Circuit Card Specifications for Payment Systems – Book 1,” EMVCo, LLC, 2008.

[7] EMVCo, “EMV Integrated Circuit Card Specifications for Payment Systems – Book 3,” EMVCo, LLC, 2008.