Communication Security between a Computer and a Hardware Token

H. Karen Lu and Asad Ali Technology and Innovation, Gemalto, Inc.

Arboretum Plaza II, 9442 Capital of Texas Hwy, Austin, TX, USA Karen.lu@gemalto.com, asad.ali@gemalto.com

Abstract

Hardware security tokens are gradually gaining popularity as tools for strong online authentication and secure storage of personal information. The security services they offer protect online service providers as well as consumers. These tokens are small embedded systems that typically have little or no human interface themselves. They work with software on the host computer for human interface and for interaction with programs on the computer or over the Internet. Since these security tokens typically provide cryptographic services and secure storage, the security of communication between the token and the host computer is a critical piece of the overall security framework. The design of this piece is a challenging task. It requires solving multiple problems, such as ensuring that the hardware token only talks with a legitimate host application; exchanging encryption keys; and minimizing the impact on communication performance. This paper presents our solutions to these problems. These solutions are applicable in a variety of hardware security tokens. 1. Introduction

The openness of the Internet and computer operating systems is fundamental to today’s fast expanding technologies. It allows new software to be added to computers and new web applications to reach millions very rapidly. On the other hand, adversaries use this same openness to setup nasty websites and propagate malicious software to computers and web servers on the Internet. They install various spyware, such as keystroke logger and Trojan, on computers without the owners’ knowledge; they use schemes, such as Phishing and Pharming, to steal victims’ confidential information for their own financial gains. The Internet has become an increasingly dangerous environment; personal computers are not secure either. As a result, online identity theft has become a major

concern for both online consumers and service providers.

Using hardware security tokens is an increasingly popular approach to alleviate this problem. Hardware security tokens are small embedded devices that are convenient for people to carry. Examples of such devices are smart cards, One Time Password (OTP) tokens, and secure memory tokens. These tokens provide services such as authentication, encryption, signature, and secure storage. Recently, some security tokens provide digital identity management and secure online authentications. Figure 1 illustrates some hardware security tokens. On the right is a smart card in a credit card form-factor. The rest are tokens of key-fob size; some of them have smart cards in it.

Figure 1. Hardware security tokens

Hardware security tokens are typically small,

portable, and have little or no user interface. When in use, a security token connects to a host computer and uses the latter for user interface and interactions with other programs on the computer or over the Internet. To achieve this, the token software works with some software on the computer. Since the token provides security services, we normally call the software on the token a server and the corresponding software running on the computer a client. For simplicity, this paper refers to a hardware security token as hardware token, a security token, or simply a token.

Assume the security token and its software are trustworthy. As described earlier, a user cannot fully trust his computer, which might have malicious software running in it. The token client software on the computer may be initially trustworthy, but can be tampered by attackers or malicious software later on.

Third International Conference on Systems

978-0-7695-3105-2/08 $25.00 © 2008 IEEEDOI 10.1109/ICONS.2008.36

232

Third International Conference on Systems

978-0-7695-3105-2/08 $25.00 © 2008 IEEEDOI 10.1109/ICONS.2008.36

220

The communication between the token and the computer can be eavesdropped or tampered if no protection is applied. In this environment, something must be done to protect the services offered by the security token. The task includes:

1. Key agreement, storage, and diversification, which manage the keys for secure communications.

2. Message authenticity, confidentiality and integrity, which make sure that the message comes from expected origin, cannot be viewed by a third party, and is not altered.

3. Client software authenticity and integrity, which check that the software is authentic and not altered.

A hardware security token is an embedded system that has, among other things, a microprocessor and a secure storage. Much work have been done to secure communications between applications on different computers; key management has been intensively studied and widely used as well [1]. However, good approaches applied to computers on the network may not necessarily be applicable to small embedded systems. There are several reasons for this:

1. Computing power. Hardware tokens normally have very limited computing resources. The popular public key based mechanism mechanisms, such as RSA and Diffie-Hellman for key exchange, SSL/TLS for secure communication, may be expensive to use between the client and the token software.

