Edinburgh Research Explorer

Getting to know your Card: Reverse-Engineering the Smart-Card

Application Protocol Data Unit
Citation for published version:
Gkaniatsou, A, McNeill, F, Bundy, A, Steel, G, Focardi, R & Bozzato, C 2015, Getting to know your Card:
Reverse-Engineering the Smart-Card Application Protocol Data Unit. in ACSAC 2015 Proceedings of the
31st Annual Computer Security Applications Conference. ACM, New York, pp. 441-450.
https://doi.org/10.1145/2818000.2818020

Digital Object Identifier (DOI):

10.1145/2818000.2818020

Link:
Link to publication record in Edinburgh Research Explorer

Document Version:
Peer reviewed version

Published In:
ACSAC 2015 Proceedings of the 31st Annual Computer Security Applications Conference

General rights
Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s)
and / or other copyright owners and it is a condition of accessing these publications that users recognise and
abide by the legal requirements associated with these rights.

Take down policy

The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer
content complies with UK legislation. If you believe that the public display of this file breaches copyright please
contact [email protected] providing details, and we will remove access to the work immediately and
investigate your claim.

Download date: 27. Jan. 2023

 Getting to know your Card: Reverse-Engineering the
Smart-Card Application Protocol Data Unit

Andriana Gkaniatsou Fiona McNeill Alan Bundy

University of Edinburgh, UK Heriot-Watt University, UK University of Edinburgh, UK
[email protected] [email protected] [email protected]

Graham Steel Riccardo Focardi Claudio Bozzato

Cryptosense, France Ca’ Foscari University, Italy Ca’ Foscari University, Italy
[email protected] [email protected] [email protected]

ABSTRACT These operations involve a deliberately confidential communica-

Smart-cards are considered to be one of the most secure, tamper- tion between smart-cards and third-party systems. Such commu-
resistant, and trusted devices for implementing confidential oper- nication is prone to “man-in-the-middle” attacks thus rendering
ations, such as authentication, key management, encryption and smart-cards vulnerable.
decryption for financial, communication, security and data man- Sniffing the smart-card communication and consequently per-
agement purposes. The commonly used RSA PKCS#11 standard forming man-in-the-middle attacks has attracted a lot of attention
defines the Application Programming Interface for cryptographic and many tools have been proposed (e.g., [7, 15]). Studies have
devices such as smart-cards. Though there has been work on for- exposed that such attacks reveal severe problems. For example,
mally verifying the correctness of the implementation of PKCS#11 by blind-replaying a communication session one may distinguish
in the API level, little attention has been paid to the low-level cryp- different passports [6]. The way an attack is designed varies de-
tographic protocols that implement it. pending on the target e.g., knowledge of the semantics of a com-
We present REPROVE, the first automated system that reverse- munication session may suggest attacks like the previous one, PIN
engineers the low-level communication between a smart-card and or authentication data sniffing, access to sensitive keys, execution
a reader, deduces the card’s functionality and translates PKCS#11 of unauthorized operations or cloning the card. However, for an
cryptographic functions into communication steps. REPROVE an- attack to be universally successful it has to deal with proprietary
alyzes both standard-conforming and proprietary implementations, protocol implementations as well as with inter-industry ones, an
and does not require access to the card. To the best of our knowl- issue that previous studies do not address.
edge, REPROVE is the first system to address proprietary imple- Analyzing, attacking and fixing cryptographic standards used by
mentations and the only system that maps cryptographic functions smart-cards, such as PKCS#11, is an active area. As defined in
to communication steps and on-card operations. We have evalu- PKCS#11 [18], cryptography is only one aspect of security and the
ated REPROVE on five commercially available smart-cards and token is only one component in a system; one must consider the
we show how essential functions to gain access to the card’s pri- environment the token operates in as well. Smart-cards suppos-
vate objects and perform cryptographic functions can be compro- edly offer a tamper-resistant environment for protecting sensitive
mised through reverse-engineering traces of the low-level commu- data, but should also be designed so that this data remains secure.
nication. This is delegated to the communication protocols, under the as-
sumption that these protocols are secure. Proprietary implementa-
tions create the illusion of security as they hide the card’s code. A
Keywords smart-card operates as a black-box: only access to the card’s code
Smart-card reverse-engineering, PKCS#11 low-level attacks, APDU may reveal the semantics of the communication protocol and its in-
formal modeling, APDU attacks. ternal operations. We propose reverse-engineering the smart-card
communication protocol, with respect to PKCS#11, to determine
the security of that implementation. We present REPROVE, which
1. INTRODUCTION stands for Reverse Engineering of PROtocols for VErification: an
Smart-cards are ubiquitous and are universally considered to be automated tool based on first-order logic, that infers the seman-
secure, tamper-resistant, and trustworthy devices. They have been tics of the communication, the on-card operations and their inter-
used to implement confidential operations such as user identifica- connection with the PKCS#11. REPROVE is implementation- and
tion and authentication and sensitive data storage and processing. function-independent, as it deals with both inter-industry and pro-
prietary implementations and does not require access to the card’s
Permission to make digital or hard copies of all or part of this work for personal or code.
classroom use is granted without fee provided that copies are not made or distributed An alternative to REPROVE’s automated reasoning is to man-
for profit or commercial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than
ually reverse-engineer the trace. This is not straightforward and is
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- far from a quick exercise. It requires access to the card’s library and
publish, to post on servers or to redistribute to lists, requires prior specific permission its internal calls, whereas REPROVE does not. If one tries to guess
and/or a fee. Request permissions from [email protected]. the meaning of the trace, without access to the card, then, given the
ACSAC ’15, December 07-11, 2015, Los Angeles, CA, USA combinatorial nature of the problem, one will need to test a con-
c 2015 ACM. ISBN 978-1-4503-3682-6/15/12. . . $15.00 siderably large number of combinations (e.g., in some of the cards
DOI: http://dx.doi.org/10.1145/2818000.2818020
 Input
Function low-level
PKCS#11
call communication
Communication Trace Abstract
APDU
API
layer
Smart-card Models

Figure 1: API and smart-card interaction when a PKCS#11 func- PKCS#11

tion is called.
ISO 7816
REPROVE
Generic
assumptions
we tested there are more than 540 × 868 possible combinations— Output

see also Section 4) which will require a long time to decode. RE- APDU semantics

PROVE does this in a matter of milliseconds. On-card operations

PKCS#11 defines an Application Programming Interface (API) pkcs#11 function

