Secure Messaging Implementation in OpenSC

doi:10.4236/jis.2012.34032

Paper Menu >>

Journal Menu >>

Journal of Information Security, 2012, 3, 251-258

http://dx.doi.org/10.4236/jis.2012.34032 Published Online October 2012 (http://www.SciRP.org/journal/jis)

Secure Messaging Implementation in OpenSC

Maurizio Talamo1,2, Maulahikmah Galinium3, Christian H. Schunck2, Franco Arcieri2

1Department of Engineering, University of Rome Tor Vergata, Rome, Italy

2Nestor Laboratory, University of Rome Tor Verg ata, Rome , Italy

3Department of Information Science, University of Rome Tor Vergata, Rome , Ita ly

Email: [email protected], [email protected].it, [email protected]roma2.it, [email protected]

Received July 15, 2012; revised August 27, 2012; accepted September 8, 2012

ABSTRACT

Smartcards are used for a rapidly increasing number of applications including electronic identity, driving licenses,

physical access, health care, digital signature, and electronic payments. The use of a specific smartcard in a “closed”

environment generally provides a high level of security. In a closed environment no other smartcards are employed and

the card use is restricted to the smartcard’s own firmware, approved software applications, and approved card reader.

However, the same level of security cannot be claimed for open environments where smartcards from different manu-

facturers might interact with various smartcard applications. The reason is that despite a number of existing standards

and certification protocols like Common Criteria and CWA 14169, secu re and co nven ien t smartcard interoperability h as

remained a challenge. Ideally, just one middleware would handle the interactions between various software applications

and different smartcards securely and seamlessly. In our ongoing research we investigate the und erlying interop erability

and security problems specifically for digital signature processes. An important part of such a middleware is a set of

utilities and libraries that support cryptographic applications including authentication and digital signatures for a sig-

nificant number of smartcards. The open-source project OpenSC provides such utilities and libraries. Here we identify

some security lacks of OpenSC used as such a middleware. By implementing a secure messaging function in OpenSC

0.12.0 that protects the PIN and data exch ange between th e SC and the midd leware, we ad dress one impo rtant secur ity

weakness. This enables th e integration of digital signature fun ctionality into the Open SC environment.

Keywords: Smart Card; Digital Signature; OpenSC; Secure Messaging

1. Introduction

The problem of secure Smartcard (SC) interoperability is

one of the main issues that might limit the use of SCs in

the future. The success of SC ba sed online authen tication

and digital signature services critically depends on how

this problem will be addressed: users expect SC based

applications to work seamlessly in different environments

(home, work, leisure) as well as in different countries

(business travel, vacation). Existing ISO standards [1,2]

and certification protocols like the Common Criteria (CC)

[3] and CWA 14169 [4] do not yet facilitate such seam-

less use in a sufficiently secure setting.

A certified middleware that facilitates the usage of a

wide range of SCs for diverse applications could provide

a solution. Studying the security requirements for and

creating such a middleware is at the focus o f our ongoing

research and led us to develop the Crypto Probing Sys-

tem (CPS) with an integrated Murphi model checker

[5-7].

OpenSC [8] supports cryptographic operations which

are used in SC security operations according to the

PKCS#15 standard such as digital signature, the applica-

tion on which we concentrate here. The PKCS#15 stan-

dard is based on the Digital Certificates on SCs and Se-

cured Electronic Information in Society (SEIS) specifica-

tions for digital signature applications using SCs [9]. As

OpenSC is easy to use an d supports a wide rang e of SCs.

OpenSC could be an ideal component of a universal

middleware enabling SC interop erability. However, there

are several security aspects that need to be addressed in

order to ensure the secur ity o f such a middlewar e.

In an environment where several SCs are connected to

various applications via a middleware, an evident secu-

rity problem is that commands that are supposed to be

executed on a certain SC are in fact executed on a dif-

ferent one. Figure 1 illustrates this situation: SC applica-

tions give input to and receive an output from several

