Actually immutable firmware authentication, recovery, and related security

Abstract

The invention relates to a method for securely booting a device having a non-volatile memory (NVM), the method comprising: performing a task mode, comprising: protecting a protected region of the NVM; protecting a draft area of the NVM; executing a download boot mode, including: protecting a protected area of the NVM; executing integrity check of the protected area, loading and starting a repair program; setting an application downloading firewall; and downloading a firmware, a draft page, or one of a firmware and a draft page for the device, including an authentication check of the downloading; executing a submission start mode, including: protecting a draft area of the NVM; submitting firewall settings by the application; checking the authenticity of the draft area; information from the draft area is copied to the protected area; and protecting the protected area of the NVM.

Description

Technical Field

[0001] Various exemplary embodiments disclosed herein relate to solutions for creating firmware (FW) attestation, recovery, and related security functions that are effectively immutable. Background Art

[0002] Protection, detection, and recovery against malware threatening an integrated circuit (IC) with embedded memory. The mutable executable memory of the IC may be altered in a way that an attacker gains control of the IC. In the worst case, the attacker cannot be removed from control of the IC, and thus the attacker has obtained persistent control. Summary of the Invention

[0003] An overview of various exemplary embodiments is presented below.

[0004] Various embodiments relate to a method for secure booting of a device having non-volatile memory (NVM), the method comprising: performing a task mode, including: protecting a protected area of the NVM; protecting a draft area of the NVM; performing a download boot mode, including: protecting the protected area of the NVM; performing a protected area integrity check to load a boot patch; applying download firewall settings; and downloading firmware, a draft page, or one of firmware and draft pages for the device, including authentication checks for the download; performing a commit boot mode, including: protecting the draft area of the NVM; applying commit firewall settings; performing a draft area authenticity check; copying information from the draft area into the protected area; and protecting the protected area of the NVM.

[0005] Describe various embodiments, wherein performing the task mode includes receiving a command indicating to initiate an application and starting the application.

[0006] Describe various embodiments, wherein performing the task mode includes receiving a command indicating to initiate a download mode, setting the boot mode to the download mode, and resetting the device.

[0007] Describe various embodiments, wherein performing the task mode includes receiving a command indicating to initiate a commit mode, setting the boot mode to the commit mode, and resetting the device.

[0008] Describe various embodiments, wherein performing the task mode includes: performing a boot measurement; and determining a boot measurement response.

[0009] Describe various embodiments, wherein performing the task mode includes: performing a protected area integrity check; and loading a boot patch.

[0010] Describes various embodiments in which the execution task mode includes: checking application integrity; applying firewall settings based on one of the application or default firewall settings; and locking the customer factory page in the NVM.

[0011] Describes various embodiments in which the execution task mode includes: generating a receive (RX) poll ready notification; and performing an RX poll.

[0012] Describes various embodiments in which the protection of the INFO factory page is performed.

[0013] Describes various embodiments that further include: performing hardware initialization; performing INFO integrity checks; and loading INFO patches.

[0014] Describes various embodiments in which the execution download start mode includes setting the start mode to the commit start mode and resetting the device at the end of the download start mode.

[0015] Various additional embodiments relate to a device configured to start securely, where the device includes a non-volatile memory (NVM), the device includes a processor configured to: execute a task mode that includes: protecting a protected area of the NVM; protecting a draft area of the NVM; execute a download start mode that includes: protecting the protected area of the NVM; performing a protected area integrity check and loading a start patch; applying download firewall settings; and downloading firmware for the device, a draft page, or one of the firmware and the draft page, including an authentication check of the download; execute a commit start mode that includes: protecting the draft area of the NVM; applying commit firewall settings; performing a draft area authenticity check; copying information from the draft area into the protected area; and protecting the protected area of the NVM.

[0016] Describes various embodiments in which the execution task mode includes receiving a command indicating to initiate an application and starting the application.

[0017] Describes various embodiments in which the execution task mode includes receiving a command indicating to initiate a download mode, setting the start mode to the download mode, and resetting the device.

