Secure verification of firmware

Abstract

The invention relates to secure verification of firmware. A computing system is described for securely verifying system firmware and recovering firmware to ensure system integrity without relying on a proprietary verification process of manufacture, hardware-specific keys, or intrinsic write protection features of system memory. In one embodiment, a computing system relies on a security processor that maintains firmware management parameters that define a process for verifying and recovering firmware independent of a mask ROM (Read Only Memory) verification process of an integrated circuit manufacturer. The security processor ensures that the firmware or recovery firmware is properly signed and coincides with a previously executed version, or if different, generates a verification result (e.g., a generated hash value) that coincides with an expected result embedded in the firmware at the time of compilation. In this manner, the computing system improves availability, customization, and user control on firmware executing within the computing system and restoring firmware.

Description

[0001] Description of the case

[0002] This application is a divisional application of Chinese invention patent application No. 201980079865.2, filed on June 10, 2019. Background Art

[0003] Some computing systems execute system firmware as part of the "boot" process after power is applied or after a reset. Some computing systems may execute "recovery" firmware instead of system firmware to return to a stable, recovered state. For security purposes, computing systems may maintain portions of system firmware and recovery firmware in persistent, write-protected areas of system memory that can only be overwritten with concurrent physical access to system memory. Some computing systems further perform a manufacturer's verification process to ensure firmware and recovery firmware integrity, in some cases using hardware-specific verification keys (e.g., burned into the fuses of an application processor) to ensure that the system firmware is from an official source.

[0004] Therefore, security and integrity may depend on proprietary authentication processes of the manufacturer, including the ability to manage hardware-specific authentication keys and the ability of the computing system to write-protect system memory. The write-protect feature may be defeated, for example, by a user with physical access to the system memory. Over-reliance on write-protect features and hardware-specific authentication keys assigned to hardware during manufacturing may unnecessarily limit the availability, customization, and user control of system firmware and recovery firmware executed by the computing system. Summary of the invention

[0005] A computing system is described for securely verifying system firmware and recovery firmware to ensure system integrity without relying on manufacturing proprietary verification processes, 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 the integrated circuit manufacturer's mask ROM (read-only memory) verification process. The security processor ensures that the firmware or recovery firmware is properly signed and consistent with a previously executed version, or if different, produces a verification result (e.g., a generated hash value) that is consistent with an expected result embedded in the firmware at compile time. In this manner, the computing system improves usability, customization, and user control over firmware and recovery firmware executed within the computing system.

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

[0007] In various examples, a method is described that includes determining, by a security processor of a computing system, an expected hash for firmware from firmware stored in a memory of the computing system; determining a generated hash for the firmware stored in the memory; and in response to determining that the expected hash corresponds to the generated hash, verifying, by the security processor, the firmware.

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

[0009] The details of one or more embodiments are set forth in the accompanying drawings and the following description. Other features and advantages will become apparent from the description and drawings and from the claims. This summary is provided to introduce the subject matter that is further described in the detailed description and drawings. Therefore, this summary should not be considered to describe essential features, nor is it intended to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The following describes details of one or more aspects of the security verification of the recovery firmware. The use of the same reference numerals in different instances indicates similar elements in the specification and figures:

[0011] Figure 1 is a conceptual diagram illustrating an example computing system configured to verify firmware and recover firmware.

[0012] Figure 2 is a flow diagram illustrating example operation of a security processor configured to authenticate firmware.

[0013] Figure 3 is a flow diagram illustrating example operation of a security processor configured to authenticate recovery firmware.

[0014] Figure 4 is a flow diagram illustrating example operations of a security processor configured to perform probabilistic or partial verification of firmware or recovery firmware.

[0015] Figure 5 is a conceptual diagram illustrating a computing device configured to perform secure verification of firmware and recovery firmware. DETAILED DESCRIPTION

[0016] In some computing systems, an application processor executes system firmware as a condition for loading and executing an operating system (OS). A write-protected portion of system memory may store a read-only portion of the system firmware, and a read-write portion of system memory may store a read-write (or unprotected) portion of the system firmware. The write-protected portion of system memory may further include specialized "recovery firmware" that is executed when the computing system is operating in recovery mode. The recovery firmware is intended to be executed in place of the system firmware during a recovery event to configure the computing system to operate in a stable recovery mode.

[0017] During a verified boot process, the security processor of the computing system can prevent the application processor from executing the system firmware until the security processor can verify its own security processor firmware (e.g., "Cr50") stored in the internal memory of the security processor. After verifying and executing the security processor firmware, the security processor enables the application processor to perform the verified boot process.

[0018] Once enabled, the application processor executes instructions embedded in a "mask ROM" (e.g., a type of read-only memory that is internal to the application processor and pre-programmed during manufacturing) to locate and retrieve a read-only portion of the system firmware from a write-protected portion of the 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 is signed using a unique, hardware-specific key that is hard-coded within the application processor (e.g., burned into the fuses of the application processor). If the mask ROM can verify the read-only portion of the system firmware using the unique, hardware-specific key, the application processor will execute the read-only system firmware. Relying on the mask ROM to verify the system firmware may prevent users from installing "unofficial" third-party or user-customized firmware that cannot be signed with the unique, hardware-specific key and therefore cannot be verified using the unique, hardware-specific key.

[0019] As a condition for executing the readable and writable portion of the system firmware, the read-only portion verifies that the readable and writable portion was signed with an "official" root key during compilation. The computing system may store the root key in a write-protected portion of the system memory. In response to determining that the readable and writable portion was signed with the root key, the application processor loads and executes the readable and writable portion of the system firmware, under the assumption that the write-protected portion of the system memory will never be corrupted.

[0020] In a similar manner, in the case where the computing system is executed in recovery mode, the read-only portion of the system firmware maintains system integrity by verifying that the recovery firmware is signed with the root key before executing the recovery firmware. By maintaining the assumption that the write-protected portion of the system memory has not been corrupted, in response to determining that the recovery firmware is signed with the root key, the application processor loads and executes the recovery firmware. If the recovery firmware cannot generate a recovery key, the computing system prohibits execution of the recovery firmware until an official version of the recovery firmware that can generate a recovery key is installed and executed.

[0021] Although some computing systems can prevent the execution of unverifiable system firmware and recovery firmware in this way, this verified boot process inhibits usability, customization, and user control. Hardware-specific and "official" root keys may only be discovered by authorized developers. In addition, the security and integrity of the computing system depends on the absolute trust that the hardware-specific key and the write-protected portion of the system memory can protect the "official" root key. However, the official root key can be destroyed by a sophisticated user who can physically access the system memory or find a write-protected portion of the system memory to destroy it. In this way, not only is this type of verified boot less safe than it could be, but it may also prevent legitimate users who are not authorized developers but wish to execute third-party or customized firmware from doing so, thereby unnecessarily limiting the usability, customization, and user control of the computing system.

[0022] To facilitate customization and user control of firmware without sacrificing security and integrity, a computing system is described that relies on a security processor and an application processor that are configured to verify system firmware and recovery firmware without relying on manufacturing proprietary verification processes, 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 including a degree of completeness, which define processes for verifying the firmware and recovery firmware independently of, for example, an integrated circuit manufacturer's mask ROM (read-only memory) verification process involving hardware-specific keys. As an example, the firmware management parameters can specify that partial or probabilistic verification, full or complete verification, or no verification at all be performed.

