KR102579861B1 - In-vehicle software update system and method for controlling the same - Google Patents

Abstract

The present invention relates to a software update device for a vehicle that has fast booting time while improving security and a method of controlling the same. The control method of a vehicle software update system according to an embodiment of the present invention includes first software that provides switching and communication functions with at least a second area as the first bootloader is executed in the first area, a first operating system, and performing a first integrity verification of at least one second software related to the security service; booting a second operating system without integrity verification as a second boot loader is executed in the second area; requesting a security service for software to be verified in the first area from the second area; and performing a second integrity verification on the software to be verified in the first area according to the request. Here, the first area corresponds to the first mode, the second area corresponds to the second mode, and the central processing unit of the vehicle software update system simultaneously performs one of the first mode and the second mode. Only the mode of is executed, and the first area and the second area may have at least a portion of an independent hardware configuration within the central processing unit.

Description

Vehicle software update device and control method thereof {IN-VEHICLE SOFTWARE UPDATE SYSTEM AND METHOD FOR CONTROLLING THE SAME}

The present invention relates to a software update device for a vehicle that has fast booting time while improving security and a method of controlling the same.

In general, software integrity means ensuring that existing programs received from trusted distributors or injected into the system have not been modified by unauthorized users or bugs. If integrity is not guaranteed, malicious users such as hackers may modify programs by exploiting software vulnerabilities, resulting in programs such as malware or backdoors being installed in the system.

Therefore, systems such as vehicles, which can threaten the safety of not only the occupants but also the surroundings if the program is modified, require a high level of security, so it is desirable to perform an integrity check before executing the software to check for software forgery.

For example, there have been cases overseas where hackers who gained control of the AVN (Audio/Video/Navigation) system installed in some SUV vehicles changed the firmware of the microprocessor (MICOM) to send CAN messages that were not previously promised. there was. This case could have been prevented if MICOM had checked the integrity when loading firmware, as it would not have been possible to load firmware that had been modified by a hacker.

Hereinafter, a process in which a general software integrity check is performed will be described with reference to FIG. 1. Figure 1 shows an example of a process in which a software integrity check is performed on a typical vehicle.

Referring to Figure 1, the integrity check process can be largely divided into a product development stage and a post-mass production process.

First, in the product development phase, the software distributor prepares the software binaries whose integrity is to be guaranteed or the system partition containing the software binaries. Afterwards, the hash of the system partition is calculated, and the calculated hash is encrypted with the software distributor's private key. The process from hash calculation to encryption is also called the electronic signature process.

The encrypted hash value can be injected into a vehicle device, such as an AVN system, along with the system partition and public key.

In order to verify the digital signature in the AVN system after mass production, the encrypted hash is decrypted with a public key, and the system partition calculates the hash in the same way that the distributor calculated the hash. The decrypted hash and the calculated hash are compared, and if the comparison results are identical, the digital signature is successfully verified and the system partition can be used.

Therefore, when the above-described electronic signature method is applied, altered software cannot be injected into the system unless an attacker obtains the software distributor's private key.

However, in the electronic signature method, the subject performing the signature verification must perform a hash calculation for the integrity verification target (e.g., the system partition in Figure 1) every time it is booted, and the time required for hash calculation is calculated based on the target binary subject to integrity verification. It is proportional to the size of the partition. Ultimately, the larger the size of the software to be verified, the longer it takes for the integrity check, which deteriorates booting performance.

However, most Linux systems omit the integrity check for the root file system partition. This is because booting time increases significantly if the integrity of the root file system, which is several gigabytes (GB) in size, is checked at each boot. In particular, since an electronic device mounted on a vehicle, such as an AVN system, must complete booting within about 2 seconds, it is common to omit the integrity check for the root file system partition. But this is especially dangerous in recent circumstances.

Specifically, recent vehicles tend to support the OTA (Over-The-Air) function, which performs firmware update or reprogramming by receiving update software wirelessly without going through a diagnostic device. Usually, there is software that performs security-critical functions in the root file system. When security-critical software that can change the contents of the system's root file system is updated through OTA, such software is executed without performing an integrity check. There is a risk of operating in the environment.

The present invention is to provide a software update device for a vehicle and a control method thereof that can perform integrity verification for security-critical software and partitions while providing a fast boot time.

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 technical problem, the control method of the vehicle software update system according to an embodiment of the present invention provides switching and communication functions with at least the second area as the first bootloader is executed in the first area. performing a first integrity verification of at least one second software related to the provided first software, first operating system, and security service; booting a second operating system without integrity verification as a second boot loader is executed in the second area; requesting a security service for software to be verified in the first area from the second area; and performing a second integrity verification on the software to be verified in the first area according to the request. Here, the first area corresponds to the first mode, the second area corresponds to the second mode, and the central processing unit of the vehicle software update system simultaneously performs one of the first mode and the second mode. Only the mode of is executed, and the first area and the second area may have at least a portion of an independent hardware configuration within the central processing unit.

