Measured Restart of the Microcontroller

Abstract

In various examples, there is a computing device that includes a first microcontroller that includes a first immutable boot loader and a first variable firmware. The first immutable boot loader uses a unique device secret burned into the hardware of the computing device to generate an attestation of authenticity for the first variable firmware. The computing device has a second microcontroller. The second microcontroller has a second variable firmware. There is a second immutable boot loader in the second microcontroller that sends a measurement of the second variable firmware to the first immutable boot loader each time the second microcontroller reboots, allowing the first microcontroller to include the measurement in the attestation of authenticity.

Description

[Background technology]

[0001] In some types of computing devices, the identity of the computing device is known from a unique device secret (UDS), which is a cryptographic public and private key pair or random number that is burned into the computing device's hardware during manufacture. The unique device secret helps enable a hardware root of trust, which allows the computing device to create keys and certificates that attest to specific firmware on the computing device. In an example, a software application that uses the computing device wants to verify that a specific firmware is installed on the computing device for security reasons. The software application wants to receive proof of authenticity that the firmware installed on the computing device is as expected, such as by verifying the firmware's identity using a certificate chain. The computing device hardware can use the unique device secret to generate one or more public and private key pairs and corresponding certificates that the software application uses to verify the firmware on the computing device.

[0002] In situations where there is more than one microcontroller on a computing device, security issues arise regarding how the hardware root of trust is implemented: Only one microcontroller may implement the root of trust, and not all microcontrollers may implement the root of trust.

[0003] The embodiments described below are not limited to implementations that address some or all of the shortcomings of known microcontrollers. Summary of the Invention [Problem to be solved by the invention]

[0004] The following presents a simplified summary of the disclosure in order to provide the reader with a basic understanding. 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. [Means for solving the problem]

[0005] In various examples, there is a computing device that includes a first microcontroller with a first immutable boot loader and a first variable firmware. The first immutable boot loader uses a unique device secret burned into the hardware of the computing device to generate an attestation of authenticity of the first variable firmware. The computing device has a second microcontroller.

[0006] The second microcontroller has a second variable firmware. The second microcontroller has a second immutable boot loader, and the second immutable boot loader transmits a measurement of the second variable firmware to the first immutable boot loader each time the second microcontroller reboots, and the first microcontroller can include the measurement in its attestation of authenticity.

[0007] Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in conjunction with the accompanying drawings.

[0008] The present description will be better understood from the following detailed description read in light of the accompanying drawings. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic diagram of a first trusted computing entity and a processing system. [Diagram 2] FIG. 2 is a schematic diagram of a data center including multiple processing systems. [Diagram 3] FIG. 3 is a schematic diagram of a processing system. [Figure 4] FIG. 4 is a schematic diagram of the processing system of FIG. 3 showing an immutable boot loader and mutable firmware. [Diagram 5] FIG. 5 shows an example of a pulse extender. [Figure 6] FIG. 6 is a flow diagram of the processing in the first microcontroller and the second microcontroller. [Figure 7] FIG. 7 is a flow diagram of processing after returning from a hard reset in both the first microcontroller and the second microcontroller. [Figure 8] FIG. 8 is a flow diagram of another process after returning from a hard reset in both the first and second microcontrollers. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] The detailed description provided below in conjunction with the accompanying drawings is intended as a description of the examples and is not intended to represent the only manner in which the examples may be constructed or utilized. The description sets forth the functions of the examples and the sequence of operations for constructing and deploying the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0011] It is not easy for a data center tenant to receive a proof of authenticity that proves that the mutable firmware of a processing system in the data center (or elsewhere) is as expected. A first microcontroller of a processing system can provide a proof of authenticity of its mutable firmware using the Trusted Computing Group (TCG) Device Identifier Composition Engine (DICE) standard and the Robust Internet of Things (RIoT) protocol scheme to implement a hardware root of trust. However, a second microcontroller in the processing system does not implement a hardware root of trust because only one entity per device can implement a hardware root of trust. Thus, there is a security risk because a malicious party may be able to tamper with or replace the mutable firmware on the second microcontroller. It is difficult to provide a proof of authenticity that proves that the mutable firmware on the second microcontroller is as expected. As described in more detail below, the inventors have devised an approach to generate measurements of the mutable firmware on the second microcontroller and make them available to a verifier in a secure and efficient manner. The verifier can use this measurement to verify that the variable firmware on the second microcontroller is as expected.

[0012] FIG. 1 illustrates three high-level entities: a first trusted computing entity 100 , an untrusted storage 108 , and a processing system 112 .

[0013] The first trusted computing entity 100, in some examples, has access to sensitive code 102 and sensitive data 104 controlled by a tenant and processed in a processing system 112. The first trusted computing entity 100 has an encryption device 106 that encrypts the sensitive code 102 and sensitive data 104 before transferring them to the processing system 112 via a storage 108. The first trusted computing entity 100 has a verifier 124 that receives one or more authenticity certificates and measurements from the processing system 112 to verify that the mutable firmware in the processing system 112 is as expected by the tenant.

[0014] The storage 108 is any storage that communicates with the first trusted computing entity 100 via a communications network or link and with the processing system 112 via a communications network or link. The storage 108 stores at least encrypted code and / or data from the first trusted computing entity 100. In some examples, the storage 108 is a memory of a host computing device and the processing system 112 is a peripheral device of the host computing device. However, it is not required that the storage 108 is on the host device. The storage 108 is any storage that is external to the processing system 112.