translation
for smart-cards. Any API call (i.e., calling a specific cryptographic
function) initiates a low-level communication that manifests as a Figure 2: High-level overview of our technique.
communication trace of API requests to the smart-card, as shown
in Figure 1. REPROVE reverse-engineers the low-level implemen-
tation of the cryptographic protocol by automatically aligning the and infer the card’s actually executed operations.
byte-wise decomposition of the communication trace to expected To the best of our knowledge, this is the first work for modeling
PKCS#11 calls for specific types of functionality. This process is the APDU layer and formally reverse-engineering it by mapping
helpful in multiple ways: (a) It provides the means to test smart- the low-level communication to the on-card operations and to the
card implementations and discover their security vulnerabilities. PKCS#11 standard. The abstract models of the background knowl-
(b) In the absence of detected vulnerabilities, it provides empiri- edge do not hard-code the implementation. Instead, they offer a
cal evidence for the security of the implementation. (c) It can be generic framework to automatically capture different implementa-
used by the developers of smart-card technologies to test their im- tions. Specific implementations are mapped to these abstractions
plementations. (d) It can be used by the clients themselves, to test by reasoning about the exact meaning of the input trace. Our nov-
whether their card is vulnerable to attack and, therefore, fraud. elty stems from not requiring access to the card’s software and deal-
A security token, such as a smart-card, implements all the cryp- ing with both inter-industry and proprietary implementations in a
tographic operations internally. The token stores objects (e.g., data single setting.
and certificates) that can be accessed via session handles, and per- Smart-card attacks If an attacker compromises the APDU level
forms cryptographic functions. PKCS#11 is the most widely used and the communication is not secure, she can have access to the
cryptographic standard of functions like signing, encryption, de- card’s sensitive information, e.g., private keys, or data that should
cryption, etc. API-related attacks were first discovered in [14], fol- be encrypted but is not. [17], for instance, proposes a man-in-the-
lowed by the exposure of the vulnerability to attacks of PKCS#11 middle device to allow authentication without knowing the card’s
[3, 8]. Formally analyzing security APIs and reasoning about at- PIN by intercepting and modifying the communication between the
tacks has been revisited [11, 16, 19, 20, 23] through approaches card and terminal. A different approach is to bypass confiden-
like model checking, theorem proving, customized decision proce- tiality by assuming access to the APDU buffer used to exchange
dures, or reverse-engineering for verification [3, 10, 12, 16, 22]. data [1]. The SmartLogic tool [15] obtains full control over the
However, security analysis has mostly focused on the PKCS#11 it- smart-card communication channel for eavesdropping and man-in-
self. There has been less attention given to the implementations the-middle attacks. These efforts motivate the need for a formal
connected to the standard, such as the low-level communication way of reverse-engineering the protocol and reasoning about smart-
between the on-card and the off-card applications, defined by the card security. A key assumption of all these approaches is that the
Application Data Protocol Unit (APDU). implementation of the communication channel is known before-
The basic principles of the APDU, e.g., the structure and the con- hand. However, a good number of smart-card vendors opt for a pro-
tents of the exchanged messages, the available inter-industry com- prietary implementation, which renders the existing security anal-
mands etc, are specified by the ISO 7816 standard. Precisely fol- ysis approaches inapplicable. A proprietary implementation of the
lowing the standard is not compulsory. Many smart-card manufac- communication, as witnessed by any security testing framework,
turers deviate from the standard under the assumption that a propri- looks like a random sequence of bits that needs to be deciphered to
etary APDU implementation is more secure. REPROVE reverse- understand its semantics.
engineers the APDU implementation and deduces the card’s func- Reverse-engineering protocols Protocol reverse-engineering is a
tionalities, regardless of whether it is inter-industry, proprietary or related area to our project, but works up to date do not satisfy the
a mixture of both. requirements of our project. For example, Polygot [4] automati-
A high-level description of REPROVE is shown in Figure 2. cally extracts protocol messages through binary analysis. Another
The card communicates with the reader and this communication similar approach is Prospex [9], which infers the protocol format
generates a trace that we reverse-engineer. The analysis module and the corresponding state machines. Discoverer [13] reverse-
accepts as parameters the trace and abstract models of the cryp- engineers the protocol message formats. ReFormat [21] reverse-
tographic protocols; and outputs how the card performs specific engineers encrypted messages, and [5] infers protocol state ma-
cryptographic functions. It models the low-level communication chines based on abstractions provided by the end users. All these
in first-order logic, and uses reasoning and inference over plug- projects either: (i) require software access, and/or (ii) assume
in knowledge bases, which consist of APDU abstractions based known message semantics, and/or (iii) derive only the protocol
on ISO 7816 and PKCS#11, to automatically reverse-engineer the message format without its semantics. What is central to our project
model. Its algorithm parses a communication trace and uses these is to make no assumptions about prior knowledge apart from what
abstractions to draw conclusions about the semantics of the various is publically available, i.e., the inter-industry commands of ISO
elements of the trace, narrow-down their possible implementations 7816, and map the communication to the card’s internal operations.
Contributions and roadmap The main contributions of this pa- the following, according to the standard [18]:
per are: C_login is called to log a user onto the token. A successful call
• Section 2 gives an overview of the PKCS#11 ISO/IEC 7816 can initiate a private session and provide user access to the token’s
standards. We show the discrepancies between the inter- private objects. The function takes as inputs the session handle, the
industry and proprietary definitions of the commands cov- type of the user (user, or a privileged user termed a security officer),
ered by the standard, and how these discrepancies aggravate the location of the user’s PIN and the length of the PIN.
the problem of reverse-engineering communication traces. C_generateKey is called to generate a secret key or a set of do-
• Section 3 presents the modeling of the APDU layer and its main parameters. It takes as inputs the session handle, the location
interconnection to PKCS#11. Due to space limitations we of the generation mechanism, the location of the template for the
focus on sample implementations of the C_logIn function. new key’s attributes, the number of attributes in the template and
REPROVE, however, is function independent as it is possi- the location of the handle of the new key.
ble to plug in different models. Computing all potential pro- C_sign signs data, with the signature being an appendix to the data.
prietary implementations and testing them for correctness is Its inputs are a session handle, the location of the data, the location
practically infeasible, as it is a combinatorial problem. In- of the signature and the length of the signature.
stead, we produce a model that is based on decomposing C_findObjectsInit is called to initiate a search for token and
the various functionalities of the API into finer-grained sub- session objects that match an input template with attribute values
functionalities and analyze how the commands of the stan- to match. It takes as inputs the session handle, the location of the
dard can be used to implement these functionalities. We template and the number of attributes in the template.
present the reverse-engineering algorithm to automatically C_findObjects is called after C_findObjectsInit and obtains
analyze a trace of commands and group them according to the handles of the objects that match the given template. It takes
their intended functionality as this has been captured by our as inputs the session handle, the maximum number of the returned
model. handles, the location of the additional object handles and the loca-
• Section 4 evaluates the accuracy of REPROVE, after reverse- tion of the actual number of the returned handles.
engineering five commercially available smart-cards for nine C_getAttributeValue is called to obtain the value of one or
cryptographic functions. Our results suggest that our method- more attributes of an object. It takes as inputs the session han-
ology can be used to automatically reverse-engineer traces to dle, the object’s handle, the location of a template with the attribute
detect security flaws for other PKCS#11 functions as well. values to be obtained and the number of the template’s attributes.
• Finally, Section 5 concludes the paper with a summary of our C_setAttributeValue is called to modify the value of one or
findings and with our future work directions. more attributes of an object. It takes as inputs the session handle,
the objects’ handle, the location of the template with the attributes,
the number of the attributes to change and the new values of the
2. BACKGROUND attributes.
2.1 RSA PKCS#11 C_wrapKey is called to encrypt a private or a secret key. It takes as
inputs the session handle, the location of the wrapping mechanism,
Security APIs implement access to sensitive resources in a se-
the handle of the wrapping key, the handle of the key to be wrapped,
cure way. The design of such APIs is critical, as they have to en-
the location of the wrapped key and the length of the wrapped key.
sure the secure creation, deletion, importing and exporting of a key
C_encrypt is called to encrypt single part data. It takes as inputs
from a device. Also, they are responsible for permitting the use of
the session handle, the data to be encrypted, the location of the en-
these keys for encryption, decryption, signing and authentication
crypted data and the the length of the encrypted data.
so that even if a device is exposed to malicious software the keys
C_unwrapKey is called to decrypt a wrapped key and creates a new
remain secure. The RSA PKCS#11 standard specifies an ANSI C
private key or a secret key objects. It takes as inputs the session
API, called Cryptoki, for hardware devices that can perform cryp-
handle, the location of the unwrapping mechanism, the handle of
tographic functions and store cryptographic-related and encrypted
the unwrapping key, the wrapped key, the length of the wrapped
data. It aims to ‘sand-box’ an application and isolate it from the
key, the location of the new key, the location of the template of
details of the underlying cryptographic device.
the new key, the number of the attributes in the template and the
When an application connects to a security token it authenticates
location of the handle of the new key.
itself and initiates a session which is either public or private, defin-
ing the kind of objects the application can access and the types of
operations that it can perform on them. Each session is assigned 2.2 ISO/IEC 7816
with a unique value by the Cryptoki, the session handle, to prevent ISO 7816 defines the contact smart-cards and comes into 15 parts
a blind-replay of the same session: replaying the communication each of them specifying different characteristics of the card. RE-
trace of the session and replicating its functionality thereby bypass- PROVE is based on parts 4, 8 and 9 which specify the organisation
ing all the security mechanisms through repetition of the transmit- of the card, security access, the commands for interchange, and
ted information. The application can then access the token’s objects the commands for security operations and card management. The
e.g., keys and certificates. communication consists of command-response pairs: a command
Objects have attributes which may be the value of the object or is sent by the outside world to the card and a response is the card’s
properties that define the allowed actions e.g., CKA_EXTRACTABLE reply. A command consists of a compulsory 4-byte header, with the
set to false means that the value of the object cannot be extracted bytes named Cla, Ins, P1 and P2 and an optional body with fields
from the token. PKCS#11 provides a set of functions for e.g., key, Lc, Data and Le. The Cla field is the type of the command i.e.,
token, session and object management, encryption, and decryption. inter-industry or proprietary. The Ins field indicates the specific
When a function for a particular object is called, the token checks command, e.g., the select_file command. Fields P1 and P2 are
whether the attributes of that object allow the use of that object with the instruction parameters for the command, e.g., the offset to write
respect to the called function. into the selected file. The Lc is the number of bytes of the Data
The functions that we have successfully reverse-engineered are field. The latter contains the data sent to the card. Finally, Le is the
number of the expected (if any) response bytes. A response consists application of already known PKCS#11 attacks e.g., [8] by calling
of an optional body, the response data, and a compulsory 2-byte a function directly through the APDU layer. Also, it may allow
trailer of bytes SW1 and SW2 encoding the expected status of the an attacker (i) to compromise the C_logIn function to initiate a
card after processing the command). A command can (i) send data private session and gain access to the corresponding objects and
to the card; (ii) expect data from the card; (iii) both send and expect operation, to steal the PIN, or even bypass that function, (ii) to
data; or (iv) none of the above. The length of the response depends blind-reply sessions with the token, (iii) to sniff sensitive data that
on the sent command. ISO 7816 specifies the inter-industry com- may be transmitted during the execution of the function, (iv) to alter
mand class for the Cla field, the allowable values of the Ins field object attributes through C_setAttributeValue, or, (v) to iden-
and the expected combinations of values for the P1, P2 and SW1, tify the location of sensitive data.
SW2 fields for all inter-industry commands/responses. The idea behind this work is that sufficient knowledge of the
Type Cla Ins P1 P2 Lc Data Le card’s implementation and the APDU semantics may allow greater
inter-industry 00 84 00 00 00 00 08 access than the API itself to specific PKCS#11 functions and sen-
proprietary 80 21 00 00 00 00 08 sitive objects, when the same access through library calls is re-
Table 1: Implementations of the get_challenge command. stricted.

