Secure Boot on Shutdown

Abstract

To provide a secure boot at shutdown.SOLUTION: A secure boot method comprises: shutting down an application being processed by a controller; setting, by the application at the shutdown, a boot mode to a first setting to indicate to a bootloader that, upon a next boot, the bootloader should authenticate the application; rebooting the bootloader prior to the controller entering a low power state; authenticating the application; setting an authentication code; storing the authentication code in persistent memory; setting, at the bootloader, the boot mode to a second setting to indicate to the bootloader that, upon the next boot, the bootloader should boot the application; and entering the low power state.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure is directed to a method for secure boot, and more particularly, to a method for secure boot at shutdown. [Background technology]

[0002] The secure boot feature in embedded devices is implemented to verify the integrity and authenticity of firmware packages during boot. If the firmware is erroneously tampered with or contains errors, the controller may apply corrective action. If the firmware is not authentic, the controller may generally abort booting the invalid software and enter an emergency recovery mode. For automotive applications, secure boot enables electronic control units (ECUs) to recognize unauthorized or defective firmware and prevent such software from compromising the safety and privacy of vehicle users.

[0003] Advances in automotive-grade microcontrollers provide hardware-based secure key storage and acceleration for certain cryptographic primitives. Secure key storage is a component or mechanism of a hardware security module (HSM) that also provides an interface for performing cryptographic operations where access to the raw key is not required. The SHE module is an example of an HSM module. The SHE specification provides 128-bit AES encryption and CMAC capabilities, but it does not provide a dedicated security coprocessor. Some hardware requires the use of a general-purpose processor to instruct the SHE module and make decisions based on the results of the operations. Without a dedicated coprocessor, a sequential secure boot process is required. A write-protected boot loader acts as a trust anchor and has primary responsibility for validating the next image in the boot chain.

[0004] The problem with standard sequential secure boot is that it delays the boot process for a certain amount of time. This delay is based on the size of the image to be activated and the activation speed, attributes that are often fixed and based on the underlying hardware. In real-time systems, such as automotive ECUs, the system must boot and establish communication with the vehicle network immediately. Significant delays can result in the loss of important messages from the vehicle, causing operational failures and setting of diagnostic trouble codes (DTCs). Additionally, activating important safety and regulatory functionality, such as a reversing camera and associated displays, can be delayed.

[0005] The amount of startup delay that can be tolerated depends on the design of the vehicle network and architecture. However, most original equipment manufacturers (OEMs) require that ECUs begin receiving and responding to network messages within 100 milliseconds of a network startup event. Consider a microcontroller with a flash module capable of executing AES-CMAC-128 at a rate of 8 megabytes per second and 2 megabytes of SHE memory. The amount of delay required to perform a secure boot for this hypothetical part is approximately 250 milliseconds. In addition to the secure boot delay, additional delays for initializing clock domains, peripherals, and the operating system must be considered. Assuming such delays combine to approximately 50 milliseconds, the combined boot delay is 300 milliseconds. Given the requirement to begin communicating on the vehicle bus within 100 milliseconds, it is clear that a standard sequential secure boot is not adequate.

[0006] There is a need for a secure boot that adversely affects the amount of startup time. Summary of the Invention [Means for solving the problem]

