Device security boot assistance and related systems, methods and devices

Abstract

The systems, methods, and devices of the present disclosure generally relate to secure boot assistance for devices. In one or more embodiments, a first device includes firmware that needs to be verified as secure as part of a secure boot process, and a second device assists the first device in implementing the secure boot process. In some embodiments, the second device verifies the security of the firmware in response to security data provided by the first device, or verifies the security of a program provided by the first device, the program being used to verify the security of the firmware. In some embodiments, the second device provides the program for verifying the security of the firmware to the first device.

Description

[0001] Priority Declaration

[0002] This application claims the benefit of the filing date of U.S. Provisional Patent Application Serial No. 62 / 760,636, filed on November 13, 2018, and entitled “SECURE BOOT ASSIST FOR MICROCONTROLLERS AND RELATED SYSTEMS, METHOD AND DEVICES,” and claims the benefit of the filing date of co-pending U.S. Patent Application Serial No. 16 / 364,391, filed on March 26, 2019, and entitled “SECURE BOOT ASSIST FOR DEVICES, AND RELATED SYSTEMS, METHODS AND DEVICES,” the disclosures of each of which are hereby incorporated by reference herein in their entirety. Technical Field

[0003] The present disclosure generally relates to ensuring that firmware to be executed at a target device is secure; and more specifically, some embodiments generally relate to using a security device external to the target device to ensure that a program used to verify the firmware at the target device is secure; and still more specifically, some embodiments generally relate to using a security device external to the target device to control at least some secure boot processes at the target device to ensure that the firmware to be executed at the target device is secure. Background Art

[0004] The firmware that runs a device such as a microcontroller unit (MCU) sometimes needs to be updated "in the field" (i.e., after the device has left the factory), for example, because the manufacturer releases a new version of the firmware to correct a bug or add functionality. Because the flash memory can be modified by the firmware itself, many devices use flash memory or other non-volatile memory to store the firmware. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] While the disclosure concludes with claims that particularly point out and distinctly claim specific embodiments, the various features and advantages of embodiments within the scope of the present disclosure may be more readily ascertained from the following description when read in conjunction with the accompanying drawings, in which:

[0006] Figure 1 is a simplified block diagram of a computing system according to one or more embodiments of the present disclosure;

[0007] Figure 2is a simplified block diagram of a system for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure;

[0008] Figure 3 is an exemplary process for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure;

[0009] Figure 4 is a simplified block diagram of a system for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure;

[0010] Figure 5 is an exemplary process for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure;

[0011] Figure 6 is a simplified block diagram of a system for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure;

[0012] Figure 7 is an exemplary process for ensuring the authenticity of an MCU application according to one or more embodiments of the present disclosure; DETAILED DESCRIPTION

[0013] In the following detailed description, reference is made to the accompanying drawings which form a part of the present disclosure and in which are shown, by way of example, specific examples of embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable one of ordinary skill in the art to practice the present disclosure. However, other embodiments may be utilized, and changes in structure, materials, and processes may be made without departing from the scope of the present disclosure.

[0014] The illustrations presented herein are not intended to be actual views of any particular method, system, apparatus, or structure, but are merely idealized representations for describing embodiments of the present disclosure. The drawings presented herein are not necessarily drawn to scale. For the convenience of the reader, similar structures or components in the various drawings may retain the same or similar numbering; however, similarity in numbering does not necessarily mean that the structures or components are identical in size, composition, configuration, or any other attribute.

[0015] It should be readily understood that the components of the embodiments as generally described herein and shown in the accompanying drawings may be arranged and designed in a variety of different configurations. Therefore, the following description of various embodiments is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments.

[0016] The following description may include examples to help those skilled in the art practice the embodiments disclosed herein. The use of terms such as "exemplary," "example," "for example," "e.g.," and the like means that the description is illustrative, and while the scope of the present disclosure is intended to encompass examples and legal equivalents, the use of such terms is not intended to limit the embodiments or the scope of the present disclosure to the specified components, steps, features, functions, and the like.

[0017] Therefore, unless otherwise indicated herein, the specific embodiments shown and described are merely examples and should not be construed as the only way to implement the present disclosure. Components, circuits, and functions may be shown in block diagram form so as not to obscure the present disclosure with unnecessary detail. On the contrary, the specific embodiments shown and described are merely exemplary and should not be construed as the only way to implement the present disclosure, unless otherwise indicated herein. Additionally, the block definitions and the partitioning of logic between the various blocks are examples of specific embodiments. It will be apparent to one of ordinary skill in the art that the present disclosure can be practiced with many other partitioning solutions. In most cases, details regarding timing considerations, etc., have been omitted where such details are not required for a complete understanding of the present disclosure and are within the capabilities of one of ordinary skill in the relevant art.

[0018] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols that may be referenced throughout this specification may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof. For clarity of presentation and description, some figures may illustrate signals as single signals. Those skilled in the art will appreciate that a signal may represent a signal bus, where the bus may have a variety of bit widths, and that the present disclosure may be implemented on any number of data signals, including a single data signal.

