KR102545102B1 - In-vehicle controller and method for performing update therof - Google Patents

Abstract

The present invention relates to a vehicle controller and an update method thereof, and more particularly, to a controller capable of wireless update in a state in which a security technology for securing integrity is applied and an update method thereof. A secure booting method of a controller including a hardware security module according to an embodiment of the present invention includes storing a first message authentication code generated based on a host application in a first memory area and then performing a first reset; injecting the first message authentication code of the first memory area into a second memory area storing a host application; generating a second message authentication code based on the first application data into which the first message authentication code is injected, storing the second message authentication code in a third memory area, and performing a second reset; When a third message authentication code is generated based on the first application data into which the first message authentication code is injected, a first comparison is performed between the third message authentication code and the second message authentication code stored in the third memory area. and performing a second comparison between the first message authentication code injected into the second memory area and the first message authentication code in the first memory area; and booting the hosting system when the result of the first comparison and the result of the second comparison are identical.

Description

Vehicle controller and its update method {IN-VEHICLE CONTROLLER AND METHOD FOR PERFORMING UPDATE THEROF}

The present invention relates to a vehicle controller and an update method thereof, and more particularly, to a controller capable of wireless update in a state in which a security technology for securing integrity is applied and an update method thereof.

In general, a hardware security module (HSM) refers to a cryptographic processor specially designed for protection of the life cycle of cryptographic keys, and performs cryptographic processing, key protection, and key management within a hardened anti-counterfeiting device. An HSM used in a vehicle controller domain generally includes a secure memory that can safely store keys. For example, the secure memory includes RAM or ROM dedicated to the HSM with high security, separate from the host system (i.e., the application), and the HSM performs a series of operations through a dedicated central processing unit (CPU) to prevent potential attackers from attacking. function can be performed relatively safely.

In particular, the HSM provides a secure booting function of the controller. Secure boot is a function that verifies the integrity of the firmware of the controller when booting through HSM. Specifically, during booting, the HSM verifies the integrity of the host bootloader, and transfers control to the host bootloader only when the integrity verification passes. Therefore, the booting process of the host can proceed normally only when the integrity of the bootloader is verified.

Hereinafter, a booting process of a host using a general HSM will be described with reference to FIGS. 1, 2 and Table 1.

1 shows an example of a memory configuration of a controller with a general HSM, and FIG. 2 shows an example of a booting procedure of a controller with a general HSM. Table 1 also shows settings of the memory configuration shown in FIG.

First, referring to FIG. 1 , a controller having an HSM may include at least a host memory 10 and an HSM memory 20 . Here, the host memory 10 may store a secure boot enable 11 indicating whether secure booting using HSM is set, and a host application program and data 13 storing an application for driving a controller and related data. there is. In addition, the HSM memory 20 may store a secure boot flag (Secure Boot Flag, 21), a first message authentication code (1st_MAC, 23), and an instant message authentication code (Instant_MAC, 25).

Data stored in the respective memories 10 and 20 may be divided into different memory addresses, and an area to store at least some of the data in each memory 10 and 20 may be set in advance.

Table 1 below shows an example of a format in which areas to be stored for each data stored in the memories 10 and 20, updates, and accessibility are set.

data division

saved
Memory
area
cable
reprogramming
wireless
reprogramming
(by OTA)
to the HOST program
by
memory access to the HSM program
memory access by By Generic Debugger By Security Debugger Read Write Read Write Secure Boot Enable HOST NVM Write impossible Write
not possible Write impossible possible not possible not possible not possible Secure Boot Flag HSM NVM Write impossible Write
possible

Write impossible not possible not possible possible possible Host Application HOST NVM Writeable Writeable possible possible possible possible 1st_MAC HSM NVM Write impossible Write impossible not possible not possible possible possible Instant_MAC HSM VMs - - - not possible not possible possible possible

In Table 1, NVM means non-volatile memory, VM means volatile memory, respectively, and a secure debugger means a debugger with secured security, which will be described later. Hereinafter, each data will be described in detail.

