WinSCard Tools: a software for the development and security ... - Hal

6 downloads 5686 Views 1MB Size Report
May 22, 2014 - are Apple, Axalto, Gemplus, Hewlett-Packard, IBM, Infineon, Ingenico, ... All developer informations are published ... to register against it.
WinSCard Tools: a software for the development and security analysis of transactions with smartcards Sylvain Vernois, Vincent Alimi

To cite this version: Sylvain Vernois, Vincent Alimi. WinSCard Tools: a software for the development and security analysis of transactions with smartcards. The third Norsk Information security conference (NISK), 2010, Gjovik, Norway. pp.69–80, 2010.

HAL Id: hal-00995054 https://hal.archives-ouvertes.fr/hal-00995054 Submitted on 22 May 2014

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.

Norwegian Information Security Conference Norsk Informasjonssikkerhetskonferanse

NISK 2010 Gjøvik University College, Gjøvik 23-24 November 2010

Program Chair Patrick Bours

HiG

Program Committee Kristian Gjøsteen NTNU Tor Helleseth UiB Erik Hjelmås HiG Audun Jøsang UNIK Martin Gilje Jaatun SINTEF IKT Stig F. Mjølnes NTNU Leif Nilsen UNIK Vladimir Oleshchuk UiA Anders Paulshus Conax Ragnar Soleng UiT Nils Kalstad Svendsen HiG Svein Willassen Svein Willassen AS Eli Winjum FFI Andre Årnes HiG

© NISK-stiftelsen og Tapir Akademisk Forlag, 2010 ISBN 978-82-519-2705-5

Det må ikke kopieres fra denne boka ut over det som er tillatt etter bestemmelser i «Lov om opphavsrett til åndsverk», og avtaler om kopiering inngått med Kopinor.

Redaktør: Patrick Bours, Norwegian Information Security Laboratory (NISlab), Gjøvik University College

Tapir Akademisk Forlag har som målsetting å bidra til å utvikle gode læremidler og alle typer faglitteratur. Vi representerer et bredt fagspekter, og vi gir ut ca. 100 nye titler i året. Vi samarbeider med forfattere og fagmiljøer i hele landet, og våre viktigste produktområder er: Læremidler for høyere utdanning Fagbøker for profesjonsmarkedet Vitenskapelig publisering

Forlagsredaktør for denne utgivelsen: [email protected] Tapir Akademisk Forlag 7005 TRONDHEIM Tlf.: 73 59 32 10 Faks: 73 59 32 04 E-post: [email protected] www.tapirforlag.no

Preface Welcome to NISK 2010, the third edition of the Norwegian Information Security Conference. After the initial NISK conference in Agder and its follow up in Trondheim, it will now take place in Gjøvik on the 23rd and 24th of November. As before the conference will take place in combination with NIK and NOKOBIT. NISK2010 is sponsored by NISnet, the resource network of Norwegian Information Security researchers funded by the Norwegian Research Council. This year we had 27 high quality submissions from 8 different institutes. Of those one was withdrawn and one came in too late. The remaining 25 were reviewed by 2 members of the Program Committee each and from their feedback 14 papers were selected for presentation. This means that the acceptance rate of 56% is very close the the 58% from last year. All 14 papers will get a 30 minutes timeslot for presenting the ideas. Out of the 14 papers, 8 are authored or co-authored by PhD students and 1 is co-authored by master students. We are glad to announce that Dr. Mike Bond from the Computer Laboratory at the University of Cambridge accepted the invitation as a keynote speaker. The title of his presentation is Chip and Empiricism: Breaking EMV, with proof. In May 2010 Mike Bond presented the controversial paper Chip and PIN is broken, which he co-authored with Steven J. Murdoch, Saar Drimer, and Ross Anderson, at USENIX Security. The paper described how an EMV card can be used to make purchases at Point-of-Sale without knowing the correct PIN. During the subsequent publicity, demonstrations of the technique deployed against the live banking system aired on various European television channels. I would like to thank all the members of the Program Committee for their valuable input in the reviewing process. Furthermore I would like to thank the organizers of NIK, Erik Hjelmås and of NOKOBIT, Tom Røise for the pleasant cooperation and last but certainly not least I would like to thank Kari Lauritzen for all the help with the practical organization of the three conferences.