2.4 Reverse-engineering goals

An APDU implementation is defined according to ISO 7816 and
can either be inter-industry, where the command codings are de- Inferred model REPROVE takes as input an APDU trace and
fined by the standards; or proprietary, where the developers define produces a model that describes the card’s implementation of the
their own command codings. Table 1 presents an inter-industry communication protocol. Reverse-engineering addresses three dif-
implementation of the get_challenge command and a possible pro- ferent derivations of the protocol: the exchanged commands, the
prietary one. Each byte of the inter-industry command can be de- executed on-card operations during the communication and the in-
coded, whereas the semantics of the proprietary command is un- terconnection with specific PKCS#11 functions, with each address-
known. The inter-industry implementation has its Cla field set to ing different types of attacks. For example:
00 as ISO 7816 defines, so, the remaining fields can be decoded. • Exchanged commands give insight into the semantics of the
The proprietary one has an unknown Cla code, so, it is not possible exchanged commands, may allow the identification of parts
to determine the semantics of the command using the ISO-based of transmitted data of interest to the attacker, or may gain
codings. REPROVE aims to infer such unknown semantics. knowledge of command semantics.
• On-card operations are mapped to a sequence of commands,
2.3 Threat model so the attacker may have complete knowledge of the exact
set of commands needed to execute unauthorized operations.
Reverse-engineering the APDU layer exposes possible bad prac-
• Since each of the PKCS#11 function is recorded as sets of
tices and vulnerabilities for both the APDU and the PKCS#11 im-
card operations, an attacker may be aware of which opera-
plementation. For example, permitting the token to reveal sensitive
tions she needs to execute to perform already known PKCS#11
data when it should not, an implementation that does not use pro-
attacks.
tection mechanisms, e.g., encryption, when transmitting sensitive
Tested functions In our experiments we tested REPROVE in five
data, or an implementation that performs cryptographic operations
commercially available smart-cards and checked for the following
outside the token. In such cases the opportunity to steal sensitive
PKCS#11 violations: (i) the cryptographic function is not exe-
information, e.g., keys, is almost inevitable. Moreover, reverse-
cuted on-card, (ii) the cryptographic function does not respect the
engineering the APDU layer provides the required knowledge to
PKCS#11 specifications, (iii) misuse of session handles, (iv) sensi-
apply a wide range of attacks.
tive data leakage, i.e., when it should not be revealed and (v) lack
Attacker model The attacker model that we are considering is
of encryption when needed, e.g., when sensitive data is transmitted.
a non-legitimate user or a malicious software that control the com-
The outputs of REPROVE can be useful to both the card sup-
munication layer to:
pliers and private users, in order to verify the security of logging
1. authenticate by compromising the C_logIn function and ex-
into a particular card. REPROVE aids in understanding the secu-
ploit their credentials to perform unauthorized operations and
rity properties of the underlying implementation. Our technique
steal senstive data e.g., keys, and/or
is extensible and allows different formal models to be plugged-in,
2. send a sequence of APDU commands that lead to sensitive
depending on the security properties to be checked.
information leakage by repeating the same operations initi-
ated by the API calls during the execution of a cryptographic
function. 3. METHODOLOGY
Attacks Although performing such attacks is not part of this We have modeled the APDU reverse-engineering as an infer-
work, we have identified potential risks that can be addressed. Such ence problem. REPROVE has a built-in inference engine that al-
attacks can be performed by using third party tools. Knowledge lows to plug-in different knowledge bases such as models, abstrac-
of the APDU semantics and the corresponding on-card operations tions and specifications of the protocol. The background knowl-
may enable (i) manipulation of the communication to deceive the edge to our problem consists of abstract models, which need to be
user, e.g., let the user believe that a particular operation is executed instantiated according to the input trace. These models are based
while in reality a different one is taking place, (ii) sniffing sensitive on ISO 7816 and define: (i) the main properties, the restrictions
data, (iii) repetition of a communication run, (iv) alteration of the and requirements of communication, (ii) possible implementations
transmitted data, (v) alteration of a communication run by injecting of the on-card operations, (iii) possible implementations of spe-
commands, (vi) bypassing security mechanisms, (vii) unauthorized cific PKCS#11 functions. Such models do not hard-code the im-
access to the card’s operations, or (viii) cloning of the card. plementation of the card. They present abstractions of different
Additionally, having the know-how of the PKCS#11 implemen- functionalities that are then refined according to the input trace.
tation at the APDU layer may allow access to the standard’s func- The background knowledge is expressed in first-order logic as it is
tions and the token’s objects that library calls do not permit, or the machine-readable and expressive enough to model the protocol’s
 decomposed implemented APDU layer characterised data exchange and command; (ii) a proprietary command that can be mapped1 to an