[0015] The processing system 112 may be a single processor as shown in FIG. 1 or may comprise multiple such processors connected to each other. The processing system may create a trusted execution environment for processing sensitive data using sensitive code. Each processor in the processing system 112 has one or more processor units 114 for processing sensitive data in a parallel manner using sensitive code. The processor units 114 are processors or other computational elements described in more detail below. The processing system 112 has cryptographic functionality that allows encryption and decryption of information. A secure microcontroller unit (SMCU) 120 of the processing system 112 controls the processing to create the trusted execution environment and various other functions. The SMCU implements a hardware root of trust. The microcontroller unit (MCU) 122 of the processing system has at least the functionality to boot the processor.

[0016] Both the processing system 112 and the encryption unit 106 in the first trusted computing entity are configured to use an encryption protocol to encrypt blocks of sensitive code and / or data for transfer via the untrusted external storage 108. Any encryption protocol that uses a key and an initialization vector to protect sensitive information can be used. Individual blocks are encrypted using a pair with an initialization vector and a key.

[0017] 2 is a schematic diagram of a data center 300 with multiple processing systems 112. In an example, multiple processing systems 112 are deployed in a data center 200, where the processing systems 112 are interconnected using a communication network in the data center 200, which is not shown in FIG. 2 for clarity. A first tenant 202 with a computing device has a secure store 206 of sensitive data and / or code and a verifier 124. The first tenant 202 communicates with the data center 200. The first tenant 202 can transfer sensitive data and / or code to the processing system 112 so that the sensitive data is processed. In an example, the sensitive code is a machine learning model and the sensitive data is training data. The first tenant 202 can use the verifier 124 to verify that the sensitive code is installed in one or more of the processing systems. The verification comprises receiving authenticity certificates and / or measurements from the processing systems 112 to verify that the mutable firmware in one or more of the processing systems 112 is as expected by the first tenant 202.

[0018] In some examples, there is a second tenant 204 with computing devices in communication with the data center 200. The second tenant 204 has a secure store 208 of sensitive code and / or data. The second tenant 204 can copy the sensitive code and data to one or more of the same processing systems 112 as the first tenant 202 in the data center 200. Resource isolation mechanisms in the processing systems 112 can be used to maintain security for the individual tenants. The second tenant 204 also has a verifier 124.

[0019] Figure 2 illustrates a data center context, however, the processing system 112 of Figure 1 may also be used in a stand-alone context or other types of deployments.

[0020] 3 is a schematic diagram of a processing system 112 that includes a first microcontroller, in the example SMCU 120, a second microcontroller, in the example MCU 122, and multiple processors 114, each having multiple processing units. The processors 114 can pass encrypted data to and from the external storage 108 using a peripheral component interconnect complex 368 or equivalent.

[0021] The SMCU 120 implements the hardware root of trust using a unique device secret burned into the hardware of the processing system 112. The unique device secret is not visible in FIG. 3. The unique device secret is unique among devices created by the manufacturer and is an encrypted public and private key pair or a random number. The unique device secret helps enable computing devices to create keys and certificates that attest to specific firmware on the processing system. In an example, the SMCU 120 uses a method for attesting mutable firmware in the SMCU 120 according to the Trusted Computing Group (TCG) Device Identifier Composition Engine (DICE) standard and the RIoT protocol scheme. DICE is a standardized method for creating private keys that devices use for authenticity proofing, attestation, data encryption, and other purposes. DICE is typically implemented in hardware or read-only memory (ROM) based firmware. The Robust Internet of Things (RIoT) is a protocol scheme for using DICE-derived secrets. RIoT includes a protocol for device authenticity attestation, which provides secure reporting of the firmware booted on the microcontroller.

[0022] In the example, the SMCU 120 manages confidential computing tasks that run on the processors 114, 374. This computing task gives each processor 114, 374 an identity based on a unique device secret. This computing task creates and manages a trusted execution environment on the processors 114, 374, measures processor configurations, generates quotes, and deploys keys for online encryption and decryption of code and data.

[0023] The MCU 122 has at least the functionality for stopping the processors 114, 374. The MCU 122 communicates with the processors 114, 374 via a connection 370.

[0024] A communication channel exists between the SMCU 120 and the MCU 122, as indicated by the arrows 358, 356 in FIG. 3. In the example, the SMCU 120 sends messages to the MCU 122 via a first interface 358 and receives messages from the MCU via a second interface 356. The communication channel between the SMCU 120 and the MCU 122 comprises a ready flag controlled by the SMCU 120. When the SMCU 120 is ready to receive a communication, it sets the ready flag high. If it is not ready, the SMCU 120 sets the ready flag low to indicate that it is not ready to receive a communication. The MCU 122 can observe the status of the ready flag to know whether the SMCU 120 is ready to receive a communication or not.

[0025] A processing system reset pin 364 may be asserted (driven low) to trigger a processing system reset. In an example where the processing system 112 is a peripheral device, the host computing device may assert (drive low) the open-drain reset pin 364. The SMCU 120 has a reset pin 352.

[0026] When the SMCU 120 receives an electrical pulse longer than a threshold duration at its reset pin 352, the SMCU 120 undergoes a hard reset. The MCU 122 also has a reset pin 376.

[0027] When the MCU 122 receives an electrical pulse at its reset pin 376 that is longer than the threshold duration, the MCU 122 undergoes a hard reset. The threshold duration is specified by the manufacturers of the SMCU 120 and MCU 122. Typically, the manufacturer specifies a range of durations for the electrical pulse that will trigger a hard reset. There is no single fixed value for either threshold due to variations introduced during manufacturing.