2. Key storage. A desirable hardware token is plug-and-play, which does not install any software on the computer, does not require administrator privileges to run, and leaves nothing behind after usage. Since the computer may not be secure, the token should not store its client software’s secrets on the computer.

Due to the above reasons, we must find new solutions to secure the communication between a computer and a hardware token. This paper presents such a solution. Our previous work developed a plug-and-play technology for smart cards [2] and a USB smart card token called Network Identity Manager (NIM) [3]. The contribution of this paper is the method of securing the communication between the smart card-based security token and its client software running on the host computer.

Our method utilizes the direct connection between the token and the computer such that, from one perspective, the token can be seen as a logical part of the computer. With this, simple, efficient, and secure methods are developed for key management. We use standard algorithms for message encryption and integrity check to secure the communication between the token and its client on the computer. Our key agreement and diversification methods also embody the client software authenticity and integrity check.

Although we designed and implemented these methods for a particular smart card-based token, the ideas can be applicable to other hardware tokens as well.

The rest of the paper is organized as the following. First we briefly review related work in Section 2. Then an overview of our approach is provided in Section 3. Section 4 details the various methods. Section 5 illustrates our implementation and discusses the methods and the choices we made. Section 6 concludes the paper. 2. Background and related work

We classify hardware security tokens into three categories: (1) online authentication tokens; (2) PKI tokens; and (3) memory tokens. The authentication tokens can be further classified into (1-a) OTP (One-Time Password) tokens; (1-b) password managers; and (1-c) strong authentication tokens. Some advanced security tokens provide combined functionalities of these token categories. For example, the Network Identity Manager (NIM) [3] supports functionalities of 1-a, b, and c.

Online authentication tokens secure website logins by two-factor authentications. OTP tokens generate passwords that can only be used once [4]. A password manager enables the user to store his usernames and passwords into the token [5]. For website login, the token automatically fills the login form. Strong authentication tokens provide password management, optionally OTP, and additional features such as mutual authentication [3]. PKI tokens are typically used in corporations and governments. They enable secure computer and network logins, encryptions, and digital signing [6]. A secure memory token contains a crypto chip inside the token. The crypto chip encrypts or decrypts data on the fly when files are written to or read from the token [7].

Most security tokens are smart card-based. Smart cards are portable, secure and tamper resistant [6]. They are subscriber identification modules in cell phones, cards for physical access to buildings and public transportation services, and tokens for logical access to computers and networks.

A hardware security token, except OTP, typically works with some client software running on a host computer. The communication between the token and the client is a key element of the mechanism. Therefore, the communication security directly impacts the security of the token service.

The smart card industry has defined standards for secure communications between smart cards and host computers. ISO 7816-4 is an international standard for smart cards, which specifies the organization, security,

233221

and commands for interchange between the card and the host applications [8]. The 2005 version of the standard specified a Secure Messaging (SM) protocol for entity authentication, message authentication, and message encryption. The GlobalPlatform (GP) is an international association that defines and manages standards for multi-application smart cards [9]. GP’s secure communication standards are called Secure Channel Protocol (SCP). The current versions include SCP02 based on symmetric cryptography and SCP10 based on asymmetric cryptography. Both ISO 7816-4 SM and GP SCP require the host software to store secrets, such as shared secret keys or private keys. This requirement is reasonable when a smart card interacts with a secure terminal, such as a portable payment terminal or a bank ATM machine. However, this does not work for environments where plug-and-play hardware security tokens are not permitted to install software, change settings, or store anything on host computers. In this case, the client software only runs temporarily in the host computer’s memory from the token. It cannot store its secrets on the host computer.

Besides smart card standards and publications, there is little published work on communication security between hardware security tokens and host computers. Although some tokens may assume trust-worthy host applications and communications, we believe such assumptions cannot be warranted under the current insecure host computer and Internet environment. The communication must be secured without storing secrets on the host computer. This paper presents our solution. The SSL/TLS protocol is not used in this work due to performance considerations and smart card’s resource constraints.