operation steps
into as commands by role properties inter-industry command that does not occurre within the same trace.
A command is categorized based on: (i) its data exchange proper-
commanda YY, core
ties; and (ii) the card operations.
sub-functionality1 Categorization according to data exchange properties Depend-
commandb NY, core ing on the exchanged data, a command is assigned to one of the
following categories:
commandx (i) commandnn (Cla, Ins, P1, P2, Lc, D, Le): no data is sent, no data is
YY, core
expected,
functionality sub-functionality2 commandy NY, additional
(ii) commandny (Cla, Ins, P1, P2, Lc, D, Le): no data is sent, data is ex-
pected,
commandz YN, additional (iii) commandyy (Cla, Ins, P1, P2, Lc, D, Le): data is sent, data is expected,
(iv) commandyn (Cla, Ins, P1, P2, Lc, D, Le): data is sent, no data is ex-
pected.
commanda YY, additional
sub-functionality3 Variables Lc, D and Le define the category of a command. We
commandx NN, dummy
defined rules that assign each command to the appropriate category.
For example, if Lc 6= 00 and D 6= 00 then the command sends some
data D with length Lc to the card. If Le is not null2 then the
Figure 3: A single operation represents a specific functionality response will be some data with length Le. The above is captured
and it is modeled as a sequence of sub-functionalities. Each sub- by the following rule:
functionality is further implemented as a sequence of commands.
Commands are characterized by their data exchange properties and
∀Cla, Ins, P1, P2, Lc, D, Le,((command(Cla, Ins, P1, P2, Lc, D, Le)
role within some particular sub-functionality.
∧ Lc = 00 ∧ D = 00 ∧ Le 6= null)
→ (commandny (Cla, Ins, P1, P2, Lc, D, Le))
rules. REPROVE’s reverse-engineering algorithm constructs and
refines the possible mappings while extracting abstract properties
Categorization according to card operations The commands
and functionalities.
are further categorized depending on their role in a specific on-card
More formally, REPROVE applies the transformation function
operation, to:
y( f (x)) with f : T n → I n and y : I n → Om , where T n is an input
(i) Core: the basic commands that perform the operation, e.g., to
trace of n commands, I n is a set of n inter-industry commands and
create a new file create_file is a core command.
Om is a set of m on-card operations.
(ii) Additional: the commands that add extra properties to the op-
3.1 Modeling the APDU layer eration, but they do not change its meaning; the same opera-
tion can be performed without them. For example, to create
ISO 7816 defines different meanings for a command depend- a file, select is an additional command as it merely adds in-
ing on particular fields of that command. REPROVE’s background formation to the file creation (e.g., selecting a path to create
knowledge consists of all the meanings defined by the ISO and the the file into) but the operation can be also performed without
corresponding preconditions: 49 individual commands with 122 it.
different meanings in total. A sample of these commands are the (iii) Dummy: the commands that neither send nor expect any data.
following: They usually just query, or check, the communication with
select get_data the card. For example, a verify command when it does not
read_binary read_record send nor expect any data to/from the card. Such commands
update_binary erase_record may occur any time during the communication and they do
activate_file put_data
get_response perform_security_operation not affect the reverse-engineering output.
append_record create_file Command preconditions The preconditions of a command de-
append_file get_challenge fine: (i) the values of its parameters, (ii) the restrictions on the
verify activate_file
external_authenticate mutual_authenticate types of previously issued commands, (iii) different semantics for
the same command, and (iv) the valid data types and file structures
In Figure 3 we show a high-level description of our modeling ap- for that command. For instance, the common use of read_binary
proach. Each individual card operation (functionality) of the card is to access the content of an elementary file (EF). Yet, if the value
is decomposed into a sequence of steps (sub-functionalities). Each of parameter P1 is between 128 and 160 then read_binary is used
step is then implemented as a sequence of APDU commands: pro- to select the EF file defined by the data field D. This precondition
prietary, inter-industry, or a mix of them. The APDU commands is modeled as:
are further characterized depending on their data exchange proper-
ties (shown, for example, as ‘YY’ in the figure to indicate a com-
∀Cla, Ins, P1, P2, Lc, D, Le,((command(Cla, bo, P1, P2, Lc, D, Le)
mand that both sends and receives data) and their role within the
sub-functionality in question (core, additional, or dummy). The ∧P1 ∈ [128, 160]) → (select(file, D) ∧ isa(D, EF)))
same command may have different data exchange properties and
different roles depending the sub-functionality, e.g., commanda and Card operations We introduce a hierarchy of abstractions, the
commandx in Figure 3. functionality models, which provide high-level views of different
APDU commands An APDU command is represented as a predi- on-card operations, and the sub-functionality models which describe
cate command(Cla, Ins, P1, P2, Lc, D, Le) where the variables Cla,
Ins, P1, P2, Lc, D, Le are instantiated according to the semantics 1 Under the condition that all preconditions are satisfiable.
of the command. A command is valid if it is: (i) an inter-industry 2 Null indicates absence of a field.
 Functionality Core and Additional sub-functionalities set
Sub-functionality Core command set
store_data {file_created, data_written, data_updated}
selected {select, read_binary}
{selected, read_data_sub}
read_data_sub {get_data, read_binary, get_response, read_record}
authenticated {challenge_sent, verified,
data_updated {update_binary} {update_record} external_authenticated, internal_authenticated,
data_written {write_binary, update_binary, write_record} mutual_authenticated} {selected, read_data_sub,
data_written}
Table 2: Sample of sub-functionalities and the corresponding core
commands. Table 3: Sample of functionalities and the corresponding sub-
functionality sets.

the steps by which each operation is implemented. A valid (sub-

)/functionality has: (i) all its preconditions satisfied by the com-
mands3 seen so far, or (ii) has a subset of its preconditions satisfied RSA PKCS#11 models PKCS#11 models are expressed in terms
by the commands seen so far, but it is possible to satisfy the rest of functionalities and represent our assumptions on how specific
by the commands that will follow, i.e., the (sub-)/functionality is cryptographic functions might be implemented at the APDU level.
partially satisfiable. These models aim to capture an abstraction of the expected on-card
Sub-functionalities Sub-functionalities model the steps, in terms operations and they do not impose an implementation, but merely
of the exchanged commands, that are needed to perform a card op- act as a flexible guide of the implemented functionality.
eration. The same sub-functionality may be performed in differ- Each cryptographic function is modeled as a set of functionali-
ent ways, thus, it may have more than one model. REPROVE’s ties based on the PKCS#11 and the ISO 7816 specifications. For
background knowledge has 36 sub-functionality models. In Ta- example, for the C_logIn function we expect one of the authen-
ble 2, we give a sample of sub-functionalities and their correspond- tication operations to be a core one: a PIN/Pass-code verification
ing core commands. For example, the authentication of the reader or a challenge-response one. Also, an invocation of the read_data
through the challenge-response protocol is expressed by the ex- functionality for authentication-related data is possible as an ad-
ternal_authenticated(RD, D) sub-functionality. The card issues a ditional operation. Authentication is defined with respect to ISO
challenge RD and the reader authenticates itself by providing the 7816: (i) authentication with a PIN: the card compares received
corresponding response D. The following rule describes this: data from the outside world with internal data; (ii) authentication
with a key: an entity to be authenticated has to prove the knowl-
edge of a relevant key through the challenge-response procedure;
∀RD, Le, P1, P2, Lc, D,((command(00, 84, 0, 0, 0, 0, Le) ∧ response(RD) (iii) data authentication: using internal data, secret or public, the
∧ command(00, 87, P1, P2, Lc, D, null) card checks data received by the outside world. Another way is for
∧P2 ∈ [128, 256]) the card to check secret internal data and compute a data element
→ external_authenticated(RD, D)) (cryptographic checksum or digital signature) and insert it to the
data sent to the outside world; (iv) data encipherment: using secret
which says that if the command Ins = 84 with a response of the internal data, the card enciphers a cryptogram received in a data
card RD, is followed by the command Ins = 87 with its parameter field, or using internal data (secret or public) the card computes
P2 being between 128 and 256, then the reader has authenticated it- a cryptogram and inserts it in a data field, possibly together with
self via a challenge-response external authentication. Furthermore, other data.
we categorize each sub-functionality as: (i) a sensitive operation:
any process that we expect to deal with sensitive data, e.g., the ver-
3.2 Reverse-engineering algorithm
ification of a PIN; or (ii) a non-sensitive operation: any generic The algorithm consists of three steps, each addressing a differ-
process over non-sensitive data, e.g., the selection of a file. ent abstraction of the implementation: (i) the APDU semantics,
Functionalities Functionalities model the on-card operations. As (ii) the on-card operations that are executed during the communi-
there are different implementation ways, each functionality consists cation, and (iii) the APDU implementation of a PKCS#11 function.
of a set of possible core and additional sub-functionalities. For ex- Figure 4 shows how we restrict the search space during the three-
ample, consider two cards Cardx and Cardy which both store data step analysis: grey arrows indicate narrowing-down and black ar-
(store_data). Cardx performs this operation through a file_created rows indicate mapping; each path of a black tree is an individual
sub-functionality, while Cardy through a data_written. Table 3 mapping of the same APDU trace. The nodes appearing at the
presents a sample of the defined functionalities and their corre- same depth represent different mappings of the same command;
sponding sub-functionality sets. The core sub-functionalities are each path of a grey tree represents a sequence of operation steps
extracted on the basis that at least one of them (but potentially (sub-/functionalities) and each path of a white tree represents a se-
more) are necessary for the implementation of the functionality. quence of executed card operations (functionalities).
Additional sub-functionalities may appear in the implementation, Step 1. Step 2. Step 3.
but are not compulsory. REPROVE’s background knowledge has
15 functionality models.
General rules We define rules to describe communication restric-
tions, card responses, file specifications and data types. For in-
stance, the following rule requires that if some data D of length
Le is expected, then the response should contain D and the corre-
sponding length should be Le.
Figure 4: Reducing the search space.
∀Le, D(expected(data, Le, D) → (response(D) ∧ length(D, Le)))
Step 1: Semantics of the APDU trace. Given an input trace T n of
3 Under the condition that the response is positive i.e., 90 00. n commands, we generate a tree in which each path from root to leaf
Tin 0 is a semantic mapping of the trace such that T n 7→ Tin 0 . As the ex- categorization to inter-industry (⃝)
change of the command-response pairs is sequential so is the anal- or proprietary commands (●)

ysis of the commands, which implies that the semantics of an un-

known command heavily depend on the previous commands. Each
unknown command is categorized and all corresponding mappings
M are identified, which are then narrowed-down to a set P0 based inter-industry mappings
for the same proprietary command
on precondition satisfiability. For each mapping m ∈ P0 , the com-
mands analyzed so far are grouped, and sets that fully or partially4
satisfy any sub-functionality are considered valid. The outcome
of this process is a set of valid5 mappings M 00 of each unknown
command such that M 00 ⊆ P0 ⊆ M , and the set P which consists of
different interpretations of T . More formally, Step 1 performs the
transformation f : f (T n ) = Pn where ∀Tin 0 ∈ Pn : T n 7→ Tin 0 .
Step 2: On-card operations. At this stage, given Pn from the potential
sub-functionalities ( )
previous step, the commands at each Tin 0 ∈ Pn are grouped in all of the same
inter-industry command
possible combinations. Each group is checked on whether there
exist any sub-functionality(ies) that satisfy its preconditions. The
outcome of this process is a set Sl of sub-functionalities such that
∀Sl k ∈ Sl ∃Tin 0 ∈ Pn : Tin 0 7→ Sl k . Then all sub-functionalities in Sl
are grouped and the set of valid functionalities Om is identified. valid sub-functionality combinations for each sub-functionality combination,
after filtering them test different groupings of
The sub-functionalities that do not satisfy Om are discarded along by precondition satisfiability sub-functionalities into functionalities
with the corresponding trace mappings. The overall step can be
0 0
presented as a function y: y(Pn ) = Om with Sl 7→ Om , Sl ⊆ Sl , and
0
Pn0 7→ Sl , Pn0 ⊆ Pn .
Step 3: APDU implementation of the PKCS#11 function. Here, …
the set of functionalities Om from Step 2 is mapped to the back-
ground models of specific PKCS#11 functions, resulting in an in-
terpretation of the communication in terms of the standard. The
outcome is the APDU mapping to PKCS#11, the set of card oper-
Figure 5: The transformations of the APDU trace during the
ations that are executed during the communication Om0 ⊆ Om , and
reverse-engineering process.
the APDU trace Tin 0 ∈ T n0 that satisfy them.
In each reverse-engineering step the low-level input (commands)
evolves to abstract models (card operations). A schematic descrip-
of an inter-industry command are not met, the erroneous mapping
tion of the transformations of the commands during the reverse-
is removed from M and the analysis continues to the next candi-
engineering process is presented in Figure 5. The trace itself goes
date mapping; else, we iterate over the analyzed trace so far, and
through a sequence of transformations: from commands, to inter-
look at the categorization of commands based on their role. Us-
industry mappings, to potential sub-functionalities, to groups of
ing this role, we group commands into different combinations that
sub-functionalities into higher-level functionalities. If REPROVE
may form potential sub-functionalities. If such grouping exists, the
is successful in providing a sequence of functionalities that de-
mapping is stored in P. If c is an inter-industry command, there
scribe a PKCS#11 function, then the trace is effectively reverse-
is only one such mapping n, so M is a singleton list. We search
engineered. This translates into a vulnerability for the card as it
for satisfiable (sub-)/functionalities by this command and store the
exposes its implementation.
command in P (lines 13 to 17). At this point P consists of differ-
Reverse-engineering algorithm The overall reverse-engineering
ent mappings of the trace. Then, P is further narrowed-down based
process for a trace of commands is shown in Algorithm 1. The input
on the sub-functionality and functionality models (lines 18 to 25).
to the algorithm is a list T of commands representing the commu-
For each different mapping of the trace, the commands are grouped
nication trace, whereas the output is a list P of potential mappings
into sub-functionalities which are then further grouped into higher-
of T (each mapping is a list itself) and a list O of card function-
level functionalities that are added to O, all in the context of our
alities. The list P is initialized to [[]] which indicates that the first
models. If no such grouping is found for a candidate trace, the
mapping is the empty one. Each command c ∈ T is then analyzed
trace is removed from P. If a grouping is found, its constituents
and depending on its value of Cla it is classified as proprietary or
mappings are annotated accordingly to denote this. The final step
inter-industry. In the former case (lines 3 to 5) the values of its Lc ,
of the algorithm is to further narrow-down P by matching the re-
D , and Le parameters are checked to categorize its data exchange
sulting functionalities in O with the PKCS#11 models. In the end,
properties and obtain a list M of potential mappings. From M we
P will contain zero or more traces of candidate mappings. If P is
only keep the valid mappings (lines 5 to 6) and store them in P.
empty, our reverse-engineering has failed to produce a mapping. If
The valid mappings are identified based on precondition and sub-
there is only one trace in P we say that the mapping is unique. If
functionality satisfiability (lines 6 to 9): for each potential mapping
there are more than one candidate traces the reverse-engineering is
to an inter-industry command, we check that the preconditions of
successful, but we have only identified an abstraction of the correct
the inter-industry command are met by computing the union of the
mapping.
postconditions of all commands that precede it. If the preconditions
4 Given a sub-functionality, there exists at least one core command
that satisfies its preconditions.
5 Valid here indicates that neither the ISO, nor any background
model is violated.
 Algorithm 1: The reverse-engineering process for a trace of exactly match the high-level view of the implementation, i.e.,
commands on-card executed operations.
input : List T of commands to be analyzed To address these aspects we used the standard precision and recall
output: Potential mappings and operation models P for T metrics, as defined by:
1 P = [[]]; O = [[]];
True Positives
2 foreach c(Cla, Ins, P1 , P2 , Lc , D, Le ) ∈ T do precision =
3 if Ins indicates c is proprietary then True Positives + False Positives
4 use `c , d, `e to extract data exchange properties δ ;
5 M = list of APDU commands c maps to based on δ ; True Postives
6 foreach m ∈ M do recall =
7 Z = {z | (k precedes m in p) ∧ (z ∈ postconditions(sk ))};
True Positives + False Negatives
8 if preconditions of m are not satisfied by Z then where (i) True Positive: the outcome model suggests the cor-
9 remove m and move on to the next; rect on-card operations and the exact meaning of the APDU trace,
10 foreach p ∈ P do (ii) False Positive: the outcome model suggests the correct on-card
11 if a grouping of p to sub-functionalities can be found operations, and a partially correct meaning of the APDU trace (the
then
APDU semantics does not exactly match with the actual implemen-
12 s = p ⊕ (c 7→ m); P = P ⊕ s
tation), (iii) False Negative: the outcome model suggest incorrect
on-card operations and an incorrect meaning of the APDU trace.
13 n = inter-industry command c maps to; M = [n]; For each smart-card we used the sniffed APDU trace as the in-
14 annotate each command with its sub-functionality;
15 annotate sub-functionalities with functionalities;
put to REPROVE. The trace was produced when each PKCS#11
16 O = O ⊕ functionalities; function was called. We were aware of the implementation of each
17 s = p ⊕ (c 7→ n); P = P ⊕ s; smart-card from the beginning but we treated them as unknowns
18 foreach p ∈ P do during the reverse-engineering. To evaluate the quality of the re-
19 foreach (c 7→ m) ∈ p, potential sub-functionality of m do sults we compared REPROVE’s output with the actual implemen-
20 group sub-functionalities into functionalities; tation. Because of a non-disclosure agreement (NDA) we must re-
21 if no such grouping can be found then remove p from P; frain from naming the cards and revealing details of their imple-
22 else mentation. More information about their implementations and a
23 annotate each command with its sub-functionality;
24 annotate command groups with functionalities;
reproduction of our study can be obtained with appropriate permis-
25 O = O ⊕ functionalities; sion through an NDA.

26 foreach f ∈ O do 4.2 Results

27 if f ∈
/ PKCS#11 models then remove f from O; remove p
from P ;
Number of inferred models REPROVE performed well on all
cards: it inferred at least one model for the exchanged commands,
28 return P,O; one model for the on-card operations and one model for the an-
alyzed cryptographic function. In most cases the inferred model
was unique and matched exactly with the actual implementation of
the card. The results are presented in Table 4. For Card1 and Card2
4. EVALUATION in the case of C_logIn and for Card5 in the case of C_sign RE-
PROVE inferred the correct on-card operations but suggested two
4.1 Experimental setting different implementation models. In all cases the correct model of
We have evaluated REPROVE using five commercially available the implementation existed within the suggested ones.
smart-cards. Each smart-card had its own API implementation, Security vulnerabilities suggested by the models We checked
provided by the manufacturer, with none of them using an open- REPROVE’s suggested models for 1. security-vulnerabilities at the
source implementation like opencryptoki. We were not able to test APDU layer, and 2. violations of the PKCS#11 standard.
the same PKCS#11 functions for all cards. This is because in some 1. APDU Level. The first security vulnerability we checked was
cases the cryptographic function was executed library-side instead sensitive information leakage and identification of the location of
of token-side (i.e., outside the card instead of on-card), which is the sensitive data. The functions that were not implemented in a
violation of the standard as it allows for sensitive data, eg., keys, to secure way are the following:
be transmitted outside of the token. i) C_logIn. In all cases we were able to identify the authentication
Our purpose was to assess REPROVE along the following di- data and the location that was stored. In two cases the authentica-
mensions: tion data was sent in plaintext, which consequently allowed man-
• Functional success: the system infers at least one model. If in-the-middle attacks.
REPROVE is unable to infer a model then, there are two Moreover, the resulting models suggested the specific on-card op-
cases: (i) the system has failed, or (ii) the communication erations that were executed during the authentication with the to-
is encrypted. The latter case is not REPROVE’s failure as it ken. As the card uses the exact same authentication ways in each
merely acts as a verification that the implementation is se- initiated session, such knowledge may enable a blind-replay attack
cure. where the attacker replays the exchanged data at specific points dur-
• Quality of the results: the output captures at least a high- ing communication; or, the attacker requests the same operations to
level view of the implementation. REPROVE can produce be performed, in the hopes that these operations, albeit applied in a
more than one output models. We consider the following blind way, are enough to gain access to sensitive data.
outcomes to be of high quality: (i) a unique model which ii) C_wrapKey. In one case the card returned the sensitive key in
matches exactly both with the low- and the high-level views plaintext and the function was executed library-side.
of the implementation, i.e., the exchanged commands and the iii) C_generateKey. In two cases the card returned the sensitive
on-card executed operations, and (ii) two or more models that key in plaintext and the function was executed library-side.
 Function Precision Recall Function Total B.CC R.CC R.SFC R.FC R.Model