[0028] The reset pins 352, 376 of the SMCU 120 and MCU 122 are coupled together with a processing system reset pin 364 as shown in Figure 3. A general purpose input / output pin (GPIO) 360 of the MCU 122 is connected to the electrical connection coupling the SMCU 120 and MCU 122 through a pulse stretcher 354. The pulse stretcher 354 functions to stretch the pulse sent by the GPIO 360 onto the electrical connection as will be described in more detail with reference to Figure 5.

[0029] As described with reference to FIG. 3, the reset pin 352 of the SMCU 120 is electrically coupled to the reset pin 376 of the MCU 122. The MCU 122 has an output connected to the electrical coupling, and the MCU 122 can send an electrical pulse from the output along the electrical coupling to trigger a hard reset of itself and of the SMCU. The electrical coupling comprises a pulse extender 354 that extends the pulse sent by the MCU 122 to the coupling. The pulse extender 354 extends the pulse to a length of time that is longer than the maximum length of time to reset the SMCU 120. Any suitable commercially available pulse extender can be used. Without the pulse extender 354, there is a risk that the MCU 122 will reset and clear the GPIO 360 before the threshold duration at which the SMCU 120 will undergo a hard reset.

[0030] 4 illustrates an overview and schematic diagram of at least a portion of the firmware on the microcontrollers of the processing system 112 of FIG. 3. The SMCU 120 has a firmware layer that is an immutable boot loader 404, and also has a mutable firmware 402. The second microcontroller, the MCU 122, has an immutable firmware layer that is an immutable boot loader 412, and also has a mutable firmware 410. As explained above, it is desirable for the MCU 122 to be able to provide measurements of the mutable firmware 410 in the MCU in a secure manner so that the verifier 124 can verify that the mutable firmware 410 in the MCU is as expected. Doing so provides a technique to prevent tampering or replacement of the mutable firmware 410 by a malicious party.

[0031] As described in more detail below, the inventors have devised an approach whereby measurements of the mutable firmware 410 are taken at the MCU 122 and transmitted in a secure manner to the immutable boot loader 404 of the SMCU 120. The immutable boot loader 404 of the SMCU 120 and the immutable boot loader 412 of the MCU 122 are trusted because they cannot be modified.

[0032] The SMCU 120 can make measurements of the MCU alterable firmware 410 available to the verifier 124 so that the verifier 124 can verify that the MCU alterable firmware 410 is as the verifier expects it to be. Because the SMCU 120 has access to a unique device secret and implements a hardware root of trust, it can provide the verifier with attestation of authenticity of its alterable firmware 402 according to the DICE and RiOT specifications. In some examples, the SMCU 120 computes the attestation of authenticity in the form of a report that includes firmware measurements of the SMCU 120 and the MCU 122. Thus, the attestation of authenticity covers both the SMCU 120 and the MCU 122. The verifier verifies the attestation of authenticity and the measurements using one or more certificates from the certification authority 416 of the manufacturer of the processing system 112. The attestation of authenticity is computed by the SMCU 120 by building a chain of certificates used for attestation of authenticity. In the present technique, one of these certificates contains measurements of the variable firmware 402, 410 on the SMCU 120 and MCU 122. These certificates are signed using a key rooted in a unique device secret.

[0033] The inventors have recognized that there are security risks associated with sending measurements of the MCU mutable firmware 410 to the SMCU 120. Because the measurements are taken at a specific point in time, it is possible that the measurements are generated and sent to the correct firmware, but some time later, a malicious party may tamper with or replace the firmware without the SMCU 120 realizing. To thwart these types of scenarios, the inventors have devised a technique whereby the MCU 122 sends a measurement of the second mutable firmware to the first immutable boot loader every time the MCU 122 reboots. Since changing the mutable firmware requires a reboot of the MCU 122, the SMCU 120 will know about the mutable firmware associated with the reboot. If a malicious party changes the mutable firmware 410 in the MCU 122, the MCU 122 will need to reboot and the SMCU 120 will receive the measurement of the mutable firmware 410.

[0034] The inventors have recognized that having the MCU 122 send measurements every time the MCU 122 reboots may address some, but not all, of the security issues. In particular, there is a potential problem if the MCU 122 sends measurements even when it has not rebooted. To overcome this, the SMCU firmware is configured to only accept measurement messages that are the first messages the SMCU 120 receives from the MCU 122 after the SMCU 120 reboots.

[0035] In an example, the SMCU firmware that runs after the immutable bootloader (see 404 in FIG. 4) does not accept firmware measurement messages sent by the MCU firmware layer. In this way, a malicious or compromised MCU firmware cannot masquerade as the MCU bootloader and send malicious measurements.

[0036] The inventors recognized that there is a potential problem with the freshness of the MCU configurable firmware measurements. To address this, the SMCU reset is coupled to the MCU reset such that if a hard reset of the MCU occurs, a hard reset of the SMCU is triggered. In this way, it becomes very difficult for a malicious party to intercept and tamper with the measurements, a so-called "man-in-the-middle attack" to occur. In the case of a soft reset of the MCU, the MCU bootloader triggers a hard reset, which adds additional security by causing a hard reset of both the MCU and the SMCU. A soft reset is a reset that is caused by software, such as a brownout reset, a watchdog timeout, receiving a command from the SMCU to reset the MCU, or software detecting a power anomaly in the MCU or corruption occurring. A hard reset occurs when there is a processing system reset signal on the coupling between the reset pins of the MCU and the SMCU.