[0018] Describes various embodiments in which the execution task mode includes receiving a command indicating to initiate a commit mode, setting the start mode to the commit mode, and resetting the device.

[0019] Describes various embodiments in which the execution task mode includes: performing a startup measurement; and determining a startup measurement response.

[0020] Describes various embodiments in which the execution task mode includes: performing a protected area integrity check; and loading a start patch.

[0021] Describes various embodiments in which the execution task mode includes: checking application integrity; applying firewall settings based on one of the application or default firewall settings; and locking the factory page in the NVM.

[0022] Describes various embodiments in which the execution task mode includes: generating a receive (RX) poll ready notification; and performing an RX poll.

[0023] Describes various embodiments in which the processor is further configured to: protect the INFO factory page.

[0024] Describes various embodiments in which the processor is further configured to: perform hardware initialization; perform INFO integrity check; and load INFO patches.

[0025] Describes various embodiments in which the execution download startup mode includes setting the startup mode to the commit startup mode and resetting the device at the end of the download startup mode.

[0026] The features and technical advantages of examples in accordance with the present disclosure have been outlined rather broadly above so that the following detailed description may be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples can be readily used as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the concepts disclosed herein, both the organization and method of operation thereof together with associated advantages will be better understood from the following description when considered in conjunction with the accompanying drawings. Each of the drawings is provided for purposes of illustration and description and is not to be construed as limiting the bounds of the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] To understand the above features of the present disclosure in detail, a more specific description briefly summarized above can be made by referring to the various aspects, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings only illustrate certain typical aspects of the present disclosure and should not be considered as limiting its scope, since the description may admit other equally effective aspects. The same reference numerals in different drawings may identify the same or similar elements.

[0028] Figures 1A - 1D A flowchart showing a startup process according to an embodiment. DETAILED DESCRIPTION

[0029] Aspects of the present disclosure are described more fully hereinafter with reference to the accompanying drawings. However, the present disclosure may be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. In fact, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art should appreciate that the scope of the present disclosure is intended to cover any aspect of the present disclosure disclosed herein, whether implemented independently of any other aspect of the present disclosure or in combination therewith. For example, any number of the aspects set forth herein may be used to implement a device or practice a method. Additionally, the scope of the present disclosure is intended to cover such devices or methods practiced using other structures, functionality, or a combination of structures and functionality in addition to or different from the various aspects of the present disclosure set forth herein. It should be understood that any aspect of the invention disclosed herein may be embodied by one or more elements of a claim.

[0030] Certain aspects of solutions for creating virtually immutable firmware (FW) attestation, recovery, and related security features will now be presented with reference to various devices and techniques. These devices and techniques will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using hardware, software, or a combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0031] Protection, detection, and recovery against malware threatening an integrated circuit (IC) with embedded memory. The mutable executable memory of the IC may be altered in a way that an attacker gains control of the IC. In the worst case, the attacker cannot be removed from control of the IC, and thus the attacker obtains persistent control. Accordingly, solutions to overcome these problems are needed, and embodiments providing such solutions will be described hereinafter.

[0032] Elements of the solution include combining the following hardware (HW) and firmware (FW) elements to provide a non-volatile memory (NVM)-based system-on-chip (SOC) solution that fully addresses the conflicting security requirements of immutability and configurability / patchability for features such as FW upgrades, FW attestation, lifecycle management, and customer factory configuration. The combination of these elements allows for the creation of virtually immutable code segments / patches in a tamper-evident manner.

[0033] The key problems overcome by this solution include the following two items. The first item includes meeting security requirements, including the immutability of boot, FW measurement, and recovery (update). This means that this function cannot be patched and updated in the field because it is immutable. This requirement stems from the security risk assessment that all mutable code must be assumed to be potentially under the control of an attacker. The second item includes that, for security reasons, the recovery mechanism needs to be updatable.