In addition, the vehicle software update system according to an embodiment of the present invention operates in a first mode or a second mode, and includes at least a first area corresponding to the first mode and a second area corresponding to the second mode. A central processing unit, some of which is processed as independent hardware; and a first memory accessible only in the first area and a second memory accessible only in the second area, wherein the central processing unit simultaneously executes only one of the first mode and the second mode, As the first bootloader is executed in the first area, a first integrity verification is performed on at least one second software related to the first software, the first operating system, and the security service that provides switching and communication functions with the second area. And, as the second boot loader is executed in the second area, the second operating system is booted without integrity verification, and when the second area requests a security service for software subject to verification in the first area, the request Accordingly, a second integrity verification of the software to be verified may be performed in the first area.

The vehicle software update system according to at least one embodiment of the present invention configured as described above places the verification target in a safe area and checks integrity when a service request occurs after booting, thereby ensuring a fast booting time.

Additionally, since the integrity verification results are reset using a timer for verification targets whose integrity has already been verified, periodic verification is possible even after the initial verification.

The effects that can be obtained from 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.

Figure 1 shows an example of a process in which a software integrity check is performed on a typical vehicle.
Figure 2 shows an example of a system configuration diagram in which embodiments of the present invention can be performed.
Figure 3 shows an example of a boot chain form of a system according to an embodiment of the present invention.
Figure 4 is a flowchart showing an example of an integrity check process of a lazy authentication safety application according to an embodiment of the present invention.
Figure 5 shows an example of a service identifier integrity check process according to an embodiment of the present invention.

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 many 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. Additionally, parts indicated with the same reference numbers throughout the specification refer to the same components.

In one embodiment of the present invention, one processor is configured to support different hardware-isolated modes, the verification target is placed on the area corresponding to the safe mode among the two modes, and the normal area corresponding to the remaining normal mode is set after booting. It is proposed that integrity verification of the verification target be performed when a service request occurs.

First, the system configuration will be described with reference to FIG. 2. Figure 2 shows an example of a system configuration diagram in which embodiments of the present invention can be performed. In the following description including FIG. 2, it is assumed that the software update system including the update engine is an AVN system, but this is for convenience of explanation and is not necessarily limited thereto.

The system configuration shown in FIG. 2 uses the so-called “ARM TrustZone” to isolate the update engine from the entire system, allowing system updates to be performed safely. ARM TrustZone technology is a technology that allows one CPU to operate in two independent modes, that is, safe mode and normal mode. This means that even if an attacker obtains a root account and uses a rootkit to modify or tamper with the operating system or bootloader, the program to be protected is isolated to an area that even the general operating system cannot access, and when the program is executed in an isolated state, It can be said to be one of the means to keep the process up to this point in a trustworthy state.

In these systems, one CPU core is designed to operate in only one mode at the same time, with safe mode running in the safe area (Secure World, 110) and normal mode running in the normal world (120). .

Specifically, the safety area 110 includes a monitor (111), a trusted operating system (TOS) (112), a secure application (Secure App) (113), and a Lazy Verified Secure App (LVSA) (114). ) may include.

The monitor 111 is software with the highest authority and is responsible for switching to other areas of the CPU core, communication between the two worlds, and interrupt processing. Additionally, the TOS 112 runs in the safety area 110, and the safety application 113 can provide services related to security. For example, the safety application 113 is relatively small in size and may be comprised of services essential to security services such as “encryption key management”. These (111, 112, 113) complete the integrity check at boot time to enable services to be provided after booting. Since the binary size of these (111, 112, 113) is small, even if the integrity is checked at boot time, the boot time is limited. This is because the performance impact can be minimized.

The LVSA 114 is subject to an integrity check, but it may be software that prolongs booting time due to its relatively large capacity, and may not be executed after loading memory at booting time, but rather an integrity check may be performed at runtime. For example, LVSA 114 may be an update binary or partition received via OTA.

The general area 120 can run Linux 121, one of the operating systems commonly referred to as Rich OS, and the framework 122 and untrusted software to perform general functions of the AVN system. (Non Trusted App, 123) can work.