[0037] In the example described with reference to FIG. 5, the pulse stretcher 354 comprises an open-drain buffer 500, a resistor 502, and a capacitor 504. The pulse stretcher 354 of FIG. 5 is particularly low-cost and efficient. In the example of FIG. 5, the MCU 122 has a reset pin 376 coupled to the reset pin 352 of the SMCU 120. The MCU 122 also has an output 360 (called a GPIO) connected to the coupling between the reset pins via the pulse stretcher 354. The capacitor 504 is connected to ground and acts as a bucket to collect the charge flowing through the resistor 502. The open-drain buffer is unidirectional, allowing voltage to pass but not current to pass from right to left in FIG. 5 from the MCU 122 to the coupling between the reset pins. The output of the open-drain buffer remains low until the voltage of the capacitor 504 charges above its input logic switching threshold via the resistor 502. Capacitor 504 , resistor 502 and open-drain buffer 500 work together to lengthen the electrical pulse emitted by MCU 122 on output 360 .

[0038] The profile of the extended pulse is illustrated in FIG. 5 at 506, where voltage is on the y-axis and time is on the x-axis. The voltage starts high and is driven low in a step change by output 360. The voltage remains driven low until output 360 stops driving low, resetting the MCU and allowing the voltage to gradually return to its original high level. The reason for the gradual return to the original high level (rather than a step change) is because resistor 502 takes time to charge capacitor 504. The result from the perspective of the SMCU reset pin 352 is an extended pulse, as shown in profile 508 in FIG. 5.

[0039] The pulse extender 354 extends the pulse by a time length 510 so that the pulse is long enough to reset the SMCU, so that both the MCU and the SMCU are reset. In this way, the MCU cannot be rebooted unless the SMCU is rebooted. Thus, the SMCU bootloader is ready to receive a variable firmware measurement from the MCU bootloader. Figure 6 is a flow diagram of the processing in SMCU 120 and MCU 122. SMCU 120 is represented in Figure 6 by a vertical dotted line, and MCU 122 is also represented by a vertical dotted line. Operations are illustrated by the vertical dotted lines. The relative vertical position of the operations represents the chronological order.

[0040] The SMCU 120 is running (600) and the MCU 122 is also operating (606). The MCU undergoes a reset (608) as a result of one or more criteria being met. Since the reset is a soft reset (608), the criteria are the same as for a soft reset. A non-exhaustive list of criteria that trigger a soft reset was given earlier in this document, but is repeated here for ease of reference: a reset request is received from the SMCU, a watchdog timeout occurs, a brownout occurs, a power failure is detected, or damage occurs. When the MCU 122 resets (608), its boot loader executes and checks (610) whether the reset is a hard or soft reset. If the check (610) determines that the reset is a soft reset (612), the MCU 122 sends a pulse to the pulse extender (614). The pulse stretcher triggers a hard reset of the MCU (616) and a hard reset of the SMCU 120 (602) substantially simultaneously, as shown in Figure 6. As a result of the hard reset of the MCU 122, the MCU boot loader performs a boot process (618), as described in more detail with reference to Figure 7 or Figure 8. As a result of the hard reset of the SMCU 120, the SMCU boot loader performs a boot of the SMCU (604). If the check (610) determines that the reset was a hard reset, processing moves directly to action (618), where the MCU boot loader performs a boot process.

[0041] As can be seen from FIG. 6, the MCU 122 performs a hard reset even if a soft reset is indicated.

[0042] As a result, when the MCU reboots, the SMCU also reboots, preventing the possibility of new MCU firmware being booted without the SMCU's knowledge.

[0043] As shown with reference to Figure 7, on the left side, exemplary operations in the SMCU are given when the SMCU comes out of hard reset. On the right side, exemplary operations in the MCU are given when the MCU comes out of hard reset. The relative vertical position of the operations with respect to Figure 6 roughly indicates the chronological order. The operations on the left side are performed by the immutable boot loader in the SMCU and the operations on the right side are performed by the immutable boot loader in the MCU.

[0044] The SMCU comes out of hard reset (700). The SMCU immutable boot loader initializes an interface to the MCU (702), such as interface 356 in Figure 3. The SMCU immutable boot loader sets a ready flag high to indicate that it is ready to receive measurements from the MCU via interface 356 (704).

[0045] Meanwhile, the MCU boot begins (712). The MCU invariant boot loader initializes (714) the MCU interface to the SMCU, which is interface 356.

[0046] The MCU immutable bootloader then obtains measurements of the mutable firmware in the MCU.

[0047] First, the MCU immutable boot loader authenticates the MCU mutable firmware as follows: The signature added to the firmware package containing the MCU mutable firmware is a signature over a hash of the firmware package header. The MCU immutable boot loader calculates the hash of the mutable firmware header. To ensure that the mutable firmware executed in the MCU is signed by a trusted organization, the MCU immutable boot loader verifies the signature over the hash of the mutable firmware header using the public firmware signing key. If the verification is successful, the hash of the mutable firmware binary is calculated (716). At this point, it is unknown whether the firmware package header matches the firmware package binary. To verify that the firmware package header matches the firmware package binary, the MCU immutable boot loader verifies (718) that the hash of the MCU mutable firmware binary (716) matches the hash stored in the firmware header (the hash stored in the firmware header is the hash of the MCU firmware already authenticated earlier in the process described herein). If the match is successful, the process proceeds to verification (720). If the match is unsuccessful, the process aborts.

