Patent Description:
Updates to firmware layers of computing devices are used in practice to fix bugs, to carry out maintenance and for deploying upgrades. However, enabling attestation of the updated firmware is not straightforward.

The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known ways of attesting update of a firmware layer. <CIT> describes a method for secure data protection including generating a firmware digital certificate for a layer of firmware. The firmware operates a hardware component of a compute node. The firmware digital certificate is an attribute certificate. The firmware digital certificate includes a cumulative hash of the layer of firmware and a nonce. The cumulative hash includes a concatenation of a hash of the layer of firmware and a hash of each one or more lower layers of the firmware. The method includes authenticating the layer of firmware using a trusted data store. The trusted data store includes a binary image of an expected layer of firmware and a certificate chain comprising the hardware digital certificate and the firmware digital certificate. <CIT> describes the implementation methods and device of a kind of device identification combine engine able to solve the problem of UDS leakage. The DICE includes Hard link input interface, selector, one-way function calculator, the first read-write register and the second read-write register of unique device secret UDS; First read-write register, for storing the input parameter all the way of one-way function calculator; Output parameter calculated in one-way function calculator, the corresponding UDS of chip for being inputted according to the Hard link input interface of the input parameter and UDS by selector; Second read-write register, for saving the output parameter of one-way function calculator; Selector, for disconnecting the connection with the Hard link input interface of UDS after obtaining output parameter to function calculator. <CIT> describes systems and methods for implementing a Device Identifier Composition Engine (DICE)-based trusted computing base architecture, among various hardware, firmware, and software layers. Attestation and security operations may be supported in a multi-layered approach, by operations to: obtain a component identifier from a particular layer of at least one operational layer in a computing system; obtain a first compound device identifier, produced as an attestation value at a lower layer; and process, with a function, the component identifier from the particular layer and the first compound device identifier from the lower layer, to produce a second compound device identifier. In various examples, the second compound device identifier indicates attestation of at least one layer located at or below the particular layer.

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not intended to identify key features or essential features of the claimed subject matter nor is it intended to be used to limit the scope of the claimed subject matter. Its sole purpose is to present a selection of concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

In various examples there is a method of enabling an attestable update of a firmware layer that provides a unique identity of a computing device. The method comprises using an immutable firmware layer to access a unique device secret. The immutable firmware layer is used to derive a hardware device identity (HDI) from the unique device secret. The immutable firmware layer is used to derive a compound device identity (CDI) from a measurement of the firmware layer and the unique device secret. The CDI and HDI are made available to the firmware layer. The firmware layer is used to issue a local certificate to endorse a device identity key, derived from the CDI, the local certificate signed by a key derived from the HDI. The unique device secret is unique among a plurality of devices.

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples are constructed or utilized. The description sets forth the functions of the examples and the sequence of operations for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.

Various embodiments are described which enable attestation of firmware at a computing device. In many cases the computing device is a peripheral device such as a graphics processing unit, field-programmable gate array (FPGA), application-specific integrated circuit, cryptographic accelerator, video processing unit, regular expression accelerator, data compression accelerator, artificial intelligence accelerator or other device used to complement a central processing unit (CPU). The CPU is part of functionality at a host computing device. Peripheral devices which comprise computer hardware to perform functions more efficiently than is possible in software running on a general-purpose CPU are often very useful units, separate from the CPU which act as hardware accelerators. Typically these types of peripheral device improve the execution of specific types of algorithm by allowing greater concurrency.

Increasingly there is a desire to work with sensitive code and or sensitive data and to retain security and privacy. Often large amounts of sensitive code and or data are to be processed using resource intensive algorithms and peripheral devices are an option to improve efficiency in such situations.

Where security and privacy are important, there is often a desire for one or more applications to be able to receive and verify an attestation from the peripheral device in order to know that the firmware on the peripheral device is as expected. For example, the firmware on the peripheral device is configured to enforce a trusted execution environment on the peripheral device and a verifier wants to know that the firmware on the peripheral device is correct and has not been tampered with or replaced by a malicious party. The verifier is an application which verifies the attestation. The verifier is at any computing element which is able to communicate with the host. In some cases the verifier is an application which is part of another service running on a server separate from the host and in communication with the host over any suitable communications network. A user relies on a trusted system to implement the verifier and verify the attestation and in some cases the host computing device is not trusted.