[0034] This challenge is overcome by a phased update mechanism. The first phase includes a patchable secure download that performs authentication and decryption of the update package, which includes patches for the secure download and the patchable boot itself. The second phase includes an unpatchable commit that has a different download authentication that is immutable (i.e., unpatchable). It is also necessary to pass through this second phase to activate the patch for the secure download in the first phase.

[0035] Therefore, the secure download / recovery mechanism is patchable, for example, to mitigate future attacks that may potentially include physical attacks. At the same time point, the download / recovery mechanism meets the requirement that cryptographic security can only rely on immutable code, and this is achieved through the second phase.

[0036] It should be noted that, in fact, in some cases, when immutable FW measurement is available, it is sufficient to only check the patch for the download in the second phase (commit).

[0037] This problem is now described in more detail. The security functions required to resist malware threats include the following two items. The first item includes firmware detection or attestation, for example, cryptographic checksums calculated based on all mutable code inspected internally (detected) or returned externally to the IC (attested). Subsequently, by comparing the checksum with a known good value, it can be detected whether the integrity of the code in the memory is still good, or whether there is potential malware infection of the device. The second item includes a secure download / recovery mechanism that can overwrite mutable code and thus expel potential malware infections. The secure download may itself have to additionally ensure the authenticity, integrity, and confidentiality of the loaded code.

[0038] In this context, sensitive assets include mutable code and data on the device and the correct functioning of the device.

[0039] The threats considered include persistent attacker control on the device, which results in permanent denial of service, permanent alteration of code or data, or download of unauthenticated code.

[0040] The following are some different attack methods. First, the attacker has full control over all available logical interfaces (system power management interface (SPMI), radio frequency (RF), communication general-purpose input / output (GPIO), I2C, etc.). Interfaces that are not connected to the printed circuit board (PCB) or cannot be controlled by logical components are not considered available logical interfaces. The residual risk assumed is that once the host interface is open, the attacker can exploit firmware errors to gain control of the device's central processing unit (CPU).

[0041] Second, since power connection / reset is usually configurable on the PCB, it is assumed that the attacker can control power and reset. Therefore, the attacker may be able to disrupt operations. Third, the attacker cannot modify the PCB. Fourth, physical attacks, side-channel attacks, fault attacks, etc. are considered outside the scope of this solution.

[0042] In addition, it is assumed that the test and debug interfaces are adequately protected or can be protected by relevant firewall mechanisms.

[0043] To minimize the risk of infection, this security function should be implemented in immutable code. This means that during field operation, the IC enforces HW protection so that the attacker cannot change this code or execute it logically. Therefore, it is assumed that the attacker has controlled all IC interfaces and all memories that can be written by the IC in the field. This is the worst-case assumption. Additionally, detection / verification and recovery may need to be run before any mutable code can be executed. Therefore, those functions may need to be implemented within the startup of the IC.

[0044] On the other hand, the security function mentioned can be complex because further requirements need to be met. For example: Verification and download require a communication stack, and the download mechanism may involve further security measures such as encryption, integrity, authentication; the communication stack may need to be customer-specific and thus cannot be stored in read-only memory (ROM). Potentially, this configuration needs to be completed and locked at the customer or original equipment manufacturer (OEM); and anti-tear protection. In addition, the startup of the IC can also perform some important firewall configurations.

[0045] Therefore, it is highly recommended that the security function or parts of it (e.g., recovery) are patchable.

[0046] The immutability, configurability, and patchability requirements in the previous paragraphs are conflicting requirements. The embodiments disclosed in this document aim to resolve this conflict so that the function becomes practically immutable.

[0047] The embodiments disclosed in this document include combining the following HW and FW components to provide a solution that fully addresses the conflicting security requirements of immutability and configurability / patchability. In addition, the solution is anti-tear.

[0048] The device includes an HW firewall that can write-protect the NVM area and lock the configuration until the next reset. This allows for the creation of a permanently immutable area and an immutable area until the next reset.