Referring to Table 1, Secure Boot Enable can be set to 0 or 1. If set to 0, the secure boot process to be described later with reference to FIG. 2 is not performed in the corresponding controller. A secure boot process may be performed. Once the secure boot setting is set to ‘1’, data value change (Writing) from ‘1’ to ‘0’ is absolutely not allowed in any path.

The secure boot flag is a flag for checking whether or not a first message authentication code (1st_MAC) has been generated at first booting for message authentication code (MAC) comparison. This flag has data integrity by blocking reading/writing through a general path such as a general debugger or over-the-air (OTA) update.

The host application may refer to a general application data area capable of reading/writing by accessing through an arbitrary path.

The first message authentication code refers to an encryption authentication code that is generated (output) through a host application program and a unique encryption algorithm stored in the HSM using, as inputs, a unique key value stored in the HSM.

The instant message authentication code refers to a message authentication code generated through application data loaded in a boot after the first message authentication code is generated during initial booting. It is used to determine the integrity of application data through

Hereinafter, a secure booting process will be described with reference to FIG. 2 based on the data and memory settings for each data described above with reference to FIG. 1 and Table 1. In FIG. 2, it is assumed that the secure boot setting is set to '1'.

Referring to FIG. 2 , since the secure boot setting is set to '1', the secure boot procedure starts. First, it may be determined whether a first boot flag is set in the HSM memory (S210). When the first boot flag is set to '0', it indicates that the secure boot procedure is performed for the first time, and when set to '1', it means that it is not the first boot.

When the initial boot flag is set to '0', the HSM generates a first message authentication code using the host application program in the host memory and the unique key value stored in the HSM (S220).

The generated first message authentication code may be stored in a secure area of the HSM memory (S230).

As the first message authentication code is generated and stored, the first boot flag is set to '1' (S240), and the system is reset (S280A).

The secure boot procedure is initiated again by system reset, but since the 1st Boot Flag in the HSM memory is set to '1' (no in S210), the HSM uses the host application program in the host memory and the unique key value stored in the HSM. An instant message authentication code is generated using (S250).

The HSM compares the instant message authentication code with the first message authentication code stored in the security area to determine whether or not they are identical (S260).

If the result of the determination is the same, it is considered that there is no abnormality in the integrity of the application data, and the host system is normally booted (S280B).

If integrity is not secured even after repeating instant message authentication code generation and comparison a preset number of times, the HSM resets the host system (S280C).

The secure booting process described with reference to FIG. 2 will be described in terms of memory change with reference to FIGS. 3 to 5 .

3 to 5 show examples of memory states in a general secure booting process.

Referring first to FIG. 3 , a memory state of the controller 100 to which a general HSM function is applied is shown. The memory of the controller 100 shown in FIG. 3 includes an application 13, an initial boot flag 31, an instant application 33 in which the application 13 is loaded during booting, an instant message authentication code (MAC) 25, It may include an area where each of the first message authentication codes 23 is stored.

First, as the memory of the controller 100 initiates a secure booting process in a state where the first boot flag is 0 as shown in the top of FIG. 3, the application 13 is loaded as an instant application 33 as shown in the interruption of FIG. Based on the 33, the first MAC 23 may be generated and stored. Also, the initial boot flag 31 is set to 1 and the host system is reset.

After reset, when rebooting, as shown in the lower part of FIG. If the MAC 23 is the same, the secure booting process is normally completed.

If, after the first boot (ie, the first boot flag = 1), the application of the host system is tampered with without permission (strange), the instant MAC 25 created based on the loaded instant application 33 as shown in FIG. Since it will not be the same as the first MAC 23, booting is aborted.

Thus, the integrity of the application can be guaranteed.

However, due to the increasing application of future mobility in the future, it is expected that the demand for updating applications through over-the-air (OTA) will increase significantly after mass production. However, it is difficult to apply the OTA method update to the HSM-applied controller. This problem will be described with reference to FIG. 5 .

Even if the application of the host system is normally updated (New) after the first boot (ie, the first boot flag = 1), the first boot flag 31 is not reset to 0. Because of the 1 MAC 23, since the instant MAC 25 generated based on the loaded instant application 33 as shown in FIG. 5 will not be the same as the first MAC 23, booting is stopped.

