Security system, security device, and security method

Abstract

This security system comprises: a first communication device; and a second communication device capable of communicating with the first communication device through an on-board network. The first communication device includes: a first communication unit realized by first communication middleware; and a first function unit realized by first application software executed in the first communication middleware. The second communication device includes: a second communication unit realized by second communication middleware; and a second function unit realized by second application software executed in the second communication middleware. The first communication unit transmits first authentication information to the second communication device through the in-vehicle network, and the second communication unit receives the first authentication information through the in-vehicle network and executes first authentication processing on the basis of the received first authentication information.

Description

Security system, security device, and security method

[0001] This application claims priority to Japanese Patent Application No. 2024-065424, filed April 15, 2024, and incorporates by reference the entire contents of said Japanese application.

[0002] A vehicle is equipped with a variety of on-board devices, such as control system ECUs (Electronic Control Units) that control the engine, transmission, etc., body system ECUs that control headlights, power windows, etc., and information system ECUs for navigation devices, multimedia devices, etc. Each on-board device is connected to an on-board network and can communicate with each other.

[0003] There are cases where unauthorized in-vehicle devices are connected to an in-vehicle network masquerading as authorized in-vehicle devices, or where information transmitted through the in-vehicle network is tampered with. To address such fraud, AUTOSAR, a common platform for in-vehicle software, requires in-vehicle devices to implement port-based authentication based on Ternary Content Addressable Memory (TCAM) rules, Security Architecture for Internet Protocol (IPsec), and Media Access Control Security (MACsec) (see Non-Patent Document 1).

[0004] "Specification of Service Discovery", P.76, [online], November 23, 2020, AUTOSAR, [Searched March 14, 2020], Internet <URL: https: / / www.autosar.org / fileadmin / standards / R23-11 / CP / AUTOSAR_CP_SWS_ServiceDiscovery.pdf>

[0005] A security system according to one aspect of the present disclosure comprises a first communication device for service-oriented communication and a second communication device for service-oriented communication capable of communicating with the first communication device through an in-vehicle network, wherein the first communication device includes a first communication unit realized by first communication middleware and a first functional unit realized by first application software executed in the first communication middleware, and the second communication device includes a second communication unit realized by second communication middleware and a second functional unit realized by second application software executed in the second communication middleware, wherein the first communication unit transmits first authentication information to the second communication device through the in-vehicle network, and the second communication unit receives the first authentication information through the in-vehicle network and performs a first authentication process based on the received first authentication information.

[0006] FIG. 1 is a block diagram showing an example of the configuration of a security system according to an embodiment. FIG. 2 is a block diagram showing an example of the hardware configuration of an ECU according to an embodiment. FIG. 3 is a diagram showing an example of the functions of each device in the security system according to an embodiment. FIG. 4 is a diagram showing a message format of the SOME / IP protocol. FIG. 5 is a diagram showing a message format of the SOME / IP-SD protocol. FIG. 6 is a sequence diagram showing an example of a service discovery procedure in the security system according to an embodiment. FIG. 7 is a sequence diagram showing an example of a normal communication procedure in the security system according to an embodiment.

[0007] When using authentication using TCAM or MACsec, the hardware must support these authentication methods. When using IPsec, for example, the IP address or port number conversion algorithm (such as NAT (Network Address Translation) or NAPT (Network Address Port Translation)) used in the relay device must support IPsec. On the other hand, when using an authentication algorithm for fraud in application software (hereinafter also referred to as "application") implemented in each in-vehicle device, the authentication algorithm must be implemented for each application, which increases costs.

[0008] According to the present disclosure, it is possible to reduce the cost of ensuring security.

[0009] The following provides an outline of embodiments of the present disclosure.

[0010] (1) A security system according to this embodiment includes a first communication device for service-oriented communication and a second communication device for service-oriented communication capable of communicating with the first communication device through an in-vehicle network, the first communication device including a first communication unit implemented by first communication middleware and a first functional unit implemented by first application software executed in the first communication middleware, the second communication device including a second communication unit implemented by second communication middleware and a second functional unit implemented by second application software executed in the second communication middleware, the first communication unit transmitting first authentication information to the second communication device through the in-vehicle network, the second communication unit receiving the first authentication information through the in-vehicle network and performing first authentication processing based on the received first authentication information. This eliminates the need for hardware supporting security functions in the first communication device and the second communication device, and the need for security functions in the first application software and the second application software. Therefore, the cost for ensuring security can be reduced.

[0011] (2) In the above (1), the second communication unit may transmit second authentication information to the first communication device via the in-vehicle network, and the first communication unit may receive the second authentication information via the in-vehicle network and perform second authentication processing based on the received second authentication information. This allows the second communication middleware to transmit the second authentication information and the first communication middleware to perform the second authentication processing. Therefore, there is no need to install hardware supporting a security function in the first communication device or the second communication device, and there is no need to install a security function in the first application software or the second application software. This reduces the cost of ensuring security.

