KR102598510B1 - Method and apparatus for verify software integrity - Google Patents

Abstract

As a method for a hardware security module to verify the integrity of software, when software stored in a serial flash memory is executed, a hash table storing hash values for the software is obtained from the serial flash memory and stored in the internal memory of the hardware security module. Loading, calculating hash values for each split block of the software, comparing the hash value calculated for the split block with the hash value of the split block stored in the hash table in the split block order to determine whether they match. It includes a step of determining, and if there is a match, ending the integrity verification, and if there is a mismatch, rebooting the system.

Description

Software integrity verification method and device {METHOD AND APPARATUS FOR VERIFY SOFTWARE INTEGRITY}

The present invention relates to a method for verifying the integrity of software operating in XIP (eXecute-In-Place) in serial flash memory.

The automotive ECU (Electronic Control Unit) uses serial flash memory that supports XIP as a storage device for fast booting and CAN (Controller Area Network) response.

However, because the XIP of serial flash memory has low read performance, it takes a lot of time to verify the integrity of software stored in serial flash memory. Therefore, if you use the commonly used trust chain of "ROM → boot loader → software executable code", the boot time will be longer.

In order to solve the boot time, there is a conventional method of first executing the software executable code stored in the serial flash memory and verifying the integrity of the software executable code in the HSM (Hardware Security Module).

At this time, the conventional method uses a single hash for the software executable code. However, this method has the problem that the integrity verification time is long due to the low read speed of the serial flash memory, and as a result, the software must run for a long time until verification is completed. Additionally, there is a problem in that the software operates in an unverified state for a long time until integrity verification is completed, errors are discovered, and the system is rebooted.

The problem to be solved is to provide a method and device for verifying the integrity of software that operates in XIP (eXecute-In-Place) in serial flash memory using a hash table.

According to one feature, as a method for the hardware security module to verify the integrity of software, when software stored in a serial flash memory is executed, a hash table storing hash values for the software is obtained from the serial flash memory to secure the hardware security. Loading into the internal memory of the module, calculating hash values in units of split blocks of the software, in the split block order, combining the hash value calculated for the split block with the hash value of the split block stored in the hash table. It includes a step of comparing and determining whether they match, and if they match, terminating the integrity verification, and if they do not match, rebooting the system.

Between the loading step and the step of calculating the hash values, calculating a hash value for the hash table, reading the hash value calculated for the hash table from the serial flash memory, and calculating the hash value for the hash table. The method may further include performing integrity verification by comparing the hash value of the hash table with the hash value of the read hash table, and rebooting the system if the integrity verification fails.

The rebooting step includes calculating an electronic signature value based on the hash value of the hash table, reading an electronic signature value generated based on the hash value of the hash table from the serial flash memory, and The method may include comparing the calculated electronic signature value with the read electronic signature value, determining that integrity verification has failed if there is a discrepancy, and rebooting the system.

The software may be executed in eXecute-In-Place (XIP) mode on serial flash memory.

According to another feature, the integrity verification device includes a serial flash memory that stores a software executable code, a hash table containing hash values for a plurality of partition blocks dividing the software executable code into a plurality of blocks, and the software executable code is executed. If so, the executed software execution code is divided into multiple pieces, the hash value of the split block is calculated in the order of the split blocks, and the hash value of the calculated split block is compared with the hash value of the corresponding split block stored in the hash table and matches. and a hardware security module that determines whether the hash value of the divided block is calculated and matches the hash value of the divided block stored in the hash table, and the hardware security module completes integrity verification. If there is a mismatch, the system is shut down. Reboot.

The hardware security module generates an electronic signature value for the hash table, reads the electronic signature value stored in the serial flash memory, and reboots the system if the generated electronic signature value and the read electronic signature value do not match. and, if they match, hash value verification can be performed in units of the divided blocks.

The hardware security module can directly access the serial flash memory and read the hash table and electronic signature value stored in the serial flash memory.

The electronic signature value may be generated based on the hash value of the hash table.

The integrity verification device further includes a microcontroller unit (MCU) that executes the software executable code in an unverified state, and the hardware security module executes software executed independently of the MCU simultaneously with executing the software executable code of the MCU. You can perform integrity verification operations on the code.

The integrity verification device may further include a microcontroller unit (MCU) that executes the software execution code in an eXecute-In-Place (XIP) mode of the serial flash memory.

According to an embodiment, the software execution code is divided into a certain size, the hash is verified in block units, and when an error is detected in one block, the system is immediately rebooted, thereby minimizing the time that unverified software runs.

