WO2018047510A1

WO2018047510A1 - Processing device for mounting in vehicle

Info

Publication number: WO2018047510A1
Application number: PCT/JP2017/027366
Authority: WO
Inventors: 尚幸山本; 中西　一弘
Original assignee: 日立オートモティブシステムズ株式会社
Priority date: 2016-09-07
Filing date: 2017-07-28
Publication date: 2018-03-15
Also published as: JP6704458B2; JPWO2018047510A1

Abstract

The present invention provides a vehicle-mounted processing device capable of introducing security into a vehicle-mounted network in stages. According to the present invention, a communication device (receiving unit) of a vehicle-mounted gateway device 1 receives data 400 (first data) including an identifier (ID). A routing control unit 2 of the vehicle-mounted gateway device 1 identifies a transfer destination corresponding to the ID. A security control unit 4 of the vehicle-mounted gateway device 1 generates, from the data 400 (first data), data 402, 403 (second data) to be transferred to the transfer destination, on the basis of safety level information (ASIL) indicating a safety level required for the transfer destination. A communication device (transmitting unit) of the vehicle-mounted gateway device 1 transmits the data 402, 403 (second data) to the transfer destination.

Description

In-vehicle processing equipment

The present invention relates to an in-vehicle processing apparatus.

 Network security risks are increasing with the progress of computerization of vehicle systems. Threat cases that have an impact on driving by actually attacking a vehicle network also occur, and security functions for protecting a vehicle control system against attacks from outside are regarded as important.

The vehicle is equipped with a plurality of electronic control devices (hereinafter referred to as ECUs), and the network between the devices is mainly composed of CAN (Controller Area Network) standards. When applying security measures to an in-vehicle network, the CAN frame transmission ECU authenticates the CAN frame using a key to guarantee the validity of the CAN frame and to prevent replay attacks from the fake ECU connected to the CAN bus. A method of assigning a code (Message Authentication Code; MAC) has been proposed (for example, see Patent Document 1).

In addition, a technique that can improve the security of data communication while suppressing the burden on the node is disclosed (for example, see Patent Document 2). The vehicle data communication apparatus of Patent Document 2 is a unit of a combination of a bus connecting a node on the data transmission side and a bus connecting a node on the data reception side for encryption information indicating whether or not to encrypt data. The node centrally manages the decoding information as to whether or not to decode the data in units of buses connecting the nodes on the data transmission side.

Japanese Patent No. 5770602 JP 2013-201510 JP

The current vehicle network CAN is a line-type network by connecting each ECU on the line. The CAN frame does not include identification information of the transmission source ECU and the destination ECU, and the reception ECU cannot simply determine whether the data is from the correct transmission source ECU.

In the technique disclosed in Patent Document 1, when applying security measures to an in-vehicle network, the transmission CAN frame itself needs to be changed, and the change handling man-hours of all the ECUs are increased.

In the technology disclosed in Patent Document 2, security measures can be taken for each bus, but all ECUs that receive data must have a function of decoding, and reliability (safety) is required. The security function cannot be taken in step by step from the ECU, and the corresponding man-hours increase.

An object of the present invention is to provide an in-vehicle processing apparatus that can introduce security in an in-vehicle network in stages.

In order to achieve the above object, the present invention provides a receiving unit that receives first data including an identifier, a routing control unit that identifies a transfer destination corresponding to the identifier, and a security level required for the transfer destination. A security control unit that generates second data to be transferred from the first data to the transfer destination based on the safety degree information that is indicated; and a transmission unit that transmits the second data to the transfer destination.

According to the present invention, security can be introduced to an in-vehicle network in stages.
Problems, configurations, and effects other than those described above will be clarified by the following description of embodiments.

