Bootlog digest

Abstract

In an example, a bootlog associated with a boot of the controller is accessed from the non-volatile memory of the controller, and a first digest of the bootlog is computed. A second digest of the bootlog is stored in a read-only hardware register in the non-volatile memory and subsequently extracted. The first and second digests are compared to determine if the controller is compromised. The controller is considered compromised when the digests do not match, and the bootlog is considered legitimate when the digests match.

Description

86294263 / HPNBT.260WO PATENT BOOTLOG DIGEST BACKGROUND

[0001] Generally described, the firmware of a computing device can be protected with a dedicated chip known as a security controller. The security controller enhances the security of the computing device by validating the integrity of the device’s basic input / output system (BIOS) and other critical firmware. However, the security controller itself has firmware in embedded non-volatile memory that can be subject to malicious tampering or malware attacks while in the supply chain, e.g., between manufacture of the security controller by a supplier and installation by a manufacturer of the computing device. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various features will now be described with reference to the following drawings. Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate examples described herein and are not intended to limit the scope of the disclosure.

[0003] FIG.1 is a pictorial diagram depicting an example of a zone of risk a security controller encounters while in transit from a supplier of the security controller to a manufacturer of a computing device, during which time a bad actor may compromise the firmware of the security controller and the compromise may be detected by a diagnostic system in accordance with the present disclosure;

[0004] FIG.2 is a pictorial diagram depicting an example system in which the security controller of a computing device can be tested using a diagnostic system implementing example routines to detect compromised firmware in accordance with the present disclosure;

[0005] FIG.3 is a block diagram depicting an example architecture of the computing device and security controller shown in FIG. 2;

[0006] FIG.4 is a flow diagram depicting an example routine implemented by a diagnostic system for verifying the legitimacy of the firmware of the security controller shown in FIG.3;

[0007] FIG.5 is a flow diagram depicting an example routine implemented by a diagnostic system for certifying a root device identity certificate generated by a security controller shown in FIG.3; and

[0008] FIG.6 is a block diagram depicting an example architecture of a diagnostic system that may detect compromised firmware in a security controller in accordance with the present disclosure. DETAILED DESCRIPTION

[0009] Computing device manufacturers need a way to detect when a security controller contains compromised firmware so that such compromised security controllers can be removed from the assembly line, or otherwise disposed of, before the computing device is sold to customers. Generally described, a computing device, such as a laptop, notebook, desktop computing device, or any other computing device (hereafter “device”), may include firmware such as a BIOS that initializes the hardware of the device and loads the operating system of the device after the device powers on. This process may be referred to as the “boot process.” Due to the importance of maintaining the security and integrity of the device firmware, a device may include a dedicated chip known as a security controller. The security controller maintains the integrity of the device firmware by checking for malware infections in the device firmware before allowing the boot process to proceed. If a malware infection or modification is detected in the device firmware by the security controller, the security controller may restore a clean, uncompromised copy of the device firmware to the device for use in the boot process. In some examples, a security controller may be referred to simply as a “controller.”

[0010] A security controller may include firmware distinct from the firmware of the device the security controller is monitoring. The firmware of the security controller may include microprocessor executable instructions that, when executed, provide low-level control for the security controller’s hardware. In some computing devices, firmware is decoupled from the security controller, meaning that firmware is loaded onto the security controller through external flash memory. This decoupled firmware may be relatively simple for a manufacturer to inspect and program into the security controller at the manufacturer’s factory. However, in other computing devices, firmware is not decoupled from the security controller, but ratherbooted from non-volatile memory embedded in the security controller. Due to the strict security measures in place on such firmware, a manufacturer may not have a simple way to inspect the legitimacy of the firmware upon arrival at the manufacturer’s factory from the supplier. Within the scope of this disclosure, “legitimacy” can be understood to mean without compromise, alteration, or malicious change from an intended original state. For example, “legitimate” firmware can be understood as the firmware the manufacturer intended to install in the controller, and a “legitimate” bootlog is a bootlog that is unaltered by malicious interference and accurately represents the true boot state of the controller.

[0011] This inspection limitation is particularly concerning for manufacturers because firmware is at risk for interception by a bad or malicious actor in the supply chain, e.g., while in transit from the supplier to the manufacturer. A bad actor may insert malware code into the embedded non-volatile memory of the firmware. Such malware code may masquerade as legitimate firmware, providing a seemingly legitimate cryptographic identity, hardware state, and hardware configuration to the device that are actually controlled by the bad actor. Because a manufacturer certifies the integrity of the devices they sell to customers, the manufacturer needs a way to detect such a malware attack on a security controller implemented within one of their devices. Accordingly, the present disclosure describes ways for manufacturers to verify security controller integrity by detecting malware attacks on firmware booting from embedded non-volatile memory (which may also be referred to as “internal flash memory,” “embedded flash memory,” just “flash memory,” or just “non-volatile memory”).

[0012] FIG.1 depicts an example scenario 100 in which a security controller 110 may be intercepted by a bad actor 120 for the purposes of a malware attack. Risk zone 130 represents the time in the supply chain during which the security controller 110 is at risk for malicious interception by a bad actor 120, e.g., between manufacture of the security controller 110 by a supplier 140 and installation by a manufacturer 150 of the security controller 110 in a computing device.

[0013] In some examples, the manufacturer 150 may be a manufacturer of computing devices and other related technology. The manufacturer 150 may incorporate the security controller 110 within a computing device to protect the integrity of the firmware of the computing device. In other examples, the manufacturer 150 may receive the security controller 110 from the supplier 140 without incorporating the security controller 110 into acomputing device. For example, techniques of detecting compromised firmware in the security controller 110 disclosed herein may be applied to a security controller 110 incorporated within a computing device or other related technology, or to a standalone security controller 110.

[0014] In some examples, the security controller 110 may include firmware that allows the security controller 110 to boot from embedded non-volatile memory. Such firmware presents a specific risk of malware attack by arriving at the factory of the manufacturer 150 ready to boot without an easy way for the manufacturer 150 to determine if the firmware being booted is the original firmware from the supplier 140 or otherwise legitimate firmware. The firmware may have been intercepted by a bad actor 120 in the risk zone 130 and replaced with a malicious copy of test-signed firmware in the embedded non-volatile memory of the security controller 110 that mimics the behavior of legitimate firmware but is controlled by the bad actor 120.

[0015] In one example of a malware attack on the firmware by a bad actor 120, a malicious copy of firmware may masquerade as a production security controller 110 reporting the “correct” state of the hardware at the time of boot. The malicious copy of firmware may report a false hardware configuration, such as “production locked.” Further, the malicious copy of firmware may report a fake device identity for the security controller 110 that appears to be the actual device identity but is controlled by the bad actor 120. A manufacturer 150 or an end user may rely on this device identity to verify the legitimacy of the security controller 110, so there is a need to prevent this type of malware attack.

[0016] In one example, the time during which the security controller 110 is with the security controller supplier 140 may also be considered within the risk zone 130. In another example, the risk zone 130 begins after the security controller 110 has left the supplier 140. In both such examples, the risk zone 130 may exist because the supplier 140 may not collect or certify the device identity of the security controller 110 for the manufacturer 150. In still other examples, the risk zone 130 may continue after the security controller 110 has left the manufacturer 150 and has entered production for use by an end user of a device in the field.

[0017] As further depicted in FIG. 1, attacks on the security controller 110 in the risk zone 130 may be detected by a diagnostic system 160. While this disclosure focuses on examples of a diagnostic system used by a manufacturer 150 in the factory, the diagnostic system 160 may be used to verify the legitimacy of a security controller 110 at any point in therisk zone 130, including but not limited to, at the supplier 140, in transit from the supplier 140 to the manufacturer 150, within factories of the manufacturer 150, in the field with an end user device, or in other applicable scenarios.

[0018] FIG. 2 a pictorial diagram depicting an example system 200 in which a security controller 110 of a computing device 210 is connected through a communication link 220 to a diagnostic system 160 that may be used, among other purposes, to verify the integrity of the firmware of the security controller 110. For example, the diagnostic system 160 may implement diagnostic routines 230 such as those described in connection with FIGs. 4 and 5 to verify the integrity of the firmware. Returning to FIG. 2, the diagnostic system 160 may include an external monitor or a docking monitor in which a docking station is integrated with the external monitor, which is separate from and connected to the computing device 210 via a communication link 220. The communication link 220 can be a wired connection made with, e.g., a USB-C cable, an HDMI cable, a DisplayPort cable, a Digital Visual Interface (DVI) cable (or an adapter for any of the foregoing) connected to a corresponding, compatible port of the computing device 210, or any other data and / or power transmitting cable or connector. For example, the communication link 220 may provide data and power over the same cable (as in the case of USB-C connection) or data only (as in the case of a DVI connection). In other examples, the diagnostic system 160 and computing device 210 are “all-in-one.” While the functional components of the diagnostic system 160 that enable an agent of the manufacturer 150 to conduct diagnostic routines 230 on the security controller 110 as described herein may be separate from the computing device 210, the diagnostic system 160 may communicate with the computing device 210 via a communication link 220 that is internal and made with an embedded connector, e.g., a low-voltage differential signaling (LVDS) connector or an embedded DisplayPort (eDP) connector. The communication link 220 can also be a wireless connection made via, e.g., Near Field Communication (NFC), BLUETOOTH®, WI-FI®, infrared, cellular, internal or external networks, the Internet, and / or the like. The communication link may also be a combination of wired and wireless communications and may be implemented with appropriate security and encryption techniques.