Meanwhile, in order to distinguish between the safe area 110 and the normal area 120, the registers of the CPU may be separated by area. For example, since the registers related to the page table are separated, the address of the table used for virtual address-physical address conversion may be different for each area. This can cause each region to see a different address space. Additionally, a device or memory area 130 that is accessible only in the safe area 110 may be designated. Therefore, if an attempt is made to access the general area 120 in the memory area 130, a page fault may occur. In addition, interrupts are also differentiated, so if the current mode is safe mode, normal mode interrupts may not occur. Of course, the general area 120 can also be prepared with a memory 140 that can be accessed only in that area, and shared access (eMMC, 150) that can be accessed by two area modes can also be supported.

Ultimately, the software update system applicable to the present embodiments may include a central processing unit (CPU) with two different hardware areas to support the two modes, and individual memories for each of the two areas.

Hereinafter, the booting process will be described with reference to FIG. 3. Figure 3 shows an example of a boot chain form of a system according to an embodiment of the present invention.

Referring to FIG. 3, when the power is turned on, a series of software from Loader 1 to the Linux Kernel is loaded into memory after performing an integrity check of the type described above with reference to FIG. 1 before being loaded into memory.

Specifically, the boot loader (Boot Loader 1) of the safe area 110 is executed (S210), and an integrity check based on the hash and electronic signature of the monitor and TOS, which are essential software for the operation of the safe area 110, is performed at boot time. It can be performed sequentially (S220, S230).

Additionally, a non-decision check for a safety application providing services in the safety area 110 may also be performed at booting time (S240).

Afterwards, the boot loader (Boot Loader 2) in the general area 120 is executed (S250), and the Linux kernel can be loaded into memory after integrity check (S260).

On the other hand, at boot time, the LVSA 114 is loaded into the memory of the safe area 110 without an integrity check. In more detail, the LVSA 114 may correspond to a security service performed by an AVN system request in the general area 120 after system booting is completed, such as an OTA update. After booting, when a request for the general area 120 occurs, the integrity of these 114s can be checked by the monitor 111 and TOS 112, which have completed the integrity check in the booting stage before execution.

Additionally, the Linux Root File System (141) used by the Linux kernel does not perform an integrity check not only at boot time but also after it is mounted.

Below, the integrity check process of the LVSA will be described with reference to FIG. 4. Figure 4 is a flowchart showing an example of an integrity check process of a lazy authentication safety application according to an embodiment of the present invention.

Referring to FIG. 4, an application in the general area 120 may request a security service from the Linux kernel (S310).

The Linux kernel can create a service identifier (Service ID) for the requested security service and transmit it to the safe area 110 (S320).

In the safe area 110, it is checked whether the integrity of the received service identifier has been checked (S330), and if the integrity check is not performed, the LVSA service can be performed after performing the integrity check (S340) (S350).

A method of managing whether to check the integrity of a service identifier (Service ID) will be described below with reference to FIG. 5. Figure 5 shows an example of a service identifier integrity check process according to an embodiment of the present invention.

Referring to FIG. 5, in the general area 120, a service can be requested from the safe area 110 through a specific command. At this time, the command can be executed by indicating the desired service identifier in the specific register 510. Here, the specific instruction may be SMC, and the specific register may be the R0 register, but are not necessarily limited thereto.

As described above, the monitor 111 is responsible for the communication contact between the safe area 110 and the general area 120. When the CPU executes the SMC instruction, the execution flow is changed to the monitor code, and the monitor 111 You can run the SMC handler within it. The monitor 111 has an integrity check table 520 for the service identifier and an integrity check table invalidation function using a hardware timer 530. Accordingly, the SMC handler can search the integrity verification table 520 for the service identifier input to the R0 register and check whether the integrity is checked. Here, the 'X' notation in the table 520 means that the integrity check is not performed (i.e., invalidated).

Additionally, the monitor 111 may periodically invalidate the integrity check of the integrity verification table 520 by indicating it as 'X' through the hardware timer 530. This is to prevent attacks that later tamper with the LVSA that has passed the integrity check. Therefore, attacks through memory modification of applications whose integrity has already been verified through integrity check invalidation can be prevented. Depending on the embodiment, even if the LVSA makes an integrity check call without using the timer 530, verification is not recorded in the integrity verification table, so that the integrity check is performed every time a request occurs in the safe area 110. You may.

The above-described present invention can be implemented as computer-readable code on a program-recorded medium. Computer-readable media includes all types of recording devices that store data that can be read by a computer system. Examples of computer-readable media include HDD (Hard Disk Drive), SSD (Solid State Disk), SDD (Silicon Disk Drive), 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 restrictive 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)