It is a figure for demonstrating the structure of the vehicle-mounted gateway apparatus by one Embodiment of this invention, the structure of a vehicle-mounted network system, and the operation | movement of key distribution. It is a figure for demonstrating the structure of the vehicle-mounted gateway apparatus by one Embodiment of this invention, the structure of a vehicle-mounted network system, and the operation | movement of the replacement | exchange or cancellation | release of an encryption key. It is a block diagram of the security table of the vehicle-mounted gateway apparatus by one Embodiment of this invention. It is a block diagram of the routing table of the vehicle-mounted gateway apparatus by one Embodiment of this invention. It is a flowchart of the vehicle-mounted gateway apparatus by one Embodiment of this invention. It is a figure which shows the hardware constitutions of the vehicle-mounted gateway apparatus by one Embodiment of this invention.

Hereinafter, the configuration and operation of the in-vehicle gateway device (in-vehicle processing device) according to the embodiment of the present invention will be described with reference to the drawings. In each figure, the same numerals indicate the same parts.

(System Configuration) The configuration of the in-vehicle gateway device and the in-vehicle network system according to an embodiment of the present invention will be described with reference to FIG.

In the example shown in FIG. 1, the in-vehicle network includes two buses (N600 and N601). The in-vehicle gateway device 1, ECU 1 (N101), ECU 2 (N301), ECU 3 (N201) and the like according to the embodiment of the present invention are connected to the bus N600 (line). On the other hand, the ECU 4 (N102) is connected to the bus N601.

Each ECU is assigned an ASIL (Automotive Safety Integrity Level) defined by ISO (International Organization for Standardization). Specifically, ASIL is classified using symbols such as QM (Quality Management), A, B, C, and D. The degree of safety required in the order of QM <A <B <C <D increases.

In the example of FIG. 1, “D”, which is the highest safety level, is assigned to the ECU 1 (N101) and the ECU 4 (N102) in the broken line N100. “B” is assigned to the ECU 3 (N201) and the ECU 5 in the broken line N200. “QM”, which is the lowest safety level, is assigned to the ECU 2 (N301) and the ECU 6 in the broken line N300.

The in-vehicle gateway device 1 includes a routing control unit 2 that determines a data transfer destination, a routing table 3 that indicates a correspondence between a CAN ID (identifier) and an output destination (transfer destination), a security control unit 4 that performs security control determination, and the like. , Key information management of each device, authentication information between ECUs, security table 5 indicating each ASIL information and encryption method, encryption / decryption algorithm 6 (FIG. 2), and key information 8.

The in-vehicle gateway device 1 includes a microcomputer 11 (processor), an input / output device 14 such as an input / output port, a communication device 15 such as a CAN transceiver, and the like, as shown in FIG. The microcomputer 11 includes an SRAM 12 (Static Random Access Memory) that is an example of a volatile memory and a FLASH 13 (Flash Memory) that is an example of a nonvolatile memory.

The FLASH 13 stores a routing table 3, a security table 5, encryption / decryption algorithms 6, 7 (program), key information 8, and the like. The SRAM 12 temporarily stores data necessary for calculation, calculation results, and the like.

As shown in FIG. 4, the routing table 3 corresponds to “connection bus No” indicating a number for identifying a bus to which the transmission destination ECU is connected, “reception data ID” indicating the ID of reception data, and reception data ID. Fields such as “transmission destination ECU” indicating the transmission destination ECU and “transmission ID” indicating ID assigned to data to be transmitted to the transmission destination are provided.

As shown in FIG. 3, the security table 5 includes an “device name”, an “ASIL” indicating a vehicle safety level, an “key ID” indicating an ID for identifying an encryption key, an “encryption method”, and an ECU indicated by the device name. Are provided with fields such as “transmission data ID” indicating the ID of data to be transmitted and “authentication” indicating the result of authentication by challenge and response. In other words, the FLASH 13 (storage device) stores a combination of a device name (transfer destination) and ASIL (safety level information) corresponding to the device name (transfer destination).

The security control unit 4 (microcomputer 11) of the in-vehicle gateway device 1 reads the ASIL (safety degree information) corresponding to the transfer destination from the FLASH 13 (storage device), and according to the read ASIL, the data to be transferred to the transfer destination Set the encryption strength. Thereby, the encryption strength of the data to be transferred is determined according to the ASIL of the transfer destination regardless of the encryption strength of the data before the transfer. Details of the operation will be described later with reference to FIG.

