Method and system for using a compact disk as a smart key device Number:7,386,736 from the United States Patent and Trademark Office (PTO) owispatent

Title: Method and system for using a compact disk as a smart key device

Abstract: A data processing system accepts a removable storage media, which becomes electrically engaged with a system unit within the data processing system, after which the removable storage media and the hardware security unit mutually authenticate themselves. The removable storage media stores a private key of a first asymmetric cryptographic key pair and a public key of a second asymmetric cryptographic key pair that is associated with the hardware security unit, and the hardware security unit stores a private key of the second asymmetric cryptographic key pair and a public key of the first asymmetric cryptographic key pair that is associated with the removable storage media. In response to successfully performing the mutual authentication operation between the removable storage media and the hardware security unit, the system unit is enabled to invoke cryptographic functions on the hardware security unit while the removable storage media remains engaged with the system unit.

Patent Number: 7,386,736 Issued on 06/10/2008 to Bade,   et al.

---

Inventors:	Bade; Steven A. (Georgetown, TX), Chao; Ching-Yun (Austin, TX)
Assignee:	International Business Machines Corporation (Armonk, NY)
Appl. No.:	11/014,559
Filed:	December 16, 2004

---

Current U.S. Class:	713/194 ; 713/189; 713/192
Field of Search:	713/189,192,194

---

References Cited [Referenced By]

---

U.S. Patent Documents

4218582	August 1980	Hellman et al.
4817140	March 1989	Chandra et al.
5502765	March 1996	Ishiguro et al.
5568552	October 1996	Davis
5604801	February 1997	Dolan et al.
5787172	July 1998	Arnold
5905799	May 1999	Ganesan
6607136	August 2003	Atsmon et al.
6607707	August 2003	Reichman et al.
6615350	September 2003	Schell et al.
2003/0024995	February 2003	Connor et al.
2003/0108205	June 2003	Joyner et al.
2003/0161473	August 2003	Fransdook

Foreign Patent Documents

	WO 00/54126		Sep., 2000		WO
	WO 03/736888		Sep., 2003		WO

Other References

A symmetric cipher using autonomous and non-autonomous cellular automata Srisuchinwong, B.; York, T.A.; Tsalides, P.; Global Telecommunications Conference, 1995. Globecom '95., IEEE vol. 2, Nov. 13-17, 1995 pp. 1172-1177 vol. 2. cited by examiner . Software smart cards via cryptographic camouflage Hoover, D.N.; Kausik, B.N.; Security and Privacy, 1999. Proceedings of the 1999 IEEE Symposium on May 9-12, 1999 pp. 208-215. cited by examiner . Hybrid key establishment for multiphase self-organized sensor networks Kotzanikolaou, P.; Magkos, E.; World of Wireless Mobile and Multimedia Networks, 2005. WoWMoM 2005. Sixth IEEE International Symposium on a Jun. 13-16, 2005 pp. 581-587. cited by examiner.

Primary Examiner: Jung; David
Attorney, Agent or Firm: Talpis; Matt Goshorn; Gregory K. Greg Goshorn, P.C.

---

Claims

---

The invention claimed is:

1. A method for performing cryptographic functions, the method comprising: engaging a removable storage media with a media reading device coupled to a system unit, wherein the system unit includes a hardware security unit and a device driver for controlling the media reading device; and wherein the removable storage media contains a first private key corresponding to a first asymmetric cryptographic key pair and a first public key corresponding to a second asymmetric cryptographic key pair, and wherein the hardware security unit contains a second private key corresponding to the second asymmetric cryptographic key pair and a second public key corresponding to the first asymmetric cryptographic key pair; performing a mutual authentication operation between the removable storage media and the hardware security unit based upon the first and second asymmetric cryptographic key pairs; in response to successfully performing the mutual authentication operation, enabling the system unit to invoke cryptographic functions on the hardware security unit while the removable storage media remains engaged to the media reading device; authenticating an application once the removable storage media has been authenticated and while the removable storage unit remains engaged with the media reading device; generating a digital certificate for the removable storage media by the hardware security unit while the removable storage media remains engaged with the media reading device; digitally signing a data item from the device driver by the hardware security unit in response to a request from the device driver while the removable storage media remains engaged with the media reading device; and performing a cryptographic function by the hardware security unit for the device driver in response to a request from the device driver after successfully performing a mutual authentication operation between the removable storage media and the hardware security unit.

---

Description

---

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to the following applications with a common assignee and are hereby incorporated by reference:

U.S. patent application Ser. No. 10/753,820 filed 01-2004 titled "Method and system for establishing a trust framework based on smart key devices." and U.S. patent application Ser. No. 10/753,818 filed 01-2004 titled "Method and System for Protecting Master Secrets Using Smart Key Devices."

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an improved data processing system and, in particular, to a method and apparatus for data storage protection using cryptography.

2. Description of Related Art

Most data processing systems contain sensitive data that needs to be protected. For example, the data integrity of configuration information needs to be protected from illegitimate modification, while other information, such as a password file, needs to be protected from illegitimate disclosure. An operator of a given data processing system may employ many different types of security mechanisms to protect the data processing system. For example, the operating system on the data processing system may provide various software mechanisms to protect sensitive data, such as various authentication and authorization schemes, while certain hardware devices and software applications may rely upon hardware mechanisms to protect sensitive data, such as hardware security tokens and biometric sensor devices. Even though multiple software and hardware mechanisms may be employed within a given data processing system to protect sensitive data, the sensitive data may also be encrypted so that if someone gains illegitimate access to the encrypted sensitive data, any copy of the encrypted sensitive data would be useless without the ability to decrypt the encrypted sensitive data.