As described above with reference to Table 1, the initial boot flag cannot be reset without using a security-secured debugger, for example, a JTAG debugger (Joint Test Action Group (JTAG) device).

After all, since the A/S center is generally the only place where the JTAG debugger can be accessed after the controller is produced, even if the wireless update is successfully completed, the driver must visit the A/S center in order for the updated application of the controller to operate normally. It is inconvenient to visit.

An object of the present invention is to provide a controller for a vehicle capable of wireless update while maintaining security and a control method thereof.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

In order to solve the above problems, a method for secure booting of a controller including a hardware security module according to an embodiment of the present invention includes storing a first message authentication code generated based on a host application in a first memory area, and then storing a first message authentication code in a first memory area. Step 1 being reset; injecting the first message authentication code of the first memory area into a second memory area storing a host application; generating a second message authentication code based on the first application data into which the first message authentication code is injected, storing the second message authentication code in a third memory area, and performing a second reset; When a third message authentication code is generated based on the first application data into which the first message authentication code is injected, a first comparison is performed between the third message authentication code and the second message authentication code stored in the third memory area. and performing a second comparison between the first message authentication code injected into the second memory area and the first message authentication code in the first memory area; and booting the hosting system when the result of the first comparison and the result of the second comparison are identical.

In addition, a vehicle controller according to an embodiment of the present invention includes a first memory for storing at least a host application; and a hardware security module (HSM) including a second memory that cannot be accessed by the host application, wherein the hardware security module generates a first message authentication code based on the host application to determine the location of the second memory. After storing in the first area, the host system is first reset, and the first message authentication code of the first memory area is injected into the second area of the first memory where the host application is stored. A second message authentication code is generated based on the first application data into which the authentication code has been injected, stored in a third area of the second memory, and then reset, and the second message authentication code into which the first message authentication code is injected. 1 A third message authentication code is generated based on application data, a first comparison is made between the third message authentication code and the second message authentication code stored in the third area, and the first message authentication code injected into the second area is compared. A second comparison is performed between the message authentication code and the first message authentication code of the first area, and when the results of the first comparison and the second comparison are identical, the hosting system may be booted.

According to at least one embodiment of the present invention, there are the following effects.

Both security and update convenience can be provided in an in-vehicle network.

In particular, according to the present invention, even if a wireless update is performed in a controller to which a hardware security module is applied, integrity verification of a normally updated application can be performed without visiting a service center.

The effects that can be obtained in the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the description below. will be.

1 shows an example of a memory configuration of a controller with a general HSM.
2 is a flowchart illustrating an example of a booting procedure of a controller having a general HSM.
3 to 5 show examples of memory states in a general secure booting process.
6 shows an example of a memory structure of a controller to which a hardware security module according to an embodiment of the present invention is applied.
7A and 7B are flowcharts illustrating an example of a secure booting process according to an embodiment of the present invention.
8 to 17 are views for explaining how the memory state of the controller is changed when the processes shown in FIGS. 7A and 7B are performed.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the accompanying drawings, but the same or similar elements are given the same reference numerals regardless of reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "unit" for components used in the following description are given or used together in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves.

In addition, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiment disclosed in this specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in this specification, the technical idea disclosed in this specification is not limited by the accompanying drawings, and all changes included in the spirit and technical scope of the present invention , it should be understood to include equivalents or substitutes.

According to an embodiment of the present invention, in a controller to which a hardware security module (HSM) is applied, two boot flags and two message authentication codes are stored in a security area so that the integrity of an updated application can be verified without a separate debugger connection. However, it is suggested to inject the message authentication code into the application in the host memory as well. A memory structure for this will be described with reference to FIG. 6 and Table 2.

6 shows an example of a memory structure of a controller to which a hardware security module according to an embodiment of the present invention is applied, and Table 2 shows memory configuration settings according to an embodiment.

First, referring to FIG. 6 , a controller having an HSM may include at least a host memory 210 and an HSM memory 220 . Here, the host memory 210 may store a secure boot enable 211 indicating whether secure booting using HSM is set, and a host application program and data 213 that stores an application for driving a controller and related data. there is. In addition, the host memory 210 includes an area 215 into which a message authentication code (ie, injection MAC) can be injected together with the host application program and data 213, and when the host application program is updated, the host application program and data 213 are installed before the update. An area 217 capable of backing up host application programs and data may be further prepared.