The FLASH 13 (storage device) stores ASIL (security level information) and a combination of encryption methods corresponding to ASIL.

The security control unit 4 (microcomputer 11) of the in-vehicle gateway device 1 reads the encryption method corresponding to ASIL (safety level information) from the FLASH 13 (storage device), and uses the read encryption method to transfer the data to the transfer destination Set the cipher strength of. As a result, the transfer destination need only perform decryption of an encryption method corresponding to ASIL. Details will be described later with reference to FIG.

Further, the FLASH 13 (storage device) stores a combination of ASIL (safety level information) and a key ID (encryption key information) indicating information of an encryption key corresponding to ASIL.

The security control unit 4 (microcomputer 11) of the in-vehicle gateway device 1 reads the key ID corresponding to ASIL (safety level information) from the FLASH 13 (storage device), and distributes the encryption key indicated by the read key ID to the transfer destination. . As a result, the transfer destination can decrypt the data using the encryption key corresponding to the ASIL.

Note that CMAC® (Cipher-based MAC) shown in FIG. 3 is a message authentication code algorithm based on block cipher. Also, HMAC (Hash-based Message Authentication Code) shown in FIG. 3 is one of message authentication codes (MAC; Message Authentication Code) and is calculated based on a secret key, a message (data), and a hash function. . The encryption strength of CMAC is greater than that of HMAC.

(Distribution of encryption key)
Next, an example in which the in-vehicle gateway device 1 distributes keys to each ECU for each ASIL will be described with reference to FIG.

In the routing table 3 of the in-vehicle gateway device 1, a transmission ID is prepared for transmitting key information to the ECU 1 (N101), ECU 3 (N201), etc. that require security. In the example of FIG. 1, the transmission ID “600” is assigned to the transmission destination “ECU1” in the third record of the routing table 3. In the fourth record of the routing table 3, the transmission ID “610” is assigned to the transmission destination “ECU3”.

In the security table 5, key information for each ASIL corresponding to each ECU is prepared. In the example of FIG. 1, the key ID “D” is assigned to the device name “ECU1” in the first record of the security table 5. In the third record of the security table, the key ID “B” is assigned to the device name “ECU3”. Here, the key ID is an identifier for identifying an encryption key.

The in-vehicle gateway device 1 performs ECU device authentication by challenge and response with each ECU. The in-vehicle gateway device 1 distributes key information 8 for each ASIL solved by the security table 5 to each ECU when authentication with each ECU is successful. The in-vehicle gateway device 1 monitors the cycle for each received data ID. ID data received outside the cycle is discarded as invalid data.

The in-vehicle gateway device 1 uses the key distributed to each ECU to resolve the MAC at the time of frame reception and frame transmission, and mediates encryption with each ECU. This frame arbitration (encryption key replacement or cancellation) will be described with reference to FIG.

(Replacement or cancellation of encryption key)
Next, the operation of changing or releasing the encryption key of the in-vehicle gateway device and the in-vehicle network according to the embodiment of the present invention will be described with reference to FIG.

When it is desired to pass data from the ECU 1 (N101) to the ECU 2 (N301) and the ECU 3 (N201), since the CAN frame is encrypted by the ECU 1 (N101), the receiving ECU receives the data. Data cannot be handled as it is. Therefore, the in-vehicle gateway device 1 resolves the received data 401 from the ECU 1 (N101) from the routing table 3 and the security table 5 and decrypts the data by the decryption algorithm 6.

The key information 8 is specified by the encryption algorithm 6 corresponding to the transmission destination ECU of the routing table 3 and the data is encrypted to obtain the data strength B (403), and the transmission ID is changed and transmitted. When the ASIL of the transmission destination ECU of the security table 5 is QM, the transmission ID is changed and transmitted as the raw data 402 without encryption.

Next, the operation of the in-vehicle gateway device 1 will be described in detail with reference to FIG. Here, it is assumed that ECU 1 shown in FIG. 2 transmits encrypted data 400 (CAN frame) having data strength D via bus N601. The ID (identifier) included in the data 400 is “100”. The data 400 (first data) is encrypted using the encryption key (first encryption key) indicated by the key ID “D”.