The ability to ultimately protect all information that is contained within the data processing system has limitations, though. For example, in an effort to further protect a password file, the password file may be encrypted using yet another secret, such as a password or a cryptographic key, often referred to as a master secret. However, this new secret also needs to be protected in some manner. Thus, a system administrator may enter a type of dilemma in which any attempt to implement another layer of security results in additional sensitive information that also needs to be protected. Turning now to the present invention, the remaining figures depict exemplary embodiments of the present invention which resolves this dilemma.

Therefore, it would be advantageous to have a mechanism for securely storing and managing secret information, such as cryptographic keys. It would be particularly advantageous to securely store and manage master secrets that are used to protect other secret information.

SUMMARY OF THE INVENTION

A data processing system accepts a removable storage media, which becomes electrically engaged with a system unit within the data processing system, after which the removable storage media and the hardware security unit mutually authenticate themselves. The removable storage media stores a private key of a first asymmetric cryptographic key pair and a public key of a second asymmetric cryptographic key pair that is associated with the hardware security unit, and the hardware security unit stores a private key of the second asymmetric cryptographic key pair and a public key of the first asymmetric cryptographic key pair that is associated with the removable storage media. In response to successfully performing the mutual authentication operation between the removable storage media and the hardware security unit, the system unit is enabled to invoke sensitive cryptographic functions on the hardware security unit while the removable storage media remains engaged with the system unit.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, further objectives, and advantages thereof, will be best understood by reference to the following detailed description when read in conjunction with the accompanying drawings, wherein:

FIG. 1A depicts a typical network of data processing systems, each of which may implement the present invention;

FIG. 1B depicts a typical computer architecture that may be used within a data processing system in which the present invention may be implemented;

FIG. 2 depicts a block diagram that shows a typical manner in which an individual obtains a digital certificate;

FIG. 3 depicts a block diagram that shows a typical manner in which an entity may use a digital certificate to be authenticated to a data processing system;

FIG. 4 depicts a block diagram that shows a portion of a data processing system that accepts a removable hardware device to enable cryptographic functionality in a hardware security unit within the data processing system;

FIG. 5 depicts a block diagram that shows a system unit that contains an internal smart key device and that uses an external smart key device to enable the cryptographic functionality within the internal smart key device;

FIG. 6 depicts a flowchart that shows an overview of a process for enabling the cryptographic functionality of the internal smart key device of a host system;

FIG. 7 depicts a flowchart that shows an overview of a process for enabling the cryptographic functionality of the internal smart key device of a host system for use by a particular software smart key unit;

FIG. 8 depicts a flowchart that shows a process for disabling the cryptographic functionality of the internal smart key device of a host system;

FIGS. 9A-9B depict a pair of flowcharts that show further detail for the mutual authentication procedure that is shown in block 604 of FIG. 6;

FIGS. 10A-10B depict a pair of flowcharts that show further detail for the mutual authentication procedure that is shown in block 704 of FIG. 7;

FIG. 11A depicts a flowchart that shows a process in an internal smart key device for performing operations as requested by a software smart key unit in which the operations are enabled or disabled based on the presence of an external smart key device;

FIG. 11B depicts a flowchart that shows a process in an internal smart key device for performing operations as requested by a software smart key unit in which the operations are not required to be enabled by the presence of an external smart key device;

FIG. 12 depicts a block diagram that shows an embodiment of the present invention for protecting master secrets;

FIGS. 13-15 depict block diagrams that show different relationships between multiple external smart key devices and multiple internal smart key devices;

FIGS. 16A-16C depict block diagrams that show a typical set of trusted relationships;

FIG. 17 depicts a block diagram that shows an example of a trust model that is constructed of trust relationships that are based on the trust provided by internal smart key devices;

FIG. 18 depicts a block diagram that shows a data processing system for generating operating system files in which each programmatic entity in the operating system contains functionality for establishing trust relationships in a trust hierarchy based on internal smart key devices;

FIG. 19 depicts a flowchart that shows a process for generating operating system modules that contain software smart key units such that the operating system modules are able to perform authentication operations with each other;

FIG. 20 depicts a block diagram that shows a data processing system for generating project code in which each programmatic entity contains functionality for establishing trust relationships in a trust hierarchy based on internal smart key devices;

FIG. 21 depicts a flowchart that shows a process for extending the certificate chain for an internal smart key device;

FIG. 22 depicts a block diagram that shows an example of a trust model that is constructed of trust relationships that are based on the trust provided by a single local internal smart key device that maintains a certificate chain containing multiple root certificates for foreign internal smart key devices;

FIG. 23 depicts a flowchart that shows a process for obtaining a current root certificate chain maintained by the local internal smart key device;

FIG. 24 depicts a flowchart that shows a process for determining whether a digital certificate from a foreign internal smart key device is trustworthy;

FIG. 25 depicts a dataflow diagram that shows entities within a hardware-assisted trust model that may be used to ensure the integrity of software modules; and

FIG. 26 depicts a flowchart that shows a process for ensuring the integrity of software modules.

FIG. 27 depicts a block diagram that shows a portion of a data processing system that accepts a removable storage media to enable cryptographic functionality in a hardware security unit within the data processing system;

FIG. 28 depicts a block diagram of a removable storage media that enables the cryptographic functionality within a internal smart key device;

FIG. 29 depicts a block diagram that shows a system unit that contains an internal smart key device and a removable storage media smart key device in conjunction with the removable storage media of FIG. 28 to enable the cryptographic functionality within the internal smart key device;

FIG. 30 depicts a flowchart that shows an overview of a process for enabling the cryptographic functionality of the internal smart key device of a host system;

FIG. 31 depicts a flowchart that shows an overview of a process for enabling the cryptographic functionality of the internal smart key device of a host system for use by a particular removable media; and

FIG. 32 depicts a flowchart that shows a process for disabling the cryptographic functionality of the internal smart key device of a host system.

DETAILED DESCRIPTION OF THE INVENTION

In general, the devices that may comprise or relate to the present invention include a wide variety of data processing technology. Therefore, as background, a typical organization of hardware and software components within a distributed data processing system is described prior to describing the present invention in more detail.

With reference now to the figures, FIG. 1A depicts a typical network of data processing systems, each of which may implement a portion of the present invention. Distributed data processing system 100 contains network 101, which is a medium that may be used to provide communications links between various devices and computers connected together within distributed data processing system 100. Network 101 may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone or wireless communications. In the depicted example, server 102 and server 103 are connected to network 101 along with storage unit 104. In addition, clients 105-107 also are connected to network 101. Clients 105-107 and servers 102-103 may be represented by a variety of computing devices, such as mainframes, personal computers, personal digital assistants (PDAs), etc. Distributed data processing system 100 may include additional servers, clients, routers, other devices, and peer-to-peer architectures that are not shown.

In the depicted example, distributed data processing system 100 may include the Internet with network 101 representing a worldwide collection of networks and gateways that use various protocols to communicate with one another, such as Lightweight Directory Access Protocol (LDAP), Transport Control Protocol/Internet Protocol (TCP/IP), Hypertext Transport Protocol (HTTP), Wireless Application Protocol (WAP), etc. Of course, distributed data processing system 100 may also include a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). For example, server 102 directly supports client 109 and network 110, which incorporates wireless communication links. Network-enabled phone 111 connects to network 110 through wireless link 112, and PDA 113 connects to network 110 through wireless link 114. Phone 111 and PDA 113 can also directly transfer data between themselves across wireless link 115 using an appropriate technology, such as Bluetooth.TM. wireless technology, to create so-called personal area networks (PAN) or personal ad-hoc networks. In a similar manner, PDA 113 can transfer data to PDA 107 via wireless communication link 116.

The present invention could be implemented on a variety of hardware platforms; FIG. 1A is intended as an example of a heterogeneous computing environment and not as an architectural limitation for the present invention.

With reference now to FIG. 1B, a diagram depicts a typical computer architecture of a data processing system, such as those shown in FIG. 1A, in which the present invention may be implemented. Data processing system 120 contains one or more central processing units (CPUs) 122 connected to internal system bus 123, which interconnects random access memory (RAM) 124, read-only memory 126, and input/output adapter 128, which supports various I/O devices, such as printer 130, disk units 132, or other devices not shown, such as an audio output system, etc. System bus 123 also connects communication adapter 134 that provides access to communication link 136. User interface adapter 148 connects various user devices, such as keyboard 140 and mouse 142, or other devices not shown, such as a touch screen, stylus, microphone, etc. Display adapter 144 connects system bus 123 to display device 146.

Those of ordinary skill in the art will appreciate that the hardware in FIG. 1B may vary depending on the system implementation. For example, the system may have one or more processors, such as an Intel.RTM. Pentium.RTM.-based processor and a digital signal processor (DSP), and one or more types of volatile and non-volatile memory. Other peripheral devices may be used in addition to or in place of the hardware depicted in FIG. 1B. The depicted examples are not meant to imply architectural limitations with respect to the present invention.

In addition to being able to be implemented on a variety of hardware platforms, the present invention may be implemented in a variety of software environments. A typical operating system may be used to control program execution within each data processing system. For example, one device may run a Unix.RTM. operating system, while another device contains a simple Java.RTM. runtime environment. A representative computer platform may include a browser, which is a well known software application for accessing hypertext documents in a variety of formats, such as graphic files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), Wireless Markup Language (WML), and various other formats and types of files.

The present invention may be implemented on a variety of hardware and software platforms, as described above with respect to FIG. 1A and FIG. 1B. More specifically, though, the present invention is directed to a mechanism for securing secret information through the use of a hardware security token. Before describing the present invention in more detail, though, some background information about digital certificates is provided for evaluating the operational efficiencies and other advantages of the present invention.

Digital certificates support public key cryptography in which each party involved in a communication or transaction has a pair of keys, called the public key and the private key. Each party's public key is published while the private key is kept secret. Public keys are numbers associated with a particular entity and are intended to be known to everyone who needs to have trusted interactions with that entity. Private keys are numbers that are supposed to be known only to a particular entity, i.e. kept secret. In a typical asymmetric cryptographic system, a private key corresponds to exactly one public key.

Within a public key cryptography system, since all communications involve only public keys and no private key is ever transmitted or shared, confidential messages can be generated using only public information and can be decrypted using only a private key that is in the sole possession of the intended recipient. Furthermore, public key cryptography can be used for authentication, i.e. digital signatures, as well as for privacy, i.e. encryption.

