KR100883442B1 - Method of delivering direct proof private keys to devices using an on-line service - Google Patents

Abstract

Passing a direct proof secret key to a device installed in a client computer system in the field can be accomplished in a secure manner without requiring significant nonvolatile storage on the device. Unique pseudo random values are generated and stored in the device at the time of manufacture. The pseudorandom value is used to generate a symmetric key that encrypts the data structure holding the direct proof secret and secret key digest associated with the device. The resulting encrypted data structure is stored on a protected online server accessible by the client computer system. When a device is launched on a client computer system, the system checks whether a local encrypted data structure exists in the system. If no local encrypted data structure exists, the system uses a secure protocol to obtain the relevant encrypted data structure from the protected online server. The device decrypts the encrypted data structure using the symmetric key regenerated from the stored pseudorandom value to obtain the proof secret key directly. If the secret key is valid, it can be used for subsequent authentication processing by a device in the client computer system.

Description

METHOOD OF DELIVERING DIRECT PROOF PRIVATE KEYS TO DEVICES USING AN ON-LINE SERVICE}

FIELD OF THE INVENTION The present invention generally relates to computer security, and more particularly to securely distributing cryptographic keys to devices in a processing system.

Some processing system architectures that support content protection and / or computer security features include specially protected or "trusted" hardware devices in which specially protected or "trusted" software modules are present in the processing system (such as a graphics controller card). Requires that an authenticated encrypted communication session be created. One method commonly used to identify devices and simultaneously create encrypted communication sessions is to use an authenticated Diffe-Helman (DH) key exchange process. In this process, the device is assigned a unique public / secret RSA (Rivest, Shamir and Adelman) algorithm key pair or a unique Elliptic Curve Cryptography (ECC) key pair. However, since this authentication process uses RSA or ECC keys, the device has a unique verifiable identity, which can create privacy concerns. In the worst case, these concerns may result in a lack of support from original equipment manufacturers (OEMs) building reliable devices that provide that kind of security.

The features and advantages of the present invention will become apparent from the following detailed description of the invention.

1 illustrates a system featuring a platform implemented with a Trusted Platform Module (TPM) operating in accordance with one embodiment of the present invention.

FIG. 2 shows a first embodiment of a platform including the TPM of FIG. 1.

3 illustrates a second embodiment of a platform including the TPM of FIG. 1.

4 illustrates an example embodiment of a computer system implemented with the TPM of FIG. 2.

5 is a diagram of a system for distributing Direct Proof keys to a device using an online service in accordance with an embodiment of the present invention.

6 is a flow chart illustrating the steps of a method for directly distributing an attestation key using an online service in accordance with an embodiment of the present invention.

7 is a flow diagram illustrating protection server setup processing in accordance with an embodiment of the present invention.

8 is a flowchart illustrating device manufacturer setup processing in accordance with an embodiment of the present invention.

9 is a flowchart illustrating device manufacturer manufacturing processing in accordance with an embodiment of the present invention.

10-12 are flowcharts of client computer system setup processing in accordance with an embodiment of the present invention.

13 is a flowchart of client computer system processing in accordance with an embodiment of the present invention.

Use a direct proof-based DH key exchange protocol to prevent the generation of any unique identity information in the processing system so that protected / trusted devices can authenticate themselves and establish encrypted communication sessions using trusted software modules. This can prevent the privacy problem from incurring. However, embedding the direct proof secret key directly into the device in the manufacturing line requires more protected nonvolatile storage on the device than other approaches, leading to increased device costs. Embodiments of the present invention can be used to deliver a direct proof (DP) secret key (eg, used for signing) to a device in a secure manner using an online service, and subsequently to be installed on a per device basis. That's how it is. The method provided by the present invention is designed such that the device does not need to reveal identification information for the installation process. In one embodiment, the device storage required to support this capability may be reduced from approximately 300 to 700 bytes to approximately 40 bytes. By reducing the nonvolatile storage required to implement direct evidence-based DH key exchange for the device, this technique becomes more widely applicable.

In an embodiment of the invention, the DP secret signing key is not distributed in or with the device. Instead, the device in the field supports a protocol that allows the device to retrieve its private key securely from an online protection server provided by the manufacturer or vendor, or delegate. This protocol creates a trust channel between the device and the server and does not require trust in any intervening software, including software on the local processing system.

Reference in the specification to “one embodiment” or “an embodiment” of the present invention means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the phrase phrase "in one embodiment" appearing in various places throughout the specification is not necessarily all referring to the same embodiment.

In the description below, certain terms are used to describe any feature of one or more embodiments of the present invention. For example, a "platform" is defined as any type of communication device that is adapted to sending and receiving information. Examples of various platforms include, but are not limited to, computer systems, personal digital assistants, cellular telephones, set top boxes, facsimile machines, printers, modems, routers, and the like. "Communication link" is broadly defined as one or more information transfer media applied to a platform. Examples of various types of communication links include, but are not limited to, electrical wiring (s), optical fiber (s), cable (s), bus trace (s), or wireless signal technology.