[0019] In one scenario, an agent of the manufacturer 150 will operate the system 200 depicted in FIG.2 by connecting a cable, such as a USB-C cable, to corresponding ports at the computing device 210 and the diagnostic system 160 to establish thecommunication link 220 between the devices. In such a scenario, the communication link 220 may be considered a physical connection. However, in other examples, the communication link 220 may be a logical connection over which data can be exchanged, e.g., between logical network interfaces or devices, or a combination of a logical and physical connection. In response to detecting the communication link 220, the computing device 210 transmits and the diagnostic system 160 receives for diagnostic testing purposes, via the communication link 220, various measurements from the firmware on the security controller 110 within the computing device 210. In some examples, measurements may include different types of data and unique identifiers related to the firmware such as a hash of the firmware, bootlogs, root device identity certificates, intermediate certificates, and leaf certificates, etc. In some examples, these various measurements may be stored in volatile memory (not shown). In some implementations, the communication link 220 between the diagnostic system 160 and the computing device 210 is an enhanced Serial Peripheral Interface (“eSPI”) bus interface.

[0020] While the example system 200 in FIG. 2 depicts a security controller 110 within a computing device 210, the present disclosure also encompasses a communication link 220 directly between a diagnostic system 160 and a standalone security controller 110 that is not incorporated within a computing device. In some examples, a standalone security controller may be a system-on-chip (“SOC”) interfacing through the communication link 220 (e.g., an eSPI) to the diagnostic system 160.

[0021] FIG.3 depicts a block diagram of an example architecture 300 of a security controller 110 of a computing device 210 that may be subject to malware detection testing by the diagnostic system 160 via the device communication interface 301. The example architecture 300 depicted in FIG. 3 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. In some examples, example architecture may include more (or fewer) components than those shown in FIG. 3. The device 210 may include a central processing unit (“CPU”) 302 in communication with the security controller 110, the device communication interface 301, and the device memory 303 which stores the operating system 304 of the device 210. All of the foregoing may communicate with one another by way of an internal communication bus. The device communication interface 301 may allow for a communication link 220 with the diagnostic system 160.

[0022] As illustrated in FIG. 3, the security controller 110 may include a microprocessor 305 in communication with the embedded memory 310 of the security controller 110. The embedded memory 310 may include an embedded non-volatile memory 320 and embedded volatile memory 315. In some examples, the embedded volatile memory 315 stores at least one bootlog of events occurring upon boot for each non-volatile memory layer. For the purposes of this disclosure, a memory layer can be understood as a distinct logical area of memory. In some examples, the embedded volatile memory 315 contains read-only hardware registers that may store trusted digests capturing events recorded to a bootlog. The embedded volatile memory 315 may be a dynamic random-access memory (“DRAM”), static random-access memory (“SRAM”), or a combination thereof. The embedded non-volatile memory 320 may be EPROM, EEPROM, flash memory (NAND or NOR flash memory), one-time-programmable (“OTP”) memory, read-only memory (“ROM”) or a combination thereof. The embedded non-volatile memory 320 may include at least two logical layers with diminishing levels of privilege and access. In some examples, three logical layers of diminishing privilege are present: the ROM layer 340 (with greatest privileges), the extended ROM layer 350, and the firmware 360 (with least privileges). Upon boot, control is passed up by the microprocessor 305 one layer at a time, starting with the ROM layer 340 until arriving at the firmware 360. Before passing control to the next, less-privileged memory layer during the boot process, the microprocessor 305 records, in a bootlog, the measurements of the code in the next layer. As noted above, the measurements may include a root device identity certificate measurement. Such measurements serve as a snapshot identifying the code that was booted and the identity credentials of the device under ROM control, and this attestation helps maintain the integrity of the boot process. For example, before the ROM layer 340 passes control to the extended ROM layer 350, the microprocessor 305 records the measurements of the ROM layer 340 and stores the measurements in a bootlog. This process repeats before the extended ROM layer 350 passes control to the firmware 360. For purposes of brevity, the ROM layer and the extended ROM layer may be referred to as ROM and extended ROM, respectively, without reference to a “layer.”