Encryption is the transformation of data into a form unreadable by anyone without a secret decryption key; encryption ensures privacy by keeping the content of the information hidden from anyone for whom it is not intended, even those who can see the encrypted data. Authentication is a process whereby the receiver of a digital message can be confident of the identity of the sender and/or the integrity of the message.

For example, when a sender encrypts a message, the public key of the receiver is used to transform the data within the original message into the contents of the encrypted message. A sender uses a public key of the intended recipient to encrypt data, and the receiver uses its private key to decrypt the encrypted message.

When authenticating data, data can be signed by computing a digital signature from the data using the private key of the signer. Once the data is digitally signed, it can be stored with the identity of the signer and the signature that proves that the data originated from the signer. A signer uses its private key to sign data, and a receiver uses the public key of the signer to verify the signature.

A certificate is a digital document that vouches for the identity and key ownership of entities, such as an individual, a computer system, a specific server running on that system, etc. Certificates are issued by certificate authorities. A certificate authority (CA) is an entity, usually a trusted third party to a transaction, that is trusted to sign or issue certificates for other people or entities. The certificate authority usually has some kind of legal responsibilities for its vouching of the binding between a public key and its owner that allow one to trust the entity that signed a certificate. There are many commercial certificate authorities; these authorities are responsible for verifying the identity and key ownership of an entity when issuing the certificate.

If a certificate authority issues a certificate for an entity, the entity must provide a public key and some information about the entity. A software tool, such as specially equipped Web browsers, may digitally sign this information and send it to the certificate authority. The certificate authority might be a commercial company that provides trusted third-party certificate authority services. The certificate authority will then generate the certificate and return it. The certificate may contain other information, such as a serial number and dates during which the certificate is valid. One part of the value provided by a certificate authority is to serve as a neutral and trusted introduction service, based in part on their verification requirements, which are openly published in their Certification Service Practices (CSP).

A certificate authority creates a new digital certificate by embedding the requesting entity's public key along with other identifying information and then signing the digital certificate with the certificate authority's private key. Anyone who receives the digital certificate during a transaction or communication can then use the public key of the certificate authority to verify the signed public key within the certificate. The intention is that the certificate authority's signature acts as a tamper-proof seal on the digital certificate, thereby assuring the integrity of the data in the certificate.

Other aspects of certificate processing are also standardized. Myers et al., "Internet X.509 Certificate Request Message Format", Internet Engineering Task Force (IETF) Request for Comments (RFC) 2511, March 1999, specifies a format that has been recommended for use whenever a relying party is requesting a certificate from a certificate authority. Adams et al., "Internet X.509 Public Key Infrastructure Certificate Management Protocols", IETF RFC 2511, March 1999, specifies protocols for transferring certificates. The present invention resides in a distributed data processing system that employs digital certificates; the description of FIGS. 2-3 provides background information about typical operations involving digital certificates.

With reference now to FIG. 2, a block diagram depicts a typical manner in which an individual obtains a digital certificate. User 202, operating on some type of client computer, has previously obtained or generated a public/private key pair, e.g., user public key 204 and user private key 206. User 202 generates a request for certificate 208 containing user public key 204 and sends the request to certificate authority 210, which is in possession of CA public key 212 and CA private key 214. Certificate authority 210 verifies the identity of user 202 in some manner and generates X.509 digital certificate 216 containing user public key 218. The entire certificate is signed with CA private key 214; the certificate includes the public key of the user, the name associated with the user, and other attributes. User 202 receives newly generated digital certificate 216, and user 202 may then present digital certificate 216 as necessary to engage in trusted transactions or trusted communications. An entity that receives digital certificate 216 from user 202 may verify the signature of the certificate authority by using CA public key 212, which is published and available to the verifying entity.

With reference now to FIG. 3, a block diagram depicts a typical manner in which an entity may use a digital certificate to be authenticated to a data processing system. User 302 possesses X.509 digital certificate 304, which is transmitted to an Internet or intranet application 306 on host system 308; application 306 comprises X.509 functionality for processing and using digital certificates. User 302 signs or encrypts data that it sends to application 306 with its private key.

The entity that receives certificate 304 may be an application, a system, a subsystem, etc. Certificate 304 contains a subject name or subject identifier that identifies user 302 to application 306, which may perform some type of service for user 302. The entity that uses certificate 304 verifies the authenticity of the certificate before using the certificate with respect to the signed or encrypted data from user 302.

Host system 308 may also contain system registry 310 which is used to authorize user 302 for accessing services and resources within system 308, i.e. to reconcile a user's identity with user privileges. For example, a system administrator may have configured a user's identity to belong to certain a security group, and the user is restricted to being able to access only those resources that are configured to be available to the security group as a whole. Various well-known methods for imposing an authorization scheme may be employed within the system.

In order to properly validate or verify a digital certificate, an application must check whether the certificate has been revoked. When the certificate authority issues the certificate, the certificate authority generates a unique serial number by which the certificate is to be identified, and this serial number is stored within the "Serial Number" field within an X.509 certificate. Typically, a revoked X.509 certificate is identified within a CRL via the certificate's serial number; a revoked certificate's serial number appears within a list of serial numbers within the CRL.