A "challenger" refers to any entity (eg, person, platform, system, software and / or device) that requests some verification of certainty or authority from another entity. Normally this is done before revealing or providing the requested information. "Responder" refers to any entity that has been asked to provide some proof of authority, validity and / or identity. "Device Manufacturer", which may be used interchangeably with "Authentication Manufacturer", refers to any entity that manufactures or configures a platform or device.

As used herein, to “challenge” or “confirm” a challenger that a responder owns or recognizes some cryptographic information (eg, a signature, a secret such as a key, etc.), the information and attestation exposed to the challenger. Based on this, it is likely that the responder has a high degree of encryption information. Proving this to the challenger without "leaking" or "disclosing" the encryption information to the challenger means that it is computationally impossible for the challenger to determine the encryption information based on the information disclosed to the challenger.

Such proof is hereinafter referred to as direct proof. The term "direct proof" is referred to as zero-knowledge proof, and these types of proof are commonly known in the art. In particular, certain direct attestation protocols referenced herein are assigned to the applicant, filed on November 27, 2002, and co-pending US patent titled "System and Method for Establishing Trust Without Reavealing Identity". The subject matter of application number 10 / 306,336. Direct attestation defines a protocol in which the issuer defines a family of many members that share common characteristics defined by the issuer. The issuer creates family public and private key pairs (Fpub and Fpri) that represent the family as a whole. Using Fpri, the issuer can also generate a unique direct proof secret signing key (DPpri) for each member of the family. Any message signed by an individual DPpri can be verified using a family public key (Fpub). However, such verification only identifies that the signer is a member of the family, and uniquely identifying information about an individual member is not exposed. In one embodiment, the issuer may be a device manufacturer or delegate. That is, the issuer may be an entity that can define a device family based on shared properties, generate a family public / private key pair, and insert a DP secret key into the device. The issuer may also generate a certificate for the family public key that identifies the source of the key and the characteristics of the device family.

Referring now to FIG. 1, shown is an embodiment of a system featuring a platform implemented with a trusted hardware device (called a “trust platform module” or “TPM”) operating in accordance with one embodiment of the present invention. The first platform 102 (challenger) sends a request 106 for the second platform 104 (responder) to provide information about itself. In response to the request 106, the second platform 104 provides the requested information 108.

Additionally, to increase security, the first platform 102 may be configured by the requested device manufacturer or a selected group of device manufacturers (hereinafter referred to as "device manufacturer (s) 110). There is a need to verify that it is sent from the manufactured device, for example, for one embodiment of the present invention, the first platform 102 may encrypt the requested information generated by the device manufacturer (s) 110. Ask the second platform to show that it has information (eg, a signature) This request can be inserted into the request 106 (as shown) or sent separately. In response to the request by providing the information in response form, assure the first platform that the second platform 104 has the cryptographic information generated by the device manufacturer (s) 110 without leaking the cryptographic information. Let's do it. Based response may be part of the information 108 requested (as illustrated) it can be transmitted separately.

In one embodiment of the invention, the second platform 104 includes a Trusted Platform Module (TPM) 115. TPM 115 is a cryptographic device manufactured by device manufacturer (s) 110. In one embodiment of the invention, the TPM 115 includes a processor with a small amount of on-chip memory sealed in a package. TPM 115 provides the first platform 102 with information to enable the TPM to determine if a response is sent from the valid TPM. The information used is content such that the identity of the TPM or the identity of the second platform cannot be determined.

2 shows a first embodiment of a second platform 104 with a TPM 115. In this embodiment of the present invention, the second platform 104 includes a processor 202 connected to the TPM 115. Generally, processor 202 is a device that processes information. For example, in one embodiment of the present invention, processor 202 may be implemented as a microprocessor, digital signal processor, micro-controller, or even a state machine. Alternatively, in another embodiment of the present invention, processor 202 may include programmable or hardcoded logic, such as field programmable gate arrays (FPGAs), transistor-transistor logic (TTL) logic, or even an application specific integrated circuit. It can also be implemented as).

In this specification, the second platform 104 further includes a storage unit 206 that can store cryptographic information, such as one or more keys, hash values, signatures, certificates, and the like. The hash value of "X" may be expressed as "Hash (X)". It is anticipated that such information may be stored in the internal memory of the TPM 115 instead of the storage unit 206 as shown in FIG. 3. The encryption information can be encrypted, especially if stored outside the TPM.

4 illustrates an embodiment of a platform that includes a computer system 300 implemented with the TPM 115 of FIG. 2. Computer system 300 includes a bus 302 and a processor 310 connected to the bus 302. Computer system 300 further includes a main memory unit 304 and a static memory unit 306.

In this specification, the main memory unit 304 is a volatile semiconductor memory that stores instructions and information executed by the processor 310. Main memory 304 may also be used to store temporary variables or other intermediate information while processor 310 executes instructions. The static memory unit 306 is a nonvolatile semiconductor memory that stores instructions and information for the processor 310 more permanently. Examples of static memory 306 include, but are not limited to, read-only memory (ROM). Both main memory unit 304 and static memory unit 306 are connected to bus 302.

In one embodiment of the invention, computer system 300 also includes a data storage device 308, such as a magnetic disk or an optical disk, and a corresponding drive is also connected to computer system 300 that stores information and instructions. Can be.

Computer system 300 is also connected to graphics controller device 314 via bus 302, which may be a cathode ray tube (CRT), liquid crystal display (LCD) or any display of information to an end user. Controls a display (not shown), such as a flat panel display. In one embodiment, it may be desirable to enable the graphics controller to establish an authenticated encrypted communication session using a software module executed by a processor.

Typically, alphanumeric input device 316 (eg, keyboard, keypad, etc.) may be connected to bus 302 which communicates information and / or command selection with processor 310. Another type of user input device is a cursor control unit 318 such as a mouse, trackball, touch pad, stylus, or a cursor that communicates direction information and command selection with the processor 310 and controls the movement of the cursor on the display 314. Arrow keys.

The communication interface unit 320 is also connected to the bus 302. Examples of interface unit 320 include a modem, network interface card, or other known interface used to connect to a communication link that forms part of a local or wide area network. In this manner, computer system 300 may be connected to multiple clients and / or servers via conventional network infrastructure, such as, for example, corporate intranets and / or the Internet. In one embodiment, the computer system may be connected with a protection server online via a network.

It is understood that some of the aforementioned embedded computer systems may be desirable for any implementation. Thus, the configuration of computer system 300 will vary in implementation depending on a number of factors such as price constraints, performance requirements, technical improvements, and / or other circumstances.

In at least one embodiment, computer system 300 is stored in main memory 304 and / or mass storage device 308 and executed by processor 310 to perform certain activities, even if other hostile software is present in the system. May support the use of specially protected “trusted” software modules (eg, strain-suppressing software, or systems having the ability to run protected programs) to perform the following. Some of these trusted software modules do not require equivalent "trusted" protected access to other platforms, but rather to one or more peripheral devices within the same platform, such as graphics controller 314. In general, such access allows the trusted software module to identify the device's capabilities and / or specific identities, and then exchange data that cannot be snooped or spoofed by other software in the system. It requires establishing an encryption session using a device that enables it.

One conventional method of identifying a device and at the same time establishing an encryption session is that one uses an authenticated DH key exchange process. In this process, the device is assigned a unique public / secret RSA or ECC key pair. The device maintains and protects the private key, but the public key can be disclosed to the software module with authenticating the certificate. During the DH key exchange process, the device signs the message using the private key, and the software module can verify it using the corresponding public key. This allows the software module to authenticate that the message actually originated from the device of interest.

However, because this authentication process uses an RSA or ECC key, the device has a unique and verifiable identity. Any software module that can allow a device to sign a message with a secret key can verify that it exists in this particular unique device car computer system. Assuming that devices rarely move between processing systems, this also represents a verifiable unique computer system identity. In addition, the device's public key itself represents a constant unique value, effectively a permanent "cookie". In some cases, these characteristics can be interpreted as important privacy issues.

One alternative approach is assigned to the Applicant, filed on 2004 /? /? And co-pending with the name "An Apparatus and Method for Establishing an Authenticated Encryped Session with a Device Without Exposing Privacy-Sensitive information". US Patent Application No. 10 / ???, ???. In this approach, the use of RSA or ECC keys in one-sided authenticated DH processes is replaced with direct proof keys. Devices using this approach may be authenticated as belonging to a particular family of devices, which may include a guarantee regarding the behavior or reliability of the device. The approach does not expose any unique identifying information that may be used to establish a unique identity representing the processing system.

Although this approach works well, additional storage is needed on the device to maintain the direct proof secret key, which can be larger than the RSA or ECC key. In order to alleviate the burden of such additional storage requirements, embodiments of the present invention provide a system that, when the key is needed, does not require substantial additional storage on the device, and ensures that the device has a proof private key directly; Define the process.

In at least one embodiment of the present invention, the device manufacturer does not store 128-bit pseudorandom numbers on the device in the manufacturing line, and a larger direct proof secret key (DPpri) is encrypted using an online service operated by a protection server. It can be delivered to the device in the field. In other embodiments, the device may store a number longer or shorter than 128 bits. This process ensures that only certain devices can decrypt and use the assigned DPpri key. 5 is a diagram of a system 500 for distributing a proof key directly in accordance with an embodiment of the present invention. There are four entities in this system: device manufacturing protection system 502, device product manufacturing system 503, client computer system 504, and protection server 522. The device manufacturing protection system includes a processing system used in the setup process prior to device 506 manufacturing. The manufacturing protection system 502 can be operated by a device manufacturer such that the protection system is protected from hacker attacks from outside the device manufacturer (eg, a closed system). The product manufacturing system 503 can be used in the manufacture of the device. In one embodiment, the protection system and the product system may be the same system. Device 506 includes any hardware for inclusion in a client computer system (eg, a peripheral device such as a memory controller, a graphics controller, an I / O device, etc.). In an embodiment of the invention, the device includes a pseudo random number RAND 508 and a key service public key hash value 509 stored in the device's nonvolatile storage.