Table of Content NISK 2010 Keynote Chip and Empiricism: Breaking EMV, with proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Mike Bond

Session 1: Crypto Coercion-Resistant Receipts in Electronic Elections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Håvard Raddum Algebraic Attack on the Second class of Modified Alternating k-Generators . . . . . . . . . 12 Mehdi M. Hassanzadeh, Tor Helleseth Formal Verification of Reductions in Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Kristian Gjøsteen, George Petrides, Asgeir Steine

Session 2: Biometrics Accelerometer-Based Gait Analysis, A survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Mohammad Omar Derawi Sift Based Recognition of Finger Knuckle Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Baptiste Hemery, Romain Giot, Christophe Rosenberger Evaluation of Biometric Systems: An SVM-Based Quality Index . . . . . . . . . . . . . . . . . . 57 Mohamad El-Abed, Romain Giot, Christophe Charrier, Christophe Rosenberger

Session 3: Harware / Security WinSCard Tools: a software for the development and security analysis of transactions with smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Sylvain Vernois, Vincent Alimi Robustness of TRNG against Attacks that Employ Superimposing Signal on FPGA Supply Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Knut Wold, Slobodan Petrovi´c Security and trust for mobile phones based on virtualization . . . . . . . . . . . . . . . . . . . . . . . 93 Chrystel Gaber, Jean-Claude Paillès Non-Invasive Reverse Engineering of the Relative Position of Bus Wires . . . . . . . . . . 104 Geir Olav Dyrkolbotn

Session 4: Information Security Management A Dynamic Approach to Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Jose J. Gonzalez, Finn Olav Sveen Enhancing Credibility of a Dynamic Model Involving Hidden Behavior . . . . . . . . . . . 122 Jaziar Radianti, Jose J. Gonzalez

Session 5: Biometrics / Forensics Secure and Privacy Preserving Management of Biometric Templates . . . . . . . . . . . . . . 134 Vincent Alimi, Rima Belguechi, Christophe Rosenberger Storage and Exchange Formats for Digital Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Anders O. Flaglien, Aleksander Mallasvik, Magnus Mustorp, André Årnes

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

WinSCard Tools: a software for the development and security analysis of transactions with smartcards Sylvain Vernois, Vincent Alimi GREYC Laboratory ENSICAEN - University of CAEN - CNRS Caen, France

Abstract A smartcard is often considered as one of the most powerful and secure element for payment systems. The development and security analysis of transactions using a smartcard is a complex task as many standards are involved. In this paper we present an open and object-oriented Application Programmer Interface for smart card exploration purpose. We illustrate how to easily build a tools suite that allows to simulate EMV payment transactions and reproduce some attacks on smartcards.

1

Introduction

When developing an application using smartcards, whatever the purpose, first thing needed is an application programming interface (API) to access the smartcard reader and then the chip itself. When looking for existing resources on developments for smartcard purpose, we found many interesting ones. Number of them involve the development of softwares embedded in the chip, most using JavaCard1 [5]. Subjects cover from the modeling of an embedded application to the compliance issues with the specifications [11]. Security issues of smartcards is another well studied domain. But our needs were neither to develop an embedded application in the chip, nor to validate the software, but to have some helpers to access the smartcard resources from a computer in order to develop some applications to study multiple aspects of a smartcard application. For this need, we could use proprietary API, provided by the card reader manufacturers, with a major default of not being directly usable if the card reader is changed. A public and recognized API could be used instead such as PC/SC [9].