[0012] (3) In the above (1) or (2), the first communication unit may transmit the first authentication information together with search information for searching for a provider of a service used by the first function unit, and the second communication unit may receive the first authentication information together with the search information. This allows the first communication unit to transmit the first authentication information using a search function of the first communication middleware, and the second communication unit to receive the second authentication information using a search information reception function of the second communication middleware.

[0013] (4) In the above (2), the second communication unit may transmit the second authentication information together with notification information notifying that the second function unit is able to provide a service, and the first communication unit may receive the second authentication information together with the notification information. This allows the second communication unit to transmit the second authentication information using a notification function of the second communication middleware, and the first communication unit to receive the first authentication information using a notification information reception function of the first communication middleware.

[0014] (5) In any one of (1) to (4) above, the first authentication information may be a digital signature of the first communication device, and the first authentication process may be a process of verifying the digital signature. The first authentication process is a process of authenticating the first communication device executed by the second communication device. This makes it possible to verify the legitimacy of the first communication device using the digital signature and ensure security.

[0015] (6) In the above (1) or (2), the first communication unit may transmit the first authentication information together with request information requesting the provision of data used by the first function unit, and the second communication unit may receive the first authentication information together with the request information. This allows the first communication unit to transmit the first authentication information using a data request function of the first communication middleware, and the second communication unit to receive the second authentication information using a request information reception function of the second communication middleware.

[0016] (7) In the above (2), when the second function unit is capable of providing data used by the first function unit, the second communication unit may transmit the second authentication information together with the data, and the first communication unit may receive the second authentication information together with the data. This allows the second communication unit to transmit the second authentication information using a data transmission function of the second communication middleware, and the first communication unit to receive the first authentication information using a data reception function of the first communication middleware.

[0017] (8) In any one of (1), (2), (6), and (7), the first authentication information may be a message authentication code generated from the request information, and the first authentication process may be a process of verifying the message authentication code. The first authentication process is a process of authenticating a message from the first communication device, executed by the second communication device. This makes it possible to verify the legitimacy of the request information transmitted from the first communication device using the message authentication code, thereby ensuring security.

[0018] (9) A security device according to this embodiment is capable of communicating with a communication device for service-oriented communication via an in-vehicle network. The security device includes a communication unit implemented by communication middleware and a functional unit implemented by application software executed in the communication middleware. The communication unit transmits authentication information to the communication device via the in-vehicle network for authentication processing by the communication device. This eliminates the need for hardware supporting security functions in the security device, and eliminates the need for security functions in the application software, since the authentication information is transmitted by the communication middleware. This reduces the cost of ensuring security.

[0019] (10) A security method according to this embodiment is a security method used by a security device capable of communicating with a communication device for service-oriented communication via an in-vehicle network, and includes a step of transmitting authentication information to the communication device via the in-vehicle network by communication middleware that executes application software for authentication processing by the communication device. This eliminates the need to install hardware supporting security functions in the security device and the need to install security functions in the application software, since the authentication information is transmitted by the communication middleware. This reduces the cost of ensuring security.

[0020] The present disclosure can be realized not only as a security system having the above-described characteristic configuration, a security device having the characteristic configuration, and a security method having characteristic processing steps, but also as a computer program for causing a computer to execute the characteristic processing, or as a semiconductor integrated circuit in which part or all of the security device is implemented.

[0021] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. At least some of the following preferred embodiments may be combined in any desired manner.

[0022] 1. Security System] Fig. 1 is a block diagram showing an example of the configuration of a security system according to an embodiment. The security system 10 according to the embodiment includes an in-vehicle system 100, a traffic signal controller 500, and an OTA server 600.

[0023] The vehicle is equipped with an in-vehicle network 40. In Fig. 1, the boundary between the inside and outside of the vehicle is indicated by a dashed line. The in-vehicle network 40 according to the embodiment is an Ethernet network capable of communication via Ethernet (registered trademark), and more specifically, an IP (Internet Protocol) network. The in-vehicle network 40 includes a relay ECU 200 and communication lines 400A, 400B, 400C, and 400D, which are Ethernet cables.

[0024] The in-vehicle system 100 includes a relay ECU 200 and ECUs 300A, 300B, and 300C.

[0025] The multiple ECUs 300A, 300B, and 300C are arranged in various parts of the vehicle. The ECUs 300A, 300B, and 300C individually control the hardware of the various parts of the vehicle, and detect or monitor the state of the hardware of the various parts of the vehicle, the state around the vehicle, or objects around the vehicle. For example, the ECUs 300A, 300B, and 300C are ECUs for a control system, a body system, and an information system. In the following description, the ECUs 300A, 300B, and 300C are also collectively referred to as "ECU 300."

[0026] The functions of ECU 300 are realized by software. That is, ECU 300 can store and execute application software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle.