<FIG> is a schematic diagram of a data center <NUM> comprising a plurality of host computing devices <NUM>. Individual ones of the host computing devices <NUM> are connected to trusted peripheral devices <NUM>. The host computing devices <NUM> are interconnected using communications links which are not shown in <FIG> for clarity and the resulting network may include one or more computing devices which have no peripheral devices. Suppose the data center <NUM> is used to execute a resource intensive compute task <NUM> using sensitive code <NUM> and sensitive data <NUM>. The data center is able to distribute the resource intensive compute task amongst various user runtime processes at the hosts <NUM>. The trusted peripheral devices <NUM> are able to execute computations, in efficient ways making use of parallelization, and to do this in a way which is secure even though the hosts <NUM> may be untrusted and even though other unsecure processes are executing in the data center at the same time. In a few years it is expected that a majority of compute cycles in public clouds will be contributed by peripheral devices such as accelerators. In <FIG> a first verifier <NUM> is depicted outside the data centre and a second verifier <NUM> is depicted inside the data centre. In practice there are many verifiers either inside or outside the data centre. In <FIG> the first verifier <NUM> is an application at a server which is in communication with the data center <NUM> via any communications network. For example, the first verifier <NUM> is a on-premise machine at an enterprise within the enterprise trusted boundary. For example, the second verifier <NUM> is a trusted service that runs in a trusted execution environment in the data centre.

<FIG> illustrates the situation for a data center. However, it is also possible to use a host <NUM> and trusted peripheral device <NUM> in stand-alone situations or in other types of deployment.

Suppose that each of the peripheral devices in <FIG> has sent a certificate to one of the two verifiers <NUM>, <NUM> so that a verifier is able to verify that firmware on the peripheral device is as expected. A peripheral device generates a certificate for a public part of a key. The peripheral device derives the key using the unique device identifier of the peripheral device (where the unique device identifier is unique among devices) and a measurement of a firmware layer of the peripheral device. The certificate is referred to as a local certificate because it is generated by the peripheral device rather than a certificate authority of the manufacturer. The firmware layer that is measured to generate the key, and which generates the local certificate, is referred to as a firmware layer which provides a unique identity of the peripheral device. In an example, the firmware layer which provides a unique identity of the peripheral device is a RIoT core as explained below.

The firmware layer of the peripheral device, which provides the unique identity of the peripheral device, is mutable and suppose it is modified as a result of a firmware upgrade of the peripheral device. A local certificate previously generated is no longer workable to attest the firmware on the peripheral device since the measurement of the upgraded firmware layer will be different from the measurement of the original firmware layer.

The situation mentioned above occurs for any computing device where device identity and attestation is handled using the Device Identifier Composition Engine (DICE) standard of the Trusted Computing Group (TCG). DICE is a standardized method to create secret keys to be used by devices for authentication, attestation, data encryption and other purposes. DICE is typically implemented in hardware or read only memory (ROM)-based firmware. Robust Internet of Things (RIoT) is a family of protocols for using DICE-derived secrets. RIoT includes protocols for device attestation whereby there is secure reporting of the firmware that booted on a computing device. More detail about DICE and RIoT are given below with reference to <FIG>.

Various approaches for dealing with the problem of the local certificate being unworkable after a change to the firmware are considered.

One approach involves making the firmware layer from which the measurement is taken to generate the local certificate immutable for the lifetime of the device. This is implemented by storing (a hash of) the firmware layer in ROM, or by ensuring that the manufacturer issues device identity certificates for a single version of the firmware layer. In either case, updates to the firmware layer are not supported. With this approach it is best to keep the firmware layer as small and simple as possible since it cannot be upgraded. This approach is inflexible and does not enable updates to the firmware layer.

Another approach is to exclude the firmware layer from the measurement used to create the local certificate. This allows the firmware layer to be updated without changing device identity. However, it places a lot of trust in the manufacturer of the computing device, who may use an update mechanism to add backdoors after a device has been deployed. This approach is not satisfactory form a security perspective.

