US20080189554A1

US20080189554A1 - Method and system for securing communication between a host computer and a secure portable device

Info

Publication number: US20080189554A1
Application number: US11/948,758
Authority: US
Inventors: Asad Ali; HongQian Karen Lu; Michael Montgomery; Apostol Vassilev
Original assignee: Gemalto Inc
Current assignee: Thales DIS USA Inc
Priority date: 2007-02-05
Filing date: 2007-11-30
Publication date: 2008-08-07
Also published as: US20100146279A1; EP2109842A2; US8560852B2; WO2008096220A2; WO2008096220A3

Abstract

A secure portable electronic device for providing secure services when used in conjunction with a host computer having a central processing unit. The secure portable device communicates with the host computer via a host agent program executing on the host computer from the secure portable device. Periodically, the host agent and a corresponding program executing on the secure portable device, cooperate to verify the integrity and authenticity of the host agent program, for example, in conjunction with exchanging a new session key. Other systems and methods are disclosed.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional application claiming priority from provisional application 60/888,288 filed on Feb. 5, 2007 the teachings of which are incorporated by reference herein as if reproduced in full below. This application is related to U.S. patent application Ser. No. 11/564,121 filed on Nov. 28, 2006

BACKGROUND OF THE INVENTION

The present invention relates generally to provision of security services to Internet applications and more particularly to ensuring the security of communication between a secure portable device and a host computer wherein the secure portable device is engaged in communication with a remote server via the host computer.
Co-pending patent application Ser. No. 11/564,121 describes a system and method for providing secure communication between the secure portable device and a remote server. In that system the secure portable device is connected to a host computer. The secure portable device, for example, in non-volatile memory contains a card agent and a host agent. The card agent and host agent is both a division of labor of security functionality, e.g., cryptography services, between the secure portable device and the host computer, and a mechanism for providing security in the communication to the remote server.
The level of security and efficiency are trade-offs in determining how to divide responsibilities between the card agent and host agent. The more tasks that are placed on the card agent, which is executing on the secure device, the higher the security but the lower the performance as typically secure devices are more secure than host computers but do not provide as high performance. On the other hand, the more tasks that are placed on the host agent, which is executing on the host computer, the higher the performance, but the lower the security as the host computer typically is not as secure as a secure device, but usually provides much more computing power and hence higher performance.
Therefore, in one division of labor between the card agent and host agent, the latter performs cryptography services such as digest computation and HMAC computation during security protocol handshake operations and application data exchange. This is a performance gain over performing these operations on the secure device in that secure portable devices, e.g., smart cards, typically do not have crypto accelerators for hashing.
However, placing any of the security operations on the host computer via the host agent increases the security risk. The security of the solution may be compromised if the host agent is compromised. The security of the host agent and the way the host agent communicates with the secure portable device determines, to a significant extent, the security of the overall architecture. The security of the host agent includes authenticity, integrity, and confidentiality of its runtime code.
Because the host agent runs in an insecure host computer environment, theoretically, while the host agent is loaded into the host computer from the secure device, after loading, the host agent may be compromised by being modified in the memory of the host computer. Because the secure communication between the host agent and card agent could be compromised by such tampering, it is desirable to avoid communication with a compromised host agent.
From the foregoing it will be apparent that there is a need for an improved method to ensure the integrity and authenticity of the host agent as the host agent participates in providing secure communication between a secure portable device and remote servers over a computer network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example scenario in which a smart card is used to access services on a remote server.

FIG. 2 is a block diagram illustrating a high-level view of the architecture of a smart card of FIG. 1.

FIG. 3 is a block diagram illustrating the architectural organization of programs over the hardware components of the smart card FIG. 2, including illustrating a host agent and card agent both stored in memory of the smart card.

FIG. 4 is a block diagram illustrating the loading of the host agent of FIG. 3 into Random Access Memory (RAM) of the host computer to which the smart card is connected.

FIG. 5 is a block diagram illustrating logic modules of the card agent and host agent as stored on a smart card of FIG. 1 pertinent to securing the communication between the card agent and host agent.

FIG. 6 is a block diagram of the logic modules of a host agent and ancillary modules executing on the host computer pertinent to securing the communication between the card agent and host agent.

FIG. 7 is an exemplary memory layout illustrating embedding of a key in the host agent code and the memory values used to calculate a thumbprint of the host agent code.

FIG. 8 is a flow chart illustrating an example of the calculation of an initial session key (K_SS) and master secret key (K_M) and the spreading out those keys over specific locations in the host agent code.

FIG. 9 is a flow chart illustrating the recovery of the initial session key (K_SS) and master secret key (K_M) as stored in the host agent according to the figure of FIG. 8.

FIG. 10 is a timing sequence diagram illustrating the message flow between the host agent and the card agent to verify the authenticity and integrity of the host agent, and to generate a new session key, K_S.