In the control method of a vehicle software update system,
As the first bootloader is executed in the first area, a first integrity verification of the first software providing switching and communication functions with at least the second area, the first operating system, and at least one second software related to the security service is performed. stage of becoming;
After the first boot loader is completely executed, a second operating system is booted without integrity verification as the second boot loader is executed in the second area;
requesting a security service for software to be verified in the first area from the second area; and
Including performing a second integrity verification on the software to be verified in the first area according to the request,
The first area corresponds to the first mode, the second area corresponds to the second mode,
The central processing unit of the vehicle software update system executes only one of the first mode and the second mode at a time,
The first area and the second area have at least a portion of an independent hardware configuration within the central processing unit,
The performance time of the second integrity verification for the software to be verified is greater than the performance time of the first integrity verification of the second software,
Control method of vehicle software update system. According to claim 1,
The step in which the first integrity verification is performed is,
A control method of a software update system for a vehicle, comprising loading the verification target software into a memory without performing both integrity verification and execution. According to claim 1,
The software subject to verification is,
A method of controlling a software update system for a vehicle, including an update binary or partition received through an over-the-air update (OTA). According to claim 1,
The first software is,
Includes monitor software,
The second software is,
A control method for a vehicle software update system that provides essential security services including encryption key management. According to clause 4,
The step of requesting the security service is,
generating a service identifier corresponding to the security service in the first area;
transmitting the generated service identifier to the monitor software;
A control method of a software update system for a vehicle, comprising the step of checking whether the monitor software checks the integrity of the service identifier. According to clause 5,
The second integrity verification step for the verification target software is:
A control method of a software update system for a vehicle, which is performed when it is confirmed that an integrity check for the service identifier has not been performed. According to clause 5,
When it is confirmed that an integrity check for the service identifier has been performed, a method of controlling a software update system for a vehicle further comprising performing a security service for the software to be verified. According to clause 5,
The monitor software is,
Manage a table indicating whether to check the integrity of at least one software including the software to be verified,
A control method of a software update system for a vehicle, periodically invalidating the integrity check of the table according to a hardware timer. According to claim 1,
The first operating system includes a trusted operating system (TOS),
A method of controlling a software update system for a vehicle, wherein the second operating system includes a Linux operating system. A computer-readable recording medium recording a program for executing the control method of a vehicle software update system according to any one of claims 1 to 9. In the vehicle software update system,
A central processing unit that operates in a first mode or a second mode, and processes at least a portion of a first area corresponding to the first mode and a second area corresponding to the second mode as independent hardware; and
A first memory that is accessible only in the first area and a second memory that is accessible only in the second area,
The central processing unit is,
Executing only one of the first mode and the second mode at a time,
As the first bootloader is executed in the first area, a first integrity verification is performed on at least one second software related to the first software, the first operating system, and the security service that provides switching and communication functions with the second area. do,
After the first boot loader completes execution, the second operating system is booted without integrity verification as the second boot loader is executed in the second area,
When the second area requests a security service for the software to be verified in the first area, a second integrity verification is performed on the software to be verified in the first area according to the request,
The performance time of the second integrity verification for the verification target software is greater than the performance time of the first integrity verification of the second software,
Vehicle software update system. According to claim 11,
The central processing unit is,
A software update system for a vehicle that controls the verification target software to be loaded into the first memory without performing both integrity verification and execution when the first integrity verification is performed. According to claim 11,
The software subject to verification is,
A software update system for vehicles, including update binaries or partitions received via over-the-air updates (OTA). According to claim 11,
The first software is,
Includes monitor software,
The second software is,
An in-vehicle software update system that provides essential security services, including encryption key management. According to claim 14,
The central processing unit is,
For a vehicle, controlling a service identifier corresponding to the security service to be generated in the first area and, when the generated service identifier is transmitted to the monitor software, to check whether the integrity of the service identifier is checked in the monitor software. Software update system. According to claim 15,
The central processing unit is,
A software update system for a vehicle that controls to perform a second integrity verification on the verification target software when it is confirmed that the integrity check on the service identifier has not been performed. According to claim 15,
The central processing unit is,
A software update system for a vehicle that controls to perform a security service for the software to be verified when it is confirmed that an integrity check for the service identifier has been performed. According to claim 15,
The monitor software is,
Manage a table indicating whether to check the integrity of at least one software including the software to be verified,
A software update system for a vehicle that periodically invalidates the integrity check of the table according to a hardware timer. According to claim 11,
The first operating system includes a trusted operating system (TOS),
The second operating system is a software update system for a vehicle, including a Linux operating system.

Images