Meanwhile, the HSM memory 220 may store a secure boot flag (Secure Boot Flag, 221), a first message authentication code (1st_MAC, 223), and an instant message authentication code (Instant_MAC, 225). In addition, the HSM memory 220 includes a MAC injection flag (MAC_Injection_Flag, 227) indicating whether a message authentication code has been injected into the host memory 210, a second secure boot flag 226, and a second message authentication code 228 can store more.

Data stored in the respective memories 210 and 220 may be divided into different memory addresses, and an area to store at least some of the data in each memory 210 and 220 may be set in advance.

Table 2 below shows an example of a format in which areas to be stored for each data stored in the memories 210 and 220, updates, and accessibility are set.

data division saved
Memory
area cable
reprogramming wireless
reprogramming by HOST program
memory access by the HSM program
memory access reference By general
debugger By Security Debugger Read Write Read Write Secure Boot Enable HOST NVM Write
not allowed Write
not allowed Write
not possible possible not possible not possible not possible Table 1 and
same Secure Boot Flag HSM NVM Write
not allowed Write
possible Write
not allowed not possible not possible possible possible Host Application HOST NVM Write
possible Write
possible possible possible possible possible 1st_MAC HSM NVM Write
not allowed Write
not possible not possible not possible possible possible Instant_MAC HSM VMs - - - not possible not possible possible possible Injected_MAC HOST NVM Write
possible Write
possible Write
possible possible possible possible possible copy
Example Host Application HOST NVM Write
possible Write
possible Write
possible possible possible possible possible Back up 2nd Secure Boot Flag HSM NVM Write
not allowed Write
possible Write
not allowed not possible not possible possible possible MAC_Injection
_Flag HSM NVM Write
not allowed Write
possible Write
not allowed not possible not possible possible possible 2nd_MAC HSM NVM Write
not allowed Write
possible Write
not allowed not possible not possible possible possible

In Table 2, descriptions of the secure boot configuration, secure boot block, host application, first MAC, and instant MAC are the same as in Table 1, and thus are omitted.

An injected MAC (Injected_MAC, 215) is a memory area for inserting the MAC generated by the HSM into the host application area 213. At this time, it is preferable that the HOST and the HSM recognize the same memory address for the area 215 where the injected MAC is stored. In addition, the host should not record the application data in the corresponding area 215 but reserve it, and the HSM may inject (write) the generated MAC into the corresponding area.

The host application back up area 217 may be a general application data area that can be read/written by accessing an arbitrary path. However, when reprogramming an application safely by a normal user, the normal user must store the application of the previous version (Legacy) in this area along with the application of the new version. Here, being able to store an application of a previous version in the host application backup area 217 means that the application itself has been accessed by a normal user. In this embodiment, the application of a previous version stored in the corresponding area 217 is stored in the HSM It is subject to verification of integrity by In addition, HOST and HSM must recognize the same memory address for this area 217.

The 2nd Secure Boot Flag (or 2nd Boot Flag) indicates whether a 2nd MAC was generated based on MAC-injected application data (ie, 213 and 215), and during normal operation, 2nd booting Since the second MAC is generated in , it may be regarded as indicating whether or not the second booting has been performed. This data has data integrity by blocking Read/Write through a general path such as a general debugger or OTA.

The MAC Injection Flag indicates whether a first MAC is injected into application data. The application into which the first MAC is injected undergoes a process of generating the second MAC, and whether or not the first MAC has been successfully injected is verified once again.

The second message authentication code (or second MAC, 2nd_MAC) refers to a MAC regenerated for the application into which the first MAC is injected, and can be used to verify whether the application is updated.

Hereinafter, a secure boot process according to the present embodiment will be described with reference to FIGS. 7A to 17 . 7A and 7B are flowcharts illustrating an example of a secure booting process according to an embodiment of the present invention. In Figures 7a and 7b, one flow chart is shown separately. Also, FIGS. 8 to 17 are diagrams for explaining how the memory state of the controller is changed when the processes shown in FIGS. 7A and 7B are performed.

