Safe boot at shutdown

Abstract

A secure boot system and method for reducing total boot time by performing a secure boot verification at shutdown and storing an authentication code in a secure manner, effectively pre-authenticating the application so that it can bypass authentication at the next boot.

Description

Technical Field

[0001] This disclosure relates to a method for secure boot, and more specifically to a method for secure boot when the computer is powered off. Background Technology

[0002] Secure boot is implemented in embedded devices to verify the integrity and authenticity of the firmware package during startup. If the firmware has been tampered with or contains errors, the controller can take corrective action. If the firmware is unreliable, the controller will typically prevent the boot of invalid software and may enter emergency recovery mode. In automotive applications, secure boot enables electronic control units (ECUs) to identify unauthorized or faulty firmware and prevent such software from compromising the safety and personal information of vehicle users.

[0003] Advances in automotive-grade microcontrollers have enabled hardware-based secure key storage and acceleration for certain cryptographic primitives. Secure key storage is a component or function of a Hardware Security Module (HSM), which also provides an interface to perform cryptographic operations, thus eliminating the need for access to the original key. The SHE module is an example of an HSM module. The SHE specification provides 128-bit AES encryption and CMAC capabilities but does not provide a dedicated secure coprocessor. In some hardware, a general-purpose processor is required to command the SHE module and make decisions based on the operation results. Without a dedicated coprocessor, a sequential secure boot process is needed. A write-protected boot loader acts as a trust anchor and is primarily responsible for verifying the next image in the boot chain.

[0004] One problem with standard sequential safe startup is that it delays the startup process by a fixed amount of time. This delay is based on the size of the image to be verified and the speed of the verification processing. These properties are typically fixed and based on the underlying hardware. In real-time systems, such as automotive ECUs, the system must start up quickly and establish communication with the vehicle network. Severe delays can cause the vehicle to miss important messages, leading to operational failures and the setting of diagnostic fault codes (DTCs). Furthermore, critical safety and regulatory functions may be delayed. For example, activating the display associated with the rearview camera.

[0005] The tolerable amount of boot latency depends on the design of the vehicle's network and architecture. However, most original equipment manufacturers (OEMs) require the ECU to begin receiving and responding to network messages within 100ms of a Wake-up event. Consider a microcontroller with 2MB of flash memory and an SHE module capable of executing AES-CMAC-128 at 8MB / s. Under this assumption, the latency required to perform a secure boot is approximately 250ms. In addition to the secure boot latency, additional latency for initializing the clock domain, peripherals, and operating system must be considered. Assuming this latency totals approximately 50ms, the combined boot latency is 300ms. Given the requirement to begin communication on the vehicle bus within 100ms, a standard sequential secure boot is clearly unsuitable.

[0006] A safe startup method that negatively impacts boot time is needed. Summary of the Invention

[0007] To reduce boot latency, a system and method for performing secure boot during shutdown has been developed. The system and method reduce overall boot time by performing secure boot verification during shutdown and securely storing authentication codes, effectively pre-authenticating applications so that authentication can be bypassed on the next boot. Specifically, according to the subject matter of the invention, secure boot processing is performed during shutdown, and the authentication codes are placed in a cache memory in a secure manner that makes them difficult to copy. Performing secure boot during shutdown caches the codes before they are needed at boot time. This improves boot time by reducing the amount of time spent during startup upon wake-up. Upon wake-up, the authentication code key is unlocked. The authentication code matches the expected code, thereby verifying that the bootloader can securely launch the application by bypassing application authentication and verification. Attached Figure Description

[0008] Figure 1 This is a block diagram of the code for an exemplary controller to launch the application; and

[0009] Figure 2 It is used for Figure 1 The flowchart shows the safe startup method for the controller.

[0010] For simplicity and clarity, the elements and steps shown in the figures are illustrated, and the elements and steps in the figures are not necessarily presented in any particular order. For example, steps that can be performed simultaneously or in different orders are shown in the figures to help improve the understanding of embodiments of this disclosure. Detailed Implementation