SCs sharing a common middleware. The middleware

translates the input into command sequences, i.e. into

Straight Line Programmes (SLP), which are supposed to

be executed on a corresponding SC. Dashed arrows indi-

cate the possibility that commands can interleave be-

tween the straight line programs. As a result a command

will be executed on a SC different from the intended on e.

M. TALAMO ET AL.

252

Figure 1. Middleware.

Such situations can arise inadvertently due to errors in

the middleware but also be due to an attack. From a se-

curity perspective such events are particularly problem-

atic if the SC executing a misdirected command does not

immediately return an error message. This problem has

been observed experimentally [10] and such a situation is

called an “anomaly”.

Any se cure mid dlewar e must ther efore be able to fully

address the issue of misdirected or interleaving com-

mands. There are several requirements that need to be

fulfilled:

 The type of a SC must be securely identified.

 Sensitive information must be communicated using

secure messaging (i.e. a protected channel between

the SC application and the SC must be built and sup-

ported by the middleware).

 Anomalies must be efficiently detected and computa-

tional chains with two or more anomalies must be

avoided [10].

The first problem of using OpenSC as part of a uni-

versal middleware is that the evaluation of a SC type is

based on the Answer to Reset (ATR) and the file struc-

ture of the SC (Figure 2). As different SCs types may

have the same ATR and file structure this method is not

reliable. Apart from interoperability problems that may

arise if a SC is actually of a different type than deter-

mined by OpenSC using the ATR, an attacker may engi-

neer a SC so that it is recognized as being of a certain

type (and serving a certain function) while it has been

designed for malicious purpo ses. In the following we will

not focus on this issue but we note that this problem

needs to be addressed in future work.

Figure 2. Evaluation of smartcard type in OpenSC.

The second problem of OpenSC is that the current

OpenSC libraries do not support secure messaging ope-

rations which are required in most digital signature ap-

plications to protect the sensitive data exchange between

software applications and the SC. In this work we extend

the OpenSC libraries to include the secure messaging

functionality (Sections 2 and 3). With this solution we

facilitate the integration of commercial ly av ailable d igital

signature SCs for example Postecert and Infocert into

OpenSC 0.12.0 (Section 4). However, even after a “state

of the art” integration of SM into OpenSC significant

problems regarding the protection of the channel between

SC applications and SCs persist as will be discussed in

Section 5.

2. Digital Signature Process

The digital signature process as implemented in OpenSC

0.12.0 provides a basic functionality in the iso7816.c

module for performing secure operation computing of a

digital signature. However, this functionality does not

support the secure messaging.

To meet the requirements of a complete digital signa-

ture process as implemented for example on the Incrypto

M. TALAMO ET AL. 253

chip based PosteCert and CNS (Carta Nazionale Servizi)

the digital signature process [11] involves the following

steps:

step 0

step 1

step 2

step 3

step 4

step 5

step 6

step 7

step 8

step 9

Reset the SC.

Change directory to the subdirectory containing

the digital sig nature certif icate which will be u se

(SELECT FILE command).

Activate the security environment for the digital

signature (MSE RESTORE command).

At file system level, choose the private key to be

used in the activ ated security environment (MSE

SET command).

Ask the SC for a random number to be used as a

challenge; the first step of activating SM (GET

CHALLENGE command).

Transmit a random number to the SC as a chal-

lenge; the second step of activating SM (GIVE

CHALLENGE command).

By using the two random numbers previously

exchanged and ciphering 3DES with the share

3DES key, transmit the PIN that is connected to

the private key used for the digital signature op-

eration (VERIFY PIN command). This closes

the first SM operation.

Ask the SC for the random number to be used as

(new) challenge; the first step of activating SM

(GET CHALLENGE command).

Transmit a random number to the SC as a chal-

lenge; the second step of activating SM (GIVE

CHALLENGE command).

By using the two random numbers previously

exchanged and ciphering 3DES with the share

3DES key, compute and send the input data