[0049] The CPU / system includes a reset with a boot reason. This allows for the expulsion of any malicious code / effects, the reset of the firewall configuration, and the passing of status information. Thus, different boot paths can be selected for each boot sequence, and this ensures that there are no malicious effects.

[0050] The embodiment includes the concept of effectively immutable pages, called protected pages. A protected page is a page made immutable by the HW firewall. It can hold patches, e.g., security fixes for security update functions in the ROM.

[0051] The embodiment also includes the ability to update protected pages. This includes a secure download mechanism that cryptographically verifies the signature of the new protected page. The protected page stores the new protected page in a dedicated candidate page called a draft page. The protected page uses a reset with a boot reason to reset the firewall to a specific commit process path.

[0052] The commit process path includes the following functions. The commit process path is implemented in immutable code; it cannot be patched. The commit process path is the only path where the protected page is open to be written. There are no communication or other configuration possibilities for this function. Thus, there are no potential external influences from attackers. The commit process path function provides cryptographic signature verification of the draft page. Optionally, the commit process path can perform a fallback check. The draft page is copied to the protected page only when the cryptographic signature verification is successful.

[0053] This specific expulsion of potential malware effects, the unaffected immutable cryptographic signature check, the unaffected copy, and the write protection of this protected page in all other boot paths make the protected page effectively immutable. The signature verification by the secure download mechanism is an additional security protection against any residual errors (or future) weaknesses in this commit signature check.

[0054] The embodiments described herein implement anti-tearing. In the case of tearing, the secure download steps can be repeated until there is a valid draft page. In the case of tearing, the commit process can be repeated until the copy from the draft page to the protected page is successful. Thus, it can be ensured that a valid protected page with patches is available.

[0055] The embodiments described herein implement FW attestation / encryption measurement of code (similar to secure boot - provided that the checksum is verified in the chip, e.g., by signature checking). This concept of creating immutable and practically immutable pages / code can be directly used to implement FW attestation, i.e., calculating an encrypted checksum (hash) based on the relevant code. For the boot path that performs attestation / measurement, the protected pages are locked and thus immutable. The attestation / measurement can calculate the encrypted checksum based on the code and internally check the checksum or return the checksum externally as an attestation value. If there is a mismatch, the code can be restored through the firmware download / recovery function. Thus, malware can also be evicted from the NVM. The attestation / measurement code needs to be implemented in immutable memory. Thus, it can be ensured that this feature is immune to malware impact.

[0056] The attestation feature can be split into two or more steps. First, attest / measure the protected pages (optionally, draft) pages. This function is implemented in immutable memory. Then, the protected pages can be trusted. Second, the patches / code in the protected pages can be used in combination with the immutable code to attest / check the next level of memory. This step can be iterated if necessary.

[0057] Figure 1A -D shows a flowchart of a boot process according to an embodiment. The flowchart includes tasks, download, and submission modes. The shading indicates the trust level in the system. The two darkest shadings indicate the highest trust for running immutable code. The lightest shading indicates a high trust for running a verified patch from a protected page, i.e., practically immutable code. Once the host interface is open as an input, there is a risk of residual attacks via errors or misconfigurations, but it can be observed that all critical areas are locked before an attack occurs.

[0058] The startup process begins with a HW startup at step 100. The startup process then automatically loads a Group Policy Object (GPO) from the INFO factory page at step 102. The INFO factory page is a page that can be programmed at the factory and locked after factory initialization (step 104). Since this page is permanently locked after factory initialization, it is considered immutable and can therefore be used to patch other immutable code after pilot production. Next, the startup process locks INFO write permission at step 104. It should be noted that this is done without a CPU. Next, the startup process starts the CPU by starting the Read-Only Memory (ROM) at step 106. HW initialization is then performed at step 108. The startup process then performs an INFO integrity check at step 110. It should be noted that steps 102, 104, 110, and 112 are optional steps depending on the implementation and whether such factory pages need to be locked or used for patching. The startup process then loads the INFO patch at step 112. The startup process then determines at step 114 which startup mode has been selected. The startup mode can be based on the L0 register content. There are three potential startup modes: task mode; commit mode; and download mode. When the startup mode is task mode, the startup process proceeds to step 116 in Figure 1B When the startup mode is download mode, the startup process proceeds to step 150 in Figure 1C When the startup mode is commit mode, the startup process proceeds to step 160 in Figure 1D