[0023] In some examples, the OTP memory 330 of the embedded non-volatile memory 320 is a data and configuration resource with access restrictions dependent on the layer of memory being executed. The OTP memory 330 may store a root device identitycertificate 352 generated upon each boot of the device 210 and the associated private key 349 (discussed in further detail below). The OTP memory 330 may include a launch control policy 332 fused into the layer. The launch control policy 332 may have a launch control policy state used during execution that is reported up through the layers of the embedded non-volatile memory 320 through bootlogs. In some examples, the last step for the supplier 140 before sending the security controller 110 to the manufacturer 150 is to fuse a measurement for the extended ROM layer 350 into the OTP memory 330. Thus, the OTP memory 330 is hardcoded to run only one version of the extended ROM layer 350 according to the fused measurements applied by the supplier 140. This allows the manufacturer 150 of the computing device 210 more time and flexibility to finalize the extended ROM layer 350 later in the manufacturing process.

[0024] The ROM layer 340 of the embedded non-volatile memory 320 includes code that generates the ROM bootlog 346. A trusted digest 344 of the ROM bootlog 346 is then calculated and stored in a set of read-only hardware registers 342 located in embedded memory 310, e.g., in embedded non-volatile memory 315. More specifically, upon a boot of the security controller 110, the microprocessor 305 may generate one or more bootlogs of the events that occur during the boot. The microprocessor 305 may then compute a digest for each such bootlog and store the digest(s) in the hardware registers 342. Since each such bootlog is generated by trusted code in ROM 340 and extended ROM 350 upon boot of the security controller 110, the resulting digest(s) are considered “verified” or “trusted” digests. A digest may be a result of a hash function performed on the bootlog. In some examples, a digest is a fixed bit length of a one-way hash function performed on the bootlog. Since the digest is sensitive to changes in the bootlog data upon which the hash function is applied, the digest can serve as a unique and compact representation of the bootlog. Moreover, a one-way hash function is collision resistant, meaning an attempt to generate a hypothetical malicious set of data that hashed to the same digest found in the hardware registers 342 would be infeasible. A digest may also be referred to as a “fingerprint,” a “message hash,” or just a “hash.” A one-way hash function may also be referred to as a “fingerprint function” or a “compression function” and may utilize hashing algorithms such as a message digest (MD) algorithm (including MD4, MD5, etc.) or a secure hash algorithm (SHA) including SHA2 functions (such as SHA256, SHA384 and SHA512) and SHA3 functions (such as SHA3-256, SHA3-384, SHA3-512,SHAKE128 and SHAKE256). In some examples, each hardware register includes a trusted digest 344. In yet other examples, only a subset (and perhaps only one) of the hardware registers includes a trusted digest 344. In yet another example, a hardware register of the set includes multiple trusted digests 344. The trusted digests 344 are used in the diagnostic routines 230 of the diagnostic system 160. The ROM layer 340 is sealed with a silicon mask during production, causing the ROM layer 340 to be permanently programmed and resistant to change without changing the mask. Because of the immutability of the ROM layer 340 due to the silicon mask, the ROM layer 340 is not considered to be at risk for malware interception like the firmware 360. Thus, the bootlogs are considered “verified” if they match the digests of the bootlogs stored in the read-only hardware registers 342 populated by the code of the trusted ROM 340 and the extended ROM 350. The “verified” bootlogs serve as a trustworthy point of comparison for the true state of the security controller 110 at the time of the boot of the security controller 110.

[0025] The code of the ROM layer 340 generates an unverified ROM bootlog 346 reporting information related to the present boot of the security controller 110. However, the security controller 110 may have been compromised in the risk zone 130 as shown in FIG.1, in which case a bad actor 120 may have inserted malware code into the embedded non-volatile memory of the firmware. Such malware code may corrupt the firmware or replace the original firmware with a malicious copy. Accordingly, the unverified ROM bootlog 346 may be a bootlog of events that occurred during boot of the security controller 110 using compromised firmware. Upon a call from an application programming interface (“API”) of the firmware 360, the unverified ROM bootlog 346 may be exposed to the device 210 (and thus, the diagnostic system 160) through the firmware 360. In this way, even though the ROM layer 340 is secure and not subject to malware attacks, the ROM bootlog 346 is initially considered unverified because the ROM bootlog 346 may have been exposed through compromised firmware, stored in the embedded memory 310 of the security controller by a bad actor 120, or otherwise modified and stored in embedded memory 310 and then exposed through the firmware 360 as a supposedly legitimate bootlog.