In order to determine whether certificate 304 is still valid, application 306 obtains a certificate revocation list (CRL) from CRL repository 312 and validates the CRL. Application 306 compares the serial number within certificate 304 with the list of serial numbers within the retrieved CRL, and if there are no matching serial numbers, then application 306 validates certificate 304. If the CRL has a matching serial number, then certificate 304 should be rejected, and application 306 can take appropriate measures to reject the user's request for access to any controlled resources.

Most data processing systems contain sensitive data that needs to be protected. For example, the data integrity of configuration information needs to be protected from illegitimate modification, while other information, such as a password file, needs to be protected from illegitimate disclosure. An operator of a given data processing system may employ many different types of security mechanisms to protect the data processing system. For example, the operating system on the data processing system may provide various software mechanisms to protect sensitive data, such as various authentication and authorization schemes, while certain hardware devices and software applications may rely upon hardware mechanisms to protect sensitive data, such as hardware security tokens and biometric sensor devices. Even though multiple software and hardware mechanisms may be employed within a given data processing system to protect sensitive data, the sensitive data may also be encrypted so that if someone gains illegitimate access to the encrypted sensitive data, any copy of the encrypted sensitive data would be useless without the ability to decrypt the encrypted sensitive data.

The ability to ultimately protect all information that is contained within the data processing system has limitations, though. For example, in an effort to further protect a password file, the password file may be encrypted using yet another secret, such as a password or a cryptographic key, often referred to as a master secret. However, this new secret also needs to be protected in some manner. Thus, a system administrator may enter a type of dilemma in which any attempt to implement another layer of security results in additional sensitive information that also needs to be protected. Turning now to the present invention, the remaining figures depict exemplary embodiments of the present invention which resolves this dilemma.

With reference now to FIG. 4, a block diagram depicts a portion of a data processing system that accepts a removable hardware device to enable cryptographic functionality in a hardware security unit within the data processing system in accordance with an embodiment of the present invention. The present invention employs a pair of matching smart key devices that hold cryptographic keys and perform encryption functions. System unit 402 interfaces with external smart key device (EXSKD) 404, which is a portable or removable device. System unit 402 also contains internal smart key device (INSKD) 406, which is a matching device that is an integral part of the host system that receives the removable device, such as a motherboard. The internal smart key device is preferably a packaged, integrated circuit that is difficult to remove from the host system; while it may be described as a hardware security unit or device, it may also comprise a processing unit for executing instructions. In this example, EXSKD 404 and INSKD 406 are paired devices. The removable device is physically secured by system administration personnel, e.g., an IT administrator; the removable device, i.e. EXSKD 404, is inserted into a host machine, such as system unit 402, when an IT administrator needs to enable certain cryptographic functions that can only be performed by the matching device on the host machine, i.e. INSKD 406. In other words, certain cryptographic functions are available when the external smart key device is inserted into the system unit. Only INSKD 406 can produce the results that are needed by the IT administrator because only INSKD 406 contains one or more particular cryptographic private keys for producing certain cryptographic output. Application 408 on system unit 402 has software smart key unit (SWSKU) 410 that is analogous to EXSKD 404 and INSKD 406. Application 408 uses SWSKU 410 to perform certain functions, which are explained in more detail below.

With reference now to FIG. 5, a block diagram depicts a system unit that contains an internal smart key device and that uses an external smart key device to enable the cryptographic functionality within the internal smart key device in accordance with an embodiment of the present invention. FIG. 5 is similar to FIG. 4 except that FIG. 5 includes additional detail on the cryptographic keys that are stored within the various components.

External smart key device (EXSKD) 502 is a removable hardware device; EXSKD 502 is preferably a portable device that is controlled by a system administrator and that acts as hardware security token. External smart key device 502 with electrical interface 504 is insertable into system unit 506 with electrical interface 508; external smart key device 502 and system unit 506 electrically engage through their respective interfaces to exchange electrical signals representing digital information.

External smart key device 502 contains cryptographic engine 510 for performing cryptographic functions using various data items that are stored in external smart key device 502. EXSKD private key 512 is stored in a manner such that it cannot be read or accessed by entities that are external to EXSKD 502; EXSDK 502 does not contain functionality for transmitting or otherwise providing a copy of EXSKD private key 512. EXSKD public key certificate 514 contains a copy of EXSKD public key 516 that corresponds to EXSKD private key 512 as an asymmetric cryptographic key pair. EXSKD 502 also contains a copy of INSKD public key certificate 518, which itself contains a copy of INSKD public key 520 that corresponds to INSKD private key 526 as an asymmetric cryptographic key pair. The copy of INSKD public key certificate 518 may be written onto EXSKD 502 as part of its manufacturing or initialization processes.

System unit 506 contains internal smart key device (INSKD) 522. Internal smart key device 522 contains cryptographic engine 524 for performing cryptographic functions using various data items that are stored in internal smart key device 522. INSKD private key 526 is stored in a manner such that it cannot be read or accessed by entities that are external to INSKD 522; INSKD 522 does not contain functionality for transmitting or otherwise providing a copy of INSKD private key 526. INSKD public key certificate 528 contains a copy of INSKD public key 530 that corresponds to INSKD private key 526 as an asymmetric cryptographic key pair. INSKD 522 also contains a copy of EXSKD public key certificate 532, which itself contains a copy of INSKD public key 534 that corresponds to EXSKD private key 512 as an asymmetric cryptographic key pair. The copy of EXSKD public key certificate 532 may be written into INSKD 522 as part of its manufacturing or initialization processes.