[0011] Although various aspects of this disclosure have been described with reference to one or more embodiments, this disclosure is not limited to such embodiments, and additional modifications, applications, and embodiments may be made without departing from this disclosure. In the accompanying drawings, similar reference numerals will be used to describe the same components. Those skilled in the art will recognize that changes may be made to the various components set forth herein without departing from the scope of this disclosure.

[0012] Any one or more devices described herein include computer-executable instructions that can be compiled or interpreted from computer programs created using various programming languages ​​and / or techniques. Typically, a processor (e.g., a microprocessor) receives and executes instructions, such as from memory, a computer-readable medium, etc. Processing units include non-transitory computer-readable storage media capable of executing the instructions of software programs. Computer-readable storage media can be, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. Any one or more devices described herein may rely on firmware, which may need to be updated from time to time to ensure compatibility with the operating system, improvements and additional features, security updates, etc. One or more devices may operate using a dedicated operating system, multiple software programs, and / or interface platforms, such as graphics, audio, wireless networking, application-enabled hardware, integrated hardware of vehicle components, systems, and external devices such as smartphones, tablets, and other systems, to name just a few.

[0013] Figure 1 This is a block diagram of an exemplary controller 100 or microcontroller (MCU) (e.g., an automotive microcontroller). Controller 100 has a processor 102 and memory including a non-volatile memory device 106 (ROM) and a volatile memory device 108 (RAM). Processor 102 is shown as a central processing unit (CPU). However, various variations are possible, such as, but not limited to, application processors (APs) and microprocessors. A hardware security module (HSM) 104, which may include a SHE, has a security key storage device 114 for one or more keys 120, which protect authentication codes for the MCU 100. A boot loader 116 is write-protected and is typically stored in ROM 106. The write-protected boot loader 116 will act as a trust anchor and is primarily responsible for verifying images in the boot chain used to launch one or more applications 118. Applications 118 are programs that are detached from the boot loader 116 and are expected to execute after the boot loader.

[0014] Typically, secure boot is performed at startup in a manner that is sequential or parallel to the executable software to be authenticated. The subject of this invention reduces overall startup time by performing secure boot verification at shutdown and securely storing the authentication code, effectively pre-authenticating the application. Therefore, authentication can be bypassed on the next startup. Specifically, according to the subject of this invention, secure boot processing is performed at shutdown, and the authentication code is stored in a cache memory in a secure manner that makes it difficult to copy. This improves boot time by reducing the amount of time spent during startup upon wake-up. This is particularly advantageous for HSM modules 104 (e.g., SHE modules) that do not have a dedicated coprocessor. Without a dedicated coprocessor, sequential secure boot is required, and standard sequential secure boot delays the startup process in a way that may adversely affect the operations performed by application 118.

[0015] During the application authentication process, the authentication code is set by the bootloader 116 and remains hidden from the application 118. To ensure that the authentication code cannot be copied by the application 118, the authentication code is unique to the MCU 100 and is either encrypted or derived from a secret key 120 accessible only to the bootloader 116. For devices with an SHE module, this can be achieved by establishing a unique random Advanced Encryption Standard (AES) key 120 for each device or controller. The AES key 120 is used to generate the authentication code. A boot mode setting with first and second settings, where the boot mode setting is a known message used as input, instructs the bootloader whether the application should be launched. In this example, the first boot mode setting is set by the application and provides the bootloader with an indication that the application needs to be pre-authenticated before powering off the controller. The second boot mode setting is set by the bootloader before powering off the controller and provides the bootloader with an indication that the application should be launched without having to perform the steps of authenticating the application when the controller wakes up. In this example, the first boot mode is set to BOOT_APP_AUTH, and the second boot mode is set to BOOT_APP.

