CONTROL DEVICE AND PROGRAM VERIFICATION METHOD

Abstract

Provided are a control device and a program verification method capable of suppressing an operation load in a case where different keys are used for respective devices. The control device 1 stores a program to be verified, a plurality of verification expected values related to verification of the program to be verified, and registered verification expected value information 183 that identifies one of the verification expected values. The control device verifies whether the program to be verified is correct using the registered verification expected value information 183.

Description

TECHNICAL FIELD

The present invention relates to a control device and a program verification method.

BACKGROUND ART

In an embedded system mounted on an automobile, a home appliance, a medical device, or the like, there is a concern that when software or firmware is illegally rewritten by an attacker, serious damage may be caused. As a countermeasure against such a threat, secure boot capable of activating only an untampered program at the time of program activation has been studied. As a method of secure boot, at the time of program activation, a verification value is calculated using a program to be verified, a verification process based on an encryption technique, and a key used in the verification process, and whether the verification value matches a verification expected value calculated in advance is verified.

For example, the technology of PTL 1 discloses a key generation device including a tampering verification unit that verifies whether software has been tampered using software proof information, and the tampering verification unit prohibits key generation by the key generation unit when determining that the software has been tampered. According to such a technology of PTL 1, it is possible to verify that the program to be activated is not tampered and to prohibit the activation of the program when it is determined that the program is tampered.

In a tamper detection technique such as secure boot, an encryption technique is generally used. In the encryption technique, a key that is required to be kept secret is used, but when the key is compromised even once, the security of secure boot itself cannot be secured. As one of methods for reducing the risk of key compromise, it is conceivable to use different keys for respective devices. As a result, even when the key is compromised, it can be expected that the influence is limited to the device using the same key.

CITATION LIST

Patent Literature

• PTL 1: JP 2009-284231 A

SUMMARY OF INVENTION

Technical Problem

However, the conventional technique has a problem that an operation load is large when different keys are used for respective devices.

An example of the operation load will be described. In a case where different keys are used for respective devices, the key is designated in the manufacturing process (for example, at the time of factory shipment). At this time, it is necessary to create and manage association information indicating which key is used for which device in advance, and input the key and the verification expected value according to the association information. As described above, it is necessary to select an appropriate key with reference to the association information not only at the time of use but also at the time of manufacturing, and an operation load is large.

The present invention has been made in view of the above problems, and an object thereof is to provide a control device and a program verification method capable of suppressing an operation load in a case where different keys are used for respective devices.

Solution to Problem

An example of a control device according to the present invention stores a program to be verified, a plurality of verification expected values related to verification of the program to be verified, and information for identifying one of the verification expected values, wherein the control device verifies whether the program to be verified is correct using the identified verification expected value.

Further, a program verification method according to the present invention is executed by a control device storing a program to be verified, a plurality of verification expected values related to verification of the program, to be verified, and information for identifying one of the verification expected values, wherein the control device verifies whether the program to be verified is correct using the identified verification expected value.

This specification includes the disclosure of Japanese Patent Application No. 2020-117468, which is the basis of the priority of the present application.

Advantageous Effects of Invention

According to the control device and the program verification method of the present invention, it is possible to suppress an operation load in a case where different keys are used for respective devices.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram illustrating a configuration example of a control device according to a first embodiment of the present invention.

FIG. 2 is a diagram illustrating an example of a processing flow in which the control device registers a verification expected value.

FIG. 3 is a diagram illustrating an example of a processing flow in which the control device verifies a program.

FIG. 4 is a diagram illustrating an example of a data structure of key-related information.

FIG. 5 is a diagram illustrating an example of a data structure of program structure information.

FIG. 6 is a diagram illustrating an example of a data structure of verification expected value memory map information.

FIG. 7 is a diagram illustrating an example of a data structure of registered verification expected value information.

FIG. 8 is a diagram illustrating an example of a data structure of verification range information.

FIG. 9 is a diagram illustrating an example of a processing flow in which a control device according to a second embodiment of the present invention registers a verification expected value.

FIG. 10 is a diagram illustrating an example of a data structure of verification expected value reference address information.

DESCRIPTION OF EMBODIMENTS

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings using embodiments.

First Embodiment

FIG. 1 illustrates a configuration example of a control device 1 according to a first embodiment. In the present embodiment, the control device 1 is an information processing device connected to a vehicle-mounted network, but the technical idea of the present invention is not limited to this example.

