[go: up one dir, main page]

WO2024154585A1 - 車載装置、情報処理方法及び、車載システム - Google Patents

車載装置、情報処理方法及び、車載システム Download PDF

Info

Publication number
WO2024154585A1
WO2024154585A1 PCT/JP2023/047307 JP2023047307W WO2024154585A1 WO 2024154585 A1 WO2024154585 A1 WO 2024154585A1 JP 2023047307 W JP2023047307 W JP 2023047307W WO 2024154585 A1 WO2024154585 A1 WO 2024154585A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
service
ecu
data
security level
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/047307
Other languages
English (en)
French (fr)
Inventor
亮 倉地
広章 高田
浩史 上田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sumitomo Wiring Systems Ltd
AutoNetworks Technologies Ltd
Sumitomo Electric Industries Ltd
Tokai National Higher Education and Research System NUC
Original Assignee
Sumitomo Wiring Systems Ltd
AutoNetworks Technologies Ltd
Sumitomo Electric Industries Ltd
Tokai National Higher Education and Research System NUC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sumitomo Wiring Systems Ltd, AutoNetworks Technologies Ltd, Sumitomo Electric Industries Ltd, Tokai National Higher Education and Research System NUC filed Critical Sumitomo Wiring Systems Ltd
Priority to CN202380090739.3A priority Critical patent/CN120530600A/zh
Publication of WO2024154585A1 publication Critical patent/WO2024154585A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation

Definitions

  • the present disclosure relates to an in-vehicle device, an information processing method, and an in-vehicle system.
  • This application claims priority based on Japanese Application No. 2023-4583 filed on January 16, 2023, and incorporates by reference all of the contents of the above-mentioned Japanese application.
  • CAN Controller Area Network
  • Patent Document 1 proposes an integrated detection and control device that is connected to a vehicle's CAN, causes on-board equipment to perform operations using device diagnostic commands, reads status response data sent by the on-board equipment, and determines the operating status of the on-board equipment.
  • An in-vehicle device is an in-vehicle device communicably connected to an in-vehicle ECU mounted on a vehicle, and includes a control unit that performs processing related to a service request from the in-vehicle ECU, and the control unit acquires request data related to the service request from the in-vehicle ECU, identifies a service to be provided to the in-vehicle ECU and a security level when providing the service based on the acquired request data, generates provision data for providing the service to the in-vehicle ECU based on the identified security level, and outputs the generated provision data to the in-vehicle ECU.
  • FIG. 1 is a schematic diagram illustrating a configuration of an in-vehicle system including an in-vehicle device according to a first embodiment
  • FIG. 2 is a block diagram illustrating a physical configuration of an in-vehicle device.
  • FIG. 11 is an explanatory diagram illustrating a service table.
  • FIG. 11 is an explanatory diagram illustrating a security processing table.
  • FIG. 2 is an explanatory diagram illustrating a protected SOME/IP message.
  • FIG. 2 is an explanatory diagram illustrating a processing sequence between an in-vehicle device (server) and an in-vehicle ECU (client).
  • 4 is a flowchart illustrating a process of a control unit of an in-vehicle device.
  • FIG. 1 is a schematic diagram illustrating a configuration of an in-vehicle system including an in-vehicle device according to a first embodiment
  • FIG. 2 is a block diagram illustrating a physical configuration of an in-veh
  • FIG. 11 is an explanatory diagram illustrating a processing sequence between an in-vehicle device (server) and an in-vehicle ECU (client) according to a second embodiment (dynamic change of security level).
  • 4 is a flowchart illustrating a process of a control unit of an in-vehicle device.
  • FIG. 13 is a functional block diagram illustrating functional units included in a control unit of an in-vehicle device according to a third embodiment (inter-process communication within an in-vehicle device).
  • Patent Document 1 does not take into consideration the fact that when request data regarding a service request is sent from an on-board ECU (Electronic Control Unit), provision data is generated and output that has undergone appropriate security processing for the request data.
  • ECU Electronic Control Unit
  • the objective of this disclosure is to provide an in-vehicle device etc. that, when request data related to a service request is sent from the in-vehicle ECU, can output provided data that has been subjected to appropriate security processing for the request data.
  • An in-vehicle device is an in-vehicle device communicatively connected to an in-vehicle ECU mounted on a vehicle, and includes a control unit that performs processing related to a service request from the in-vehicle ECU, and the control unit acquires request data related to the service request from the in-vehicle ECU, identifies a service to be provided to the in-vehicle ECU and a security level when providing the service based on the acquired request data, generates provision data for providing the service to the in-vehicle ECU based on the identified security level, and outputs the generated provision data to the in-vehicle ECU.
  • the vehicle-mounted device and the vehicle ECU communicate with each other via an in-vehicle network, and perform communication regarding requests and provision of services executed by the vehicle-mounted device.
  • an in-vehicle device that handles processing related to a rear camera executes a service that outputs an image (service instance) captured by the rear camera via the in-vehicle network.
  • the in-vehicle ECU can receive the provision of a service related to the rear camera from the in-vehicle device by requesting the service from the in-vehicle device, and can execute various applications such as human detection processing in the rear using the service instance (e.g., rear camera image) acquired from the in-vehicle device.
  • the in-vehicle device may acquire request data including an application name corresponding to the service from the in-vehicle ECU, and specify the service to be provided according to the application name.
  • the control unit of the in-vehicle device specifies not only the service to be provided to the in-vehicle ECU but also the security level when providing the service based on the request data (data related to the service request) from the in-vehicle ECU.
  • the control unit of the in-vehicle device generates provision data responding to the request data based on the identified security level and outputs the generated provision data to the in-vehicle ECU, so that the security level of the provision data can be guaranteed in response to a request from the in-vehicle ECU.
  • security processing can be performed on a data (message) basis in communications related to requests and provision of services so as to ensure an appropriate security level.
  • pre-processing such as session establishment when communicating related to the requests and provision can be eliminated.
  • processing related to session establishment as pre-processing for ensuring security such as TLS (Transport Layer Security) can be eliminated, and communication overhead can be reduced.
  • the process of generating the provided data based on the security level includes at least one security process among a process of assigning a message authentication code, a process of assigning a digital signature, and a process of encrypting the payload included in the provided data, and the control unit differs the security process when generating the provided data depending on the identified security level.
  • the process of generating the provided data based on the security level includes one or more security processes.
  • the security processes include at least one of the following security processes: a process of adding a message authentication code, a process of adding a digital signature, and a process of encrypting the payload included in the provided data. Since the security processes performed in the process of generating the provided data thus consist of multiple types, the types or combinations of security processes included in the process of generating the provided data can be varied, allowing for a variety of security processes.
  • control unit increases the number of types of security processing included in the generation processing of the provided data in response to an increase in the security level.
  • the security level is defined as multiple levels, such as three stages (low: level 1 ⁇ level 2 ⁇ level 3: high).
  • the control unit of the in-vehicle device increases the number of types of security processing included in the generation process of the provided data in accordance with an increase in the security level, so that robustness against unauthorized attacks, etc. can be improved for messages of services that require a high security level (sensor information, etc.).
  • the number of types of security processing applied can be reduced, thereby reducing the processing load in providing the service.
  • control unit identifies the security level by referencing a service table that is stored in an accessible storage area and includes setting information related to the security level.
  • the control unit of the in-vehicle device identifies the security level of the service requested by the in-vehicle ECU by referring to a service table stored in an accessible storage area.
  • a service table stored in a storage area accessible from the control unit of the in-vehicle device such as the storage unit of the in-vehicle device, associates the names (service names) of services that the in-vehicle device can provide with security levels in a table format.
  • the control unit of the in-vehicle device can efficiently identify the security level of the requested service in accordance with the request data from the in-vehicle ECU.
  • control unit when an attack affecting communication within the vehicle is carried out, changes the setting information regarding the security level contained in the service table and resends the provided data generated based on the changed security level to the in-vehicle ECU.
  • the control unit of the in-vehicle device performs, for example, an IDS (Intrusion Detection System) function to detect attacks that affect communication within the vehicle, i.e., unauthorized attacks on the in-vehicle network.
  • the control unit of the in-vehicle device may obtain a message such as an alert indicating unauthorized detection from another ECU having an unauthorized detection function such as an IDS.
  • the control unit of the in-vehicle device may determine that an attack has been made on the vehicle when request data including a request to change the security level is received from the in-vehicle ECU that transmitted the request data.
  • control unit of the in-vehicle device determines that an attack has been made on the vehicle through communication on the in-vehicle network in this way, it changes the setting information regarding the security level contained in the service table, i.e., modifies the service table so as to increase the security level.
  • the control unit of the in-vehicle device generates provision data based on the changed security level to indicate that the security level has been changed, and resends the generated provision data to the in-vehicle ECU.
  • control unit of the in-vehicle device dynamically changes (increases) the security level defined in the service table in response to an attack on the vehicle, generates provision data that has been subjected to security processing corresponding to the higher security level, and provides (transmits) it to the in-vehicle ECU.
  • This makes it possible to continue providing services to the vehicle-mounted ECU (sending messages including sensor information, etc.) while ensuring an appropriate secure communication environment according to the state of attack on the vehicle.
  • control unit determines the validity of the acquired request data, and outputs the provided data if the result of the validity determination is positive, and does not output the provided data if the result of the validity determination is negative.
  • the request data acquired from the on-board ECU contains information that ensures the legitimacy of the sender of the request data, such as a digital signature that indicates the on-board ECU that sent the request data.
  • the control unit of the on-board device determines the legitimacy of the request data based on the digital signature or the like included in the request data, and if the determination result is positive (legitimate), outputs the provided data to the on-board ECU, and if the determination result is negative (illegal), does not output the provided data to the on-board ECU.
  • a determination process from a security perspective is also performed on the request data that causes the provision of the service, and if the determination result is negative, the provided data is not output, thereby effectively preventing the provision of services to, for example, an unauthorized on-board ECU, etc.
  • control unit when the result of the validity determination is positive, the control unit generates a session key and outputs the provided data including the session key to the in-vehicle ECU.
  • the control unit of the in-vehicle device judges the validity of the request data acquired from the in-vehicle ECU to be positive, the control unit of the in-vehicle device generates a session key consisting of a common key using, for example, a generated random number.
  • the control unit of the in-vehicle device outputs the provision data including or to which the generated session key is added to the in-vehicle ECU, and thereafter, in providing the service (transmission of sensor information corresponding to the service, etc.), outputs a message encrypted with the session key, i.e., a message in which the encrypted sensor information, etc. is stored in the payload, to the in-vehicle ECU.
  • the in-vehicle ECU can receive the provision of the service by decrypting the service message (encrypted sensor information, etc.) transmitted from the in-vehicle device using the session key included in the provision data acquired from the in-vehicle device.
  • the robustness of the message transmitted for the provision of the service can be ensured by encrypting the message using the generated session key each time a request for and communication related to the provision of the service is executed.
  • the request data from the in-vehicle ECU includes a public key corresponding to a private key held by the in-vehicle ECU, and the control unit outputs the provided data encrypted using the public key of the in-vehicle ECU to the in-vehicle ECU.
  • the request data from the on-board ECU includes a public key corresponding to the private key held by the on-board ECU.
  • the request data from the on-board ECU includes a public key certificate that certifies the on-board ECU itself, and the public key may be included in (exist within) the public key certificate.
  • the control unit of the on-board device encrypts the payload of the provided data using the public key included in the request data from the on-board ECU, and outputs the encrypted provided data to the on-board ECU. In this way, encryption is also performed on the provided data in response to the request data, and since the encryption uses an asymmetric key based on the public key from the on-board ECU, the robustness of the provided data can be ensured.
  • the protocol for communication with the in-vehicle ECU is SOME/IP (Scalable service-oriented Middleware over IP)
  • the requested data corresponds to Find Service in SOME/IP
  • the provided data corresponds to Offer Service in SOME/IP.
  • the communication protocol for requesting and providing services between the on-board device and the on-board ECU is SOME/IP (Scalable service-Oriented Middleware over IP).
  • SOME/IP Scalable service-Oriented Middleware over IP
  • the request data sent by the on-board ECU corresponds to "Find Service” in SOME/IP, i.e., the on-board ECU corresponds to the client in SOME/IP-SD (Service Discovery).
  • the provided data sent by the on-board device corresponds to "Offer Service” in SOME/IP, i.e., the on-board device corresponds to the server in SOME/IP-SD (Service Discovery).
  • the in-vehicle ECU and the in-vehicle device are configured as a single device, and communication between the in-vehicle ECU and the in-vehicle device corresponds to communication between applications in the in-vehicle device.
  • the on-board ECU and the on-board device are configured as a single device, and communication between the on-board ECU and the on-board device, i.e., communication regarding service requests and provision, is executed as communication between applications in the on-board device (inter-process communication).
  • inter-process communication the robustness of communication regarding service requests and provision can be guaranteed not only between different communication nodes but also for the on-board device, which is a single device, via the on-board network.
  • the on-board device configured as a single device executes multiple applications, even if inter-process communication regarding service requests and provision is performed between these applications, robustness of communication can be guaranteed.
  • a virtualization system such as a hypervisor
  • the on-board device operates as multiple virtual environments (virtual machines) generated by the virtualization system
  • robustness of communication regarding service requests and provision between applications executed by each of these multiple virtual machines can be guaranteed.
  • An information processing method causes a computer communicatively connected to an on-board ECU mounted on a vehicle to execute a process of acquiring request data relating to a request for a service from the on-board ECU, identifying a service to be provided to the on-board ECU and a security level for providing the service based on the acquired request data, generating provision data for providing the service to the on-board ECU based on the identified security level, and outputting the generated provision data to the on-board ECU.
  • an information processing method causes a computer to function as an in-vehicle device that, when request data related to a service request is transmitted from an in-vehicle ECU, can output provision data that has been subjected to appropriate security processing for the request data.
  • An in-vehicle system is an in-vehicle system including an in-vehicle ECU mounted on a vehicle and an in-vehicle device communicatively connected to the in-vehicle ECU, in which the in-vehicle ECU generates request data relating to a request for a service and outputs the generated request data to the in-vehicle device, and the in-vehicle device acquires the request data from the in-vehicle ECU, identifies a service to be provided to the in-vehicle ECU and a security level for providing the service based on the acquired request data, generates provision data for providing the service to the in-vehicle ECU based on the identified security level, and outputs the generated provision data to the in-vehicle ECU.
  • an in-vehicle system includes an in-vehicle device that, when request data related to a service request is transmitted from the in-vehicle ECU, can output provision data that has been subjected to appropriate security processing for the request data.
  • FIG. 1 is a schematic diagram illustrating a configuration of an in-vehicle system including an in-vehicle device 2 according to the first embodiment.
  • FIG. 2 is a block diagram illustrating a physical configuration of the in-vehicle device 2.
  • the in-vehicle system S is configured with an in-vehicle device 2 mounted on a vehicle C as a main device, and the in-vehicle device 2 is communicatively connected to one or more in-vehicle ECUs 6 via an in-vehicle network.
  • the in-vehicle device 2 may be communicatively connected to an external server or a mobile terminal such as a smartphone connected to an external network such as the Internet via an external communication device 1.
  • the in-vehicle device 2 functions, for example, as a SOME/IP server, and the in-vehicle ECU 6 functions as a SOME/IP client.
  • the in-vehicle device 2 and the in-vehicle ECU 6 use SOME/IP communication to send and receive messages (request data: Find Service, provided data: Offer Service) associated with the provision of services from the in-vehicle device 2.
  • the communication protocol between the in-vehicle device 2 and the in-vehicle ECU 6 is not limited to SOME/IP, and may be another communication protocol used to send and receive messages associated with the request for services (request data similar to Find Service, etc.) and the provision of services (provided data similar to Offer Service, etc.).
  • the in-vehicle device 2 functioning as a SOME/IP server may acquire (uplink) sensor information detected by various sensors etc. connected to the in-vehicle device 2 and various sensors etc. connected to each of the multiple in-vehicle ECUs 6, and store the information in a database (DB) stored in the storage unit 4, thereby centrally managing various sensor information etc. that are instances of a service.
  • the in-vehicle device 2 may further acquire various data that are instances of a service from an external server or a mobile terminal (smartphone) etc. via the extra-vehicle communication device 1, and store the data in the database (DB).
  • the in-vehicle device 2 may provide (downlink) the various sensor information etc. thus centrally managed in the database (DB) to the in-vehicle ECU 6 that requests the service, using SOME/IP communication.
  • Vehicle C is equipped with an external communication device 1, an in-vehicle device 2, and multiple in-vehicle ECUs 6 for controlling various in-vehicle devices (actuators, sensors).
  • the external communication device 1 and the in-vehicle device 2 are communicatively connected by a harness such as a serial cable.
  • the in-vehicle device 2 and the in-vehicle ECUs 6 are communicatively connected by an in-vehicle network 7 that supports a communication protocol such as Ethernet (registered trademark), and the in-vehicle device 2 may function as an Ethernet switch (layer 2 switch or layer 3 switch) that has a relay function for IP packets.
  • Ethernet registered trademark
  • the external-vehicle communication device 1 includes an external-vehicle communication unit (not shown) and an input/output I/F (not shown) (interface) for communicating with the in-vehicle device 2.
  • the external-vehicle communication unit is a communication device for wireless communication using a mobile communication protocol such as LTE, 4G, 5G, or WiFi, and transmits and receives data to and from an external server or a mobile terminal via an antenna 11 connected to the external-vehicle communication unit. Communication between the external-vehicle communication device 1 and the external server is performed via an external network such as a public line network or the Internet.
  • the in-vehicle device 2 may be configured as one functional part of a body ECU that controls the entire vehicle C. Furthermore, the in-vehicle device 2 may function as an intrusion detection device such as an IDS (Intrusion Detection System).
  • IDS Intrusion Detection System
  • the in-vehicle device 2 includes a control unit 3, a memory unit 4, and an in-vehicle communication unit 5.
  • the control unit 3 is configured with a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and is configured to perform various control processes, calculation processes, etc. by reading and executing a control program P (program product) and data pre-stored in the memory unit 4.
  • CPU Central Processing Unit
  • MPU Micro Processing Unit
  • the storage unit 4 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM) or flash memory, and pre-stores the control program P and data to be referenced during processing.
  • the control program P (program product) stored in the storage unit 4 may be a control program P (program product) read from a recording medium M readable by the in-vehicle device 2.
  • the control program P may also be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 4.
  • the storage unit 4 may also store a database (DB) that saves and manages sensor information detected by various sensors etc. connected to the in-vehicle device 2 and various sensors etc. connected to each of the multiple in-vehicle ECUs 6.
  • the various sensor information etc. stored in the database (DB) is provided as a service to each of the in-vehicle ECUs 6, which are SOME/IP clients, using SOME/IP communication.
  • the in-vehicle communication unit 5 is an input/output interface (Ethernet PHY unit) that uses a communication protocol such as Ethernet (TCP/IP).
  • a plurality of in-vehicle communication units 5 are provided, and each of the in-vehicle communication units 5 is connected to a respective communication line 71 (Ethernet cable) that constitutes the in-vehicle network 7.
  • the in-vehicle network 7 may be divided into a plurality of segments, and the in-vehicle ECU 6 may be connected to each segment according to the function of the in-vehicle ECU 6.
  • the control unit 3 of the in-vehicle device 2 communicates with the in-vehicle ECU 6 connected to the in-vehicle network 7 via the in-vehicle communication unit 5.
  • FIG. 3 is an explanatory diagram illustrating an example of a service table.
  • FIG. 4 is an explanatory diagram illustrating an example of a security processing table.
  • a storage area accessible to the control unit 3 of the in-vehicle device 2 such as the storage unit 4 of the in-vehicle device 2
  • setting information regarding the security level for a service (service table) and information regarding security processing corresponding to the security level (security processing table) are stored, for example, in table format.
  • the service table includes management items (fields), such as a client IP, application name, service name, and security level.
  • the management item of the client IP stores, for example, the IP address of the in-vehicle ECU 6, which is a client of the SOME/IP.
  • a MAC (Media Access Control address) address may be stored instead of the IP address.
  • the control unit 3 of the in-vehicle device 2 acquires requested data, it may determine the validity of the requested data by comparing the sending address of the requested data with an IP address that is predefined in the management item of the client IP in the service table.
  • the service name management item stores the name of the service (name of the service instance) that corresponds to the application name stored in the same record.
  • the service defined (stored) in the service name management item corresponds to the service that is requested and provided based on SOME/IP-SD (Service Discovery).
  • the security level management item stores a security level value corresponding to the service name stored in the same record.
  • the security level value is indicated by a number, and is set so that the larger the value, the higher the security level (low: level 1 ⁇ level 2 ⁇ level 3 ... ⁇ level N: high).
  • the security level may be set to three levels, or may be further subdivided to set the security level to four or more levels (four or more stages).
  • the request data (Find Service) sent from the vehicle-mounted ECU 6 functioning as a SOME/IP client includes the application name (AppA) executed by the vehicle-mounted ECU 6.
  • the vehicle-mounted device 2 functioning as a SOME/IP server can identify the corresponding service name by referring to a service table based on the application name (AppA) included in the request data (Find Service) acquired from the vehicle-mounted ECU 6.
  • the request data (Find Service) from the vehicle-mounted ECU 6 may include a service name (service), and the vehicle-mounted device 2 may identify the service to provide in response to the request data.
  • the security processing management item stores the processing content of the security processing corresponding to the security level value stored in the same record. For example, when the security level is set to three levels (low: level 1 ⁇ level 2 ⁇ level 3: high), if the security level is the lowest level 1, the security processing assigns a message authentication code (MAC: Message Authentication Code) to messages related to SOME/IP. Alternatively, the security processing may further assign a counter to messages related to SOME/IP. By assigning a MAC, it is possible to verify whether the message has been tampered with or replaced en route (message integrity). This makes it possible to respond to message tampering or replay attacks.
  • MAC message authentication code
  • the security process assigns a digital signature identifying the vehicle-mounted device 2 itself to messages related to SOME/IP instead of (instead of) assigning a MAC.
  • the security process may assign a digital signature identifying the vehicle-mounted device 2 itself to messages related to SOME/IP, in addition to assigning a MAC.
  • the security process may assign a role-based signature to messages related to SOME/IP.
  • the security process includes a digital signature added in place of the MAC, and further includes a process of encrypting the payload (such as sensor information stored in the payload) in the message related to SOME/IP.
  • the security process may include a process of encrypting the payload (such as sensor information stored in the payload) in the message related to SOME/IP, in addition to adding the MAC and the digital signature.
  • the control unit 3 of the in-vehicle device 2 may generate a session key, include the generated session key in the provided data (Offer Service), and output it to the in-vehicle ECU 6. This makes it possible to respond to message eavesdropping attacks.
  • Instances of services set to such a high security level include, for example, GPS information, copyright information of the infotainment system, and information of mobile devices such as smartphones, and the like, and this information can be efficiently protected.
  • FIG. 5 is an explanatory diagram illustrating a protected SOME/IP message.
  • SOME/IP Scalable service-oriented middleware over IP
  • OSI Open System Interconnection
  • a SOME/IP message includes a header area including a source address and a destination address, etc., and a payload area for storing data corresponding to the service provided, such as sensor information.
  • the SOME/IP message is protected according to the security level of this embodiment, and includes additional information consisting of a count and a role base (digital signature), etc., and a message authentication code (MAC).
  • additional information and MAC may be stored in the payload area.
  • protection for SOME/IP messages is applied according to the security level; for example, at level 1, a MAC (and count) is applied, at level 2, a role-based (digital signature) is also applied, and at level 3, the payload is further encrypted (encrypted using a session key).
  • a MAC and count
  • a role-based digital signature
  • the payload is further encrypted (encrypted using a session key).
  • FIG. 6 is an explanatory diagram illustrating a processing sequence between the in-vehicle device 2 (server) and the in-vehicle ECU 6 (client).
  • the in-vehicle device 2 functions as a SOME/IP-SD (Service Discovery) server
  • the in-vehicle ECU 6 functions as a client.
  • the vehicle-mounted device 2 and the vehicle-mounted ECU 6 each hold (store) a public key certificate, and the vehicle-mounted device 2 and the vehicle-mounted ECU 6 may realize mutual authentication.
  • the vehicle-mounted device 2 and the vehicle-mounted ECU 6 may realize an authentication protocol by adding information according to a security level to the payload in the request data (Find Service) and the provided data (Offer Service) by the SOME/IP protocol.
  • the vehicle-mounted device 2 and the vehicle-mounted ECU 6 may also perform security processing according to the security level on the subscribe request data (Subscribe Event group, Subscribe Event ACK) performed after the transmission and reception of the request data (Find Service) and the provided data (Offer Service).
  • the in-vehicle ECU 6 outputs (transmits) request data (Find Service) to the in-vehicle device 2 (S01).
  • the in-vehicle ECU 6 generates request data including an application (AppA) corresponding to (using) the service requested.
  • the in-vehicle ECU 6 may further generate request data by including in the request data a public key certificate (CertA) of the in-vehicle ECU 6 itself and a digital signature (SigA) using the in-vehicle ECU 6's own private key.
  • the in-vehicle ECU 6 outputs (transmits) the request data thus generated to the in-vehicle device 2.
  • the in-vehicle device 2 identifies the service and security level based on the request data acquired from the in-vehicle ECU 6 (S02).
  • the in-vehicle device 2 acquires the request data from the in-vehicle ECU 6 and verifies the digital signature (SigA) included in the request data to determine the validity of the request data, i.e., whether the sender of the request data is the true in-vehicle ECU 6. If the result of the determination is negative, the in-vehicle device 2 may not respond to the request data, i.e., may not transmit the provided data. In addition, the request data, etc.
  • SigA digital signature
  • AEAD Authenticated Encryption with Associated Data
  • MAC Network Address Translation
  • the in-vehicle device 2 identifies the name of the service requested by the application receiving the service and the security level when providing the service, from the name of the application (AppA) included in the request data or the contents of the public key certificate (CertA) included in the request data.
  • the in-vehicle device 2 may refer to a service table stored in the storage unit 4.
  • the in-vehicle device 2 may not respond to the request data, i.e., may not send the provided data.
  • the in-vehicle device 2 generates a session key (S03). If the in-vehicle device 2 determines (judges) that the request data from the in-vehicle ECU 6 is valid based on these judgment results, etc., it generates a session key (common key: enckey) using any or known means.
  • the in-vehicle device 2 outputs (transmits) the provided data (Offer Service) including the generated session key to the in-vehicle ECU 6 (S04).
  • the in-vehicle device 2 generates the provided data (Offer Service) including (stored in the payload) the generated session key (enckey), the in-vehicle device 2's own public key certificate (PubkeyB), and the specified security level (SecLevel), and outputs (transmits) it to the in-vehicle ECU 6.
  • the in-vehicle device 2 may encrypt the payload of the generated provided data with a public key present in the public key certificate (CertA) included in the request data from the in-vehicle ECU 6, and output (transmit) the encrypted provided data to the in-vehicle ECU 6.
  • This procedure ensures that only the owner of the corresponding private key (communication node) can decrypt the data, ensuring the confidentiality of the session key.
  • the vehicle ECU 6 acquires the provided data and decompresses (decrypts) the session key (enckey) included in the provided data (S05).
  • the vehicle ECU 6 acquires the encrypted provided data from the vehicle device 2 and decrypts the payload of the encrypted provided data using the private key corresponding to the vehicle ECU 6's own public key certificate (CertA).
  • the vehicle ECU 6 verifies the validity of the vehicle device 2's own public key certificate (PubkeyB) included in the provided data, and if it is determined to be valid, acquires the session key (enckey) and security level (SecLevel) included in the provided data.
  • the vehicle ECU 6 By acquiring the session key (enckey) and security level (SecLevel), the vehicle ECU 6 recognizes the security level of the provided service and can subsequently decrypt messages whose payloads are encrypted with the session key. It is also possible to update the pre-shared key with this session key.
  • the subscribe request data may also be subjected to security processing according to the security level.
  • the in-vehicle device 2 After transmitting an ACK to the in-vehicle device 2 to the in-vehicle ECU 6, the in-vehicle device 2 performs security processing according to the security level on a message (Event/Field Notification) including data of the service to be provided (sensor information, etc.), and then transmits the message to the in-vehicle ECU 6.
  • Event/Field Notification data of the service to be provided (sensor information, etc.
  • the message (Event/Field Notification) from the in-vehicle device 2 is subjected to various security processing according to the security level, such as encryption of the payload using a session key, and addition of a MAC and a digital signature.
  • the form of security processing described in this embodiment assumes a relatively high security level (e.g., level 3), but is not limited to this.
  • the security level is relatively low (e.g., levels 1 and 2)
  • the in-vehicle device 2 may generate and output provided data that has been subjected to security processing such as the addition of a MAC and a digital signature, without generating a session key (enckey).
  • security processing such as the addition of a MAC and a digital signature
  • the payload of the message (Event/Field Notification) sent by the in-vehicle device 2 in accordance with the service provided may also be in plain text without encryption, and only security processing such as the addition of a MAC and a digital signature may be performed.
  • FIG. 7 is a flowchart illustrating the processing of the control unit 3 of the in-vehicle device 2.
  • the control unit 3 of the in-vehicle device 2 steadily performs the following processing, for example, when the vehicle C is in a running state or a stopped state (the IG switch or the power switch is on or off).
  • the control unit 3 of the in-vehicle device 2 acquires request data regarding a service request from the in-vehicle ECU 6 (S101).
  • the in-vehicle ECU 6 may include in the request data the application name (AppA) corresponding to the service, the in-vehicle ECU 6's own public key certificate (CertA), and a digital signature (SigA) using the in-vehicle ECU 6's own private key.
  • AppA application name
  • CertA public key certificate
  • SigA digital signature
  • the control unit 3 of the in-vehicle device 2 determines whether the request data is valid or not (S102).
  • the control unit 3 of the in-vehicle device 2 determines the validity of the request data, i.e., whether the request data is valid or not, for example, by verifying the digital signature (SigA) included in the request data.
  • SigA digital signature
  • control unit 3 of the in-vehicle device 2 determines that the request data is not valid (S102: NO), i.e., that the request data is fraudulent, the control unit 3 of the in-vehicle device 2 outputs a message indicating that fraudulent request data has been acquired (S1021). If the control unit 3 of the in-vehicle device 2 determines that the request data is not valid, i.e., that the request data is fraudulent, the control unit 3 stores in the memory unit 4 a message indicating that fraudulent request data has been acquired in association with the time of reception of the fraudulent request data.
  • the control unit 3 of the in-vehicle device 2 may store information regarding the fraudulent request data in an abnormality history database stored in the memory unit 4.
  • the control unit 3 of the in-vehicle device 2 may display the message indicating that fraudulent request data has been acquired on an HMI (Human Machine Interface) device, or transmit the message to an external server via the external vehicle communication device 1.
  • HMI Human Machine Interface
  • the control unit 3 of the in-vehicle device 2 generates the provided data based on the identified security level (S104). For example, if the security level is set to three levels (low: level 1 ⁇ level 2 ⁇ level 3: high), the control unit 3 of the in-vehicle device 2 generates the provided data that has been subjected to security processing according to the identified security level.
  • the control unit 3 of the in-vehicle device 2 may determine the security processing according to the security level, for example, by referring to a security processing table stored in the memory unit 4. For example, when the security level is level 1, which is the lowest, the control unit 3 of the in-vehicle device 2 generates the provided data to which a MAC generated using a private key shared with the in-vehicle ECU 6 is added. When the security level is level 2, which is intermediate, the control unit 3 of the in-vehicle device 2 generates the provided data to which, in addition to adding a MAC, a digital signature identifying the in-vehicle device 2 itself is added.
  • control unit 3 of the in-vehicle device 2 generates the provided data (Offer Service) including (stored in the payload) the generated session key (enckey), the in-vehicle device 2's own public key certificate (PubkeyB), and the identified security level (SecLevel) in response to the security level.
  • the control unit 3 of the in-vehicle device 2 may further encrypt the payload of the provided data (Offer Service) using the public key (present in the public key certificate) included in the request data from the in-vehicle ECU 6.
  • control unit 3 of the in-vehicle device 2 may increase the types of security processing used when generating the provided data in response to an increase in the security level, i.e., as the security level becomes higher.
  • control unit 3 of the in-vehicle device 2 may increase the difficulty of deciphering security objects such as MACs, for example by increasing the number of digits of the random number used when generating a MAC in response to an increase in the security level.
  • the control unit 3 of the in-vehicle device 2 starts providing the service according to the security level (S106).
  • the control unit 3 of the in-vehicle device 2 encrypts the message (Event/Field Notification) associated with the provision of the service using a session key according to the security level and transmits it to the in-vehicle ECU 6.
  • the control unit 3 may transmit the message (Event/Field Notification) to which the MAC and digital signature have been added, without encrypting the payload, in plain text, to the in-vehicle ECU 6.
  • the control unit 3 of the in-vehicle device 2 ends the series of processes in this flow.
  • the control unit 3 of the in-vehicle device 2 may perform loop processing to execute the process from S101 again after executing the process of S106 or S1021.
  • the control unit 3 of the in-vehicle device 2 may generate a process for each service and perform parallel processing of the processing related to the provision of these multiple services using the multiple processes.
  • the control unit 3 of the in-vehicle device 2 may change the amount of resources allocated to the process executing the service depending on the security level of these services.
  • the hardware resources such as CPU allocation time, memory occupation amount, or number of threads may be set (allocated) more to a process for providing a service with a high security level than to a process for providing a service with a low security level. This allows processing related to services with a high security level to be performed with comparative priority.
  • (Embodiment 2) 8 is an explanatory diagram illustrating a processing sequence between the in-vehicle device 2 (server) and the in-vehicle ECU 6 (client) according to the second embodiment (dynamic change of security level).
  • the in-vehicle device 2 and the in-vehicle ECU 6 according to the second embodiment show a processing (sequence) related to an event in which the security level of the service is changed after a message (Event/Field Notification) corresponding to the service provided in the first embodiment is transmitted from the in-vehicle device 2 to the in-vehicle ECU 6 periodically, regularly, or steadily.
  • the vehicle ECU 6 outputs (transmits) request data (Find Service) regarding a change in security level to the vehicle device 2 (S21). For example, when the vehicle ECU 6 detects an attack on itself or an attack on the vehicle network 7, the vehicle ECU 6 generates request data regarding a change in security level and outputs (transmits) it to the vehicle device 2.
  • the vehicle ECU 6 generates request data including the application (AppA), the vehicle ECU 6's own public key certificate (CertA), and the digital signature (SigA) by the vehicle ECU 6's own private key, as in the request data of embodiment 1, and further includes a request for a change (increase) in the security level (value of the security level after the change: rSecLevel).
  • the vehicle ECU 6 outputs (transmits) the request data including the value of the security level after the change (rSecLevel) to the vehicle device 2.
  • the in-vehicle device 2 determines that the in-vehicle network 7 has been attacked (S22). When the in-vehicle device 2 acquires request data for changing the security level from the in-vehicle ECU 6, it determines that the in-vehicle network 7 has been attacked. Alternatively, even when the in-vehicle device 2 does not acquire request data for changing the security level from the in-vehicle ECU 6, it may determine that the in-vehicle network 7 has been attacked by, for example, exerting a function such as an IDS, and detecting an attack that affects communication within the vehicle C, i.e., an unauthorized attack on the in-vehicle network 7.
  • a function such as an IDS
  • the in-vehicle device 2 changes the security level (S23). Based on the application name (AppA) and security level value (rSecLevel) included in the request data acquired from the in-vehicle ECU 6, the in-vehicle device 2 changes the security level of the service defined in the service table. By changing the security level, the security level of the target service is set to a higher security level than the security level before the attack was detected.
  • AppA application name
  • rSecLevel security level value
  • the in-vehicle device 2 generates a session key (S24).
  • the in-vehicle device 2 generates (regenerates) the session key again, similar to step S03 in embodiment 1.
  • By regenerating the session key in this manner it is possible to make the session key used in the SOME/IP communication between the in-vehicle device 2 and the in-vehicle ECU 6 different before and after the attack is detected.
  • the in-vehicle device 2 outputs (transmits) the provided data (Offer Service) regarding the change in security level to the in-vehicle ECU 6 (S25).
  • the in-vehicle device 2 generates the provided data (Offer Service) including the regenerated session key (enckey), the in-vehicle device 2's own public key certificate (PubkeyB), and the changed security level (SecLevel) (stored in the payload), and outputs (transmits) it to the in-vehicle ECU 6.
  • the vehicle ECU 6 acquires the resent provision data and decompresses (decrypts) the session key (enckey) included in the provision data (S26).
  • the vehicle ECU 6 decrypts (decrypts) the session key (enckey) included in the provision data by using the private key to decrypt the acquired provision data in the same manner as in the first embodiment.
  • the session key (enckey) is a session key that is regenerated with the attack detection as a trigger.
  • the vehicle ECU 6 can recognize the changed security level by referring to the security level (SecLevel) included in the provision data.
  • the vehicle ECU 6 recognizes the changed security level and can continue to receive the service provided by the vehicle device 2 using the session key resent from the vehicle device 2 even after the attack is detected, and can execute an application using a message (Event/Field Notification) transmitted in conjunction with the provision of the service.
  • Event/Field Notification a message transmitted in conjunction with the provision of the service.
  • FIG. 9 is a flowchart illustrating the processing of the control unit 3 of the in-vehicle device 2.
  • the control unit 3 of the in-vehicle device 2 steadily performs the following processing, for example, when the vehicle C is in a running state or a stopped state (the IG switch or the power switch is on or off).
  • the control unit 3 of the in-vehicle device 2 performs the processes from S201 to S206, similar to the processes from S101 to S106 in embodiment 1. By performing these processes, the control unit 3 of the in-vehicle device 2 is in a state where it has started providing a service according to the security level, similar to embodiment 1, that is, it is continuously transmitting (outputting) messages associated with the provision of the service (messages in which sensor information corresponding to the service, etc., is stored in the payload) to the in-vehicle ECU 6, which is the client.
  • control unit 3 of the in-vehicle device 2 may determine that an unauthorized attack in the in-vehicle network 7 has been detected.
  • control unit 3 of the in-vehicle device 2 performs a loop process to execute the process of S207 again.
  • the control unit 3 of the in-vehicle device 2 If it is determined that an attack has been detected (S207: YES), the control unit 3 of the in-vehicle device 2 generates data to be provided based on the changed security level (S208). If it is determined that an attack has been detected, the control unit 3 of the in-vehicle device 2 changes the security level of the service currently being provided based on the request data (Find Service) from the in-vehicle ECU 6, and generates data to be provided based on the changed security level.
  • the request data Service
  • the control unit 3 of the in-vehicle device 2 refers to the service table stored in the storage unit 4 and identifies the current security level of the service. Then, the control unit 3 of the in-vehicle device 2 changes the service table based on the value of the changed security level (rSecLevel) included in the request data from the in-vehicle ECU 6. This makes it possible to set the service table so that the target service (the service currently being provided) has a higher security level than the current security level. For example, if the current security level of the target service is 1, the control unit 3 of the in-vehicle device 2 changes the security level to 2.
  • the control unit 3 of the in-vehicle device 2 changes the security level to 3. If the current security level of the target service is the highest value (e.g., 3, etc.), the control unit 3 of the in-vehicle device 2 may maintain the security level that is the highest value.
  • the control unit 3 of the in-vehicle device 2 may vary the degree of increase in the security level depending on the impact (severity) of the detected attack. If the in-vehicle device 2 has an IDS (Intrusion Detection System) function, for example, the IDS function may be used to derive the impact of the detected attack, and the security level may be increased by two steps if the impact on control, etc. of the vehicle C is high, and increased by one step if the impact is low. Increasing the security level will also increase overhead in SOME/IP communication, but by increasing (changing) the security level in consideration of the impact of the attack on control, etc. of the vehicle C, it is possible to prevent the occurrence of excessive overhead.
  • IDS Intrusion Detection System
  • control unit 3 of the in-vehicle device 2 When the control unit 3 of the in-vehicle device 2 detects an unauthorized attack on the in-vehicle network 7 in this manner, it may store the detection of the attack in the memory unit 4 (save in the abnormality history database) in association with the time of detection of the attack, similar to S1021 in the first embodiment.
  • the control unit 3 of the in-vehicle device 2 may further output the detection of the attack as a display to an HMI (Human Machine Interface) device, or transmit the detection of the attack to an external server via the external communication device 1.
  • HMI Human Machine Interface
  • the control unit 3 of the in-vehicle device 2 resends the provided data to the in-vehicle ECU 6 (S209).
  • the control unit 3 of the in-vehicle device 2 generates (regenerates) provided data indicating that the security level has been changed, and resends the regenerated provided data to the in-vehicle ECU 6.
  • the control unit 3 of the in-vehicle device 2 may include, for example, the changed security level value, a public key certificate identifying itself, and a session key in the provided data.
  • control unit 3 of the in-vehicle device 2 may also generate (regenerate) the session key again, and resend the provided data indicating that the security level has been changed to the in-vehicle ECU 6, including the regenerated session key.
  • the session key is used to encrypt and decrypt data included in the payload of a message (an instance of a service such as sensor information) when the in-vehicle device 2, which is the server, sends a message to the in-vehicle ECU 6, which is the client, in connection with the provision of the service after the retransmission of the provided data. Therefore, by changing the session key used in the SOME/IP communication between the in-vehicle device 2 and the in-vehicle ECU 6 in response to the detection of an attack, i.e., before and after the detection of an attack, it is possible to ensure the robustness of messages sent to provide the service.
  • the control unit 3 of the in-vehicle device 2 continues to provide the service at the changed security level (S210).
  • the control unit 3 of the in-vehicle device 2 references the service table in which the changed security level, i.e., the security level of the target service, has been changed, generates a message associated with the provision of the service according to the changed security level, and transmits the message to the in-vehicle ECU 6.
  • the control unit 3 of the in-vehicle device 2 can continue to provide the service to the in-vehicle ECU 6 while ensuring robustness against the attack.
  • (Embodiment 3) 10 is a functional block diagram illustrating functional units included in the control unit 3 of the in-vehicle device 2 according to the third embodiment (inter-process communication within the in-vehicle device 2).
  • the in-vehicle device 2 (SOME/IP server) and the in-vehicle ECU 6 (SOME/IP client) in the first embodiment are configured as a single device, that is, the in-vehicle device 2 has the functions of both the SOME/IP server and the SOME/IP client and is responsible for the processing of both.
  • the control unit 3 of the in-vehicle device 2 executes the control programs stored in the memory unit 4, thereby functioning as an application execution unit 301, a SOME/IP master unit 302, and a platform unit 303. That is, the control programs stored in the memory unit 4 include an application program that uses a service, a communication program based on the SOME/IP protocol, and a platform unit 303 that is composed of a communication socket module, a software library, etc.
  • the application execution unit 301 executes an application program that uses the service, and performs various control processing or information processing using sensor information or camera images, which are instances of the service.
  • the SOME/IP master unit 302 performs general control related to SOME/IP communication. Furthermore, the SOME/IP master unit 302 may acquire sensor information detected by various sensors connected to the in-vehicle device 2 and various sensors connected to each of the multiple in-vehicle ECUs 6 connected to the in-vehicle network 7, and store the information in a database (DB) stored in the storage unit 4.
  • the SOME/IP master unit 302 may provide the various sensor information, etc., stored centrally in the database as service instances to the application execution unit 301 using SOME/IP communication.
  • the platform unit 303 performs general control of inter-process communication between the application execution unit 301 and the SOME/IP master unit 302, i.e., the protocol at a layer lower than the SOME/IP communication layer.
  • the application execution unit 301 corresponds to a SOME/IP client
  • the SOME/IP master unit 302 corresponds to a SOME/IP server.
  • the communication between the application execution unit 301 and the SOME/IP master unit 302 is executed as IP communication within the vehicle-mounted device 2, for example, by using a loopback address. Therefore, the application execution unit 301 functioning as a SOME/IP client and the SOME/IP master unit 302 functioning as a SOME/IP server can perform SOME/IP communication with security processing according to the security level, i.e., sending and receiving protected SOME/IP messages, in the same way as the vehicle-mounted device 2 and the vehicle-mounted ECU 6 of the first and second embodiments. In this way, the security processing related to SOME/IP communication shown in the first and second embodiments can be applied to the vehicle-mounted device 2, which is a single device (communication node), and the availability of the security processing can be expanded.
  • the application of security processing related to SOME/IP communication to the vehicle-mounted device 2, which is a single device (communication node), is not limited to a real environment in which hardware resources are directly controlled by an OS (operating system) or the like.
  • the security processing related to SOME/IP communication according to this embodiment may be applied to SOME/IP communication between multiple virtual environments (virtual machines) generated by a virtualization system such as a hypervisor.
  • a virtualization system such as a hypervisor.
  • one of these multiple virtual machines may function as a SOME/IP server, and the other virtual machines may function as a SOME/IP client.
  • the availability of the security processing shown in embodiments 1 and 2 can be expanded by applying the security processing related to SOME/IP communication to virtual environments (virtual machines).
  • the claims described in the claims may be combined with each other regardless of the form of reference.
  • the claims may contain multiple dependent claims that depend on multiple claims. Multiple dependent claims that depend on multiple dependent claims may be contained. Even if a multiple dependent claim that depends on a multiple dependent claim is not contained, this does not limit the description of multiple dependent claims that depend on a multiple dependent claim.
  • Vehicle S Vehicle-mounted system 1 Vehicle-external communication device 11 Antenna 2 Vehicle-mounted device (SOME/IP server) 3 Control unit 301 Application execution unit 302 SOME/IP master unit 303 Platform unit 4 Storage unit 5 In-vehicle communication unit M Recording medium P Control program (program product) 6. Vehicle ECU (SOME/IP client) 7 In-vehicle network 71 Communication line

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

車載装置は、車両に搭載される車載ＥＣＵと通信可能に接続される車載装置であって、前記車載ＥＣＵからのサービスの要求に関する処理を行う制御部を備え、前記制御部は、前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、生成した提供データを前記車載ＥＣＵへ出力する。

Description

車載装置、情報処理方法及び、車載システム
　本開示は、車載装置、情報処理方法及び、車載システムに関する。
　本出願は、２０２３年１月１６日出願の日本出願第２０２３－４５８３号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。
　従来、車両に搭載されたＥＣＵ（Electronic Control Unit）等の複数の装置間で行われる通信に用いられる通信プロトコルには、ＣＡＮ（Controller Area Network）の通信プロトコルが広く採用されていた。
　特許文献１においては、車両のＣＡＮに接続され、装置診断コマンドにより車載機器に動作を実行させて、この車載機器が送信する状態応答データを取り込み、車載機器の動作状態を判断する検知・制御統合装置が提案されている。
特開２００９－２２０８００号公報
　本開示の一態様に係る車載装置は、車両に搭載される車載ＥＣＵと通信可能に接続される車載装置であって、前記車載ＥＣＵからのサービスの要求に関する処理を行う制御部を備え、前記制御部は、前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、生成した提供データを前記車載ＥＣＵへ出力する。
実施形態１に係る車載装置を含む車載システムの構成を例示する模式図である。 車載装置の物理構成を例示するブロック図である。 サービステーブルを例示した説明図である。 セキュリティ処理テーブルを例示した説明図である。 保護のあるＳＯＭＥ／ＩＰメッセージを例示した説明図である。 車載装置（サーバ）と車載ＥＣＵ（クライアント）との処理シーケンスを例示した説明図である。 車載装置の制御部の処理を例示するフローチャートである。 実施形態２（セキュリティレベルの動的変更）に係る車載装置（サーバ）と車載ＥＣＵ（クライアント）との処理シーケンスを例示した説明図である。 車載装置の制御部の処理を例示するフローチャートである。 実施形態３（車載装置内のプロセス間通信）に係る車載装置の制御部に含まれる機能部を例示する機能ブロック図である。
［本開示が解決しようとする課題］
　特許文献１の検知・制御統合装置は、車載ＥＣＵ（Electronic Control Unit）から、サービスの要求に関する要求データが送信された際、当該要求データに対し適切なセキュリティ処理を施した提供データの生成及び出力を行う点が、考慮されていない。
　本開示の目的は、車載ＥＣＵから、サービスの要求に関する要求データが送信された際、当該要求データに対し適切なセキュリティ処理を施した提供データを出力することができる車載装置等を提供する。
［本開示の効果］
　本開示の一態様によれば、車載ＥＣＵから、サービスの要求に関する要求データが送信された際、当該要求データに対し適切なセキュリティ処理を施した提供データを出力する車載装置等を提供することができる。
［本開示の実施形態の説明］
　最初に本開示の実施態様を列挙して説明する。また、以下に記載する実施形態の少なくとも一部を任意に組み合わせてもよい。
（１）本開示の一態様に係る車載装置は、車両に搭載される車載ＥＣＵと通信可能に接続される車載装置であって、前記車載ＥＣＵからのサービスの要求に関する処理を行う制御部を備え、前記制御部は、前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、生成した提供データを前記車載ＥＣＵへ出力する。
　本態様にあたっては、車両に搭載される車載装置と車載ＥＣＵとは、車載ネットワークを介して相互に通信し、車載装置が実行するサービスに関する要求及び提供に関する通信を行う。例えば、後方カメラに関する処理を担う車載装置は、当該後方カメラが撮像した画像（サービスのインスタンス）を、車載ネットワークを介して出力するサービスを実行する。車載ＥＣＵは、車載装置に対し後方カメラに関するサービスを要求することにより、車載装置から当該サービスの提供を受けることができ、車載装置から取得したサービスのインスタンス（例えば、後方カメラの画像）を用いて、例えば後方における人検知処理等の各種アプリケーションを実行することができる。又は、車載装置は、車載ＥＣＵからサービスに対応するアプリケーション名を含む要求データを取得することにより、当該アプリケーション名に応じて提供するサービスを特定するものであってもよい。車載装置の制御部は、このようなサービスの要求及び提供に関する通信処理を行うにあたり、車載ＥＣＵからの要求データ（サービスの要求に関するデータ）に基づき、車載ＥＣＵに提供するサービスのみならず、当該サービスを提供する際のセキュリティレベルを特定する。車載装置の制御部は、特定したセキュリティレベルに基づき、要求データに応答する提供データを生成し、生成した提供データを車載ＥＣＵへ出力するため、当該提供データのセキュリティレベルを車載ＥＣＵからの要求に応じて担保することができる。このようにサービスに関する要求及び提供に関する通信におけるデータ（メッセージ）単位にて、適正なセキュリティレベルとなるようにセキュリティ処理を施すことができる。更にサービスに関する要求及び提供に関する通信に用いるデータに対し、セキュリティレベルに応じた処理を施すため、当該要求及び提供に関する通信を行う際のセッション確立等の前処理を不要とすることができる。すなわち、例えばＴＬＳ（Transport Layer Security）等のセキュリティ確保のための前処理としてのセッション確立に関する処理を不要とでき、通信におけるオーバヘッドを低減することができる。
（２）本開示の一態様に係る車載装置は、セキュリティレベルに基づく提供データの生成処理は、メッセージ認証コードの付与処理、デジタル署名の付与処理、及び提供データに含まれるペイロードの暗号化処理の内の少なくとも１つ以上のセキュリティ処理を含み、前記制御部は、特定したセキュリティレベルに応じて、提供データを生成する際のセキュリティ処理を異ならせる。
　本態様にあたっては、セキュリティレベルに基づく提供データの生成処理は１つ以上のセキュリティ処理を含む。当該セキュリティ処理は、メッセージ認証コードの付与処理、デジタル署名の付与処理、及び提供データに含まれるペイロードの暗号化処理の内の少なくとも１つのセキュリティ処理を含む。このように提供データの生成処理にて行われるセキュリティ処理は、複数種類から成るため、提供データの生成処理に含まれるセキュリティ処理の種類又は組み合わせを異ならせることができ、セキュリティ処理のバリエーション化を図ることができる。
（３）本開示の一態様に係る車載装置は、前記制御部は、セキュリティレベルの増加に応じて、提供データの生成処理に含まれるセキュリティ処理の種類数を増加する。
　本態様にあたっては、セキュリティレベルは、例えば３段階等の複数のレベル（低：レベル１＜レベル２＜レベル３：高）にて、定義されている。車載装置の制御部は、セキュリティレベルの増加に応じて、提供データの生成処理に含まれるセキュリティ処理の種類数を増加するため、高いセキュリティレベルが要求されサービスのメッセージ（センサ情報等）に対しては、不正な攻撃等に対する堅牢性を向上させることができる。又、比較的に低いセキュリティレベルが要求されサービスのメッセージ（センサ情報等）に対しては、施すセキュリティ処理の種類数を少なくすることにより、サービスの提供における処理負荷の低減等を図ることができる。
（４）本開示の一態様に係る車載装置は、前記制御部は、アクセス可能な記憶領域に記憶されており、セキュリティレベルに関する設定情報を含むサービステーブルを参照することにより、セキュリティレベルを特定する。
　本態様にあたっては、車載装置の制御部は、アクセス可能な記憶領域に記憶されているサービステーブルを参照することにより、車載ＥＣＵから要求されたサービスのセキュリティレベルを特定する。例えば、車載装置の記憶部等、車載装置の制御部からアクセス可能な記憶領域に記憶されているサービステーブルには、当該車載装置が提供可能なサービスの名称（サービス名）とセキュリティレベルとがテーブル形式にて関連付けられている。車載装置の制御部は、このようにサービス名とセキュリティレベルとが関連付けられたサービステーブルを参照することにより、車載ＥＣＵからの要求データに応じて、要求されるサービスのセキュリティレベルを効率的に特定することができる。
（５）本開示の一態様に係る車載装置は、前記制御部は、前記車両内における通信に影響を与える攻撃が実施された場合、前記サービステーブルに含まれているセキュリティレベルに関する設定情報を変更し、変更されたセキュリティレベルに基づき生成した提供データを、前記車載ＥＣＵへ再送する。
　本態様にあたっては、車載装置の制御部は、例えばＩＤＳ（Intrusion Detection System）の機能を発揮し、車両内における通信に影響を与える攻撃、すなわち車載ネットワークにおける不正な攻撃を検出する。又は、車載装置の制御部は、ＩＤＳ等の不正検出機能を有する他のＥＣＵ等から、不正検出を示すアラート等のメッセージを取得するものであってもよい。又は、要求データを送信した車載ＥＣＵから、セキュリティレベルの変更要求を含む要求データを受信した場合、車両に対し攻撃が実施された判断するものであってもよい。車載装置の制御部は、このように車載ネットワーク上の通信を介して車両に対し攻撃が実施されたと判断した場合、サービステーブルに含まれているセキュリティレベルに関する設定情報を変更、すなわち当該セキュリティレベルを上昇させるようにサービステーブルを修正する。車載装置の制御部は、セキュリティレベルを変更した旨を示すべく、変更されたセキュリティレベルに基づき提供データを生成し、生成した提供データを、車載ＥＣＵへ再送する。このように車載装置の制御部は、車両に対する攻撃に応じて、動的にサービステーブルにて定義されているセキュリティレベルを変更（上昇）させ、より高いセキュリティレベルに応じたセキュリティ処理を施した提供データを生成し、車載ＥＣＵに提供（送信）する。従って、車載ＥＣＵに対するサービスの提供（センサ情報等を含むメッセージの送信）を継続しつつ、車両に対する攻撃状態に応じた適切な通信セキュア環境を担保することができる。
（６）本開示の一態様に係る車載装置は、前記制御部は、取得した要求データの正当性を判定し、正当性の判定結果が肯定的である場合、提供データを出力し、正当性の判定結果が否定的である場合、提供データを出力しない。
　本態様にあたっては、車載ＥＣＵから取得した要求データには、例えば、要求データの送信元である車載ＥＣＵを示すデジタル署名等、当該要求データの送信元正当性を担保する情報が含まれている。車載装置の制御部は、要求データに含まれるデジタル署名等に基づき、当該要求データの正当性を判定し、判定結果が肯定的（正当）である場合、提供データを車載ＥＣＵへ出力し、判定結果が否定的（不正）である場合、提供データを車載ＥＣＵへ出力しない。このようにサービスに関する要求及び提供に関する通信において、サービスの提供の起因となる要求データに対しても、セキュリティ的な観点からの判定処理を行い、判定結果が否定的である場合は提供データの出力を行わないため、例えば不正な車載ＥＣＵ等へサービスが提供されることを効果的に抑制することができる。
（７）本開示の一態様に係る車載装置は、前記制御部は、正当性の判定結果が肯定的である場合、セッション鍵を生成し、前記セッション鍵を含めた提供データを前記車載ＥＣＵへ出力する。
　本態様にあたっては、車載装置の制御部は、車載ＥＣＵから取得した要求データに対する正当性の判定結果が肯定的である場合、例えば発生させた乱数を用いた共通鍵から成るセッション鍵を生成する。車載装置の制御部は、生成したセッション鍵を含めた、又は付与した提供データを車載ＥＣＵへ出力し、以降、サービスの提供（サービスに対応するセンサ情報等の送信）において、当該セッション鍵にて暗号化したメッセージ、すなわち暗号化したセンサ情報等をペイロードに格納したメッセージを車載ＥＣＵへ出力する。車載ＥＣＵは、車載装置から取得した提供データに含まれるセッション鍵を用いて、以降、車載装置から送信されるサービスのメッセージ（暗号化されたセンサ情報等）を復号することにより、当該サービスの提供を受けることができる。このようにサービスに関する要求及び提供に関する通信の実行都度、生成したセッション鍵を用いて暗号化することにより、当該サービスの提供のための送信されるメッセージに対する堅牢性を担保することができる。
（８）本開示の一態様に係る車載装置は、前記車載ＥＣＵからの要求データは、前記車載ＥＣＵが保持する秘密鍵に対応した公開鍵を含み、前記制御部は、前記車載ＥＣＵの公開鍵を用いて暗号化した提供データを、前記車載ＥＣＵへ出力する。
　本態様にあたっては、車載ＥＣＵからの要求データは、車載ＥＣＵが保持する秘密鍵に対応した公開鍵を含む。この場合、車載ＥＣＵからの要求データには、当該車載ＥＣＵ自身を証明する公開鍵証明書が含まれており、公開鍵は、当該公開鍵証明書に含まれる（公開鍵証明書内に存在する）ものであってもよい。車載装置の制御部は、車載ＥＣＵからの要求データに含まれる公開鍵を用いて提供データのペイロードを暗号化し、当該暗号化した提供データを車載ＥＣＵへ出力する。このように要求データに応答する提供データに対しても、暗号化を行うものであり、当該暗号化は、車載ＥＣＵからの公開鍵による非対称鍵を用いるため、提供データに対する堅牢性を担保することができる。
（９）本開示の一態様に係る車載装置は、前記車載ＥＣＵとの通信のプロコトルは、ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）であり、要求データは、ＳＯＭＥ／ＩＰにおけるＦｉｎｄ　Ｓｅｒｖｉｃｅに相当し、提供データは、ＳＯＭＥ／ＩＰにおけるＯｆｆｅｒ　Ｓｅｒｖｉｃｅに相当する。
　本態様にあたっては、車載装置と車載ＥＣＵとにおけるサービスに関する要求及び提供に関する通信のプロコトルは、ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）である。この際、車載ＥＣＵが送信する要求データは、ＳＯＭＥ／ＩＰにおける”Ｆｉｎｄ　Ｓｅｒｖｉｃｅ”に相当し、すなわち車載ＥＣＵは、ＳＯＭＥ／ＩＰ－ＳＤ（Service Discovery）におけるクライアントに相当する。車載装置が送信する提供データは、ＳＯＭＥ／ＩＰにおける”Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ”に相当し、すなわち車載装置は、ＳＯＭＥ／ＩＰ－ＳＤ（Service Discovery）におけるサーバに相当する。このように車載装置と車載ＥＣＵとがＳＯＭＥ／ＩＰの通信プロコトルによる通信を行うにあたり、車載装置及び車載ＥＣＵにより送受信される”Ｆｉｎｄ　Ｓｅｒｖｉｃｅ”及び”Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ”に対し、メッセージ単位でのセキュリティ処理を施すことが可能となり、ＳＯＭＥ／ＩＰを用いた通信における堅牢性を担保することができる。
（１０）本開示の一態様に係る車載装置は、前記車載ＥＣＵと車載装置とは単一の装置として構成され、前記車載ＥＣＵと車載装置との間における通信は、車載装置におけるアプリケーション間の通信に相当する。
　本態様にあたっては、車載ＥＣＵと車載装置とは単一の装置として構成され、車載ＥＣＵと車載装置との間における通信、すなわちサービスに関する要求及び提供に関する通信は、車載装置におけるアプリケーション間の通信（プロセス間通信）として実行される。このように車載ネットワークを介して、異なる通信ノード間における通信のみならず、単一の装置である車載装置に対しても、サービスに関する要求及び提供に関する通信における堅牢性を担保することができる。すなわち、単一の装置として構成される車載装置が複数のアプリケーションを実行する際、これらアプリケーション間にてサービスに関する要求及び提供に関するプロセス間通信が行われる場合であっても、通信における堅牢性を担保することができる。又は、車載装置に例えばＨｙｐｅｒｖｉｓｏｒ（ハイパーバイザー）等の仮想化システムが適用され、当該車載装置が、仮想化システムによって生成された複数の仮想環境（仮想マシン）として動作する場合、これら複数の仮想マシンそれぞれが実行するアプリケーション間でのサービスの要求及び提供に関する通信における堅牢性を担保することができる。
（１１）本開示の一態様に係る情報処理方法は、車両に搭載される車載ＥＣＵと通信可能に接続されるコンピュータに、前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、生成した提供データを前記車載ＥＣＵへ出力する処理を実行させる。
　本態様にあたっては、コンピュータを、車載ＥＣＵから、サービスの要求に関する要求データが送信された際、当該要求データに対し適切なセキュリティ処理を施した提供データを出力することができる車載装置として機能させる情報処理方法を提供することができる。
（１２）本開示の一態様に係る車載システムは、車両に搭載される車載ＥＣＵと、前記車載ＥＣＵと通信可能に接続される車載装置とを含む車載システムであって、前記車載ＥＣＵは、サービスの要求に関する要求データを生成し、生成した要求データを前記車載装置へ出力し、前記車載装置は、前記車載ＥＣＵから要求データを取得し、取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、生成した提供データを前記車載ＥＣＵへ出力する。
　本態様にあたっては、車載ＥＣＵから、サービスの要求に関する要求データが送信された際、当該要求データに対し適切なセキュリティ処理を施した提供データを出力することができる車載装置を含む車載システム提供することができる。
[本開示の実施形態の詳細]
　本開示をその実施の形態を示す図面に基づいて具体的に説明する。本開示の実施形態に係る車載装置２を、以下に図面を参照しつつ説明する。なお、本開示はこれらの例示に限定されるものではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。
（実施形態１）
　以下、実施の形態について図面に基づいて説明する。図１は、実施形態１に係る車載装置２を含む車載システムの構成を例示する模式図である。図２は、車載装置２の物理構成を例示するブロック図である。車載システムＳは、車両Ｃに搭載された車載装置２を主たる装置として構成され、当該車載装置２は、車載ネットワークを介して１つ以上の車載ＥＣＵ６と通信可能に接続される。更に、車載装置２は、車外通信装置１を介して、インターネット等の車外ネットワークに接続される外部サーバ又はスマートホン等の携帯端末等と通信可能に接続されるものであってもよい。
　車載装置２は、例えば、ＳＯＭＥ／ＩＰサーバとして機能し、車載ＥＣＵ６はＳＯＭＥ／ＩＰクライアントとして機能する。詳細は後述するが、車載装置２と車載ＥＣＵ６とは、ＳＯＭＥ／ＩＰ通信を用いて、車載装置２からのサービスの提供に伴うメッセージ（要求データ：Ｆｉｎｄ　Ｓｅｒｖｉｃｅ、提供データ：Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）の送受信を行う。なお、車載装置２と車載ＥＣＵ６との通信プロトコルは、ＳＯＭＥ／ＩＰに限定されず、サービスの要求（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ等と同様の要求データ）及び提供（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ等と同様の提供データ）に伴うメッセージの送受信を行う他の通信プロトコルに対して用いるものであってもよい。
　ＳＯＭＥ／ＩＰサーバとして機能する車載装置２は、当該車載装置２に接続される各種センサ等、及び複数の車載ＥＣＵ６それぞれに接続される各種センサ等が検出したセンサ情報を取得（アップリンク）し、記憶部４に記憶されているデータベース（ＤＢ）に保存することにより、サービスのインスタンスである各種センサ情報等を一元管理するものであってもよい。車載装置２は、更に車外通信装置１を介して、外部サーバ又は携帯端末（スマートホン）等から、サービスのインスタンスとなる各種データを取得し、データベース（ＤＢ）に保存するものであってもよい。車載装置２は、このようにデータベース（ＤＢ）にて一元管理した各種センサ情報等を、サービスを要求する車載ＥＣＵ６に対し、ＳＯＭＥ／ＩＰ通信を用いて提供（ダウンリンク）するものであってもよい。
　車両Ｃには、車外通信装置１、車載装置２、及び種々の車載機器（アクチュエータ、センサ）を制御するための複数の車載ＥＣＵ６が、搭載されている。車外通信装置１と車載装置２とは、例えばシリアルケーブル等のハーネスにより通信可能に接続されている。車載装置２及び車載ＥＣＵ６は、Ｅｔｈｅｒｎｅｔ（イーサネット：登録商標）等の通信プロトコルに対応した車載ネットワーク７によって通信可能に接続されており、車載装置２は、ＩＰパケットの中継機能を有するイーサスイッチ（レイヤー２スイッチ又はレイヤー３スイッチ）として機能するものであってもよい。
　車外通信装置１は、車外通信部（図示せず）及び、車載装置２と通信するための入出力Ｉ／Ｆ（図示せず）（インターフェイス）を含む。車外通信部は、ＬＴＥ、４Ｇ、５Ｇ、ＷｉＦｉ等の移動体通信のプロトコルを用いて無線通信をするための通信装置であり、車外通信部に接続されたアンテナ１１を介して外部サーバ又は携帯端末等とデータの送受信を行う。車外通信装置１と外部サーバとの通信は、例えば公衆回線網又はインターネット等の外部ネットワークを介して行われる。
　車載装置２は、ＳＯＭＥ／ＩＰサーバとして機能し、例えばヴィークルコンピュータ等の中央制御装置にて構成され、車両Ｃの全体的な制御を行う統合ＥＣＵである。車載装置２は、更にイーサスイッチ（レイヤー２スイッチ又はレイヤー３スイッチ）等の中継装置（ＧＷ）として機能するものであってもよい。車載装置２は、通信に関する中継に加え、二次電池等の電源装置から出力された電力を分配及び中継し、自装置（車載装置２）に接続されるアクチュエータ等の車載機器に電力を供給する電力分配装置としても機能するＰＬＢ（Power Lan Box）であってもよい。又は、車載装置２は、車両Ｃ全体をコントロールするボディＥＣＵの一機能部として構成されるものであってもよい。更に、車載装置２は、ＩＤＳ（Intrusion Detection System）等の侵入検知装置として機能するものであってもよい。
　車載装置２は、制御部３、記憶部４及び車内通信部５を含む。制御部３は、ＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）等により構成してあり、記憶部４に予め記憶された制御プログラムＰ（プログラム製品）及びデータを読み出して実行することにより、種々の制御処理及び演算処理等を行うようにしてある。
　記憶部４は、ＲＡＭ（Random Access Memory）等の揮発性のメモリ素子又は、ＲＯＭ（Read Only Memory）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）若しくはフラッシュメモリ等の不揮発性のメモリ素子により構成してあり、制御プログラムＰ及び処理時に参照するデータが予め記憶してある。記憶部４に記憶された制御プログラムＰ（プログラム製品）は、車載装置２が読み取り可能な記録媒体Ｍから読み出された制御プログラムＰ（プログラム製品）を記憶したものであってもよい。また、図示しない通信網に接続されている図示しない外部コンピュータから制御プログラムＰをダウンロードし、記憶部４に記憶させたものであってもよい。
　記憶部４には、当該車載装置２に接続される各種センサ等、及び複数の車載ＥＣＵ６それぞれに接続される各種センサ等が検出したセンサ情報を保存及び管理するデータベース（ＤＢ）が記憶されているものであってもよい。当該データベース（ＤＢ）に保存されている各種センサ情報等は、ＳＯＭＥ／ＩＰ通信を用いて、ＳＯＭＥ／ＩＰクライアントである車載ＥＣＵ６それぞれに対し、サービスとして提供される。
　車内通信部５は、例えばイーサネット（ＴＣＰ／ＩＰ）等の通信プロトコルを用いた入出力インターフェイス（イーサネットＰＨＹ部）である。イーサネットＰＨＹ部等にて構成される車内通信部５は、車載装置２と車載ＥＣＵ６とが通信するための物理層に対応した通信部として機能する。
　車内通信部５は、複数個設けられており、車内通信部５夫々に、車載ネットワーク７を構成する通信線７１（イーサネットケーブル）夫々が接続されている。このように車内通信部５を複数個設けることにより、車載ネットワーク７を複数個のセグメントに分け、各セグメントに車載ＥＣＵ６を、当該車載ＥＣＵ６の機能に応じて接続するものであってもよい。車載装置２の制御部３は、車内通信部５を介して車載ネットワーク７に接続されている車載ＥＣＵ６と相互に通信する。
　車載ＥＣＵ６は、ＳＯＭＥ／ＩＰクライアントとして機能し、車載装置２と同様に制御部、記憶部及び車内通信部を含む。車載ＥＣＵ６には、例えば、ＬｉＤＡＲ（Light Detection and Ranging）、人感センサ、ＣＭＯＳカメラ、赤外線センサ等の各種センサが接続されており、これら各種センサ等から取得した各種センサ情報を車載装置２に送信するものであってもよい。車載ＥＣＵ６は、更に各種スイッチ、カーエアコン、ランプ装置、エンジン又は駆動モータ等のパワートレイン装置等のアクチュエータが接続され、これらアクチュエータを制御する個別ＥＣＵとして構成されるものであってもよい。車載ＥＣＵ６は、更にＩＤＳ（Intrusion Detection System）等の侵入検知装置として機能するものであってもよい。
　図３は、サービステーブルを例示した説明図である。図４は、セキュリティ処理テーブルを例示した説明図である。車載装置２の記憶部４等、車載装置２の制御部３がアクセス可能な記憶領域には、サービスに対するセキュリティレベルに関する設定情報（サービステーブル）、及び当該セキュリティレベルに応じたセキュリティ処理に関する情報（セキュリティ処理テーブル）が、例えばテーブル形式にて記憶されている。
　サービステーブルは、管理項目（フィールド）として、例えば、クライアントＩＰ、アプリケーション名、サービス名、及びセキュリティレベルを含む。クライアントＩＰの管理項目には、例えばＳＯＭＥ／ＩＰのクライアントである車載ＥＣＵ６のＩＰアドレスが格納される。又は、当該ＩＰアドレスに替えてＭＡＣ（Media Access Control address）アドレスが格納されるものであってもよい。車載装置２の制御部３は、要求データを取得した場合、当該要求データの送信アドレスと、サービステーブルのクライアントＩＰの管理項目にて予め定義されているＩＰアドレスとを対比することにより、要求データの正当性を判定するものであってもよい。
　アプリケーション名の管理項目には、例えばＳＯＭＥ／ＩＰのクライアントである車載ＥＣＵ６が実行するアプリケーションの名称であり、当該車載ＥＣＵ６が要求するサービスに対応するアプリケーションの名称が格納される。車載装置２の制御部３は、要求データを取得した場合、当該要求データに含まれるアプリケーション名と、サービステーブルのアプリケーション名の管理項目にて予め定義されているアプリケーション名とを対比することにより、要求データの正当性を判定するものであってもよい。
　サービス名の管理項目には、同一レコードにて格納されるアプリケーション名に対応するサービスの名称（サービスのインスタンスの名称）が格納される。サービス名の管理項目にて定義（格納）されているサービスが、ＳＯＭＥ／ＩＰ－ＳＤ（Service Discovery）に基づき要求及び提供の対象となるサービスに相当する。
　セキュリティレベルの管理項目には、同一レコードにて格納されるサービス名に対応するセキュリティレベルの値が格納される。本実施形態において、当該セキュリティレベルの値は、数字にて示され、値が大きくなるほど、セキュリティレベルが高くなるように設定（低：レベル１＜レベル２＜レベル３・・・＜レベルＮ：高）されている。当該セキュリティレベルは、一例として３レベルにて設定されるものであってもよく、更に細分化して４レベル以上（４段階以上）にてセキュリティレベルが設定されるものであってもよい。
　ＳＯＭＥ／ＩＰクライアントとして機能する車載ＥＣＵ６から送信される要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）には、当該車載ＥＣＵ６が実行するアプリケーション名（AppA）が含まれている。ＳＯＭＥ／ＩＰサーバとして機能する車載装置２は、車載ＥＣＵ６から取得した要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）に含まれるアプリケーション名（AppA）に基づき、サービステーブルを参照することにより、対応するサービス名を特定することができる。又は、車載ＥＣＵ６から要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）にサービス名（service）が含まれており、車載装置２は、当該要求データに応じて、提供するサービスを特定するものであってもよい。
　セキュリティ処理テーブルは、管理項目（フィールド）として、例えば、セキュリティレベル及びセキュリティ処理を含む。セキュリティレベルの管理項目には、サービステーブルのセキュリティレベルの管理項目にて定義されているセキュリティレベルの値が格納される。従って、セキュリティ処理テーブルとサービステーブルとは、当該セキュリティレベルの管理項目により正規化される。
　セキュリティ処理の管理項目には、同一レコードにて格納されるセキュリティレベルの値に対応するセキュリティ処理の処理内容が格納される。例えば、セキュリティレベルが３段階（低：レベル１＜レベル２＜レベル３：高）に設定されている際、セキュリティレベルが最も低いレベル１である場合、セキュリティ処理は、ＳＯＭＥ／ＩＰに関するメッセージに対し、メッセージ認証コード（ＭＡＣ：Message Authentication Code）を付与する。又は、セキュリティ処理は、ＳＯＭＥ／ＩＰに関するメッセージに対し、更にカウンタを付与するものであってもよい。ＭＡＣを付与することにより、メッセージが途中で改竄やすり替えに合っていないか（メッセージの完全性）を検証することができる。これにより、メッセージの改竄又は再送攻撃に対応することができる。
　セキュリティレベルが中間に位置するレベル２である場合、セキュリティ処理は、ＳＯＭＥ／ＩＰに関するメッセージに対し、ＭＡＣの付与に替えて（ＭＡＣの代わりに）、車載装置２自身を示すデジタル署名を付与する。又は、セキュリティ処理は、ＳＯＭＥ／ＩＰに関するメッセージに対し、ＭＡＣの付与に加えて、更に車載装置２自身を示すデジタル署名を付与するものであってもよい。又は、セキュリティ処理は、ＳＯＭＥ／ＩＰに関するメッセージに対し、更にロースベースを付与するものであってもよい。デジタル署名を付与することにより、ＳＯＭＥ／ＩＰに関し車載装置２が送信したメッセージ（情報）が署名した車載装置２（本人）のものであること（正当な発信元から発信さらたメッセージ）と、及び改竄されていないことを証明することができる。これにより、メッセージの送信元になりすます攻撃、ロールベースに関する攻撃に対応することができる。
　セキュリティレベルが最も高いレベル３である場合、セキュリティ処理は、ＭＡＣに替えて（ＭＡＣの代わりに）付与したデジタル署名に加え、更にＳＯＭＥ／ＩＰに関するメッセージにおけるペイロード（ペイロードに格納されるセンサ情報等）を暗号化する処理を含む。又は、セキュリティ処理は、ＭＡＣ及びデジタル署名の付与に加え、更にＳＯＭＥ／ＩＰに関するメッセージにおけるペイロード（ペイロードに格納されるセンサ情報等）を暗号化する処理を含むものであってもよい。当該ペイロードの暗号化処理を行うにあたり、車載装置２の制御部３は、セッション鍵を生成し、生成したセッション鍵を提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）に含めて、車載ＥＣＵ６へ出力するものであってもよい。これにより、メッセージの盗聴攻撃に対応することができる。このような高いセキュリティレベルに設定するサービスのインスタンスは、例えば、ＧＰＳ情報、インフォテイメントシステムの著作権情報、スマートホン等の携帯端末の情報等であり、これら情報の保護を効率的に図ることができる。
　図５は、保護のあるＳＯＭＥ／ＩＰメッセージを例示した説明図である。ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）は、車載ネットワーク７にて送受信されるメッセージの制御に用いられるサービス指向のミドルウェアであり、ＯＳＩ（Open System Interconnection）においては、レイヤー４（ＴＣＰ／ＵＤＰ等）よりも上位レイヤーのプロトコルとして定義される。ＳＯＭＥ／ＩＰメッセージは、送信元アドレス及び送信先アドレス等を含むヘッダ領域、センサ情報等の提供されるサービスに対応するデータを格納するペイロード領域を含む。更に、当該ＳＯＭＥ／ＩＰメッセージは、本実施形態によるセキュリティレベルに応じて保護されることにより、カウント及びロールベース（デジタル署名）等から成る付帯情報、及びメッセージ認証コード（ＭＡＣ：Message Authentication Code）を含む。これら付帯情報及びＭＡＣは、ペイロード領域に格納されるものであってもよい。
　上述のとおり、ＳＯＭＥ／ＩＰメッセージに対する保護は、セキュリティレベルに応じて施され、例えば、レベル１ではＭＡＣ（及びカウント）の付与、レベル２では更にロールベース（デジタル署名）の付与、レベル３では更にペイロードの暗号化（セッション鍵による暗号化）が行われる。このようにＳＯＭＥ／ＩＰメッセージに対し、当該メッセージに対応するサービスのセキュリティレベルに応じて、施されるセキュリティ処理の種類を増加することにより、ＳＯＭＥ／ＩＰメッセージに対する保護態様のバリエーション化を図ることができる。
　図６は、車載装置２（サーバ）と車載ＥＣＵ６（クライアント）との処理シーケンスを例示した説明図である。本実施形態においては、車載装置２はＳＯＭＥ／ＩＰ－ＳＤ（Service Discovery）のサーバとして機能し、車載ＥＣＵ６はクライアントとして機能する。
　車載装置２及び車載ＥＣＵ６それぞれは、公開鍵証明書それぞれを保持（記憶）しており、車載装置２と車載ＥＣＵ６とは、相互認証を実現するものであってもよい。その上で、車載装置２及び車載ＥＣＵ６は、ＳＯＭＥ／ＩＰプロコトルによる要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）及び提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）におけるペイロードにセキュリティレベルに応じた情報を付与することにより、認証プロコトルを実現するものであってもよい。車載装置２及び車載ＥＣＵ６は、要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）及び提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）の送受信後に行われるサブスクライブ要求データ等（Ｓｕｂｓｃｒｉｂｅ　Ｅｖｅｎｔｇｒｏｕｐ、Ｓｕｂｓｃｒｉｂｅ　Ｅｖｅｎｔ　ＡＣＫ）においても、セキュリティレベルに応じたセキュリティ処理を施すものであってもよい。
　車載ＥＣＵ６は、要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）を車載装置２に出力（送信）する（Ｓ０１）。車載ＥＣＵ６は、提供を要求するサービスに対応する（サービスを利用する）アプリケーション（AppA）を含めた要求データを生成する。車載ＥＣＵ６は、更に、当該要求データに車載ＥＣＵ６自身の公開鍵証明書（CertA）、車載ＥＣＵ６自身の秘密鍵によるデジタル署名（SigA）を含めて、要求データを生成するものであってもよい。車載ＥＣＵ６は、このように生成した要求データを車載装置２に出力（送信）する。
　車載装置２は、車載ＥＣＵ６から取得した要求データに基づき、サービス及びセキュリティレベルを特定する（Ｓ０２）。車載装置２は、車載ＥＣＵ６から要求データを取得し、当該要求データに含まれるデジタル署名（SigA）の検証を行うことにより、要求データの正当性、すなわち要求データの送信元が真の車載ＥＣＵ６であるかの判定を行う。当該判定の結果が否定的な結果である場合、車載装置２は、当該要求データへの対応を行わず、すなわち提供データを送信しないものであってもよい。また、事前共有鍵を用いてＡＥＡＤ（認証付き暗号：Authenticated Encryption with Associated Data）により当該要求データ等を暗号化し、ＭＡＣを付与して転送してもよい。ＡＥＡＤを用いることにより、暗号化と認証を同時に実行するものとなり、要求データ等に対する秘匿性、完全性、及び認証性を同時に担保することができる。
　当該判定の結果が肯定的な結果である場合、すなわち要求データの送信元が真の車載ＥＣＵ６であると判定した場合、車載装置２は、要求データに含まれるアプリケーション（AppA）の名称、又は要求データに含まれる公開鍵証明書（CertA）の内容から、サービスを受信するアプリケーションが要求するサービスの名称と、当該サービスを提供する際のセキュリティレベルを特定する。車載装置２は、当該サービス及びセキュリティレベルを特定するにあたり、記憶部４に記憶されているサービステーブルを参照するものであってもよい。車載装置２は、この際、サービステーブルにて定義されている各種内容と、車載ＥＣＵ６からの要求データに基づく内容とが適合しない等の問題がある場合、当該要求データへの対応を行わず、すなわち提供データを送信しないものであってもよい。
　車載装置２は、セッション鍵を生成する（Ｓ０３）。車載装置２は、これら判定結果等に基づき、車載ＥＣＵ６からの要求データが正当であると判断（判定）した場合、任意又は既知の手段を用いてセッション鍵（共通鍵：enckey）を生成する。
　車載装置２は、生成したセッション鍵を含めた提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を車載ＥＣＵ６に出力（送信）する（Ｓ０４）。車載装置２は、生成したセッション鍵（enckey）、車載装置２自身の公開鍵証明書（PubkeyB）、及び特定したセキュリティレベル（SecLevel）を含めた（ペイロードに格納）した提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を生成し、車載ＥＣＵ６に出力（送信）する。この際、車載装置２は、当該生成した提供データのペイロードを、車載ＥＣＵ６からの要求データに含まれる公開鍵証明書（CertA）内に存在する公開鍵で暗号化し、当該暗号化した提供データを車載ＥＣＵ６に出力（送信）するものであってもよい。この手順により、対応する秘密鍵の所有者であるもの（通信ノード）のみが復号できることが保証され、セッション鍵の機密性が確保される。
　車載ＥＣＵ６は、提供データを取得し、提供データに含まれるセッション鍵（enckey）を解凍（復号）する（Ｓ０５）。車載ＥＣＵ６は、車載装置２からの暗号化された提供データを取得し、車載ＥＣＵ６自身の公開鍵証明書（CertA）に対応する秘密鍵を用いて、当該暗号化された提供データのペイロードを復号する。車載ＥＣＵ６は、提供データに含まれる車載装置２自身の公開鍵証明書（PubkeyB）の正当性を検証し、正当であると判定して場合、当該提供データに含まれるセッション鍵（enckey）及びセキュリティレベル（SecLevel）を取得する。車載ＥＣＵ６は、これらセッション鍵（enckey）及びセキュリティレベル（SecLevel）を取得することにより、提供されるサービスのセキュリティレベルを認識すると共に、以降、セッション鍵にてペイロードが暗号化されたメッセージを復号することができる。また、このセッション鍵により事前共有鍵を更新しても良いものとする。
　車載装置２と車載ＥＣＵ６とによるＳＯＭＥ／ＩＰ通信において、要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）及び提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）の送受信が行われた後、サブスクライブ要求データ等（Ｓｕｂｓｃｒｉｂｅ　Ｅｖｅｎｔｇｒｏｕｐ、Ｓｕｂｓｃｒｉｂｅ　Ｅｖｅｎｔ　ＡＣＫ）においても、セキュリティレベルに応じたセキュリティ処理が施されるものであってもよい。車載装置２は、ＡＣＫを車載ＥＣＵ６に送信した後、提供するサービスのデータ（センサ情報等）を含むメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）に対し、セキュリティレベルに応じたセキュリティ処理を施した上で車載ＥＣＵ６に送信する。上述のとおり、車載装置２からのメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）は、例えば、セッション鍵を用いたペイロードの暗号化、ＭＡＣ及びデジタル署名の付与等、セキュリティレベルに応じた各種のセキュリティ処理が施される。
　本実施形態にて説明するセキュリティ処理の形態は、セキュリティレベルが比較的に高い（例えば、レベル３）場合を想定するものであり、これに限定されない。セキュリティレベルが比較的に低い（例えば、レベル１、２）場合、車載装置２はセッション鍵（enckey）を生成することなく、ＭＡＣ及びデジタル署名の付与等のセキュリティ処理を施した提供データを生成及び出力するものであってもよい。この場合、提供するサービスに応じて車載装置２が送信するメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）についても、ペイロードは暗号化することなく平文とし、ＭＡＣ及びデジタル署名の付与等のセキュリティ処理のみが、行われるものであってもよい。
　図７は、車載装置２の制御部３の処理を例示するフローチャートである。車載装置２の制御部３は、例えば車両Ｃが起動状態又は停止状態（ＩＧスイッチ又はパワースイッチが、オン又はオフ）において、定常的に以下の処理を行う。
　車載装置２の制御部３は、車載ＥＣＵ６からのサービスの要求に関する要求データを取得する（Ｓ１０１）。ＳＯＭＥ／ＩＰのクライアントとして機能する車載ＥＣＵ６は、要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）をＳＯＭＥ／ＩＰのサーバとして機能する車載装置２に送信する。車載ＥＣＵ６は、当該要求データに、サービスに対応するアプリケーション名（AppA）、車載ＥＣＵ６自身の公開鍵証明書（CertA）、及び車載ＥＣＵ６自身の秘密鍵によるデジタル署名（SigA）を含めるものであってもよい。
　車載装置２の制御部３は、要求データが正当であるか否かを判定する。（Ｓ１０２）。車載装置２の制御部３は、例えば要求データに含まれるデジタル署名（SigA）を検証することにより、要求データの正当性の判定、すなわち要求データが正当であるか否かを判定する。
　要求データが正当でない判定した場合（Ｓ１０２：ＮＯ）、すなわち要求データが不正であると判定した場合、車載装置２の制御部３は、不正な要求データを取得した旨を出力する（Ｓ１０２１）。車載装置２の制御部３は、要求データが正当でない、すなわち要求データが不正であると判定した場合、不正な要求データを取得した旨を、当該不正な要求データの受信時点と関連付けて記憶部４に記憶する。車載装置２の制御部３は、不正な要求データの受信時点と関連付けて記憶部４に記憶するにあたり、記憶部４に記憶されている異常履歴データベースに当該不正な要求データに関する事項を保存するものであってもよい。車載装置２の制御部３は、不正な要求データを取得した旨を、ＨＭＩ（Human Machine Interface）装置への表示出力、車外通信装置１を介して外部サーバへ送信するものであってもよい。
　要求データが正当であると判定した場合（Ｓ１０２：ＹＥＳ）、車載装置２の制御部３は、車載ＥＣＵ６に提供するサービス及びセキュリティレベルを特定する（Ｓ１０３）。車載装置２の制御部３は、要求データに含まれるアプリケーションの名称に基づき、サービステーブルを参照することにより、当該アプリケーションに対応するサービス及び、当該サービスを提供する際のセキュリティレベルを特定する。
　車載装置２の制御部３は、特定したセキュリティレベルに基づき提供データを生成する（Ｓ１０４）。例えば、セキュリティレベルが３段階（低：レベル１＜レベル２＜レベル３：高）に設定されている場合、車載装置２の制御部３は、特定したセキュリティレベルに応じたセキュリティ処理を施した提供データを生成する。
　車載装置２の制御部３は、例えば、記憶部４に記憶されているセキュリティ処理テーブルを参照することにより、セキュリティレベルに応じたセキュリティ処理を決定するものであってもよい。例えば、セキュリティレベルが最も低いレベル１である場合、車載装置２の制御部３は、車載ＥＣＵ６と共有している秘密鍵を用いて生成したＭＡＣを付与した提供データを生成する。セキュリティレベルが中間に位置するレベル２である場合、車載装置２の制御部３は、ＭＡＣの付与に加え、更に車載装置２自身を示すデジタル署名を付与した提供データを生成する。
　セキュリティレベルが最も高いレベル３である場合、車載装置２の制御部３は、ＭＡＣ及びデジタル署名の付与に加え、更に車載ＥＣＵ６からの公開鍵にて暗号化した提供データを生成する。この際、車載装置２の制御部３は、更にセッション鍵を含めて提供データを生成するものであってもよい。当該セッション鍵は、サービスを提供するにあたり送信するデータを暗号化する際、車載装置２及び車載ＥＣＵ６にて共通鍵として用いられるものであってもよい。すなわち、サービスを提供するにあたり送信されるメッセージのペイロードは、車載装置２の制御部３が当該セッション鍵を用いることにより暗号化されるものであってもよい。この場合、車載ＥＣＵ６は、車載装置２からのサービスの提供に応じて送信されるメッセージのペイロードを、セッション鍵を用いて復号する。
　このように車載装置２の制御部３は、セキュリティレベルに応じることにより、例えば、生成したセッション鍵（enckey）、車載装置２自身の公開鍵証明書（PubkeyB）、及び特定したセキュリティレベル（SecLevel）を含めた（ペイロードに格納）した提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を生成する。車載装置２の制御部３は、更に、車載ＥＣＵ６からの要求データに含まれる公開鍵（公開鍵証明書内に存在）を用いて、提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）のペイロードを暗号化するものであってもよい。
　このように車載装置２の制御部３は、セキュリティレベルの増加に応じて、すなわちセキュリティレベルが高くなるにつれ、提供データを生成する際に用いるセキュリティ処理の種類を増加するものであってもよい。又は、車載装置２の制御部３は、セキュリティレベルの増加に応じて、例えばＭＡＣを生成する際に用いる乱数の桁数を増加する等、ＭＡＣ等のセキュリティオブジェクトに対する解読難易性を向上させるものであってもよい。
　車載装置２の制御部３は、セキュリティレベルに応じて生成した提供データを車載ＥＣＵ６へ出力する（Ｓ１０５）。車載装置２の制御部３は、セキュリティレベルに応じて生成及び暗号化した提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を車載ＥＣＵ６へ出力する。
　車載装置２の制御部３は、セキュリティレベルに応じて、サービスの提供を開始する（Ｓ１０６）。車載装置２の制御部３は、セキュリティレベルに応じて、サービスの提供に伴うメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）を、セッション鍵を用いて暗号化して車載ＥＣＵ６に送信する。又は、セキュリティレベルが比較的に低い場合、ペイロードを暗号化することなく平文とし、ＭＡＣ及びデジタル署名の付与等がされたメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）を、車載ＥＣＵ６に送信するものであってもよい。車載装置２の制御部３は、Ｓ１０６又はＳ１０２１の処理の実行後、本フローにおける一連の処理を終了する。又は、車載装置２の制御部３は、Ｓ１０６又はＳ１０２１の処理の実行後、再度Ｓ１０１からの処理を実行すべく、ループ処理を行うものであってもよい。
　車載装置２の制御部３は、複数のサービスの提供を行う場合、当該サービス毎にプロセスを生成し、これら複数のサービスの提供に関する処理を複数のプロセスにより並列処理するものであってもよい。車載装置２の制御部３は、提供するサービスの個数に応じて、複数のプロセスにより並列処理を行う場合、これらサービスのセキュリティレベルに応じて、当該サービスを実行するプロセスへ割り当てるリソース量を変更するものであってもよい。すなわち、セキュリティレベルの高いサービスを提供するためのプロセスに対しては、セキュリティレベルの低いサービスを提供するためのプロセスよりも、ＣＰＵ割当時間、メモリ占有量、又はスレッド数等のハードウェアリソースを多く設定する（割り当てる）ものであってもよい。これにより、セキュリティレベルが高いサービスに関する処理を比較的に優先して実行することができる。
（実施形態２）
　図８は、実施形態２（セキュリティレベルの動的変更）に係る車載装置２（サーバ）と車載ＥＣＵ６（クライアント）との処理シーケンスを例示した説明図である。実施形態２の車載装置２及び車載ＥＣＵ６は、実施形態１にて提供するサービスに応じたメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）が車載装置２から車載ＥＣＵ６に対し、周期的、定期的又は定常的に送信された後、当該サービスのセキュリティレベルが変更されるイベント等に関する処理（シーケンス）を示すものである。
　車載ＥＣＵ６は、セキュリティレベルの変更に関する要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）を車載装置２に出力（送信）する（Ｓ２１）。車載ＥＣＵ６は、例えば、自身に対する攻撃又は車載ネットワーク７における攻撃を検出した場合、セキュリティレベルの変更に関する要求データを生成し、車載装置２に出力（送信）する。車載ＥＣＵ６は、実施形態１の要求データと同様にアプリケーション（AppA）、車載ＥＣＵ６自身の公開鍵証明書（CertA）、及び車載ＥＣＵ６自身の秘密鍵によるデジタル署名（SigA）を含め、更にセキュリティレベルの変更（増加）の要求（変更後のセキュリティレベルの値：rSecLevel）を含めて要求データを生成する。車載ＥＣＵ６は、変更後のセキュリティレベルの値（rSecLevel）を含む要求データを車載装置２に出力（送信）する。
　車載装置２は、車載ネットワーク７に対し攻撃を受けたと判定する（Ｓ２２）。車載装置２は、セキュリティレベルの変更に関する要求データを車載ＥＣＵ６から取得した場合、車載ネットワーク７に対し攻撃を受けたと判定する。又は、車載装置２は、セキュリティレベルの変更に関する要求データを車載ＥＣＵ６から取得しない場合であっても、例えばＩＤＳ等の機能を発揮し、車両Ｃ内における通信に影響を与える攻撃、すなわち車載ネットワーク７における不正な攻撃を検出した場合、攻撃を受けたと判定するものであってもよい。
　車載装置２は、セキュリティレベルの変更を行う（Ｓ２３）。車載装置２は、車載ＥＣＵ６から取得した要求データに含まれるアプリケーション名（AppA）及びセキュリティレベルの値（rSecLevel）に基づき、サービステーブルにて定義されているサービスのセキュリティレベルを変更する。当該セキュリティレベルの変更により、対象となるサービスのセキュリティレベルは、攻撃が検出されるより前のセキュリティレベルよりも高いセキュリティレベルに設定される。
　車載装置２は、セッション鍵を生成する（Ｓ２４）。車載装置２は、実施形態１の処理Ｓ０３と同様にセッション鍵を再度、生成（再生成）する。このようにセッション鍵を再生成することにより、攻撃検出の前後において、車載装置２と車載ＥＣＵ６との間におけるＳＯＭＥ／ＩＰ通信にて用いられるセッション鍵を異ならせることができる。
　車載装置２は、セキュリティレベルの変更に関する提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を車載ＥＣＵ６に出力（送信）する（Ｓ２５）。車載装置２は、実施形態１のＳ０４と同様に、再生成したセッション鍵（enckey）、車載装置２自身の公開鍵証明書（PubkeyB）、及び変更後のセキュリティレベル（SecLevel）を含めた（ペイロードに格納した）提供データ（Ｏｆｆｅｒ　Ｓｅｒｖｉｃｅ）を生成し、車載ＥＣＵ６に出力（送信）する。
　車載ＥＣＵ６は、再送された提供データを取得し、提供データに含まれるセッション鍵（enckey）を解凍（復号）する（Ｓ２６）。車載ＥＣＵ６は、実施形態１と同様に取得した提供データを、秘密鍵を用いて復号することにより、提供データに含まれるセッション鍵（enckey）を解凍（復号）する。当該セッション鍵（enckey）は、攻撃検出をトリガーとして再生成されたセッション鍵である。車載ＥＣＵ６は、提供データに含まれるセキュリティレベル（SecLevel）を参照することにより、変更されたセキュリティレベルを認識することができる。車載ＥＣＵ６は、変更されたセキュリティレベルを認識すると共に、車載装置２から再送されたセッション鍵を用いて、攻撃を検出した後においても、車載装置２からのサービスの提供を継続して受けることができ、当該サービスの提供に伴い送信されたメッセージ（Ｅｖｅｎｔ／Ｆｉｅｌｄ　Ｎｏｔｉｆｉｃａｔｉｏｎ）を用いて、アプリケーションを実行することができる。
　図９は、車載装置２の制御部３の処理を例示するフローチャートである。車載装置２の制御部３は、例えば車両Ｃが起動状態又は停止状態（ＩＧスイッチ又はパワースイッチが、オン又はオフ）において、定常的に以下の処理を行う。
　車載装置２の制御部３は、実施形態１の処理Ｓ１０１からＳ１０６と同様にＳ２０１からＳ２０６までの処理を行う。車載装置２の制御部３は、これら処理を行うことにより、実施形態１と同様にセキュリティレベルに応じて、サービスの提供を開始している状態であり、すなわちサービスの提供に伴うメッセージ（サービスに対応するセンサ情報等をペイロードに格納したメッセージ）を、クライアントである車載ＥＣＵ６に継続的に送信（出力）している。
　車載装置２の制御部３は、攻撃を検出したか否かを判定する（Ｓ２０７）。車載装置２の制御部３は、例えば、車載ＥＣＵ６からの攻撃を受けている旨の通知を取得した場合、又は車載装置２が有するＩＤＳの機能により車両Ｃ内における通信に影響を与える攻撃、すなわち車載ネットワーク７における不正な攻撃を検出した場合、攻撃を検出したと判定する。車載ＥＣＵ６からの攻撃を受けている旨の通知は、例えば、当該車載ＥＣＵ６から、現時点にて提供を受けているサービスのセキュリティレベルの変更を要求するための要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）によるものであってもよい。この際、車載装置２の制御部３は、車載ＥＣＵ６からセキュリティレベルの変更を要求するための要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）を取得した場合、車載ネットワーク７における不正な攻撃を検出したと判定するものであってもよい。攻撃を検出していないと判定した場合（Ｓ２０７：ＮＯ）、車載装置２の制御部３は、再度Ｓ２０７の処理を実行すべくループ処理を行う。
　攻撃を検出したと判定した場合（Ｓ２０７：ＹＥＳ）、車載装置２の制御部３は、変更したセキュリティレベルに基づき提供データを生成する（Ｓ２０８）。攻撃を検出したと判定した場合、車載装置２の制御部３は、車載ＥＣＵ６からの要求データ（Ｆｉｎｄ　Ｓｅｒｖｉｃｅ）に基づき、現時点に提供しているサービスのセキュリティレベルを変更し、変更したセキュリティレベルに基づき提供データを生成する。
　車載装置２の制御部３は、例えば、例えば、記憶部４に記憶されているサービステーブルを参照し、当該サービスの現時点におけるセキュリティレベルを特定する。その上で、車載装置２の制御部３は、車載ＥＣＵ６からの要求データに含まれる変更後のセキュリティレベルの値（rSecLevel）に基づき、サービステーブルを変更する。これにより、対象となるサービス（現時点に提供しているサービス）が現時点のセキュリティレベルよりも高いセキュリティレベルとなるように、サービステーブルを設定することができる。例えば、対象となるサービスの現時点のセキュリティレベルが１の場合、車載装置２の制御部３は、当該セキュリティレベルを２に変更する。対象となるサービスの現時点のセキュリティレベルが２の場合、車載装置２の制御部３は、当該セキュリティレベルを３に変更する。対象となるサービスの現時点のセキュリティレベルが最上位の値（例えば３等）である場合、車載装置２の制御部３は、当該最上位の値であるセキュリティレベルを維持するものであってもよい。
　車載装置２の制御部３は、検出した攻撃の影響度（深刻度）に応じて、セキュリティレベルの増加度合を異ならせるものであってもよい。車載装置２が例えばＩＤＳ（Intrusion Detection System）の機能を有する場合、当該ＩＤＳの機能を用いて検出した攻撃の影響度を導出し、例えば、車両Ｃにおける制御等に対する影響度が高い場合はセキュリティレベルを２段階増加させ、影響度が低い場合はセキュリティレベルを１段階増加させるものであってもよい。セキュリティレベルを増加させることにより、ＳＯＭＥ／ＩＰ通信におけるオーバヘッドも増加するものとなるが、攻撃による車両Ｃの制御等に対する影響度を鑑みて、セキュリティレベルを増加（変更）することにより、当該オーバヘッドが過度に発生することを抑制することができる。
　車載装置２の制御部３は、このように車載ネットワーク７における不正な攻撃を検出した場合、実施形態１のＳ１０２１と同様に、攻撃を検出した旨を当該攻撃の検出時点と関連付けて、記憶部４に記憶（異常履歴データベースに保存）するものであってもよい。車載装置２の制御部３は、更に攻撃を検出した旨を、ＨＭＩ（Human Machine Interface）装置への表示出力、車外通信装置１を介して外部サーバへ送信するものであってもよい。
　車載装置２の制御部３は、提供データを車載ＥＣＵ６へ再送する（Ｓ２０９）。車載装置２の制御部３は、セキュリティレベルを変更した旨を示す提供データを生成（再生成）し、当該再生成した提供データを車載ＥＣＵ６へ再送する。車載装置２の制御部３は、提供データに、例えば、変更したセキュリティレベルの値、自身を示す公開鍵証明書、及びセッション鍵を含めるものであってもよい。この際、車載装置２の制御部３は、セッション鍵についても再度、生成（再生成）し、再生成したセッション鍵を含めて、セキュリティレベルを変更した旨を示す提供データを車載ＥＣＵ６へ再送するものであってもよい。
　セッション鍵は、当該提供データの再送以降において、サービスの提供に伴いサーバである車載装置２が、クライアントである車載ＥＣＵ６にメッセージを送信する際、メッセージのペイロードに含まれるデータ（センサ情報等のサービスのインスタンス）を暗号化及び復号化する際に用いられる。従って、攻撃の検出に応じて、すなわち攻撃検出の前後において、車載装置２と車載ＥＣＵ６との間におけるＳＯＭＥ／ＩＰ通信にて用いられるセッション鍵を異ならせることにより、当該サービスの提供のための送信されるメッセージに対する堅牢性を担保することができる。
　車載装置２の制御部３は、変更したセキュリティレベルにてサービスの提供を継続する（Ｓ２１０）。車載装置２の制御部３は、変更したセキュリティレベル、すなわち対象となるサービスのセキュリティレベルが変更されたサービステーブルを参照し、当該変更されたセキュリティレベルに応じて、サービスの提供に伴うメッセージを生成し、当該メッセージを車載ＥＣＵ６に送信する。これにより、車載ネットワーク７に対する攻撃が行われた場合であっても、車載装置２の制御部３は、当該攻撃に対する堅牢性を担保しつつ、車載ＥＣＵ６に対するサービスの提供を継続することができる。
（実施形態３）
　図１０は、実施形態３（車載装置２内のプロセス間通信）に係る車載装置２の制御部３に含まれる機能部を例示する機能ブロック図である。本実施形態においては、実施形態１における車載装置２（ＳＯＭＥ／ＩＰサーバ）と車載ＥＣＵ６（ＳＯＭＥ／ＩＰクライアント）とは、単一の装置として構成され、すなわち車載装置２がＳＯＭＥ／ＩＰサーバ及びＳＯＭＥ／ＩＰクライアントの双方の機能を有し、双方の処理を担う。
　車載装置２の制御部３は、記憶部４に記憶されている制御プログラムを実行することにより、アプリケーション実行部３０１、ＳＯＭＥ／ＩＰマスタ部３０２、及びプラットフォーム部３０３として機能する。すなわち、記憶部４に記憶されている制御プログラムは、サービスを利用するアプリケーションプログラム、ＳＯＭＥ／ＩＰプロコトルに基づく通信プログラム、通信ソケットモジュール及びソフトウェアライブラリ等にて構成されるプラットフォーム部３０３を含む。
　アプリケーション実行部３０１は、サービスを利用するアプリケーションプログラムを実行することにより、サービスのインスタンスであるセンサ情報又はカメラ画像等を用いて、各種の制御処理又は情報処理を行う。ＳＯＭＥ／ＩＰマスタ部３０２は、ＳＯＭＥ／ＩＰ通信に関する制御全般を行う。更にＳＯＭＥ／ＩＰマスタ部３０２は、車載装置２に接続される各種センサ等、及び車載ネットワーク７に接続される複数の車載ＥＣＵ６それぞれに接続される各種センサ等が検出したセンサ情報を取得し、記憶部４に記憶されているデータベース（ＤＢ）に保存するものであってもよい。ＳＯＭＥ／ＩＰマスタ部３０２は、当該データベースに一元的に保存された各種センサ情報等をサービスのインスタンスとして、ＳＯＭＥ／ＩＰ通信を用いてアプリケーション実行部３０１に提供するものであってもよい。プラットフォーム部３０３は、アプリケーション実行部３０１とＳＯＭＥ／ＩＰマスタ部３０２とによるプロセス間通信、すなわちＳＯＭＥ／ＩＰ通信のレイヤーよりも下位レイヤーにおけるプロコトルでの制御全般を行う。
　アプリケーション実行部３０１は、ＳＯＭＥ／ＩＰクライアントに相当し、ＳＯＭＥ／ＩＰマスタ部３０２は、ＳＯＭＥ／ＩＰサーバに相当する。これらアプリケーション実行部３０１とＳＯＭＥ／ＩＰマスタ部３０２との通信は、例えばループバックアドレスを用いることにより、車載装置２内におけるＩＰ通信として実行されるものとなる。従って、ＳＯＭＥ／ＩＰクライアントとして機能するアプリケーション実行部３０１と、ＳＯＭＥ／ＩＰサーバとして機能するＳＯＭＥ／ＩＰマスタ部３０２とは、実施形態１及び２の車載装置２と車載ＥＣＵ６と同様に、セキュリティレベルに応じたセキュリティ処理が施されたＳＯＭＥ／ＩＰ通信、すなわち保護されたＳＯＭＥ／ＩＰメッセージの送受信を行うことができる。このように実施形態１及び２にて示されるＳＯＭＥ／ＩＰ通信に関するセキュリティ処理を、単一の装置（通信ノード）である車載装置２に対しても適用することができ、当該セキュリティ処理の可用性を拡大することができる。
　単一の装置（通信ノード）である車載装置２に対しＳＯＭＥ／ＩＰ通信に関するセキュリティ処理を適用する形態は、ハードウェアリソースがＯＳ（operating system）等によりダイレクトに制御される実環境である場合に限定されない。本実施形態によるＳＯＭＥ／ＩＰ通信に関するセキュリティ処理は、例えばＨｙｐｅｒｖｉｓｏｒ（ハイパーバイザー）等の仮想化システムにて生成された複数の仮想環境（仮想マシン）間でのＳＯＭＥ／ＩＰ通信に適用されるものであってもよい。すなわち、これら複数の仮想マシンのいずれかの仮想マシンがＳＯＭＥ／ＩＰサーバとして機能し、他の仮想マシンがＳＯＭＥ／ＩＰクライアントとして機能するものであってもよい。このように仮想環境（仮想マシン）に対しても、実施形態１及び２にて示されるＳＯＭＥ／ＩＰ通信に関するセキュリティ処理を適用することにより、当該セキュリティ処理の可用性を拡大することができる。
　今回開示された実施形態は全ての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。
　請求の範囲に記載されている複数の請求項に関して、引用形式に関わらず、相互に組み合わせることが可能である。請求の範囲では、複数の請求項に従属する多項従属請求項を記載してもよい。多項従属請求項に従属する多項従属請求項を記載してもよい。多項従属請求項に従属する多項従属請求項が記載されていない場合であっても、これは、多項従属請求項に従属する多項従属請求項の記載を制限するものではない。
　Ｃ　車両　
　Ｓ　車載システム
　１　車外通信装置
　１１　アンテナ
　２　車載装置（ＳＯＭＥ／ＩＰサーバ）
　３　制御部
　３０１　アプリケーション実行部
　３０２　ＳＯＭＥ／ＩＰマスタ部
　３０３　プラットフォーム部
　４　記憶部
　５　車内通信部
　Ｍ　記録媒体
　Ｐ　制御プログラム（プログラム製品）
　６　車載ＥＣＵ（ＳＯＭＥ／ＩＰクライアント）
　７　車載ネットワーク
　７１　通信線

Claims (12)

  1. 　車両に搭載される車載ＥＣＵと通信可能に接続される車載装置であって、
    　前記車載ＥＣＵからのサービスの要求に関する処理を行う制御部を備え、
    　前記制御部は、
    　前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、
    　取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、
    　特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、
    　生成した提供データを前記車載ＥＣＵへ出力する
    　車載装置。
  2. 　セキュリティレベルに基づく提供データの生成処理は、メッセージ認証コードの付与処理、デジタル署名の付与処理、及び提供データに含まれるペイロードの暗号化処理の内の少なくとも１つ以上のセキュリティ処理を含み、
    　前記制御部は、特定したセキュリティレベルに応じて、提供データを生成する際のセキュリティ処理を異ならせる
    　請求項１に記載の車載装置。
  3. 　前記制御部は、セキュリティレベルの増加に応じて、提供データの生成処理に含まれるセキュリティ処理の種類数を増加する
    　請求項２に記載の車載装置。
  4. 　前記制御部は、アクセス可能な記憶領域に記憶されており、セキュリティレベルに関する設定情報を含むサービステーブルを参照することにより、セキュリティレベルを特定する
    　請求項１に記載の車載装置。
  5. 　前記制御部は、
    　前記車両内における通信に影響を与える攻撃が実施された場合、前記サービステーブルに含まれているセキュリティレベルに関する設定情報を変更し、
    　変更されたセキュリティレベルに基づき生成した提供データを、前記車載ＥＣＵへ再送する
    　請求項４に記載の車載装置。
  6. 　前記制御部は、
    　取得した要求データの正当性を判定し、
    　正当性の判定結果が肯定的である場合、提供データを出力し、
    　正当性の判定結果が否定的である場合、提供データを出力しない
    　請求項１に記載の車載装置。
  7. 　前記制御部は、
    　正当性の判定結果が肯定的である場合、セッション鍵を生成し、
    　前記セッション鍵を含めた提供データを前記車載ＥＣＵへ出力する
    　請求項６に記載の車載装置。
  8. 　前記車載ＥＣＵからの要求データは、前記車載ＥＣＵが保持する秘密鍵に対応した公開鍵を含み、
    　前記制御部は、前記車載ＥＣＵの公開鍵を用いて暗号化した提供データを、前記車載ＥＣＵへ出力する
    　請求項１に記載の車載装置。
  9. 　前記車載ＥＣＵとの通信のプロコトルは、ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）であり、
    　要求データは、ＳＯＭＥ／ＩＰにおけるＦｉｎｄ　Ｓｅｒｖｉｃｅに相当し、
    　提供データは、ＳＯＭＥ／ＩＰにおけるＯｆｆｅｒ　Ｓｅｒｖｉｃｅに相当する
    　請求項１から請求項８のいずれか１項に記載の車載装置。
  10. 　前記車載ＥＣＵと車載装置とは単一の装置として構成され、
    　前記車載ＥＣＵと車載装置との間における通信は、車載装置におけるアプリケーション間の通信に相当する
    　請求項９に記載の車載装置。
  11. 　車両に搭載される車載ＥＣＵと通信可能に接続されるコンピュータに、
    　前記車載ＥＣＵからのサービスの要求に関する要求データを取得し、
    　取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、
    　特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、
    　生成した提供データを前記車載ＥＣＵへ出力する
    　処理を実行させる情報処理方法。
  12. 　車両に搭載される車載ＥＣＵと、前記車載ＥＣＵと通信可能に接続される車載装置とを含む車載システムであって、
    　前記車載ＥＣＵは、
    　サービスの要求に関する要求データを生成し、
    　生成した要求データを前記車載装置へ出力し、
    　前記車載装置は、
    　前記車載ＥＣＵから要求データを取得し、
    　取得した要求データに基づき、前記車載ＥＣＵに提供するサービス及び、サービスを提供する際のセキュリティレベルを特定し、
    　特定したセキュリティレベルに基づき、前記車載ＥＣＵにサービスを提供するための提供データを生成し、
    　生成した提供データを前記車載ＥＣＵへ出力する
    　車載システム。
PCT/JP2023/047307 2023-01-16 2023-12-28 車載装置、情報処理方法及び、車載システム Ceased WO2024154585A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202380090739.3A CN120530600A (zh) 2023-01-16 2023-12-28 车载装置、信息处理方法及车载系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2023-004583 2023-01-16
JP2023004583A JP2024100524A (ja) 2023-01-16 2023-01-16 車載装置、情報処理方法及び、車載システム

Publications (1)

Publication Number Publication Date
WO2024154585A1 true WO2024154585A1 (ja) 2024-07-25

Family

ID=91955891

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/047307 Ceased WO2024154585A1 (ja) 2023-01-16 2023-12-28 車載装置、情報処理方法及び、車載システム

Country Status (3)

Country Link
JP (1) JP2024100524A (ja)
CN (1) CN120530600A (ja)
WO (1) WO2024154585A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018157463A (ja) * 2017-03-21 2018-10-04 オムロンオートモーティブエレクトロニクス株式会社 車載通信システム、通信管理装置、車両制御装置
US20210398364A1 (en) * 2018-10-02 2021-12-23 Volkswagen Aktiengesellschaft Method for executing one or more vehicle applications using a vehicle computation unit of a vehicle, vehicle computation unit, method for providing a permission information manifest for a vehicle application, permission information manifest for a vehicle application and computer program
JP2022530406A (ja) * 2019-04-23 2022-06-29 イタルデザイン－ジュジアーロ・ソシエタ・ペル・アチオニ Ｓｏｍｅ／ｉｐ通信プロトコルを用いる乗物上におけるデータ又はメッセージの伝送の改良

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018157463A (ja) * 2017-03-21 2018-10-04 オムロンオートモーティブエレクトロニクス株式会社 車載通信システム、通信管理装置、車両制御装置
US20210398364A1 (en) * 2018-10-02 2021-12-23 Volkswagen Aktiengesellschaft Method for executing one or more vehicle applications using a vehicle computation unit of a vehicle, vehicle computation unit, method for providing a permission information manifest for a vehicle application, permission information manifest for a vehicle application and computer program
JP2022530406A (ja) * 2019-04-23 2022-06-29 イタルデザイン－ジュジアーロ・ソシエタ・ペル・アチオニ Ｓｏｍｅ／ｉｐ通信プロトコルを用いる乗物上におけるデータ又はメッセージの伝送の改良

Also Published As

Publication number Publication date
JP2024100524A (ja) 2024-07-26
CN120530600A (zh) 2025-08-22

Similar Documents

Publication Publication Date Title
US12217042B2 (en) Method and apparatus for processing upgrade package of vehicle
US10708248B2 (en) Vehicle and method for controlling same
EP3780481B1 (en) Method for upgrading vehicle-mounted device, and related device
EP3348036B1 (en) Unauthorized access event notificaiton for vehicle electronic control units
US9215228B1 (en) Authentication of devices having unequal capabilities
US20160173530A1 (en) Vehicle-Mounted Network System
JP7747034B2 (ja) 設定装置、通信システムおよび車両通信管理方法
JP7647974B2 (ja) 中継装置、車両通信方法および車両通信プログラム
Kohli et al. Security of cloud-based vehicular ad-hoc communication networks, challenges and solutions
JP7704192B2 (ja) 車載中継装置、管理装置、車載システムおよび通信管理方法
CN116685971A (zh) 服务中介装置、服务中介方法和程序
JP6677132B2 (ja) 車載通信機、管理装置、管理方法および監視プログラム
KR20190127867A (ko) 통신 디바이스의 평판 레벨을 관리하기 위한 방법
KR20180072340A (ko) 운송 수단 내부 네트워크에서의 제어 데이터를 보안 전송하는 방법
CN119995841A (zh) 一种认证车联网通信安全的系统、方法、装置、设备和存储介质
WO2024154585A1 (ja) 車載装置、情報処理方法及び、車載システム
JP6830877B2 (ja) 配信システム、鍵生成装置、配信方法、及びコンピュータプログラム
JP6218914B1 (ja) 配信システム、データ保安装置、配信方法、及びコンピュータプログラム
CN115883174A (zh) 一种适用于汽车ecu ota升级的国密混合加密算法、装置及存储介质
JP7704051B2 (ja) 車載通信装置及び車載通信システム
US12088672B1 (en) Efficient and secured access to in-vehicle end nodes across a vehicle fleet
JP6681755B2 (ja) 車両用通信網装置及び通信方法
WO2025220668A1 (ja) セキュリティシステム、セキュリティ装置、及びセキュリティ方法
JP2024131140A (ja) 車両制御システムおよび通信処理方法
KR20220085375A (ko) 블록체인 기반 공개키 관리 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23916605

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202380090739.3

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 202380090739.3

Country of ref document: CN