Another approach is for the manufacturer to issue a fresh certificate for every deployed device. However, this approach is only workable where the unique device secret is known to the manufacturer. This approach places a lot of administrative burden on the manufacturer. The approach also relies on trust in the manufacturer to keep information about the deployed devices secret.

Another approach is re-certification. In this approach device owners collect requests from the deployed devices for public device identity. The device owners then request the manufacturer to issue fresh certificates for the devices to use to attest their firmware. In confidential computing scenarios, where the device owner is not trusted, an appropriate authentication mechanism is needed to ensure that the manufacturer only signs appropriate keys. This approach introduces complexity and delays.

The inventors devised a way for the local certificate to be workable even after a change to the firmware layer which provides the device identity. In various examples described herein an immutable firmware layer is used to generate an additional secret referred to as Hardware Device Identity (HDI) which is not salted by the measurement of the firmware layer. The HDI remains constant despite firmware updates to the device and is used to enable firmware updates to take place in a manner so that the firmware is attestable in a simple and effective manner.

In various examples there is a method of enabling an attestable update of a firmware layer that provides a unique identity of a computing device. The method comprises using an immutable firmware layer to access a unique device secret. The immutable layer is used to derive a hardware device identity (HDI) from the unique device secret. The immutable layer is used to derive a compound device identity (CDI) from a measurement of the firmware layer, which provides the unique identity, and the unique device secret. The CDI and HDI are made available to the firmware layer. The firmware layer computes and issues a local certificate to endorse a device identity key, derived from the CDI, the local certificate signed by a key derived from the HDI. In this way a local certificate is issued by the firmware layer and is useable by a verifier to verify the firmware update. In contrast to the measurement of the firmware layer which is updated, the HDI remains constant despite the firmware layer update. The HDI is used to derive a key and the key is used to sign the local certificate.

The immutable firmware layer and the firmware layer which is updated operate together in an unconventional manner to achieve the ability to attest to the updated firmware layer.

The immutable firmware layer and the firmware layer which is updated together improve the functioning of the underlying computing device by generating and using the HDI in order to enable a local certificate to be generated to attest to the updated firmware layer.

<FIG> shows a CPU <NUM> of a host computing device <NUM>. The host computing device <NUM> has a software stack comprising a hypervisor <NUM>, host operating system <NUM>, peripheral device driver <NUM>, a user runtime process <NUM> and a user application <NUM>. The host computing device is connected to a peripheral device <NUM> via a peripheral component interconnect bus <NUM>. A non-exhaustive list of examples of types of peripheral device is: graphics processing unit, field-programmable gate array (FPGA), application-specific integrated circuit, cryptographic accelerator, video processing unit, regular expression accelerator, data compression accelerator, artificial intelligence accelerator and others.

The peripheral device <NUM> has a software stack comprising firmware <NUM> and code and data <NUM>. The hardware of the peripheral device (represented as region <NUM> in <FIG>) has burnt into it a unique device secret <NUM>. The unique device secret is provisioned into the hardware during manufacturing. The unique device secret is either generated within the peripheral device from a high entropy source or is provisioned externally.

An immutable firmware layer <NUM> is installed on the peripheral device as indicated schematically in <FIG>. Higher firmware layers of the peripheral device comprise a firmware layer providing device identity <NUM> and device firmware <NUM> as indicated schematically in <FIG>.

<FIG> also shows a device manufacturer certificate authority <NUM> which is a computing entity accessible via a communications network and which is able to generate and issue digital certificates. The digital certificates are made available to the owner of the peripheral devices and are available to various services via a certificate cache service.

In one embodiment where the peripheral device <NUM> complies with the Trusted Computing Group's DICE standard, the immutable firmware layer <NUM> of firmware implements the DICE layer and the firmware layer providing the device identity implements a RIoT core as now explained with reference to <FIG>.

<FIG> is a schematic diagram of a device identifier composition engine <NUM> and layers of firmware on a computing device such as the peripheral device of <FIG> and <FIG>. Burnt into the device hardware is a unique device secret <NUM>. The DICE <NUM> is deployed in hardware or ROM of the computing device and has access to the unique device secret <NUM>. The DICE is able to compute and issue a per-device secret called the compound device identity CDI <NUM>. Immediately above the DICE is a layer of firmware referred to as L0 firmware and also referred to as the RIoT core <NUM>. The L0 firmware provides a unique device identity of the computing device as it computes and issues keys and certificates <NUM> for device authentication. Immediately above the L0 firmware is L1 device firmware <NUM> and there are zero or more higher layers of device firmware <NUM> above the L1 device firmware.