The manufacturing protection system includes a protection database 510 and a generation function 512. The protection database includes a data structure that stores a number of pseudo-random values (at least one per device to be manufactured) generated by the generation function 512 in the manner described below. The generation function includes logic (implemented in software or hardware) for generating a data structure referred to herein as keyblob 514. The keyblob 514 includes at least three items. The unique direct proof secret key (DPpri) contains an encryption key that can be used by the device for signing. DP secret digest 516 (DPpri digest) includes DPpri's message digest according to any known method for generating a secure message digest, such as SHA-1. In some embodiments, a pseudo random number initialization vector (IV, 518) containing a bit stream as part of a keyblob may be included for compatibility purposes. If a stream cipher is used for encryption, the IV is used in a known method for using the IV in a stream cipher. If a block cipher is used for encryption, the IV is used as part of the message to be encrypted, causing each instance of encryption to be different. The manufacturing protection system also includes a key service public key 507 that is used for the online protocol as described in detail below.

In one embodiment of the invention, the manufacturing protection system generates one or more keyblobs (described in detail below) and stores the keyblobs in the keyblob database 520 on the protection server 522. In one embodiment, there may be multiple keyblobs in the keyblob database. The protection server can be operated by the device manufacturer, device vendor, or other party. The protection server may be communicatively connected to the client computer system 504 using, for example, a network such as the Internet. The protection server also includes a key service secret key 511 for use in the online protocol between the protection server and the device.

A client computer system 504 wishing to use and use a direct proof protocol for key exchange and authentication of a communication session with a device 506 contained within the system 504 uses a key service public / private key pair and an online protocol described below. The selected keyblob 514 can be read from the keyblob database 520 on the protection server. The device uses the keyblob data to generate a localized keyblob 524 (as described below) for use in the direct proof protocol implementation. Device driver software 526 is executed by the client computer system to initialize and control device 506.

In an embodiment of the present invention, there may be five separate steps of operation. 6 is a flow diagram 600 illustrating the steps of a method for directly distributing an attestation key in accordance with an embodiment of the present invention. According to embodiments of the present invention, any action may be executed at each step. At the device manufacturer's site, there are at least three steps: protection server setup step 601, device manufacturer setup step 602 and product manufacturing step 604. The protection server setup step is described herein with reference to FIG. 7. The device manufacturer setup step is described herein with reference to FIG. 8. Device manufacturer manufacturing steps are described herein with reference to FIG. At the consumer site with a client computer system, there are at least two steps, a client computer system setup step 606 and a client computer system use step 608. The client computer system setup step is described herein with reference to FIGS. 10-12. The steps of using a client computer system are described herein with reference to FIG.

7 is a flowchart 700 illustrating protection server setup phase processing in accordance with an embodiment of the present invention. This processing may be performed by the device manufacturer prior to device manufacture. In block 702, the device manufacturer establishes a protection server 522 to support the key retrieval request. In one embodiment, the protection server is communicatively connected to the Internet in a known manner. In order to improve security, the protection server should not be the same as the processing system used in the manufacturing protection system or the product manufacturing system. At block 704, the device manufacturer creates a key service public / private key pair to be used for the key retrieval service provided by the protection server. In one embodiment, the key service public / private key pair may be stored on a protection server. This key pair may be generated once for all processing performed by the system, or a new key pair may be generated for each class of device. At block 706, the device manufacturer passes the key service public key 507 to the manufacturing protection system 502.

8 is a flowchart 800 illustrating device manufacturing setup processing in accordance with an embodiment of the present invention. In one embodiment, device manufacturers may perform these actions using manufacturing protection system 502. At block 802, the device manufacturer generates direct proof family key pairs Fpub and Fpri for each class of device to be manufactured. Each unique device will have a DPpir key so that the signature generated using DPpri can be verified by Fpub. The class of device may include any set or subset of devices, such as a selected product line (ie, device type), or a subset of the product line based on a version number, or other feature of the device. Family key pairs are for use by the class of device that is generated.

For each device to be manufactured, the generation function 512 of the manufacturing protection system 502 performs blocks 804 through 820. First, at block 804, the generation function generates a unique pseudo random value (RAND 508). In one embodiment, the length of the RAND is 128 bits. In other embodiments, values of different sizes may be used. In one embodiment, pseudo-random values for multiple devices may be generated in advance. At block 806, using the one-way function f supported by the device, the generation function generates a symmetric encryption key (SKEY) from the unique RAND value (SKEY = f (RAND)). The one-way function can be any known algorithm suitable for this purpose (eg, SHA-1, MGF1, Data Encryption Standard (DES), Triple DES, Advanced Encryption Standard (AES), etc.). In block 808, in one embodiment, the generation function uses key SB data on protection server 522 by using SKEY to encrypt a "null entry" (e.g., a small number of zero bytes). Generate an identifier (ID) label that will be used to refer to the keyblob 514 of this device in base 520 (using SKEY, device ID = Encrypt (0..0)). In other embodiments, other ways of generating device IDs may be used, and other values may be encrypted by the SKEY.

