Patent Description:
Secure boot functionality is often integrated into a data processing system or secure micro-controller (MCU) to verify and guarantee the integrity of the data or executable code (firmware) stored in a NVM. A secure boot may be implemented into a data processing system to prevent the execution of malicious code. Any unauthorized or modified firmware stored in the NVM is detected by the secure boot function.

Some systems may prevent or control access to the NVM. For example, a password may be required to gain access to the NVM. This approach limits the non-volatile memory access to one (or a few) processors, but does not necessarily prevent a malicious application running on those processors to also use the password.

A secure boot mechanism may be implemented with digital signature verification or similar cryptographic operation to verify the data, or firmware, stored in the NVM. The firmware is signed by an authorized entity and the signature is stored next to the firmware. The signature verification may require a long time to complete and is performed during every secure boot. In some cases, the additional time required to securely boot the system is too restrictive and may have unacceptable consequences. Some applications, such as automotive applications, may be sensitive to start-up time and may not be able to afford the extra delay required for a secure boot.

Therefore, a need exists for data integrity verification during a secure boot process in a data processing system that does not require a long time to complete.

In a first aspect, there is provided a method for performing a secure boot of a data processing system according to claim <NUM>. In a second aspect, there is provided a data processing system according to claim <NUM>.

<CIT> (<NUM>-<NUM>-<NUM>) discloses a system with a security bit to indicate the changes in the different blocks of an E2PROM. The bits are set at runtime (after the boot) and force a checksum check at the next boot.

A Lock bit disables the system during boot (so that the boot code may change any E2PROM address). The boot verification is dependent on the status of the security bit of the corresponding block.

<CIT> relates to an integrated circuit that may comprise a secure volatile memory configured to store first data-validity information associated with first data stored in an external nonvolatile memory; and a secure processor configured to: retrieve the first data-validity information from a secure remote server over a secure communication channel, wherein the secure processor uses mutual authentication with the secure remote server to secure the secure communication channel; store the first data-validity information in the secure volatile memory; retrieve the first data from the external nonvolatile memory; obtain second data-validity information associated with the first data; compare the first data-validity information stored in the secure volatile memory with the second data-validity information to generate a comparison value; and determine, based on the comparison value, whether the first data is valid.

Generally, there is provided, a data processing system and a method in the data processing system for data integrity verification of an NVM during a secure boot. Instead of cryptographically verifying the data in the NVM at each secure boot, an NVM modification counter is used to log each command to the NVM that may cause the data stored in the NVM to be modified. If the counter value from the NVM modification counter does not indicate that a modification command, such as a write command, has been provided to the NVM since the last boot up, then it is assumed the NVM has not been modified, and the device is securely booted without first cryptographically verifying the NVM contents. If the counter value indicates the NVM has been modified, then a cryptographic verification of the NVM is performed. If the verification is successful, then the device is securely booted. Otherwise, the secure boot fails. In one embodiment, the counter is controlled by the NVM controller and modifications of the NVM modification counter is restricted to the NVM controller. The use of a counter value to record modification commands to the NVM significantly reduces the amount of time required for a secure boot of the data processing system when the NVM has not been modified since the last secure boot.

<FIG> illustrates data processing system <NUM> in accordance with an embodiment. Data processing system <NUM> is highly simplified, and includes a bus <NUM>, processors <NUM> and <NUM>, and NVM <NUM>. Note, there may be many other functional blocks in data processing system <NUM> in an actual implementation. In one embodiment, data processing system <NUM> may be implemented on a single integrated circuit. Processor <NUM> includes secure bootloader <NUM>, and counter <NUM>. The functions of counter <NUM> will be discussed below. Processors <NUM> and <NUM> can be any type of processing circuit. For example, processors <NUM> and <NUM> may be microprocessors (MPUs), microcontrollers (MCUs), digital signal processors (DSPs), or another type of processor or processor core. Additionally, processors <NUM> and <NUM> may be peripheral devices or special-purpose processors used to control peripheral units, such as for example, a direct memory access (DMA) peripheral. Non-volatile memory <NUM> is bi-directionally connected to processors <NUM> and <NUM> through bus <NUM>. Bus <NUM> can be any type of bus structure, for example, bus <NUM> may be an advanced high-performance bus (AHB) or an advanced peripheral bus (APB). Counter <NUM> may be implemented using one-time programmable (OTP) memory or a monotonic counter. Secure bootloader <NUM> may be used with counter <NUM>. Counter <NUM> is provided to record the number of times the contents of NVM <NUM> have been successfully cryptographically verified. Counter <NUM> may only be accessible to secure bootloader <NUM>.