[0048] In operation 720, the MCU immutable boot loader checks whether the ready flag is set high in the SMCU. If it is not, the MCU immutable boot loader waits a predefined period of time to allow time for the SMCU to set the flag high and issues a hard reset (722) by sending a pulse to the pulse extender (732), which causes both the MCU and the SMCU to reset (734), and processing returns to operations 700, 712.

[0049] If the ready flag is set high in operation 720, the MCU immutable boot loader transfers (724) the measurement to the SMCU via interface 356. The measurement is a hash of the mutable firmware binary.

[0050] After transferring the measurements, the MCU immutable bootloader checks whether the ready flag has been set low by the SMCU (726). If not, the MCU waits a predefined period (to allow time for the SMCU to set the flag low) and then issues a hard reset (722). If the ready flag is set low, the MCU immutable bootloader applies the runtime security configuration (728) and transfers control to the MCU firmware (730).

[0051] 7, a hash of the MCU firmware is a measurement of the MCU alterable firmware and is transferred to the SMCU. In some examples, additional information, such as one or more of a hash of the MCU firmware signature public key, serial numbers of the MCU, processor, and processing unit card, a signature of the MCU alterable firmware, and a security version number of the MCU alterable firmware, is transferred (in transfer operation 724) along with the hash of the alterable firmware binary.

[0052] In an example, the size of the information to be transferred is known in advance to both the MCU and the SMCU so that both know when the information transfer is complete.

[0053] Returning to the left side of FIG. 7, once the SMCU receives the measurement of the variable firmware in the MCU (706), it sets a ready flag low (708) and proceeds with its own boot sequence (710).

[0054] The boot sequence of the SMCU comprises sending an authenticity certificate to the verifier 124. The authenticity certificate includes, among other attributes, measurements of the variable SMCU firmware (according to the DICE and RIoT protocols) as well as measurements of the variable firmware in the MCU. Using the measurements, the verifier can verify that the variable firmware in the MCU and SMCU are as expected using conventional verification methods.

[0055] If the SMCU wishes to reset itself, it sends a message to the MCU requesting a hard reset of the MCU (which also triggers a hard reset of the SMCU). In this way, the MCU quiesces from interfacing with the processor and both the SMCU and MCU reset and run the immutable boot loader as described with reference to FIG. 7.

[0056] As shown with reference to Figure 7, there are at least three scenarios for the SMCU: In the first scenario, the SMCU signals that it is ready to receive measurements from the MCU (sets the ready flag high at 704), and the SMCU actually receives the measurements (706).

[0057] In the second scenario, the SMCU signals that it is not ready to receive measurements. In this case, a ready flag is not received at the MCU at decision point 720 and the MCU issues a hard reset (722).

[0058] In a third scenario, the SMCU signals that it is ready to receive measurements (setting the ready flag high in 704) but does not receive measurements from the MCU. In this situation, the ready flag remains high (operation 704), the MCU check 726 returns "no", and the MCU will issue a hard reset (722).

[0059] As shown with reference to Figure 8, on the left side, another exemplary process in the SMCU is provided when the SMCU comes out of hard reset 734. On the right side, another exemplary process in the MCU is provided when the MCU comes out of hard reset 734. With respect to Figure 6, the relative vertical position of the operations roughly indicates the chronological order. The operations on the left side are performed by the immutable boot loader of the SMCU and the operations on the right side are performed by the immutable boot loader of the MCU.

[0060] The SMCU returns from hard reset (700). The SMCU immutable boot loader sets the SMCU valid flag to false (800). The SMCU immutable boot loader initializes an interface to the MCU (702), such as interface 356 in FIG.

[0061] The SMCU immutable bootloader sets the ready flag high to indicate that it is ready to receive measurements from the MCU over interface 356 (704).

[0062] Meanwhile, the MCU boot begins (712). The MCU immutable boot loader initializes (714) the MCU interface to the SMCU, which is interface 356 in FIG.

[0063] Next, the MCU immutable boot loader obtains measurements of the mutable firmware in the MCU. First, the MCU immutable boot loader authenticates the MCU mutable firmware as follows: The signature added to the firmware package containing the MCU mutable firmware is a signature over a hash of the firmware package header. The MCU immutable boot loader calculates the hash of the mutable firmware header. To ensure that the mutable firmware executed in the MCU is signed by a trusted organization, the MCU immutable boot loader verifies the signature over the hash of the mutable firmware header using the public firmware signing key. If the verification is successful, the hash of the mutable firmware binary is calculated (716). At this point, it is unknown whether the firmware package header matches the firmware package binary. To verify that the firmware package header matches the firmware package binary, the MCU immutable boot loader verifies (718) that the hash of the MCU mutable firmware binary matches the hash stored in the firmware header (the hash stored in the firmware header is the hash of the MCU firmware already authenticated earlier in the process described herein). If the match is successful, the process proceeds to verification (720). If the match is unsuccessful, the process aborts.

[0064] In operation 720, the MCU immutable boot loader checks whether the ready flag in the SMCU is set high within time Y. If not, the MCU immutable boot loader proceeds to operation 728 and applies the runtime security configuration.

[0065] In operation 720, if the ready flag is set high within time Y, the MCU immutable boot loader transfers (724) the measurement to the SMCU via the interface initialized in operation 714. The measurement is a hash of the mutable firmware binary. Time Y is sufficient for the SMCU to perform operations 800-704.