buffer which is ciphered using the selected pri-

vate key. Furthermore, receiving the result of the

digital signature operation (PSO CDS—Perfor

Security Operation Compute Digital Signature

command).

Extending the OpenSC capabilities to include the ad-

ditional steps for SM in the digital signature process re-

quired modifications of the pkcs15-tool.c module of

OpenSC 0.12.0 which will be detailed below. Integrating

the digital signature functions of the digital signature SC

into OpenSC also required to take the d ifferent file struc-

tures (e.g. different locations of PIN and PUK) into ac-

count.

3. Secure Messaging in OpenSC

Secure messaging (SM) is used to protect the exchange

of sensitive data (e.g. the user’s PIN) between the mid-

dleware and the SC. In digital signature processes SM is

therefore used to protect the data exchanged in connec-

tion with the VERIFY PIN and PSO CDS commands

(steps 6 and 9 of the digital signature process detailed).

[12] presents a first but incomplete step towards inte-

grating SM into OpenSC. While some of this work was

useful as a starting po int, achieving the SM functionality

required substantial modifications and extensions. As seen

in the steps of the digital signatu re process detailed in th e

previous section SM requires both the “Get Challenge”

and “Give Challenge” functions. However, OpenSC pro-

vides only the Get Challenge function so the Give Chal-

lenge command was added to the iso7816.c module and

registered in the sc_card_operations structure that con-

sists of all the required SC operation commands. Any

newly created SC command must be registered in this

structure (Figure 3).

Furthermore the SM main module sm.c and a corre-

sponding header file sm.h have been developed from

scratch. The header file sm.h consists of interface func-

tions used in the sm.c module. The sm.c module contains

all essential functions related to SM operations.

As in [12], we created a SM hook in order to link the

SM code into OpenSC. A sc_sm_context structure was se t

up in the header file opensc.h. Figure 4 shows how the

sc_sm_context structure is used in the sc_card structure in

order to be recognized by the SC. The sc_sm_context

Figure 3. Structure of the SC operations.

Figure 4. Secure messaging hook into OpenSC.

M. TALAMO ET AL.

254

structure contains the variable use_sm that will be used in

the apdu.c module as a flag for SM. If the SC requires

SM, this variable is flagged when the pkcs15-tool.c mod-

ule calls the digital signature process.

For the SM operation, the original APDU serves as an

input. The output of the SM operation is the encrypted

APDU which is sent to the SC. Th is involves the follow-

ing steps [ 1 3]:

step 1

step 2

step 3

step 4

step 5

step 6

step 7

Initialize the 24 bytes of SM key.

Set up and divide the SM key into three encryp-

tion and signature keys (8 bytes for each key)

according to the 3DES algorithm.

Obtain two random numbers as challenges (ge

and give challenge functions—8 bytes for each

random number).

Set up the header block for the APDU Command

using the 8 byte random number generate d by the

get challenge function (Figure 5(a)). The heade

lock also contains the mandatory header of the

APDU command: the Class Byte (CLA), the Ins-

truction Byte (INS) and two parameter bytes

(P1,P2). Since the length of an object must be an

integer multiple of 8 bytes, 4 byte padding is re-

quired.

Set up the Cipher Text Block (CTB) and the Ci-

pher Text Object (CTO) by encrypting the dat

field of the original APDU using the 3DES algo-

rithm. In the VERIFY PIN command, the dat

field contains the 8 byte PIN of the SC. In the

PSO CDS command, the data field contains the

input data (117 bytes) to be digitally signed. The

CTO structure is a TLV (Tag-Length-Value)

object containing a 1 byte Tag, a 1 byte Length

variable and a Value variable (encrypted dat

and padding, either 16 or 120 b ytes). Figure 5(b)

shows the CTO structure using the VERIFY PIN

(PSO CDS) commands as examples: the Value

contains 16 (120) bytes of encrypted data fro

the 8 byte PIN (117 byte input data) and 8 (3)