[0027] Specifically, the ECU 300A is a driving assistance ECU that has driving assistance functions including autonomous driving. The ECU 300A performs autonomous driving of the vehicle using camera images of the surroundings of the vehicle, detection results from various sensors, a planned driving route calculated by a navigation system, the lighting status of traffic lights, etc.

[0028] The ECU 300A includes a communication middleware 50A and application software 61C that implements a driving assistance function. The application software 61C is executed on the communication middleware 50A.

[0029] The ECU 300B is a camera control ECU that controls the camera 70 for monitoring the surroundings of the vehicle. The ECU 300B controls the camera 70 to capture images of the surroundings (camera images). The ECU 300B transmits the camera images obtained by the camera 70 in response to requests from other ECUs.

[0030] The ECU 300B includes a communication middleware 50B and application software 61S_1 that implements a camera control function. The application software 61S_1 is executed on the communication middleware 50B.

[0031] The application software 61S_1 is a server application (hereinafter also referred to as "server APP") that provides camera images. The application software 61C is a client application (hereinafter also referred to as "APP") of the server APP 61S_1. The client APP 61C requests camera images for autonomous driving. The server APP 61S_1 provides camera images in response to a request from the client APP 61C.

[0032] The ECU 300C is a car navigation ECU having a first function of the car navigation system. In order to determine a planned driving route of the vehicle, the ECU 300C acquires the current location of the vehicle from a Global Navigation Satellite System (GNSS) receiver (not shown) and acquires a destination input by a user to an input device (e.g., a touch sensor) (not shown).

[0033] The ECU 300C includes a communication middleware 50C and application software 62C that implements a first function of the navigation system. The application software 62C is executed on the communication middleware 50C.

[0034] The relay ECU 200 includes a plurality of ports, and communication lines 400A, 400B, 400C, and 400D are connected to the respective ports. The communication line 400A is connected to the ECU 300A. The communication line 400B is connected to the ECU 300B. The communication line 400C is connected to the ECU 300C. The communication line 400D is connected to the external communication device 350.

[0035] The relay ECU 200 relays communication between the communication lines 400A, 400B, 400C, and 400D. The ECUs 300A, 300B, and 300C and the external communication device 350 can communicate with each other via the relay ECU 200.

[0036] For example, the relay ECU 200 may be connected to another relay ECU.

[0037] The external communication device 350 can transmit and receive frames between the ECUs 300A, 300B, and 300C and the relay ECU 200. The external communication device 350 is, for example, a TCU (Telematics Control Unit) and can communicate with devices outside the vehicle. The external communication device 350 has a wireless communication interface for a mobile communication system, such as a fifth-generation mobile communication system (5G) or a fourth-generation mobile communication system (4G). The external communication device 350 can perform communication according to, for example, TCP / IP (Transmission Control Protocol / Internet Protocol) packets or UDP / IP (User Datagram Protocol / Internet Protocol). The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with a traffic signal controller 500 and an OTA server 600. The external communication device 350 relays communications between the ECUs 300A, 300B, and 300C, and the relay ECU 200, and external devices (including the traffic signal controller 500 and the OTA server 600).

[0038] The traffic signal controller 500 is connected to the traffic signal 80 and controls the traffic signal 80. The traffic signal 80 has a function (hereinafter also referred to as a "signal information providing function") of providing signal information indicating the current state of the traffic signal 80. The signal information includes, for example, the current light color, the remaining time for the light color to be turned on, etc.

[0039] The traffic signal controller 500 includes a communication middleware 50E and application software 61S_2 that implements a traffic signal control function. The application software 61S_2 runs on the communication middleware 50E.

[0040] The application software 61S_2 is a server APP that provides traffic light information. The application software 61C is a client APP of the server APP 61S_2. The client APP 61C requests traffic light information for autonomous driving. The server APP 61S_2 provides the traffic light information in response to a request from the client APP 61C.

[0041] For example, the relay ECU 200 has a function as an ECU in addition to the relay function. In a specific example, the relay ECU 200 has a second function of a car navigation system. The relay ECU 200 stores map data or receives map data from a map server (not shown), and calculates a planned driving route from the current location of the vehicle to the destination based on the map data.

[0042] The relay ECU 200 includes a communication middleware 50D and application software 62S that implements a second function of the navigation system. The application software 62S is executed on the communication middleware 50C.

[0043] The application software 62S is a server APP that provides the calculation results of the planned driving route. The application software 62C is a client APP of the server APP 62S. The client APP 62C outputs the current location acquired from the GNSS receiver and the destination input by the user, and requests calculation of the planned driving route. The server APP 62S accepts the current location and destination output from the client APP 62C, and calculates the planned driving route of the vehicle in response to the request from the client APP 62C. The server APP 62S provides the calculated planned driving route to the requestor.