[0066] After transferring the measurements, the MCU immutable boot loader applies (728) the runtime security configuration and transfers (730) control to the MCU firmware.

[0067] After operation 702, the SMCU immutable boot loader checks (802) whether it has received MCU measurements within a specified time period. The time period specified in operation 802 may be any time period long enough for the MCU to perform operations up to operation 724. If the MCU measurements are not received within the specified time period, it proceeds to operation 710 and proceeds with its own boot sequence so that the SMCU can boot.

[0068] If the check at operation 802 reveals that the measurement was received in time, then the SMCU immutable boot loader sets the SMCU valid flag to true at operation 804. The SMCU immutable boot loader then proceeds to operation 710 and proceeds with its own boot sequence.

[0069] 8, the hash of the MCU firmware is a measurement of the MCU alterable firmware and is transferred to the SMCU. In some examples, additional information, such as one or more of the hash of the MCU firmware signature public key, the serial numbers of the MCU, the processor, and the processing unit card, the signature of the MCU alterable firmware, and the security version number of the MCU alterable firmware, is transferred (in transfer operation 724) along with the hash of the alterable firmware binary.

[0070] In an example, the size of the information to be transferred is known in advance to both the MCU and the SMCU so that both know when the information transfer is complete.

[0071] With reference to FIG. 7, the boot sequence of the SMCU comprises sending a certificate of authenticity to the verifier 124. The certificate of authenticity includes, among other attributes, measurements of the variable SMCU firmware (according to the DICE and RIoT protocols) as well as measurements of the variable firmware in the MCU if received in time. In an example, the certificate of authenticity includes an SMCU valid flag so that the verifier knows if the boot handshake was successful. In another example, the SMCU valid flag is not included in the certificate of authenticity and is omitted entirely from the method of FIG. 8 since the verifier will not verify blank measurements anyway. Using the measurements, the verifier can verify that the variable firmware in the MCU and SMCU are as expected using conventional verification methods.

[0072] With respect to Figure 7, in the embodiment of Figure 8, when the SMCU wishes to reset itself, it sends a message to the MCU requesting a hard reset of the MCU (which also triggers a hard reset of the SMCU). In this way, the MCU quiesces from interfacing with the processor and both the SMCU and MCU reset and run the immutable boot loader.

[0073] As shown with reference to Figure 8, there are at least three scenarios for the SMCU. In the first scenario, the SMCU signals that it is ready to receive measurements from the MCU (sets the ready flag high at 704) and the SMCU actually receives the measurements (706). In this case, the SMCU valid flag is set to true, allowing safe operation to continue.

[0074] In a second scenario, the SMCU signals that it is not ready to receive measurements. In this case, a ready flag is not received at the MCU at decision point 720, and the MCU applies 728 the runtime security configuration. Because the SMCU does not have the SMCU enabled flag set, it can act accordingly to avoid setting secure operation.

[0075] In a third scenario, the SMCU signals that it is ready to receive measurements (sets the ready flag high in 704) but does not receive measurements from the MCU within the specified time in check 802. In this situation, the SMCU proceeds with its own boot sequence in operation 710. Because the SMCU does not have the SMCU valid flag set, it can act accordingly to avoid setting safe operation.

[0076] Alternatively or in addition to other examples described herein, examples include any combination of the following:

[0077] Item A. A computing device, comprising: a first microcontroller having a first immutable boot loader and a first mutable firmware, the first immutable boot loader using a unique device secret burned into the hardware of the computing device to generate an attestation of authenticity of the first mutable firmware; a second microcontroller; a second variable firmware in a second microcontroller; and and a second immutable boot loader in the second microcontroller that sends a measurement of the second variable firmware to the first immutable boot loader each time the second microcontroller reboots, enabling the first microcontroller to include the measurement in the authenticity certificate.

[0078] Item B. The computing device of item A, wherein the reset pin of the first microcontroller is electrically coupled to the reset pin of the second microcontroller.

[0079] Item C. The computing device of item B, wherein the second microcontroller has an output connected to the electrical coupling, and wherein the second microcontroller can send an electrical pulse from the output along the electrical coupling to trigger a hard reset of itself and of the first microcontroller.

[0080] Item D. The computing device of item C, wherein the electrical coupling comprises a pulse extender that extends a pulse sent to the coupling by the second microcontroller.

[0081] Item E. The computing device of item D, wherein the pulse stretcher comprises an open-drain buffer, a resistor, and a capacitor.

[0082] Item F. The computing device of any preceding item, wherein the second immutable boot loader triggers a hard reset of both the first microcontroller and the second microcontroller in response to a soft reset in the second microcontroller.

[0083] Item G. The computing device of any preceding item, wherein the first microcontroller, in response to a reset of the first microcontroller being requested, sends a message to the second boot loader requesting a hard reset of both the first microcontroller and the second microcontroller.

[0084] Item H. The computing device of any preceding item, wherein the first microcontroller, upon returning from a hard reset, initializes an interface to the second microcontroller, sets a ready flag to indicate availability, waits to receive measurements from the second microcontroller via the initialized interface, and resets the ready flag to indicate receipt of the measurements.

[0085] Item I. The computing device of any preceding item, wherein the second microcontroller, in response to returning from a hard reset, initializes an interface to the first microcontroller, calculates measurements of the second variable firmware, and, in response to a ready flag of the first microcontroller indicating availability, transfers the measurements to the first microcontroller via the initialized interface.