byte padding. Furthermore the CTB requires 5

yte padding to concatenate with the 19 (123)

byte CTO (Figure 5(c)).

Set up the Net Le Object (if required—Figure

5(d)). The Net Le object is used in MAC (Mes-

sage Authentication Code) Computation when

the original APDU does not have a data field. In

our experim e nt at i on, we d o n ot use thi s o bject.

Set up MAC Computation (using 3DES algo-

rithm), which requires a header block, the CTB

and optionally the Net Le Object and set up the

MAC object. Figure 5(e) shows the MAC Objec

structure: it is a TLV object containing a 1 byte

Tag (0 × 8E), 1 byte Length (0 × 08) and an 8

byte Value (as a result of MAC Computation).

step 8

step 9

Create the SM APDU Command including CTO,

MAC Object and the optional Net Le Object in

the data field (Figure 5(f)).

Send the SM APDU Command and wait for SM

APDU Response. SM APDU Response to the

Verify PIN command is only a Status Wor

(SW) without a data field while the response to

the PSO CDS command includes a data field as

well as the SW (Figure 5(g)). This SW is a re-

sponse code from the SC indicating whether o

not the APDU command has gene r ated an error .

These steps are coded in the do_single_transmit func-

tion of the apdu.c module. If SM is required, the

do_single_transmit function calls the applySM function

which is coded in the sm.c module. As shown in Figure

6, the applySM function supports the SM process from

setting up the header block until composing the APDU

Figure 5. Structure of the objects in the SM operation.

M. TALAMO ET AL. 255

Figure 6. Secure messaging implementation in OpenSC.

which is sent to the SC (steps 4 - 8). In particular the

applySM function implements padding, the 3DES en-

cryption algorithm, MAC signing and the challenge

functions.

4. Integrating Digital Signature Cards into

OpenSC

OpenSC 0.12.0 recognizes three SCs with digi tal signature

functionality which are approved in Italy [14]:

 The government issued official Italian electronic iden-

tity card (Carta Identita Elettronica—CIE).

 The digital signature card issued by the Italian Cham-

bers of Commerce (InfoCert) but without supporting

its digital signature functionality.

 The Carta Nazionale Servizi (CNS), which is avail-

able to citizens in some Italian regions.

In the previous section we have shown how the digital

signature functionality of these cards can be supported

via the introduction of SM. Here we show how other

digital signature SC can be integrated into OpenSC (in-

cluding their digital signature functionality) using the

example of the PosteCert card issued by the Italian Postal

Service (Posteitaliane).

First, a file called card-itaposte.c was created wh ich is

used to initialize the Postecert card and to call the Poste-

cert card driver (matching the ATR of the card). To rec-

ognize the driver, we add the Postecert card by defining

sc_card_type_itaposte_generic variable and declaring a

driver function sc_get_itaposte_driver in the file cards.h.

Finally the driver sc_get_itaposte_driver is registered in

file ctx.c which is used for context related functions.

In order to enable the digital sign ature functionality of

the PosteCert card, the required PKCS#15 functions are

provided in the pkcs15-itaposte.c module. All certificates,

private keys and the PIN are created and their locations

in the card’s file structure are coded in function sc_

pkcs15emu_itaposte_init. The pkcs15-itaposte.c module

is a modified version of the pkcs15-postecert.c [15] and

of the pkcs15-itacns.c [16] modules to match the current

file structure of the Postecert card. We also register the

function sc_pkcs15emu_itaposte_init_ex as built-in emu-

lators in the pkcs15-syn.c module.

Furthermore an itaposte.h module is created in order to

support the card-itaposte.c and pkcs15-itaposte.c mod-

ules. The itaposte.h module is derived from the itacns.h

module of the CNS card. The itaposte.h module contains

a structure called itaposte_drv_data_t, which consists of

the IC manufacturer code, mask manufaturer code, oper-

ating system version, card type and SM key. The process

of adding Postecert SC into OpenSC is shown in Figures