The in-vehicle gateway device 1 receives the data 400 (S1). Here, the communication device 15 of the in-vehicle gateway device 1 functions as a receiving unit that receives data 400 including an ID (identifier).

The in-vehicle gateway device 1 determines whether or not the received data 400 (received data 401) is a transfer target (S2).

Specifically, the in-vehicle gateway device 1 searches the routing table 3 for a record in which the value of the “reception data ID” field matches the ID “100” of the data 400. When the value of the “transmission destination ECU” field of the record hit by the search is not itself (S2: YES), the in-vehicle gateway device 1 proceeds to the process of S3, and in the “transmission destination ECU” field of the record hit by the search If the value is self or there is no record that satisfies the search condition (S2: NO), the process is terminated.

In the routing table 3 shown in FIG. 5, the first record is hit by the search. The in-vehicle gateway device 1 determines that the transmission destination ECUs are the

ECUs

2 and 3 from the value of the “transmission destination ECU” field D1 of the first record of the routing table 3, and the received data 400 is a transfer target. The in-vehicle gateway device 1 specifies that the IDs of data to be transmitted are 101 and 102 from the “transmission ID” field of the first record of the routing table 3.

Here, the microcomputer 11 of the in-vehicle gateway device 1 functions as the routing control unit 2 that specifies the transfer destination corresponding to the ID (identifier) included in the data 400.

Subsequently, the in-vehicle gateway device 1 determines whether or not the ASIL of the ECU 1 that transmitted the data 400 is different from the ASIL of the transmission destination ECU 2 and ECU 3 (S3).

First, the in-vehicle gateway device 1 refers to the security table 5 and identifies the ASIL of the ECU 1 that has transmitted the data 400. Specifically, the in-vehicle gateway device 1 searches the security table 5 for a record in which the value of the “transmission data ID” field matches the ID “100” of the data 400. In the security table 5 shown in FIG. 5, the first record is hit. The in-vehicle gateway device 1 specifies that the ASIL of the ECU 1 that transmitted the data 400 is “D” from the value of the “ASIL” field D2 of the first record of the security table 5.

Next, the in-vehicle gateway device 1 refers to the security table 5 and identifies the ASIL of the transfer destination ECU 2 and ECU 3. Specifically, the in-vehicle gateway device 1 searches the data of the ECU 2 and the ECU 3 for the value of the “device name” field from the security table 5. In the security table 5 shown in FIG. 5, the second record and the third record are hit.

The in-vehicle gateway device 1 identifies that the ASIL of the destination ECU 2 is “QM” from the value of the “ASIL” field D2 of the second record of the security table 5.
Similarly, the in-vehicle gateway device 1 specifies that the ASIL of the destination ECU 3 is “B” from the value of the “ASIL” field D 2 of the third record of the security table 5.

Thereby, the in-vehicle gateway device 1 determines that the ASIL of the ECU 1 that transmitted the data 400 is different from the ASIL of the destination ECU 2 and ECU 3 (S3: YES).

The in-vehicle gateway device 1 specifies that the ECU 1 has encrypted the data 400 with “CMAC” from the value of the “encryption method” field of the first record of the security table 5, and the received data 400 is encrypted with the encryption method “CMAC”. (S4).

The in-vehicle gateway device 1 determines whether the ASIL of the transmission destination (transfer destination) ECU is other than “QM” (S5). In the example of FIG. 5, the ASIL of the destination ECU 2 is “QM”, so the in-vehicle gateway device 1 generates and transmits plaintext raw data 402 (CAN frame) from the data 400 decrypted in S4. (S7). Further, since the ASIL of the ECU 3 as the transmission destination is “B”, the in-vehicle gateway device 1 sets the value “B” in the “key ID” field of the third record of the security table 5 to the data 400 decrypted in S4. The data 400 decrypted in S4 is encrypted with the value “HMAC” in the “encryption scheme” field (S6) using the encryption key shown (S6), and data 403 (CAN frame) with data strength B is generated and transmitted (S7). ).