[0026] The ROM layer 340 is the only layer of embedded non-volatile memory 320 with access to a unique seed 348 stored in OTP memory 330 needed to generate a root device identity certificate 352. In some examples, the root device identity certificate is aX.509 certificate. When the ROM layer 340 passes control to the extended ROM layer 350, the hardware registers 342 (and thus the trusted digests 344) are locked and a processed version of the unique seed 348 is passed by the microprocessor 305 to the extended ROM layer 350. Code executed from the ROM layer 340 can use a private key 349 (accessible only by ROM 340) to sign the root device identity certificate 352 generated with the unique seed 348. The private key 349 corresponds to the public key 354, the latter of which is accessible by extended ROM 350. Upon each boot of the security controller 110, the root device identity certificate 352 can be regenerated or otherwise retrieved from OTP memory 330.

[0027] The extended ROM layer 350 of the embedded non-volatile memory 320, like the ROM layer 340, is not considered to be at risk for malware interception like the firmware 360. Sometimes called “soft ROM,” the extended ROM layer 350 includes code that, when executed by the microprocessor 305, generates a root device identity certificate 352 for the security controller 110 which is then stored in OTP memory 330. In some examples, an extended ROM layer is not a separate logical layer from the ROM layer, and only a ROM layer is referenced. The microprocessor 305 may also compute a certificate digest 356 for each of the root device identity certificates 352 issued. Each certificate digest 356 may be a result of a hash function performed on a root device identity certificate. In some examples, a certificate digest is a fixed bit length of a one-way hash function performed on the root identity certificate. Since the certificate digest is sensitive to changes in the data upon which the hash function is applied, the certificate digest can serve as a unique and compact representation of the root identity certificate. Moreover, because a one-way hash function is performed, the certificate digest is collision resistant. Thus, an attempt by a bad actor 120 to generate a hypothetical alternative identity that corresponds to the hash of the certificate digest would be infeasible.

[0028] In the example in FIG.3, the measurements of the firmware 360, the state of the launch control policy 332, and certificate digest(s) 356 of the root device identity certificate 352 are reported as part of an unverified extended ROM bootlog 358 generated during a boot of the security controller 110. As with the unverified ROM bootlog 346, the unverified extended ROM bootlog 358 may include a bootlog of events that occurred during boot of the security controller 110 using compromised firmware rather than legitimate firmware. The unverified extended ROM bootlog 358 is generated by extended ROM 350, passed to embedded volatile memory 315, and exposed by the firmware 360 to the device 210,specifically through the device communication interface 301. Because the extended ROM bootlog 358 may have been modified during a boot using compromised firmware 360, or otherwise stored in the embedded memory 310 of the security controller by a bad actor 120, the extended ROM bootlog 358 is initially considered “unverified” and needs integrity verification by the diagnostic system 160 before the contents may be deemed legitimate.

[0029] The firmware 360 of the embedded non-volatile memory 320 includes code stored in embedded non-volatile memory of the security controller 110 that is at risk of malware attack by a bad actor 120 within the risk zone 130. Accordingly, the present disclosure describes verifying that the firmware 360 has not been compromised. If the calculated digests of the unverified ROM bootlog 346 and the unverified extended ROM bootlog 358 exposed through the firmware 360 are consistent with the trusted bootlog digests 344 stored in the hardware registers 342, the unverified bootlogs 346 and 358 can be confirmed as “verified” or “legitimate” bootlogs. From there, these newly confirmed legitimate bootlogs, which contain a digest 356 of the root device identity certificate 352 generated at the time of boot, serve as a source of truth for the next step of the diagnostic testing. Specifically, the root device identity certificate digests 356 in the newly confirmed legitimate bootlogs serve as the comparison point to the root device identity certificate passed through the firmware 360, which must still be verified. To do this, the diagnostic system 160 makes a call to the firmware API to retrieve the root device identity certificate stored in OTP memory 330 and exposed by the firmware 360, and the digest of this certificate is calculated. If this digest of the root device identity certificate exposed through the firmware 360 matches the digest 356 of the root device identity certificate stored in the legitimate bootlogs, the root device identity certificate exposed through the firmware 360 can now be certified as legitimate. On the other hand, if there is not a match between the root device identity certificate digests, the firmware 360 was likely compromised by malware and is thus reporting a falsified root device identity certificate. This is because the firmware 360 does not have access to the private key 349 needed to generate the true root device identity certificate 352. Therefore, if an incorrect digest of the root device identity certificate is coming from the firmware 360, this is most likely because malware is maliciously reporting a falsified root device identity certificate the bad actor 120 controls (instead of the true root device identity certificate 352, which the malware in the firmware 360 does not have the ability to access in the secured layers of memory below). In such a scenario,the compromised security controller may be removed from production by the manufacturer 150 or otherwise flagged as compromised.