Figure 1 is a block diagram showing the configuration of a software integrity verification device according to an embodiment.
Figure 2 is an example of hash table creation for verifying the integrity of software according to an embodiment.
Figure 3 explains the integrity verification operation of software using a hash table according to an embodiment.
Figure 4 is a flowchart showing a software integrity verification operation according to an embodiment.

Below, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention. However, the present invention may be implemented in various different forms and is not limited to the embodiments described herein. In order to clearly explain the present invention in the drawings, parts that are not related to the description are omitted, and similar parts are given similar reference numerals throughout the specification.

Throughout the specification, when a part is said to “include” a certain element, this means that it may further include other elements rather than excluding other elements, unless specifically stated to the contrary.

In addition, terms such as “…unit”, “…unit”, and “…module” used in the specification refer to a unit that processes at least one function or operation, which may be implemented through hardware or software or a combination of hardware and software. You can.

The devices described in the present invention are composed of hardware including at least one processor, a memory device, a communication device, etc., and a program that is executed in conjunction with the hardware is stored in a designated location. The hardware has a configuration and performance capable of executing the method of the present invention. The program includes instructions that implement the operating method of the present invention described with reference to the drawings, and executes the present invention by combining it with hardware such as a processor and memory device.

In this specification, “transmission or provision” may include not only direct transmission or provision, but also indirect transmission or provision through another device or by using a circuitous route.

In this specification, expressions described as singular may be interpreted as singular or plural, unless explicit expressions such as “one” or “single” are used.

In this specification, the same reference numbers refer to the same elements regardless of the drawings, and “and/or” includes each and all combinations of one or more of the mentioned elements.

In this specification, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, a first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component without departing from the scope of the present disclosure.

In the flowcharts described herein with reference to the drawings, the order of operations may be changed, several operations may be merged, certain operations may be divided, and certain operations may not be performed.

Figure 1 is a block diagram showing the configuration of a software integrity verification device according to an embodiment, Figure 2 is an example of generating a hash table for verifying the integrity of software according to an embodiment, and Figure 3 is a hash table using a hash table according to an embodiment. Describes the software integrity verification operation.

First, referring to FIG. 1, the software integrity verification device 100 is included in a chip and is mainly illustrated with components related to software integrity verification. The software integrity verification device 100 includes a microcontroller unit (MCU) 120 and a hardware security module (hereinafter referred to as 'HSM') 130.

The MCU 120 includes a serial flash memory 111 and a processor 120.

The serial flash memory 111 stores software required for a device to which the MCU 120 is applied.

The processor 120 loads a bootloader into the serial flash memory 111 and executes software.

At this time, the software subject to integrity verification operates in XIP (Execute In-Place) in the serial flash memory 111. XIP is a technology that directly executes program code from non-volatile memory without loading it into main memory. It includes the process of loading the kernel image from non-volatile memory to main memory during kernel booting, the process of decompressing the compressed kernel image, and During the decompression process, the process of writing the decompressed kernel to main memory can be omitted.

The HSM 130 verifies the integrity of software operating as XIP in the serial flash memory 111.

Referring to FIG. 2, the serial flash memory 111 stores software executable code running in XIP mode, a hash table, and an electronic signature value generated based on the hash value of the hash table. The software executable code, hash table, and electronic signature value can be input and stored in advance into the serial flash memory 111 from the outside.

When the software executable code stored in the serial flash memory 111 is executed in XIP mode, it takes a lot of time to verify the integrity of the software executable code due to the low read performance of the serial flash memory 111. To prevent this problem, in an embodiment of the present invention, the software execution code is divided into a plurality of blocks and integrity verification is performed on a block-by-block basis. Accordingly, the software executable code is divided into a plurality of blocks, and the size of the blocks may be the same or different.

The hash table includes hash values derived through a hash operation for a plurality of blocks divided from the software execution code. At this time, hash values corresponding to the order of the plurality of partition blocks constituting the software execution code may be sequentially configured into a hash table.

The digital signature value is created using the hash value calculated on the hash table.

Referring to FIG. 3, the HSM 130 loads the hash table and electronic signature value from the serial flash memory 111.

The HSM 130 calculates a hash value for the loaded hash table. The HSM 130 verifies the loaded electronic signature value based on the calculated hash value and public key. At this time, the public key is stored in a separate memory that only the HSM 130 can access.

Additionally, the HSM 130 divides the software execution code stored in the serial flash memory 111 and calculates hash values for the divided blocks.