The PC/SC specification This specification has been written in order to facilitate the use of integrated circuit card technology in a Personal Computer environment. The main contributors are Apple, Axalto, Gemplus, Hewlett-Packard, IBM, Infineon, Ingenico, Microsoft, This paper was presented at the NISK-2010 conference. 1 JavaCard defines a standard smartcard computing environment using a java virtual machine embedded in the chip, allowing an applet to be run on different smartcards

69

Philips, Siemens, Sun Microsystems, Toshiba and VeriFone, gathered in the PC/SC Workgroup [10].

PC/SC implementations On Windows operating systems The first implementation of PC/SC specification has been realized by Microsoft for Windows operating system. Released as a third party tool for Windows NT/9x system, it has been implemented in all versions since Windows 2000. The implementation takes place as a dynamic linked library, named winscard.dll, defining a set of elementary functions. All developer informations are published on MSDN web site [6]. On unix/linux like operating systems MUSCLE [8], standing for Movement for the Use of Smart Cards in a Linux Environment, has 2 main goals: • Provide a middleware to access a smartcard using PC/SC API (project ’pcsclite’) • Provide a framework for cross platform and card independent smartcard solutions (project ’musclecard’) The ’pcsclite’ project finally provides an API very similar to the Microsoft one.

The need for a simple API The existing implementations allow the use of a large number of smartcard readers from the majority of manufacturers, provided that a conform driver is made available. These C-based APIs are welcome, but not sufficient for use with objectoriented “modern language“, because of the lack of object representation. The bases for a new API Because C# language is modern, robust, and portable on several systems (.net platform for windows operating systems, and mono project for linux systems), it is used in several projects in our research. It has been chosen to be used to develop the object oriented API. Some objectives at the beginning are used as a guideline: 1. Publish a very basic but convenient object-oriented API 2. Publish an enhanced API to allow more control over the communication between the smartcard and the application 3. Allow independence between the final application and the smartcard. An API respecting these constraints has been developed since 2006. It now comes with a graphic user interface that is a valuable helper for future developments and tests. In the following sections, we first introduce the architecture of the WinSCard Tools API and software developed. Then we present some complementary

70

tools implemented thanks to the API and applying more specifically to payment smartcards. We finally demonstrate how these tools can be used in the smartcard research domain by allowing to replay a known attack on an EMV transaction.

2

Open architecture

The software developed is divided into two parts, each meeting different purposes. The first part is a simple, object oriented, application programming interface on top of the native windows PC/SC dynamic library winscard.dll. The second part is a core graphic user interface, aiming at easing the use of smartcard reader and developing test applications as plug-ins.

The smartcard API The three aforementionned objectives lead naturally to the implementation of three respective modules. Figure 1 outlines the interactions between these modules, based on top of the C# virtual machine and the native PC/SC implementation. The Wrapper module allows the .net framework to access the native functions thanks to platform invocation methods. It resolves all communication issues that can happen between the C-style library and the final C# language. It is composed of two classes: Primitives is a static class realizing the concrete wrapping of native library and ErrorCode is an enumeration of the PC/SC return codes. The Core module is more interesting, because it publishes several interfaces and classes that can be used in a flexible way, as briefly shown in figure 2. A CardContext object allows claim and release of the PC/SC resources of the computer, and should be used only once in an application. Once acquired, smartcard readers installed on the system are available to be used by a CardChannel object, that will allow direct communication between the application and the card reader or the smartcard. Interfaces are extracted from these classes because, as it will be shown later, several implementations can co exist and extend the original one.  

   

 



 

Fig. 1: General architecture of the API The objective of having an enhanced control over the communication is realized thanks to the well-known ”observer” design pattern [2], describing how an object called an ’observable’ can publish internal informations to any object that is able to register against it. This pattern is the source of the flexibility of our API, and is largely used. Furthermore, the C# language offers a very simple way of implementing this pattern by the use of the keyword delegate. Explicit declaration of an interface for each information to be published being avoided, code written to use the pattern is kept short and clear.

71



 



 

 





   

      



 



