Secure Firmware Verification

Abstract

To provide a computing system for securely verifying system firmware and recovery firmware to ensure system integrity without depending on a manufacturer's proprietary verification process, hardware unique keys, or a system memory unique write protection function, and a storage medium.SOLUTION: A computing system 100 relies on a security processor that holds firmware management parameters which define a process for verifying firmware and recovery firmware independent of an integrated circuit manufacturer's Mask ROM (Read Only Memory) verification process. The security processor ensures that the firmware or recovery firmware is signed appropriately and consistent with previously executed versions, or if different, produces verification results that are consistent with expected results embedded in the firmware at compile time.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] background Some computing systems execute system firmware as part of the "boot" process after power-on or following a reset. Some computing systems can return to a stable, recovered state by executing "recovery" firmware instead of the system firmware. For security, computing systems may keep portions of the system firmware and recovery firmware in persistent, write-protected areas of system memory that can only be overridden by simultaneous physical access to the system memory. Some computing systems further ensure the integrity of the firmware and recovery firmware by performing a manufacturer's validation process, and in some cases, hardware validation. It uses a hardware-specific verification key (e.g., burned into a fuse in the application processor) to ensure that the system firmware is from an official source. Summary of the Invention [Problem to be solved by the invention]

[0002] As such, security and integrity may depend on the manufacturer's proprietary validation process, including the ability to manage hardware-specific validation keys and the computing system's ability to write-protect system memory. The write-protect feature may be compromised, for example, by a user with physical access to the system memory. Overreliance on the write-protect feature and hardware-specific validation keys assigned to the hardware during manufacturing may unnecessarily limit the usability, customization, and user control over the system and recovery firmware executed by the computing system.

[0003] overview A computing system is described that securely verifies system firmware and recovery firmware to ensure system integrity without relying on a manufacturer's proprietary verification process, hardware-specific keys, or inherent write-protection features of system memory. The computing system relies on a security processor that maintains firmware management parameters that define a process for verifying firmware and recovery firmware independent of an integrated circuit manufacturer's masked ROM (read-only memory) verification process. The security processor ensures that the firmware or recovery firmware is properly signed and matches a previously executed version, or, if different, produces a verification result (e.g., a generated hash value) that matches an expected result embedded in the firmware at compile time. In this way, the computing system improves usability, customization, and user control over the firmware and recovery firmware executed within the computing system. [Means for solving the problem]

[0004] In one example, a computing system is described that includes an application processor, a memory containing firmware and corresponding recovery firmware, and a security processor, and the security processor executes the firmware or recovery firmware as a condition for the application processor to execute the firmware or recovery firmware. The firmware is configured to verify the recovery firmware by determining an expected hash of the firmware or recovery firmware that the firmware holds and verifying the firmware or recovery firmware based on whether the expected hash matches the generated hash of the firmware or recovery firmware.

[0005] In another example, a method is described that includes a security processor of a computing system determining an expected hash of firmware from firmware stored in memory of the computing system, determining a generated hash of the firmware stored in memory, and verifying the firmware in response to the security processor determining that the expected hash corresponds to the generated hash.

[0006] In another example, a computer-readable storage medium includes instructions that, when executed, configure a security processor of a computing system to determine, from firmware stored in a memory of the computing system, an expected hash of the firmware; determine a generated hash of the firmware stored in the memory; and verify the firmware in response to a determination that the expected hash corresponds to the generated hash.

[0007] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the above description and drawings, and from the claims. This Summary is provided to introduce subject matter that is further described in the Detailed Description and Drawings. As such, this Summary should not be considered to state essential features, nor should it be used to limit the scope of the claimed subject matter.

[0008] One or more aspects of secure verification of recovery firmware are described in detail below. The same reference numbers used in different examples in this description and the drawings refer to similar elements. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a conceptual diagram illustrating an example of a computing system configured to verify firmware and recovery firmware. [Figure 2]10 is a flowchart illustrating an example of the operation of a security processor configured to verify firmware. [Figure 3] 10 is a flowchart illustrating an example of the operation of a security processor configured to verify recovery firmware. [Figure 4] 10 is a flowchart illustrating an example of the operation of a security processor configured to perform probabilistic or partial verification of firmware or recovery firmware. [Figure 5] FIG. 1 is a conceptual diagram illustrating a computing device configured to perform secure verification of firmware and recovery firmware. DETAILED DESCRIPTION OF THE INVENTION

[0010] Detailed Description In some computing systems, an application processor executes system firmware as a condition for loading and running an operating system (OS). Write-protected portions of system memory can store read-only portions of the system firmware, and read-write portions of system memory can store read-write (or unprotected) portions of the system firmware. The write-protected portions of system memory can also be used when the computing system is in recovery mode. The system may include specialized "recovery firmware" that executes when the system is operational. The recovery firmware is intended to execute in place of the system firmware during a recovery event to configure the computing system to operate in a stable recovery mode.

[0011] During the verified boot process, the security processor of the computing system may prevent the application processor from executing system firmware until the security processor can verify its own security processor firmware (e.g., "Cr50") stored in the security processor's internal memory. After verifying and executing the security processor's firmware, the security processor allows the application processor to continue with the verified boot process.