7 and 8.

Finally, the newly added and modified files are com-

piled together with the unchanged OpenSC files. To do

that, the itaposte.h, card-itaposte.c, pkcs15-itaposte.c,

sm.h and sm.c modules are registered in Makefile.am,

and card-itaposte.obj and pkcs15-itaposte.obj are regis-

tered in Makefile.mak.

Other digital signature SCs [17] can be integrated into

OpenSC analogously with minimal changes such as ad-

justing for different ATR and file structu res.

5. Experimentation and Results

In this section we provide an overview of the digital sig-

nature process as we have implemented it in OpenSC.

Figure 9 shows the modules which are used in the digital

signature process for a certain SC. OpenSC requires the

following modules:

 pkcs15-tool.c module. This module is used to initial-

ize the digital signature process. After calling this

module, the digital signature process function is cho-

sen according to the SC used. The digital signature

M. TALAMO ET AL.

256

Figure 7. Adding postecert SC into OpenSC (1).

process function consists of all sequential required

steps for the digital signature.

 iso7816.c module. This module contains ISO 7816

standard functions which are used in the digital sig-

nature process (Secti on 2).

Figure 8. Adding postecert SC into OpenSC (2).

Figure 9. Digital signature process in Ope nSC.

 sm.c module. This module is used to perform the SM

operation.

 apdu.c module. This module is used to send the

APDU Commands to and receive the APDU Re-

sponses from the SCs.

In our experimentation the data to be signed (string of

117 bytes) are provided to the middleware as a file (in-

put.c).

While we have implemented “state of the art” secure

messaging we note that the security provided by the SM

functionality is li mited. First, the SM key used to en crypt

the input plaintext is generally the same for all SCs of a

given type and therefore this key is essentially publicly

known and therefore offers questionable protection. Sec-

ond, the random numbers exchanged in connection with

the Get and Give challenge commands are sent in clear

between the middleware and SCs. An attacker who is

M. TALAMO ET AL.

257

able to sniff the exchanged random numbers and who has

knowledge of the SC specific SM key can then easily

decrypt the exchanged messages and/or inject his own

commands into the “secured process”.

In Table 1 we summarize the complete digital signa-

ture process in terms of the exchanged APDU commands

and responses for a digital signature SC using the In-

crypto microprocessor. In the Verify (PSO CDS) com-

mand the PIN (Input data) are encoded in the byte se-

quences [09 0F...91 AE] ([5B 5E...3E F0]) and the last 8

bytes of the input data are the result of the MAC compu-

tation. Bytes [D6 E4...C1 DA] of the output data contain

the digitally signed input data. For each APDU command,

the microprocessor replies with an APDU response that

consists of optional response data and a 2 byte of Status

Word (SW). The SW [90 00] indicates that the APDU

command has been processed by the microprocessor

without error.

Table 1. APDU command and APDU response for Incrypto CNS and postecert card (hexadecimal representation).

APDU command APDU response

Command CLA INS P1 P2 Lc Data in CNS (postecert) LeResponse data SW

Select file 00 A4 08 00 04 (02) 14 00 81 10 (81 10)

This indicates the certificate location of the SCs. FF

6F 34 81 02 00 00 83 02 81 10 86 0A

FF FF FF FF FF FF FF FF FF FF 8A 01

05 8B 18 FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF 82 01 38

This indicates file control parameters

that consist of a Tag [6F], a Length

variable [34] and a Value variable [81

02... 01 38]

90 00

MSE restore 00 22 F3 03 00 - -- 90 00

MSE set 00 22 F1 B6 03 83 01 10 -- 90 00

Get challenge 00 84 00 00 00 - 088 bytes random number 90 00

Give challenge 80 86 00 00 08 8 bytes random number -- 90 00

Verify 0C 20 00 9A 1D

87 11 01 09 0F 0C EC CC 81 FB 9 1 F2 3A 45 96 7 E