[0030] FIG.4 is a flow diagram depicting an example routine 400 implemented by the diagnostic system 160 for verifying the legitimacy of the unverified ROM bootlog 346 and unverified extended ROM bootlog 358 (collectively “unverified bootlogs 346 and 358”), generated upon boot of the security controller 110. While routine 400 may be implemented by the diagnostic system 160 connected via a communication link 220 to a computing device 210 that includes a security controller 110, in other examples the routine may be implemented by the diagnostic system 160 connected via a communication link 220 directly to a security controller 110. The routine 400 starts in block 410 where the diagnostic system 160 receives the unverified bootlogs 346 and 358 exposed to the diagnostic system 160 through the firmware 360. In one example, the diagnostic system 160 may receive the unverified bootlogs 346 and 358 after making a call to retrieve the bootlogs through a firmware API. As noted above, the unverified bootlogs 346 and 358 may have been modified during boot of the security controller 110 using compromised firmware and cannot yet be considered legitimate.

[0031] Next, at block 420, the diagnostic system 160 may compute respective diagnostic digests of the unverified bootlogs 346 and 358 retrieved at block 410. Each diagnostic digest may be a result of a hash function performed on an unverified bootlog. In some examples, a diagnostic digest is a fixed bit length of a one-way hash function performed on the unverified bootlog. Since the diagnostic digest is sensitive to changes in the bootlog data upon which the hash function is applied, the diagnostic digest can serve as a unique and compact representation of the unverified bootlog. Moreover, the one-way hash function is collision resistant, meaning an attempt to produce a hypothetical malicious bootlog with a hash corresponding to the diagnostic digest would be infeasible.

[0032] The routine 400 continues at block 430, where the diagnostic system 160 extracts the trusted digests 344 from the hardware registers 342 that were populated and locked by ROM 340 and extended ROM 350 during the respective phases of the boot. The hardware registers 342 are exposed to the device 210 (and thus, the diagnostic system 160) as input / output (“I / O”) memory space, where the I / O cycles from the diagnostic system 160 to the security controller 110 are handled by security controller hardware, entirely independent of the firmware 360 (and thus, a trusted point of reference not subject to compromise bymalware). Thus, the diagnostic system 160 can extract the trusted digests 344 directly from the hardware registers 342, rather than request them through a firmware API.

[0033] At block 440, the diagnostic system 160 compares the diagnostic digests of the unverified bootlogs 346 and 358 computed by the diagnostic system 160 to the trusted digests 344 extracted directly from the secure hardware registers 342 in order to determine the legitimacy of the unverified bootlogs. For brevity, a “diagnostic digest” may be referred to as a “first digest” and a “trusted digest” may be referred to as a “second digest” (and vice versa, depending on context). However, where reference is made to a “first,” “second,” “third,” “fourth,” and so on, the adjectives, “first,” “second,” “third,” “fourth,” and so on are not used to connote any description of structure or to provide any substantive meaning; rather, such adjectives are merely used to differentiate one component from a similarly named component.

[0034] At decision block 450, the diagnostic system 160 looks for a match: if the diagnostic digests of the unverified bootlogs 346 and 358 match the trusted digests 344 extracted from the hardware registers 342, the diagnostic system 160 determines at block 460 that the unverified bootlogs 346 and 358 may be safely considered legitimate bootlogs reporting the true state of the security controller 110. However, if the diagnostic digests of the unverified bootlogs 346 and 358 do not match the trusted digests 344 extracted from the hardware registers 342, then at block 470, the diagnostic system may display an alert to an agent of the manufacturer 150 or may otherwise flag or identify that the security controller 110 has been compromised and thus needs to be removed from production.

[0035] FIG.5 is a flow diagram depicting an example routine 500 implemented by the diagnostic system 160 following the successful completion of the example routine 400. The example routine 500 uses the legitimate bootlogs verified, for example, by routine 400 to certify the root device identity certificate 352 generated by code in extended ROM 350. Beginning at block 510, the diagnostic system 160 accesses the legitimate bootlogs received during successful completion of routine 400. In one example, at block 510, the diagnostic system 160 also confirms that the ROM 340 and the extended ROM 350 of the security controller 110 are in the correct production state. In such an example, the correct production state may entail revoked test keys, disabled debugging interfaces, and legitimate digests from legitimate bootlogs reported through the firmware 360.

[0036] After successful completion of the confirmations at block 510, the routine proceeds to block 520 where the diagnostic system 160 retrieves the certificate digest 356 of the root device identity certificate 352 from the extended ROM bootlog 358, which has been verified as legitimate. Because the extended ROM bootlog 358 is confirmed as legitimate, the certificate digest 356 of the root device identity certificate 352 that is included in the ROM bootlog 358 can safely be considered legitimate.