3. Method overview

We focus on USB hardware security tokens. Figure 1 illustrates three of them (the first, third, and forth from the left). The user plugs his token to a USB port of a computer to use it. The token has a microprocessor and some non-volatile memory. It communicates through the USB connection with its client application running on the host computer to provide security services. Current tokens use various communication protocols over USB, such as Mass Storage protocol, HID, CCID, and ISO 7816-12. To recap from Section 1, the tasks for secure communication include: key management; message authenticity, confidentiality, and integrity; client software authenticity and integrity.

For key management and plug-and-play behavior, a hardware token can enumerate as a USB Mass Storage device among other devices that it might enumerate. The client software resides on the mass storage device

and can be launched (or executed) from there. When the token is powered up (e.g. by inserting it into the USB port of a host computer) the token software embeds some randomly generated shared secrets in the client software before it is executed by the host computer. The shared secrets are different each time the token connects to the computer.

The token software and the client software derive session keys from the shared secrets for message encryption. The session keys are recomputed (diversified) periodically to prevent brute-force, and known-plain-text attacks. The shared secrets enable the token and the client to check each other’s authenticity. The session keys enable the message authenticity and confidentiality. The message integrity can be checked by appending Message Authentication Code (MAC) [1] to the message.

For integrity check we store pre-computed values in the hardware token. Periodically, the token asks the client to compute a hash or checksum on a specified code block and compares the result with its corresponding benchmark value. We also combine the integrity check with the key diversification. This enables the token to verify the client’s authenticity and integrity, and to generate a new session key in one logical step. The next section provides details of our communication security method.

4. Communication security

We use a symmetric encryption algorithm, such as DES-CBC, to secure the communication channel between the security token and the client on the host computer. DES-CBC is chosen to minimize the impact on the communication performance. The symmetric encryption key is diversified on a regular basis to prevent brute force attacks.

4.1 Key initialization

The security token initializes the symmetric encryption key, Ks, through a shared secret, Kss, between the token and the client software. The encryption key Ks is further diversified (or renewed) through an independent master secret Km (Section 4.3). Both Kss and Km are generated dynamically by the token each time it is inserted in the host computer.

The client software runs from the mass storage partition of the hardware token. On each read access on the client software binary, if there is no active client session, the microprocessor of the hardware token generates a random shared secret Kss and a random master key Km of desired lengths (e.g. 8 bytes for DES). The token software writes Kss and Km to the

234222

non-volatile memory (NVM) allocated for them inside the client software binary. This is possible because, although it runs on the host computer, the executable of the client software actually resides in the hardware token. The Kss is the initial value of the encryption key Ks. To further secure Kss and Km, the security token could also use various obfuscation techniques. The initialization vector (IV) is set to zero initially in the binary of the client software. The IV is further diversified along with the encryption key (Section 4.3).

4.2 Thumbprint checking

The security token regularly checks its client software’s authenticity and integrity. To do so, the token challenges the client to compute a thumbprint at a specified code location. It then compares the result with its own record. The thumbprint can be implemented as a cryptographic hash (e.g. SHA-1) of the run-time image of the client software at a particular offset from its starting memory address. The amount of data to hash and a unique diversified list of offsets for each token are configurable during token manufacturing. The offset list and the corresponding hash values are stored in the internal secure memory of the hardware token, which cannot be read or exported to an external application. Only the token software can access the list and challenge the client using one offset at a time during the key diversification sequence.

The list of offsets and the size of data to hash at each offset can also be updated through post-issuance token update. This mitigates the risk of attack against the client software integrity.

4.3 Key diversification

The symmetric encryption key Ks is diversified on a regular basis while the security token is in use. This prevents brute force attacks. The negotiation of a new key requires the knowledge of the master secret key Km that is shared between the token and its client. The Km persists only for one token-insertion session and is used only for Ks update. In this way even if a malicious third party breaks the secure connection between the token and the client, the success is limited because they cannot guess the key for the next session.