[0059] ​In the cold start mode, the start-up process first protects the protected area of the start-up device using a firewall, for example, in step 116. Subsequently, the start-up process protects the draft area using a firewall, for example, in step 118. It should be noted that after this step and until the next reset, the protected pages and draft pages are immutable. Next, the start-up process performs a start-up measurement in step 120. This can, for example, include calculating a cryptographic checksum of sensitive information or code. Subsequently, the start-up process makes a measurement response based on the start-up measurement in step 122. It should be noted that in other embodiments, steps 120 and 122 are optional and may not be included. This start-up measurement can, for example, include comparing the cryptographic measurement with a known value or outputting this data so that other entities in the system can check the measurement. The start-up process then performs a protected integrity check in step 124, and next, the start-up process loads a start-up patch in step 126. The start-up process then checks the application integrity in step 128. The start-up process applies firewall settings to lock the factory page in step 130. These firewall settings can be application-based or default values. The start-up process generates a receive (RX) poll ready notification in step 132. The start-up process then performs an RX poll in step 134. This means that the device waits for a command from outside the device. In another embodiment, the device can implement a time window in which the device looks for a signal that triggers a specific action. The start-up process then determines the received start-up command in step 132. If a MEASURE_APPLICATION command is received during the RX poll, the process performs the MEASURE_APPLICATION command in step 138. If the application is ready to start, the start-up process starts the application based on an external indication in step 140, and the start-up process ends.

[0060] If the received command indicates the download mode, the startup process sets the startup mode to the download mode at step 142 and initiates a hard and soft reset at step 144. This causes the startup process to restart at step 100. If the received command indicates the commit mode, the startup process sets the startup mode to the commit mode at step 146 and initiates a hard and soft reset at step 148. This causes the startup process to restart at step 100. In the download startup mode, the startup process first protects the protected area of the startup device using a firewall, for example, at step 150. The startup process then performs a protected integrity check at step 152. Next, the startup process loads a startup patch at step 154. The startup process applies the download firewall settings at step 156. The startup process then performs a firmware download at step 158. This then causes the startup process to restart at step 100. It should be noted that the firmware update can update the draft pages with the established updates for the protected pages, and this can be done because the draft pages are not protected. The protected pages cannot be changed because they are protected. The firmware download can be a secure firmware download that checks the authenticity of the update. This provides a good barrier against malware. Thus, the integrity and authenticity of the content of the draft pages are checked.

[0061] In the commit mode, the startup process first protects the draft area of the startup device using a firewall, for example, at step 160. The startup process applies the commit firewall settings at step 162. The startup process then performs a draft authenticity check at step 164. Next, the startup process copies the draft information into the protected area at step 166. The startup process then protects the protected area using a firewall, for example, at step 168. The startup process then generates a commit completion response indication at step 170. This then causes the startup process to restart at step 100.

[0062] The startup process and device may include the following security features.

[0063] One feature is that some specific areas of the NVM have specific roles including the following. The factory area includes the INFO factory page, which contains configuration data set at the factory, such as chip identification (ID), device-specific trimming, ROM patches, etc. These data are never updated in the field.

[0064] The protected area includes configuration data specific to the current state of the device and the current FW stored in the NVM, such as FW version, reference values, firewall configuration, patches, etc. This area is updated every time there is a new FW update.

[0065] The draft area contains content similar to the protected area but is not the active version. It is updated every time there is a successful FW download.

[0066] The customer factory area contains configuration information specific to the customer application, such as host interface settings, and / or device-specific configuration information, such as trimming. If these settings are modified, the device may be spoofed. This area is set by the customer at their factory and is never changed in the field.