In alternative embodiments, INSKD private key 526 and INSKD public key 530 may be used for other functions. In a preferred embodiment as shown in FIG. 5, INSKD private key 526 and INSKD public key 530 are reserved for communications between INSKD 522 and EXSKD 502 while INSKD 522 employs one or more other cryptographic key pairs for other functions. In this example, INSKD_SW private key 536 is used by INSKD 522 for securing communications between INSKD 522 and software smart key unit (SWSKU) 538 in application 540. INSKD_SW public key certificate 542 contains a copy of INSKD_SW public key 544 that corresponds to INSKD_SW private key 536 as an asymmetric cryptographic key pair. INSKD 522 also contains a copy of SWSKU public key certificate 546, which itself contains a copy of SWSKU public key 548 that corresponds to SWSKU private key 550 as an asymmetric cryptographic key pair.

System unit 506 supports execution of application 540 that contains SWSKU 538, which itself contains cryptographic engine 552 for performing cryptographic functions using various data items that are stored in software smart key unit 538. SWSKU 538 does not contain functionality for transmitting or otherwise providing a copy of SWSKU private key 550. SWSKU public key certificate 554 contains a copy of SWSKU public key 556 that corresponds to SWSKU private key 550 as an asymmetric cryptographic key pair. SWSKU 538 also contains a copy of INSKD_SW public key certificate 558, which itself contains a copy of INSKD_SW public key 560 that corresponds to INSKD_SW private key 536 as an asymmetric cryptographic key pair. As explained in more detail further below, SWSKU 538 may be digitally signed. In the example that is shown in FIG. 5, SWSKU 538 contains digital signature 562 that has been computed over SWSKU 538 using INSKD_SW private key 536; in other words, INSKD 522 has digitally signed SWSKU 538 using INSKD_SW private key 536.

With reference now to FIG. 6, a flowchart depicts an overview of a process for enabling the cryptographic functionality of the internal smart key device of a host system. The process commences in a block 602 when the external smart key device is electrically engaged with a system unit that includes an internal smart key device. For example, an IT administrator may insert the external smart key device into a receiving unit that includes a slot for receiving the external smart key device. The internal smart key device and the external smart key device then, during a block 604, perform a mutual authentication procedure, after which, during a block 606, the internal smart key device is enabled to perform cryptographic functions, and the process is concluded. It may be assumed that any error in the mutual authentication procedure results in the continued disablement of the internal smart key device. In a less restrictive embodiment, the cryptographic functions of the internal smart key device may then be invoked by any application that is running on the host system. In a more restrictive embodiment, the cryptographic functions of the internal smart key device may be invoked only by an application that includes a software smart key unit, as shown in FIG. 7.

With reference now to FIG. 7, a flowchart depicts a process for enabling the cryptographic functionality of the internal smart key device of a host system for use by a particular software smart key unit in accordance with an embodiment of the present invention. The process commences in a block 702 when an application or an applet containing a software smart key unit invokes a cryptographic function of the internal smart key device, e.g., through an application programming interface (API). The internal smart key device and the software smart key unit then, during a block 704, perform a mutual authentication procedure, after which, during a block 706, the internal smart key device is enabled to perform cryptographic functions for the software smart key unit, and the process is concluded. Assuming that multiple software smart key units on a host system have completed a mutual authentication procedure with the internal smart key device, then the internal smart key device may be simultaneously enabled to perform cryptographic functions on behalf of the multiple software smart key units.

While the external smart key device remains engaged with the system unit containing the internal smart key device, the internal smart key device is enabled to provide functionality to act as a certificate authority, i.e. generate new public certificates. In one embodiment, the external smart key device should be engaged with the system unit containing the internal smart key device when installing a new software package. A new public certificate may be issued to the new software package during the software installation; the private key that corresponds to the public key in the newly issued digital certificate may be embedded within the software package, and the private key may be protected by having the internal smart key device sign the software package. Furthermore, in a Java.RTM. environment, a JAR file and the Java.RTM. package in which the private key is embedded may be further sealed to prevent a malicious user from tampering with the private key.

With reference now to FIG. 8, a flowchart depicts a process for disabling the cryptographic functionality of the internal smart key device of a host system in accordance with an embodiment of the present invention. The process commences in a block 802 when the external smart key device is electrically disengaged from the system unit containing the internal smart key device, e.g., at some subsequent point in time after the external smart key device had been inserted and the internal smart key device had been enabled. When the system unit detects the disengagement of the external smart key device, then, during a block 804, the internal smart key device becomes disabled from further performing cryptographic functions, and the process is concluded.

The process that is shown in FIG. 8 operates as a complementary process to either of the processes that are shown in FIG. 6 or FIG. 7. It should be noted, though, that the internal smart key device may still perform some functions such that it is not completely disabled, depending on the implementation of the present invention. It may be assumed that the cryptographic functionality in the internal smart key device may be enabled or disabled through software or hardware. For example, in a hardware mode, the operation of particular circuitry in the internal smart key device might be prevented from entering an operable state by certain flip-flops or other mechanisms that must be set or cleared based on an enablement state that represents whether the external smart key device has been accepted; in a software mode, the operation of certain cryptographic functions may be protected by setting and clearing special enablement flags that logically control the execution of the cryptographic functions.