[0037] Next, at block 530, the diagnostic system 160 retrieves a root device identity certificate 352 through a call to the firmware API. Because this root device identity certificate is being exposed through firmware 360 to the device 210, the root device certificate being reported may be subject to malicious misrepresentation by malware infecting the firmware 360. Thus, like the bootlogs, the root device identity certificate being reported through the firmware must be verified by the diagnostic system 160 by way of a routine such as example routine 500.

[0038] Once the diagnostic system 160 has retrieved the root device identity certificate 352 from the firmware 360, the diagnostic system 160 computes a diagnostic certificate digest of the root device identity certificate 352 passed through the firmware 360. The diagnostic certificate digest 356 may be a result of a hash function performed on the root device identity certificate 352. In some examples, the diagnostic certificate digest is a fixed bit length of a one-way hash function performed on the root identity certificate. Since the diagnostic certificate digest is sensitive to changes in the data upon which the hash function is applied, the diagnostic certificate digest can serve as a unique and compact representation of the root identity certificate. Moreover, the one-way hash function is collision resistant, meaning an attempt to generate a hypothetical malicious root identity certificate with a hash corresponding to the diagnostic certificate digest would be infeasible.

[0039] At block 540, the diagnostic system 160 compares the certificate digest 356 of the root device identity certificate obtained in block 520 from the legitimate extended ROM bootlog 358 to the diagnostic certificate digest calculated in block 530. In some examples, the root device identity certificate obtained in block 520 is included within an unverified extended ROM digest. For brevity, a “certificate digest” may be referred to as a “first digest” and a “diagnostic certificate digest” may be referred to as a “second digest” (and vice versa, depending on context). However, where reference is made to a “first,” “second,” and so on,the adjectives, “first,” “second” and so on are not used to connote any description of structure or to provide any substantive meaning; rather, such adjectives are merely used to differentiate one component from a similarly named component. At block 550, the diagnostic system 160 looks for a match: if the certificate digest 356 of the root device identity certificate accessed from the legitimate extended ROM bootlog 358 matches the diagnostic certificate digest computed by the diagnostic system 160 at block 530, then at block 560, the diagnostic system 160 certifies the root device identity certificate obtained from the firmware 360 as a legitimate root device identity certificate. This certification approach can be used for any such unique identifier for any individual device 210. However, if the certificate digest 356 of the root device identity certificate accessed from the legitimate extended ROM bootlog 358 does not match the diagnostic certificate digest computed by the diagnostic system 160, then at block 570, the diagnostic system declines to certify the root device identity certificate. In such a case, the diagnostic system 160 may display an alert to an agent of the manufacturer 150 that communicates that the security controller 110 has been compromised or may otherwise flags or identify that the security controller 110 has been compromised and thus needs to be removed from production.

[0040] In FIG. 6, a block diagram depicts example architecture 600 that may be implemented by the diagnostic system 160 used to verify the integrity of the security controller 110. The example architecture 600 depicted in FIG. 6 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. In some examples, example architecture may include more (or fewer) components than those shown in FIG.6. The diagnostic system 160 may include a central processing unit (CPU) 610 in communication with a communication interface 620 and a diagnostic system memory 630, all of which may communicate with one another by way of an internal communication bus. The communication interface 620 may provide a port for a communication link 220 with a device 210 with a security controller 110. In one example, the memory 630 of the diagnostic system 160 store computer-executable instructions that, when executed by the CPU 610, implements diagnostic routines 230, such as the diagnostic tests described in the present disclosure. The memory 630 may include RAM, ROM and / or other persistent or non-transitory memory.

[0041] It is to be understood that not necessarily all objects or advantages may be achieved in accordance with any particular example described herein. Thus, certain examples may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages as may be taught or suggested herein.

[0042] All of the processes described herein may be embodied in, and fully automated via, software code modules, including specific computer-executable instructions, which are executed by a computing system. The computing system may include at least one computer or processor. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all the methods may be embodied in specialized computer hardware.

[0043] Many other variations than those described herein will be apparent from this disclosure. For example, depending on the example, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain examples, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and / or computing systems that can function together.

[0044] The various example logical blocks, components and modules described in connection with the examples disclosed herein can be implemented or performed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry configured to process computer-executable instructions. In another example, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented asa combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, at least one microprocessor in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

[0045] Conditional language such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain examples include, while other examples do not include, certain features, elements, and / or blocks. Thus, such conditional language is not generally intended to imply that features, elements and / or blocks are in any way required for any examples or that any example necessarily includes logic for deciding, with or without user input or prompting, whether these features, elements, and / or blocks are included or are to be performed in any particular example.

[0046] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain examples require at least one of X, at least one of Y, or at least one of Z to each be present.

[0047] Any process descriptions, elements or blocks in the flow diagrams described herein and / or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the examples described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.