[0067] Another feature is a first-level HW firewall that can protect specific NVM areas and addresses / registers. Specific areas in the non-volatile memory can include, for example, the factory area, draft area, protected area, customer factory area, etc.

[0068] Another feature is a second-level HW firewall that can be configured to protect any memory area or address / register, for example, using a unified translation lookaside buffer. The first-level and second-level firewalls can provide write protection for the corresponding areas (read / execute protection can also be provided). In addition, the first-level and second-level firewalls can be locked until the next reset of the device. The first-level firewall can be locked at the level of each area defined in its configuration, while the second-level firewall can only be locked at the level of the complete firewall.

[0069] After an area is write-protected by a firewall and the corresponding firewall configuration is locked, this area is immutable until the next reset of the device because the HW does not allow any write access to this area or any reconfiguration that enables write access.

[0070] Another feature includes a reset with a boot reason function. See, for example, steps 114, 140, 142, and 146. The HW supports a function for the SW that resets the CPU and all configurations done by the SW, with two exceptions; first, settings that are non-critical for the security of the device; and second, specific registers or memories that have values that can be evaluated after the CPU reset. This can be used to pass status information to control the next boot path. Therefore, this value is also called the boot reason.

[0071] Another feature includes cryptographic hash, decryption, or signature verification functions implemented by the HW or by immutable code (in ROM or immutable memory).

[0072] Multiple security features for creating immutable functions will now be described. The CPU can be started in the following modes: task mode; FW download mode; and commit mode. In task mode, the code stored in the NVM is executed after the content of the NVM has been measured cryptographically against a reference value. ROM patches from the factory area or protected area can be applied. However, ROM patches from the protected area are only applied after measurement to prevent the execution of tampered ROM patches.

[0073] In the FW download mode, after successful authentication, the FW image update is applied to the scratch area and the NVM. ROM patches from the INFO area or the protected area are applied. Additionally, the authenticity of the FW image / scratch page is checked by verifying the cryptographic signature before writing to the NVM. In the commit mode, the scratch area is copied to the protected area after additional encryption checks. Only ROM patches from the factory area can be applied.

[0074] In another feature used to create an immutable function, the user can switch from one mode to another via a command through the host. Alternatively, the device FW can trigger this mode switch by setting a hardware register. This will cause a reset of the device, where the boot reason register is updated to the expected mode. This means that when entering a mode other than the boot reason, the CPU will start from a pristine state.

[0075] Another feature used to create an immutable function requires that the scratch area and the protected area are not opened simultaneously for write operations. Both areas are closed in the task mode. During FW download, the protected area is closed and the scratch area is open. During the commit phase, the protected area is open and the scratch area is closed. The protected area can be considered effectively immutable because it is only copied after additional encryption checks have been performed. These checks and copies are done via immutable code with the host interface uninitialized, so it can be considered trustworthy.

[0076] Another feature used to create an immutable function requires that the factory area is always closed and write - inaccessible after leaving the manufacturer's factory. It can be considered immutable.

[0077] Another feature used to create an effectively immutable function requires that the customer factory area is always closed and write - inaccessible after leaving the customer's factory. It can be considered effectively immutable.

[0078] The following security feature is used to produce anti - tear. Tearing can occur during FW download. Depending on the timing, the code / data area or the scratch area may be incomplete. If the code / data area is torn, this will be detected the next time the contents of the NVM are checked during startup. If the scratch area is torn, this will be detected when the commit mode is executed.

[0079] Tearing can also occur during the commit phase. In this case, the protected area may be incomplete. This will be detected the next time the device starts up. If the protected area is torn, the boot ROM will not allow FW download because this could cause tearing of the scratch area, so a commit is mandatory.