[0044] In another example, the relay ECU 200 has a function (OTA master function) of managing updates to application software of the ECU 300. The relay ECU 200 further includes application software 63S that realizes the update management function for the application software. The application software 63S is executed on the communication middleware 50C.

[0045] The OTA (Over The Air) server 600 provides software for updating application software (hereinafter also referred to as "update software" or "update SW") to the relay ECU 200, which is the OTA master. That is, the OTA server 600 transmits the update software when an update of the application software is necessary. The update of the application software includes changing the functions realized by the application software (changing at least a part of the functions), adding functions, and deleting functions.

[0046] External communication device 350 receives the update software and transfers the received update software to relay ECU 200, which is the OTA master. Relay ECU 200 stores the update software and, when it is time to update the application software of ECU 300 to be updated, transmits the update software to ECU 300. Upon receiving the update software, ECU 300 to be updated restarts, and after restarting, executes the update software to update the application software.

[0047] To determine whether an application software update is necessary, the OTA server 600 uses version information of the application software installed in each ECU 300 and the relay ECU 200. For example, the OTA server 600 compares the version of new application software (hereinafter also referred to as "new software") with the version of the application software installed in the ECU 300 (hereinafter also referred to as "current software"), and determines that the application software needs to be updated if the version of the new software is newer than the version of the current software. If the version of the new software is not newer than the version of the current software, the OTA server 600 determines that the application software does not need to be updated.

[0048] The relay ECU 200 has a function of collecting version information of the ECUs 300A, 300B, 300C and the application software 61C, 61S_1, 62C, 62S, 63S of the relay ECU 200 and providing the collected version information (hereinafter also referred to as the "version information providing function").

[0049] The OTA server 600 includes a communication middleware 50F and application software 63C that implements the functions of the OTA server. The application software 63C runs on the communication middleware 50F.

[0050] Application software 63S is a server APP that provides version information. Application software 63C is a client APP of server APP 63S. Client APP 63C requests version information of the application software in order to determine whether or not the application software in each ECU 300 and relay ECU 200 needs to be updated. In response to a request from client APP 61C, server APP 63S collects version information of the application software in each ECU 300 and relay ECU 200 and provides the collected version information.

[0051] 2. Hardware Configuration of ECU] Fig. 2 is a block diagram showing an example of a hardware configuration of an ECU according to the embodiment. The ECU 300A includes a processor 301, a non-volatile memory 302, a volatile memory 303, and a communication interface 304.

[0052] 2 shows the hardware configuration of ECU 300A as a representative, the hardware configurations of ECUs 300B and 300C are similar. Similarly to ECU 300A, relay ECU 200, traffic signal controller 500, and OTA server 600 each include a processor, a non-volatile memory, a volatile memory, and one or more communication interfaces.

[0053] The processor 301, the nonvolatile memory 302, the volatile memory 303, and the communication interface 304 are connected to one another by a bus (data bus) 305. The processor 301, the nonvolatile memory 302, the volatile memory 303, and the communication interface 304 can transmit data to one another via the bus 305.

[0054] The volatile memory 303 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The nonvolatile memory 302 is a rewritable nonvolatile memory such as a flash memory or a hard disk. The nonvolatile memory 302 stores the client APP 61C and the communication middleware 50A.

[0055] The processor 301 is, for example, a CPU (Central Processing Unit). However, the processor 301 is not limited to a CPU. The processor 301 may be a GPU (Graphics Processing Unit). In a specific example, the processor 301 is a multi-core processor. The processor 301 may be a single-core processor. The processor 301 is configured to be able to execute a computer program. However, the processor 301 may include, for example, an ASIC (Application Specific Integrated Circuit) in part, or may include a programmable logic device such as an FPGA (Field Programmable Gate Array) in part.

[0056] The communication interface 304 is a communication interface that complies with the above-mentioned communication protocol for the in-vehicle network. That is, the communication interface 304 is, for example, an Ethernet interface. In another example, the communication interface 304 is an Ethernet interface.

[0057] The communication interface 304 is connected to the communication line 400 A. The ECU 300 A can communicate with the ECUs 300 B and 300 C, the relay ECU 200 , the traffic signal controller 500 , and the OTA server 600 via the communication interface 304 .

[0058] 3. Functions of Each Device FIG. 3 is a diagram showing an example of the functions of each device in the security system according to the embodiment.

[0059] ECU 300A has the functions of a functional unit 610C and a communication unit 510A. Functional unit 610C is realized by processor 301 executing client APP 61C. Communication unit 510A is realized by processor 301 executing communication middleware 50A. Functional unit 610C includes a function for requesting camera images and a function for requesting signal information.

[0060] The ECU 300B has the functions of a functional unit 610S_1 and a communication unit 510B. The functional unit 610S_1 is realized by the processor executing a server APP 61S_1. The communication unit 510B is realized by the processor executing communication middleware 50B. The functional unit 610S_1 includes a function of providing a camera image.