Card1 C_logIn 0.5 1 Card1 C_logIn 13932 24 11 3 2
C_wrapKey 1 1 C_wrapKey 20 4 1 1 1
C_sign 1 1 C_sign 20 8 1 1 1
C_findObjects 20 3 1 1 1
C_findObjects 1 1
C_generateKey 86 9 2 1 1
C_getAttributeValue 1 1 C_getAttribute 400 6 1 1 1
C_generateKey 1 1 C_encrypt 200 4 1 1 1
C_getAttribute 1 1 Card2 C_logIn 32000 12 4 2 2
C_encrypt 1 1 C_sign 20 24 1 1 1
Card2 C_logIn 0.5 1 C_findObjects 400 3 1 1 1
C_sign 1 1 C_generateKey 540x868 512 69 8 1
C_findObjects 1 1 C_setAttributeValue 86 14 3 1 1
C_generateKey 1 1 C_encrypt 20 3 4 2 1
C_setAttributeValue 1 1 Card3 C_logIn 1 1 1 1 1 1
C_sign 1 1 1 1 1
C_encrypt 1 1
C_findObjects 1 1 1 1 1
Card3 C_logIn 1 1 C_getAttribute 1 1 1 1 1
C_sign 1 1 C_setAttribuyeValue 1 1 1 1 1
C_findObjects 1 1 Card4 C_logIn 7396 65 39 21 1
C_getAttribute 1 1 C_findObjects 7396 6 1 1 1
C_setAttribuyeValue 1 1 C_getAttributeValue 54700816 3 1 1 1
Card4 C_logIn 1 1 C_sign 86 1 1 1 1
Card4 C_findObjects 1 1 Card5 C_logIn 1 1 1 1 1
C_sign 12322 53 7 4 2
Card4 C_getAttributeValue 1 1
C_setAttributeValue 1 1 1 1 1
Card4 C_sign 1 1
Card5 C_logIn 1 1
C_sign 0.5 1
C_setAttributeValue 1 1 Table 5: Reduction in the number of alternative implementations
during the analysis.
Table 4: RSA PKCS#11 reverse-engineering evaluation results.