Fig. 2: Partial class diagram of Core module Protocol stack In 2004, a first java implementation of the FDIS ISO/IEC 24727-2 [4] was developed at ENSICAEN, known as Cardstack. The new developed API has benefited from this experience and gained a stack complying with the standard. That way, the third initial objective has been completed. Concretely, what has been realized is a set of new classes (as shown in Figure 3) allowing to add abstraction levels between the application and the smartcard. Even if a smartcard is conform to ISO/IEC 7816 [3], describing the requirements for integrated circuit cards, not all the parts are supported. That’s why an application is rarely able to support all kinds of smartcards, but only a small set, or need to be adapted when the smartcard change. The abstraction added by the stack implemented helps reduce these interoperability difficulties, by allowing the application to be independent from the smartcard finally used: an intermediate adapter layer can be introduced between the application and the smartcard to adapt commands sent to the card and responses that are received. Because CardChannel and CardChannelStack implement the same interface, one can be used in replacement of the other without any difficulties, adding a stack very easily to an application without any modification but the instantiation of the class. Each layer of the stack must implement ICardChannelLayer so that it can be inserted into the stack. A specific layer CardChannelLayer extends the basic CardChannel to allow its insertion into a stack.

A graphic user interface A companion tool has been realized simultaneously to the protocol stack, serving as a proof of concept. It has evolved into a graphic user interface (GUI) exploiting all the abilities of the API and allowing extensibility thanks to a plugin system, as illustrated by figure 5. Main GUI The main GUI (see figure 4) is responsible of the resources management: access to underlying PC/SC driver, channel established between the user and the smartcard

72

                   

 

 



  

   

 

 

 

 

Fig. 3: Partial class diagram of Stack module   

       

      

   



       

  

          

  

Fig. 4: WinSCard GUI main window

73



   



    

Fig. 5: Architecture of the graphic user interface itself. Plugin system A plugin system is used to allow extensibility of the main GUI, in order to easily implement small and independent applications (plugin) conform to the concrete needs. All plugins and the main GUI share a single context and channel offered by the API. By actively using the event mechanisms, several plugins can access communication data between the “application“ and the smartcard in a transparent way, allowing live analyze or modification of the data exchanged. Record and replay of APDU exchange While using the GUI for educational and research projects, we faced a repetitive need: replay a set of card responses to allow multiple analyzes. The same set of commands can be sent several times to the same card, but in the case we had it was not sufficient as it implied random numbers generated by the card or transaction counters incremented by the card. The exact same scenario can not be reproduced. That is why a new layer, shown as “Interactive Layer” on figure 5 has been added. By using the stack mechanisms, this layer is introduced between the application and the smartcard and offers three modes (see figure 6): • The record mode allows all data sent or received to be logged and saved. • The replay mode allows to replay responses previously logged. In this mode, the smartcard is not accessed any more, and the Interactive Layer sends back the recorded responses directly to the application, that does not know of the faked card. • The transparent mode allows the layer to act as a pass through, without any action on the communication. In this section, we presented the API and the graphic tools created to simplify the access to smartcard resources. The open architecture, based on some simple design patterns, allows not only the communication between an application (or a plugin) and the card, but also provides comfortable means to analyze and modify the data.

74

  

 

 

  

  

 

 

     

       

       

Fig. 6: Illustration of Interactive Layer modes

3

Applications to the analysis of smartcard transactions

The 7816 plugin: a first concrete implementation The initial need for WinSCard Tools came from our main research domain based on electronic payments, where smartcards are often used. The use of ISO/IEC 7816 [3] normalized APDU2 led us to add a specific plugin dedicated to these cards. Among the functionalities, the most important one is the ability to observe the communication and to decode all command/response pairs as standard APDU. The APDU is then stored, and the historic is kept for future references. Once a complete transaction is done, all data can be saved on disk, or unitary replayed at will, as the plugin is also able to send recorded or new commands from its own graphic user interface (figure 7).



  

           

         !"#$% & '

Fig. 7: Plugin ISO 7816 GUI This plugin is of a great help when trying to look at the raw details of a transaction. 2 Application Protocol Data Unit: represents the command and response exchanged at the interface