[0080] Table 1 below describes the reasons why a tear can occur and what the next steps should be in response to a tear. A tear can occur in the draft area or the protected area. The draft area and the protected area can be torn or intact. Unless in rare cases, such as when cosmic rays irradiate the device, it should not happen that both the draft area and the protected area are torn. When this happens, the next step is to degrade the download to restore the draft area. If the draft area is torn and the protected area is intact, this may occur when the download is interrupted. In this case, the next step is to enter the download mode. If the draft area is intact and the protected area is torn, this may occur when the submission mode is interrupted. In this case, the next step is to enter the submission mode. If the draft area is intact and the protected area is intact, but the NVM / code area is incorrect, this may occur when the download is interrupted. In this case, the next step is to enter the download mode. If the draft area is intact and the protected area is intact, this may occur when the operation is normal. In this case, the next step is to start execution or enter the download mode.

[0081] Table 1

[0082] The boot process embodiments described herein interleave repairable downloads and immutable submissions to solve problems while always fully relying on an immutable foundation in terms of encryption, and at the same time being able to address the security issues of firmware updates / restorations when other implementation attacks (e.g., fault attacks) transition to post-quantum cryptography (PQC), etc., occur in the future.

[0083] As discussed above, an important aspect of the boot process solution is to combine HW and FW elements to provide an NVM-based SOC solution that fully addresses the conflicting security requirements of immutability and configurability / patchability for features such as FW upgrades, FW attestation, lifecycle management, and customer factory configuration. The combination of these elements allows for the creation of virtually immutable code segments / patches in a tear-proof manner.

[0084] In the NVM execution mode, measurements are performed before opening the host interface and applying the ROM patch, so these measurements and the reaction to error values are immutable.

[0085] FW download is split between updates to the code / data area, the draft area, and the submission phase where the draft area is copied to the protected area. Combined with HW protection from the firewall, this ensures that updates to the protected area can only be done through immutable code. This immutable code can apply specific checks, e.g., additional signature verification, without the risk of being bypassed.

[0086] The use of the HW firewall allows for making memory areas such as the factory area and the customer factory area immutable.

[0087] Generally, ROM patching can still be applied, and the code for critical phases such as measurement and submission can still be considered immutable.

[0088] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit aspects to the precise forms disclosed. Modifications and variations can be made in light of the above disclosure, or can be obtained from practice of the aspects.

[0089] As used herein, the term "component" is to be construed broadly as hardware, firmware, and / or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, and / or a combination of hardware and software.

[0090] As used herein, meeting a threshold can refer, depending on the context, to a value being greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, not equal to a threshold, and so on. It will be apparent that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or combinations of hardware and software. The actual specific control hardware or software code for implementing these systems and / or methods does not limit the aspects. Accordingly, the operations and behavior of the systems and / or methods are described herein without reference to specific software code - it is understood that software and hardware can be designed to implement the systems and / or methods at least in part based on the description herein.

[0091] As used herein, the term "non-transitory machine-readable storage medium" is to be understood as not including transitory propagated signals, but including all forms of volatile and non-volatile memory. When software is implemented on a processor, the combination of the software and the processor becomes a particular special-purpose machine.

[0092] Since the data processing for implementing the embodiments described herein consists mostly of electronic components and circuits known to those of ordinary skill in the art, circuit details will not be set forth in any greater detail than considered necessary above in order to understand and appreciate the basic concepts of the aspects described herein and in order not to obscure or deviate from the teachings of the aspects described herein.

[0093] Unless stated otherwise, terms such as "first" and "second" are used arbitrarily to distinguish the elements described by these terms. Thus, these terms are not necessarily intended to indicate a temporal or other prioritization of such elements.

[0094] Those of ordinary skill in the art will appreciate that any block diagrams herein represent illustrative conceptual views of hardware embodying the principles of the aspects.

[0095] While each of the embodiments has been described above in terms of its structural arrangement, it is to be understood that the aspects also cover the associated methods using the embodiments described above.