FIG. 11 is an exemplary database table illustrating pre-stored expected thumbprint values for the host agent. The database table is used by one embodiment of the card agent for storing expected thumbprint values and parameters used to calculate the expected thumbprint values.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.
A security device as described in co-pending patent application Ser. No. 11/564,121. Ser. No. 11/564,121 provides a self-contained infrastructure that is automatically shared with a host computer to which the security device is connected. The security device, hereinafter, for illustrative purposes, a smart card, is configured to be connected, to a host computer using a standard peripheral connection and to behave as a device normally connected to such a standard peripheral connection. The smart card communicates with the host computer using the communications protocol associated with the standard peripheral connection.
In one embodiment, that connection is a Universal Serial Bus (USB) connection and the smart card appears to the host computer as a USB mass storage device. As such, the smart card communicates with the host computer using communications protocol such as the USB mass storage protocol. Upon connecting the security device to a host computer, a special program used for communication with the host computer, the card agent starts executing on the smart card. Next, another special program, the host agent, stored on the smart card, is automatically launched on the host computer. The host agent and card agent communicate over a special communications protocol for providing secure communications there between. In one embodiment, that special communications protocol is carried over the USB mass storage protocol.
While the communication between a host computer and a smart card is described herein using the USB mass storage protocol other communications protocols are possible alternatives for alternative embodiments. Some examples include, but is not limited to APDU (as described in the ISO-7816 standard for communication between smart cards and other devices) including middleware stored on the host computer, Chip Card Interface Device (CCID) protocol with a CCID driver on the host computer, USB Human Interface Device (HID) protocol, and TCP/IP
By providing a standard hardware interface, one that is available on virtually every modern computer, and by communicating over a standard protocol, while providing the host agent and card agent functionality, a smart card according to the invention, may provide a hitherto unavailable advantage of providing the security functionality of a smart card without requiring any special hardware or software on the host computer. Thus, a person carrying such a smart card may achieve the hitherto unavailable advantage of connecting that smart card to virtually any computer, e.g., one provided in a public place, a friend or co-worker's computer, or even, a totally untrusted computer, and achieve a secure communication between the smart card and a remote service. Availability of such smart cards makes new uses of smart cards possible because there is no longer a requirement of a special card reader or middleware.
Security of the overall solution is further enhanced by ensuring the authenticity and integrity of the host agent. The card agent ensures the authenticity and integrity of the host agent, by periodically, for example, during key diversification, checking a thumbprint of a section of the host agent code, e.g., a hash computed over a specified section of host agent code.

1. Introduction

FIG. 1 is a block diagram illustrating an example scenario in which a smart card is used to access services on a remote server. A smart card 101 is connected to a host computer 103 using a standard connector 105. The host computer 103, in turn, is connected to a network 107, e.g., the Internet. At a remote location on the network 107, a server computer 109 is connected. A user 111, for example, the owner of the smart card 101, wishes to access a service 113 provided by the server 109. Consider, as an example, that the service 113 requires the user 111 to identify himself using a PIN. The user 111 (or a service provider) has previously stored the user's PIN on the smart card 101. If the user 111 cannot trust the host computer 103, there is a risk that the host computer 103 would capture the PIN, if the user 111 merely types in the PIN using the keyboard of the computer 103. Alternatively, the user 111 can direct the smart card 101 to transmit the PIN directly to the remote service 113. That is also problematic. Malware installed on the host computer 103 or elsewhere on the path between the smart card 101 and the remote service 113 may capture the PIN by snooping on the communication.
As will be discussed in greater detail below, in one embodiment of the invention, the PIN is securely transmitted to the remote service 113 over a secure communications channel, without requiring special hardware or software to be preinstalled on the remote server 109, the host computer 103, or anywhere along the path between the smart card 101 and the remote service 113.
While the discussion herein, for purposes of providing an illustrative example, is directed to the use of a smart card 101 with a host computer 103, many alternatives exist. For example the smart card 101 may be a SIM card used in a mobile telephone; in which case, the host computer 103 would be such a mobile telephone. The smart card 101 may also be substituted with other forms of secure portable devices, e.g., a USB token with a memory card and secure integrated circuit. It should also be noted that while the illustration of FIG. 1 shows a USB dongle form factor for the smart card 101 and corresponding interface device, that is also only for the purpose of illustration. The embodiments described herein are applicable to any other smart card or secure memory form factor and corresponding interface devices, e.g., but not limited to, the traditional credit card sized smart card form factor used in conjunction with a smart card reader.
FIG. 2 is a block diagram illustrating a high-level view of the architecture of a smart card 101. As illustrated in FIG. 1, the smart card 101 is equipped with a standard peripheral hardware connector 105, e.g., a USB connector. The smart card 101 contains a central processing unit 201, a RAM 203, and a non-volatile memory 205. These components are connected via a bus 207. Also connected to the bus 207 are a communications hardware interface 209 for providing a connection between the bus 207, and consequently, the CPU 201, RAM 203, and non-volatile memory 205, and the connector 105.
FIG. 3 is a block diagram illustrating the architectural organization of programs over the hardware components of the smart card 101. The hardware connection between the smart card 101 and the host computer 103 is achieved using the hardware connector 105. The communication on the hardware connection uses the USB mass storage protocol. The CPU 201, executing an interface firmware module 227, which is stored as firmware on the smart card 101, manages that communication. As such, the interface firmware module 227 is located in the non-volatile memory 205 or in Read Only Memory (ROM). The interface firmware module 227 implements the USB mass storage protocol such that the host computer 103 perceives the smart card 101 to be a USB mass storage device.
In alternative embodiments, the communication between the smart card 101 and the host computer 103 is performed according to other communications protocols. For example, the smart card 101 may enumerate at start up as another type of peripheral device, e.g., a CD ROM, in which case the interface firmware module 227 implements the appropriate communications protocol.
The non-volatile memory 205 of the smart card 101 contains three areas: a mass storage read-only partition 221, a mass storage read-write partition 223, and a secure read/write memory 225. The mass storage read-only partition 221 and the mass storage read-write partition 223 are accessible from external devices, e.g., the host computer 103. However, while external devices, e.g., host computer 103, can write to the read-write partition 205, in one embodiment, the read-only partition may be written to by the CPU 201 of the smart card 101, i.e., the read-only partition 203 is read-only with respect to external devices, but not necessarily to the smart card 101. Conversely, the secure read/write memory 225 may not be accessed directly from external devices for either read or write operations. Because all interactions are managed by the interface firmware 227, the interface firmware 227 can control access to various parts of the non-volatile memory 205 or files stored in the non-volatile memory 205 so that, for example, only the card agent 213 can access the secure data 215 (described herein below).
The mass storage read-only partition 221 contains public data 209 that may be accessed from any host computer 103 to which the smart card 101 may be connected. The mass storage read-only partition 221 also contains a program, the host agent 211, which is auto-launched on the host computer 103 when the smart card 101 is connected to the host computer 103 via the hardware connection 105. The USB mass storage standard provides that a USB mass storage device may include a trigger file called autorun.inf that is a script that automatically is executed when the device is connected to a host computer 103. Alternatively, the host agent 211 is visible from the file browser of the host computer's 103 operating system. A user 111 launches the host agent 211 manually, for example, by clicking on the icon corresponding to the host agent 211 in the file browser. Table I is a code example of one possible autorun.inf file to launch the host agent 211 on the Microsoft Windows Application Program Interface known as Win32:

TABLE 1

Example Autorun.inf to launch the host agent 211.

	[autorun]
	shellexecute=hagent_r.exe
	action=Launch the Network Card Host Agent
	label=NetCard Host
	UseAutoPlay=0

When a user 111 inserts the smart card 101 into the appropriate slot on a host computer 103, the operating system (e.g., Microsoft Windows) displays a dialog box allowing the user 111 to select the action “Launch the Network Card Host Agent”. If the user 111 accepts that action, the host agent 211 (“hagent_r.exe” in the example code) is executed by the host computer 103.
The secure read/write memory 225 contains a module called the card agent 213. The smart card 101 is configured such that, when the smart card 101 is connected to a host computer 103, i.e., when a USB connection has been established between the smart card 101 and the host computer 103, the CPU 201 launches (i.e., executes) the card agent 213. As described in greater detail below, in one embodiment, the card agent 213 is the only program through which certain secure data 215 may be accessed.
Typically a USB mass storage device is used to store data files. USB memory sticks are one example of a USB mass storage device. A USB memory stick functions as a very compact and easily transportable non-volatile storage device. A user uses such a device to store data files.
The mass storage files are files with public access that are exposed by the smart card 101 and accessible from the host computer 103. The host agent 211 has direct access to these files. Examples of these files can be HTML, image, JavaScript, CSS files, as well as public key certificates. All files accessible through the mass storage interface are read-only files for the host computer 103. The only exception is a set of communications files 217 in the mass storage read-write partition 223; for example, according to one embodiment of the invention, the communication channel between the host agent 211 and the card agent 213 is based on mass storage files. These files are read-write files.
Thus, to achieve a communication according to the USB mass storage protocol between the card agent 213 and the host agent 211, when the host agent 211 is executing on the host computer 103, the card agent 213 and host agent 211 writes communication data files 217 in the mass storage read-write partition 223. The nature of that communication is described in greater detail herein below.
FIG. 4 is a block diagram illustrating the loading of the host agent 211 into the RAM 403 of the host computer 103. The CPU 401 of the host computer 103, then executes the host agent 211. The host agent 211 communicates with the card agent 213, which is loaded in the RAM 203 of the smart card 101 and executed by the CPU 201 of the smart card 101. The card agent 213 has access to private files 215 for certain calculations, providing services to the host agent 211. Communication between the host agent 211 and the card agent 213 is performed via the host-side USB mass storage interface 405 a and the smart card-side USB mass storage interface 405 b (collectively, 405).
The architecture illustrated in FIGS. 1-4 provides a framework in which a smart card 101 can provide security and convenience of services for Internet applications. In one embodiment, the components involved rely solely on the USB mass storage interface for connectivity and do not require the smart card 101 to implement networking protocols, such as TCP/IP, DHCP server, or DNS server, in order to provide services. The architecture avoids the burden of implementing a network communications stack, DHCP server, or a DNS server on the smart card 101. In one class of solutions using a smart card 101, as described herein, dealing with authentication and secure Internet access, the smart card 101 may include the following components:

- An interface capable of enumerating as a USB mass storage device and an internal secure file system.
- SSL/TLS library, in client and server mode
- OATH, etc. for OTP
- HTTPS web server
- HTTPS agent
- Application programs