75

EMV Library for research purposes EMV 3 [1] is a frequently used specification for payment transactions using smartcards, as it is the specification imposed by the main worldwide payment networks Mastercard, Visa and JCB. This is why we have implemented an EMV library, based on the developed API, with a dedicated plugin to manage the transaction. This library has been realized with the same objectives as the API, particularly it exposes several events to monitor the internals. The associated plugin enables to pilot the EMV transaction, step by step, and to analyze precisely all APDU complying with the EMV specifications, e.g. the control of cryptograms generated by the card. Also, some adaptations have been tweaked to allow some EMV-based contactless cards to be used instead of contact smartcards. An example of use for research purposes of the EMV library is detailed in the next section.

4

Replay of the ”Cambridge” attack

Presentation The so-called ”Cambridge” attack has been realized in the Computer Laboratory of the University of Cambridge and exposed in [7]. In this article, Murdoch et al. demonstrate the feasibilty of an attack on an EMV smartcard. It is a man-in-themiddle attack on the PIN (Personal Identification Number) code verification. It consists in intercepting the VERIFY command sent by the POS 4 to the smart card to verify the PIN code entered by the cardholder. It relies on the fact that an EMV smart card can support other Cardholder Verification Methods (CVM) than ”offline”PIN code – i.e. PIN code verified by the smart card –, such as cardholder signature verification and online PIN code verification by the issuing bank. So, if one succeeds in intercepting the command and send a positive response to the POS on behalf of the card, both the POS and the card will ”think” the cardholder verification was successful and the transaction will keep processing normally. Murdoch et al. implemented this attack in hardware. It is made of a fake smart card wired to a FPGA board. The FPGA board is connected to a laptop, which is connected through a smart card reader to a stolen EMV smart card (c.f. Figure 8).

Fig. 8: Hardware material used to execute the attack (source: [7] courtesy of Murdoch et al.) A python script running on the laptop relays all commands sent by the POS to the card. It waits for a VERIFY command and, instead of relaying it to the card, sends the 0x9000 status word to the card. At this point, the POS considers the PIN code has been successfully verified by the card and carries the payment transaction on. 3 4

Europay MasterCard Visa Point Of Sales

76

Software implementation of the attack For research and educational purposes, we have reproduced this attack in software thanks to WinSCard Tools. Indeed, WinSCard Tools’ architecture allows to define a ”man-in-the-middle” (MITM) layer to implement this attack. Experimental setup The MITM layer is added to the communication stack and relay all commands sent by WinSCard Tools to the card, except the VERIFY one (cf. Figure 9). Instead, it sends 0x9000 back to WinSCard Tools. Then, the transaction carries on normally and one can observe that the card validates the transaction.       

  



 



        

  

Fig. 9: Software implementation of the PIN attack Thanks to WinSCard Tools, one can also observe the Point of Sales (POS) side of the transaction. Indeed, in an EMV transaction, it is possible to spy the link between the card and the POS but it is not possible to know the way the POS processes the data, e.g. how the POS checks the smartcard certificates validity and the data it gets from them. As WinSCard Tools totally emulates a POS, those processings are totally accessible to the user. A dedicated user interface shows the user the different certificates, the result of the signature verification process and the data contained into the certificates. Another WinSCard Tools’ feature is particularly useful for attacks replaying: the interactive layer. This layer allows to record and replay transactions. It records the data sent by the card at the reception of commands and can replay them on behalf of the card in replay mode. In the implementation of this kind of attack, this feature is interesting because it allows to keep, for example, the Application Transaction Counter of an EMV smartcard unchanged. Indeed, for each transaction initiated, a counter is incremented. This counter is used, among many elements, by the card to decide whether or not go online to authorize the transaction. It is then interesting to keep unchanged the data of a genuine EMV smartcard when performing a certain amount of tests and attacks. Operations performed Once the experimental environment is set, an EMV smart card is inserted and the ”EMV Explorer” user interface is launched. EMV Explorer (cf. Figure 10) simulates a POS and allows to process a transaction step by step. It displays all the APDU commands exchanged between the card and the terminal and interpretes them thanks to the EMV library.