The hash value operation of the HSM 130 can use a known hash algorithm, for example, the SHA (Secure Hash Algorithm) algorithm. However, it is not limited to this hash algorithm. The hash value calculation algorithm of the HSM 130 is the same as the hash algorithm used for hash values stored in the serial flash memory 111.

The HSM 130 performs integrity verification by comparing the calculated hash values with hash values stored in the hash table to determine whether they match.

At this time, since the split blocks are arranged in a row, the HSM 130 compares the hash values in the listed order.

If the hash value of the first block does not match the hash value of the first block of the hash table, the HSM 130 determines that the integrity verification has failed and reboots the MCU 110.

If the hash value of the first block matches the hash value of the first block of the hash table, the HSM 130 performs integrity verification on the next block. In this way, if a block with an inconsistent hash value occurs while performing integrity verification on a block-by-block basis, it is determined that the integrity verification has failed, and the MCU 110 is rebooted.

Figure 4 is a flowchart showing a software integrity verification operation according to an embodiment.

Referring to FIG. 4, when booted, the MCU 110 loads and executes the software execution code from the serial flash memory 111 (S101).

The MCU 110 transmits a verification request to the HSM 130 (S102). Accordingly, the HSM 130 performs an integrity verification operation on the software executable code simultaneously with the execution of the software executable code of the MCU 110.

The HSM 130 loads the hash table stored in the serial flash memory 111 into the internal memory of the HSM 130 (S103) and calculates a hash value for the hash table (S104). Hash operation speed is proportional to the size of the input data. Since the size of the hash table is very small compared to the size of the software execution code, the integrity verification speed can be accelerated by calculating the hash of the hash table.

Additionally, whenever the chip including the MCU 110 and the HSM 130 boots, the MCU 110 executes software execution code such as an OS without verification. Therefore, passing any value from the OS to the HSM 130 is unreliable. For example, if someone manipulates the OS, no value can be transmitted to the HSM 130. Therefore, since the process of verifying the OS must proceed independently of the MCU 110, the HSM 130 reads the hash table directly from the serial flash memory 111.

The HSM 130 uses the hash value of the hash table calculated in S104 and the public key stored in advance to determine whether root hash verification, which verifies the electronic signature value loaded from the serial flash memory 111, is successful (S105) ).

If it is determined that the root hash verification is successful in S105, the HSM 130 divides the software execution code of the serial flash memory 111 into a plurality of blocks and selects the first block among the divided blocks (S106).

HSM 130 calculates the hash value for the first block (S107). As mentioned earlier, the hash calculation speed is proportional to the size of the input data, so the integrity verification speed can be accelerated by calculating the hash for one block rather than calculating the hash of the entire software execution code as in the past.

The HSM 130 compares the hash value calculated in S107 with the hash value of the first block of the hash table to determine whether they match (S108).

If there is a match in S108, the HSM 130 determines whether the block for which the hash value was calculated in S107 is the last block (S109), and if it is not the last block, selects the next block (S110). Then, the HSM 130 repeats steps S107 to S109 for the block selected (S110).

If it is determined to be the last block in S109, the HSM 130 determines that the integrity verification for all blocks has been successfully processed and completes the verification (S111).

On the other hand, if it is determined that the root hash verification has failed in S105 or the hash value verification has failed in S108, the HSM 130 determines that the integrity verification has failed and reboots the system (S112). That is, the HSM 130 may reboot the MCU 110 by sending a reboot command to the MCU 110.

As such, according to an embodiment of the present invention, the MCU 110 executes software execution code such as an OS (Operating System) without verification, and forms a trust chain from HSM 130 → hash table → software execution code. . Errors can be discovered as quickly as possible by verifying them in block units using a hash table rather than directly verifying the software execution code in the HSM 130. Conventionally, since the verification procedure is performed on the entire software execution code, there is a problem that verification of the entire software takes a long time even if there is an error in the first block. However, this problem can be solved in the embodiment of the present invention.

Additionally, conventionally, a trust chain is formed from ROM → OS (Operating System) Loader → OS. This trust chain refers to a chain that verifies the OS Loader in the ROM and verifies the OS in the OS Loader. However, when serial flash memory is used, the read performance of the serial flash is low, resulting in longer booting times. In contrast, in the embodiment of the present invention, the hash table is verified through the trust chain of HSM -> hash table -> OS. Also, if the OS is verified using a single hash, the verification time is long due to the performance of flash memory, so verification is performed in block units. Accordingly, the MCU 110 executes software executable code (e.g., OS) without a trust chain, but the HSM 130 may instead form a trust chain to verify the software executable code.