In other words, the microcomputer 11 of the in-vehicle gateway device 1 transfers the

data

402, 403 to be transferred from the data 400 (first data) to the transfer destination based on the ASIL (safety level information) indicating the safety level required for the transfer destination. It functions as the security control unit 4 that generates (second data). The communication device 15 of the in-vehicle gateway device 1 functions as a transmission unit that transmits the data 402 and 403 (second data) to the transfer destination.

Specifically, the microcomputer 11 (security control unit 4) sets the encryption strength of the data 402 and 403 (second data) according to the ASIL (safety level information) of the transfer destination. Specifically, the microcomputer 11 (security control unit 4) exchanges the encryption key of the data 400 (first data) or releases the encryption of the data 400 according to the ASIL (safety level information) of the transfer destination. Thus, data 402 and 403 (second data) are generated.

For example, the microcomputer 11 (security control unit 4) decrypts the data 400 (first data) using the first encryption key (key ID = D) according to the ASIL (security level information) of the transfer destination, When the encryption key of the data 400 is exchanged by encryption using a second encryption key (key ID = B) different from the one encryption key, and the ASIL of the transfer destination indicates the lowest security level, the first encryption key The data 400 is decrypted by decrypting the data 400 using (key ID = D). Thereby, security can be introduced for each transfer destination according to the ASIL of the transfer destination.

The ECU 2 (N301) receives the unencrypted raw data 402 and performs a predetermined process using the received raw data 402. On the other hand, the ECU 3 (N201) uses the encryption key corresponding to the key ID “B” distributed from the in-vehicle gateway device 1 to decrypt the encrypted data 403 having the data strength B, and uses the decrypted data. Predetermined processing.

In this way, the ECU 2 (N301) handles the data only by receiving the data without decoding the raw data 402. The ECU 3 (N201) handles the data by decoding the data 403 of the data strength B with the target algorithm (HMAC) when receiving the data.

As described above, according to the present embodiment, security can be introduced into the in-vehicle network in stages. Specifically, security can be easily introduced by allowing a mixture of a security function compatible ECU (with a decryption function) and a conventional ECU (without a decryption function).
In addition, the conventional ECU can be provided with a security function in the network without requiring a change man-hour. Since authentication and key management are performed at the gateway, security functions can be centrally managed at the gateway, enabling quick response to accidents.

Note that the present invention is not limited to the above-described embodiment, and includes various modifications. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. Further, a part of the configuration of an embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of an embodiment. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

In the above embodiment, values are stored in advance in each field of the routing table 3 and the security table 5, but they may be specified and registered from each ECU.

In addition, each of the above-described configurations, functions, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by a processor (microcomputer). Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

In addition, the following aspects may be sufficient as embodiment of this invention.

(1) In an in-vehicle processing device connected to another in-vehicle processing device, a storage unit storing safety information of the other in-vehicle processing device and data transmitted to the other in-vehicle processing device An in-vehicle processing device comprising: a transmission data processing unit that processes based on safety information of the in-vehicle processing device; and a transmission unit that transmits data processed by the transmission data processing unit to the other in-vehicle processing device.

(2) The in-vehicle processing device according to (1), wherein the transmission data processing unit is an encryption unit that encrypts data transmitted to the other in-vehicle processing device.

(3) The in-vehicle processing device according to (2), wherein the encryption unit sets an encryption level when encrypting the data based on the safety degree information.

(4) In the in-vehicle processing device according to (1), the encryption unit treats the data based on an identification number assigned to data transmitted from another in-vehicle gateway device. After specifying the gateway device, the information of the other in-vehicle processing device and the safety level information are collated to set an encryption level when transmitting the data.

(5) In the in-vehicle processing device according to (1), at least one of the plurality of in-vehicle gateway devices is an in-vehicle processing device.

(6) In the in-vehicle processing device according to (1), at least one of the plurality of in-vehicle processing devices is an ECU.