77

Fig. 10: The EMV Explorer plugin At the cardholder verification step, any PIN code is entered and we can observe that the POS receives the 0x9000 status word (normal processing) and processes the next command (GENERATE AC). Results and discussion The attack has been succesfully performed on all EMV smart cards in our possession (real and test cards). None of them has been able to detect the attack because they allow other CVMs than PIN code verification. This is also due to the fact that Issuers did not implement any countermeasures in the versions of applications we have on our smartcards. But, since a few years one can observe such implementaions in new the application specifications – from Visa and MasterCard for example. It often consists in passing the CVM Results data element to the card when sending the GENERATE AC command. To protect the transmission of the CVM Result from another man-in-the-middle attack we recommend to use CDA (Combined DDA/Application Cryptogram Generation) to dynamically sign the data sent to the card. We have seen in this section how we have been able to reproduce the ”Cambridge” attack in a software way. Of course, it can not been implemented in real-life with real POS as the people from Cambridge did but we have demonstrated that WinSCard Tools is a perfectly adapted tool for a research work on smartcards in general and on EMV in particular.

78

5

Conclusion and future works

We presented in this paper the benefits of developing an open and object-oriented Application Programmer Interface for research on smartcards. Indeed, by wrapping the operating system PC/SC layer and the ISO 7816 smartcards protocol, it is very easy to develop a tool responding exactly to the needed functionalities. As an illustration, it has been very easy for us to use the API to develop an EMV framework and a tool implementing a man-in-the-midle attack on PIN code verification by EMV smartcards. We plan to use the API to implement in WinSCard Tools all known attacks on EMV smartcards, propose and implement counter-measures on the card side. We will also investigate the security of emerging technologies such as contactless and mobile payment.

Acknowledgment The authors would like to thank Ren´e Lozach, important contributor to the ISO 7816 & 24727 standards, for his valuable comments and Steven J. Murdoch et al. for accepting to reproduce in this paper the figure 8.

References [1] EMVCo. EMV integrated circuit card specifications for payment systems. Technical report, EMVCo, 2008. [2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Addison-Wesley, Boston, MA, January 1995. [3] International Organization for Standardization, http://www.iso.org. ISO/IEC 7816-1 to 15: Identification cards - Integrated circuit(s) cards with contacts (Parts 1 to 15). [4] ISO/IEC, http://www.iso.org. 24727: Identification cards - Integrated circuit card programming interfaces. [5] Eduard De Jong, Pieter Hartel, Patrice Peyret, and Peter Cattaneo. Java card: An analysis of the most successful smart card operating system, 2005. [6] Winscard Module. http://msdn.microsoft.com/en-us/library/ms924513.aspx. [7] Steven Murdoch, Saar Drimer, Ross Anderson, and Mike Bond. Chip and PIN is broken. In David Evans and Giovanni Vigna, editors, SSP 2010, 31st IEEE Symposium on Security & Privacy, Piscataway, NJ, USA, May 2010. IEEE Computer Society Technical Committee on Security and Privacy/The International Association for Cryptologic Research, IEEE Computer Society. [8] MUSCLE Cross-Platform http://www.musclecard.com/.

Smart

Card

[9] PC/SC Workgroup, http://www.pcscworkgroup.com/. Specifications 2, 2005.

79

Development.

PC/SC Workgroup

[10] PC/SC Workgroup. http://www.pcscworkgroup.com/. [11] Denis Sabatier and Pierre Lartigue. The Use of the B Formal Method for the Design and the Validation of the Transaction Mechanism for Smart Card Applications. In Jeannette M. Wing, Jim Woodcock, and Jim Davies, editors, World Congress on Formal Methods, volume 1708 of Lecture Notes in Computer Science, pages 348–368. Springer, 1999.

80