The smart card 101 enumerates as a USB mass storage device and contains a private file system 215. The components used for providing security services may be split between the host computer 103 and the smart card 101. These components are divided between the smart card 101 and the host computer 103 into two main logical pieces, namely, those provided by the host agent 211 and those provided by the card agent 213. All functionality provided by connecting the smart card 101 is contained in these two main components, divided judiciously to suit a particular preference for security vs. performance trade-off. The host agent 211 and the card agent 213 communicate with each other using a mass storage interface as an I/O channel. In one embodiment, the communication is encrypted by the host agent 211 and the card agent 213 to prevent access by a third party along a communications path from the smart card 101 to the host computer 103 or a remote server 109.
The actual division of workload between host agent 211 and card agent 213 is driven by the security versus performance considerations. On one end of the security/performance spectrum, the card agent 213 contains implementation of all the security components provided through the smart card 101 and the host agent 211 merely acts as a thin proxy. That solution is a very secure solution but may not have acceptable performance for certain classes of applications. On the other end of the spectrum all features are run on the host computer 103. That solution has excellent performance characteristics but offers little in way of security. The architecture provided herein offers flexibility in defining the right balance between security and performance. One embodiment is described herein below as one possible example of a division of tasks between the card agent 213 and the host agent 211 where performance is significantly improved with very little compromise in regard to security.
As is described in the co-pending patent application Ser. No. 11/564,121, the communication between the host agent 211 and the card agent 213 is secured by a shared session key, K_S. The shared session key, K_S, is initialized from an initial shared session key, K_SS, or shared master secret key, K_M.
FIG. 5 is a block diagram illustrating the architectural arrangement of various modules stored in the smart card NVM 205. As discussed hereinabove and described in the co-pending patent application Ser. No. 11/564,121, the host agent 211 is stored in the NVM 205 and is loaded by the host computer 103 from the mass storage portion 221 of the smart card 101.
On each read access by a host computer 103 of the host agent 211 binary from the mass storage partition 221 of the smart card 101, the smart card processor generates a random key, shared master secret key, K_M, of desired length and writes to a specific NVM 205 memory location allocated for this purpose inside the host agent binary 211. Because the host agent 211 is stored in the NVM 205 of the smart card 101 it is possible to write the master secret key, K_M, into the host agent 211 even though the host agent 211 is actually executed by the host computer 103. The master secret key, K_M, may be used as an initial value of a session key, K_S. Alternatively, two random numbers, an initial session key, K_SS, and the master secret key, K_M, may be generated and written into the host agent 211 code. For sake of simplifying the discussion, the second alternative (with a separate master secret key, K_M, and an initial session key, K_SS) is primarily described herein. For either alternative, in a preferred embodiment, the initial keys, master secret key, K_M, or K_Mand the initial session key, K_SSare generated on each smart card 101 reset, typically occurring on each power up, e.g., on smart card 101 insertion.
Thus, in one embodiment, the card agent 213 includes a start-up module 501 that is executed upon each power up of the token. The start-up module 501 includes a master key generator 503 that computes a random key of desired length and a master key embeddor module 505 that writes the master secret key, K_M, into the appropriate location 507 in the host agent code 211. In the alternative embodiment wherein both the master secret key, K_M, and the initial session key, K_SS, are generated, the start-up module 501 also generates the initial session key, K_SS, and the embeddor module 505 also writes the initial session key, K_SS, into an appropriate location 508 in the host agent 213 code.
To generate the master secret key, K_M, and the initial session key, K_SS, the master key generator 503 may simply be a call in the start up module 501 to an external function, e.g., a function of the crypto services module 509 or the smart card 101. The master key generator 503 also may call upon the crypto services module 509 to store the master secret key, K_M, and session key, K_S, in memory locations 511 and 513 that are under control of the crypto services module 509.
The communication between the host agent 211 and the card agent 213 is further secured by periodically refreshing the session key, K_S, through a process known as key diversification. Key diversification is a process in which a new key is generated from the master secret key, K_M, and a random number, and in one embodiment is performed by a key diversification module 515.
As is discussed in greater detail below, the key diversification process uses message transmission between the host agent 211 executing on the host computer 103 and the card agent 213 executing on the smart card 101. Thus, the smart card NVM 205 includes some I/O services 517 for receiving and sending messages. The card agent 213 may include modules or other code for managing the reception of messages, e.g., a message receiver module 519, and for transmitting messages, e.g., a message transmitter module 521. In some implementations, the receiver module 519 may simply be logic to determine that nature of an incoming message and logic to route the message internally for appropriate processing, e.g., key diversification.
In a preferred embodiment, the card agent 213 and host agent 211 use hmac_SHA1 to compute the new key from the master secret key, K_M, and additional random data. The master secret key, K_M, is the key for hmac_SHA1 whereas the random value is the input text. The message can carry information needed by the encryption algorithm used to secure communication between the smart card 101 and the host computer 103, e.g., for the DES CBC algorithm an initialization vector is carried as the message text. In that example, the resulting 20 bytes, the first 8 bytes form the new key and the second 8 bytes form the initialization vector (IV) for the DES CBC algorithm.
The session key, K_S, is diversified while the smart card 101 is in use. Key diversification prevents the session key, K_S, from being stale and susceptible to brute force attacks. The negotiation of an update of the session key, K_S, uses knowledge of the master secret key, K_M, which is shared between the card agent 213 and host agent 211 through a secret obfuscation technique described in greater detail below. The master secret key, K_M, persists only for one token-insertion session and is used only for session key, K_S, update. Using this technique of securing the session key, K_S, protects the information stored on the smart card 101 from third party impostors because even if a malicious third party breaks the secure connection between host agent 211 and card agent 213, the third party's success is of limited risk to the smart card 101 security because the third party cannot gain advantage in guessing the next session key K_S.
While it is important to ensure that the new session key, K_S, is consistent across the host computer 103 and the smart card 101 and that no one else knows the session key, K_S. However, if something fails during the sequence, the fact that the sequence fails is the only information that is relevant. Therefore, in one embodiment, no failure diagnostics are provided.
In one embodiment, the card agent 213, initiates key diversification. In another embodiment, the host agent 211 triggers the key renewal sequence with a RenewKey request. Thus, when the host agent 211 determines a desire to update the session key, K_S, the host agent 211 transmits a request to that effect to the card agent 213.
As is discussed in greater detail below, one aspect of key diversification 515 includes checking a thumbprint of the host agent 211 code. Thus, the card agent 213 includes a thumbprint checker 523 that requests thumbprints 525, verifies the thumbprint against a thumbprint database 527, and controls access 531 based on the result of the verification. The operations of these modules or the logic to perform these functions are described below.
FIG. 6 is a block diagram illustrating one possible architecture for the host agent 211 and host computer 103 services that the host agent 211 uses. The host agent 211 has an analogous architecture to that of the card agent 213. While the card agent 213 has modules to generate and store a master secret key, K_M, in the host agent 211, the host agent 211 has corresponding code to extract the master secret key, K_M, e.g., a master key extractor module 601, code to compute a specified thumbprint over the code of the host agent 211, e.g., a thumbprint calculator 603, and code to calculate a new session key, K_S, based on input received from the card agent 213. The master key extractor 601, in one embodiment, relies on the crypto services 607 of the host computer 103, to store the master secret key, K_M, and the session key, K_S, in memory locations 609 and 611 that are managed by the crypto services 607.
Like the card agent 213, the host agent 211 may have code for receiving and transmitting messages, e.g., message receiver 613 and message transmitter 615, respectively, via the I/O services 617 provided by the host computer 103.
To further secure the master secret key, K_M, the card agent 211 and host agent 213 may employ various obfuscation techniques.
The card and host agents 213 and 211 must utilize redundancy and thereby secrecy in exchanging session key, K_S, and master secret key, K_M, through the NVM of the executable code of the host agent 211. If the session key, K_S, and master secret key, K_M, are N-bytes long, the smart card 101 must update a buffer B of M-bytes in the executable code, where
M>>2N.
if both the initial session key, K_SSand master secret key, K_M, are initially written to the host agent 211 code.
The information about the real N-bytes of initial session key, K_SS, and master secret key, K_M, is encoded in the M-bytes and in the logic of an algorithm capable of restoring initial session key, K_SS, and master secret key, K_M, from B. The algorithm must be secret and its implementation obfuscated. In one embodiment, the value of M should be on the order of
M˜m*2N, where m>5.
To populate B, the smart card 101 should fill it up with random data and then overwrite the initial session key, K_SS, and master secret key, K_M, bytes as indicated below.
In one embodiment, the host agent 211 starts master secret key, K_M, recovery at an offset from the beginning of B determined by the first byte. The host agent 211 reads every i-th byte, starting at the offset specified by the first byte in B. Here, i is a step increment determined by the last byte in B.
Since the offset from the start of B is likely to be sufficiently small, not all bits in the first byte may be needed to encode it. Consequently, if only p bits are needed, the remaining 8-p most significant bits should be set to random values to obscure the logic.
Similarly, the increment k is likely also to be a small number. If q is the number of bits needed to encode it, the remaining 8-q bits in the last byte should be set to random values.
The values of p and q must be agreed upon beforehand and used by the host 211 and card 213 agents.
For example, the card agent 213 may spread out the master secret key, K_M, over a block of the host agent 211 binary code starting at a particular location of the host agent 211 binary code so that only every i-th byte of that block of code actually is used to store master secret key, K_M, e.g., every-other byte or every fifth byte in a block of memory. Similarly, the actual number of bytes may also be a variable parameter defining the master secret key, K_M. Thus, for example, the card agent 213 may write the master secret key, K_M, as every-other byte for a total of 8 bytes starting at memory location 0020.
FIG. 7 is an exemplary memory layout of the host agent code 211. The example of FIG. 7 is not an actual example of host agent 211 code. Rather FIG. 7 presents randomly selected hexadecimal values in the various memory locations for purposes of illustration. Furthermore, the example code illustrated in FIG. 7 is very short in comparison to what one would expect of an actual implementation of the host agent 211.
In the example of FIG. 7, the master secret key, K_M, starts at memory location 0020, has a length of 8 bytes, and is written as every-other byte, i.e., the increment i is 2. Thus, in the example, the master secret key, K_M, 507 has the value FA021787141670CA.
The starting location of the master secret key, K_M, and the increment i may be obscured by not writing their full information in the memory locations that define these parameters. For example, if the offset at which the master secret key, K_M, is known to not exceed 31 (0x1F) the offset could be written over five bits the remaining three bits random. Similarly, if the increment i is known to never exceed the value 7 only three bits are required to encode this information. The remaining bits of the bytes in which the offset and the increment i are stored may be randomized. Thus, if the last five bits of the first are used for storing the offset 0020 (of the example of FIG. 7), for example, the values 0x14 (0x0001 0100), 0x54 (0x0101 0100), and 0xF4 (0b1111 0100) could be used to store the offset value of 20.
If the buffer B consists of the code section illustrated in FIG. 7 and the last byte of the buffer B is used to store the increment, which in the example has the value 2, and only 3 bits are used to store the increment (i.e., q=3), the last byte should have a value that fits the pattern 0brrrr r010 so that the last three bits have the value 2. One possible value is 0xFE (0b1111 1010).
By randomizing the unused bits in the code used to encode the offset, the increment and the length of the master secret key, K_M, it becomes very difficult to determine which bytes are used for encoding these items.
If a separate initial session key, K_SS, and master secret key, K_M, are both stored in the host agent 211 code, a similar approach is used to encode the initial session key, K_SS, e.g., using the second byte in the buffer B to include its offset.
There are many different possible approaches to spreading out the initial master secret key, K_M, and the initial session key, K_SSall of which must be considered as equivalent to the specific techniques described herein. For example, with one such alternative a function is used to determine the location from which to retrieve the next portion of the key.
FIG. 8 is a flow chart illustrating the steps of writing the initial session key, K_SSand master secret key, K_M, into the host agent 211 code.
As a first step, the buffer B that may hold the initial session key, K_SS, and the master secret key, K_M, is initialized with random data, step 801.
Next the card agent 213, e.g., the master key generator code 503, generates a master secret key, K_M, value to be used during the current session, step 803. Note that in a preferred embodiment, the host agent 211 is reloaded into the host computer 103 memory on each new session, e.g., on each new insertion of the smart card 101 into the host computer 103. Thus, a new master secret key, K_M, (and initial session key, K_SS) is generated for each such session.
The initial value for the initial session key, K_SS, is then written into the buffer B at a specific offset O and spread out by an increment k, step 805. Similarly, the master secret key, K_M, is written beginning at a specific offset C and spread out by an increment i, step 807.
Finally, the offsets and increments are written into locations known to hold those values in a subset of the bits found at those locations, respectively, step 809.
FIG. 9 is a flow-chart illustrating the converse steps taken by the host agent 211, e.g., master key extractor 601, to recover the initial session key, K_SS, and the value for master secret key, K_M.
First the offsets for initial session key, K_SS, and master secret key, K_M, are read from specific locations of B used for storing K_SSand K_Mby only reading those bits of the bytes at those locations, respectively, that are used for storing K_SSand K_M. In other words, if only 3 bits of the last byte of B is used to store the increment i, then only those three bits are read step 901.
Next, the initial session key, K_SS, is read by reading every k-th byte in B beginning at the offset O, step 903.
Finally, the master secret key, K_M, is read by reading every i-th byte in B beginning at the offset C, step 905.
Note: in one embodiment described herein above, the initial value for initial session key, K_SS, is the value master secret key, K_M, in which case steps 805 and 903 are not performed.
During a session, the host agent 211 and card agent 213 refresh the value of session key, K_S, i.e., key diversification is performed. FIG. 10 is a timing sequence diagram illustrating the steps of performing the key diversification in the context of a communications session between the host computer 103 and the smart card 101.
Upon startup of a session, the start up module 501 of the card agent 213 embeds master secret key, K_M, and an initial value for session key, K_Sinto the host agent 211 code as described herein above in conjunction with FIGS. 7 and 8. Once that is completed, the host agent 211 may be transmitted to the host computer 103, step 153. This would usually be performed by executing the host agent 211 from the memory of the smart card 101 because the smart card 101 has enumerated itself as a USB mass storage device. Thus, to the host computer 103, the smart card 101 is like any other USB mass storage device and the host computer 103 may execute programs stored thereon.
Next the host agent 211 extracts the master secret key, K_M, and initial session key, K_SS, from the host agent 211 code, step 155, in the manner discussed in conjunction with FIG. 9, and uses the initial session key, K_SS, to initialize the session key, K_S.
The communication between the smart card 101 and the host computer 103 can now be secured using the session key, K_S. The communication of messages between the smart card 101 and the host computer 103 are encrypted using session key, K_S.
During a session, the host agent 211 may request that session key, K_Sbe updated. This may be triggered by any number of events, e.g., time-based, particular instructions or operations attempted, step 157.
The host agent 211 then transmits a request for a new session key, K_S, value to the card agent 213, step 159. The message notation sent with the request contains no data. Alternatively, the card agent 213 initiates the exchange of a new session key, K_S.
To compute a new session key, K_S, the card agent performs a series of steps 161:

- The card agent 213 generates a random string R.
- Then it uses this string and the master secret key, K_M, to generate the new value for session key, K_S, K_new.
- It also picks a random index from a finite list. This index will be used to retrieve a thumbprint value of the host agent 211 memory.
- Then it issues the AskThumb request, which sends the random string R and the thumbprint index Idx encrypted together with the current session key, K_S, which is known by the host agent 211.

The AskThumb request bearing the random number and the index is transmitted by the card agent 213 to the host agent 211, step 163.
In response the host agent 211 performs a number of steps to transmit the requested thumbprint of the host agent 211 code, steps 165:

- The host agent 211 decrypts the message within the AskThumb request using the current session key, K_S, and thereby recovers the random string R′ and the thumbprint Idx′. If the host agent 211 has successfully decrypted the message R′=R and Idx′=Idx.
- Then the host agent 211 uses the R′ string and the shared secret master secret key K_mto generate its new Key K′new. Again, if the host agent 211 has successfully decrypted the message K′_new=K_new.
- It also compute a thumbprint of its own memory doing a HMAC at the offset indicated by Idx′.

Computing a thumbprint may be performed in several different ways. One way is to use a specific function, e.g., SHA-1. Another is to have a number of different functions. In the latter case, the message may indicate a function number to use to calculate the thumbprint.
The card agent 213 may have several different thumbprints for the host agent 211 stored in a thumbprint database 527. A sample thumbprint database 527 is illustrated in FIG. 11. Each row in the table represents a different thumbprint taken on the host agent 211 code. For each row, the table contains a thumbprint number to index in the table 527. Each row also contains an index field to indicate an offset in the host agent 211 code to begin the thumbprint computation, a length over which the thumbprint is to be computed, the function to use to compute the thumbprint on the data found at the offset given the length, and finally, the expected value for the thumbprint. For example, for thumbprint 1, the index is 10, the length 128 bytes, the function is function number 1, and the expected result is A3F0. The actual length of the thumbprint depends on the algorithm used and generally would be longer than two bytes.
Considering the code example of FIG. 7, if the card agent 213 has transmitted an indication to start a SHA-1 computation on the host agent 211 code the 16 bytes beginning at byte 0004 and ending at byte 0013, the host agent 211 would perform the SHA-1 computation 701 over those bytes and produce a result 703.
Having computed the requested thumbprint, e.g., thumbprint 703, the host agent 211 encrypts the thumbprint with the host agent new key K′_new, step 167, and transmits that result to the card agent 213, step 169.
If the host agent 211 code has not been tampered with, the host agent 211 should have computed the expected thumbprint. If the host agent 211 has successfully computed the new session key, K_S, e.g., K′_new=K_new, then the host agent 211 should have also encrypted the thumbprint in a manner that the card agent 213 can decrypt.
When the card agent 213 receives the TellThumb message from the host agent 211, the card agent 213 computes the received thumbprint (Thumb) by decrypting the received message using the new symmetric key as computed by the card agent 213, i.e., K_new, step 171.
Having decrypted the thumbprint (Thumb), the card agent 213 compares this thumbprint with a pre-computed value stored in a thumbprint table at the offset Idx, step 173. If this check verifies that the computed thumbprint received from the host agent 211 matches the expected thumbprint, the card agent 213 validates both the thumbprint and that the host agent 211 and the card agent 213 new keys are consistent and the card agent 213 sets session key, K_Sto equal K_new. If thumbprint check fails, in one embodiment no diagnostics are performed as doing so may cause other security issues. In case of success, the card agent 213 sends an OK status to the host agent 211 or in the case the thumbprint check fails, the card agent 213 only sends a KO status to the host agent, message 175. In both case, all internal state variables used in the key renewal sequence are cleared.
If the host agent 211 receives an OK status, the host agent 211 also replaces the old session key, K_S, with its new one, step 177. If the host agent 211 receives a KO status, the host agent 211 does not replace the value of session key, K_S. Rather, communication with the smart card 101 has been terminated and, in one embodiment, an appropriate message is transmitted to the calling function, e.g., a host computer 103 application program that is accessing the smart card 101.
In both case, i.e., regardless of whether an OK or a KO is received from the card agent 213, the host agent 211 clears all internal state variables used in the key renewal sequence.
In an alternative embodiment, a certain number of retries are allowed by the card agent 213 after which the communication is terminated.
From the foregoing it will be appreciated that the request for and computation of a thumbprint of the host agent 211 further ensures the authenticity and integrity of the host agent 211 thereby improving the security aspects of the use of a smart card 101 as described herein.
From the foregoing it will be appreciated that the aforementioned improvements to the state of the art allow for a more secure communication between a smart card 101 and a host computer 103 to which the smart card 101 is connected. In particular, in a system using a host agent 211 program that is stored on the smart card 101 the aforementioned techniques ensure against tampering of the host agent 211 and ensures the authenticity of the host agent 211.
Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.