Next, at block 810, the generation function generates a DP secret signing key DPpri that is correlated with the device's family public key Fpub. At block 812, the generation function hashes DPpri to generate a DPpri digest using known methods (eg, using SHA-1 or other hash algorithm). At block 814, the generation function builds a keyblob data structure for the device. The keyblob contains at least DPpri and DPpri digests. In one embodiment, the keyblob also includes a random initialization vector IV having a plurality of pseudo randomly generated bits. These values are encrypted using SKEY to produce encrypted keyblob 514. At block 816, the device ID generated at block 808 and the encrypted keyblob 514 generated at block 814 may be stored in an entry in the keyblob database 520. In one embodiment, an entry in the keyblob database may be indicated by the device ID. At block 818, the current RAND value may be stored in the protection database 510. At block 820, because SKEY and DPpri will be played by the device in the field, they can be deleted.

The creation of a DPpri digest and subsequent encryption by the SKEY ensures that the content of the DPpri cannot be determined by any entity that does not own the SKEY, and that the content of the keyblob is SKEY without subsequent detection by the entity that does not own the SKEY. It is designed so that it cannot be modified by an entity that does not own it. In other embodiments, other methods of providing such confidentiality and integrity protection may be used. In some embodiments, integrity protection may not be required, and methods that provide only confidentiality may be used. In this case, the DPpri digest value is not necessarily required.

At any time after block 820, at block 822, the protection database of RAND values may be securely uploaded to product manufacturing system 503 to store the RAND values in the device during the manufacturing process. Once this upload has been verified, the RAND value can be securely deleted from the manufacturing protection system 502. Finally, at block 824, keyblob database 520 with a plurality of cryptographic keyblobs is used by one keyblob database entry for each device, as indexed by the device ID field. May be stored on the protection server 522.

9 is a flow chart 900 illustrating device product fabrication processing in accordance with an embodiment of the present invention. As the device is manufactured in the product line, at block 902, the product manufacturing system selects an unused RAND value from the protection database. The selected RAND value can then be stored in nonvolatile storage in the device. In one embodiment, the nonvolatile reservoir comprises a TPM. In one embodiment, the RAND value may be stored in approximately 16 bytes of nonvolatile storage. At block 904, a hash 509 of the key service public key 507 may be stored in non-volatile storage of the device. This hash can be generated using any known hashing algorithm. In one embodiment, the hash value may be stored in approximately 20 bytes of nonvolatile storage. At block 906, if the RAND value was successfully stored, the product manufacturing system destroys any record of the device's RAND value in the protection database 510. At this time, a unique copy of the RAND value is stored on the device.

In an alternate embodiment, RNAD values may be generated during manufacture of the device and then sent to the manufacturing protection system for calculation of the kiblob.

In another embodiment, the RAND value may be generated on a device, and the device and manufacturing protection system may handle the protocol to generate the DPpri key using a method that does not leak the DPpri key out of the device. The device may then generate a device ID, SKEY and keyblob. The device may pass the device ID and keyblob to the manufacturing system for storage in the protection database 510. In this way, the manufacturing system will eventually have the same information (device ID, keyblob) in the protection database, but do not know the RAND value or the DPpri value.

10-12 are flowcharts of client computer system setup processing in accordance with an embodiment of the present invention. The client computer system performs these actions as part of the system boot. Beginning with the flowchart 1000 of FIG. 10, at block 1002, the client computer system may be booted in a regular manner and the device driver software module 526 for the device may be loaded into the main memory of the client computer system. . When the device driver is initialized and starts executing, the device driver determines in block 1004 whether the encrypted local keyblob 524 is already stored in the mass storage device 308 for the device 506. If it is already stored, no further setup processing needs to be performed and setup processing ends at block 1006. If not, processing continues at block 1008. At block 1008, the device driver issues a key acquisition command to device 506 to begin the DP secret key acquisition process of the device.

At block 1010, the device driver sends the key service public key 507 to the device. At block 1014, the device extracts the received key service public key, generates a hash value of the key service public key, and stores the hash of the received key service public key in the key service public key stored in the device's nonvolatile storage. Compare to hash 509. If the hashes match, the received key service public key is known to be the key of the device manufacturer's key retrieval service, and the client computer system setup processing continues.

In another embodiment, the device may receive a certificate of an authentication key service public key, which certificate chain is a certificate chain for a key service public key whose hash is a key service public key hash 509 stored in the device's nonvolatile storage. Can be verified through The authentication key service public key can then be used as the key service public key in subsequent steps.

At block 1018, the device uses one-way function f to regenerate the symmetric key SKEY from the embedded RAND value 508 (SKEY = f (RAND)). At block 1020, the device generates its own device ID label by encrypting the "null entry" (e.g., a few zero bytes) using the SKEY (device ID = Encrypt (0 using SKEY). ..0)). Processing continues in flow diagram 1100 of FIG. 11.