With reference now to FIGS. 9A-9B, a pair of flowcharts depicts further detail for the mutual authentication procedure that is shown in block 604 of FIG. 6. FIG. 9A depicts the process for the internal smart key device to authenticate the external smart key device, while FIG. 9B depicts the process for the external smart key device to authenticate the internal smart key device. The process that is shown in FIG. 9A may be performed prior to the process that is shown in FIG. 9B or vice versa; depending on the manner in which the present invention is implemented, the processes may be independent and/or may be performed simultaneously, e.g., through appropriate signals or status flags that indicate the operations that are being attempted.

Referring now to FIG. 9A, the process commences in a block 902 when the internal smart key device uses the public key of the external smart key device to encrypt a message, e.g., a random text string. During a block 904, the internal smart key device, through the appropriate interface of the host system, transfers the encrypted message to the external smart key device, which then, during a block 906, decrypts the encrypted message with its private key. The external smart key device then, during a block 908, encrypts the decrypted message with the public key of the internal smart key device and passes, during a block 910, the encrypted message to the internal smart key device. The internal smart key device then, during a block 912, decrypts the encrypted message with its private key and, during a block 914, compares the received message with its original message. If the two messages match, then, during a block 916, the internal smart key device provides an indication, e.g., with an appropriate signal or by setting a logical flag variable, that the internal smart key device has determined that the external smart key device is authentic, thereby concluding the process.

Referring now to FIG. 9B, the process commences in a block 922 when the external smart key device uses the public key of the internal smart key device to encrypt a message, e.g., a random text string. During a block 924, the external smart key device transfers the encrypted message to the internal smart key device, which then, during a block 926, decrypts the encrypted message with its private key. The internal smart key device then, during a block 928, encrypts the decrypted message with the public key of the external smart key device and, during a block 930, passes the encrypted message to the external smart key device. The external smart key device then, during a block 932, decrypts the encrypted message with its private key and, during a block 934, compares the received message with its original message. If the two messages match, then, during a block 936, the external smart key device provides an indication, e.g., with an appropriate signal or by setting a logical flag variable, that the external smart key device has determined that the internal smart key device is authentic, thereby concluding the process.

With reference now to FIGS. 10A-10B, a pair of flowcharts depicts further detail for the mutual authentication procedure that is shown in block 704 of FIG. 7. FIG. 10A depicts the process for the software smart key unit to authenticate the internal smart key device, while FIG. 10B depicts the process for the internal smart key device to authenticate the software smart key unit. The process that is shown in FIG. 10A may be performed prior to the process that is shown in FIG. 10B or vice versa; depending on the manner in which the present invention is implemented, the processes may be independent and/or may be performed simultaneously, e.g., through appropriate messages or status flags that indicate the operations that are being attempted.

Referring now to FIG. 10A, the process commences in a block 1002 when the software smart key unit uses the public key of the internal smart key device to encrypt a message, e.g., a random text string. During a block 1004, the software smart key unit transfers the encrypted message to the internal smart key device, which then, during a block 1006, decrypts the encrypted message with its private key. The internal smart key device then, during a block 1008, encrypts the decrypted message with the public key of the software smart key unit and, during a block 1010, passes the encrypted message to the software smart key unit. The software smart key unit then, during a block 1012, decrypts the encrypted message with its private key and, during a block 1014, compares the received message with its original message. If the two messages match, then, during a block 1016, the software smart key unit provides an indication, e.g., with an appropriate message or by setting a logical flag variable, that the software smart key unit has determined that the internal smart key device is authentic, thereby concluding the process.

In contrast to FIG. 10A, FIG. 10B illustrates the use of a session key instead of a random text string as the message that is passed between the two entities. The session key is to be used for securing subsequent message traffic during a session between the two entities if the mutual authentication process between the two entities is successfully completed; the session may be timed, or the session may terminated by a particular event, such as the termination of the execution of a software entity or the power shutdown of a hardware entity. The session key may be placed within a larger message containing other information prior to encryption, whereafter the encrypted message is passed between the two entities. In an alternative embodiment, a random text string may be used for the authentication procedure, after which the two entities may exchange a session key. As explained in more detail further below, additional information may be securely passed between the two entities during the authentication process to reduce the number of actions that are used to exchange information.

Referring now to FIG. 10B, the process commences in a block 1022 when the internal smart key device uses the public key of the software smart key unit to encrypt a session key. During a block 1024, the internal smart key device transfers the encrypted session key to the software smart key unit, which then, during a block 1026, decrypts the encrypted session key with its private key. The software smart key unit then, during a block 1028, encrypts the decrypted session key with the public key of the internal smart key device and, during a block 1030, passes the encrypted session key to the internal smart key device. The internal smart key device then, during a block 1032, decrypts the encrypted session key with its private key and, during a block 1034, compares the received session key with its original session key. If the two versions of the session key match, then, during a block 1036, the internal smart key device provides an indication, e.g., with an appropriate message or by setting a logical flag variable, that the internal smart key device has determined that the software smart key unit is authentic, thereby concluding the process.

Additional security actions may be performed in conjunction with the process that is shown in FIG. 7. For example, at block 702, an application or an applet has requested the use of functionality embedded in the internal smart key device. At some point in time, prior to starting the process that is shown in FIG. 10B, the internal smart key device may perform an additional action of verifying whether the software smart key unit in the requesting application or applet contains secure code. As mentioned above with respect to FIG. 5, SWSKU 538 may be digitally signed; SWSKU 538 contains digital signature 562 that has been computed over SWSKU 538 using INSKD_SW private key 536. Hence, the internal smart key device may verify whether or not the software smart key unit in the requesting application or applet contains secure code by verifying the digital signature associated with the software smart key unit.