[0016] When the controller wakes up and initiates startup, the bootloader 116 tests the validity of the authentication code by performing a password-based message authentication code (CMAC) verification operation. This operation compares the stored authentication code with the expected value. If successful, meaning the authentication code matches the expected value and the known message is set to the second boot mode setting BOOT_APP, the bootloader 116 clears the authentication code from memory and continues to start the application 118. If the authentication code is not present at startup, meaning CMAC verification has failed, the MCU will perform steps to authenticate the application and shut down, or optionally enter recovery mode.

[0017] When the authentication code is valid and the startup mode is set to the second setting, before transferring control to the application 118, the startup loader 116 invalidates the authentication code by clearing it from memory, making it impossible for the application 118 to read the authentication code. Furthermore, before transferring control to the application 118, the application 118 cannot access the authentication code key 120 by locking the key 120. To protect the key, a startup protection flag is set and applied to the key 120 in the security key storage device 114, which is part of the HSM 104. Once locked (disabled), the key 120 with the startup protection flag set cannot be re-enabled until the next startup cycle.

[0018] Upon power-off, application 118 sets the startup mode setting to the first setting, BOOT_APP_AUTH, before the controller enters a low-power state. The second startup mode setting, BOOT_APP_AUTH, provides the bootloader 116 with an instruction to verify and store the authentication code before powering off and entering a low-power state.

[0019] No unexpected code can be executed between the secure boot verification and wake-up event during power-off. To ensure that the contents of flash memory are not modified by external components while the system is in a low-power state, all external connections used for programming and debugging are password protected or disabled. Finally, exiting deep sleep mode is internally considered a reset, and any subsequent boot execution begins from the reset vector. The reset vector is fixed and cannot be modified.

[0020] Figure 2 This is a flowchart of a method 200 for secure booting upon power-off. Starting with the initial boot 201, which occurs when the controller is initially connected to the battery, the bootloader boots 210 by unlocking the authentication code key 212. During the initial boot, checks 214 are performed on the boot mode setting status and the validity of the authentication code. Because no application has been pre-authenticated, the authentication code is expected to be invalid 230. Application authentication 202 is then performed. After application authentication 202, an application validity check 203 is performed. If the application has been authenticated and is valid 204, the authentication code is set 206. The authentication code is protected by a key and stored in persistent memory. The boot mode is set to the second setting BOOT_APP, thus instructing the bootloader that it should launch the application on the next boot.

[0021] During initial startup, the bootloader is restarted (226), and upon startup (210), the authentication code key (212) is unlocked. Authentication and validity (214) are checked. The startup mode is set to the second setting, BOOT_APP, thus instructing the bootloader to launch the application. Simultaneously, the validity of the authentication code (214) is checked. This is done by comparing the authentication code with an expected value, and if they match, the authentication code is valid. In both cases—with the startup mode set to the second setting and the authentication code valid—the bootloader prepares to transfer control to the application. Before transferring control to the application for processing, the authentication code (208) is invalidated and the authentication code key (203) is locked. This protects the application from accessing the authentication code and authentication code key without prior authentication.

[0022] The application continues execution of process 218 at 220 until a shutdown is initiated at 222 at 219. At shutdown at 222, the application sets the boot mode setting at 224 to the first boot mode setting BOOT_AUTH_APP to instruct the bootloader that the application will be pre-authenticated before the MCU enters a low-power sleep state.

[0023] Before entering the low-power state, the application restarts 226 and launches the loader to unlock the authentication code key 212. At this point, when method 200 determines whether the boot mode is set to BOOT_APP 214 and whether the authentication code is valid 214, the answer will be incorrect 230, because the authentication code is invalid before control is passed to the application, and before restarting 226, the application sets the boot mode setting 224 to the first setting BOOT_AUTH_APP.

[0024] The startup loader performs the following steps: authenticating the application (202), setting a valid authentication code (206), and setting the startup mode to the second startup mode (BOOT_APP) to indicate that the application has been pre-authenticated before shutdown and is ready to start on the next boot. Finally, the MCU enters a low-power sleep state (236), where the application has been pre-authenticated and is ready to start.