Claims

1. A secure portable electronic device for providing secure services when used in conjunction with a host computer having a central processing unit of a first type, the secure portable electronic device having a central processing unit of a second type, wherein a secure service is provided by executing an application in a flexible distributed fashion among the host computer and the secure portable electronic device, comprising:

a read-only memory partition, a read/write memory partition, and a secure memory partition;

a communications interface for securely transmitting and receiving data between the host computer and the secure portable electronic device using a communications protocol over the communications interface, wherein communications between secure portable device and the host computer are secured by encryption using a symmetric key;

instructions stored in the read-only partition, wherein the instructions comprise:

a host agent containing instructions executable by a central processing unit of the first type;

private information stored in the secure memory partition; and

instructions stored in the secure memory partition, comprising:

a card agent containing instructions executable by central processing units of the second type, the instructions including instructions to cause the secure device to:

receive a message from a host agent executing on the host computer requesting to diversify the symmetric key established to secure communication between the host agent executing on the host computer and the card agent executing on the secure device to establish a replacement value for the symmetric key;

in response to receiving a key diversification request, transmit a message to request a thumbprint of the host agent instructions executing on the host computer;

receive a message containing a thumbprint from the host computer;

compare the received thumbprint against a known-to-be-correct thumbprint;

prevent further access to secure data stored on the secure device by the host computer if the received thumbprint does not match the known-to-be-correct thumbprint; and