[0019] The various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or implemented with a general-purpose processor, a special-purpose processor, a digital signal processor (DSP), an integrated circuit (IC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof designed to implement the functions described herein. A general-purpose processor (also referred to herein as a host processor or simply a host) may be a microprocessor, but in an alternative embodiment, 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, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. When a general-purpose computer is configured to execute computing instructions (e.g., software code) related to the embodiments of the present disclosure, the general-purpose computer including the processor is considered a special-purpose computer. Although the code may be described herein as being configured to enable the processor to perform certain functions or operations, the description of the processor may be omitted in some cases because the inventors believe that repeated descriptions of the processor may obscure the details of the disclosed embodiments. For example, code may sometimes be described as performing, or being configured to perform, functions or operations of the disclosed embodiments without specifically reciting that the functions or operations are performed by the processor executing the code.

[0020] The embodiments may be described in terms of a process depicted as a flow chart, a flow diagram, a structure diagram, or a block diagram. Although a flow chart may describe operational actions as a sequential process, many of these actions may be performed in another sequence, in parallel, or substantially simultaneously. In addition, the order of the actions may be rearranged. A process may correspond to a method, a thread, a function, a program, a subroutine, a subprogram, etc. In addition, the methods disclosed herein may be implemented in hardware, software, or both. If implemented in software, these functions may be stored or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include both computer storage media and communication media, including any medium that facilitates transferring a computer program from one location to another.

[0021] Unless such limitation is explicitly stated, any reference to an element herein using names such as "first," "second," etc. does not limit the number or order of those elements. Rather, these names may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, reference to a first element and a second element does not mean that only two elements can be employed there, or that the first element must precede the second element in some manner. Furthermore, unless otherwise indicated, a group of elements may include one or more elements.

[0022] As used herein, the term "substantially" with respect to a given parameter, property, or condition refers to and includes the degree to which a person of ordinary skill in the art would understand that the given parameter, property, or condition is satisfied with a small degree of variance, such as, for example, within acceptable manufacturing tolerances. By way of example, depending on the specific parameter, property, or condition that is substantially satisfied, the parameter, property, or condition may be satisfied by at least 90%, by at least 95%, or even by at least 99%.

[0023] As used in this disclosure, the terms "unit," "module," or "component" may refer to a specific hardware implementation configured to perform the actions of the unit, module, or component and / or a software object or software routine that may be stored on and / or executed by general-purpose hardware of a computing system (e.g., a computer-readable medium, a processing device, etc.). In some embodiments, the different units, components, modules, engines, and services described in this disclosure may be implemented as objects or processes that execute on a computing system (e.g., as separate threads). Although some of the systems and methods described in this disclosure are generally described as being implemented in software (stored on and / or executed by general-purpose hardware), specific hardware implementations or combinations of software and specific hardware implementations are possible and contemplated.

[0024] Boot code is often used in conjunction with field programming of a device. Boot code is a small section (i.e., block) of code (as compared to application code) that is added to the operating code (i.e., stored in flash memory) that performs system functions, such as when the device is turned on or when the device performs a reset. In typical embedded systems (particularly those that use flash memory), the boot code may perform tasks such as checking the contents of the flash memory and system initialization tasks. The operating code may be responsible for moving new firmware to the embedded system and replacing the old firmware, and may share some of the boot code's functionality for checking the new firmware image or may rely on the boot code to check the new firmware image.

[0025] To tell a device to prepare to receive new firmware, hardware and / or software conditions are typically used. An example of a hardware condition might be pressing a button during a device reset, and an example of a software condition might be detecting the absence of a valid application stored on the device during a reset. If the boot code (typically the boot code that performs the check at system startup) detects an update condition, the installation application or boot code will attempt to connect to a host (e.g., a personal computer or programming tool, but not limited to such) and wait to receive an image of the new firmware. Once the new firmware is moved to the device and replaces the old firmware, the new code can be executed by the device.

[0026] One issue that sometimes arises during field programming of devices is that the new firmware may not be authentic. For example, it may be designed or provided by an unauthorized third party, i.e., not by a licensee, such as the original manufacturer or a third party authorized by the original manufacturer. Consequently, the new firmware can be developed for malicious purposes, such as, but not limited to, bypassing security protections or illegally accessing critical device functions. Furthermore, the new firmware may be provided by a licensee but intended for a different device.

[0027] Another issue is that the integrity of the new firmware may be compromised. That is, the new firmware's data may be modified (sometimes only slightly) from its original form. The modified firmware may still appear authentic, but these modifications may facilitate the same security issues mentioned above: bypassing security protections or illicit use of critical device functions. Furthermore, compromised firmware can expose the firmware to the outside world and enable third parties to copy and / or reverse engineer the manufacturer's firmware.

[0028] Another issue is that privacy can be compromised if an image of the new firmware (an electronic copy of the firmware distributed to the device) is exposed or accessible. The firmware can be decompiled or otherwise analyzed by a third party when it is transferred to the target device, and proprietary information stored in or about the firmware can be captured.

[0029] Boot code is a critical part of maintaining the security (i.e., authenticity, integrity, and / or privacy) of the firmware. Firmware security is sometimes verified by the boot code in an operating sequence often referred to as a "secure boot sequence." For example, in a typical secure boot sequence, the boot code is the first code executed after the processor has been reset or powered on. The boot code then verifies the security of the new firmware stored in program memory, and if the new firmware is verified, the boot code initiates the loading and execution of the firmware.

[0030] Verifying firmware security typically involves authenticating the source of new application code and confirming the integrity of the firmware. This is typically done using a digital signature and / or a message authentication code (MAC) unique to the authorized party, such as using the corresponding public key for digital signatures or the private key used to calculate the MAC.

[0031] To verify integrity, a hash function is typically used when creating firmware to generate a digest (sometimes also called a "message digest") corresponding to the created firmware. The hash function used to create the digest is assumed to be the same hash function stored on the target device when it was manufactured. This "first" digest can be encrypted, for example, using public-key cryptography to obtain a digital signature. This digital signature can be distributed with the new firmware for field programming of the device. When the device receives the firmware and the first digital signature, it calculates a second digest from the received firmware using a locally stored hash function, which should be the same hash function used to create the first digest. The receiver encrypts the second digest to obtain a second digital signature and compares the second digital signature to the first to determine whether the signatures match. If the firmware has been modified, even slightly, then theoretically (statistically, the probability of a collision (i.e., obtaining the same digest when using the same hash function with different firmware) is very small) the second digest will not match the first, and therefore the first digital signature will not match the second.

[0032] In some cases, the boot code can use the public key corresponding to the private key used to create the first digital signature to decrypt the first digital signature and recover the first digest. The boot code can then create a second digest as described herein and compare the first digest and the second digest to determine whether they match. MAC codes generated using private key cryptography are sometimes used in place of or in addition to digital signatures. It is worth noting that encryption is also used to implicitly authenticate the target device, i.e., to verify that it is the authentic or intended target device for the firmware.

[0033] Verification of firmware security depends, at least in part, on establishing a "root of trust" for the security of the initial program itself, such as the boot code, which is responsible for authentication, integrity validation, and / or decryption. Conventional techniques for establishing this initial root of trust are to store the boot code in read-only memory (ROM) of the target device and, for a secure boot process, either execute the boot code directly from the ROM or copy the stored boot code into program memory and, as an initial step, use the stored boot code to verify the security of the copied boot code. In either case, the ROM establishes the initial root of trust.

[0034] Secure boot capabilities are increasingly being used in devices such as MCUs, but many existing devices lack a boot ROM (i.e., a ROM on which boot code is stored) to establish an initial root of trust and implement the secure boot process. Some devices, such as microprocessors (MPUs), implement a separate chip between the processor and memory, but this technique is not feasible for devices with integrated code memory (i.e., the same memory for both operating code and boot code). Furthermore, in the case of MCUs, changing the mask set of each MCU to include a boot ROM would be prohibitive and expensive in terms of cost and time.

[0035] Therefore, the inventors of the present disclosure have recognized a need for systems, methods, and devices that assist target devices in performing a secure boot process. In some embodiments, such systems, methods, and devices can establish a root of trust for implementing a secure boot at a target device without requiring a boot ROM or other hardware for establishing a root of trust. Furthermore, the inventors of the present disclosure have recognized a need for systems, methods, and devices for implementing a secure boot process in a target device that initially does not have secure boot capabilities or requires a stronger root of trust.

[0036] One or more embodiments of the present disclosure generally relate to using a secure external device (e.g., a chip or microcontroller, but not limited thereto) to verify the boot code of a host device or provide boot code to the host device so that the host device can perform a secure boot process. In one or more embodiments, the hardware output of the security device is operably coupled to the hardware input of the host device, wherein the hardware input is the only trigger for initiating a restricted operating mode at the host device, and during the restricted mode, the host device cannot independently execute local code (e.g., boot code or operating code, but not limited thereto) and the I / O ports are disabled except for the interface of the host device having a set of I / O ports that can only be accessed and controlled by the secure external device. In one or more embodiments, the connections for the hardware inputs and interfaces can be physically isolated so that they are not accessible from the outside, for example by stacking and / or packaging the security device with the host device in a module so that the connection is "hidden" between the security device and the host device. In this way, the hardware input of the host device can be characterized as a "trust anchor" between the security device and the host device.

[0037] Figure 1A simplified block diagram of a computing system 100 according to one or more embodiments of the present disclosure is shown, the computing system including a security device 110 and a host device 130. As non-limiting examples, the computing system 100 can be a component of, be part of, or include a component of a microcontroller-based embedded system, a consumer computer, a file server, a computer server, a laptop computer, a tablet computer, a handheld device, a mobile device, a wireless earbud or headphone device, a wired earbud or headphone device, an appliance, an automotive subsystem, or other computer system for executing software. Computer, computing system, and server are used interchangeably herein to refer to a system for practicing embodiments of the present disclosure. The computing system 100 can be configured to execute software programs containing computing instructions and can include one or more processors, memory, storage devices, user interface elements, one or more communication elements, and combinations thereof.

[0038] In one or more embodiments, host device 130 may include a central processing unit (CPU) 140, flash memory 136 (i.e., flash memory), CPU interface 134, RAM 146, input / output (I / O) ports 132, and peripheral devices 148. Flash memory 136 may be, for example, program memory and may be used to store computing instructions, data structures, and other information (collectively referred to herein as "firmware") used to perform a variety of tasks, including executing embodiments of the present disclosure. By way of example, firmware may include operating code and boot code. By way of further example, operating code may include code for integrating an embedded system, an operating system, an operating system loader, separately installed applications, and combinations thereof. Flash memory 136 is a non-limiting example of non-volatile memory, but it should be understood that any non-volatile memory may be used in place of flash memory, including, but not limited to, silicon nitride-based charge trapping devices and resistive memory, without exceeding the scope of the present disclosure. CPU 140 may use RAM 146 in conjunction with performing computations and other operations on data, including executing embodiments of the present disclosure.

[0039] The CPU 140 can be configured to execute a wide variety of software such as an operating system and / or application programs, including computing instructions for executing all or part of the embodiments of the present disclosure. The CPU 140 can be a single-core or multi-core processor, and the one or more cores can be any combination of dedicated (e.g., a DSP or ASIC, but not limited to) and general-purpose processors configured and / or programmed to perform one or more functions described in the present disclosure. In a multi-core embodiment, these cores can operate independently and interdependently (including but not limited to in a master-slave arrangement). The CPU 140 includes a control unit 142 that controls the CPU 140 via the CPU interface 134. As an example, the control unit 142 can be used to control the CPU 140 to read and write to the flash memory 136 and the RAM 146, execute (all or part) software stored at the flash memory 136 and / or the RAM 146, enable / disable the I / O port 132 of the host device 130, check the internal state or variables of the CPU 140, and / or set checkpoints, breakpoints, and watchpoints. Such functionality can be used for a variety of applications, including but not limited to testing / debugging computing system 100, updating computing system 100, protecting computing system 100 from unsafe code, and more generally implementing embodiments of the present disclosure. Any descriptors used herein such as "debug," "test," "verify," or "certify" are not intended to limit the general applicability of such circuitry.

[0040] exist Figure 1 In the example shown, the CPU 140 communicates with the system via multiple buses (in Figure 1 The bus 144 is labeled as bus 144 in FIG. 1 to communicate with the flash memory 136, RAM 146, and I / O port 132. By way of example, the bus 144 may include various buses that perform one or more functions of an address bus, a data bus, a peripheral bus, an event bus, a test bus, and a program bus, but is not limited thereto.

[0041] The control unit 142 is incorporated into the CPU 140 and is directly accessible by the CPU interface 134. The CPU interface 134 communicates with the I / O port 132 via the bus 144 and communicates with external devices (such as the security device 110 or the host computer) via the I / O port 132. The I / O port 132 may include a variety of input and output ports implemented in hardware and / or software. In various embodiments, the I / O port 132 may include general-purpose and specialized I / O ports (GPIO and SPIO) for sending and receiving messages and signals, a software port for communicating with the CPU interface 134, a port for receiving an asserted reset of the security device 110 from the computing system 100, and other ports.

[0042] Peripherals 148 are configured to perform a variety of peripheral support functions in conjunction with CPU 140 and / or independently, including, for example, analog input and output, serial input / output, timers, and threshold detection circuits. Figure 1 132, one or more of the I / O ports 132 may be implemented as peripherals 148. For example, a GPIO may be implemented as a peripheral 148. In one or more embodiments, the peripherals 148 may include a peripheral configured to place and / or maintain the CPU 140 in a reset mode, whereby the CPU 140 cannot begin "normal" operation. For example, while in reset mode, the CPU 140 cannot load the memory address of the first instruction into the program counter, or, as another example, cannot fetch the first instruction at the memory address in the flash memory 136. Such a peripheral may place and / or maintain the CPU 140 in reset mode in response to detecting power-on of the computing system 100 and / or the CPU 140, or detecting a condition that is treated as power-on of the computing system 100, such as, for example, a reset caused by assertion of a hardware input of the I / O port 132.

[0043] In one or more embodiments, the security device 110 includes a trusted sequence circuit 112, a cryptographic circuit 114, a ROM 116, and an I / O port 118. The trusted sequence circuit 112 may generally be configured to perform functions and other operations for verifying boot code and / or firmware according to embodiments of the present disclosure. The cryptographic circuit 114 may generally be configured to perform asymmetric and / or cryptographic operations such as signature verification, MAC generation / verification, hash digest calculation encryption / decryption, or other operations using stored public, private, or secret keys according to embodiments of the present disclosure. More specifically, the cryptographic circuit 114 may more generally be configured to provide one or more public and / or private cryptographic services to the security device 110 and / or computing system 100. In one or more embodiments, the cryptographic circuit 114 may be an analog circuit, an integrated circuit, software, or a combination thereof. The ROM 116 may store data and code for executing one or more embodiments of the present disclosure, including, for example, a trusted copy of the boot code.

[0044] exist Figure 1 In the example shown, I / O port 118 of security device 110 and I / O port 132 of host device 130 are operatively coupled via bidirectional connection 122 to facilitate the transfer of messages and data between the two devices, including the execution of one or more embodiments of the present disclosure.

[0045] Figure 2 A simplified block diagram of an exemplary system 200 for assisting with a secure boot process at a host device of a computing system according to one or more embodiments of the present disclosure is shown. Figure 2 In the illustrated embodiment, a program configured to verify the security of the MCU application 234 is stored by the security device 210 and provided to the MCU 230 .

[0046] In one or more embodiments, the MCU 230 includes a native boot code 236 stored in a program memory 232. In one or more embodiments, the native boot code 236 may not be configured to verify that the MCU application 234 is secure or may not be trusted to verify that the MCU application 234 is secure. The security device 210 has a low-level boot code 218 boot code stored in a permanent memory 216 and provides a copy 220 of the low-level boot code 218 (i.e., an image of the low-level boot code 218) to the MCU 230. In one or more embodiments, the low-level boot code 218 may be a program that, when executed by a processor (such as a CPU 248), is configured to verify that the firmware is secure, including verifying that the MCU application 234 is secure. Characterized in another way, the low-level boot code 218 may be configured to perform at least some operations of the secure boot process, and in this example, the native boot code 236 is not configured to perform or the native boot code 236 is not trusted to perform operations. As examples, the low-level boot code 218 may be configured to verify that the native boot code 236 is secure, verify that the MCU application 234 is secure, or verify that both the native boot code 236 and the MCU application 234 are secure.

[0047] In one or more embodiments, the low-level boot code 218 may be configured to enable the processor to perform operations for verifying the security of the firmware, and include data associated with performing these operations, including but not limited to one or more of digests, hash functions, and public and / or private encryption keys.

[0048] In one or more embodiments, the trusted sequence circuit 214 can generally be configured to initiate a restricted operating mode (e.g., a reset mode, but not limited thereto) at the MCU 230, send a copy 220 of the low-level boot code 218 to the MCU 230, and initiate execution of the copy 220 of the low-level boot code 218 at the MCU 230. In one embodiment, the trusted sequence circuit 214 can be configured to instruct the CPU 248 to initiate execution of the copy 220 of the low-level boot code 218 upon entering a known state, and then deassert the reset 244, thereby placing the MCU 230 in such a known state, for example, a normal operating mode such as a normal boot or reset. When the MCU 230 enters the reset-initiated (i.e., by deasserting the reset 244) known state, the copy 220 of the low-level boot code 218 attempts to authenticate the MCU application 234 and / or the native boot code 236 without any further assistance from the secure device 210.

[0049] In another embodiment, the trusted sequence circuit 214 can be configured to receive and process a verification result 246 received from the copy 220 of the low-level boot code 218 executing at the MCU 230 and transmitted to the trusted sequence circuit 214 by the debug function circuit 242 as a message 222. The trusted sequence circuit 214 can be configured to control the exit of the activated restricted operating mode at the MCU 230 in response to the verification result 246. In one or more embodiments, the verification result 246 can generally indicate the success or failure of the verification of the firmware. In one or more embodiments, the verification result 246 can indicate whether the native boot code 236 and / or the MCU application 234 are verified to be secure.

[0050] In some embodiments, if verification fails, verification result 246 may include some indication of why verification failed, such as an error code.

[0051] In one or more embodiments, the trusted sequence circuit 214 may be, for example, Figure 1The I / O port 118 and the I / O port 132 of the MCU 230 are operatively coupled to a reset 244 and debug functionality circuitry 242 of the MCU 230. The reset 244 may be a peripheral device of the MCU 230 such that when a hardware input is asserted to the reset 244, the reset 244 is configured to trigger a hardware condition at the MCU 230, thereby causing the MCU 230 to enter a restricted mode, such as the reset mode described in the present disclosure. When the MCU 230 is in the restricted mode, the CPU 248 may not be able to perform one or more of the following operations: independently initiate execution of local software, receive or send data through certain input and output ports, or respond to signals received at certain input ports. However, the debug functionality circuitry 242 may be used by the trusted sequence circuitry 214 to instruct the CPU 248 to execute software.

[0052] When the MCU 230 is in restricted mode, the trusted sequence circuit 214 can access the SRAM 238, more specifically the code space 240, via the debug function circuit 242. In addition, the trusted sequence circuit 214 can use the debug function circuit 242 to move the copy 220 of the low-level boot code 218 to the code space 240, can instruct the CPU 248 to execute the code stored in the code space 240 (i.e., the copy 220 of the low-level boot code 218), and receive a verification result 246.

[0053] In one or more embodiments, the trusted sequence circuit 214 can be configured to use the debug function circuit 242 to instruct the CPU 248 to execute the native boot code 236 to perform some system initialization functions. More specifically, the trusted sequence circuit 214 can instruct the CPU 248 to execute a limited number of functions of the native boot code 236 related to system initialization. In one embodiment, after all functions (if any) executed by software on the MCU 230 (e.g., by the native boot code 236, but not limited thereto) are completed so that the integrity of the copy 220 of the low-level boot code 218 is not compromised, the trusted sequence circuit 214 can transfer the copy 220 of the low-level boot code 218 to the MCU 230.

[0054] In one or more embodiments, the trusted sequence circuit 214 may be configured to use the debug function circuit 242 to instruct the CPU 248 to execute code at an address space corresponding to the code space 240 (i.e., execute the copy 220 of the low-level boot code 218) in order to run the copy 220 of the low-level boot code 218 and verify the MCU application 234.

[0055] In one or more embodiments, the debug functionality circuitry 242 may be a hardware and / or software CPU interface and / or control unit for communicating with and controlling the CPU 248, for example, in accordance with the Joint Test Action Group (JTAG) standard, or a dedicated hardware / software CPU interface and / or control unit for implementing such operations. Although various embodiments of the present disclosure may illustrate and describe the debug functionality circuitry as being "on-chip," the present disclosure is not limited to on-chip implementations. For example, one of ordinary skill in the art will appreciate that internal circuitry techniques for off-chip CPU emulation may also be used and the disclosed embodiments are applicable thereto.

[0056] exist Figure 2 In the illustrated exemplary system 200, the security device 210 includes a cryptographic unit 212 for encrypting and decrypting messages 222 between the security device 210 and the MCU 230. Encryption and decryption of messages 222 between the security device 210 and the MCU 230 are not necessarily required, and therefore, in some embodiments of the exemplary system 200, it is specifically contemplated that the cryptographic unit 212 may be omitted.

[0057] Figure 3 A process 300 for secure boot assistance according to one or more embodiments of the present disclosure is shown, wherein a security device 302 provides low-level boot code to a host device represented by an MCU 304, the low-level boot code being configured to verify whether the firmware of the MCU 304 host device is secure. Figure 3 In the envisaged example, the MCU application has already been received at the MCU 304 and loaded into the program memory, so although no reference is made to the Figure 3 Steps for connecting to a source and downloading an MCU application are described, but incorporation of such steps into the disclosed embodiments is specifically contemplated.

[0058] In operation 310, the security device 302 asserts and maintains reset at the MCU 304. In operation 312, the MCU 304 enters reset mode in response to the security device 302 asserting reset, and while reset is asserted, in operation 312, the MCU 304 is maintained in reset mode and prevented from running any software on its own. In optional operation 314, the debug functionality of the MCU 304 (e.g., debug functionality circuitry 242, but not limited thereto) is authenticated, for example, using a digital signature generated using public key cryptography. In one or more embodiments, authenticating the debug functionality can be used to confirm that the debug functionality has not been modified or that the security device 302 has not been coupled to an unauthorized MCU. In embodiments where the debug functionality is primarily hardware and / or software stored in non-volatile memory and the security device 302 is not separable from the MCU 304, the step of authenticating the debug functionality can be omitted.

[0059] In operation 316, the low-level boot code is retrieved from the permanent memory of the security device 302. In operation 318, the retrieved low-level boot code (or a copy thereof) is sent to the MCU 304 using the debug function of the MCU 304. In operation 320, the MCU 304 receives the sent low-level boot code and stores the low-level boot code in SRAM. In operation 322, the security device 302 uses the debug function of the MCU 304 to instruct the MCU 304 to execute the low-level boot code stored in the SRAM. In operation 324, the low-level boot code performs an attempted verification of at least a portion of the MCU application 234, and in operation 326, the verification result is sent to the security device 302 via the debug function of the MCU 304. In operation 328, the security device 302 receives the verification result via the debug function of the MCU 304. If the verification fails, then in operation 330, the security device 302 continues to assert reset until it detects that the trusted code has been installed at the MCU 304. In one embodiment, the security device 302 may repeatedly restart the MCU 304 until the low-level boot code detects that the MCU application is secure (e.g., the low-level boot code sends a verification result indicating that the operating code is secure to the security device 302). If the verification is successful, then in operation 332, the security device 302 stops asserting reset, and in operation 334, the MCU 304 enters a known operating state, whereby it can execute the at least partially verified MCU application of operation 324.

[0060] In one or more embodiments, the low-level boot code from the secure device can be configured to attempt to verify the MCU application, the native boot code, or both. In embodiments where the low-level boot code attempts to verify that the native boot code is secure, if the native boot code is verified, the verified native boot code can be executed to verify that other firmware is secure, including the MCU application.

[0061] Depending on the implementation, the new MCU application may overwrite the native boot code at the MCU or not (i.e., the native boot code may remain). In either case, in one or more embodiments, when the low-level boot code loaded from the trusted device attempts to verify that the MCU application code is safe, it may be configured to verify both the MCU application code and the native boot code together or separately. For example, the low-level boot code 218 may use the MCU application 234 and the native boot code 236 ( Figure 2 ) to create a digital signature for verification security.

[0062] One or more embodiments generally relate to systems and methods for secure boot assistance, in which a native program generates security data for firmware, and circuitry at a secure device compares the security data with trusted security data stored at the secure device to determine whether the firmware is secure and trusted.

[0063] Figure 4 A simplified block diagram of an exemplary system 400 for assisting with a secure boot process at a host device (here implemented as an MCU 430) of a computing system according to one or more embodiments of the present disclosure is shown. Figure 4 In the illustrated embodiment, the MCU 430 includes a native boot code 438 stored at the program memory 432, and the native boot code 438 is configured to generate security data based at least in part on the MCU application 434. The security data may include, for example, a digital signature generated using public / private key cryptography, a digest generated using a hash function, and a MAC code. Figure 4 In the illustrated embodiment, the native boot code 438 is not configured or trusted to confirm the validity of security data and / or make the final decision on the security of the MCU application 434. More specifically, in one or more embodiments, the native boot code 438 does not have or cannot access the trusted digest 420 stored at the persistent memory 418 of the secure device 410. Figure 4 In the example shown, the native boot code 438 is configured to obtain a digest 446 from the MCU application 434, generate a signature 448 from the MCU application signature 436, and send the digest 446 and signature 448 as the sent message 422 to the trusted sequence circuit 416 via the debug function circuit 442, but it does not verify that the digest 446 or the signature 448 are secure.

[0064] In alternative embodiments, the trusted sequence circuitry 416 may be configured to read the digest 446 and signature 448 from a location in the program memory 432 or another memory where they are stored in the native boot code 438 via the debug functionality circuitry 442. In other words, in some embodiments, it is contemplated that the native boot code 438 may be configured to send the digest 446 and / or signature 448 to the secure device 410, and in some embodiments, it is contemplated that the trusted sequence circuitry 416 may be configured to use the debug functionality circuitry 442 to retrieve the digest 446 and / or signature 448 from the MCU 430. For example, the trusted sequence circuitry 416 may use the debug functionality circuitry 442 to insert a breakpoint into the native boot code 438, stop execution of the native boot code 438 once the digest 446 and / or signature 448 are calculated, and retrieve the calculated values.

[0065] In one or more embodiments, the trusted sequence circuit 416 can be configured to assert a reset 444 of the MCU 430 via a reset signal 424 (the reset 444 is configured to cause the MCU 430 to be placed in a restricted operating mode), and use the debug functionality circuit 442 to instruct the CPU 440 to execute the native boot code 438 and receive (or retrieve) the digest 446 and the signature 448. In one or more embodiments, the trusted sequence circuit 416 can generally be configured to use one or more of the digest 446 and the signature 448 to verify that the MCU application 434 is secure. More specifically, the trusted sequence circuit 416 can be configured to use the signature 448 in conjunction with the cryptographic unit 414 to authenticate the source of the MCU application 434, and use the trusted digest 420 to confirm the integrity of the MCU application 434.

[0066] In one or more embodiments, cryptographic unit 414 may generally be configured to verify signature 448 using public key and / or private key cryptographic techniques. Figure 4 In the exemplary system 400 shown, the security device 410 includes a public key 412, and the cryptographic unit 414 uses the public key 412 to decode the signature 448. The trusted sequence circuit 416 can verify the identity of the source of the MCU application 434 in response to the decoded signature 448 and confirm that the MCU application 434 is associated with an authorized party. The trusted sequence circuit 416 can confirm that the digest 446 matches one of the trusted digests 420 and, in response, confirm the integrity of the MCU application 434.

[0067] Figure 5 A process 500 for secure boot assistance is shown in which a security device 502 performs verification of a digest generated by boot code implemented at an MCU 504 of a host device, in accordance with one or more embodiments of the present disclosure.

[0068] exist Figure 5 In the example contemplated in the foregoing, a new MCU application has been received at the MCU 504 and loaded into the program memory, so although the steps for connecting to the host and downloading the MCU application are not described in detail, implementations including such steps are specifically contemplated.

[0069] In operation 510, the security device 502 asserts and holds a reset at the MCU 504. In operation 512, the MCU 504 enters a reset mode in response to the security device 502 asserting the reset, and while the reset is asserted, the MCU 504 is held in the reset mode and prevented from running any software on its own. In optional operation 514, the debug function of the MCU 504 (e.g., debug function circuit 442), for example, using a digital signature generated using public key cryptography, but not limited thereto, is authenticated. Figure 3 ), in some embodiments, the authentication debug function can be omitted. In operation 516, the security device 502 uses the debug function to instruct the MCU 504 to execute the boot code stored at the MCU 504. In operation 518, the boot code generates a digest and a signature from the MCU application stored at the MCU 504. In one or more embodiments, the signature can be an MCU signature included with the MCU application or created by the boot code. In operation 520, the MCU 504 uses the debug function to send the signature and digest to the security device 502.

[0070] In operation 522, security device 502 receives signature and digest via the debug function of MCU. In operation 524, security device 502 attempts to authenticate the signature received. In operation 526, security device 502 attempts to verify the digest received. In one embodiment, security device 502 uses the trusted digest of local storage (that is, stored in the permanent memory of security device 502) to verify this digest. In one embodiment, security device 502 only attempts to verify this digest after successfully authenticating this signature. If this signature is not real or this digest is not verified, then in operation 528, security device 502 asserts reset until it detects that trusted code has been installed at MCU 504. If this signature is real and this digest is verified, then in operation 530, security device 502 stops asserting reset, and in operation 532, MCU 504 enters known operating state, so that it can execute the new MCU application program that has now been verified.

[0071] Figure 6 A simplified block diagram of an exemplary system 600 for assisting with a secure boot process at a host device (here implemented as an MCU 630) of a computing system according to one or more embodiments of the present disclosure is shown. Figure 6In the illustrated embodiment, native boot code 636 stored in program memory 632 at MCU 630 is configured to verify that MCU application 634 is secure, but because native boot code 636 may be compromised in some way, security device 610 is configured to use trusted boot code 618 stored in persistent memory 616 of security device 610 to verify that native boot code 636 is secure. In one or more embodiments, trusted sequence circuit 614 is configured to assert reset signal 622 to reset 642, and reset 642 is configured to respond by placing MCU 630 in a restricted operating mode and using debug functionality circuit 640 (e.g., using send and receive messages 620) to retrieve a copy 644 of native boot code 636. Trusted sequence circuit 614 is configured to determine whether the retrieved copy 644 of boot code 636 matches trusted boot code 618. If the retrieved copy 644 of the native boot code 636 matches the trusted boot code 618, then the boot code 636 is successfully authenticated and the trusted sequence circuitry 614 determines that the boot code 636 is secure.

[0072] exist Figure 6 In the illustrated exemplary system 600, trusted boot code 618 is stored in persistent memory 616 of secure device 610, but other security information may be used to authenticate native boot code 636 in addition to or in lieu of trusted boot code 618. In one embodiment, trusted security data, such as a trusted digital signature, a trusted digest, or a trusted MAC code, may be stored at persistent memory 616.

[0073] As described in this disclosure, in some cases, there may be a risk that debug functionality circuitry, such as debug functionality circuitry 640, may be compromised. If compromised, debug functionality circuitry 640 may modify copy 644 of native boot code 636 before sending it to secure device 610 in order to mask differences between native boot code 636 and trusted boot code 618. Therefore, in one or more embodiments, trusted sequence circuitry 614, in conjunction with cryptographic unit 612, may attempt to authenticate debug functionality circuitry 640, for example, using various public and / or private key cryptographic techniques, and only attempt to verify native boot code 636 in response to successful authentication of debug functionality circuitry 640. By way of example, trusted sequence circuitry 614 may request and receive (e.g., using message 620, but not limited thereto) a signature from debug functionality circuitry 640 and authenticate the received signature using a public key.

[0074] Upon successful verification of the native boot code 636, the trusted sequence circuit 614 can be configured to use the debug function circuit 640 to instruct the CPU 638 to execute the boot code 636 upon exiting the restricted mode and then stop asserting the power-on reset signal 622 at reset 642. The CPU 638 executes the native boot code 636 when the reset signal 622 to reset 642 is deasserted, and the native boot code 636 attempts to verify that the MCU application 634 is secure.

[0075] Figure 7 A process 700 for secure boot assistance is shown in which a security device 702 performs verification of boot code of a host device (implemented as an MCU 704 ) in accordance with one or more embodiments of the present disclosure.

[0076] In the contemplated example, a new MCU application has already been received at the MCU 704 and loaded into program memory, so while the steps for connecting to the source of new firmware and downloading the MCU application are not described in detail, they are specifically contemplated.

[0077] In operation 710, the security device 702 asserts and holds the reset at the MCU 704. In operation 712, the MCU 704 enters a reset mode in response to the security device 702 asserting the reset, and while the reset is asserted, the MCU 704 is held in the reset mode and is prevented from running any software on its own. In optional operation 714, the debug function of the MCU 704 is authenticated, for example, using a digital signature generated using public key cryptography. Figure 3 ) and process 500( Figure 5), in some embodiments, the authentication debug function may be omitted. In operation 716, the security device 702 uses the debug function to instruct the MCU 704 to send a copy of the boot code core stored at the MCU 704 to the security device 702. In operation 718, the MCU 704 reads the native boot code and sends the copy of the native boot code to the security device 702 via the debug function in operation 720. In operation 722, the security device 702 receives the copy of the boot code via the debug function and attempts to verify the native boot code of the MCU 704 in response to the copy of the native boot code and the trusted boot code stored locally at the security device 702. In one or more embodiments, the copy of the boot code and the trusted boot code can be compared using any suitable technique, including but not limited to a bit-by-bit comparison or using a hash. If the boot code is not successfully verified, then in operation 724, the security device 702 continues to hold the MCU 704 in reset until it detects that the trusted boot code has been installed at the MCU 704. If the MCU's native boot code is successfully verified in operation 722, then in operation 726, the security device 702 instructs the MCU 704 to execute the native boot code upon exiting reset mode and deasserts reset at the MCU 704. In operation 728, the boot code executes at the MCU 704 upon exiting reset mode and attempts to verify that the MCU application is secure.