<FIG> illustrates NVM <NUM> of data processing system <NUM> of <FIG> in more detail. Non-volatile memory <NUM> includes NVM controller <NUM>, interface <NUM>, and NVM array <NUM>. External interface <NUM> is bi-directionally connected to bus <NUM> and provides control and data access to NVM <NUM> via bus <NUM> under the control of NVM controller <NUM>. NVM array <NUM> may include any type of non-volatile memory cell that can be read from or written to, such as for example, a flash memory cell, a magnetic random access memory (MRAM), a ferroelectric random access memory (RAM), etc. NVM controller <NUM> interprets control commands from a requester, and accesses memory array <NUM> for read and write operations. The requester may be a processor connected to bus <NUM> such as one of processors <NUM> and <NUM>. NVM controller <NUM> includes NVM modification flag <NUM> and counter <NUM>. In one embodiment, NVM modification counter <NUM> is controlled by the NVM controller and modifications of NVM modification counter <NUM> is restricted to the NVM controller. In another embodiment, NVM modification flag <NUM> may be implemented as part of a register file (not illustrated) in data processing system <NUM>. NVM modification flag <NUM> is set to a predetermined logic state when a command is received by NVM controller <NUM> that modifies the stored information in NVM array <NUM>. Note, a modification command is a command that causes the information stored in NVM array <NUM> to be changed or modified. For example, a modification command may be a command that causes a write, program, or erase operation of NVM array <NUM>.

NVM <NUM> may store information that includes software, firmware, executable code, data, instructions, authentication secrets, etc., and other information used during a secure boot or during normal operation of data processing system <NUM>. The term data, as used herein, may be any type of information stored in a memory, including the above mentioned types of information. The firmware may be encrypted prior to being stored in NVM <NUM>. The advanced encryption standard (AES) is one encryption type commonly used for encryption and decryption. There are also many other encryption/decryption algorithms that may be used. In an attempt to gain control of data processing system <NUM>, the information stored in NVM array <NUM> may be modified, altered, or replaced by an unauthorized entity. To ensure that data processing system <NUM> is not powered up or operated with unauthorized data code, data processing system <NUM> verifies that the information stored in NVM <NUM> is authorized and has not been replaced or modified.

<FIG> illustrates method <NUM> for monitoring and logging modification commands sent to a memory of a data processing system in accordance with an embodiment. Method <NUM> is performed by NVM controller <NUM> each time data processing system <NUM> powers up or is reset. At step <NUM>, NVM modification flag <NUM> (<FIG>) is reset to a "not set" value at system power-on. In one embodiment, NVM modification flag <NUM> is reset to a logic low state. At step <NUM>, a command for accessing NVM array <NUM> is received by NVM controller <NUM>. At decision step <NUM>, it is determined if the received command is a command that would modify the contents of NVM array <NUM>. As stated above, a modification command may be a command that either writes, programs, or erases a portion or all of NVM array <NUM>. If the command is not a modification command, the NO path is taken from decision step <NUM> back to step <NUM>. If the command is determined to be a modification command, the YES path is taken to decision step <NUM>. At decision step <NUM>, it is determined if NVM modification flag <NUM> has already been set by a previously received modification command. If modification flag <NUM> had already been set, then the YES path is taken back to step <NUM>. If modification flag <NUM> had not been previously set, the NO path is taken to step <NUM>. At step <NUM>, NVM modification counter <NUM> is incremented by one and logged. NVM modification counter <NUM> counts and stores each receipt of a NVM modification command that causes modification flag <NUM> to be set if it had not already been previously set. This ensures that counter <NUM> is only incremented once for each power up or reset period and thus reduces the number of bits required to implement counters <NUM> and <NUM>. In another embodiment, the way counter <NUM> is incremented may be different. At step <NUM>, NVM modification flag <NUM> is set.

<FIG> illustrates method <NUM> for verifying the data integrity of NVM array <NUM> during a secure boot of data processing system <NUM>. At step <NUM>, a secure boot of data processing system <NUM> begins. At step <NUM>, a count value is read from NVM modification counter <NUM>. Counter <NUM> is controlled by NVM controller <NUM> and may be incremented as described above in the discussion of <FIG>. The count value from counter <NUM> indicates how many power-on or boot cycles included reception of a NVM modification command by NVM controller <NUM>. At step <NUM>, a count value is read from counter <NUM> in processor <NUM>. The count value from counter <NUM> indicates how many times the contents of NVM array <NUM> have been cryptographically verified and trusted. Counter <NUM> is under the control of processor <NUM>. At decision step <NUM>, it is determined if the two count values are equal to each other. To determine if the two count values are equal, a comparator (not shown) such as an exclusive OR logic gate may be used. If the two count values are equal, then there has been no new modifications to the contents of NVM array <NUM> since the last cryptographic verification, and the YES path is taken from decision step <NUM> to step <NUM>. At step <NUM>, the secure boot process continues. However, if the NO path is taken from decision step <NUM> to step <NUM>, then the contents of NVM array <NUM> has been modified. It is not known if the modification is authorized or not. Therefore, at step <NUM>, a cryptographic integrity verification is performed on NVM array <NUM>. As mentioned above, the cryptographic integrity verification of the data may take a significant amount of time to complete.