46 91 AE 8E 08 67 1E 69 C0 FA 33 B D 26

[87 11... 91 AE] is a TLV object of CTO structure

which consists of a Tag [87], a Le ngth variable [11]

and a Value variable [01 09... 91 AE] that contains

adding [01] and encoded PIN [09 0F... 91 AE]

[8E 08... BD 26] is a TLV object of MAC object

structure which consists of a Tag [87], a Length

variable [08]

and a Value variable [67 1E... BD 26] that indicates

result of MAC Computation

(see Figures 5(b), (e), (f))

00- 90 00

Get challenge 00 84 00 00 00 - 088 bytes random number 90 00

Give challenge 80 86 00 00 08 8 bytes Random Number -- 90 00

PSO_CDS 0C 2A 9E 9A 85

87 79 01 5B 5E 97 05 BD 43 96 B1 F A 8 A 5B E5 C1

BC 2A 24 23 ED 5D 51 D4 DA D4 D5 AC F8 70 96

83 75 F7 38 41 00 0F 88 D1 A6 B 3 7 C F0 6 C 1C 4 1

86 2A 05 1D 52 6B 2B 15 B9 FD AC ED 25 12 AC

C0 2A C3 1C 7F 92 65 10 1D 89 52 5D A6 F1 F5 81

CE 6A 0C AE 3A F4 62 C4 ED BC 0E 89 27 1 D 2 5

01 D7 18 5C E1 06 B1 E9 5A 7B 91 E 6 D 5 5F 47 7 2

B8 68 C0 B3 B1 50 17 58 BD A6 F 5 A 7 3 E F0 8E

08 EC 51 AA 8D 9F AA 1A 3A

[87 79... 3E F0] is a TLV object of CTO structure

which consists of a Tag [87], a Le ngth variable [79]

and a Value variable [01 5B... 3E F0] that contains

adding [01] and encoded Input [5B 5E... 3E F0]

[8E 08... 1A 3A] is a TLV object of MAC object

structure which consists of a Tag [8E], a Length

variable [08] and a Value variable [EC 51... 1A 3A]

that indicates result of MAC Compu tation

(see Figures 5(b), (e), (f))

87 89 01 D6 E4 88 36 FE A7 AC F6 D7

46 4D E4 61 F2 E6 E2 4E 3D 04 F8 8B

00 DD B9 90 DD A0 0A D2 93 E5 91

46 C1 26 D1 32 BE 1E EC 03 FB FC

3C 12 FC 9F 16 6F 1A E6 E9 CD CA

42 72 CF 88 9A A5 7E 2D 4F F0 6D

EC 11 AC 63 9B 2A 47 70 70 A6 81 59

8C 87 62 5B 45 8F 0A B8 35 23 BC 67

F4 AD 60 AC 73 19 7E C7 94 A2 29 78

45 E8 4A E7 D5 F2 68 68 32 52 BD BB

1C 14 EB 0F E5 9F E3 4C 63 0E E9 D9

7A EC 1D A1 C4 11 1F 13 34 C1 DA

8E 08 42 A9 5C 97 FE B9 0 7 F D

[87 89... C1 DA] is a TLV object of

CTO structure which consists of a Ta g

[87], a Length variable [89] and a Value

variable [01 D6... C1 DA] that contains

adding [01] and encoded Output [D6

E4... C1 DA]

[8E 08... 07 FD] is a TLV object of

MAC object structure which consists of

a Tag [8E], a Length variable [08] and a

Value variable [42 A9... 07 FD] that

indicates result of MAC Computation

(see Figure 5(g))

90 00

M. TALAMO ET AL.

258

6. Conclusion and Outlook

We have extended OpenSC 0.12.0 to include secure

messaging so that the digital signature functionality of

SCs can be supported in OpenSC. This will enable us to

run extensive test on the interoperability of a wide class

of digital signature SCs which are connected with their

software applications via a single middleware [7]. We

have identified several important security issues that

must be addressed in future work. Part of this effort will