In a Java.RTM. environment, the software smart key unit may be implemented as a signed JAR file; in one embodiment, the internal smart key device is used to verify the digital signature of the signed JAR file. In a different embodiment, the JAR file and the Java.RTM. package may be further sealed so that the class loader would enforce that all code in the package should be loaded from the sealed JAR file. The act of sealing the JAR file and the Java.RTM. package can prevent functionality from being modified by malicious users via injecting code into the class path. Moreover, the class loader itself may be signed and sealed such that the integrity of the class loader can be verified.

In a more generic computational environment, while internal smart key device may digitally sign a software smart key unit and later validate the digital signature, the process of ensuring that the software smart key unit is signed and validated may be controlled by an appropriate operating system module within the data processing system with assistance from the internal smart key device, e.g., a program loader that loads software modules for execution. Prior to allowing the software module to execute, the program loader could perform additional security processes. Moreover, the program loader itself may be signed and sealed such that the integrity of the program loader can be verified.

Although the above-mentioned process provides a mechanism for ensuring the integrity of the software smart key unit, the operations of the software smart key unit within a data processing system may still be regarded as somewhat vulnerable because its cryptographic keys may be viewed and copied by inspecting the code that comprises the software smart key unit; it may be assumed that the cryptographic keys are stored in the clear within the software smart key unit.

Hence, in order to protect the software smart key unit, in particular its private key, yet another security action may be performed in conjunction with the process that is shown in FIG. 7. At some prior point in time, the software smart key unit can be encrypted, thereby concealing any sensitive information within the software smart key unit, particularly its private key. In a different embodiment, a software module that includes a software smart key unit could be encrypted. For example, when a software module is installed on a data processing system, the internal smart key device on the data processing system could encrypt the software module as part of the installation procedure for the application program that includes the software module.

In a system in which this additional action is performed, then the software smart key unit and/or a software module that includes the software smart key unit would require decryption before it could be executed. At a point in time similar to that described above with respect to protecting the integrity of the software smart key unit using digital signatures, e.g., at some point in time prior to starting the process that is shown in FIG. 10B, the internal smart key device would perform an additional action of decrypting the software smart key unit and/or the software module that includes the software smart key unit. Again, in a manner similar to that described above, the decryption process may be controlled by an appropriate operating system module within the data processing system with assistance from the internal smart key device. Further detail about the process of modifying software modules upon installation for use in conjunction with an internal smart key device and about the process of executing such software modules in a secure manner is provided below.

With reference now to FIG. 11A, a flowchart depicts a process in an internal smart key device for performing operations as requested by a software smart key unit in which the operations are enabled or disabled based on the presence of an external smart key device. The process commences in a block 1102 when the internal smart key device receives a request message from the software smart key unit; the request message contains a message-type variable that indicates the type of operation that is being requested by the software smart key unit. During a block 1104, a determination is then made as to whether or not the software smart key unit has been authenticated by the internal smart key device; the determination may be performed by successfully decrypting the contents of the received message using the session key that the internal smart key device passed to the software smart key unit during a prior authentication procedure, e.g., as described above with respect to FIG. 10B. If the software smart key unit has not been authenticated, then, during a block 1106, the internal smart key device generates an appropriate error response and, during a block 1108, returns the response message to the requesting software smart key unit, thereby concluding the process.

If the software smart key unit has been authenticated, then, during a block 1110, the internal smart key device determines if the external smart key device is still electrically engaged with the system unit. For example, the determination may merely entail checking a special register that would have been cleared had the electrical connection between the system unit and the external smart key device been broken. If the external smart key device is not electrically engaged with the system unit, then the internal smart key device generates an error response at block 1106 and returns the response message to the software smart key unit at block 1108, thereby concluding the process.

If the software smart key unit has been authenticated and the external smart key device is still electrically engaged with the system unit, then the internal smart key device performs the requested function for the software smart key unit, if possible. Block 1112 and block 1114 depict examples of functionality that may be provided by an internal smart key device; the enumeration of these examples does not imply that other functions may not be available in other implementations of the present invention. In a preferred embodiment, the internal smart key device performs the following functions only if the external smart key device remains electrically engaged with the internal smart key device after mutual authentication: issuing new digital certificates while acting as a certificate authority; and signing a software module using a private key of the internal smart key device, wherein the private key corresponds to an available public key certificate. It should be noted that the present invention does not allow any interface for retrieving a private key of the internal smart key device; hence, performing a signing operation using its private key can only be performed by the internal smart key device.

If the software smart key unit has requested a digital signature on a data item that was embedded within the request message, then, during a block 1112, the internal smart key device computes a digital signature over the data item using an appropriate private key and inserts the digitally signature (preferably, along with the copy of the data item that it returns) into the response message. If the software smart key unit has requested a digital certificate, then, during a block 1114, the internal smart key device generates a digital certificate using an appropriate private key and inserts the digital certificate into the response message; the digital certificate may include various identifying information that was provided by the software smart key unit within the request message. After the appropriate response message has been generated, which would include encrypting any sensitive data with the appropriate session key, the response message is returned to the software smart key unit at block 1108, and the process is concluded.

Referring again to block 1112, any type of digital data item may be signed. Referring again to FIG. 4, application 408 represents many different types of applications that may incorporate the functionality of the present invention. In one embodiment, the application may be an application server that sig