[0086] Item J. The computing device of item H, wherein the first microcontroller executes a boot sequence comprising making available to a remote verifier an attestation of authenticity of the second variable firmware, the attestation of authenticity being calculated using at least measurements from the second microcontroller and signed by a key derived from a unique device secret.

[0087] Item K. The computing device of item J, wherein the second microcontroller applies the runtime security configuration after transferring the measurements to the first microcontroller in response to a ready flag of the first microcontroller indicating receipt of the measurements.

[0088] Item L. The computing device of any preceding item, wherein the second microcontroller, in response to returning from hard reset, initializes an interface to the first microcontroller, calculates a second variable firmware measurement, and, in response to a ready flag of the first microcontroller indicating no response after a predefined period of time, issues a hard reset command to trigger a hard reset of both the first microcontroller and the second microcontroller or continues the boot sequence.

[0089] Item M. The computing device of any preceding item, wherein the second microcontroller, in response to transferring the second variable firmware measurement to the first microcontroller, checks a ready flag of the first microcontroller, and, in response to the ready flag indicating that the first microcontroller is ready to receive the measurement and has not received the measurement, issues a hard reset command to trigger a hard reset of both the first microcontroller and the second microcontroller.

[0090] Item N. The computing device of item A, wherein the first microcontroller, in response to failing to receive the measurement from the second microcontroller within the time, proceeds with the boot sequence, and, in response to receiving the measurement within the time, sets the flag to true.

[0091] Item O. A method in a computing device, comprising: using a first immutable boot loader in a first microcontroller to generate an attestation of authenticity for a first mutable firmware, the first mutable firmware being in the first microcontroller, the attestation of authenticity being signed by a key derived from a unique device secret burned into the hardware of the computing device; and using a second immutable boot loader in the second microcontroller to send a measurement of the second variable firmware in the second microcontroller to the first immutable boot loader each time the second microcontroller of the computing device reboots, such that the first microcontroller can include the measurement in the authenticity certificate.

[0092] Item P. The method of item N, comprising sending an electrical pulse from an output of the second microcontroller along an electrical coupling to a reset pin of the first microcontroller and to a reset pin of the second microcontroller to trigger a hard reset of both the first microcontroller and the second microcontroller prior to transmitting the measurement value.

[0093] Item Q. The method of item O or item P comprising extending the pulse to be longer than a reset threshold duration of the first microcontroller.

[0094] Item R. The method of any of items N through Q, comprising triggering a hard reset of both the first microcontroller and the second microcontroller in response to a soft reset in the second microcontroller.

[0095] Item S. The method of any of items N through Q, comprising, in response to a reset of the first microcontroller being requested at the first microcontroller, sending a message to the second boot loader requesting a hard reset of both the first microcontroller and the second microcontroller.

[0096] Item T. A peripheral computing device, comprising: At least one processor; a first microcontroller having a first immutable boot loader and a first mutable firmware, the first immutable boot loader using a unique device secret burned into the hardware of the computing device to generate an attestation of authenticity of the first mutable firmware; a second microcontroller for managing the processor; a second variable firmware in a second microcontroller; and and a second immutable boot loader in the second microcontroller that sends measurements of the second variable firmware to the first immutable boot loader each time the second microcontroller reboots, and the peripheral computing device makes the authenticity certificate and the measurements available to a host of the peripheral computing device for access by the verifier.

[0097] As will be apparent to one skilled in the art, any ranges or device values ​​given herein can be expanded or modified without losing the effect sought.

[0098] The system described for implementing the embodiments of the present disclosure comprises data processing equipment and functions that may be provided by one or more data processors. The data processor may be of any type suitable for the local technology environment and may include, as non-limiting examples, one or more of the following: a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and a processor based on a multi-core processor architecture. Data processing may be distributed among several data processing modules.

[0099] At least some aspects of the embodiments described herein with reference to the drawings comprise computer processes executed in a processing system or processor, but the invention also extends to computer programs, in particular computer programs on or in a carrier adapted for carrying out the invention. The programs may be non-transitory source code, object code, code intermediate source and object code, such as partially compiled form, or any other non-transitory form suitable for use in carrying out the processes according to the invention. The carrier may be any entity or device capable of carrying a program. For example, the carrier may comprise a storage medium, such as a solid state drive (SSD) or other semiconductor-based RAM, a ROM, e.g. a CD ROM or semiconductor ROM, a magnetic recording medium, e.g. a floppy disk or hard disk, an optical memory device in general, etc.

[0100] The actions of the methods described herein may be performed in any suitable order, or simultaneously as appropriate. In addition, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the above-described examples may be combined with aspects of any of the other described examples to form further examples without losing the claimed effect.

[0101] The term "comprising" is used herein to mean including specified method blocks or elements, but such blocks or elements do not constitute an exclusive list and the method or apparatus may include additional blocks or elements.

[0102] It will be understood that the above description is given by way of example only, and that various modifications may be made by those skilled in the art. The above specification, examples, and data provide a complete description of the structure and use of the exemplary embodiments. Although various embodiments have been described above with a degree of particularity, or with reference to one or more individual embodiments, those skilled in the art will be able to make many modifications to the disclosed embodiments without departing from the scope of the present specification.

Claims

1. A computing device, a first microcontroller disposed in the computing device and comprising a first immutable bootloader and a first variable firmware; a second microcontroller disposed in the computing device and comprising a second immutable bootloader and a second variable firmware, wherein the first immutable bootloader stores a genuine proof of the first variable firmware, including a unique device secret burned into the hardware of the computing device and a measurement value of the second variable firmware from the second immutable bootloader; the first immutable bootloader accepts the measurement value of the second variable firmware when the measurement value is included in an initial message received from the second microcontroller after the first microcontroller restarts. A computing device.