[0061] ECU 300C has the functions of a functional unit 620C and a communication unit 510C. Functional unit 620C is realized by a processor executing client APP 62C. Communication unit 510C is realized by a processor executing communication middleware 50C. Functional unit 620C includes a function of requesting calculation of a planned driving route.

[0062] The relay ECU 200 has the functions of functional units 620S, 630S and a communication unit 510D. The functional unit 620S is realized by the processor executing a server APP 62S. The functional unit 630S is realized by the processor executing a server APP 63S. The communication unit 510D is realized by the processor executing communication middleware 50D. The functional unit 620S includes a function of calculating a planned driving route for the vehicle and providing the calculated planned driving route. The functional unit 630S includes a function of collecting version information of application software from each ECU 300 and the relay ECU 200 and providing the collected version information.

[0063] The traffic signal controller 500 has the functions of a functional unit 610S_2 and a communication unit 510E. The functional unit 610S_2 is realized by the processor executing a server APP 61S_2. The communication unit 510E is realized by the processor executing a communication middleware 50E. The functional unit 610S_2 includes a function of providing traffic signal information.

[0064] The OTA server 600 has the functions of a functional unit 630C and a communication unit 510F. The functional unit 630C is realized by the processor executing the client APP 63C. The communication unit 510F is realized by the processor executing the communication middleware 50F. The functional unit 630C includes a function to request version information of the application software of each ECU 300 and the relay ECU 200.

[0065] The communication middleware 50A, 50B, 50C, 50D, 50E, and 50F are common communication middleware. That is, the communication units 510A, 510B, 510C, 510D, 510E, and 510F are common communication functions. Hereinafter, the communication middleware 50A, 50B, 50C, 50D, 50E, and 50F are collectively referred to as "communication middleware 50," and the communication units 510A, 510B, 510C, 510D, 510E, and 510F are collectively referred to as "communication unit 510."

[0066] The communication middleware 50 is, for example, SOME / IP (Scalable service-oriented middleware over IP). SOME / IP is middleware for performing communication between devices, known as service-oriented communication. In service-oriented communication, a server performs communication to provide services to a client. For example, the above-mentioned functions of providing camera images, traffic signal information, planned driving routes, and application software version information are each a service.

[0067] The communication unit 510 of the client (i.e., the device that executes the client application) transmits the authentication information to the server (i.e., the device that executes the server application) via the in-vehicle network 40 .

[0068] The client is an example of a “security device.” The client is also an example of a “first communication device.” In other words, ECUs 300A and 300C and OTA server 600 are the “security device” and the “first communication device.”

[0069] For example, if the communication unit 510 of the client can identify a server that provides the desired service, it transmits the authentication information to that server. For example, if the communication unit 510 of the client cannot identify a server that provides the desired service, it multicasts the authentication information.

[0070] The communication unit 510 of the server transmits the authentication information to the client through the in-vehicle network 40 .

[0071] The server is an example of a “security device.” The server is also an example of a “second communication device.” In other words, the ECU 300B, the relay ECU 200, and the traffic signal controller 500 are the “security device” and the “second communication device.”

[0072] For example, if the communication unit 510 of the server can identify a client that requests a service provided by the server, it transmits authentication information to that client. For example, if the communication unit 510 of the server cannot identify a client that requests a service provided by the server, it multicasts the authentication information.

[0073] In SOME / IP, a client requests a server to provide a service, and the server provides the service to the client in response to the request.

[0074] SOME / IP uses the SOME / IP protocol, which is a higher-level protocol than TCP and UDP and is a communication protocol at layers 5 to 7 in the OSI reference model.

[0075] FIG. 4 is a diagram showing a message format of the SOME / IP protocol.

[0076] The message format shown in Fig. 4 is used in communication after a service subscription has been set for a client (hereinafter also referred to as "normal communication"). In normal communication, the client requests the provision of data to be used (Request), and the server provides the requested data (Response). That is, in response to a Request from a client, the communication unit 510 of the client transmits the message shown in Fig. 4 to the server, and in response from the server, the communication unit 510 of the server transmits the message shown in Fig. 4 to the client. The Request is an example of "request information."

[0077] In the message format shown in Fig. 4, Service ID is identification information of the service, and Client ID is identification information of the client.

[0078] In normal communication, for example, authentication information is stored in the payload of a message. In normal communication, for example, authentication information is a message authentication code (MAC). The message authentication code is information for authenticating a message. The message authentication code is generated by encrypting a message using a common key held by each of the client and server. However, the authentication information is not limited to a message authentication code of a common key cryptosystem that is decrypted using the common key. The authentication information used in normal communication may be information encrypted using another cryptosystem (e.g., public key cryptosystem, hybrid cryptosystem) as long as it is information for authenticating a message. For example, when a client is a message sending device, the client generates a message authentication code and sends a message (Request) with the generated message authentication code stored in the payload.

