Journal of Information Security, 2012, 3, 251-258 Published Online October 2012 (
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
Received July 15, 2012; revised August 27, 2012; accepted September 8, 2012
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
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.
opyright © 2012 SciRes. JIS
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
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
Copyright © 2012 SciRes. JIS
chip based PosteCert and CNS (Carta Nazionale Servizi)
the digital signature process [11] involves the following
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
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-
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.
Copyright © 2012 SciRes. JIS
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-
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.
Copyright © 2012 SciRes. JIS
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
4. Integrating Digital Signature Cards into
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,
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
Copyright © 2012 SciRes. JIS
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
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-
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
Copyright © 2012 SciRes. JIS
Copyright © 2012 SciRes. JIS
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 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
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.
[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,
[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.,
[4] The European Committee for Standardization (CEN),
“Secure Signature-Creation Devices ‘EAL 4+’,” Euro-
pean Committee for Standardization (CEN) Std., Brussels,
[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,”
[9] W. Rankl and W. Effing, “Smart Card Handbook,” 4th
Edition, Wiley, West Sussex, 2010.
[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-
[12] E. Pucciarelli, “Implementation of Secure Messaging,”
[13] A. Villani, “Incrypto34v2 User and Administrator Guid-
ance,” ST. Incard, Marcianese, 2004.
[14] OpenSC. “Supported Hardware (Smart Cards and Usb
tokens),” 2011.
[15] O. Kirch and A. Iacono, “pkcs15-Postecert.c,” 2004.
[16] E. Pucciarelli, “pkcs15-Itacns.c,” 2008.
[17] Agencia per L’Italia Digitale, “Certificatori Firma Digi-
tale. Ente Nazionale per la Digitalizzazione della Pubblica
Amministrazione,” 2011.
Copyright © 2012 SciRes. JIS