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 sci- entific research documents, whether they are pub- lished 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ée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
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. �hal-00995054�
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:
Lasse.Postmyr@tapirforlag.no
Tapir Akademisk Forlag
7005 TRONDHEIM
Tlf.: 73 59 32 10
Faks: 73 59 32 04
E-post: post@tapirforlag.no
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 23 rd and 24 th 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 Sup- ply 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 JavaCard
1[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 object- oriented “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 APDU
2led 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-the- middle attack on the PIN (Personal Identification Number) code verification. It consists in intercepting the VERIFY command sent by the POS
4to 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
Europay MasterCard Visa
4
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.