[0078] In one or more embodiments, the computing system may be configured to operate in response to a plurality of operating modes. A first mode may correspond to a reference to Figure 2 and Figure 3 The second mode may correspond to the embodiment described with reference to Figure 4 and Figure 5 The embodiment described, and the third mode may correspond to reference Figure 6 and Figure 7 In other words, the secure boot assistance system may be configured to perform secure boot assistance using low-level boot code provided from a secure device according to a first operating mode, perform secure boot assistance using a trusted digest generated by native boot code according to a second operating mode, and perform secure boot assistance using verified native boot code according to a third operating mode.

[0079] Such a system can be configured to operate according to a first operating mode, a second operating mode, or a third operating mode in response to a detected mode setting. In some embodiments, the mode of the system can be based at least in part on the context, and more specifically on the potential damage caused by the security breach given the particular context. In other words, more restricted operating modes can be used in high-risk contexts, and less restricted operating modes can be used in low-risk contexts.

[0080] As an example, a boot assist circuit used in a medical device or autonomous vehicle controller may be configured to perform secure boot assistance using a trusted digest if the firmware is being upgraded at an authorized service location or using authorized service equipment at a machine shop or a medical provider's office. Such a boot assist circuit may be configured to perform secure boot assistance using low-level boot code and require authentication of the debug functionality circuitry if the firmware is being upgraded at a location other than an authorized service location or using unauthorized service equipment (e.g., using an unsecured personal computer).