[0048] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as“a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B, and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

Claims

WHAT IS CLAIMED IS:

1. A non-transitory computer readable medium comprising machine-readable instructions that, when executed by a processor, cause the processor to: access a first bootlog from a controller of a computing device, wherein the controller includes a non-volatile memory, and wherein the first bootlog is associated with a boot of the controller; compute a first digest of the first bootlog; extract, from a read-only hardware register in the non-volatile memory, a second digest of the first bootlog; determine whether the first digest matches the second digest; indicate the controller is compromised when the first digest does not match the second digest; and indicate the first bootlog is a first legitimate bootlog when the first digest matches the second digest.

2. The non-transitory computer readable medium of claim 1, wherein the non-volatile memory of the controller comprises: read-only memory (ROM); extended ROM; and firmware.

3. The non-transitory computer readable medium of claim 2, wherein the first bootlog is stored in the ROM of the non-volatile memory.

4. The non-transitory computer readable medium of claim 3 comprising further computer-executable instructions that, when executed by the processor, cause the processor to: access the first bootlog stored in the ROM via the firmware.

5. The non-transitory computer readable medium of claim 4, wherein the second digest of the first bootlog is extracted directly from the read-only hardware register.

6. The non-transitory computer readable medium of claim 2 comprising further computer-executable instructions that, when executed by the processor, cause the processor to: access a second bootlog from the controller of the computing device, wherein the second bootlog is stored in the extended ROM of the non-volatile memory, and wherein the second bootlog is associated with the boot of the controller; compute a third digest of the second bootlog; extract, from a read-only hardware register in the non-volatile memory, a fourth digest of the second bootlog; determine whether the third digest matches the fourth digest; indicate the controller is compromised when the third digest does not match the fourth digest; and indicate the second bootlog is a second legitimate bootlog when the third digest matches the fourth digest.

7. The non-transitory computer readable medium of claim 6 comprising further computer-executable instructions that, when executed by the processor, cause the processor to: access a root device identity certificate from the non-volatile memory; compute a first digest of the root device identity certificate accessed from the non-volatile memory; determine that the first digest of the root device identity certificate matches a second digest of the root device identity certificate included in the first legitimate bootlog; and certify the root device identity certificate as a legitimate root device identity certificate.

8. The non-transitory computer readable medium of claim 7, wherein the first digest of the root device identity certificate is computed with a one-way hash function.

9. A device comprising: non-volatile memory to store firmware of the device, wherein the non-volatile memory includes a hardware register; and a microprocessor in communication with the non-volatile memory, wherein the microprocessor is to: generate a bootlog during boot of the device by the firmware; store a first digest of the bootlog in the hardware register of the non-volatile memory; lock the hardware register that stores the first digest of the bootlog to form a read-only hardware register; in response to a first request, access a second digest of the bootlog from the non-volatile memory via the firmware; and in response to a second request, extract the first digest of the bootlog from the read-only hardware register rather than via the firmware, wherein legitimacy of the second digest of the bootlog accessed via the firmware is determined based on a comparison of the second digest and the first digest.

10. The device of claim 9, wherein the non-volatile memory comprises: read-only memory (ROM), wherein the ROM includes the read-only hardware register, and wherein the ROM is to store the second bootlog; and firmware, wherein the firmware is to store firmware of the device.

11. The device of claim 9, wherein the microprocessor is further to generate the first digest of the bootlog with a one-way hash function.

12. A method comprising: accessing a bootlog from a controller for a computing device, wherein the controller includes a non-volatile memory, wherein the bootlog is associated with boot of the controller and includes a first digest of a root device identity certificate for the controller, and wherein the non-volatile memory stores the root device identity certificate for the controller; determining that the bootlog is a legitimate bootlog; accessing the root device identity certificate from the non-volatile memory; calculating a second digest of the root device identity certificate accessed from the non-volatile memory; determining that the second digest of the root device identity certificate matches the first digest of the root device identity certificate included in the legitimate bootlog; and certifying the root device identity certificate as a legitimate root device identity certificate.

13. The method of claim 12, wherein determining that the bootlog is a legitimate bootlog further comprises: obtaining the bootlog from the non-volatile memory; calculating a first bootlog digest of the bootlog; extracting, from a read-only hardware register in the non-volatile memory, a second bootlog digest of the bootlog; and determining that the first bootlog digest matches the second bootlog digest.

14. The method of claim 13, wherein at least one of the digests of the bootlog or the digests of the root device identity certificate is calculated with a one-way hash function.

15. The method of claim 13, wherein the first digest of the bootlog is extracted directly from the read-only hardware register in the non-volatile memory rather than via firmware.

Images