First, a process before reprogramming occurs in FIG. 7A will be described with reference to FIG. 8 .

Referring first to the top of FIG. 8 , the memory of the controller 200 according to the embodiment includes a host application area 213, a MAC injection area 215, a host application backup area 217, an initial boot flag 231, a second 2 may include a boot flag 226, an instant application area 233, an instant MAC area 225, a second MAC area 228, a first MAC area 223 and a MAC injection flag 227. Unless otherwise noted, the memory of the controller 200 shown in FIGS. 9 to 17 has the same configuration as in FIG. 8 .

In the following description, it is assumed that the secure boot setting is set to '1'.

First, since the secure boot setting is set to '1', the secure boot process starts. First, it is determined whether the first boot flag 231, the second boot flag 226, and the MAC injection flag 227 in the HSM memory are all 0 (S701). Since all flags are 0 as shown in the upper part of FIG. 8 , the HSM generates a first MAC using the unique key value stored in the host application HSM loaded in the instant application area 233 as shown in the lower part of FIG. 8 (S702).

The generated first MAC may be stored in the first MAC area 223 (S703).

As the first MAC is generated and stored, the initial boot flag 231 is set to '1' (S704), and the system is reset (S705).

Next, the following process will be described with reference to FIGS. 7A and 9 together.

Since the secure boot procedure is initiated again by system reset, it is determined whether the initial boot flag 231, the second boot flag 226, and the MAC injection flag 227 are all 0 in the HSM memory (S701), and Since the first boot flag 231 is set to '1' (no), only the first boot flag 231 among the first boot flag 231, the second boot flag 226, and the MAC injection flag 227 is stored in the HSM memory. 1 is determined (S711).

Since the initial boot flag 231 is set to '1' in the HSM memory (yes), the HSM injects the first MAC into the injection MAC area 215 (S712).

The injected first MAC is loaded into the instant MAC area 225 again (S713), and the first MAC loaded into the instant MAC area 225 is compared with the MAC stored in the first MAC area 223 (S714). In the same case, it is determined that the first MAC is normally injected, and the MAC injection flag 227 is set to 1. If the result of the comparison (S714) is not the same, steps S712 to S714 are repeated a preset number of times (S716), and if the preset number is exceeded, it is determined that the injection of the first MAC has failed and the host system boots It is limited (S717).

Next, the next process will be described with reference to FIGS. 7A and 10 together.

If the injection of the first MAC is successful, that is, after the MAC injection flag is set to 1 (S715), the HSM selects the first boot flag 231, the second boot flag 226, and the second boot flag among the MAC injection flags 227. It is determined whether only (226) is 0 (S721).

When only the second boot flag 226 is 0, the HSM generates a second MAC based on the host application into which the first MAC loaded in the instant application area 223 is injected (S722), and generates the second MAC area (S722). 228) (S723). Thereafter, the HSM sets the second boot flag 226 to 1 (S724) and resets the host system (S725).

When the host system is reset, the initial boot flag 231, the second boot flag 226, and the MAC injection flag 227 are all set to 1, so the process proceeds to step S731 of FIG. 7B through steps S701, S711, and S721. do.

Hereinafter, a subsequent process will be described with reference to FIGS. 7B and 11 together.

First, the HSM determines whether all of the initial boot flag 231, the second boot flag 226, and the MAC injection flag 227 are 1 (S731). If all flags are 1, the HSM may generate an instant MAC 225 based on the host application loaded with the first MAC loaded into the instant application area 223 (S732).

The HSM determines the identity of the injected MAC 215 and the first MAC 223 and the identity of the second MAC 223 and the generated instant MAC 225 (S733), and if they are identical, the integrity of the host application is Considering that it has been verified, the host system is normally booted (S735).

If all of the flags are not 1 in step S731, the HSM determines that the situation is abnormal and may restrict booting of the host system (S741).

Next, a secure booting process when an application of the host system is updated will be described with reference to FIGS. 7B and 12 to 15 together. 12 to 15 , it is assumed that the update is completed through the normal path of the host application regardless of the update method.