[0007] To reduce startup delays, systems and methods have been developed that perform secure boot at shutdown. The systems and methods reduce the overall time to boot by performing secure boot validation at shutdown and storing the authentication code in a secure manner, effectively pre-authenticating the application, so that authentication can be bypassed on the next boot. Specifically, in accordance with the inventive subject matter, the secure boot process is performed at shutdown, and the authentication code is placed in cache memory in a secure manner that prevents the authentication code from being easily duplicated. Performing secure boot at shutdown caches the authentication code before the code is needed at startup. This improves startup timing by reducing the amount of time that elapses during boot at startup. Upon wake, the authentication code key is unlocked. The authentication code matches an expected code, which verifies that the boot loader can bypass application authentication and validation to securely boot the application. For example, the present application provides the following: (Item 1) Shutting down the application handled by the controller; setting, by the application upon shutdown, a boot mode to a first setting that indicates to the boot loader that upon next boot, the boot loader should authenticate the application; rebooting the boot loader before the controller enters a low power state; Authenticating said application; and Set the authentication code, storing the authentication code in persistent memory; setting the boot mode in the boot loader to a second setting that indicates to the boot loader that upon the next boot, the boot loader should boot the application; entering said low power state; A secure boot method comprising the steps of: (Item 2) determining that upon waking from the low power state, the boot mode variable is set to boot the application; unlocking an authentication code key in said bootloader; accessing said authentication code using said authentication code key; comparing said authentication code with an expected value; when the authentication code matches the expected value and the boot mode is in the second setting, invalidating the authentication code associated with the application and locking the authentication code key; transferring control from said boot loader to said application; The method according to the preceding item, further comprising the steps of: (Item 3) When the authentication code does not match the expected value or the boot mode is in the first setting, Authenticating said application; and Set the authentication code, storing the authentication code in persistent memory; setting the boot mode variable in the boot loader to indicate to the boot loader that on the next boot, the boot loader should boot the application; entering said low power state; 3. The method of claim 1, further comprising the step of repeating the steps of (a) and (b). (Item 4) 10. The method of claim 1, further comprising the step of entering a recovery mode when the authentication code does not match the expected value or the boot mode is in the second setting. (Item 5) A controller; a read-only memory device storing a boot loader and at least one application to be authenticated using an authentication code encrypted using a randomized authentication code key unique to the device; a hardware security module in a boot loader that stores the randomized authentication code key; a boot mode having a first setting set by the at least one application upon shutdown that indicates to the boot loader that the application will be authenticated upon shutdown, and a second setting set by the boot loader before the controller enters a low power state that indicates to the boot loader that the application will be booted; and upon shutdown, prior to entering the low power state, the controller is configured to execute instructions of the boot loader to reboot 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. Secure Boot system. (Item 6) 10. The system of claim 9, wherein upon waking from the low power state, the controller executes instructions of the boot loader 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 transferring control to the at least one application. (Item 7) 10. The system of claim 9, wherein upon waking from the low power state, the controller is further configured to execute instructions of the boot loader to unlock the randomized authentication code key and use the randomized authentication code key to verify that the authentication code is invalid, and wherein before passing control to the at least one application, the controller executes instructions of the boot loader to authenticate the at least one application, set a valid authentication code, set the boot mode to the second setting, reboot, 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. (Item 8) 10. The system of claim 9, further configured to: upon waking from the low power state, the controller executes instructions of the boot loader to unlock the randomized authentication code key, use the randomized authentication code key to verify that the authentication code is invalid, attempt to authenticate the application, and enter a recovery mode if authentication of the application fails. (Item 9) setting a boot mode in an application to a first setting, the first setting indicating to a boot loader that the application will be authenticated before entering a low power state; Rebooting the boot loader, Authenticating said application; and Set the authentication code, setting the boot mode in the boot loader to a second setting, the second setting indicating to the boot loader that upon wake, the application should be booted; entering a low power state; A secure boot method comprising the steps of: (Item 10) encrypting said authentication code with an authentication code key that is randomized and unique to the device; When you wake it, you will unlock the authentication code key. verifying that the authentication code is valid using the authentication code key; Invalidating the authentication code, Locking the authentication code key; invalidating the authentication code and locking the authentication code key, and then transferring control from the boot loader to the application; The method according to the preceding item, further comprising the steps of: (Item 11) 10. The method of claim 9, wherein the step of disabling the authentication code further comprises erasing the authentication code from memory before transferring control from the boot loader to the application, thereby preventing the application from accessing the authentication code. (Item 12) encrypting said authentication code with an authentication code key that is randomized and unique to the device; When you wake it, you will unlock the authentication code key. verifying that the authentication code is invalid using the authentication code key; Authenticating said application; and Set the authentication code, setting the boot mode in the boot loader to a second setting, the second setting indicating to the boot loader that upon wake, the application should be booted; 3. The method according to any one of the preceding items, further comprising the step of: (Item 13) encrypting said authentication code with an authentication code key that is randomized and unique to the device; When you wake it, you will unlock the authentication code key. verifying that the authentication code is invalid using the authentication code key; attempting to authenticate said application; If you fail to authenticate the above applications, you will enter recovery mode and setting the boot mode in the boot loader to a second setting, the second setting indicating to the boot loader that upon wake, the application should be booted; 3. The method according to any one of the preceding items, further comprising the step of: (Summary) The secure boot system and method reduces the total time to boot by performing secure boot enablement at shutdown and storing authentication codes in a secure manner, effectively pre-authenticating applications so that authentication can be bypassed on the next boot. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a block diagram of an example controller for booting application code. [Figure 2] 2 is a flowchart of a secure boot method for the controller of FIG. 1. DETAILED DESCRIPTION OF THE INVENTION