happens when either most of the commands or all the commands of

the trace are inter-industry, which suggests an 1-1 mapping. How-
iv) C_encrypt. In one case the card returned the sensitive key in ever, in some cases the search space is prohibitive, eg., in Card2
plaintext and the function was executed library-side. for the C_generateKey function there are 540x868 total command
2. RSA PKCS#11. We checked the resulting models for viola- combinations. In such cases REPROVE narrows-down the combi-
tions of the standard that may lead to security vulnerabilities. Ac- nations to a single mapping.
cording to PKCS#11 each initiated session is uniquely identified by Discussion REPROVE inferred at least a high-level model of the
a freshly produced session handle. This handle will also be an in- actual implementation for all tested cards. In some cases the reverse-
put of each function that is called within that session. REPROVE’s engineering outcome was more than one model, each one captur-
results showed that all tested cards violated this specification. Such ing the same on-card operations but differed at the implementation
departure from the standard allows blind-replaying a given ses- level. We do not consider this as a failure as REPROVE provided
sion. Another problem is that trivial authentication methods were at least a high-level view of the implementation. However, this
used. As the protocol is stateless, the same trivial authentication shows the necessity of incorporating feedback techniques to refine
method is used before all operations over sensitive data. There- the reverse-engineering outcome. A straightforward technique is
fore, by knowing how C_login is implemented one may employ to send the analyzed commands to the card in order to check the
this trivial authentication to gain access to unauthorized operations. validity of the results and discard suggestions that do not work.
Moreover, according to the PKCS#11 documentation sensitive keys
must not be revealed off the token in plaintext which is another se-
rious violation of the standard. Finally, one of the most significant 5. CONCLUSIONS AND FUTURE WORK
findings is that in many cases the tested cryptographic functions We have presented REPROVE, a proof-of-concept system for
took place library-side, instead of token-side as the intended use of automatically analyzing the low-level communication protocol of
smart-cards. Such misuse of the standard allows sensitive data to a smart-card by reasoning over a formal model of the ISO 7816
leave the token. standard, regardless of the protocol’s implementation. We have
Narrowing-down the search space The reverse-engineering of used REPROVE to successfully extract at least one model from
proprietary APDUs is a combinatorial problem and the solution each tested card and shown that, although analyzing proprietary
time grows exponentially with the size of the APDU trace. RE- implementations is a combinatorial problem, it is possible to lever-
PROVE uses search to advance towards the proof, and inference to age background knowledge to effectively reduce the search space.
block and exclude directions from the search. During the analy- To the best of our knowledge, REPROVE is the first system that
sis, the search space is continuously restricted until the final model successfully reverse-engineers proprietary implementations. RE-
is produced. To demonstrate REPROVE’s effectiveness on that PROVE’s results can provide the necessary evidence to reason about
matter, we have implemented a baseline algorithm that generates the implementation of the protocol and discover possible security
a search tree that consists of all possible mappings (including dif- flaws. Obtaining such evidence is especially crucial, as bad imple-
ferent meanings of each command) of the APDU trace, based on mentations may lead to fraud and/or disputes between card issuer
the category each command belongs to. Table 5 presents the com- and client.
mand combinations produced by the baseline algorithm, termed We have evaluated REPROVE by reverse-engineering the APDU
B.CC. The terms R.CC, R.SBC and R.FC present REPROVE’s to- implementations of five commercially available smart-cards. Dur-
tal command, sub-functionality and functionality combinations re- ing these experiments we were surprised by our findings, which
spectively. Model is the number of final model(s) suggested by RE- suggested many insecurities of the cards. All of the cards violate
PROVE for the specific cryptographic function. At each successive the specification of PKCS#11 that requires each session to be iden-
step the number of alternative implementations is progressively re- tified by a unique session handle. This specification aims at pre-
duced. As Table 5 demonstrates there are cases that B.CC is 1. That venting blind-reply attacks and its violation automatically makes
the token vulnerable. Also, the majority of the cards do not respect [8] J. Clulow. On the Security of PKCS#11. In IN Proceedings
the security specifications of the standard by allowing sensitive in- Of the 5TH International Workshop on Cryptographic
formation to leave the token or even performing the cryptographic Hardware and Embedded Systems, CHES, pages 411–425,
functions library-side. Last but not least, we discovered implemen- 2003.
tations that allowed the cryptographic function to be executed out- [9] P. M. Comparetti, G. Wondracek, C. Kruegel, and E. Kirda.
side the token. Regarding the implementation of the communica- Prospex: Protocol specification extraction. In Proceedings of
tion, in many cards sensitive data was treated as public: this part the 2009 30th IEEE Symposium on Security and Privacy, SP
of the communication was not encrypted and the data was sent in ’09, pages 110–125, 2009.
plaintext. Such implementations are vulnerable to attacks and make [10] V. Cortier, G. Keighren, and G. Steel. Automatic analysis of
the sectors that use them insecure. Detecting such violations man- the security of XOR-based key management schemes,. In
ually is not trivial: it requires either knowledge of the semantics of O. Grumberg and M. Huth, editors, TACAS 2007, number
the communication trace, access to the PKCS#11 library or/and to 4424 in LNCS, pages 538–552, 2007.
the card’s code. REPROVE does not make any of these assump- [11] J. Courant and J.-F. Monin. Defending the Bank with a Proof
tions. assistant. In In Proceedings of the 6th International
Reverse-engineering PKCS#11 based APIs and discovering vul- Workshop on Issues in the Theory of Security, pages 87–98,
nerabilities is not a new idea, e.g., Tookan [3] reverse-engineers a 2006.
card’s API and discovers security flaws with respect to the standard. [12] J. Courant and J.-F. Monin. Defending the bank with a proof
On another perspective, Caml Crush [2] acts as an attack filtering assistant. In WITS 2006, 2006. In WITS proceedings.
tool that sits between the PKCS#11 device and the calling applica-
[13] W. Cui, J. Kannan, and H. J. Wang. Discoverer: Automatic
tion. Caml Crush considers attacks only at the API level and not
protocol reverse engineering from network traces. In
at the low-level communication. Targeting the implementation of
Proceedings of 16th USENIX Security Symposium on
PKCS#11 at the low-level communication is a novel idea and sug-
USENIX Security Symposium, SS’07, pages 14:1–14:14,
gests a new way of attacking the standard by bypassing the API and
2007.
talking directly to the device, thereby avoiding API-level restric-
tions. Such attacks cannot be detected nor filtered by such tools, as [14] S. R. D. Longley. An automatic search for security flaws in
they address strictly the API level. REPROVE addresses PKCS#11 key management schemes. Computers and Security, 11(1),
attacks at the APDU layer. PKCS#11 defines specifications for se- 1992.
cure implementations and applies to a broad range of cards. These [15] G. de Koning Gans and J. de Ruiter. The SmartLogic Tool:
specifications have to be addressed at the communication layer as Analysing and Testing Smart Card Protocols. In Proceedings
well, e.g., in session identification. REPROVE’s analysis exposed of the 2012 IEEE Fifth International Conference on Software
several violations of the standard’s specifications. Reaching these Testing, Verification and Validation, ICST ’12, pages
findings in the first place would not have been possible without 864–871, 2012.
reverse-engineering. We therefore believe our approach cuts across [16] S. Delaune, S. Kremer, and G. Steel. Formal analysis of
all layers of the PKCS#11 implementation and provides a blueprint PKCS#11. In CSF, pages 331–344, 2008.
that can be applied to other models and protocols as well. [17] S. J. Murdoch, S. Drimer, R. Anderson, and M. Bond. Chip
and pin is broken. In Proceedings of the 2010 IEEE
6. REFERENCES Symposium on Security and Privacy, SP ’10, pages 433–446.
[1] G. Barbu, C. Giraud, and V. Guerin. Embedded IEEE Computer Society, 2010.
eavesdropping on java card. In SEC, pages 37–48, 2012. [18] RSA Security INC. v2.20. PKCS#11: Cryptographic Token
[2] R. Benadjila, T. Calderon, and M. Daubignard. Caml crush: Interface Standard, 2004.
A pkcs# 11 filtering proxy. In Smart Card Research and [19] G. Steel and A. Bundy. Deduction with xor constraints in
Advanced Applications, pages 173–192. Springer, 2014. security api modelling. In In Proceedings of the 20th
[3] M. Bortolozzo, M. Centenaro, R. Focardi, and G. Steel. International Conference on Automated Deduction, volume
Attacking and fixing pkcs#11 security tokens. In ACM 3632 of LNCS, pages 322–336, 2005.
Conference on Computer and Communications Security, [20] E. Tsalapati. Analysis of PKCS#11 using AVISPA tools.
pages 260–269, 2010. Master thesis, University of Edinburgh, 2007.
[4] J. Caballero, H. Yin, Z. Liang, and D. Song. Polyglot: [21] Z. Wang, X. Jiang, W. Cui, X. Wang, and M. Grace.
Automatic extraction of protocol message format using Reformat: Automatic reverse engineering of encrypted
dynamic binary analysis. In Proceedings of the 14th ACM messages. In Proceedings of the 14th European Conference
Conference on Computer and Communications Security, on Research in Computer Security, ESORICS’09, pages
CCS ’07, pages 317–329, 2007. 200–215, 2009.
[5] C. Y. Cho, D. Babi ć, E. C. R. Shin, and D. Song. Inference [22] P. Youn, B. Adida, M. Bond, J. Clulow, J. Herzog, A. Lin,
and analysis of formal models of botnet command and R. Rivest, and R. Anderson. Robbing the bank with a
control protocols. In Proceedings of the 17th ACM theorem prover. Technical Report UCAM-CL-TR-644,
Conference on Computer and Communications Security, University of Cambridge, 2005.
CCS ’10, pages 426–439, 2010. [23] P. Youn, B. Adida, M. Bond, J. Clulow, J. Herzog, A. Lin,
[6] T. Chothia and V. Smirnov. A traceability attack against R. L. Rivest, and R. Anderson. Robbing the bank with a
e-passports. In Financial Cryptography, volume 6052 of theorem prover. Technical report, Univerisity of Cambridge,
Lecture Notes in Computer Science, pages 20–34. Springer, 2005.
2010.
[7] O. Choudary. The Smart Card Detective: a hand-held emv
interceptor, University of Cambridge, Computer Laboratory,
Darwin College, MPhil thesis, 2010.