<FIG> is a sequence chart of a method of attesting a firmware layer. The method of <FIG> cannot be used where the firmware layer L0 is updated. The method of <FIG> illustrates a problem that the present technology seeks to overcome. Individual vertical lines are used in <FIG> to represent each of, the unique device secret <NUM>, the DICE <NUM>, the L0 firmware <NUM>, the L1 firmware <NUM>, the manufacturer's certification authority <NUM> and a verifier <NUM>. Horizontal lines in <FIG> represent messages sent between the entities represented by the vertical lines and arrow on the horizontal lines represent the directions the messages are sent. The relative vertical position of the horizontal lines in <FIG> represents a chronological order in which the messages are sent.

As illustrated in <FIG> there is a DICE <NUM> of a computing device configured to use the Trusted Computing Group's DICE standard. When the computing device comes out of reset, control transfers to the DICE which is immutable. The DICE authenticates the L0 firmware using a public firmware signing key embedded in DICE as a constant. The DICE <NUM> derives <NUM> a CDI from the unique device secret (UDS) <NUM>. The CDI is expressed mathematically as: <MAT>.

Where KDF[x](l) is a key derivation which computes a key using x as the key and l as the salt. Any suitable key derivation function is used. The above equation is expressed in words as, a compound device identity key is computed using a key derivation function which takes as arguments the unique device secret and a hash of a measurement of the level L0 firmware layer.

After deriving CDI, DICE removes access to the unique device secret until the next boot cycle using a hardware mechanism such as a latch.

The DICE <NUM> sends (or makes available) the CDI to the L0 firmware <NUM> using message <NUM>.

The L0 firmware receives CDI from DICE and optionally authenticates the next layer of firmware L1 <NUM>.

The L0 firmware derives <NUM> a device identity key referred to as DevID from the CDI. The L0 firmware derives <NUM> an attestation key (AK) from the CDI and an L1 measurement which is a measurement of the level L1 firmware. <MAT> <MAT>.

Any suitable asymmetric key generation function is used. The above equations are expressed in words as: the private and public parts of the device identity public-private key pair are computed using an asymmetric key generation function given as argument, the result of the key derivation function applied to the compound device identity and a salt denoted "Identity" which is a label string. And, the attestation public-private key pair is computed using the asymmetric key generation function given as argument, the result of the key derivation function applied to the compound device identity and a salt which is a hash of a measurement of the level L1 firmware layer concatenated with a label string "Attestation".

The L0 firmware generates an attestation certificate for the AK and signs it using the private DevID. The attestation certificate is sent <NUM> to the verifier <NUM>. The level L0 firmware generates a self-signed certificate signing request (CSR) for DevID. The CSR is sent by the L0 firmware to the manufacturer's certificate authority. In response, the manufacturer's certificate authority <NUM> issues a certificate for the DevID and makes it available <NUM> to the verifier <NUM>.

Before transferring control to firmware layer L1, the L0 firmware layer erases the secrets CDI and DevIDpriv and copies the public keys, signature and measurements of L0 and L1 to an area of memory accessible to L1.

In the process of <FIG> if there is a change to firmware layer L0 because of a firmware upgrade, then the attestation key AK becomes out of date since it was based on a measurement of the L0 firmware layer.

<FIG> is a schematic diagram of another method of attesting a firmware layer which is compatible with an update to the firmware layer. In <FIG> the vertical lines are given the same reference numerals as for <FIG>. But note that DICE <NUM> can be any immutable firmware layer which has access to the unique device secret.

When the computing device comes out of reset, control transfers to the DICE <NUM> which is immutable. The DICE authenticates the L0 firmware using a public firmware signing key embedded in DICE as a constant. The DICE <NUM> derives <NUM> a CDI from the unique device secret (UDS) <NUM>. The CDI is expressed mathematically as given above for <FIG>.

