Abstract: Technologies for establishing device locality are disclosed. A processor in a computing device generates an identifier distinct to the computing device. The processor transmits the identifier to a management controller via a hardware bus in the computing device. The processor generates a key and encrypts the key with the identifier to generate a wrapped key. The processor transmits the wrapped key to the management controller. In turn, the management controller unwraps the key using the identifier. Other embodiments are described and claimed.

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: Technologies for establishing device locality are disclosed. A processor in a computing device generates an identifier distinct to the computing device. The processor transmits the identifier to a management controller via a hardware bus in the computing device. The processor generates a key and encrypts the key with the identifier to generate a wrapped key. The processor transmits the wrapped key to the management controller. In turn, the management controller unwraps the key using the identifier. Other embodiments are described and claimed.

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: Technologies for establishing device locality are disclosed. A processor in a computing device generates an identifier distinct to the computing device. The processor transmits the identifier to a management controller via a hardware bus in the computing device. The processor generates a key and encrypts the key with the identifier to generate a wrapped key. The processor transmits the wrapped key to the management controller. In turn, the management controller unwraps the key using the identifier. 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 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: Technologies for establishing device locality are disclosed. A processor in a computing device generates an identifier distinct to the computing device. The processor transmits the identifier to a management controller via a hardware bus in the computing device. The processor generates a key and encrypts the key with the identifier to generate a wrapped key. The processor transmits the wrapped key to the management controller. In turn, the management controller unwraps the key using the identifier. 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: 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: 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.

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.