[0009] Elements and steps in the figures are illustrated for simplicity and clarity and are not necessarily depicted according to any particular order, for example, steps that can be performed simultaneously or in different orders are shown in the figures to help improve understanding of embodiments of the present disclosure.

[0010] While various aspects of the present disclosure have been described with reference to one or more embodiments, the present disclosure is not limited to such embodiments, and additional modifications, applications, and embodiments may be implemented without departing from the present disclosure. In the drawings, like reference numerals are used to indicate like components. Those skilled in the art will recognize that the various components shown herein may be modified without departing from the scope of the present disclosure.

[0011] Any one or more of the devices described herein include computer-executable instructions, which may be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies. Generally, a processor (such as a microprocessor) receives and executes instructions, for example, from a memory or a computer-readable medium. The processing unit includes a non-transitory computer-readable storage medium capable of executing instructions of a software program. The computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. Any one or more of the devices herein may rely on firmware, which may require updates from time to time to ensure compatibility with operating systems, improvements and additional functionality, security updates, etc. One or more of the devices may operate using multiple software programs and / or platforms for interfacing with dedicated operating systems, graphics, audio, wireless networking, enabled applications, integrated hardware of vehicle components, systems, and external devices such as smartphones, tablets, and other systems, to name a few.

[0012] FIG. 1 is a block diagram of an exemplary controller 100 or microcontroller (MCU), e.g., an automotive microcontroller. The controller 100 includes a processor 102 and memory, including a non-volatile memory device 106 (ROM) and a volatile memory device 108 (RAM). The processor 102 is depicted as a central processing unit (CPU). However, variations are possible, such as, but not limited to, an application processor (AP) and a microprocessor. A hardware security module (HSM) 104, which may include an SHE, includes a secure key storage device 114 for one or more keys 120 that protect authentication code for the MCU 100. A boot loader 116 is write-protected and typically stored in the ROM 106. The write-protected boot loader 116 acts as a trust anchor and is primarily responsible for validating an image in the boot chain for booting one or more applications 118. The applications 118 are separate programs from the boot loader 116 that are intended to run after the boot loader.

[0013] Typically, secure boot is performed at boot time, either sequentially or in parallel with the running software to be authenticated. The inventive subject matter reduces the total boot time by performing secure boot enablement at shutdown and storing the authentication code in a secure manner. Effectively, applications are pre-authenticated. Therefore, authentication can be bypassed at the next boot. Specifically, in accordance with the inventive subject matter, the secure boot process is performed at shutdown, and the authentication code is stored in cache memory in a secure manner that prevents the authentication code from being easily duplicated. This improves start-up timing by reducing the amount of time that elapses during boot at startup. This is particularly advantageous for HSM modules 104 that do not have a dedicated coprocessor, such as an SHE module. Without a dedicated coprocessor, a sequential secure boot is required, and a standard sequential secure boot delays the boot process in a manner that adversely affects operations performed by applications 118.

[0014] During the process of authenticating an application, an authentication code is set by the boot loader 116 and remains hidden from the application 118. To ensure that the authentication code cannot be duplicated by the application 118, the authentication code is encrypted or derived from a secret key 120 that is unique to the MCU 100 and accessible only to the boot loader 116. For devices with an SHE module, this is possible by establishing a unique, randomized Advanced Encryption Standard (AES) key 120 per device or controller. The AES key 120 is used to generate the authentication code. Using a boot mode setting having a first setting and a second setting, the boot mode setting is a known message used as an input that indicates to the boot loader whether the application should be booted. In this embodiment, the first boot mode setting is set by the application and provides an indication to the boot loader that the application needs to be pre-authenticated before shutting down the controller. The second boot mode setting is set by the boot loader before shutting down the controller and provides an indication to the boot loader that the application will be booted when the controller wakes up without having to perform steps to authenticate the application. In this embodiment, the first boot mode setting is BOOT_APP_AUTH, and the second boot mode setting is BOOT_APP.