The DICE <NUM> sends (or makes available) the CDI to the L0 firmware <NUM>. In an example the CDI and HDI are passed to L0 (indicated by <NUM> in <FIG>) by writing them to a pre-defined static random-access memory (SRAM) location before transferring control to the L1 firmware.

The DICE <NUM> derives <NUM> an additional secret referred to herein a Hardware Device Identity (HDI) from the unique device secret <NUM> which is not salted by measurement of the L0 firmware layer <NUM>. The DICE <NUM> sends or otherwise makes available, the HDI to the L0 firmware layer <NUM> such as using message <NUM>. Generation of the HDI is expressed mathematically as follows: <MAT> Which is expressed in words as the hardware device identity is derived using the key derivation function taking as arguments the unique device secret and a label string "DeviceCA" as a salt which is NOT a measurement of the L0 firmware. The DICE <NUM> sends (or makes available) the HDI to the L0 firmware <NUM> such as using message <NUM>.

The L0 firmware derives <NUM> a device identity key referred to as DevID from the CDI and a measurement of the L0 firmware as follows. <MAT> Which is expressed in words as the private and public parts of the device identity public-private key pair are computed using an asymmetric key generation function given as argument, the result of the key derivation function applied to the compound device identity and a label string "Identity" as a salt to the KDF.

The L0 firmware derives <NUM> an attestation key (AK) from the CDI and an L1 measurement which is a measurement of the level L1 firmware. An AK certificate is sent to the verifier.

The L0 firmware derives an additional key referred to as a device certificate authority key (DCK) <NUM> from HDI as follows: <MAT> Which is expressed in words as, a device certificate authority public private key pair is derived by using an asymmetric key generation function which takes as argument the result of a key derivation function applied to the hardware device key and a label string "DeviceCA" as a salt to the KDF.

The DCK is shared by all authenticated versions of L0 and used to sign a certificate endorsing L0-specific DevID. The DCK acts as a certificate authority local to the device.

Before deploying the device, the manufacturer harvests CSRs for public DCK and DevID keys from the device, and issues certificates for both keys. The firmware on the device exposes certificate signing requests (CSRs) to the certificate authority. Hence <FIG> shows the manufacturer certificate authority <NUM> issuing a certificate for the DCK at operation <NUM> and issuing a certificate for the DevID at operation <NUM>. The operation <NUM> is when the DevID Key certificate authority issues and signs the DevID Key certificate.

The device is deployed at operation <NUM> in <FIG>. On boot the L0 firmware layer <NUM> of the device regenerates a DCK and a DevID at operation <NUM>. The L0 firmware also issues a local certificate for the DevID at operation <NUM>. The local certificate for the DevID is signed by the DCK.

Before updating the L0 firmware the manufacturer issues a firmware update certificate at operation <NUM>. The firmware update certificate captures measurements of the new version of the L0 firmware layer and versions of the L0 firmware layer that are no longer certifiable.

A firmware update of either L0 or L1 is performed as follows.

L1 <NUM> downloads <NUM> new firmware from a host computing device of the peripheral via a set of commands.

L1 writes the new firmware in a download slot in flash memory, sets a FW_UPDATE flag, and issues a reset <NUM>.

The immutable layer <NUM> is designed to check the FW_UPDATE flag when it boots. When the flag is set, the immutable layer <NUM> will first authenticate and then copy the new firmware (only if the authentication succeeds) from the download slot to an active slot, and proceeds with the measured boot sequence of <FIG>.

Thus the firmware update, is activated by the DICE layer at operation <NUM> of <FIG>. After activating the firmware update the DICE <NUM> generates a new CDI from the unique device secret. The new CDI is denoted CDIY at operation <NUM> of <FIG>. The updated L0 firmware layer generates identity and attestation keys specific to the new version of the L0 firmware as follows:.

The L0 firmware derives <NUM> an attestation key (AK) from CDIY and the L0 measurement as follows. The L0 firmware derives <NUM> a device identity key from CDIY as follows. <MAT> <MAT> Which is expressed in words as the device identity public private key pair is computed using the asymmetric key generation function given as argument, the result of the key derivation function applied to the compound device identity and with a label string "Identity" used as a salt to the KDF. The equation for the attestation key is expressed in words as the attestation public-private key pair is computed using the asymmetric key generation function given as argument, the result of the key derivation function applied to the compound device identity and a salt which is a concatenation of a measurement of the L1 firmware and a label string "Attestation".

