TIWIS 2003, Tunis, Tunisia
A protocol for simulating Match-on-Card authentication through the use of Template-on-Card technology Luca Bechelli (*), Stefano Bistarelli (*,#) and Stefano Frassi (*) (*)
Istituto di Informatica e Telematica, C.N.R. Pisa, Italy E-mail: {Luca.bechelli,Stefano.Bistarelli,Stefano.Frassi}@iit.cnr.it (#) Dipartimento di Scienze, Università degli studi di Chieti-Pescara, Italy E-mail:
[email protected]
ABSTRACT A protocol is proposed to address the problem of user authentication to smartcards using devices that are currently inexpensive. The protocol emulates expensive Match On Card (MOC) smartcards, which can compute a biometric match, by cheap Template on Card (TOC) smartcards, which only store a biometric template. The actual match is delegated to an extension of the cryptographic module running on the card host, which is called Cryptoki according to the PKCS#11 standard [8]. Compliance to such a standard increases the portability of the protocol. KEYWORDS: Smartcard, biometry, authentication. OVERVIEW Smartcards are currently used as a secure and tamper-proof device to store sensitive information such as digital certificates and private keys. Access to smartcards has historically been regulated by a trivial means of authentication: the Personal Identification Number (PIN). A user gains access to a card if he enters the right PIN. Experience shows that PINs are weak secrets [4] in the sense that they are often poorly chosen, and that they are easy to loose. Moreover, many actual implementation that use the PIN, consider the channel between host and smartcard secure. So, they simply send the PIN in a clear communication. This implies many easy attacks [4]. A simple Trojan on the host could easily sniff the PIN and store it for future usage. (We checked four different brand of cryptographic smartcards using each his Cryptoki implementation and we was able to capture the PIN of all of them.) Biometric technologies have been proposed to strengthen authentication mechanisms in general by matching a stored biometric template to a live biometric template [1, 2, 3]. In the case of authentication to smartcards, intuition imposes the match to be performed by the smartcard. But this is not always possible because of the complexity of biometric information such as fingerprints or iris scans, and because of the yet limited computational resources offered by currently available smartcards. In general, three strategies of biometric authentication can be identified. Template on Card (TOC). The biometric template is stored on a hardware security module (smartcard or USB token). It must be retrieved and transmitted to a different system that 28
TIWIS 2003, Tunis, Tunisia matches it to the live template acquired by special scanners from the user. Cheap memory cards with no or small operating systems and onboard applications are generally sufficient for this purpose. Match on Card (MOC). The biometric template is stored on a hardware security module, which also performs the matching with the live template. Therefore, a microprocessor smartcard is necessary, which must be endowed with an operating system running suitable match applications. System on Card (SOC). This is a combination of the previous two technologies. The biometric template is stored on a hardware security module, which also performs the matching with the live template, and hosts the biometric scanner to acquire, select, and process the live template. Our research aims at the development of a viable and easy-to-deploy protocol to allow secure authentication of users to smartcards, enforced by biometric matching. Clearly, if we could cast a spell, we would choose the third of the strategies sketched above. Indeed SOC cards appear to be the best in terms of security, as everything takes place on card. Unfortunately, the existence of SOC cards is still confined to research laboratories at present [5, 9]. The benefits deriving from MOC cards are valuable themselves, although these cards must be still considered rare and expensive. Reasonably cheap microprocessor cards do come with a cryptographic processor, which unfortunately is too specialised to perform biometric matches. Going down the hierarchy of prices, we find that TOC cards are obviously inadequate. In the present setting, how can we implement biometric authentication on smartcards that are commercially available? We address this issue by developing a novel protocol that employs inexpensive TOC cards as if they were MOC cards. The actual match is carried out by a module added to the Cryptoki application running on the card host according to the PKCS#11 standard defined by RSA laboratories [8]. In principle, if we trust the Cryptoki module, then we should protect the extra exchange that we expect is necessary to transmit the stored template from the card to the Cryptoki. By doing so, the resulting protocol should not be more vulnerable than the corresponding protocol for MOC cards. The presentation of the protocol messages may reveal possible optimizations. The current design is imposed by the restricted set of functions that we want to implement in the Applet we need to load on the smartcard. After a brief introduction to PKCS#11 Cryptoki, this paper describes our protocol, sketches its practical implementation, and concludes. PKCS#11: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD The PKCS#11 standard specifies an API, called “Cryptoki” (cryptographic token interface), to devices that hold cryptographic information and perform cryptographic functions [8]. Cryptoki follows a simple object based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a “cryptographic token”. The primary goal of Cryptoki is a lower level programming interface that abstracts the details of the devices, and presents to the application a common model of the cryptographic device, called a cryptographic token (or simply token). Cryptoki's general model is illustrated in Figure 1. The model begins with one or more applications that need to perform certain cryptographic operations, and ends with one or more cryptographic devices, on which some or all of the operations are actually performed. A user may or may not be associated with an application. 29
TIWIS 2003, Tunis, Tunisia
Figure 1: A general Cryptoki model Usually, a cryptographic device can perform some cryptographic operations, following a certain command set. For example, a smartcard can generate a nonce, but in practice cannot perform any operation by itself. To have the smartcard generate a nonce, the application should invoke function C_GenerateRandom(...) of the Cryptoki library. Figure 2 represents such interactions.
Figure 2: The request-answer PKCS#11 model To let the smartcard able to interact by itself and follow the protocol rule, we used a JavaCard compliant smartcard and we load a small Applet responsible to run the protocol with the Cryptoki. (See Implementation Section) The most important operation that is requested using the PKCS#11 interface is the Login request. Following PKCS#11 standard, we implement a biometric login starting the protocol when a login(NULL) request is performed from the application.
30
TIWIS 2003, Tunis, Tunisia SIMULATING MOC USING TOC This section presents the protocol. It illustrates the interactions among the Cryptoki (that is also in charge of the communication with the biometric scanner) ad a PKCS#11 compliant smartcard. A schematic representation can be defined as in Figure 3 and 4. In short, when the application sends the login(NULL) request to the Cryptoki, it starts the protocol with the smartcard, by asking for a nonce. This will be used for a challenge-response phase to authenticate the Cryptoki to the smartcard (messages 1 and 2). In message 3, the Cryptoki receives the symmetric session key used to encrypt all the subsequent messages. In message 4, the Cryptoki transmits the justacquired live template to the card. The live template is sent encrypted with a session key to ensure user privacy. In message 5, the Cryptoki receives the attribute certificate containing the enrolment template and performs the biometric match. If this is successful than Cryptoki sends the hashed live template to the card, which computes the hash on the template received at step 4. If the match between the two hashes is OK then the user is authenticated. A fuller description is given below.
Nonce
Nsc
1. Cryptoki SC: Nsc
Private Key Cryptoki
Kso-1
2. Cryptoki SC: SIGNKso-1(Nsc)
Public Key Cryptoki
Kso
3. Cryptoki SC: asyCRYPTKso (Ksc-app)
Session Key
Ksc-app
4. Cryptoki SC: symCRYPTKsc-app (RTT)
Real Time Template
RTT
5. Cryptoki SC: symCRYPTKsc-app (AT)
Attribute Certificate
AT
6. Cryptoki SC: symCRYPTKsc-app (HASH(RTT)) Enrolled Template Figure 3: Data exchange between Cryptoki and Smartcard
31
ENT
TIWIS 2003, Tunis, Tunisia HOST Login
User Application
Template
Biometric Device Driver
6
5
4
3
2
1
Cryptoki
Smartcard Reader
Biometric Scanner
Smartcard
Figure 4: Data exchange between entities
DETAILED MOC-USING-TOC PROTOCOL User’s application (PKCS#11 compliant) requires the access to the smartcard through the Cryptoki module The user application asks for a login to Cryptoki specifying a NULL pin. This operation is carried out by calling C_Login(NULL) in order to authenticate the user through biometric fingerprint instead of PIN as specified in the PKCS#11 standard [8]. In this phase, a challenge-response authentication between smartcard and Cryptoki takes place. The smartcard issues a fresh nonce and the Cryptoki returns it. Cryptoki asks the smartcard to generate a pseudorandom number Nsc to start the challenge/response protocol The generated number is kept in a session object. It will be used in the next step of the protocol. Cryptoki signs the challenge Nsc and sends it back to the smartcard Cryptoki generates a hash of the challenge Nsc and encrypts it with its private key Kso-1 (the public key Kso is contained in its certificate). Then, it sends the signature of the challenge Nsc to the smartcard. The smartcard verifies the signature of the challenge Nsc The smartcard computes the hash of the challenge Nsc (the session object) using the same algorithm as Cryptoki did in the previous step. On the other hand, it decrypts the received 32
TIWIS 2003, Tunis, Tunisia signature using the public key Kso that it retrieves from the Cryptoki’s certificate (stored on board) and obtains a second hash. Access is granted to Cryptoki only if the two hashes match, otherwise the Login phase in rejected. We can assume that the Cryptoki public key is already available to the smart card, otherwise the Cryptoki should send also the appropriate digital certificate. Now Cryptoki is authenticated. Cryptoki asks for a Session Key Ksc-app to smartcard During this phase, a session key Ksc-app (that will be used to encipher confidential data transmitted between the smartcard and Cryptoki) is generated on board. Then it is encrypted with the public key Kso stored inside the digital certificate and sent to Cryptoki. Cryptoki acquires the fingerprint Template RTT from the scanner This operation is performed through the use of the library made available by the producer of the biometric scanner. A live and trusted template is generated. The idea is to accept biometric template only if coming from a trusted device and only if acquired during the current authentication session. Cryptoki enciphers the template RTT of the acquired fingerprint with the session key Ksc-app and stores it in the smartcard as a temporary data object The next step is to create a message representing the biometric information of the user. The session key sent to the Cryptoki from the smartcard will be useful for encrypting the biometric template. This is not for confidentiality reasons, but only for privacy. In fact, the user may want to secure his biometric information from eavesdroppers for a number of reasons (for example, the fingerprint could reveal certain diseases). Cryptoki encrypts the acquired template RTT with the session key Ksc-app and sends it to the smartcard. Then, the smartcard generates a hash of the acquired template RTT, that was previously decrypted with the symmetric session key Ksc-app, and store it as a session object. Cryptoki request from smartcard the Attribute Certificate AT The routine that implements this operation, reads the original attribute certificate AT with inside the template ENT, located in the PKCS#11 file system, encrypt it with the session key Ksc-app and sends it to Cryptoki. Cryptoki could verify if the attribute certificate has been enrolled from a trusted Authority. Cryptoki carries out the match between live fingerprint RTT and the old template ENT Cryptoki then extracts the enrolment Template ENT from the Attribute Certificate AT. Cryptoki checks if the original fingerprint template ENT stored during the enrolment phase matches with the acquired fingerprint template RTT. Notice that this operation relies on the matching function of the biometric scanner provider. If the match is successful, Cryptoki asks for a login for the user by sending the hash of the acquired fingerprint RTT encoded with the session key Ksc-app The smartcard answers confirm the opening of the authenticated session with the user if the match (hash received and decoded, hash generated from the memorization of the template RTT at a previous step) is positive. Last phase: Successful login If the smartcard generate the last message, means that a successful biometric match has been performed and the login is successful. Cryptoki confirms to the user application the success of the login and grants access to the smartcard. 33
TIWIS 2003, Tunis, Tunisia IMPLEMENTATION The above protocol provides a detailed specify of the interactions between user application and the device management sub-systems (smartcard and biometric scanner). Next section illustrates the technological solution adopted. Three aspects are prevalent in the investigation that must be made to determine the most suitable solution: 1. The protocol needs the modification of smartcard operation because this expects a larger number of functions in comparison with the standard implemented functions. 2. The protocol should be used with the larger number of smartcard available on the market, and these should be usable with the traditional authentication methods (PIN) and with the Cryptoki given by the vendor. 3. The protocol expects that smartcard should be accessible from user applications through a Cryptoki PKCS#11. The added code installed on the smartcard does not should prevent the use of other applications, nor replace the authentication/access primitives. To support the new authentication methods, the Cryptoki have to be supplied with some new functions or with some modifications over the existing ones. ARCHITECTURE OF THE SOLUTION In order to have the possibility to port our solution over a big number of smartcard and operating systems, we develop the protocol on the Hardware Security Module (HSM) according to the JavaCard standard [6]. JavaCard is a widely adopted technology to develop application that must run into a smartcard using the Java language. JavaCard technology has been developed from SUN and a consortium of companies that are involved in the development of chip, applications and operating systems for HSM with the objective to apply the advantages of Java technology inside smartcard’s world. The principal feature of the JavaCard specifications is the presence, on board of the smartcard, of a virtual machine, which interprets and executes bytecode generated from the compilation of Java source code. The language is, consequently, Object Oriented, and has the mechanisms of standard Java, like inheritance, abstraction and encapsulation. Every application for smartcard, called “Applet”, can be executed on any JavaCard compliant smartcard, without the need to be recompiled. In this way, once realized the Applet that implement our protocol, this can be installed and executed into any JavaCard. On the end user machine, must be realized a PKCS#11 compliant Cryptoki able to open a connection with the Applet and to send the opportune commands invoked by the end user application. To develop a solution as platform and vendor independent as possible, we have adopted an Open Source framework ( MUSCLECard [7]). MUSCLE (Movement for the Use of Smartcard in a Linux Environment) is a project that has as objective the realization of a framework to allow the use of cryptographic smartcards on Open Source operating systems, for which the vendors of HSM generally don’t release some support. For this reason, MUSCLECard has realized an Open Source Cryptoki able to communicate with a JavaCard Applet (released under the same license). The framework is currently available for several operating systems (MS Windows, Linux, MacOSX and *BSD). 34
TIWIS 2003, Tunis, Tunisia The final schema is presented in Figure 5. HOST
User Application PKCS11 standard calls
Biometric Device Driver
MUSCLE Cryptoki
PKCS11 standard calls + Biometric authentication
Smartcard Reader
Biometric Scanner
Smartcard Applet implementing PKCS11 commands + MOC-TOC protocol
Figure 5: Schema of the implemented solution ACKNOWLEDGEMENTS The results presented in the paper are part of the IIT-CNR and NDCA collaboration Project. We would like to thank the NDCA team (in particular Mohamed Hamdi and Arbia Riahi) that worked jointly with us despite the distance and Anna Vaccarelli from the IIT-CNR team for all the support. CONCLUSIONS Modern, inexpensive TOC smartcards cannot compute a biometric match as MOC smartcards. We have developed a protocol, which simulates the MOC strategy through the use of TOC cards. In practice, the actual match is delegated to the Cryptoki module of the card host. The computational burden that the protocol puts on the smartcards is not heavy. Our protocol achieves the goal of authenticating a user to a smartcard by means of the user's biometric information, although the smartcard does not perform the match. The design we have presented has been fully implemented using the MUSCLE framework, which provides an Open Source PKCS#11 Cryptoki, and by a JavaCard compatible smartcard, which has been used to implement the smartcard-side protocol.
35
TIWIS 2003, Tunis, Tunisia RELATED WORK Some of the results presented in this paper are someway related to [10]. REFERENCES 1. L. Bechelli, S. Bistarelli, F. Martinelli, M. Petrocchi, and A. Vaccarelli. Integrating biometric techniques with electronic signature for remote authentication. ERCIM News, (49), 2002. 2. L. Bechelli, S. Bistarelli, and A. Vaccarelli. Biometrics authentication with smartcard. Technical Report 08-2002, CNR, Istituto di Informatica e Telematica, Pisa, 2002. 3. L. Bechelli, S. Bistarelli, and A. Vaccarelli. Certificati per impronte digitali memorizzati su smartcard. Technical Report 09-2002, CNR, Istituto di Informatica e Telematica, Pisa, 2002. In Italian. 4. Mike Bond and Piotr Zielinski. Decimalisation table attacks for pin cracking. Technical Report UCAM-CL-TR-560, University of Cambridge, Computer Laboratory, feb 2003. 5. N. J. Henderson and P. H. Hartel. Pressure sequence - a novel method of protecting smart cards. In J. Domingo-Ferrer, D. Chan, and A. Watson, editors, Proceedings 4th Int. IFIP wg 8.8 Conf. Smart card research and advanced application (CARDIS), Bristol, UK, pages 241--256. Kluwer, 2000. 6. Java Card Technology, http://java.sun.com/products/javacard/ 7. MUSCLE - Linux Smart Card Development, http://www.musclecard.com 8. “RSA Security Inc.”. Pkcs#11 v2.11: Cryptographic token interface standard. Technical Report PKCS#11 v2.11 r1, RSA Security Inc., nov 2001. RSA Security Inc. PublicKey Cryptographic Standard (PKCS). 9. B. Struif. Use of biometrics for user verification in electronic signature smartcards. In Smart Card Programming and Security - Proceedings of the International Conference on Research in Smart Cards (Esmart), Cannes, France, pages 220--228, sep 2001. 10. Biometrics to Enhance Smartcard Security (Simulating MOC using TOC), G.Bella, S. Bistarelli, F. Martinelli, Proc. 11th International Workshop on Security Protocols Cambridge, England 2-4 April 2003. ABOUT THE AUTHORS Luca Bechelli is freelance consultant in information security. He was born in Barga (LU), Italy, studied at the University of Pisa where he has a degree in Informatics (1999). He works on consulting, project management, learning, and research activities, in collaboration with the IIT-CNR, some Italian Qualified PKI, Public Administrations, Consulting Companies, Banks and E commerce Services Companies. E-mail
[email protected], web http://www.bechelli.net, mobile +39 328 3164385 Stefano Bistarelli (BA degree magna cum laude in 1994 and PhD in 2001 at Pisa University). His PhD thesis titled “Soft Constraint Solving and programming” received two important Italian awards: • Best Italian PhD thesis in Theoretical Computer Science, and • Best Italian PhD thesis in Artificial Intelligence. PostDoc student at the Mathematics and Computer Science department (Padova University) and at the Institute of Informatics and Telematica - IIT (CNR, Pisa), he is now Research Associate at the Science Department (University of Chieti-Pescara) and External Researcher of the IIT- CNR. 36
TIWIS 2003, Tunis, Tunisia His main research activity is in the area of Constraint Solving and in Security. Stefano Frassi has a degree with first class honours in computer science. Now he is working as collaborator at the Institute of Informatics and Telematica - IIT (CNR, Pisa). He implements software solutions that concern smartcard, biometry and Intrusion Detection System.
[email protected]
37
