Abstract:
Secure creation and management of device ownership keys. TPM ownership keys are generated by cryptographically combining manufacturer information with device specific information. Ownership keys are established in the TPM containing device. The manufacturer retains necessary information to reconstruct the ownership key if needed.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    The present invention relates to device ownership keys, and to the creation and management of device ownership keys in Trusted Platform Modules. 
         [0002]    A Trusted Platform Module (TPM) is a special purpose digital microprocessor-based module which offers facilities for the secure generation of cryptographic keys in the nonvolatile memory of the TPM, and other capabilities such as remote attestation and sealed storage. These facilities may be used, for example, to authenticate computing systems. TPMs are specified by the Trusted Computing Group (http://trustedcomputinggroup.org); the specification at the time of this application is Version 1.2 Revision 103, published Jul. 9, 2007, and incorporated herein by reference. TPMs are produced by companies such as Atmel, Broadcom, Infineon, AMT, and ST Microelectonics, among others. 
         [0003]    Trusted Platform Modules (TPMs) require the creation and management of an “owner” key in order to provide these and other security functions. In general terms, the owner key forms the root of a cryptographic key hierarchy, but it is keys lower in this hierarchy that are typically used for day to day activities. Hence, it is entirely possible that for some use cases, an owner key, once used to create the key hierarchy that lays beneath it, may be set aside and not used for further operations. 
         [0004]    In currently shipping laptop computers and other consumer devices containing TPMs, the purchaser of the device is typically expected to “take ownership”, generating an “owner key” in the process, and to provide for the secure management and use of that key. However, this is a complex undertaking that requires significant security expertise and planning to perform correctly, and there currently are very few convenient tools available for this purpose. The net effect is that many TPMs exist in consumer devices today, but, owing to the complexities involved, few are actually being used. 
         [0005]    In the case of an embedded device such as network controller or access node, it is not strictly necessary that the customer purchasing the device be aware of the TPM and concepts such as TPM ownership in order to reap many of the advantages it provides. That is, ownership operations can be pre-programmed at some point (e.g. during manufacturing), and the TPM can be entirely operated by the system software/firmware on the device, with no customer interaction. This model also extends quite readily to centralized management of laptop and desktop computers containing TPMs. 
         [0006]    If in such cases the owner key were to reside on the device, there is a risk that device compromise could result in loss of legitimate TPM ownership, and this could, in turn, lead to loss of control of the device. This is potentially very serious. However, since the owner key is not typically required for day to day operations, this key may be eliminated from the device once the underlying key hierarchy has been generated, so long as it is possible to restore the owner key in those rare cases where a very advanced customer might want to reset the TPM, and derive their own owner key hierarchy. 
         [0007]    Taking such an approach entails the following requirements: 
         [0008]    Each device should have a unique owner key; that is, the probability of any two devices having the same owner key should be very close to zero. Owner keys should be unpredictable. 
         [0009]    Guessing the owner key should be impractical, i.e. the probability of guessing an owner key within the useful lifetime of the device, say 20 years, should be very close to zero. 
         [0010]    The device manufacturer should be able to derive the owner key for any given device, should this ever become necessary. 
         [0011]    It should be highly unlikely for the device manufacturer to “lose” the owner key for any device, although the net cost of such a loss would be the cost of replacement of the affected device. 
         [0012]    It should not be possible for an adversary to obtain a single data value that, once compromised, would permit derivation of arbitrary owner storage keys; put differently, owner keys should be derived based on multiple factors, raising the bar against a process compromise leading to exposure of all owner keys. 
         [0013]    It should be possible to provide advanced customers with owner keys for their own devices, so that they can reset the devices and derive their own (secret) owner keys if desired. 
         [0014]    What is needed is a process for creating and managing TPM device ownership keys which addresses these requirements. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0015]    The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention in which: 
           [0016]      FIG. 1  shows a block diagram of an electronic system, and 
           [0017]      FIG. 2 . shows a flowchart of an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    Embodiments of the invention relate methods of creating and managing device ownership keys for use with Trusted Platform Modules (TPMs). 
         [0019]    In understanding the invention, the following definitions may be useful: 
         [0020]    Target Device: the device for which the owner key is generated 
         [0021]    Ownership Recovery Database: the backend database containing owner key recovery information 
         [0022]    Key Manager: the backend process responsible for generating and managing owner key and related quantities 
         [0023]    Key Generation Process: the process by which the owner key is created and distributed 
         [0024]    Nonce: an unpredictable numeric quantity used in the key generation process 
         [0025]    Model Key: for each device module (e.g. A3200), there is a unique secret key which is used as an input to the key generation process 
         [0026]    Model Key ID: to limit the window of exposure (should a model key be compromised), model keys may be changed from time to time. Thus, each model key must have a unique identifier, e.g. “A3200-00001” 
         [0027]    Owner Key: the target device owner key 
         [0028]    Key Manager Public Key: the public RSA key of the key manager 
         [0029]    Key Manager Private Key: the private RSA key of the key manager 
         [0030]    Key Recovery Token: Model Key ID and nonce concatenated and encrypted with Key Manager Public Key 
         [0031]    According to the present invention and as shown in  FIG. 1  and the descriptions following, Key Manager  100  combines manufacturer information with device specific information to form an owner key, which is sent to the device, and a key recovery token, which is retained by the manufacturer and which may be used, in combination with device specific information, to recover the owner key. Cryptographic processes are used to combine information and form the keys. In one embodiment, device specific information may include device model, device serial number, and/or device base MAC address for network enabled devices. The owner key is sent to target device  200  and used to take ownership of Trusted Platform Module (TPM)  220 . The recovery token is similarly sent to target device  200 , and may be stored in TPM  220 . 
         [0032]    Key Manager  100  is a computer system or process driving the creation and transfer of ownership and recovery keys. Key manager  100  comprises CPU  110 , memory hierarchy  120 , and an interface  130  for communicating with target device  200 . As is known to the art, memory hierarchy  120  comprises non-volatile and volatile memory devices used to hold programs and data required to operate the system. Key manager  100  communicates with database  140 , which may be a disk drive local to key manager  100 , or a network-connected datbase server. 
         [0033]    Target device  200  is a device containing TPM  220 . Device  200  operates under control of CPU  210 , which communicates to memory hierarchy  230 , I/O interfaces  250 , communications port  240 , and TPM  220 . As is known to the art, memory hierarchy  230  comprises non-volatile and volatile memory devices used to hold programs and data for device operation. Communications port  240  is used to communications  150  with key manager  100 . Port  240  may be a standard port or channel in the target device, such as an Ethernet port, serial port, or the like, or it may be a port dedicated to the manufacturing process, such as a port internal to the device. Target device CPU  210  communicates with TPM  220  through a TPM communication bus. As an example, manufacturers such as Atmel and Infineon provide TPMs which use the well known Low Pin Count (LPC) bus. TPM  220  responds to commands as defined in the TPM Specification, Part 3 Commands, incorporated herein by reference. 
         [0034]    In operation according to the present invention, key manager  100  communicates  150  with device  200 , which results in commands being sent to TPM  220 . 
         [0035]    According to the present invention, device ownership and recovery keys are generated and transferred to the device according to the following procedure, as illustrated in  FIG. 2 . 
         [0036]    1. Key Manager  100  makes use of a preexisting public/private key pair; the private key is safely stored offline, key manager  100  is in possession of the key manager public key 
         [0037]    2. Target device  200  provides unique inputs to key manager  100 , for example in the case of a network-enabled device, the device model, base MAC address and device serial number may be used. 
         [0038]    3. Key manager  100  generates hash data based on the device identification combined with manufacturer information to form an intermediate value. As an example, key manager  100  may generate a nonce as he manufacturer information, and concatenate the device MAC address, serial number, and nonce into a contiguous string of octets. 
         [0039]    4. Key manager  100  chooses the model key corresponding to device model and computes a hash of the intermediate value, for example HMAC_SHA256(model key, intermediate value), and assigns 160 bits of the output to the owner key. In one embodiment, the first 160 bits of the output are used as the owner key. 
         [0040]    5. Key manager  100  concatenates Model Key ID and nonce and encrypts with Key Manager Public Key; the resulting value is the key recovery token. Optionally, if the concatenated Model Key ID and nonce are shorter than the length of the public key, it may be useful to pad this intermediate result to at least the same length as the public key. One method of padding is according to the PKCS #1 v1.5 algorithm. 
         [0041]    6. Key manager  100  sends owner key and key recovery token to device  200 . 
         [0042]    7. Device  200  clears TPM, takes ownership with new owner key by issuing the TPM_TakeOwnership command with the new owner key. The new owner key will be required for future device operations using the TPM. 
         [0043]    8. While the recovery token may be stored in memory  230 , it is preferably stored in TPM  220 . Device  200  stores key recovery token in non-volatile memory of TPM  220  for safekeeping; this is redundant, as key manager  100  also maintains a copy of the key recovery token. 
         [0044]    9. Good security practice suggests that device  200  purge the owner key from device memory. While this step could be omitted if the owner key (and copies) were only maintained in volatile memory, and the device is powered off later in the process, good security practice suggests that the owner key be actively purged from device memory, such as by writing over it. 
         [0045]    10. Device  200  notifies Key manager  100  of successful owner key change. 
         [0046]    11. Key manager  100  stores transaction information (including device identification, in this example MAC and serial number), and key recovery token in ownership recovery database  140 . 
         [0047]    While the invention has been described in terms of various embodiments, the invention should not be limited to only those embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is this to be regarded as illustrative rather than limiting.