[0079] The communication unit 510 of the message receiving device performs authentication processing based on the received authentication information. For example, if the message receiving device is a server, the communication unit 510 of the server performs authentication processing based on the authentication information added to the request. This confirms the validity of the request.

[0080] For example, if the communication unit 510 of the server is successful in authenticating the request, it notifies the functional unit of the data request. The functional unit outputs the requested data to the communication unit 510. For example, if the communication unit 510 of the server is unsuccessful in authenticating the request, it does not notify the functional unit of the data request.

[0081] For example, if the server is the message sending device, the server generates a message authentication code and transmits a message (Response) with the generated message authentication code stored in its payload. That is, the communication unit 510 of the server generates a Response with the data received from the functional unit and the generated message authentication code stored in its payload, and transmits the generated Response.

[0082] For example, if the client is the device receiving the message, the communication unit 510 of the client executes authentication processing based on the authentication information added to the response, thereby confirming the validity of the response.

[0083] For example, if the communication unit 510 of the client is successful in authenticating the response, it outputs the data added to the response to the functional unit. The functional unit uses the received data for the service. For example, if the communication unit 510 of the client is unsuccessful in authenticating the response, it does not output the data to the functional unit.

[0084] In order for a server to provide a service to a client, the client must identify which device is the server that provides the desired service, and the server must identify which device is the client requesting the service. For this reason, SOME / IP has a function called service discovery. Service discovery allows a client to request a service subscription from a server that provides the desired service, and the server can set up a service subscription for the client.

[0085] For service discovery, the SOME / IP-SD (Service Discovery) protocol is used.

[0086] FIG. 5 is a diagram showing a message format of the SOME / IP-SD protocol.

[0087] The SOME / IP-SD protocol uses a message format that is an extension of the message format of the SOME / IP protocol used in normal communication. In service discovery, a client searches for a service provider (Find), and a server offers to provide the service (Offer). That is, in a Find from a client, the client's communication unit 510 sends the message shown in Fig. 5 to the server, and in an Offer from the server, the server's communication unit 510 sends the message shown in Fig. 5 to the client. Find is an example of "search information," and Offer is an example of "notification information."

[0088] In service discovery, for example, authentication information is stored in the Option Array of a message. In service discovery, for example, authentication information is the digital signature of the sending device. A user creates a digital signature in advance using a private key and stores the digital signature in non-volatile memory of the sending device. The digital signature is information generated by, for example, encrypting a hash value generated from the code of application software with the private key. For example, when a client is the sending device of a message, the communication unit 510 of the client transmits a message (Find) in which the digital signature generated from the code of the client APP is stored in the Option Array.

[0089] The communication unit 510 of the message receiving device performs authentication processing based on the received digital signature. For example, if the message receiving device is a server, the communication unit 510 of the server performs authentication processing based on the digital signature attached to Find. That is, the communication unit 510 of the server decrypts the digital signature using a public key stored in advance, compares the hash value obtained by the decryption with a hash value generated from the code of the client APP, and verifies whether the client is legitimate. This confirms the legitimacy of the client. However, the authentication information is not limited to a digital signature using a public key cryptography method decrypted using a public key. The authentication information used in service discovery may be information encrypted using another cryptography method (e.g., a symmetric key cryptography method or a hybrid cryptography method) as long as it authenticates the message sending device.

[0090] For example, if the communication unit 510 of the server succeeds in authenticating a client using a digital signature, it sends an offer addressed to the client. For example, if the communication unit 510 of the server fails to authenticate a client, it does not send an offer addressed to the client.

[0091] For example, when a server is a message sending device, the communication unit 510 of the server sends a message (Offer) in which a digital signature generated from the code of the server APP is stored in the Option Array.

[0092] The client's communication unit 510 executes authentication processing based on the digital signature attached to the Offer. That is, the client's communication unit 510 decrypts the digital signature using a public key stored in advance, compares the hash value obtained by decryption with the hash value generated from the code of the server APP, and verifies whether the server is legitimate. This confirms the legitimacy of the server.

[0093] For example, if the communication unit 510 of the client is successful in authenticating the server using a digital signature, it notifies the functional unit that the server can provide the desired service. For example, if the communication unit 510 of the client is unsuccessful in authenticating the server, it does not notify the functional unit that the server can provide the desired service.

[0094] [4. Operation of the Security System] Figure 6 is a sequence diagram showing an example of a service discovery procedure in the security system according to the embodiment. Figure 6 shows service discovery between the driving assistance ECU 300A (client) and the camera control ECU 300B (server) as an example. However, service discovery between other clients and servers is similar. In the following description, although the operations of each device are executed by a processor, for simplicity, software (application software, communication middleware) will be referred to as the entity that executes the operations. For example, the execution entity and operation of application software refers to the operation of a processor that executes the application software, and the execution entity and operation of communication middleware refers to the operation of a processor that executes the communication middleware.

