U.S. patent application number 12/956793 was filed with the patent office on 2012-05-31 for method and apparatus for key provisioning of hardware devices.
Invention is credited to Ernest F. Brickell, Shay Gueron, Simon P. Johnson, Jiangtao Li, Daniel Nemiroff, Carlos V. Rozas, Uday R. Savagaonkar, Vincent R. Scarlata.
Application Number | 20120137137 12/956793 |
Document ID | / |
Family ID | 46127438 |
Filed Date | 2012-05-31 |
United States Patent
Application |
20120137137 |
Kind Code |
A1 |
Brickell; Ernest F. ; et
al. |
May 31, 2012 |
METHOD AND APPARATUS FOR KEY PROVISIONING OF HARDWARE DEVICES
Abstract
Keying materials used for providing security in a platform are
securely provisioned both online and offline to devices in a remote
platform. The secure provisioning of the keying materials is based
on a revision of firmware installed in the platform.
Inventors: |
Brickell; Ernest F.;
(Hillsboro, OR) ; Gueron; Shay; (Haifa, IL)
; Li; Jiangtao; (Beaverton, OR) ; Rozas; Carlos
V.; (Portland, OR) ; Nemiroff; Daniel;
(Folsom, CA) ; Scarlata; Vincent R.; (Beaverton,
OR) ; Savagaonkar; Uday R.; (Portland, OR) ;
Johnson; Simon P.; (Beaverton, OR) |
Family ID: |
46127438 |
Appl. No.: |
12/956793 |
Filed: |
November 30, 2010 |
Current U.S.
Class: |
713/182 |
Current CPC
Class: |
G06F 21/572 20130101;
H04L 9/0816 20130101; G06F 21/73 20130101 |
Class at
Publication: |
713/182 |
International
Class: |
G06F 21/00 20060101
G06F021/00 |
Claims
1. A method comprising: receiving, by a hardware device in a
system, an encrypted security key, the encrypted security key
stored in a database maintained by a provisioning server associated
with a provisioning identifier derived from a unique device key,
the unique device key embedded by a key generation server in the
hardware device by writing the unique device key in a protected
memory in the hardware device, the security key encrypted using a
base provisioning key derived from the unique device key; deriving,
by the hardware device, the base provisioning key from the unique
device key stored in protected memory, the protected memory
inaccessible by software; and decrypting, by the hardware, the
encrypted security key using the derived base provisioning key.
2. The method of claim 1, wherein the protected memory is
write-once memory.
3. The method of claim 1, wherein the key generation server is an
off-line server that operates in a trusted environment.
4. The method of claim 1, wherein the provisioning identifier and
provisioning key derived from the unique device identifier are
symmetric keys.
5. The method of claim 1, wherein a copy of the unique device key
is not available to the first server after the unique device key is
written to the protected memory.
6. The method of claim 1, wherein the hardware device receives the
encrypted security key via a communications network.
7. The method of claim 1, wherein the hardware device receives the
encrypted security key from a storage medium in the system.
8. The method of claim 1, further comprising: deriving, by the
hardware device, a provisioning key from the base provisioning key,
the provisioning key derived based on a latest firmware version
number associated with firmware available for installation in the
hardware device.
9. The method of claim 7, further comprising: receiving, by the
hardware device, a encrypted device authentication key, the device
authentication key encrypted by the provisioning key; and
decrypting, by the hardware device, the encrypted device
authentication key associated with the provisioning key associated
with the latest firmware version number or a prior firmware version
number.
10. An apparatus comprising: a hardware device in a system to
receive an encrypted security key, the encrypted security key
stored in a database maintained by a provisioning server associated
with a provisioning identifier derived from a unique device key,
the unique device key embedded by a key generation server in the
hardware device by writing the unique device key in a protected
memory in the hardware device, the security key encrypted using a
base provisioning key derived from the unique device key, the
hardware device to derive the base provisioning key from the unique
device key stored in protected memory, the protected memory
inaccessible by software and the hardware device to decrypt the
encrypted security key using the derived base provisioning key.
11. The apparatus of claim 10, wherein the protected memory is
write-once memory.
12. The apparatus of claim 10, wherein the key generation server is
an off-line server that operates in a trusted environment.
13. The apparatus of claim 10, wherein the provisioning identifier
and provisioning key derived from the unique device identifier are
symmetric keys.
14. The method of claim 10, wherein a copy of the unique device key
is not available to the first server after the unique device key is
written to the protected memory.
15. The apparatus of claim 10, wherein the hardware device receives
the encrypted security key via a communications network.
16. The apparatus of claim 10, wherein the hardware device receives
the encrypted security key from a storage medium in the system.
17. The apparatus of claim 10, wherein the hardware device derives
a provisioning key from the base provisioning key, the provisioning
key derived based on a latest firmware version number associated
with firmware available for installation in the hardware
device.
18. The apparatus of claim 16, wherein the hardware device receives
an encrypted device authentication key, the device authentication
key encrypted by the provisioning key and the hardware device
decrypts the encrypted device authentication key associated with
the provisioning key associated with the latest firmware version
number or a prior firmware version number.
19. An article including a machine-accessible medium having
associated information, wherein the information, when accessed,
results in a machine performing: receiving, by a hardware device in
a system, an encrypted security key, the encrypted security key
stored in a database maintained by a provisioning server associated
with a provisioning identifier derived from a unique device key,
the unique device key embedded by a key generation server in the
hardware device by writing the unique device key in a protected
memory in the hardware device, the security key encrypted using a
base provisioning key derived from the unique device key; deriving,
by the hardware device, the base provisioning key from the unique
device key stored in protected memory, the protected memory
inaccessible by software; and decrypting, by the hardware, the
encrypted security key using the derived base provisioning key.
20. The article of claim 19, further comprising: deriving, by the
hardware device, a provisioning key from the base provisioning key,
the provisioning key derived based on a latest firmware version
number associated with firmware available for installation in the
hardware device.
21. A system comprising: a disk drive; and a hardware device, the
hardware device to receive an encrypted security key, the encrypted
security key stored in a database maintained by a provisioning
server associated with a provisioning identifier derived from a
unique device key, the unique device key embedded by a key
generation server in the hardware device by writing the unique
device key in a protected memory in the hardware device, the
security key encrypted using a base provisioning key derived from
the unique device key, the hardware device to derive the base
provisioning key from the unique device key stored in protected
memory, the protected memory inaccessible by software and the
hardware device to decrypt the encrypted security key using the
derived base provisioning key.
22. The system of claim 21, wherein the encrypted security key is
stored on a storage medium accessible via the disk drive and the
hardware device receives the encrypted security key from the disk
drive.
Description
FIELD
[0001] This disclosure relates generally to the field of
information processing and in particular to the field of security
in computing systems and microprocessors.
BACKGROUND
[0002] Cryptographic algorithms and the protocols that use them
require keys which are based upon random numbers. For example, such
keys can be secret/shared keys used by symmetric key algorithms
such as the Advanced Encryption Standard (AES) and the Data
Encryption Standard (DES) used for block or stream encryption and
public/private key pairs used by asymmetric key algorithms such as
Riverst, Shamir, Adleman (RSA) and Digital Signal Algorithm
(DSA).
[0003] A trusted platform module (TPM) is an integrated circuit
(device) that conforms to the trusted platform module specification
to enable trusted computing features. The manufacturer of the TPM
provisions an asymmetric key to each TPM. This asymmetric key can
be used for encryption and to obtain other keys.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Features of embodiments of the claimed subject matter will
become apparent as the following detailed description proceeds, and
upon reference to the drawings, in which like numerals depict like
parts, and in which:
[0005] FIG. 1 is a block diagram illustrating a system for
performing the initial key provisioning in a manufacturing
environment;
[0006] FIG. 2 is a flow graph illustrating a method for basic
initial manufacturing provisioning of a device unique key 110 to
the hardware device;
[0007] FIG. 3 is a flow graph illustrating a method for initial
manufacturing provisioning of the device unique key 110 with shared
key protection of a device unique key 110 to the hardware
device;
[0008] FIG. 4 is a flow graph illustrating a method for secure
initial manufacturing provisioning of a device unique key 110 to
the hardware device;
[0009] FIG. 5 illustrates a system that includes a key generation
server, a provisioning server and a platform including the device
coupled to a communications network;
[0010] FIG. 6 illustrates an embodiment of an on-line method for a
device to obtain a key from the provisioning server;
[0011] FIG. 7 illustrates a method for decrypting the encrypted
key(s) implemented in the device;
[0012] FIG. 8 is a block diagram of an embodiment of a Trusted
Computing Base (TCB) of a trusted platform;
[0013] FIG. 9 is a flowgraph illustrating a method to recover from
a security vulnerability in the TCB shown in FIG. 8;
[0014] FIG. 10 is a flowgraph of an embodiment of a hash chain
method to perform key derivation to compute prior storage keys;
[0015] FIG. 11 is a flowgraph illustrating an embodiment of a
method performed by the unrecoverable TCB to derive the Storage
Keys;
[0016] FIG. 12 is a block diagram of a two layer TCB;
[0017] FIG. 13 is a block diagram illustrating a hybrid approach
using a hash chain to protect a recoverable layer;
[0018] FIG. 14 illustrates an embodiment of a Device Authentication
Key (DAK) provisioning protocol between a platform and a
provisioning server;
[0019] FIG. 15 illustrates an embodiment of the re-provisioning
protocol in FIG. 14 between the platform and the provisioning
server that supports privacy;
[0020] FIG. 16 illustrates an embodiment of a DAK backup retrieval
protocol between the platform and the provisioning server that
stores the platform's DAK encrypted by its storage key;
[0021] FIG. 17 is flowgraph of an embodiment of a method for
storing a P-SVN in the non-volatile re-writable memory.
[0022] Although the following Detailed Description will proceed
with reference being made to illustrative embodiments of the
claimed subject matter, many alternatives, modifications, and
variations thereof will be apparent to those skilled in the art.
Accordingly, it is intended that the claimed subject matter be
viewed broadly, and be defined only as set forth in the
accompanying claims.
DETAILED DESCRIPTION
[0023] One method to provision keys used for providing security in
a platform is for a manufacturer of a hardware device to
permanently store the keys (key materials) in a programmable write
once memory during the manufacturing of the hardware device. These
keys may be stored in the hardware device prior to installing the
hardware device in a platform. For example, the write-once memory
may be a plurality of fuses in a secure area of the hardware device
that cannot be accessed by firmware or software.
[0024] However, because all of the key materials are stored in
write once memory the device manufacturer can only provision key
materials to the hardware devices during the manufacturing process.
In addition, if there are a large number of keys to be provisioned
securely to a hardware device, a corresponding large area of write
once memory is required which can be expensive to add to the
platform.
[0025] Another method to provision key materials is for the device
manufacturer to store a unique asymmetric Device Authentication Key
(DAK) in write-once memory during the manufacturing process. Later,
a provisioning server can provision keys (transmit keys) remotely
to the hardware device installed in a platform using an interactive
provisioning protocol. After validating the stored DAK received
from the hardware device, the provisioning server sends the key
materials to the hardware device. The disadvantages of this method
include the size of the region of write-once memory used to store a
unique DAK in the hardware device, the possibility of security
breach via a manufacturing tester machine that stores the keys in
write-once memory, no support for off-line provisioning (that is,
when no Internet connection is available to the platform in which
the hardware device is installed), and the use of asymmetric key
operations which requires more memory for a larger Trusted
Computing Base (TCB) size in the hardware device.
[0026] In an embodiment of the present invention, a key
provisioning method uses a symmetrical key and supports both online
and offline provisioning. A symmetric key is shared and used by
both the sender and receiver of a message to encrypt and decrypt
the message. In addition, during manufacturing of the hardware
device, a method of initial key provisioning that is secure against
attacks is performed to store a device unique key 110 in the
hardware device. A key provisioning server includes a provisioning
database to store a unique provisioning key for each hardware
device that is tested by a manufacturing tester machine. The
provisioning key is used to support both offline and online
provisioning.
[0027] FIG. 1 is a block diagram illustrating a system 100 for
performing the initial key provisioning in a manufacturing
environment. The system 100 includes a hardware device 102, a
manufacturing tester machine 104 and a key generation server 106.
The manufacturing tester machine 104 and the key generation server
106 communicate via a secure channel 108. A secure channel is an
authenticated and encrypted communication channel between two
entities. For example, using Transport Layer Security (TLS), a
platform can set up a secure channel with a server to perform
online banking.
[0028] During manufacturing, a device unique key 110 is assigned to
the hardware device 102 by the key generation server 106 and stored
in a protected memory 109 in the hardware device 102. This device
unique key 110 is protected by the hardware and is never exposed
later to software executing in a platform in which the hardware
device 102 is later installed. The platform in which the hardware
device 102 is installed may be any computing device, for example, a
mobile phone or computer.
[0029] In an embodiment, the hardware device 102 can be a
processor. The processor may be any one of a plurality of
processors such as a single core Intel.RTM. Pentium IV.RTM.
processor, a single core Intel Celeron processor, an Intel.RTM.
XScale processor or a multi-core processor such as Intel.RTM.
Pentium D, Intel.RTM. Xeon.RTM. processor, or Intel.RTM. Core.RTM.
Duo processor or any other type of processor. In another embodiment
the hardware device 102 can be an integrated circuit to be coupled
to a processor on a platform to control communications with
Input/Output devices. The integrated circuit can be one of a
plurality of integrated circuits in a chipset that are designed to
work together. For example, an integrated circuit in the chipset
can link the processor to high speed devices such as memory and
graphics controllers and another integrated circuit in the chipset
can link the processor to lower-speed peripherals accessed via a
Peripheral Controller Interface (PCI), Universal Serial Bus (USB)
or communications protocol such as Ethernet.
[0030] The key generation server 106 is an off-line server that
generates key materials including the hardware device unique key
110 assigned to the hardware device 102 and other keys used by the
platform, for example, keys that may be used by
encryption/decryption algorithms such as Advanced Encryption
Standard (AES). An off-line server is a secure facility for key
generation that does not directly interact with external entities
over the Internet. The key generation server 106 operates in a
secure/protected environment. There are many different methods that
can be used to perform the initial provisioning of the device
unique key 110 to the hardware device 102. The method used is
dependent on the security level of the manufacturing environment.
Three of these methods will be described in conjunction with FIGS.
2-4 below.
[0031] FIG. 2 is a flow graph illustrating a method for basic
initial manufacturing provisioning of a device unique key to the
hardware device.
[0032] At block 200, the key generation server 106 chooses a random
device unique key for the hardware device 102 that is coupled to
the manufacturing tester machine 104. Processing continues with
block 202.
[0033] At block 202, the key generation server 106 sends the device
unique key 110 for the hardware device 102 under test to the
manufacturing tester machine 104 using a secure channel 108. Upon
receiving the device unique key 110, the manufacturing tester
machine 104 stores the device unique key 110 in a protected memory
109 which can be a write-once memory or a re-writable memory such
as a Flash memory device in the hardware device 102. In an
embodiment, the write-once memory comprises a plurality of fuses,
and the unique key is stored by blowing fuses to permanently store
the device unique key 110 in the device 102. Processing continues
with block 204.
[0034] At block 204, the key generation server 106 derives a
provisioning identifier and a provisioning key 804 for the hardware
device 102 from the device unique key using different one-way
functions. The provisioning key 804 and provisioning identifier
will be described later. The use of a one-way function, allows the
provisioning key 804 and the provisioning identifier to be derived
from the device unique key 110 but the device unique key 110 cannot
be derived from the provisioning key 804 or the provisioning
identifier. In an embodiment, the one-way functions are pseudo
random functions (PRF) used for key derivation, such as Hash-based
Message Authentication Code (HMAC) and Advanced Encryption
Standard-Cipher-based Message Authentication Code (AES-CMAC). The
provisioning identifier and provisioning key 804 are unique to the
hardware device 102. Processing continues with block 206.
[0035] At block 206, the key generation server 106 stores the
provisioning identifier and the provisioning key derived from the
device unique key 110 in a provisioning database 112 for use later
in on-the-field key provisioning of other security keys to the
hardware device 102. Processing continues with block 208.
[0036] At block 208, the key generation server 106 deletes the copy
of the device unique key 110 stored in the key generation server
106 which was used to generate the provisioning key and
provisioning identifier (ID) stored in the provisioning database
112.
[0037] FIG. 3 is a flow graph illustrating a method for initial
manufacturing provisioning of the device unique key with a shared
key protection to the hardware device. To enhance security, the key
generation server 106 encrypts the device unique key 110 with a
shared key that is embedded in each hardware device 102 such that
only the hardware device 102 can decrypt the device unique key 110.
The manufacturing tester machine 104 does not store or have access
to the shared key. Thus, the manufacturing tester machine 104
cannot decrypt the device unique key 110 generated by the key
generation server 106.
[0038] At block 300, the hardware device 102 to be tested has a
symmetric shared key (SK) embedded in logic in the hardware device
102. The shared key is the same for a number of devices. The shared
key is known to the hardware device 102 and the key generation
server 106, but not known to the manufacturing tester machine 104.
In an embodiment, the shared key is generated by the key generation
server. The key generation server 106 chooses a random device
unique key for each hardware device 102. The key generation server
106 encrypts the device unique key using the shared key which is
known to the key generation server 106. The purpose of the shared
key is two-folded: (1) add protection against malicious
manufacturing tester, (2) add more protection to device unique key
after the device 102 has been manufactured. Processing continues
with block 302.
[0039] At block 302, the key generation server 106 sends an
encrypted device unique key to the manufacturing tester machine 104
using the secure channel 108. The manufacturing tester machine 104
stores the encrypted device unique key in the protected memory 109
(for example, write-once memory (fuses)) in the hardware device
102. As the hardware device 102 stores the shared key used by the
key generation server 106 to encrypt the device unique key, the
hardware device 102 can access its stored encrypted device unique
key and decrypt using the shared key to obtain the device unique
key. Processing continues with block 304.
[0040] At block 304, the key generation server 106 derives a
provisioning identifier and provisioning key from the device unique
key as described earlier in conjunction with the embodiment shown
in FIG. 2. Processing continues with block 306.
[0041] At block 306, the key generation server 106 deletes the
device unique key 110 that it has generated and stores the
provisioning identifier and provisioning key derived from the
device unique key 110 in the provisioning database 112
[0042] FIG. 4 is a flow graph illustrating a method for secure
initial manufacturing provisioning of the device key to the
hardware device. The method described in conjunction with FIG. 4 is
more secure than the methods described in conjunction with FIGS. 2
and 3 because the device unique key is generated in the device and
is not transmitted over a communications channel to any other
hardware device 102. The hardware device 102 has a symmetric shared
key (GK) embedded in logic. The GK is known to the hardware device
102 and the key generation server 106, but not known to the
manufacturing tester machine 104. In addition to the GK discussed
in the embodiment discussed in conjunction with FIG. 3, in this
embodiment an asymmetric key pair, that is, a public encryption key
(PEK) and private decryption key (PDK) are embedded in the hardware
device 102. This asymmetric key pair is also stored in the key
generation server 106.
[0043] The hardware device 102 generates a unique device key 110
using known methods which are beyond the scope of the present
invention. For example, the unique device key 110 can be generated
using a random gates technique or using physically unclonable
functions (PUF) with fuzzy extractors. The hardware device 102
derives a provisioning identifier (ID) and a provisioning key from
the device unique key 110, encrypts these two keys using PEK and
computes a Message Authentication Code (MAC) of the two keys using
the shared key. An example of functions used is shown below:
C1=RSA-Enc(PEK,Provisioning ID.parallel.Provisioning Key),
C2=MAC(GK,C1),
Ciphertext=C1.parallel.C2.
[0044] RSA-Enc(K, M) denotes RSA (Rivest, Shamir and Adleman)
encryption of message M using an RSA public encryption key K. In an
embodiment, the Message Authentication Code (MAC) function is HMAC.
In another embodiment the MAC function is AES-CMAC. 5. The hardware
device 102 outputs the ciphertext (encrypted keys) to the
manufacturing tester machine 104.
[0045] At block 400, the key generation server 106 receives the
ciphertext from the manufacturing tester machine 104 via a secure
channel 108. Processing continues with block 402.
[0046] At block 402, the key generation server 106, verifies the
MAC using GK, for each ciphertext, then decrypts using PDK. The key
generation server 106 obtains the provisioning ID and provisioning
key of the hardware device 102 securely via secure channel 108. In
an embodiment, the key generation server 106 performs the following
functions on the received ciphertext to obtain the provisioning
identifier and provisioning key derived from the device unique key
110 stored in the hardware device 102.
Verify C2=MAC(GK,C1)using GK,
Provisioning ID.parallel.Provisioning Key=RSA-Dec(PDK,C1)using
PDK,
[0047] Processing continues with block 404.
[0048] At block 404, the key generation server 106 stores the
provisioning identifier and provisioning key in a provisioning
database 112.
[0049] After the hardware device 102 is manufactured, the hardware
device 102 may be distributed to Outside Equipment Manufacturers
(OEMs) and installed in platforms. Typically, the platforms are
distributed to end users. There may be a need for the hardware
device manufacturer to send (provision) a key to the end user of
the platform that includes the hardware device 102. For example,
the hardware device manufacturer can provision a unique key per
hardware device 102, such as, a symmetric device authentication
key, a Trusted Platform Module (TPM) endorsement key, a
High-bandwidth Digital Content Protection (HDCP) key, or an
Advanced Access Content System (AACS) device key or a common key to
the hardware device 102.
[0050] In order to ensure that the hardware device manufacturer
only provisions the key to a hardware device 102 that it has
manufactured, prior to sending the key to the hardware device 102,
the key is encrypted using the provisioning key associated with the
hardware device 102 that was stored in the provisioning database
112. The device manufacturer can use this provisioning method
multiple times to provision different keys to hardware devices 102
that it has manufactured.
[0051] The provisioning database 112 in the key generation server
106 stores a provisioning identifier and a provisioning key for
each hardware device 102 that has been tested by the manufacturing
tester machine 104. To provision a key for a hardware device 102
associated with a provisioning identifier and provisioning key, the
key generation server 106 prepares the key material to be
provisioned to the hardware device 102. The key material, also
referred to as a "key blob" can be a single key, for example, a TPM
key or a plurality of keys, for example, a TPM key and a HDCP key.
Each hardware device 102 can be assigned different key
material.
[0052] The key generation server 106 encrypts the key material
using the provisioning key. The encryption is performed by a key
wrapping (encryption) algorithm that can be any encryption
algorithm, such as Advanced Encryption Standard-Galois/Counter Mode
(AES-GCM) mode encryption or Advanced Encryption Standard-Cipher
Block Chaining (AES-CBC) mode encryption combined with a pseudo
random function (PRF). AES-GCM and AES-CBC are defined in NIST
standard FIPS-197. The key generation server 106 prepares the
provisioning database 112 to store all of the provisioning IDs and
corresponding encrypted key(s).
[0053] FIG. 5 illustrates a system that includes a key generation
server 106, a provisioning server 500 and a platform 502 including
the hardware device 102 coupled to a communications network 504. In
an embodiment, the system also includes a storage device 506 which
may be a disk drive, for example, a Compact Disk (CD) or Digital
Video Disk (DVD) with a removable storage medium (CD or DVD).
[0054] The key generation server 106 sends the contents of the
provisioning database 112 to the provisioning server 500 so that
the provisioning server 500 can perform on-line provisioning of
keys via a communications network 504 to platforms 502 in which the
hardware device 102 is installed. The provisioning database 112 can
also be stored on a removable storage device, for example, a
non-volatile memory device such as a Flash memory or a Compact Disk
(CD) or Digital Video Disk (DVD) to perform off-line provisioning
of the key to the hardware device 102.
[0055] When the hardware device 102 is installed in a platform (for
example, a host system), and discovers that its keys have been
revoked, the device issues a request to contact the provisioning
server 500. In an embodiment, the request is sent from the hardware
device 102 via a host network stack in the platform 502 over a
secure communications channel to the provisioning server 500. As
the secure channel is robust against man-in-the-middle attack, even
if the host network stack is corrupted, the security of key
provisioning is not affected because only firmware can access the
provisioning ID and provisioning key.
[0056] FIG. 6 illustrates an embodiment of an on-line method for a
hardware device 102 to obtain a key from the provisioning
server.
[0057] At block 600, the hardware device 102 in the platform
obtains its device unique key stored in protected memory 109 in the
hardware device 102, for example, in fuses or in random gates. If
the hardware device unique key 110 is encrypted, the hardware
device 102 decrypts it using the shared key (GK). The hardware
device 102 derives the Provisioning ID from the device unique key
using a pseudo random function as discussed earlier in conjunction
with the key generation server 106. Processing continues with block
602.
[0058] At block 602, the hardware device 102 initiates a key
exchange protocol with the provisioning server 500 to set up a
secure channel. In an embodiment, the key exchange protocol is
performed using a Secure Sockets Layer (SSL)/Transport Layer
Security (TLS) session to verify that the provisioning server is
authorized. In an embodiment in which revealing the provisioning ID
over the communications network 504 does not pose a privacy
concern, the security channel is not necessary and is not used.
Processing continues with block 604.
[0059] At block 604, the hardware device 102 sends its Provisioning
ID to the provisioning server 500 via the secure channel over the
communication network, for example, the Internet. Processing
continues with block 606.
[0060] At block 606, the provisioning server 500 receives the
Provisioning ID from the provisioning database 112 and obtains the
encrypted key associated with the provisioning ID stored in the
provisioning data base. The hardware device 102 receives the
encrypted key from the provisioning server 500 via the secure
channel.
[0061] In some embodiments, the hardware device 102 may not have
access to the communications network and requires a key to be
provisioned in order to provide security functions in the hardware
device 102. The key can be provisioned to the hardware device 102
off-line by distributing the provisioning database 112 on a
removable storage device to the end user of the hardware device
102. The end user receives the entire provisioning database on the
removable storage device but can only use the key(s) in the
provisioning database that are encrypted by the hardware device's
Provisioning key that is derived from the unique device key.
[0062] For off-line provisioning, the hardware device 102 obtains
its provisioning ID using the method discussed for on-line
provisioning. However, instead of sending its provisioning ID via
the communications network, the hardware device 102 searches the
local provisioning database for the encrypted key(s) associated
with its provisioning ID.
[0063] FIG. 7 illustrates a method implemented in the hardware
device 102 for decrypting the encrypted key(s). The method shown in
FIG. 7 applies to an encrypted key provisioned using either on-line
or off-line provisioning.
[0064] At block 700, the hardware device 102 obtains it device
unique key 110 stored in the hardware device 102. Processing
continues with block 702.
[0065] At block 702, the hardware device 102 derives the
Provisioning Key and a Storage Key from the device unique key 110
using one-way pseudo random functions (PRF). The derived Storage
key can be used to seal arbitrary secrets of the platform. The
derived Provisioning key is used for provisioning. Processing
continues with block 704.
[0066] At block 704, the hardware device 102 uses the derived
provisioning key to decrypt the encrypted key(s) obtained using the
online or offline key provisioning method discussed in conjunction
with FIG. 6. Processing continues with block 706.
[0067] At block 706, the hardware device 102 stores the encrypted
key(s) locally in its secure storage. In another embodiment, the
encrypted key(s) can be encrypted again using the storage key and a
pseudo-random function, the result of this additional encryption
can be stored locally in secure storage instead of the received
encrypted key(s).
[0068] A hardware device 102 can successfully remotely obtain key
materials (encrypted keys) from the manufacturer of the hardware
device 102 because it can derive the provisioning key used to
encrypt the key materials. An attacker (for example, malware)
cannot get the key materials from the hardware device manufacturer
without the device unique key 110 from which the provisioning key
is derived using a pseudo random function. The attacker may have
access to the provisioning database via the removable storage
device, but the attacker cannot decrypt the encrypted keys without
a valid Provisioning Key. In an embodiment that uses the shared key
discussed in conjunction with FIG. 3, if the manufacturing tester
machine 104 is corrupted, the attacker cannot get the encrypted
key(s) from the manufacture because all the device unique keys are
encrypted by the shared key which is unknown to the manufacturing
tester machine 104. In the embodiment discussed in conjunction with
FIG. 4, even if the manufacturing tester machine 104 has knowledge
of the shared key, it is unable to learn the device unique key or
Provisioning Key.
[0069] A small write-once memory is used to store a device unique
key as a root of trust for the hardware device 102 which is used to
derive other keys used to protect the hardware device 102 against
malicious attackers. In one embodiment, the write-once memory is
128-bits. In another embodiment, the write-once memory is 256-bits.
In other embodiments, the write-once memory is 128-bits or 192-bits
or another size that is dependent on the length of the key used by
symmetric encryption. The method for storing keys in the hardware
device 102 during the manufacturing process is robust against a
malicious manufacturing tester machine 104 which is important when
device manufacturing is outsourced to other entities. In a platform
that includes at least processor and a chipset having one or more
integrated circuits, each integrated circuit in the chipset and
processor can include a security engine with a device unique key.
The provisioning of keys is simple and scalable and because of the
use of symmetric key operations, the size of the Trusted Computing
Base (TCB) is reduced.
[0070] A trusted platform typically has a Device Authentication Key
(DAK) for attesting to the configuration of an execution
environment or for platform authentication. The DAK can be
provisioned to the trusted platform using the on-line or off-line
provisioning methods described in conjunction with FIGS. 6-7. A
trusted platform may also have a storage root key (SRK) used for
encrypting platform keys and secrets. In an embodiment, the DAK can
be a Direct Anonymous Attestation (DAA) key or any other type of
digital signing key.
[0071] Direct Anonymous Attestation (DAA) is a cryptographic
protocol for providing anonymous signatures. DAA is designed
specifically for the Trusted Platform Module (TPM). DAA enables the
remote authentication of a trusted platform while preserving the
privacy of the user of the trusted platform.
[0072] If a vulnerability in the Trusted Computing Base (TCB) of
the platform is found, for example, based on a malicious attack
(software virus) on the platform, the vulnerability may be patched
by installing another version of firmware in the platform. However,
the platform cannot cryptographically prove that the vulnerability
in the firmware has been corrected to others, for example, external
entities.
[0073] FIG. 8 is a block diagram of an embodiment of a Trusted
Computing Base (TCB) 800 of a trusted platform.
[0074] In the key hierarchy of a Trusted Computing Base 800, there
is a device unique key 110 embedded in a hardware device 102 in a
platform 502. The device unique key 110 is permanently stored in a
protected storage 109 in the hardware device 102. This device
unique key 110 is the "root key" for other keys in the platform,
that is, several other keys in the Trusted Computing Base 800 are
derived from this device unique key 110, such as, a provisioning
ID802, a provisioning base key 822, a provisioning key 804 and a
storage key 806.
[0075] The provisioning ID 802 and provisioning key 804 are used to
download a unique DAK key from a key provisioning server 500. The
storage key 806 is used for encrypting keys and secrets of the
platform 502 including the DAK key.
[0076] The upgraded firmware in the TCB 802 needs to access these
derived keys, for example, provisioning ID 802, provisioning key
804, and storage key 806 to be functional. A unique identifier is
assigned to identify different versions of the firmware. In one
embodiment, the unique identifier is a Security Version Number
(SVN) 808 that can be stored in non-reportable firmware code 818 in
non-volatile memory and read by the unrecoverable TCB 810. In other
embodiments, instead of assigning a unique identifier to identify
different versions of the firmware, the unique identifier for each
firmware version can be derived by performing a cryptographic
function on each version of the firmware image.
[0077] The keys that are derived from the device unique key 110,
that is, the provisioning ID 802, provisioning key 804, and storage
key 806 are computed inside a signature verification portion of the
TCB 810, which is designated to be non-recoverable and can also be
referred to as the "unrecoverable TCB". The provisioning key 804
and storage key 806 are derived based on the Security Version
Number 808, then output from the signature verification portion of
the TCB 810 to a recoverable portion of the TCB 800. After the keys
have been derived from the device unique key 110, the signature
verification portion of the TCB 810 "locks" access to the device
unique key 110, preventing recoverable portions of the TCB 800 from
accessing the device unique key 110, that is, the raw "root key".
As the provisioning key 804 and storage key 806 are stored in the
recoverable portions of the TCB, the Provisioning key 804 and
Storage key 806 are updated when there is an update to the SVN 808
of the TCB 800. For example, the key derivations are performed
inside the recoverable TCB 810 during device boot. Each time new
firmware is installed in the platform, a device re-boot is
performed which results in a new provisioning key and storage key
that are computed during the device re-boot.
[0078] FIG. 9 is a flowgraph illustrating a method to recover from
a security vulnerability in a TCB 800. If security vulnerability
has been discovered in the recoverable TCB, a TCB recovery event is
triggered.
[0079] At block 900, when a security vulnerability is found in the
TCB 800, the platform/hardware manufacturer generates a new version
of the firmware that includes a software modification to fix the
vulnerability. The new version of the firmware is assigned a
security version number 808. To verify that the firmware is not
malware but is from the platform/hardware manufacturer, the new
version of the firmware is digitally signed (encrypted) by the
hardware manufacturer. The unrecoverable TCB 810 can verify the
signature using the manufacturer's public key, that is, the
firmware verification key embedded in the hardware device 102 and
make sure that the new firmware image was received from the
hardware manufacturer and is not malware. The manufacturer
distributes the new firmware to each platform using known methods,
for example, via a firmware update from an Original Equipment
Manufacturer (OEM), or a software update from a software
manufacturer. Processing continues with block 902.
[0080] At block 902, after the new version of the firmware is
installed on the platform, the signature verification portion of
the TCB 800 verifies the signature of the new firmware for the
recoverable TCB using the firmware verification key 820 embedded in
the hardware device 102 in the platform. The signature verification
portion of the TCB 810 retrieves the Security Version Number (SVN)
808 of the new firmware embedded in the firmware and retrieves the
device unique key 110 stored in the hardware device 102. The
provisioning ID 802 and Provisioning Base Key 822 are derived from
the device unique key 110. The Provisioning key 804 is derived from
the Provisioning Base Key 822 and the SVN 808. The Storage Key 806
is derived from the device unique key 110 and the SVN 808. Methods
for deriving these keys will be described later. The derived
provisioning ID 802, provisioning key 804, and storage key 806 are
sent to the recoverable TCB. Processing continues with block
804.
[0081] At block 906, a new DAK is generated for the new version of
firmware. After a TCB recover event has been triggered, the
hardware manufacturer re-provisions a Device Authentication Key
(DAK) to each platform 502 that received the new version of the
firmware to fix the security vulnerability. The key generation
server 106 generates the DAKs and sends to the respective platforms
502 via the communications network 504. As discussed earlier, the
provisioning database 112 in the key generation server 106 stores a
provisioning ID 802 and a Provisioning Base Key 822 for each
hardware device 102 that was tested by the manufacturing tester
device. A provisioning key 804 is derived from the stored
provisioning base key 822 based on the latest Security Version
Number 808. In an embodiment, the key derivation method selected is
the same as used in block 904. The new unique DAK is generated for
the hardware device 102 and encrypted using the provisioning key
804. Any symmetric encryption algorithm can be used, for example,
AES-GCM. The key generation server 106 prepares a DAK provisioning
database in which each database entry has a provisioning key 804
and the corresponding encrypted DAK. The key generation server 106
sends the DAK provisioning database to the key provisioning server
500. Each platform downloads a new DAK from the key provisioning
server 500.
[0082] The recoverable TCB has the provisioning ID 802 and
provisioning key 804 and communicates with the provisioning server
500 using a provisioning protocol to obtain the new DAK key for the
platform 502. The platform 502 encrypts its provisioning ID 802
using the provisioning server 500's public key and sends the
encrypted provisioning ID to the provisioning server 500. The
provisioning server 500 decrypts the received encrypted
provisioning ID using its private key to obtain the unencrypted
provisioning ID 802 of the requesting platform 502. The
provisioning server 500 searches the DAK provisioning database for
an entry corresponding to the provisioning ID 802 that stores the
encrypted new DAK key which is encrypted by the new provisioning
key for the hardware device 102 in the platform 502. The
provisioning server 500 sends the encrypted new DAK to the platform
502. The platform 502 decrypts the new DAK using the new
provisioning key. The platform 502 re-encrypts the new DAK using
its new storage key 806 and stores the encrypted new DAK securely.
The encrypted new DAK is stored in non-volatile memory in the
platform 502. The non-volatile memory can be BIOS flash memory,
chipset flash memory, a solid state drive or hard disk drive. As
the DAK is encrypted by the storage key, even if the non-volatile
memory is accessed by an attacker, the attacker is unable to
decrypt the DAK.
[0083] If the platform 502 has not installed the new firmware to
fix the security vulnerability, it cannot derive the new
provisioning key 804 corresponding to the latest SVN. Thus, the
platform 502 cannot decrypt the new DAK; even it receives the
encrypted new DAK from the provisioning server 500. Processing
continues with block 908.
[0084] At block 908, after the platform 502 has installed the new
firmware with a new SVN, it also has a new storage key 806
corresponding to the new SVN. Before the firmware upgrade, the
platform 502 may have encrypted the platform key materials and
secrets using an old storage key 806 corresponding to an old SVN.
Thus, the platform 502 performs key migration, that is, re-encrypts
all the platform key materials using the new storage key. For each
data item (key materials or secrets) that is encrypted by the old
storage key, the platform 502 decrypts using the old storage key
and verifies the integrity of the unencrypted data. The platform
502 then re-encrypts the data using the new storage key and stores
the encrypted data in non-volatile memory in the platform. As
discussed earlier, the non-volatile memory is memory other than the
TCB.
[0085] A new storage key is derived because if an attacker has
corrupted the old version of the TCB firmware and extracted the
storage key 806 associated with the old version, the attacker can
still decrypt the platform secrets (including the new DAK) even
after the firmware update.
[0086] If software vulnerability has been discovered in the current
recoverable TCB, recovery is possible by updating the recoverable
TCB firmware that fixes the vulnerability and assigning a new SVN
808. The old version of TCB cannot access or derive the new
provisioning key 804 or the new storage key 806, which is used for
downloading and wrapping (encrypting) a new DAK key, respectively
because these keys are derived using the new SVN 808. In addition,
the manufacturer of the platform 502 may revoke the DAKs associated
with the previous TCB version. Each platform 502, after downloading
new DAK, can use its new DAK to attest and cryptographically prove
which version of the TCB 800 is being used.
[0087] If the recoverable TCB has not been upgraded with new
firmware that fixes the vulnerability, the recoverable TCB cannot
obtain a provisioning key 804 for the latest SVN, thus it cannot
get the current version of the DAK key. Also, if the recoverable
TCB gets access to previous storage Keys 824 for the key migration
purpose and the recoverable TCB has been upgraded to a new SVN, the
new recoverable TCB can decrypt the keys and data from the previous
version and encrypt them using the new storage key.
[0088] Methods to perform key derivation to compute prior storage
keys will be described below. In an embodiment, the initial value
assigned to the SVN is 1 and for each new firmware update the SVN
increments by one. SK[i] denotes the Storage Key corresponding to
SVN i. The Provisioning ID and provisioning key 804 are computed as
shown below:
Provisioning ID=PRF(device unique key,"Provisioning ID"),
Provisioning Base Key=PRF(device unique key,"Provisioning Base
Key"),
Provisioning Key=PRF(Provisioning Base Key,"Provisioning
Key".parallel.SVN).
[0089] In one embodiment, the unrecoverable TCB derives all of the
previous Storage Keys 824 as follows:
For i=1, . . . ,SVN,
compute SK[i]=PRF(device unique key,"Storage Key".parallel.i).
[0090] The unrecoverable TCB then sends all the Storage Keys to the
recoverable TCB.
[0091] In another embodiment, only one prior storage key is
computed. A platform 502 that controls storage of data protected by
a storage key 806 may only require access to the current Storage
Key and its prior Storage Key. The prior storage key is the storage
key that was used by the platform 502 prior to the last firmware
update.
[0092] Firmware can decrypt all existing data using the prior SVN
and then re-encrypt the data using the current SVN, removing the
need for any old SVN keys except during this transition. The
unrecoverable TCB 810 outputs two Storage Keys, a first storage key
806 for the current SVN and a second storage key 824 for the prior
SVN. As the user of the platform may skip some firmware upgrades,
the prior SVN (pSVN) may not be SVN-1. The unrecoverable TCB 802
computes the following:
SK[SVN]=PRF(device unique key,"Storage Key".parallel.SVN).
SK[pSVN]=PRF(device unique key,"Storage Key".parallel.pSVN).
[0093] where: SVN is the current SVN; pSVN is the prior SVN and PRF
is a pseudo random function.
[0094] The SVN 808 is available from the firmware of the TCB 800.
The pSVN can be provided to the unrecoverable TCB 810 from the
non-volatile memory in which it is stored. For example, in an
implementation of a chipset TCB recovery implementation, the
platform stores pSVN in the Flash Partition Table FPT partition of
the Built In Operating System (BIOS). In an embodiment for a
processor TCB recovery implementation, a previous storage key can
be derived without using a pSVN.
[0095] FIG. 10 is a flowgraph of an embodiment of a hash chain
method to perform key derivation to compute prior storage keys. In
a platform 502 that does not have control over where protected data
is stored, multiple prior storage keys 824 are needed to ensure
proper access to previously protected data.
[0096] At block 1000, the current SVN 808 is read from the
recoverable TCB firmware. Processing continues with block 1002.
[0097] At block 1002, there are a maximum number of recoverable
prior SVNs (`n`). For example, in an embodiment, the maximum number
of recoverable prior SVNs can be 32. If the current SVN is less
than the maximum number of recoverable prior SVNs, processing
continues with block 1004. If not, that is SVN is greater than n,
the provisioning key and storage key cannot be derived and the TCB
is no longer recoverable.
[0098] At block 1004, the value of the storage key corresponding to
the maximum number of recoverable storage keys is computed as
follows:
SK[n]=PRF(device unique key,"Storage Key".parallel.n).
[0099] Processing continues with block 1006.
[0100] At block 1006, all of the storage keys up to the maximum
number-1 are computed as follows:
SK[i]=Hash(SK[i+1])for i=1, . . . ,n-1.
[0101] Given SK[i], the storage keys for any previous firmware
version can be derived by computing the hash function. However,
given SK[i], future versions of storage keys cannot be derived
without the device unique key 110. Processing continues with block
1008.
[0102] At block 1008, SK[SVN] is output.
[0103] The unrecoverable TCB 810 only needs to output a single
storage key 806. However, the amount of computation to derive the
storage key increases as maximum number of prior storage keys
increases but if the maximum number of prior storage keys is small,
the number of prior storage keys that can be recovered is
reduced.
[0104] In yet another embodiment, some storage keys are directly
derived from the device unique key 110, and other storage keys are
computed from the hash of the next version. The value of the
storage keys are defined as follows:
SK[i]=PRF(device unique key,"Storage Key".parallel.i)if i is a
multiplier of n,
SK[i]=Hash(SK[i+1])if i is not a multiplier of n. [0105] where n is
a checkpoint integer.
[0106] FIG. 11 is a flowgraph illustrating an embodiment of a
method performed by the unrecoverable TCB to derive the storage
keys.
[0107] At block 1100, the SVN 808 is read from the unrecoverable
TCB firmware. Processing continues with block 1102.
[0108] At block 1102, the current storage key is derived using the
device unique key 110 as follows:
Let m=[SVN/n];
SK[m-n]=PRF(device unique key,"Storage Key".parallel.m-n);
For i=mn-1, . . . ,SVN,SK[i]=Hash(SK[i+1]).
[0109] Processing continues with block 1104.
[0110] At block 1104, the prior storage keys are computed using the
current storage key as follows:
For i=1, . . . ,m-1,Compute SK[i-n]=PRF(device unique key,"Storage
Key".parallel.i-n).
[0111] Processing continues with block 1106.
[0112] At block 1106, the compute storage keys, SK[SVN], SK[n],
SK[2n], . . . , SK[(m-1)-n] are output to the recoverable TCB.
Given SK[SVN], SK[n], SK[2n], . . . , SK[(m-1)-n], the recoverable
TCB can compute any SK[i] for i=1, . . . , SVN.
[0113] Embodiments of methods to compute previous storage keys 824
for a single recoverable TCB have been described. However, a
platform can have multiple layers of recoverable TCBs. In an
embodiment, each layer of TCB has its own SVN 808. Each layer has a
derived key computed by the previous layer. If the security version
number is an integer, each layer of TCB may need to verify the
signature of the next layer TCB firmware. For example, in an
embodiment, the unrecoverable TCB can be a firmware patch loader,
the layer 1 TCB is firmware layer 1 and layer 2 TCB is the firmware
implementation of a higher level technology.
[0114] FIG. 12 is a block diagram illustrating the unrecoverable
TCB 810 and layer 1 TCB 1202. During a boot sequence, that is, each
time the platform is powered on, the unrecoverable TCB 810 receives
the device unique key 110.
[0115] At block 1204, the unrecoverable TCB 810 verifies the
signature of unrecoverable TCB firmware and forwards unrecoverable
TCB's SVN to block 1206. At block 1206, the unrecoverable TCB
derives a key for Layer 1 TCB 1202 based on performing a pseudo
random function on the received device unique key 110 and
unrecoverable TCB's SVN.
[0116] In layer 1 TCB 1202 at block 1208, Layer 1 TCB 1202 checks
the signature of Layer 1 TCB firmware. At block 1210, the Layer 1
TCB 1202 derives the key for Layer 2 TCB (not shown) based on
performing a pseudo random function on the received derived
unrecoverable TCB key and Layer 1 TCB's SVN in block 1210. To
generate k keys, the key generation functions shown in blocks 1204,
1206, 1208 and 1210 are repeated k times.
[0117] In an embodiment discussed earlier, in which a current key
and previous key are used, each level of a multi-layer TCB can
produce two keys based on the SVN and pSVN of that layer. These two
keys are derived from the SVN and pSVN keys of the previous
layer.
[0118] The hash chain method discussed in conjunction with FIG. 10,
provides single layer TCB recovery, however this does not scale to
multiple layers.
[0119] If the platform contains an active recoverable layer, that
can queried at run time, a hybrid approach uses the hash chain to
protect a recoverable layer. The recoverable layer stores the
remaining layer SVNs and can derive storage keys for any arbitrary
combination of pSVN of different layers on demand.
[0120] FIG. 13 is a block diagram illustrating a hybrid approach
using a hash chain to protect a recoverable layer. Four layers are
shown: an unrecoverable TCB layer 810, layer 1 TCB 1300, layer 2
TCB 1302 and layer 3 1304. All four layers shown can be implemented
in an embodiment for a processor unit. Only two of the layers: an
unrecoverable TCB layer 810 and layer 1 TCB 1300 are typically used
in an embodiment for a chipset. The key register 1314 can be a
special register in the processor unit or chipset that is used by
the unrecoverable TCB layer 810 and by layer 3 1304 in an
embodiment for a processor unit.
[0121] The TCB for each layer (i) is computed as follows:
TCB[i]=SVN of TCB layer i.
[0122] The unrecoverable TCB layer 810 receives the stored device
unique key 110, verifies the integrity and source of Layer 1
recoverable TCB firmware and calculates SK[TCB[1]] using hash
chaining in the PRF loop 1312. The PRF loop 1312 derives a
provisioning key for a particular layer for a particular revision
of the key and stores the provisioning key for layer 1 CB 1300 in
the key register. The PRF loop also generates the Layer 1 SVN 1305,
Layer 2 SVN 1306 and Layer 3 SVN 1308. The PRF function performed
in the PRF loop 1312 can be a hash function that is performed on
the root key and the current TCB version (or a previous TCB version
number).
[0123] Layer 1 TCB 1302 verifies the integrity and source of Layer
2 and stores Layer 2's Security Version Number (SVN) 1306 generated
by PRF loop 1312 in a protected register, for example, in a TCBSVN
Register 1310. The TCBSVN Register 1310 can be protected from being
overwritten by the other layers.
[0124] Layer 2 through the last layer perform the same operations
as discussed in conjunction with layer 1 1300. Instructions
implemented in the last layer can call a layer 1 function getKey
(TCB_request[ ]) which performs the following operations.
TABLE-US-00001 For i = 1, ..., TCB layer count If TCB_request[i]
> TCB[i], then return failure. If TCB_request[i] < TCB[i]
then tmp = SK[TCB_request[i]] using chaining Return PRF(tmp,
"Storage Key" .parallel. j .parallel. k); where j and k are SVNs
for layer 1 TCB 1300 and layer 2 TCB 1302.
[0125] The storage key 806 for any previous permutation of TCB
layers can be derived, if layer 1 remains active.
[0126] Layer 3 1304 also uses the provisioning key stored in the
key register 1314 and performs an optional PRF function in PRF loop
1318 if required to generate a previous version of the provisioning
key. A PRF function is performed at 1320 on either the stored
provisioning key stored in the key register 1314 or derived in PRF
loop 1318 with the stored layer 2 SVN 1306 and stored layer 3 SVN
1308. The storage keys are computed based on the result of this PRF
function 1326.
[0127] A corrupted platform is prevented from receiving a new DAK
from the provisioning server 500. Each platform can receive a new
DAK if it has updated its recoverable TCB firmware. If a platform
has been revoked, for example, the platform's device unique key 110
has been extracted during a malicious hardware attack, a DAK
re-provisioning protocol does not provide a new DAK to the
platform.
[0128] FIG. 14 illustrates an embodiment of a DAK provisioning
protocol between a platform 502 and a provisioning server 500.
[0129] At 1400, the platform 502 and the provisioning server 500
set up a secure communication channel using a standard protocol,
such as TLS/SSL.
[0130] At 1402, the platform 502 encrypts a message using its
previous DAK and sends the encrypted message to the provisioning
server 500. The provisioning server 500 checks the previous DAK and
performs a revocation check on the previous DAK to determine if it
has been revoked. If the platform 502 has been revoked, the
provisioning server 500 terminates the protocol.
[0131] At 1404, the Platform sends the Provisioning ID 802 over the
secure channel to the provisioning server 500. The provisioning
server 500 searches the DAK provisioning database using the
received provisioning ID (one per hardware device 102) and
retrieves the encrypted new DAK for the platform 502.
[0132] At 1406, the provisioning server 500 sends the new encrypted
DAK to the platform 502.
[0133] In an embodiment in which there is a privacy requirement for
the provisioning server 500 to delete the DAK after it has been
provisioned to the platform 502, the DAK re-provisioning is
modified to store the DAK in the provisioning server 500.
[0134] FIG. 15 illustrates an embodiment of the re-provisioning
protocol in FIG. 14 between the platform 502 and the provisioning
server 500 that supports privacy.
[0135] As discussed in conjunction with FIG. 14, at 1400, the
platform 502 sets up a secure channel with the provisioning server
500.
[0136] At 1402, the platform 502 proves that it has not been
revoked by sending its previous DAK to the provisioning server
500.
[0137] At 1404, the platform 502 sends the Provisioning ID over the
secure channel to the provisioning server 500. The provisioning
server 500 searches the DAK provisioning database for a match for
the previous DAK and retrieves the new DAK for the platform
502.
[0138] At 1406, the provisioning server 500 sends the new DAK
encrypted using the provisioning key 804 back to platform 502. The
platform 502 decrypts the encrypted DAK using its provisioning key
804.
[0139] At 1408, the platform 502 re-encrypts the received new DAK
using its storage key 806, which is unknown to the provisioning
server 500 and key generation server 106. The platform 502 sends
the new DAK encrypted by its storage key 806 to the provisioning
server 500. The provisioning server 500 deletes the platform's DAK
from its database and stores the new DAK encrypted by its storage
key in the database.
[0140] FIG. 16 illustrates an embodiment of a DAK backup retrieval
protocol between the platform and the provisioning server 500 that
stores the platform's DAK encrypted by its storage key.
[0141] If the platform loses its DAK, it can download the DAK
stored in the database in the provisioning server 500.
[0142] At 1600, the platform 502 encrypts its provisioning ID 804
using the provisioning server's public key and sends the encrypted
provisioning ID to the provisioning server 500. Upon receiving the
encrypted provisioning ID, the provisioning server 500 decrypts the
provisioning ID and searches for an entry corresponding to the
provisioning ID in the provisioning server's database.
[0143] At 1602, the provisioning server 500 sends the DAK encrypted
in by the platform's storage key 806 that is stored in the
provisioning server 500's database to the platform. Upon receiving
the encrypted DAK, the platform 502 uses its storage key to decrypt
the received encrypted DAK (the backup copy of the DAK).
[0144] The Previous Security Version Number (PSVN) is stored in a
non-volatile re-writable memory such as a Flash memory in the
platform 502. A simple wear-out protection algorithm is used to
store the PSVN persistently in the non-volatile re-writable memory
with minimal flash file system support to avoid erase cycles in the
non-volatile re-writable memory.
[0145] A 64-byte block (partition) in the non-volatile re-writable
memory (for example, Flash memory) is used to store the Previous
Security Version (PSVN). Each byte represents a potential PSVN,
with only a single byte of the 64-byte block being valid at any
time. The default value for a byte in the 64-byte block is 255
(0xFF in hexadecimal representation). If the value of the byte is 0
(0x00 in hexadecimal representation), the PSVN entry has already
been used and is now invalid. Any other value (1 through 254
(0x01-0xFE in hexadecimal representation)) indicates that the PSVN
entry is valid.
[0146] FIG. 17 is flowgraph of an embodiment of a method for
storing a PSVN in the non-volatile re-writable memory.
[0147] At block 1700, if the current byte address is less than the
maximum byte address in the 64-byte block, processing continues
with block 1702.
[0148] At block 1702, the byte in the 64-byte block at the current
address is read. Processing continues with block 1704.
[0149] At block 1704, if the value is zero, processing continues
with block 1705. If not, processing continues with block 1706.
[0150] At block 1705, the address of the 64-byte block is
incremented to read the next byte location. Processing continues
with block 17000.
[0151] At block 1706, if the value is 255 there is no active PSVN.
Processing continues with block 1708. If the value is not 255, the
value is 1 through 254 and the PSVN is valid. Processing continues
with block 1710.
[0152] At block 1710, the previous root key is derived.
[0153] At block 1708, the number of PSVN entries exceeds 64 (the
number of locations available in the 64-byte block reserved for
storing PSVN entries), no provisioning keys can be derived and the
DAK keys cannot be re-keyed.
[0154] A method and apparatus has been described for a platform to
prove the TCB has been patched by facilitating provisioning of a
new DAK. This method and apparatus can be used by security
applications such as, Manageability Engine (ME), and TPM.
[0155] It will be apparent to those of ordinary skill in the art
that methods involved in embodiments of the present invention may
be embodied in a computer program product that includes a computer
usable medium. For example, such a computer usable medium may
consist of a read only memory device, such as a Compact Disk Read
Only Memory (CD ROM) disk or conventional ROM devices, or a
computer diskette, having a computer readable program code stored
thereon.
[0156] While embodiments of the invention have been particularly
shown and described with references to embodiments thereof, it will
be understood by those skilled in the art that various changes in
form and details may be made therein without departing from the
scope of embodiments of the invention encompassed by the appended
claims.
* * * * *