The token and the client on the computer use a keyed hash, for example, HMAC-SHA1, to compute a

new encryption key from the old key, the master secret Km, and a random data. Km is the key for HMAC-SHA1 whereas the random value is the input text. From the resulting 20 bytes, the first 8 bytes form the new key and the second 8 bytes form the new initialization vector (IV) for the DES-CBC algorithm.

The security token has the master position during the key diversification sequence. The client might trigger the sequence with a key renewal request. To continue communication, the new key must be consistent across the token and its client; no one else should know the key.

Figure 2 illustrates the key diversification sequence. (In the figure, Kold and Knew are old and new Ks, respectively. The subscript s is omitted for simplicity.) The token and the client exchange the following messages to negotiate a new key:

1. The client on the computer sends a key renewal request.

2. The token generates a random string R. It computes HMAC-SHA1 for R using Km as the hash key to generate a new encryption key Knew. It also picks a random index Idx from the thumbprint list. The index represents a pair: the offset into the starting memory address of the client software binary, and the size over which the thumbprint is to be computed. This index will be used to retrieve a thumbprint value of the client software memory. Then the token sends a thumbprint checking request to the client by sending R and Idx encrypted together with the old key Kold.

3. The client on the computer decrypts the message using the old key Kold and retrieves the random string R’ and the thumbprint index Idx’. Then it uses the R’ string and the shared secret Km to generate its new key K’new. It also computes a thumbprint of its own memory doing a SHA-1 at the offset indicated by Idx’. The client sends the thumbprint value encrypted with its new key K’new to the token.

4. The security token decrypts the message using its new key Knew, and retrieves the client thumbprint. Then it compares this thumbprint with the pre-computed value stored in the thumbprint list at the index Idx. If the thumbprint matches the one in the list, the token has verified three things: first, authenticity of the client; second, the integrity of the client; and third, the consistency of the new encryption key between the token and the client.

235223

On a successful thumbprint match, the security

token replaces its old key with the new one and sends an ACK to the client. In case of failure, the token sends a NAK to the client.

5. If the client on the host computer receives an ACK, it also replaces its old key with its new one. If it receives an NAK, the key is not renewed.

The hardware security token specifies a limited number of re-tries for key update. After the number of re-try exceeds the threshold, the token stops communicating with the client.

4.4 Discussions

The initialization and the diversification of the encryption key provide the forward secrecy. The security token generates two random numbers as an initial session key and a master secret at each token insertion to a computer. The token injects the two numbers in the host agent binary. A new session key is generated from the old key, a random number, and the master secret. Even if an attacker records all encrypted messages and breaks one session key, he cannot decrypt any of the past or future messages. This is because he cannot compute new or old keys from the compromised session key. Furthermore, even if the attacker breaks into the host agent and finds the master secret, his gain is limited only to one token session.

5. Implementation

We have developed a smart card-based hardware security token called the Network Identity Manager (NIM) [3]. NIM is a key fob-sized USB token with an embedded smart card. Figure 3 illustrates an engineering sample of the NIM token.

Figure 3. An engineering sample of the NIM token.

The left picture shows the size of NIM token

relative to a car key. The right picture shows three main components of the token: the smart card (top left); the base that holds the smart card and provides electrical connections between the smart card and the host computer (center); and the token cover (bottom right). Because of its stringent manufacturing processes smart card is a secure and tamper-resistant hardware. It is very difficult to get the card’s microprocessor chip and even harder to extract information from the chip [6].

Client Token

1. Key renewal request

2. Tmsg = {R, Idx} Kold

1. R = RAND_STR( ); 2. Knew = HMAC( R, Km ); 3. Idx = RAND_IDX( ); 4. Tmsg = Encrypt((R, Idx), Kold);