The control device 1 has a secure boot function. That is, the control device 1 can verify whether the program to be activated (program to be verified) is correct using the verification expected value by executing the program verification method described in the present specification.

Here, the meaning of the expression “program is correct” can be appropriately understood by those skilled in the art, but for example, means that the program is the same as a program intended to be executed by a designer or a user, and/or means that the program has not been tampered with by unauthorized means. The determination as to whether the program is correct can be made based on, for example, whether the verification value matches the verification expected value as described later.

The control device 1 is connected to an information processing device 3 via a communication bus 2. The information processing device 3 is, for example, an information processing device connected to a vehicle-mounted network, and may be a control device. The information processing device 3 is, for example, a computer having a known configuration. The communication bus 2 may be physically a plurality of communication buses, and communication standards of the respective communication buses may be the same or different. The communication standards are CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), Ethernet (registered trademark), and the like.

The control device 1 can be configured using a known computer, and includes, for example, a calculation unit and a storage unit 18. The calculation unit includes, for example, a processor. The processor is, for example, a CPU 10. The storage unit 18 includes a ROM (not illustrated) and a RAM (not illustrated). In addition, the storage unit 18 includes a nonvolatile storage device.

The CPU 10 develops the program stored in the ROM in the RAM and executes the program, whereby the control device 1 implements the functions described in the present specification. That is, the control device 1 includes, as functional units thereof, a communication unit 11, a key-related information acquisition unit 12, a verification expected value identification unit 13, a verification expected value registration unit 14, a verification expected value acquisition unit 15, a program verification unit 16, and a program execution control unit 17.

An example of the function of each functional unit will be described below. The communication unit 11 is a communication interface and performs calculation necessary for communication. The communication unit 11 receives a message transmitted from the information processing device 3 via the communication bus 2 and transmits a message to the information processing device 3 via the communication bus 2. As described above, the communication bus 2 physically includes a plurality of communication buses. The control device 1 transmits and receives information necessary for program update using the communication unit 11.

The key-related information acquisition unit 12 acquires key-related information registered in the control device 1. The verification expected value identification unit 13 identifies a verification expected value suitable for the key value acquired by the key-related information acquisition unit 12 from a plurality of verification expected values stored in the storage unit 18. The verification expected value registration unit 14 registers the verification expected value identified by the verification expected value identification unit 13 as a verification expected value used for the program verification process. The verification expected value acquisition unit 15 acquires the verification expected value registered by the verification expected value registration unit 14 at the time of program verification. The program verification unit 16 verifies that the program to be activated is correct. The program execution control unit 17 executes the program only when it is confirmed that the program to be activated is correct.

The storage unit 18 stores key-related information 181 including a key value used at the time of program verification, verification expected value group information 182 in which a plurality of verification expected values is stored, registered verification expected value information 183 in which the verification expected value used at the time of program verification is stored in advance, and verification range information 184 indicating a verification target range of program verification.

The control device 1 stores program structure information. FIG. 5 illustrates an example of a data structure of program structure information 501. The program structure information 501 includes at least one type of program. This program is a program to be verified. In addition, the program structure information 501 includes verification expected values calculated for the program using any key values where the number of verification expected values is as many as the number of types of keys to be distinguished.

In the example of FIG. 5, the program structure information 501 includes a program A (program to be verified). In addition, the program structure information 501 includes a verification expected value 1 calculated from the program A and a key value 1, a verification expected value 2 calculated from the program A and a key value 2, and a verification expected value 3 calculated from the program A and a key value 3.

These verification expected values are calculated in advance and stored in the storage unit 18. That is, the verification expected values corresponds to respective key values, and each verification expected value is calculated based on the corresponding key value and the program A. This calculation processing can be generally performed by any computer, and may be performed by the control device 1 or another computer, for example. In addition, the verification expected value is calculated by executing an encryption processing operation. As an example of the encryption processing operation, an operation by a message authentication code (MAC) method using a common key, an operation by an RSA method using a public key, a signature operation by ECDSA or the like, or the like can be used. Note that this encryption processing operation can have the same scheme as the encryption processing operation used in step 304 described later.

As described above, the control device 1 stores the program to be verified and the plurality of verification expected values related to verification of the program to be verified.