[0012] Once enabled, the application processor executes instructions embedded in a “mask ROM” (e.g., a type of read-only memory internal to the application processor and preprogrammed during manufacturing) to locate and retrieve the read-only portion of the system firmware in a write-protected portion of system memory. The mask ROM may configure the application processor to perform a proprietary verification process before executing the read-only portion of the system firmware. For example, the proprietary verification process may cause the application processor to verify that the read-only portion of the system firmware was signed using a unique hardware-specific key hard-coded in the application processor (burned into the application processor's fuses). If the mask ROM can verify the read-only portion of the system firmware using this unique hardware-specific key, the application processor executes the read-only system firmware. Relying on the mask ROM to verify the system firmware can prevent users from installing “unofficial,” third-party or user-customized firmware that was not signed using the unique hardware-specific key and therefore could not be verified.

[0013] As a condition of executing the read-write portion of the system firmware, the read-only portion verifies that the read-write portion was signed with the "official" root key during compilation. The computing system may store the root key in a write-protected portion of system memory. Assuming the write-protected portion of system memory cannot be corrupted, the application processor loads and executes the read-write portion of the system firmware in response to determining that the read-write portion of the system firmware was signed with the root key.

[0014] Similarly, when a computing system is running in recovery mode, the read-only portion of the system firmware preserves system integrity by verifying that the recovery firmware was signed with the root key before executing it. Continuing the assumption that the write-protected portions of the system memory are uncorrupted, the application processor loads and executes the recovery firmware in response to determining that the recovery firmware was signed with the root key. If the recovery firmware is unable to generate a recovery key, the computing system refrains from executing the recovery firmware until an official version of the recovery firmware capable of generating a recovery key is installed and running.

[0015] Some computing systems may in this way prevent the execution of unverifiable system and recovery firmware; A verified boot process inhibits usability, customization, and user control. The hardware-specific "official" root key may be discoverable only by an authenticated developer. Furthermore, the security and integrity of a computing system depend on the hardware-specific key and the implicit trust that write-protected portions of system memory can protect the "official" root key. However, the official root key may be compromised by a sophisticated user with physical access to the system memory or who otherwise finds a way to compromise the write-protected portions of the system memory. Thus, not only may this type of verified boot be less secure, but it may unnecessarily limit the usability, customization, and user control of a computing system by preventing legitimate users who are not authenticated developers but who wish to run third-party or custom firmware from doing so.

[0016] A computing system is described that facilitates firmware customization and user control without sacrificing security and integrity. The computing system relies on a security processor and an application processor configured to verify system firmware and recovery firmware without relying on a manufacturer's proprietary verification process, hardware-specific keys, or inherent write-protection features of system memory. Instead, the security processor verifies the firmware based in part on firmware management parameters that define a process, including a degree of thoroughness, for verifying the firmware and recovery firmware independent of an integrated circuit manufacturer's mask ROM (read-only memory) verification process, e.g., including a hardware-specific key. As an example, the firmware management parameters may specify performing partial or probabilistic verification, performing complete or full verification, or no verification.

[0017] After verifying the header signature and / or body signature of the system firmware, the security processor generates a hash (e.g., SHA-256) value associated with each block of the system firmware stored in the system memory and compares the generated hash value with an expected hash value derived by the security processor from the read-only portion of the firmware body.

[0018] Recovery firmware is generally larger in size than system firmware because it typically supports low-level drivers and user interfaces that system firmware does not. As a result, the security processor may rely on a more powerful application processor to verify the recovery firmware. After verifying the signature of the recovery firmware's header and / or body, the application processor generates a hash value associated with each block of the recovery firmware stored in system memory. The application processor may automatically generate and store the hash values ​​for the recovery firmware (e.g., as a background task performed by the operating system), for example, following the initial successful boot-up and execution of the system firmware.

[0019] The application processor compares the generated hash value with an expected hash value derived by the application processor from the read-only portion of the firmware body. If the expected hash value and the generated hash value do not match, the application processor notifies the security processor that the recovery firmware failed verification and refrains from executing the recovery firmware. If the expected hash value and the generated hash value of the recovery firmware match, the application processor executes the recovery firmware.

[0020] In response to the recovery firmware failing verification by the application processor, the security processor may attempt to verify the recovery firmware based on firmware management parameters. The security processor may partially verify the recovery firmware by verifying only a portion of the generated hash values ​​against the expected hash values. Alternatively, the security processor may perform a full verification and verify the generated hash values ​​against the expected hash values, or may not perform verification at all by skipping entire block verifications.

[0021] In this way, a computing system can verify firmware and recovery firmware independently of an integrated circuit manufacturer's mask ROM verification process and without relying on hardware-specific keys. Instead, the computing system relies on a security processor to ensure that system firmware matches a properly signed and previously executed version, or, if different, provides a verification result (e.g., a generated hash value) that matches an expected result embedded in the firmware at compile time. In this way, a computing system can improve the usability, customization, and user control over firmware and recovery firmware executed within the computing system. An example computing system can securely run custom or third-party firmware without the benefit of official firmware versions or predetermined hardware keys and without sacrificing system integrity.

[0022] By decoupling firmware verification from knowledge of processor-specific hardware keys, the techniques of this disclosure enable computing systems to run a greater variety of firmware and recovery firmware programs: firmware developers no longer need to rely on implied product knowledge of hardware-specific verification keys that may be controlled by hardware manufacturers who may or may not be willing to work with the firmware developers.

[0023] Additionally, the techniques of this disclosure can enable computing systems to defend against a broader or different range of attacks than those to which computing systems may have previously been exposed. For example, previous systems relied on write protection of system memory, and the only way an attacker could override system memory was via physical access to the computing system, including the memory chips or motherboard. This is known as a “malicious maid” attack, which refers to a scenario in which someone leaves a device unattended for an extended period of time (e.g., when an attacker poses as a hotel maid in order to access the device). However, some computing systems must defend against other types of attacks, for example, by users who may themselves be authorized users with long-term access to the device. For example, some schools issue computing devices to students with strict policies regarding student use. Schools use enterprise policies, sometimes based on legislative standards, to limit what students can do with their devices. Some students do not like these restrictions and may therefore attempt to circumvent the enterprise policies. Because students have long-term access to their devices, relying on write protection to enforce policy restrictions may be impractical. Other government agencies or private companies may have gaps in their physical security that allow an attacker to gain physical control of a device long enough to propagate a malicious maid attack.

[0024] In both cases, the device owner must be able to detect the attack and restrict device functionality during the attack. This restriction can take a range of forms, such as refusing to decrypt user data on disk, refusing to provide previously stored credentials to a website or wireless access point, or refusing to boot altogether. Owners may also vary in their tolerance for the impact of additional protection on boot speed. A typical user will prefer a faster boot in exchange for some reduced security, much like how some users may use short, easily guessed passwords. A corporate user will prefer a more secure boot, even if the security adds a few seconds to boot time.

[0025] In another scenario, an attacker may return a device to a store after modifying the firmware (e.g., by embedding malicious code in the device). The store must ensure that the firmware on the device has not been modified before reselling the device to a new customer. Similarly, devices may be returned to schools, government agencies, and businesses. Existing processes for verifying firmware for so-called "in-store returns" are slow, manual, and may require a second device.

[0026] For each of the above scenarios, the techniques of this disclosure can enable stores, schools, businesses, etc. to defend against these broader or different ranges of attacks by relying on the computing system to automatically verify firmware and recovery firmware before execution. In this way, the actual owner of the device, rather than an authenticated user, can ensure the integrity of the computing system they control without having to manually verify the system's integrity.

[0027] 1 is a conceptual diagram illustrating an example computing system 100 configured to perform secure verification of recovery firmware. Computing system 100 may form part of any type of mobile or non-mobile computing system. In a mobile computing system, computing system 100 may represent one or more components of a mobile phone, a laptop computer, a wearable device (e.g., a watch, eyeglasses, headphones, clothing), a tablet, an automobile / vehicle device, a portable gaming device, an e-reader device, and a remote control device. In a mobile computing system, computing system 100 may represent one or more components of a server, a network device (e.g., a router, a switch, a firewall), a desktop computer, a television device, an entertainment set-top device, a thermostat device, a garage door opener device, other home devices or appliances, a tabletop assistant device, a speaker device, a non-portable gaming device, and business conferencing equipment.

[0028] Computing system 100 may be part of a system-on-chip (SoC). For example, computing system 100 may be the processing component of a mobile phone, replacing a traditional central processing unit (CPU) or central controller processing architecture. The distributed processing architecture of computing system 100 may allow the mobile phone to offload work that would otherwise have to be performed by a single CPU, rather than subjecting the mobile phone to a CPU performance bottleneck.

[0029] 1 includes an application processor 102, storage 104, memory 106, and a security processor 108. These and other components of computing system 100 may communicate in various ways via buses 110, 112, and 114 and control links 116A and 116B. Computing system 100 may include more or fewer components, buses, or links than those shown in FIG.

[0030] The computing system 100 includes buses 110, 112, and 114. The application processor 102 communicates with the controller of the storage 104 by sending and receiving data over the storage bus 110, which allows the application processor 102 to read from or write to the storage 104. Similarly, the application processor 102 and the security processor 108 Each of the security processor 108 and the application processor 102 communicates with a controller of the memory 106 by exchanging data over a memory bus 112, which allows each of the security processor 108 and the application processor 102 to read from or write to the memory 106. Additionally, the security processor 108 and the application processor 102 can communicate directly by exchanging data over a host bus 114. The application processor 102 is configured to execute software including firmware, kernel programs, operating system software, applications that run within the operating system, etc.

[0031] The security processor 108 includes control links 116A and 116B to facilitate control over the application processor 102 and the memory 106. The security processor 108 can control a write-protect feature of the memory 106 by outputting control signals over the control link 116A. In some cases, the security processor 108 can monitor the write-protect feature, for example, if an attacker attempts to subvert the control link 116A. The security processor 108 can reset the application processor 102 or take it out of reset by outputting control signals over the control link 116B. For example, the security processor 108 may hold the application processor in reset until it can verify the firmware or recovery firmware, at which point the security processor takes the application processor 102 out of reset and then executes the verified firmware or recovery firmware.

[0032] 1 are merely some examples of interconnections that computing system 100 may include between application processor 102, storage 104, memory 106, and security processor 108. In other examples of computing system 100, more or fewer interfaces, links, and connections may be used between the components of computing system 100. Each of buses 110, 112, and 114 and control links 116A and 116B may include any one or combination of a variety of bus structures, such as a memory bus structure, a peripheral bus structure, a universal serial bus structure, a processor or local bus structure, or any of a variety of bus architectures, that facilitate communication between components.

[0033] Storage 104 is configured to provide computing system 100 with persistent storage of executable instructions (e.g., firmware, recovery firmware, software, applications, modules, programs, functions) and data (e.g., user data, operational data) that support the execution of the executable instructions. For example, a controller of storage 104 reads data from or writes data to storage 104 by communicating over storage bus 110 upon commands from application processor 102. In the example of FIG. 1, 104 contains two different copies (A and B) of the operating system kernel and the operating system file system, as well as other data necessary to support the installation and execution of the operating system kernel and the operating system file system.

[0034] Examples of storage 104 include volatile and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that holds executable instructions and supporting data. Storage 104 may include various implementations of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage memory in various memory device configurations. Storage 104 excludes propagating signals. Storage 104 may be a solid-state drive (SSD) or a hard disk drive (HDD).

[0035] Memory 106 represents a secure memory device separate from storage 104, being system memory (e.g., non-volatile) configured to store data necessary to execute secure boot and firmware / recovery firmware verification techniques. This memory may be a flash memory chip configured to communicate with security processor 108 and application processor 102 over memory bus 112, which may be a serial peripheral interface (SPI) bus, in which case memory 106 may be an SPI flash chip. In other examples of computing system 100, other types of non-volatile memory may be used for memory 106.

[0036] Memory 106 includes a write-protected area and an unprotected or "no write protection" area. In the write-protected area, memory 106 includes a boot descriptor, a read-only portion of the system firmware, recovery firmware, and a root key (and possibly other information, such as a recovery key for signing the recovery firmware). In the unprotected area, memory 106 includes two different copies of the read-write portion of the firmware and other data.

[0037] Holding the firmware and recovery firmware may occupy a large area of ​​memory 106. Memory 106 may be divided into "blocks." It may be desirable to divide a large area of ​​memory 106 into multiple blocks. A firmware image may span multiple blocks. Security processor 108 may hold the firmware and recovery firmware in memory 106, which may include embedding an expected hash for each block of the firmware and recovery firmware in the body of the firmware and recovery firmware, which security processor 108 may verify against the hash generated for that block. In some cases, depending on whether a full verification is performed, if the firmware or recovery firmware includes multiple blocks, security processor 108 and / or application processor 102 may generate a hash value for each block or only a subset of the multiple blocks.

[0038] The controller of memory 106 can modify or delete data stored in unprotected areas of memory 106. However, the controller cannot modify or delete data stored in protected areas of memory while write protection for memory 106 is enabled. Memory 106 may include a physical feature for disabling write protection, such as a physical button, pin, or switch. Memory 106 may also include an electronic interface for disabling write protection, such as a special programming interface, etc. Using the control link 116A between the security processor 108 and the memory 106, the security processor 108 can send a signal to disable the write protection of the memory 106, for example, to allow the computing system 100 to install a new version of the read-only portion of the firmware.

[0039] The read-only portion of the system firmware stored in memory 106 may include a body section and a header section. The header section may include information such as: • An identifying byte sequence (e.g., a "magic number") that allows firmware running on security processor 108 to identify the header from among other blocks of memory 106 and store the header and firmware at one of several different possible addresses. • A version number to associate the firmware with a particular device model and to distinguish the system firmware from other versions intended to run on other device models. A header signature applied to the header section using the public half of a verification key (e.g., stored in the security processor's firmware). The private half may be controlled at a remote entity, such as the hardware manufacturer, operating system developer, or other entity that acts to ensure that the computing system 100 runs only verifiable firmware. The private half may be stored in the security processor's firmware. A verification subkey used by security processor 108 to verify the body section of the system firmware. The secret half may be controlled at a remote entity, such as the hardware manufacturer, operating system developer, or other entity that acts to ensure that computing system 100 runs only verifiable firmware. The secret half may be stored in the security processor's firmware.

[0040] The body section of the firmware image may contain: ● A body version number that is incremented to distinguish the system firmware from other versions. ● A body signature applied to the body section using a verification subkey (e.g., stored in the header section of the system firmware). The private half may be controlled at a remote entity, such as the hardware manufacturer, operating system developer, or other entity that acts to ensure that computing system 100 runs only verifiable firmware. • The expected values ​​of the control registers of memory 106 that control the portions of memory 106 that are write-protected when memory 106 write-protection is enabled. A table of expected hash values, with each entry corresponding to a different block of memory 106 where a portion of the firmware or recovery firmware is stored. ● The number of entries in the table.

[0041] Each entry in the table of expected hash values ​​contained in the body section of the firmware can specify: The address (or offset) in memory 106 of the block. ● The size of the block (for example, in bytes). The weight assigned to the block used for validation. The weight can be expressed as a fixed point value, a logarithmic value, or any other kind of parameter. The largest weight will always cause the block to be validated with a probabilistic validation scheme. The smallest weight will always cause the block to be validated with a probabilistic validation scheme. The validation scheme can prevent a block from being validated. Weightings between the maximum and minimum weightings cause the block to be validated more or less frequently depending on whether the weighting is assigned to a value closer to the maximum weighting or closer to the minimum weighting. ●An expected hash (e.g., SHA-256) of the portion of the firmware or recovery firmware stored in the block.

[0042] The application processor 102 is the main processing complex of the computing system 100, and the security processor 108 is a dedicated processing unit of the computing system 100. The application processor 102 is primarily configured to execute instructions (e.g., firmware, recovery firmware, kernel software, operating system software) that cause the computing system 100 to perform various operations, while the security processor 108 is a support processor configured to perform security and validation operations. For example, if the computing system 100 is an SoC within a mobile computer (e.g., a mobile phone), the application processor 102 may execute instructions related to the operating system and applications that run in the operating environment provided by the operating system. The security processor 108 may interact with the application processor 102 to manage the secure boot of the operating system, perform validation of firmware before the application processor 102 executes it, or, if the computing system 100 enters recovery mode, validate recovery firmware before the application processor 102 executes it.

[0043] Each of the application processor 102 and the security processor 108 may include any combination of one or more controllers, microcontrollers, processors, microprocessors, hardware processors, hardware processing units, digital signal processors, graphics processors, graphics processing units, etc. Each of the application processor 102 and the security processor 108 may be an integrated processor and memory subsystem (e.g., implemented as an SoC) that processes computer-executable instructions to control the operation of the computing system 100. In some examples, the computing system 100 may be implemented using any one or combination of hardware or fixed logic circuitry implemented in association with processing and control circuitry generally identified as the application processor 102 and the security processor 108.

[0044] The security processor 108 maintains firmware management parameters (FWMP), security processor firmware (SPFW), generated hash values, and other data in an area of ​​non-volatile memory internal to the security processor 108. The security processor 108 verifies the security processor firmware (e.g., called "Cr50" in some systems) using an internal verification process before executing the security processor firmware.

[0045] The firmware management parameters represent configuration parameters set by the application processor 102. In some examples, the computing system 100 may require a password for the application processor 102 to change the firmware management parameters. In some examples, the password may be deleted or "forgotten" by the computing system 100 after initial configuration of the computing system 100, thereby making the firmware management parameters static. Or write it all at once.

[0046] The firmware management parameters may include various security-related settings, including whether operating system developer mode is enabled, whether security chip firmware debug mode is enabled, etc. To enable firmware and recovery firmware verification, the firmware management parameters may include one or more other options or security-related settings, including an option to force a "full verification" on each boot of computing system 100, rather than a "probabilistic verification" or a "partial verification" or "no verification" (e.g., an option that disables verification entirely). Details of the various verification modes, including full verification and probabilistic verification, are described with reference to other figures.

[0047] In some examples, security processor 108 may support handling of more options or settings through firmware management parameters. For example, firmware management parameters may include additional options to allow enterprise and developer flexibility to trade off security for complexity and usability in the verification process. For example, rather than just including options to select full verification, probabilistic verification, or no verification, firmware management parameters may include options for a user or security administrator to adjust the weighting, and therefore the odds, for checking particular blocks during probabilistic verification.

[0048] In some examples, firmware management parameters may provide further configurations of security processor 108 (e.g., settings that allow enterprises and developers more flexibility to trade off security and usability). For example, one additional setting may be a modifier to the assigned weighting attached to a particular block of firmware or recovery firmware to adjust the likelihood that the block will be checked during partial or probabilistic validation. Another firmware management parameter may be a setting that requests security processor 108 to check model-specific validation data (e.g., in the firmware's header section), optionally checking the model-specific validation data if present, and ignoring the check if absent, or ignoring the model-specific validation check entirely (which may be useful, for example, to developers).

[0049] The security processor 108 may maintain validation status information in its internal non-volatile memory, which the security processor 108 and / or application processor 102 can access to perform firmware or recovery firmware validation. For example, the security processor 108 may have one or more platform configuration registers that can be increased but not decreased for updating to a new state (without removing power). As an example, the security processor may maintain validation status information that includes: ● A "generated hash" that represents the value output from a secure hash function applied to one or more blocks of firmware or recovery firmware (eg, by the application processor 102 or security processor 108). A status indicator as to whether the firmware or recovery firmware was verifiable using the generated hash.

[0050] As previously mentioned, the security processor 108 may, in its firmware, apply a header section to the system firmware. The system firmware may also retain a verification key for verifying the header signature applied to the system firmware during compilation. For example, security processor 108 may determine a verification key (or a hash thereof for storage reduction) for verifying the header signature applied to the system firmware during compilation from the header section of the security processor firmware (e.g., the private half of the system firmware verification key is known to the compiler and applied to the system firmware during compilation). Security processor 108 may first compare the header signature applied to the system firmware against a verification key stored in the security processor firmware (e.g., embedded in the header section of the CR50) before continuing with the verification of the system firmware body. Security processor 108 may then compare the body signature applied to the system firmware against a verification sub-key stored in the body section of the system firmware before continuing with the verification of the system firmware.

[0051] The application processor 102, the security processor 108, and the memory 106 exchange data over the host bus 114 and the memory bus 112 to verify the firmware and recovery firmware loaded in the memory 106. The application processor 102 can initialize firmware management parameters held by the security processor 108, and the security processor 108 can verify the firmware according to the firmware management parameters, where the verification includes generating a hash of the firmware and comparing the generated hash with an expected hash that the security processor 108 extracts from a body section of the firmware stored in the memory 106. The security processor 108 can verify the recovery firmware, where the verification includes generating a hash of the recovery firmware (or relying on the application processor 102 to generate a hash of the recovery firmware) and comparing the generated hash with an expected hash that the security processor 108 extracts from a body section of the recovery firmware stored in the memory 106.

[0052] During operation, security processor 108 may first verify the firmware's header signature using a system firmware verification key (or a hash thereof) maintained by security processor 108. If security processor 108 determines that the header signature is incorrect, it may shut down computing system 100 to prevent computing system 100 from loading and executing incompatible or corrupted system firmware. Assuming that the header system firmware signature is verifiable using the verification key, security processor 108 may then determine whether the body signature applied to the body section of the system firmware was generated using a verification subkey. If security processor 108 determines that the body section signature is incorrect, it may shut down computing system 100 to prevent computing system 100 from loading and executing incompatible or corrupted system firmware.

[0053] Assuming that the signature of the body section can be verified using the verification subkey, security processor 108 determines an expected hash value of the block of system firmware or recovery firmware loaded into memory 106 according to the firmware management parameters. For example, security processor 108 may identify an expected hash value for each block of system firmware stored in memory 106 from the header or body of the system firmware during a full check of the system firmware. The expected hash value may remain a fixed attribute of the system firmware or may be determined in advance, for example, before compilation time. Security processor 108 may determine the expected hash value of the block of system firmware or recovery firmware loaded into memory 106 as a condition for executing the system firmware and recovery firmware. The generated hash values ​​of the blocks of system firmware and recovery firmware currently stored in 106 are compared with predetermined expected hash values ​​embedded in the system firmware and recovery firmware.

[0054] The security processor 108 may apply the hash function directly to blocks of system firmware loaded into memory 106, or the security processor 108 may rely on the application processor 102 to apply the hash function as a background or operating system task. In either case, these generated hash values ​​are compared to expected hash values. If the security processor 108 identifies a mismatch between the hashes, it may notify the application processor 102 of the verification failure to prevent the application processor 102 from executing corrupted or potentially malicious firmware or recovery firmware.

[0055] During the next boot process, security processor 108 may refresh the generated hash of the system firmware and repeat the verification process described above by replacing the first generated hash of the system firmware with the second generated hash of the system firmware. For example, if the system firmware previously failed verification, security processor 108 may re-generate the hash associated with the system firmware to enable the next verification attempt. In response to determining that the expected hash of the system firmware does not match the second hash, security processor 108 may direct application processor 102 to enter recovery mode or otherwise refrain from executing the system firmware.

[0056] In some examples, security processor 108 may control an output component, such as a light-emitting diode (LED) or speaker, of computing system 100 to indicate when firmware or recovery firmware fails verification. Security processor 108 may also use this at other times, for example, to indicate that two-factor authentication has been requested. The output component may be a dedicated output component used by security processor 108. In other cases, the output component may have dual functions (e.g., a power or charging identifier, or a keyboard or display backlight, etc.). Security processor 108 may control the output component to indicate verification failure, verification success, or other conditions. Such output components may have dual purposes (e.g., a power or charging LED, or a keyboard or display backlight, etc.) or may be intentionally integrated into computing system 100 to provide the status of firmware and recovery firmware verification. A typical control scheme for an output component may include sending a message from application processor 102 to security processor 108 to control the output component. In another example, the security processor 108 may have a pulse width modulation (PWM) capture unit on a pin to measure the output of the application processor 102, and the security processor 108 may have its own PWM unit to replicate the output to an output component. In another example, the security processor 108 may have an internal switch controllable by the application processor 102 to control the output component.

[0057] An attacker with physical access to computing system 100 can remove or block light from the output components. Security processor 108 controls the output components during the verification process to immediately turn on the engine light for a few seconds during boot, similar to how an automobile starts up. Alternatively, enabling the output component very early during the login process makes such attacks more difficult. An attacker could attempt to duplicate the behavior by wiring the output component to another processor in computing system 100, which would involve permanent and potentially visible hardware modifications.

[0058] In some cases, the security processor 108 may include a single open-drain pin connected to the write-protect signal. This is connected through a resistor to allow a debugger to override the signal during manufacturing. Removing this resistor is a reasonably feasible way for an attacker to both prevent the security processor 108 from driving the write-protect signal and from detecting its current state. The security processor 108 may also include a second pin connected to the exact same net as the first write-protect pin. This additional pin may be hidden under an inner layer of the motherboard to make this signal more difficult to interfere with. The security processor 108 may monitor this signal to determine the true state of the first write-protect pin.

[0059] An attacker would need to power down the computing system 100 to prevent the security processor 108 from detecting the change in the state of the write-protect pin. However, upon boot, the security processor 108 can rescan the system memory 106 and identify the change. An attacker could replace the system memory 106 with more advanced circuitry that allows more control of the SPI bus and stack the new memory 106 on top of that circuitry. However, this is a more difficult attack and would leave physical evidence.

[0060] Although primarily described with respect to verifying firmware executable on an application processor, the techniques for securely verifying recovery firmware apply to other processors as well. For example, in addition to the application processor 102 and the security processor 108, the computing system 100 may include other processors having firmware, such as an embedded controller (EC), a fingerprint sensor (FPMCU), other hardware units, hardware accelerator units, etc. If the security processor 108 has access to the firmware of another processor, the security processor 108 can also verify the firmware and recovery firmware in the same way that the security processor 108 verifies the firmware of the application processor 102. In this way, the other processors can benefit from the flexibility and security that secure verification provides.

[0061] FIG. 2 is a flowchart illustrating an example of the operation of a security processor configured to verify firmware. FIG. 2B is a flowchart illustrating an example of the operation of a security processor configured to verify recovery firmware. Operation 200 includes steps 202-214. Operation 200 may be performed in a different order than shown in FIG. 2 or may include more or fewer operations than shown. By performing operation 200, security processor 108 can verify system firmware stored in memory 106.

[0062] 2, security processor 108 may perform operation 200 during each power-on or reset of computing system 100. Security processor 108 may perform operation 200 in response to a transition from a sleep mode. Security processor 108 may perform operation 200 in response to a reset of security processor 108 (e.g., when a user provides a particular key combination that triggers a reset of security processor 108).

[0063] At 202, when security processor 108 is powered on, booted, or reset, the security processor (SP) verifies, loads, and executes its security processor firmware (SPFW). At 204, security processor 108 maintains firmware management parameters including options for verifying firmware. In other words, security processor 108 may be configured to verify system firmware or recovery firmware based on information inferred from the firmware management parameters, for example, by performing a “full verification” of the recovery firmware at each boot of computing system 100, performing a “probabilistic verification” of the recovery firmware, or not verifying the recovery firmware. Security processor 108 can store status information and flags as firmware management parameters that security processor 108 uses to determine the level of verification (e.g., full verification, partial or probabilistic verification, or no verification) and to determine the results of previous verification processes performed by application processor 102 and / or security processor 108.

[0064] The firmware management parameters may be initialized by the application processor 102 upon initial boot of the computing system 100. When the security processor 108 performs a full verification of the recovery firmware, it verifies the entire recovery firmware, including comparing the hash generated for each block of the firmware with the corresponding expected hash recorded in the body section of the firmware. If the security processor 108 does not perform verification of the recovery firmware, it refrains from generating hashes for the firmware (e.g., useful for debugging).

[0065] Some blocks of firmware may not affect the functionality of computing system 100. Skipping certain blocks at boot time or during recovery allows computing system 100 to operate in a wider range of scenarios without significantly reducing the security of computing system 100. Thus, a table of weights within the firmware may be associated with each firmware block and specify a weighting factor that is used to determine whether the block can be skipped.

[0066] In some examples, some blocks may be less frequently used when recovering from deep sleep or entering a low-power suspend mode in which the application processor and / or security processor may be shut down. There are some blocks used by normal boot that do not affect resuming from deep sleep or entering a low-power suspend mode, such as root keys or other parts of the firmware. Skipping these blocks during resume can improve resume time without significantly reducing security.

[0067] At 206, the security processor determines whether the computing system 100 is in a recovery mode or in a normal, non-recovery mode. For example, the security processor 108 may determine whether a user of the computing system 100 manually selects recovery mode in response to detecting a particular input on a keyboard or other input component of the computing system 100. In other cases, the security processor 108 may enter recovery mode and begin verifying the recovery firmware in response to receiving a request from the application processor 102 to verify the recovery firmware. The application processor 102 may check the recovery firmware before execution, and in response to detecting a mismatch between the generated hash of the recovery firmware and the expected hash, the application processor 102 may communicate a command to the security processor 108 (e.g., via the host bus 114) to enter recovery mode.

[0068] In response to a decision to enter recovery mode, security processor 108 performs operation 300 shown in Figure 3. Alternatively, in response to a decision to enter non-recovery mode, security processor continues by performing step 208 of automatically verifying system firmware based on firmware management parameters maintained by security processor 108.

[0069] At 208A, security processor 108 verifies the signature applied to the system firmware against the system firmware verification key and subkeys. For example, security processor 108 may use a verification key maintained in the header section of the security processor firmware (or maintained elsewhere within security processor 108) to verify the firmware's header signature. The private half of the system verification key may be maintained by the operating system developer or manufacturer of computing system 100 and provided to official compilers used to compile and sign system firmware intended to run on application processor 102.

[0070] In response to verifying the header signature, security processor 108 can verify the body signature applied to the system firmware using a verification subkey from the header section of the system firmware. The private half of the system verification subkey may be held by the operating system developer or manufacturer of computing system 100 and provided to an official compiler used to compile and sign the body of system firmware intended to run on application processor 102.

[0071] If security processor 108 determines that the system firmware was not signed using the appropriate verification key and verification sub-key, the system firmware verification check fails and security processor 108 proceeds to step 210. Alternatively, security processor 108 continues to verify the firmware in steps 208B-208D in response to verification of the signature applied to the system firmware.

[0072] Checking the signature as part of the firmware verification process may be more taxing on the resources of security processor 108 than simply checking the hash in steps 208C-208D. Security processor 108 may store the intermediate value (e.g., the signature hash) generated in step 208 so that security processor 108 can perform a faster signature check the next time it performs operation 200.

[0073] Security processor 108 may provide "rollback protection." By storing the highest version number of verified recovery firmware that security processor 108 has checked, security processor 108 can output a notification to alert computing system 100 when an older version having a version number lower than this highest version number is being checked. For example, if the previous version checked by security processor 108 was version B, but the header section of the firmware indicates version A, security processor 108 may , it may set a flag in its internal register, or it may signal to the application processor 102 a warning (e.g., output via a user interface) that the firmware has been "rolled back" to the previous version.

[0074] Based on the firmware management parameters, security processor 108 performs steps 208B-208D for each block of system firmware if a full verification is performed, for only some of the blocks of system firmware if a partial or probabilistic verification is performed, or for none of the blocks of system firmware if the firmware management parameters indicate that verification can be skipped.

[0075] At 208B, security processor 108 hashes the system firmware based on the firmware management parameters to determine a generated hash of the system firmware. For example, security processor 108 may load one or more of the individual blocks of the system firmware from memory 106 and apply a hash function to the blocks. The security processor may retain the result of the hash function in a register or internal memory for later comparison with an expected hash value.

[0076] At 208C, security processor 108 determines an expected hash of the system firmware. For example, computing system 100 may require that system firmware include a dedicated discoverable area (e.g., part of the body section) for recording expected hash values ​​of blocks of system firmware held in memory 106. Because the firmware and recovery firmware are typically constructed during a comprehensive construction process that includes compiling the firmware and recovery firmware together as part of the firmware image, the expected hash value embedded in the system firmware is typically sufficient to verify the recovery firmware. Security processor 108 can determine the expected hash by extracting a specific value from a predetermined area of ​​the body section of the firmware.

[0077] At 208D, security processor 108 determines whether the expected hash and the generated hash match. If the hashes match, security processor 108 verifies the firmware and updates a status register maintained by security processor 108 to reflect that the firmware was verified. Similarly, if the hashes do not match, security processor 108 updates the status register to indicate that the firmware was unverifiable.

[0078] At 210, the security processor determines whether the firmware was successfully verified. If the firmware fails the verification check at step 208 and is not verified, at 212, the security processor 108 instructs the computing system 100 to terminate boot and power down. If the firmware passes the verification check at step 208 and is verified, at 214, the security processor 108 instructs the computing system 100 to continue the boot process by releasing the application processor 102 from reset and allowing the application processor 102 to execute the firmware.

[0079] 3 is a flowchart illustrating an example of the operation of a security processor configured to verify recovery firmware. Operation 300 includes steps 302-308. Operation 300 may be performed in a different order than shown in FIG. 3 or may include more or fewer operations than shown. By performing operation 300, security processor 108 verifies the recovery firmware stored in memory 106. The software can be verified.

[0080] In FIG. 3, security processor 108 may perform operation 300 in response to security processor determining in step 206 of operation 200 that computing system 100 has entered recovery mode.

[0081] Computing system 100 can enter recovery mode in a variety of ways. For example, computing system 100 can enter recovery mode in response to application processor 102 determining that a user has manually requested entry into recovery mode (e.g., by detecting the pressing of a particular key on a keyboard of computing system 100 / by detecting a different signal from an input component of computing system 100). Computing system 100 can enter recovery mode if, during execution of the read-only portion of the system firmware, application processor 102 determines that the signature applied to the read-write portion of the system firmware is incorrect. The read-only portion of the system firmware can check the signature using a root key stored in a write-protected portion of memory 106.

[0082] Before entering recovery mode, the operating system of computing system 100 may verify the recovery firmware and store an expected hash of the recovery firmware in memory 106, for example, as a background task. During a normal boot, computing system 100 does not need to verify the recovery firmware because the recovery firmware is not executed during the initial boot pass. Application processor 102 can boot completely to the operating system without verifying the recovery firmware unless instructed by a user to enter recovery mode.

[0083] The operating system may verify the recovery firmware in the background during normal operation to prevent an attacker from disabling the recovery firmware, which may go unnoticed by the computing system 100 until the normal boot path fails. While this may not necessarily prevent an attacker from causing the computing system 100 to execute unverified code, having the operating system check the integrity of the recovery firmware in the background at least allows the computing system 100 to proactively detect potential attackers prior to rebooting. In some cases, developers may be testing new firmware versions and want to be notified or warned in advance that the computing system 100 may be running bad or unverified firmware. This may give the user the option of not running the recovery firmware or repairing the firmware before the computing system 100 executes untrusted recovery firmware.

[0084] The operating system or other service or thread running on the application processor 102 may, for various reasons, request the security processor 108 to enter recovery mode to revalidate the recovery firmware. The operating system or other service or thread communicates the revalidation request by communicating with the security processor 108 over the host bus 112.

[0085] The application processor 102 is typically more powerful and faster than the security processor 108, providing faster processing speeds, greater bandwidth, and more power. The greater the computing system 100, the more powerful the application processor 102 can be to first verify the recovery firmware faster than the security processor 108.

[0086] During execution, the system firmware may maintain an expected hash of the recovery firmware in system memory, initially determined on a previous boot. Because the recovery firmware and the system firmware (including the read-only portions) are constructed together contemporaneously, the hash may provide a sufficient reference point to determine the integrity of the recovery firmware (e.g., whether the recovery firmware has been modified since it was last used). Upon determining that computing system 100 is in recovery mode, the system firmware instructs application processor 102 to compare the expected hash of the recovery firmware with the hash of the application processor-generated recovery firmware loaded in memory 106.

[0087] In response to determining that the expected hash and the generated hash match, application processor 102 executes the recovery firmware. In response to determining that the recovery firmware failed the check and that the signature of the recovery firmware is bad or the expected hash and the generated hash do not match, application processor 102 requests that security processor 108 verify the recovery firmware, thereby enabling computing system 100 to execute the recovery firmware and operate in recovery mode.

[0088] At 302, in response to determining that computing system 100 has entered recovery mode at 206, security processor 108 optionally automatically validates the recovery firmware according to firmware management parameters used during validation of system firmware. For example, by default, security processor 108 may perform a full validation of the recovery firmware, checking each block of the recovery firmware loaded into memory 106. In other cases, if some blocks of the recovery firmware are unlikely to cause a problem if corrupted, security processor 108 may perform a probabilistic or partial validation of the recovery firmware, skipping blocks least likely to cause a catastrophic failure. Security processor 108 may determine whether to perform a full or partial check of the recovery firmware based on information in the firmware management parameters.

[0089] For probabilistic verification, each block may be assigned a weighting that is then compared to a dynamically generated threshold during the verification process (e.g., during operations 300 or 200). The dynamically generated threshold may correspond to the output from a random number generator. If the assigned weighting exceeds the dynamic threshold for a block, security processor 108 performs steps 302A-302D to auto-verify the block, following a process similar to that outlined above with respect to steps 208A-208D. If the assigned weighting does not exceed the dynamic threshold, security processor 108 may skip the block and not consider whether the expected hash for that block matches the generated hash.

[0090] At 302A, security processor 108 verifies the signature applied to the system firmware against the system firmware verification key and subkey. In response to verifying the header signature, security processor 108 may verify the body signature applied to the system firmware using the verification subkey from the header section of the system firmware. If security processor 108 determines that the system firmware was not signed using the appropriate verification key and verification subkey, security processor 108 may verify the body signature applied to the system firmware. If the firmware verification check fails, the process proceeds to step 304. Alternatively, security processor 108 may subsequently verify the recovery firmware in steps 302B-302D in response to verifying the signature applied to the system firmware.

[0091] Typically, security processor 108 performs steps 302B-302D for each block of recovery firmware, since full verification is necessary to maximize detection of corrupted blocks of recovery firmware. However, if the firmware management parameters indicate no verification or only partial verification, security processor 108 may be configured to perform partial or no verification of the recovery firmware. In such cases, security processor 108 selectively performs steps 302B-302D for blocks of recovery firmware that have pre-assigned weights that, when applied to the random number, cause the random number to meet a threshold.

[0092] At 302B, security processor 108 may hash each block of the recovery firmware and store the results of the hash function in a register or internal memory for later comparison with the expected hash value. At 302C, security processor 108 determines the corresponding expected hash for each block of the recovery firmware, as originally determined by the application processor during its initial check of the recovery firmware. At 302D, security processor 108 determines whether the expected hash and the generated hash match. If the hashes match, security processor 108 verifies the recovery firmware and updates a status register maintained by security processor 108 to reflect that the firmware has been verified. Similarly, if the hashes do not match, security processor 108 updates the status register to indicate that the recovery firmware was unverifiable.

[0093] At 304, the security processor determines whether the recovery firmware was successfully verified. At 306, if the recovery firmware fails the verification check at step 304 and is not verified, the security processor 108 instructs the computing system 100 to terminate boot and power down. At 308, if the recovery firmware passes the verification check at step 304 and is verified, the security processor 108 instructs the computing system 100 to continue the recovery process by releasing the application processor 102 from reset and allowing the application processor 102 to execute the recovery firmware.

[0094] As previously mentioned, security processor 108 can control the write protection for memory 106 via control link 116A. An attacker of computing system 100 could attempt to override the write protection signal controlled by security processor 108 by, for example, applying voltage to a physical write protection feature on memory 106, cutting wires, or severing the link between the write protection signal and security processor 108. Security processor 108 monitors whether the write protection for memory 106 has changed and, if so, can set a flag or otherwise indicate that the write protection of memory 106 has changed and information stored in memory 106 may have changed. For example, security processor 108 may change a value in an internal register or internal memory monitored by a component of an operating system executing on application processor 102. Accordingly, security processor 108 can initiate a recovery process, including performing operation 300, when security processor 108 experiences a recovery condition.

[0095] For example, security processor 108 may skip step 302, including sub-steps 302A-302D, entirely if the firmware management parameters indicate that block checking is disabled. Thus, a prerequisite for performing operation 300 may include determining whether block checking is disabled, full block checking is enabled, or probabilistic block checking is enabled. Thus, security processor 108 may comply with the checking scheme defined in the firmware management parameters by performing step 302, including sub-steps 302A-302D.

[0096] Security processor 108 may load and check the recovery firmware, assuming block checking is not disabled. Security processor 108 may perform a full check, for example, performing operations 204-210 for each block of the recovery firmware by comparing each block to an expected hash. Security processor 108 may also perform a probabilistic check, for example, performing operations 204-210 for only a portion of the blocks. Security processor 108 may perform a probabilistic check by hashing and comparing only blocks of the recovery firmware that meet a threshold for checking or skipping the block.

[0097] In some cases, security processor 108 may perform firmware and firmware verification even without receiving a request to do so. For example, security processor 108 may be programmed to verify firmware or recovery firmware (e.g., periodically, according to a schedule, or according to other conditions or rules) by automatically performing operations 200 or 300 without waiting for a signal from application processor 102.

[0098] 4 is a flowchart illustrating example operations of a security processor configured to perform probabilistic or partial verification of firmware or recovery firmware. Operations 400 include operations 402-416. Operations 400 may be performed in a different order than shown in FIG. 4 or may include more or fewer operations than shown. By performing operations 400, security processor 108 can probabilistically verify firmware or recovery firmware stored in memory 106.

[0099] To increase the speed and efficiency of firmware or recovery firmware verification without sacrificing security, security processor 108 may probabilistically verify or only partially verify the firmware or recovery firmware. While security processor 108 can perform a full verification and check all blocks of the firmware or recovery firmware, with probabilistic verification, security processor 108 typically checks only a portion of the firmware or recovery firmware.

[0100] For example, security processor 108 may rely on a corresponding pre-assigned weighting (e.g., in the firmware header) for each block of firmware or recovery firmware. Security processor 108 may dynamically generate a threshold for each block and compare this threshold with the pre-assigned weighting for that block as a condition for validating the block. For example, security processor 108 may implement a random number generator that outputs a value between 0 and 1 for each block of firmware or recovery firmware. The dynamic threshold output from the random number generator is compared to the pre-assigned weighting (e.g., in this example, also a value between 0 and 1). ), security processor 108 skips the block and continues to check subsequent blocks. In response to determining that the dynamic threshold does not exceed the pre-assigned weighting, security processor 108 checks the block (e.g., by comparing the expected hash of the block with the generated hash of the block).

[0101] At 402, security processor 108 determines a probabilistic validation threshold for the block. This threshold represents a value between the maximum and minimum weightings assigned to the block of recovery firmware. This threshold may be fixed or dynamic, for example, based on the context of computing system 100 or other conditions. Security processor 108 may determine the threshold by analyzing the firmware to derive the maximum and minimum weightings among all entries in a table in the body section of the firmware. Security processor 108 may use a random number generator to determine the dynamic threshold as any value greater than or equal to the maximum weighting and less than or equal to the minimum weighting.

[0102] At 404, the security processor determines a weighting for the block. For example, as described above, the body section of the firmware may specify a table of weights assigned to each block or other logical section of the firmware or recovery firmware. Each weight may indicate a relative importance for verification purposes compared to other blocks. The weighting may be a fixed point value, a logarithmic value, or some other type of parameter with a maximum and minimum value.

[0103] During probabilistic verification, a higher weighting may cause a block to be verified more frequently than a block with a lower weighting. Each block may be assigned a weighting when the firmware is generated, or the weightings may be adjusted, for example, in a debug mode where a developer has access to the weightings via inputs to the application processor 102. In some examples (e.g., through a special programming channel), the weights may be adjusted so that different verification schemes can be performed by changing the weightings of body sections of the firmware.

[0104] At 406, security processor 108 determines whether the weight assigned to the block exceeds the probabilistic verification threshold. Blocks with weights that do not exceed the threshold are skipped at 408, and at 410, security processor 108 checks whether this is the last block being checked. If not, security processor returns to step 402; if the block is the last block, security processor ends the probabilistic check at C.

[0105] If the security processor determines at 406 that the weight assigned to the block exceeds the probabilistic verification threshold for the block, then at 412 the security processor 108 determines whether the hash generated for the block matches the expected hash for the block. In response to determining at 414 that the hash value generated for the block and the recorded hash value do not match, the security processor terminates operation 400 and sets a status register to indicate that the firmware or recovery firmware is not verifiable, or otherwise signals the application processor 102. In response to determining at 416 that the hash generated for the block matches the expected hash, the security processor 108 sets a status register to indicate that the firmware or recovery firmware is verifiable. At 410, the security processor If the security processor 108 determines that this block is the last block to be checked after setting the status register to indicate that the firmware or recovery firmware is verifiable, the security processor 108 sends a signal to the application processor 102 indicating that the firmware or recovery firmware is verifiable.

[0106] In some cases, security processor 108 may change the probabilistic verification threshold or use different weightings assigned to blocks of firmware or recovery firmware depending on whether security processor 108 is verifying firmware, verifying recovery firmware, booting from deep sleep, or booting from reset. For example, in some cases, security processor 108 may check all blocks of recovery firmware during a recovery boot, and the weighting assigned to each block specifying the likelihood of checking that block may be the same for all other boot or resume operations.

[0107] There are some blocks used by normal boot that will not affect recovery operations, such as blocks in the firmware or recovery firmware containing the root key. Skipping these blocks during recovery boot will allow recovery from a wider range of scenarios without reducing the security of the recovery operations. A validation data table maintained in firmware can additionally specify the likelihood of checking a block during recovery boot, or a flag indicating that the block is not used by recovery.

[0108] When the application processor 102 executes the recovery firmware, it can still check any blocks that the security processor 108 skipped and optionally display a warning to the user, which can be useful for diagnosing problems with normal mode boot without blocking the recovery boot.

[0109] There are some blocks used by normal boot that do not affect resume from deep sleep, such as the root key or parts of the read-only firmware that verify the read-write parts of the firmware. Skipping these blocks on resume can improve resume times without reducing security.

[0110]

[0013] Figure 5 is a conceptual diagram illustrating a computing device configured to perform secure verification of firmware and recovery firmware. Figure 5 illustrates an example computing device 500, which may be any type of computing device, client device, mobile phone, tablet, wearable, vehicle, communication, entertainment, gaming, media playback, and / or other type of device.

[0111] The computing device 500 includes a communication device 510 that enables wired and / or wireless communication of device data 506, such as data communicated between devices in a WLAN, data being received, data scheduled for broadcast, data packets of data, data synchronized between devices, etc. The device data may include any type of communication data, as well as audio, video, and / or image data generated by applications executing on the device. The communication device 510 may also include a transceiver for cellular telephone communication and / or network data communication.

[0112] The computing device 500 also includes an input / output (I / O) interface 512, such as a data network interface, that provides a connection and / or communication link between the device, a data network (e.g., a mesh network, an external network, etc.), and other devices. The I / O interface can be used to couple the device to any type of component, peripheral, and / or accessory device. The I / O interface also includes a data input port through which any type of data, media content, and / or input can be received, such as user input to the device, any type of communication data, and audio, video, and / or image data received from any content and / or data source.

[0113] Computing device 500 also includes an audio and / or video system 518 that generates audio data for audio device 520 and / or generates display data for display device 522. Audio device 520 and / or display device 522 include any device that processes, displays, and / or otherwise renders audio, video, display, and / or image data, such as the image content of a digital photograph. In an implementation, the audio device and / or display device are integrated components of example computing device 500. Alternatively, the audio device and / or display device are external peripheral components of the example device.

[0114] The computing device 500 includes a processing system 514 that includes an application processor 502 as an example of the processor 102 and a security processor 508 as an example of the security processor 108. Components of the processing system 514 may be implemented at least in part in hardware, e.g., using any type of microprocessor, controller, or the like that processes executable instructions. The processing system may include components of integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and may include processor and memory systems implemented in silicon and / or hardware in other implementations, e.g., as a system-on-a-chip (SoC). The device may be implemented in any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented in processing and control circuits. The computing device 500 may further include any type of system bus or other data and command transfer system that couples various components within the device. The system bus may include any one or combination of a variety of bus structures and architectures and control and data lines.

[0115] The computing device 500 also includes computer-readable storage memory 516, such as a data storage device that is accessible by the computing device and provides persistent storage of data and executable instructions (e.g., software applications, modules, programs, functions, etc.). Computer-readable storage memory as described herein excludes propagating signals. Examples of computer-readable storage memory include volatile and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that holds data for computing device access. Computer-readable storage memory may include various implementations of RAM, ROM, flash memory, and other types of storage memory in various memory device configurations.

[0116] The computer-readable storage memory 516 is an example of the storage 104. The computing device 500 includes a storage component 504 and a memory component 506, which is an example of memory 106. The storage component 504 may store a kernel, a root file system, or other operating system-related software. The memory 506 may store firmware and recovery firmware for booting the computing device 500 as a prerequisite for loading and executing the kernel, the root file system, and other operating system-related software.

[0117] The computing device 500 is configured to perform secure verification of the firmware and recovery firmware stored in memory 506. The security processor 508 compares generated hash values ​​associated with the firmware and recovery firmware with expected hash values ​​(e.g., stored in memory 506). If the generated hash values ​​and the expected hash values ​​match, the application processor 502 may instruct the application processor to execute the verified firmware or recovery firmware. However, if the generated hash values ​​and the expected hash values ​​do not match, the application processor 502 may refrain from executing the firmware or recovery firmware, the computing device 500 may shut down, or, as previously described, the application processor 502 may instruct the security processor 508 to reverify the firmware or recovery firmware.

[0118] For ease of explanation, the following scenarios consider several use cases for computing device 500, which is a laptop. A typical user may purchase computing device 500 and initially log in to computing device 500. If the user subscribes to a remote (e.g., two-factor) authentication service via a second device (e.g., a mobile phone), the second device can verify whether the user is attempting to log in to a fully verified laptop in response to a remote request by computing device 500 to perform firmware or recovery firmware verification. The user can control whether the service requires verification, for example, by subscribing to an option that says, "I only want to be allowed to log in on devices with fully verified firmware." In this way, even if an attacker who enables developer mode can install a corrupted version of firmware or reset the user's security credentials on computing device 500, when the user logs in to computing device 500 after the attack, the service will recognize computing device 500 as a new device and undergo the two-factor authentication process.

[0119] During the enterprise registration process, the computing device 500 may perform the following steps to ensure the integrity of the device using the described verification techniques: The registration server responsible for the enterprise registration process may query the security processor 508 to obtain the motherboard identifier (e.g., BoardID) and the verification result obtained by the security processor 508 (e.g., generated hash value, verification result).

[0120] If the generated hash value or verification result indicates that fewer than all blocks of the firmware or recovery firmware have been verified, the registration server may instruct the application processor 502 to reset and reboot by performing a full firmware verification, thus ensuring that only fully verified firmware is allowed to participate in the registration process.

[0121] If the motherboard identifier is not a certified serial number or generated hash value If is not the expected hash value stored at the registration server, the registration server may refuse to register the computing device 500 on the enterprise network (e.g., this may occur if a pre-manufactured device was somehow shipped to a consumer).

[0122] In response to verifying the firmware, the registration server obtains the user's login credentials and performs two-factor authentication or some other authentication process to complete the log in. In this way, the user and the registration server can ensure that the computing device 500 is a fully verified device before providing login credentials that could be snooped and shared with an attacker if the computing device 500 is compromised.

[0123] In some instances, the registration server may determine whether future system boots are part of an enterprise policyThe registration server may automatically configure firmware management parameters of the computing device 500 to ensure that the firmware management parameters are verified (or not) in accordance with the security processor 508. In some cases, the registration server may terminate registration unless the security processor 508 can accurately verify the firmware management parameters. Additionally, the registration server may de-register the computing device 500 by simply erasing the firmware management parameters. While various preferred embodiments of the present disclosure have been described in the above description and illustrated in the drawings, it should be clearly understood that the present disclosure is not limited thereto and may be variously embodied so as to be carried out within the scope of the following claims. From the above description, it will be apparent that various modifications can be made without departing from the spirit and scope of the present disclosure, as defined by the scope of the following claims.

[0124] For developers, the computing device 500 can be configured to allow developers to modify the operating system and / or firmware at will. The computing device 500 can automatically enter an operating system developer mode via an operating system task. The operating system developer mode may allow modifications to the operating system but not to the firmware or recovery firmware. In firmware developer mode, the computing device 500 can erase and modify the contents of the memory 506, including write-protected portions. In any of the operating system developer modes, the security processor 508 may erase secrets stored in its non-volatile memory, including decryption keys for data stored in the storage 504. In some cases, firmware management parameters of the security processor 508 may prevent modifications to the firmware or secrets controlled by the security processor 508. However, in other cases, the computing device 500 may be configured to receive and write custom firmware management parameters to the security processor 508 when an operating system or firmware developer mode is enabled. Following a change in firmware management parameters, computing device 500 may be configured to refrain from performing verification of the firmware or recovery firmware (e.g., by avoiding full or probabilistic verification checks), but security processor 508 may report that the firmware or recovery firmware was not checked, so that new users logging into computing device 500 may still be alerted to the unverified device (e.g., by two-factor authentication).

[0125] Any owner user of computing device 500 may have the ability to configure firmware management parameters for computing device 500, at least during the initial login. In this way, a typical user may configure firmware management parameters for the operating system or disables firmware developer mode and optionally allows you to select between different boot verification levels (e.g., specify a higher or lower level of boot verification).

[0126] In some examples, computing device 500 provides an interface through which a user can specify a password required to change firmware management parameters. In other cases, computing device 500 may generate a password for a user and upload the password to the user's account (e.g., in a cloud computing environment) so that the user can retrieve the password whenever they want if they want to change firmware management parameters.

[0127] When computing device 500 is manufactured, the manufacturer may configure computing device 500 to store a model-specific BoardID in non-volatile memory of security processor 108. The BoardID may be used to lock a release of security processor firmware to a specific device model, unlock a remote access server, etc. The expected BoardID may be included in a header of a read-only portion of the firmware. Computing device 500 may be configured to verify that the expected BoardID matches a BoardID pre-programmed into security processor 508.

[0128] Other data stored in memory 506 may vary from device to device and may be verified in a manner similar to how firmware or recovery firmware is verified. Security processor 508 may also be configured to protect this data, for example, to prevent security processor 508 from being swapped between boards or to prevent a device from modifying this data to appear to be in an incorrect configuration.

[0129] The other data may include a header section with a different identifying byte sequence and no subkey, and a body section containing model-specific data. Security processor 508 may verify a hardware identifier, service tag, wireless access node calibration or serial data, etc. Security processor 508 may compare the generated hash of the other data to an expected hash and verify the other data if the two values ​​match.

[0130] During manufacturing, this device-specific verification data can be stored in a write-protectable area of ​​memory 506 just before write protection is enabled in a factory finalization step. There may be no signature on the header or body, as the other data described above varies from device to device and only needs to be checked to ensure that the data has not been modified since manufacturing of computing device 500. A hash of this data can be stored in security processor 508 during the factory finalization step after the data has been written to memory 506.

[0131] While various preferred embodiments of the present disclosure have been described in the above description and shown in the drawings, it should be clearly understood that the present disclosure is not limited thereto and can be variously embodied as carried out within the scope of the following claims. From the above description, it will be apparent that various changes can be made without departing from the spirit and scope of the present disclosure, which is defined by the following claims.

Claims

1. 1. A computing system comprising: an application processor; a memory containing firmware of the computing system, the firmware including a plurality of blocks of the firmware, the computing system further comprising: a security processor, the security processor verifying the firmware as a condition for the application processor to execute the firmware; determining respective probabilistic verification thresholds for the plurality of blocks of the firmware using a random number generator; determining respective weighting values ​​for the plurality of blocks of the firmware; determining not to verify a first block of the firmware in response to a corresponding first weighted value of the first block of the plurality of blocks of the firmware not exceeding a corresponding first probabilistic threshold; and verifying the second block of the firmware based on whether an expected hash value determined for the second block of the firmware matches a hash value generated for the second block of the firmware in response to a corresponding second weighted value for the second block of the firmware being greater than a corresponding second probabilistic threshold. a computing system configured to perform the

2. 1. A computing system comprising: an application processor; a memory containing firmware of the computing system, the firmware including a plurality of blocks of the firmware, the computing system further comprising: a security processor, the security processor verifying the firmware as a condition for the application processor to execute the firmware; determining respective probabilistic verification thresholds for the plurality of blocks of the firmware; determining respective weighting values ​​for the plurality of blocks of the firmware; determining not to verify a first block of the firmware in response to a corresponding first weighted value of the first block of the plurality of blocks of the firmware not exceeding a corresponding first probabilistic threshold; and verifying the second block of the firmware based on whether an expected hash value determined for the second block of the firmware matches a hash value generated for the second block of the firmware in response to a corresponding second weighted value for the second block of the firmware being greater than a corresponding second probabilistic threshold. and The security processor is further configured to dynamically determine the corresponding probabilistic verification threshold for each block of the plurality of blocks of the firmware.

3. The security processor further performs verification of the firmware by: by setting the status of the firmware to a verifiable status in response to the expected hash value determined for the second block of the firmware matching the generated hash value for the second block of the firmware; or setting the status of the firmware to an unverifiable status in response to the expected hash value determined for the second block of the firmware not matching the generated hash value for the second block of the firmware.

3. A computing system according to claim 1 or 2, configured to:

4. the expected hash value determined for the second block of the firmware matches the generated hash value for the second block of the firmware, and the security processor further performs verification of the firmware by: determining whether the second block of firmware is the last block of the plurality of blocks of firmware; Indicating to the application processor that the firmware is verified in response to the status of the firmware being set as a verifiable status and the second block of the firmware being the last block of the plurality of blocks of the firmware. The computing system of claim 3 , configured to:

5. 5. The computing system of claim 1, wherein the security processor is further configured to determine the respective weighting values ​​by accessing a body section of the firmware to obtain the respective weighting values ​​assigned to the plurality of blocks of the firmware.

6. 6. The computing system of claim 1, wherein the security processor is further configured to determine the expected hash value for the second block of the firmware by accessing a body section of the firmware to obtain the expected hash value.

7. The security processor is further configured to obtain the expected hash value for the second block of the firmware by accessing a table in the body section of the firmware, the table including, for each block of the plurality of blocks of the firmware, a corresponding entry, the entry comprising: a corresponding address or offset for said block of firmware; the corresponding size of said block of said firmware; a corresponding expected hash value for the block of firmware; or The corresponding weighting value assigned to the block of firmware The computing system of claim 6 , comprising:

8. 8. The computing system of claim 1, wherein the security processor is further configured to verify the second block of firmware by generating the generated hash value for the second block of firmware.

9. 9. The computing system of claim 1, wherein the security processor is further configured to determine the respective probabilistic verification thresholds for the plurality of blocks of the firmware based on a maximum weighted value and a minimum weighted value among the respective weighted values ​​for the plurality of blocks of the firmware.

10. the firmware verified by the security processor includes system firmware of the computing system, and the memory further includes recovery firmware; or The computing system of any one of claims 1 to 9, wherein the firmware verified by the security processor includes recovery firmware of the computing system, and the memory further includes system firmware.

11. 11. The computing system of claim 10, wherein the security processor is configured to maintain firmware management parameters including options for directing the security processor in validating the firmware or the recovery firmware.

12. 12. The computing system of claim 11, wherein the security processor maintains the firmware management parameters in a write-protected portion of the security processor's internal memory.

13. A method for verifying firmware of a computing system, executed by a security processor of the computing system, the firmware including a plurality of blocks, the method comprising: determining respective probabilistic verification thresholds for the plurality of blocks of the firmware using a random number generator; determining respective weighting values ​​for the plurality of blocks of the firmware; determining not to verify a first block of the firmware in response to a corresponding first weighted value of the first block of the plurality of blocks of the firmware not exceeding a corresponding first probabilistic threshold; and in response to a corresponding second weighting value of a second block of the plurality of blocks of the firmware being greater than a corresponding second probabilistic threshold, verifying the second block of the firmware based on whether an expected hash value determined for the second block of the firmware matches a hash value generated for the second block of the firmware.

14. A method for verifying firmware of a computing system, executed by a security processor of the computing system, the firmware including a plurality of blocks, the method comprising: determining respective probabilistic verification thresholds for the plurality of blocks of the firmware; determining respective weighting values ​​for the plurality of blocks of the firmware; determining not to verify a first block of the firmware in response to a corresponding first weighted value of the first block of the plurality of blocks of the firmware not exceeding a corresponding first probabilistic threshold; responsive to a corresponding second weighted value of a second block of the plurality of blocks of firmware being greater than a corresponding second probabilistic threshold, verifying the second block of firmware based on whether an expected hash value determined for the second block of firmware matches a hash value generated for the second block of firmware; and dynamically determining the corresponding probabilistic verification threshold for each block of the plurality of blocks of the firmware.

15. A computer program comprising instructions which, when executed, cause a security processor of a computing system to perform the method of claim 13 or 14.

Images