Abstract: Embodiments include a serial bus controller that may be coupled to an in band serial peripheral interface (SPI) link, to request a write of data and a subsequent read of the data from a memory device and in response to the request to read the data, receive a bit error report and optionally correct the bit error over the in band SPI link. Embodiments include a memory device, e.g., a flash memory device, to detect and report the bit error over the in band SPI link, where the flash memory device, in response to a request to write and/or erase data, calculates or determines an error correction code (ECC) and stores corresponding parity data. In embodiments, after receiving a subsequent request to read the data, the flash memory device accesses the stored parity data to check the ECC for a bit error and if a bit error is detected, reports the detected bit error over the in band SPI link. Other embodiments may be described and claimed.

Abstract: Embodiments described herein enable independently recoverable security for processor and peripheral communication, enabling a processor without native non-volatile memory to generate and recover credentials in response to a firmware update. The processor and peripheral can each have credentials burned into secure fuses. The processor can derive a shared secret from the secure fuses using security attributes that are based on the security version number of firmware within the processor and the peripherals to which the processor is to security communicate. The processor and peripherals can generate ephemeral session keys from the shared secret and nonces. The ephemeral session keys can be used to secure communications between the processor and the peripherals.

Abstract: In embodiments, an apparatus for microcontroller (?C) or system-on-chip (SoC) computing includes a set of fuses disposed in a ?C or a SoC to store a seed value and M pairs of loop counter values (LCVs) with which to locally generate M private keys from the seed value on the microcontroller or SoC, where M is a positive integer, each private key to decrypt data encrypted with a pre-defined public key cryptosystem, wherein each private key includes two prime numbers p and q (p,q), the LCVs being a number of iterations of a key derivation function (KDF) needed to respectively obtain p and q from the seed value; and a key decoder, disposed in the (?C) or the SoC, and coupled to the set of fuses, to read the seed value and the M pairs of LCVs, and, for each of the M private keys to: respectively generate (p,q) from the seed value by respectively iterating the KDF by the LCVs for that key.

Abstract: In one embodiment, an apparatus includes a non-volatile storage to store a seed value and a signature that is based on an iterative execution of a function for a predetermined number of intervals. The apparatus may further include the security processor coupled to the non-volatile storage, where the security processor is to independently recover a credential for an updated version of the firmware based at least in part on the seed value and a security version number for the updated version of the firmware. Other embodiments are described and claimed.

Abstract: A system-on-chip (SoC) includes a host CPU on a CPU fabric, the host CPU including multiple processor cores, each associated with multiple security attributes. The SoC includes a secure asset on a network-on-chip and a security co-processor. The security co-processor includes circuitry to detect requests from the processor cores targeting the secure asset and security function processing requests, to determine, based on associated security attributes, whether the core or function is authorized to access the secure asset, to allow the request to be issued, if the core or function is so authorized, and to prevent its issuance, if not. The determination may be dependent on a signal from the CPU fabric indicating whether the host CPU can modify its security attributes or they are locked down. The security co-processor may have the highest security level and may be the only master on the SoC that can access the secure asset.

Abstract: A system-on-chip (SoC) includes a host CPU on a CPU fabric, the host CPU including multiple processor cores, each associated with multiple security attributes. The SoC includes a secure asset on a network-on-chip and a security co-processor. The security co-processor includes circuitry to detect requests from the processor cores targeting the secure asset and security function processing requests, to determine, based on associated security attributes, whether the core or function is authorized to access the secure asset, to allow the request to be issued, if the core or function is so authorized, and to prevent its issuance, if not. The determination may be dependent on a signal from the CPU fabric indicating whether the host CPU can modify its security attributes or they are locked down. The security co-processor may have the highest security level and may be the only master on the SoC that can access the secure asset.