FIG. 2 is a flowchart illustrating an example of a process when the control device 1 registers a verification expected value. This process is executed at the first timing (for example, at the time of factory shipment of the product related to the control device 1). The product is, for example, a vehicle. At this timing, the program to be verified does not need to be executed (but may be executed). An execution entity for each step described below is the CPU 10 of the control device 1.

In step 201, the control device 1 (for example, the communication unit 11) receives the key-related information 181.

FIG. 4 illustrates an example of a data structure of the key-related information 181. The key-related information 181 includes, for each key, a key ID 401 for identifying the key, a key value 402 indicating a value used for program verification, and a key length 403 indicating a length of the key value 402. Note that “Ox” in the figure represents hexadecimal digit, and the same applies to the other figures.

As described above, since the control device 1 stores the key length 403 for each key value 402, it is possible to cope with a case where the key lengths are different from each other.

In this step, it is desirable to securely transmit and receive the key-related information 181. For example, a secret encryption process may be performed on the key-related information, a tampering detection code may be further given to the key-related information to transmit and receive the information, and the tampering detection process and the decryption process may be performed after the reception. Alternatively, the control device 1 may receive the key-related information in an environment where confidentiality and integrity are ensured by operation.

In step 202, the control device 1 stores the key-related information 181 in the storage unit 18 and registers the key-related information. The key-related information 181 to be registered includes information on one or more keys.

In step 203, the control device 1 (for example, the key-related information acquisition unit 12) acquires the key ID 401 used for program verification. The key ID 401 is a single value and is input by, for example, an operator.

Here, the operator does not need to identify and input a specific key ID, and can input an any key ID from the available range. Therefore, for example, the key ID can be freely determined without referring to a table or the like associating the product and the key ID, and only the determined result may be recorded. In this way, the operation load is suppressed.

In addition, the operator does not need to input the same key ID for all the products (that is, all the control devices 1), and can change the key ID for each product (that is, for each control device 1). Therefore, different keys can be used for respective control devices 1. Therefore, even when the content of a certain key is compromised, the influence is limited. Note that a unique key may be used for each product, but it is not necessary to do so (that is, a certain key may be commonly used for the plurality of control devices 1).

In step 204, the control device 1 (for example, the verification expected value identification unit 13) identifies the verification expected value information.

FIG. 6 illustrates an outline of verification expected value memory map 600 which is referred to by the verification expected value identification unit 13 in step 204. The verification expected value memory map 600 includes verification expected value information. The control device 1 stores the verification expected value memory map 600 in advance.

The verification expected value memory map 600 associates a key ID 601 (key identification information) for identifying each of a plurality of key values with a verification expected value address 602 (address information) at which a verification expected value corresponding to each key ID 601 is stored. The key ID 601 corresponds to the key ID 401 illustrated in FIG. 4.

In this manner, the control device 1 stores a plurality of key values related to verification of the program to be verified. As a result, as described above, the operator can input an any key ID.

The control device 1 refers to the verification expected value memory map 600 based on the key ID 401 acquired in step 203, and identifies the verification expected value address 602 associated with the corresponding key ID 601. In the present embodiment, it is assumed that the verification expected value memory map 600 is received together with the key-related information in step 201, but the verification expected value memory map 600 may be stored in the control device 1 in advance.

It is determined in step 205 whether the corresponding verification expected value address can be identified in step 204. When the identification has been made, the process by the control device 1 proceeds to step 206, and when the identification has not been made, the process by the control device 1 proceeds to step 207.

In step 206, the control device 1 (for example, the verification expected value registration unit 14) stores the verification expected value address 602, as the registered verification expected value information 183, identified in step 204 in the storage unit 18, and registers the address.

FIG. 7 illustrates an example of a data structure of the registered verification expected value information 183. The registered verification expected value information 183 is information for identifying one of the verification expected values. The registered verification expected value information 183 includes a value indicating an address at which the verification expected value corresponding to the key ID acquired in step 203 is stored. In this way, even when the verification expected value is long, the verification expected value can be identified with a relatively small storage capacity. As a modification, the registered verification expected value information 183 may be a value indicating the verification expected value itself.

In step 207, the control device 1 (for example, the verification expected value registration unit 14) determines that the corresponding verification expected value has not been correctly identified and executes error processing. The error processing includes a process of recording the operation as a log, a process of stopping the activation of the program, and the like.

Through the above steps, the verification expected value corresponding to the key value 402 stored in the control device 1 can be identified as the registered verification expected value information 183.