[0095] When the vehicle starts traveling, the client APP 61C of the ECU 300A starts autonomous driving. In this case, the client APP 61C needs data to be used for autonomous driving, such as camera images of the vehicle's surroundings, detection results from various sensors, a planned driving route calculated by a navigation system, and the status of traffic lights. For this reason, an interrupt is generated from the client APP 61C to the communication middleware 50A to request a camera image provision service.

[0096] The communication middleware 50A creates a Find message in the SOME / IP-SD protocol. The communication middleware 50A creates an electronic signature for authenticating the ECU 300A, or reads a pre-created electronic signature from the non-volatile memory 302 and stores the electronic signature in the Find Option Array.

[0097] The communication middleware 50A transmits the Find command with the digital signature attached (step S1). At this time, the ECU 300A has not yet specified a device (ECU 300B) that can provide camera images. Therefore, the Find command is multicast.

[0098] The communication middleware 50B of the EUC 300B receives the Find command, extracts the digital signature from the received Find command, and executes authentication processing using the digital signature (verification processing of the digital signature) (step S2).

[0099] If the communication middleware 50B has successfully authenticated the ECU 300A using the electronic signature, the communication middleware 50B notifies the server APP 61S that the client requesting the camera image providing service is the ECU 300A. On the other hand, if the communication middleware 50B has failed to authenticate the ECU 300A using the electronic signature, the communication middleware 50B does not notify the server APP 61S that the client requesting the camera image providing service is the ECU 300A. Figure 6 shows the procedure when the authentication of the ECU 300A using the electronic signature is successful.

[0100] When the communication middleware 50B notifies the server APP 61CA that the client requesting the camera image providing service is the ECU 300A, the communication middleware 50B creates an Offer message in the SOME / IP-SD protocol. The communication middleware 50B creates an electronic signature for authenticating the ECU 300B, or reads a previously created electronic signature from a nonvolatile memory and stores the electronic signature in the Option Array of the Offer.

[0101] The communication middleware 50B transmits the Offer with the digital signature attached (step S3). At this time, the device (ECU 300A) requesting the camera image providing service has been identified in the ECU 300B. Therefore, the Find is unicast to the ECU 300A.

[0102] The communication middleware 50A of the EUC 300A receives the Offer, extracts the digital signature from the received Offer, and executes authentication processing using the digital signature (verification processing of the digital signature) (step S4).

[0103] If the communication middleware 50A successfully authenticates the ECU 300B using the digital signature, it notifies the client APP 61C that the ECU 300B is a server that can provide the camera image providing service. On the other hand, if the communication middleware 50B fails to authenticate the ECU 300B using the digital signature, it does not notify the client APP 61C that the ECU 300B is a server that can provide the camera image providing service. This completes the service discovery.

[0104] 7 is a sequence diagram showing an example of a procedure for normal communication in the security system according to the embodiment. As an example, FIG. 7 shows normal communication between the driving assistance ECU 300A (client) and the camera control ECU 300B (server). However, normal communication between other clients and servers is similar.

[0105] During autonomous driving, the client APP 61C of the ECU 300A periodically requires data such as camera images of the vehicle's surroundings, detection results from various sensors, a planned driving route calculated by the navigation system, the status of traffic lights, etc. For this reason, an interrupt is generated from the client APP 61C to the communication middleware 50A to request camera images.

[0106] The communication middleware 50A creates a Request message in the SOME / IP protocol, creates a message authentication code for authenticating the Request message, and stores the message authentication code in the payload of the Request.

[0107] The communication middleware 50A transmits (unicasts) the Request to which the message authentication code has been added to the ECU 300B (step S11).

[0108] The communication middleware 50B of the EUC 300B receives the request, extracts the message authentication code from the received request, and performs authentication processing using the message authentication code (verification processing of the message authentication code) (step S12).

[0109] If the communication middleware 50B succeeds in authenticating the request using the message authentication code, it notifies the server APP 61S of the camera image request from the client. On the other hand, if the communication middleware 50B fails to authenticate the request using the message authentication code, it does not notify the server APP 61S of the camera image request from the client. Figure 7 shows the procedure when the request is successfully authenticated using the message authentication code.

[0110] When the server APP 61S receives a request for a camera image, it outputs the latest camera image to the communication middleware 50B. The communication middleware 50B creates a Response message in the SOME / IP protocol. The communication middleware 50B stores the camera image in the payload of the Response. Furthermore, the communication middleware 50B creates a message authentication code for authenticating the Response message and stores the message authentication code in the payload of the Response.

[0111] The communication middleware 50B transmits (unicasts) the response to which the message authentication code has been added to the ECU 300A (step S13).