continue key diversification operations if the received thumbprint matches the known-to-be-correct thumprint;

the host agent comprising instructions including instructions to:

compute a thumbprint; and

transmit the computed thumbprint to the secure device.

2. The secure portable electronic device of claim 1, wherein the thumbprint request comprises an offset; and wherein the host agent comprises thumbprint computation instructions to cause the host computer compute the thumbprint over the host agent instruction code executing on the host computer starting at the offset.

3. The secure portable electronic device of claim 1 wherein the thumbprint request comprises a length parameter and wherein the thumbprint computation instructions further comprise instructions to cause the host computer to compute the thumbprint over a section of the host agent instruction code executing on the host computer and equal in size to the length parameter.

4. The secure portable electronic device of claim 1 wherein the thumbprint request comprises an algorithm indicator and wherein the thumbprint computation instructions further comprise instructions to cause the host computer to compute the thumbprint over a section of the host agent instruction code using an algorithm corresponding to the algorithm indicator.

5. The secure portable electronic device of claim 1 wherein the thumbprint computation instructions comprise instructions to cause the host computer to compute the thumbprint over a section of the host agent instruction code using a hashing algorithm.

6. The secure portable electronic device of claim 1 wherein the card agent further comprises instructions to compute the known-to-correct thumbprint over a section of the host agent instruction code using a hashing algorithm.

