Abstract: The disclosed technology is generally directed to embedded device updates. In one example of the technology, a request for a nonce from a device is received. The nonce is sent in response to the request. An authentication request that includes the nonce, a set of measurements associated with the device, and a cryptographic signature generated from a private key associated with the device is received. The device is validated based on the authentication request. In response to successful validation of the device, a short-term certificate is generated for the device.

Abstract: The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Abstract: Specific images of an OS are built using only the driver bindings that are necessary to link the OS to the particular hardware of a client device. A device tree of the client device is analyzed to identify the hardware components. Databases of different hardware source code for various hardware drivers are maintained and used to craft the driver bindings and instances for the hardware of the client device. The device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. Specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers are then generated and included in an image of the OS that may be installed on the client device.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Abstract: Specific images of an OS are built using only the driver bindings that are necessary to link the OS to the particular hardware of a client device. A device tree of the client device is analyzed to identify the hardware components. Databases of different hardware source code for various hardware drivers are maintained and used to craft the driver bindings and instances for the hardware of the client device. The device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. Specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers are then generated and included in an image of the OS that may be installed on the client device.

Abstract: Specific images of an OS are built using only the driver bindings that are necessary to link the OS to the particular hardware of a client device. A device tree of the client device is analyzed to identify the hardware components. Databases of different hardware source code for various hardware drivers are maintained and used to craft the driver bindings and instances for the hardware of the client device. The device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. Specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers are then generated and included in an image of the OS that may be installed on the client device.

Abstract: The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Abstract: Specific images of an OS are built using only the driver bindings that are necessary to link the OS to the particular hardware of a client device. A device tree of the client device is analyzed to identify the hardware components. Databases of different hardware source code for various hardware drivers are maintained and used to craft the driver bindings and instances for the hardware of the client device. The device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. Specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers are then generated and included in an image of the OS that may be installed on the client device.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Abstract: The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Abstract: Disclosed is a cryptographic key management system implemented in access and tamper resistant circuitry. The circuitry includes processing circuitry to perform cryptographic processing based cryptographic keys. Cryptographic key registers include key portions and attribute portions. An interface receives commands from exposed circuitry that controls the processing circuitry to perform cryptographic processing based on the keys and associated attributes. The attributes indicate what operations may be performed on, or using, the associated keys. of the associated keys. The attributes indicate intended uses of the keys.

Abstract: The disclosed technology is generally directed to embedded device updates. In one example of the technology, a request for a nonce from a device is received. The nonce is sent in response to the request. An authentication request that includes the nonce, a set of measurements associated with the device, and a cryptographic signature generated from a private key associated with the device is received. The device is validated based on the authentication request. In response to successful validation of the device, a short-term certificate is generated for the device.

Abstract: The disclosed technology is generally directed to protection against unauthorized code. In one example of the technology, a read request to a restricted region of memory is detected. The read request is associated with a first processor. In response to detecting the read request to the restricted region of memory, a data value that causes an exception in response to execution by the first processor is provided.

Abstract: The disclosed technology is generally directed to embedded device updates. In one example of the technology, a request for a nonce from a device is received. The nonce is sent in response to the request. An authentication request that includes the nonce, a set of measurements associated with the device, and a cryptographic signature generated from a private key associated with the device is received. The device is validated based on the authentication request. In response to successful validation of the device, a short-term certificate is generated for the device.

Abstract: The disclosed technology is generally directed to secure key storage. A secret device key may be mutated based on a hash of a first boot loader to derive a first mutated key. The first mutated key may be mutated based on a random seed to derive a second mutated key. The second mutated key may be used to encrypt the hash of the runtime for a first core. The second mutated key may be mutated based on a hash of the runtime of the first execution environment for the second core to derive a third mutated key. The second mutated key may be used to encrypt the hash of the runtime of the first execution environment. The encrypted keys and hashes may be stored in a secure key store.

Abstract: The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Abstract: The subject disclosure is directed towards protecting code in memory from being modified after boot, such as code used in a dedicated microprocessor or microcontroller. Hardware, such as in logic or in a memory protection unit, allows a range of memory to be made non-writeable after being loaded, e.g., via a secure boot load operation. Further, startup code that is used to configure the hardware/memory may be made non-executable after having run once, so that no further execution may occur in that space, e.g., as a result of an attack. A function in the runtime code may allow for a limited, attack-protected reconfiguration of sub-regions of memory regions during the runtime execution.

Abstract: The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Abstract: The disclosed technology is generally directed to protection against unauthorized code. In one example of the technology, a read request to a restricted region of memory is detected. The read request is associated with a first processor. In response to detecting the read request to the restricted region of memory, a data value that causes an exception in response to execution by the first processor is provided.