[0015] When the controller wakes and begins booting, the boot loader 116 checks the validity of the authentication code by performing a Cryptographic Message Authentication Code (CMAC) verification operation. This operation compares a stored authenticated code with an expected value. If successful, meaning the authentication code matches the expected value and a known message is set in the second boot mode setting, BOOT_APP, the boot loader 116 erases the authentication code from memory and proceeds to boot the application 118. If the authentication code is not present during boot, meaning the CMAC verification failed, the MCU performs the steps of authenticating the application, shutting down, or optionally entering recovery mode.

[0016] Before transferring control to application 118, when the authentication code is valid and the boot mode is set to the second setting, boot loader 116 disables the authentication code by erasing it from memory, so that application 118 cannot read it. Also, before transferring control to application 118, authentication code key 120 is made inaccessible to application 118 by locking key 120. To protect the key, a boot protection flag is set and applied to key 120 in secure key storage 114, which is part of HSM 104. Once locked (disabled), key 120 with the boot protection flag set cannot be re-enabled until the next boot cycle.

[0017] During shutdown, the application 118 sets the boot mode setting to a first setting, BOOT_APP_AUTH, before the controller enters a low power state. The second boot mode setting, BOOT_APP_AUTH, provides an indication to the boot loader 116 to activate and store an authentication code before shutting down and entering a low power state.

[0018] No unintended code can be executed between enabling Secure Boot at shutdown and a wake event. To ensure that the contents of flash memory are not modified by external means while the system is in a low-power state, all external connections for programming and debugging are password protected or disabled. Finally, exiting deep-sleep mode is treated internally as a reset, and any subsequent boots are performed from the reset vector, which is fixed and cannot be modified.

[0019] Figure 2 is a flowchart of a method 200 for secure boot at shutdown. Starting with an initial boot 201, which occurs when the controller is first connected to a battery, the boot loader boots 210 by unlocking the authentication code key 212. During the initial boot, a check is performed 214 on the status of the boot mode setting and the validity of the authentication code. Because there has been no prior authentication of the application, the authentication code is predicted to be invalid 230. Application authentication is performed 202. After the application is authenticated 202, an application validity check is performed 203. If the application is authenticated and 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 a second setting, BOOT_APP, which indicates to the boot loader that it should boot the application on the next boot.

[0020] During initial boot, the boot loader is rebooted 226, and at boot time 210, the authentication code key is unlocked 212. Authentication and validity are checked 214. The boot mode is set to a second setting, BOOT_APP, which indicates to the boot loader that an application should be booted. At the same time, the validity of the authentication code is checked 214. This is accomplished by comparing the authentication code with an expected value; if they match, the authentication code is valid. With both the boot mode set to the second setting and the authentication code valid, the boot loader prepares to hand control to the application. Before handing control to the application for processing, the authentication code is invalidated 208 and the authentication code key is locked 203. This protects against an application accessing the authentication code and authentication code key without first being authenticated.

[0021] The application continues 220 executing 218 until shutdown 219 is initiated 222. Upon shutdown 222, the application sets 224 the boot mode to a first boot mode setting, BOOT_AUTH_APP, which indicates to the boot loader that the application will be pre-authenticated before the MCU enters a low-power sleep state.

[0022] Before entering the low power state, the application reboots 226 and the boot loader unlocks 212 the authentication code key. At this time, when the method 200 determines 214 whether the boot mode is set to BOOT_APP and whether the authentication code is valid, the answer is both no 230 because the authentication code was invalidated before handing control to the application, and the application sets 224 the boot mode setting to the first setting, BOOT_AUTH_APP, before rebooting 226.

[0023] The boot loader goes through the steps of authenticating 202 the application, setting a valid authentication code 206, and setting the boot mode to a second boot mode setting, BOOT_APP, as an indicator that the application has been pre-authenticated and is ready to be booted on the next boot prior to shutdown. Finally, the MCU enters a low-power sleep state 236 with the application pre-authenticated and ready to boot.