First, referring to FIG. 7B and FIG. 12 together, according to the update of the host application, updated (NeW) application data is stored in the host application area 213, and previously installed (legacy) data is stored in the backup application area 217. Application data may be stored. In addition, the injected MAC area 215 is emptied due to updates.

When booting starts, since all flags are 1, an instant MAC 225 is created using the application data loaded in the instant application area 233 in step S731 (S732).

However, since the injection MAC area 215 is empty in step S733, the comparison result with the first MAC 223 is different, and the second MAC 228 is also generated based on the application data of the previous version and the injected MAC. Therefore, it is different from the updated data-based MAC of the instant MAC area 225 (ie, no in step S733).

The following process will be described with reference to FIG. 7B and FIGS. 13 and 14 together.

If integrity verification fails (no in S734) even after the instant MAC generation and comparison process is repeated a set number of times, as shown in FIG. 13, the HSM uses the legacy application stored in the backup application area 217. A MAC 225 is generated based on the program (S751) and compared with the stored first MAC 223 (S752). As described above, it is assumed that the fact that application data of a previous version is stored in the backup application area 217 means an update by a normal user.

If the comparison result is the same, as shown in FIG. 14, the HSM may set all of the first boot flag 231, the second boot flag 226, and the MAC injection flag 227 to 0 (S755). In addition, the HSM may also delete the data of the backup application area 217 (S756), and may also delete the first MAC 223 and the second MAC 228 (S757). After that, the host system may be reset (S758).

The following process will be described with reference to FIGS. 7A and 15 together.

According to the reset of the host system, the process of S701 of FIG. 7A may be started again. However, since all flags were previously set to 0 (S755), the HSM performs steps S702 to S705 again. Accordingly, as shown in FIG. 15 , an updated application may be loaded into the instant application area 233 to generate and store a first MAC, and the initial boot flag 231 is set to 1. Subsequent processes are the same as those described above based on the legacy version, except that the application data is a new version, so duplicate descriptions will be omitted.

Hereinafter, an HSM operation process when a host application is modulated in an abnormal manner will be described with reference to FIG. 7A and FIGS. 16 and 17 together.

First, referring to FIG. 7B and FIG. 16 together, as the host application is modulated through an abnormal process, the host application area 213 may store strange application data. In addition, the injection MAC area 215 and the backup application area 217 may be empty or may be in a state in which abnormal data is recorded.

When booting starts, since all flags are 1, an instant MAC 225 is generated using modulated application data loaded in the instant application area 233 in step S731 (S732).

However, in step S733, since the injection MAC area 215 is empty or abnormal data is recorded, the result of comparison with the first MAC 223 is different, and the second MAC 228 is also injected with the application data of the previous version. Since it is generated based on the MAC, it is different from the MAC based on the modulated data of the instant MAC area 225 (ie, no in step S733).

The following process will be described with reference to FIGS. 7B and 17 together.

If integrity verification fails even after repeating the instant MAC generation and comparison process a preset number of times (no in S734), as shown in FIG. A MAC 225 is generated based on (S751) and compared with the stored first MAC 223 (S752).

Since the comparison result will be different, the HSM may perform steps S751 and S752 as many times as the preset number (S753), and may limit booting of the host system if the preset number of retries is exceeded (S754).

When the controller according to the embodiment described so far is applied, even if an application update occurs after mass production, a normal secure booting procedure can be performed without a specific type of secure wired connection such as a JTAG debugger. Therefore, from the customer's point of view, there is an advantage in that a new application can be used immediately without visiting a service center even when a wireless update is performed.

The above-described present invention can be implemented as computer readable code on a medium on which a program is recorded. The computer-readable medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include Hard Disk Drive (HDD), Solid State Disk (SSD), Silicon Disk Drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. there is

Accordingly, the above detailed description should not be construed as limiting in all respects and should be considered illustrative. The scope of the present invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present invention are included in the scope of the present invention.

Claims (19)