[0025] On the next boot 210, the bootloader unlocks the authentication code key 212, determines 214 that the boot mode is set to the second setting and the authentication code is valid 216, therefore the bootloader invalidates the authentication code 208 and locks the authentication code key 203 before transferring control to the application. At this point, booting occurs without the authentication and verification steps, thus reducing boot time. Because the authentication code is invalidated 208 before transferring control to the application, the application cannot read the authentication code again if a secure boot is not performed before shutdown.

[0026] In the case of invalid or non-existent authentication code 232, the startup loader will return to performing full authentication and verification of the installed firmware 202, 204, 206, 228, or you can enter the optional recovery mode 234.

[0027] The boot mode setting (BOOT_APP or BOOT_APP_AUTH) is stored in permanent memory. The boot mode controls the boot process operation mode based on its value. When the boot loader sets the boot mode to the second boot mode setting BOOT_APP (228), authentication (202) has already been performed; therefore, authentication is not performed upon wake-up, saving valuable boot time. Upon power-off, the application program is responsible for setting the boot mode to the second boot mode setting BOOT_APP_AUTH (224). This second boot mode setting notifies the boot loader that authentication (202) and verifications (203, 204) are required before the MCU enters low-power or standby state (236).

[0028] In the foregoing description, this disclosure has been described with reference to specific exemplary embodiments. However, various modifications and changes may be made without departing from the scope of this disclosure as set forth in the claims. For example, the method may consist of one or more stages. The first stage is write-protected and must be certified for the next stage. This specification and drawings are illustrative and not restrictive, and modifications are intended to be included within the scope of this disclosure. Therefore, the scope of this disclosure should be determined by the claims and their legal equivalents, and not merely by the described examples.

[0029] For example, the steps described in any method or process claim can be performed in any order, and are not limited to the specific order presented in the claims. Furthermore, the components and / or elements described in any apparatus claim can be assembled in various arrangements or otherwise operably configured, and are therefore not limited to the specific configuration described in the claims.

[0030] The benefits, other advantages, and solutions to problems have been described above for specific embodiments; however, no benefit, advantage, solution to a problem, or any element that may make any particular benefit, advantage, or solution apparent or more apparent shall be construed as a critical, claimed, or necessary feature or component of any or all claims.

[0031] The terms “comprising,” “having,” or any other variations thereof are intended to refer to a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that comprises a list of elements includes not only those elements described but also other elements not expressly listed or inherent to such process, method, article, composition, or apparatus. Except where specifically described, other combinations and / or modifications of the aforementioned structures, arrangements, applications, proportions, elements, materials, or components used in the practice of this disclosure may be altered or otherwise specifically adapted to particular environments, manufacturing specifications, design parameters, or other operational requirements without departing from their general principles.

Claims

1. A secure boot method, the method comprising the following steps: Shut down the application that the controller is currently processing; The application sets the startup mode to the first setting when the device is powered off, instructing the startup loader that the startup loader should authenticate the application on the next startup. The startup loading program is restarted before the controller enters a low-power state. Authenticate the application; Set the authentication code; The authentication code is stored in permanent storage; At the startup loader, the startup mode is set to a second setting to instruct the startup loader that it should launch the application on the next startup. as well as Entering the low power state.

2. The method of claim 1, further comprising the following step: Upon waking from the low-power state, it is determined that the startup mode variable will be set to start the application. Unlock the authentication code key at the startup loader; Use the authentication code key to access the authentication code; Compare the authentication code with the expected value; When the authentication code matches the expected value and the launch mode is in the second setting, the authentication code associated with the application is invalidated, and the authentication code key is locked. as well as Control is transferred from the startup loader to the application.