In block 1102 of FIG. 11, the device generates a transient symmetric key (Tkey). This key is sent to the protection server, which can use the key to encrypt messages returned by the protection server to the device. In block 1104, the device constructs a search key request message that includes the device ID and the transient symmetric key (Tkey), encrypts the message using the key service public key received from the device drive in block 1014, The search key request message is sent to the protection server via the device driver. (Using a key service public key, Retrieve Key Request = Encrypt (Device ID, Tkey)). Those skilled in the art typically generate a symmetric cryptographic session key (Skey), encrypt the session key using the public key, and then use the session key to encrypt the message using the public key. You will notice that it encrypts the message. In block 1106, the protection server decrypts the received key request message using the key service secret key 511 and extracts the fields stored in that message. Since the Protection Server now knows the device ID (obtained from the key request message), the Protection Server retrieves the keyblob database for the record containing the matching device ID value and retrieves the encrypted keyblob of the device from that record. Extract. In block 1110, the protection server constructs a second response message that includes the family public key and the encrypted keyblob, and encrypts the second response message using the transient symmetric key (Tkey) supplied by the device. Thus, key response = (encryption of (encrypted keyblob) using family public key, Tkey). Since encrypted keyblobs are already encrypted with a symmetric key (SKEY) and can only be played by a device, encrypting an encrypted keyblob using Tkey does not protect the keyblob. Rather, encryption in this manner ensures that the returned keyblob is changed every time the key acquisition process is performed, so that the keyblob itself cannot be used as a "cookie". The second response message may be returned to the device driver on the client computer system at block 1112, which forwards the message to the device.

In block 114, the device extracts the family public key from the second response message, decrypts the wrapped keyblob using a transient symmetric key (Tkey), and converts the cryptographic keyblob to the device's volatile memory. Store in Next, processing continues in flow diagram 1200 of FIG. 12.

In block 1216 of FIG. 12, the device decrypts the cryptographic keyblob using the symmetric key SKEY, yielding DPpri and DPpri digests, and storing these values in non-volatile storage (key decrypted using SKEY). Blob = Decrypt (IV, DPpri, DPpri Digest)). The initialization vector IV may be discarded. At block 1218, the device checks the integrity of the DPpri by hashing the DPpri and comparing the result to the DPpri digest. If the comparison is good, the device accepts DPpri as a valid key. The device can also set the key acquisition flag to true to indicate that the DP secret key was successfully obtained. At block 1220, the device selects a new IV and generates a new encrypted local keyblob using the new IV (local keyblob = Encrypt (IV2, DPpri, DPpri Digest) using SKEY). In one embodiment, the new encrypted local keyblob may be returned to a key retrieval utility software module (not shown in FIG. 5) on the client computer system. In block 1222, the key retrieval utility stores the encrypted local keyblob in a repository (eg, mass storage device 308) in the client computer system. The device's DPpri is now securely stored on the client computer system.

If the device acquired DPpri during setup processing, the device can use DPpri. 13 is a flow chart 1300 of a client computer system in accordance with an embodiment of the present invention. The client computer system can perform these actions at any time after setup is complete. At block 1302, the client computer system may boot in a regular manner and a device driver 526 for the device may be loaded into main memory. When the device driver is initialized and starts executing, the device driver determines whether the encrypted local keyblob 524 already stored in the mass storage device 308 for the device 506. If no keyblob is present, the setup processing of FIGS. 10-12 is performed. If there is an encrypted local keyblob available for this device, processing continues to block 1306. At block 1306, the device driver retrieves the cryptographic local keyblob and passes the keyblob to the device. In one embodiment, delivery of the keyblob may be accomplished by executing a Load Keyblob command.

At block 1308, the device regenerates the symmetric key SKEY (now used for decryption) from the embedded RAND value 508 using one-way function f (SKEY = f (RAND)). At block 1310, the device decrypts the encrypted local keyblob using the symmetric key SKEY to produce DPpri and DPpri digests and stores these values in non-volatile storage (keyblock decrypted using the SKEY). = Decrypt (IV2, DPpri, DPpri Digest)). The second initialization vector IV2 may be discarded. At block 1312, the device checks the integrity of the DPpri by hashing the DPpri and comparing the result with the DPpri digest. If the comparison is good (eg, if the digest matches), the device accepts the DPpri as a valid key obtained earlier and enables the DPpri for use. The device may also set the key acquisition flag to true to indicate that the DP secret key was successfully obtained. At block 1314, the device selects another IV and generates a new encrypted local keyblob using the new IV (local keyblob = Encrypt (IV3, DPpri, DPpri Digest) using SKEY). The encrypted new local keyblob can be returned to the key retrieval utility. In block 1316, the key retrieval utility stores the encrypted local keyblob in a repository (eg, mass storage device 308) in the client computer system. The device's DPpri is now securely stored once again on the client system.

In one embodiment of the invention, it is not necessary to generate all the device DP secret keys at once. Assuming that the keyblob database on the protection server is uploaded regularly, the device DP secret key can be generated in batch as needed. Each time the keyblob database is uploaded on the protection server, it will include the keyblob database as it is created so far, including device keys that have been generated but not yet assigned to the device.

In another embodiment, it is also possible to delay the generation of the device's DPpri key while only generating these keys for devices that require keys. Upon receiving the first key acquisition request from the device, the protection server generates a request to the protection manufacturing system that still maintains the device's RAND value. At this time, the manufacturing protection system generates a DPpri key for the device, returns this key to the protection server, and then destroys only the RAND value.

In another embodiment, instead of storing the key service public key hash in the device's nonvolatile storage, the device manufacturer stores the hash of the root key and then signs the certificate for the key service public key with this root key. You can choose. In this way, the same root key can be used for a large number of devices.