A method for secure booting of a controller including a hardware security module,
first resetting a first message authentication code generated based on a host application after being stored in a first memory area;
injecting the first message authentication code of the first memory area into a second memory area storing a host application;
generating a second message authentication code based on the host application of the second memory area into which the first message authentication code is injected, storing the second message authentication code in a third memory area, and performing a second reset;
generating a third message authentication code based on the host application of the second memory area into which the first message authentication code is injected;
The third message authentication code and the second message authentication code stored in the third memory area are first compared, and the first message authentication code injected into the second memory area and the first message authentication code stored in the first memory area are compared. a second comparison of message authentication codes; and
booting the host system when the result of the first comparison and the result of the second comparison are identical;
setting a first flag indicating whether to boot for the first time or whether to generate the first message authentication code before the first reset is performed;
setting a second flag indicating whether the second message authentication code is generated before the second reset is performed;
performing a third comparison between the first message authentication code stored in the first memory area and the injected first message authentication code after the injection; and
Setting a third flag indicating that message authentication code injection is successful if the result of the third comparison is the same.
Including more,
A secure boot method for a controller that includes a hardware security module. delete delete delete According to claim 1,
The first comparing step and the second comparing step,
The secure booting method of a controller including a hardware security module, which is performed when all of the first flag, the second flag, and the third flag are set during booting. According to claim 1,
Generating a fourth message authentication code based on data stored in a fourth memory area where a host application of a previous version is backed up when the update succeeds, when at least one of the first comparison result and the second comparison result is different. ; and
The secure booting method of a controller including a hardware security module, further comprising a fourth comparison step of the fourth message authentication code and the first message authentication code stored in the first memory area. According to claim 6,
setting the first flag, the second flag, and the third flag to 0 if they are the same as a result of the fourth comparison; and
The secure booting method of a controller including a hardware security module, further comprising erasing data in the fourth memory area, the first memory area, and the third memory area. According to claim 6,
The secure booting method of a controller including a hardware security module, further comprising limiting booting of the host system if the result of the fourth comparison is different. According to claim 1,
In the first resetting step,
The secure booting method of a controller including a hardware security module, which is performed when all of the first flag, the second flag, and the third flag are 0 during booting. A computer readable recording medium recording a program for executing a secure booting method of a controller including the hardware security module according to any one of claims 1 and 5 to 9. In the vehicle controller,
a first memory storing at least a host application; and
A hardware security module (HSM) including a second memory inaccessible by the host application,
The hardware security module,
After generating a first message authentication code based on the host application and storing it in a first area of the second memory, performing a first reset of the host system;
injecting the first message authentication code of the first memory area into a second area of the first memory where the host application is stored;
A second message authentication code is generated based on the host application of the second area into which the first message authentication code is injected, the second message authentication code is stored in the third area of the second memory, and then the second message authentication code is stored in the second area. reset,
A third message authentication code is generated based on the host application in the second memory area into which the first message authentication code is injected, and the third message authentication code and the second message authentication code stored in the third area are generated. performing a first comparison, and performing a second comparison between the first message authentication code injected into the second area and the first message authentication code in the first area;
Booting the host system when the result of the first comparison and the result of the second comparison are identical;
Setting a first flag indicating whether to boot for the first time or whether to generate the first message authentication code before performing the first reset;
Setting a second flag indicating whether the second message authentication code is generated before the second reset is performed;
After injecting the first message authentication code, performing a third comparison between the first message authentication code stored in the first area and the injected first message authentication code;
Setting a third flag indicating that message authentication code injection succeeds when the result of the third comparison is the same.
vehicle controller. delete delete delete According to claim 11,
The hardware security module,
A vehicle controller that performs the first comparison and the second comparison when all of the first flag, the second flag, and the third flag are set upon booting. According to claim 11,
The hardware security module,
If at least one of the result of the first comparison and the result of the second comparison is different, a fourth message authentication code based on data stored in a fourth area in the first memory where the host application of the previous version is backed up when the update is successful. create,
and performing a fourth comparison between the fourth message authentication code and the first message authentication code stored in the first area. According to claim 16,
The hardware security module,
If the result of the fourth comparison is the same, the first flag, the second flag, and the third flag are set to 0;
and erasing data of the fourth area, the first area, and the third area. According to claim 16,
The hardware security module,
and limiting booting of the host system when the result of the fourth comparison is different. According to claim 11,
The hardware security module,
and generating the first message authentication code when all of the first flag, the second flag, and the third flag are 0 at booting.

Images