[0023] After verifying the header signature and / or body signature of the system firmware, the security processor generates hash (e.g., SHA-256) values ​​that are associated with corresponding blocks of the system firmware stored in the system memory. The security processor compares the generated hash values ​​with expected hash values ​​derived by the security processor from the read-only portion of the firmware body.

[0024] Because recovery firmware typically supports low-level drivers and user interfaces that are not supported by system firmware, the size of recovery firmware is typically larger than that of system firmware. As such, the security processor can rely on a higher-performance application processor to verify the recovery firmware. After verifying the header and / or body signatures of the recovery firmware, the application processor generates hash values ​​that are associated with corresponding blocks of the recovery firmware stored in system memory. The application processor can automatically generate and store (e.g., as a background task performed by an operating system) hash values ​​for the recovery firmware, for example, after the system firmware initially successfully boots and executes.

[0025] 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 has failed verification and prohibits execution of the recovery firmware. If the expected hash value of the recovery firmware and the generated hash value match, the application processor executes the recovery firmware.

[0026] In response to the recovery firmware failing the check by the application processor, the security processor may attempt to verify the recovery firmware according to the firmware management parameters. The security processor may partially verify the recovery firmware by checking only some generated hash values ​​against expected hash values. Alternatively, the security processor may perform a full verification and check the generated hash values ​​against the expected hash values ​​or not perform verification at all, bypassing the block check entirely.

[0027] In this way, the computing system can verify firmware and recovery firmware independently of the integrated circuit manufacturer's mask ROM verification process and without relying on hardware-specific keys. The computing system instead relies on the security processor to ensure that the system firmware is properly signed and consistent with the previously executed version, or if different, produces a verification result (e.g., a generated hash value) that is consistent with the expected result embedded in the firmware at compile time. In this way, the computing system can improve the usability, customization, and user control of the firmware and recovery firmware executed within the computing system. Rather than being subject to official firmware versions or predetermined hardware keys, the example computing system can securely execute custom or third-party firmware without sacrificing system integrity.

[0028] By separating the verification of firmware from the knowledge of processor-specific hardware keys, the techniques of the present disclosure may enable computing systems to execute a wider variety of firmware and recovery firmware programs. Firmware developers no longer need deep product knowledge of and reliance on hardware-specific verification keys, which may be controlled by hardware manufacturers who may or may not be willing to coordinate with firmware developers.

[0029] In addition, the technology of the present disclosure can enable computing systems to resist attacks that are broader or of a different range than those to which the computing systems may have been previously exposed. For example, previous systems relied on write protection of system memory, and the only way an attacker could overwrite system memory was by physically accessing the computing system, including memory chips or motherboards. This is called an "evil maid" attack, which refers to a situation where someone leaves a device unsupervised for a long time (e.g., in the presence of an attacker who disguises himself as a hotel maid to gain access to the device). However, some computing systems must resist additional types of attacks by, for example, users who may themselves be authorized users with long-term access to the device. For example, some schools issue computing devices to students and strict policies related to their use. Schools use enterprise policies to limit what students can do on these devices, in some cases due to legal requirements. Some students may not like those restrictions and may therefore try to circumvent enterprise policies. Students are able to access devices for a long period of time, which makes it unrealistic to rely on write protection to implement policy restrictions. Other government entities or private companies may have gaps in their own physical security, which may allow attackers to have physical control over the device long enough to spread evil maid attacks.

[0030] In both cases, the device owner may wish to detect attacks and limit device functionality if an attack occurs. Restrictions can take many 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 at all. Owners may also have different tolerances for the impact of additional protection on boot speed. Regular users may prefer a faster boot at the expense of some security, just as some users may use short, easily guessed passwords. Enterprise users may prefer a more secure boot, even if security adds a few seconds to boot time.

[0031] In another scenario, an attacker may return a device to a store after modifying the firmware (e.g., embedding malicious code into the device). Before reselling the device to a new customer, the store should ensure that the firmware on the device has not been modified. Similarly, devices may be returned to schools, governments, and businesses. Existing so-called "in-store return" processes for verified firmware can be slow, manual, and require a second device.

[0032] For each of the above scenarios, the techniques of this disclosure may enable stores, schools, businesses, etc. to defend against these broader or different attacks by relying on the computing system to automatically verify the firmware and recovery firmware before executing it. In this way, the true owner of the device, who is different from the authorized user, can ensure the integrity of the computing system they control without having to manually verify the integrity of the system.

[0033] Figure 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 suggest one or more components of a mobile phone, a laptop computer, a wearable device (e.g., a watch, glasses, headphones, clothing), a tablet computer, an automobile / in-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 box device, a thermostat device, a garage door opener device, other home devices or appliances, a desktop assistant device, a speaker device, a non-portable gaming device, and a business conferencing device.

[0034] The computing system 100 may be part of a system on a chip (SoC). For example, the computing system 100 may be a processing component of a mobile phone that replaces a traditional central processing unit (CPU) or central controller processing architecture. The distributed processing architecture of the computing system 100 may also enable the mobile phone to share work that would otherwise be performed by a single CPU without causing the mobile phone to be bottlenecked by the CPU performance.

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

[0036] The computing system 100 includes buses 110, 112, and 114. The application processor 102 communicates with a controller of the storage 104 by exchanging data on the storage bus 110, enabling the application processor 102 to read from or write to the storage 104. In a similar manner, the application processor 102 and the security processor 104 may each communicate with a controller of the memory 106 by exchanging data on the memory bus 112, enabling each of the security processor 108 and the application processor 102 to read from or write to the memory 106. Further, the security processor 108 and the application processor 102 may communicate directly by exchanging data on the host bus 114. The application processor 102 is configured to execute software, including firmware, kernel programs, operating system software, applications executed within the operating system, and the like.

[0037] The security processor 108 includes control links 116A and 116B for facilitating control of the application processor 102 and the memory 106. The security processor 108 can control a write protection feature of the memory 106 by outputting a control signal on the control link 116A. In some cases, the security processor 108 can monitor the write protection feature, for example, if an attacker attempts to disconnect the control link 116A. The security processor 108 can place the application processor in reset or release the application processor 102 from reset by outputting a control signal on the control link 116B. For example, the security processor 108 can hold the application processor in reset until the firmware can be verified or the firmware can be restored, at which point the security processor releases the application processor 102 from reset to subsequently execute the verified firmware or the restored firmware.

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

[0039] The storage 104 is configured to provide persistent storage of executable instructions (e.g., firmware, recovery firmware, software, applications, modules, programs, functions) and data (e.g., user data, operational data) to the computing system 100 to support the execution of the executable instructions. For example, a controller of the storage 104 communicates on the storage bus 110 to read or write input to the storage 104 under the command of the application processor 102. Figure 1 The storage 104 in the example of includes two different copies (A and B) of the operating system kernel and the operating system file system and other data required to support the installation and execution of the operating system kernel and the operating system file system.

[0040] 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 maintains 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 does not include propagating signals. Storage 104 may be a solid state drive (SSD) or a hard disk drive (HDD).

[0041] Memory 106 represents a secure memory device in addition to storage 104, which is a system memory (e.g., non-volatile) configured to store data required to perform secure boot and firmware / recovery firmware verification techniques. The memory can be a flash memory chip configured to communicate with security processor 108 and application processor 102 on a memory bus 112, which can be a serial peripheral interface (SPI) bus, and in this case, memory 106 can be a SPI flash memory chip. In other examples of computing system 100, other types of non-volatile memory can be used for memory 106.

[0042] Memory 106 includes a write-protected area and an unprotected or "non-write-protected" area. In the write-protected area, memory 106 includes boot descriptors, read-only portions of system firmware, recovery firmware, and root keys (and possibly other information, such as a recovery key used to sign the recovery firmware). In the unprotected area, memory 106 includes two different copies of the read-write portions of the firmware, as well as other data.

[0043] Maintenance firmware and recovery firmware can occupy large areas of memory 106. Memory 106 can be divided into "blocks". It may be desirable to break up large areas of memory 106 into multiple blocks. A firmware image can span multiple blocks. The security processor 108 can maintain the firmware and recovery firmware in memory 106, including - embedded in the body of the firmware and recovery firmware - an expected hash for each block of the firmware and recovery firmware, which the security processor 108 can then verify against the corresponding generated hash of the block. In some cases, depending on whether a full verification is performed, when the firmware or recovery firmware includes multiple blocks, the security processor 108 and / or the application processor 102 can generate a hash value for each of the multiple blocks or only a subset.

[0044] The controller of the memory 106 can modify or delete data stored in the unprotected area of ​​the memory 106. However, when the write protection of the memory 106 is enabled, the controller cannot modify or delete the data stored in the protected area of ​​the memory. The memory 106 may include a physical feature for disabling the write protection, such as a physical button, a physical pin, or a physical switch. The memory 106 may include an electronic interface for disabling the write protection, such as a special programming interface, etc. The security processor 108 may use the control link 116A between the security processor 108 and the memory 106 to 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.

[0045] The read-only portion of the system firmware stored in memory 106 may include a body segment and a header segment. The header segment may include information such as:

[0046] • Identifying a sequence of bytes (eg, a “magic number”) so that firmware executing in the security processor 108 can identify the header from other blocks of memory 106 and enable the header and firmware to be stored at one of several different possible addresses.

[0047] • A version number that associates the firmware with a specific device model and distinguishes the system firmware from other versions intended to execute on other device models.

[0048] • A header signature that is applied to the header segment using the public half of the authentication key (e.g., stored in the security processor firmware). The private half may be controlled at a remote entity, such as a hardware manufacturer, operating system developer, or other entity that works to ensure that computing system 100 executes only verifiable firmware. The private half may be stored in the security processor firmware.

[0049] • An authentication subkey that the security processor 108 uses to authenticate segments of system firmware. The private half may be controlled at a remote entity, such as a hardware manufacturer, operating system developer, or other entity that works to ensure that computing system 100 executes only verifiable firmware. The private half may be stored in the security processor firmware.

[0050] The body of a firmware image may include:

[0051] • A body version number that is incremented to distinguish system firmware from other versions.

[0052] • A body signature that is applied to the body segment using a verification subkey (e.g., stored in a header segment of the system firmware). The private half may be controlled by a remote entity, such as a hardware manufacturer, operating system developer, or other entity that works to ensure that computing system 100 executes only verifiable firmware.

[0053] • An expected value of a control register of the memory 106, which controls which portion of the memory 106 is write-protected when write protection of the memory 106 is enabled.

[0054] • A table of expected hash values ​​where each entry corresponds to a different block of memory 106 storing the firmware or a portion of the recovery firmware.

[0055] • The number of entries in the table.

[0056] Each entry in the table of expected hash values ​​contained in the body section of the firmware may specify:

[0057] • The address (or offset) of the block in memory 106.

[0058] • The size of the block (eg, in bytes).

[0059] • The weight assigned to the block for validation. Weights can be expressed as fixed-point values, logarithmic values, or other types of parameters. In a probabilistic validation scheme, the maximum weight may result in the block always being validated. In a probabilistic validation scheme, the minimum weight may result in the block never being validated. Weights between the maximum and minimum weights will result in blocks being validated more often or less often, depending on whether the weight is assigned a value closer to the maximum weight or a value closer to the minimum weight.

[0060] • The expected hash (e.g., SHA-256) of the portion of the firmware or recovery firmware stored in the block.

[0061] The application processor 102 is the main processing complex of the computing system 100, and the security processor 108 is a specialized processing unit of the computing system 100. Although the application processor 102 is primarily configured to execute instructions (e.g., firmware, recovery firmware, kernel software, operating system software) to enable the computing system 100 to perform various operations, the security processor 108 is a support processor configured to perform security and verification operations. For example, in the case where the computing system 100 is a SoC in a mobile computer (e.g., a mobile phone), the application processor 102 can execute instructions associated with the operating system and applications executed in the operating environment provided by the operating system. The security processor 108 can interact with the application processor 102 to manage the secure boot of the operating system, and can perform verification of the firmware before the application processor 102 executes the firmware, or can verify the recovery firmware before the application processor 102 executes the recovery firmware in the case where the computing system 100 enters a recovery mode.

[0062] Application processor 102 and security processor 108 may each 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. Application processor 102 and security processor 108 may each be an integrated processor and memory subsystem (e.g., implemented as a SoC) that processes computer-executable instructions to control the operation of computing system 100. In some examples, computing system 100 may be implemented with any one or combination of hardware or fixed logic circuitry implemented in conjunction with processing and control circuits, which are generally identified as application processor 102 and security processor 108.

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

[0064] Firmware management parameters represent configuration parameters set by application processor 102. In some examples, computing system 100 may require a password for application processor 102 to change firmware management parameters. In some examples, after initial setup of computing system 100, the password may be deleted or "forgotten", resulting in the firmware management parameters being static or written once.

[0065] The firmware management parameters may include various security-related settings, including whether to enable operating system developer mode, whether to enable security chip firmware debug mode, etc. In order 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 "full verification" instead of "probabilistic verification" or "partial verification" or "no verification" (e.g., an option to completely disable verification) each time the computing system 100 is started. Details about various verification modes, including full verification and probabilistic verification, are described with reference to other figures.

[0066] In some examples, the security processor 108 may support handling more options or settings through the firmware management parameters. For example, the firmware management parameters may include additional options to enable enterprises and developers to achieve flexibility in the verification process to trade off security against complexity and usability. For example, in addition to only including options to select full verification, probabilistic verification, or no verification, the firmware management parameters may also include an option for a user or security administrator to adjust the weights and therefore the probability of checking a particular block during probabilistic verification.

[0067] In some examples, the firmware management parameters may provide further configuration of the security processor 108 (e.g., settings that enable enterprises and developers to implement more flexibility to trade off security and usability). For example, one additional setting may be a modifier for the assigned weights of specific blocks appended to the firmware or recovery firmware to adjust the likelihood that the block will be checked during partial or probabilistic verification. Other firmware management parameters may be a setting that requires the security processor 108 to check for model-specific verification data (e.g., in a header segment of the firmware), optionally check for model-specific verification data if present and ignore the check if not present, or ignore the model-specific verification check entirely (e.g., which may be useful to developers).

[0068] The security processor 108 may maintain verification status information in an internal non-volatile memory of the security processor 108, which the security processor 108 and / or the application processor 102 may access to perform firmware or restore firmware verification. For example, the security processor 108 may have one or more platform configuration registers that may be incremented to update to a new state, but not decremented (without removing power). As an example, the security processor may maintain verification status information including:

[0069] • “Generated hash,” which refers to a value output from a secure hash function applied (eg, by application processor 102 or security processor 108 ) to one or more blocks of firmware or recovery firmware.

[0070] • A status indicator of whether the hash generated by the firmware or recovery firmware is verifiable or unverifiable.

[0071] As described above, within the security processor firmware, the security processor 108 may maintain a verification key for verifying a header signature of a header segment applied to the system firmware. For example, from the header segment of the security processor firmware, the security processor 108 may determine a verification key (or a hash thereof for storage preservation) for verifying the header signature applied to the system firmware during compilation (e.g., the private half of the system firmware verification key is known to the compiler and applied to the system firmware during compilation). Before continuing to verify the body of the system firmware, the security processor 108 may initially check the header signature applied to the system firmware against the verification key stored in the security processor firmware (e.g., embedded in the header segment of Cr50). Before continuing to verify the system firmware, the security processor 108 may then check the body signature applied to the system firmware against the verification subkey stored in the body segment of the system firmware.

[0072] 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 the recovery firmware that have been loaded onto the memory 106. The application processor 102 may initialize firmware management parameters maintained by the security processor 108, and based on the firmware management parameters, the security processor 108 may verify the firmware, including 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 may verify the recovery firmware, including 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.

[0073] In operation, the security processor 108 may initially verify the header signature of the firmware using a system firmware verification key (or a hash thereof) maintained by the security processor 108. If the security processor 108 determines that the signature of the header is incorrect, the security processor 108 may shut down the computing system 100 to prevent the computing system 100 from loading and executing incompatible or corrupted system firmware. Assuming that the signature of the header system firmware can be verified using the verification key, the security processor 108 may determine whether the body signature applied to the body segment of the system firmware was generated using the verification subkey. If the security processor 108 determines that the signature of the body segment is incorrect, the security processor 108 may shut down the computing system 100 to prevent the computing system 100 from loading and executing incompatible or corrupted system firmware.

[0074] Assuming that the signature of the body segment can be verified using the verification subkey, the security processor 108 determines the expected hash value of the block of the system firmware or recovery firmware loaded in the memory 106 based on the firmware management parameters. For example, during a complete check of the system firmware, from the header or body of the system firmware, the security processor 108 can identify the expected hash value of each block of the system firmware stored in the memory 106. The expected hash value can remain a fixed attribute of the system firmware and can be determined in advance, for example, at compile time. As a condition for executing the system firmware and the recovery firmware, the security processor 108 compares the generated hash value of the block of the system firmware and the recovery firmware currently stored in the memory 106 with the predetermined expected hash value embedded in the system firmware and the recovery firmware.

[0075] The security processor 108 may apply the hash function directly to the blocks of system firmware loaded in the 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 the expected hash values. If the security processor 108 identifies a difference between the hashes, the security processor 108 may notify the application processor 102 of the failed verification to prevent the application processor 102 from executing the potentially corrupted or malicious firmware or recovering the firmware.

[0076] During a subsequent boot process, the security processor 108 may repeat the above verification process by refreshing the generated hash of the system firmware, thereby 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, the security processor may regenerate the hash associated with the system firmware to enable subsequent verification attempts. In response to determining that the expected hash of the system firmware does not match the second hash, the security processor 108 may direct the application processor 102 to enter a recovery mode, or otherwise prohibit execution of the system firmware.

[0077] In some examples, the security processor 108 can control an output component of the computing system 100, such as a light emitting diode (LED) or a speaker, to indicate when the firmware or recovery firmware fails to verify. It can also be used by the security processor 108 at other times, for example, to indicate a request for two-factor authentication. The output component can be a dedicated output component used by the security processor 108. In other cases, the output component can have dual functions (for example, such as a power or charging identifier or a keyboard or display backlight). The security processor 108 can control the output component to indicate a failed verification, a successful verification, or other conditions. Such an output component can have a dual purpose (such as a power or charging LED, or a keyboard or display backlight) or can be intentionally integrated into the computing system 100 to provide the status of firmware and recovery firmware verification. A typical control scheme for the output component can include sending a message from the application processor 102 to the security processor 108 to control the output component. In other examples, the security processor 108 can 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 can have its own PWM unit to copy the output to the output component. In other examples, the security processor 108 may have internal switches that are controllable by the application processor 102 to control output components.

[0078] An attacker with physical access to computing system 100 can remove the output component or block light from the output component. By controlling the output component during the authentication process, security processor 108 makes this attack more difficult by enabling the output component very early in the boot or login process, similar to the way the check engine light in a car is displayed for a few seconds immediately during starting. An attacker can wire the output component to another processor in computing system 100 to try to replicate this behavior, but involves persistent, potentially noticeable hardware modifications.

[0079] 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, enabling a debugger to override the signal during manufacturing. Removing this resistor is a moderately feasible method for an attacker to both prevent the security processor 108 from being able to drive the write protect signal and prevent the security processor 108 from being able to detect the current state of the write protect signal. The security processor 108 may include a second pin connected to the exact same net as the first write protect pin. The additional pin may be hidden beneath an inner layer of the motherboard to make interfering with the signal more difficult. The security processor 108 may monitor this signal to measure the true state of the first write protect pin.

[0080] The attacker needs to power off the computing system 100 to prevent the security processor 108 from detecting the change in state of the write protection pin. However, at startup, the security processor 108 can rescan the system memory 106 and identify the change. The attacker can replace the system memory 106 with a more complex circuit that allows more control over the SPI bus and stack the new memory 106 on top of that circuit. However, this is a more difficult attack and leaves physical evidence.

[0081] Although described as being primarily used to verify firmware executable on an application processor, the techniques for securely verifying recovery firmware are also applicable to other processors. For example, in addition to the application processor 102 and the security processor 108, the computing system 100 may also include other processors with firmware, such as an embedded controller (EC) fingerprint sensor (FPMCU), other hardware units, hardware accelerator units, etc. If the security processor 108 can access 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, other processors can benefit from the flexibility and security provided by secure verification.

[0082] Figure 2 2 is a flow chart illustrating an example operation of a security processor configured to verify firmware. Operation 200 includes steps 202 to 214. Operation 200 may be performed in a different order or with a different Figure 2 The operations are additional or fewer than those shown. The security processor 108 may perform the operation 200 to verify the system firmware maintained in the memory 106 .

[0083] exist Figure 2 2 , the security processor 108 may perform operation 200 each time the computing system 100 is powered on or reset. In response to a transition out of sleep mode, the security processor 108 may perform operation 200. In response to a reset of the security processor 108 (e.g., if a user provides a particular key input combination that triggers a reset of the security processor 108), the security processor 108 may perform operation 200.

[0084] In 202, when the security processor 108 is powered on, awakened, or reset, the security processor verifies, loads, and executes its own security processor firmware. In 204, the security processor 108 maintains firmware management parameters, including options for verifying firmware. In other words, the security processor 108 can be configured to verify the system firmware or recovery firmware based on information inferred from the firmware management parameters, for example, by performing a "full verification", "probabilistic verification" of the recovery firmware, or no verification of the recovery firmware each time the computing system 100 boots. The security processor 108 can store status information and flags as firmware management parameters, which the 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 the application processor 102 and / or the security processor 108.

[0085] The firmware management parameters may be initialized by the application processor 102 at the initial boot of the computing system 100. When performing full verification of the recovery firmware, the security processor 108 checks the entire recovery firmware, including checking the generated hash of each block of the firmware against the corresponding expected hash recorded in the body section of the firmware. When performing no verification of the recovery firmware, the security processor 108 prohibits the generation of any hashes for the firmware (e.g., for debugging).

[0086] Certain blocks of firmware may not affect the functionality of computing system 100. Skipping certain blocks at boot time or during recovery may allow computing system 100 to operate in a wider range of scenarios without significantly reducing the security of computing system 100. As such, a weight table in the firmware may specify a weight factor associated with each firmware block and used to determine whether a block may be skipped.

[0087] In some examples, some blocks may have less chance of being used when resuming from deep sleep or when entering low power suspend mode, where 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 low power suspend mode, such as root keys or other parts of the firmware. Skipping these blocks when resuming can improve resume time without significantly reducing security.

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

[0089] In response to determining to enter recovery mode, the security processor 108 executes Figure 3 Operation 300 is shown. Alternatively, in response to determining to enter a non-recovery mode, the security processor continues by executing step 208 to automatically verify the system firmware based on the firmware management parameters maintained by the security processor 108.

[0090] In 208A, the security processor 108 checks the signature applied to the system firmware against the system firmware verification key and subkey. For example, the security processor 108 may verify the header signature of the firmware using a verification key maintained in a header section of the security processor firmware (or maintained elsewhere within the security processor 108). The private half of the system verification key may be maintained by an operating system developer or a manufacturer of the computing system 100 and provided to an official compiler that is used to compile and sign the system firmware intended to be executed on the application processor 102.

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

[0092] If the security processor 108 determines that the system firmware is not signed using the appropriate verification key and verification subkey, the security processor 108 fails the system firmware verification check and moves to step 210. Alternatively, in response to verifying the signature applied to the system firmware, the security processor 108 continues to verify the firmware in steps 208B through 208D.

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

[0094] The security processor 108 may provide "rollback protection" by retaining the highest version number of the verified recovery firmware that the security processor 108 has checked. When an older version with a lower version number than the highest version number is checked, the security processor 108 may output a notification to alert the computing system 100. For example, if the header section of the firmware indicates version A, then even though the previous version checked by the security processor 108 was version B, the security processor may set a flag in its internal register or otherwise signal a warning to the application processor 102 (e.g., for output via a user interface) that the firmware was "rolled back" to a previous version.

[0095] Based on the firmware management parameters, the security processor 108 performs steps 208B to 208D on each block of the system firmware when performing full verification, performs steps 208B to 208D on only some blocks of the system firmware when performing partial verification or probabilistic verification, and does not perform steps 208B to 208D on any block of the system firmware when the firmware management parameters indicate that verification can be skipped.

[0096] In 208B, the security processor 108 hashes the system firmware based on the firmware management parameters to determine a generated hash of the system firmware. For example, the security processor 108 may load one or more of the separate blocks of the system firmware from the memory 106 and apply the hash function to the blocks. The security processor may maintain the result of the hash function in a register or internal memory for subsequent comparison against an expected hash value.

[0097] In 208C, the security processor 108 determines an expected hash of the system firmware. For example, the computing system 100 may require that the system firmware include a dedicated and discoverable area (e.g., part of a body segment) for recording expected hash values ​​of blocks of the system firmware maintained in the memory 106. The expected hash value embedded in the system firmware is generally sufficient to verify the recovery firmware because the firmware and the recovery firmware are generally built in a comprehensive build process that involves compiling the firmware and the recovery firmware together as part of the firmware image. The security processor 108 may determine the expected hash by extracting a specific value from a predetermined area of ​​the body segment of the firmware.

[0098] In 208D, the security processor 108 determines whether the expected hash matches the generated hash. If the hashes match, the security processor 108 verifies the firmware and updates a status register maintained by the security processor 108 to reflect that the firmware is verified. Likewise, if the hashes do not match, the security processor updates the status register to indicate that the firmware is not verifiable.

[0099] In 210, the security processor determines whether the firmware is successfully verified. In 212, when the firmware fails the verification check in step 208 and is not verified, the security processor 108 directs the computing system 100 to terminate the boot and turn off the power. In 214, when the firmware passes the verification check in step 208 and is verified, the security processor 108 directs the computing system 100 to continue the boot process by releasing the application processor 102 from reset and enabling the application processor 102 to execute the firmware.

[0100] Figure 3 300 includes steps 302 to 308. Operation 300 may be performed in a different order or with a different Figure 3 The operations shown may be in addition to or less than those shown. The security processor 108 may perform the operation 300 to verify the recovery firmware maintained in the memory 106 .

[0101] exist Figure 3 In response to the security processor determining in step 206 of operation 200 that the computing system 100 enters the recovery mode, the security processor 108 may perform operation 300 .

[0102] The computing system 100 may enter the recovery mode in a variety of ways. For example, in response to the application processor 102 determining that a user manually requested to enter the recovery mode (e.g., by detecting a particular key press on a keyboard of the computing system 100, by detecting different signals from input components of the computing system 100), the computing system 100 may enter the recovery mode. If during execution of the read-only portion of the system firmware, the application processor 102 determines that the signature applied to the read-write portion of the system firmware is incorrect, the computing system 100 may enter the recovery mode. The read-only portion of the system firmware may check the signature using a root key stored in a write-protected portion of the memory 106.

[0103] Prior to entering recovery mode, the operating system of computing system 100 may have verified the recovery firmware, for example, as a background task, and stored the expected hash of the recovery firmware in memory 106. During normal boot, computing system 100 does not need to verify the recovery firmware because the recovery firmware is not executed on the initial boot path. Unless commanded by the user to enter recovery mode, application processor 102 can always boot the operating system without verifying the recovery firmware.

[0104] The operating system can verify the recovery firmware in the background during normal operation to prevent an attacker from disabling the recovery firmware, which may not be noticed by the computing system 100 until the normal boot path fails. Although it may not necessarily prevent an attacker from causing the computing system 100 to execute unverified code, at least having the operating system check the integrity of the recovery firmware in the background can enable the computing system 100 to detect potential attackers in advance before restarting. In some cases, developers may be testing new firmware versions and may want to be notified or warned in advance that the computing system 100 may be executing bad or unverified firmware. This may give the user an option to not execute the recovery firmware or to repair the firmware before the computing system 100 executes the untrusted recovery firmware.

[0105] For various reasons, an operating system or other service or thread executing at application processor 102 may request 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 security processor 108 via host bus 112.

[0106] The application processor 102 is typically more powerful and faster than the security processor 108. As such, the computing system 100 can take advantage of the faster processing speed, greater bandwidth, and capabilities of the application processor 102 to initially verify the recovery firmware faster than the security processor 108.

[0107] During execution, the system firmware can maintain an expected hash of the recovery firmware in the system memory, as initially determined from a previous boot. The hash can provide a sufficient reference point to determine the integrity of the recovery firmware (e.g., whether the recovery firmware has changed since the last use) because the recovery firmware and the system firmware (including the read-only portion) are built together at the same time. Upon determining that the computing system 100 enters recovery mode, the system firmware directs the application processor 102 to compare the expected hash of the recovery firmware with the hash of the recovery firmware loaded in the memory 106 generated by the application processor.

[0108] In response to determining that the expected hash and the generated hash match, the application processor 102 executes the recovery firmware. In response to determining that the recovery firmware check fails and the signature of the recovery firmware is bad or the expected hash and the generated hash do not match, the application processor 102 will request the security processor 108 to verify the recovery firmware so that the computing system 100 can execute the recovery firmware and operate in recovery mode.

[0109] In response to determining in 206 that the computing system 100 enters recovery mode, the security processor 108 may optionally automatically verify the recovery firmware according to the firmware management parameters used during the verification of the system firmware in 302. For example, the security processor 108 may perform a full verification of the recovery firmware by default, checking each block of the recovery firmware loaded in the memory 106. In other cases, some blocks of the recovery firmware may be unlikely to cause problems if damaged, so the security processor 108 may skip the blocks that are least likely to cause catastrophic failures and perform a probabilistic or partial verification of the recovery firmware. The security processor 108 may determine whether to perform a full check or a partial check of the recovery firmware based on the information in the firmware management parameters.

[0110] For probabilistic verification, each block may be assigned a weight, which is then compared to a threshold dynamically generated during the verification process (e.g., during operation 300 or 200). The dynamically generated threshold may correspond to an output from a random number generator. If the assigned weight exceeds the dynamic threshold for the block, the security processor 108 will perform steps 302A to 302D to automatically verify the block, following a process similar to that described above with respect to steps 208A to 208D. If the assigned weight does not exceed the dynamic threshold, the security processor 108 may skip the block without considering whether the expected hash of the block matches the generated hash.

[0111] In 302A, the security processor 108 checks the signature applied to the system firmware against the system firmware verification key and subkey. In response to verifying the header signature, the security processor 108 may verify the body signature applied to the system firmware using the verification subkey from the header segment of the system firmware. If the security processor 108 determines that the system firmware is not signed using the appropriate verification key and verification subkey, the security processor 108 fails the system firmware verification check and proceeds to step 304. Alternatively, in response to verifying the signature applied to the system firmware, the security processor 108 continues to verify the recovery firmware in steps 302B to 302D.

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

[0113] In 302B, the security processor 108 hashes the individual blocks of recovery firmware and may maintain the results of the hash function in a register or internal memory for subsequent comparison against the expected hash value. In 302C, the security processor 108 determines the corresponding expected hash of the individual blocks of recovery firmware as initially determined by the application processor during the initial check of the recovery firmware. In 302D, the security processor 108 determines whether the expected hash matches the generated hash. If the hashes match, the security processor 108 verifies the recovery firmware and updates the status register maintained by the security processor 108 to reflect that the firmware is verified. Likewise, if the hashes do not match, the security processor updates the status register to indicate that the recovery firmware is not verifiable.

[0114] In 304, the security processor determines whether the recovery firmware is successfully verified. In 306, when the recovery firmware fails the verification check in step 304 and is not verified, the security processor 108 directs the computing system 100 to terminate the boot and turn off the power. In 308, when the recovery firmware passes the verification check in step 304 and is verified, the security processor 108 directs the computing system 100 to continue the recovery process by releasing the application processor 102 from reset and enabling the application processor 102 to execute the recovery firmware.

[0115] As previously described, write protection of memory 106 may be controlled by security processor 108 via control link 116A. It is possible that an attacker of computing system 100 may attempt to override the write protection signal controlled by security processor 108, for example, by applying voltage to a physical write protection feature on memory 106, cutting a wire, or breaking a link between the write protection signal and security processor 108. Security processor 108 may monitor whether write protection of memory 106 has changed, and if so, set a flag or otherwise indicate that write protection of memory 106 has changed and information stored in memory 106 may be changing. 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 at application processor 102. Thus, security processor 108 may initiate a recovery process, including performing operation 300 when security processor 108 experiences a recovery condition.

[0116] The security processor 108 may skip step 302 entirely, including sub-steps 302A to 302D, for example, when the firmware management parameters indicate that block checking is disabled. Thus, the preconditions for performing operation 300 may include determining whether block checking is disabled, whether complete block checking is enabled, or whether probabilistic block checking is enabled. Therefore, the security processor 108 may perform step 302, including sub-steps 302A to 302D, to follow the checking scheme defined in the firmware management parameters.

[0117] Assuming block checking is not disabled, the security processor 108 can load and check the recovery firmware. The security processor can perform a complete check, for example, by performing operations 204 to 210 on each block of the recovery firmware by comparing each block to an expected hash. The security processor 108 can perform a probabilistic check, for example, by performing operations 204 to 210 on only some of the blocks. The security processor 108 can perform a probabilistic check by hashing and comparing only blocks of the recovery firmware that meet a threshold for checking or skipping a block.

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

[0119] Figure 4 4 is a flow chart illustrating example operations of a security processor configured to perform probabilistic or partial verification of firmware or recovery firmware. Operation 400 includes steps 402 to 416. Operation 400 may be performed in a different order or with a different set of operations. Figure 4The operations shown may be in addition to or less than those shown. The security processor 108 may perform the operations 400 to probabilistically verify the firmware maintained in the memory 106 or the recovery firmware.

[0120] In order to improve the speed and efficiency of firmware or recovery firmware verification without sacrificing security, the security processor 108 can probabilistically verify or only partially verify the firmware or recovery firmware. Although the security processor 108 can perform a complete verification and check on each block of the firmware or recovery firmware, with probabilistic verification, the security processor 108 generally only checks portions of the firmware or recovery firmware.

[0121] For example, the security processor 108 may rely on a respective weight that has been pre-assigned (e.g., in a firmware header) to each block of the firmware or recovery firmware. The security processor 108 may dynamically generate a threshold for each block and compare the threshold to the pre-assigned weight of the block as a condition for verifying the block. For example, the security processor 108 may execute a random generator for each block of the firmware or recovery firmware that outputs a value between 0 and 1. In response to determining that the dynamic threshold output from the random number generator exceeds the pre-assigned weight (e.g., in this example, also a value between 0 and 1), the security processor 108 will skip the block and continue to check subsequent blocks. In response to determining that the dynamic threshold does not exceed the pre-assigned weight, the security processor 108 will check the block (e.g., by comparing the expected hash of the block with the generated hash of the block).

[0122] In 402, the security processor 108 determines a probabilistic verification threshold for a block. The threshold represents a value between a maximum weight and a minimum weight that is assigned to a block of the recovery firmware. The threshold may be fixed or dynamic, for example, based on the context of the computing system 100 or other conditions. The security processor 108 may determine the threshold by analyzing the firmware to derive a maximum weight and a minimum weight from all entries in a table in a body section of the firmware. The security processor 108 may determine the dynamic threshold using a random number generator as any value greater than or equal to the maximum weight and less than or equal to the minimum weight.

[0123] At 404, the security processor determines the weights of the blocks. For example, as described above, the body of the firmware may specify a table of weights assigned to each block or other logical segment of the firmware or recovery firmware. Each corresponding weight may indicate a relative importance of verification compared to other blocks. The weights may be fixed point values, logarithmic values, or other types of parameters with maximum and minimum values.

[0124] During probabilistic verification, higher weights may cause blocks to be verified more frequently than blocks with lower weights. Each block may be assigned a weight when the firmware is generated, or may be adjusted, for example, in a debug mode where the weights may be accessed by a developer via input to the application processor 102. In some examples (e.g., via a special programming channel), the weights may be adjusted so that different verification schemes may be performed by changing the weights of segments of the firmware.

[0125] In 406, the security processor 108 determines whether the weight assigned to the block exceeds the probability verification threshold. In 408, any block whose weight does not exceed the threshold is skipped, and in 410, the security processor 108 checks whether this is the last block to be checked. If it is not the last block, the security processor returns to step 402, and if the block is the last block, the security processor completes the probability check at C.

[0126] If the security processor determines in 406 that the weight assigned to the block exceeds the probability verification threshold for the block, then in 412, the security processor 108 determines whether the hash generated for the block matches the expected hash of the block. The security processor exits operation 400 in response to determining in 414 that the generated and recorded hash values ​​of the block do not match, and sets a status register or otherwise signals the application processor 102 that the firmware or recovery firmware is not verifiable. In 416, in response to determining that the generated hash of the block matches the expected hash, the security processor 108 sets the status register to indicate that the firmware or recovery firmware is verifiable. In 410, if after setting the status register to indicate that the firmware or recovery firmware is verifiable, the security processor 108 determines that the block is the last block to be checked, the security processor 108 signals the application processor 102 to indicate that the firmware or recovery firmware is verifiable.

[0127] In some cases, the security processor 108 may change the probabilistic verification threshold, or use different weights assigned to blocks of firmware or recovery firmware, depending on whether the security processor 108 is verifying firmware, recovering firmware, booting from deep sleep, or booting from reset. For example, in some cases, the security processor 108 may check every block of recovery firmware during a recovery boot, and the weight assigned to each block to specify the chance of checking the block may be the same for all other boot or recovery operations.

[0128] There are some blocks used by normal boot that may not affect the recovery operation, such as blocks of firmware or recovery firmware that include root keys. Skipping these blocks at recovery boot can allow recovery from a wider range of scenarios without reducing the security of the recovery operation. The verification data table maintained in the firmware can additionally specify opportunities to check blocks at recovery boot, or flags indicating that the blocks are not used for recovery.

[0129] Once the application processor 102 executes the recovery firmware, the application processor 102 can still check any blocks that the security processor 108 skipped and optionally display a warning to the user. This may help diagnose normal mode boot problems without blocking the recovery boot.

[0130] There are some blocks used by normal boot that may not affect resume from deep sleep, such as parts of read-only firmware such as root keys or read-write parts of authentication firmware. Skipping these blocks on resume can improve resume time without reducing security.

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

[0132] The computing device 500 includes communication devices 510 that enable wired and / or wireless communication of device data 506, such as data communicated between devices in a WLAN, received data, 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 images generated by applications executed on the device. The communication device 510 may also include a transceiver for cellular telephone communications and / or network data communications.

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

[0134] The computing device 500 also includes an audio and / or video system 518 that generates audio for an audio device 520 and / or generates display data for a display device 522. The 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 photo). In an embodiment, the audio device and / or display device are integrated components of the example computing device 500. Alternatively, the audio device and / or display device are external peripheral components of the example device.

[0135] 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. The components of the processing system 514 may be implemented at least in part in hardware, such as with any type of microprocessor, controller, etc. 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 other implementations in silicon and / or hardware, such as a processor and memory system implemented 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 with processing and control circuits. The computing device 500 may further include any type of system bus or other data and command transmission system that couples the various components within the device. The system bus may include any one or combination of different bus structures and architectures and control and data lines.

[0136] The computing device 500 also includes computer-readable storage memory 516, such as a data storage device that can be accessed by the computing device and provides persistent storage for data and executable instructions (e.g., software applications, modules, programs, functions, etc.). The computer-readable storage memory described herein does not include 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 maintains data accessed by the computing device. The computer-readable storage memory can include various embodiments of RAM, ROM, flash memory, and other types of storage memory in various memory device configurations.

[0137] Computer readable storage memory 516 includes storage component 504 as an example of storage 104 and memory component 506 as an example of memory 106. Storage component 504 can store software related to a kernel, a root file system, or other operating systems. Memory 506 can store firmware and recovery firmware for booting computing device 500 as a prerequisite for loading and executing software related to a kernel, a root file system, and other operating systems.

[0138] The computing device 500 is configured to perform security verification of the firmware and recovery firmware stored in the memory 506. The security processor 508 compares the generated hash value associated with the firmware and the recovery firmware with the expected hash value (e.g., stored in the memory 506). In the event that the generated hash value matches the expected hash value, the application processor 502 can direct the application processor to execute the verified firmware or recovery firmware. However, in the event that the generated hash value does not match the expected hash value, the application processor 502 can prohibit the execution of the firmware or recovery firmware, the computing device 500 can be shut down, or the application processor 502 can command the security processor 508 to re-verify the firmware or recovery firmware, as described above.

[0139] Consider some use cases for computing device 500, which for ease of description is a laptop in the following scenario. An average user may purchase computing device 500 and log into computing device 500 for the first time. If the user subscribes to a remote (e.g., two-factor) authentication service through a second device (e.g., a mobile phone), then in response to a remote request for computing device 500 to perform firmware or recovery firmware authentication, the second device may confirm that the user is about to log into a fully authenticated laptop, or not. The user may control whether the service requires authentication, for example, by registering an option to "only let me log in to devices with fully authenticated firmware." In this way, even if an attacker with developer mode enabled can install a corrupted version of firmware or reset the user's security credentials on computing device 500, when the user logs into computing device 500 after the attack, the service will recognize computing device 500 as a new device and perform the two-factor authentication process.

[0140] During the enterprise registration process, the computing device 500 may perform the following steps to ensure device integrity 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 (e.g., generated hash value, verification result) obtained by the security processor 508.

[0141] If the generated hash value or verification result indicates that less than all of the firmware or all of the blocks of the recovery firmware are verified, the registration server can direct the application processor 502 to reset and restart by performing a complete firmware verification. This ensures that only fully verified firmware is allowed to participate in the registration process.

[0142] In the event that the motherboard identifier is not an authorized production number or the generated hash value is not the expected hash value stored in the registration server, the registration server can deny registration of computing device 500 to the enterprise network (for example, this may occur if a pre-production device is somehow marketed to consumers).

[0143] In response to the verification firmware, the registration server obtains the user login credentials and performs two-factor authentication or some other authentication process to complete the login. In this way, the user and the registration server can confirm that the computing device 500 is a fully authenticated device before providing login credentials that can be snooped and shared with the attacker if the computing device 500 is attacked.

[0144] In some examples, the registration server may automatically configure the firmware management parameters of the computing device 500 to ensure that future system boots are authenticated (or not authenticated) according to the enterprise police. In some cases, the registration server may terminate the registration unless the security processor 508 can accurately prove the firmware management parameters. In addition, the registration server may simply erase the firmware management parameters to unregister the computing device 500. Although various preferred embodiments of the present disclosure are described in the above description and shown in the drawings, it should be clearly understood that the present disclosure is not limited thereto, but may be embodied in different ways to be practiced within the scope of the following claims. It is apparent from the above description that various changes may be made without departing from the spirit and scope of the present disclosure as defined in the following claims.

[0145] For developers, the computing device 500 can be configured to allow developers to change the operating system and / or firmware at will. The computing device 500 can automatically enter the operating system developer mode through an operating system task. The operating system developer mode can allow changes to the operating system, but does not allow changes to the firmware or recovery of the firmware. In the firmware developer mode, the computing device 500 can erase and change the contents of the memory 506, including the write-protected portion. In any operating system developer mode, the security processor 508 can erase the secrets stored in the non-volatile memory of the security processor 508, including the decryption key for the data stored on the storage 504. In some cases, the firmware management parameters of the security processor 508 can prevent changes to the firmware or secrets controlled by the security processor 508. However, in other cases, once the operating system or firmware developer mode is started, the computing device 500 can be configured to receive customized firmware management parameters and write the customized firmware management parameters to the security processor 508. With the change in firmware management parameters, computing device 500 may be configured to disable verification of firmware or recovery firmware (e.g., bypassing full or probabilistic verification checks), however, security processor 508 may report that the firmware or recovery firmware was not checked so that a new user logging into computing device 500 may still be warned about unverified devices (e.g., via two-factor authentication).

[0146] Any owner-user of computing device 500 may have the ability to configure firmware management parameters of computing device 500, at least during initial login. Thus, a regular user may disable operating system or firmware developer mode, and optionally select from different boot verification levels (e.g., specify a higher or lower boot verification level).

[0147] In some examples, computing device 500 provides an interface from which a user can specify a password required to change firmware management parameters. In other cases, computing device 500 can generate a password for the 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 if and when the user wants to change the firmware management parameters.

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

[0149] Other data stored in memory 506 may vary on a per-device basis and may be verified in a manner similar to that of verifying firmware or restoring firmware. Security processor 508 may be configured to protect such data as well, e.g., to prevent swapping security processors 508 between boards, or modifying such data to make one device appear to be misconfigured.

[0150] Such other data may include a header segment with a different identification byte sequence but without a subkey and a body segment including model-specific data. The security processor 508 may verify hardware identifiers, service tags, wireless access node calibration or serial data, etc. The security processor 508 may compare a generated hash of the other data to an expected hash and, when the two values ​​match, verify the other data.

[0151] During manufacturing, before write protection is enabled at a factory termination step, such device-specific verification data may be stored in a write-protected area of ​​memory 506. There may be no signature for the header or body, as such other data varies on a per-device basis and only needs to be checked to ensure that the data has not changed since manufacturing of computing device 500. After the data has been written to memory 506, a hash of such data may be stored in security processor 508 during a factory termination step.

[0152] Although various preferred embodiments of the present disclosure are described in the above description and shown in the drawings, it should be clearly understood that the present disclosure is not limited thereto, but can be embodied in different ways to be practiced within the scope of the following claims. It is apparent from the above description that various changes can be made without departing from the spirit and scope of the present disclosure as defined in the following claims.

Claims

1. A computing system (100), comprising: Application processor (102, 502); a memory (106, 506), the memory comprising firmware of the computing system, the firmware comprising a plurality of blocks of the firmware; as well as A security processor (108, 508), the security processor being configured to verify the firmware as a condition for the application processor (102, 502) to execute the firmware by: determining respective probabilistic verification thresholds for the plurality of blocks of the firmware; determining respective weight values ​​of the plurality of blocks of the firmware; In response to a first block of the plurality of blocks of the firmware having a first corresponding weight value exceeding a first corresponding probability verification threshold, determining not to verify the first block of the firmware; as well as In response to a second block of the plurality of blocks of the firmware having a second corresponding weight value that does not exceed a second corresponding probability verification 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 generated hash value for the second block of the firmware.

2. The computing system (100) of claim 1, wherein: The security processor is further configured to verify the firmware by: in response to the expected hash value determined for the second block of the firmware matching the generated hash value of the second block of the firmware, setting a state of the firmware as verifiable; or In response to the expected hash value determined for the second block of firmware not matching the generated hash value of the second block of firmware, setting a status of the firmware as unverifiable.

3. The computing system (100) of claim 2, wherein: The expected hash value determined for the second block of the firmware matches the generated hash value of the second block of the firmware and the security processor is further configured to verify the firmware by: determining whether the second block of the firmware is a last block of the plurality of blocks of the firmware; as well as The firmware is indicated to the application processor in response to a state of the firmware being set to be verifiable and the second block of the firmware being a last block of the plurality of blocks of the firmware being verified.

4. The computing system (100) of claim 1, wherein: The security processor is further configured to determine the respective weight values ​​by accessing a body section of the firmware to obtain the respective weight values ​​assigned to the plurality of blocks of the firmware.

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

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

7. The computing system (100) of claim 1, wherein: The security processor is further configured to determine the respective probability verification threshold for each of the plurality of blocks of the firmware by using a random number generator.

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

9. The computing system (100) of claim 1, wherein: The security processor is further configured to determine the respective probability verification threshold for each of the plurality of blocks of the firmware using a random number generator.

10. The computing system (100) 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 weight value and a minimum weight value from the respective weight values ​​for the plurality of blocks of the firmware.

11. The computing system (100) of claim 1, wherein: The firmware verified by the security processor includes system firmware of the computing system and the memory further includes recovery firmware; or The firmware verified by the security processor includes recovery firmware for the computing system and the memory further includes system firmware.

12. The computing system (100) of claim 11, wherein: The security processor (108, 508) is configured to maintain firmware management parameters including options for directing the security processor (108, 508) in verifying the firmware or the restoring firmware.

13. The computing system (100) of claim 12, wherein: The security processor (108, 508) maintains the firmware management parameters in a write-protected portion of an internal memory of the security processor (108, 508).

14. A method for verifying firmware, comprising: The method causes a computing system to perform the operations of a computing system according to any one of claims 1 to 13.

15. A computer-readable storage medium comprising instructions which, when executed, cause a computing system to perform the operations of the computing system of any one of claims 1 to 13.

Images