Additionally, the hash operation speed is proportional to the size of the input data.

Computing and verifying hashes for the entire software executable code takes a lot of time. The size of the hash table is very small compared to the software executable code. Therefore, the time to calculate the hash is short. For example, if the software size is 10240 kilobytes (Kbyte), SHA256 is used as the hash algorithm, and the block size is 8 Kbyte, the size of the hash table is 40KByte = (10240 KByte / 8 KByte) × 32Byte. At this time, the hash size of SHA256 is 32 Bytes. Therefore, in order to detect an error in the first block, the prior art needs to calculate a hash for 10240 KBytes, but according to the embodiment of the present invention, to verify the integrity of the first block, calculating a hash of 48KB (=40KB+8KB) Therefore, errors in software execution code can be quickly discovered and responded to.

The embodiments of the present invention described above are not only implemented through devices and methods, but can also be implemented through programs that implement functions corresponding to the configurations of the embodiments of the present invention or recording media on which the programs are recorded.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements made by those skilled in the art using the basic concept of the present invention defined in the following claims are also possible. It falls within the scope of rights.

Claims (10)

A method for a hardware security module to verify the integrity of software, comprising:
The software is,
It is executed in XIP (eXecute-In-Place) mode on serial flash memory in an unverified state by an MCU (microcontroller unit), and at the same time, an integrity verification operation is performed by the hardware security module,
The integrity verification operation is,
When the software stored in the serial flash memory is executed in XIP mode, directly reading a hash table storing hash values for the software from the serial flash memory and loading it into the internal memory of the hardware security module,
Comparing the hash value calculated for the hash table and the hash value for the hash table stored in the serial flash memory, and if there is a discrepancy, rebooting the system;
Dividing the software into a plurality of blocks and calculating hash values for each divided block,
In order of split blocks, comparing the hash value calculated for each split block with the hash value of the corresponding split block stored in the hash table to determine whether there is a match;
If the hash values of the split blocks match, terminating the integrity verification, and
If the hash values of the split blocks do not match, rebooting the system,
If the hash values of the split blocks do not match, the step of rebooting the system is,
While determining whether the hash values match in the order of the split blocks, if one split block determined to have a hash value mismatch occurs, an integrity verification method that immediately reboots the system without comparing the hash values in the next order. delete In paragraph 1:
The step of comparing the hash values calculated for the hash table and if there is a mismatch, rebooting the system,
Calculating an electronic signature value based on the hash value calculated for the hash table,
Reading an electronic signature value generated based on a hash value of a hash table from the serial flash memory, and
Comparing the calculated electronic signature value with the read electronic signature value, determining that integrity verification has failed if there is a discrepancy, and rebooting the system.
Integrity verification method including. delete A serial flash memory that stores a hash table containing a software executable code and hash values for a plurality of partition blocks in which the software executable code is divided into a plurality of blocks, and a hash value for the hash table,
An MCU (microcontroller unit) that executes the software execution code in an eXecute-In-Place (XIP) mode of the serial flash memory in an unverified state, and
A hardware security module that performs an integrity verification operation for the software executable code independently of the MCU while simultaneously executing the software executable code of the MCU,
The hardware security module is,
When the software executable code is executed in XIP mode, the hash table is directly read from the serial flash memory and loaded into the internal memory of the hardware security module,
Compare the hash value calculated for the hash table with the hash value for the hash table stored in the serial flash memory, and if there is a discrepancy, reboot the system,
The software execution code is divided into a plurality of pieces, and the hash value calculated for the hash value of the split block in the order of the split blocks is compared with the hash value of the corresponding split block stored in the hash table. If there is a mismatch, the system is rebooted,
While determining whether the hash values match in the order of the split blocks, if one split block that is determined to have a hash value mismatch occurs, the system is immediately rebooted without comparing the hash values in the next order.
An integrity verification device that compares hash values calculated for all split blocks with corresponding hash values stored in the hash table and terminates integrity verification if they match. In paragraph 5,
The hardware security module is,
Generating an electronic signature value for the hash table and reading the electronic signature value stored in the serial flash memory,
An integrity verification device that reboots the system if the generated electronic signature value and the read electronic signature value do not match, and performs hash value verification in units of the divided blocks if they match. In paragraph 6:
The hardware security module is,
An integrity verification device that directly accesses the serial flash memory and reads the hash table and electronic signature value stored in the serial flash memory. In paragraph 6:
The electronic signature value is,
An integrity verification device generated based on a hash value for the hash table. delete delete

Images