include combining the OpenSC middleware with a model

checker as a “watch-dog” to identify and prevent anoma-

lies. The ultimate goal is to certify the secure in teropera-

bility of all SCs integrated into such an environment.

7. Acknowledgements

This project has been supported in part by MIUR under

contract PRIN 2008ZE493H.

REFERENCES

[1] International Organization for Sta ndardization (I SO) “Iden-

tification Cards—Integrated Circuit Cards Part 4: Or-

ganization, Security and Commands for Interchange,” In-

ternational Organization for Standardization Std., Geneva,

2005.

[2] International Organization for Sta ndardization (I SO) “Iden-

tification Cards—Integrated Circuit Cards Programming

Interfaces—Part 3: Application Programming Interface,”

International Organization for Standardization Std., Ge-

neva, 2008.

[3] The Common Criteria, “Common Criteria for Information

Technology Security Evaluation,” Common Criteria Std.,

2009. http://www.commoncriteriaportal.org/cc/

[4] The European Committee for Standardization (CEN),

“Secure Signature-Creation Devices ‘EAL 4+’,” Euro-

pean Committee for Standardization (CEN) Std., Brussels,

2004.

[5] M. Talamo, et al., “Robustness and Interoperability Pro-

blems in Security Devices,” Proceedings of 4th Interna-

tional Conferences on Information Security and Cryptol-

ogy, Beijing, 14-17 December 2008.

[6] M. Talamo, et al., “Verifying Extended Criteria for In-

teroperability of Security Devices,” Proceedings of 3rd

International Symposium on Information Security, Mon-

terrey, 10-11 November 2008, pp. 1131-1139.

[7] M. Talamo, M. Galinium, C. H. Schunck and F. Arcieri,

“Interleaving Command Sequences: A Thread to Secure

Smartcard Interoperability,” Proceedings of the 10th In-

ternational Conference on Information Security and Pri-

vacy, Jakarta, 1-3 December 2011, pp. 102-107.

[8] OpenSC, “OpenSC Tools and Libraries for Smartcard,”

2001. http://www.opensc-project.org/opensc

[9] W. Rankl and W. Effing, “Smart Card Handbook,” 4th

Edition, Wiley, West Sussex, 2010.

doi:10.1002/9780470660911

[10] M. Talamo, M. Galinium, C. H. Schunck and F. Arcieri,

“Interleaving Commands: A Threat to the Interoperability

of Smartcard Based Security Applications,” International

Journal of Computer and Communication, Vol. 6, No. 1,

2012, pp. 76-83.

[11] M. Talamo, M. Galinium, C. H. Schunck and F. Arcieri,

“Integrating Secure Messaging into OpenSC,” Proceed-

ings of the 2nd International Conference on Computer

and Management, Wuhan, 9-11 March 2012, pp. 1222-

1227.

[12] E. Pucciarelli, “Implementation of Secure Messaging,”

2008.

http://www.mail-archive.com/[email protected]

project.org/msg03034.html

[13] A. Villani, “Incrypto34v2 User and Administrator Guid-

ance,” ST. Incard, Marcianese, 2004.

[14] OpenSC. “Supported Hardware (Smart Cards and Usb

tokens),” 2011.

http://www.opensc-project.org/opensc/wiki/SupportedHar

dware

[15] O. Kirch and A. Iacono, “pkcs15-Postecert.c,” 2004.

http://www.opensc-project.org/opensc/browser/OpenSC/s

rc/libopensc/pkcs15-postecert.c

[16] E. Pucciarelli, “pkcs15-Itacns.c,” 2008.

http://www.opensc-project.org/opensc/browser/OpenSC/s

rc/libopensc/pkcs15-itacns.c

[17] Agencia per L’Italia Digitale, “Certificatori Firma Digi-

tale. Ente Nazionale per la Digitalizzazione della Pubblica

Amministrazione,” 2011.

http://www.digitpa.gov.it/certificatori_firma_digitale