7. The secure portable electronic device of claim 1 wherein the card agent further comprises a table of known-to-correct thumbprints each corresponding to thumbprints computed over a particular section of the host agent instruction code.

8. The secure portable electronic device of claim 1 further comprising key obfuscation instructions including instructions to cause the secure device to generate the symmetric key and to write the symmetric key at specified locations in the host agent code.

9. The secure portable electronic device of claim 8 wherein the key obfuscation instructions further comprise instructions to cause the secure device to generate the symmetric key and to write the symmetric key at specified locations in the host agent code at start up of the secure device.

10. The secure portable electronic device of claim 8 the key obfuscation instructions further comprise instructions wherein the instructions to write the symmetric key at specified locations in the host agent code writes the symmetric key beginning at an offset and distributed over the host agent code.

11. The secure portable electronic device of claim 10 the key obfuscation instructions further comprise instructions to cause the secure device to distribute the symmetric key over the host agent code according to a specified increment.

12. The secure portable electronic device of claim 11 wherein the key obfuscation instructions further comprise instructions to cause the secure device to write at least one of the offset and increment into the host agent in a subset of bits of a memory location and randomizing the remaining bits of the memory location.

13. The secure portable electronic device of claim 8 further comprising key recovery instructions in the host agent code to cause the host computer executing the host agent to recover the symmetric key from locations in the host agent code where the secure device has written the symmetric key according to the key obfuscation instructions.

14. The secure portable electronic device of claim 13 wherein the host agent code further comprises instructions to cause the host computer to write the recovered symmetric key into a cryptography key management system of the host computer.

15. The secure portable electronic device of claim 14 wherein host computer includes a Crypto Services API, and the instructions to cause the host computer to write the recovered symmetric key into the cryptography key management system includes calls to the Crypto Services API.

16. The secure portable electronic device of claim 1 wherein the card agent and host agent each further comprise instructions to cause the secure device and the host computer, respectively, to negotiate a replacement value for the symmetric key.

17. The secure portable electronic device of claim 16 wherein the instructions to negotiate a replacement value for the symmetric key comprises using a known shared master secret and a random string to generate the replacement value for the symmetric key.

18. The secure portable electronic device of claim 17

wherein the instructions to negotiate a replacement value for the symmetric key comprises instructions in the card agent to cause the secure device to:

generate the random string;

compute the replacement value for the symmetric key using the master shared secret and the random string;

encrypt the random string using the symmetric key; and

transmit the encrypted random string to the host computer; and

wherein the instructions of negotiate a replacement value for the symmetric key comprises instructions in the host agent to cause the host computer to:

receive the encrypted random string;

decrypt the encrypted random string using the symmetric key; and

compute the replacement value for symmetric key from the master shared secret and the random string.

19. The secure portable electronic device of claim 18

wherein the instructions to negotiate a replacement value for the symmetric key comprises instructions in the card agent to request the host agent to compute the thumbprint according to a specification;

wherein the instructions to negotiate a replacement value for the symmetric key comprises instructions in the host agent to cause the host computer to compute and to encrypt the thumbprint using the replacement value for the symmetric key; and

wherein the instructions to negotiate a replacement value for the symmetric key comprises instructions in the card agent to cause the secure device to decrypt the thumb print using the replacement value for the symmetric key.