In one embodiment, the secure boot mechanism may be implemented with digital signature verification or similar cryptographic operation to verify the NVM contents. The contents of the NVM is signed by an authorized entity and the signature is stored. A hash of the contents of NVM array <NUM> is then computed. The cryptographic nature of the hash is checked to validate the signature of the hash. The signature verification of the NVM content is used to provide the cryptographic verification of the memory contents. This cryptographic verification is computationally intensive and takes a certain time to complete. The time increases with the increasing size of the memory, and the verification is performed every time the secure data processing system undergoes a secure boot. In another embodiment, the cryptographic verification may be performed differently. If NVM array <NUM> is successfully verified, then the YES path is taken to step <NUM> and counter <NUM> is incremented. If the verification is not successful, meaning the modification of the contents of NVM array <NUM> was not authorized, then the NO path is taken to step <NUM> and the secure boot has failed.

The use of method <NUM> during secure boot of the data processing system results in much faster boot times when a NVM modification command (such as for a write or erase) is not received and the count values of counters <NUM> and <NUM> are equal. The boot times are faster because the verification step can be bypassed.

<FIG> illustrates data processing system <NUM> in accordance with another embodiment. Data processing system <NUM> is highly simplified and includes bus <NUM>, processor <NUM>, and NVM <NUM>. Data processing system <NUM> may be implemented on a single integrated circuit. Processor <NUM> includes secure bootloader <NUM> and a plurality of counters including counters <NUM> and <NUM>. Counters <NUM> and <NUM> may be implemented as OTP memory or monotonic counters. Processor <NUM> can be any type of processor such as a microprocessor (MPU), microcontroller (MCU), digital signal processor (DSP), or other type of processor or processor core. NVM <NUM> is bi-directionally connected to processor <NUM> through bus <NUM>. Bus <NUM> may be the same as bus <NUM> (<FIG>). NVM <NUM> includes a plurality of NVM partitions represented by NVM partitions <NUM> and <NUM>. Each NVM partition includes a counter. For example, NVM <NUM> includes counter <NUM> and NVM <NUM> includes counter <NUM>. There are the same number of counters as there are NVM partitions that need to be individually trusted, where one counter in NVM <NUM> is assigned to and corresponds with one NVM partition. In the illustrated embodiment, there is a one-to-one correspondence between counters <NUM> and <NUM> in processor <NUM> to counters <NUM> and <NUM> in NVM <NUM>. Note, for purposes of this description, the words partition, block, sector, section, and the like are interchangeable when referring to the NVM partitions <NUM> and <NUM>.

The different NVM blocks record modifications separately, but in the same way as described above for data processing system <NUM>. The embodiment of <FIG> separately assigns the plurality of counters to the plurality of NVM blocks, and independently trusts the plurality of NVM blocks. This provides the same benefits and advantages as described above regarding the embodiment of <FIG>. And in addition to the above mentioned advantages, secure bootloader <NUM> is provided with the flexibility of treating the different NVM blocks differently based on the application.

A method for performing a secure boot of a data processing system, and the data processing system are provided. The method includes: processing a command issued from a processor of the data processing system, the command directed to a memory; determining that the command is a command that causes the memory to be modified; performing cryptographic verification of the memory; and incrementing a first counter in response to the determining that the command is a command that causes the memory to be modified. The data processing system includes a processor, a memory, and a counter. The memory is coupled to the processor, and the memory stores data used by a bootloader during a secure boot. The counter is incremented by a memory controller in response to a command being a type of command that modifies the data stored by the memory.

Various embodiments, or portions of the embodiments, may be implemented in hardware or as instructions on a non-transitory machine-readable storage medium including any mechanism for storing information in a form readable by a machine, such as a personal computer, laptop computer, file server, smart phone, or other computing device. The non-transitory machine-readable storage medium may include volatile and non-volatile memories such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage medium, flash memory, and the like. The non-transitory machine-readable storage medium excludes transitory signals.

The invention is described by the independent claims.

Claim 1:
A method for performing a secure boot of a data processing system (<NUM>), the method comprising:
processing (<NUM>) a command issued from a processor (<NUM>) of the data processing system (<NUM>), the command directed to a memory (<NUM>);
determining (<NUM>) that the command is a command that causes the memory (<NUM>) to be modified;
incrementing (<NUM>) a first counter value of a first counter (<NUM>) in response to the determining that the command is a command that causes the memory (<NUM>) to be modified;
setting (<NUM>) a modification flag (<NUM>) to a first logic state in response to incrementing the first counter (<NUM>), wherein the set modification flag (<NUM>) indicating that the memory (<NUM>) has been modified so that the first counter (<NUM>) is not incremented for subsequent modification commands, such that the first counter value indicates how many boot cycles include reception of a modification command by the memory controller (<NUM>);
determining (<NUM>) that the first counter value of the first counter (<NUM>) is not equal to a second counter value of a second counter (<NUM>); and
performing (<NUM>) cryptographic verification of the memory (<NUM>) in response to the first and second counter values not being equal, otherwise continuing (<NUM>) with the secure boot process if the first and second counter values are equal;
incrementing (<NUM>) the second counter (<NUM>) in response to the cryptographic verification of the memory being successful, such that the second counter value indicates how many times the memory (<NUM>) has been cryptographically verified;
resetting the modification flag (<NUM>) to a second logic state in response to a subsequent restart of the data processing system (<NUM>); and
wherein the first counter (<NUM>) is under the control of a memory controller (<NUM>) of the memory (<NUM>) and the second counter (<NUM>) is under the control of the processor (<NUM>).