3. The method of claim 2, further comprising the following step: When the authentication code does not match the expected value or the startup mode is in the first setting, repeat the following steps: Authenticate the application; Set the authentication code; The authentication code is stored in permanent storage; The startup mode variable is set at the startup loader to instruct the startup loader that it should launch the application on the next startup. as well as Entering the low power state.

4. The method of claim 2, further comprising the following step: When the authentication code does not match the expected value or the startup mode is in the second setting, enter recovery mode.

5. A secure boot system, comprising: Controller; A read-only memory device that stores a bootloader and at least one application, the application being authenticated using an authentication code encrypted with a randomized authentication code key unique to the controller; A hardware security module stores the randomized authentication key at the startup loader. A startup mode having: a first setting, the first setting being set by the at least one application at power-off, the first setting instructing the startup loader that the application will perform authentication at power-off; And a second setting, which is set by the startup loader before the controller enters a low-power state, the second setting instructing the startup loader to launch the application; and When the device is powered off, before entering the low-power state, the controller is configured to execute instructions in the bootloader to restart the at least one application, authenticate the at least one application, set a valid authentication code, and set the boot mode to the second setting.

6. The system of claim 5, wherein upon waking from the low-power state, the controller is configured to execute instructions in the bootloader to unlock the randomized authentication code key, use the randomized authentication code key to verify that the authentication code is valid, and invalidate the authentication code and lock the randomized authentication code key before passing control to the at least one application.

7. The system of claim 5, wherein upon waking from the low-power state, the controller is further configured to execute instructions in the bootloader to unlock the randomized authentication code key, use the randomized authentication code key to verify that the authentication code is invalid, and before transferring control to the at least one application, the controller executes instructions in the bootloader to authenticate the at least one application, set a valid authentication code, set the boot mode to the second setting, restart, unlock the randomized authentication code key, use the randomized authentication code key to verify that the authentication code is valid, invalidate the authentication code, and lock the randomized authentication code key before transferring control to the at least one application.

8. The system of claim 5, wherein upon waking from the low-power state, the controller is further configured to execute instructions in the bootloader to unlock the randomized authentication code key, use the randomized authentication code key to confirm that the authentication code is invalid, attempt to authenticate the application, and enter recovery mode if the application cannot be authenticated.

9. A secure boot method, the method comprising the following steps: At the application level, the startup mode is set to a first setting, which instructs the startup loader to authenticate the application before entering a low-power state; Restart the startup loader; Authenticate the application; Set the authentication code; At the startup loader, the startup mode is set to a second setting, which instructs the startup loader that the application should be launched upon wake-up. as well as Entering low power mode.

10. The method of claim 9, further comprising the step of: The authentication code is encrypted using a randomized authentication code key that is unique to the controller; Unlock the authentication code key upon wake-up; Use the authentication code key to verify that the authentication code is valid; Invalidate the authentication code; Lock the authentication code key; as well as After invalidating the authentication code and locking the authentication code key, control is transferred from the bootloader to the application.

11. The method of claim 10, wherein the step of invalidating the authentication code further comprises: Before control is transferred from the bootloader to the application, the authentication code is cleared from memory to prevent the application from accessing it.

12. The method of claim 9, further comprising the step of: The authentication code is encrypted using a randomized authentication code key that is unique to the controller; Unlock the authentication code key upon wake-up; The authentication code key is used to verify that the authentication code is invalid; Authenticate the application; Set the authentication code; as well as At the startup loader, the startup mode is set to a second setting, which instructs the startup loader that the application should be launched upon wake-up.

13. The method of claim 9, further comprising the step of: The authentication code is encrypted using a randomized authentication code key that is unique to the controller; Unlock the authentication code key upon wake-up; Use the authentication code key to verify that the authentication code is invalid; Attempt to authenticate the application; Enter recovery mode if the application cannot be authenticated; as well as At the startup loader, the startup mode is set to a second setting, which instructs the startup loader that the application should be launched upon wake-up.

Images