FIG. 3 is a flowchart illustrating processing when the control device 1 verifies the program. This processing is executed at the second timing (for example, when an owner of a product related to the control device 1 uses the product). More specifically, when the control device 1 is instructed to execute a program to be verified, the control device 1 verifies whether the program is correct by executing the process of FIG. 3. An execution entity for each step described below is the CPU 10 of the control device 1.

In step 301, the control device 1 (for example, the key-related information acquisition unit 12) refers to the key-related information 181 and acquires the predetermined key value 402. This key value 402 can be designated in advance. For example, in the process of FIG. 2, information indicating the key value 402 corresponding to the identified verification expected value may be stored, or this information may be separately input.

In step 302, the control device 1 (for example, the verification expected value acquisition unit 15) refers to the registered verification expected value information 183 and acquires the registered verification expected value information 183.

In step 303, the control device (for example, the program verification unit 16) refers to the verification range information and acquires the address of the program to be verified.

FIG. 8 illustrates an example of the verification range information 184. The verification range information 184 is referred to in order for the program verification unit 16 to acquire the verification range in step 303 described above. In this manner, the control device 1 stores the verification range for the program to be verified.

The verification range information 184 includes a verification target ID 801 (not corresponding to a key ID) indicating an identifier for identifying a program to be verified, a verification content 802 indicating verification content, that is, the name of the program, and the like, and a verification target address 803, (verification range) indicating address information, at which the verification target is stored. In this example, the verification range includes a start address and an end address, and the program is stored in an area from the start address to the end address.

In step 304, the control device 1 (for example, the program verification unit 16) calculates a verification value based on the key value 402 acquired in step 301 and the program corresponding to the verification target address 803 acquired in step 303.

The verification value is calculated by executing an encryption processing operation. As an example of the encryption processing operation, an operation by a message authentication code (MAC) method using a common key, an operation by an RSA method using a public key, a signature operation by ECDSA or the like, or the like can be used. Note that this encryption processing operation can be the same scheme as the encryption processing operation used to calculate the verification expected value in FIG. 5 and the like.

In this way, even when the product is used, the program can be verified using the verification expected value set at the time of manufacturing.

In addition, since the control device 1 verifies whether the program is correct based on the verification range illustrated in FIG. 8, it is possible to flexibly define a portion, of the program, to be particularly a verified.

In step 305, the control device 1 (for example, the program verification unit 16) compares the verification value calculated in step 304 with the registered verification expected value information 183 acquired in step 302. In this manner, the control device 1 verifies whether the program to be verified is correct using one of the plurality of verification expected values.

When the verification value matches the verification expected value, the process by the control device 1 proceeds to step 306. This corresponds to a case where the program is correct. When the verification value does not match the verification expected value, the process by the control device 1 proceeds to step 307. This corresponds to a case where the program is not correct.

As described above, the control device 1 verifies whether the program to be verified is correct using one verification expected value identified as the registered verification expected value information 183 of FIG. 7 of the plurality of verification expected values. Therefore, it is possible to realize the secure boot function at the time of use while reducing the operation load as described above at the time of manufacturing the product.

In step 306, the control device 1 (for example, the program execution control unit 17) executes the program. In step 307, the control device 1 (for example, the program execution control unit 17) does not execute the program. In addition, in step 307, error processing similar to that in step 207 may be executed. By this determination process, the secure boot function is realized.

Note that, when verifying the program, the programs related to all the verification target IDs 801 may be verified collectively. In this case, the processing from step 301 to step 307 is performed only once for all the verification target IDs 801 at the same time.

Alternatively, the program may be verified for each verification target ID 801. In this case, in the process of steps 201 to 206, a plurality of pieces of verification expected value information is registered in the registered verification expected value information 183, and the process of steps 301 to 307 is repeatedly performed by the number of verification target IDs 801.

According to the above steps, the program can be safely activated in the control device 1 (for example, the control device connected to the vehicle-mounted network).

In the present embodiment, the control device receives the key-related information and the verification expected value memory map in order to identify the verification expected value in steps 201 to 207. However, the verification expected value can be identified by any method, and for example, the verification expected value may be dynamically identified based on pre-registered key information.

Second Embodiment