Although the operations discussed herein have been described in sequential processes, some of the operations may be performed in parallel or concurrently. In addition, in some embodiments, the order of the operations may be readjusted without departing from the scope of the present invention.

The techniques described herein are not limited to any particular hardware or software configuration, which techniques may find applicability in any computing or processing environment. This technique can be implemented in hardware, software or a combination of both. The technology includes programmable machines such as mobile or fixed computers, personal digital assistants, set-top boxes, cellular telephones and pagers, and storage, including volatile and nonvolatile memory and / or storage elements, respectively, by the processor, the processor. It can be implemented as a program running on another medium including a medium, at least one input device, and one or more output devices. Program code is applied to data input using an input device to perform the described functions and to generate output information. Output information may be provided to one or more output devices. Those skilled in the art will appreciate that the present invention may be practiced in a variety of computer system configurations, including multiprocessor systems, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks may be performed by remote processing devices that are linked through a communications network.

Each program may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. However, the program can be implemented in assembly or machine language, if desired. In either case, the language can be compiled or interpreted.

Program instructions may be used to cause general purpose or special purpose processing systems programmed with instructions to perform the operations described herein. Alternatively, the operation may be performed by a specific hardware component including logic by wiring to perform the operation, or by a combination of a programmed computer component and a custom hardware component. The method described herein can be provided as a computer program product or other electronic device for performing the method that can include a machine readable medium having stored thereon instructions that can be used to program the processing system. The term "machine-readable medium" as used herein may store or encode a sequence of instructions for execution by a machine, and any medium on which a machine may perform any of the methods described herein. It includes. Thus, the term "machine-readable medium" includes, but is not limited to, solid-state memory, magneto-optical disks, and carrier waves that encode data signals. In addition, it is common in the art to refer to one form or another (eg, program, procedure, process, application, module, logic, etc.) by taking action or producing a result. Such representation is merely a shorthand for stating the execution of the software by the processing system that causes the processor to perform an action to produce a result.

Although the present invention has been described with reference to the described embodiments, such description is not intended to be limiting. It will be apparent to those skilled in the art that various modifications of the exemplary embodiments as well as other embodiments of the present invention will fall within the spirit and scope of the present invention.

Claims (35)

