US20120137137A1 - Method and apparatus for key provisioning of hardware devices - Google Patents
Method and apparatus for key provisioning of hardware devices Download PDFInfo
- Publication number
- US20120137137A1 US20120137137A1 US12/956,793 US95679310A US2012137137A1 US 20120137137 A1 US20120137137 A1 US 20120137137A1 US 95679310 A US95679310 A US 95679310A US 2012137137 A1 US2012137137 A1 US 2012137137A1
- Authority
- US
- United States
- Prior art keywords
- key
- provisioning
- hardware device
- encrypted
- derived
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/73—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by creating or determining hardware identification, e.g. serial numbers
Definitions
- 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;
- FIG. 4 is a flow graph illustrating a method for secure initial manufacturing provisioning of a device unique key 110 to the hardware device
- 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;
- FIG. 6 illustrates an embodiment of an on-line method for a device to obtain a key from the provisioning server
- FIG. 8 is a block diagram of an embodiment of a Trusted Computing Base (TCB) of a trusted platform
- FIG. 9 is a flowgraph illustrating a method to recover from a security vulnerability in the TCB shown in FIG. 8 ;
- FIG. 14 illustrates an embodiment of a Device Authentication Key (DAK) provisioning protocol between a platform and a provisioning server;
- DAK Device Authentication Key
- FIG. 15 illustrates an embodiment of the re-provisioning protocol in FIG. 14 between the platform and the provisioning server that supports privacy;
- 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.
- DAK Device Authentication Key
- 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.
- TDB Trusted Computing Base
- 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.
- TLS Transport Layer Security
- 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.
- 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.
- PCI Peripheral Controller Interface
- USB Universal Serial Bus
- Ethernet communications protocol
- FIG. 2 is a flow graph illustrating a method for basic initial manufacturing provisioning of a device unique key to the hardware device.
- 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 .
- 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 .
- the manufacturing tester machine 104 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 .
- 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 .
- 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 .
- 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 .
- 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.
- 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 .
- 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 .
- 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
- 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.
- GK is known to the hardware device 102 and the key generation server 106 , but not known to the manufacturing tester machine 104 .
- GK symmetric shared key
- Ciphertext C 1 ⁇ C 2.
- RSA-Enc(K, M) denotes RSA (Rivest, Shamir and Adleman) encryption of message M using an RSA public encryption key K.
- the Message Authentication Code (MAC) function is HMAC.
- the MAC function is AES-CMAC. 5.
- the hardware device 102 outputs the ciphertext (encrypted keys) to the manufacturing tester machine 104 .
- the key generation server 106 stores the provisioning identifier and provisioning key in a provisioning database 112 .
- 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 .
- 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 .
- 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 .
- TPM Trusted Platform Module
- HDCP High-bandwidth Digital Content Protection
- 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 .
- 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.
- 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).
- 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 .
- 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).
- 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).
- 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 .
- the device 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 .
- 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 .
- 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.
- FIG. 6 illustrates an embodiment of an on-line method for a hardware device 102 to obtain a key from the provisioning server.
- 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 .
- the hardware device 102 initiates a key exchange protocol with the provisioning server 500 to set up a secure channel.
- 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.
- SSL Secure Sockets Layer
- TLS Transport Layer Security
- the security channel is not necessary and is not used. Processing continues with 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 .
- 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.
- 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.
- 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.
- 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.
- the hardware device 102 obtains it device unique key 110 stored in the hardware device 102 . Processing continues with 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 .
- 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 .
- the hardware device 102 stores the encrypted key(s) locally in its secure storage.
- 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).
- 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
- An attacker 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.
- 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 .
- the manufacturing tester machine 104 has knowledge of the shared key, it is unable to learn the device unique key or Provisioning Key.
- 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.
- the write-once memory is 128-bits.
- the write-once memory is 256-bits.
- 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.
- 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.
- DAA Direct Anonymous Attestation
- TPM Trusted Platform Module
- TLB Trusted Computing Base
- the vulnerability may be patched by installing another version of firmware in the platform.
- the platform cannot cryptographically prove that the vulnerability in the firmware has been corrected to others, for example, external entities.
- 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 ID 802 , a provisioning base key 822 , a provisioning key 804 and a storage key 806 .
- 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.
- 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.
- 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 .
- the unique identifier for each firmware version can be derived by performing a cryptographic function on each version of the firmware image.
- 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 .
- 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”.
- 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 .
- 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.
- 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.
- the platform/hardware manufacturer 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 .
- 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 .
- OEM Original Equipment Manufacturer
- 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 .
- a new DAK is generated for the new version of firmware.
- 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.
- DAK Device Authentication Key
- the key generation server 106 generates the DAKs and sends to the respective platforms 502 via the communications network 504 .
- 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 .
- 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 .
- 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.
- the platform 502 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 .
- 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.
- 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.
- 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” ⁇ SVN).
- the unrecoverable TCB derives all of the previous Storage Keys 824 as follows:
- the unrecoverable TCB then sends all the Storage Keys to the recoverable TCB.
- 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.
- 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” ⁇ SVN).
- SK[ p SVN] PRF(device unique key,“Storage Key” ⁇ p SVN).
- SVN is the current SVN
- pSVN is the prior SVN
- PRF is a pseudo random function
- 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.
- the platform stores pSVN in the Flash Partition Table FPT partition of the Built In Operating System (BIOS).
- BIOS Built In Operating System
- a previous storage key can be derived without using a pSVN.
- FIG. 10 is a flowgraph of an embodiment of a hash chain method to perform key derivation to compute prior storage keys.
- 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.
- the current SVN 808 is read from the recoverable TCB firmware. Processing continues with block 1002 .
- n there are a maximum number of recoverable prior SVNs (‘n’).
- 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.
- 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” ⁇ n).
- SK[SVN] is output.
- the unrecoverable TCB 810 only needs to output a single storage key 806 .
- 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.
- 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” ⁇ i )if i is a multiplier of n,
- FIG. 11 is a flowgraph illustrating an embodiment of a method performed by the unrecoverable TCB to derive the storage keys.
- the SVN 808 is read from the unrecoverable TCB firmware. Processing continues with block 1102 .
- the current storage key is derived using the device unique key 110 as follows:
- the prior storage keys are computed using the current storage key as follows:
- the compute storage keys, SK[SVN], SK[n], SK[2n], . . . , SK[(m ⁇ 1) ⁇ n] are output to the recoverable TCB.
- Embodiments of methods to compute previous storage keys 824 for a single recoverable TCB have been described.
- a platform can have multiple layers of recoverable TCBs.
- 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.
- the unrecoverable TCB can be a firmware patch loader
- the layer 1 TCB is firmware layer 1
- layer 2 TCB is the firmware implementation of a higher level technology.
- FIG. 12 is a block diagram illustrating the unrecoverable TCB 810 and layer 1 TCB 1202 .
- the unrecoverable TCB 810 receives the device unique key 110 .
- the unrecoverable TCB 810 verifies the signature of unrecoverable TCB firmware and forwards unrecoverable TCB's SVN to 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.
- 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.
- the hash chain method discussed in conjunction with FIG. 10 provides single layer TCB recovery, however this does not scale to multiple layers.
- 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.
- 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.
- the TCB for each layer (i) is computed as follows:
- TCB[ i ] SVN of TCB layer i.
- 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).
- 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.
- 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.
- TCB_request[i] > TCB[i]
- tmp SK[TCB_request[i]] using chaining Return PRF(tmp, “Storage Key” ⁇ j ⁇ k); where j and k are SVNs for layer 1 TCB 1300 and layer 2 TCB 1302.
- the storage key 806 for any previous permutation of TCB layers can be derived, if layer 1 remains active.
- 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 .
- FIG. 14 illustrates an embodiment of a DAK provisioning protocol between a platform 502 and a provisioning server 500 .
- the platform 502 and the provisioning server 500 set up a secure communication channel using a standard protocol, such as TLS/SSL.
- 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.
- 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 .
- the provisioning server 500 sends the new encrypted DAK to the platform 502 .
- the DAK re-provisioning is modified to store the DAK in the provisioning server 500 .
- 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.
- the platform 502 sets up a secure channel with the provisioning server 500 .
- the platform 502 proves that it has not been revoked by sending its previous DAK to the provisioning server 500 .
- 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 .
- 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 .
- 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.
- 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.
- the platform If the platform loses its DAK, it can download the DAK stored in the database in the provisioning server 500 .
- 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 .
- the provisioning server 500 decrypts the provisioning ID and searches for an entry corresponding to the provisioning ID in the provisioning server's database.
- 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.
- the platform 502 uses its storage key to decrypt the received encrypted DAK (the backup copy of the DAK).
- 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.
- a 64-byte block (partition) in the non-volatile re-writable 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.
- FIG. 17 is flowgraph of an embodiment of a method for storing a PSVN in the non-volatile re-writable memory.
- processing continues with block 1705 . If not, processing continues with block 1706 .
- the previous root key is derived.
- 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.
- 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.
- ME Manageability Engine
- 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.
- 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.
- CD ROM Compact Disk Read Only Memory
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.
Description
- This disclosure relates generally to the field of information processing and in particular to the field of security in computing systems and microprocessors.
- 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).
- 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.
- 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:
-
FIG. 1 is a block diagram illustrating a system for performing the initial key provisioning in a manufacturing environment; -
FIG. 2 is a flow graph illustrating a method for basic initial manufacturing provisioning of a deviceunique key 110 to the hardware device; -
FIG. 3 is a flow graph illustrating a method for initial manufacturing provisioning of the deviceunique key 110 with shared key protection of a deviceunique key 110 to the hardware device; -
FIG. 4 is a flow graph illustrating a method for secure initial manufacturing provisioning of a deviceunique key 110 to the hardware device; -
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; -
FIG. 6 illustrates an embodiment of an on-line method for a device to obtain a key from the provisioning server; -
FIG. 7 illustrates a method for decrypting the encrypted key(s) implemented in the device; -
FIG. 8 is a block diagram of an embodiment of a Trusted Computing Base (TCB) of a trusted platform; -
FIG. 9 is a flowgraph illustrating a method to recover from a security vulnerability in the TCB shown inFIG. 8 ; -
FIG. 10 is a flowgraph of an embodiment of a hash chain method to perform key derivation to compute prior storage keys; -
FIG. 11 is a flowgraph illustrating an embodiment of a method performed by the unrecoverable TCB to derive the Storage Keys; -
FIG. 12 is a block diagram of a two layer TCB; -
FIG. 13 is a block diagram illustrating a hybrid approach using a hash chain to protect a recoverable layer; -
FIG. 14 illustrates an embodiment of a Device Authentication Key (DAK) provisioning protocol between a platform and a provisioning server; -
FIG. 15 illustrates an embodiment of the re-provisioning protocol inFIG. 14 between the platform and the provisioning server that supports privacy; -
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; -
FIG. 17 is flowgraph of an embodiment of a method for storing a P-SVN in the non-volatile re-writable memory. - 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.
- 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.
- 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.
- 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.
- 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. -
FIG. 1 is a block diagram illustrating asystem 100 for performing the initial key provisioning in a manufacturing environment. Thesystem 100 includes ahardware device 102, amanufacturing tester machine 104 and akey generation server 106. Themanufacturing tester machine 104 and thekey generation server 106 communicate via asecure 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. - During manufacturing, a device
unique key 110 is assigned to thehardware device 102 by thekey generation server 106 and stored in a protectedmemory 109 in thehardware device 102. This deviceunique key 110 is protected by the hardware and is never exposed later to software executing in a platform in which thehardware device 102 is later installed. The platform in which thehardware device 102 is installed may be any computing device, for example, a mobile phone or computer. - 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® Pentium IV® processor, a single core Intel Celeron processor, an Intel® XScale processor or a multi-core processor such as Intel® Pentium D, Intel® Xeon® processor, or Intel® Core® Duo processor or any other type of processor. In another embodiment thehardware 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. - The
key generation server 106 is an off-line server that generates key materials including the hardware deviceunique key 110 assigned to thehardware 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. Thekey 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 deviceunique key 110 to thehardware device 102. The method used is dependent on the security level of the manufacturing environment. Three of these methods will be described in conjunction withFIGS. 2-4 below. -
FIG. 2 is a flow graph illustrating a method for basic initial manufacturing provisioning of a device unique key to the hardware device. - At
block 200, thekey generation server 106 chooses a random device unique key for thehardware device 102 that is coupled to themanufacturing tester machine 104. Processing continues withblock 202. - At
block 202, thekey generation server 106 sends the deviceunique key 110 for thehardware device 102 under test to themanufacturing tester machine 104 using asecure channel 108. Upon receiving the deviceunique key 110, themanufacturing tester machine 104 stores the deviceunique key 110 in a protectedmemory 109 which can be a write-once memory or a re-writable memory such as a Flash memory device in thehardware 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 deviceunique key 110 in thedevice 102. Processing continues withblock 204. - At
block 204, thekey generation server 106 derives a provisioning identifier and aprovisioning key 804 for thehardware device 102 from the device unique key using different one-way functions. Theprovisioning key 804 and provisioning identifier will be described later. The use of a one-way function, allows theprovisioning key 804 and the provisioning identifier to be derived from the deviceunique key 110 but the deviceunique key 110 cannot be derived from theprovisioning 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 thehardware device 102. Processing continues withblock 206. - At
block 206, thekey generation server 106 stores the provisioning identifier and the provisioning key derived from the deviceunique key 110 in aprovisioning database 112 for use later in on-the-field key provisioning of other security keys to thehardware device 102. Processing continues withblock 208. - At
block 208, thekey generation server 106 deletes the copy of the deviceunique key 110 stored in thekey generation server 106 which was used to generate the provisioning key and provisioning identifier (ID) stored in theprovisioning database 112. -
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, thekey generation server 106 encrypts the deviceunique key 110 with a shared key that is embedded in eachhardware device 102 such that only thehardware device 102 can decrypt the deviceunique key 110. Themanufacturing tester machine 104 does not store or have access to the shared key. Thus, themanufacturing tester machine 104 cannot decrypt the deviceunique key 110 generated by thekey generation server 106. - At
block 300, thehardware device 102 to be tested has a symmetric shared key (SK) embedded in logic in thehardware device 102. The shared key is the same for a number of devices. The shared key is known to thehardware device 102 and thekey generation server 106, but not known to themanufacturing tester machine 104. In an embodiment, the shared key is generated by the key generation server. Thekey generation server 106 chooses a random device unique key for eachhardware device 102. Thekey generation server 106 encrypts the device unique key using the shared key which is known to thekey 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 thedevice 102 has been manufactured. Processing continues withblock 302. - At
block 302, thekey generation server 106 sends an encrypted device unique key to themanufacturing tester machine 104 using thesecure channel 108. Themanufacturing tester machine 104 stores the encrypted device unique key in the protected memory 109 (for example, write-once memory (fuses)) in thehardware device 102. As thehardware device 102 stores the shared key used by thekey generation server 106 to encrypt the device unique key, thehardware device 102 can access its stored encrypted device unique key and decrypt using the shared key to obtain the device unique key. Processing continues withblock 304. - At
block 304, thekey generation server 106 derives a provisioning identifier and provisioning key from the device unique key as described earlier in conjunction with the embodiment shown inFIG. 2 . Processing continues withblock 306. - At
block 306, thekey generation server 106 deletes the deviceunique key 110 that it has generated and stores the provisioning identifier and provisioning key derived from the deviceunique key 110 in theprovisioning database 112 -
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 withFIG. 4 is more secure than the methods described in conjunction withFIGS. 2 and 3 because the device unique key is generated in the device and is not transmitted over a communications channel to anyother hardware device 102. Thehardware device 102 has a symmetric shared key (GK) embedded in logic. The GK is known to thehardware device 102 and thekey generation server 106, but not known to themanufacturing tester machine 104. In addition to the GK discussed in the embodiment discussed in conjunction withFIG. 3 , in this embodiment an asymmetric key pair, that is, a public encryption key (PEK) and private decryption key (PDK) are embedded in thehardware device 102. This asymmetric key pair is also stored in thekey generation server 106. - 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. Thehardware device 102 derives a provisioning identifier (ID) and a provisioning key from the deviceunique 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∥Provisioning Key), -
C2=MAC(GK,C1), -
Ciphertext=C1∥C2. - 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 themanufacturing tester machine 104. - At
block 400, thekey generation server 106 receives the ciphertext from themanufacturing tester machine 104 via asecure channel 108. Processing continues withblock 402. - At
block 402, thekey generation server 106, verifies the MAC using GK, for each ciphertext, then decrypts using PDK. Thekey generation server 106 obtains the provisioning ID and provisioning key of thehardware device 102 securely viasecure channel 108. In an embodiment, thekey generation server 106 performs the following functions on the received ciphertext to obtain the provisioning identifier and provisioning key derived from the deviceunique key 110 stored in thehardware device 102. -
Verify C2=MAC(GK,C1)using GK, -
Provisioning ID∥Provisioning Key=RSA-Dec(PDK,C1)using PDK, - Processing continues with
block 404. - At
block 404, thekey generation server 106 stores the provisioning identifier and provisioning key in aprovisioning database 112. - After the
hardware device 102 is manufactured, thehardware 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 thehardware device 102. For example, the hardware device manufacturer can provision a unique key perhardware 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 thehardware device 102. - 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 thehardware device 102, the key is encrypted using the provisioning key associated with thehardware device 102 that was stored in theprovisioning database 112. The device manufacturer can use this provisioning method multiple times to provision different keys tohardware devices 102 that it has manufactured. - The
provisioning database 112 in thekey generation server 106 stores a provisioning identifier and a provisioning key for eachhardware device 102 that has been tested by themanufacturing tester machine 104. To provision a key for ahardware device 102 associated with a provisioning identifier and provisioning key, thekey generation server 106 prepares the key material to be provisioned to thehardware 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. Eachhardware device 102 can be assigned different key material. - 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. Thekey generation server 106 prepares theprovisioning database 112 to store all of the provisioning IDs and corresponding encrypted key(s). -
FIG. 5 illustrates a system that includes akey generation server 106, aprovisioning server 500 and aplatform 502 including thehardware device 102 coupled to acommunications network 504. In an embodiment, the system also includes astorage 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). - The
key generation server 106 sends the contents of theprovisioning database 112 to theprovisioning server 500 so that theprovisioning server 500 can perform on-line provisioning of keys via acommunications network 504 toplatforms 502 in which thehardware device 102 is installed. Theprovisioning 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 thehardware device 102. - 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 theprovisioning server 500. In an embodiment, the request is sent from thehardware device 102 via a host network stack in theplatform 502 over a secure communications channel to theprovisioning 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. -
FIG. 6 illustrates an embodiment of an on-line method for ahardware device 102 to obtain a key from the provisioning server. - At
block 600, thehardware device 102 in the platform obtains its device unique key stored in protectedmemory 109 in thehardware device 102, for example, in fuses or in random gates. If the hardware deviceunique key 110 is encrypted, thehardware device 102 decrypts it using the shared key (GK). Thehardware device 102 derives the Provisioning ID from the device unique key using a pseudo random function as discussed earlier in conjunction with thekey generation server 106. Processing continues withblock 602. - At
block 602, thehardware device 102 initiates a key exchange protocol with theprovisioning 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 thecommunications network 504 does not pose a privacy concern, the security channel is not necessary and is not used. Processing continues withblock 604. - At
block 604, thehardware device 102 sends its Provisioning ID to theprovisioning server 500 via the secure channel over the communication network, for example, the Internet. Processing continues withblock 606. - At
block 606, theprovisioning server 500 receives the Provisioning ID from theprovisioning database 112 and obtains the encrypted key associated with the provisioning ID stored in the provisioning data base. Thehardware device 102 receives the encrypted key from theprovisioning server 500 via the secure channel. - 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 thehardware device 102. The key can be provisioned to thehardware device 102 off-line by distributing theprovisioning database 112 on a removable storage device to the end user of thehardware 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. - 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, thehardware device 102 searches the local provisioning database for the encrypted key(s) associated with its provisioning ID. -
FIG. 7 illustrates a method implemented in thehardware device 102 for decrypting the encrypted key(s). The method shown inFIG. 7 applies to an encrypted key provisioned using either on-line or off-line provisioning. - At
block 700, thehardware device 102 obtains it deviceunique key 110 stored in thehardware device 102. Processing continues withblock 702. - At
block 702, thehardware device 102 derives the Provisioning Key and a Storage Key from the deviceunique 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 withblock 704. - At
block 704, thehardware 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 withFIG. 6 . Processing continues withblock 706. - At
block 706, thehardware 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). - A
hardware device 102 can successfully remotely obtain key materials (encrypted keys) from the manufacturer of thehardware 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 withFIG. 3 , if themanufacturing 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 themanufacturing tester machine 104. In the embodiment discussed in conjunction withFIG. 4 , even if themanufacturing tester machine 104 has knowledge of the shared key, it is unable to learn the device unique key or Provisioning Key. - 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 thehardware 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 thehardware device 102 during the manufacturing process is robust against a maliciousmanufacturing 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. - 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. - 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.
- 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.
-
FIG. 8 is a block diagram of an embodiment of a Trusted Computing Base (TCB) 800 of a trusted platform. - In the key hierarchy of a
Trusted Computing Base 800, there is a deviceunique key 110 embedded in ahardware device 102 in aplatform 502. The deviceunique key 110 is permanently stored in a protectedstorage 109 in thehardware device 102. This deviceunique key 110 is the “root key” for other keys in the platform, that is, several other keys in theTrusted Computing Base 800 are derived from this deviceunique key 110, such as, a provisioning ID802, aprovisioning base key 822, aprovisioning key 804 and astorage key 806. - The
provisioning ID 802 and provisioning key 804 are used to download a unique DAK key from akey provisioning server 500. Thestorage key 806 is used for encrypting keys and secrets of theplatform 502 including the DAK key. - The upgraded firmware in the
TCB 802 needs to access these derived keys, for example,provisioning ID 802, provisioning key 804, andstorage 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 innon-reportable firmware code 818 in non-volatile memory and read by theunrecoverable 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. - The keys that are derived from the device
unique key 110, that is, theprovisioning ID 802, provisioning key 804, andstorage key 806 are computed inside a signature verification portion of theTCB 810, which is designated to be non-recoverable and can also be referred to as the “unrecoverable TCB”. Theprovisioning key 804 andstorage key 806 are derived based on theSecurity Version Number 808, then output from the signature verification portion of theTCB 810 to a recoverable portion of theTCB 800. After the keys have been derived from the deviceunique key 110, the signature verification portion of theTCB 810 “locks” access to the deviceunique key 110, preventing recoverable portions of theTCB 800 from accessing the deviceunique key 110, that is, the raw “root key”. As theprovisioning key 804 andstorage 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 theSVN 808 of theTCB 800. For example, the key derivations are performed inside therecoverable 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. -
FIG. 9 is a flowgraph illustrating a method to recover from a security vulnerability in aTCB 800. If security vulnerability has been discovered in the recoverable TCB, a TCB recovery event is triggered. - At
block 900, when a security vulnerability is found in theTCB 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 asecurity 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. Theunrecoverable TCB 810 can verify the signature using the manufacturer's public key, that is, the firmware verification key embedded in thehardware 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 withblock 902. - At
block 902, after the new version of the firmware is installed on the platform, the signature verification portion of theTCB 800 verifies the signature of the new firmware for the recoverable TCB using thefirmware verification key 820 embedded in thehardware device 102 in the platform. The signature verification portion of theTCB 810 retrieves the Security Version Number (SVN) 808 of the new firmware embedded in the firmware and retrieves the deviceunique key 110 stored in thehardware device 102. Theprovisioning ID 802 andProvisioning Base Key 822 are derived from the deviceunique key 110. The Provisioning key 804 is derived from theProvisioning Base Key 822 and theSVN 808. TheStorage Key 806 is derived from the deviceunique key 110 and theSVN 808. Methods for deriving these keys will be described later. The derivedprovisioning ID 802, provisioning key 804, andstorage key 806 are sent to the recoverable TCB. Processing continues withblock 804. - 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 eachplatform 502 that received the new version of the firmware to fix the security vulnerability. Thekey generation server 106 generates the DAKs and sends to therespective platforms 502 via thecommunications network 504. As discussed earlier, theprovisioning database 112 in thekey generation server 106 stores aprovisioning ID 802 and aProvisioning Base Key 822 for eachhardware device 102 that was tested by the manufacturing tester device. Aprovisioning key 804 is derived from the storedprovisioning base key 822 based on the latestSecurity Version Number 808. In an embodiment, the key derivation method selected is the same as used inblock 904. The new unique DAK is generated for thehardware device 102 and encrypted using theprovisioning key 804. Any symmetric encryption algorithm can be used, for example, AES-GCM. Thekey generation server 106 prepares a DAK provisioning database in which each database entry has aprovisioning key 804 and the corresponding encrypted DAK. Thekey generation server 106 sends the DAK provisioning database to thekey provisioning server 500. Each platform downloads a new DAK from thekey provisioning server 500. - The recoverable TCB has the
provisioning ID 802 and provisioning key 804 and communicates with theprovisioning server 500 using a provisioning protocol to obtain the new DAK key for theplatform 502. Theplatform 502 encrypts itsprovisioning ID 802 using theprovisioning server 500's public key and sends the encrypted provisioning ID to theprovisioning server 500. Theprovisioning server 500 decrypts the received encrypted provisioning ID using its private key to obtain theunencrypted provisioning ID 802 of the requestingplatform 502. Theprovisioning server 500 searches the DAK provisioning database for an entry corresponding to theprovisioning ID 802 that stores the encrypted new DAK key which is encrypted by the new provisioning key for thehardware device 102 in theplatform 502. Theprovisioning server 500 sends the encrypted new DAK to theplatform 502. Theplatform 502 decrypts the new DAK using the new provisioning key. Theplatform 502 re-encrypts the new DAK using itsnew storage key 806 and stores the encrypted new DAK securely. The encrypted new DAK is stored in non-volatile memory in theplatform 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. - If the
platform 502 has not installed the new firmware to fix the security vulnerability, it cannot derive thenew provisioning key 804 corresponding to the latest SVN. Thus, theplatform 502 cannot decrypt the new DAK; even it receives the encrypted new DAK from theprovisioning server 500. Processing continues withblock 908. - At
block 908, after theplatform 502 has installed the new firmware with a new SVN, it also has anew storage key 806 corresponding to the new SVN. Before the firmware upgrade, theplatform 502 may have encrypted the platform key materials and secrets using anold storage key 806 corresponding to an old SVN. Thus, theplatform 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, theplatform 502 decrypts using the old storage key and verifies the integrity of the unencrypted data. Theplatform 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. - 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. - 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 thenew provisioning key 804 or thenew storage key 806, which is used for downloading and wrapping (encrypting) a new DAK key, respectively because these keys are derived using thenew SVN 808. In addition, the manufacturer of theplatform 502 may revoke the DAKs associated with the previous TCB version. Eachplatform 502, after downloading new DAK, can use its new DAK to attest and cryptographically prove which version of theTCB 800 is being used. - 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 toprevious 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. - 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”∥SVN). - 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”∥i). - The unrecoverable TCB then sends all the Storage Keys to the recoverable TCB.
- In another embodiment, only one prior storage key is computed. A
platform 502 that controls storage of data protected by astorage 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 theplatform 502 prior to the last firmware update. - 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, afirst storage key 806 for the current SVN and asecond 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. Theunrecoverable TCB 802 computes the following: -
SK[SVN]=PRF(device unique key,“Storage Key”∥SVN). -
SK[pSVN]=PRF(device unique key,“Storage Key”∥pSVN). - where: SVN is the current SVN; pSVN is the prior SVN and PRF is a pseudo random function.
- The
SVN 808 is available from the firmware of theTCB 800. The pSVN can be provided to theunrecoverable 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. -
FIG. 10 is a flowgraph of an embodiment of a hash chain method to perform key derivation to compute prior storage keys. In aplatform 502 that does not have control over where protected data is stored, multipleprior storage keys 824 are needed to ensure proper access to previously protected data. - At
block 1000, thecurrent SVN 808 is read from the recoverable TCB firmware. Processing continues withblock 1002. - 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 withblock 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. - 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”∥n). - Processing continues with
block 1006. - 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. - 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 withblock 1008. - At
block 1008, SK[SVN] is output. - The
unrecoverable TCB 810 only needs to output asingle 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. - 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”∥i)if i is a multiplier of n, -
SK[i]=Hash(SK[i+1])if i is not a multiplier of n. -
- where n is a checkpoint integer.
-
FIG. 11 is a flowgraph illustrating an embodiment of a method performed by the unrecoverable TCB to derive the storage keys. - At
block 1100, theSVN 808 is read from the unrecoverable TCB firmware. Processing continues withblock 1102. - At
block 1102, the current storage key is derived using the deviceunique key 110 as follows: -
Let m=[SVN/n]; -
SK[m−n]=PRF(device unique key,“Storage Key”∥m−n); -
For i=mn−1, . . . ,SVN,SK[i]=Hash(SK[i+1]). - Processing continues with
block 1104. - 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”∥i−n). - Processing continues with
block 1106. - 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. - 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 itsown 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, thelayer 1 TCB isfirmware layer 1 andlayer 2 TCB is the firmware implementation of a higher level technology. -
FIG. 12 is a block diagram illustrating theunrecoverable TCB 810 andlayer 1TCB 1202. During a boot sequence, that is, each time the platform is powered on, theunrecoverable TCB 810 receives the deviceunique key 110. - At
block 1204, theunrecoverable TCB 810 verifies the signature of unrecoverable TCB firmware and forwards unrecoverable TCB's SVN to block 1206. Atblock 1206, the unrecoverable TCB derives a key forLayer 1TCB 1202 based on performing a pseudo random function on the received deviceunique key 110 and unrecoverable TCB's SVN. - In
layer 1TCB 1202 atblock 1208,Layer 1TCB 1202 checks the signature ofLayer 1 TCB firmware. Atblock 1210, theLayer 1TCB 1202 derives the key forLayer 2 TCB (not shown) based on performing a pseudo random function on the received derived unrecoverable TCB key andLayer 1 TCB's SVN inblock 1210. To generate k keys, the key generation functions shown inblocks - 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.
- The hash chain method discussed in conjunction with
FIG. 10 , provides single layer TCB recovery, however this does not scale to multiple layers. - 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.
-
FIG. 13 is a block diagram illustrating a hybrid approach using a hash chain to protect a recoverable layer. Four layers are shown: anunrecoverable TCB layer 810,layer 1TCB 1300,layer 2TCB 1302 andlayer 3 1304. All four layers shown can be implemented in an embodiment for a processor unit. Only two of the layers: anunrecoverable TCB layer 810 andlayer 1TCB 1300 are typically used in an embodiment for a chipset. Thekey register 1314 can be a special register in the processor unit or chipset that is used by theunrecoverable TCB layer 810 and bylayer 3 1304 in an embodiment for a processor unit. - The TCB for each layer (i) is computed as follows:
-
TCB[i]=SVN of TCB layer i. - The
unrecoverable TCB layer 810 receives the stored deviceunique key 110, verifies the integrity and source ofLayer 1 recoverable TCB firmware and calculates SK[TCB[1]] using hash chaining in thePRF loop 1312. ThePRF loop 1312 derives a provisioning key for a particular layer for a particular revision of the key and stores the provisioning key forlayer 1CB 1300 in the key register. The PRF loop also generates theLayer 1SVN 1305,Layer 2SVN 1306 andLayer 3SVN 1308. The PRF function performed in thePRF 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). -
Layer 1TCB 1302 verifies the integrity and source ofLayer 2 andstores Layer 2's Security Version Number (SVN) 1306 generated byPRF loop 1312 in a protected register, for example, in aTCBSVN Register 1310. TheTCBSVN Register 1310 can be protected from being overwritten by the other layers. -
Layer 2 through the last layer perform the same operations as discussed in conjunction withlayer 1 1300. Instructions implemented in the last layer can call alayer 1 function getKey (TCB_request[ ]) which performs the following operations. -
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” ∥ j ∥ k); where j and k are SVNs for layer 1TCB 1300 andlayer 2TCB 1302. - The
storage key 806 for any previous permutation of TCB layers can be derived, iflayer 1 remains active. -
Layer 3 1304 also uses the provisioning key stored in thekey register 1314 and performs an optional PRF function inPRF 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 thekey register 1314 or derived inPRF loop 1318 with the storedlayer 2SVN 1306 and storedlayer 3SVN 1308. The storage keys are computed based on the result of this PRF function 1326. - 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 deviceunique key 110 has been extracted during a malicious hardware attack, a DAK re-provisioning protocol does not provide a new DAK to the platform. -
FIG. 14 illustrates an embodiment of a DAK provisioning protocol between aplatform 502 and aprovisioning server 500. - At 1400, the
platform 502 and theprovisioning server 500 set up a secure communication channel using a standard protocol, such as TLS/SSL. - At 1402, the
platform 502 encrypts a message using its previous DAK and sends the encrypted message to theprovisioning server 500. Theprovisioning server 500 checks the previous DAK and performs a revocation check on the previous DAK to determine if it has been revoked. If theplatform 502 has been revoked, theprovisioning server 500 terminates the protocol. - At 1404, the Platform sends the
Provisioning ID 802 over the secure channel to theprovisioning server 500. Theprovisioning server 500 searches the DAK provisioning database using the received provisioning ID (one per hardware device 102) and retrieves the encrypted new DAK for theplatform 502. - At 1406, the
provisioning server 500 sends the new encrypted DAK to theplatform 502. - 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 theplatform 502, the DAK re-provisioning is modified to store the DAK in theprovisioning server 500. -
FIG. 15 illustrates an embodiment of the re-provisioning protocol inFIG. 14 between theplatform 502 and theprovisioning server 500 that supports privacy. - As discussed in conjunction with
FIG. 14 , at 1400, theplatform 502 sets up a secure channel with theprovisioning server 500. - At 1402, the
platform 502 proves that it has not been revoked by sending its previous DAK to theprovisioning server 500. - At 1404, the
platform 502 sends the Provisioning ID over the secure channel to theprovisioning server 500. Theprovisioning server 500 searches the DAK provisioning database for a match for the previous DAK and retrieves the new DAK for theplatform 502. - At 1406, the
provisioning server 500 sends the new DAK encrypted using theprovisioning key 804 back toplatform 502. Theplatform 502 decrypts the encrypted DAK using itsprovisioning key 804. - At 1408, the
platform 502 re-encrypts the received new DAK using itsstorage key 806, which is unknown to theprovisioning server 500 andkey generation server 106. Theplatform 502 sends the new DAK encrypted by itsstorage key 806 to theprovisioning server 500. Theprovisioning server 500 deletes the platform's DAK from its database and stores the new DAK encrypted by its storage key in the database. -
FIG. 16 illustrates an embodiment of a DAK backup retrieval protocol between the platform and theprovisioning server 500 that stores the platform's DAK encrypted by its storage key. - If the platform loses its DAK, it can download the DAK stored in the database in the
provisioning server 500. - At 1600, the
platform 502 encrypts itsprovisioning ID 804 using the provisioning server's public key and sends the encrypted provisioning ID to theprovisioning server 500. Upon receiving the encrypted provisioning ID, theprovisioning server 500 decrypts the provisioning ID and searches for an entry corresponding to the provisioning ID in the provisioning server's database. - At 1602, the
provisioning server 500 sends the DAK encrypted in by the platform'sstorage key 806 that is stored in theprovisioning server 500's database to the platform. Upon receiving the encrypted DAK, theplatform 502 uses its storage key to decrypt the received encrypted DAK (the backup copy of the DAK). - 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. - 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.
-
FIG. 17 is flowgraph of an embodiment of a method for storing a PSVN in the non-volatile re-writable memory. - At
block 1700, if the current byte address is less than the maximum byte address in the 64-byte block, processing continues withblock 1702. - At
block 1702, the byte in the 64-byte block at the current address is read. Processing continues withblock 1704. - At
block 1704, if the value is zero, processing continues withblock 1705. If not, processing continues withblock 1706. - At
block 1705, the address of the 64-byte block is incremented to read the next byte location. Processing continues with block 17000. - At
block 1706, if the value is 255 there is no active PSVN. Processing continues withblock 1708. If the value is not 255, the value is 1 through 254 and the PSVN is valid. Processing continues withblock 1710. - At
block 1710, the previous root key is derived. - 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. - 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.
- 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.
- 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.
Claims (22)
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.
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/956,793 US20120137137A1 (en) | 2010-11-30 | 2010-11-30 | Method and apparatus for key provisioning of hardware devices |
PCT/US2011/060345 WO2012074720A1 (en) | 2010-11-30 | 2011-11-11 | Method and apparatus for key provisioning of hardware devices |
JP2013536941A JP5690412B2 (en) | 2010-11-30 | 2011-11-11 | Hardware device key provisioning method and apparatus |
EP11844100.5A EP2647156A4 (en) | 2010-11-30 | 2011-11-11 | Method and apparatus for key provisioning of hardware devices |
CN201180057317.3A CN103229451B (en) | 2010-11-30 | 2011-11-11 | For the method and apparatus that the key of hardware device is supplied |
TW100142701A TWI567579B (en) | 2010-11-30 | 2011-11-22 | Method and apparatus for key provisioning of hardware devices |
US13/987,807 US9043604B2 (en) | 2010-11-30 | 2013-09-05 | Method and apparatus for key provisioning of hardware devices |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/956,793 US20120137137A1 (en) | 2010-11-30 | 2010-11-30 | Method and apparatus for key provisioning of hardware devices |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/987,807 Continuation US9043604B2 (en) | 2010-11-30 | 2013-09-05 | Method and apparatus for key provisioning of hardware devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120137137A1 true US20120137137A1 (en) | 2012-05-31 |
Family
ID=46127438
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/956,793 Abandoned US20120137137A1 (en) | 2010-11-30 | 2010-11-30 | Method and apparatus for key provisioning of hardware devices |
US13/987,807 Active US9043604B2 (en) | 2010-11-30 | 2013-09-05 | Method and apparatus for key provisioning of hardware devices |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/987,807 Active US9043604B2 (en) | 2010-11-30 | 2013-09-05 | Method and apparatus for key provisioning of hardware devices |
Country Status (6)
Country | Link |
---|---|
US (2) | US20120137137A1 (en) |
EP (1) | EP2647156A4 (en) |
JP (1) | JP5690412B2 (en) |
CN (1) | CN103229451B (en) |
TW (1) | TWI567579B (en) |
WO (1) | WO2012074720A1 (en) |
Cited By (100)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110276809A1 (en) * | 2008-10-23 | 2011-11-10 | Herve Sibert | Method of Storing Data in a Memory Device and a Processing Device for Processing Such Data |
US20130007739A1 (en) * | 2011-06-30 | 2013-01-03 | Indrajit Poddar | Virtual machine disk image installation |
US20130046981A1 (en) * | 2011-08-17 | 2013-02-21 | Vixs Systems, Inc. | Secure provisioning of integrated circuits at various states of deployment, methods thereof |
US20130145164A1 (en) * | 2011-12-02 | 2013-06-06 | Yuji Nagai | Semiconductor memory device |
US20130339732A1 (en) * | 2012-06-15 | 2013-12-19 | Kabushiki Kaisha Toshiba | Device |
US8634557B2 (en) | 2011-12-02 | 2014-01-21 | Kabushiki Kaisha Toshiba | Semiconductor storage device |
US8645677B2 (en) * | 2011-09-28 | 2014-02-04 | Intel Corporation | Secure remote credential provisioning |
US8650393B2 (en) | 2011-11-11 | 2014-02-11 | Kabushiki Kaisha Toshiba | Authenticator |
US8661527B2 (en) | 2011-08-31 | 2014-02-25 | Kabushiki Kaisha Toshiba | Authenticator, authenticatee and authentication method |
US8667286B2 (en) | 2012-01-16 | 2014-03-04 | Kabushiki Kaisha Toshiba | Host device, semiconductor memory device, and authentication method |
WO2014051741A2 (en) * | 2012-09-28 | 2014-04-03 | Intel Corporation | Integrated circuits having accessible and inaccessible physically unclonable functions |
US20140093074A1 (en) * | 2012-09-28 | 2014-04-03 | Kevin C. Gotze | Secure provisioning of secret keys during integrated circuit manufacturing |
US20140122885A1 (en) * | 2012-11-01 | 2014-05-01 | Miiicasa Taiwan Inc. | Method and system for managing device identification |
US20140133652A1 (en) * | 2012-11-12 | 2014-05-15 | Renesas Electronics Corporation | Semiconductor device and information processing system for encrypted communication |
US20140143552A1 (en) * | 2012-11-18 | 2014-05-22 | Cisco Technology Inc. | Glitch Resistant Device |
US8761389B2 (en) | 2011-12-02 | 2014-06-24 | Kabushiki Kaisha Toshiba | Memory |
US20140189374A1 (en) * | 2011-08-23 | 2014-07-03 | Bernd Meyer | System and method for the secure transmission of data |
WO2014105146A1 (en) * | 2012-12-29 | 2014-07-03 | Intel Corporation | Secure key derivation and cryptography logic for integrated circuits |
US8812843B2 (en) | 2011-12-02 | 2014-08-19 | Kabushiki Kaisha Toshiba | Device and authentication method therefor |
US8856515B2 (en) | 2012-11-08 | 2014-10-07 | Intel Corporation | Implementation of robust and secure content protection in a system-on-a-chip apparatus |
US8885819B2 (en) * | 2012-12-27 | 2014-11-11 | Intel Corporation | Fuse attestation to secure the provisioning of secret keys during integrated circuit manufacturing |
US20140351584A1 (en) * | 2011-08-12 | 2014-11-27 | Power-One Italy S.P.A. | Method and system for protected transmission of files |
US20140365763A1 (en) * | 2013-06-07 | 2014-12-11 | Qualcomm Incorporated | Apparatus and method for provisioning an endorsement key certificate for a firmware trusted platform module |
US20140380057A1 (en) * | 2013-06-05 | 2014-12-25 | Huawei Technologies Co., Ltd. | Method, Server, Host, and System for Protecting Data Security |
US8938792B2 (en) * | 2012-12-28 | 2015-01-20 | Intel Corporation | Device authentication using a physically unclonable functions based key generation system |
US8984294B2 (en) | 2013-02-15 | 2015-03-17 | Kabushiki Kaisha Toshiba | System of authenticating an individual memory device via reading data including prohibited data and readable data |
US9043604B2 (en) | 2010-11-30 | 2015-05-26 | Intel Corporation | Method and apparatus for key provisioning of hardware devices |
CN104734854A (en) * | 2013-12-23 | 2015-06-24 | 西门子公司 | Secure Provision of a Key |
WO2015116288A3 (en) * | 2013-11-10 | 2015-10-08 | Sypris Electronics, Llc | Authenticatable device |
US9166783B2 (en) | 2010-10-14 | 2015-10-20 | Kabushiki Kaisha Toshiba | Protection method, decryption method, player, storage medium, and encryption apparatus of digital content |
US9201811B2 (en) | 2013-02-14 | 2015-12-01 | Kabushiki Kaisha Toshiba | Device and authentication method therefor |
US9258315B2 (en) * | 2014-01-13 | 2016-02-09 | Cisco Technology, Inc. | Dynamic filtering for SDN API calls across a security boundary |
WO2016025940A1 (en) * | 2014-08-15 | 2016-02-18 | Sypris Electronics, Llc | Resilient device authentication system with metadata binding |
US20160078251A1 (en) * | 2014-09-16 | 2016-03-17 | Freescale Semiconductor, Inc. | Key storage and revocation in a secure memory system |
US9479328B1 (en) * | 2013-06-11 | 2016-10-25 | Amazon Technologies, Inc. | Secure key provisioning |
US9497171B2 (en) | 2011-12-15 | 2016-11-15 | Intel Corporation | Method, device, and system for securely sharing media content from a source device |
US9519757B2 (en) * | 2014-02-26 | 2016-12-13 | Unisys Corporation | AES-GCM based enhanced security setup for media encryption |
US9544141B2 (en) | 2011-12-29 | 2017-01-10 | Intel Corporation | Secure key storage using physically unclonable functions |
US20170039368A1 (en) * | 2013-09-27 | 2017-02-09 | Mcafee, Inc. | Trusted execution of an executable object on a local device |
US20170091463A1 (en) * | 2015-09-25 | 2017-03-30 | Ty Lindteigen | Secure Audit Logging |
WO2017065900A1 (en) * | 2015-10-13 | 2017-04-20 | Sony Interactive Entertainment America Llc | Secure key store derivation and management from a single secure root key |
US9646154B2 (en) | 2014-12-12 | 2017-05-09 | Microsoft Technology Licensing, Llc | Return oriented programming (ROP) attack protection |
US9672342B2 (en) | 2014-05-05 | 2017-06-06 | Analog Devices, Inc. | System and device binding metadata with hardware intrinsic properties |
EP3075096A4 (en) * | 2014-03-11 | 2017-06-07 | Tencent Technology (Shenzhen) Company Limited | Method and system for encrypted communications |
US9714004B2 (en) | 2015-02-02 | 2017-07-25 | Kabushiki Kaisha Tokai Rika Denki Seisakusho | Electronic key registration system |
EP3214797A1 (en) * | 2016-03-01 | 2017-09-06 | Siemens Aktiengesellschaft | Deriving a device unique encryption key of a system on chip using a physical unclonable function |
US9819493B2 (en) * | 2014-02-26 | 2017-11-14 | Unisys Corporation | Enhanced security for media encryption |
US9825764B2 (en) * | 2014-02-26 | 2017-11-21 | Unisys Corporation | Enhanced security for media decryption |
US9887838B2 (en) | 2011-12-15 | 2018-02-06 | Intel Corporation | Method and device for secure communications over a network using a hardware security engine |
US9913135B2 (en) | 2014-05-13 | 2018-03-06 | Element, Inc. | System and method for electronic key provisioning and access management in connection with mobile devices |
US9946858B2 (en) | 2014-05-05 | 2018-04-17 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US9965728B2 (en) | 2014-06-03 | 2018-05-08 | Element, Inc. | Attendance authentication and management in connection with mobile devices |
WO2018089006A1 (en) * | 2016-11-10 | 2018-05-17 | Ernest Brickell | Balancing public and personal security needs |
US9996480B2 (en) | 2012-07-18 | 2018-06-12 | Analog Devices, Inc. | Resilient device authentication system with metadata binding |
US20180234410A1 (en) * | 2013-10-29 | 2018-08-16 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
US10135815B2 (en) | 2012-09-05 | 2018-11-20 | Element, Inc. | System and method for biometric authentication in connection with camera equipped devices |
CN109074466A (en) * | 2016-06-18 | 2018-12-21 | 英特尔公司 | Platform for server proves and registration |
US20190087577A1 (en) * | 2017-09-18 | 2019-03-21 | Nxp B.V. | Method for protecting the confidentiality and integrity of firmware for an internet of things device |
US20190097795A1 (en) * | 2017-09-26 | 2019-03-28 | Samsung Sds Co., Ltd. | Method of provisioning key information and apparatus using the method |
US20190103961A1 (en) * | 2017-09-29 | 2019-04-04 | Intel Corporation | System and techniques for encrypting chip-to-chip communication links |
US10282533B2 (en) | 2013-03-22 | 2019-05-07 | Nok Nok Labs, Inc. | System and method for eye tracking during authentication |
CN109787756A (en) * | 2018-12-24 | 2019-05-21 | 吉林微思智能科技有限公司 | A kind of car-mounted terminal key distribution management method based on whitepack encryption technology |
US10348706B2 (en) | 2017-05-04 | 2019-07-09 | Ernest Brickell | Assuring external accessibility for devices on a network |
US10382962B2 (en) | 2014-05-22 | 2019-08-13 | Analog Devices, Inc. | Network authentication system with dynamic key generation |
US10425235B2 (en) | 2017-06-02 | 2019-09-24 | Analog Devices, Inc. | Device and system with global tamper resistance |
US10432409B2 (en) | 2014-05-05 | 2019-10-01 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US10440006B2 (en) | 2017-06-21 | 2019-10-08 | Microsoft Technology Licensing, Llc | Device with embedded certificate authority |
US10498712B2 (en) | 2016-11-10 | 2019-12-03 | Ernest Brickell | Balancing public and personal security needs |
WO2019231683A1 (en) * | 2018-05-31 | 2019-12-05 | Motorola Solutions, Inc. | Method for provisioning device certificates for electronic processors in untrusted environments |
US10558812B2 (en) | 2017-06-21 | 2020-02-11 | Microsoft Technology Licensing, Llc | Mutual authentication with integrity attestation |
US10637853B2 (en) | 2016-08-05 | 2020-04-28 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US10652245B2 (en) | 2017-05-04 | 2020-05-12 | Ernest Brickell | External accessibility for network devices |
US10735205B1 (en) * | 2019-03-08 | 2020-08-04 | Ares Technologies, Inc. | Methods and systems for implementing an anonymized attestation chain |
US10735959B2 (en) | 2017-09-18 | 2020-08-04 | Element Inc. | Methods, systems, and media for detecting spoofing in mobile authentication |
US10769635B2 (en) | 2016-08-05 | 2020-09-08 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US10855465B2 (en) | 2016-11-10 | 2020-12-01 | Ernest Brickell | Audited use of a cryptographic key |
US20200387611A1 (en) * | 2017-12-22 | 2020-12-10 | Vincent J. Zimmer | Manageability engine and automatic firmware validation |
US10878106B2 (en) * | 2018-08-01 | 2020-12-29 | Vdoo Connected Trust Ltd. | Firmware verification |
US10938560B2 (en) | 2017-06-21 | 2021-03-02 | Microsoft Technology Licensing, Llc | Authorization key escrow |
US10958452B2 (en) | 2017-06-06 | 2021-03-23 | Analog Devices, Inc. | System and device including reconfigurable physical unclonable functions and threshold cryptography |
NL1044044A (en) | 2020-05-28 | 2021-12-01 | Sandgrain B V | Centralized handling of ic identification codes |
NL2025695B1 (en) * | 2020-05-28 | 2022-01-13 | Sandgrain B V | Centralized handling of ic identification codes |
US20220050605A1 (en) * | 2018-12-03 | 2022-02-17 | Nagravision Sa | Remote enforcement of device memory |
US11308241B2 (en) * | 2018-05-14 | 2022-04-19 | Innogrit Technologies Co., Ltd. | Security data generation based upon software unreadable registers |
US20220129565A1 (en) * | 2019-07-09 | 2022-04-28 | Huawei Technologies Co., Ltd. | Operation method, operation apparatus, and device |
US11343277B2 (en) | 2019-03-12 | 2022-05-24 | Element Inc. | Methods and systems for detecting spoofing of facial recognition in connection with mobile devices |
US11374760B2 (en) | 2017-09-13 | 2022-06-28 | Microsoft Technology Licensing, Llc | Cyber physical key |
US11398906B2 (en) | 2016-11-10 | 2022-07-26 | Brickell Cryptology Llc | Confirming receipt of audit records for audited use of a cryptographic key |
CN114830110A (en) * | 2019-11-07 | 2022-07-29 | 美光科技公司 | Single-use password generation |
US11405201B2 (en) | 2016-11-10 | 2022-08-02 | Brickell Cryptology Llc | Secure transfer of protected application storage keys with change of trusted computing base |
US20220245252A1 (en) * | 2022-02-22 | 2022-08-04 | Intel Corporation | Seamless firmware update mechanism |
US11409877B2 (en) * | 2020-03-27 | 2022-08-09 | Intel Corporation | Firmware verification mechanism |
US11463267B2 (en) | 2016-09-08 | 2022-10-04 | Nec Corporation | Network function virtualization system and verifying method |
US11507248B2 (en) | 2019-12-16 | 2022-11-22 | Element Inc. | Methods, systems, and media for anti-spoofing using eye-tracking |
US20230040468A1 (en) * | 2021-08-04 | 2023-02-09 | International Business Machines Corporation | Deploying a system-specific secret in a highly resilient computer system |
US20230205895A1 (en) * | 2021-12-29 | 2023-06-29 | Arm Limited | Methods and apparatus for provisioning a device |
US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
US11868995B2 (en) | 2017-11-27 | 2024-01-09 | Nok Nok Labs, Inc. | Extending a secure key storage for transaction confirmation and cryptocurrency |
US11929997B2 (en) | 2013-03-22 | 2024-03-12 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
Families Citing this family (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9171133B2 (en) * | 2013-10-11 | 2015-10-27 | Landis+Gyr Innovations, Inc. | Securing a device and data within the device |
EP2911086A1 (en) * | 2014-02-19 | 2015-08-26 | Renesas Electronics Europe GmbH | Integrated circuit with parts activated based on intrinsic features |
CN104868998B (en) * | 2014-02-23 | 2017-08-01 | 阿姆科技以色列有限公司 | A kind of system, apparatus and method that encryption data is supplied to electronic equipment |
WO2015147879A1 (en) * | 2014-03-28 | 2015-10-01 | Hewlett-Packard Development Company, L.P. | Allowing use of a test key for a bios installation |
US9594910B2 (en) | 2014-03-28 | 2017-03-14 | Intel Corporation | In-system provisioning of firmware for a hardware platform |
GB2531248B (en) | 2014-10-08 | 2017-02-22 | Ibm | Controlled use of a hardware security module |
EP3007094B1 (en) * | 2014-10-08 | 2021-05-05 | Nintendo Co., Ltd. | Boot program, information processing apparatus, information processing system, information processing method, semiconductor apparatus, and program |
US9584317B2 (en) * | 2014-10-13 | 2017-02-28 | Microsoft Technology Licensing, Llc | Identifying security boundaries on computing devices |
US9667606B2 (en) * | 2015-07-01 | 2017-05-30 | Cyphermatrix, Inc. | Systems, methods and computer readable medium to implement secured computational infrastructure for cloud and data center environments |
CN105184121A (en) * | 2015-09-02 | 2015-12-23 | 上海繁易电子科技有限公司 | Hardware authorization system and method using remote server |
US9953167B2 (en) | 2015-10-12 | 2018-04-24 | Microsoft Technology Licensing, Llc | Trusted platforms using minimal hardware resources |
US9917687B2 (en) | 2015-10-12 | 2018-03-13 | Microsoft Technology Licensing, Llc | Migrating secrets using hardware roots of trust for devices |
CN105701407B (en) * | 2016-01-08 | 2018-04-10 | 腾讯科技(深圳)有限公司 | Level of security determines method and device |
WO2017135942A1 (en) * | 2016-02-03 | 2017-08-10 | Hewlett-Packard Development Company, L.P. | Heartbeat signal verification |
CN106022166B (en) * | 2016-06-02 | 2018-10-23 | 东北大学 | A kind of code reuse attack defending system and method |
US10785022B2 (en) * | 2016-09-13 | 2020-09-22 | Hiroshi Watanabe | Network without abuse of a private key |
US10482036B2 (en) * | 2016-09-18 | 2019-11-19 | Winbond Electronics Corporation | Securely binding between memory chip and host |
GB2556638B (en) * | 2016-12-02 | 2018-12-12 | Gurulogic Microsystems Oy | Protecting usage of key store content |
CN109120573B (en) * | 2017-06-22 | 2021-06-04 | 武汉大学 | Transmission key generation method, terminal and server |
US10505732B2 (en) | 2017-08-14 | 2019-12-10 | Nxp B.V. | Method for generating a public/private key pair and public key certificate for an internet of things device |
EP3483772A1 (en) * | 2017-11-14 | 2019-05-15 | Nagravision S.A. | Integrated circuit personalisation with data encrypted with the output of a physically unclonable function |
CN108155986A (en) * | 2017-12-14 | 2018-06-12 | 晶晨半导体(上海)股份有限公司 | A kind of key programming system and method based on credible performing environment |
WO2019125238A1 (en) * | 2017-12-19 | 2019-06-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and nodes for handling lldp messages in a communication network |
CN110489351B (en) | 2018-05-14 | 2021-03-09 | 英韧科技(上海)有限公司 | Chip fingerprint management device and security chip |
CN109639409B (en) * | 2018-09-20 | 2021-05-04 | 创新先进技术有限公司 | Key initialization method, key initialization device, electronic equipment and computer-readable storage medium |
US10742421B1 (en) * | 2019-03-08 | 2020-08-11 | Ares Technologies, Inc. | Methods and systems for anonymous hardware attestation |
TWI758697B (en) * | 2019-03-22 | 2022-03-21 | 旺宏電子股份有限公司 | Integrated circuit, memory circuit, and method for operating integrated circuit |
WO2020238878A1 (en) * | 2019-05-31 | 2020-12-03 | 创新先进技术有限公司 | Dynamic encryption method and device |
KR20230043235A (en) * | 2019-06-10 | 2023-03-30 | 구글 엘엘씨 | Secure verification of firmware |
TWI774986B (en) * | 2019-09-09 | 2022-08-21 | 新唐科技股份有限公司 | Key storage system and key storage method |
CN111082925B (en) * | 2019-10-23 | 2021-07-30 | 中山大学 | Embedded system encryption protection device and method based on AES algorithm and PUF technology |
CN112398657B (en) * | 2020-11-05 | 2021-10-29 | 北京邮电大学 | PUF authentication method and device based on wireless multipath fading channel |
US20220191017A1 (en) * | 2020-12-11 | 2022-06-16 | PUFsecurity Corporation | Key management system providing secure management of cryptographic keys, and methods of operating the same |
US11783057B2 (en) | 2021-08-24 | 2023-10-10 | Nxp B.V. | Method for securely provisioning a device incorporating an integrated circuit without using a secure environment |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6829596B1 (en) * | 2000-05-23 | 2004-12-07 | Steve Frazee | Account/asset activation device and method |
US20050022025A1 (en) * | 2003-06-30 | 2005-01-27 | Hug Joshua D. | Rights enforcement and usage reporting on a client device |
US7353388B1 (en) * | 2004-02-09 | 2008-04-01 | Avaya Technology Corp. | Key server for securing IP telephony registration, control, and maintenance |
US20080244698A1 (en) * | 2004-10-13 | 2008-10-02 | Matsushita Electric Industrial Co., Ltd. | Authorized Content Verification Method, Content Transmission/Reception System, Transmitter, and Receiver |
CN101699891A (en) * | 2009-10-21 | 2010-04-28 | 西安西电捷通无线网络通信有限公司 | Method for key management and node authentication of sensor network |
WO2010116618A1 (en) * | 2009-04-06 | 2010-10-14 | パナソニック株式会社 | Key implementation system |
US20110091037A1 (en) * | 2009-10-16 | 2011-04-21 | Cisco Technology, Inc. | Content protection key encryptor for security providers |
US8205080B2 (en) * | 2007-05-11 | 2012-06-19 | Microsoft Corporation | Over the air communication authentication using a device token |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4457474B2 (en) * | 2000-04-04 | 2010-04-28 | ソニー株式会社 | Information recording apparatus, information reproducing apparatus, information recording method, information reproducing method, information recording medium, and program providing medium |
TW583568B (en) * | 2001-08-27 | 2004-04-11 | Dataplay Inc | A secure access method and system |
AU2003303882A1 (en) * | 2003-02-03 | 2004-08-30 | Nokia Corporation | Architecture for encrypted application installation |
US7778422B2 (en) * | 2004-02-27 | 2010-08-17 | Microsoft Corporation | Security associations for devices |
US7697691B2 (en) * | 2004-07-14 | 2010-04-13 | Intel Corporation | Method of delivering Direct Proof private keys to devices using an on-line service |
CN101495957A (en) | 2006-07-31 | 2009-07-29 | 皇家飞利浦电子股份有限公司 | Device and method for generating a random bit string |
DE102006046017B4 (en) * | 2006-09-28 | 2010-01-14 | Siemens Ag | A method for providing a symmetric key for securing a key management protocol |
US8031009B2 (en) | 2008-12-02 | 2011-10-04 | Electronics And Telecommunications Research Institute | Frequency calibration loop circuit |
JP5183517B2 (en) * | 2009-02-05 | 2013-04-17 | 三菱電機株式会社 | Information processing apparatus and program |
WO2010134192A1 (en) * | 2009-05-22 | 2010-11-25 | 三菱電機株式会社 | Electronic device, key generation program, recording medium, and key generation method |
US8677459B2 (en) * | 2009-08-11 | 2014-03-18 | Broadcom Corporation | Secure zero-touch provisioning of remote management controller |
US20120137137A1 (en) | 2010-11-30 | 2012-05-31 | Brickell Ernest F | Method and apparatus for key provisioning of hardware devices |
-
2010
- 2010-11-30 US US12/956,793 patent/US20120137137A1/en not_active Abandoned
-
2011
- 2011-11-11 WO PCT/US2011/060345 patent/WO2012074720A1/en unknown
- 2011-11-11 EP EP11844100.5A patent/EP2647156A4/en not_active Withdrawn
- 2011-11-11 JP JP2013536941A patent/JP5690412B2/en not_active Expired - Fee Related
- 2011-11-11 CN CN201180057317.3A patent/CN103229451B/en not_active Expired - Fee Related
- 2011-11-22 TW TW100142701A patent/TWI567579B/en not_active IP Right Cessation
-
2013
- 2013-09-05 US US13/987,807 patent/US9043604B2/en active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6829596B1 (en) * | 2000-05-23 | 2004-12-07 | Steve Frazee | Account/asset activation device and method |
US20050022025A1 (en) * | 2003-06-30 | 2005-01-27 | Hug Joshua D. | Rights enforcement and usage reporting on a client device |
US7353388B1 (en) * | 2004-02-09 | 2008-04-01 | Avaya Technology Corp. | Key server for securing IP telephony registration, control, and maintenance |
US20080244698A1 (en) * | 2004-10-13 | 2008-10-02 | Matsushita Electric Industrial Co., Ltd. | Authorized Content Verification Method, Content Transmission/Reception System, Transmitter, and Receiver |
US8205080B2 (en) * | 2007-05-11 | 2012-06-19 | Microsoft Corporation | Over the air communication authentication using a device token |
WO2010116618A1 (en) * | 2009-04-06 | 2010-10-14 | パナソニック株式会社 | Key implementation system |
US20110091037A1 (en) * | 2009-10-16 | 2011-04-21 | Cisco Technology, Inc. | Content protection key encryptor for security providers |
CN101699891A (en) * | 2009-10-21 | 2010-04-28 | 西安西电捷通无线网络通信有限公司 | Method for key management and node authentication of sensor network |
US20120300939A1 (en) * | 2009-10-21 | 2012-11-29 | China Iwncomm Co., Ltd. | Key management and node authentication method for sensor network |
Cited By (173)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8607068B2 (en) * | 2008-10-23 | 2013-12-10 | St-Ericsson Sa | Method of storing data in a memory device and a processing device for processing such data |
US20110276809A1 (en) * | 2008-10-23 | 2011-11-10 | Herve Sibert | Method of Storing Data in a Memory Device and a Processing Device for Processing Such Data |
US9166783B2 (en) | 2010-10-14 | 2015-10-20 | Kabushiki Kaisha Toshiba | Protection method, decryption method, player, storage medium, and encryption apparatus of digital content |
US9043604B2 (en) | 2010-11-30 | 2015-05-26 | Intel Corporation | Method and apparatus for key provisioning of hardware devices |
US9280336B2 (en) * | 2011-06-30 | 2016-03-08 | International Business Machines Corporation | Virtual machine disk image installation |
US9875133B2 (en) | 2011-06-30 | 2018-01-23 | International Business Machines Corporation | Virtual machine disk image installation |
US20130007739A1 (en) * | 2011-06-30 | 2013-01-03 | Indrajit Poddar | Virtual machine disk image installation |
US20140351584A1 (en) * | 2011-08-12 | 2014-11-27 | Power-One Italy S.P.A. | Method and system for protected transmission of files |
US9225692B2 (en) * | 2011-08-12 | 2015-12-29 | Abb Technology Ag | Method and system for protected transmission of files |
US20130046981A1 (en) * | 2011-08-17 | 2013-02-21 | Vixs Systems, Inc. | Secure provisioning of integrated circuits at various states of deployment, methods thereof |
US9203617B2 (en) * | 2011-08-17 | 2015-12-01 | Vixs Systems, Inc. | Secure provisioning of integrated circuits at various states of deployment, methods thereof |
US9680643B2 (en) * | 2011-08-23 | 2017-06-13 | Siemens Aktiengesellschaft | System and method for the secure transmission of data |
US20140189374A1 (en) * | 2011-08-23 | 2014-07-03 | Bernd Meyer | System and method for the secure transmission of data |
US8661527B2 (en) | 2011-08-31 | 2014-02-25 | Kabushiki Kaisha Toshiba | Authenticator, authenticatee and authentication method |
US9887841B2 (en) | 2011-08-31 | 2018-02-06 | Toshiba Memory Corporation | Authenticator, authenticatee and authentication method |
US9225513B2 (en) | 2011-08-31 | 2015-12-29 | Kabushiki Kaisha Toshiba | Authenticator, authenticatee and authentication method |
US10361851B2 (en) | 2011-08-31 | 2019-07-23 | Toshiba Memory Corporation | Authenticator, authenticatee and authentication method |
US10361850B2 (en) | 2011-08-31 | 2019-07-23 | Toshiba Memory Corporation | Authenticator, authenticatee and authentication method |
US8645677B2 (en) * | 2011-09-28 | 2014-02-04 | Intel Corporation | Secure remote credential provisioning |
US8650393B2 (en) | 2011-11-11 | 2014-02-11 | Kabushiki Kaisha Toshiba | Authenticator |
US9100187B2 (en) | 2011-11-11 | 2015-08-04 | Kabushiki Kaisha Toshiba | Authenticator |
US8634557B2 (en) | 2011-12-02 | 2014-01-21 | Kabushiki Kaisha Toshiba | Semiconductor storage device |
US8761389B2 (en) | 2011-12-02 | 2014-06-24 | Kabushiki Kaisha Toshiba | Memory |
US20130145164A1 (en) * | 2011-12-02 | 2013-06-06 | Yuji Nagai | Semiconductor memory device |
US8812843B2 (en) | 2011-12-02 | 2014-08-19 | Kabushiki Kaisha Toshiba | Device and authentication method therefor |
US8732466B2 (en) * | 2011-12-02 | 2014-05-20 | Kabushiki Kaisha Toshiba | Semiconductor memory device |
US8855297B2 (en) | 2011-12-02 | 2014-10-07 | Kabushiki Kaisha Toshiba | Device and authentication method therefor |
US9887838B2 (en) | 2011-12-15 | 2018-02-06 | Intel Corporation | Method and device for secure communications over a network using a hardware security engine |
US9497171B2 (en) | 2011-12-15 | 2016-11-15 | Intel Corporation | Method, device, and system for securely sharing media content from a source device |
US9544141B2 (en) | 2011-12-29 | 2017-01-10 | Intel Corporation | Secure key storage using physically unclonable functions |
US10284368B2 (en) | 2011-12-29 | 2019-05-07 | Intel Corporation | Secure key storage |
US9160531B2 (en) | 2012-01-16 | 2015-10-13 | Kabushiki Kaisha Toshiba | Host device, semiconductor memory device, and authentication method |
US8667286B2 (en) | 2012-01-16 | 2014-03-04 | Kabushiki Kaisha Toshiba | Host device, semiconductor memory device, and authentication method |
US8990571B2 (en) | 2012-01-16 | 2015-03-24 | Kabushiki Kaisha Toshiba | Host device, semiconductor memory device, and authentication method |
US20130339732A1 (en) * | 2012-06-15 | 2013-12-19 | Kabushiki Kaisha Toshiba | Device |
US20140223188A1 (en) * | 2012-06-15 | 2014-08-07 | Kabushiki Kaisha Toshiba | Device |
US8762717B2 (en) * | 2012-06-15 | 2014-06-24 | Kabushiki Kaisha Toshiba | Authentication device |
US9996480B2 (en) | 2012-07-18 | 2018-06-12 | Analog Devices, Inc. | Resilient device authentication system with metadata binding |
US10135815B2 (en) | 2012-09-05 | 2018-11-20 | Element, Inc. | System and method for biometric authentication in connection with camera equipped devices |
US10728242B2 (en) | 2012-09-05 | 2020-07-28 | Element Inc. | System and method for biometric authentication in connection with camera-equipped devices |
US9742563B2 (en) * | 2012-09-28 | 2017-08-22 | Intel Corporation | Secure provisioning of secret keys during integrated circuit manufacturing |
GB2520196A (en) * | 2012-09-28 | 2015-05-13 | Intel Corp | Integrated circuits having accessible and inaccessible physically unclonable functions |
CN104584435A (en) * | 2012-09-28 | 2015-04-29 | 英特尔公司 | Integrated circuits having accessible and inaccessible physically unclonable functions |
US8928347B2 (en) | 2012-09-28 | 2015-01-06 | Intel Corporation | Integrated circuits having accessible and inaccessible physically unclonable functions |
WO2014051741A3 (en) * | 2012-09-28 | 2014-09-12 | Intel Corporation | Integrated circuits having accessible and inaccessible physically unclonable functions |
US20140093074A1 (en) * | 2012-09-28 | 2014-04-03 | Kevin C. Gotze | Secure provisioning of secret keys during integrated circuit manufacturing |
WO2014051741A2 (en) * | 2012-09-28 | 2014-04-03 | Intel Corporation | Integrated circuits having accessible and inaccessible physically unclonable functions |
US9143383B2 (en) * | 2012-11-01 | 2015-09-22 | Miiicasa Taiwan Inc. | Method and system for managing device identification |
US20140122885A1 (en) * | 2012-11-01 | 2014-05-01 | Miiicasa Taiwan Inc. | Method and system for managing device identification |
US8856515B2 (en) | 2012-11-08 | 2014-10-07 | Intel Corporation | Implementation of robust and secure content protection in a system-on-a-chip apparatus |
US20140133652A1 (en) * | 2012-11-12 | 2014-05-15 | Renesas Electronics Corporation | Semiconductor device and information processing system for encrypted communication |
US20180241559A1 (en) * | 2012-11-12 | 2018-08-23 | Renesas Electronics Corporation | Semiconductor device and information processing system for encrypted communication |
US10944554B2 (en) * | 2012-11-12 | 2021-03-09 | Renesas Electronics Corporation | Semiconductor device and information processing system for encrypted communication |
US9960914B2 (en) * | 2012-11-12 | 2018-05-01 | Renesas Electronics Corporation | Semiconductor device and information processing system for encrypted communication |
US9158901B2 (en) * | 2012-11-18 | 2015-10-13 | Cisco Technology Inc. | Glitch resistant device |
US20140143552A1 (en) * | 2012-11-18 | 2014-05-22 | Cisco Technology Inc. | Glitch Resistant Device |
US8885819B2 (en) * | 2012-12-27 | 2014-11-11 | Intel Corporation | Fuse attestation to secure the provisioning of secret keys during integrated circuit manufacturing |
US8938792B2 (en) * | 2012-12-28 | 2015-01-20 | Intel Corporation | Device authentication using a physically unclonable functions based key generation system |
WO2014105146A1 (en) * | 2012-12-29 | 2014-07-03 | Intel Corporation | Secure key derivation and cryptography logic for integrated circuits |
US9390291B2 (en) | 2012-12-29 | 2016-07-12 | Intel Corporation | Secure key derivation and cryptography logic for integrated circuits |
KR20150079880A (en) * | 2012-12-29 | 2015-07-08 | 인텔 코포레이션 | Secure key derivation and cryptography logic for integrated circuits |
KR101726108B1 (en) * | 2012-12-29 | 2017-04-11 | 인텔 코포레이션 | Secure key derivation and cryptography logic for integrated circuits |
US9201811B2 (en) | 2013-02-14 | 2015-12-01 | Kabushiki Kaisha Toshiba | Device and authentication method therefor |
US8984294B2 (en) | 2013-02-15 | 2015-03-17 | Kabushiki Kaisha Toshiba | System of authenticating an individual memory device via reading data including prohibited data and readable data |
US10366218B2 (en) | 2013-03-22 | 2019-07-30 | Nok Nok Labs, Inc. | System and method for collecting and utilizing client data for risk assessment during authentication |
US10762181B2 (en) | 2013-03-22 | 2020-09-01 | Nok Nok Labs, Inc. | System and method for user confirmation of online transactions |
US10282533B2 (en) | 2013-03-22 | 2019-05-07 | Nok Nok Labs, Inc. | System and method for eye tracking during authentication |
US11929997B2 (en) | 2013-03-22 | 2024-03-12 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
US10706132B2 (en) | 2013-03-22 | 2020-07-07 | Nok Nok Labs, Inc. | System and method for adaptive user authentication |
US10776464B2 (en) | 2013-03-22 | 2020-09-15 | Nok Nok Labs, Inc. | System and method for adaptive application of authentication policies |
EP2947811A4 (en) * | 2013-06-05 | 2016-04-06 | Huawei Tech Co Ltd | Method, server, host and system for protecting data security |
US20140380057A1 (en) * | 2013-06-05 | 2014-12-25 | Huawei Technologies Co., Ltd. | Method, Server, Host, and System for Protecting Data Security |
US20140365763A1 (en) * | 2013-06-07 | 2014-12-11 | Qualcomm Incorporated | Apparatus and method for provisioning an endorsement key certificate for a firmware trusted platform module |
US9100192B2 (en) * | 2013-06-07 | 2015-08-04 | Qualcomm Incorporated | Apparatus and method for provisioning an endorsement key certificate for a firmware trusted platform module |
JP2016521937A (en) * | 2013-06-07 | 2016-07-25 | クアルコム,インコーポレイテッド | Apparatus and method for provisioning an endorsement key certificate for a firmware trusted platform module |
CN105339948A (en) * | 2013-06-07 | 2016-02-17 | 高通股份有限公司 | Apparatus and method for provisioning an endorsement key certificate for a firmware trusted platform module |
US9479328B1 (en) * | 2013-06-11 | 2016-10-25 | Amazon Technologies, Inc. | Secure key provisioning |
US20170039368A1 (en) * | 2013-09-27 | 2017-02-09 | Mcafee, Inc. | Trusted execution of an executable object on a local device |
US11907362B2 (en) | 2013-09-27 | 2024-02-20 | MAfee, LLC | Trusted execution of an executable object on a local device |
US10678908B2 (en) * | 2013-09-27 | 2020-06-09 | Mcafee, Llc | Trusted execution of an executable object on a local device |
US20180234410A1 (en) * | 2013-10-29 | 2018-08-16 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
US10798087B2 (en) * | 2013-10-29 | 2020-10-06 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
WO2015116288A3 (en) * | 2013-11-10 | 2015-10-08 | Sypris Electronics, Llc | Authenticatable device |
US9998445B2 (en) | 2013-11-10 | 2018-06-12 | Analog Devices, Inc. | Authentication system |
US9806883B2 (en) | 2013-12-23 | 2017-10-31 | Siemens Aktiengesellschaft | Secure provision of a key |
EP2899714A1 (en) * | 2013-12-23 | 2015-07-29 | Siemens Aktiengesellschaft | Secure provision of a key |
CN104734854A (en) * | 2013-12-23 | 2015-06-24 | 西门子公司 | Secure Provision of a Key |
US9258315B2 (en) * | 2014-01-13 | 2016-02-09 | Cisco Technology, Inc. | Dynamic filtering for SDN API calls across a security boundary |
US9819493B2 (en) * | 2014-02-26 | 2017-11-14 | Unisys Corporation | Enhanced security for media encryption |
US9519757B2 (en) * | 2014-02-26 | 2016-12-13 | Unisys Corporation | AES-GCM based enhanced security setup for media encryption |
US9825764B2 (en) * | 2014-02-26 | 2017-11-21 | Unisys Corporation | Enhanced security for media decryption |
EP3075096A4 (en) * | 2014-03-11 | 2017-06-07 | Tencent Technology (Shenzhen) Company Limited | Method and system for encrypted communications |
US10931467B2 (en) | 2014-05-05 | 2021-02-23 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US10013543B2 (en) | 2014-05-05 | 2018-07-03 | Analog Devices, Inc. | System and device binding metadata with hardware intrinsic properties |
US10432409B2 (en) | 2014-05-05 | 2019-10-01 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US9672342B2 (en) | 2014-05-05 | 2017-06-06 | Analog Devices, Inc. | System and device binding metadata with hardware intrinsic properties |
US9946858B2 (en) | 2014-05-05 | 2018-04-17 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US10771267B2 (en) | 2014-05-05 | 2020-09-08 | Analog Devices, Inc. | Authentication system and device including physical unclonable function and threshold cryptography |
US9913135B2 (en) | 2014-05-13 | 2018-03-06 | Element, Inc. | System and method for electronic key provisioning and access management in connection with mobile devices |
US10382962B2 (en) | 2014-05-22 | 2019-08-13 | Analog Devices, Inc. | Network authentication system with dynamic key generation |
US9965728B2 (en) | 2014-06-03 | 2018-05-08 | Element, Inc. | Attendance authentication and management in connection with mobile devices |
WO2016025940A1 (en) * | 2014-08-15 | 2016-02-18 | Sypris Electronics, Llc | Resilient device authentication system with metadata binding |
US20160078251A1 (en) * | 2014-09-16 | 2016-03-17 | Freescale Semiconductor, Inc. | Key storage and revocation in a secure memory system |
US9830479B2 (en) * | 2014-09-16 | 2017-11-28 | Nxp Usa, Inc. | Key storage and revocation in a secure memory system |
US9646154B2 (en) | 2014-12-12 | 2017-05-09 | Microsoft Technology Licensing, Llc | Return oriented programming (ROP) attack protection |
US9714004B2 (en) | 2015-02-02 | 2017-07-25 | Kabushiki Kaisha Tokai Rika Denki Seisakusho | Electronic key registration system |
US9852300B2 (en) * | 2015-09-25 | 2017-12-26 | Saife, Inc. | Secure audit logging |
US20170091463A1 (en) * | 2015-09-25 | 2017-03-30 | Ty Lindteigen | Secure Audit Logging |
US9838201B2 (en) | 2015-10-13 | 2017-12-05 | Sony Interactive Entertainment America Llc | Secure key store derivation and management from a single secure root key |
WO2017065900A1 (en) * | 2015-10-13 | 2017-04-20 | Sony Interactive Entertainment America Llc | Secure key store derivation and management from a single secure root key |
EP3214797A1 (en) * | 2016-03-01 | 2017-09-06 | Siemens Aktiengesellschaft | Deriving a device unique encryption key of a system on chip using a physical unclonable function |
CN109074466A (en) * | 2016-06-18 | 2018-12-21 | 英特尔公司 | Platform for server proves and registration |
US10637853B2 (en) | 2016-08-05 | 2020-04-28 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US10769635B2 (en) | 2016-08-05 | 2020-09-08 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US11463267B2 (en) | 2016-09-08 | 2022-10-04 | Nec Corporation | Network function virtualization system and verifying method |
US11398906B2 (en) | 2016-11-10 | 2022-07-26 | Brickell Cryptology Llc | Confirming receipt of audit records for audited use of a cryptographic key |
US10498712B2 (en) | 2016-11-10 | 2019-12-03 | Ernest Brickell | Balancing public and personal security needs |
US10855465B2 (en) | 2016-11-10 | 2020-12-01 | Ernest Brickell | Audited use of a cryptographic key |
US11115208B2 (en) * | 2016-11-10 | 2021-09-07 | Ernest Brickell | Protecting sensitive information from an authorized device unlock |
US11405201B2 (en) | 2016-11-10 | 2022-08-02 | Brickell Cryptology Llc | Secure transfer of protected application storage keys with change of trusted computing base |
WO2018089006A1 (en) * | 2016-11-10 | 2018-05-17 | Ernest Brickell | Balancing public and personal security needs |
US10652245B2 (en) | 2017-05-04 | 2020-05-12 | Ernest Brickell | External accessibility for network devices |
US10771467B1 (en) | 2017-05-04 | 2020-09-08 | Ernest Brickell | External accessibility for computing devices |
US10904256B2 (en) | 2017-05-04 | 2021-01-26 | Ernest Brickell | External accessibility for computing devices |
US10348706B2 (en) | 2017-05-04 | 2019-07-09 | Ernest Brickell | Assuring external accessibility for devices on a network |
US10425235B2 (en) | 2017-06-02 | 2019-09-24 | Analog Devices, Inc. | Device and system with global tamper resistance |
US10958452B2 (en) | 2017-06-06 | 2021-03-23 | Analog Devices, Inc. | System and device including reconfigurable physical unclonable functions and threshold cryptography |
US10938560B2 (en) | 2017-06-21 | 2021-03-02 | Microsoft Technology Licensing, Llc | Authorization key escrow |
US10440006B2 (en) | 2017-06-21 | 2019-10-08 | Microsoft Technology Licensing, Llc | Device with embedded certificate authority |
US10558812B2 (en) | 2017-06-21 | 2020-02-11 | Microsoft Technology Licensing, Llc | Mutual authentication with integrity attestation |
US11374760B2 (en) | 2017-09-13 | 2022-06-28 | Microsoft Technology Licensing, Llc | Cyber physical key |
US10735959B2 (en) | 2017-09-18 | 2020-08-04 | Element Inc. | Methods, systems, and media for detecting spoofing in mobile authentication |
US10482252B2 (en) * | 2017-09-18 | 2019-11-19 | Nxp B.V. | Method for protecting the confidentiality and integrity of firmware for an Internet of Things device |
US20190087577A1 (en) * | 2017-09-18 | 2019-03-21 | Nxp B.V. | Method for protecting the confidentiality and integrity of firmware for an internet of things device |
US11425562B2 (en) | 2017-09-18 | 2022-08-23 | Element Inc. | Methods, systems, and media for detecting spoofing in mobile authentication |
KR20190035356A (en) * | 2017-09-26 | 2019-04-03 | 삼성에스디에스 주식회사 | Method for provisioning key information and apparatus using the same |
WO2019066319A1 (en) * | 2017-09-26 | 2019-04-04 | Samsung Sds Co., Ltd. | Method of provisioning key information and apparatus using the method |
KR102305858B1 (en) * | 2017-09-26 | 2021-09-27 | 삼성에스디에스 주식회사 | Method for provisioning key information and apparatus using the same |
CN109560925A (en) * | 2017-09-26 | 2019-04-02 | 三星Sds株式会社 | Key information Supply Method and the device for utilizing key information Supply Method |
US11101994B2 (en) | 2017-09-26 | 2021-08-24 | Samsung Sds Co., Ltd. | Method of provisioning key information and apparatus using the method |
US20190097795A1 (en) * | 2017-09-26 | 2019-03-28 | Samsung Sds Co., Ltd. | Method of provisioning key information and apparatus using the method |
US10666430B2 (en) * | 2017-09-29 | 2020-05-26 | Intel Corporation | System and techniques for encrypting chip-to-chip communication links |
US20190103961A1 (en) * | 2017-09-29 | 2019-04-04 | Intel Corporation | System and techniques for encrypting chip-to-chip communication links |
US11868995B2 (en) | 2017-11-27 | 2024-01-09 | Nok Nok Labs, Inc. | Extending a secure key storage for transaction confirmation and cryptocurrency |
US20200387611A1 (en) * | 2017-12-22 | 2020-12-10 | Vincent J. Zimmer | Manageability engine and automatic firmware validation |
US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
US11308241B2 (en) * | 2018-05-14 | 2022-04-19 | Innogrit Technologies Co., Ltd. | Security data generation based upon software unreadable registers |
WO2019231683A1 (en) * | 2018-05-31 | 2019-12-05 | Motorola Solutions, Inc. | Method for provisioning device certificates for electronic processors in untrusted environments |
US10979232B2 (en) * | 2018-05-31 | 2021-04-13 | Motorola Solutions, Inc. | Method for provisioning device certificates for electronic processors in untrusted environments |
GB2587957B (en) * | 2018-05-31 | 2022-11-09 | Motorola Solutions Inc | Method for provisioning device certificates for electronic processors in untrusted environments |
US20190372780A1 (en) * | 2018-05-31 | 2019-12-05 | Motorola Solutions, Inc. | Method for provisioning device certificates for electronic processors in untrusted environments |
GB2587957A (en) * | 2018-05-31 | 2021-04-14 | Motorola Solutions Inc | Method for provisioning device certificates for electronic processors in untrusted environments |
US10878106B2 (en) * | 2018-08-01 | 2020-12-29 | Vdoo Connected Trust Ltd. | Firmware verification |
US20220050605A1 (en) * | 2018-12-03 | 2022-02-17 | Nagravision Sa | Remote enforcement of device memory |
CN109787756A (en) * | 2018-12-24 | 2019-05-21 | 吉林微思智能科技有限公司 | A kind of car-mounted terminal key distribution management method based on whitepack encryption technology |
WO2020185582A1 (en) * | 2019-03-08 | 2020-09-17 | Ares Technologies, Inc. | Methods and systems for implementing an anonymized attestation chain |
US10735205B1 (en) * | 2019-03-08 | 2020-08-04 | Ares Technologies, Inc. | Methods and systems for implementing an anonymized attestation chain |
US11343277B2 (en) | 2019-03-12 | 2022-05-24 | Element Inc. | Methods and systems for detecting spoofing of facial recognition in connection with mobile devices |
US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
US20220129565A1 (en) * | 2019-07-09 | 2022-04-28 | Huawei Technologies Co., Ltd. | Operation method, operation apparatus, and device |
US11868485B2 (en) * | 2019-07-09 | 2024-01-09 | Huawei Technologies Co., Ltd. | Operation method, operation apparatus, and device |
CN114830110A (en) * | 2019-11-07 | 2022-07-29 | 美光科技公司 | Single-use password generation |
US11728982B2 (en) | 2019-11-07 | 2023-08-15 | Micron Technology, Inc. | Single-use password generation |
US11507248B2 (en) | 2019-12-16 | 2022-11-22 | Element Inc. | Methods, systems, and media for anti-spoofing using eye-tracking |
US11409877B2 (en) * | 2020-03-27 | 2022-08-09 | Intel Corporation | Firmware verification mechanism |
US11928215B2 (en) | 2020-03-27 | 2024-03-12 | Intel Corporation | Firmware verification mechanism |
NL2025695B1 (en) * | 2020-05-28 | 2022-01-13 | Sandgrain B V | Centralized handling of ic identification codes |
WO2021240445A1 (en) | 2020-05-28 | 2021-12-02 | Sandgrain B.V. | Centralized handling of ic identification codes |
NL1044044A (en) | 2020-05-28 | 2021-12-01 | Sandgrain B V | Centralized handling of ic identification codes |
US20230040468A1 (en) * | 2021-08-04 | 2023-02-09 | International Business Machines Corporation | Deploying a system-specific secret in a highly resilient computer system |
WO2023011850A1 (en) * | 2021-08-04 | 2023-02-09 | International Business Machines Corporation | Deploying a system-specific secret in a highly resilient computer system |
US20230205895A1 (en) * | 2021-12-29 | 2023-06-29 | Arm Limited | Methods and apparatus for provisioning a device |
US20220245252A1 (en) * | 2022-02-22 | 2022-08-04 | Intel Corporation | Seamless firmware update mechanism |
Also Published As
Publication number | Publication date |
---|---|
TW201227390A (en) | 2012-07-01 |
JP5690412B2 (en) | 2015-03-25 |
JP2013545388A (en) | 2013-12-19 |
CN103229451A (en) | 2013-07-31 |
CN103229451B (en) | 2015-11-25 |
EP2647156A1 (en) | 2013-10-09 |
EP2647156A4 (en) | 2017-07-05 |
US9043604B2 (en) | 2015-05-26 |
TWI567579B (en) | 2017-01-21 |
WO2012074720A1 (en) | 2012-06-07 |
US20140089659A1 (en) | 2014-03-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9043604B2 (en) | Method and apparatus for key provisioning of hardware devices | |
US9602282B2 (en) | Secure software and hardware association technique | |
US11604901B2 (en) | Systems and methods for using extended hardware security modules | |
US8677144B2 (en) | Secure software and hardware association technique | |
CN109714168B (en) | Trusted remote attestation method, device and system | |
US7502946B2 (en) | Using hardware to secure areas of long term storage in CE devices | |
CN109937419B (en) | Initialization method for security function enhanced device and firmware update method for device | |
US8462955B2 (en) | Key protectors based on online keys | |
CN110249336B (en) | Addressing trusted execution environments using signing keys | |
US20100332820A1 (en) | Information security device and information security system | |
US20100268936A1 (en) | Information security device and information security system | |
CN113785548B (en) | Attestation service for enforcing payload security policies in a data center | |
US11334345B2 (en) | Differential firmware update generation | |
US9893882B1 (en) | Apparatus, system, and method for detecting device tampering | |
US10229272B2 (en) | Identifying security boundaries on computing devices | |
US20180260568A1 (en) | Modifying service operating system of baseboard management controller | |
US10841287B2 (en) | System and method for generating and managing a key package | |
US20120213370A1 (en) | Secure management and personalization of unique code signing keys | |
US10938563B2 (en) | Technologies for provisioning cryptographic keys | |
US20210126776A1 (en) | Technologies for establishing device locality | |
EP3525391A1 (en) | Device and method for key provisioning | |
KR20220081068A (en) | Application security device and method using encryption/decryption key |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BRICKELL, ERNEST F.;GUERON, SHAY;LI, JIANGTAO;AND OTHERS;SIGNING DATES FROM 20101228 TO 20110209;REEL/FRAME:025793/0783 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |