Multi-stage device booting with independent stage keys

Abstract

Systems, apparatus, methods, and computer-readable media are disclosed for booting devices with independent stage keys. In one exemplary example, a computing device may generate a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device. The computing device may authenticate a first firmware of a first stage using a first authentication tag and a first stage key, wherein the first authentication tag is generated during a previous boot operation. The computing device may execute the first firmware based on authenticating the first firmware.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to electronic devices, and more particularly, but not exclusively, to systems and techniques for multi-stage boot with independent stage keys. BACKGROUND

[0002] Computing devices, such as mobile phones, tablet computers, and laptop computers, include many different components that support peripheral functionality. For example, a cellular phone can include a primary function that enables and supports cellular phone calls, as well as peripheral functions such as a still camera, a video camera, global positioning system (GPS) navigation, web browsing, sending and receiving email, sending and receiving text messages, push-to-talk capabilities, and the like. Many of these portable devices include a system on a chip (SoC) to enable one or more primary and peripheral functions on a particular device.

[0003] SoCs typically include multiple central processing unit (CPU) cores embedded in an integrated circuit or chip and coupled to a local bus. The CPU cores can be further arranged into or multiple compute clusters. SoCs can typically include hardware components and other processors. For example, a SoC can include one or more CPUs, CPUs with multiple cores, one or more digital signal processors, and the like, grouped as one or more subsystems. SoCs can also include other components such as network interfaces, programmable network processors, and other embedded components.

[0004] SoCs and other CPUs rely on a boot sequence or boot code when power is turned on. The boot sequence is an initial set of operations performed by the SoC when power is first applied to the SoC. The boot code enables the process of initializing and booting the SoC to load and execute an operating system (OS) (e.g., a bootstrap). The boot code is generally stored in read-only memory (ROM) for reasons of fast access, low complexity, space efficiency, low cost, and security. SUMMARY

[0005] The following presents a simplified summary related to one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary is presented in a simplified form to provide a basic understanding of some concepts relating to one or more aspects as disclosed herein before presenting a more detailed description in the following section.

[0006] Systems and techniques for providing multi-stage booting with independent stage keys are described herein. In one illustrative example, an apparatus configured for multi-stage booting is provided. The apparatus includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to generate a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device, authenticate a first firmware of the first stage using a first authentication tag and the first stage key, where the first authentication tag is generated during a previous boot operation, and execute the first firmware based on authenticating the first firmware.

[0007] In another example, a method of booting a device is provided. The method includes generating a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device, authenticating a first firmware of the first stage using a first authentication tag and the first stage key, where the first authentication tag is generated during a previous boot operation, and executing the first firmware based on authenticating the first firmware.

[0008] In another example, a non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to generate a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device, authenticate a first firmware of the first stage using a first authentication tag and the first stage key, where the first authentication tag is generated during a previous boot operation, and execute the first firmware based on authenticating the first firmware.

[0009] In another example, an apparatus for booting using at least one firmware is provided. The apparatus includes means for generating a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device, means for authenticating a first firmware of the first stage using a first authentication tag and the first stage key, where the first authentication tag is generated during a previous boot operation, and means for executing the first firmware based on authenticating the first firmware.

[0010] Aspects generally include a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, base station, wireless communication device, and / or processing system, as substantially described herein with reference to and as illustrated by the accompanying drawings and specification.

[0011] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows can be better understood. Additional features and advantages will be described below. The disclosed concepts and specific examples can be readily utilized as bases upon which the other structures can be built employing the principles of the disclosure. Such equivalent constructions do not depart from the scope of the claims. The characteristics of the concepts disclosed herein, both their organization and their method of operation, together with associated advantages will be better understood from the following description when considered in connection with the accompanying drawings. Each of the figures is provided to illustrate and describe aspects in accordance with the present disclosure, and is not intended to be limiting of the claims.

[0012] While aspects are described in the disclosure by illustration to some examples, those skilled in the art will understand that such aspects can be practiced in many different arrangements and scenarios. The technology described herein can be implemented using different platform types, devices, systems, shapes, sizes, and / or packaging arrangements. For example, some aspects can be implemented via integrated chip implementations or other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, and / or artificial intelligence devices). Aspects can be implemented in chip-level components, modular components, non-modular components, non-chip-level components, device-level components, and / or system-level components. Devices incorporating described aspects and features can include additional components and features employed to implement and practice the claimed and described aspects. For example, transmission and reception of wireless signals can include one or more components for analog and digital purposes (e.g., hardware components including antennas, radio frequency (RF) chains, power amplifiers, modulators, buffers, processors, interleavers, adders, and / or summers). It is intended that aspects described herein can be practiced in a wide variety of devices, components, systems, distributed arrangements, and / or end-user devices of varying size, shape, and constitution.

[0013] Other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0014] Examples of various specific implementations are described in detail below with reference to the following drawings: Figure 1 is a simplified schematic diagram of a system on a chip (SoC) in accordance with certain aspects of the disclosure.

[0015] Figure 2 a block diagram illustrating an example boot phase of an example SoC is illustrated; Figure 3 a method of authenticating multiple boot software binaries using multiple asymmetric encryption operations to authenticate each firmware in accordance with some aspects of the disclosure is illustrated. Figure 4 This is a conceptual diagram illustrating several asymmetric encryption operations according to some aspects of this disclosure; Figure 5 This is a block diagram illustrating multi-stage bootstrapping using independent stage keys according to some aspects of this disclosure; Figure 6 A method for authenticating multiple boot software binaries using independent stage keys, according to some aspects of this disclosure, is illustrated. Figure 7 This is a timeline illustrating example bootstrapping operations associated with multi-stage bootstrapping utilizing independent stage keys, according to some aspects of this disclosure; Figure 8 This illustrates a method for bootstrapping a device using a multi-stage approach with independent stage keys, according to some aspects of this disclosure; and Figure 9 An example of a computing system is shown, which can be any computing device, such as components that can implement the system. Detailed Implementation

[0016] Certain aspects and embodiments of this disclosure are provided below. Some of these aspects and embodiments may be applied independently, and some may be combined, as will be apparent to those skilled in the art. Specific details are set forth in the following description for purposes of explanation in order to provide a thorough understanding of the various embodiments of this application. However, it will be apparent, however, that the various embodiments may be practiced without these specific details. The accompanying drawings and descriptions are not intended to be limiting.

[0017] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the subsequent description of exemplary embodiments will provide those skilled in the art with enabling descriptions for implementing the exemplary embodiments. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the spirit and scope of this application as set forth in the appended claims.

[0018] System-on-a-chip (SoC) devices and modern processors (e.g., central processing units (CPUs), digital signal processors (DSPs), graphics processors, etc.) rely on boot sequences or boot code when powered on. For example, when executing a boot sequence, a system (e.g., an SoC) may utilize internal memory (e.g., on-chip memory on the same chip as the SoC, such as static random access memory (SRAM)) and complex drivers to securely boot the system. In some cases, when executing a boot sequence, a system (e.g., an SoC) may also utilize external memory (e.g., off-chip memory outside the same chip as the SoC, including dynamic random access memory (DRAM), such as double data rate (DDR) synchronous DRAM (SDRAM), low-power DDR (LPDDR), etc.), such as to save costs on the amount of internal memory used when the system (e.g., the SoC) has more functionality that requires more memory to boot. External memory may be stacked with the SoC (e.g., application processors, modem chips, etc.), may be configured in a stacked package design, may be entirely external (e.g., not on the same package as the SoC), etc.

[0019] As part of the boot sequence, a chain of bootloaders and delivery secure executables (e.g., firmware, also known as firmware images) may exist for each or a group of hardware components and other processors in a system (e.g., a System-on-a-Chip). Firmware is software that provides the basic machine instructions to the hardware, allowing it to operate and communicate with other software running on the device or other components interacting with the device. Firmware may also perform initial power-on functions, such as performing self-tests, initializing the device's state, etc. Firmware should be protected within the system to prevent malicious actors from tampering with it. Each hardware component in the system (e.g., a System-on-a-Chip) may require booting (e.g., secure boot) using a firmware image (e.g., a corresponding firmware image for each hardware component). Chained loading methods can be used to boot the various hardware components of the system (e.g., a System-on-a-Chip) by executing each firmware image in the firmware image chain. The larger the number of hardware components on the system (e.g., a System-on-a-Chip), the larger the number of firmware images the system needs to execute. Therefore, the system's boot time (e.g., secure and insecure booting of components in the System-on-a-Chip) is a function of the number of firmware images.

[0020] Furthermore, the booting of one or more hardware components can be protected, such as to comply with the requirements of strong integrity checks, authentication, or other security algorithms in certain applications, to ensure that the firmware image has not been tampered with or corrupted and originates from the intended source. Therefore, the system (e.g., SoC) can implement hash algorithms (e.g., SHA256, SHA384, SHA512, etc.), encryption algorithms (e.g., AES variants), and / or digital signature algorithms (e.g., RSA2K, RSA 4K, ECC P384, etc.) for checking the integrity and authentication of the firmware image. Hash algorithms can still be used to enforce firmware image integrity checks when secure booting is not enabled, such as when booting from flash media or flashless interfaces or interconnects (e.g., Universal Serial Bus (USB), Peripheral Component Fast Interconnect (PCIe), etc.). These various algorithms can be implemented in hardware or software on the system (e.g., SoC) and can increase the system's boot time due to computational complexity. The larger the number of firmware images, the more times these algorithms are run on the firmware images, thus increasing boot time.

[0021] Each firmware image may require multiple asymmetric cryptographic calculations to verify its authenticity. The system's root certificate is authenticated, and this root certificate is used to authenticate the leaf certificate that signs the firmware; the leaf certificate must then verify the signature. Asymmetric cryptographic calculations are more expensive due to their complexity and key length. For example, the National Institute of Standards and Technology (NIST) recommends 128-bit keys for symmetric encryption and 2048 bits for asymmetric encryption. In current hardware devices, a single asymmetric cryptographic calculation consumes a significant amount of time (e.g., 10 ms), and multiple calculations and further appended firmware can significantly increase the time associated with the boot operation. The boot operation is the process of booting (or starting) a device to a milestone defined for a specific product that indicates the end of the boot operation when the device is powered on or reset (e.g., power-on start). Boot milestones may vary based on the specific use case of the device. For example, in the case of a device with a user interface, the boot operation may begin with a power-on reset and end when the user interface loads and becomes available for the user to operate the device.

[0022] This document describes systems, apparatus, processes (also referred to as methods), and computer-readable media (collectively, “Systems and Technologies”) for a multi-stage boot process utilizing independent stage keys (referred to as stage-independent keys). In some cases, the stage key may include an authentication key. For example, according to some aspects, a multi-stage boot process may use a stage-independent key to perform firmware image authentication during the boot process of a system (e.g., a SoC, processor, etc.). In some cases, a multi-stage boot process may use an authentication tag to authenticate the firmware image based on a symmetric cryptographic function. In some aspects, the symmetric cryptographic function may be configured during a previous successful authentication using asymmetric encryption. For example, after authenticating the firmware image and certificate chain using a public key, a keyed hash of the firmware image may be computed and stored in an authentication tag. The authentication tag may be a key-value table or another data structure mapping an image associated with a hardware device (e.g., a wireless communication device) or hardware function (e.g., an external memory initialization function). During subsequent boots, the authentication tag may authenticate the firmware image instead of authenticating it based on a certificate chain. Symmetric cryptographic functions are faster and more efficient. In this case, the authentication tag can facilitate faster and more efficient boot operations.

[0023] Various aspects of this disclosure will be described with reference to the figures.

[0024] Figure 1 This is a block diagram of a SoC 100 according to certain aspects of this disclosure. The SoC 100 can be interconnected to other chips via one or more chip-to-chip interfaces, such as PCIe, USB, Serial Peripheral Interface (SPI), etc. In some aspects, one of the one or more chip-to-chip interfaces can be used to boot the SoC 100.

[0025] As shown in the figure, SoC 100 includes a CPU subsystem 105. CPU subsystem 105 includes multiple CPU cores 111, 112, 121, and 122. Although CPU subsystem 105 is shown as having a specific number of CPU cores, it should be noted that additional or fewer cores may be present in CPU subsystem 105. Furthermore, CPU cores 111 and 112 are part of cluster 110, and CPU cores 121 and 122 are part of cluster 120. Similarly, although shown as having a specific number of CPU clusters, CPU subsystem 105 may include additional or fewer clusters. Furthermore, each cluster may include the same or different numbers of CPU cores. The CPU cores of a given cluster (e.g., CPU cluster 110 or 120) may be of the same type or may be of different types (e.g., intra-cluster big.LITTLE design, cluster-based big.LITTLE design, etc.). The big.LITTLE design can refer to a computing architecture that includes low-power, slower processor cores that provide battery saving (e.g., LITTLE) and high-power, faster processor cores that provide better processing performance (e.g., big).

[0026] Furthermore, CPU subsystem 105 may include CPU resources, such as one or more caches. As shown, each cluster 110 and 120 includes caches 115 and 125, respectively. In some aspects, the CPU cores of clusters 110 and 120 may share caches 115 and 125 for memory storage, respectively. It should be noted that CPU subsystem 105 may include additional CPU resources or CPU resources different from those shown. For example, in some aspects, one or more CPU cores may have their own associated cache, one or more clusters may have their own associated cache (e.g., shared by the CPU cores of the cluster), and / or CPU subsystem 105 may include one or more caches shared by one or more clusters and / or CPU cores. SoC 100 may further include an additional CPU subsystem 103 and one or more digital signal processor (DSP) subsystems, such as DSP subsystem 107 and DSP subsystem 109. In some respects, each of the CPU subsystem 103, DSP subsystem 107, and DSP subsystem 109 may have its own functionality as (e.g., instead of) SRAMs 152, 154, and 156 for reading and writing data. The CPU subsystem 103 is shown as having a single CPU core 114, but may include additional cores, caches, etc.

[0027] SoC 100 further includes a reset controller 130, a fuse assembly 140, SRAM 150, read-only memory (ROM) 160, a DRAM controller 170, a memory controller 180, and a boot interface (I / F) controller 183, all of which are shown as internal (e.g., on-chip) components of SoC 100. The internal components of SoC 100 are coupled together via bus 185. Further, DRAM controller 170 is coupled via bus 192 to DRAM 190 external to SoC 100 (e.g., under-chip). The physical implementation of DRAM 190 may be stacked with SoC 100, may be configured as a stacked package design, may be entirely external (e.g., not part of the same package as SoC 100), etc. Memory controller 180 is coupled via bus 197 to memory device 195 (e.g., off-chip) external to SoC 100 (e.g., off-chip). In addition to caches 115 and 125, SRAM 150, DRAM 190 and storage device 195 provide storage capacity for SoC 100.

[0028] In some aspects, the reset controller 130 is configured to release the CPU core of the CPU subsystem 105 from reset during system boot. In some aspects, the released CPU core is then configured to begin executing code / data (e.g., boot code) from ROM 160 (such as the ROM bootloader BL0 shown) to begin booting the SoC 100. ROM 160 (e.g., boot ROM) is an integrated circuit that includes code (e.g., boot code) executed by the CPU subsystem 105 during initial power-on or after monitoring for reset conditions (e.g., after a failure of the SoC 100 detected by a timer that has not been reset or has "timed out" on the SoC 100). In some aspects, the CPU subsystem 105 boots (e.g., securely) from storage device 195 by running executable files, data images, etc., stored in storage device 195 for booting the SoC 100 (including various hardware components of the SoC 100). For example, the CPU subsystem 105 loads a firmware image from storage device 195 into DRAM 190 for execution. In some aspects, CPU subsystem 105 boots from a transport layer (e.g., a flash-free transport layer) rather than a storage device (e.g., securely). For example, CPU subsystem 105 can boot from the transport layer by loading a firmware image of the bootable SoC 100 received via the transport layer into DRAM 190 for execution. Specifically, SoC 100 can utilize boot I / F controller 183 to communicate with another component (e.g., another SoC) via a chip-to-chip interface. For example, boot I / F controller 183 of SoC 100 can control the chip-to-chip interface (e.g., a transport layer) of SoC 100 (such as PCIe 188 or USB 186) to communicate with the chip-to-chip interface of another component. Thus, SoC 100 can communicate via the transport layer through boot I / F controller 183.

[0029] In some respects, the CPU subsystem 105 boots securely by checking the integrity of the firmware image used for booting (e.g., using cryptographic signature protocols, chains of trust, authentication tags, checksums, etc.) before executing the firmware image.

[0030] In some respects, CPU subsystem 105 is configured to boot by running a firmware image, as shown, loaded in DRAM 190, SRAM 150, SRAM 152, SRAM 154, and SRAM 156. For example, CPU subsystem 105 executes a ROM bootloader BL0 from ROM 160. ROM bootloader BL0 causes CPU subsystem 105 to execute bootloader BL1a in SRAM 150. Bootloader BL1a can initialize DRAM controller 170 and DRAM 190. In some respects (e.g., in a boot configuration from a flash memory device), bootloader BL1a also initializes memory controller 180 and memory device 195, and causes CPU subsystem 105 to load a firmware image from memory device 195 into DRAM 190 for execution. In some respects (e.g., in a flashless boot configuration), bootloader BL1a also initializes boot I / F controller 183 (rather than initializing storage controller 180 and storage device 195) and causes CPU subsystem 105 to load firmware received via the transport layer into DRAM 190 for execution. Thus, SoC 100 can access the firmware image from DRAM 190. BL1a can further boot SoC 100 by controlling the execution of additional firmware images (such as bootloaders BL2, BL3, and BL4, TZ (e.g., Secure World firmware), HYP (e.g., HyperManager firmware), and OS1 (e.g., operating system)) on the application processor (e.g., CPU subsystem 105) subsystem. Furthermore, in some aspects, other subsystem firmware images booted during the boot process include PWR (e.g., power firmware), CPU subsystem 103 FW1 (e.g., CPU subsystem 103 firmware), CPU subsystem 103 OS1 (e.g., CPU subsystem 103 operating system), DSP107 FW1 (e.g., DSP subsystem 107 firmware), and DSP109 FW1 (e.g., DSP subsystem 109 firmware). In some aspects, BL1a can boot the SoC 100 by controlling the execution of additional firmware images through other subsystems, such as BL1b executed by DSP subsystem 107 and BL1c executed by CPU subsystem 103. In some aspects, certain early firmware images are booted by BL1a, and the remaining firmware images are booted by an operating system such as OS1.

[0031] Typically, the execution of each of BL0, BL1a, BL2, BL3, and BL4 occurs on a single core of CPU subsystem 105 (e.g., CPU core 111), and each runs as a single thread. The operating system (such as the core of OS1) is the first firmware image executed on SoC 100, which enables the scheduler to facilitate multi-threading and multi-core optimization to allow multiple CPU cores of CPU subsystem 105 to execute additional firmware images during boot and / or to allow processes to be executed as individual threads running on one or more CPU cores of CPU subsystem 105. For example, BL2 and BL3 may implement and facilitate a pre-boot environment (e.g., as defined by the Unified Extensible Firmware Interface (UEFI) specification), and BL4 may be the boot manager that loads the OS.

[0032] UEFI is a specification that describes the software interface between an operating system (OS) and the hardware platform or system (e.g., a System-on-a-Chip) on which the OS executes. For example, UEFI distinguishes between a pre-boot environment (before the OS executes on the SoC) and a post-boot environment (where the OS executes on the SoC). This distinction between boot environments allows the OS to be designed in a hardware-independent manner, and the software interface can establish an interface between the OS and the SoC. In some aspects, the Platform Initialization (PI) specification can define the pre-boot environment, for example, before the boot process is complete and the OS is fully operational. The PI specification includes the SoC's boot phase chain (e.g., Security (SEC) phase, Pre-EFI Initialization (PEI) phase, Driver Execution Environment (DXE) phase, Boot Device Selection (BDS) phase, Operating System Loader phase, etc.).

[0033] A pre-boot environment can be configured by loading and executing firmware or firmware images that enable the pre-boot environment on the SoC. The pre-boot environment provides certain drivers, frameworks, protocols, and interfaces, and allows certain applications to run on the SoC within the pre-boot environment. For example, boot manager applications (e.g., OS loaders) can execute in a pre-boot environment that loads the OS. Other applications can also run in the pre-boot environment, such as applications that test and verify the functionality of the CPU cores and memory, and applications that program firmware images to the SoC (e.g., via fast boot) at the factory.

[0034] Figure 2 This is a block diagram illustrating an example boot phase (e.g., stage) of a SoC according to some aspects of this disclosure. Figure 2An example boot phase chain is illustrated in the UEFI and PI specifications defining the pre-boot environment. Each boot phase may correspond to a separate firmware image loaded and running on the CPU core of SoC 100 (e.g., CPU core 111) to perform the functions of the boot phase. The firmware image may correspond to or be included in a BL3 firmware image. The first boot phase in this chain is shown as PI (e.g., SEC) 202, which is initially loaded on SoC 100. PI 202 is configured to perform platform, target, and architecture-dependent initialization.

[0035] PI 202 is configured to provide initialization information to the next boot phase in DXE 204. In some aspects, DXE 204 is configured to enable driver services in the pre-boot environment. For example, DXE 204 includes a core image (e.g., DxeCoreImage) that provides platform, compiler target, and architecture-independent capabilities. DXE 204 is configured to load one or more driver images 206, such as driver images from external storage devices (not shown). Each driver corresponds to a driver service that provides platform, compiler target, and architecture-independent capabilities and services. The driver services can then be made available to any application that boots and executes on the compute core of the SoC in the pre-boot environment. For example, a file system driver can enable UEFI to read the contents of the storage medium.

[0036] After loading driver image 206, the SoC continues booting by loading and executing BDS 208. During the execution of BDS 208, all drivers are loaded and initialized at the SoC. Furthermore, the complete pre-boot environment system and protocol services function normally. BDS 208 is configured to handle boot options based on persistent settings in environment variables. Furthermore, BDS 208 can be configured to boot various applications 210, such as OS loader applications, any verification applications, etc., to continue booting the SoC. In one aspect, application 210 can load and boot OS 212 on the SoC. Although some examples are shown in relation to UEFI environments and UEFI applications, these techniques can be similarly applied to other suitable environments and applications.

[0037] One limitation of the UEFI specification (and also of most conventional bootloaders or preboot environments such as U-Boot, CoreBoot, etc.) is that it is restricted to using a single CPU core of the SoC, executing a single thread. For example, applications running in a preboot environment may be limited to using a single CPU core of the SoC and executing as a single thread, and the SoC's boot process may occur solely using that single CPU core running a single thread. Using a single CPU core for booting can slow down boot times and impact the performance of processes in the preboot environment, such as the SoC's authentication and factory programming processes.

[0038] Figure 3 This illustrates a method for booting an OS within a SoC based on conventional asymmetric encryption operations. In some aspects, the CPU of the SoC or device (e.g., a mobile phone, a laptop computer, an extended reality (XR) device such as a virtual reality (VR) device or an augmented reality (AR) device, a vehicle or a component or system of a vehicle, or other types of computing devices) is capable of executing... Figure 3 The operation.

[0039] At box 302, the SoC or CPU can load a hash associated with the root certificate. The hash can be stored in non-volatile memory, such as ROM or an electrical fuse programmed into the SoC or CPU.

[0040] At box 304, the SoC or CPU may verify the root certificate based on a hash. In this case, the hash is static and cannot be changed to prevent tampering with the SoC or CPU. The SoC or CPU may load the root certificate, which may be stored in another non-volatile memory, and subsequently verify that the root certificate has not been altered based on a one-way hash, which should make the result of the one-way hash correspond to the hash loaded in box 302. Although not shown, booting will fail if the result of the one-way hash does not correspond to the hash loaded in box 302.

[0041] If the hash is indeed verified at box 304, at box 306, the SoC or CPU can load the next stage firmware (e.g., device firmware) into the SoC or CPU's memory. The SoC and CPU device architecture may vary, and the firmware may be stored on secure or insecure storage media.

[0042] At box 308, the SoC or CPU can use asymmetric key operations to authenticate the certificate chain and binary signature of the firmware. For example, at box 308, at least two asymmetric key operations can be performed. Specifically, the firmware may also include a proof certificate, a public key, and a signature. Firmware verification may include at least two authentications. For example, the SoC or CPU can verify whether the root certificate has been signed with the proof certificate using the public key. After verifying the proof certificate, the SoC or CPU can use the proof certificate and the signature to verify the firmware.

[0043] In the example described in box 308, at least two symmetric encryption operations are performed. In some examples, box 308 may include authentication of multiple firmware (or firmware images). For example, an original equipment manufacturer (OEM) may sign firmware to prevent third-party manufacturers from modifying the firmware and subsequently further signing it.

[0044] At box 310, the SoC or CPU determines whether the firmware in box 308 has been authenticated. If the firmware fails authentication, the boot process cannot proceed. If the SoC determines at box 310 that the software binary has been authenticated, the SoC or CPU continues to box 312.

[0045] At box 312, the SoC or CPU determines whether an additional boot phase is required. In some cases, the SoC may include three phases of the boot process, but the final number of phases varies depending on the device, the functionality required to be supported during the boot operation, etc. In one example, the first phase initializes memory and basic hardware components, the second phase initializes various drivers (e.g., network interfaces), and the third phase initializes one or more protocols (e.g., to boot an external image to repair the device). The boot phases are provided as examples and are not limited to the types of phases, the purposes of different phases, etc. If an additional boot phase is determined to exist at box 312, the SoC or CPU returns to box 306 to load the firmware for the next phase. Alternatively, if no additional boot phase exists at box 312, the SoC or CPU continues to load the operating system, and method 300 ends.

[0046] As mentioned above, asymmetric encryption operations are processor-intensive and consume a small amount of time. In some cases, the amount of firmware to be loaded can increase based on the number of embedded devices (e.g., network interfaces, DSPs, neural network processing units (NNPUs), network processing units (NPUs), hardware interfaces, etc.). Additionally, as mentioned above, each driver performs at least two asymmetric encryption operations on each software boot binary. These operations can consume a significant amount of time and may add an unusual amount of time to the boot process, as well as increase the power consumption during startup.

[0047] Figure 4This is an example instance 400 of a firmware load sequence using asymmetric encryption operations. Specifically, Figure 4 Examples include root certificate 405, first proof certificate 415 signed by root certificate 405, second proof certificate 425 signed by first proof certificate 415, and firmware 440 signed by second proof certificate 425. Each stage of signature authentication (or verification) certifies (or verifies) the signature of the next stage, and verifies the signature of each certificate at each stage.

[0048] In this scenario, each certificate (e.g., root certificate 405, first proof certificate 415, etc.) includes a signature to verify the authenticity of the next stage. In this case, there are at least three authentications using asymmetric encryption, which can result in significant time commitments. For example, loading firmware might result in a 10ms computation time per asymmetric operation, while loading three firmware images would result in a 90ms delay. However, the device may have a large number of firmware files to load, and the boot process could cause significant delays.

[0049] Figure 5 This is a block diagram illustrating a multi-stage boot device 500 utilizing independent stage keys according to some aspects of this disclosure. In some aspects, the multi-stage boot device 500 includes a firmware access engine 510 configured to authenticate one or more firmware files. In some cases, firmware may also be referred to as a boot software binary or firmware image. As presented above, firmware is a software binary loaded into the device and executed by the device. In some cases, firmware may also be a pure function configured to perform initialization or testing functions. For example, external memory (e.g., DDR) may need to be initialized during the boot sequence. Firmware access engine 510 may include a root certificate verification engine 512 configured to authenticate a root certificate image stored within the device. In some aspects, the root certificate may be stored in non-volatile memory (such as flash memory media), and the hash associated with the root certificate may be stored in hardware (such as ROM or a device fuse). In some cases, multiple root certificates and multiple corresponding hashes may be stored. For example, in the event of a corrupted root certificate, the corresponding fuse may be blown to prevent the use of the root certificate. Firmware access engine 510 is configured to calculate the hash of the root certificate at boot time and compare the calculated hash with the hash stored in the hardware to verify that the root certificate has not been modified. Generally, the root certificate does not necessarily need to be stored in a secure location, but it should not be used to prevent accidental system corruption.

[0050] Firmware access engine 510 also includes an asymmetric verification engine 514 configured to perform conventional asymmetric authentication of software boot binaries as described above. For example, asymmetric verification engine 514 may be configured to authenticate firmware by signing an authentication certificate and subsequently verifying the firmware's signature using that certificate.

[0051] Firmware access engine 510 also includes a symmetric verification engine 516 configured to perform symmetric authentication based on previous asymmetric authentication according to some aspects of this disclosure. In some cases, symmetric authentication may also include a hash function to verify the authenticity of a message. In some cases, an authentication tag may be generated by the symmetric verification engine 516 during asymmetric authentication of the software boot binary and subsequently used by the symmetric verification engine 516 during subsequent boots to authenticate the firmware. In some aspects, symmetric authentication requires a single authentication per firmware at each stage, compared to at least two asymmetric authentications in asymmetric verification engine 514. In some aspects, the symmetric verification engine 516 may be configured to fall back to the asymmetric verification engine 514 in some cases. For example, when an over-the-air (OTA) firmware update occurs, the hash calculated by the symmetric verification engine 516 will fail based on the firmware having changed, and an asymmetric encryption operation will be performed to verify the authenticity of the updated firmware.

[0052] 500 also includes a storage medium 520 for storing multiple firmware 522 and authentication tags 524 (e.g., Figure 1 The storage device 524 is a symmetric cryptographic value or hash value, and each authentication tag corresponds to a single firmware 522. For example, each authentication tag 524 may be a cryptographic hash that uniquely identifies the firmware 522 based on a corresponding cryptographic hash function. In some aspects, keyed cryptographic hash functions may be used to create the hash for each firmware 522. In some aspects, the boot process may consist of several stages, such as loading a first set of firmware to access system components (e.g., external memory, flash memory, etc.), followed by a second stage (e.g., network drivers, etc.). For example, since the firmware for later stages may be too large for the internal SRAM in the SoC or CPU, the first set of firmware may initialize DDR memory to allow for later booting to external memory.

[0053] In some respects, the authentication tag 524 can be a key pair value that maps firmware 522 to a value. This key can be, for example, an address or other metadata that uniquely identifies the firmware 522 corresponding to that value. In this case, the value is a hash value calculated by the asymmetric authentication engine 514 during the boot process. As mentioned above, firmware 522 can be updated using OTA technology, and upon the next boot, the hash value stored in the authentication tag 524 will not match because firmware 522 has different content. Tables 1 through 3 below illustrate example tables of authentication tags 524 corresponding to different firmware boot stages of the device. The firmware listed in Tables 1 through 3 is non-limiting and is provided to illustrate different possible firmware that can be implemented by the SoC or CPU.

[0054]

[0055] Table 1: Boot Phase 1 Firmware

[0056] Table 2: Boot Phase 1 Firmware

[0057] Table 3: Boot Phase 3 Firmware

[0058] Although the authentication tag 524 is described as a keyed hash, it can also be ciphertext that can be decoded using a private key. In one respect, the private key can decode a sequence number or other identifying information (such as a checksum) to verify the authenticity of the firmware or device. In another respect, the authentication tag 524 can be keyed to detect tampering with the authentication tag. When the authentication tag 524 is a keyed hash, it can be stored in an unrestricted storage medium, such as unused flash memory protected by a securely designated address space. In other respects, the authentication tag 524 may further include additional information, such as the encryption type, hash type, or other identifying information that distinguishes different types of encryption or hashes.

[0059] Figure 6 A method 600 for authenticating multiple boot software binaries using independent stage keys, according to some aspects of this disclosure, is illustrated. Method 600 can implement... Figure 5 Firmware access engine 510 and is powered by computing devices (e.g., the CPU core 111 of the SoC or...) Figure 9 The computational system 900) performs the operation. In one aspect, method 600 corresponds to the operations associated with the asymmetric verification engine 514 and the symmetric verification engine 516, and is assumed to begin after loading and authenticating the initial boot sequence associated with the boot ROM.

[0060] At box 602, the computing system can load the next stage of firmware (e.g., from...). Figure 5 Multiple firmware files (522) and authentication tags (e.g., authentication tag 524) are included. The firmware may be loaded into the CPU's SRAM (e.g., SRAM 152) or into external memory (e.g., DDR memory) based on the availability of external memory (e.g., if DDR memory has been initialized).

[0061] At box 604, the computing system can generate a stage-specific key based on the device private key and the boot value. The private key can be made unavailable to system resources and, for example, can be programmed into an electrical fuse or restricted ROM, and the boot value is a value associated with the boot stage. In some cases, the boot value can be a spin value determined based on hardware resources (such as a random number generator) or other methods.

[0062] At box 606, the computing system calculates the hash value of the loaded firmware based on the authentication tag and the phase-specific key. Although the hash has been calculated, other types of values ​​can still be generated. For example, the ciphertext can be decoded using the phase-specific key. For clarity, in this non-limiting respect, the following description assumes the use of a hash function.

[0063] At box 608, the calculation system determines whether the authentication tag has been authenticated. For example, if the calculation system determines that the hash value calculated at box 608 corresponds to an authentication tag associated with the corresponding firmware (e.g., the keyed hash values ​​illustrated in Tables 1 to 3 above), then the firmware is authenticated and method 600 proceeds to box 610. In some aspects, box 608 may include the authentication of multiple firmware images. For example, as presented in Tables 1 to 3 above, boot phase 1 to boot phase 3 each include multiple firmware images, and each firmware image must be authenticated to proceed to box 610. If the calculated hash value does not correspond to an authentication tag associated with the corresponding firmware, then the firmware is not authenticated and method 600 proceeds to box 612.

[0064] At box 612, the computing system falls back to conventional authentication using asymmetric encryption, as described above. For example, the computing system can verify that the certificate associated with the firmware is authentic, and subsequently use the public key to verify that the firmware's signature is genuine. Although not shown, the inability to authenticate the firmware indicates that the firmware is corrupted and cannot boot. For clarity, it is assumed that the firmware is authenticated at box 612.

[0065] At box 614, the computing system can use a phase-specific key to generate an authentication tag for firmware that failed authentication at box 608. For example, the computing system can generate a hash based on the firmware and the phase-specific key.

[0066] At box 616, the computing system can update the authentication tag used for the firmware. For example, assuming the USB firmware identified in Table 2 is updated in an OTA update, the USB firmware will fail authentication based on the authentication tag at box 608 due to the OTA update. However, the USB firmware is signed using a certificate of proof (e.g., during an OTA update) and authenticated at box 612. The computing system updates the keying hash in Table 3 above based on the new authentication tag generated for the updated firmware at box 616. After updating the authentication tag, method 600 proceeds to box 618.

[0067] At box 610, the computing system determines that the boot phase is complete and updates the boot value to correspond to the next phase. In some respects, box 610 may occur at the beginning or end of a phase. For example, box 610 may occur after loading the firmware image at box 602. In this case, the boot value ensures that the firmware is loaded in the corresponding phase and in the correct order. For example, the image signal processor (ISP) firmware may have a size exceeding that of the SRAM of the CPU core (e.g., CPU core 111), and external DDR memory should be initialized so that the CPU can store the ISP firmware in the DDR memory.

[0068] The computing system can also provide firmware to the corresponding device for various devices to initialize the SoC or CPU. As mentioned above, firmware is executed by the device for low-level control, such as for controlling hardware components within the device.

[0069] At box 618, the computing device determines whether there are further boot stages. If there are further boot stages, method 600 returns to box 602 to load the firmware associated with the next stage. If there are no further boot stages, the computing system then proceeds to operations related to loading the OS to enable user interaction with the device.

[0070] Figure 7 This is a timeline 700 illustrating an example boot operation associated with multi-stage booting utilizing independent stage keys, according to some aspects of this disclosure. In some aspects, timeline 700 is not drawn to scale and is provided to further describe the operation of firmware access engine 510. In some aspects, prior to timeline 700, the computing system (e.g., the CPU core 111 of the SoC or...) Figure 9 The computing system (900) loads, authenticates, and executes the initial boot ROM. In some aspects, the boot ROM includes executing... Figure 7 Method 600 executes the instructions for the operations described in the timeline.

[0071] In one aspect, at time t0, the computing system generates a Phase 1 key associated with the firmware for that phase. As an example, the Phase 1 key could be “A890A” and be a keyed hash used to verify the authentication key or a private key used to decrypt the authentication tag. In one example, a key derivation function, for example, is used to combine the computing system's boot value and the device's private key to generate the Phase 1 key. As presented above, the Phase 1 key is associated with a hash function or cryptographic function associated with the Phase 1 firmware.

[0072] At time t1, the computing system uses an authentication tag to authenticate firmware BL1a. For example, the Phase 1 key could be a key used to generate a keyed hash, and if the firmware is authentic, the resulting keyed hash value corresponds to the value of the authentication tag (e.g., as shown in Tables 1 through 3). As described above, the firmware's keyed hash is generated after authenticating the firmware using a slower and more processor-intensive asymmetric authentication technique.

[0073] At time t2, the computing system uses an authentication tag to authenticate firmware BL2a. In this case, the Phase 1 boot involves two different firmwares, but this phase may include additional or fewer firmware images to be authenticated.

[0074] At time t3, the computing system determines that all boot state 1 firmware is genuine and proceeds to load the firmware into each corresponding device or execute the corresponding function, and subsequently updates the boot value to correspond to phase 2. For example, as proposed above, phase 1 may include DDR firmware, which includes instructions executed by the CPU core to initialize the memory. The generation of the boot value corresponding to phase 2 can be any suitable function to generate a suitable key combined with the device key. For example, the boot value could be a rotation key generated based on an encryption algorithm using, for example, system time.

[0075] In Phase 1, loading time is reduced because symmetric encryption is faster than asymmetric encryption. As an example, a 128-bit private key is recommended for symmetric encryption, and a 2048-bit asymmetric key is recommended. The private key will require less computation due to the virtual key length, but asymmetric computation is still more complex.

[0076] At time t4, the computing system is considered to have entered Phase 2, and a Phase 2 key is generated based on the updated boot value (at time t3) and the private device key. For example, as... Figure 7 As shown, for illustrative purposes, the Phase 2 key is "76AF1".

[0077] At time t5, the computing system loads firmware BL2a from a storage device (e.g., ROM, flash memory, etc.) and authentication using the authentication tag fails. For example, as mentioned above, BL2a may have already been updated due to an OTA firmware update.

[0078] At time t6, the computing system uses the public key to authenticate firmware BL2a, as well as the authentication of the certificate that signed firmware BL2a.

[0079] At time t7, the computing system generates an authentication tag for firmware BL2a. For example, using the phase 2 key generated at time t4, the computing system generates a keyed hash and subsequently stores that keyed hash in the authentication tag. For example, the computing system can use tables to update values ​​associated with the corresponding firmware (such as those illustrated in Tables 1 through 3 above).

[0080] At time t8, the computing system uses the corresponding authentication tag to authenticate firmware BL2b. In this case, based on symmetric encryption, firmware BL2b is considered authentic.

[0081] At time t9, the computing system determines that all boot state 2 firmware is real, proceeds to load the firmware into each corresponding device or execute the corresponding function, and then updates the boot value to correspond to stage 3.

[0082] At time t 10 At this point, the computing system is considered to have entered Phase 3, and a Phase 3 key is generated based on the updated boot value (at time t9) and the private device key. For example, as... Figure 7 As shown, for illustrative purposes, the Phase 3 key is "1FF03".

[0083] At time t 11 At this stage, the computing system uses the corresponding authentication tag (e.g., from Table 3) to authenticate firmware BL3. After authenticating all firmware in stage 3, the computing system determines that the firmware in boot state 3 is genuine and proceeds to load the firmware into each corresponding device or execute the corresponding function.

[0084] At time t 12 At this point, the computing system has loaded all firmware and continues to load the OS.

[0085] Figure 8 This is a flowchart illustrating a process 800 for bootstrapping a device using a multi-stage process leveraging independent stage keys, according to some aspects of this disclosure. Process 800 may be performed by a computing device or a component or system of the computing device (e.g., Figure 1 SoC or Figure 9 The computing device (900) executes the process. In some cases, the computing device may be integrated into a mobile device (e.g., a mobile phone), a network-connected wearable device (such as a watch), an extended reality (XR) device (such as a virtual reality (VR) device or an augmented reality (AR) device), a vehicle or a component or system of a vehicle, or other types of computing devices. The operation of process 800 may be implemented on one or more processors (e.g., Figure 1 CPU, Figure 9 Software components that execute and run on one or more of the processor 910 and / or other processors.

[0086] In some respects, a computing device (or a component thereof) may load an initial boot phase from a boot read-only memory and authenticate the initial boot phase using a public key associated with it. In this case, the first-stage key is generated based on the authentication of the initial boot phase. For example, if the initial boot phase is not authenticated, the boot process fails.

[0087] At box 802, the computing device (or a component thereof) may generate a first-stage key for the first stage of the current boot operation of the device based on the private key associated with the device.

[0088] In one aspect, as part of box 802, a computing device (or a component thereof) may use symmetric encryption based on a first-stage key to compute a first value associated with first firmware. The symmetric encryption may be the computation of ciphertext, the decoding of ciphertext, or the computation of a hash. The value determined based on the symmetric encryption is compared with a first authentication tag to authenticate the first firmware. For example, the computed hash can authenticate the validity of the first firmware. In other examples, the decoded text from the ciphertext can authenticate the validity of the first firmware.

[0089] At box 804, the computing device (or a component thereof) may use a first authentication tag and a first-stage key to authenticate the first firmware of the first stage, wherein the first authentication tag was generated during a previous boot operation. The first authentication tag may be generated based on symmetric encryption using a private key and a boot value corresponding to the boot stage of the current boot operation.

[0090] In some respects, as part of box 804, the first authentication tag may be unavailable (e.g., the first authentication tag is deleted during an OTA update). In this case, the computing device (or a component thereof) may authenticate the first firmware using a public key based on the unavailability of the first authentication tag, and generate a first authentication tag for the first firmware based on authenticating the first firmware using the public key.

[0091] In some cases, as part of box 804, the first firmware was updated by the device during a previous power cycle and therefore failed to be authenticated due to the different firmware. In this case, the computing device (or a component thereof) may authenticate the first firmware using a public key based on the identifier that the first firmware does not correspond to the first authentication tag, and generate an updated authentication tag for the first firmware based on the authentication of the first firmware using the public key.

[0092] In some respects, as part of box 804, the computing device (or a component thereof) may authenticate the first authentication tag based on a message authentication code. In this case, in response to the inability to authenticate the first authentication tag, the computing device (or a component thereof) may use a public key to authenticate the first firmware and, based on the authentication of the first firmware, generate an updated authentication tag for the first firmware.

[0093] In some cases, the initial authentication tag and the initial firmware are stored on a single storage medium. For example, the initial firmware and the initial authentication tag may be stored on an insecure storage medium, such as flash memory. Because the authentication tag is a key or keyed hash, tampering with the firmware or authentication tag will be detected. In other cases, the authentication tag and the firmware may be stored in different locations. For example, the initial authentication tag may be stored on a restricted storage medium.

[0094] At block 806, the computing device (or a component thereof) may execute the first firmware based on certified first firmware. In one exemplary aspect, as part of block 806, the execution of the first firmware may include loading the first firmware into a corresponding device and subsequently executing the first firmware at that device. In another aspect, as part of block 806, the execution of the first firmware may be a function that initializes a component of the computing device (or a component thereof). For example, this function may be an initialization function that initializes DDR memory or a flash drive. In some aspects, this function may be a test to ensure the component operates.

[0095] In some cases, after executing the first firmware, the computing device may update the boot value to correspond to the second stage based on verifying each firmware associated with the first stage. After updating the boot value, computation may generate a second-stage key for the second stage of the current boot operation based on the private key and the boot value, and subsequently use a second authentication tag and the second-stage key to authenticate the second firmware. After authenticating the second firmware, the computing device (or a component thereof) may execute the second firmware associated with the second device. For example, the second firmware may be loaded into the memory of the second device and executed. However, the second firmware may be executed from the CPU core to initialize, test, or execute another function associated with the second device.

[0096] In some aspects, the boot phase may include multiple firmware files to be loaded and authenticated. In this case, the computing device (or a component thereof) may use a second authentication tag and a first-phase key to authenticate a second firmware file in the first phase, and execute the second firmware file based on the authenticated second firmware file.

[0097] Figure 9 This is a diagram illustrating an example of a system used to implement certain aspects of this technology. Specifically, Figure 9 An example of a computing system 900 is illustrated. This computing system can be any computing device, such as constituting an internal computing system, a remote computing system, a camera, or any component thereof, wherein the components of the system communicate with each other using a connection 905. The connection 905 can be a physical connection using a bus, or a direct connection to a processor 910, such as in a chipset architecture. The connection 905 can also be a virtual connection, a networking connection, or a logical connection.

[0098] In some embodiments, the computing system 900 is a distributed system, wherein the functions described herein may be distributed across a data center, multiple data centers, a peer-to-peer network, etc. In some embodiments, one or more system components described represent a number of such components that each perform some or all of the functions described for which the component is used. In some embodiments, the components may be physical devices or virtual devices.

[0099] Example computing system 900 includes at least one processing unit (CPU or processor) 910 and a connection 905 that communicatively couples various system components, including system memory 915 (such as ROM 920 and RAM 925), to processor 910. Computing system 900 may include a cache 912 of high-speed memory that is directly connected to, closely proximates, or integrated into processor 910.

[0100] Processor 910 may include any general-purpose processor and hardware or software services, such as services 932, 934, and 936 stored in storage device 930, which are configured to control processor 910 and dedicated processors in which software instructions are incorporated into the actual processor design. Processor 910 may be a substantially completely independent computing system containing multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0101] To enable user interaction, the computing system 900 includes an input device 945 that can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphic input, a keyboard, a mouse, motion input, voice input, etc. The computing system 900 may also include an output device 935 that can be one or more of a plurality of output mechanisms. In some instances, a multimodal system allows a user to provide multiple types of input / output to communicate with the computing system 900.

[0102] The computing system 900 may include a communication interface 940, which typically controls and manages user input and system output. The communication interface may perform or facilitate the receiving and / or transmitting of wired or wireless communications using wired and / or wireless transceivers, including utilizing audio jacks / plugs, microphone jacks / plugs, USB ports / plugs, Apple... ™ Lightning ™ Ports / plugs, Ethernet ports / plugs, fiber optic ports / plugs, dedicated wired ports / plugs, 3G, 4G, 5G and / or other cellular data network wireless signal transmission, Bluetooth ™ Wireless signal transmission, Bluetooth ™ Low-power (BLE) wireless signal transmission, IBEACON™ Wireless signal transmission, including radio frequency identification (RFID) wireless signal transmission, near field communication (NFC) wireless signal transmission, dedicated short range communication (DSRC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, wireless local area network (WLAN) signal transmission, visible light communication (VLC), microwave access global interoperability (WiMAX), infrared (IR) wireless signal transmission, public switched telephone network (PSTN) signal transmission, integrated services digital network (ISDN) signal transmission, ad hoc network signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet light signal transmission, wireless signal transmission along the electromagnetic spectrum, or some combination thereof. The communication interface 940 may also include one or more Global Navigation Satellite System (GNSS) receivers or transceivers used to determine the location of the computing system 900 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based Global Positioning System (GPS), the Russian-based Global Navigation Satellite System (GLONASS), the Chinese-based BeiDou Navigation Satellite System, and the European-based Galileo GNSS. There are no limitations on operation on any particular hardware configuration, and therefore the underlying features can be easily replaced to obtain improved hardware or firmware configurations as they are developed.

[0103] Storage device 930 may be a non-volatile and / or non-transitory and / or computer-readable storage device, and may be a hard disk or other type of computer-readable medium capable of storing data accessible by a computer, such as magnetic tape, flash memory cards, solid-state storage devices, digital multifunction discs, cartridges, floppy disks, hard disks, magnetic tapes, magnetic stripes, any other magnetic storage media, flash memory, memristor memory, any other solid-state storage, CD-ROM, rewritable CD, DVD, Blu-ray Disc, holographic disc, another optical medium, Secure Digital (SD) card, microSD card, Memory Stick ®Cards, smart card chips, EMV chips, Subscriber Identity Module (SIM) cards, mini / micro / nano / micro SIM cards, another integrated circuit (IC) chip / card, random access memory (RAM), SRAM, DRAM, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash EPROM, cache memory (e.g., layer 1 (L1) cache, layer 2 (L2) cache, layer 3 (L3) cache, layer 4 (L4) cache, layer 5 (L5) cache, or other (L#) cache), resistive random access memory (RRAM / ReRAM), phase change memory (PCM), spin-transfer torque RAM (STT-RAM), another memory chip or cassette and / or combinations thereof.

[0104] Storage device 930 may include software services, servers, services, etc., which enable the system to perform functions when the code defining such software is executed by processor 910. In some embodiments, hardware services performing specific functions may include software components for performing functions stored in a computer-readable medium connected to necessary hardware components such as processor 910, connection 905, output device 935, etc. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. Computer-readable media may include non-transitory media in which data can be stored and which does not include carrier waves and / or transient electronic signals propagated wirelessly or via a wired connection. Examples of non-transitory media may include, but are not limited to, magnetic disks or magnetic tapes, optical storage media (such as compact discs (CDs) or digital versatile discs (DVDs)), flash memory, memory, or memory devices. Computer-readable media may store code and / or machine-executable instructions thereon, which may represent procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements. Code segments may be coupled to other code segments or hardware circuitry by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0105] Specific details have been provided in the foregoing description to offer a thorough understanding of the various embodiments and examples presented herein, but those skilled in the art will recognize that this application is not limited thereto. Therefore, although exemplary embodiments of this application have been described in detail herein, it is to be understood that the inventive concept can be embodied and adopted in a variety of other ways, and the appended claims are intended to be construed as including such variations, unless limited by prior art. Various features and aspects of the applications described above may be used individually or in combination. Furthermore, without departing from the broader scope of this specification, the embodiments can be used in any number of environments and applications beyond those described herein. Therefore, the specification and drawings should be considered illustrative rather than restrictive. For illustrative purposes, the methods are described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in a different order than described.

[0106] For clarity, in some cases, this technology may be presented as comprising individual functional blocks, which include devices, device components, steps, or routines embodied in a method, either in software or a combination of hardware and software. Additional components may be used in addition to those shown in the figures and / or described herein. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form to avoid obscuring these embodiments with unnecessary detail. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without necessary detail to avoid obscuring the embodiments.

[0107] Furthermore, those skilled in the art will understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such specific implementation decisions should not be construed as departing from the scope of this disclosure.

[0108] Individual implementations may be described above as processes or methods depicted as flowcharts, flow diagrams, data flow diagrams, structure diagrams, or block diagrams. Although flowcharts may describe operations as sequential processes, many operations within an operation may be executed in parallel or concurrently. Furthermore, the order of operations may be rearranged. A process terminates when its operations are completed, but a process may have additional steps not included in the accompanying drawings. A process may correspond to a method, function, procedure, subroutine, subroutine, etc. When a process corresponds to a function, the termination of the process may correspond to the function returning to the calling function or the main function.

[0109] The processes and methods described in the examples above can be implemented using stored computer-executable instructions or computer-executable instructions otherwise available from a computer-readable medium. Such instructions may include, for example, instructions and data that configure, or otherwise configure, a general-purpose computer, special-purpose computer, or processing device to perform a function or group of functions. The portion may be accessible via a network of the computer resources used. The computer-executable instructions may be, for example, binary, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that can be used to store the instructions, the information used, and / or information created during the methods according to the described examples include disks or optical discs, flash memory, USB devices with non-volatile memory, networked storage devices, etc.

[0110] In some implementations, computer-readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0111] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and arts. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description may, in some cases, be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc.

[0112] The various exemplary logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein can be implemented or executed using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any form factor of various form factors. When implemented in software, firmware, middleware, or microcode, program code or code segments (e.g., computer program products) for performing necessary tasks can be stored in a computer-readable or machine-readable medium. A processor can perform the necessary tasks. Examples of form factors include: laptop computers, smartphones, mobile phones, tablet devices, or other small form factor personal computers, personal digital assistants, rack-mounted devices, self-contained devices, etc. The functionality described herein can also be embodied in peripheral devices or interlocking cards. By further example, such functionality can also be implemented on circuit boards in different chips or different processes running on a single device.

[0113] Instructions, media for delivering such instructions, computing resources for executing them, and other structures for supporting such computing resources are example components for providing the functionality described in this disclosure.

[0114] The techniques described herein can also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques can be implemented in any of a variety of devices, such as general-purpose computers, wireless communication devices (mobile phones), or integrated circuit devices with multiple uses, including applications in wireless communication devices (mobile phones) and other devices. Any feature described as a module or component can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques can be implemented at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, perform one or more of the methods, algorithms, and / or operations described above. The computer-readable data storage medium can form part of a computer program product, which may include packaging material. The computer-readable medium may include memory or data storage media, such as random access memory (RAM) (such as synchronous dynamic random access memory (SDRAM)), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. Additionally or alternatively, the technology may be implemented at least in part by a computer-readable communication medium that carries or conveys program code in the form of instructions or data structures that can be accessed, read and / or executed by a computer, such as propagated signals or waves.

[0115] The program code can be executed by a processor, which may include one or more processors, such as one or more DSPs, general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Such processors can be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor; however, in alternatives, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Therefore, as used herein, the term "processor" may refer to any of the foregoing structures, any combination of the foregoing structures, or any other structure or means suitable for implementing the techniques described herein.

[0116] Those skilled in the art will understand that, without departing from the scope of this specification, the less than (“<”) and greater than (“>”) symbols or terms used herein may be represented by less than or equal to (“>”) respectively. The sign "") and greater than or equal to (" The symbol ) is used instead.

[0117] When a component is described as being “configured” to perform certain operations, such configuration can be achieved, for example, by designing electronic circuits or other hardware to perform the operations, by programming programmable electronic circuits (e.g., microprocessors or other suitable electronic circuits) to perform the operations, or any combination thereof.

[0118] The phrase “coupled to” or “communicatively coupled to” means that any component is physically connected directly or indirectly to another component, and / or that any component is in communication with another component directly or indirectly (e.g., connected to that other component via a wired or wireless connection and / or other suitable communication interface).

[0119] Claim language or other languages ​​that state "at least one of" and / or "one or more of" in a set indicate that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language stating "at least one of A and B" or "at least one of A or B" means A, B, or A and B. In another example, claim language stating "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, A and B and C, or any repetition is information or data (e.g., A and A, B and B, C and C, A and A and B, etc.), or any other ordering, repetition, or combination of A, B, and C. The language "at least one of" and / or "one or more of" in a set does not limit the set to the items listed in the set. For example, the language of a claim that expresses “at least one of A and B” or “at least one of A or B” may mean A, B or A and B, and may additionally include items not listed in the set of A and B.

[0120] Claims containing phrases such as "at least one processor, the at least one processor being configured to," or other languages ​​indicate that one or more processors (in any combination) are capable of performing associated operations. For example, a claim containing the phrase "at least one processor, the at least one processor being configured to: X, Y, and Z" means that a single processor can be used to perform operations X, Y, and Z; or that multiple processors are each assigned a specific subset of tasks involving operations X, Y, and Z, such that the multiple processors together perform X, Y, and Z; or that a group of multiple processors work together to perform operations X, Y, and Z. In another example, a claim containing the phrase "at least one processor, the at least one processor being configured to: X, Y, and Z" could mean that any single processor can perform only at least one subset of operations X, Y, and Z.

[0121] The exemplary aspects of this disclosure include: Aspect 1. A method for booting a device, the method comprising: generating a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device; authenticating first firmware of the first stage using a first authentication tag and the first stage key, wherein the first authentication tag was generated during a previous boot operation; and executing the first firmware based on the authentication of the first firmware.

[0122] Aspect 2. The method according to aspect 1, wherein authenticating the first firmware includes: using symmetric encryption to calculate a first value associated with the first firmware based on the first stage key; and comparing the first firmware with the first authentication tag to authenticate the first firmware.

[0123] Aspect 3. The method according to any one of Aspects 1 to 2, wherein the first authentication tag is generated based on symmetric encryption using the private key and a boot value corresponding to the boot phase of the current boot operation.

[0124] Aspect 4. The method according to aspect 3, the method further comprising: updating the boot value to correspond to the second phase based on verifying each firmware associated with the first phase.

[0125] Aspect 5. The method according to aspect 4, the method further comprising: after updating the boot value, generating a second-stage key for the second stage of the current boot operation based on the private key and the boot value; authenticating the second firmware using a second authentication tag and the second-stage key; and executing the second firmware based on the authentication of the second firmware.

[0126] Aspect 6. The method according to any one of Aspects 1 to 5, the method further comprising: authenticating the first firmware using a public key based on the first authentication tag being unavailable; and generating the first authentication tag of the first firmware based on the authentication of the first firmware using the public key.

[0127] Aspect 7. The method according to any one of Aspects 1 to 6, the method further comprising: authenticating the first firmware using a public key based on an identifier that the first firmware does not correspond to the first authentication tag; and generating an updated authentication tag for the first firmware based on the authentication of the first firmware using the public key.

[0128] Aspect 8. The method according to aspect 7, wherein the first firmware is updated by the device during a previous power cycle of the device.

[0129] Aspect 9. The method according to any one of Aspects 1 to 8, the method further comprising: loading an initial boot phase from a boot read-only memory; and authenticating the initial boot phase using a public key associated with the initial boot phase, wherein the first phase key is generated based on the authentication of the initial boot phase.

[0130] Aspect 10. The method according to any one of Aspects 1 to 9, the method further comprising: authenticating the first authentication tag based on a message authentication code; authenticating the first firmware using a public key in response to the inability to authenticate the first authentication tag; and generating an updated authentication tag for the first firmware based on the authentication of the first firmware.

[0131] Aspect 11. The method according to aspect 10, wherein the first authentication tag and the first firmware are stored in a single storage medium.

[0132] Aspect 12. The method according to any one of Aspects 1 to 11, wherein the first authentication tag is stored in a restricted storage medium.

[0133] Aspect 13. The method according to any one of Aspects 1 to 12, the method further comprising: authenticating the second firmware of the first stage using a second authentication tag and the first stage key; and executing the second firmware based on the authentication of the second firmware.

[0134] Aspect 14. An apparatus for performing a boot operation, the apparatus comprising at least one memory and at least one processor, the at least one processor being coupled to the memory and configured to: generate a first stage key for a first stage of a current boot operation of the device based on a private key associated with the device; authenticate first firmware of the first stage using a first authentication tag and the first stage key, wherein the first authentication tag was generated during a previous boot operation; and execute the first firmware based on the authentication of the first firmware.

[0135] Aspect 15. The apparatus according to aspect 14, wherein the at least one processor is configured to: compute a first value associated with the first firmware using symmetric encryption based on the first stage key; and compare the first firmware with the first authentication tag to authenticate the first firmware.

[0136] Aspect 16. The apparatus according to any one of Aspects 14 to 15, wherein the first authentication tag is generated based on symmetric encryption using the private key and a boot value corresponding to the boot phase of the current boot operation.

[0137] Aspect 17. The apparatus according to aspect 16, wherein the at least one processor is configured to update the boot value to correspond to the second phase based on verifying each firmware associated with the first phase.

[0138] Aspect 18. The apparatus according to aspect 17, wherein the at least one processor is configured to: after updating the boot value, generate a second-stage key for the second stage of the current boot operation based on the private key and the boot value; authenticate the second firmware using a second authentication tag and the second-stage key; and execute the second firmware based on the authentication of the second firmware.

[0139] Aspect 19. The apparatus according to any one of Aspects 14 to 18, wherein the at least one processor is configured to: authenticate the first firmware using a public key based on the first authentication tag being unavailable; and generate the first authentication tag of the first firmware based on the authentication of the first firmware using the public key.

[0140] Aspect 20. The apparatus according to any one of Aspects 14 to 19, wherein the at least one processor is configured to: authenticate the first firmware using a public key based on an identifier that the first firmware does not correspond to the first authentication tag; and generate an updated authentication tag for the first firmware based on the authentication of the first firmware using the public key.

[0141] Aspect 21. The apparatus according to aspect 20, wherein the first firmware is updated by the device during a previous power cycle of the device.

[0142] Aspect 22. The apparatus according to any one of Aspects 14 to 21, wherein the at least one processor is configured to: load an initial boot phase from a boot read-only memory; and authenticate the initial boot phase using a public key associated with the initial boot phase, wherein the first phase key is generated based on the authentication of the initial boot phase.

[0143] Aspect 23. The apparatus according to any one of Aspects 14 to 22, wherein the at least one processor is configured to: authenticate the first authentication tag based on a message authentication code; authenticate the first firmware using a public key in response to the inability to authenticate the first authentication tag; and generate an updated authentication tag for the first firmware based on the authentication of the first firmware.

[0144] Aspect 24. The apparatus according to aspect 23, wherein the first authentication tag and the first firmware are stored in a single storage medium.

[0145] Aspect 25. The apparatus according to any one of Aspects 14 to 24, wherein the first authentication tag is stored in a restricted storage medium.

[0146] Aspect 26. The apparatus according to any one of Aspects 14 to 25, wherein the at least one processor is configured to: authenticate the second firmware of the first stage using a second authentication tag and the first stage key; and execute the second firmware based on the authentication of the second firmware.

[0147] Aspect 27. A non-transitory computer-readable storage medium comprising instructions stored thereon, the instructions causing the at least one processor, when executed by at least one processor, to perform any one of aspects 1 to 13.

[0148] Aspect 28. An apparatus for guiding a device, the apparatus comprising one or more components for performing operations according to any one of aspects 1 to 13.

Claims

1. A method for booting a device, the method comprising: generating, based on a private key associated with the device, a first stage key for a first stage of a current boot operation of the device; authenticating, using a first authentication tag and the first stage key, a first firmware of the first stage, wherein the first authentication tag is generated during a previous boot operation; and executing the first firmware based on authenticating the first firmware.

2. The method of claim 1, wherein authenticating the first firmware comprises: calculating, based on the first stage key, a first value associated with the first firmware using symmetric encryption; and comparing the first firmware with the first authentication tag to authenticate the first firmware.

3. The method of claim 1, wherein the first authentication tag is generated based on symmetric encryption using the private key and a boot value corresponding to a boot stage of the current boot operation.

4. The method of claim 3, the method further comprising: updating the boot value to correspond to a second stage based on verifying each firmware associated with the first stage.

5. The method of claim 4, the method further comprising: generating, after updating the boot value, a second stage key for the second stage of the current boot operation based on the private key and the boot value; authenticating a second firmware using a second authentication tag and the second stage key; and executing the second firmware based on authenticating the second firmware.

6. The method of claim 1, the method further comprising: authenticating the first firmware using a public key based on the first authentication tag being unavailable; and generating the first authentication tag for the first firmware based on authenticating the first firmware using the public key.

7. The method of claim 1, the method further comprising: authenticating the first firmware using a public key based on identifying that the first firmware does not correspond to the first authentication tag; and generating an updated authentication tag for the first firmware based on authenticating the first firmware using the public key.

8. The method of claim 7, wherein the first firmware is updated by the device during a previous power cycle of the device.

9. The method of claim 1, the method further comprising: loading an initial boot stage from a boot read-only memory; and authenticating the initial boot stage using a public key associated with the initial boot stage, wherein the first stage key is generated based on authentication of the initial boot stage.

10. The method of claim 1, the method further comprising: authenticating the first authentication tag based on a message authentication code; authenticating the first firmware using a public key in response to being unable to authenticate the first authentication tag; and generating an updated authentication tag for the first firmware based on authenticating the first firmware.

11. The method of claim 10, wherein the first authentication tag and the first firmware are stored in a single storage medium.

12. The method of claim 1, wherein the first authentication tag is stored in a restricted storage medium.

13. The method of claim 1, further comprising: authenticating second firmware of the first stage using a second authentication tag and the first stage key; and executing the second firmware based on authenticating the second firmware.

14. An apparatus configured for multi-stage booting, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: generate a first stage key for a first stage of a current boot operation of the apparatus based on a private key associated with the apparatus; authenticate first firmware of the first stage using a first authentication tag and the first stage key, wherein the first authentication tag is generated during a previous boot operation; and execute the first firmware based on authenticating the first firmware.

15. The apparatus of claim 14, wherein the at least one processor is configured to: calculate a first value associated with the first firmware based on the first stage key using symmetric encryption; and compare the first firmware to the first authentication tag to authenticate the first firmware.

16. The apparatus of claim 14, wherein the first authentication tag is generated based on symmetric encryption using the private key and a boot value corresponding to a boot stage of the current boot operation.

17. The apparatus of claim 16, wherein the at least one processor is configured to: update the boot value to correspond to a second stage based on verifying each firmware associated with the first stage.

18. The apparatus of claim 17, wherein the at least one processor is configured to: generate a second stage key for the second stage of the current boot operation based on the private key and the boot value after updating the boot value; authenticate second firmware using a second authentication tag and the second stage key; and execute the second firmware based on authenticating the second firmware.

19. The apparatus of claim 14, wherein the at least one processor is configured to: authenticate the first firmware using a public key based on the first authentication tag not being available; and generate the first authentication tag for the first firmware based on authenticating the first firmware using the public key.

20. The apparatus of claim 14, wherein the at least one processor is configured to: authenticate the first firmware using a public key based on identifying that the first firmware does not correspond to the first authentication tag; and generate an updated authentication tag for the first firmware based on authenticating the first firmware using the public key.

21. The apparatus of claim 20, wherein the first firmware is updated by the apparatus during a previous power cycle of the apparatus.

22. The apparatus of claim 14, wherein the at least one processor is configured to: load an initial boot stage from a boot read-only memory; and ​ authenticating the initial boot stage using a public key associated with the initial boot stage, wherein the first stage key is generated based on authentication of the initial boot stage.

23. The apparatus of claim 14, wherein the at least one processor is configured to: authenticate the first authentication tag based on a message authentication code; in response to being unable to authenticate the first authentication tag, authenticate the first firmware using a public key; and based on authenticating the first firmware, generate an updated authentication tag for the first firmware.

24. The apparatus of claim 23, wherein the first authentication tag and the first firmware are stored in a single storage medium.

25. The apparatus of claim 14, wherein the first authentication tag is stored in a restricted storage medium.

26. The apparatus of claim 14, wherein the at least one processor is configured to: authenticate second firmware of the first stage using a second authentication tag and the first stage key; and based on authenticating the second firmware, execute the second firmware.

Images