[0112] The communication middleware 50A of the EUC 300A receives the response, extracts the message authentication code and the camera image from the received response, and executes authentication processing using the message authentication code (step S14).

[0113] If the communication middleware 50A successfully authenticates the response using the message authentication code, it outputs the camera image provided by the server to the client APP 61C. On the other hand, if the communication middleware 50A fails to authenticate the response using the message authentication code, it does not output the camera image provided by the server to the client APP 61C. This completes one cycle of normal communication. The above cycle is executed, for example, periodically.

[0114] 5. Variations In the above-described embodiment, both authentication processing using a digital signature in service discovery and authentication processing using a message authentication code in normal communication are performed, but this is not limiting. For example, authentication processing using a digital signature may be performed in service discovery but not in normal communication, or authentication processing may not be performed in service discovery but authentication processing using a message authentication code may be performed in normal communication.

[0115] In the above-described embodiment, authentication information is transmitted and received between devices via the in-vehicle network 40, which is an Ethernet network, using SOME / IP, which is a higher-level protocol than TCP and UDP. However, the present invention is not limited to this. For example, in an in-vehicle network that is a Controller Area Network (CAN) network, authentication information may be transmitted and received between devices using a communication protocol based on communication middleware defined as a higher-level protocol than CAN (for example, SOME / IP modified for CAN).

[0116] [6. Supplementary Note] A security program used by a security device capable of communicating with a communication device through an in-vehicle network, the security program causing a computer to execute a step of transmitting authentication information to the communication device through the in-vehicle network by communication middleware that executes application software for authentication processing by the communication device, the security program being included in the communication middleware.

[0117] [7. Supplementary Note] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present disclosure is defined by the claims, not the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof.

[0118] 10 Security system 100 In-vehicle system 200 Relay ECU (security device) 40 In-vehicle network 300 ECU (security device) 301 Processor 302 Non-volatile memory 303 Volatile memory 304 Communication interface 305 Bus 350 External communication device 400A, 400B, 400C, 400D Communication line 500 Traffic signal controller (security device) 600 OTA server (security device) 50, 50A, 50B, 50C, 50D, 50E, 50F Communication middleware 61C, 61S_1, 61S_2, 62C, 62S, 63C, 63S Application software 510, 510A, 510B, 510C, 510D, 510E, 510F Communication unit 610C, 610S_1, 610S_2, 620C, 620S, 630C, 630S Functional unit 70 Camera 80 Traffic signal

Claims

1. A security system comprising: a first communication device for service-oriented communication; and a second communication device for service-oriented communication capable of communicating with the first communication device through an in-vehicle network; wherein the first communication device includes a first communication unit realized by first communication middleware and a first functional unit realized by first application software executed in the first communication middleware; the second communication device includes a second communication unit realized by second communication middleware and a second functional unit realized by second application software executed in the second communication middleware; the first communication unit transmits first authentication information to the second communication device through the in-vehicle network; and the second communication unit receives the first authentication information through the in-vehicle network and performs a first authentication process based on the received first authentication information.

2. The security system described in claim 1, wherein the second communication unit transmits second authentication information to the first communication device via the in-vehicle network, and the first communication unit receives the second authentication information via the in-vehicle network and performs second authentication processing based on the received second authentication information.

3. A security system as described in claim 1 or claim 2, wherein the first communication unit transmits the first authentication information together with search information for searching for a provider of a service used by the first function unit, and the second communication unit receives the first authentication information together with the search information.

4. The security system described in claim 2, wherein the second communication unit transmits the second authentication information together with notification information notifying that the second function unit is able to provide a service, and the first communication unit receives the second authentication information together with the notification information.

5. A security system according to any one of claims 1 to 4, wherein the first authentication information is an electronic signature of the first communication device, and the first authentication process is a process of verifying the electronic signature.

6. A security system as described in claim 1 or claim 2, wherein the first communication unit transmits the first authentication information together with request information requesting the provision of data to be used by the first function unit, and the second communication unit receives the first authentication information together with the request information.

7. The security system described in claim 2, wherein, when the second function unit is capable of providing data to be used by the first function unit, the second communication unit transmits the second authentication information together with the data, and the first communication unit receives the second authentication information together with the data.

8. A security system as described in any one of claims 1, 2, 6 and 7, wherein the first authentication information is a message authentication code generated from the request information, and the first authentication process is a process of verifying the message authentication code.

9. A security device capable of communicating with a communication device for service-oriented communication through an in-vehicle network, comprising: a communication unit realized by communication middleware; and a functional unit realized by application software executed in the communication middleware, wherein the communication unit transmits authentication information to the communication device through the in-vehicle network for authentication processing by the communication device.

10. A security method used by a security device capable of communicating with a communication device for service-oriented communication through an in-vehicle network, the security method comprising a step of transmitting authentication information to the communication device through the in-vehicle network by communication middleware executing application software for authentication processing by the communication device.

Images