(7) A gateway device having a setting table in which a plurality of encryption levels are assigned to the in-vehicle processing device according to (1), and the encryption level is associated with the output destination in-vehicle device.

(8) A gateway device having a setting table in which a plurality of safety levels are assigned to the in-vehicle processing device according to (1), and a safety level is associated with an encryption level.

(9) A gateway device having a setting table in which a plurality of encryption methods are assigned to the in-vehicle processing device according to (1), and the encryption method is associated with the encryption level.

1 In-vehicle gateway device 2 Routing control (part)
3 Routing table 4 Security control (part)
5 Security Table 6 Encryption / Decryption Algorithm (CMAC)
7 Encryption / Decryption Algorithm (HMAC)
8 Key information 11 Microcomputer 12 SRAM
13 FLASH
14 Input / output device 15 Communication device 100 Safety level ASIL-D ECU
N101 ECU1
N102 ECU4
N200 ECU with safety level ASIL-B
N201 ECU3
N202 ECU5
ECU of N300 safety level ASIL-QM
N301 ECU2
N302 ECU6
400 Data strength D data 401 Received data 402 Raw data 403 Data strength B data 501 Key information B
502 Key information D

Claims

A receiving unit for receiving first data including an identifier;
A routing control unit that identifies a transfer destination corresponding to the identifier;
A security control unit that generates second data to be transferred from the first data to the transfer destination based on safety degree information indicating a safety degree required for the transfer destination;
A transmission unit for transmitting the second data to the transfer destination;
A vehicle-mounted processing device comprising:
The in-vehicle processing device according to claim 1,
The security control unit
The in-vehicle processing device, wherein the encryption strength of the second data is set according to the security level information of the transfer destination.
The in-vehicle processing device according to claim 2,
The first data is:
Encrypted,
The security control unit
The in-vehicle processing device characterized in that the second data is generated by exchanging an encryption key of the first data or releasing the encryption of the first data according to the safety degree information of the transfer destination. .
The in-vehicle processing device according to claim 3,
The first data is:
Encrypted with the first encryption key,
The security control unit
The first data is decrypted using the first encryption key and encrypted using a second encryption key different from the first encryption key according to the security level information of the transfer destination, thereby Exchange one data encryption key,
When the security level information of the transfer destination indicates the lowest level of security, the first data is decrypted using the first encryption key to decrypt the first data. In-vehicle processing device.
The in-vehicle processing device according to claim 2,
A storage device for storing a combination of the transfer destination and the safety degree information corresponding to the transfer destination;
The security control unit
The in-vehicle processing device, wherein the safety level information corresponding to the transfer destination is read from the storage device, and the encryption strength of the second data is set according to the read safety level information.
The in-vehicle processing device according to claim 5,
The storage device
Storing the safety information, and a combination of encryption methods corresponding to the safety information;
The security control unit
The in-vehicle processing device, wherein the encryption method corresponding to the safety degree information is read from the storage device, and the encryption strength of the second data is set using the read encryption method.
The in-vehicle processing device according to claim 6,
The storage device
Storing a combination of encryption key information indicating information on the safety level information and an encryption key corresponding to the safety level information;
The security control unit
The in-vehicle processing device, wherein the encryption key information corresponding to the security level information is read from the storage device, and the encryption key indicated by the read encryption key information is distributed to the transfer destination.
The in-vehicle processing device according to claim 1,
The safety information is
An in-vehicle processing apparatus characterized by being an automobile safety level ASIL.
An in-vehicle system including a first in-vehicle processing device, a second in-vehicle processing device, and a third in-vehicle processing device,
The first in-vehicle processing device
Sending first data including an identifier;
The second in-vehicle processing device is
A receiving unit for receiving the first data;
A routing control unit that identifies a transfer destination corresponding to the identifier;
A security control unit that generates second data to be transferred from the first data to the transfer destination based on safety degree information indicating a safety degree required for the transfer destination;
A transmission unit that transmits the second data to the third in-vehicle processing device that is the transfer destination,
The third in-vehicle processing device is
The in-vehicle system characterized by receiving the second data and performing a predetermined process using the received second data.