Abstract: Embodiments include a serial bus controller that may be coupled to an in band serial peripheral interface (SPI) link, to request a write of data and a subsequent read of the data from a slave device and in response to the request to read the data, receive a bit error report and optionally correct the bit error over the in band SPI link. Embodiments include a slave device, e.g., a flash memory device, to detect and report the bit error over the in band SPI link, where the flash memory device, in response to a request to write and/or erase data, calculates or determines an error correction code (ECC) and stores corresponding parity data. In embodiments, after receiving a subsequent request to read the data, the flash memory device accesses the stored parity data to check the ECC for a bit error and if a bit error is detected, reports the detected bit error over the in band SPI link. Other embodiments may be described and claimed.

Abstract: Embodiments described herein enable independently recoverable security for processor and peripheral communication, enabling a processor without native non-volatile memory to generate and recover credentials in response to a firmware update. The processor and peripheral can each have credentials burned into secure fuses. The processor can derive a shared secret from the secure fuses using security attributes that are based on the security version number of firmware within the processor and the peripherals to which the processor is to security communicate. The processor and peripherals can generate ephemeral session keys from the shared secret and nonces. The ephemeral session keys can be used to secure communications between the processor and the peripherals.

Abstract: Technologies for securely binding a manifest to a platform include a computing device having a security engine and a field-programmable fuse. The computing device receives a platform manifest indicative of a hardware configuration of the computing device and a manifest hash. The security engine of the computing device blows a bit of a field programmable fuse and then stores the manifest hash and a counter value of the field-programmable fuse in integrity-protected non-volatile storage. In response to a platform reset, the security engine verifies the stored manifest hash and counter value and then determines whether the stored counter value matches the field-programmable fuse. If verified and current, trusted software may calculate a hash of the platform manifest and compare the calculated hash to the stored manifest hash. If matching, the platform manifest may be used to discover platform hardware. Other embodiments are described and claimed.

Abstract: In embodiments, an apparatus for microcontroller (?C) or system-on-chip (SoC) computing includes a set of fuses disposed in a ?C or a SoC to store a seed value and M pairs of loop counter values (LCVs) with which to locally generate M private keys from the seed value on the microcontroller or SoC, where M is a positive integer, each private key to decrypt data encrypted with a pre-defined public key cryptosystem, wherein each private key includes two prime numbers p and q (p,q), the LCVs being a number of iterations of a key derivation function (KDF) needed to respectively obtain p and q from the seed value; and a key decoder, disposed in the (?C) or the SoC, and coupled to the set of fuses, to read the seed value and the M pairs of LCVs, and, for each of the M private keys to: respectively generate (p,q) from the seed value by respectively iterating the KDF by the LCVs for that key.

Abstract: In one embodiment, an apparatus includes a non-volatile storage to store a seed value and a signature that is based on an iterative execution of a function for a predetermined number of intervals. The apparatus may further include the security processor coupled to the non-volatile storage, where the security processor is to independently recover a credential for an updated version of the firmware based at least in part on the seed value and a security version number for the updated version of the firmware. Other embodiments are described and claimed.

Abstract: Various embodiments for providing datalink security in a datalink between a first hardware device (e.g., a system-on-a-chip (SoC) device) and a second hardware device (e.g., an encrypted storage device) are described. Various embodiments using differing types of keys and setups are described and claimed.

Abstract: A system-on-chip (SoC) includes a host CPU on a CPU fabric, the host CPU including multiple processor cores, each associated with multiple security attributes. The SoC includes a secure asset on a network-on-chip and a security co-processor. The security co-processor includes circuitry to detect requests from the processor cores targeting the secure asset and security function processing requests, to determine, based on associated security attributes, whether the core or function is authorized to access the secure asset, to allow the request to be issued, if the core or function is so authorized, and to prevent its issuance, if not. The determination may be dependent on a signal from the CPU fabric indicating whether the host CPU can modify its security attributes or they are locked down. The security co-processor may have the highest security level and may be the only master on the SoC that can access the secure asset.