The L0 firmware generates <NUM> a local certificate for the DevID. The local certificate is sent to the verifier <NUM>. The L0 firmware also sends a certificate for the attestation key derived at operation <NUM> to the verifier <NUM>.

Before transferring control to firmware layer L1, the L0 firmware layer erases the secrets CDI and HDI and copies the public keys, signed certificates and measurements of L0 and L1 to an area of memory accessible to L1.

The verifier <NUM> carries out verification <NUM> using a combination of the firmware update certificate from operation <NUM>, the local certificate for the DevID from operation <NUM> and the original certificates from operations <NUM> and <NUM> to check there is a valid certificate chain in place. The DevID certificate includes the L0 firmware identity i.e. the L0 firmware measurement. To verify that the new DevID certificates are issued by a device specific DCK rooted to the DCK certificate certification authority, a check is made that the new and old firmware measurement in the firmware update certificate match the firmware measurement included in the new and original DevID certificates, and consequently the rest of the certificate chain rooted at the DevID certificate. If the certificate chain is complete the verifier knows that the firmware layer L0 has been updated correctly. If the certificate chain is incomplete the verifier knows to stop using the device as the L0 firmware layer is incorrect.

<FIG> shows an example certificate chain that the verifier <NUM> checks for. The root of the certificate chain is a manufacturer root certificate (referred to as a Root CA). The root has two branches. Using the root CA a DevID Key CA certificate is issued as indicated by one branch to an original device identity key certification authority certificate (DevID Key CA certificate). <FIG> shows a certificate revocation list CRL which is a list of certificates that have been revoked by the issuing certificate authority. The CRL is connected to the DevID Key CA certificate.

The second branch from the root goes to a DCK certificate authority certificate which is the certificate of operation <NUM> of <FIG>. A certificate revocation list CRL for DCK certificates is connected to the DCK certificate authority certificate.

The use of the DCK to sign the local device identity certificate is indicated by the arrow joining the two branches that goes via a box denoting the Device CA Key Certificate. The operations <NUM> and <NUM> both involve the use of the DCK to sign the local device identity certificate. The certificate chain continues with an attestation certificate which is a child of the device identity key certificate which was signed by the DCK. The attestation certificate is the certificate that is signed using the DevID and endorses the Attestation Key derived in the operation <NUM>. The Attestation Key is used by the L1 firmware to sign a Quote. The quote is the leaf certificate (final certificate) issued by the L1 firmware and contains information about the configuration of the accelerator device and the execution of the workload. The existence of attestation key allows to sign quotes without exposing the DevID to the L1 firmware. This way if the L1 is compromised by a bug, it is upgraded into a new version without the bug, and receives a different attestation key (because the L0 derives it from CDI using the L1 measurement).

An L1 firmware update is optionally applied at any point without the need for any additional certification from the manufacturer. When a device boots with a new version of L1 firmware, it generates a new attestation key AK with a signature over the public AK along with a hash of L1 using DevIDpub. Quotes generated by the updated version of L1 firmware are validated as long as a valid certificate endorsing DevIDpub is available.

The immutable firmware layer is used to update a L1 firmware layer which is a firmware layer immediately above the L0 firmware layer. During boot of the computing device after updating the L1 firmware layer, the device generates an attestation private-public key pair and a certificate comprising the public part of the attestation key and the hash of the L1 firmware layer signed using the private part of the device identity key.

Claim 1:
A method of enabling an attestable update of a firmware layer (<NUM>) that provides a unique identity of a computing device (<NUM>) the method comprising:
using an immutable firmware layer (<NUM>) to access a unique device secret (<NUM>);
using the immutable firmware layer (<NUM>) to derive a hardware device identity, HDI, from the unique device secret (<NUM>);
using the immutable firmware layer (<NUM>) to derive a compound device identity, CDI, from a measurement of the firmware layer (<NUM>) and the unique device secret (<NUM>);
making the compound device identity CDI and HDI available to the firmware layer (<NUM>); and
using the firmware layer (<NUM>) to issue a local certificate to endorse a device identity key, derived from the CDI, the local certificate signed by a key derived from the HDI.