FIG. 9 is a flowchart illustrating processing when the control device according to a second embodiment of the present invention registers the verification expected value. In the second embodiment, the process of FIG. 2 is replaced with the process of FIG. 9 in the first embodiment. Hereinafter, description of parts common to the first embodiment may be omitted. An execution entity for each step described below is the CPU 10 of the control device 1.

In step 901, the control device 1 (for example, the key-related information acquisition unit 12) refers to the key-related information 181 to acquire the key ID.

In step 902, the control device 1 (for example, the verification expected value identification unit 13) identifies address information in which the verification expected value is stored.

FIG. 10 illustrates an example of a data structure of the verification expected value reference address information used in step 902. The control device 1 acquires verification expected value reference address information 1001, and identifies the address information in which the verification expected value is stored using the key ID acquired in step 901 and the verification expected value reference address information 1001.

For example, the verification expected value reference address information 1001 represents a reference address representing a reference position for searching for a verification expected value. The control device 1 can acquire the address of each verification expected value by sequentially adding the length of the verification expected value to the reference address. For example, the first verification expected value is stored at the reference address. The second verification expected value is stored in an address obtained by adding the length of the first verification expected value to the reference address. The third verification expected value is stored at an address obtained by adding the length of the first verification expected value and the length of the second verification expected value to the reference address.

The process of steps 903, 904, and 905 may be similar to that of steps 205, 206, and 207 of FIG. 2, respectively.

Through the above steps, the verification expected value corresponding to the key value 402 stored in the control device 1 can be identified as the registered verification expected value information 183.

As described above, according to the first and second embodiments, even in a case where different keys are stored for respective devices, the program is verified by the combination of the correct key value and the verification expected value at the time of program activation, and the program that is not likely to be tampered can be activated while reducing the influence of key compromise. In addition, the key values are different for respective devices, but the program-related information is common to respective devices, so that it can be expected to suppress the operation load of the device manufacturer or the program update operator.

For example, when the operator inputs different key IDs for respective devices, an any key ID can be input from among a plurality of available key IDs without referring to a predetermined key ID. Therefore, the operator can freely determine the key ID without referring to the key correspondence table or the like, and only the determined result may be recorded. In this way, the operation load is suppressed.

For example, in the case of an in-vehicle control device, by making the verification expected value different for each predetermined number of devices (for example, every 10, every 100, or every 1000), the influence of key compromise can be limited to the number of devices.

REFERENCE SIGNS LIST

• 1 control device
• 183 registered verification expected value information (information for identifying one of verification expected values)
• 402 key value
• 403 key length
• 501 program structure information (program to be verified, verification expected value)
• 600 verification expected value memory map (memory map)
• 803 verification target address (verification range)
• All publications, patents, and patent applications cited in this specification are incorporated herein by reference in their entirety.

Claims

1. A control device that stores a program to be verified, a plurality of verification expected values related to verification of the program to be verified, and information for identifying one of the verification expected values, wherein

the control device verifies whether the program to be verified is correct using the identified verification expected value.

2. The control device according to claim 1, wherein

the control device stores a plurality of key values related to the verification of the program to be verified, and

each of the verification expected values is calculated by the control device or another computer executing an encryption processing operation based on a corresponding key value of the key values and the program to be verified.

3. The control device according to claim 1, wherein the information for identifying one of the verification expected values includes an address.

4. The control device according to claim 3, wherein

the control device stores a memory map, and

the memory map associates key identification information for identifying each of a plurality of key values with an address at which the verification expected value corresponding to each key identification information is stored.

5. The control device according to claim 1, wherein

when execution of the program to be verified is instructed, the control device verifies whether the program to be verified is correct,

when the program to be verified is correct, the control device executes the program to be verified, and

when the program to be verified is not correct, the control device does not execute the program to be verified.

6. The control device according to claim 1, wherein

verifying whether the program to be verified is correct includes

calculating a verification value by executing an encryption processing operation based on a predetermined key value and the program to be verified, and

determining whether the verification value matches the identified verification expected value.

7. The control device according to claim 1, wherein

the control device stores a verification range for the program to be verified, and

the control device verifies whether the program to be verified is correct based on the verification range related to the program to be verified.

8. The control device according to claim 2, wherein the control device stores a key length for each of the key values.

9. A program verification method executed by a control device, the control device storing a program to be verified, a plurality of verification expected values related to verification of the program to be verified, and information for identifying one of the verification expected values, wherein

the control device verifies whether the program to be verified is correct using the identified verification expected value.