1. ( R’, Idx’ ) = Decrypt( Tmsg, Kold ); 2. K’new = HMAC( R’, Km ); 3. Thumb = SHA-1( Mem[ Idx’ ] ); 4. Cmsg = Encrypt( Thumb, K’new ); 3. Cmsg = {Thumb} K’new

Thumb’ = Decrypt( Cmsg, Knew ); If ( Thumb’ == ThumbTable[ Idx ] ) Kold := Knew; Ack( ); Else Nack( );

4. ACK

4’. NAK Kold := K’new;

Renewal failed.

Figure 2. Key diversification process

236224

The NIM smart card has a USB interface for communication. It connects to a USB port of the user’s computer. The computer provides Internet connection and the human interface for accessing NIM and the Web.

NIM is an application based on the xID architecture that provides communication and plug-and-play behavior for smart cards [2]. A xID application partitions its functionalities into two main logical components - Host Agent and Card Agent. The host agent is the client software that resides in the smart card and runs in the host computer; the card agent resides and runs in the smart card (Figure 4).

Figure 4. xID architecture.

A xID-based smart card token, when plugged into a

host computer, enumerates two USB Mass Storage devices to enable the plug-and-play behavior. One mass storage device is read-only for storing the host agent and some associated files. The other mass storage device provides a communication channel between the host and the smart card.

The host agent is a user-mode application. It interacts with other applications outside the smart card. It does not access, change, or store any data on the host computer. The smart card stores confidential data, including private keys and user login credentials, in its internal secure file system. Only the card agent can access the private data and perform cryptographic operations on this data.

The card agent and the host agent communicate via USB protocols. Although several protocols and corresponding device drivers are available on host computers, the xID architecture uses protocols that satisfy the “no administrator privilege” and “no software installation” requirements to achieve the plug-and-play behavior. Currently only two USB protocols, Mass Storage Device (MSD) and Human Interface Device (HID), satisfy those requirements.

For performance reasons, xID uses the Mass Storage Device protocol for connectivity and its own protocols for communication. The host agent and the

card agent communicate through files that reside on a special mass storage partition of the smart card. We use the approach described in this paper to secure the communication, where the NIM smart card is the core of the security token and the host agent is the client software.

6. Conclusions and future work

When connecting a hardware security token to a host computer, the communication between the token and the host must be secured to achieve overall security. This paper has presented a practical way to secure such communications for smart card-based hardware tokens. The method is equally applicable to other hardware security tokens as well.

Our future work includes research on protecting token client software from tampering and remote updating of security tokens.

Acknowledgement

The authors would like to thank Apostol Vassilev, Mike Montgomery, Laurent Castillo, and Stephane Durand for their contributions to this work.

References [1] C. Kaufman, R. Perlman, and M. Speciner, “Network

Security – Private Communication in a Public World,” 2nd edition, Prentice Hall PTR, 2002.

[2] Ali, A.M. and Lu, H.K., Securing the Internet through Plug-n-Play Smart Cards, The 2007 International Conference on Internet Computing, Las Vegas, Nevada, June 25-28, 2007.

[3] Lu, H.K. and Ali, A.M., “Security, Privacy, and Usability: A High Common Ground,” IASTED Int. Conf. on Communication, Network, and Information Security, Berkeley, CA, USA, Sept. 24-27, 2007.

[4] RSA SecureID, http://www.rsa.com/node.aspx?id=1156.

[5] ID Vault from GuardID Systems, http://www.guardidsystems.com.

[6] T.M. Jurgensen and S.B. Guthery, Smart Cards – The Developer’s Toolkit, Pearson Education, Inc. Prentice Hall PTR, Upper Saddle River, NJ 07458, 2002.

[7] IronKey, www.ironkey.com. [8] ISO/IEC 7816-4: Identification Cards – Integrated

Circuit Cards, Part 4: Organization, Security, and Commands for Interchange.

[9] GlobalPlatform Card Specification, v2.2.

Host Agent

CardAgent

Host Computer Smart Card

Private Files

USB mass storage read-only files

USB communication interface

237225