[0024] During the next boot 210, the boot loader unlocks 212 the authentication code key, determines 214 that the boot mode is set to the second setting, and that the authentication code is valid 216, so the boot loader invalidates 208 the authentication code and locks 203 the authentication code key before handing control to the application. This time, the boot occurs without going through the authentication and validation steps, thereby reducing boot time. Because the authentication code was invalidated 208 before control was passed to the application, it is not possible for the application to read the authentication code at shutdown without first going through secure boot.

[0025] For example, when the authentication code is invalid or absent 232, the boot loader may fall back to performing a full authentication and validation 202, 204, 206, 228 of the installed firmware or enter an optional recovery mode 234.

[0026] The boot mode setting (BOOT_APP or BOOT_APP_AUTH) is stored in persistent memory. Depending on its value, the boot mode controls the boot flow operating mode. When the boot loader sets 228 the boot mode to the second boot mode setting, BOOT_APP, authentication 202 has already been performed and therefore will not be performed upon wake, saving valuable boot time. When the application shuts down, it is responsible for setting 224 the boot mode setting to the second boot mode setting, BOOT_APP_AUTH. The second boot mode setting for the boot mode informs the boot loader that authentication 202 and activation 203, 204 must occur before the MCU enters a low-power or standby state 236.

[0027] In the above specification, the present disclosure has been described with reference to certain exemplary embodiments. However, various modifications and changes may be made without departing from the scope of the present disclosure, as set forth in the claims. For example, the method may consist of one or more stages. A first state is write-protected, and a subsequent stage requires authentication. The specification and drawings are exemplary rather than limiting, and modifications are intended to be included within the scope of the present disclosure. Therefore, the scope of the present disclosure should be determined by the claims and their legal equivalents, rather than merely by the examples described.

[0028] For example, the steps recited in any method or process claim may be performed in any order and are not limited to the specific order presented in the claim. Additionally, the components and / or elements recited in any apparatus claim may be assembled or otherwise operatively configured in various permutations and therefore are not limited to the specific configuration recited in the claims.

[0029] Although benefits, other advantages, and solutions to problems have been described above with respect to particular embodiments, any benefit, advantage, solution to a problem, or any element that may give rise to or make more apparent any particular benefit, advantage, or solution, should not be construed as a critical, required, or essential feature or element of any or all claims.

[0030] The terms "comprise," "comprises," "comprising," "having," "including," "includes," or any variation thereof, are intended to refer to a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that includes a list of elements may include not only those elements described, but also other elements not expressly listed or that are specific to such process, method, article, composition, or apparatus. In addition to those not specifically listed, other combinations and / or modifications of the above-described structure, arrangement, application, proportions, elements, materials, or components used in the practice of the present disclosure may be changed without departing from its general principles or otherwise specifically adapted to particular environments, manufacturing specifications, design parameters, or other operating requirements.

Claims

1. A secure boot method for a system having a controller that processes an application, the method comprising: the controller shutting down the application processed by the controller; Upon shutdown, the application sets a boot mode to a first setting that indicates to the boot loader that the boot loader should authenticate the application upon next boot; the controller rebooting the boot loader before the controller enters a low power state; the controller authenticating the application; the controller setting an authentication code; the controller storing the authentication code in persistent memory; the controller setting, in the boot loader, the boot mode to a second setting that indicates to the boot loader that the boot loader should boot the application upon the next boot; the controller entering the low power state; Upon waking from the low power state, the controller determines that the boot mode variable is set to boot the application; the controller unlocking an authentication code key in the boot loader; the controller accessing the authentication code using the authentication code key; the controller comparing the authentication code with an expected value; when the authentication code matches the expected value and the boot mode is in the second setting, the controller invalidates the authentication code associated with the application and locks the authentication code key; the controller transferring control from the boot loader to the application; A secure boot method comprising the steps of:

2. When the authentication code does not match the expected value or the boot mode is in the first setting, the controller: authenticating the application; Set the authentication code, storing the authentication code in persistent memory; setting a boot mode variable in the boot loader that indicates to the boot loader that it should boot the application during the next boot; entering said low power state; The method of claim 1 , further comprising the step of repeating the steps of (a) and (b).

3. 2. The method of claim 1, further comprising the step of the controller entering a recovery mode when the authentication code does not match the expected value or the boot mode is in the second setting.