[0081] One or more embodiments of the present disclosure are directed to a contemplated "secure" implementation in which a computing system (such as Figure 1 The computing system 100 includes a secure device stacked on a host device, for example, using a module or system-in-package (SiP) arrangement. When stacked, the trusted device and the host device can be arranged relative to each other such that a software debug pin and / or a hardware reset pin of the host device are hidden, i.e., accessible by the secure device but not accessible from outside the module.

[0082] Those skilled in the art will recognize the many advantages and benefits of the various embodiments described in this disclosure. For example, one or more of the advantages and benefits may include: strong isolation between the boot code and application code of the MCU; no software attack methods other than those inherently available in the boot ROM itself; accelerated availability of module / SiP solutions across a wide range of MCU capabilities without requiring new mask sets and associated development time; leveraging existing secure boot capabilities to enhance the secure boot capabilities of the MCU without requiring new mask sets and associated development time; and adding the ability to verify asymmetric signatures promptly and correctly at an MCU that already has a boot ROM.

[0083] Any characterization of something in this disclosure as "typical," "conventional," or "known" does not necessarily mean that it is disclosed in the prior art or understood in the prior art for the aspect in question. It also does not necessarily mean that it is well-known, readily understood, or conventionally used in the relevant art.

[0084] Although the present invention is described herein with respect to certain illustrated embodiments, those skilled in the art will recognize and understand that the present invention is not so limited. Rather, many additions, deletions, and modifications may be made to the illustrated embodiments and the described embodiments without departing from the scope of the invention as claimed below and its legal equivalents. Furthermore, features from one embodiment may be combined with features from another embodiment while still being included within the scope of the invention as contemplated by the inventors.

[0085] Additional non-limiting embodiments of the present disclosure include:

[0086] Embodiment 1: A method of assisting a device in performing a secure boot process, the method comprising: placing and maintaining the device in a restricted operating mode; sending a program to the device using an interface for controlling a central processing unit (CPU) of the device; initiating execution of the program at the device using the interface for controlling the CPU; and attempting to verify the security of firmware stored at the device in response to the initiated execution of the program.

[0087] Embodiment 2: The method of embodiment 1, wherein sending the program to the device comprises sending low-level boot code to the device.

[0088] Embodiment 3: The method of embodiments 1 and 2, wherein placing and maintaining the device in the restricted operating mode comprises disabling independent booting of execution of code at the device in response to detecting that new firmware has been received at the device.

[0089] Embodiment 4: The method of embodiments 1 to 3, wherein attempting to verify the security of the firmware stored at the device in response to the initiated execution of the program comprises: performing a hash function on an operation code stored at a program memory of the device to obtain secure data; comparing the obtained secure data with trusted secure data; and attempting to verify that the operation code is secure in response to the comparison of the obtained secure data with the trusted secure data.

[0090] Embodiment 5: The method of embodiments 1 to 4, further comprising verifying that the operation code is secure in response to detecting that the obtained security data matches the trusted security data.

[0091] Embodiment 6: The method of embodiments 1 to 5, further comprising determining that the operation code is unsecure in response to detecting that the obtained security data does not match the trusted security data.

[0092] Embodiment 7: The method of embodiments 1 to 6, further comprising maintaining the device in the restricted operating mode until the program detects that a secure operating code is installed at the device.

[0093] Embodiment 8: The method of embodiments 1 to 7, further comprising restarting the device until the program detects that the secure operating code is installed at the device.

[0094] Embodiment 9: The method of embodiments 1 to 8, wherein using the interface for controlling the CPU to initiate execution of the program at the device comprises: instructing the device to execute the program when the device exits the restricted operating mode; and releasing the device from the restricted operating mode.

[0095] Embodiment 10: The method according to Embodiments 1 to 9, further comprising: receiving a first verification result in response to verifying that the firmware is secure; and receiving a second verification result in response to determining that the firmware is unsecure.

[0096] Embodiment 11: The method according to embodiments 1 to 10 further includes, in response to receiving the first verification result: instructing the device to execute the firmware when exiting the restricted operating mode; and releasing the device from the restricted operating mode.

[0097] Embodiment 12: The method according to embodiments 1 to 11 further comprising, in response to receiving the second verification result: maintaining the device in the restricted operating mode until it is detected that the security of the firmware stored at the device is verified.

[0098] Embodiment 13: A secure boot assistance system, which includes: a first device, the first device including: a program memory, the program memory being configured to store firmware of the first device; a processor; and an interface for accessing and controlling the processor; a second device operatively coupled to the first device, the second device including: a permanent memory having a program stored thereon, the program being configured to enable the processor to attempt to verify the security of the firmware stored at the program memory of the first device when executed by the processor of the first device; and a trusted sequence circuit, the trusted sequence circuit being configured to use the interface to send the program to the first device and to initiate execution of the program at the first device, and wherein the trusted sequence circuit is configured to keep the first device in a restricted operating mode while attempting to verify the security of the stored firmware of the first device.

[0099] Embodiment 14: The system of embodiment 13, wherein the trusted sequence circuit is configured to assert a signal at a hardware input of the first device in response to detecting that new firmware is stored at the first device, and further wherein the first device is configured to operate in the restricted operating mode while the hardware input is asserted.

[0100] Embodiment 15: The system of embodiments 13 and 14, wherein the trusted sequence circuit is configured to control the interface of the first device to prevent at least some functions of the first device.

[0101] Embodiment 16: The system of Embodiments 13 to 15, wherein the processor of the first device is configured to execute in response to the control signal provided by the interface in response to the first device being in the restricted operating mode.

[0102] Embodiment 17: A system according to embodiments 13 to 16, wherein the trusted sequence circuit of the second device is configured to: in response to storing the program at the first device: use the interface to instruct the first device to start execution of the program when exiting the restricted operating mode; and release the first device from the restricted operating mode.

[0103] Embodiment 18: The system of embodiments 13 to 17, wherein the firmware includes an operation code, and the program, when executed by the processor, is configured to enable the processor to: hash the operation code stored in the program memory of the first device to obtain a first digest; compare the first digest to a second digest; and attempt to verify that the operation code is secure in response to the comparison of the first digest and the second digest.

[0104] Embodiment 19: The system of embodiments 13 to 18, wherein the program, when executed by the processor, is configured to: determine that the operation code is secure in response to detecting that the first digest matches the second digest; and determine that the operation code is unsecure in response to detecting that the first digest does not match the second digest.

[0105] Embodiment 20: The system of embodiments 13 to 19, wherein the trusted sequence circuit of the second device is configured to, in response to installing the program at the second device, instruct the first device to initiate execution of the program using the interface.

[0106] Embodiment 21: The system of embodiments 13 to 20, wherein the program, when executed by the processor, is configured to: provide a first verification result in response to verifying that the operation code is secure; and provide a second verification result in response to determining that the operation code is unsecure.

[0107] Embodiment 22: A system according to embodiments 13 to 21, wherein the firmware includes an operation code, and the trusted sequence circuit of the second device is configured to, in response to receiving the first verification result: use the interface to instruct the first device to initiate execution of the operation code when exiting the restricted operating mode; and release the first device from the restricted operating mode.

[0108] Embodiment 23: The system of embodiments 13 to 22, wherein the trusted sequence circuit of the second device is configured to, in response to receiving the second verification result, maintain the first device in the restricted operating mode until secure firmware is detected to be installed at the first device.

[0109] Embodiment 24: The system of embodiments 13 to 23, wherein the firmware includes code for one or more of: an integrated embedded system, an operating system, an operating system loader, and separately installed applications.

[0110] Embodiment 25: A method for assisting a device in performing a secure boot process, the method comprising: placing and maintaining the device in a restricted operating mode; using an interface for controlling a central processing unit (CPU) of the device to copy code stored in a program memory of the device to another device; and attempting to verify that the copied code is secure.

[0111] Embodiment 26: The method of Embodiment 25, wherein placing and maintaining the device in the restricted operating mode comprises disabling independent initiation of execution of code at the device.

[0112] Embodiment 27: A method according to embodiments 25 and 26, wherein the attempting to verify that the copied code is secure includes: performing a hash function on the copied code to obtain first security data; and attempting to verify that the copied code is secure in response to the first security data.

[0113] Embodiment 28: A method according to embodiments 25 to 27, wherein the attempting to verify that the copied code is secure in response to the first security data includes: comparing the first security data with second security data stored at another device; and attempting to verify the copied code in response to the comparison.

[0114] Embodiment 29: The method of embodiments 25 to 28, wherein attempting to verify that the copied code is secure in response to the first security data includes attempting to verify the copied code by performing signature verification on the first security data.

[0115] Embodiment 30: A method according to embodiments 25 to 29, further comprising: verifying that the copied code is secure; instructing the device to execute code corresponding to the copied code upon exiting the restricted operating mode; and releasing the device from the restricted operating mode.

[0116] Embodiment 31: The method of embodiments 25 to 30, further comprising: in response, determining that the copied code is unsafe; and maintaining the device in the restricted operating mode until the code installed at the device is verified to be safe.

[0117] Embodiment 32: The method of Embodiments 25 to 31, wherein copying the code stored at the program memory of the device comprises copying boot code stored at the program memory of the device.

[0118] Embodiment 33: A method according to embodiments 25 to 32, wherein copying the code stored at the program memory of the device includes: copying a portion of the operation code stored at the program memory of the device, wherein the device is configured to execute the copied portion of the operation code when the device is booted or when the device is reset.

[0119] Embodiment 34: A secure boot assistance system, comprising: a first device, the first device comprising: a program memory configured to store code of the firmware of the first device; a processor; and an interface for accessing and controlling the processor; a second device operatively coupled to the first device, the second device comprising: a permanent memory on which security information for verifying the security of the code stored at the first device is stored; and a trusted sequence circuit, the trusted sequence circuit configured to use the debug function circuit to copy the code from the first device and to use the security information to attempt to verify that the copied code is secure, wherein the trusted sequence circuit is configured to keep the first device in a restricted operating mode while attempting to verify that the copied code is secure.

[0120] Embodiment 35: A system according to embodiment 34, wherein the trusted sequence circuit is configured to assert a hardware input of the first device in response to detecting that new firmware is installed at the first device, and further wherein the first device is configured to operate in the restricted operating mode while the hardware input is asserted.

[0121] Embodiment 36: The system of embodiments 34 and 35, wherein the trusted sequence circuit is configured to control the interface of the first device to prevent at least some functions of the first device.

[0122] Embodiment 37: The system of Embodiments 34 to 36, wherein the processor of the first device is configured to execute in response to the control signal provided by the interface in response to the first device being in the restricted operating mode.

[0123] Embodiment 38: A system according to embodiments 34 to 37, wherein the security information includes trusted security data, and the trusted sequence circuit is configured to: perform a hash function on the copied code to obtain first security data; and attempt to verify that the copied code is secure in response to the obtained security data and the trusted security data.

[0124] Embodiment 39: A system according to embodiments 34 to 38, wherein the security information includes trusted code, and the trusted sequence circuit of the second device is configured to: perform a hash function on the copied code to obtain first security data; perform the hash function on the trusted code to obtain second security data; compare the first security data with the second security data; and attempt to verify that the copied code is secure in response to comparing the first security data with the second security data.

[0125] Embodiment 40: A system according to embodiments 34 to 39, wherein the trusted sequence circuit of the second device is configured to, in response to verifying that the copied code is secure: use the interface to instruct the first device to execute code corresponding to the copied code when exiting the restricted operating mode; and release the first device from the restricted operating mode.

[0126] Embodiment 41: The system of embodiments 34 to 40, wherein the trusted sequence circuit of the second device is configured to, in response to determining that the copied code is unsecure, maintain the first device in the restricted operating mode until secure code is detected to be installed at the first device.

[0127] Embodiment 42: The system of embodiments 34 to 41, wherein the security information includes a trusted code, and the trusted sequence circuit of the second device is configured to compare the copied code with the trusted code and attempt to verify that the copied code is secure in response to the comparison.

[0128] Embodiment 43: A method for assisting a device in performing a secure boot process, the method comprising: placing and maintaining the device in a restricted operating mode; initiating execution of native boot code stored at the device using an interface of a central processing unit (CPU) for controlling the device; receiving security data using the interface of the CPU for controlling the device in response to initiating execution of the native boot code, wherein the received security data represents firmware of the device; and attempting to verify that the firmware of the device is secure in response to the received security data and trusted security data stored outside the device.

[0129] Embodiment 44: The method according to embodiment 43 further includes: performing a hash function on the code of the firmware of the device to obtain the security data; and sending the obtained security data to another device to verify that the firmware of the device is secure.

[0130] Embodiment 45: A method according to embodiments 43 and 44, further comprising: verifying that the firmware of the device is secure in response to detecting that the received security data matches the trusted security data; instructing the device to execute the native boot code upon exiting the restricted operating mode; and releasing the device from the restricted operating mode.

[0131] Embodiment 46: The method of embodiments 43 to 45, further comprising: determining that the firmware is unsecure in response to detecting that the received security data does not match the trusted security data; and maintaining the device in the restricted operating mode until secure firmware is detected to be installed at the device.

[0132] Embodiment 47: A secure boot assistance system, the secure boot assistance system comprising: a first device, the first device comprising: a program memory configured to store code of the first device; a processor; and an interface for accessing and controlling the processor; a second device operatively coupled to the first device, the second device comprising: a permanent memory on which trusted security data for verifying the security of the code stored at the first device is stored; and a trusted sequence circuit, the trusted sequence circuit configured to: use the interface to initiate execution of native boot code stored at the first device; use the interface for controlling the CPU of the device to receive security data in response to initiating execution of the native boot code, wherein the received security data represents firmware of the first device; and use the received security data and the trusted security data to attempt to verify that the firmware of the device is secure, wherein the trusted sequence circuit is configured to keep the first device in a restricted operating mode while attempting to verify that the firmware is secure.

[0133] Embodiment 48: A system according to embodiment 47, wherein the trusted sequence circuit is configured to assert a hardware input of the first device in response to detecting that new firmware is installed at the first device, and further wherein the first device is configured to operate in the restricted operating mode while the hardware input is asserted.

[0134] Embodiment 49: The system of embodiments 47 and 48, wherein the trusted sequence circuit is configured to control the interface of the first device to prevent at least some functions of the first device.

[0135] Embodiment 50: The system of embodiments 47 to 49, wherein the processor is configured to execute in response to the first device being in the restricted operating mode in response to a control signal provided by the interface.

[0136] Embodiment 51: A system according to embodiments 47 to 50, wherein the native boot code, when executed by the processor, is configured to: perform a hash function on the code of the firmware of the first device to obtain the security data; and send the obtained security data to the second device to verify that the firmware of the first device is secure.

[0137] Embodiment 52: A system according to embodiments 47 to 51, wherein the trusted sequence circuit is configured to, in response to verifying that the firmware of the first device is secure: instruct the first device to execute the operation code of the first device when exiting the restricted operating mode; and release the first device from the restricted operating mode.

[0138] Embodiment 53: The system of embodiments 47 to 52, wherein the trusted sequence circuit is configured to, in response to determining that the firmware of the first device is insecure, maintain the first device in the restricted operating mode until secure firmware is detected to be installed at the first device.

Claims

1. A method for assisting a device in performing a secure boot process, the method comprising: placing and maintaining a device in a restricted operating mode, wherein while in the restricted operating mode, independent initiation of execution of code by a central processing unit (CPU) of the device is disabled; sending a program to the device via an interface, wherein the interface is used to control the CPU of the device; initiating execution of the program at the device using the interface for controlling the CPU; as well as An attempt is made to verify the security of firmware stored at the device in response to the initiated execution of the program. 2 . The method of claim 1 , wherein the sending the program to the device comprises sending low-level boot code to the device. 3 . The method of claim 1 , wherein the placing and maintaining the device in the restricted operating mode comprises disabling independent booting of execution of code at the device in response to detecting that new firmware has been received at the device.

4. The method of claim 1 , wherein the attempting to verify the security of the firmware stored at the device in response to the initiated execution of the program comprises: performing a hash function on an operation code stored at a program memory of the device to obtain secure data; comparing the obtained safety data with credible safety data; as well as An attempt is made to verify that the operating code is secure responsive to the comparison of the obtained security data with the trusted security data. 5 . The method of claim 4 , further comprising verifying that the operating code is secure in response to detecting that the obtained security data matches the trusted security data. 6 . The method of claim 4 , further comprising determining that the operation code is unsecure in response to detecting that the obtained security data does not match the trusted security data.

7. The method of claim 6, further comprising maintaining the device in the restricted operating mode until the program detects that secure operating code is installed at the device.

8. The method of claim 6, further comprising restarting the device until the program detects that a secure operating code is installed at the device.

9. The method of claim 1 , wherein said initiating execution of said program at said device using said interface for controlling said CPU comprises: instructing the device to execute the program when the device exits the restricted operating mode; as well as The device is released from the restricted operating mode.

10. The method according to claim 1, further comprising: receiving a first verification result in response to verifying that the firmware is secure; as well as A second verification result is received in response to determining that the firmware is unsafe.

11. The method according to claim 10, further comprising, in response to receiving the first verification result: instructing the device to execute the firmware upon exiting the restricted operating mode; and The device is released from the restricted operating mode.

12. The method according to claim 10, further comprising, in response to receiving the second verification result: The device is maintained in the restricted operating mode until it is detected that the security of the firmware stored at the device is verified.

13. A safety boot assistance system, comprising: A first device, the first device comprising: a program memory configured to store firmware of the first device; processor; and an interface for accessing and controlling the processor; a second device operatively coupled to the first device, the second device comprising: a persistent memory having stored thereon a program that, when executed by the processor of the first device, is configured to enable the processor to attempt to verify the security of firmware stored at the program memory of the first device; and trusted sequence circuitry configured to use the interface to send the program to the first device and initiate execution of the program at the first device, and The trusted sequence circuit is configured to maintain the first device in a restricted operating mode while attempting to verify the security of the stored firmware of the first device, wherein while in the restricted operating mode, independent initiation of execution of code by a central processing unit (CPU) of the first device is disabled.

14. The system of claim 13, wherein the trusted sequence circuit is configured to assert a signal at a hardware input of the first device in response to detecting that new firmware is stored at the first device, and further wherein the first device is configured to operate in the restricted operating mode while the hardware input is asserted.

15. The system of claim 14, wherein the trusted sequence circuit is configured to control the interface of the first device to prevent at least some functions of the first device.

16. The system of claim 14, wherein the processor of the first device is configured to execute in response to a control signal provided by the interface in response to the first device being in the restricted operating mode.

17. The system of claim 13, wherein the trusted sequence circuitry of the second device is configured to, in response to storing the program at the first device: using the interface to instruct the first device to initiate execution of the program upon exiting the restricted operating mode; and The first device is released from the restricted operating mode.

18. The system of claim 17, wherein the firmware includes operating codes, and the program, when executed by the processor, is configured to enable the processor to: performing a hash operation on the operation code stored in the program memory of the first device to obtain a first digest; comparing the first summary to the second summary; as well as An attempt is made to verify that the operation code is secure responsive to a comparison of the first digest and the second digest.

19. The system of claim 18, wherein the program, when executed by the processor, is configured to: determining that the operation code is secure in response to detecting that the first digest matches the second digest; and The operation code is determined to be unsafe in response to detecting that the first digest does not match the second digest.

20. The system of claim 13, wherein the trusted sequence circuitry of the second device is configured to, in response to the program being installed at the second device, instruct the first device to initiate execution of the program using the interface.

21. The system of claim 20, wherein the program, when executed by the processor, is configured to: providing a first verification result in response to verifying that the operation code is secure; and A second verification result is provided in response to determining that the operation code is unsafe.

22. The system of claim 21 , wherein the firmware includes an operation code, and the trusted sequence circuit of the second device is configured to, in response to receiving the first verification result: using the interface to instruct the first device to initiate execution of the operation code upon exiting the restricted operating mode; and The first device is released from the restricted operating mode.

23. The system of claim 21, wherein the trusted sequence circuitry of the second device is configured to, in response to receiving the second verification result, maintain the first device in the restricted operating mode until secure firmware is detected to be installed at the first device.

24. The system of claim 13, wherein the firmware comprises code for one or more of: an integrated embedded system, an operating system, an operating system loader, and a separately installed application.

25. A method for assisting a device in performing a secure boot process, the method comprising: placing and maintaining a device in a restricted operating mode, wherein while in the restricted operating mode, independent initiation of execution of code by a central processing unit (CPU) of the device is disabled; copying code stored at a program memory of the device to another device using an interface, wherein the interface is used to control the CPU of the device; as well as Try to verify that the copied code is safe.

26. The method of claim 25, wherein the placing and maintaining the device in the restricted operating mode comprises disabling independent initiation of execution of code at the device.

27. The method of claim 25, wherein the attempting to verify that the copied code is safe comprises: performing a hash function on the copied code to obtain first security data; as well as An attempt is made to verify that the copied code is secure in response to the first security data.

28. The method of claim 27, wherein the attempting to verify that the copied code is secure in response to the first security data comprises: comparing the first security data with second security data stored at the other device; as well as An attempt is made to verify the copied code responsive to the comparison.

29. The method of claim 27, wherein the attempting to verify that the copied code is secure in response to the first security data comprises attempting to verify the copied code by performing signature verification on the first security data.

30. The method of claim 27, further comprising: Verify that the copied code is safe; instructing the device to execute code corresponding to the copied code upon exiting the restricted operating mode; as well as The device is released from the restricted operating mode.

31. The method of claim 27, further comprising: In response, determining that the copied code is unsafe; as well as The device is maintained in the restricted operating mode until the code installed at the device is verified to be secure.

32. The method of claim 25, wherein the copying of code stored at the program memory of the device comprises copying boot code stored at the program memory of the device.

33. The method of claim 25, wherein said copying code stored at said program memory of said device comprises: A portion of an operation code stored at the program memory of the device is copied, wherein the device is configured to execute the copied portion of the operation code upon boot-up of the device or upon a reset condition of the device.

Images