Secure Messaging Implementation in OpenSC

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 manufacturers 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, secure and convenient smartcard interoperability has 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 underlying interoperability 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 significant 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 exchange between the SC and the middleware, we address one important security weakness. This enables the integration of digital signature functionality into the OpenSC environment.


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 based online authentication 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 seamless 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 of our ongoing research and led us to develop the Crypto Probing System (CPS) with an integrated Murphi model checker [5][6][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 standard is based on the Digital Certificates on SCs and Secured Electronic Information in Society (SEIS) specifications for digital signature applications using SCs [9].As OpenSC is easy to use and supports a wide range of SCs.OpenSC could be an ideal component of a universal middleware enabling SC interoperability.However, there are several security aspects that need to be addressed in order to ensure the security of such a middleware.
In an environment where several SCs are connected to various applications via a middleware, an evident security problem is that commands that are supposed to be executed on a certain SC are in fact executed on a different one.Figure 1 illustrates this situation: SC applications 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 indicate the possibility that commands can interleave between the straight line programs.As a result a command will be executed on a SC different from the intended one.Such situations can arise inadvertently due to errors in the middleware but also be due to an attack.From a security perspective such events are particularly problematic 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 secure middleware must therefore be able to fully address the issue of misdirected or interleaving commands.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 supported by the middleware). Anomalies must be efficiently detected and computational chains with two or more anomalies must be avoided [10].The first problem of using OpenSC as part of a universal middleware is that the evaluation of a SC type is based on the Answer to Reset (ATR) and the file structure 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 determined by OpenSC using the ATR, an attacker may engineer 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 purposes.In the following we will not focus on this issue but we note that this problem needs to be addressed in future work.The second problem of OpenSC is that the current OpenSC libraries do not support secure messaging operations which are required in most digital signature applications 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 commercially available digital 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.

Digital Signature Process
The digital signature process as implemented in OpenSC 0.12.0 provides a basic functionality in the iso7816.cmodule 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 signature process as implemented for example on the Incrypto chip based PosteCert and CNS (Carta Nazionale Servizi) the digital signature process [11]  Reset the SC.Change directory to the subdirectory containing the digital signature certificate which will be used (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 activated 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 challenge; the second step of activating SM (GIVE CHALLENGE command).By using the two random numbers previously exchanged and ciphering 3DES with the shared 3DES key, transmit the PIN that is connected to the private key used for the digital signature operation (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 challenge; the second step of activating SM (GIVE CHALLENGE command).By using the two random numbers previously exchanged and ciphering 3DES with the shared 3DES key, compute and send the input data buffer which is ciphered using the selected private key.Furthermore, receiving the result of the digital signature operation (PSO CDS-Perform Security Operation Compute Digital Signature command).Extending the OpenSC capabilities to include the additional steps for SM in the digital signature process required modifications of the pkcs15-tool.cmodule 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 different file structures (e.g.different locations of PIN and PUK) into account.

Secure Messaging in OpenSC
Secure messaging (SM) is used to protect the exchange of sensitive data (e.g. the user's PIN) between the middleware and the SC.In digital signature processes SM is therefore used to protect the data exchanged in connection 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 integrating SM into OpenSC.While some of this work was useful as a starting point, achieving the SM functionality required substantial modifications and extensions.As seen in the steps of the digital signature process detailed in the previous section SM requires both the "Get Challenge" and "Give Challenge" functions.However, OpenSC provides only the Get Challenge function so the Give Challenge command was added to the iso7816.cmodule and registered in the sc_card_operations structure that consists 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 corresponding header file sm.h have been developed from scratch.The header file sm.h consists of interface functions 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 set 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  structure contains the variable use_sm that will be used in the apdu.cmodule as a flag for SM.If the SC requires SM, this variable is flagged when the pkcs15-tool.cmodule 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.This involves the following steps [13]:    which is sent to the SC (steps 4 -8).In particular the applySM function implements padding, the 3DES encryption algorithm, MAC signing and the challenge functions.

Integrating Digital Signature Cards into OpenSC
OpenSC 0.12.0 recognizes three SCs with digital signature functionality which are approved in Italy [14]:  The government issued official Italian electronic identity card (Carta Identita Elettronica-CIE). The digital signature card issued by the Italian Chambers of Commerce (InfoCert) but without supporting its digital signature functionality. The Carta Nazionale Servizi (CNS), which is available 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 (including 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 which is used to initialize the Postecert card and to call the Postecert card driver (matching the ATR of the card).To recognize 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 signature functionality of the PosteCert card, the required PKCS#15 functions are provided in the pkcs15-itaposte.cmodule.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.cmodule 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 emulators in the pkcs15-syn.cmodule.
Furthermore an itaposte.hmodule is created in order to support the card-itaposte.c and pkcs15-itaposte.cmodules.The itaposte.hmodule is derived from the itacns.hmodule of the CNS card.The itaposte.hmodule contains a structure called itaposte_drv_data_t, which consists of the IC manufacturer code, mask manufaturer code, operating 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 compiled 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.objare registered in Makefile.mak.
Other digital signature SCs [17] can be integrated into OpenSC analogously with minimal changes such as adjusting for different ATR and file structures.

Experimentation and Results
In this section we provide an overview of the digital signature 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.cmodule.This module is used to initialize the digital signature process.After calling this module, the digital signature process function is chosen according to the SC used.The digital signature process function consists of all sequential required steps for the digital signature. iso7816.cmodule.This module contains ISO 7816 standard functions which are used in the digital signature process (Section 2). sm.c module.This module is used to perform the SM operation. apdu.cmodule.This module is used to send the APDU Commands to and receive the APDU Responses from the SCs.In our experimentation the data to be signed (string of 117 bytes) are provided to the middleware as a file (input.c).
While we have implemented "state of the art" secure messaging we note that the security provided by the SM functionality is limited.First, the SM key used to encrypt 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.Second, 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 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 signature process in terms of the exchanged APDU commands and responses for a digital signature SC using the Incrypto microprocessor.In the Verify (PSO CDS) command 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 computation.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.

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 anomalies.The ultimate goal is to certify the secure interoperability of all SCs integrated into such an environment.

Figure 2 .
Figure 2. Evaluation of smartcard type in OpenSC.

Figure 3 .
Figure 3. Structure of the SC operations.
bytes of SM key.Set up and divide the SM key into three encryption and signature keys (8 bytes for each key) according to the 3DES algorithm.Obtain two random numbers as challenges (get 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 generated by the get challenge function (Figure5(a)).The header block also contains the mandatory header of the APDU command: the Class Byte (CLA), the Instruction 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 required.Set up the Cipher Text Block (CTB) and the Cipher Text Object (CTO) by encrypting the data field of the original APDU using the 3DES algorithm.In the VERIFY PIN command, the data 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 data and padding, either 16 or 120 bytes).

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 from the 8 byte PIN (117 byte input data) and 8 (3) byte padding.Furthermore the CTB requires 5 byte padding to concatenate with the 19 (123) byte CTO (Figure 5(c)).Set up the Net Le Object (if required-Figure5(d)).The Net Le object is used in MAC (Message Authentication Code) Computation when the original APDU does not have a data field.In our experimentation, we do not use this object.Set up MAC Computation (using 3DES algorithm), which requires a header block, the CTB and optionally the Net Le Object and set up the MAC object.

Figure 5 ( 8 step 9 Figure 5 .
Figure 5. Structure of the objects in the SM operation.