Establishing a protected online server supporting a key retrieval request from a client computer system to request a private key for a device of a device class present in the first client computer system, wherein the device does not include a secret key, The first client computer system not including an encrypted data structure associated with the device; Generating a key service public / private key pair for use in secure key retrieval processing by a client computer system comprising a device of the device class and storing the key service public / private pair in the protected online server; Generating a pseudo random number value for a device of the device class; Generating the encrypted data structure associated with the device, the encrypted data structure including a secret key; Generating an identifier for the encrypted data structure based on the pseudo random number value; Storing the identifier and the encrypted data structure on the protected online server; Storing the pseudo-random value and a hash value of the key service public key in non-volatile storage in the device without storing the secret key in the device. How to pass a secret key to a device. The method of claim 1, Generating a proof-family key pair directly for the class of device. The method of claim 2, And the secret key comprises a direct proof secret key associated with the public key of the direct proof family key pair, and hashing the direct proof secret key to generate a secret key digest. The method of claim 1, Generating a symmetric key based on the pseudorandom value for the device. The method of claim 4, wherein Generating the identifier includes encrypting a data value using the symmetric key. The method of claim 4, wherein Encrypting the data structure using the symmetric key. The method of claim 1, Storing the key service public key in a manufacturing protection system. Claim 8 was abandoned when the registration fee was paid. The method of claim 1, And wherein the pseudo random number value for the device is unique. A computer readable storage medium comprising a first storage medium having a plurality of machine readable instructions, When the instruction is executed by a processor, the instruction is Establish a protected online server supporting a key retrieval request from a client computer system to request a private key for a device of a device class present in the first client computer system, wherein the device does not include a secret key and 1 the client computer system does not include an encrypted data structure associated with the device, Generate a key service public / private key pair for use in secure key retrieval processing by a client computer system comprising a device of the device class and store the key service public / private pair in the protected online server, Generate a pseudo-random value for a device of the device class, Create the encrypted data structure associated with the device, the encrypted data structure including a secret key, Generate an identifier for the encrypted data structure based on the pseudo random number, Store the identifier and the encrypted data structure on the protected online server, Storing the pseudo-random value and the hash value of the key service public key in non-volatile storage in the device without storing the secret key in the device. A computer readable storage medium for delivering a secret key to a device. The method of claim 9, And delivering a secret key to the device, the instructions further comprising generating a proof family key pair directly for the class of device. The method of claim 10, The secret key includes a direct proof secret key associated with the public key of the direct proof family key pair, and further comprising instructions for hashing the direct proof secret key to generate a secret key digest. Possible storage medium. The method of claim 9, And instructions for generating a symmetric key based on the pseudorandom value for the device. The method of claim 12, And the instructions for generating the identifier include instructions for encrypting a data value using the symmetric key. The method of claim 12, And encrypting the data structure using the symmetric key. The method of claim 9, And instructions for storing the key service public key in a manufacturing protection system. Claim 16 was abandoned upon payment of a setup registration fee. The method of claim 9, And transmit a secret key to the device such that the pseudo random number value for the device is unique. Determining whether an encrypted data structure associated with a device installed in a computer system is stored in a memory on the computer system, the device consisting of a device class and not including the secret key Wow, If the encrypted data structure is not stored in the memory, obtaining the encrypted data structure associated with the device from a protected online server accessible by the computer system, wherein the protected online server is a device of the device class. Storing a database of the encrypted data structures associated with each; How to pass a secret key to a device. The method of claim 17, Acquiring the encrypted data structure includes sending a key acquisition command to the device to initiate a secret key acquisition process. Claim 19 was abandoned upon payment of a registration fee. The method of claim 17, And the secret key comprises a direct proof secret key associated with the public key of the direct proof family key pair for the class of device. The method of claim 18, The secret key obtaining process includes obtaining, by the device, a key service public key signed by a corresponding key service secret key from the protected online server. The method of claim 20, The secret key obtaining process further comprises generating a symmetric key based on a unique pseudo random value stored in the device, and generating, based on the pseudo random number value, a device identifier for the encrypted data structure. How to pass a secret key to a device. The method of claim 21, The secret key obtaining process generates a transient symmetric key by a device, constructs a search key message comprising the device identifier and the transient symmetric key, encrypts the search key message using the key service public key, Sending a cryptographic retrieval key message to the protected online server. Claim 23 was abandoned upon payment of a set-up fee. The method of claim 22, The secret key obtaining process further includes the step of decrypting an encryption search key message using the key service secret key to obtain a device identifier. Claim 24 was abandoned when the setup registration fee was paid. The method of claim 23, The secret key obtaining process includes searching the protected online server for an entry in a database of encrypted data structures indexed by an identifier that matches a generated device identifier, wherein the entry includes the encrypted data structure. Constructing a key response message, encrypting the key response message with the transient symmetric key, and forwarding the key response message to a device. Claim 25 was abandoned upon payment of a registration fee. The method of claim 24, The secret key obtaining process further includes decrypting, by the device, an encryption key response message using the transient symmetric key to obtain the encrypted data structure. Claim 26 was abandoned upon payment of a registration fee. The method of claim 25, The secret key obtaining process further includes decrypting the encrypted data structure received from the protected online server using the symmetric key to obtain the secret key and the secret key digest to deliver a secret key to a device. Way. Claim 27 was abandoned upon payment of a registration fee. The method of claim 25, The secret key obtaining process hashes the secret key to generate a new secret key digest, comparing the secret key digest from the decrypted data structure to a new secret key digest, and when the digest matches the secret. Accepting a key as valid for the device. A computer readable storage medium having a plurality of machine readable instructions, When the instruction is executed by a processor, the instruction is Determine whether an encrypted data structure associated with a device installed in the computer system is stored in a memory on the computer system, the device consisting of a device class and not including the private key; If the encrypted data structure is not stored in the memory, obtain the encrypted data structure associated with the device from a protected online server accessible by the computer system, wherein the protected online server is associated with a device of the device class, respectively. By storing a database of the associated encrypted data structures, Providing a secret key for a device installed in the computer system A computer readable storage medium for delivering a secret key to a device. The method of claim 28, And instructions for obtaining the encrypted data structure include instructions for sending a key acquisition command to the device to initiate a secret key acquisition process. The method of claim 28, And the secret key comprises a direct proof secret key associated with the public key of the direct proof family key pair for the class of device. The method of claim 29, The computer-readable storage medium for delivering the secret key to the device includes instructions for obtaining, by the device, a key service public key signed by a corresponding key service secret key from the protected online server. . The method of claim 31, wherein The command for the secret key obtaining process generates a symmetric key based on a unique pseudo random value stored in the device, and generates a device identifier for the encrypted data structure based on the pseudo random number value. A computer readable storage medium for delivering a secret key to the device. The method of claim 32, The command for the secret key obtaining process generates a transient symmetric key by the device, constructs a search key message that includes the device identifier and the transient symmetric key, and uses the key service public key to retrieve the search key message. And encrypting and transmitting the encrypted search key message to the protected online server. A system that delivers a secret key to a device installed on a client computer system using a security protocol, Store a database of encrypted data structures accessible to the client computer system, generating a key service public / private key pair, each containing a secret key corresponding to a selected device of a device class; Securely communicating the selected one to the client computer system, the device comprising a protected online server configured to not include the secret key; A protection configured to connect to the protected online server, generate the encrypted data structure associated with the device, receive the key service public key from the protected online server, and send the encrypted data structure to the protected online server. System, Connect to the protection system, receive a hash value and a unique pseudo-random value of the key service public key from the protection system, and store the device in the client computer system without storing the secret key in non-volatile storage of the device. A manufacturing system configured to store a hash value of the key service public key and the unique pseudo random number value in a non-volatile storage of the device prior to installation. A system for passing secret keys to devices. The method of claim 34, wherein And the secret key comprises a direct proof secret key associated with the public key of the direct proof family key pair.

Images