2. The computing device according to claim 1, wherein a reset pin of the first microcontroller is electrically coupled to a reset pin of the second microcontroller. A computing device.

3. The computing device according to claim 1, wherein the second microcontroller has an output connected to an electrical connection between the first microcontroller and the second microcontroller, and the second microcontroller can trigger a hard reset of the second microcontroller and the first microcontroller by sending an electrical pulse from the output along the electrical connection. A computing device.

4. The computing device according to claim 1, wherein the electrical connection between the first microcontroller and the second microcontroller includes a pulse extender that extends a pulse transmitted to the electrical connection by the second microcontroller. A computing device.

5. The computing device according to claim 4, wherein the pulse extender comprises an open drain buffer, a resistor, and a capacitor. A computing device.

6. The computing device according to claim 1, The second immutable bootloader is a computing device that triggers a hard reset of both the first microcontroller and the second microcontroller in response to a soft reset in the second microcontroller.

7. The computing device according to claim 1, wherein the first microcontroller transmits a message requesting a hard reset of both the first microcontroller and the second microcontroller to the second immutable bootloader in response to a request for reset of the first microcontroller.

8. The computing device according to claim 1, wherein the first microcontroller initializes an interface to the second microcontroller in response to a return from a hard reset, sets a ready flag to indicate availability, waits to receive a measurement value from the second microcontroller via the initialized interface, and resets the ready flag to indicate receipt of the measurement value.

9. The computing device according to claim 1, wherein the second microcontroller initializes an interface to the first microcontroller in response to a return from a hard reset, calculates a measurement value of the second variable firmware, and transfers the measurement value to the first microcontroller via the initialized interface in response to the ready flag of the first microcontroller indicating availability.

10. The computing device according to claim 9, wherein the first microcontroller executes a boot sequence including making a genuine proof of the second variable firmware available to a remote verifier, the genuine proof being calculated using at least the measurement value of the second microcontroller from the second microcontroller and signed using a key derived from the unique device secret.

11. The computing device according to claim 10, The second microcontroller transfers the measured value of the second microcontroller to the first microcontroller, and then applies a runtime security configuration in response to the readiness completion flag of the first microcontroller indicating reception of the measured value. A computing device.

12. The computing device according to claim 1, wherein the second microcontroller initializes an interface to the first microcontroller in response to a return from a hard reset, calculates a measured value of the second variable firmware, and after a predefined period, issues a hard reset command to trigger a hard reset of both the first microcontroller and the second microcontroller, or continues the boot sequence, in response to the readiness completion flag of the first microcontroller indicating no response. A computing device.

13. The computing device according to claim 1, wherein the second microcontroller checks the readiness completion flag of the first microcontroller in response to transferring the measured value of the second variable firmware to the first microcontroller, and issues a hard reset command to trigger a hard reset of both the first microcontroller and the second microcontroller, in response to the readiness completion flag indicating that the first microcontroller is ready to receive the measured value but has not received the measured value. A computing device.

14. The computing device according to claim 1, wherein the first microcontroller proceeds with the boot sequence if it fails to receive the measured value from the second microcontroller within a predetermined time, and sets the flag to true if it receives the measured value within the predetermined time. A computing device.

15. A method in a computing device, wherein In a first microcontroller disposed in the computing device, generating a proof of authenticity of first variable firmware using a first immutable bootloader, wherein the first variable firmware is in the first microcontroller, and the proof of authenticity includes a unique device secret burned into the hardware of the computing device; Each time the second microcontroller disposed in the computing device restarts, using a second immutable bootloader in the second microcontroller to transmit a measurement of the second variable firmware in the second microcontroller to the first immutable bootloader, and enabling the first microcontroller to include the measurement in the proof of authenticity; The method by which the first immutable bootloader accepts the measurement of the second variable firmware when the measurement is included in an initial message received from the second microcontroller after the first microcontroller restarts.

16. The method according to claim 15, including extending an electrical pulse from the second microcontroller to a reset pin of the first microcontroller to be longer than a reset threshold time of the first microcontroller.

17. The method according to claim 15, including triggering a hard reset of both the first microcontroller and the second microcontroller in response to a soft reset in the second microcontroller.

18. A peripheral computing device, comprising: at least one processor; a first microcontroller disposed in the peripheral computing device and including a first immutable bootloader and first variable firmware; a second microcontroller disposed in the peripheral computing device and including a second immutable bootloader and second variable firmware. The first immutable bootloader stores the authenticity proof of the first variable firmware, including the unique device secret burned into the hardware of the peripheral computing device and the measurement value of the second variable firmware obtained from the second immutable bootloader. The first immutable bootloader accepts the measurement value of the second variable firmware when the measurement value is included in the initial message received from the second microcontroller after the first microcontroller restarts. The peripheral computing device is a peripheral computing device that makes the authenticity proof and the measurement value available to the host of the peripheral computing device for access by a verifier.

19. A computing device according to claim 1, wherein the second immutable bootloader is a computing device that checks whether the restart of the second microcontroller is a hard reset or a soft reset.

20. A peripheral computing device according to claim 18, wherein the second immutable bootloader is a peripheral computing device that checks whether the restart of the second microcontroller is a hard reset or a soft reset.

Images