Abstract: Technologies for securely binding a manifest to a platform include a computing device having a security engine and a field-programmable fuse. The computing device receives a platform manifest indicative of a hardware configuration of the computing device and a manifest hash. The security engine of the computing device blows a bit of a field programmable fuse and then stores the manifest hash and a counter value of the field-programmable fuse in integrity-protected non-volatile storage. In response to a platform reset, the security engine verifies the stored manifest hash and counter value and then determines whether the stored counter value matches the field-programmable fuse. If verified and current, trusted software may calculate a hash of the platform manifest and compare the calculated hash to the stored manifest hash. If matching, the platform manifest may be used to discover platform hardware. Other embodiments are described and claimed.

Abstract: Provided are a system, memory controller, and method for using counters and a table to protect data in a storage device. Upon initiating operations to modify a file in the storage device, a storage write counter is incremented in response to initiating the operations to modify the file. In response to incrementing the storage write counter, write table operations are initiated including setting a table write counter to a storage write counter and setting a table commit counter to the storage commit counter plus a value. The operation to modify the file in response to completing the write table operations. The system commit counter is incremented by the value in response to completing the operation to modify the file.

Abstract: A method of protecting a cabinet includes the positioning of a liner on a bottom wall of a cabinet. The cabinet has a top wall and a perimeter wall that is attached to and extends between the top and bottom walls. The perimeter wall has a front side is open. At least one door is mounted on the perimeter wall to selectively open or close the front side. The liner includes a lower wall and a peripheral wall that is attached to and extends upwardly from the lower wall.

Abstract: Provided are a system, memory controller, and method for using counters and a table to protect data in a storage device. Upon initiating operations to modify a file in the storage device, a storage write counter is incremented in response to initiating the operations to modify the file. In response to incrementing the storage write counter, write table operations are initiated including setting a table write counter to a storage write counter and setting a table commit counter to the storage commit counter plus a value. The operation to modify the file in response to completing the write table operations. The system commit counter is incremented by the value in response to completing the operation to modify the file.

Abstract: In one embodiment, a processor has at least one core to execute instructions, a security engine coupled to the at least one core, a first storage to store a first immutable key associated with a vendor of the processor, and a second storage to store a second immutable key associated with an original equipment manufacturer (OEM) of the system. A first portion of firmware is to be verified based at least in part on the first immutable key and a second portion of firmware is to be verified based at least in part on the second immutable key, the first portion of firmware associated with the vendor and the second portion of firmware associated with the OEM. Other embodiments are described and claimed.

Abstract: Embodiments of the invention create an underlying infrastructure in a flash memory device (e.g., a serial peripheral interface (SPI) flash memory device) such that it may be protected against user attacks—e.g., replacing the SPI flash memory device or a man-in-the-middle (MITM) attack to modify the SPI flash memory contents on the fly. In the prior art, monotonic counters cannot be stored in SPI flash memory devices because said devices do not provide replay protection for the counters. A user may also remove the flash memory device and reprogram it. Host platforms alone cannot protect against such hardware attacks. Embodiments of the invention enable secure standard storage flash memory devices such as SPI flash memory devices to achieve replay protection for securely stored data. Embodiments of the invention utilize flash memory controllers, flash memory devices, unique device keys and HMAC key logic to create secure execution environments for various components.

Abstract: Embodiments of the invention create an underlying infrastructure in a flash memory device (e.g., a serial peripheral interface (SPI) flash memory device) such that it may be protected against user attacks—e.g., replacing the SPI flash memory device or a man-in-the-middle (MITM) attack to modify the SPI flash memory contents on the fly. In the prior art, monotonic counters cannot be stored in SPI flash memory devices because said devices do not provide replay protection for the counters. A user may also remove the flash memory device and reprogram it. Host platforms alone cannot protect against such hardware attacks. Embodiments of the invention enable secure standard storage flash memory devices such as SPI flash memory devices to achieve replay protection for securely stored data. Embodiments of the invention utilize flash memory controllers, flash memory devices, unique device keys and HMAC key logic to create secure execution environments for various components.