[0096] Unless otherwise indicated, all numbers expressing parameter values, etc. used in this specification and the claims are to be understood as being modified in all instances by the term "about". Accordingly, unless indicated to the contrary, the numerical parameters set forth in the specification and the appended claims are approximations that may vary depending upon the desired properties sought to be obtained by the embodiments of the present disclosure. As used herein, "about" can be understood by one of ordinary skill in the art and can vary to some extent depending upon the context in which it is used. If there is a term usage that is not clear to one of ordinary skill in the art, "about" can mean up to ±10% of the particular term, taking into account the context in which the term is used.

[0097] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various aspects. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or not specifically disclosed in the specification. While each of the dependent claims listed below may directly depend on only one claim, the disclosure of the various aspects includes each dependent claim in combination with every other claim in the claim set. A phrase referring to "at least one" of a list of items refers to any combination of those items, including a single member. For example, "at least one of the following: a, b, or c" is intended to cover a, b, c, a - b, a - c, b - c, and a - b - c, as well as any combination with multiple of the same element (e.g., a - a, a - a - a, a - a - b, a - a - c, a - b - b, a - c - c, b - b, b - b - b, b - b - c, c - c, and c - c - c, or any other ordering of a, b, and c).

[0098] Elements, acts, or instructions used herein are not to be construed as critical or essential unless explicitly so described. Further, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more". Additionally, as used herein, the terms "set" and "group" are intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more". Where only one item is intended, the phrase "only one" or similar language is used. Also, as used herein, the term "having" and / or the like is intended to be an open - ended term. Additionally, unless otherwise expressly stated, the phrase "based on" is intended to mean "at least partially based on".

Claims

1. A method for securely booting a device having a non-volatile memory (NVM), characterized in that: The method comprises Execute mission mode, including: protecting a protected area of ​​the NVM; protecting a scratch area of ​​the NVM; Execute the download startup mode, including: protecting a protected area of ​​the NVM; Perform protected area integrity check Load boot patch; Application download firewall settings; and downloading firmware, a draft page, or one of firmware and a draft page for the device, including an authentication check of the downloading; Execute the commit startup mode, including: protecting the scratch area of ​​the NVM; Application submission firewall settings; Perform draft area plausibility checks; copying information from the scratch area to the protected area; and The protected area of ​​the NVM is protected.

2. The method according to claim 1, characterized in that Executing the task mode includes receiving a command instructing to initiate an application and launching the application.

3. The method according to claim 1 or 2, characterized in that: Executing the task mode includes receiving a command indicating initiation of a download mode, setting a boot mode to the download mode, and resetting the device.

4. A method according to any of the preceding claims, characterised in that Executing the mission mode includes receiving a command indicating initiation of a commit mode, setting a startup mode to the commit mode, and resetting the device.

5. A method according to any of the preceding claims, characterised in that Executing the task mode includes: Performing startup measurements; and Determines the start of the measurement response.

6. The method according to claim 5, characterized in that Executing the task mode includes: Performing protected area integrity checks; and Load the boot patch.

7. The method according to claim 6, characterized in that Executing the task mode includes: Check application integrity; Applying a firewall setting based on one of an application or a default firewall setting; and A customer factory page is locked in the NVM.

8. The method according to claim 7, characterized in that Executing the task mode includes: Generate a receive (RX) poll ready notification; and Perform RX polling.

9. The method according to claim 8, characterized in that Perform protection of the INFO factory page.

10. A device configured to start safely, characterized in that The apparatus comprises a non-volatile memory (NVM), the apparatus comprising a processor, the processor being configured to: Execute mission mode, including: protecting a protected area of ​​the NVM; protecting a scratch area of ​​the NVM; Execute the download startup mode, including: protecting a protected area of ​​the NVM; Perform protected area integrity check Load boot patch; Application download firewall settings; and downloading firmware, a draft page, or one of firmware and a draft page for the device, including an authentication check of the downloading; Execute the commit startup mode, including: protecting the scratch area of ​​the NVM; Application submission firewall settings; Perform draft area plausibility checks; copying information from the scratch area to the protected area; and The protected area of ​​the NVM is protected.

Images