4. A controller; a read-only memory device storing a boot loader and at least one application to be authenticated using an authentication code encrypted using a randomized authentication code key unique to the device; a hardware security module in a boot loader that stores the randomized authentication code key; a boot mode having a first setting set by the at least one application upon shutdown that indicates to the boot loader that the application will be authenticated upon shutdown, and a second setting set by the boot loader before the controller enters a low power state that indicates to the boot loader that the application will be booted; and upon shutdown, prior to entering the low power state, the controller is configured to execute instructions of the boot loader to reboot 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.

1. A secure boot system, comprising:

1. A secure boot system comprising: a controller configured to, upon waking from the low power state, execute instructions of the boot loader 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 transferring control to the at least one application.

5. A controller; a read-only memory device storing a boot loader and at least one application to be authenticated using an authentication code encrypted using a randomized authentication code key unique to the device; a hardware security module in a boot loader that stores the randomized authentication code key; a boot mode having a first setting set by the at least one application upon shutdown that indicates to the boot loader that the application will be authenticated upon shutdown, and a second setting set by the boot loader before the controller enters a low power state that indicates to the boot loader that the application will be booted; and upon shutdown, prior to entering the low power state, the controller is configured to execute instructions of the boot loader to reboot 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.

1. A secure boot system, comprising: and upon waking from the low power state, the controller is further configured to execute instructions of the boot loader to unlock the randomized authentication code key and use the randomized authentication code key to verify that the authentication code is invalid, and before passing control to the at least one application, the controller executes instructions of the boot loader to authenticate the at least one application, set a valid authentication code, set the boot mode to the second setting, reboot, 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.

6. A controller; a read-only memory device storing a boot loader and at least one application to be authenticated using an authentication code encrypted using a randomized authentication code key unique to the device; a hardware security module in a boot loader that stores the randomized authentication code key; a boot mode having a first setting set by the at least one application upon shutdown that indicates to the boot loader that the application will be authenticated upon shutdown, and a second setting set by the boot loader before the controller enters a low power state that indicates to the boot loader that the application will be booted; and upon shutdown, prior to entering the low power state, the controller is configured to execute instructions of the boot loader to reboot 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.

1. A secure boot system, comprising:

1. The secure boot system of claim 1, wherein upon waking from the low power state, the controller executes instructions of the boot loader to unlock the randomized authentication code key, use the randomized authentication code key to verify that the authentication code is invalid, attempt to authenticate the application, and enter a recovery mode if authentication of the application fails.

7. A secure boot method for a system having a controller that processes an application, the method comprising: the application setting a boot mode to a first setting, the first setting indicating to a boot loader that the application will be authenticated before entering a low power state; the controller rebooting the boot loader; the controller authenticating the application; the controller setting an authentication code; the controller setting the boot mode to a second setting in the boot loader, the second setting indicating to the boot loader that upon wake, the application should be booted; the controller entering a low power state; the controller encrypting the authentication code with a randomized, device-unique authentication code key; Upon waking, the controller unlocks the authentication code key; the controller verifying that the authentication code is valid using the authentication code key; the controller invalidating the authentication code; the controller locking the authentication code key; after invalidating the authentication code and locking the authentication code key, the controller transferring control from the boot loader to the application; A secure boot method comprising the steps of:

8. 8. The method of claim 7, wherein the step of disabling the authentication code further comprises the controller erasing the authentication code from memory before transferring control from the boot loader to the application, thereby preventing the application from accessing the authentication code.

9. A secure boot method for a system having a controller that processes an application, the method comprising: the application setting a boot mode to a first setting, the first setting indicating to a boot loader that the application will be authenticated before entering a low power state; the controller rebooting the boot loader; the controller authenticating the application; the controller setting an authentication code; the controller setting the boot mode to a second setting in the boot loader, the second setting indicating to the boot loader that upon wake, the application should be booted; the controller entering a low power state; the controller encrypting the authentication code with a randomized, device-unique authentication code key; Upon waking, the controller unlocks the authentication code key; the controller verifying that the authentication code is invalid using the authentication code key; the controller attempting to authenticate the application; if the application fails to be authenticated, the controller enters a recovery mode; the controller setting the boot mode to a second setting in the boot loader, the second setting indicating to the boot loader that upon wake, the application should be booted; A secure boot method comprising the steps of:

Images